entity_binding_hierarchy.md

Entity Binding Hierarchy in Web4

Implementation from modbatt-CAN demonstrating multi-level entity binding through cryptographic key chains

Overview

The modbatt-CAN project implements a concrete example of Web4's entity binding hierarchy through a multi-level cryptographic key distribution system. This demonstrates how physical devices establish witnessed presence through hierarchical binding relationships.

Implementation Hierarchy

Level 1: API-Bridge (Root Authority)

• Role: Trust root and witness aggregator
• LCT Type: Domain-level LCT
• MRH Tensor: Contains links to all registered components
• Witnessing: Records all component registrations

Level 2: Windows Application (Intermediary Entity)

• Role: Bridge between digital and physical realms
• Binding Keys:
  • App Private Key (32 bytes) - Identity core, never shared
  • App Public Key (32 bytes) - Shared for witnessing
• MRH Tensor Links:
  • Upward: API-Bridge (HTTP/Web connection)
  • Downward: Pack Controller (CAN bus connection)
• Witnessing Actions:
  • Witnesses device public keys
  • Registers devices with API-Bridge on their behalf
  • Creates bidirectional presence links

Level 3: Pack Controller (Device Entity)

• Role: Physical device coordinator
• Binding Keys:
  • Device Private Key (32 bytes) - Stored in flash, never transmitted
  • Device Public Key (32 bytes) - Shared for identity establishment
  • App Public Key (32 bytes) - Received and stored for trust
  • Module Public Key (32 bytes) - Received from downstream
• MRH Tensor Links:
  • Upward: Windows App (via CAN)
  • Downward: Battery Modules (via CAN)
• Witnessing: Bridges app-level presence to module-level presence

Level 4: Battery Module (Leaf Entity)

• Role: Physical component with individual identity
• Binding Keys:
  • Module Private Key (32 bytes) - Hardware-bound identity
  • Module Public Key (32 bytes) - Shared upward
  • Pack Controller Public Key (32 bytes) - Trust anchor
  • App Public Key (32 bytes) - Ultimate authority link
• MRH Tensor: Terminal node with upward links only
• Witnessing: Exists through being witnessed by pack controller

Key Exchange as Witnessed Presence Creation

Phase 1: Public Key Exchange (Identity Announcement)

Module → Pack Controller: "Here is my public key" (I exist)
Pack Controller → App: "Here is my public key" (I exist)
App → API-Bridge: "Here are all the public keys" (We all exist)

Each exchange creates bidirectional MRH tensor links:

• Sender's tensor gains witness link
• Receiver's tensor gains witnessing link
• Both entities become more "present" through mutual recognition

Phase 2: Key Distribution (Trust Establishment)

API-Bridge → App: Encrypted key halves
App → Pack Controller: Encrypted(device_key_half)
Pack Controller → Module: Encrypted(module_key_half)

The encryption using public keys ensures:

• Only the intended entity can decrypt (authentication)
• The act of successful decryption is self-witnessing
• Failed decryption breaks the presence chain

Connection to Web4 LCT Principles

1. Unforgeability Through Witnessing

• Physical Implementation: Device can't claim identity without app witnessing
• Cryptographic Proof: Public key exchange creates verifiable presence
• Hierarchical Validation: Each level witnesses the level below

2. Bidirectional Links

• App ↔ Pack Controller: Both store each other's public keys
• Pack Controller ↔ Module: Mutual key storage
• Cannot be faked: Would require private key of both parties

3. Cross-Domain Validation

• Web Domain: API-Bridge (HTTP/REST)
• Application Domain: Windows App (OS-level)
• Embedded Domain: Pack Controller (Firmware)
• Hardware Domain: Battery Module (Physical)

Each domain transition requires witnessed key exchange, creating a verifiable chain of presence from web to physical hardware.

4. Presence Accumulation

Initial State: Module exists but has no digital presence
↓ Module generates keypair
↓ Pack Controller witnesses module (first presence)
↓ App witnesses pack controller witnessing module (stronger presence)
↓ API-Bridge records entire chain (permanent presence)
Result: Module now has verifiable digital presence

Security Properties Through Binding

What Binding Achieves

• Confidentiality: Only bound entities can decrypt communications
• Authentication: Binding keys prove entity identity
• Integrity: Tampering breaks cryptographic verification
• Non-repudiation: Actions are cryptographically signed by bound keys
• Witnessed Presence: Entity exists because others acknowledge it

Trust Degradation Prevention

Each level of binding maintains trust:

1. API-Bridge binding: Ensures app is authorized
2. App binding: Ensures devices are genuine
3. Device binding: Ensures modules are authentic
4. Module binding: Ensures component integrity

Implementation as MRH Tensor

The binding key architecture directly implements MRH tensors:

// This C++ structure IS an MRH tensor
struct binding_keys_t {
    uint8_t device_private_key[32];     // Identity core (never shared)
    uint8_t device_public_key[32];      // Presence announcement
    uint8_t app_public_key[32];         // Upward MRH link
    uint8_t module_public_key[32];      // Downward MRH link
    bool keys_initialized;              // Presence state
};

Each key represents a tensor link:

• Private key: Entity's core identity (self-link)
• Own public key: Outward presence projection
• Others' public keys: Bidirectional witness links

Practical Benefits

1. Tamper-Proof Device Identity

• Devices can't be impersonated without private keys
• Replacement devices must go through full binding process
• Historical actions remain attributed to original device

2. Secure Firmware Updates

• Updates can be signed with binding keys
• Only properly bound devices accept updates
• Rogue firmware rejected by binding validation

3. Supply Chain Security

• Each component's journey witnessed and recorded
• Manufacturing, testing, installation all create presence
• Counterfeit components lack witness history

Future Extensions

Hardware Security Modules (HSM)

• Store private keys in tamper-proof hardware
• Make physical extraction impossible
• Strengthen the physical-digital binding

Factory Pre-Programming

• Burn initial public keys during manufacturing
• Create "birth certificate" LCTs
• Establish presence from moment of creation

Cross-Manufacturer Binding

• Different vendors' components can establish mutual presence
• Industry-wide trust networks emerge
• Interoperability through witnessed standards

Conclusion

The modbatt-CAN implementation demonstrates that Web4's entity binding hierarchy is not theoretical but practical. Through cryptographic key chains and witnessed presence, we create verifiable presence from web services down to individual hardware components.

This is Web4 in action: Every entity, from API to battery cell, exists through being witnessed, and presence accumulates through hierarchical binding relationships.

The binding keys ARE the MRH tensor links. The key exchange IS the witnessing. The encryption IS the trust relationship. What seems like a security protocol is actually the implementation of witnessed presence across domains.

"In Web4, you don't just have a key. You ARE a key in the universal trust tensor, witnessed into existence by your connections."