ATECC608B USB breakout

[rounin]

A little ATECC608B carrier, using a Sillicon Labs CP2112 USB/I2C bridge for host access.

I started working on some auth code for some "IOT" things, decided that key enclave + hmac-sha would probably be the best way to auth the remote headless devices with reduced risk of key leakage vs just holding a cert in the rootfs. After AUTHing with the key enclave, some limited scope/time session key will be negotiated so we don't have to hit the key enclave for every request, which might take half a second. (I will also have a cert in the rootfs for mTLS).

Initially prototyped with yubikeys which have a hmac-sha mode, but the keys have a limit of 64B message text and are somewhat expensive for just using in hmac-sha mode. Also the server-side version, the yubiHSM2 is rather expensive @ 650$ (and still only holds ~200 odd keys).

So the thought is some simple USB carrier could hold a few ATECC608Bs server side, at much less than the cost of a yubiHSM2. Each ATECC608B can hold 16 keys for ~$0.90, so pretty cheap, the whole prototype run will probably be cheaper than one yubiHSM2. The end devices will just have a ATECC608B whacked on the i2c bus somewhere.

This carrier has 4x ATECC608B for burning chips during prototyping, or extra key slots for key rotation.

[rounin]

Cad view

[rounin]

Got the PCBA from JLC without the CP2112-F03-GMR since it was out of stock, which was a mistake since I'm terrible at soldering QFNs. Oh well, will get another 2 in ~2 weeks with all the parts when it gets to JLC from Mouser.

I might switch a few to the trust&go chip variant, it comes pre-locked with a key which might be nice. Also hilariously, there is an ATECC608C already to fix yet more silicon errata .

The USB4085-GF-A USB connector is nice, but didn't realize the through holes are really short, seems like its for a 1.0mm thick PCB instead of 1.6mm, will switch to thin PCB for the next set.

Have some sample code running with MCP's cryptoauthlib on a breadboard, and the library seems to be somewhat rubbish - eg 1 year old year deref NULL after NULL check bug in the issue tracker...  hopefully it gets some attention from upstream, I was really hoping i could just drop it in and not need to rewrite the low level io code.

[tooki]

since I'm terrible at soldering QFNs.

FWIW, I highly recommend getting a “PLCC blade” soldering tip (nowadays often just called a blade tip) because they can really get into the joint. A PLCC blade and lots of good flux makes QFNs a snap!

[rounin]

Very odd limitation of CP2112 - i2c device address must be in range 0xF7 - 0x02, and the data length must be greater than 0.

This means eg i2c_smbus_write_quick to a address of 0x00 doesn't work, which seems like an odd thing to prohibit.

ATECCXXXX chips need a write to the 0x00 general call address to wake them (well, really a 60us low on SDA), which this usb bridge can't do. Might switch to MCP2221A or FT260S. As a work around, just re-configuring the bridge mux setting works since there are enough zero bits on a write to 0x70.

This became an issue when switching to the TNGTLSS variant, the watchdog is much shorter so the chip needs to be woken up for almost every command.

[rounin]

Man, this project really turned into a survey of USB-I2C master chips.

Created revB with a MCP2221A and performance was very disappointing. Had some strange glitches where it would not send the stop pulse for a long time after the byte to be written was sent, for a while I thought it was just sending extra stop pulses they were so far from the transaction. The in-tree kernel driver is supposed to let you use the free gpios as a gpiochip under /sys/class/gpio, and it did enumerate there for me but I couldn't get it to work. Bitrate was also was fixed at 333kHz, which is too fast for the ATECC608 chips to wake up and there was no in-band way to change the baud rate short of a kernel module rebuild (I didn't want to pull in any libusb code to configure it from my code, shouldn't have been too hard but meh, the stop pulse glitches were already too much).

Will switch revC to FT260. Actually got a dev kit for it first this time, and using an out-of-tree driver allows changing the bitrate from userland via a /sys/bus/hid/drivers/ft260 node!!! (The in-tree driver is old and missing features, hopefully they get merged soon). Haven't tested the uart or gpiochip iface but they enumerate now. It also correctly does the 0 byte write to the 0x00 general call address for device wake up. This along with dynamic userland baud rate change is nice, should be able to switch to 100kHz for wake up then to 1MHz mode for lower latency (only tested to 400kHz so far, since that is limit of PCA9544).

FT260 driver: https://github.com/MichaelZaidman/hid-ft260

revB / revC also add 4x TNGTLSS variant chips to the 4x blank ATECC608Bs, total of 8 ICs, and a more compact layout.

FT260 seems like a winner, I'll probably use it on some other test / calibration fixtures we have coming up. I might switch from PCA9544 to PCA9849 for 1MHz fast mode support.