Skip to content

Encryption

All SmartPot communications are authenticated using AES-128-CMAC. This page documents the key management model and security considerations.

Each pot has a unique 128-bit AES key, provisioned during firmware flashing. The base station stores all keys for its fleet in encrypted NVS (non-volatile storage) on the ESP32.

Base Station
├── Fleet Master Key (derived from passphrase)
├── Pot 0x0001 Key
├── Pot 0x0002 Key
├── ...
└── Pot 0xNNNN Key
  1. Generate a fleet master passphrase (human-memorable, stored securely offline)
  2. Derive per-pot keys using HKDF-SHA256:
    pot_key = HKDF(master_key, salt="smartpot", info=pot_id_bytes)
  3. Flash pot key to the smart buoy’s NVS during initial programming
  4. Flash same key to the base station’s fleet key store

This means the master passphrase can regenerate any pot key — useful for base station replacement.

  • All packets carry a 4-byte truncated CMAC tag
  • The CMAC covers: Preamble + Pot ID + Command + Payload + Sequence
  • The receiver verifies the tag before processing any command

The current design uses authentication only, not encryption. Packet contents are sent in cleartext over LoRa.

Rationale: LoRa’s chirp spread spectrum modulation already provides physical-layer obscurity. The primary threat model is command injection (someone sending a rogue SURFACE command to steal a pot), not eavesdropping. Authentication prevents that.

Each packet includes a 2-byte monotonic sequence counter. The receiver tracks the last-seen sequence number per pot and rejects any packet with a sequence ≤ the last accepted value.

The sequence counter wraps at 65535. On wrap, a re-keying handshake is triggered automatically.

ThreatMitigation
Command injectionAES-CMAC authentication
Replay attackMonotonic sequence counter
Key extraction (physical access to pot)Per-pot keys — one compromised pot doesn’t affect fleet
Base station lossMaster passphrase regenerates all keys
JammingLoRa frequency hopping + operator alert on sustained comm loss