Peer stabs you in the back

The message checked out

While building a flocking-drone node for coursework, I started looking at what it trusted. Each message carried a Cipher-based Message Authentication Code (CMAC), checked against a shared team key.

That check tells the receiver whether a message was authenticated with the key and whether it was altered. It doesn’t tell the receiver whether the reported position or velocity is true. My node accepted those values once authentication passed.

For the adversary part of the project, I considered a sender with access to that key. I wasn’t trying to break the cryptography; I was testing what an authenticated participant could get away with.

Three ghost neighbours

I targeted cohesion, the flocking rule that draws a drone towards the average position of its neighbours. The attacker reported three fake neighbours ahead of the victim, with velocities biased towards the simulation boundary.

In the coursework simulation, the victim moved 93 metres off course after 38 packets from three fake identities. There was no physical drone flight in this experiment.

What authentication left open

The node needed checks on the states it accepted as well as the sender. Position continuity, plausible movement and limits on how much one participant can influence the flock are places to investigate. They also cost time and computation in a real-time system.

The result changed the question I was asking. I’d checked whether a neighbour could prove it had the key. I also needed to decide how much influence to give it if its data was wrong.

The next thing I’d test is how gracefully the flock can continue when a peer becomes unreliable.