Secure Microcontroller for crypto hardware - Page 1
Forum section: electronics / general

author: rakeshm55
author_rank: Regular Contributor
timestamp: March 13, 2018, 05:12:40 pm
content: 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 need1. Secure boot2. Firmware authentication3. Secure key storage4. JTAG disable feature5. Hardware accelerators6. Tamper detectionWhat are the other features needed for a typical security device?? Please advice

author: helius
author_rank: Super Contributor
timestamp: March 13, 2018, 05:32:30 pm
content: protection grid to prevent decapping the IC and reading out the private keysconstant-time and -power design to prevent timing attack and DPA attack.

author: nctnico
author_rank: Super Contributor
timestamp: March 13, 2018, 05:35:11 pm
content: Quote from: rakeshm55 on March 13, 2018, 05:12:40 pmSecurity 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.

author: dmills
author_rank: Super Contributor
timestamp: March 13, 2018, 05:49:46 pm
content: 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.

author: marshallh
author_rank: Unknown
timestamp: March 14, 2018, 02:52:53 am
content: 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.

author: rakeshm55
author_rank: Regular Contributor
timestamp: March 14, 2018, 04:34:27 am
content: Quote from: marshallh on March 14, 2018, 02:52:53 amCould you please elaborate on why MCU firmware should have atleast one key?? I was expecting all keys to reside in Secure key storage area.

author: David Chamberlain
author_rank: Frequent Contributor
timestamp: March 14, 2018, 08:12:18 am
content: Because its turtles all the way down... i mean keys.