A Brief Look at Open Security Keys. Part one: Solokeys

Introduction

We all love our second factor hardware security keys - devices such as the Yubikey. Unfortunately, quite a few of these devices are proprietary black boxes which require you to trust them at face value. Fortunately there are an expanding number of open alternatives. Devices such as OpenSK, SoloKeys and OpenTitan">. But what are the differences between these devices? How secure are they? And how open are they really? In this series we will look at some of the open security token projects to find out more about what they are, what they provide. And since they are supposedly open, try and take a look at their guts to find out what makes them tick. We start out with SoloKeys.

SoloKeys

SoloKeys claims to be the first open-source FIDO2 security key. The webpage showcase a number of form factors including SOMU a USB-nano device that looks very much like the Yubikey Nano. The devices supports a couple of different authentication protocols such as FIDO2 and the older U2F In terms of connectivity there are devices supporting USB and NFC.

Ok, enough about the high level functionality. Let's open up a device to find out more about the licenses used, the hardware and the software design.

Both the SW and firmware as well as the hardware design are available on Github. The SW for Solokeys is licensed under both Apache 2.0 and MIT licenses. The Solokeys HW is licensed under CERN OHL and under Creative Commons CC BY-SA.

The Solokeys basically contains a Microcontroller (MCU) with a few external components needed for touch sensing and for NFC communication.

The HW designs are provided in a design format for the KiCAD EDA open PCB design tool. Opening up the design in KiCAD works nicely, and everything needed to work with the design and build devices including Bill of Material (BOM) seems to be included in the HW design.

The Solo keys uses an ARM based MCU from ST Microelectronics (ST). The STM2L432 is a low cost device with fairly few peripherals. There are no cores for cryptographic acceleration such as AES and SHA-1, SHA-256. But the core supports floating point operations. The MCU has several interfaces including USB, SPI, I2C etc. But not that many kitchen sinks/black boxes with functionality you need to trust. There is code in the SoloKeys repository from ST. The code from ST is licensed under a BSD 3-clause license.

The STM32L432 contains a True Random Number Generator (TRNG) which is used by the SoloKeys design. Interestingly the code for the TRNG contains functionality for calculating the Shannon entropy. Grepping through the code, the output from the TRNG seems to be used directly for things like master secrets and U2F keys, not as seed for a cryptographically strong random number generator (CSPRNG).

The NFC functionality is provided by a AS3956 chip from AMS.The driver for the NFC chip seems to have been developed by the SoloKeys project. The NFC device may contain a simple microcontroller in itself.

The cryptographic functionality in SoloKeys is based on the Cifra embedded crypto library. The Cifra library is licensed under Creative Commons CC0 license. Interestingly the FIDO crypto code in SoloKeys refers to ARM's open library MbedTLS, at least for curves. But the code actually seems to use curves from the uECC library. The uECC library is licensed under a 2-clause BSD license.

One thing I note is that the planned key derivation in SoloKeys seems not to be using an existing Key Derivation Function (KDF) such as HKDF. Instead they describe something that looks like a HMAC combined with AES-256. There is some motivation given. But it would be interesting where the key derivation mechanism originates from, and how the scheme has been evaluated.

Conclusions

SoloKeys looks like nice, well thought out and really open security keys that provides the functionality needed in U2F and FIDO2 keys. The design rely on a few external parts and libraries. But browsing through the design I find no real binary blobs and black boxes. In terms of licenses there were more licenses than I initially expected with more than one dual license.

Looking at the code itself it seems to have been written defensively. The attack surface is low, but received inputs are not always filtered. Also some possibly problematic functions like memcmp() are used. That said, running tools like Flawfinder and Cppcheck on the code does not reveal any major horrors. As pointed out in both code and documentation for SoloKeys and Cifra, some cryptographic functions are not side-channel silent. Before going through the code I hadn’t heard about the Cifra library and don’t know how well tested and trusted it is.

One thing I noted security wise is that the SoloKeys code uses the TRNG in the MCU directly. I would have expected and recommended using the TRNG as a seed generator for something like a SP 800-90 secure random number generator. And using standardized key derivation algorithms.

By Joachim Strömbergson
Embedded Security Specialist at Assured AB.