project idea: portable password safe

Werner Almesberger werner at almesberger.net
Mon Sep 9 11:16:01 EDT 2013


Felix wrote:
> Wow, they're sooooo cheap! I said the LCD one because it has built-in
> character display, so it's easy (at least for me) to interact with it.

Everything is cheap in China ;-) The challenge is to find out if
it also works ...

> Also can be developed in the future a usb powered mcu with usb-host (again
> for keyboad plug-in) and radio that will communicate with the device :P

Regarding USB, there the the following options:

0) device only. This is what I drew in the block diagram.

1) unpowered OTG: constrains choice of MCU, but there are good and
   inexpensive MCUs with OTG now, and it'll only get better in the
   future. To attach a USB device, you need a Y cable that provides
   power from another source (e.g., a PC) and you lose USB device
   functionality while operating as host.

2) powered OTG. Add a boost converter for Vbat -> 5 V, but still
   require a Y cable and external power source if the device we
   connect draws more than very little. I.e., it would be fine for
   pairing a dongle but not for some/most/all(?) keyboards.

   A device that draws little power would be connected either via
   the same Y cable but without needing an external power source,
   or via a Micro-AB to A cable.

3) more power. Switch to a stronger battery, at least for keyboards.
   Since a stronger battery (AAA, AA) has a low voltage,
   a) the system would need to run a boost converter also while in
      standby, or
   b) we'd need to have two battery cells (yuck), or
   c) we'd add a second battery (CR2032) for standby (so that the
      MCU can listen for a wakeup signal and also maintain time).
   Being able to maintain time would be desirable for any "code
   token", e.g., TOTP (RFC 6238).

4) separate USB A receptacle. This considerably constrains the
   choice of MCU or requires two USB-capable MCUs. Power could come
   from
   a) an external source, plugged into the USB device port. So the
      password safe basically acts like a Y cable itself.
   b) a weak internal source (or an external source).
   c) a strong internal source (or an external source).

5) USB A receptacle plus dongle bay. This adds an empty space in
   the password safe's case to transport an RF dongle. This was the
   original proposal.

   A purely mechanical bay could also be added to any of the other
   designs, if there is room.

So, assuming we want to use this with power-hungry devices, each of
these solutions would require the following features:

Feature required	0   1   2   3a  3b  3c  4a  4b  4c  5
----------------------- --- --- --- --- --- --- --- --- --- ------
MCU USB			dev OTG OTG OTG OTG OTG D+H D+H D+H D+H
Y cable			-   Y   Y   opt opt opt -   -   -   -
AB Host cable (or Y)	-   -   -   Y   Y   Y   -   -   -   -
External power source	-   Y   Y   opt opt opt Y   Y   opt see 4*
Bigger battery		-   -   -   Y   Y   Y   -   -   Y   see 4*
USB A receptacle	-   -   -   -   -   -   Y   Y   Y   Y
Dongle bay		-   -   -   -   -   -   -   -   -   Y

1) would be an easy upgrade for the device-only design. People who
are comfortable with the treacherous safety of their PC as their
interface to set up the password safe and those who don't mind to
do such things through a possibly quite clumsy dial-and-push
interface would see no difference to solution 0).

Those who want the extra security of using a "dumb" keyboard would
be able to do that, but at the cost of somewhat messy cabling and
the occasional hunt for a power source.

Also pairing the dongle would require either trust in the PC, a Y
cable, or the use of an over-the-air pairing protocol.

I kinda like that for a first round. All the powered solutions
that don't also include a second port still need fancy cables and
thus don't really improve usability all that much. And the second
port is a bit of a burden.

Dropping the bay may have a usability impact. On the other hand,
it decouples the mechanical design of safe and dongle, which is
nice from an engineering point of view.

> Agree with that. I remember to see a curious design in TI documentation[3]
> using tactile sensors.

I'm a bit wary of capacitive sensors. I did a design that runs
from a unregulated battery, not too dissimilar from what we'd have
here, that uses a small sensor through some 3 mm of acrylic and it
performs very unevenly. But maybe it's just my algorithm that
sucks. Should look at TI's :)

BTW, their code [1] is under 3-clause BSD. None of that "use this
only with our hardware" others are so fond of. Nice.

Another drawback of having only a capacitative sensor is that,
when in standby, the MCU has to wake up from time to time to take
a sample and see if the user demands its attention.

- Werner

[1] http://www.ti.com/tool/capsenselibrary



More information about the discussion mailing list


interactive