800MHz ARMÂ® processor
How am I supposed to watch porn on that thing?
Stream to another device? Connect via X11 or VNC (and sacrifice the resolution/framerate)? Many possibilities within the bandwidth limit of the USB 2.0 interface. Easier with static pictures and text, though.
Maybe USB display.
The number of GPIOs is atrociously low. Otherwise it looks rather good.
The i.MX53 has one USB OTG port and three USB hosts. It would be good if at least one or two was available on some sort of header.
It also has a choice of video outputs and a camera input. A display port could allow using it as a secure module. With e.g. a touchscreen it would allow e.g. PIN unlock. It has a keypad port, too.
It has I2S ports (if available, the unit could be used as a secure phone, but the same can be done with a USB headset, but that needs a port).
The built-in security accelerators are interesting. With two USB ports it could act as a nice e.g. internet connection proxy.
That said, it’s a pretty good beginning and the chip’s features are promising new features in further versions. Also, to look at the unused potential from the other side, kudos for resisting the temptation of feature creep.
…but at least two more USBs would be nice…
…also, for a security platform, a roadmap towards some tamper-resistant or at least tamper-evident design would be nice too…
Feature creep is definitely to be avoided; but the one thing that gives me a case of skepticism-eyebrow strain about some of the potential features foregone is that this is supposed to be a ‘security’ device.
Yes, with a dash of the right software, you can do all sorts of crazy things across just the USB connection between the host system and this module; but a great many of them require trusting the host system if they are to be of actual use.
USB2 is more than fast enough to treat the host system as little more than a thin client; but it’s still a thin client running more than enough untrusted software to sniff and report absolutely everything coming in or out of the USB device, which might be a problem.
It just seems rather overpowered and vaguely focused if you want a smartcard/SIM style device for securely generating and storing cryptographic materials and performing a few low-bandwidth operations for signing, challenge/response, and the like; but too dependent on the host system to implement much more than that without putting some (quite possibly misplaced) trust in a variety of interfaces provided by host software(that may or may not end up existing in usable shape).
I certainly admit that I may be succumbing to pessimism for want of creativity; but it just seems to fall into a slightly confused gap between several categories of device, jack of all trades, master of none.
It’s too punchy and expensive(in cash and power) to fulfill the basic secure token job, it’s too dependent and I/O constrained to do a fair number of potentially useful things without trusting the host it is connected to to some degree, and for low-level-doing-really-mean-things-to-USB purposes, you want something like a facedancer, which allows you to use a full computer to load and control the malice for power and convenience, or (once the malice is finalized) something disposably cheap and not at all suspicious looking, probably based on a reflashed commercial USB device.
I guess I’m just not certain where this one is supposed to fit.
For security, the lack of I/O ports is a serious problem - Ian Goldberg’s comments years ago about what you need for a security dongle were that you need input you can trust (at least a digit-pad that doesn’t go through the untrusted computer), and some output you can trust (an LED could blink numbers or Morse code, but that’s annoying - at least 1-4 digits would be a big help.) They could get the input by adding another USB port for a keyboard, but if you have to solder it yourself, you’re looking at a hobbyist board, and there are lots of those already.
The price seems rather high compared to similar-horsepower boards (e.g. BeagleBone Black for $50-55, Raspberry Pi B for $35), and the main advantage it provides is that it’s a bit smaller, in return for having fewer I/O ports, so it fits in a single stick as opposed to a credit-card-sized board with a cable. But the BBB and RPi B/B+ can connect to an HDMI monitor (if you need a real display) and have spare USB ports.
Or if you can jailbreak a Chromecast, $35 will get you an interesting platform as well, though it probably wants to get power from the HDMI, not the USB, so it wouldn’t exactly be a replacement.
The device is not primarily meant to be used for its GPIOs, we broken them out because we could painlessly do it without affecting its form factor and to provide UART, SPI, I2C and possibility of interfacing. But its security purpose, rather than DIY maker culture, meant that we intentionally didn’t over do it in this area (there are far more powerful and cheaper options for such specific applications anyway).
Breaking out a USB host would have meant to risk shutting down the whole port if the USB device would drain more power, also it didn’t fit one of our primary usage goals. Maybe future versions might expand on this, but certainly not the first one.
The device can act as an internet connection proxy without a separate USB host port or connection, we already use it as a Tor/OpenVPN router and anyway you can securely run your clients on the device itself (using the USB host just for I/O) as it is powerful enough. Its lack of other interfaces is intentional.
The trust that you need to put on the USB host can be severely minimized depending on the application. Of course at the end of the day in most cases the USB host will be used for I/O but at least private key material (VPN certs, SSH keys, BitCoin private keys, etc) can be safely stored (and used) on the USB armory without compromising it to the USB host.
For instance when using it as encrypted storage you assume that the unencrypted file is coming from an external source anyway, so by transferring the file from the host to USB armory for encryption the security of the whole process remains the same.
Same thing goes with VPN/Tor etc.
The pin header would also allow trivial connection to an alphanumeric PIN pad, we might just build an open source one so that passwords/PINs can be input externally. This is quite feasible.
We carefully considered not over-engineering the device, keeping it minimal, simple, open but flexible enough. To me (of course I am biased here since I am one of the designers ) the price of the device justifies Tor/OpenVPN, password manager, SSH proxy, BitCoin wallet functionalities on their own and these are perfectly accomplished by the device.
You mentioned the Facedancer, we use it and we love it. It is a fantastic board. However it currently sells for 125 USD on int3.cc and if you want to assemble it on your own in very low quantities it would still cost 90 USD. For 130 USD the USB armory accomplishes the same tasks and so much more. So I think the price is actually fair.
For secure comm, consider breaking out more of the serial ports, maybe with an optional add-on “shield” with USB-UART converter. Serial communication is way easier to monitor, which may be important for security auditing. The kernel code is simpler and easier to check, not the USB mess of protocols and too many thousands of badly audited code (always assume code is badly audited, see some recent mishaps in bash and SSL for how code trusted for years can harbor a pinhole). The userspace handling of the comm then has to be also written well, but a simple enough suitably restricted application can make the attack surface small enough to be auditable with reasonable work/time/money budget.
With enough of them, one of the interfaces can even be used for attaching a tiny microcontroller handling a small display and a keypad (assuming breaking out the keypad pins from the CPU itself would cost too much of the board’s real estate).
You may like to consider being hack-friendly and break out some of such additional signals to little solderable “test pads”, a compromise between pad size and ease of use (the chip is the annoying BGA, if it had pins along its edges it’d be doable even without modding); if applications appear, you can always break them out to real connectors in a later revision.
A thought I had for a PIN is a long non-bruteforceable code stored in a tamper-detecting microcontroller, which handles the keypad and returns the long key instead of just dumb relaying of the keypad data. Too many bad attempts to enter PIN, one duress code entered, or attempts to tamper with the unit itself (unauthorized move, attempt to open, left alone for too many days…) and it forgets the long key. Such microcontroller can have only very low power consumption, and can last on a supercap for days to weeks or on a coin cell for years. The adversary then has a pretty good chance of tripping the key-erasing during unauthorized manipulation (consult the usual electronic-evidence securing procedures to find a detectable set of events, this is how a very careful, high-threat, schooled adversary will proceed).
Another thought… what about attaching a “dumb” keyboard/screen, so the thing can run without a host computer? So the plaintext may never touch the host at all? (This is also doable via a serial terminal. Files then can be read/written over the terminal in plaintext, and every other access from the host computer then handles only the ciphertext.)
For a router/proxy, what about using the chip’s Ethernet interface? There is a possible use-case with the device used as a red/black separator, and comm monitor/auditor.
Even better it might be possible to invert the role of the USB port (from device to host), attach to a hub and natively use keyboard and USB displays (I have at least one and it is supported by Linux). I have to check if the SoC allows us to do this, but it might be possible. By the way currently we connect to the UART on the pin header with this (https://www.sparkfun.com/products/10527) and this (https://www.sparkfun.com/products/12977) without any issues.
I’d love to break out as much as I can, there is a lot to break out, have to compromise with the size however. Maybe one day we will offer two versions, a bigger one with more breaking out.
Again, it already acts as a router/proxy without the need for Ethernet. We can put Ethernet on it but that would be an entirely different class of product in terms of purpose and size
Anyway, I see a lot of possibilities, so I am looking forward to launch this and see what the future holds.
Thanks for all the feedback! .
That’s quite possible. USB-OTG should be able to act in both device and host mode. You may (or may not) need one more pin for the USB ID pin as defined on the microUSB connector for the OTG spec but I am not certain about it.
Consider two concurrent possibilities that may be possibly done with the current size of the board.
The current holes for the breakout pins are taking both sides of the board. You could use pads of the same size, without the hole, so a header can be soldered flat, one from each side (resp. a two-line header pin). Voila, 7 more pins for no added size cost, so potentially you can have all four UARTs there. Or two UARTs and two USB. Or so. Would also allow putting in the headers without having to compromise on the thickness, as they’ll be in-line instead of sticking out (the bent ones would work but don’t have enough space on the board edge for the support of the plastic they are in; but that’s a small wart, not a show-stopper).
For this approach you’d have to rotate the microSD holder by 90 degrees so the header pins won’t be in the way.
Alternatively, don’t rotate the card, drop the holes, and use 1.25mm-pitch pads on the non-card side for a two-rows 2.54mm SMD header. The kind used on e.g. old IDE hard drives (newer than what used the through-hole ones). A ribbon cable can also be directly soldered to them.
I did not read the IO mux section of the datasheet, beyond knowing that some pins’ functions are shared between different peripherals. Breaking out these may allow more potential functions with the same pins. But that’s a choice to do; e.g. lacking an I2C is only a minor annoyance if you have GPIOs to bitbang.
The second possibility is more involved from the end-user side. Use those little 1mm round or square test pads so the more advanced users/developers can attach things with thin wires. I did some soldering on chips with 0.5mm pitch pins so it is doable. This also lets you having the pins scattered all around the board, wherever they fit, without requirement to be neatly arranged on one side. I do this routinely on my designs (way less hightech than yours - no BGA, for example, and just microcontrollers); when I have a spare pin, and at least a little piece of free board area, I break it out to a solderable pad. It costs nothing and may be handy some day.
If the pads are in a line with suitable pitch, even a SMD breakout connector could be attachable, for a daughter board or that kind of a thin flat kapton-based foil cable so common in today’s portable electronics. But I am not sure how much better it’d be for the first-gen in comparison with individual pads scattered around according to what routing was easiest. There’s quite some space on the SD card side of the board, under the square chip on the USB side. (Disclaimer: I don’t see the copper layers so don’t know how clogged the routing there is, so it may as well not be possible.)
If the host computer acts at the same time as an internet uplink, and shares both the red and black data, and the USB dongle just acts as a red/black converter, it is a much less secure arrangement than if the dongle physically separates the red and black zone.
Or just break out the pins to solder pads and provide an unofficial guide for attachment of the connector and the magnetics. Next to no added effort, and suddenly you have a board ready for prototyping a “grown-up” security proxy. Or an ethernet-attached secure node (e.g. for document signing, or authorization (Kerberos server?), or so.
Just some thoughts to pick or leave…
I dislike using pads, the header allow to use it without having to solder something on the board, which I think is very important.
All USB hosts are very likely to have other means of connection, if you assume that the software on its side is misbehaving then having USB armory with its on interface, rather than routing in/out of it, then doesn’t help in principle. Also running clients on the USB armory itself mitigates this and it fits the intended use and horsepower of the device.
So while I don’t strictly see the reason to break out more I take all the feedback and I promise that a future version, if we make one…and I hope so ;), will try to add even more flexibility and accommodate what you are asking :).
Headers are the best. Pads are the admittedly distant second best.
Tiny pads you need a magnifying glass or a stereomicroscope to access are the still pretty good third best; even they are way way better than the frustration of wanting to access a pin and not being able to because it is the G18 one somewhere under the BGA, buried in underfill.
As the representative of the old school, with soldering iron on standby, I consider the difficulty of a nominal size solder joint to be zero and the difficulty of a tiny one to be twice that. But I also readily admit that it’s just me.
I agree that for something that is intended to be used often and by many, no-soldering is an important feature. But there is the long, thin tail of higher-skill people with potential of breaking a new ground and using things in unintended ways for whom even a tiny-but-accessible pad is a significant enabler.
Especially in the age of BGAs, aka Bloody Goddamn Annoying. I got a pair or so of cheapo GPS modules left over from some project and while the chip has a pulse-per-second output, whose edge can be used as highly accurate timebase for syncing e.g. data acquisition units, it is hidden underneath the chip and has no way to be accessed. The module itself has only the Rx/Tx lines, which are good for position and approximate time but not for high accuracy it COULD have if there was a single little pad! Unbelievably frustrating!
I don’t understand, please rephrase?
That’s true. However, you need to access the thing via a terminal or other means, and then it is where the quick sand appears.
We have red data, the plaintext we work with. The red data are in a terminal window, vulnerable to malware and keyboard sniffers. We work on them on the host computer, remoting into the Armory over the USB connection. The Armory itself then handles the red data and converts them to black, to send to the enemy territory aka the Internet. And sends them back via the host computer, the same where the red data are worked with, which is connected to the Internet.
The host computer is the problem here, its Net connection. With the attack surface of the operating system and all the applications that run on it (including but not limited to the browser, Adobe Acrobat reader, and java plugins), and the expertise on the side of NSA on one side, Chinese govt hackers on the other one, and Russian crime underworld pushing itself in from the third side, we can not just rely on it not being compromised. If we consider it trusted enough for red data, even in a terminal, we may be in for a rude surprise.
But here is something that even a lowly text-based microcontroller-handled terminal can do. Some minimal implementation of the terminal handling the red data. Your idea of using a USB hub with a keyboard and USB-monitor would work here, if we do not require being connected to the Net in real time, or if we use a modem over the serial line on the breakout header. Similarly, the same can be achieved by a VT100-class terminal (e.g. a netbook booted from a trusted, preferably readonly, USB dongle) on the serial line.
(Thought: Let the Armory act as a trusted boot device, too? Something that not only lets said netbook/laptop start from a known-good image but also can check the integrity of the files, e.g. running Tripwire on them and looking for changes? The serial lines or a second USB then can be used for attaching e.g. a cellular modem. Using the computer’s wifi or ethernet port is also possible but then we run into the red/black non-separation. (Thought: would that concern be mitigable at least somewhat by virtualization, running two computers on one, one for the red and one for the black data?))
The main problem with this kind of paranoia is that you never know if you are paranoid too much, and only sometimes and in retrospect when you weren’t paranoid enough.
…Edit: And, speaking about paranoia, we have the can of TEMPEST worms, in all their squirmy glory, which may however be better left for version 3 or 5. With the advent of cheap software-defined radio, this angle of security may become significant even outside of highly classified security/military scenarios…
Don’t embed auto-playing shit… this is fucking annoying!
@codinghorror is it possible to deactivate autoplaying in the bbs? I got totally deafened by the unnecessarily loud SFX on this embed.
Please, PLEASE, switch off the autoplay!
In the video URL, change the autoplay=true to autoplay=false, as soon as possible.
You do not, repeat do NOT, want to be noticed this way.
Edit: Idea: Given that the autoplay parameter is a fairly standard thing in many players, could the “autoplay=(true|1|yes)” be automaticky replaced with “autoplay=(false|0|no)” if detected in a url? @codinghorror, could this work? Can the embed URLs from the database be mined to find the top 5 or so of playback URL styles and make regexps for them?
BGAs are annoying for hand soldering but a great form factor for mass production actually ;).
Regarding my connection remark, you can route through the USB armory via VPN (host routes VPN server address, default gateway is USB armory) or Tor (host routes selectively as illustrated at https://github.com/inversepath/usbarmory/wiki/Applications). This means using the host as gateway for the USB armory.
Your concern is that the Net connection of the host computer is compromised. This can happen in several ways.
If you mean that someone intercepts the network connection from the host computer to the Internet this is not a concern if you route a VPN (or whatever encrypted tunnel) from the USB armory, as outgoing traffic from your host (which is routed through USB armory first) will be encrypted. Here USB armory is merely piggybacking on the host connection.
If you mean that the host computer is internally compromised and the fear is that someone can bypass the routing rules that force connection through USB armory…well at that point it’s game over anyway isn’t it? Your laptop would 99.9% of the cases have a wifi adapter anyway, so a compromise can in any case (even if USB armory would have its own connection) do exfiltration.
This is said just for the network part.
Concerning the input you are right, if you are 100% paranoid and you care protecting everything (not only passphrases but also the text) then yes, means of external input to USB armory would help mitigating that.
But as I said not only the pin header provides enough connectivity for that at this point (UART/GPIOs) but per your (and a few others) feedback we are also evaluating our options for either a self-sufficient docking station for USB armory, or a module that can bridge USB keyboard on the existing pin header. We shall see
We also already have the idea of using mass storage emulation to boot the host PC with a thin client for the USB armory itself (that can later change roles on the USB emulation), this is also a good way of re-using the host hardware while not trusting its software.
My concern is that the host computer is compromised. Securing the connection is easy, for just that you don’t need any external gadget - just run the software on the host.
Doesn’t have to be. (Though you then run the risk of the malware storing the stuff and sending it away later. But then you can stop that if only specific, allowed comm is permitted, when the Armory acts as a network proxy, and the unauthorized comm can be detected, betraying the malware.)
The laptop also has a mechanical switch that disables the wifi hardware. Most have them. You can also physically remove the wifi card when this is a concern.
Or go the honeypot way and attach a signal detector to the antenna (diode-capacitor-LED may be enough?) and watch for activity. And do a full audit if it becomes active when it shouldn’t.
But my main concern is keyloggers, remote-access trojans, and other malware that’s uncomfortably common.
Another concern, a bit more high-end and esoteric but a good model case, is the family of threats like Stuxnet, GhostNet, Red October, Turla, The Mask, Flame, and Regin.
Or, also, the Citadel.
Also, consider the uses of “trusted boot” for auditing of the host computer’s own software. The Armory then can act as a trusted device that stores the OS image that starts the host computer, checks key parts of its own operating system, and stores checksums for later comparisons. Something like Tripwire.
The thought with two computers running virtualized on one, one as red and one as black, may be worth examining. That way you could trust-boot the virtualization host, run it as red, and from it run the untrusted OS from the host’s own hard drive as virtualized and sandboxed. Would also alleviate the issues with the balance of security and comfort; for-comfort stuff can be run on the black sandboxed machine, secure stuff with the annoyances on the red one.
But I am too inexperienced with virtualization, and with its security aspects, to know about possible holes, so please consult that one. (And possibly everything else. And let me know if/where I made any mistakes.)
If you’re not worrying about the host computer getting compromised, you don’t need a separate piece of physical hardware at all; just run a virtual machine.
At minimum, you really need to have a button on the stick to say “let me update software from the current computer”, unless you’re going to do all your updates by removable micro-SD-card media (which actually isn’t a bad idea.)
This topic was automatically closed after 5 days. New replies are no longer allowed.