USB Armory MkII

What the USB Armory MkII actually is

Plug a YubiKey in and it does the one thing it was built to do. Plug an Armory in and the host sees whatever you told it to be that morning. The USB Armory MkII is the second-generation open-source secure computer from F-Secure Foundry (now WithSecure Foundry) and Andrea Barisani's team, launched in 2018 and sold through Crowd Supply. The MkI ran a Freescale i.MX53 and was already unusually transparent for secure hardware; the MkII shrinks the design onto a single PCB the size of a flash drive, moves to the NXP i.MX 6ULZ, and adds a carefully chosen set of security peripherals: the NXP CAAM cryptographic engine, an ATECC608 secure element, a fully removable microSD slot, and an exposed JTAG/UART header for development.

That last item is worth pausing on. The debug header is what makes the device developable and it is also an unauthenticated door into a running system for anyone holding it, which is precisely why the fuse-locked boot chain exists and why leaving a device unfused is the most common mistake made with this platform. Underneath, the Armory is a full ARM Linux computer — 900 MHz, 512 MB of RAM — that presents to a host as any USB device class you choose: mass storage, network, HID, serial, because the i.MX 6ULZ controller supports full device-role operation. That generality is the whole platform, and the reason nothing else really occupies this category.

SoC, peripherals & the open-hardware reality

The i.MX 6ULZ is a deliberately boring chip choice, and that is the point. A single Cortex-A7 at 900 MHz, ARMv7-A with NEON, TrustZone, an MMU, 32 KB L1 and 128 KB L2 — old enough that the research community understands the silicon and its published weaknesses, new enough that NXP still issues errata and lifecycle support. You give up performance for that: this is roughly Pi Zero-class compute, and any workload that wants throughput is on the wrong board. The on-die CAAM (Cryptographic Acceleration and Assurance Module) implements AES-128/192/256, 3DES, RSA, ECC on P-256 and P-384, SHA-1/2 and a hardware PRNG, with a key-encryption-key tree rooted in fuses that the application core cannot read out. Keys derived that way are bound to that individual device — which is the security property and also means a dead board is a dead key, so anything you seal this way needs a recovery story written before you fuse it.

The CAAM matters because it is the only secure crypto engine you can realistically drive from your own bare-metal Go runtime on hardware you can buy. Foundry's TamaGo project — a Go compiler and runtime targeting ARM bare metal, no kernel underneath — was built for this device and has since been picked up by other hardware-rooted secure compute projects. Add the ATECC608A secure element, holding ECC P-256 keys the i.MX itself cannot read, and a fuse-locked HABv4 boot chain, and you get one of the few devices where "this key has never been in memory anything but the CAAM could reach" is a defensible sentence rather than a marketing one.

Schematics, PCB layout and bill of materials are published in full. No NDA-gated components, no unreplaceable signed blobs in the boot path, no closed-firmware co-processor sitting quietly on the board. That is rarer than the phrase "open hardware" suggests — most devices carrying the label close the boot ROM or hide a management core. Two honest limits remain: the i.MX boot ROM itself is NXP silicon you take on trust, and open schematics tell you what was designed, not what came off the line, so supply-chain assurance still needs your own inspection.

Software stack — TamaGo, GoTEE and INTERLOCK

Three reference stacks ship with the device, each aimed at a different deployment profile. The choice is really about how much operating system you are willing to trust, and it is not reversible cheaply once you have built on one.

TamaGo earns its own paragraph. It is a Go runtime executing directly on bare metal — no Linux, no microkernel, no RTOS. Compact, audited, with drivers for the i.MX peripherals you care about (USB, CAAM, GPIO, I²C, SPI), and it lets you ship the entire firmware as one statically linked Go binary. Where a full Linux distribution's attack surface is unacceptable — HSMs, hardware wallets, code-signing appliances — that changes the shape of the problem. The binary you sign is the whole executing surface. No shell, no package manager, no privileged daemon waiting to be misconfigured. The cost is everything Linux was giving you for free: no package ecosystem, no strace when something misbehaves, and any peripheral without a TamaGo driver is a driver you are now writing.

