reflashing via bootloader and protecting code

Log in or register to post comments
Go To Last Post
6 posts / 0 new
Author
Message
kalbun
kalbun's picture
Level: Hangaround
Joined: Tue. Mar 2, 2010
Posts: 132 View posts
Location: Firenze, Italy
#1
Posted by kalbun: Thu. Jul 9, 2015 - 02:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using an Ethernet bootloader which nicely allows to reflash the application area via a mini-HTTP server.

Everything works nice, but I am thinking how to protect the application for being stolen.

I assume that lock fuses and security bit cannot be used, as this would prevent the reflash operation from the bootloader. Another option could be to disable the JTAG port, but I can't find a way to do so (if I remember correctly, this can be done on some Mega/XMega).

Any suggestions? Or correction, if I am wrong?

Thanks.

 

Tags:

AVR Microcontrollers, AVR UC3
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 105140 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Jul 9, 2015 - 02:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely this is exactly what the lock bits are for? So why do you "assume" in this:

I assume that lock fuses and security bit cannot be used,

Of course if the application code passes as plain binary on it's journey from the HTTP server to the client in the bootloader then THAT could be intercepted. To guard against that consider something like AES or triple-DES encryption so that even if the binary payload is intercepted it will be useful without the decryption key built into the protected bootloader.

 

Having said all this I guess it's as true for UC3 as it is for tiny/mega that there are companies that offer a service for about $500 to break lock bit protection so if a commercial competitor wants to steal the code all they have to do is invest $500. As such no AVR is very secure.

 

EDIT: this:

 

http://atmel.force.com/support/a...

 

reminds me that there are some models of UC3 with built-in 256 bit AES crypto engine. Google also mentions "FlashVault" - not sure what that is but it could well be something offering more than $500's worth of code protection!

Top
kalbun
kalbun's picture
Level: Hangaround
Joined: Tue. Mar 2, 2010
Posts: 132 View posts
Location: Firenze, Italy
Posted by kalbun: Thu. Jul 9, 2015 - 07:21 PM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Surely this is exactly what the lock bits are for? So why do you "assume" in this:

I assume that lock fuses and security bit cannot be used,

 

Sorry, I compressed my thoughts too much, and the sentence is hard to understand.

 

In facts, security bit does prevent unauthorised access, but it also prevents the bootloader from reflashing - at least, when I attempted to do so, the application area was not rewritten, while everything works fine with secbit not active.

 

Security is a major concern in this project, but it was not addressed correctly from the very beginning. Luckily I designed neither the board, nor the firmware... but I may have a good chance to sell some more consulting services to my customer   cool

 

Thanks for your suggestions

Top
gchapman
gchapman's picture
Level: 10k+ Postman
Joined: Tue. Jan 9, 2007
Posts: 16848 View posts
Location: Clay County, Texas, u.S.A.
Posted by gchapman: Fri. Jul 10, 2015 - 02:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel

Home > Products > Microcontrollers > AVR 8- and 32-bit MCUs > 32-bit AVR UC3 MCUs

32-bit Atmel Architecture Manual

http://www.atmel.com/Images/doc32000.pdf

...

1.2.3 FlashVault

Revision 3 of the AVR32 architecture introduced a new CPU state called Secure State.

This state is instrumental in the new security technology named FlashVault.

...

IIRC, rev 3 is UC3C and UC3L.

"Dare to be naïve." - Buckminster Fuller

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 105140 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Jul 10, 2015 - 09:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know UC3 but in tiny/mega there are various lockbits both for the application section and the bootloader section. I would have assumed the UC3 has similar offerings. That would allow the bootloader to be protected so it cannot write over itself but it can still write the application section and equally both can be protected so that any attempt to read out their contents over a programming or debug interface just return junk. Surely UC3 offers this?

Top
kalbun
kalbun's picture
Level: Hangaround
Joined: Tue. Mar 2, 2010
Posts: 132 View posts
Location: Firenze, Italy
Posted by kalbun: Fri. Jul 10, 2015 - 10:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unfortunately the UC3  is rather basic from this point of view.

 

There are 16 "lock" fuses for write protection  + a fuse that protects a variable-size area at the beginning of flash, 0 up to 64k. This effectively prevents the bootloader from reflashing itself.

All these fuses can be reprogrammed via JTAG - no erase needed.

 

There is another fuse, called "security bit", that completely protects from external interfaces. If you set this bit, all read and write operations via JTAG become impossible, but the bootloader still works.

In the end, I discovered that I was doing something VERY stupid: attempting to reflash with BOTH the lock fuses and the security bit set angry

 

Once I corrected the problem (only secbit active), reflashing via bootloader works very well.

There is still the need to encrypt/decrypt the updates, but this is another story, and the AES machine could help.

 

So the code seems to be safe, until someone spends the 500 USD that you mention in your message, eh eh...

Last Edited: Fri. Jul 10, 2015 - 10:05 AM
Top