While I agree with this instinct: this sounds like a simple "just use PKI" solution but it's really not simple at all. How do the vehicles' or devices' cert keys get provisioned and protected? Are they unique per device, per vehicle, or per manufacturer? Per device or per vehicle increases manufacturing process overhead (read: price) immensely [edit: as well as overhead at service departments]. Every device that can sign messages needs access to perform private key operations, which necessarily either increases cost (eg by storing the keys in a device-local HSM or adding network-based key operations along with the corresponding one-turtle-down auth problems) or decreases security of those private keys. What happens when they inevitably get extracted and baked into spoofing tools? Can the manufacturer rotate the root keys? What happens to vehicles that are offline when that happens?

I thought it was covered in the article but all the devices on the bus would need secret keys that were unique across all devices manufactured. This isn't impossible though since we've been making unique MAC addresses on NICs for many decades, and motherboards often come these days with the actual serial number of the server flashed into the DMI information, etc. It will also take an electron microscope to read the keys out of the chips, which is not a very mobile attack to use against a parked car on the street.

First, those unique MACs and serial numbers are not currently in storage that requires an electron microsocope to read, so that's a pretty big additional cost burden. Second, assuming all devices were to be given secure key storage parts, you also have the cost burden of the pairing process during manufacturing and maintenance, as I mentioned above (not to mention the design and development of that pairing database and its failure/diag/maintenance/factory-reset modes). It's far from trivial.

If you don't provide a convenient interface to read a MAC address then you're going to need an electron microscope to pull it off a NIC chip as well. They just always provide the convenient interface to get at it.

No, you don't need an electron microscope to overcome that type of inconvenience, because those pieces of data are not sensitive and no effort has been made to ensure you can't just read them out using the pins. This is why the problem of storing private keys is so different than the problem of storing a MAC address. Or put another way: inconvenience is not security, and what we're talking about is a security problem.

I think to be feasible from a maintenance and consumer-friendliness standpoint, each vehicle should have its own local CA and have some sort of open standard for how individual devices can have certificates provisioned so that they can be installed on a car. A replacement-part-pairing function that can only be performed by having physical access to a specific secured component (e.g. not just bus access) should work without contacting the manufacturer. I'm in for this startup idea. :D

Toyota had already introduced message signing for lane-keep inputs, just not for theft protection(?)

Ref: https://github.com/commaai/openpilot/discussions/19932

The list of ECUs for the Rav4 Prime was looked up in Toyota TechInfo, but not for future cars that also have that system.

As someone who has (successfully) implemented this at multiple manufacturers, it is absolutely not as easy as "just signing it".

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.

I’m sure there are a lot of complexities, I think the general shape of the solution is the same. Another poster (perhaps you?) mentioned that luxury cars do sign CAN packets.

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.

That can be a solution, but I usually push to simply scrap CAN everywhere possible and move to IP networking as mentioned by others in a sibling thread. That requires a ground-up system redesign, but it has a lot of benefits like not requiring a bunch of automotive programmers to implement a custom crypto architecture on constrained systems in C.

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.

[1] https://doi.org/10.1109/MTITS.2017.8005670