Securing the EEPROM

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

I have a little program running in an Attiny2313. But before it can do anything, the device has to be authenticated first with an "authenticator".

The way it work is, the authenticator sends a bunch of characters(encryption/decryption keys, settings, etc) to the tiny2313 via the serial port. The tiny2313 will then save this in EEPROM. Only that time(when the tiny2313 has these array of characters) that the two can communicate via wireless.

My problem is, how do i prevent someone from reading the EEPROM data and at the same time still "programmable" by the authenticator by sending a new batch of data via serial(writing to EEPROM is handled by code in tiny2313)?

The datasheet tells me of lockbits but I'm not sure if the EEPROM can still be programmed by code if I use this setting

Quote:
Further programming and verification of the Flash and
EEPROM is disabled in Parallel and Serial Programming
mode. The Boot Lock bits and Fuse bits are locked in both
Serial and Parallel Programming mode

Thanks.

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

If you lock the Attiny you won't be able to program the EEPROM until you unlock it. When you attach the serial port could you also attach an SPI programmer and unlock | authenticate | lock in one operation?

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

i use USART for communication between attiny2313 and authenticator.

Basically,

authenticator <--> USART <--> attiny2313
//exchange data over USART
//attiny2313 saves data to eeprom

//on next reset, attiny2313 loads keys from eeprom and now can communicate via SPI (to a wireless transceiver) to the authenticator

my question is, can I even write to the eeprom (using a subroutine inside attiny2313) when the lockbits are set?

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

i guess I don't have a choice but try it myself. Hopefully, my army of tiny2313 arrive soon enough in case I lock myself out

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

I've never tried what you want to do, but maybe someone else has.

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

The 'fuse' lockbits prevent external (ISP/High Voltage etc) from being able to read/write the code/eeprom. The internal AVR code still has read/write access to code/eeprom, so your program will still be able to read/write & re-write the eeprom space.

How 'secure' the fuse lockbits are has been discussed in this forum more than once.

cheers,
george.

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

That all what I need to hear.

Thanks

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

If you need secure storage of that kind, you need some "secure" IC... I would look at IC's made for smartcards, they usually come with decent enough crypto libs and are made exactly for what you want to do. Your AVR would never actually know any of the data, it would need to be transmitted and passed to the crypto IC encrypted with a public key, and decrypted internally with a private key known only to you and hopefully inaccessible to anyone else. The AVR would be nothing more than a system controller, and would ask for a "token" from the crypto chip, usually in the form of a control word just telling your controller that everything is fine, device is authorized.

Any 2-bits hacker would tear through data stored in an AVR EEPROM.

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

my requirement is fairly simple. Since my server needs to communicate with a device over wireless (not WiFi), all I need is at least some form of encryption between the two. Its not like Im sending some nuclear codes over it, just simple serial commands to tell the device what to do, nothing fancy.

But before they can talk over wireless, I need to authenticate the device first (send the encryption/decryption keys, some RF channel settings, etc unique to the server via serial). That way, the device can only talk to the server where it gets the keys. Another server can be in the same area but wouldn't be able to talk to my device linked to the original server.

And I have to keep the BOM small and cheap

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

In all honesty, I think you would be way better off with a SoC wifi chip. It will do everything you want and then some.

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

I would have gone WiFi but the price different is just something I can't pass

WiFi SoC ~ $40

my setup
attiny2313+RF transceiver ~ $4

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

Plus the countless hours of debugging RF issues, paying for regulatory tests for certification if you want to sell the units, plus the networking stack development time, plus the link encryption/decryption code, plus the insane amount of technical support you will have to deal with if somehow you messed up something RF-wise... 40$ seems a bit steep too, what modules did you look at? At what range do they need to work, what bitrate? In what quantity do you need them?

Do the units need to operate independantly directly in WiFi or could you use a central WiFi bridge and a separate zigbee link for the devices? You can have complete 2.4GHz modules that include the antenna for 20$ in singles, which IMO are well worth the price if they fit your specifications. They have 128-bit AES encryption integrated too, which you can easily support on your AVR with AVR-Crypto-Lib:

http://avrcryptolib.das-labor.or...

http://search.digikey.com/script...
http://search.digikey.com/script...

All you have to do after this is have the bridge send out encrypted keys periodically, which you decrypt and keep (obfuscated) in SRAM. Disable the debug interface on final units and it's near impossible to break unless someone breaks the key server (which would probably be a PC with a WiFi link to the xbee bridge), or does some pretty advanced power analysis.

For WiFi there's these for 26.50$ each in 10's:

http://search.digikey.com/script...

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

I actually have the wireless part working, I just added the encryption as a bonus security feature. I developed my own stack to accomodate my needs, nothing fancy but works like a charm. I implemented something similar how IP networks work.

As for the regulatory concern, the manufacturer said its FCC certified so I guess thats good enough for me (for now)

As for the amount of data to send, its not a lot. Like I said, just simple commands to a device. Theres not a lot of data exchange going on, its more like SET/GET/ACK and some data but thats about it.

Im not sure about the AES side, as you know, my tiny2313 only has 128 bytes of RAM and a whopping 2KB of flash (I have to code everything in assembly as thats the only way I can fit so much is such a little resource)

Quote:
All you have to do after this is have the bridge send out encrypted keys periodically, which you decrypt and keep (obfuscated) in SRAM.

Thats the main reason why I have to transfer the encryption key via a physical connection (serial) as it would be pointless to send keys over an unencrypted wireless.

I actually looked at xbee, wifi modules from Roving networks, Olimex, Atmel, etc but they all cost upwards of $20 which is rather steep for a simple device that only need to process a few commands. If I would have to process some realtime data such as video or audio, then xbee or wifi would have been appropriate.

As for the issue regarding the security of the EEPROM, that I have to address in the future.