USB Password Manager
Prototype devices and PCBsDates
- First Public Announcement: July 4, 2009
- Functional Prototype: June 2009
- Began Development: January 2009
Goals
The primary goal of this project was to learn about the process of designing a small hardware device from start to finish, including expanding my knowlege of embedded software development, the USB protocol, symmetric key encryption, and PCB design.
The goal for the device itself is to be a cross-platform USB based password manager that requires no special software to be intalled on the computer it is being used on. I have some ideas, which are not yet implemented, to also add other authentication features to the device.
Please, tell me what you think about this project.
Description
File used to enter master password and unlock device. To mask the password the window can be moved off the edge of the screen.The USB password manager is a small USB "dongle" with three buttons on it. (the prototype is about 1 inch by 3 inches) It appears to a PC as both a USB keyboard and mass storage device. When the device is plugged into the computer it shows up as a "virtual" hard drive containing a plain text file called "unlock.txt".
To unlock the password data stored in the device, the user will enter their master password into this file and save it. The device will then simulate a USB detach and attach and re-enumerate as both a keyboard and a "virtual" hard drive (this time with a file called "data.txt"). All password data on the device is encrypted using AES-256 in CBC/ESSIV mode with keys derived from the master password using PBKDF2 with HMAC-SHA-256.
UPDATE: No More Buttons! (July 12, 2009)
Once the device is unlocked, a text file called data.txt will show up on the virtual hard drive. Each line in this file represents a "slot" in the password memory of the device. Initially, each line will contain the username/identifier for the password that has been stored on the device in that particular "slot". To select the password to use, the user simply types a * character in the file next to the username/identifier for the desired password and saves the file. Once the user has placed the cursor into the field where the password should be typed they will tap the scroll lock or num lock key twice on their main ("real") keyboard to trigger the device to type the password. These two new features allow usage of the device without the use of physical buttons on the device.
To configure the password data stored on the device "data.txt" is also used. To configure a slot the user will type the name to identify the password and the password itself, separated by whitespace, on a line in the file. When the user saves the file the password memory will be updated by the device.
Please, tell me what you think about this project.
OLD User Interface: Physical Buttons on the Device
The following describes a previous version of the user interface to the device
Cycling through password identifiers (usernames) and selecting a password.
Entering new password data into the device.Once the device is unlocked, the user can use the physical buttons on the device to cycle through the passwords stored on it. As the user presses the up and down buttons the device will "type" text to the PC just as if the user had typed it at a keyboard. This text is the name the user has associated with a password (usually the username or the username with an extra note appended). As the up and down buttons are pressed again and again, the device will backspace away the name it typed previously and type the next one in the list. When the user sees the name associated with the password they want to use they will press the enter button on the device which causes it to type the password itself into the PC.
The user can configure the passwords stored (and the name associated with each of them) by using a file called "data.txt" that shows up on the "virtual" hard drive after the device has been unlocked. Each line of this file will appear blank when the user opens it. Each line represents a "slot" in the password memory of the device. To configure a slot the user will type the name to identify the password and the password itself, separated by whitespace, on a line in the file. When the user saves the file the password memory will be updated by the device.
Status
I currently have functional prototypes of this device. There is more work to be done in cleaning up the firmware code. I have also considered adding support for one time password and/or challenge-response authentication schemes. Once I have gotten a chance to clean up the firmware code, I may consider releasing the firmware and hardware designs under an open license.
I would only consider having these devices built on a larger scale if there were enough interest from people wanting to purchase them such that it would justify the costs.