SparkFun Forums 

Where electronics enthusiasts find answers.

Have questions about a SparkFun product or board? This is the place to be.
By jonkuhn
#76560
I'm looking for some feedback on my project and thought the people here may find it interesting. I found these forums very helpful while working on the project.

http://jonathankuhn.com/usb-password-manager/
(No advertising or anything, just my project page)

I have developed a working prototype of a small USB device that is a cross-platform password manager. It appears to the PC as a USB mass storage device and a USB keyboard. Virtual files on the USB mass storage device are used to enter the master password and to configure the stored password data. The keyboard function is used to "type" the passwords for you. You select which password to enter by using physical buttons on the device.

All password data is encrypted using AES-256 encryption in CBC mode using ESSIV. The AES-256 keys are derived from the master password using PBKDF2 (with HMAC-SHA-256), however less iterations are practical on the 8051 microcontroller than would be practical on a desktop PC.

If you check it out please let me know what you think.

-Jon
By Voelker
#76573
This is a great project !! This kind of stuff could be very usefull for any network administrator. You may try to have a way to update the passwords on the key remotely. This way a network administrator could provide passwords with no need for the user to know all the password, just the main one. Great product, let me know if you intend to sell some.

Thanks
By billroy
#76581
...and of course the pictures raise the question: is that an AVR in there? What are you using for the USB stack?

Inquiring minds...

-br
By signal7
#76584
One thought: would it be possible to use software to select which password is to be entered? The reason I bring it up is because moving parts tend to be the weakest portion of any electronics product and software control would make it less prone to breakage by the end user. Of course, if that limits the cross-platform goals, it could be a deal breaker.
By jonkuhn
#76586
You may try to have a way to update the passwords on the key remotely.
That is an interesting idea I'm not sure exactly how it would work. You could definitely write an application to operate on a bunch of devices plugged into a single PC, but that isn't really remotely. I guess since the interface is all through mass storage it would also be easy to write an application that you ran on each user's "home base" PC that transparently updated it in the background. What do you think?
...and of course the pictures raise the question: is that an AVR in there? What are you using for the USB stack?
I am using the Atmel 89C5131 8051 architecture USB microcontroller. I started developing it using a development board that I bought for this micro a while back.
One thought: would it be possible to use software to select which password is to be entered?
My thought on this, that I had planned to implement, is to have a file that listed all of the username and the user could put a * next to the password to enter. You'd still probably need a button to trigger it to type the password. I've thought about trying to use the caps lock/num lock/scroll lock LEDs for user input as well because I've noticed, at least on Linux, if those keys are pressed on the main keyboard the information is relayed to all keyboards.

I've also thought of trying to embed software that would run on the desktop into the device to hide the "virtual text file" user interface from the end user. I'm not sure at what point you might as well just use a software password manager program though.
By jonkuhn
#76616
Voelker wrote:Great product, let me know if you intend to sell some.
I'd only make the investment producing them in quantities and at a price where I could sell them if I felt there were enough people interested in purchasing one to justify the risk. There's also certainly work that would need done to polish the implementation before it would really be an accessible product.

