views:

211

answers:

3

Generally I would go about this by placing something(s) unique and random in the ROM image and use that as a seed to encrypt the EEPROM content to stop extraction and reprogram after image mod.

An obvious flaw seems to be that this doesn't stop tampering in the form of replacing the EEPROM external chip with a blank one... oh look were back to first time used state, lets ask for keys to save!


Selecting components is not an option for me, the hardware platform is already defined. The EEPROM is programmed during the lifetime of the device as configuration and state change so disconnecting the erase line is also a no-go.

I was seeking opinion on possible solutions to prevent the faking of a virgin (first run) state since this would allow functionality to save the sensitive data and unlock the device.

I am confident a block cipher (ECB mode) is sufficient to secure the sensitive data, maybe over the top! This approach along with multiple copies, salting one and not the other should make it financially unrewarding to place money and time to counter these measures.

+3  A: 

Float the erase pin and epoxy the whole chip to the board? Use a PROM?

If you don't want the image modified, make it impossible to modify.

greyfade
+4  A: 

Some thoughts: if by 'securing against modification' you mean that you can detect such tampering, then you can

  1. generate a checksum over the whole eeprom, only start your app if the checksum is ok
  2. use an additional chip which provides a unique number, use that number to encrypt the content of the eeprom
  3. store all your info in several places in the eeprom (two times if you only want to detect a change, three times if you want to detect and reject the tampered value and use the 'still correct' values)

But if you want to prevent the tampering in the first place, you have to use mechanical guards - hot glue the whole chip, lock the housing of your pcb, ...

Stefan
A: 

If hardware measures are out, and you're stuck with a software approach, and the thing that reads the EEPROM can handle public-key algorithms, then you could use a public-key signed block of data in the EEPROM (take your EEPROM data, precede it by a fixed block containing the length of the data and a secure hash of the data that's been encrypted with the private key).

This requires whatever uses the EEPROM contents to validate it with the corresponding public key (obviously don't put this in the same eeprom). Public key algorithms are computationally kinda expensive so it's a bit tough to justify this approach for microcontrollers.


If you can't stop people from tampering with the hardware, but you can pick which hardware you use, you could also use a secure EEPROM, such as the Maxim DS28CN01 (although I gotta admit, I hate Maxim since their parts are pricey and have long lead times and are often vaporware until enough people put in orders for them to make their parts) or Atmel's AT88SC series.

Jason S
all right, mr. -1, perhaps you could comment on your opinion?
Jason S