Hardware Class 1 - Overview and Threat Model
Document version: Session 44 | March 2026 Applies to: LilyGo T-Deck Plus (ESP32-S3), Guition JC4880P443C (ESP32-P4 + ESP32-C6) Copyright: 2025-2026 Sascha Daemgen, IT and More Systems, Recklinghausen License: AGPL-3.0 (Software) | CERN-OHL-W-2.0 (Hardware)
What is Hardware Class 1?
Hardware Class 1 is the foundation tier of SimpleGo's hardware security architecture. It runs on commercially available ESP32-based development boards without external secure elements, using only the security features built into the ESP32 silicon itself: one-time-programmable eFuse memory, an HMAC hardware peripheral for key derivation, AES-XTS flash encryption, and RSA-3072 Secure Boot V2.
SimpleGo is not a smartphone app. It is a complete standalone firmware running as multiple parallel FreeRTOS tasks on two CPU cores. There is no Android, no Linux, no baseband processor, no browser engine, no Bluetooth stack in active use, no USB mass storage, no NFC. The entire codebase is 47 source files totaling 21,863 lines of C. Every message passes through four cryptographically independent encryption layers before reaching the network: Double Ratchet (X448 + AES-256-GCM), Per-Queue NaCl cryptobox (X25519 + XSalsa20 + Poly1305), Server-to-Recipient NaCl cryptobox, and TLS 1.3 transport. Content padding to fixed 16 KB blocks makes all messages identical in size to a network observer.
Hardware Class 1 security protects the keys that make this encryption work. Without key protection, the four encryption layers are meaningless to an attacker who can simply read the private keys from the device's flash memory.
The Three Pillars
Hardware Class 1 security rests on three pillars. All three must be implemented for the security concept to be considered complete. A device with only one or two pillars has gaps that undermine the overall protection.
Pillar 1: The Vault (Keys at Rest)
All cryptographic keys stored in non-volatile flash memory are encrypted using a hardware-derived key that cannot be read by software, by debug interfaces, or by physically reading the flash chip. The encryption key is generated by the device's hardware random number generator at first boot, burned permanently into a one-time-programmable eFuse block, and protected by hardware read-protection that makes the raw key invisible even to the device's own firmware. NVS encryption and decryption happen transparently through the HMAC hardware peripheral at runtime.
Every SimpleGo device generates its own unique vault key. No master key exists. Not even the manufacturer (IT and More Systems) can decrypt a device's stored keys.
Technical details: HMAC-Based NVS Encryption eFuse hardware reference: ESP32-S3 eFuse Architecture
Pillar 2: Runtime Hygiene (Keys and Messages in RAM)
Decrypted messages and derived key material in volatile RAM are securely overwritten with zeros when no longer needed. This happens at every security-relevant transition: when the user switches between contacts, when the chat screen is closed, when the display times out, and at device shutdown. The LVGL display memory pool is also cleared, preventing message text from surviving in the UI framework's internal buffers.
The principle is simple: what is not in memory cannot be stolen from memory. Even if an attacker bypasses the vault, the window during which sensitive data exists in RAM is minimized.
Technical details: Runtime Memory Protection
Pillar 3: Post-Quantum Readiness
The architecture does not block future activation of hybrid post-quantum key exchange. Published academic benchmarks demonstrate that lattice-based key encapsulation (ML-KEM / CRYSTALS-Kyber) runs in under 10 milliseconds on ESP32 hardware with hardware acceleration. The ciphertext fits within the SimpleX Messaging Protocol's 16 KB transport blocks. No eFuse blocks are consumed. No hardware changes are required.
This is not a marketing promise - it is a verifiable technical statement backed by published research and open-source reference implementations on the exact hardware platform.
Technical details: Post-Quantum Readiness
What Hardware Class 1 Protects Against
Flash readout attacks
The most common and accessible physical attack against embedded devices is reading the external flash memory. On an unprotected ESP32, anyone with a $15 SPI flash reader and 5 minutes of time can dump the entire flash contents, including all private cryptographic keys stored in the NVS partition. With the HMAC vault active, the NVS partition is encrypted with a key derived from eFuse hardware that cannot be read externally. The attacker sees encrypted data that is computationally infeasible to decrypt without the hardware key.
Casual physical access
A stolen or confiscated device with the vault active and display timed out holds no plaintext messages in RAM (Pillar 2) and no readable keys in flash (Pillar 1). The attacker would need to connect laboratory equipment to the powered device before the display timeout triggers memory clearing, or attempt side-channel analysis of the eFuse-derived keys - both requiring specialized equipment and expertise.
Remote network attacks
SimpleGo's attack surface for remote exploitation is extraordinarily small compared to any smartphone. The device exposes exactly one network service: a TLS 1.3 connection to SimpleX Messaging Protocol servers. There is no web browser, no Bluetooth listener, no NFC reader, no USB data interface, no cellular baseband. The entire network stack consists of the ESP-IDF WiFi driver, the mbedTLS TLS implementation, and SimpleGo's SMP client code.
A remote attacker cannot discover that a SimpleGo device exists on a network without monitoring traffic to specific SMP servers. SimpleX Protocol uses no persistent user identities - no phone number, no username, no IMEI, no device ID. Separate message queues on potentially different servers are used for each contact, preventing traffic correlation even if one server is fully compromised. Content padding to fixed 16 KB blocks prevents message length analysis.
Even if TLS 1.3 were fully compromised (a zero-day in mbedTLS, for example), three additional independent encryption layers protect every message. Layer 3 (Server-to-Recipient NaCl) was specifically designed for this scenario. Layer 2 (Per-Queue NaCl) prevents cross-queue correlation. Layer 1 (Double Ratchet with Perfect Forward Secrecy) ensures that compromise of current keys does not reveal past messages.
Server compromise
SimpleX Protocol's architecture means that a compromised server sees only encrypted 16 KB blocks, has no knowledge of user identities, cannot correlate senders with recipients (only queue-to-queue relationships), and cannot forge messages (the sender's NaCl signature would not validate). This is architecturally superior to any centralized messaging system and is the primary reason SimpleGo implements the SimpleX Protocol rather than Signal, Matrix, or custom protocols.
Firmware tampering (Modes 3 and 4)
When Flash Encryption and Secure Boot are enabled, the device rejects any unsigned or unencrypted firmware. An attacker who obtains physical access cannot flash malicious firmware to extract keys - the device will only execute code signed with IT and More Systems' RSA-3072 private key. This protection is available in Hardware Class 1 Modes 3 and 4 but requires manufacturing-time provisioning.
Technical details: Four Security Modes
What Hardware Class 1 Does NOT Protect Against
This section exists because honesty about limitations is more valuable than false confidence. Every claim SimpleGo makes must withstand scrutiny from security researchers, and overstating protection destroys credibility permanently.
Side-channel analysis with laboratory equipment
Published research has demonstrated that the AES hardware accelerator in ESP32-family chips (including the ESP32-S3 used in SimpleGo) is vulnerable to Correlation Power Analysis (CPA). Researchers at Ledger's Donjon security lab extracted the complete 256-bit flash encryption key from an ESP32-V3 using approximately 300,000 power measurements collected over roughly 2 hours. Espressif has confirmed in advisory AR2022-003 that this vulnerability likely applies to the ESP32-S3 and has stated that hardware countermeasures will only be available in future chip generations.
The HMAC peripheral (used for NVS encryption) has not been specifically targeted by published side-channel research. Its internal use of SHA-256 (rather than AES) means that CPA techniques do not transfer directly, and the limited number of HMAC operations during boot provides fewer exploitable traces. However, the conservative assumption is that a sufficiently motivated researcher with physical access and appropriate equipment could eventually extract the HMAC key as well.
The ESP32-P4 (planned evolution for Class 1) includes anti-DPA pseudo-rounds for AES and a Power Glitch Detector, which raise the bar but have not yet been independently validated against attack.
Equipment cost for side-channel analysis ranges from approximately $2,000 (researcher-grade) to $30,000 (professional lab). Every attack requires sustained physical possession of the specific target device. Compromising one device reveals nothing about any other SimpleGo device.
Technical details: Known Vulnerabilities and Attack Research Equipment analysis: Attack Equipment Economics
Electromagnetic fault injection
Researchers have demonstrated electromagnetic fault injection (EMFI) attacks against ESP32 chips that can bypass Secure Boot and redirect program execution. These attacks require an EM pulse generator, precision positioning equipment, an oscilloscope, and physical access to the chip. Success requires optimization of timing parameters that varies per individual chip specimen.
The ESP32-P4's Power Glitch Detector provides some mitigation, but its effectiveness against EMFI specifically has not been independently tested.
State-level adversaries with physical access
A well-resourced intelligence agency with sustained physical access to a specific SimpleGo Class 1 device can likely extract its cryptographic keys using a combination of the techniques described above. Hardware Class 1 is not designed to resist this threat level. For protection against state-level physical attacks, Hardware Class 2 (single dedicated secure element) and Hardware Class 3 (triple-vendor secure elements with tamper detection) are planned.
Compromised WiFi infrastructure
SimpleGo connects to the internet via WiFi. An attacker who controls the WiFi access point can observe that the device connects to SMP servers (visible as TLS connections to known IP addresses). They cannot read message content (four encryption layers), but they can observe connection timing and data volume patterns. Private Message Routing (on the roadmap) mitigates this by routing through intermediate servers, hiding the destination server from the WiFi observer.
User-level operational security failures
No hardware security can protect against a user who shares their device unlock code, photographs their screen, or verbally reveals message contents. SimpleGo protects the cryptographic channel - operational security of the endpoints remains the user's responsibility.
Comparison with Existing Devices
SimpleGo vs hardened smartphones (GrapheneOS on Pixel)
GrapheneOS is the most secure smartphone operating system available. It provides verified boot with Titan M2 hardware attestation, hardened memory allocator, per-profile encryption, auto-reboot on inactivity, and the best available baseband isolation through IOMMU. The Titan M2 is a dedicated secure element with side-channel countermeasures that significantly exceed what the ESP32-S3 eFuse system provides against physical attacks.
However, GrapheneOS operates within architectural constraints that SimpleGo avoids entirely. A Pixel phone contains a cellular baseband processor running proprietary Qualcomm firmware - a secondary computer with known vulnerability classes (29 bugs found by BASECOMP, USENIX Security 2023). GrapheneOS isolates it brilliantly but cannot eliminate it. The AOSP codebase contains millions of lines of code, providing vastly more attack surface for remote exploitation. Every Pixel has an IMEI, a phone number, and registers with cellular networks - creating metadata that SimpleX Protocol is specifically designed to eliminate.
SimpleGo and GrapheneOS are not competitors. They are complementary security layers. GrapheneOS is the best hardened daily-driver smartphone. SimpleGo is the dedicated secure channel for communications where the threat model demands that no general-purpose computing stack, no baseband processor, and no persistent identity sit between the message and the wire.
SimpleGo vs LoRa mesh devices (Meshtastic, Reticulum)
LoRa mesh messengers achieve three of SimpleGo's six target security features: bare-metal firmware, no baseband processor, and open source code. They lack multi-layer encryption (maximum 2 layers vs SimpleGo's 4), have no hardware secure elements or eFuse key protection (keys stored in unprotected flash), use persistent node identities based on MAC addresses, and provide no forward secrecy for group messages.
SimpleGo's 16 KB SMP message blocks also carry significantly more payload than typical LoRa packets (which are limited to 256 bytes at common spreading factors), enabling full JSON-formatted application-layer messages rather than compressed short texts.
SimpleGo vs encrypted phone networks (EncroChat, Sky ECC, ANOM)
Every criminal encrypted phone network that has been shut down (EncroChat 2020, Sky ECC 2021, ANOM 2021, Phantom Secure 2018, Ghost 2024) shared the same fatal architecture: modified Android smartphones with centralized server infrastructure. They were compromised through server-side attacks, not by breaking encryption. SimpleX Protocol's serverless identity model and independent per-contact queues eliminate the centralized infrastructure that enabled these takedowns. SimpleGo adds hardware-level key protection that none of these services provided.
SimpleGo vs military-grade devices (Sectra Tiger, Sectéra vIPer)
Military Type 1 devices use classified encryption algorithms, TEMPEST shielding, and extensive tamper detection. They are also proprietary, closed-source, extremely expensive (typically government-only procurement), and require persistent identity binding to military communication networks. SimpleGo occupies a fundamentally different position: open-source, identity-free, commercially available, and relying on publicly audited cryptographic algorithms (the Trail of Bits cryptographic review of SimpleX SMP, July 2024, found the protocol sound).
Hardware Class 1 Devices
Currently supported: LilyGo T-Deck Plus (ESP32-S3)
| Property | Specification |
|---|---|
| MCU | ESP32-S3 Dual-Core Xtensa LX7, 240 MHz |
| SRAM | 512 KB |
| PSRAM | 8 MB (external) |
| Flash | 16 MB (external SPI) |
| Display | 320x240 ST7789V IPS LCD |
| Input | BB Q20 QWERTY keyboard + trackball |
| Connectivity | WiFi 802.11 b/g/n, Bluetooth 5.0 (disabled in SimpleGo) |
| SD Card | MicroSD slot, FAT32, AES-256-GCM encrypted per contact |
| eFuse Key Blocks | 6 (256 bits each) |
| Security features | HMAC peripheral, AES-XTS flash encryption, Secure Boot V2 (RSA-3072), TRNG |
| Side-channel countermeasures | None |
| Price | $50-70 (retail) |
Planned evolution: ESP32-P4 + ESP32-C6 dual-chip board
| Property | Specification |
|---|---|
| MCU | ESP32-P4 Dual-Core RISC-V, 400 MHz + ESP32-C6 (WiFi/BT companion) |
| SRAM | 768 KB (P4) |
| PSRAM | 32 MB (in-package) |
| Connectivity | WiFi 6 + Bluetooth 5.0 via ESP32-C6 over SDIO |
| eFuse Key Blocks | 6 (256 bits each) |
| Security features | Key Management Unit, Digital Signature Peripheral, HMAC, AES-XTS, Secure Boot V2 (RSA-3072 + ECDSA), TRNG |
| Side-channel countermeasures | Anti-DPA pseudo-rounds for AES (configurable), Power Glitch Detector |
| Price | Under evaluation |
The ESP32-P4 represents a significant security upgrade within Class 1. Its Key Management Unit ensures private keys can be used for cryptographic operations without ever being exposed to firmware in plaintext. The anti-DPA pseudo-rounds randomize the power profile during AES operations, increasing the measurement count required for successful side-channel analysis. The dual-chip architecture (P4 for computation, C6 for wireless) mirrors SimpleGo's security principle of functional separation.
Technical details: ESP32-P4 Evolution Path
Security Mode Summary
Hardware Class 1 supports four progressive security modes on the same hardware and firmware:
| Mode | Name | What is locked | Web Flash | OTA | Who provisions |
|---|---|---|---|---|---|
| 1 | Open | Nothing | Yes | Yes | Nobody |
| 2 | NVS Vault | 1 eFuse block (HMAC key) | Yes | Yes | Device itself (first boot) |
| 3 | Fortress | 2-3 eFuse blocks (HMAC + Flash Encryption) | No | Yes | Manufacturer |
| 4 | Bunker | 3-4 eFuse blocks (HMAC + FE + Secure Boot) | No | Signed only | Manufacturer |
Each mode builds on the previous. The user or manufacturer chooses the appropriate level. Mode 1 can always transition to Mode 2 (automatic at first boot). Mode 2 can transition to Mode 3 or 4 (requires manufacturer tooling). No mode can be downgraded once activated - eFuse burns are permanent by design.
Technical details: Four Security Modes
Document Navigation
This document provides the overview. For technical depth on any specific topic, follow the links below:
| Topic | Document |
|---|---|
| eFuse hardware details | ESP32-S3 eFuse Architecture |
| Key vault implementation | HMAC-Based NVS Encryption |
| All known attacks and CVEs | Known Vulnerabilities and Attack Research |
| Cost to break a device | Attack Equipment Economics |
| RAM protection and memory wiping | Runtime Memory Protection |
| Quantum-resistant key exchange | Post-Quantum Readiness |
| Firmware confidentiality | Flash Encryption Deep Dive |
| Firmware integrity | Secure Boot V2 |
| Installation and provisioning modes | Four Security Modes |
| Next-generation ESP32-P4 | ESP32-P4 Evolution Path |
| How to build it | Implementation Plan |
SimpleGo - IT and More Systems, Recklinghausen First native C implementation of the SimpleX Messaging Protocol AGPL-3.0 (Software) | CERN-OHL-W-2.0 (Hardware)