Shoot at our cybersecurity proposal

Hi folks,

I've been tasked to improve our cybersecurity setup at work for our new generation of devices. Like all of our "favorite" mandates - I've been given little guidance and few requirements. Our customers "want cybersecurity" but they have yet to be able to articulate what that means to them. I performed an audit of our current setup and decided on a course I believe is reasonable regardless of if we have a concrete requirement eventually come down or not. I'd like some people with more experience than we have to shoot at the idea.

Some vague context (I don't have permission to discuss this with details). We're an automotive tier 2 supplier. The device I'm working on sits in the engine compartment and only communicates over CAN-FD. They have the capability to have the application upgraded in the field but that isn't a typical scenario. Over the last 20 years we have sold about a million of our previous devices - so cost is an issue. The powers that be have yet to select a microcontroller, but it's likely that if a cheaper option is available that they'll choose it over one with strong cybersecurity features outside of a customer mandate.

Onto the meat:

We've decided to sign our applications with Ed25519 signatures and verify them on download and boot. The key(s) will live in protected bootloader memory or specialized key storage that we've been assured form our 3 primary microcontroller candidates can't be read. As part of the application head we'll include an algorithm ID and a key ID (among other fields) that the bootloader will use. The idea being that we can perform key revocation in a new run of devices should it become necessary. The private key will be burned into a hardware token yet to be selected and is intended never to leave our development facility. We selected Ed25519 due to its speed in software (in case we can't get hardware support) and the availability of libraries like libsodium and monocypher.

Authentication to download will be over UDS 0x27. We're not terribly concerned over the shared key nature as our images are signed and should be tamper proof. The only other thing UDS 0x27 will do is allow someone to read some customer specific data. Manufacturer routines will be protected behind UDS 0x29 with yet to be decided parameters.

For UDS 0x27:

Only one of our candidate processors has a TRNG so we need some way to gather quick entropy for the seed generation portion of the 0x27 flow. Here is the rough algorithm I'm using on my bench setup.

1. Generate 128 bytes of low-quality entropy through reading the lsb of a floating ADC pin and concatenating that with the lsb of the bandgap. This gives us about 0.7 bits of usable entropy per bit but, as expected, fails most practrand and dieharder tests. Attempting to debias these bits through a von Neumann debiaser ends up even worse.

2. Use sha512 hdkf to condition those bits into 32 bytes of high quality entropy to use for the UDS 0x27 seed. This is >0.9 bits of usable entropy per bit and passes all practrand and most dieharder tests. I suspect that if I had 250GB instead of 250MB of random bits it would pass all of them, but generating at 7KB/s makes that a task for an intern I hate. I don't have any interns I currently hate, but am taking applications in the form of fawning flattery.

3. We feed that into SHA 512 HMAC for the rest of the UDS 0x27 exchange. The key for this is 32 bytes also stored in protected memory but, as I stated, we're not currently concerned with this being leaked. We'll have to provide the customer some tools with the key embedded in so we're treating it as compromised (or at least suspect) from the start.

We do some standard timeouts / lockouts. Tool identification happens in additional bytes in the 0x27 0x01 message and is recorded. We're not overly concerned about replay attacks given 32 bytes of what appears to be very high quality seed and the nature of what they can access even if *they* do pull off an attack.

Thoughts? Concerns? Praise? Did I do a dumb anywhere that I overlooked? Thanks a bunch!