project idea: portable password safe
werner at almesberger.net
Fri Sep 6 18:04:46 EDT 2013
Bas Wijnen wrote:
>> 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).
> The Ben has all that (RF with your board), except for the USB host.
The Ben may be a bit too large to start with. Then there's the lack
of USB host. RF in the form of atben is way too fragile. This is a
device that should accompany you everywhere, which means that it has
to survive traveling in front and rear pockets of possibly overly
And the killer flaw is that I don't see how you could prevent a Ben
from getting compromised if left unobserved for a moment. E.g., if
you take the password safe to your work place, a sports club, etc.,
and leave it unattended from time to time, someone could USB-boot it
and install a key logger.
This could be made more difficult if we cut the USB_BOOT trace
somewhere near the CPU (that way, the infiltrator would have to
disassemble the Ben to get at the trace), but this would then make
the Ben highly brickable, since it has no reliable Flash protection
mechanism. This could in turn be prevented by cutting the write
signal to the NAND after flashing an MMC boot loader.
The next entry point for a key logger would be JTAG, which could
again be disabled by cutting traces, but things get rather hackish
by then. Also, if the board is expected to be full of cuts, it gets
harder to detect any more serious tampering.
With each step, the number of people who could pull it off decreases.
But even injecting a key logger via JTAG would still be within the
reach of quite a lot of people.
There's also the potential issue of reading the Flash. E.g., if we
want to store a secret key there. Such a key could be useful as a
master for all data the device handles, so that access to all the
data could be denied simply by erasing this one key.
Those little MCUs, on the other hand, all have what appears to be
decent protection against reading their Flash and also against
unauthorized changes, and some even against running code from other
sources than the Flash.
They may have NSA backdoors, bugs, side channels, and such, but it
would be a good first line of defense.
> But the only thing you seem to need USB host for is the keyboard, which
> the Ben has, too.
I was thinking of a scenario where the password safe would connect
to your regular keyboard. You'd type "through" it (with the ability
to inject a password when needed), with a more convenient keyboard
and not needing an additional USB port on the PC. But yes, maybe
that's not the most relevant use case. Maybe if you have a lot of
editing to do on the password safe itself ...
> I think having it run Linux might not be the best idea, because Linux
> is too complex; you couldn't really be sure that it doesn't do things you
> don't want.
That's one problem. Another problem is that most of the chips you
can get to build a Linux system expose low-level interfaces (memory
bus, etc.), creating possible paths for compromising the system.
This could be countered by using BGAs, placing all such traces under
the chips and then routing them through inner PCB layers, but system
complexity jumps up quite a bit if you do that.
With those MCUs, you can basically have your "trusted" core with
enough processing capabilities inside the chip. Much easier to
One big drawback of not using Linux is that you have to find or
write USB drivers and such, creating a parallel effort. That time
would be better spent hardening the drivers already present in
> Iris (my kernel/OS) would probably work really well for it, but it needs
> quite a bit of polishing before it can be used.
So far, I imagine the "OS" to be mainly an event loop and a lot of
interrupts :-) But much would depend on the USB stack. If there's a
good basic stack for some reasonably small and clean kernel, that
would make that a likely choice. There may also be a "generic" stack
in or near the libopencm3 project.
> If you use the sd-slot for RF, you lose this benefit, of course (unless you
> sacrifice the Ben, but that doesn't sound like a reasonable thing to me).
Yeah, the cheaper you can make the thing carrying the crucial data,
the less reluctant people will be to destroy it when they ought to.
An uSD card also has the benefit that it can be easily hidden, so when
traveling (you have almost no rights when crossing a border, as not
only the Miranda incident has shown), you could put a dummy card in
the password safe and hide the real card somewhere safe. Or travel
without the data and download the encrypted container over the
Internet upon arrival.
> Additionally, the Ben would be able to present itself as a pgp token, doing
> the encryption and signing and never providing the keys,
Yeah, it would also be nice if the system had the processing power to
be able to generate 2048 to 4096 bit RSA keys within a reasonable
amount of time. Just in case we'd have a use for that at some point in
> It would probably be possible to write a firefox plugin which would
> communicate this information to the device somehow.
Yes, the integration gap could be closed. A bit messy because we'd
probably need USB drivers for all the PC OSes (well, we could try to
"morse" it through the HID LEDs ;-), but certainly feasible.
More information about the discussion