STM 32F4xx - what hacks are known around Level 2 security? - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: August 07, 2024, 10:04:43 am
content: It seems perfectly possible, under Level 2, to have a "boot block" which accepts a firmware block, say via USB MSC or via HTTP, encrypted with a key stored in the boot block, and you have a product whose firmware can be upgraded but can't be extracted. You can even publish the firmware block but with say AES256 "nobody" can decipher it. And obviously there would also be a CRC or a hash inside the encrypted block. Superficially there does not appear to be a vulnerability in this basic scheme. The CPU can write CPU FLASH even with L2 set.That's if Level 2 doesn't have a back door.Googling yields various success stories but only for the 32F0 e.g.https://www.usenix.org/system/files/conference/woot17/woot17-paper-obermaier.pdf(STM32F051R8T6)https://www.aisec.fraunhofer.de/en/FirmwareProtection.html(32F0 general)https://community.st.com/t5/stm32-mcus-security/readout-protection-cracked-on-stm32/td-p/387997(ambiguous but 32F0 again AFAICT)https://community.st.com/t5/stm32-mcus-security/stm32f4xx-firmware-protection/td-p/133047(someone asking about 32F4; no useful replies)Does anyone know any more? The setup described for the 32F0 extraction is a fairly easy hobby job. I am not talking about de-packaging and etching off the passivation layer; that's pretty esoteric.

author: wek
author_rank: Frequent Contributor
timestamp: August 07, 2024, 04:38:40 pm
content: Quote from: peter-h on August 07, 2024, 10:04:43 amThose who do are unlikely to go public (i.e. black hats).JW

author: peter-h
author_rank: Super Contributor
timestamp: August 07, 2024, 08:29:06 pm
content: Sure, but the guy in the 32F0 attack did publish it. Actually the first two URLs in my post above are the same paper, from roughly 2017.How old is the 32F0? In particular the STM32F051R8T6 ? The DS is 2017 but that's just the last revision.The errata for this chiphttps://www.st.com/resource/en/errata_sheet/es0202-stm32f051x4x6x8-device-errata-stmicroelectronics.pdfunder 2.2.2 shows ST addressed the specific race condition referenced in the attack paper. So perhaps that attack - quoted all over the place - is no longer viable. ST fixed it in 2016. Interesting they think L2 remains secure:Now for the 32F417VGT6https://www.st.com/resource/en/errata_sheet/es0182-stm32f405407xx-and-stm32f415417xx-device-errata-stmicroelectronics.pdfMy reading of the above is that L2 is defective in that it can be (in effect) downgraded but only by internal software, which is hardly a problem because if somebody can run own code in there, they can read out the whole device anyway. Is that right?

author: dietert1
author_rank: Super Contributor
timestamp: August 07, 2024, 09:12:37 pm
content: If you have a choice, you can superimpose a private security scheme on top of the proposed one or the legal standard. If you don't trust STM you could add another device of different make to improve security. Thus one can block a chip maker backdoor. Security is a moving target.I am currently studying the STM32H7 true random number generator. They publish very little info on that peripheral. Like there is no clock frequency spec in the datasheet. They do have an application note AN4230 about using NIST procedures to check the quality of random number generation. I already noticed that the more recent checks "can't" be used with my STM32H743 prototype. What this really means is the older parts won't pass those tests. Only more recent MCUs have a configuration switch to turn off "moderation". On top of that they write: "A special device must be used for certification." I understand that MCUs available from distributors won't certify!In my own tests i saw that the quality of generated random numbers depends somewhat on clock setup. With HSI48 it worked better than with PLL1Q crystal derived clock. Also i saw a 8x 32-bit fifo instead of the 4x 32-bit fifo described in manuals. Currently i am running a large test searching for "unexpected" correlations. Needs roughly a day or so. Even if i find nothing, i will probably use some extra linear transform for those random numbers, just in case.Regards, Dieter

author: peter-h
author_rank: Super Contributor
timestamp: August 07, 2024, 09:23:03 pm
content: QuoteCan you give an example? People talk about using a smartcard chip for "secure processing" but you still have a wire connection between that and the main CPU. The smartcard chip could do some authentication, maybe, but at extra cost and hassle.What I find interesting is that ST apparently fixed that 32F0 back door very fast - a year before that paper about it was published. I think that's pretty good.

author: dietert1
author_rank: Super Contributor
timestamp: August 07, 2024, 11:02:43 pm
content: I remember a solution with a 1wire peripheral chip that included some onetime programmable EPROM. If you mirror there an encrypted version of the unique STM32 id, it can provide additional protection against cloning. Another cheap solution may be some CPLD or so that implements a challenge-response scheme similar to a dongle for a PC application or a cell phone for bank account access.A firmware-only solution could be based on a small component hidden inside a large package that makes the whole thing crash once per hour if missing. This works like those tax avoidance schemes involving chains of bank accounts. With a little effort one can make it very tedious to re-engineer.Regards, Dieter

author: wek
author_rank: Frequent Contributor
timestamp: August 08, 2024, 08:59:41 am
content: Quote from: peter-h on August 07, 2024, 08:29:06 pmMotivation of white hats (prospect of employment, fame?, altruism?) is way weaker than of the black hats (money). Read, most successful attacks are unlikely to be published.Quote from: peter-hAround 2012and the 'F051 was the first in the line.JW

author: darkspr1te
author_rank: Frequent Contributor
timestamp: August 08, 2024, 01:55:15 pm
content: I have not tried on the F4x yet but i have had success with 103's via a vector attack, STM32F3xx via a vcc glitch and sram attack and I am guessing but the STM32F4x should also fall to this.A chip whisperer glitch attack is by far the easiest and every device I have tried has fallen to it. i've managed to repair quite a few devices that have had broken bootloaders due to firmware flash issues or worse when the OEM provides the wrong file and kills you machine then shrugs and goes "sorry, nothing more i can do" , Looking you ANSEL and your dodgy support team.there are some other attacks out there i have not tried that may work on stm's ,reading found here ->https://offzone.moscow/upload/iblock/0a5/nad1d86e3ah3ayx38ue56vxbh2j07kd4.pdfthe clock pulse glitch has worked on one stm i tried but no others which lead me to believe it's a re-marked clone and indeed to does fail the bluepill test code.darkspr1te

author: peter-h
author_rank: Super Contributor
timestamp: August 08, 2024, 02:14:30 pm
content: Very interesting,darkspr1te.Is the SRAM attack just SRAM readout?One interesting bit is that ST document the vulnerability on the F0 and say (in the errata) that they fixed it. But there is no mention on the F4, which may suggest that it doesn't have that particular vulnerability.Which STM32F3xx did you succeed with and did you read the FLASH or just the RAM? The errata for the 303 does not say anythinghttps://www.st.com/resource/en/errata_sheet/es0204-stm32f303xbc-device-errata-stmicroelectronics.pdfA google on chip whisperer glitch attack finds a ton of stuff...

author: darkspr1te
author_rank: Frequent Contributor
timestamp: August 08, 2024, 03:26:49 pm
content: The SRAM attack with vcc glitch is you load code into sram then reset the device and then a timed glitch of power and sudden change to BOOT1 pin will cause the device to run SRAM code but ignore RDP2 status , another user mentioned he had also done the same but instead his SRAM code used code already on the flash to read out but i have not personally tried this method as it requires cold boot stepping and a lot of guessing to figure out the UART code on flash (if it even has it). i cannot actually remember the exact model of the F3x i did as it was a long time back, some OBD device that emulated SLCAN belonging to a client.Also any device that used STM DFU code be it in hardware support or added via software will fall to the USB request buffer over flow as the way the code works is it read flash first then checks to see if RDP if greater than zero which means that data is in RAM and can be read via a debugger, if you patch libusb then you can in fact read the entire flash via DFU_DUMP which uses the first valid read option and request a large amount of data which causes DFU to just keep reading and dumping to uartthe DFU has been fixed in newer chips but too many companies using the software DFU option are still using old buggy stm code and this goes for GD & CS devices too, any of their chips with soft DFU support can be dumped this way.for a really good video on it too is this

