I wonder if it's one of the chips that has a bootloader vulnerability. All of the trustzone stuff was completely broken on their original, and nobody ever implemented working code for it anyway.

The BOM cost is probably pretty high because of the BGA package, the original was like a 8 layer board or something absurd.

Those processors, as you pointed out, are comically slow even compared with the raspberry pi.

We took part of in the original HAB disclosure process for the NXP i.MX series and we carry on testing these parts.

Please see https://github.com/f-secure-foundry/advisories

Of course all P/Ns used for the Mk II have a patched boot ROM, please see https://github.com/f-secure-foundry/usbarmory/wiki/Secure-bo....

The original Mk I was 6 layers in the end, the Mk II is also 6 layers.

And yes the BOM cost is considerable due to its specifications.

The i.MX SoC core we use is comparable to a 1st gen Raspberry PI in speed, but of course slower than newer multi-core ones.

However security and form factor, rather than pure speed, is our goal. For the intent and purposes of the board performance is more than adequate.

Some benchmarks here: https://github.com/f-secure-foundry/usbarmory/wiki/Benchmark...

I have deep respect for you disclosing issues in a processor you're using in your own product.

The ATECC608A is a very nice feature. I have an older version of the USB Armory--i.MX53 and USB-A. The cryptographic engine (SCCv2), and in particular the AES module with unique, secret eFUSE'd key (for creating a proper HSM) was poorly documented. NXP only made security component documentation available under NDA, and to achieve that you needed to work with a reseller, which after repeated attempts over many weeks I never managed to accomplish. Plus, even if I got the documentation, the keyed AES module only worked properly if you had secure boot working, otherwise it used a fixed test key rather than an alternative unique key. This was such a steep hill to climb that none of the example or open source applications ever made proper use of the AES module, AFAIK.

I ended up simply buying a Pi 3, a Mikroe Click shield, and Mikroe ATECC608A board (for the shield), though by that time I had already run out of steam so I never had a chance to bring it up.

So, the ATECC608A is very nice and I'd like to see it more widely included in hardware.[1] And the armory is much smaller than my literal Pi 3 hardware stack. Bonus points if documentation for i.MX6ULZ and related bits are publicly available, but I'm not keen on risking another goose chase so I probably wouldn't even factor that in one way or another.

[1] I believe an ATECC chip is what AWS originally used for end-to-end hardware attestation of EC2 servers. And maybe still do. Though, this is speculation on my part based on some AWS developer blog posts discussing the chip.

The ATECC608A itself has an NDA'd datasheet, though.

Yes, however it is pretty much identical to the non-NDA'ed ATECC508.

Also the ATECC608A library from Microchip is open source and you can gather all necessary info from there.

Then we also have the NXP AT71CH with all info available publicly.

I think that's his point, and that's why he's glad to see it in the newer version.

I didn't know the ATECC608A had an NDA'd datasheet. But as far as I remember all documentation needed to utilize it from software (e.g. I2C protocol) was available, in PDF or in code (https://github.com/MicrochipTech/cryptoauthlib/).

> Pi Zero outspecs it for 5% of the cost

Does Pi do USB device "emulation" (has it "gadget" drivers)?

Not all of them, but the A, A+ and zero do. Basically all models _without_ a built-in USB hub work. The Pi 4 is capable of OTG only over the USB-C port, and only with a recent firmware.

They support a bunch of modes, like Mass Storage, Ethernet, Serial, HID, etc.

Example: https://gist.github.com/gbaman/50b6cca61dd1c3f88f41

The production costs are way more than 15 USD, you have to account for the 6 layers PCB, assembly and a BOM which is higher than what you suggest.

We can take costs down a little more with larger numbers but not by a great margin.

The assembly process of Type-C plugs is also time consuming and therefore costly.