FIDO2 Authentication In All The Colors

Here at Hackaday, we have a soft spot for security dongles. When a new two-factor-authentication dongle is open source, uses USB and NFC, and supports FIDO2, the newest 2FA standard, we take notice. That just happens to be exactly what [Conor Patrick] is funding on Kickstarter.

We’ve looked at [Conor]’s first generation hardware key, and the process of going from design to physical product.  With that track record, the Solo security key promises to be more than the vaporware that plagues crowdfunding services.

Another player, Yubikey, has also recently announced a new product that supports FIDO2 and NFC. While Yubikey has stepped away from their early open source policy, Solo is embracing the open source ethos. The Kickstarter promises the release of both the software and hardware design as fully open, using MIT and CC BY-SA licenses.

For more information, see the blog post detailing the project goals and initial design process.  As always, caveat emptor, but this seems to be a crowdfunding project worth taking a look at.

14 thoughts on “FIDO2 Authentication In All The Colors

  1. The colour of that thing is probably the most unimportant attribute of all.
    What about a stretch goal, that promises to support the nRF52840 dongle?
    It’s already in their github rep, but that doesn’t contain much yet.

    If you don’t know about that dongle, here’s a link: https://www.nordicsemi.com/eng/Products/nRF52840-Dongle

    Why should you care?
    Well, that dongle contains the latest and biggest offspring of the Nordic nRF family, offering not only an ARM M4 core and 1MB of Flash, but also (besides the usual peripherals) a very capable radio, that fully supports Bluetooth 5, including mesh, thread, long range and high throughput, but also ANT, 802.15.4, and the old proprietary nRF protocols (nRF24L01). And NFC.

    Also, this dongles are dirt cheap, and therefore sell like hotcakes.
    Adafruit’s Circuitpython supports them, Arduino support is underway, there are free C++ IDE’s available.

    I think, that this chip will be the next big thing in the maker world, especially for mobile devices (badges, anybody?) and home automation. As it has USB, Bluetooth, NFC, secure memory and a cryptographic co-processor, it would be a natural choice for a security dongle.

    1. Yeah the NRF52840 is definitely a good option for BLE. We decided to wait on a BLE implementation for the following reasons.

      – RF is hard and there are regulatory concerns, especially when you make a consumer product.
      – You need a lipo battery. Which comes with hard reliability and safety problems for consumer product.

      We’d like to solve these issues down the road for sure, just decided to start more simple :)

      Some other comments.
      – NRF52 chips don’t have any actual extra security features aside from the TRNG. There’s the crypto cell, but this provides acceleration, which doesn’t really have additional security benefit. It’s not needed except for RSA 4096 in my opinion (and Cryptocell doesn’t support that).
      – NRF52 would be prohibitive for passive NFC use.
      – Cypress’s PSoC USB/BLE chip is another good option. Has Crypto, TrustZone, etc.

  2. There’s no details from Solo how they intend to keep the key material secret and are explicitly against SEs.

    Not that I’m all for SEs or anything. Trezor also took this route. In bboth cases however I tthink their justification is flawed.

    1. Same here, I did not get the justification. Either the chip contains an processor doing Diffie Hellman with a hardware unique secret key (only the public key is readable) to derive a secret key that would resist eavesdropping, and this is not “open source” anymore (you have to trust the hardware there is no backdoor here). Either it’s doing the computations on a crypto processor that’s open source, and the storage/communication is protected by some “magic gate” chip (like usual crypto keys in fact). Since this can’t be proved safe, the only alternative would be to use a FPGA whose logic is “fused” down (you program it with open source code, then you e-fuse the matrix so it can’t changed), but this would be overpriced.

  3. Hi, Nicolas from SoloKeys here.

    We ended up deciding against a BLE-capable chip since we didn’t want to add a battery… In the future, we may create a version with BLE and battery (during the Kickstarter, we have a partnership with OneSpan offering a BLE-capable key in combo with our Solo, if BLE is one of your use cases). So this leaves us with (ultra) low power MCU choices.

    We are not explicitly against secure elements – it’s just that they (EAL chips) are hard/impossible to get without being a bank or otherwise “reputable organization”, plus we are explicitly pro-open source, and those chips involve NDAs and closing up source code.

    The security/threat model we are aiming for (besides phishing, MITM and other online attacks) is protection against “casual extraction of the keys”; debugger pins and DFU access will be locked down (Conor wrote about our signed update process in https://solo.solokeys.io/signed-updates). Generally, just like HSMs, the model is “if you have the key, you can use it, but you can’t extract the key”. So yes, we do not think reading out flash via decapsulation, or side channel attacks, is an actual threat model for (most of) our target customers. Cold boot attacks will be made more difficult by scrambling the RAM. If we find the resources, I’d love to stage an actual flash attack, and decapsulate a Solo, though! :))

    The crypto wallet comparison is an interesting one: While Trezor also uses an STM32 ARM chip, Ledger uses a combination of STM32 and secure ST31 one. And while Ledger’s SDK lets you develop “apps”, the source code for their BOLOS operating system is closed.

    What will be interesting for a future “Solo v2” are the Cortex-M23 chips, which have ARM TrustZone and enhanced flash readout protection. For a while, we were toying with the Microchip SAM L11, but ended up deciding against due to flash size limitations, since extendability is an explicit goal – post Kickstarter we will announce our roadmap to move beyond the FIDO2 use case. It includes Rust :) There is now also a dev board for the Nuvotron M2351, which is also M23 and has more flash – just arrived and we’re testing it!

    Generally, the STM chips have the biggest ecosystem, which we think is a plus for actual community participation in improving and extending the firmware. Certainly, the choice of Cortex-M23 chips will grow in the near future.

    Looking forward to community involvement, to ensure Solo becomes the best security dongle that can be done in full open source!

  4. The truly paranoid would want to know and trust those who are making the actual chips involved. (a tall order) Until we can roll-our-own chips we really can’t be as secure as we should be. That said, this product is a step in the right direction although a finger ring touch device would be nice. …small steps :-)…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.