[masfuerte]

I don't want the cockpit to lose contact with the engines during a flight because a certificate just expired. And even if this particular example isn't realistic, adding security to a system will necessarily add lots of new failure modes. It seems likely that it will be really hard to do this without making the system as a whole less reliable.

[GTP]

I know yoh mean this in a general sense, but I just whish to point out for everyone that in this scenario you don't actually need certificates: a MAC to prove authenticity is enough.

[baby_souffle]

>a MAC to prove authenticity is enough.

This would work in most cases, yes.

I think the point that 'masfuerte' was making is that simplicity and redundancy are _the_ bedrock of reliability.

Even if all the new hardware and software to implement this new security model on avionics busses is 100% open and audited by every laudable computer science / security specialist, it's just _more_ to possibly go wrong. That tends to change how people think about risk (weather rationally or not!)

[numpad0]

End result is the same: expired certificate getting rejected.

[GTP]

No, with a MAC function you don't have certificates in the first place ;)

[theamk]

Not really, you still need some system to distribute the shared key.

The paper's method suppresses original message then generates btand-new one, so if the key is easy to find out, then the spoofed message will have a correct MAC. Which means you need a cryptographically secure method to distribute the key, but you also have multiple consumers and you want to be able to replace broken devices too. This sounds like a non-trivial cryptosystem, and assymetric crypto + certificates is one possible solution.

[GTP]

Key distribution can be done manually at the factory where the plane is built. Which can also keep a keystore holding the key used for each plane. But we don't need to delve deep in this scenario, as ultimately op's point was that, by introducing crypto, you risk adding failure modes to the plane.