Skip to content

Instantly share code, notes, and snippets.

@darconeous
Last active September 26, 2017 22:22
Show Gist options
  • Select an option

  • Save darconeous/8802ed22f6c7e0aad70b to your computer and use it in GitHub Desktop.

Select an option

Save darconeous/8802ed22f6c7e0aad70b to your computer and use it in GitHub Desktop.
Hardware encrypted USB drive concept #Security #Ideas #Hardware

Hardware encrypted USB ideas

There are hardware encrypted USB sticks on the market, but a few things make me uncomfortable about them:

  • They all involve running an executable on the computer you want to access the data from.
  • There is no standardized mechanism for how the app takes your password and communicates that to the microcontroller on the encrypted drive.

Instead of using a vendor-provided executable, I propose a mechamism which allows the encrypted USB drive to be securely mounted on any machine that has a web browser.

How it works

The mechanism uses a a special HTML page, which is opened from a virtual CD-ROM image when the drive is inserted. The user enters their passphrase into that page and clicks "unlock". The web page then sends the passphrase-derived key to the drive (using the mechanism described below). The microcontroller on the USB drive then unmounts the ISO and tries to open the encrypted volume using the key. If the key works, the decrypted drive is then mounted. If the key isn't recognized, the virtual CD-ROM image is re-mounted and the HTML page indicates the error (and, perhaps, the number of remaining attempts).

The passphrase would be processed via javascript into the passphrase-derived key and then communicated to the microcontroller by accessing special hidden files on the virtual CD-ROM image in sequence.

The directory tree would look something like this:

/.xxx/.[hex-address-of-byte]/.[hex-value-of-byte]

For example, to send the microcontroller the key 13 37 BE EF and instruct it to attempt to decrypt and mount the drive, the following files would be accessed:

/.xxx/.00/.13
/.xxx/.01/.37
/.xxx/.02/.BE
/.xxx/.03/.EF
/.xxx/.04/.mount-rw

After the last access the ISO is unmounted automatically and the key attempted. If it fails, the ISO is re-offered and the user can try again. If it succedes, the decrypted drive is mounted.

There are other commands in addition to .mount-rw:

  • mount-ro - Mount read-only
  • configure - Configure the drive (add keys, remove keys, wipe device, etc)

The system works by giving a virtual block to each of the files in the file system. Reading a specific block "chooses" the value for the associated byte position.

Other thoughts

When inserted, the microcontroller on the USB device generates a set of challenge keys (possibly using RSA or Eliptic-curve) and exposes them to the decryption JS app as a JSON file. Using an asymetric key encryption algorithm and a screen keyboard will allow for secure decryption on all but the most compromised of machines---but a simple mechanism where the password is fed directly to the microcontroller using the above mechanism should be secure enough for the majority of situations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment