STM 32F4xx - what hacks are known around Level 2 security?

[jnk0le]

This can be targeted by DPA/CPA attacks. Complexity varies on the used crypto implementation, which is easy to deduce (HWcrypto from part numbers, execution times from SPA etc.)
e.g. tiny-aes-c can be broken in like 50CPA traces by chipwhisperer.

Can you supply more detail?

this is the one with 50CPA claim https://webthesis.biblio.polito.it/secure/26870/1/tesi.pdf

Are you saying there is key leakage via exec time varying with the key or data? There might be but you need to be able to inject known data to do the measurement, which is slow because the spoof firmware will be rejected each time, but only after some seconds. For the paranoid, it would make sense to do some random delay before rejecting each candidate block after the decrypted version fails the hash...

In power analysis this won't change anything. Chip will be reset right after power traces have been captured. The bigger binary the better.

The timming leaks can still be measured via shift of power traces (SPA)

Are you saying there is key leakage via exec time varying with the key or data?

HWcrypto from part numbers

The hardware AES you get on some chips (like the 32F417) may have key leakage too but again you need to be able to inject small bits of data and run it.

tiny-aes-c can be broken in like 50CPA traces by chipwhisperer.

How would chipwhisperer crack AES, if you are not inside the device? The purpose of chipwhisperer is to break RDP2 and extract the entire FLASH and then you don't need to crack AES-anything because the key is right there somewhere.

RDP2 cannot be always broken.

Malformed update package is sent to the target device, which subsequently decrypts it (then verifies).
This exact step is exploited by DPA/CPA, where the "malformation" is precisely controlled by the attacker.
(random delays or timming leaks make it harder but not impossible)

With the key you can decrypt the update package without the need of getting anything from the flash.
Bootloader? If your adversary is some chinese "R&D" shop, then subpar bootloader just adds up to the collection of subpar components. All of which will make "your" customers "happy".

(glitch attacks on verification are also possible)

[Siwastaja]

What are those? I've never heard of such a thing, if the CPU FLASH is wide open.

I mean, you know, the source code of pretty much all of the Internet architecture is "wide open" for anybody to examine, yet very same software is used in mission critical data security stuff, e.g. internet banking. The same thinking of course applies to a firmware project. Regardless of what you try to do, your program is wide open anyway. Security does not need obscurity, quite the opposite.

These practices are things like asymmetric key encryption and signing e.g. TLS, using proven-good networking stacks, following vulnerability reports and taking actions... It's not perfect, but that's how the real world runs with surprisingly rare problems. (There are always some, e.g. openssl has some major security issue every few years.)

Further, you use practices like generate device-unique private keys so that compromising one device does not give access to any other device.

If you need a product where you cannot extract data (or pretend to be that device) even with full, unlimited physical access, then things indeed get quite difficult. You almost always depend on IC-scale special custom solutions which you carefully discuss with the IC provider, and make agreements on sharing the responsibilities. Stuff like ST's generic lock bits are too unreliable.

[dietert1]

After reading the italian paper on power side attacks i was wondering, whether using peripherals like counters, DMA or interrupts during decryption could destroy the power traces. I'd guess in a real product of some complexity those attacks will be rather difficult.

Regards, Dieter

[peter-h]

generate device-unique private keys

That's quite an admin task, maintaining a database of who got which unit and encrypting firmware updates individually. But, yes, possible.

Actually this takes us to a somewhat related topic: who gets OTA firmware updates? In general they would be deployed to 1-off and small customers first, as a corporate risk management practice, and only after a long time (or better still never) deployed to customers who have known large installed bases - unless it is a critical security fix, but they should be using IoT in such applications anyway (on open ports etc). And to implement that you will need a database of which unit went to who, and control OTA deployment according to S/N, CPU ID, etc.

After reading the italian paper on power side attacks i was wondering, whether using peripherals like counters, DMA or interrupts during decryption could destroy the power traces. I'd guess in a real product of some complexity those attacks will be rather difficult.

That Italian paper - very interesting - shows what has been known for many years. The more recent smartcard chips attempt to obscure their power consumption. Still takes a lot of setting up, if you are starting with a target which is some product whose inner workings are not known to you. The author is super bright.

Rapid interrupts will mess up the analysis for sure, and yes you could very easily set up a DMA channel to do some inconsequential memory to memory transfers during the AES operation.

I don't know if this guy set up the code so that nothing else was running. Don't have time to read every page.

[Siwastaja]

