[BREAKING] Fix AES-CCM nonce reuse (direction bit) + exact-counter replay (MJ-12)

[balloob]

⚠️ BREAKING — coordinated protocol change. DO NOT MERGE standalone.

This fixes finding MJ-12 in src/encryption.cpp. It has two parts: one safe replay-guard fix, and one breaking change to the on-wire AES-CCM nonce.

Part A — safe replay-guard fix (non-breaking, internal state only)

verifyNonceReplay() skipped the replay-window scan whenever the incoming counter exactly equaled last_seen_counter — the && counter_diff != 0 guard on the window check. That let the most-recent command (and the counter-0 command) be replayed and re-executed, since an exact-counter match bypassed the "already seen" scan entirely.

Fix: remove the && counter_diff != 0 guard so an exact-counter match is scanned against the replay window like any other non-new-maximum counter. A legitimate packet always carries a strictly-increasing counter, so this rejects only replays.

One supporting change is required to keep it correct: the client's first command uses counter 0 (py-opendisplay _nonce_counter starts at 0 and increments after encrypting), and the replay window was zero-initialised. Scanning counter 0 against an all-zero window would false-match and reject the genuine first command. So the replay window is now initialised to a 0xFF sentinel ("no counter recorded") instead of 0, which is a real counter value. This is internal RAM state only — no wire/format change.

Part B — nonce direction bit (⚠️ BREAKING wire crypto change)

The 16-byte full nonce was session_id(8) || counter(8, big-endian) for both directions. Both the inbound command counter and the outbound response counter reset to 0 at authentication, so command #0 and response #0 encrypt under an identical (key, nonce) pair. AES-CCM nonce reuse under the same key is fatal: it leaks the keystream (XOR of the two plaintexts) and enables tag forgery.

Fix: reserve the most-significant bit of the counter field — bit 0x80 of nonce[8], which sits inside the CCM nonce slice nonce_full[3:16] — as a direction flag:

• inbound commands (client → server): bit MUST be clear; an inbound command with the bit set is now rejected.
• outbound responses (server → client): bit is SET.

This guarantees the two directions can never collide on a nonce. The counter never grows large enough to reach this bit in practice.

This changes the on-wire crypto. Updated firmware will not interoperate with an un-updated client, and vice-versa.

Rollout / lockstep required

Part B must land together with matching nonce-construction changes in all peers, or encrypted comms break for un-updated devices/clients:

• py-opendisplay — src/opendisplay/crypto.py (get_nonce() / encrypt_command() / decrypt_response()): as the client it must keep the direction bit clear on the command nonces it sends, and set/expect it set on the response nonces it decrypts.
• Firmware_NRF — encryption.c (nonce construction + inbound direction-bit check).
• Firmware_Silabs — equivalent nonce construction + inbound check.

None of those repos are touched by this PR.

Suggestion: Part A (the replay-guard fix + sentinel init) is fully backward-compatible and could be split into its own non-breaking PR if the team wants the replay fix shipped ahead of the coordinated Part B rollout.

Testing

Firmware builds clean with the changes:

• pio run -e nrf52840custom → SUCCESS (encryption.cpp recompiled + linked)
• pio run -e esp32-c3-N4 → SUCCESS (encryption.cpp recompiled + linked)

No on-device / interop testing performed; Part B interop requires the coordinated peer changes above.

🤖 Generated with Claude Code

https://claude.ai/code/session_012g2e8mr132vcizx92WsgiR