Harvard Architecture MCU requiring physical access to program

[gilsho]

I want to pick a microcontroller for my next project. Generally I want it to be as powerful as possible / have more resources. I am less sensitive to power, peripherals and I/O. It can even be a microprocessor or a full fledged CPU. I do care very much about information security though. In light of that I want a Harvard Architecture that will keep program and data memory separate. I would also like the microcontroller not to have the ability to programmatically write to program memory. I've been looking at PIC microcontrollers and most of the ones I looked at have boot loaders which implies the ability to write to program memory programmatically.

Are there any microcontrollers out there that fit the bill? i.e Harvard Architecture that requires physical access and/or a separate hardware interface in order to program?

 

[KlausST]

Hi,

I´d say all harvard microcontrollers I know have bootloader functionallity or "write to program ability".
A bootloader can write to code section. But it´s on you whether to install a bootloader or not.
So: no bootloader installed --> no programmability via bootloader
Besdies the botloader it depends on your software wheter it is able to write to the code section or not.

And most microcontrollers do have separate (from bootloader) security features.
If you set them properly then it doesn´t matter whether there is a bootloader installed or not .. it will prevent access to your code. Write protection, read protection, often section wise.

I have good experience with ATMEL/MICROCHIP AVR microcontrollers in this. Other microcontrollers will have comparable features.

And: it´s said that every code can be read out with enough effort.

Klaus

 

[gilsho]

Thank you Klaus for pointing out that I can do without a boot loader. That's likely the approach I am going to take. An even stronger guarantee would be an instruction set that doesn't even contain an instruction for writing to program memory. But from your response I take it that might be asking for too much.

FWIW I'm not concerned about the code being read out so much that it will be overwritten. The application will need to handle network data so I'm concerned that an attacker might find a remote code execution vulnerability and use it to overwrite the program memory. If that capability is missing then I can guarantee that after a hard restart the original software will be restored.

Perhaps I can make the claim that if the program memory doesn't contain a "write to program memory" instruction anywhere, and that in Harvard Architecture all executed instructions must originate from program memory, then it should be impossible for a network attacker to overwrite it?

 

[KlausST]

Hi,

Perhaps I can make the claim that if the program memory doesn't contain a "write to program memory" instruction anywhere, and that in Harvard Architecture all executed instructions must originate from program memory, then it should be impossible for a network attacker to overwrite it?

Yes. (Speaking for AVRs with properly set security fuses)
It´s totally different to a PC with van Neumann hardware, where you may uplode a "fake picture" into RAM that indeed contains executable code and with any code exception (and the help of an Operating System) are able to run this code.

With AVRs you can´t execute code at SRAM.
You already need code in your code section that is able to write code.
With AVRs there is an application section and a bootloader section.
With AVRs you can disable that application code can modify application code.
and .. before you can "write" code into the flash memory it needs to be "erased" first.

So I think it´s rather difficult for an internet attack to acces code Flash if you don´t want to.

We´ve built our own secure bootloader for AVRs. We are able to update our applications via internet. But for this we have an external memory. No direct access from application to application section.
One has to transmit crypted code to the external memory, one has to pass several security features. Then one has to hard reset the microcontroller.
Then the bootloader starts and verifies and validates the data in external memory. and only if all these matches the bootloader encryts te code from external memory and programs it into the application section.

There needs to be a good reason for a hacker to invest much time to attack your application. He needs to gain something.
And it greatly helps if he has some knowledge about your source code. Hide it.

For the very most hacker access the "door" is the OS - like Windows.... which you don´t have installed on your microcontroller.

Klaus

 

[gilsho]

I agree that it's indeed very difficult. I am aiming for impossible though. While a bit contrived, the attack highlighted in this paper demonstrates that it is theoretically possible to inject code into program memory: https://arxiv.org/abs/0901.3482. Security through obscurity is considered bad practice in the security field. Better to rely on provable security guarantees.

 

[KlausST]

Hi,

did you read this:

