bootloader section and interrupts

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

 

I hope that you are all and your families safe! 

 

Assuming that I have a Hash function that resides in the bootloader section (which acts as a virtual ROM without physical access), while I have the normal software running in the rest of Flash memory starting from address 0x00. Considering serial communication (for simplicity), if I have the microcontroller connected to my laptop while this laptop sends a request over serial every a couple of minutes. This request requires computing the Hash value of the entire memory to check if something is changed or not.  Now, in the current design, the request gets received by the normal software which redirects it to the Hash function in the bootloader section. My problem is that I do not want to trust this software. I would assume it contains malware. Is there a way in AVR that this request is handled by hardware first, i.e., interrupts, where the hardware would decide to whom to give this message. In other words, I suppose with each message received that there is an interrupt is fired where this interrupt should fire another interrupt that its interrupt vector routine exists in the bootloader section (considering it as a secure memory area). The task of this routine is to check this request and see the content of the message. If it contains some specific words, it would jump into the first instruction of the Hash function. Otherwise,  it would just continue the normal operation of the software. But I think this approach, if it is valid, is still not guaranteed as there is still a possibility for the untrusted software to disable interrupts using cli() function. Am I missing something? Any suggestion? hint? tip?

 

So, in short, I want a technique to ensure the availability of HASH function residing in the bootloader section in the sense that whenever I invoke it over serial communication, it responds. 

 

Many thanks!

M.A.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mammar wrote:
Am I missing something?

Any system with a boot loader is inherently insecure! 

If the boot loader can return a hash of the contents of the flash, could the hacker not retrieve this hash value, then write his/her malware to return the same value?

How does this hash protect the contents of the flash?

In addition, any system that is not protected physically is insecure.

 

Jim

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mammar wrote:

...there is still a possibility for the untrusted software to disable interrupts using cli() function...

 

Surely, if someone can compromise one part of your memory then they can compromise the other parts? The 'normal' area of flash and the bootloader section are all in the same memory array. All that makes the bootloader special is that you can change the value that gets loaded into PC at reset to change the point in flash that gets executed first. Plus there are a couple of fuses to protect different areas.

 

If you need the level of protection implied by your question then you are using the wrong chip family. The AVR is not for you.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A mildly related aside...

 

I once wrote a secure bootloader that worked a bit like the internet CHAPS. In that both ends know a secret. To validate one end puts the secret and then the data to be verified (could be code image) through a hashing function. You then send just the message text and the final hash to the other end. It starts by putting its copy of the shared secret through a hash then all the received data so that it comes up with a hash at its end. If the hash it calculates does not match the hash of the transferred data then the sending end can not have known the shared secret so cannot be trusted. In effect this is "signing" the code image to be delivered. In my case I used SHA256 and my shared secret was the first versus of the King James Bible.

 

Of course if I did this in an AVR then there is a chance the "hacker" could learn the shared secret. AVRs have lock bits but it's a poor protection that you can get broken for about $500. So the hacker could access the bootloader code, get the secret then produce his own "signed" code images.

 

However it is quite a strong protection unless it really is "commercial hackers" you are trying to protect against from delivering new firmware to your device that can take over operation (in our case this would mean circumventing a subscription payment system to re-use heavily subsidised hardware - not unlike the case with mobile phones).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW by a complete coincidence one of today's other threads was this: https://www.avrfreaks.net/forum/... If you read that it may prompt you to download the product summary datasheet (I think you can only get the full datasheet under NDA). That's a very interesting device - far more secure than the puny lockbits on an AVR - it could form the basis of some kind of code signing/encrytping scheme.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This raises a number of questions -
What is the overall aim of all these shenigans?

1. If the question is can you call a function that resides in the bootloader sector from non- bootloader code - yes you can.
2. As for your idea of interrupts etc , i’d suggest you think clearly about what you want to achieve.
3. Doing cryptographic hashes on an AVR is going to be slow.
4. How is the malware going to be injected into the AVR? Code cannot execute from ram, so anything subversive is going to have to find its way into flash. It can only get into flash via the bootloader.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
2. As for your idea of interrupts etc , i’d suggest you think clearly about what you want to achieve.
The actual question of bootloader interrupts is pretty clear (and simple) in AVR. There are TWO vector tables, one just above the reset jump at 0x0000 and one just above the entry point at BOOTRST/BOOTSZ. The IVSEL bit says which is active. If you are running bootloader code and want it to respond to interrupts then you set IVSEL otherwise in the default case IVSEL=0 and the active IVT is the one down near 0 ("app")
Kartman wrote:
3. Doing cryptographic hashes on an AVR is going to be slow.
And can also EAT flash space!
Kartman wrote:
It can only get into flash via the bootloader.
Which is also kind of my point above. As long as everything delivered/programmed is "protected" in some way the 3rd party simply can't "break in" to the execution sequence. So if the bootloader will only accept images that are signed or encrypted then the miscreant cannot create suitable signed/encrypted images.

 

