32F417: can SWD be blocked by internal software?

[peter-h]

The last post here
https://www.eevblog.com/forum/microcontrollers/32f417-security-question-(disabling-swd-etc)/
wasn't answered because the poster making that suggestion didn't come back.

I don't think it is possible because a debugger does a Reset, and starts off by releasing the Reset, so your code doesn't get a chance to run at all if you set a breakpoint at the very start. And upon hitting any breakpoint the debugger has total memory space access.

[langwadt]

and you can use the boot pin to start the bootloader

[nctnico]

It should be possible by setting the read protection byte to the right value. Before anything else, the STM32 controllers run an internal bootloader to do some initial setup.

[peter-h]

I would quite like to block SWD access, because I have a really robust and fairly secure route for loading in signed/encrypted firmware via USB, or an HTTP server. But as I put in the other thread I don't want to set Level 2 security because you cannot reverse that.

Being able to bugger up SWD somehow, while preserving the ability to reverse it by loading new firmware via the above routes, would be nice.

I am sure others have been up this road because Level 2 is a big commercial liability. You need to have total confidence in your firmware, or at least total confidence in the boot loader process for uploading new firmware. Especially if selling to large companies who tend to enjoy screwing small suppliers and who will happily force you to scrap an entire build of a few k units.

There are hacks for a lot of these chips although the ones I have found were for the older F1xx ones, not the F4xx ones. Still, nothing is as easy as connecting an STLINK to a board, and blocking that is worth doing.

[ataradov]

You want contradicting things. L2 security is designed to disable SWD. But you say that you may want to have SWD back in some cases. This means you should not disable SWD.

You say that you have a robust bootloader, so sounds like "total confidence in your firmware" is not an issue.

[peter-h]

Nobody can be 100% sure; the commercial risk (dead stock, etc) remains. Large-customer balance of power issues are bad enough to bankrupt a small company.

I wonder why they made SWD disabling non-reversible.

Especially as all these chips seem to be hackable using the method of a very short reset just as they read the security fuses.

Anyway, am I right there is no way to achieve the subject - because a debugger does NRST=0 which resets the AF mapping, and prevents software access to the BOOTx pins?

[ataradov]

If it were reversible, then what would be the point? Anyone can reverse it then.

No, without completely locking the device it is impossible. Debugger can always intercept whatever firmware is doing. The only way to disable SWD is to prevent it being enabled in a first place though L2.

On more recent generation of devices there are more advanced features to control that. SAM L11, for example has a key you program before locking and the chip erase is only possible once you provide the key. Otherwise device is locked with no way to unlock it. But this is a relatively modern invention. I expect it to propagate to more devices in the future. And we need to see how this holds up to attacks, of course.

[peter-h]

If it were reversible, then what would be the point? Anyone can reverse it then.

Depends on what other protections can be selected, and whether they actually work. None of these do actually work, including Level 2.

But anyway, my Q has been answered. Thank you all

[eutectique]

If it were reversible, then what would be the point? Anyone can reverse it then.

SAMV70 has security bit which, when enabled, disables access to ETM and hence to SWD and internal flash. The bit can be reversed by asserting ERASE pin, which is very convenient.

On more recent generation of devices there are more advanced features to control that. SAM L11, for example has a key you program before locking and the chip erase is only possible once you provide the key. Otherwise device is locked with no way to unlock it. But this is a relatively modern invention. I expect it to propagate to more devices in the future. And we need to see how this holds up to attacks, of course.

Automotive Freescale/NXP MPC5674F has this feature for quite some time. Censorship password is 64 bits long, so brute force would hardly be practical. The problem though could be the single password used for all the items of the same product. Once cracked, it will open 'em all.

[ataradov]

SAMV70 has security bit which, when enabled, disables access to ETM and hence to SWD and internal flash. The bit can be reversed by asserting ERASE pin, which is very convenient.

Yes, but that's equivalent to RDP level 1 in STM32. Sure, SWD interface remains enabled, but you can't do anything via it other than erase. This is actually far better than a dedicated erase pin.

Once cracked, it will open 'em all.

Sure, but it is on you to make sure that codes are unique. Device vendors can only do so much to help you.

In this case power glitching attacks become more viable. No point in cracking the lock bits if you can make your firmware to dump itself on an external port.

[peter-h]

that's equivalent to RDP level 1 in STM32. Sure, SWD interface remains enabled, but you can't do anything via it other than erase

I didn't realise this. So on the 32F417 one can disable SWD for the purpose of examining memory, and it is reversible by internal software?

The bit can be reversed by asserting ERASE pin, which is very convenient.

Yes - can save you scrapping a load of boards. Manually replacing a QFP-100 is quite a job. Done that sort of thing hundreds of times

[ataradov]

I didn't realise this. So on the 32F417 one can disable SWD for the purpose of examining memory, and it is reversible by internal software?

Yes. You don't disable SWD, but you disable debug port access to the memory to ensure firmware security. And MCU without that would not make it far on the market.

But it is not reversible without chip erase. So, internal software may trigger the process, but it would also be erased in the process.

[wek]

I didn't realise this.

The exact effects of RDP settings including Level1 are clearly described in RM0090, in FLASH chapter's subchapter aptly named Read protection (RDP).

As decreasing RDP level from 1 to 0 implies mass erase, the only practical way to utilize this (except "suicide") is to run the recovery software (bootloader) *entirely* from RAM.

JW

[peter-h]

OK, but you can trigger a software feature which starts the mass erase, doesn't need to run throughout the erase process, and then you can load new firmware via SWD, presumably.

This avoids scrapping the board.

You just need a rock solid means of triggering the mass erase (L1 to L0) "suicide feature"

I should read the RM but I find this quite confusing, and background knowledge is very useful.

[ataradov]

With RDP1 you can just erase the device via SWD, you don't need software for that. And it is as rock solid as it gets.

[abyrvalg]

A whole bunch of easy-to-do-at-home attacks abuses side effects of this “nice” idea of blocking just the flash access and leaving SWD working for other “useful” things (observable CPU regs on nRF51, flash “firewall” race condition on older ST M0s, forced exceptions leaking vector table contents on ST M3s, DMA attack on GD32 etc), not mentioning the “official” ability to dump RAM (which can lead to interesting discoveries in peter-h’s case with RAM-resident bootloader). That’s just too big attack surface to control IMO.
I liked the approach of old SAM7S where setting the protection was disabling JTAG completely, leaving the only way out thru a mass erase by asserting a dedicated pin.

[ataradov]

It is always a compromise. It is absolutely possible to do it securely (as compared to a disabled interface) with just the SWD.

And the dedicated erase pin can also be abused, especially on SAM7S where it does not erase the SRAM. This was fixed on SAM V7x/S70/E70, where SRAM is also erased before the unlock happens.

[peter-h]

With RDP1 you can just erase the device via SWD, you don't need software for that. And it is as rock solid as it gets.

Ok, sorry, I forgot that. I get it now. Where is the Erase function in Cube? I can't see one - apart from an erase happening when a new program is loaded. But that erase seems to be done sector by sector. Does one need to use e.g. the Segger tool, which has a command line interface?

which can lead to interesting discoveries in peter-h’s case with RAM-resident bootloader

There is nothing secure in my boot loader. In fact I have probably already posted the source here, a while ago It took a lot of work to get it going... working out the linkfile commands for relocating the execution address, etc and then jumping to it. The boot loader can call functions in the CPU FLASH, which presumably cannot be examined via SWD.

A whole bunch of easy-to-do-at-home attacks abuses side effects of this “nice” idea of blocking just the flash access and leaving SWD working for other “useful” things

I like the one on the chinese "32F407" which uses a separate FLASH chip next to the CPU. You remove enough resin to expose four bonding wires between the two chips, and read out the code at startup

[ataradov]

Where is the Erase function in Cube?

No idea, never used it. I assume it is just on the part where you set RDP level in a first place. The erase is not a separate function, it is just a side effect of changing RDP 1 -> 0.

I like the one on the chinese "32F407" which uses a separate FLASH chip next to the CPU. You remove enough resin to expose four bonding wires between the two chips, and read out the code at startup

This is much harder than it sounds, since you need access to the micro-probing equipment.

It is also more than 4 wires. And you can't really probe the bonging wires, you need to get access to the die pads. And as was mentioned, on those devices there are other exploits in RDP1. With RDP2 extracting the die may be a good option, but not trivial.

Although it looks like some attacks do use bonding wires.  It still does not look easy, especially given other holes in those devices.

And of course, all of those things are vulnerable to power glitching attacks during the protection bit readout. And ST is not the worst here, as you need to spoof all 8 bits to unlock the device. But lowering RDP2->RDP1 is much easier. It does not buy you much as far as firmware extraction goes. May be if combined with other exploits.

[peter-h]

This https://stm32world.com/wiki/STM32_Read_Out_Protection_(RDP)
shows an "stm32 cube programmer". Never seen that before It is indeed a whole separate app, perhaps suitable for production programming.
https://www.st.com/en/development-tools/stm32cubeprog.html

And ST is not the worst here, as you need to spoof all 8 bits to unlock the device.

How is that done? I didn't find this bit.

since you need access to the micro-probing equipment.

Sure, but that's a lot easier than decapsulating and scanning the FLASH, which is apparently possible.

[AndyBeez]

Stepping back, what is the attack surface you are concerned with? Physical security maybe enough; ball arrays with the uC preflashed before placing and no PCB tracks to the SWD lines. This frustrates casual hackers but  otherwise, if you ard building a crypto wallet of a voting machine for examples, how about using a microcontroller designed for secure/banking applications? Such as the ST31H family. Decapping would be pointless. I know that's an dxpensive redesign, but what level of security are you designing too?

[peter-h]

Good Q.

I am just trying to do a reasonable level of diligence - it is debatable what that may be. The reason is this: this product may be sold to someone who does a bit of code for it (the dev kit will be free) and sells it on. Sometimes for 20x the price and that creates an incentive for the person paying that price to get the custom program out, while buying the 1/20th-priced one from me directly.

