How does UART bootloader program flash application data into Flash/ROM memory

[nctnico]

Not sure about useless, but the same plaintext block produces the same ciphertext block, so you can pretty much tell the size of the image, but with AES there is no known attack even if not using CBC.

You think there is no known attack... I've been digging a bit deeper a while ago and there are some concepts floating around about doing so called plaintext attacks to AES. Using CBC adds an extra unknown to the equation.

[peter-h]

There is no published attack for the full-round AES.

Also with CBC the first block still looks the same, and since there is likely to be the jump table there, you have a bit of plausible known plaintext to work on.

One could add some "salt" into it to make it harder but I really think that in the context of boot loaders, firmware OTA, etc, and that EU regulation (actual or the intent) this is way off reality.

It will be easier to break the RDP security. I reckon it is breakable on nearly all MCUs already, and anyway there are firms which will decapsulate the package and read out the FLASH directly. But again the EU reg cannot be aimed at this because every "industrial grade" chip is vulnerable. Only specialised smartcard type chips have any hope.

[Siwastaja]

There is no known attack for AES because detecting similarity of repeated messages and figuring out what they mean is not considered a cipher weakness, even if it means revealing the plaintext and as such it's still a very real shortcoming. This is exactly why counter mode or CBC have been invented - simply put, the message is modified before encryption so that similar repeated messages appear different every time. Same concept applies to any cipher with any amount of strength. So AES is good, but AES alone doesn't mean secure transport of the messages.

I don't know how relevant this is for firmware signing or firmware leakage protection. Some wiser than me could tell.

[NorthGuy]

You think there is no known attack... I've been digging a bit deeper a while ago and there are some concepts floating around about doing so called plaintext attacks to AES. Using CBC adds an extra unknown to the equation.

Every little thing you do increases the attack surface. CBC, for example, may open up a way for oracle attacks. Xilinx 7-series bitstream AES encryption has been broken that way - because they used CBC in a wrong way:

https://www.usenix.org/system/files/sec20fall_ender_prepub.pdf

[Siwastaja]

You think there is no known attack... I've been digging a bit deeper a while ago and there are some concepts floating around about doing so called plaintext attacks to AES. Using CBC adds an extra unknown to the equation.

Every little thing you do increases the attack surface. CBC, for example, may open up a way for oracle attacks. Xilinx 7-series bitstream AES encryption has been broken that way - because they used CBC in a wrong way:

https://www.usenix.org/system/files/sec20fall_ender_prepub.pdf

To be fair, if I read that correctly, the failed CBC means a failed CBC, no more - having no CBC wouldn't have been any better, but even worse (easier attack). So it's not like adding a necessary feature added any surface area for attacks, just that there was a hole in it, so it didn't protect what it was designed to protect.

But it does demonstrate that security is hard, as we all know.

[peter-h]

Security is hard to do right but also any scheme to prevent malicious firmware loading will fail if the RDP security of the CPU can be broken. Which pretty much means that the vast majority of CPU/MCU chips in common use are useless.

Unless the EU reg discussed just requires "due diligence" and carries no strict liability on the mfg if a 3rd party breaks RDP.

Since this is well off topic for the OP's question, I started a thread here:
https://www.eevblog.com/forum/microcontrollers/eu-cyber-regulation-and-secure-firmware-updates-mandatory/

[nctnico]

There is no published attack for the full-round AES.

Also with CBC the first block still looks the same, and since there is likely to be the jump table there, you have a bit of plausible known plaintext to work on.

No. Because with CBC the first block is random garbage. And this random garbage is then used to obscure the first block of the payload and this ripples through all the way to the end. If you encrypt a file with all zeros usin plain AES, you'll get a repeating pattern every 16 bytes. With AESCBC you get an extra 16 random bytes at the start and the rest are non-repeating 16 bytes blocks. In theory AES is designed so you can't extract the key if you know the original data. But every theory lasts until proven otherwise... Quantum computing and/or AI may help come up with something clever. Where CBC gets it's strength from is that the encrypted data is obscured by random data. So even if you know the original data, you don't know the random data. To know the random data, you need the key. This creates a much harder to crack chicken & egg problem compared to reverting encrypted known data into a key.

[NorthGuy]

You think there is no known attack... I've been digging a bit deeper a while ago and there are some concepts floating around about doing so called plaintext attacks to AES. Using CBC adds an extra unknown to the equation.

Every little thing you do increases the attack surface. CBC, for example, may open up a way for oracle attacks. Xilinx 7-series bitstream AES encryption has been broken that way - because they used CBC in a wrong way:

https://www.usenix.org/system/files/sec20fall_ender_prepub.pdf

To be fair, if I read that correctly, the failed CBC means a failed CBC, no more - having no CBC wouldn't have been any better, but even worse (easier attack). So it's not like adding a necessary feature added any surface area for attacks, just that there was a hole in it, so it didn't protect what it was designed to protect.

But it does demonstrate that security is hard, as we all know.

In this particular case, the attack wouldn't be possible if Xilinx didn't use CBC.

Of course, it is also possible that other circumstances may exist where there would be a successful attack on non-CBC AES. It is also entirely possible that such an attack may have been prevented with using CBC.

Security is about identifying possible attacks and making them impossible, not about using prescribed allegedly "secured" methods.