Security concern, SPI downloading, parallell pgm and JTAG

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

Hi all:
I have a strange question about security with AVR's.

We all know that we can lock the AVR to a state in which it´s impossible to read program code nor internal EEPROM data from outside, even in JTAG capable devices.

My question is: can be the internal RAM contents be read from the outside? (i mean using a SPI dongle or parallel programmer).

As an AVR programmer, I know this isn´t possible since the AVR doesn't have any resource to do that by spi programming. But what if I tamper the AVR with a program of myself that i load to the chip (spi) and then it reads the RAM contents and dumps it by the serial port??

Stupid of you (could you say) you will end up erasing the FLASH contents! But what if I want the internal RAM contents?

Just imagine a device like a Pin Pad device which had encription features. This gadget uses a DES algorithm (actually a 3DES) to perform encription. But it needs one or more keys to be present in oder to encrypt.

My question comes after the fact that this keys are stored in RAM with a battery backup and an antitamper device which disrupt backup voltage in the event the PP case is opened.

Now if someone with the necessary skills does access the controller (having "tampered" the antitamper circuit) , Can he load a simple program to the AVR and read the internal RAM contents?
There's no "RAM destruction or resetting" when programming the AVR FLASH?

This is rather a concern for me, because I will have to design such a device in brief, and if were possible to retrieve the RAM contents in such a stupid way I'd have to look for another device (compiler, debug tools and etc...) which is expensive and time consuming or look for a mask ROM device (expensive and complicated too)

Could anyone share his experience or give advice?

Thank you.

Nachus

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

You could consider putting one key in FLASH, one key in EEPROM, and one key in RAM. Requiring all three to be valid to encrypt means that a single attack will get only one at best, destroying the other two.

Use a processor with self-programming.

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

Hi mneary:

The problem is that all keys must be stored in internal (volatile) RAM, this is a standard requeriment, along with an antitamper ckt. We planned to epoxi dip the PCB so there is one troublesome step before gain physical access to the chip.

thank you

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

hi, what AVR are you using?

Reading the RAM is quite easy, just do a chiperase and program the chip to dump the contents of the RAM to the U(S)ART, or some other interface. All this must be done while keeping the chip powered of course. Some of the newer AVRs will erase the contents of the ram and register files during chiperase, I know that at least mega162 and mega169 does this, but you should probably ask Atmel or test yourself for the device you are using.

- Speedy.

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

With alittle determination, I am sure you can figure out ways to hide your open keys in the ram.

From your post, I am assuming that the public know the algorithms you are using.

You could spread the bytes of the key out at various places in the ram. If key[0] resides at 0x125 in ram while key[1] is at 0x182 and so on, it's not so easy to just guess.

If they don't have your code, they don't know what clock cycle precisely to stop the circuit for the chip erase.

There are lots of ways to help hide your issues and I mean hide them. This is obscurity as the security of the device is limiting what you can do.

Regards

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

Hi , thanks all who replied,

To Speedy: I havn't determined yet which uC to use, but I have an already working design using an ATmega8515, so I will test the "ram destruction" with a ATmega 162
(im planning to upgrade this design to a atmega162 anyways for improved code space)

To sxpilot450: Yeah, I think it´s possible to hide the placement of the keys in diffrent addressing spaces, but the keys have to be updated in a regular basis, so it`s not possible to load keys in flash, because It will be necessary to set lock bits from a bootloader (to protect the keys!!) and this can be done once. And of course, i was told to put all the keys in RAM. and load the keys(encrypted) using UART

I will experiment with these micros, Best regards

Nachus

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

This is when the FPSLIC from Atmel could potentially help you.

You could implement your algorithm entirely in HDL inside the FPGA side of the device. As well, you could implement your own scrambled/encrypted ram using the ram from the FPGA.

Atmel's FPGAs are entry level due to propagation-delay constraints but they can do this type of stuff with ease!

To Atmel- Please grow above 40k gates and add more ram bits. Also, keep producing a PLCC 84 for people like me to prototype with ;).

It would be great if they could implement flash inside the FPGA line like Actel's ProASICPlus line of FPGAs.

Regards