More modern control modules with a bit more resource available to them will use AES as the symmetric encryption (although there are also fixed-key XOR schemes and custom stuff used like this: https://github.com/bri3d/VW_Flash/blob/master/lib/decryptdsg... ).
The keys and even IV are usually fixed across a "model line" of ECUs, so once a decrypted flash memory can be extracted, this isn't much of a protection measure, but it's a lot better than XOR.
Then, in more modern control units, flash areas are also usually protected by both a checksum (usually some CRC permutation, although cute tweaks and random nonsense are common here too) and some form of digital signature.
bri3d refers to using RSA signatures on the firmware once it's written to the flash. By ensuring the firmware is signed using the manufacturers private key it should (in theory) prevent messing with the firmware, even if all encryption/flashing steps have been reverse engineered.
Some interesting reading: https://github.com/bri3d/VW_Flash/blob/master/docs/docs.md https://github.com/jglim/UnsignedFlash
I'm not a cryptographer - but I don't think there's anything wrong with XOR encryption, and I'm not sure why you're putting it in scare-quotes - XOR with a sufficiently large key is absolutely fine, and with a one-time pad is unbreakable. XOR with very large keys is how critical military encryption systems such as radios work.
When cryptographers and security professionals talk about XORing the keystream output of a pseudorandom function with plaintext to encrypt it, we don't call it "XOR encryption", we call it a stream cipher.
When we talk about XORing with a random pad of equal length to the plaintext, we don't call it "XOR encryption", we call it a one-time pad.
When we say "XOR encryption" we invariably mean "silly insecure thing with a repeating keystream no longer than a few bytes".
> XOR with a sufficiently large key is absolutely fine
It isn't. XOR with any key ever used more than once or looped around isn't not just "not unbreakable", it's demonstrably insecure. There is no "sufficiently large key" other than "same size as the plaintext and used only once for that plaintext" (a one time pad). To use smaller keys you need real cryptography, not XOR. Military radios absolutely do not work like this. They use stream ciphers, which can produce ~arbitrary length keystreams without repetition from a small seed key.
These ECUs aren't using one time pads with key lengths the same size as the firmware. I doubt they're using one time pads at all, which would necessitate each version of firmware using a different key.
Excuse me, how do you envision the use of one-time pads in the real world?
And with sufficiently large block keys - how do you deal with data full of zeros? Because XOR of 0 will give you the exact key you have encrypted the data with.
You are not a cryptographer, and indeed, I don’t think you’ve spent enough time thinking about it.
You load up as much one-time pad as you will have data to transmit - sometimes hundreds of MB of key if required. Storage is cheap.
Also you are surprisingly quite clueless about basic crypto if you think storage is the biggest issue with practically using one time pads (though it is indeed one). I’m pretty sure even the Wikipedia article can explain this so no reason to spoon feed it here.
If you only have a hundred MB of data to send… a hundred MB of key is sufficient to use as a one-time pad.
Until digitisation the military literally did encryption over radios using physical pads - everyone carried a big one-time-pad (just a few tens of KB though). It was done as a lookup table rather than an XOR though.
[0] I'm assuming we mean computerized here. Old school cipher machines of the type of the ENIGMA and M-209 were arguably digital machines, just base ~26.
No, pre common man-pack digital radios, so as recently as just prior to this century. They used paper one-time pads, with a big list of table indices for substitution. You still get them for use when you have no digital crypto for whatever reason.
They might have taught that use case to radio operator MOSs, but it wasn't actually deployed in the general case it seems.
I'm was literally trained in the British variant of technique I'm describing. There's a wikipedia article about it, and it's referenced from this cryptography wiki's one-time-pad page. Other countries used similar systems.
I'll give it that's it's definitely way better than DRYAD, which is pretty universally not considered a OTP because of the much greater key reuse (like how auth uses the same cipher tables as encrypt, leaking tables). So it boils down to the practical use case on whether it falls into OTP.
A new row per message means you don't re-use between messages (message is something like a sentence).
Each message should be short enough that you don't re-use (a 22-symbol message is already crazy), and you are not allowed to re-use if that means re-using a target symbol, but yes you might slightly re-use within messages if you're being sloppy.
In reality you don't get through the pad very quickly due to the 'compression' of a dictionary for typical parts of messages.
(This is all public info, not disclosing anything here.)
Is it that large keys are factors of very large prime numbers so that to know the keys you will need a very powerful computer?
But even correcting to what you must have meant to suggest doesn't make sense.
Cool! Do you have any references?
Do you mean the XOR encryption used? As someone working on the embedded linux(!= than embedded MCU) side i was very surprised to find such a crude "encryption" scheme employed. On the other hand i reckon there is only so much encryption an 8bit MCU can do. Also tolerance for complex encryption designs must be very low when you are trying to limit the scope of a life critical component.
The anti brute force measure was a bit more refined and almost got the job done.
Regardless, i agree. An great write-up. The binwalk and narrow down of possible CPUs used due to the ASIL-D constraint were really illuminating.