4 ms·
This seems one of those pure-academic papers which have no practical applications whatsoever. First of all we have MIL-STD-1553, which is a broadcast bus. Thos
by theamk 4y ago
This seems one of those pure-academic papers which have no practical applications whatsoever.
First of all we have MIL-STD-1553, which is a broadcast bus. Those are inherently unprotected, as any device can jam the bus at any moment. OK, the attacker wants to override the device output instead. But this immediately suggests most efficient fix for any takeover process: switch to some other technology which is not broadcast. This will fix takeover problem, and jamming problem, and sniffing problem and many other problems.
Next, the mitigation they propose is "Occasionally, one device would slip in a coded message that would change both devices' network addresses". I don't think this works well.. after all, the messages themselves are not encrypted. So an attacker can just look at the message content to determine address to spoof. It is pretty easy to tell "throttle stick position" message from "engine status" one, especially given you know the prior history. One message immediately after address change might be unmodified, but that's OK, the next ones would be spoofed. Idea: as long as you are changing firmware in incompatible ways, maybe just add encryption? This is well understood and works well to protect against spoofing (and many other things too).
Finally, they assume attacker is guessing the number sequence using machine learning model, and that random number generation is done using predictable methods (I bet something like LFSR or LCG) What is their threat model exactly? Machine learning is pretty resource-intensive. If the attacker knows it will be LFSR or LCG, they can use predictors tuned to that specific algorithm, which will be substantially more efficient. And if this is any of many known cryptographically strong RNGs, then attacker might as well give up immediately. Either way, no need for machine learning.