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

[peter-h]

Like I said above Here you go:

https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-Defeating-A-Secure-Element-With-Multiple-Laser-Fault-Injections.pdf

You are just swapping one probably-hacked chip with another (more) probably-hacked chip.



The other challenge is that if you are using one of these chips, you do need the CPU to be secured (RDP2) otherwise somebody can just replace the security chip with another one (which does whatever the attacker wants it to do). These chips have the capability to authenticate themselves to the CPU but that is worthless if RDP2 itself is cracked.

I am not an expert in this stuff. I understand the outline of PK, RSA, EC, good old DES and 3DES (I used to make DES line encryptors but they had a fixed key). But clearly there is no way to provably secure your product with one of these chips unless you can also provably secure the CPU itself.

In the real world, say cash machines (ATMs), they do not trust any chip and instead use physical security, constructing a module which is encapsulated and the encapsulation (which can be glass!) contains a fine wire...

[dietert1]

If those setups are good enough for bitcoin wallets, i'd guess they are good enough for whatever you are making.
The video you linked has a very clear statement that adding the crypto chip makes an attack more difficult, as one needs to break two chips instead of one. You cannot break the wallet choosing one of the chips.
By the way the reported attack was on the A version of the chip that is no longer available. Those crypto chips likely have more security related revisions than ST micros. Anyway as far as i remember you are using an old STM32F4xx product.

[peter-h]

The problem is if you can spend e-cash over and over. When the e-cash debate started, c. 30 years ago, some of the proposals would have allowed that. Hitachi produced a smartcard chip back then, H8 based of course, which they said was unbreakable but

- nobody really trusted it (all the hacks discussed here were known back then... google on the Capstone Clipper chip and the special features it had; ignore the civil rights stuff).
- the banking business would not touch e-cash on which there was no central "database" (fantastic for tax evasion, etc)

Then the whole e-cash business basically died because it became obvious nothing can be trusted.

AIUI, bitcoin cannot be spent multiple times so your loss is limited to the contents, and that's fine.

Yes the 32F417 is > 10 years old but is there another software-compatible and pin-compatible chip which has "strong" RDP2? If ST do one, they are admitting the previous ones are weak. But give it 5 years and the new one may be broken too.

I did a quick google and there is the ST33K but much less RAM, much slower, "Hardware security-enhanced DES accelerator" suggests it was designed > 15 years ago, but hey it has "Highly efficient protection against faults"

Interesting debate but every time someone comes up with something, 30 secs on google finds a problem. Ultimately, if RDP2 was secure, you would not be able to improve on any crypto co-processor (except on speed of RSA).

[Siwastaja]

If those setups are good enough for bitcoin wallets, i'd guess they are good enough for whatever you are making.

Of course not. Securing against physical access is highly dependent on project. Maybe it is easy for a bitcoin wallet. We, on the other hand, have a let's call it heating controller. With physical access, attacker can just install a box of their own, connect the heaters to it, and connect our relays into inputs of their so they can mimic the operation. They can split the Ethernet and connect to a server of their own. They can record everything our box does, and control the customer's heaters in any way they wish - not too different from getting access to the device private keys and taking control of our device.

Therefore in this kind of case it's most important they can't gain remote access to another customer's box which they have no physical access to. In other words: device keys must be unique so that only that single device is compromised.

And then again, for things like bitcoin wallets, you want to make it as secure as possible even against physical access attacks.

[peter-h]

But you don't need a "crypto coprocessor" for that.

AFAICS those chips don't do anything other than speeding up some ops, but the 32F417 already does AES at a very high speed (practically, as fast as 100mbps ETH). In fact I struggle to see their EC capability because I know a lot of public servers (as encountered in TLS testing) still use RSA as #1 and maybe they can use EC but I haven't seen it.

[dietert1]

As far as i understand the advantages of a separate crypto chip are:
- closing brand backdoor. Somebody with insider knowledge still needs to break the other chip.
- detailed datasheet only with NDA. An advantage for some and a hurdle for everybody else.
- no debugging interface
- no boot manager

The bitcoin wallet example shows once more how security is the result of combining several hurdles. An attacker would need to break the MCU, the cryptochip and probably some certificate hosted online. As someone wrote before: Multiple hurdles are a statement.
Just remember how Microsoft organized a huge business by distributing registration keys! A bit ridiculous but good enough as they kept moving. Update support with ever changing protection schemes is a good method.

[Siwastaja]

As someone wrote before: Multiple hurdles are a statement.

Maybe a statement to investors or higher-ups, but nothing to do with security. Real security is as weak as the weakest link. Adding as many real layers of security as possible truly helps, but adding ineffective layers is totally unhelpful. E.g. thinking that the "bad guys" do not have access* to the datasheet of a mass-produced IC just because it is "under NDA" is ridiculous. This whole dietert1's message is so full of cargo cult that it causes physical pain to my eyes.

