> Ensure the patches to the calibration values are safe before using.
How would you do that? I've worked on both ends of steering on VW Bugs and Golfs (steering column fixes and tie rod replacements). You don't want to mess either of these up either, but the repairs are (a) well documented and (b) relatively easy to verify you did them correctly.
By contrast, I've seen software break catastrophically in the past from "harmless" updates like changing the number of commas in a version string. In this case it's not the kinda doesn't work problem but hitting an unexpected corner case on the freeway that would worry me.
I'm not a big advocate for comma/OpenPilot or EPS patching stuff in general, but I thought the patch in this example was fairly benign and reasonable as these things go - it was a data patch to the calibration area rather than a code patch, and the altered calibration contained relatively straightforward values with clear references and obvious effects.
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.
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?
Ah, yeah, and this is irritating if you're a used car owner, particularly an owner of a car that's now lower value. I can't, for example, pick up a cheap used throttle body for my older Volvo because the main ECU will reject it until someone from the stealership charges me a LOT of money to "program" it.
Although, unfortunately this too is changing, starting in the 2021 model year VW AG have introduced a rather evil technology called SFD which requires server-signed tokens to perform these kinds of basic adaptations. This is all being done in the name of anti-theft security.
We really need better right-to-repair rules for vehicles.
The running "joke" is that insurers pay to put your original stuff back into car, as insurers somehow find "used" parts for mechanics.
Edit: Especially airbags, they require special certifications to be installed and managed in Sweden, second hand airbags is NOT a thing here. Though other parts very well might be.
There isn't any greater authority, keeping track of every car part or ensuring the number of wingmirrors leaving stock matches the number legitimately entering stock.
I'm not saying it can't happen every now and then, but it wouldn't work systematically.
Just as Apple can’t prevent abusive people from having the desire to track, stalk, and creep on their own family members, I don’t think you have a practical outlook or plan here.
The manufacturers do what they can, and they deserve all our respect for that, not derision.
It’s not inequality when instead of a cheap hatchback you NEED to buy BMW 5-Series or Porsche Macan. But you import a damaged one from US. And then you need a bunch of „used“ parts to repair it.
Unfortunately it’s hard to check every boot for stolen headlights and steering wheels without border control
"Involving checks at border crossing points and in-land activities in 16 EU countries and five countries in the Balkan region"
More modern VW control units are the same in broad strokes - they use UDS on ISO-TP instead of KWP on TP2.0, but this is just evolution of the same fundamentals. And instead of the wacky SGO format inside of FRF update files, they use the ASAM MCD-2 D-ODX format to define flashing layers. Most European automakers are similar.
One interesting difference and trend in automotive control modules (also mentioned in Willem's fantastic write-up) is that many EU modules started adding signature checking and encrypted updates in the late 2000s, while most US and Japanese automakers have only done so in the last 2-3 years.
These encrypted and signature checked updates are by and large still fairly vulnerable - often due to logic errors in the complex upgrade processes and occasionally due to a strange insistence on using RSA using PKCS#1.5 with e=3 and inadequate padding validation.