author: peter-h
author_rank: Super Contributor
timestamp: August 08, 2024, 04:20:10 pm
content: Great video, but surely it is easy to design a CPU which is immune to this particular attack.Anyway, back to the 32F4... nothing found yet on hacking that one.

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: August 08, 2024, 06:21:20 pm
content: Found this:https://jerinsunny.github.io/stm32_vglitch/Well, RDP1, but I found that to be interesting.

author: peter-h
author_rank: Super Contributor
timestamp: August 08, 2024, 06:44:21 pm
content: This attack is pretty easy. But as you say L1, not L2, was set. I reckon they failed with L2 otherwise they would have reported it.I can't see the point in L1. Is there any?It sounds like they used this boot loader featureYou can't delete the ST boot loader or replace with a custom one, so the attacker just needs to set the BOOT0/BOOT1 pins to jump to this boot loader.The simplest way to piss him off is to use a BGA package and make the BOOT0/BOOT1 connections on inner layers. That will waste, what, a day?But then you have made a rod for your own back if you need to troubleshoot something.Actually there is a whole "tamper-proof" industry out there, with stuff encapsulated in resin or even glass, with embedded wire wound around it, and breaking the wire wipes the data inside. Every ATM contains such a module, AIUI. It is done because fundamentally you cannot trust even the most modern smartcard chips, with some things. But that's a big hassle.

author: rbe
author_rank: Contributor
timestamp: August 14, 2024, 04:47:13 pm
content: This topic is quite relevant to me as well, and I have some concerns regarding the potential risks of not read/write protecting the flash memory on MCUs like the STM32F0 or STM32G0 series. Specifically, if another user were to connect a debugger and download the flash contents using STM32CubeProgrammer, what could realistically be deciphered from the extracted .bin file, especially if the firmware is relatively complex?My bigger concern is whether this person could generate a usable HEX file that could be later uploaded to another MCU by accessing all the option and other registers through STM32CubeProgrammer. While downloading the flash contents provides access to some data, it doesn't include RAM information or dynamic execution context, so the extracted flash content alone shouldn't offer a complete understanding of the code's behavior. Is that correct?

author: peter-h
author_rank: Super Contributor
timestamp: August 14, 2024, 05:20:36 pm
content: Extracted FLASH is the product's entire code, normally, but any factory-input data held on another chip (e.g. serial numbers) obviously won't be obtained that way.As regards disassembly, it's a long time since I did that, but clearly lots of people do it today, otherwise you would not get cracked versions of high value retail software which was presumably written in MS VC++ and whose executables are a few MB. But then one doesn't disassemble the whole program - only the license checking code.It depends on who the enemy is. If it is just copying your product then you can do strategy 1, if it is reverse engineering a complex function, strategy 2, if it is crypto key extraction, strategy 3.

author: uer166
author_rank: Super Contributor
timestamp: August 14, 2024, 05:24:11 pm
content: Quote from: rbe on August 14, 2024, 04:47:13 pmUnless you're loading stuff into RAM from another data source that is not flash (e.g. from internet), then dumping flash and running code on another MCU will provide all info needed to reverse engineer the application. To be frank: if you're using a STM32G0 or similar chip, you're not making a nuclear reactor, worry about your thing working and not about someone dumping the flash, it's never as valuable as you might think.