5.1 System assumptions
Throughout this paper, we make the following assumptions:
• The WSN under attack is composed of Micaz nodes [7].
• All nodes are identical and run the same code.
• The attacker knows the program memory content 1.
• Each node is running the same version of TinyOS and no changes were performed in the OS libraries.
• Each node is configured with a bootloader.
• Running code has at least one exploitable buffer overflow vulnerability.

*****

as already previously noted:
* hide your source code --> then the attacker does not know the code content
* don´t use a known OS --> no TinyOS with an "open door"
* don´t use a bootloader --> no "write to code" possibility at all.
* But: There is no guarantee. For no microcontroller

Klaus

 

[gilsho]

Yes, I am aware that the setup in the paper is very much contrived and that can never be any guarantees. Nevertheless your suggestions are all valid and I intend to employ them, but if I can find an instruction set that doesn't contain an instruction to write to program memory that will be preferrable.

I see that the AVR instruction set contains the "SPM" instruction to write to program memory[1]. And I also see 16-bit PIC controllers have the "TBLWTL" and "TBLWTH" instructions to write to program memory. But the wiki page for the 8-bit family doesn't contain any instructions for how to program the flash memory. And the form post in [3] suggests its not possible to do so. The wikipedia page for PIC microcontrollers [4] suggests that only newer models have the ability to reprogram themselves, so this leads me to believe that some (if not all?) of the 8-bit microcontrollers can't be programmed in this way.

[1] https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-Instruction-Set-Manual-DS40002198A.pdf
[2] https://microchipdeveloper.com/16bit:flash-write
[3] https://www.microchip.com/forums/m500879.aspx
[4] https://en.wikipedia.org/wiki/PIC_microcontrollers

 

[KlausST]

Hi,

Setting a fuse - that can't be prorammed via code - to disable the "write to Flash" isn't enough?
I't makes the "SPM" non functional, Id say it's almost the same as having no SPM instruction at all.


Klaus

 

[gilsho]

Setting a fuse to disable "write to flash" would be exactly what I was looking for! Can you please elaborate on how that can be done? Which input pins need to be fused? And which devices support this feature? I'm not familiar with this feature.

 

[KlausST]

Simple. When programming your firmware on the chip set the according fuse. (Programming feature). Programmer documentation and datasheet give more information.

Klaus

 

[betwixt]

PIC architecture has similar memory block (or entire device protection) built in.
Note that on PIC18+ series, the table read/write instructions "TBLxx" are normally used to give fast access to tables of data but if configured properly they can extend to writing program memory space. Those instructions have themselves to be located in program space so it isn't possible to use them in a security breach unless the program is written specifically to allow such use.

Brian.

 

[ftsolutions]

Ultimately *everything* is hackable, if you have physical access to the device and patience. Klaus' point about setting the security bit in the AVR is an (additional) good idea... but as it seems you do not have much experience with microcontrollers - be aware that this "fuse" is a bit which is resettable by a an ICE/programming device with access to the JTAG or SWI programming pins on the AVR. "Hiding" your code also entails denying physical access to the chip, if need by, to make it not worth the hackers effort to go in there - or more likely s/he will destroy device trying to uncover it. So, "hiding" also means physical security measures like removing ID marks on chip so no one can readily ID it, sealing it into an enclosed box, or possibly encapsulating it in epoxy if it can tolerate the thermal conditions, employing tamper-proof devices in the design, etc.

 

[KlausST]

be aware that this "fuse" is a bit which is resettable by a an ICE/programming device with access to the JTAG or SWI programming pins on the AVR.

An AVR provides several levels of code and data protection.
* You may enable/disable JTAG
* You may enable/disable OCD
* You may enable/disable ISP
...this are the interfaces.

But besides this there are the security bits. When they are set then you don't have access to the code, nor are you able to modify the security bits.
Independent whether interfaces are enabled or not...
...unless you do a complete CHIP ERASE.
You still have the option whether a CHIP ERASE clears the EEPROM data (in case there are secure informations inside) or to keep them (in case there are calibration data inside)

This gives a good level of protection. But for sure no system is 100% safe. But it will need a lot of effort.
It will not be simply "switch OFF protection via JTAG".

Klaus