5 ms·

> One interesting difference and trend in automotive control modules (also mentioned in Willem's fantastic write-up) is that many EU modules started adding sign

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

pd0wm 5y ago
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/bri3d/VW_Flash/blob/master/docs/docs.md https://github.com/jglim/UnsignedFlash https://github.com/jglim/UnsignedFlash
chrisseaton 5y ago
> 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.
- formerly_proven 5y ago
  I'm assuming they meant XOR-ECB with a block size of 1/2/4 bytes.
- j4hdufd8 5y ago
  > XOR with very large keys is how critical military encryption systems such as radios work. Cool! Do you have any references?
  - chrisseaton 5y ago
    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".
    - fanf2 5y ago
      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/02.01.01_60/en_30039207v020101p.pdf https://www.etsi.org/deliver/etsi_en/300300_300399/30039207/...
      - chrisseaton 5y ago
        Yes you can programatically generate a key.
        marcan_42 5y ago
        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.
        ncmncm 5y ago
bri3d 5y ago
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.py 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.

pd0wm 5y ago

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/bri3d/VW_Flash/blob/master/docs/docs.md https://github.com/jglim/UnsignedFlash https://github.com/jglim/UnsignedFlash

chrisseaton 5y ago

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

formerly_proven 5y ago
I'm assuming they meant XOR-ECB with a block size of 1/2/4 bytes.
j4hdufd8 5y ago
> XOR with very large keys is how critical military encryption systems such as radios work. Cool! Do you have any references?
- chrisseaton 5y ago
  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".
  - fanf2 5y ago
    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/02.01.01_60/en_30039207v020101p.pdf https://www.etsi.org/deliver/etsi_en/300300_300399/30039207/...
    - chrisseaton 5y ago
      Yes you can programatically generate a key.
      - marcan_42 5y ago
        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.
        ncmncm 5y ago

bri3d 5y ago

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