*) or that getting the access would slow them down in any significant amount

[peter-h]

NDA data sheets are usually found on chinese websites. For example I found the full SD card interface spec in minutes.

I don't think you need to break both chips in the context of this thread. You need to break only the CPU (RDP2) and then you can replace the crypto chip with some little CPU (or FPGA) which says Yes to everything. Or patch the main code to not use it.

[dietert1]

If you want to provide a link to the full ATECC608C that appears to be the current version i am interested. Or another video showing how to hack the current version.

[Siwastaja]

If you want to provide a link to the full ATECC608C that appears to be the current version i am interested. Or another video showing how to hack the current version.

You fall to the same trap as peter-h often does in these kind of threads: that by showing that you or me cannot show an obvious attack vector within a few minutes proves absence of such.

But a sane assumption is that even if you or me don't, an attacker will have access to full ATECC608C datasheet, and they don't have to be NSA-tier to have that. Do not base your security on obscurity. Design the security such that it's based on key exchange principles, not trying to hide implementation details because they inevitably and always leak.

[dietert1]

Nothing of a trap. No need to be that nervous.
I am just trying to find a useful response to Peter's questions. After STM32 hacks exist, learning about additional crypto measures is useful. Probably not for trolls.

[peter-h]

peter-h often does in these kind of threads:

Not me. No need to get personal. But I know you like that

I fully expect the cracking of these chips to be harder than RDP2 on 32F4 but a much more interesting challenge

If I was marketing the ATECC608 and the C version really was much better against these attacks (which are at least 30 years old) I would spread the word because it would be a huge selling point

I am also surprised at no RSA anymore. It's a bit of a risk if building a general purpose TLS box.

Also I am surprised at the "an AES hardware accelerator" given that the I2C clock is 1MHz max and any modern CPU can do AES as fast in software. In fact probably a lot faster by the time you shifted the data there and back. These chips must be really old.

[dietert1]

Just found this:
https://forum.digikey.com/t/atecc608-node-authentication-example-walk-through/13141 and
https://www.microchip.com/en-us/product/atecc608c-tflxtls
There they have a migration guide for revision B to revision C

Regards, Dieter

[peter-h]

Dieter - are you using these chips and, if so, why?

[tellurium]

I am also surprised at no RSA anymore. It's a bit of a risk if building a general purpose TLS box.

ATECC (ATmel Elliptic Curve Crypto) is elliptic curve, which is a more modern TLS (sub)standard. EC-based TLS and certs are smaller and faster than their RSA counterparts. What is risky about it?

[dietert1]

We made quite some money with MSP430 boards and that business worked almost 20 years. We provided firmware updates as encrypted files about once a year and they were used by our customers. The 'system' part of the firmware installed the updates over a UART connection. We could update the system part as well using the same method.
That MSP430 had a hardware fuse for disconnecting its JTAG. 98 % of the few boards coming back were with flash memory errors, maybe after attacks, but i don't think it got cracked. For us it was nice and easy to fix broken boards using a back door for flash programming. The other 2 % of failures were over- or reverse voltage and broken crystals, probably hard hits.
Now we happen to use STM32 MCUs instead, including ones without internal crypto peripheral. I think those crypto chips can be useful in the context. Just for fun: 35 years ago i made some PC dongles for an expensive CAD software. Image shows prototypes.

Regards, Dieter

[peter-h]

ATECC (ATmel Elliptic Curve Crypto) is elliptic curve, which is a more modern TLS (sub)standard. EC-based TLS and certs are smaller and faster than their RSA counterparts. What is risky about it?

I said " It's a bit of a risk if building a general purpose TLS box" meaning that if - as a client - it needs to connect to a server which does RSA only, it isn't gonna work

Now why would a server do RSA and not EC?

Lots of reasons, like the sysadmin charging $1000 per half day for doing anything on it If you think I am joking, I am paying £1.5k per day or part day, for admin on a server. It happens to run Ruby on Rails but that is just another example that a solid working system is not going to get reconfigured just for fun. Fairly obviously I don't get work done on that machine unless necessary.

If EC was really preferred out there in the big ugly wide world, you would expect servers to specify EC first, not RSA as most of them do. But of course I don't actually know how many of them would drop down to EC; probably most? Who knows?

Dieter1 - thanks I remember those dongles. I still use some of that software, like Protel PCB 2.8 (1995) which I bought for £1.5k and got de-dongled by some Polish guy.

[Siwastaja]

I am also surprised at no RSA anymore. It's a bit of a risk if building a general purpose TLS box.

ATECC (ATmel Elliptic Curve Crypto) is elliptic curve, which is a more modern TLS (sub)standard. EC-based TLS and certs are smaller and faster than their RSA counterparts. What is risky about it?

