Project Description
Implement a proof-of-concept USB security key with support for encrypted data storage, U2F and FIDO2 (webauthn). I plan on using a NanoPi NEO2 board for this project, what has a few useful attributes:
- it can boot a mainline Linux kernel
- it's relatively portable (40mm x 40mm)
- it has an aarch64 CPU with support for ARMv8 Crypto Extensions
- dm-crypt performance should benefit significantly from this
The hardware doesn't provide a secure enclave or TPM, so it's likely unsuitable as a commercial security key device.
When powered, the device will boot a minimal buildroot Linux image and expose a pseudo-mass-storage USB device with a single-file static website. On first-boot the website will provide a setup wizard for the device. Subsequent boots will immediately prompt for a decryption key. Output data generated by both setup wizard and password prompt web pages will need to be propagated back to the USB device. This could be done via the pseudo-mass-storage filesystem, or possibly (if time permits and I can live with myself) via webusb.
Most of the work needed for this project will be configuration and plumbing, with the exception of the U2F and FIDO2 USB gadget implementations. https://github.com/ellerh/softfido looks attractive as a U2F/FIDO2 starting point, but it currently exposes the endpoints via USBIP, so will need to be converted to a Linux functionfs USB gadget.
Goals for this Hackweek
- generate a buildroot 2022.11.1 image for the NanoPi NEO2
- write a static website which provides dm-crypt setup and unlock for the encrypted data storage area
- work out a partitioning scheme for the OS/config/dm-crypt
- for simplicity I'd like to avoid LUKS and instead have the website produce a PBKDF2 derived key for direct use by dm-crypt
- test https://github.com/ellerh/softfido
- convert softfido from USBIP to a Linux functionfs gadget interface
- stretch: write a webusb client and server (USB endpoint) for transferring configuration / key data between host and device
- stretch: support snapshots and transparent compression for encrypted data storage
- stretch: provide some way for a user to update the buildroot OS on the USB device
Resources
This project is part of:
Hack Week 22
Activity
Comments
-
almost 3 years ago by dmdiss | Reply
I pushed the (still very much WIP) results of this project to: https://github.com/ddiss/lioness
It was a lot of fun and served as a good learning experience, particularly with regard to Buildroot embedded development. I didn't get far with softfido, but managed to code a chunk of the config handling / parsing logic in rust. I'm particularly happy with the USB device<->host configuration message passing logic using an emulated mass-storage device. Rather than detecting eject events to ensure safe access to the exposed storage, the USB device monitors the fat filesystem contents for
lioness.txtconfiguration presence. The static website provides a SHA256 digest, allowing for config file integrity verification despite concurrent host/device access. -
Similar Projects
OSHW USB token for Passkeys (FIDO2, U2F, WebAuthn) and PGP by duwe
Description
The idea to carry your precious key material along in a specially secured hardware item is almost as old as public keys themselves, starting with the OpenPGP card. Nowadays, an USB plug or NFC are the hardware interfaces of choice, and password-less log-ins are fortunately becoming more popular and standardised.
Meanwhile there are a few products available in that field, for example
yubikey - the "market leader", who continues to sell off buggy, allegedly unfixable firmware ROMs from old stock. Needless to say, it's all but open source, so assume backdoors.
nitrokey - the "start" variant is open source, but the hardware was found to leak its flash ROM content via the SWD debugging interface (even when the flash is read protected !)
solokey(2) - quite neat hardware, with a secure enclave called "TrustZone-M". Unfortunately, the OSS firmware development is stuck in a rusty dead end and cannot use it.
I plan to base this project on the not-so-tiny USB stack, which is extremely easy to retarget, and to rewrite / refactor the crypto protocols to use the keys only via handles, so the actual key material can be stored securely. My Initial testbed is the devkit for the solokey2, the NXP LPCXpresso55S69.
Goals
Create a proof-of-concept item that can provide a second factor for logins and/or decrypt a PGP mail with your private key without disclosing the key itself. Implement or at least show a migration path to store the private key in a location with elevated hardware security.
Resources
LPCXpresso55S69, tropicsquare tropic01, arm-none cross toolchain
OSHW USB token for Passkeys (FIDO2, U2F, WebAuthn) and PGP by duwe
Description
The idea to carry your precious key material along in a specially secured hardware item is almost as old as public keys themselves, starting with the OpenPGP card. Nowadays, an USB plug or NFC are the hardware interfaces of choice, and password-less log-ins are fortunately becoming more popular and standardised.
Meanwhile there are a few products available in that field, for example
yubikey - the "market leader", who continues to sell off buggy, allegedly unfixable firmware ROMs from old stock. Needless to say, it's all but open source, so assume backdoors.
nitrokey - the "start" variant is open source, but the hardware was found to leak its flash ROM content via the SWD debugging interface (even when the flash is read protected !)
solokey(2) - quite neat hardware, with a secure enclave called "TrustZone-M". Unfortunately, the OSS firmware development is stuck in a rusty dead end and cannot use it.
I plan to base this project on the not-so-tiny USB stack, which is extremely easy to retarget, and to rewrite / refactor the crypto protocols to use the keys only via handles, so the actual key material can be stored securely. My Initial testbed is the devkit for the solokey2, the NXP LPCXpresso55S69.
Goals
Create a proof-of-concept item that can provide a second factor for logins and/or decrypt a PGP mail with your private key without disclosing the key itself. Implement or at least show a migration path to store the private key in a location with elevated hardware security.
Resources
LPCXpresso55S69, tropicsquare tropic01, arm-none cross toolchain