author: rbe
author_rank: Contributor
timestamp: August 14, 2024, 05:59:53 pm
content: You're not wrong folks, the application itself might not be significant on a large scale. However, there are specific control algorithms in this power supply unit (PSU) firmware that I would be concerned about if they fell into other people hands.I sincerely apologize if my concerns seem off-topic, but I thought it would be a great opportunity to bring them up here.In fact, I would appreciate some advice on a related issue I'm currently dealing with. The company I work for is planning a business model that involves using a third-party gang programmer to limit and track the number of firmware flashes that our customers perform. This would allow to charge our customers based on the amount of flashes were performed. Additionally, customers would have the option to flash a specific memory section with a .bin file containing firmware parameters. The simplest approach would be to allow the customer to connect to the MCU via SWD and use STM32CubeProgrammer to upload these contents. However, without flash protection, they could easily download the entire flash contents to their local drive. Not only that, but they would also have access to all option bytes and other critical settings. This is a scenario I'm not comfortable with, so I'm seeking insights from industry experts on potential solutions or alternative approaches.I’m aware of the level 1 and level 2 RDP. However, I noticed that with RDP Level 1 enabled, I couldn't write to flash memory. I only tested this briefly and plan to investigate further.Just so I understand this correctly, is it possible for the other party, if no flash protection is in place, to download the entire flash memory content and generate a HEX file that essentially reconstructs the entire program? This could potentially allow customers to bypass the flash counter and abuse the system.Much appreciated in advance!

author: dietert1
author_rank: Super Contributor
timestamp: August 14, 2024, 06:06:39 pm
content: The RTC persistent memory may be useful to implement a protection scheme involving the device unique id. There are so many ways to confuse an attacker, like taking advantage of otherwise unused peripherals, e.g. some timer that "traps" while debugging. Nobody distributes a software product without any protection. Of course the effort depends. Invent something of your own and get it checked by people you can trust. A little obscurity doesn't hurt.Regards, Dieter

author: peter-h
author_rank: Super Contributor
timestamp: August 14, 2024, 06:25:34 pm
content: Yes if you allow customers to upload executable code then you have no security - except through obscurity.You could have an interface whereby you have a USB MSC (removable storage device) profile and people can drop files into that. Then your code can validate those files in some way. My product does exactly that. It also has an HTTP server which presents a view of the filesystem and that is another way but USB is a lot less work (FatFS and the ST USB MSC code). Other ways would be a PC app which interacts with your box over a serial port and uploads the modules but that is more work and you have to maintain a windows application on top! And laptops don't have serial ports anymore, etc, etc.Even if you have set RDP2, your code can still program the CPU FLASH. This is how you can do secure firmware upgrades. The upgrade is encrypted and/or has a hash on the end, and the decryption key is stored in the CPU FLASH which in theory cannot be read under RDP2.The problem is that, as the above cracking examples show, probably not a single industrial-level uC is secure from the VCC pulsing attack. And every box you sell will contain the key, the attacker needs to just get hold of one, and then the entire installed base is vulnerable. Just like DVDs all became wide open once the mpeg keys were extracted from a copy of PowerDVD...However, depends on who the customers are. If they are big firms they are very unlikely to do hacking, in case somebody on the inside spills the beans on them. Big firms today also almost never touch bootleg software. But smaller users may well have a go. That is my experience across 40+ years. I used to sell to banks, utilities, etc and they would not touch it, but small businesses, especially ones run by people from, shall we say, the Indian subcontinent, frequently had a go at disassembly, sometimes complaining to me that I made it hardToday, the chinese will attack anything that is worth attacking, and copy it.Yes timers have been used since the 1970s to break single-stepping but the ST chips have an option to pause timers when single stepping.All the modern uCs have a unique CPU ID and it would be normal to duplicate that in another EEPROM type device on the board. Disassembly will find it but you can bury it deep.There is an endless list of obscurity methods. In the 1970s and 80s, Z80 days, people used to execute the copyright message. ASCII letters were mostly reg-reg moves and you could rig it that if the copyright message was edited out, it would crash, etc. But asm was also very easy to unravel. C is much harder.If you have a very high value algorithm then you can run it on a modern smartcard chip, which is supposedly immune to these attacks. They have a serial port and you can interface it to a uC easily. I did such a design many years ago. The smartcard chip contained fast RSA hardware, secure key storage, and it had an 8051 for housekeeping. I don't know the state of the art now.People also use Xilinx RAM-based FPGAs for protecting designs.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 14, 2024, 06:29:50 pm
content: Remember that whenever someone publishes an attack, at least 10 others discovered it months or years earlier.Given the track record of large part of STM32 microcontrollers having published attack vectors against their flash protections within short time (often less than a year), it's a good initial assumption to consider any locking to have no effect whatsoever, i.e., any firmware you write will be readable by anyone who really wants to do it, investing some possibly trivial amount of money and time (some thousands of $, some weeks) into the process. So no FBI/NSA scale stuff.Locking is therefore only useful to slow down total hobbyists from looking at the project. Not that they would probably be interested in disassembling some machine code anyway.QuoteI do. Our products do not use any flash locking, obfuscation, or self-invented encryption (which would be then decrypted into RAM/FLASH for running anyway) because I consider it fully false sense of security. We do our best to develop safe firmware using well known good data security practices, and we also believe thatsecurity by obscurity(what you are kinda implicitly suggesting) is such colossally useless tactic that it's not worth any time.But I do realize that some manager type people prefer to use proven-useless techniques, even if they understand they are such, as a proof ofintent(in a non-technical sense). I understand the rationale, but the problem is the opinionated nature of this: for some others (e.g. myself), proven-useless techniques show thewrong type of intent, intention to believe in false sense of security and cargo cult engineering, both very negative aspects. I do realize however that some people see it in the opposite way, and think that superficial cargo cult engineering is pretty neutral and wastes only a small amount of time and does not prevent proper engineering from happening.And maybe enabling the lock bits is just that. Nobody got fired by setting the lock bits. Not that it prevents copying, examining or reverse-engineering the firmware in any way at all, but hey, you did set the lock bits. And setting them takes only seconds.