Some people think RSA refers to a concept, not the actual algorithm, which is not surprising because RSA keys and certificates were in use for so long. When they hear that RSA is getting deprecated, they don't necessarily understand that the concept has not changed at all, just the algorithm replaced with something else (EC) which produces even better security with way fewer bits in the key.

[peter-h]

The SE050 does it all, and being a new chip (2023) mentions resistance to the above-discussed attacks.

https://www.nxp.com/docs/en/data-sheet/SE050-DATASHEET.pdf

I have this from someone who knows a lot about it:

ECRSA was proposed in some research paper as an attempt to provide encryption with the public key as opposed to ECDSA which is only for signatures. But in practice there don’t appear to be any advantages to using this and no one does use it, as the commonly accepted approach to encrypt data is using an EC public key that can be decrypted with the private key, is to use ECDH with an ephemeral key pair and the recipient’s public key to co-derive a shared session AES key with which any amount of data is then encrypted.

How this applies to the topic, I don't know. AFAICT it still needs a secure RDP2.

Does this mean that RDP2 prevents code execution in RAM?



Update: a guy on the ST forum has clarified that the OTP memory should work in RDP2. Obviously, if you want to store keys in there, and want to change a key, you need to move it along to the next 16 byte block. One would assume a valid key would never be all-FFs which is how the OTP starts up, AFAIK.

[peter-h]

Well, RDP2 does seem to work with everything except the SWD debugger - exactly as it should be. All functions are already provided, ex Cube MX (HAL).

Code: [Select]

HAL_FLASH_Unlock();  // Unlock the flash memory
HAL_FLASH_OB_Unlock(); // Unlock the option bytes
*(__IO uint8_t*) OPTCR_BYTE1_ADDRESS = OB_RDP_LEVEL_2;
HAL_FLASH_OB_Launch();
HAL_FLASH_OB_Lock();
HAL_FLASH_Lock();

Gotcha is that you have to test the RDP level before the above because if you run above code with RDP2 set, it hard faults. So a lot of code found online, and countless forum posts, do not work

[dietert1]

The MSP430 system i mentioned before executed code from RAM while installing a new application version. In a protected STM32 one would probably execute from one flash bank while writing to the other bank.

Regards, Dieter

[peter-h]

I have a loader which gets copied to RAM and runs there, doing the CPU FLASH programming - the whole 1MB block.

This all works under RDP2.

Every time I test this I blow away one board so I haven't tested this yet with the if statement around it, but the required code looks like this

Code: [Select]

if (FLASH_OB_GetRDP() != OB_RDP_LEVEL_2)
{
        HAL_FLASH_Unlock();  // Unlock the flash memory
HAL_FLASH_OB_Unlock(); // Unlock the option bytes
*(__IO uint8_t*) OPTCR_BYTE1_ADDRESS = OB_RDP_LEVEL_2;  // Set RDP2
HAL_FLASH_OB_Launch();  // Activate it
HAL_FLASH_OB_Lock();
HAL_FLASH_Lock();
{


and this code can just go into startup, and it should run only once ever, per CPU.

RDP2 blocks booting from RAM but I don't know who would be doing that. You need to somehow get code into the RAM, set up BOOT0 BOOT1 pins, and reset the CPU. What would be the point of such a process?

[peter-h]

From the ST forum, some of the above code is not needed:

if (FLASH_OB_GetRDP() != OB_RDP_LEVEL_2)
{
   HAL_FLASH_OB_Unlock(); // Unlock the option bytes
   *(__IO uint8_t*) OPTCR_BYTE1_ADDRESS = OB_RDP_LEVEL_2;  // Set RDP2
   HAL_FLASH_OB_Launch();  // Activate it
   HAL_FLASH_OB_Lock();
}

There is every possible other version of this on the internet

The conditional is important otherwise you end up with a bricked unit, because setting rdp2 if already set produces a hard fault trap - unless your unit has some recovery mechanism.

The "proper HAL way" is more lines because ST like to use typedefed structs all over the place.

I know regulars will find this funny but it's amazing how much of the full functionality you can get at RDP2 lock level. Firmware updates are no problem if you have a RAM based loader. You need some way to auth updates before flashing them, obviously. The only real loss is the debugger.

[peter-h]

Came across this "zero-content" ST paper

https://www.st.com/resource/en/technical_note/dm01011952-.pdf

I can confirm above code works and the line

Code: [Select]

uint8_t level = *(__IO uint8_t*) OPTCR_BYTE1_ADDRESS;
works for reading out the current value: 0xaa for no security and 0xcc for RDP2.

[Siwastaja]

Came across this "zero-content" ST paper

https://www.st.com/resource/en/technical_note/dm01011952-.pdf

Yeah, you need to officially state obvious stuff like that for managers and possibly lawyers.