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.

[cv007]

Both my and gspeed's solutions are provably brick safe

I guess this assumes the latest firmware update contains a flawless app, and although the bootloader is choosing the latest valid version like is should, if that firmware for example had a flaw which prevented loading the next firmware update then you are stuck running that version and there is now no way to update firmware.

If I understand this update process correctly.

I would probably not consider something brick safe if I could write the app in a way which would prevent further updates. If you can intentionally write the app in such a way to cause a problem, you can do so unintentionally also. Giving the bootloader the ability to also do firmware updates if needed would at least allow for a way to recover from this type of problem.

[peter-h]

I would argue that it should be possible to replace the entire firmware including the boot block, but the distributed firmware should not touch the boot block.

That way you protect the large business risk, while also protecting the hopefully much smaller (but much more expensive if triggered) business risk of having a crippled boot block.

It's mainly about risk management, not "technology". For example you may choose to not offer upgrades to a large customer, because a mistake could sink your business. The place to roll out updates, at least initially, is to a small customer in the Peoples' Republic of Upper Volta

[NorthGuy]

For example you may choose to not offer upgrades to a large customer, because a mistake could sink your business. The place to roll out updates, at least initially, is to a small customer in the Peoples' Republic of Upper Volta

Or you may decide not to offer upgrades at all, which in itself offers lots of benefits.

[Siwastaja]

Both my and gspeed's solutions are provably brick safe

I guess this assumes the latest firmware update contains a flawless app, and although the bootloader is choosing the latest valid version like is should, if that firmware for example had a flaw which prevented loading the next firmware update then you are stuck running that version and there is now no way to update firmware.

You are right, I was fixated on the safety of the update process itself, e.g. against power loss at any timing, corruption while writing. That is easy to prove. Old app always stays bootable, but if new app also becomes bootable and prevents entering the update process, the the device is effectively bricked, even if it technically runs a valid application.

To protect from this, some sort of "boot the old app" signal to the bootloader helps, but doesn't guarantee anything - a more subtle flaw that allows one update more to succeed would wipe the old, working app. So would a new update operation which starts (erases) but never finishes.

The only flawless version is that bootloader itself is the one which receives and does the update, which doesn't happen in either mine or gpseed's or nctnico's examples. If the update interface is simple, say, UART, then it's obvious to do it like this. But if it's like in our case, that the firmware connects to the production server through TLS authentication&encryption, and updates are served through the same path, then that would mean bootloader needs to do all of that. Fair enough, it could do it, and the app would reuse the same networking code to avoid wasting flash in duplicated code. But then the question of updating the bootloader arises. Sooner or later the TLS / networking code needs an update, and that means the bootloader needs to be updateable, which means same A/B concept for the bootloader, which means the same risk of putting technically correct but functionally broken code in place we just discussed. We just changed names of parts (app -> bootloader), not the actual structure.

There is silver lining through: this risk of "broken update" can be mitigated by good testing. Test well before releasing. Release in waves with canaries. This is what we do. Final simple test that after update and wait of a few days, another new update passes, in different device configurations.

Testing doesn't help if the flashing process physically is sensitive to power loss or data corruption, though. Which makes these two failure modes different. It's inexcusable to have an update process which bricks the device on power loss in 2026, in my mind.

[peter-h]

Or you may decide not to offer upgrades at all, which in itself offers lots of benefits.

Indeed, although the capability to do so, even if not publicised, gives you a lot of business risk insurance. The cost of scrapping a lot of units could be astronomical, and the cost of the same at a customer's is even higher

We have numerous OTA threads e.g.
https://www.eevblog.com/forum/microcontrollers/stm-32f4xx-what-hacks-are-known-around-level-2-security/msg5605715/#msg5605715

Unless you are selling phones or similar, OTA is largely a business risk limitation exercise. You are not some crook so you won't be knowingly selling non-working junk, so updating is largely about critical bug fixing.