1. Software that you run on your computer (the “host”) to send commands to…
2. A USB “token” which A) encrypts and stores credentials from the host and B) decrypts and displays them on its LCD.

Creds101 serves the same purpose as traditional “password database” solutions but it is different in two fundamental ways:

1. Credentials aren’t stored on the user’s computer – they’re stored on a USB “token”.
2. Sensitive credential data cannot be read by malicious software on the user’s computer – credentials can only be viewed on the token’s “trusted LCD display”.

• AsciiDoc-based documentation including the “host->token” serial command protocol and data-flow diagrams illustrating how credentials are encrypted, stored, decrypted, and displayed by the token.
• A unittest test suite which exercises each of the commands accepted by the token. Install Twisted and try

  PYTHONPATH=src trial src/TestSimulatorToken.py

• A cross-platform “token administration” GUI for storing and retrieving credentials. Try

  bin/creds101-admin-gui --use-simulator

  or see screenshot 1.

  
• A command-line “token administration” interface. Try

  bin/creds101 --help

• A “token simulator” that allows us to 1) develop tests 2) iron out token design issues before coding in C for an embedded platform. Try

  bin/creds101-simulator --gui

  or see screenshot 1.

• 
  The beginnings of the code for an Arduino-based token. Take a look in `src/arduino`. This includes code for…
  • Receiving commands from the “host” via the Arduino’s FTDI serial-over-USB chip.
  • Reading and writing data to the 512 bytes of internal EEPROM or an attached SPI DataFlash part. See photos 2 and 3.
  • Displaying text on a SparkFun SerLCD LCD module.
  • Encrypting and decrypting data with 128-bit AES.

• 
  Completing the Arduino token implementation so that we have something that’s suitable for everyday use.
• Completing a thumbdrive-sized token implementation – the ideal form factor.
• The smaller tasks that can be found in the `TODO` file.

• How to create slick, source-based docs with the AsciiDoc tool suite. As much as I like MoinMoin markup, the wiki engine itself isn’t amenable to being invoked from a build automation tool.
• GUI design with Glade, a slick RAD tool used by many free software projects.
• GUI interaction with PyGTK. I wrote a well-behaved worker thread that runs alongside the GTK main loop for the token simulator component.
• The theory and implementation of “Secret Sharing” schemes especially Shamir’s Secret Sharing Scheme (SSSS). We discarded SSSS in favor of the current “store-the-key-on-the-host, store-the-ciphertext-on-the-token” design.
• A handful of Python skills…
  • Finding a script’s location from within the script. Handy for using `bin/foo -> src/foo.py` symlinks in conjunction with external (e.g. Glade XML) resources.
  • Python’s built-in XML-RPC library. Reconciling UNIX socket semantics with thread semantics gave me fits before I switched to this IPC mechanism.
  • Steven Bethard’s superior argparse module which makes handling subcommands and required positional arguments a breeze compared with Python’s standard optparse module.

Creds101 is licensed under the GPL.

Here are the steps to grab the v0.1 source tarball from the hgweb interface and take the GUIs for a test drive!

$ wget http://unsyncopated.com/hg/creds101/archive/0.1.tar.gz
$ tar xzf 0.1.tar.gz
$ cd creds101-0.1
$ bin/creds101-simulator --gui &           # launch the token simulator
$ bin/creds101-admin-gui --use-simulator & # connect to the simulator

You can see our design notes, plans, and a list of similar projects at the wiki page but beware the outdated Secret Sharing content.

I’m accumulating all the research papers, datasheets, and application notes I’ve encountered during this project in a “research materials” repository. You might find the contents useful if you’re trying to choose an AES implementation for an AVR microcontroller or if your project falls into one of these categories: “cryptographic co-processor”, “hardware security module”, “embedded secret secret sharing”, “ubiquitous/pervasive computer security”, or “tamper evidence/proof”.

One of the software tools I’m using to do this is called cdparanoia. It’s a solid little app from the venerable Xiph.org multimedia project with an entertaining but informative console interface. An excerpt from `cdparanoia(1)`:

OUTPUT SMILIES
:-)  Normal operation, low/no jitter
:-|  Normal operation, considerable jitter
:-/  Read drift
:-P  Unreported loss of streaming in atomic read operation
8-|  Finding read problems at same point during reread;
     hard to correct
:-0  SCSI/ATAPI transport error
:-(  Scratch detected
;-(  Gave up trying to perform a correction
8-X  Aborted read due to known, uncorrectable error
:^D  Finished extracting

PROGRESS BAR SYMBOLS

    No corrections needed
-   Jitter correction required
+   Unreported loss of streaming/other error in read
!   Errors  found  after stage 1 correction; the drive is
    making the same error through multiple re-reads, and
    cdparanoia is having trouble detecting them.
e   SCSI/ATAPI transport error (corrected)
V   Uncorrected error/skip

The interface is a testament to the poor reliability of the little plastic discs. I’ve found, however, that I’d rather learn of a fatal scratch on some rare dub reggae disc from it rather than by a Zsh core dump message.

The UI also uses an interesting variation on the throbber/baton: main.c – cdparanoia-3.10+debian~pre0.

Long live the console.