Hacker News Reader

Comment by ptsneves | Hacker News Reader

> 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

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.

View on HN

No, this EPS control module is remarkably primitive even by late 2000s standards and several generations behind today's state of the art.

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.

The XOR encryption was just for the update container. Newer update files usually employ some stronger forms of compression/encryption. However, it's usually some strange in-house crypto, so eventually people figure it out.

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

> 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.

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.

I'm assuming they meant XOR-ECB with a block size of 1/2/4 bytes.

> XOR with very large keys is how critical military encryption systems such as radios work.

Cool! Do you have any references?

For example the TETRA standard for trunked radio, "The key stream bits shall be modules 2 added (XORed) with plain text bits in data, speech and control channels".

In the TETRA specification they use the term “key stream” to mean the output of a stream cipher, which they call a “key stream generator”. They aren’t XORing directly with a large key - the TETRA key size is 80 bits. See section 6.3.2.2 of https://www.etsi.org/deliver/etsi_en/300300_300399/30039207/...

Yes you can programatically generate a key.

And we call that a stream cipher, not "XOR encryption", even though it uses a XOR operation. You're programmatically generating a keystream, which is not the same thing as a key.

See, this is why we can't have secure things.

> XOR with very large keys is how critical military encryption systems such as radios work.

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?

XOR with a one-time pad doesn't work off factors of large numbers - you're thinking of asymmetric encryption there. You literally just XOR each plain text byte with a key byte.

Thanks! I don't know much about cryptography and will check this out.

There are only two factors of any prime number, large or otherwise: 1 and the number.

But even correcting to what you must have meant to suggest doesn't make sense.

Sorry I meant something else, can't wrap my head around to recall the name...

The article's XOR key was 0xFF :) Definitely out of the sufficiently large key range.

I think they mean using XOR with a repeated fixed tiny key _as_ the stream cipher, rather than just using XOR to mix the keystream and the plaintext.

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.

> XOR with a sufficiently large key is absolutely fine, and with a one-time pad is unbreakable

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.

> Excuse me, how do you envision the use of one-time pads in the real world?

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.

Hundreds of Megabytes? That’s a big number to you? Did you step out of a time warp from 1990?

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.

> Hundreds of Megabytes? That’s a big number to you?

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.

The pad system used by the military predigitisation[0] was a set of keys to input into a keystream generator rather than a strict one time pad style system, except for very specific and limited espionage use cases. And it wouldn't be one time, it'd be on the order of a daily key rotation with key reuse (with maybe a few chosen per day depending on classification level).

[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.

> I'm assuming we mean computerized here

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.

That's not quite what I'm seeing, instead that what I believe you're talking about (Morse code over open air with a Diana cipher backed by one time pads) were pretty much exclusively used by special forces in Vietnam. The issues with key distribution inherent in one time pads otherwise got in the way of cross team cooperation too much since each pad would only exist in two places (the spec ops team, and a major base close by, but not a FOB in case it was overrun).

They might have taught that use case to radio operator MOSs, but it wasn't actually deployed in the general case it seems.

> That's not quite what I'm seeing ... it wasn't actually deployed in the general case

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.

https://en.wikipedia.org/wiki/BATCO

https://cryptography.fandom.com/wiki/One-time_pad

So if I'm understanding BATCO correctly, there's an average key reuse by a single sender after 13 messages because of the how the traffic key rotation selects a row? That, combined with the sense I'm getting that the cipher sheets were distributed widely (auth tables imply multiple senders using the same cipher sheet at the same time) seems to imply broad reuse of key rows, making it a pad, but not a one time pad. Do my assumptions filing in the blanks line up?

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.

Yes entire radio net is moving through the shared pad together - so you when you send you consume a bit of the pad, and when someone sends to you they use the next bit of the pad, then you use the next, etc.

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.)

> I'm not a cryptographer - but I don't think there's anything wrong with XOR encryption

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.

Reply on news.ycombinator.com