author: peter-h
author_rank: Super Contributor
timestamp: August 14, 2024, 06:41:21 pm
content: QuoteBut, often, that is all that's needed. I know (circumstantially) that grinding off some chip markings pisses off most casual ripoff artists. Not on a CPU but on smaller chips. Copying is a huge vast business so a lot of copying is not done by really smart people. Just look at my other thread about fake H8/323 chips; they invested ~5 digits in a chip packaging and marking line but even got the markings wrong!Setting RDP2 will piss off a lot of people.QuoteWhat are those? I've never heard of such a thing, if the CPU FLASH is wide open.And at the upper end, say banking comms security products (used to do a bit of that too) people use physical tamper-proofing. They don't trust any smartcard chip.

author: dietert1
author_rank: Super Contributor
timestamp: August 14, 2024, 08:13:33 pm
content: Yes, a photo sensor can be a pretty innocent looking anti-tampering device. I mean if you have a board with some 200 or more components. Once more a hurdle that can be overcome, e.g. by analyzing more than one device, yet that's what people use. Multiple hurdles can make an attacker go somewhere else.Regards, Dieter

author: peter-h
author_rank: Super Contributor
timestamp: August 14, 2024, 08:18:30 pm
content: Widely used in banking comms, way back. A funny case where one box kept getting wiped overnight; a security guard shone a torch at the LCDThey had keys in battery backed CMOS SRAMs and wiped these upon various tamper triggers.IIRC, an LED can be used to measure light too.

author: jnk0le
author_rank: Regular Contributor
timestamp: August 14, 2024, 09:30:56 pm
content: Quote from: peter-h on August 07, 2024, 10:04:43 amThis 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.Not even talking about timming attacks as many of those libraries really like to put T tables in flash memory (8x128b cached lines on F4), or somewhere else behind cache

