Secure Microcontroller for crypto hardware

[rakeshm55]

I have to develop a crypto module for SDR platform with RED/Back separation. I am in the process of literature survey.

I want to know what is the importance of using a secure microcontroller.
Is there any standard guidelines to be followed while developing Hardware for crypto ??
Any example implementation would do as a starting point.
how to choose the right secure controller??

I guess I would need

1. Secure boot
2. Firmware authentication
3. Secure key storage
4. JTAG disable feature
5. Hardware accelerators
6. Tamper detection


What are the other features needed for a typical security device?? Please advice

[helius]

protection grid to prevent decapping the IC and reading out the private keys
constant-time and -power design to prevent timing attack and DPA attack.

[nctnico]

I have to develop a crypto module for SDR platform with RED/Back separation. I am in the process of literature survey.

I want to know what is the importance of using a secure microcontroller.
Is there any standard guidelines to be followed while developing Hardware for crypto ??
Any example implementation would do as a starting point.
how to choose the right secure controller??

I guess I would need

1. Secure boot
2. Firmware authentication
3. Secure key storage
4. JTAG disable feature
5. Hardware accelerators
6. Tamper detection


What are the other features needed for a typical security device?? Please advice

Security goes way further than just making a box which is difficult to hack. If this is for a commercial project then please hire a security expert to review the entire project.

[dmills]

What does your threat model look like? Nation state is a game of economics as much as anything, and are you looking at tactical or strategic time scales?

Do NOT invent your own cypher scheme, hackerdom eats those guys for lunch, don't be that idiot, use something well tested, ideally something like AES for the payload and a well thought out key exchange protocol to generate the keys.

Given the standard attacks on these things include power based side channel attacks you probably need something that deals with that.
Ideally you want constant power drain irrespective of the activity and for the crypologic cores to run in constant time.

I would observe that the first place you target when trying to break these things is stupid implementation bugs (VERY common), and then that things like the RNG are fair game (Speaking of which a good hardware RNG is useful in these things, but depending on your paranoia level, be aware that exploits targeting the RNG (Possibly at the level of semiconductor masks) are a popular game because compromising that screws with essentially all of the key exchange protocols).

Power and RF sidechannel are popular attacks and have been since I was breaking satellite cards back in the day, you would be surprised by what is possible, especially if the software author was not aware of the risks.

Speaking of side channel, the clock is another vector, maybe I can extract information by crashing the thing by running the clock out of spec? Same for most of the other IO, can I mess with the chip by driving some random IO pin outside the rails?

Sometimes you can learn things by hooking a few SDRs to the IO pins around the chip and doing correlations between the noise received, if nothing else it can hint as to where on the die things are happening. 

One of the better ones I have seen was an attack on a micro that had the usual protective lattice metal layer over the die, they went in thru the back! ground away most of the bulk Si, then laser drilled, metallised and probed! Expensive, but given sufficient incentive....

73 Dan.

[marshallh]

Many microcontrollers have a security bit that can be used to prevent readout of their own flash. However, an attacker can usually find a way around it, such as manually flipping the protection bit. Depending on the attacker they may have access to specialized equipment like a FIB station to make that possible.
Some MCU families have publicly disclosed vulnerabilities, avoid those.

It is possible to add some secure crypto ICs like the ATSHA204 which funtions as a key store and can be used to verify legitimacy via HMAC-SHA256. However, you will still need to store at least 1 key in your MCU firmware, and the MCU will always be a little bit vulnerable. Obfuscation could make statically extracting the key much more difficult (in the case someone was able to dump your flash, they would still not find the key explicitly stored in 1 place). Ideally you would use a MCU that has separate OTP memory for storing these keys making them harder to read out.

Firmware updates can be signed by the manufacturer and verified by the device using public key crypto. Elliptic curve is the latest hotness here and works well when implemented properly. It's always best to re-use trusted libraries where someone else has written the crypto, rather than writing your own (because you WILL make subtle mistakes).

In the end, no device is completely unhackable. The first step is to find out who you are worried about copying/hacking your product and then design accordingly.

[rakeshm55]

However, you will still need to store at least 1 key in your MCU firmware, and the MCU will always be a little bit vulnerable.

Could you please elaborate on why MCU firmware should have atleast one key?? I was expecting all keys to reside in Secure key storage area.

[David Chamberlain]

Because its turtles all the way down... i mean keys.