1. 24

We’re launching a full redesign of our FIDO2 security key.

Much more robust, water resistant, stronger NFC, reversible usb plug. Shiny NXP LPC55S6x micro with juicy security features and firmware rewritten in Rust. As always fully open source.

  1.  

  2. 7

    After everything is tested and programmed, the electronics cavity is permanently sealed with clear epoxy. This provides durability, waterproofing, and tamper resistance for the keys. Here is a demo of our glue dispensing being set up.

    It’s to my understanding that yubikeys are fairly hard to tamper with since the cover can’t easily be removed along with fuses that would blow. But I really struggle to understand how clear epoxy makes it tamper resistent? From the looks of it you can remove the circuit from the case, and then you would probably be able to remove the epoxy and refill.

    Is there are threat model to this or a better explanation how it’s tamper resistent?

    1. 2

      I think the threat model is the Hotel’s housekeeper. I know this is a threat model for full disk encryption without BIOS passwords. Loading an alternative keylogging BIOS to get your disk password can take them 10-20min if they come with the right tools from their security agency.

      I could be wrong, but ticketing with your hardware security module encased in epoxy might be hard within the 10-20 min you’re out of the room for breakfast. Also because it’s clear epoxy, any scratch can be visible and noticed.

    2. 4

      Hmm…. I have a couple of Solo keys (v1). Does this mean they do not get new software to support Ed25519 for use with SSH, i.e. ed25519-sk? Do the new v2 keys support this “out of the box”?

      1. 7

        It’s a bit tricky, we really hope to get ed25519 to v1 too. The issue is interfacing with SSH as we tried openpgp in v1 but the result doesn’t fit the cache.

        We’re now focused on v2 because the platform is easier to use and extend. As we’re a tiny team, we don’t have much resources to work in parallel on v1 & v2. This said, we don’t plan to drop v1 entirely and if we see any movement in the community we’re happy to help & support.

        1. 1

          Thanks for the answer!

          Is ed25519-sk substantially different from ecdsa-sk? Because that does work on the v1 with OpenSSH…

          1. 2

            Re. this: no it’s the exact same thing from the key’s point of view, if the key implements both P256 and Ed255: just a normal WebAuthn/CTAP assertion.

            Re. Ed255 on v1 and movement in the community: https://github.com/solokeys/solo/pull/478

        2. 2

          From what I understand the new v2 still use the same chip as the v1.

          1. 3

            No, v2 has NXP LPC55S6x, while v1 has STM32L4. Firmware is rewritten in Rust.

            1. 1

              I was told awhile back the firmware will work on both chips? Is this still true? (I guess I was confusing memories.)

              Thank you for the correction!

              1. 1

                No, these are two very different chips. The LPC55 is very new and much more powerful. It’s unclear if the new firmware could be backported on the old chip, and we definitely currently don’t have the resources to do so.

        3. 3

          I would like to give my experience backing the Somu to those considering backing this project.

          From a practicality point of view, the device does its job. It works strictly with FIDO2.

          From a hacking point of view, it pretty much sucks. You are one flash away from bricking the device.

          It was recommended by Conor to not even use the Somu Hacker to do any real development, but instead purchase a real development rig for the chip. It totally defeats the purpose of why I bought my Somu Hackers in the first place.

          Now I’m left with 3 Somu Hackers which I plan to not touch for a looong time. I wanted to hack them to store some very small secrets, but I can’t even do this playful task without worrying. I plan to wait until the (small) community comes up with a way to reduce this risk.

          I want to be clear, regardless, I think the project is still worth backing if only to prevent monopolies in this space, and to cause competition to lower prices of similar products.

          1. 3

            Hey thank you for the feedback!

            Our keys ship in 2 versions, Secure and Hacker, aka locked down or reprogrammable. Because the hw is the same, we can’t add a reset button, so they’re slightly more complex to use than a dev board.

            I guess what Conor meant is that because you can’t reset, you should be careful when you flash firmware. If you’re experimenting like writing code you’re not sure it works, a dev board is recommended. But once you have your own code that you want to run, there should be no issue flashing your Somus like any other of our keys.

            1. 0

              Please re-read my comment. Clearly I am already talking about the reprogrammable Somu Hacker.

              I know exactly what Conor meant, and no, he recommended this because it is very easy to mess up the bootloader.

              Obviously there will be no issues with actually flashing, come on. Please stop the marketing.

              1. 1

                I read this: “I wanted to hack them to store some very small secrets” as in “I have a concrete use case”.

                I agree with you (& Conor): to experiment it’s better to use a dev board. And once you have working code you can use the somu for storing your secrets for real.

                (sorry if it came up as marketing, I spoke about the “secure” just to explain why we don’t add a reset button. I was absolutely clear you got the hacker)

            2. 1

              The hacker version in the new key will be a somewhat different experience. We’re using NXP’s ROM bootloader, which can’t be overwritten; so it’s always available. There are also headers for a Tag-Connect cable, so you can debug properly with a Segger mini or similar.

              1. 1

                This sounds excellent, but doesn’t fix the fact there is still no recommended “safe” process for working with Somu Hacker. It sounds like Solo v2 will actually deliver on what the Solo v1 and Somu v1 should’ve delivered for those looking to do some playing.

                (Thanks for the reply nick, I know you’ve been working on the platform for awhile.)

            3. 2

              I use the solokey v1 “SOMU” which gets stuck in the USB port, it’s great, I don’t have to plug anything when I log in.

              However, their lack of “GPG security module” is really bad IMHO. I wish it could be use as a “GPG smartcard” like the Nitrokey. (I haven’t tried the nitrokey, maybe I have false expectations there as well)

              1. 2

                Flag as spam, because this obviously fits this:

                “Spam” for links that promote a commercial service.

                1. 1

                  I was going to back this, because I want a key anyway.

                  So I tried to Sign In with Apple on their website. Nope “something went wrong at our end”. Multiple times.

                  So I installed the iOS app, and tried to Sign In with Apple. Nope, same error.

                  So I tried to create an account using an email. Oh it sent me two verification emails and the page after login says I need to verify. Click the button. Nope “you are not authorised to access this resource”.

                  So I gave up.