project idea: portable password safe
edorfaus at xepher.net
Fri Sep 6 19:13:26 EDT 2013
On 09/06/2013 07:18 PM, Werner Almesberger wrote:
> I've been thinking for a long time about making a portable password
> safe device. I originally thought of using the Ben for such a purpose,
> but it has some properties that would be undesirable for such a role.
> I wonder if there may be interest in building a small computer
> designed specifically for such a purpose. Besides such a project being
> highly Zeitgeist-compatible, I think we now also have accumulated
> enough skills and know-how to actually be able to make it happen.
I like this idea.
It could be improved by also supporting things like ssh private keys,
but I assume that doing that would be far more complex than only
supporting passwords, so it is best left for a later version.
> The device would have a small display, a (tiny) keyboard, USB host
> and USB device, and RF (802.15.4, to keep things simple and cheap).
This made me think of another (fairly recent) RF standard I've been
interested in, named DASH7 - it's optimized for very low power
operation, and bursty transmissions (which should be fine for this kind
of use), and there's an open-source RTOS-based implementation that
helped to shape the standard.
I haven't actually done any real work with it yet though, so I don't
know if it would actually be a good fit here.
> USB device would be used for a HID device to "type" things to a PC.
> The source of such keystrokes would be a) an account record, b) the
> device's keyboard, c) a keyboard connected via USB host.
I did some work on reading characters from a USB HID keyboard recently
(well, an emulated one technically, kinda like this device), and the
experience taught me some things that are worth being aware of.
Most importantly for this use case, is that the USB HID keyboard
protocol does not allow for sending characters at all.
It only allows for sending keypresses (and releases), which is not quite
the same thing, as that only tells you which key (or combo) was pressed,
not what character was printed on that key.
This means that the device needs to know which keyboard layout is in use
on the PC it is talking to, and the keyboard protocol doesn't give it
Now, *most* people use a QWERTY keyboard, which usually has the most
important keys in the same places across the various national variants
(specifically A-Z and 0-9), so we could just limit ourselves to those
(at least per default), but that means we can't use any "special"
characters (like minus or colon) in the passwords.
That's not really a good idea, as having complex passwords is one of the
main reasons to have a password safe in the first place.
One potential workaround for this would be to not use a built-in
keyboard, but use whatever keyboard you would normally use to enter the
passwords - just connected to the device instead - then the device could
just save the keystrokes instead of the corresponding characters.
Unfortunately, there's several problems with that workaround, which
makes it far less than ideal, e.g. consider what happens if you move to
a different PC with a different keyboard layout, or simply want to show
the password on the device's screen.
So, just to reiterate, the only real solution (that I know of, and that
doesn't require custom driver installation) is to make the device aware
of which keyboard layout is in use.
The easiest way to do that would probably be to make a setting for it.
> Instead of a USB device, the password safe could also use RF to send
> the (encrypted and traffic-shaped) keystrokes. USB host would in this
> case also be used to "pair" (set up a shared secret) RF dongles with
> the password safe.
I assume the RF dongle would, again, appear as a keyboard to the host?
Basically making the RF part just a replacement for the USB cable?
> Does that sound useful ?
It does to me.
I'm not sure how much I'd use such a device myself (maybe, maybe not - I
do have a software equivalent at work, but mostly for the ones I use
rarely, and notes on each), but I'm hardly typical. Even if the final
device ends up not seeing much use, though, I still think it sounds like
a useful project, even if only as a learning experience (or to prove
that we can do it).
It needs to be reliable, though - this means that it must work when it's
needed, and it needs to have a long battery life.
Even if it's a common battery type and they're easily replaceable, noone
wants to swap out batteries often, and especially not in something like
More information about the discussion