Sensors whose outputs are used to do cruise control and lane keeping assistance and so on should also be encrypted.
I don't believe anything in this space is cost-prohibitive in the long term, or even in the medium term. It's just dev cost amortization, because the chips are cheap once they tape out.
ASIL-critical inputs/outputs should not be encrypted,full end stop. Do I really trust that the dinky economy-scale micro that GM would pick is always going to hold up that encryption when I'm starting to drift off road? Absolutely the hell not.
I worked in this space (auto RE, including keyless entry) for a while, and there's almost no way this would work at scale without a top-down platform redo for automakers.
> Do I really trust that the dinky economy-scale micro that GM would pick is always going to hold up that encryption when I'm starting to drift off road?
Is your concern that the key management can leave a mess of key disagreement? But that's like the sensors failing altogether, and that already has to be taken into account.
So yes, I would trust "that the dinky economy-scale micro that GM would pick is always going to hold up that encryption when I'm starting to drift off road" because I have to trust that the computers will handle sensor failure correctly.
That said I'd only trust that if the crypto is sensible. Specifically authenticated encryption is essential. Key exchange, pairing -- those are important too. It needn't be complicated to set up: trust-on-first-use-after-reset (with reset being not trivial to execute) should suffice.
> [...] there's almost no way this would work at scale without a top-down platform redo for automakers.
I don't believe anything in this space is cost-prohibitive in the long term, or even in the medium term. It's just dev cost amortization, because the chips are cheap once they tape out.