|flabbergast 09771bc19a Update READMEs.||преди 4 години|
|binaries||преди 10 месеца|
|sources||преди 10 месеца|
|README.md||преди 10 месеца|
This is a firmware for ATMEL’s USB capable chips (e.g. atxmega128A4U, atxmega128A3U, atmega32U4) , which turns the device into an USB stick pretending to be a combined Mass Storage, CDC Serial and HID/Keyboard interface.
The whole shebang is about making an encrypted USB storage.
The data can be stored on a microSD card (e.g. X-A4U-stick, Stephan Baerwolf’s AVRstick with a microSD shield, or Arduino Leonardo or Teensy 2.0/++2.0 with a wired SD or microSD socket). Alternatively, with Stephan’s remarkable MassStorage bootloader on his AVRstick, the data can be stored inside xmega’s flash (mind its size!).
The data is encrypted with AES128 (cbc). “Unlocking” the drive is done by connecting to the stick via CDC Serial interface and entering the passphrase (see the Usage instructions for more details).
To use the Serial on Windows machines, an
.inf file is provided (not
tested). Note that it doesn’t install any driver, it just lets Windows
know that it’s a standard CDC Serial interface. (Like for Arduino.)
(for flash-backed storage) Using atxmega128a3u’s flash as a writable USB drive is a bad idea, since the flash on ATMEL’s chips is not meant to be used like this and has a very limited lifespan compared to usual solid-state storage (on the order of 1000 writes?).
This is more like a demo firmware, which can be quite useful for storing passwords and similar data which is small (it needs to fit into 64kB!) and don’t change often. This is also why extra steps are needed to make the storage writable.
Using a microSD for storage of course does not suffer from this problem. Just be aware that it is still slow (compared to what one expects from a microSD): I’m getting something like 130kB/sec for reading on xmega’s and about 30kB/sec on atmega32U4.
Every USB device has a Vendor/Product identifying signature. This is set
in software here (
Descriptors.c). The current code uses a pair which
belongs to the LUFA library. DO NOT USE IT for any other than
development purposes only! See LUFA’s VID/PID
apipageexample/library (see the AVRstick’s webpage).
Generally speaking, you should compile the firmware from sources; see
the README in
However, for X-A4U-stick there is precompiled firmware in
binaries directory. Even in this case, you’ll need to use
python script to generate a random AES key, set password and flash
the generated EEPROM file.
When the AVR stick is first inserted, it presents itself as a USB composite device, Mass Storage combined with CDC Serial and Keyboard.
Keyboard is there, but its functionality is not used at the moment.
Mass Storage appears as a SCSI USB drive, with one read-only
FAT12-formatted partition (ENSTIX), with one README.TXT file on it.
Nothing too interesting. (You can tweak the contents of the README file
in the sources,
To switch to “encrypted mode”, connect to the Serial interface using one of serial terminal programs, e.g. minicom, picocom, puTTY or even screen. The baud rate is not important, any should work. For example, on linux:
picocom -b 115200 /dev/ttyUSB0
screen /dev/ttyACM0 115200
You should of course use the apropriate
ttyXXXX, you can find it by
looking at the output of
OK, so now you’re talking to AVR stick via a serial terminal. Any key
c will display a short help. The individual
keys do the following:
iwill print some info.
pwill ask you for your passphrase. If entered correctly, the stick switches to the “encrypted mode”.
ryou can switch from “read-only” to “writable” and back. This only works in the “encrypted mode”.
cyou can change your passphrase.
Note that any change to the disk state (initial -> encrypted mode, or RO to RW or back) will cause the whole stick to disconnect from USB and then connect back after 1 second delay.
In the “encrypted mode”, the Mass Storage works as a common SCSI disk drive (size depends: either 64kB if it’s flash based, or the size of your microSD card). The only thing that the stick is doing is that whenever the computer wants to read a sector from that “drive”, the stick will take the appopriate portion of the flash or microSD, decrypt it and serve the result to the computer. Likewise for writing (receive the sector contents, encrypt and save to flash or microSD). So you can partition and format it to your liking. All the partition/filesystem business is now done on the computer side. For flash-based version, if you followed the set-up instructions above, then the default “contents” of the drive will be a drive with one FAT12-formatted partition (ENSTIXEN). For microSD-based version, you’ll need to partition and format the drive from scratch.
Once more, the xmega’s flash has a very limited lifespan, so I recommend enabling the RW mode only when absolutely necessary (so when you actually need to write some data to it).
The encrypted disk image is encrypted with aes128-cbc-essiv (probably not directly compatible with other existing programs using this scheme). So there is one main AES128 key. This one is used to encrypt each sector (usually 512 bytes) with CBC, where the IV is derived from the key and the sector number as described by the ESSIV scheme.
What is stored in xmega’s EEPROM is the main AES128 key encrypted with AES (the key for this is the first 16 bytes of the SHA256 hash^1000 of the passphrase). Another piece of data stored in EEPROM is the SHA256 hash^1000 of the SHA256 hash of the passphrase (for verifying if the entered passphrase is “correct”). (Hash^1000 means it’s repeatedly hashed, 1000 times.)
Of course, for the flash-based version, the (encrypted) disk drive image
can be easily extracted from the stick by putting it into the bootloader
mode and inspecting the contents of the
FIRMWARE.BIN file. Likewise,
the passphrase-encrypted AES key, as well as HASH^2000(passphrase) can
be read from
Finally, while the stick is in operation and in the “encrypted mode”, the main AES key is stored in chip’s SRAM (working memory), as well as probably in the “AES hardware module” of the chip. So it can be probably extracted with, say, a JTAG debugger hooked up to the chip. This is the same problem as with pretty much all the “encrypted storage” schemes that I know - while the encryption is in operation, the key can be extracted from the device’s working memory. However, as the passphrase is only needed for getting a hold of the main AES key, it is deleted from the working memory after the main AES key is decrypted.
I would be grateful if you can let me know if there are some security holes in this scheme.
There have been some changes to the encryption and hashing that break disk images (namely to 1.2 and again to 1.4). Since these were very early development stages, you’d need to ask me for instructions if you happen to need them (it’s possible to retain the data with a bit of python).
In principle this firmware should compile for other USB breakouts with ATMEL’s USB capable chips (e.g. atmega32u4), but a bit of hacking of the current code is needed. The limitations that come into play are:
My code is © flabbergast. GPL v3 license (see LICENSE file). Portions of the code come from LUFA demos, this is licensed by LUFA’s license.