Bootloader too small (authenticated encryption + Bluetooth)

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

I'm writing a bootloader that has to update the chip's application code over Bluetooth. The firmware should be sent authenticated encrypted to the device. I'm not worried about an attacker gaining access to the hex file (as I've read on here with a 500 dollar device you can clear the lock bit and read the firmware off the device anyway). What I want to do is prevent an attacker from uploading his own (potentially malicious) code to the device over Bluetooth. Therefore I need data authentication so that the device can detect that the code is coming from a malicious sender. Note that the attacker does not have physical access to the device so uploading his own code is only possible over Bluetooth.

 

The problem is that my code doesn't fit on the Atmega328p's 4kB bootloader. My Bluetooth bootloader is about 3kB without encryption, and with encryption gets up to 10kB (I'm using the avrnacl library). Looking around this forum I found that it is quite unusual to have such a large bootloader so I was wondering whether I was doing something wrong. 

 

I considered switching to an XMEGA but they have a maximum bootloader size of 8kB so that wouldn't work either. An ARM chip or something similar would be another solution but this would require me to rewrite all of the code. And it seems a bit overkill since the performance of the Atmega is fine, it's just the bootloader that's too small for my purposes. Another solution would be to get an external memory chip for the bootloader (is this possible?) or even another avr chip just for encryption. Or an authenticated encryption library that's a lot smaller than the one I'm using right now. I'm not sure what the best way to go is here, I would appreciate any help!

Last Edited: Mon. Feb 8, 2016 - 10:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Others can comment on the Bootloader size, not something I'm familiar with.

 

Note that the Xmega A series have a hardware encryption/decryption module which might significantly reduce that part of the code's size.

 

JC

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

Have you read AVR231?  It includes an AES bootloader which fits into 2K.  I have no idea how you managed to fill 10K.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Your bootloader theoretically doesn't have to ALL fit within the bootloader section.  In theory, you can position it so that the start vector is in the right place, and the portion of code that actually writes application space is in the bootloader section, but you still have SOME code that extends into the top of the application section as well.

 

(there's an interesting question.  Can I set up a linker script that causes a section to be built "downward" from a specific location in memory?)

 

Last Edited: Tue. Feb 9, 2016 - 01:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note that the Xmega A series have a hardware encryption/decryption module which might significantly reduce that part of the code's size.

 I believe it only implements the cryptographic engine AES and no mode of operation, I'd need to add CCM or GCM myself which can probably be done but requires some work.

 

Have you read AVR231?  It includes an AES bootloader which fits into 2K.  I have no idea how you managed to fill 10K.

Yes I went through this, but this is again just the AES engine (with maybe ECB mode). This is not authenticated which would mean I need to add CCM or GCM.

Your bootloader theoretically doesn't have to ALL fit within the bootloader section.  In theory, you can position it so that the start vector is in the right place, and the portion of code that actually writes application space is in the bootloader section, but you still have SOME code that extends into the top of the application section as well.

 I've briefly looked into this but in general it seems like this is greatly discouraged.

 

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

westfw wrote:
Can I set up a linker script that causes a section to be built "downward" from a specific location in memory?

No. The linker starts at whatever 0xNNNN you give it as a base and goes up/on from there.

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

Which bluetooth module/chip do you use? (I use BLE121 and it can save the AVR code in it's flash and there do the check)

 

The new 328pb chips have an unique number, if that's any help.

 

And I also have a problem to understand how the boot loader can be that big. (I do know that picoboot are simple but it use 66 byte on a chip that don't even have a UART)   

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

sparrow2 wrote:
Which bluetooth module/chip do you use? (I use BLE121 and it can save the AVR code in it's flash and there do the check)

 

I'm using a BLE112, so it seems like it should be capable of the same thing you are doing. It looks like you are doing exactly what I am trying to do. If I understand correctly, you load all the AVR firmware on the BLE121, do checks, then send it over UART to an AVR device where the firmware gets upgraded? If this is correct, it seems like you need to program C on the BLE121? How do you go about this? On the Bluegiga website it says this can be done with IAR Embedded Workbench, is this how you do it? I heard this is really expensive though, there aren't any open source possibilities? :) Thanks!

Last Edited: Tue. Feb 9, 2016 - 12:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They have a BASIC like script I use. (event driven) 

 

(And no I'm not doing it today, but It's a part of the plan .I run a script that do the bluetooth setup things, and the serial communication to the micro, (pull some data) ), so I can't see if it's RS232 , WIFI or bluetooth that talk to me.

 

edit:

And I guess I need to add that the script tool is free (you will need to register ), 

Last Edited: Tue. Feb 9, 2016 - 02:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note that the attacker does not have physical access to the device so uploading his own code is only possible over Bluetooth.

I have a display that show a serial number, you need to know that before you can connect to the controller. I don't care if people can read my adv. data.    

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

Perhaps the trick is to have the main application receive and decrypt the data and stash it into some external storage, a flash chip or something. Then the bootloader can just read from this external storage and flash the application section.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

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

yes that is the idea with the BLE module, it has no problem holding the AVR code