Using Atmel's ATSHA204 sha256 chip

From HeepyWiki
Revision as of 19:05, 6 June 2013 by Morris (talk | contribs) (Created page with "Atmel's [ ATSHA204] embedded crypto chip can store keys and compute sha256 hashes using them, among oth...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Atmel's ATSHA204 embedded crypto chip can store keys and compute sha256 hashes using them, among other operations. This is fairly useful in cases, for instance, where you want to be able to verify whom you're talking to but don't want to store a readable key in memory where an attacker could grab it or read it off a bus, etc. Of course you still have to trust Atmel to have implemented it properly and not inserted backdoors, but if your application isn't particularly critical it is pretty convenient.

It comes in both one-wire (not dallas one-wire compatible, sadly) and i2c versions. The onewire version is available in a 3-pin SOT23 package that looks just like a transistor, which is sort of cool.

My application here is simply using it to decrypt short non-replayable commands from a host. I can write a bunch of keys to its 16 keyslots prior to locking its config and data zones, after which those keys can't be read or written, but only used as inputs to crypto operations such as SHA256 MAC computations. You give the chip a 32 byte block of data (the challenge) and tell it which keyslot and other data to incorporate into the hash, and it assembles your data together with whatever else you've asked it to add (the chip's unique serial number, etc..) and returns to you a 32 byte hash.

If you need to send a short encrypted message, and you already know what is stored in the chip's keyslot and other data, you can compute the hash yourself and xor your message with it; the chip then computes the hash and xors it with what you've sent it, giving the original plaintext. The point here is to additionally incorporate an always changing value with the "challenge" component of the hash, so that as long as the sender and receiver remain in sync, the cipher text will be different even with successive sends of the same data, and capturing an encrypted command and replaying it to the receiver won't work. This of course assumes a sufficiently large set of sequence numbers, but in my case I'm just trying to make this harder than kicking my door down, so the bar is pretty low. :)