First off, almost all vehicles are running CANbuses right to the edge of their available bandwidth. Making the signature data fit is a vehicle-wide refactor unless you've designed for it from the beginning.
Secondly, many automotive MCUs don't have hardware crypto support or enough spare cycles for signing/verification. You have to design for that from the beginning.
Third, key distribution is hard. There are a lot of parties outside the OEM that need to flash firmware for various reasons during production. Do you give them all private keys or do you put up a public image signing service anyone can submit binaries to?
There's lots of other issues I could go on about like what the key rollover looks like, but I hope it's clear that retrofitting cryptography onto complicated systems that weren't designed for it is anything but straightforward.
Anyways I’m not in this industry but work on SPIFFE and see similarities- you could have a centralized CA in the car that does attestation to remote workloads.
With CAN, you're pretty firmly in the land of tradeoffs because the safety-critical stuff you want to auth is also hard realtime and solutions that involve expensive coprocessors like HSMs are usually off the table for a number of reasons like cost, lack of vendors supplying high-integrity solutions, inability to do board spins, etc. Adding authentication also has the nasty problem of sometimes reducing your safety because it makes the channel less noise resistant, as demonstrated by Dariz et al [1]. Navigating these sorts of tradeoffs are why some manufacturers have gone with half-measures like only authenticating a small subset of messages.
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.
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.
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.