[clipclopflop]

HW wise, the older units were intel atom based cpu (latest gen is amd I believe?) - the hardware is typical embedded stuff - cpu + eMMC + bt/wifi mcu + cellular daughter card. OS is linux + QT UI stuff. I would expect things have changed for newer HW revisions, but the previous gen did not utilize encryption (dmcrypt) so all data was unprotected at rest.

[clipclopflop]

Following up on this - the actual 'self driving' part of the HW stack is an entirely separate board with 2x custom ARM chips on it. The HW/SW is much more locked down and the OS/Data is not accessible. I believe a lot of the self-driving info gleaned by types like green were built up from the first generation of Model S cars where the 'self driving' HW was much less defensible and it was much easier to gain access to it.

[pas]

what does locked down mean here? this is almost the same situation that happened with DRM stuff like HDCP and the BluRay (?) encryption key (that was then posted all over the net), right?

at best the decryption key is somehow custom to each car, not reproducible (eg. it's made by some random manufacturing process), and then Tesla reads this and encrypts everything in a way so that only that key can open it.

but then do they keep every bit of decrypted data "on die"? (or they encrypt RAM too?)

[clipclopflop]

Locked down meaning the storage devices are encrypted and decrypted on-the-fly via the SoC/CPU using a key programmed into the Fuses/OTP (this is usually per device keys), bootrom/loader requiring signed firmware images, limited exposure of external interfaces (attack surface) - from my memory even the Uart interface attached to the SoC was disabled very early on in the boot loader, exposing only one or two messages. I would not expect that ram is encrypted - I cannot think of a single time I have seen that implemented in a device. Maybe it’s time to dig that board out of storage and poke at it a bit more invasively, my understanding is they are not very robust when faced with fault injection :>

[bdamm]

It is now sort of common for embedded chips to generate on-die encryption keys for external processes (flash) and there could even be a one-time encryption key for the ROM (pushed to the on-die ROM and then wiped from manufacturing). Encryption RAM is basically free because the chip can generate a key internally at each boot. There can even be deeper lock-downs although obviously the deeper you go the less common it is. Getting to the on-die key can be pretty much impossible unless you can find some bootloader attacks, and then you're very much into dangerous territory. In some cases even looking for a bootloader attack can be paramount to disruption of international arms treaties, legally.

I'd expect them to also have fleet keys for stuff like navigation data. And of course, public-key based firmware signing. That's just table stakes these days.

[pas]

so it seems that secure computing has arrived. (yay!) unfortunately we don't have the keys. (welp.)

now the next step is to fund FairPhone (and/or other open phones) to keep it alive, and hope the networks will allow open phones to participate.