3 ms·
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 c
by cryptonector 4y ago
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.
- quake 4y agoASIL-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.
- cryptonector 4y ago> 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. That's possible, but I doubt it.