author: peter-h
author_rank: Super Contributor
timestamp: August 14, 2024, 10:19:07 pm
content: QuoteCan you supply more detail?AES is AES. TinyAES is merely a slow version which generates the tables on the fly, so it is 900 bytes in size and does 100kbytes/sec (AES256) compared with a more usual AES256 (like you get in e.g. MbedTLS, which AFAIK is a commonly used bit of code) which is 4026 bytes in size and does 800kbytes/sec (my measurements, 168MHz 32F417).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...QuoteThe 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. FWIW for the purpose discussed, tinyAES is fine and the low speed doesn't matter. Software AES is better anyway because you can then use the chinese copies of the 32F407. I am using hw aes in MbedTLS though because that runs over 100mbps ETH so can be doing 1MB/sec (a poorly optimised but reliable ETH implementation).QuoteHow would chipwhisperer crack AES, if you arenotinside 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.

author: jnk0le
author_rank: Regular Contributor
timestamp: August 15, 2024, 12:22:44 am
content: Quote from: peter-h on August 14, 2024, 10:19:07 pmthis is the one with 50CPA claimhttps://webthesis.biblio.polito.it/secure/26870/1/tesi.pdfQuote from: peter-h on August 14, 2024, 10:19:07 pmIn 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)Quote from: peter-h on August 14, 2024, 10:19:07 pmRDP2 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)

author: Siwastaja
author_rank: Super Contributor
timestamp: August 15, 2024, 06:43:01 am
content: Quote from: peter-h on August 14, 2024, 06:41:21 pmI 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 programiswide 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 withfull, 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.

author: dietert1
author_rank: Super Contributor
timestamp: August 15, 2024, 07:02:09 am
content: 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

author: peter-h
author_rank: Super Contributor
timestamp: August 15, 2024, 07:21:39 am
content: QuoteThat'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:whogets 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.QuoteThat 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 15, 2024, 08:01:26 am
content: Quote from: peter-h on August 15, 2024, 07:21:39 amWhy 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 15, 2024, 08:04:54 am
content: 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 15, 2024, 09:21:00 am
content: Quote from: peter-h on August 15, 2024, 08:04:54 amYou 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 15, 2024, 09:49:22 am
content: 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 15, 2024, 10:02:02 am
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 15, 2024, 12:37:16 pm
content: 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 athttps://github.com/mongoose-os/mbedtlswhich loads the certificates into RAM one at a time; this took a few days to implement.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 15, 2024, 02:02:22 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 15, 2024, 08:26:55 pm
content: How about if the device does not have a direct internet connection?

author: dietert1
author_rank: Super Contributor
timestamp: August 15, 2024, 10:31:01 pm
content: 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

author: Siwastaja
author_rank: Super Contributor
timestamp: August 16, 2024, 06:23:55 am
content: Quote from: peter-h on August 15, 2024, 08:26:55 pmThen 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 16, 2024, 06:46:04 am
content: QuoteThat's a really bad idea. Everybody wants an "app" for everything. Half the population would ask for an "app" for wiping their bottomBut 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.QuoteYes; see aboveThis is not a good solution for a firmware upgrade system.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 16, 2024, 07:10:46 am
content: Quote from: peter-h on August 16, 2024, 06:46:04 amI 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 acomputerandusb cableand 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.

author: dietert1
author_rank: Super Contributor
timestamp: August 16, 2024, 07:21:11 am
content: 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

author: peter-h
author_rank: Super Contributor
timestamp: August 18, 2024, 02:56:09 pm
content: 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.

