Use constant-time comparison for MAC verification

[weebl2000]

Severity: low

Summary

The HMAC verification in MACThenDecrypt uses standard memcmp(), which short-circuits on the first mismatched byte. The time taken to return reveals how many leading bytes of the MAC were correct, leaking information through a timing side-channel.

How this can be exploited

MeshCore uses a 2-byte MAC (65,536 possible values). With a timing-variable comparison, an attacker can break the MAC verification into two sequential brute-forces:

1. First byte — send 256 packets, each with a different first MAC byte and an arbitrary second byte. The packet where memcmp takes slightly longer to reject reveals the correct first byte (because it proceeded to compare the second byte before failing).
2. Second byte — with the first byte known, send up to 256 more packets varying the second byte. The one that triggers decryption (noticeably slower due to AES work) reveals the correct second byte.

Total: ~384 attempts on average instead of ~32,768 for blind brute-force.

On local interfaces (BLE, WiFi, serial) the timing difference between a 1-byte and 2-byte comparison is measurable with sub-millisecond precision. Over RF the timing window is harder to exploit directly, but a BLE-connected attacker (e.g. a compromised phone app, or someone within Bluetooth range of a companion radio) could:

• Forge messages from any known contact — craft packets that pass MAC verification without knowing the shared secret, then inject arbitrary text messages, commands, or requests that appear to come from a trusted peer
• Forge admin commands — if the attacker can target a repeater or room server's BLE interface, they can forge REQ packets to execute privileged operations (config changes, ACL modifications)
• Replay with modification — combine with the ECB encryption mode to splice known ciphertext blocks into forged packets with valid MACs

Fix

Replace memcmp with a constant-time XOR-accumulate loop. The comparison now always examines every byte regardless of where the first mismatch occurs, eliminating the timing signal.

Test plan

• Normal encrypted message exchange still works (send/receive between peers)
• Invalid MACs still rejected (packets with wrong shared secret don't decrypt)
• Build tested on Heltec_v3_companion_radio_ble

---

Build firmware: Build from this branch

[liamcottle]

The time taken to return reveals how many leading bytes of the MAC were correct, leaking information through a timing side-channel.

What time taken to return are you referring to? As far as I know, none of the firmwares reply to anything over LoRa if the encryption/decryption fails? So there's no response to measure the time of?

Or am I missing something?

[weebl2000]

The time taken to return reveals how many leading bytes of the MAC were correct, leaking information through a timing side-channel.

What time taken to return are you referring to? As far as I know, none of the firmwares reply to anything over LoRa if the encryption/decryption fails? So there's no response to measure the time of?

Or am I missing something?

You're right. Exploiting this is really hard in practice (near to impossible). Still good to have it in I guess.