Key Management on the STM32 Flight Controller

The following security features are available on the STM32 F7 series, documented in ST's application note AN5156, Introduction to Security for STM32 MCUs (STMicroelectronics, 2021).

Assumed attacker capabilities:

• Physical capture of a drone and attempt to extract key material from hardware.
• Debug interface connection to read flash or SRAM contents.
• MAVLink parser exploitation to achieve code execution on the flight controller.
• Interception and replay of MAVLink messages over the radio link.

Goal: A system in which no single drone compromise cascades into swarm-wide failure.

Each STM32 flight controller stores two key values:

The initial provisioning flow establishes session_key_0 on a drone using its device_key and a one-time nonce.

1. GS derives session_key_0: device_key = HMAC-SHA256(master_secret, UID), then session_key_0 = HMAC-SHA256(key=device_key, data=nonce).

2. GS sends encrypted payload to drone: Encrypt(device_key, session_key_0) with nonce sent in plaintext.

3. Drone decrypts and stores: decrypts using device_key from RDP Level 2 flash. session_key_0 is stored in TAMP backup SRAM.

4. Drone sends ACK signed with session_key_0: ACK(sig=HMAC-SHA256(session_key_0, ack_payload)).

5. GS verifies ACK: GS verifies HMAC using its own session_key_0 copy and confirms storage.

Session keys are rotated regularly. The derivation routine is placed in a PCROP-protected flash sector, execute-only and unreadable even by the firmware itself. This matters because the derivation incorporates additional secret values alongside the publicly transmitted nonce R. An attacker who intercepts R sees the public input but has no visibility into what happens inside the sector.

1. GS generates nonce R and sends a signed message: MAVLink(R, sig=HMAC-SHA256(session_key_n, R)).

2. Drone verifies signature: HMAC-SHA256(session_key_current, R) is checked; message is rejected if invalid.

3. Drone derives new key locally in PCROP sector: session_key_n+1 = HMAC-SHA256(key=session_key_n, data=R).

4. Drone sends ACK signed with new session key: ACK(sig=HMAC-SHA256(session_key_n+1, ack_payload)).

5. GCS verifies ACK before switching: GCS derives the same session_key_n+1, verifies the ACK, and only then discards the old key.

The rotation protocol provides forward secrecy: compromise of any session key reveals nothing about past keys since each key is derived using a one-way function from the previous one. No key material is ever transmitted. Per-drone key isolation ensures all drones receive the same nonce R but derive completely different keys since each chain starts from a unique device_key. The ACK-before-switch rule keeps the ground station and drone always synchronized.

Accepted limitation: forward secrecy protects past keys but not future ones. If the current session key is compromised and the attacker intercepts the next nonce R, the next session key can be derived. This is mitigated by frequent rotation, the majority vote liveness system which triggers revocation before extended exposure occurs, and the key derivation algorithm placed in a PCROP-protected sector, allowing additional static private secrets to be incorporated beyond just the previous key and R, making the next key non-trivially guessable even under partial compromise.

Each design choice carries an accepted trade-off.

Other than the proposed initial session key generation and rotation, additional mechanisms such as liveness and revocation should be considered, which require separate handling. Since we are dealing with a swarm system, drones periodically report peer connectivity and behavioral consistency to the ground station. Any revocation decision requires majority vote across the swarm rather than a single drone report.

For suspected drones, soft revocation excludes them from the next key rotation until the situation is cleared. In more extreme cases where a drone is confirmed malicious or physically compromised, it is permanently excluded.