author: uer166
author_rank: Super Contributor
timestamp: August 18, 2024, 05:54:49 pm
content: Quote from: peter-h on August 18, 2024, 02:56:09 pmOne (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.

author: jnk0le
author_rank: Regular Contributor
timestamp: August 18, 2024, 06:52:53 pm
content: Quote from: dietert1 on August 15, 2024, 07:02:09 amDMA 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.pdfIt's just a matter of how rich is your adversary.

author: peter-h
author_rank: Super Contributor
timestamp: August 18, 2024, 07:25:42 pm
content: 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.QuoteYes 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.

author: tellurium
author_rank: Frequent Contributor
timestamp: August 19, 2024, 06:53:51 am
content: Quote from: peter-h on August 15, 2024, 12:37:16 pmThat's when crypto elements can be used. For example, Microchip'shttps://www.microchip.com/en-us/product/atecc608aor ST'shttps://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

author: dietert1
author_rank: Super Contributor
timestamp: August 19, 2024, 07:30:51 am
content: Due to risk of backdoor i would not try to secure a ST micro adding a ST crypto element. Better combine with other brand.

author: peter-h
author_rank: Super Contributor
timestamp: August 19, 2024, 07:39:06 am
content: 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 chipwith 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).

author: dietert1
author_rank: Super Contributor
timestamp: August 19, 2024, 08:18:29 am
content: It would be ATECC608Bor ATECC608Cnow. Have a look at the datasheet. NDA may be necessary. An example of the one-wire device i mentioned above.

author: peter-h
author_rank: Super Contributor
timestamp: August 19, 2024, 11:10:12 am
content: Like I said aboveHere you go:https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-Defeating-A-Secure-Element-With-Multiple-Laser-Fault-Injections.pdfYou 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...

author: dietert1
author_rank: Super Contributor
timestamp: August 19, 2024, 11:59:26 am
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 19, 2024, 12:45:29 pm
content: 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 unbreakablebut- 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).

author: Siwastaja
author_rank: Super Contributor
timestamp: August 19, 2024, 04:03:18 pm
content: Quote from: dietert1 on August 19, 2024, 11:59:26 amOf 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 toanother customer'sbox which they haveno 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 19, 2024, 08:27:21 pm
content: 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.

author: dietert1
author_rank: Super Contributor
timestamp: August 20, 2024, 05:07:47 am
content: 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 managerThe 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 20, 2024, 05:24:25 am
content: QuoteMaybe 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 anysignificantamount

author: peter-h
author_rank: Super Contributor
timestamp: August 20, 2024, 07:09:04 am
content: 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.

author: dietert1
author_rank: Super Contributor
timestamp: August 20, 2024, 07:21:00 am
content: If you want to provide a link to the full ATECC608Cthat appears to be the current version i am interested. Or another video showing how to hack the current version.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 20, 2024, 07:39:03 am
content: Quote from: dietert1 on August 20, 2024, 07:21:00 amYou 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 ATECC608Cdatasheet, 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.

author: dietert1
author_rank: Super Contributor
timestamp: August 20, 2024, 08:47:29 am
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 20, 2024, 09:29:52 am
content: QuoteNot me. No need to get personal.But I know you like thatI fully expect the cracking of these chips to be harder than RDP2 on 32F4 but a much more interesting challengeIf 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 pointI 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.

author: dietert1
author_rank: Super Contributor
timestamp: August 20, 2024, 10:16:53 am
content: Just found this:https://forum.digikey.com/t/atecc608-node-authentication-example-walk-through/13141andhttps://www.microchip.com/en-us/product/atecc608c-tflxtlsThere they have a migration guide for revision B to revision CRegards, Dieter

author: peter-h
author_rank: Super Contributor
timestamp: August 20, 2024, 11:34:43 am
content: Dieter - are you using these chips and, if so, why?