For anyone who thinks this is something they would purchase, please drop me a line via the contact form on my website (http://jonathankuhn.com/contact). I'd also be interested in knowing what you think the retail price would need to be.

Thanks,
Jon
By frank26080115
#76671
how much memory do you have left on the AT89C5131?
how much memory do you think you can add to it? if you have about half a megabyte, a simple C++ program like
Code: Select all
#include <iostream>
#include <fstream>
using namespace std;

int main () {
  ofstream myfile;
  myfile.open ("unlock.txt");
  char pass[256];
  cin.getline (pass,256);
  myfile << pass;
  myfile.close();
  return 0;
}
will fit, with a bit more work you can probably mask the password

edit: bleh, probably not the best idea in the world, still trying to think of a driver-less way of implementing a masked password box
By jonkuhn
#76689
how much memory do you have left on the AT89C5131?
how much memory do you think you can add to it? if you have about half a megabyte, a simple C++ program like will fit, with a bit more work you can probably mask the password
edit: bleh, probably not the best idea in the world, still trying to think of a driver-less way of implementing a masked password box
I was thinking of trying something like this, but haven't done it yet. The current solution to mask the password is to slide notepad off the right edge of the screen :lol: The AT89C5131 only has 32 KBytes of program memory and I am using 46%. It'd be very difficult to get a EXE created with a standard compiler that small, but it may be possible to write something in assembly that is pretty small (http://www.phreedom.org/solar/code/tinype/), so I may look into that.

I am also using a AT24C128B I2C EEPROM chip for storing the encyrpted password data. I could possibly get a larger one or another non-volatile memory chip.

If I write a host executable and embed it in the device, what is the benefit of having the hardware at all? The best thing I can think of is that it may be more secure since it wouldn't leave remnants of password data around in memory (unless of course you are configuring the password data in which case it would be in the OSes disk cache). And I suppose "power users" could drop down to using the text file interface if they couldn't run the software in a certain environment.

:idea: Challenge Response Authentication
The application of the technology that I think may end up be most useful is a challenge response authentication scheme. You would register an encryption key with the service you want to authenticate to and you would also store that key in the device. Then to authenticate they would give you a string of text and you would paste it into a file on the device and save it. The device would encrypt it and type back out the encrypted data. Then you could give the encrypted data back to the server and it could check if the encryption result was the same as the key they have on file, if it is, you have authenticated successfully. Maybe you would also SHA-256 hash the encrypted result to guard against a known plaintext attack. The challenge-response system maybe could even be a real product.

This would be an alternative to other one time password solutions such as the Yubikey (www.yubico.com), Where there is only one embedded encryption key, so you have to trust all services with the key. Aside from possible IP issues, I could probably implement something very similar to the yubikey but that could have keys for multiple services.

The other big thing I want to look into is if all OSes relay the status LED information to all keyboards, because that may make it possible to use the scroll lock key on a real keyboard to trigger the device to type passwords. Then I could have no physical buttons on the device making it smaller and easier to produce.

-Jon
By jonkuhn
#76697
It seems like the keyboard LED features are consistent across Windows and Linux. Although it seems depending on the configuration of the PC certain LEDs may not get toggled. On my Linux PC the scroll lock LED doesn't get toggled, and on my Windows XP laptop the num lock LED doesn't get toggled (probably since it doesn't have a real numeric pad).

So I think I am going to make these usability improvements, which will also remove the need for all physical buttons:

There will be a file that lists all password identifiers and the user will put a * next to the one they want to have entered.

When the caps lock, num lock, or scroll lock is toggled it will enter the password. For caps lock, there will be some special actions taken because you want to type the password with the caps lock off. I may also use some timeouts in a couple places to keep from inadvertently activating it.

What do you think?

I guess I know what I am working on this weekend.... 8)

-Jon
By jonkuhn
#76849
Today I successfully implemented two new features that allow the device to be used with no physical buttons:

1. The user now selects passwords by first opening a file that contains a list of the usernames/identifiers. Next the user places a * on the line with the username/identifier for the password they wish to use and then they save the file.

2. To trigger the device to type passwords the user taps the num lock or scroll lock key on their main/"real" keyboard twice. My device detects the LED status that is reported to all keyboards by the OS.

I am still looking into finding a secure challenge-response authentication system. At minimum I would need to analyze the idea I had much further, and with crypto stuff it is always better to use something established so I will probably try to find an existing protocol.

-Jon
By frank26080115
#76878
hey since you are making a fake mass storage device, why not have the volume name be a question and the user has to double click on a fake file with the answer as the file name?
By jonkuhn
#76886
frank26080115 wrote:hey since you are making a fake mass storage device, why not have the volume name be a question and the user has to double click on a fake file with the answer as the file name?
I see a couple of problems with this: The first would be that it seems like there would be too small of a number of possible responses to provide security. The second is just a technical issue. The device cannot detect when the user opens a file because the OS will cache the contents of the disk. Basically you cannot change the data the user sees during a session of using the device except for when the user writes to the device, in which case the OS obviously caches the data that the user wrote. The OS could cache writes as well and execute them later (which would cause problems for me) but in general they are not configured to do this for removable devices.

The challenge response feature I am talking about would no be to authenticate to the device itself. It would just be an added feature to support services wanting to offer a "second factor" of authentication. You'd still enter your password on a server but the server would also give you a challenge string and you would have to provide the correct response string.

For authenticating to the device I think the master password entry that I have works well (other than that it doesn't mask the password), which I may write a small host software application for.

-Jon
By frank26080115
#76915
jonkuhn wrote:
frank26080115 wrote:hey since you are making a fake mass storage device, why not have the volume name be a question and the user has to double click on a fake file with the answer as the file name?
I see a couple of problems with this: The first would be that it seems like there would be too small of a number of possible responses to provide security. The second is just a technical issue. The device cannot detect when the user opens a file because the OS will cache the contents of the disk. Basically you cannot change the data the user sees during a session of using the device except for when the user writes to the device, in which case the OS obviously caches the data that the user wrote. The OS could cache writes as well and execute them later (which would cause problems for me) but in general they are not configured to do this for removable devices.

The challenge response feature I am talking about would no be to authenticate to the device itself. It would just be an added feature to support services wanting to offer a "second factor" of authentication. You'd still enter your password on a server but the server would also give you a challenge string and you would have to provide the correct response string.

For authenticating to the device I think the master password entry that I have works well (other than that it doesn't mask the password), which I may write a small host software application for.

-Jon
I understand the caching that takes place but i doubt the OS will cache every file, perhaps just the file table and maybe some more after that.

How about if you rename a file as the answer to the question? I do believe modern OSes automatically "optimizes" USB mass storage devices "for quick removal" (option from the windows device manager), caching might not be a problem.

Can I buy a spare prototype? I live in Canada and I have PayPal.
By inventore123
#76929
How about if you rename a file as the answer to the question? I do believe modern OSes automatically "optimizes" USB mass storage devices "for quick removal" (option from the windows device manager), caching might not be a problem.
Only Windows does that, and from XP SP3.
Older versions of Windows and Linux doesn't do that, because it decreases write throughput.
#76949
Take a look at http://www.splintered.net/sw/otp.

There are some new features since the last release such as a micro Radius server and the option to key in the challenge to the card. The control software runs under Unix now, as does the spyrus bootloader.

We have about 80 staff using this for remote logins with sshd or a SSL VPN.

--
mark

:idea: Challenge Response Authentication
The application of the technology that I think may end up be most useful is a challenge response authentication scheme. You would register an encryption key with the service you want to authenticate to and you would also store that key in the device. Then to authenticate they would give you a string of text and you would paste it into a file on the device and save it. The device would encrypt it and type back out the encrypted data. Then you could give the encrypted data back to the server and it could check if the encryption result was the same as the key they have on file, if it is, you have authenticated successfully. Maybe you would also SHA-256 hash the encrypted result to guard against a known plaintext attack. The challenge-response system maybe could even be a real product.

This would be an alternative to other one time password solutions such as the Yubikey (www.yubico.com), Where there is only one embedded encryption key, so you have to trust all services with the key. Aside from possible IP issues, I could probably implement something very similar to the yubikey but that could have keys for multiple services.

The other big thing I want to look into is if all OSes relay the status LED information to all keyboards, because that may make it possible to use the scroll lock key on a real keyboard to trigger the device to type passwords. Then I could have no physical buttons on the device making it smaller and easier to produce.

-Jon[/quote]