C code for forcing variables into registers R0 and upwards

[anthony239955_stm1_stmicro]

Posted on March 07, 2012 at 11:03

Hi,

I would be grateful if someone could show me how, using C language or by using a line of assembler in a C program, I can force storage of a variable in a register r0 and upwards in an STM32. Even a very basic example will do. In particular, I would like to force the storage of a result from an encryption peripheral into such a register without intermediate storage elsewhere, if that is also possible.  I want to increase my code security. I've been making a study of the security features and holes in the STM32. Even if you burn out USART and JTAG, there are SEM/FIB facilities available to rent for Euro 200 an hour that can cut into a depackaged die, kill off the CPU and hijack the memory counter circuit to act as a full memory scanner, and read out the hex. I've learned a lot by posing as a pirating client seek to hire these firms!  Therefore I have a couple of good scheme in mind that I think would offer additional protection if we could make use of the in-cpu registers and avoid SRAM for key data...so any help would be most appreciated and could form the seed of higher piracy security for newbies as the discussion grows.I deeply appreciate any expertise you might be able to offer, Thanks! #r #piracy #c-code #security

[Tesla DeLorean]

Posted on March 07, 2012 at 13:30

Learn to program in assembler, even your most barely competent adversary can do this. For the most part they are better equipped and smarter than you are, do not think you can out smart them, or be more creative. This is not necessarily a commentary on your personal abilities, just the realization that you must be infallible, while the adversary only needs to land one effective punch and you're done, and he has more time and can cheat.

Use a device that actually has die-level protection against physical intrusion, and has tamper protection, place keys in self-wiping SRAM/NVRAM. Can't you see the register content with an SEM? Sure the window of visibility is tighter, but the device can be clocked slowly and a video of register file would make interesting viewing. Burning out JTAG and USART, please explain this process, and how it doesn't damage surrounding silicon, and can be achieved reliably in a production environment. How would this protect a design where the adversary has made a one-to-one copy of FLASH, etc and placed it on a new part where JTAG, TRACE and USARTs work? Calling foo(x, y, z); Will enter foo with R0=x, R1=y, R2=z When using an optimizing compiler, if you only have a few auto/local variables these will be stored in registers. Look at listing files, or disassemble it, might be instructive about how different things are coded in assembler. What tool chain are you using, in-line assembler isn't particularly portable, and not supported by all tools? ; Enable FSMC clock                          LDR R0,= 0x00000114                          LDR R1,= 0x40021014                          STR R0,[R1] ; Enable GPIOD, GPIOE, GPIOF and GPIOG clocks                          LDR R0,= 0x000001E0                          LDR R1,= 0x40021018                          STR R0,[R1] or                          LDR R0,= 0x00000114                          LDR R7,= 0x40021000                          LDR R1,= 0x000001E0                          STR R0,[R7+0x14]                          STR R1,[R7+0x18]

[anthony239955_stm1_stmicro]

Posted on March 07, 2012 at 16:32Hi,Thanks for your answer.Would you be able to recommend a more secure microcontroller or FPGA with the physical protection suggested, that hopefully also has a free toolchain? Alterra have the Cyclone III LS with CPLD, and upcoming Cyclone V, but the security features are not supported in the free toolchain. I am using Keil and Atollic at the moment. I was thinking of laying out the consumed resources in such a way as to avoid the areas subject to decay after the circuit burning proposed...but obviously you have noted a second reason why this is an insufficient solution, so involving a different micro may be the way to go.  Thanks

[anthony239955_stm1_stmicro]

Posted on March 07, 2012 at 16:33