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 flattering jeans. 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 defend. 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 Linux. > 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 time. > 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. - Werner _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