generate device-unique private keys

That's quite an admin task, maintaining a database of who got which unit and encrypting firmware updates individually. But, yes, possible.

Why would you encrypt firmware updates individually? After you decrypt it to run it, it has to reside in RAM (or flash) anyway unencrypted so that a common CPU can execute it. Therefore it's again readable in plain text.

[peter-h]

We may have wires crossed.

If you have device-individual private keys then you will also have differing public keys, and the public key is used to encrypt the firmware, no?

Then you have a system where compromising one device does not yield a way to do bogus firmware upgrades (code of attacker's choice) to all the others.

I don't see any other way to achieve that. If you were deploying upgrades to a small device population then you could encrypt with every key.

[Siwastaja]

If you have device-individual private keys then you will also have differing public keys, and the public key is used to encrypt the firmware, no?

You sure can do it that way, but that is not how how modern-day asymmetric key authentication and encryption systems like TLS is usually used. Device certificate (public key) is signed by a trusted CA. Server certificate is signed by the same trusted CA. Therefore they can communicate, and the server will authenticate the client. Single-use keys are negotiated for the session only.

You only need to manage the CA, which at its simplest is to use a CA private key to sign device (and server) certificates and make 110% sure this CA private key never leaks. But thanks to having this CA, you don't need to store and manage certificates (even less private keys) for each device.

[peter-h]

Doesn't that require each device to hold a root certificate file (cacert.pem etc) or equivalent if using a private server? That can be compromised.

Same with a browser doing HTTPS to your bank. The browser's certificate store must not be compromised.

My box holds this file in its filespace. No way to access a server using TLS without that file, or a stored certificate.

[Siwastaja]

Public key aka certificate. It's public by definition. Nothing is compromised, you can put it on your website for a download. It's the CA key (private key) which is sensitive.

[peter-h]

OK I get this.

If that server certificate is stored so it cannot be tampered with, e.g. in the CPU FLASH and not on a USB accessible drive, and RDP2 is compromised only on one unit, then a client-initiated OTA update should be secure.

Incidentally this is how the ST demo code stores it, and it is ok for updates from a private server, but for many/most MbedTLS applications this is not useful, so one ends up storing the cacert.pem file somewhere. This file is currently 224k. It could all go into the CPU FLASH (it zips to 127k so if you want to have unzipping code in your product...) but the bigger problem is that it needs RAM to hold the whole 224k! This is a major shortcoming of MbedTLS. There is a mod published for MbedTLS at https://github.com/mongoose-os/mbedtls which loads the certificates into RAM one at a time; this took a few days to implement.

[Siwastaja]

Server certificate is not stored on device. CA certificate, device certificate and device key are.

For device-server interaction, you can simply be your own CA provider. CA certificate is then less than 1Kbyte.

If you want to build a product which is a web server such that modern browsers do not complain about it, then your life is going to suck more.

[peter-h]

How about if the device does not have a direct internet connection?

[dietert1]

Some developers "marry" their devices to a smart phone app. So they don't need compatibility with a web browser and they can use existing infrastructure like internet connectivity, display, touch screen, camera to scan QR codes and GPS location awareness.
Recently we got a GPS tracker meant for dogs. It is hermetic (water proof) with inductive charging. It has an acceleration sensor to wake up on movement and sends SMS messages once per minute to some server that the app is connected to via internet.

Regards, Dieter

[Siwastaja]

How about if the device does not have a direct internet connection?

Then you can do stuff like create a phone app which connects to your device using bluetooth, or even USB port. Then you can decide on any infrastructure you want and it can be quite simple (of course the bluetooth stack in itself is complex, though), and the phone acts as a gateway to the Internet. Most users are fine with that as almost anyone has a smartphone now and they are used to installing gazillion of stupid apps so yours would be only one such thing more.

[peter-h]

Some developers "marry" their devices to a smart phone app

That's a really bad idea. Everybody wants an "app" for everything. Half the population would ask for an "app" for wiping their bottom But it is a dev nightmare to test these and keep them current, against phone OS updates.

If one really must, it is far better to knock up a simple HTTP server (I wrote one) and use a phone browser, with some JS running in it. I have that for my box, and got some guy on Freelancer.com to write the JS. You can't do file transfers properly without client side JS.

are used to installing gazillion of stupid apps

Yes; see above

This is not a good solution for a firmware upgrade system.

[Siwastaja]

This is not a good solution for a firmware upgrade system.

I hate it, too, but let's be honest: 99.9% of actual end users would prefer this over anything else (excluding the best solution of direct internet connection and updates happening completely transparently to them). Regardless of how stupid it seems to have to install stupid apps, most people have given up any hope of better life and totally used to this sort of crap. As long as your app is less than 500MB download from app store, starts in less than 10 seconds and doesn't crash >50% of the time, it is an easier solution than e.g. having to find a computer and usb cable and run some weird updater.exe; or find an SD card or USB stick and put some weird files on it.

The advantage of an app is it's self-documenting. You only need to tell "install X". They know how to access app store. Then the app itself can show all relevant instructions on-screen.

Of course making the app is more work.

[dietert1]

The GPS tracker device i mentioned is typical and selling in thousands. I'd guess those people know what they are doing. Meanwhile i found that their app is available in the app store only for certain countries.
You were asking about a device without internet connection. If your device needs to be compatible to web browsers or another PC application ("upgrader tool") the security nightmare is very similar. Strong language doesn't replace arguments.

Regards, Dieter

[peter-h]

App development, cross platform, android, ios, is a huge hassle and is absolutely the last thing anybody wants to do unless you are a big company with loads of app programmers already sitting there, OR you need to implement a special security protocol across the link.

[uer166]

App development, cross platform, android, ios, is a huge hassle and is absolutely the last thing anybody wants to do unless you are a big company with loads of app programmers already sitting there, OR you need to implement a special security protocol across the link.

One (not as clean) way I've seen one-offs done is running an HTML5 webserver on your embedded thing on an ESP32 with WiFi. You make an AP out of it and use a browser to get the controls. Much bigger user hassle but works okay for small scale things.

[jnk0le]

After reading the italian paper on power side attacks i was wondering, whether using peripherals like counters, DMA or interrupts during decryption could destroy the power traces. I'd guess in a real product of some complexity those attacks will be rather difficult.

Regards, Dieter

DMA with generated random data could have some effect.
However even the bitsliced-bitmasked implementations do get broken e.g. https://eprint.iacr.org/2022/327.pdf

It's just a matter of how rich is your adversary.

[peter-h]

That just means they have not done it very well.

Going way back, one reason why software DES products could never get export approval (in say banking comms boxes) was because the exec time was generally key or data dependent, whereas the DES chips (Zilog, 2nd sourced by AMD) didn't have this problem.

And now you need to make the power consumption the same regardless of key or data.

You make an AP out of it and use a browser to get the controls. Much bigger user hassle but works okay for small scale things.

Yes you can do that but having an HTTP server in your box and going to it with a browser (over ETH) is basically the same thing. The web server needs to be manually enabled for the config task.

[tellurium]

If that server certificate is stored so it cannot be tampered with, e.g. in the CPU FLASH and not on a USB accessible drive, and RDP2 is compromised only on one unit, then a client-initiated OTA update should be secure.

That's when crypto elements can be used. For example, Microchip's https://www.microchip.com/en-us/product/atecc608a or ST's https://www.st.com/en/secure-mcus/stsafe-a100.html .

They have multiple layers of protection, and can store private keys without ever revealing them to the main MCU. TLS library should be modified to offload crypto operations to the crypto element - which may also hardware-accelerate calculations.

Some manufacturers even make modules with the integrated crypto element, like here's Espressif's ESP32 with EC608: https://docs.espressif.com/projects/esp-idf/en/v4.4.2/esp32/api-reference/peripherals/secure_element.html

[dietert1]

Due to risk of backdoor i would not try to secure a ST micro adding a ST crypto element. Better combine with other brand.

[peter-h]

I looked at these a while ago.

Basically you are swapping secure storage in CPU FLASH locked with RDP2 for secure storage in a separate chip with which you communicate on open wires. And neither of these devices is provably resistant to the various attacks discussed.

There are many more people attacking RDP2 on 32F4 than attacking the specialised chips whose usage is much narrower (and whose users probably do not advertise they are using them) so we may not see a lot of publication of successful attacks on the latter.

What am I missing?

BTW the atecc608a (EC only, no RSA) is very cheap but is now listed as obsolete.

What these chips do give you is that for a few $ or less you can make RSA/EC run a lot faster. A 32F417 168MHz does it in something of the order of 1 second (2k bit RSA, IIRC).

[dietert1]

It would be ATECC608B or ATECC608C now. Have a look at the datasheet. NDA may be necessary. An example of the one-wire device i mentioned above.