GoTEE is a TrustZone-aware monitor running two TamaGo binaries — one in the Secure World, one in the Normal World — talking over a deliberately narrow RPC channel. Think of it as OP-TEE's cousin, written in Go, with a far shorter path from "I want to test a boundary case" to running code than the C-and-make thicket around most TEE work. It is a research and teaching platform, not a certified TEE, and nobody should present it to an auditor as one.

INTERLOCK is the flagship reference application: a TLS-served file-encryption appliance with a web UI. Plug the stick in, browse to its local-only HTTPS address, upload files, and the Armory encrypts them under AES-256 keys derived from a passphrase and a CAAM-bound master key, writing ciphertext back to the host. It is a genuinely shippable artefact and the best available template for building your own Armory-hosted service. Worth being precise about the threat model it answers: the key material stays off the host, but you are still typing a passphrase into a browser on a machine you may not trust, and INTERLOCK does not fix that.

Supported attack & research vectors

• USB-class shape-shifting: enumerate as HID, mass storage, CDC-ACM, RNDIS or ECM — and change what you are between plug-ins. The USB-Ethernet path is the interesting one, because a host that ignores a new keyboard will still happily route traffic through a freshly attached network adapter, which is what makes Responder and NTLM relay work from a stick.
• Hardware-rooted key custody: ECC private keys in the ATECC608A or sealed in CAAM-encrypted blobs. A portable code-signing or commit-signing token where the key physically cannot leave. The trade is that key escrow becomes a design decision you make up front rather than a mistake you recover from later.
• Trusted execution research: GoTEE gives a clean two-world TEE for attestation, sealed storage and side-channel work, on hardware that costs a fraction of a vendor evaluation kit.
• Covert payload host: a TamaGo binary can present a perfectly ordinary labelled mass-storage volume while running a keystroke injector, an exfiltration agent or a pivot. It looks like a memory stick to a person and to most endpoint tooling — though a USB device that changes class between insertions is exactly what mature device-control policies are watching for.
• Pentester drop box: with the Ethernet expansion, the MkII sits inside a kiosk or behind a rack and beacons a SOCKS tunnel or WireGuard back to operator infrastructure. Bus-powered, so it dies whenever the host does — plan the callback interval around that, not around uptime.
• Secure-boot teaching: HABv4 fuses, signed U-Boot images and CAAM-rooted key derivation, all documented. The best device available for teaching the i.MX secure-boot pipeline, with the caveat that fuses are burned once and a teaching mistake is permanent.

Open-source community, customisation & longevity

Small community, unusually high signal. The usbarmory GitHub organisation carries the hardware files, firmware, TamaGo, GoTEE, INTERLOCK and the Debian image, and the Foundry team answers issues themselves. Hobbyists have published enclosures, carrier boards, USB-C adapters and PoE daughterboards. There is nothing resembling the Flipper's hobbyist scene — the audience is researchers and product engineers — so there is no YouTube video for your specific problem and there is not going to be. What exists instead is a handful of people who genuinely know the platform, answering in pull-request threads, and documentation written by people running the device in production. That is better than a large forum right up until the week the project goes quiet, which is the real risk to weigh before you build a product on it.

Legality & ethical posture

This is the cleanest legal posture of any device reviewed here. A generic ARM computer in a USB shell: no regulated radio, no LF or HF reader, nothing that transmits. It ships from Crowd Supply in the US and EU under ordinary commodity classifications, and customs has not been a story. All the risk is downstream and behavioural. A TamaGo binary doing HID injection or NTLM relay is legally indistinguishable from any other tool doing the same thing, and the same discipline applies: written scope, signed authorisation, an inventory of what you carried in. One thing the form factor does change is disclosure — a device that looks exactly like a memory stick is easy to leave behind and hard to explain afterwards, so count them out and count them back in.

Deployment scenarios

How the MkII stacks up against the alternatives

The Pi Zero 2 W wins on price and on the sheer volume of people who have already solved your problem. The BeagleBone wins on industrial I/O. The Armory wins on one axis nothing else on this page competes for: trust posture. It is the only one where the boot chain, the secure element and the runtime are all auditable, and where you can demonstrate a private key has never left the silicon. That is a narrow advantage and it is worth being blunt about the price of it — eleven times the cost of a Pi Zero 2 W, sporadic availability, and a software stack you will partly write yourself. If nothing in your design depends on attestation, the Pi is the correct answer and this is an expensive way to feel secure.

Pros & cons

Verdict