MCUs/FPGAs reasonably good vs. definitely bad for security? - Page 1
Forum section: electronics / general

author: evb149
author_rank: Regular Contributor
timestamp: April 10, 2022, 02:55:44 am
content: I'm wondering what the status is these days for which MCU / FPGA devices which are in the "reasonably good" vs. "definitely bad" categories with respect to readout or cloning protection for the loaded firmware/data and also if these are connected / IOT parts whether the communication firmware / ROM / library is reasonably secure?Mostly I don't care and advocate open sourcing hw / fw as much as possible but sometimes have something that's not in that category.For MCUs I'm speaking of things mostly like ARM Cortex-M series parts, though if there's a good list covering the commonly available Cortex-A parts that'd be interesting.Every now and then I hear of x, y, z device / family's security being compromised one way or another and I haven'tkept track as to what's considered ok vs. bad in that category.The level of protection I'm inquiring about is what I'll call "reasonably good" -- it's not for anything particularly sensitive for information / IP security, there are no hard and fast anti-clone / anti-tamper requirements, it doesn't have to haveheroic protections against particularly advanced decapsulate the chip, probe the die, use focused e-beam / xray probes or whatever kinds of attacks. I know if someone is determined enough they'll probably find a way given enough time / budget.But the sort of thing that if I designed something and sent it out for overseas manufacturing or whatever that it wouldn't be able to be cloned in some automated trivial fashion involving very little effort / expense.This assumes the parts are locked in whatever common ways the device OEM provides for that purpose (JTAG, SWD, encryption, whatever).So are there any good lists / data bases / common wisdom options for commodity level generic use part families?Edit: I suppose I should also mention that some things I'm curious about are just general MCUs, though as I occasionally work on ethernet / IOT / other network connected stuff then any IC family that supports tcp/ip/udp, 802.11, 802.15.4, BLE, whatever is relevant to my question, too, and probably worthy of more serious concern even for purely personal projects.

author: ataradov
author_rank: Super Contributor
timestamp: April 10, 2022, 03:40:21 am
content: I'm not aware of a specific list, since it is really hard to compare strength of attack. Most of the modern devices could be considered reasonably good. Vendors typically fix completely obvious no-skill required attacks. And fault injection is reasonably effective against most devices, but it requires skills, equipment (although now there are some very cheap options) and persistence.There are papers describing attacks on most popular MCUs out there, and yet products continue to be released, so obviously thousands of huge companies don't consider them significant enough.There is a good list of devices with prices to for extraction -https://russiansemiresearch.com/It is hard to tell if those guys are legit, since there are no happy customer testimonials, but they have been around forever, and there are no bad reviews, which I assume would appear by now.You will have better luck with MCUs advertise secure peripherals and memories, they would typically have shields over sensitive areas, making attacks harder. But I don't think any of them shields the whole MCU, they typically focus on memories containing secrets.

author: ataradov
author_rank: Super Contributor
timestamp: April 10, 2022, 04:08:46 am
content: But on a connectivity level it is on you to use secure protocols. Obviously if you use an non-secure bootloader, then security bit of the MCU does not matter, attacker can just use your bootloader to dump the firmware.Most of the reports of things being compromised have nothing to do with the security of the MCU. You don't need the firmware do prepare good attacks.

author: ataradov
author_rank: Super Contributor
timestamp: April 10, 2022, 04:30:43 am
content: There are some devices that are straight up broken. Nordic nRF51 family security is very broken, it is trivial to extract the firmware. nRF52 fixed that a bit, but it is still possible to bypass with fault injection -https://limitedresults.com/2020/06/nrf52-debug-resurrection-approtect-bypass/I would assume that most MCUs can be broken with fault injection, some are just waiting someone motivated enough to do it.Most of the things you mention are faults in the firmware, not hardware. You need to differentiate external attacks for takeover/DoS and hardware attacks to extract the firmware. They are not the same and one does not generally lead to the other.