I've been in this business for over 30 years... I did some products, a long time ago and vastly less powerful than this 32F417 one, where the only protection was to prevent somebody doing the most obvious thing: unsoldering and duplicating the TSOP-28 28C256 EEPROM storing the custom program. That was sufficient, because the next step would have been extensive disassembly. Maybe somebody did it (many thousands were sold back then, often to users who never contacted us) but I doubt it. With this new box, I want to do a bit more, especially as firmware updates may be deployed online, and there is a limit on how secure that can be. My box would start up an HTTP/S client and call up a private server to grab whatever file it is entitled to, based on its serial number or whatever, and flash it.

This isn't a crypto wallet or anything like that. I was sort of involved with that stuff many years ago (google Siemens 44C200 - I still have a whole reel of them) so I know the issues there. Smartcard chips were always attacked and usually successfully. I also started on a product using the Capstone chip, which died an early death.
https://en.wikipedia.org/wiki/Capstone_(cryptography)
Today's smartcard chips are probably pretty good but the idea of a chip holding cash has been pretty well killed, due to the potential for tax evasion.

Unless the CPU security is good enough, a smartcard is the only way but it is another thing to pay for and not worth it in this case.

[AndyBeez]

Nice to see you are doing due diligence by design.

There are secure elements that can protect microcontroller deployments: often secure 'S'EEPROMs used as AES key stores. Offering crypto authentication and code encryption would be a big plus to your value added customers, maybe?

I'm sure there are experts here who deal with this stuff every day

I2C example: https://www.maximintegrated.com/en/products/embedded-security/secure-authenticators/DS28C22.html

[peter-h]

I think you would need a chip which both

- holds the key, and
- does the crypto internally

Short of that, all you are getting is half the job. The proper solutions still require a physically tamper-proof design (encapsulation, various features to detect tempering, self-erase if attempted, etc). BTW I think most people are designing-out anything from Maxim

For what I am doing, it isn't needed. I just need to piss somebody off for a few days. I am not going to discuss what I am doing in detail but you certainly won't be able to disassemble any OTA update. Unfortunately somebody who is very clever can probably crack a 32F4 in minutes and get the FLASH out, with the right equipment. They will need much more time to work out other aspects of the product, however.

Many years ago, in the days of Z80 etc and EPROMs, I used to jumble up the address and data lines I had a utility written which jumbled them in reverse for the EPROM programmer. One customer, the usual kind of wide-boy opportunist chancer from a certain country, who used to run the corporate IT business in London in the 1980s, told me he spent days on trying to work out why my EPROMs disassembled to junk and eventually gave up, believing they were "encrypted"

One can also use security selectively. When a new product comes out, the first orders tend to be from competitors, and will never be actually deployed. So you can set Level 2 on those Same on anything going out to China, etc.

[darkspr1te]

I think you would need a chip which both

- holds the key, and
- does the crypto internally

Short of that, all you are getting is half the job. The proper solutions still require a physically tamper-proof design (encapsulation, various features to detect tempering, self-erase if attempted, etc). BTW I think most people are designing-out anything from Maxim

For what I am doing, it isn't needed. I just need to piss somebody off for a few days. I am not going to discuss what I am doing in detail but you certainly won't be able to disassemble any OTA update. Unfortunately somebody who is very clever can probably crack a 32F4 in minutes and get the FLASH out, with the right equipment. They will need much more time to work out other aspects of the product, however.

Many years ago, in the days of Z80 etc and EPROMs, I used to jumble up the address and data lines I had a utility written which jumbled them in reverse for the EPROM programmer. One customer, the usual kind of wide-boy opportunist chancer from a certain country, who used to run the corporate IT business in London in the 1980s, told me he spent days on trying to work out why my EPROMs disassembled to junk and eventually gave up, believing they were "encrypted"

One can also use security selectively. When a new product comes out, the first orders tend to be from competitors, and will never be actually deployed. So you can set Level 2 on those Same on anything going out to China, etc.

If you want to piss someone off in the design then here are a few tricks
1. epoxy the the vpu caps by the xtal pins
2. put half the key in the rtc and the other half in the irq vectors that match 10-13 (old sega trick )
3. crc any update packets
4. randomly set and unset debug pins (even in debug mode you can set the pins and cause issues)
5. build into the design finger prints that can be checked by software (a trick used by DELPHI OBD2 boxes ) , separate the checks into single lines across many normal routines using multiple vars and add in one based on a timer (they dont show up in calls often) to mix it up
6. dont use standard libs in the boot loader (eg cube mx)
7. use the debug pins in the main stay of the design to further hamper step by step.
8.control the source of updates and have version checking routines different to your crc routines.
9. ensure keys are FLASH marked and not loaded into ram
10.use a key cycle system between versions
11. spread keys across multiple locations a in between mundane checks
12. learn the compilers issues when the design switches between various settings eg debug/O1,O2 etc , some speed ups will overide prior "keep in flash" options.
14. confuse the reverse engineer by using strange stepping



darkspr1te