Date: 2026-05-15 Scope: Self-contained introduction to the DevProof P2P edge TEE system built on NXP silicon Core Insight: Attestation + open-source code = the trust boundary. Hardware provides the proof, protocol handles the misbehavior.
DevProof is a p2p secretnetwork architecture built on NXP RT1180/i.MX93 silicon. It combines hardware-rooted attestation (EdgeLock Enclave + HAB4 secure boot) with threshold cryptography and BFT consensus to create a network where nodes are verified but potentially misaligned - the protocol tolerates misbehavior up to a Byzantine fault threshold.
The key architectural realization: If the whole firmware stack is open source, attested, and can't self-modify, the trust boundary is the attestation itself, not hardware isolation zones. You don't need to trust the operator - you trust the silicon proving what it runs.
Dual-core architecture:
- Cortex-M7 @ 800MHz: High-performance core for crypto operations, message processing, protocol handling
- Cortex-M33 @ 300MHz: Low-power core with TrustZone-M for TEE, attestation, and key storage
Memory hierarchy:
- 1.5MB on-chip SRAM with ECC
- ~128KB OCRAM (On-Chip RAM) with hardware-gated secure/non-secure access
- External memory via Octal SPI, DDR, HyperRAM interfaces
Security primitives:
- EdgeLock Enclave (ELE): Hardware-isolated security subsystem with independent processing, TRNG, key storage, and cryptographic acceleration (AES, SHA, ECC, RSA)
- HAB4 (High Assurance Boot v4): Cryptographic boot chain verification from ROM → SPL → bootloader → application
- TrustZone-M: Hardware memory isolation between secure (M33) and non-secure (M7) worlds
- SecureJTAG (SJC): Challenge-response debug authentication with fuse-based lockout
- Fuses: One-time programmable boot config, debug lock, lifecycle state
Performance:
- ~50 msg/sec crypto throughput
- ECDSA P-256 sign: ~2ms (M7), ~5ms (M33)
- AES-256-GCM (1KB): ~0.1ms (hw accel)
- Limited by no MMU - bare-metal RTOS only
Tri-core architecture:
- 2x Cortex-A55 @ 1.7GHz: Full ARMv8-A with MMU - runs Linux, handles consensus, orchestration
- Cortex-M33 @ 400MHz: TrustZone-M TEE for attestation and key storage
Security parity with RT1180:
- Same ELE attestation protocol, HAB4 boot chain, TrustZone isolation
- 640KB OCRAM with ECC
- Identical physical attack surface (same die construction)
Performance:
- ~500 msg/sec crypto throughput
- Full Linux networking stack
- Hermes agent hosting capability
Both SoCs share identical physical exposure. Security is architectural, not physical:
- OCRAM has hardware-gated access control - M7 can't read secure regions from M33
- ELE is a separate processing unit - not bus-accessible from main cores
- Decapping exposes both cores identically - no physical security distinction
Purpose: Prove hardware identity and firmware integrity to the network.
Boot chain measurements (HAB4):
Boot ROM (fused) → SPL → Bootloader → TEE on M33 → Application
Each stage measures the next stage's hash into RTCs (Revocation and Trust Control registers).
Attestation report contents:
- HAB4 fuse state and boot measurements (8 RTCs)
- OCRAM hash (code integrity)
- Enclave hash (TEE image integrity)
- Device identity (chip-unique from fuses)
- ELRNG nonce proof (proves live generation, not replay)
- Signed with chip-unique ELE attestation key
Protocol:
- Verifier sends random 32-byte challenge + timestamp
- Node signs challenge with ELE key + generates attestation report
- Verifier validates signature chain (NXP root CA → device cert) + checks measurements match reference
Continuous attestation: Periodic re-attestation every 300s + on-demand challenge-response.
Purpose: Distribute secrets so no single node holds reconstructable material.
Scheme: (t, n)-threshold Shamir's Secret Sharing over GF(2^256)
- t = floor(2n/3) for BFT threshold
- Pedersen VSS for verifiable share distribution
- Dynamic share refresh every 24h
Example (7 nodes, t=5):
- Need 5 shares to reconstruct secret
- Tolerates 2 Byzantine faults
- Any subset of 5 honest nodes can reconstruct
MPC threshold signatures:
- Nodes compute partial signatures without reconstructing the full secret
- i.MX93 coordinators aggregate partial signatures from RT1180 edge nodes
- Result is a valid ECDSA/Schnorr signature
Purpose: Coordinate network decisions (membership, revocation, config) despite misbehavior.
Protocol: HotStuff-inspired linear pipelined BFT
- View-based leader election
- 4 phases: Propose → Pre-prepare → Prepare → Commit
- Quorum = 2f+1 signatures per phase
- Handles f = floor((n-1)/3) Byzantine faults
RT1180 role: Do not participate in consensus directly. Trust coordinator's consensus outcomes but verify threshold signatures on critical decisions.
Purpose: Detect and mitigate "verified but misaligned" nodes.
Five layered defenses:
-
Suspicion scoring (0-100):
- 0-20: Normal
- 21-40: Increased monitoring
- 41-60: Restricted role
- 61-80: Quarantine
- 81-100: Ejection
-
Receipt-based accountability:
- Nodes prove they forwarded messages via signed receipts
- Missing receipts increment suspicion score
-
Timing side-channel mitigation:
- Constant-time operations
- Random jitter U(0,50ms) on all responses
- Latency budgets per node type
-
Collusion detection:
- Canary secrets injected periodically
- Share consistency checks
- Cross-coordinator verification
-
Ejection protocol:
- BFT consensus required (2f+1 agreement)
- Evidence bundle with proofs
- Graceful degradation
Channels:
- Attestation Channel: DTLS 1.3, mutual auth, AEAD
- Data Channel: Custom UDP, ChaCha20-Poly1305
- Control Channel: Custom TCP over DTLS, AEAD + MAC
- Key Channel: DTLS + threshold signatures
Key exchange: Post-quantum hybrid (X25519 + Kyber-768/ML-KEM), falling back to X25519-only if compute budget exceeded on RT1180.
Topology:
- i.MX93 coordinators form BFT consensus ring
- RT1180 edge nodes attach to coordinators (star topology per cluster)
- Edge nodes communicate through coordinators only (no direct edge-to-edge)
CAN DO:
- Physical access to devices
- Network traffic analysis
- Selective message forwarding
- Timing attacks
- Supply-chain attacks (pre-firmware)
- Side-channel analysis (power, EM, timing)
- Fault injection (voltage, clock, laser)
CANNOT DO:
- Modify firmware remotely (HAB4 + attestation prevents)
- Extract keys from OCRAM (hardware-gated access)
- Bypass attestation (chip-unique ELE keys, non-extractable)
- Reconstruct secrets without threshold (Shamir's scheme)
- Hide misbehavior from protocol (detection engines)
| Attack | Impact | Mitigation |
|---|---|---|
| Firmware modification | High | HAB4 attestation, open-source audit |
| Key extraction | Medium | OCRAM + ELE hardware protection |
| Physical probing | Low | On-die memory, decapping required |
| Timing side channel | Low | Constant-time ops, jitter, budgets |
| Selective forwarding | Medium | Receipt-based accountability |
| Collusion | Medium | Threshold crypto, canary secrets |
| Denial of service | Low | BFT consensus, redundancy |
| Supply chain | High | Attestation + open-source verification |
| Debug interface | Medium | SJC + fuse lockout |
| I2C bus sniffing | Medium | EdgeLock keeps keys internal |
| Voltage/clock glitching | Medium | Vmon, HAB4 crypto verification |
| Cold boot | Medium | EdgeLock tamper-resistant NVM |
Attestation guarantees:
- ✅ Node runs expected firmware
- ✅ Boot chain is intact
- ✅ TEE is operational
Attestation does NOT guarantee:
- ❌ Node forwards all messages
- ❌ Node doesn't add timing side-channels
- ❌ Node doesn't collude with others
- ❌ Node doesn't perform selective DoS
The protocol must tolerate misbehavior from any verified subset of nodes up to the Byzantine fault threshold. This is why threshold cryptography + BFT consensus + misbehavior detection are all essential - they handle what attestation alone cannot.
Functional network:
- 3 i.MX93 coordinators (BFT threshold)
- 5+ RT1180 edge nodes per cluster
- Total: 3+15 = 18 nodes minimum
Cost:
- i.MX93: ~$15-20 per unit
- RT1180: ~$10-15 per unit
- Total: ~$300-450 for minimum network
- Add more i.MX93 coordinators for throughput
- Add more RT1180 edge nodes for redundancy
- No single point of failure
- Geographic distribution supported
- Signed firmware images
- HAB4 measures new boot chain
- Attestation proves update integrity
- Monotonic counter prevents rollback
- Coordinated rollout across clusters
i.MX93 coordinator role:
- Runs full Hermes agent stack (Linux + Python)
- Handles LLM inference orchestration
- Manages secret sharing across edge nodes
- Produces threshold signatures
RT1180 edge role:
- Holds secret shares in secure OCRAM
- Produces partial signatures on request
- Attestation on demand
- No inference capability
Workload distribution:
- Coordinator: Hermes agent runtime, LLM inference, consensus, share management
- Edge: Secret storage, partial signatures, attestation, packet forwarding
RT1180 + EdgeLock provides strong hardware-rooted attestation but has gaps for DevProof:
- EdgeLock proves code provenance but not execution integrity
- Proprietary quote format lacks expressiveness for on-chain verification
- No standard "bind-to-measurement" API for secret sealing (unlike SGX)
23 distinct attack vectors identified. Key findings:
- Most attacks require lab-grade equipment
- EdgeLock SE050/SE051 CC EAL6+ design resists most physical attacks
- RT1180 host MCU crypto has NO side-channel countermeasures
- I2C bus between host and EdgeLock is plaintext (no encryption)
| Feature | RT1180 | i.MX93 |
|---|---|---|
| Cores | M7 + M33 | 2x A55 + M33 |
| MMU | No | Yes (A55) |
| OS | Bare-metal RTOS | Linux + Zephyr TEE |
| OCRAM | ~128KB | ~640KB |
| Crypto throughput | ~50 msg/sec | ~500 msg/sec |
| Role | Edge (shares, signatures) | Coordinator (consensus, orchestration) |
| Cost | ~$10-15 | ~$15-20 |
- RT1180 bare-metal stack (Zephyr/FreeRTOS)
- i.MX93 Linux + Zephyr TEE integration
- ELE attestation integration
- HAB4 boot chain verification
- Secure key storage in OCRAM
- BFT consensus implementation
- Secret sharing scheme
- Misbehavior detection system
- Attestation protocol
- Receipt-based accountability
- Agent runtime on i.MX93
- LLM inference orchestration
- Threshold signature aggregation
- Network management interface
- Monitoring and observability
- Cluster deployment automation
- Firmware update system
- Performance optimization
- Security audit
- Documentation and tooling
- RT1180 Reference Manual:
/hermes/rt1180-report/IMXRT1180RM.pdf - i.MX93 Reference Manual:
/hermes/rt1180-report/IMX93RM.pdf - Architecture doc:
/hermes/rt1180-report/devproof-network-architecture.md - Protocol design:
/hermes/secretnetwork-protocol-design.md - Crypto analysis:
/hermes/crypto-analysis/devproof-cryptographic-analysis.md - Red team assessment:
/hermes/rt1180-edgelock-redteam-analysis.md - Study plan:
/hermes/home/rt1180-tee-workflow/RT1180_STUDY_PLAN.md - Previous gist: https://gist.github.com/amiller/361708a41cffaf66a7dcf9216d911963