fl-shelved
/
sha204_playground
1
0
Fork 0
Code Releases Activity
Interact with ATSHA204 chips via AVR chips (firmware for Arduino or pure avr-gcc) + python script a-la hashlet
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
19 Commits
1 Branch
0 Tags
147 KiB
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'master'
${ noResults }
Go to file
flabbergast 0be233f89e
Update README. 		9 years ago
arduino Update README. 9 years ago
avr Update README. 9 years ago
firmware_binaries Add some compiled firmwares. 9 years ago
talk_to_sha204 talk_to_sha: SHA support. 9 years ago
.gitignore Initial checkin. 9 years ago
LICENSE Initial checkin. 9 years ago
README.md Initial checkin. 9 years ago

README.md

sha204_playground

Firmware for ATMEL chips to communicate with ATSHA204 chip interactively over Serial. Sources are supplied in two forms:

  • As AVR-GCC project utilizing the LUFA library (for USB capable ATMEL chips, tested on atmega32U4 and atxmega128a3u).
  • As an Arduino sketch.

Along with this, a python script talk_to_sha204.py is provided to access some of the functionality of the ATSHA204 chip, talking to it via the firmware above (in a binary mode), a-la hashlet.

Usage / Installation

Please see the READMEs in the individual subdirectories for some info on how to use them.

Pictures

The original impetus to write this stuff for me was that I had a couple of ATSHA204 breakout boards from Sparkfun and I wanted to play with them outside Arduino, using just avr-gcc and LUFA, on some USB sticks with ATMEL chips. Here are pics with two of them:

A pic of atmega32U4 USB stick with ATSHA204

And matrixstorm's AVR stick with the same Sparkfun's ATSHA breakout:

A pic of AVR stick with ATSHA204

Idle thoughts / ramblings

So, what can be ATSHA204 used for? Well, it performs hashing (SHA256) and it can securely store "keys" (32 bytes long blocks of data).

The important point (for me) is that to verify that a "signature" (hash, MAC) was generated on a particular ATSHA requires knowing all the "secrets" that were used to generate the signature. This works fine for Client/Server-like situations: "Client" ATSHA generates a signature for, say, a file, (e.g. on a local computer), which is then sent to "Server" for verification. However the "Server" has to know the "secret keys" on ATSHA that were used in the signature computation; so either the "Server" has a copy of the keys stored in ATSHA, or there's another ATSHA on the "Server" with the keys.

This kind of thing can be used for instance to roll one's own authentication service a-la YubiKey.

What I wanted to use it for is to securely store encryption keys locally, for a "two-factor key storage". This is also possible to do: user enters a password, this is passed to ATSHA which generates a hash of the user's password, together with one of its "secret keys". This hash is then used as an encryption key. So to obtain the encryption key, one has to know the password and have the ATSHA along.

Notes

Please see the READMEs in the individual subdirectories for more info about the various parts of the project, as well as credits.

TODO / Roadmap

  • Make also binary-mode-only versions of the firmware (for smaller than 32kB chips).

License

My code is (c) flabbergast. MIT license (see LICENSE file). Portions of the code come from LUFA demos, this is licensed by LUFA's license. The original code from SHA204 library is licensed by Apache V2.0 license.