author: Miyuki
author_rank: Frequent Contributor
timestamp: April 10, 2022, 07:15:38 pm
content: Here are two separate things as ataradov mentionedPhysical device security. General-purpose processors never will have impermeable protection again cloning or some hacking attempts when you have physical access. The only way for paranoid designs is something like encoded data and keeping the key in secured memory and being ready to dump it when detected any attempt. And even it is not 100%. It does not worth the effort for most designs.And when you send your devices to manufacture and flash to some third-world countryYou just throw everything out of the window anyway.Firmware security and updates. Consumer-grade devices use software developed by the cheapest third-world guys you can hire. That is the fact. And is maintained only when it makes a profit. That is why most devices are abandoned soon.When you want secure firmware you need in-house development with detailed reviews and checks. It cost an order of magnitude more than something from some guys who barely understand you. And even it can have some vulnerability from time to time which is not detected soon in testing.It is all matter of risk vs reward

author: peter-h
author_rank: Super Contributor
timestamp: April 12, 2022, 08:03:13 pm
content: I read somewhere that battery backed up Xilinx FPGAs were used on some weapons. Load the config code before launch, obviouslyThe idea is that the weapon might get captured, especially if it fails to explode, but the launcher should not.Comms security products often store a key or certificate internally and have well developed tamper-proof packaging - right up to glass encapsulation with a wire embedded in the glass. This is a decades-old technique, and some ingenious approaches were used. Still needed today; I believe every cash machine has such a module, storing a key which, if compromised, would create absolute havoc.Smartcard chips are very secure nowadays; after all your PIN is storedonthe credit card. The trick is how to make use of the secure smartcard storage, in a way which is hard to intercept and patch out etc. If you can run some critical codeinthe smartcard, that will be very good nowadays. I did some work with a Siemens SLE44C200 many years ago (https://cordis.europa.eu/project/id/1728);that was one of the early ones (8051 based IIRC). A very cheap very secure approach.

author: NiHaoMike
author_rank: Super Contributor
timestamp: April 13, 2022, 02:20:40 am
content: Quote from: Miyuki on April 10, 2022, 07:15:38 pmOpen source firmware solves a lot of that problem. LineageOS and OpenWRT are two good examples.

author: peter-h
author_rank: Super Contributor
timestamp: April 13, 2022, 08:21:33 am
content: Problem with open source is that - apart from large projects - it tends to be supported until the guy who wrote it gets a girlfriendAnd everybody knows where the back doors are.Open source websites (Magento, PHP-BB, etc) are heavily compromised all the time and nobody seems to be able to stop it.

author: hans
author_rank: Super Contributor
timestamp: April 13, 2022, 01:08:53 pm
content: Quote from: Miyuki on April 10, 2022, 07:15:38 pmAgreed. Even with physical access, it's the question if someone wants to get destructive/medieval to get the device to do what it wants."Security" can be both. E.g. look at the recent Dymo RFID integration. Is the hacked RFID reader a breach of security in that device? It certainly is. But if someone has access and is willing to modify the hardware, there is little to stop them (apart from using very complex/expensive cryptographic algorithms with secret keys, challenge responses, etc.)But I think for most companies MCU security means not being able to clone them. As long as the device doesn't spit out it's ROM when you press read on the programmer, that can be good enough.However, the very popular STM32F103 has a pretty well known vulnerability with it's IVT to read out 85%+ of program data quite easily. If someone is looking for a secret encryption key, they have a pretty good chance of scoring it with that vulnerability.Let alone talking about powersupply fault injection, which is pretty cheaply done nowadays. There are plenty of open source tools available. And even if you don't achieve a full ROM readout of a chip, it can be used to readout the PIN of a cryptowallet, as a combination of a software vulnerability:But again, it's not a trivial "read ROM" button, and, if your life doesn't depend on that single chip, then it's protection is probably OK. If your (or someone else's) life does depend on it.. you probably don't use a mainstream ARM MCU, and would also do a design audit by an independent consultancy firm to test your security.

author: peter-h
author_rank: Super Contributor
timestamp: April 14, 2022, 08:09:05 am
content: Not sure how representative the above experiment is, for modern smartcard chips.