How to update a commercial Xmega equipment in a secure manner?

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

Hi guys, the company that I work for has developed medical equipment which has inside an Atxmega128a1U running bare C code (no OS is present).

 

The equipment works fine, we use an Atmel-ICE programmer to burn the code and yet inside the main factory we change the lock-bits to not allow read or write (this policy might be changed if need to allow writes if it doesn't come safety issues).

 

The question that I would like to bring is: is there any safe away to update the equipment firmware without sending the complete .hex our .elf code to a company branch, which may not have all security precautions to deal with such relevant information?

 

Appreciate your attention!

Regards!
FS.

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

Use a bootloader with encryption. Atmel have an app note about both AES and triple-DES bootloaders. Admittedly that is for Tiny/Mega but most of the technique should port to Xmega.

 

Of course the only protection this gives is that the person you pass the binary too cannot disassemble it to found out how it works.

 

There are also schemes where you can have some kind of "signing" so that others cannot create images that would look "valid" for the bootloader to load in.

 

But all this depends on the Lockbits in the chip that prevent a malicious user extracting the code when it has been programmed in. Given that there are services in nefarious parts of the world who will break those locks for $500 then the entire systemin any AVR is only ever as secure as those $500 protect anyway.

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

F Schneider wrote:
we use an Atmel-ICE programmer

 

Atmel-ICE would be good for prototyping, but for production I would suggest that you use an In-Circuit Programmer. I had the chance lately to deal with one of Atmels specific ICP that is ICP2(G3) from Softlog, a third party company that provides solutions for MC/Atmel specific products. Now if you are willing to pay 600$ you get a decent programmer. they happen to develop a secure programming tool:

 

http://softlog.com/index.asp?pag...

 

A multi-layer IP protection that I would say it would do the exact job for you. the features include the possibility to remote update the HEX files and the counter and many other features (Check the link). I suppose this is exactly what you are looking for....so far I used this for atmels chips. Unfortunately SEGGER (German supplier) of In-Circuit programmers havent developed something yet for the specific atmel chips that am using but they have for other MC's chips.

 

Hope my information helps you a bit.

 

Lg/Regards,

Moe

 

 

EDIT: https://youtu.be/wmwFFjOE1_w

youtube video :)

Last Edited: Thu. Sep 5, 2019 - 12:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Data-at-rest encryption where the data is the application.

Crypto key stored with the bootloader; better is pass phrase and salt that's hashed to generate the crypto key.

Bootloader operates the XMEGA's crypto engine.

Encrypted application via USB though the XMEGA USB DFU bootloader has some size (Microchip's, third parties are apparently less); a USB HID bootloader is significantly less in size.

Branch offices will need physical security though communications security isn't necessary.

HQ and PCBA fab have physical and communications security (secure storage of the pass phrase and salt)

Some organization's logistics group program the bootloader after receiving the tested PCBA; BIT firmware is what the PCBA fab programs and operates.

 

Enhance system security with better data-at-rest encryption | Embedded (hash on page 3 of 4)

Drivers | ASF Source Code Documentation (pull-downs : Cryptography, xmegaau)

GitHub - kuro68k/kboot: USB bootloader for XMEGA devices

Given your preferred XMEGA USB driver, can roll your own USB bootloader and loader.

Though USB megaAVR instead of USB XMEGA, a very small GPLv3 low-speed USB bootloader and loader :

GitHub - rrevans/ubaboot: USB bootloader for atmega32u4 in 512 bytes

 

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

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

clawson wrote:
But all this depends on the Lockbits in the chip that prevent a malicious user extracting the code when it has been programmed in.
fyi, the dual-core XMEGA has ROM that might contain a first-level bootloader; a USB HID bootloader can be very small.

https://www.avrfreaks.net/forum/megaavr-0-series?page=3#comment-2660896

A metal layer over the relevant transistors in the die is a common guard.

In-lieu of, the keys and such can be protected; though not a complete Secure Boot there's Secure Boot | Counterfeit Protection | Cryptoauthentication | Microchip Technology (for complete Secure Boot, replace the SAM D21 with a SAM L11)

SAM L10 and L11 | Microchip Technology

 

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

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

gchapman wrote:

dual-core XMEGA has ROM

What in the name of all that is holy is a "dual core" Xmega and since when has any Microchip Xmega had ROM and not flash ??

 

Are you getting mixed up with Samba in ARM devices or something?

 

Anyway OP said  Atxmega128a1U  so I think he's only going to be interested in solutions for that chip as he said:

F Schneider wrote:
has developed medical equipment which has inside

Or are you really suggesting a redesign from scratch?

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

I was also surprised, gchapman seems to miss the point and went a little bit further beyond the question :) but anyway thanks for the info.

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

Thank you guys, I found it very nice how I can always find some help here...
 

clawson wrote:

Atmel have an app note about both AES and triple-DES bootloaders.

 

I will take a look at those papers and evaluate if I can implement something using as basis those documents.

 

Clawson, you also mentioned the lockbits protection break, is it very common? I have heard something about it, including some procedures that scrape the chip down to the silicon but it doesn't seem a easy procedure.

Regards!
FS.

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

Thank you, I believe that the company who owns the product that we have developed would pay $600 to keep the source code safe.

 

I will get in contact with Softlog and see with they have some support to the micro that we use.

Regards!
FS.

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

clawson wrote:
... and since when has any Microchip Xmega had ROM and not flash ??
Indeed it's flash for the smart card MCU that Atmel sold to Inside Secure in '10.

Couldn't find any information for the AT90SCR400 that appeared in IAR EWAVR approximate to July'19 though did for the AT90SCR200.

clawson wrote:
Are you getting mixed up with Samba in ARM devices or something?
No

clawson wrote:
Or are you really suggesting a redesign from scratch?
No

Intention : To make visible one way to secure crypto data.

 


History - Inside Secure

Inside Secure DEBUTS FIRST IN A FAMILY OF EMV-COMPLIANT SMART CARD READER CONTROLLERS

Speeds Development of EMV Level 1 Certified Smart Card Readers

AIX-EN-PROVENCE, France, September 25, 2012 

[mid-page]

The AT90SCR200 also includes a hardware AES crypto engine and random number generator, and offers 4KB of data SRAM and EEPROM, plus 64KB of flash code memory, including a dedicated boot loader area.

 

Availability and Pricing

...

AVR | IAR Device Search

[select the AVR check box for Architecture, expand it by 'Show more' multiple times]

[11 instances of 'INSIDE Secure']

https://netstorage.iar.com/SuppDB/Public/UPDINFO/013556/ew/doc/infocenter/readme.ENU.html#highlights (Release Notes, 7.20.1, AT90SCR400)

 

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

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

gchapman wrote:
Intention : To make visible one way to secure crypto data.
But of little/no relevance to what OP is asking?

F Schneider wrote:
the lockbits protection break, is it very common?
It does seem that a number of places offer it and it does seem to involve making optical access to the chip then I'm not sure if they then use lasers to cut tracks or something or whether they use laser energy to change the charge state on the gate of locking transistors or something. I seem to remember that someone at one of the prestigious universtities (could have been Cornell or Harvard or Cambridge or Oxford?) published some research about the various techniques used to break into "locked" chips. (any google is almost bound to involve the term "hydrofluoric acid" (if you can work out how to spell it!)