BTW another approach (versus "signed") is to recognise that Atmel have application notes both for AES and triple-DES bootloaders.

 

(but once again you are really just up against the $500 lockbits).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

That's a very interesting device - far more secure than the puny lockbits on an AVR - it could form the basis of some kind of code signing/encrytping scheme.

 

And Maxim have a whole range of secure chips with security designed in...

 

https://www.maximintegrated.com/...

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
(but once again you are really just up against the $500 lockbits).

As I've often added, could you take that $500 and $1000 and bribe or join the cleaning crew?  Is your entire development and production facility locked up CIA-tight?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
This raises a number of questions - What is the overall aim of all these shenigans? 1. If the question is can you call a function that resides in the bootloader sector from non- bootloader code - yes you can. 2. As for your idea of interrupts etc , i’d suggest you think clearly about what you want to achieve. 3. Doing cryptographic hashes on an AVR is going to be slow. 4. How is the malware going to be injected into the AVR? Code cannot execute from ram, so anything subversive is going to have to find its way into flash. It can only get into flash via the bootloader.

 

Forget about the HASH function as a function. Just I assume that I have a function inside the bootloader section and I want to get the answer from it not from the normal code in Flash (even forget about the malware). So, my question was would it be possible to securely trigger some hardware interrupts to check the content of the message received and accordingly decide where to jump in the memory? 

M.A.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

A mildly related aside...

 

I once wrote a secure bootloader that worked a bit like the internet CHAPS. In that both ends know a secret. To validate one end puts the secret and then the data to be verified (could be code image) through a hashing function. You then send just the message text and the final hash to the other end. It starts by putting its copy of the shared secret through a hash then all the received data so that it comes up with a hash at its end. If the hash it calculates does not match the hash of the transferred data then the sending end can not have known the shared secret so cannot be trusted. In effect this is "signing" the code image to be delivered. In my case I used SHA256 and my shared secret was the first versus of the King James Bible.

 

Of course if I did this in an AVR then there is a chance the "hacker" could learn the shared secret. AVRs have lock bits but it's a poor protection that you can get broken for about $500. So the hacker could access the bootloader code, get the secret then produce his own "signed" code images.

 

However it is quite a strong protection unless it really is "commercial hackers" you are trying to protect against from delivering new firmware to your device that can take over operation (in our case this would mean circumventing a subscription payment system to re-use heavily subsidised hardware - not unlike the case with mobile phones).

 

I know about this. There is even something more stronger where you can store a key and this key cannot be read by the software. Check this out:
https://distrinet.cs.kuleuven.be/software/microvisor/

 

My question is: Is it possible anyway to securely trigger an interrupt upon receiving any message and according to its content, the interrupt vector routine will decide where to jump in the memory? 

M.A.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mammar wrote:

My question is: Is it possible anyway to securely trigger an interrupt upon receiving any message and according to its content, the interrupt vector routine will decide where to jump in the memory? 

 

No. Because the chip is not secure.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mammar wrote:
My question is: Is it possible anyway to securely trigger an interrupt upon receiving any message and according to its content, the interrupt vector routine will decide where to jump in the memory? 

When an interrupt happens (from any enabled source) control transfers to the IV table and processing proceeds from there, period, there is nothing secure about it, and it would have no content to examine before this happens!

 

Jim

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mammar wrote:
My question is: Is it possible anyway to securely trigger an interrupt upon receiving any message and according to its content,
"message", "Secure"? You are talking about much higher concepts that operate in a lowly AVR micro! The AVRs generally have one interrupt for UART receive (I'm assuming you mean a UART bootloader?). There are TWO possible vectors to handle it - one in the app section (IVSEL=0) and one in the boot section (IVSEL=1). That is all.

 

AVRs don't have any kind of "data filtering" concept to take different actions based on the received data (singly or across multiple bytes). So all you can do is enter the ISR for each byte that arrives and process its content there - such as pushing the bytes into an MD5/SHA/other hash or whatever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it possible anyway to securely trigger an interrupt upon receiving any message and according to its conten

The AVR does not have a hardware capability to put "some" interrupt vectors in the bootloader, and some in the application section.

You could define an "operating system" that grabs all of the hardware interrupt vectors and provides a mechanism to call user/runtime-provided "callback" functions for certain conditions, whether that was a pretty "bare" interrupt (like the Arduino "attachInterrupt()" function), or some high-level capability (OS handles the UART, and calls back the app on "full line received.")  You could even use the normal vector section of the application as vectors for the interrupts that you are willing to pass on (or you could define your own .vectors section.)

 

Parts of this OS that fit within the bootloader section would, I guess, be slightly more secure than parts of the code that didn't.  I'd think that it would be difficult to fit a "full" OS (plus secure bootloader) into the memory space normally available for the boot section.  And of course there's no RAM security to prevent an application for munging any internal state of the OS code...