author: tellurium
author_rank: Frequent Contributor
timestamp: August 20, 2024, 02:25:13 pm
content: Quote from: peter-h on August 20, 2024, 09:29:52 amATECC (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?

author: dietert1
author_rank: Super Contributor
timestamp: August 20, 2024, 02:31:39 pm
content: 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

author: peter-h
author_rank: Super Contributor
timestamp: August 20, 2024, 02:37:23 pm
content: QuoteI 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 workNow why would a server do RSA and not EC?Lots of reasons, like the sysadmin charging $1000 per half day for doing anything on itIf 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 - thanksI 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 20, 2024, 06:03:57 pm
content: Quote from: tellurium on August 20, 2024, 02:25:13 pmSome people think RSA refers to aconcept, 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 20, 2024, 08:17:21 pm
content: 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.pdfI 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 23, 2024, 02:11:34 pm
content: 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:HAL_FLASH_Unlock(); // Unlock the flash memoryHAL_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

author: dietert1
author_rank: Super Contributor
timestamp: August 23, 2024, 03:50:00 pm
content: 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

author: peter-h
author_rank: Super Contributor
timestamp: August 23, 2024, 05:55:46 pm
content: 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 boardso I haven't tested this yet with the if statement around it, but the required code looks like thisCode:if (FLASH_OB_GetRDP() != OB_RDP_LEVEL_2){HAL_FLASH_Unlock(); // Unlock the flash memoryHAL_FLASH_OB_Unlock(); // Unlock the option bytes*(__IO uint8_t*) OPTCR_BYTE1_ADDRESS = OB_RDP_LEVEL_2; // Set RDP2HAL_FLASH_OB_Launch(); // Activate itHAL_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?

author: peter-h
author_rank: Super Contributor
timestamp: August 26, 2024, 07:46:13 am
content: 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 RDP2HAL_FLASH_OB_Launch(); // Activate itHAL_FLASH_OB_Lock();}There is every possible other version of this on the internetThe 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.

author: peter-h
author_rank: Super Contributor
timestamp: September 11, 2024, 12:57:14 pm
content: Came across this "zero-content" ST paperhttps://www.st.com/resource/en/technical_note/dm01011952-.pdfI can confirm above code works and the lineCode:uint8_t level = *(__IO uint8_t*) OPTCR_BYTE1_ADDRESS;works for reading out the current value: 0xaa for no security and 0xcc for RDP2.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 11, 2024, 02:24:44 pm
content: Quote from: peter-h on September 11, 2024, 12:57:14 pmYeah, you need to officially state obvious stuff like that for managers and possibly lawyers.

author: peter-h
author_rank: Super Contributor
timestamp: August 05, 2025, 11:21:40 am
content: This data point is interestinghttps://community.st.com/t5/stm32-mcus-security/readout-protection-cracked-on-stm32/m-p/388031/highlight/true#M5102I posted this because this link is very widely postedhttps://www.aisec.fraunhofer.de/en/FirmwareProtection.htmlAnd this is the RDP1 hackhttps://jerinsunny.github.io/stm32_vglitch/Nobody should use RDP1, and really there is no reason to, unless you want to preserve the option of re-flashing products which have come back from the field. If you set RDP2 then you have to unsolder the CPU...

author: peter-h
author_rank: Super Contributor
timestamp: August 31, 2025, 01:03:33 pm
content: Somebody found a hack for RDP1 for 32F103https://www.eevblog.com/forum/microcontrollers/dumping-stm32-protected-firmware/

author: roboknight
author_rank: Newbie
timestamp: October 06, 2025, 11:17:30 pm
content: DONGLES! That takes me back. Yeah MSP430s take a bit of doing. STM32Fxxx not quite as much. Nice prototype at any rate.

author: roboknight
author_rank: Newbie
timestamp: October 06, 2025, 11:25:39 pm
content: Yeah, there are a few ways to do the F103. But as someone pointed out a long while back, using RDP isn't much of a defense. I've been able to get by several of the STM line RDP2, the only real issue was the SPRMOD bit in models like the F427. The flash controller, or maybe even the flash storing that bit, was often effected by glitching. At any rate, with many of their chips RDP1=RDP0 so once you get by RDP2, its game over.

author: peter-h
author_rank: Super Contributor
timestamp: October 07, 2025, 11:29:56 am
content: Have you cracked RDP2 on a 32F4xx?