Security, Obscurity, Openness

This is a transcript of a talk I gave at the Hacker Noon #devstories @Github event, with minor modifications to improve readability. I wanted to call out the irony that security calls for openness, but security is also the reason for obscurity and proprietary implementations, especially in the hardware world. Making security more open is what motivated us to found SoloKeys, and make open source hardware security keys.

What I think is really fascinating about security is the duality that I tried to capture in the title between openness and obscurity.

Borrowing a definition from cryptography:

A (crypto)system should be secure even if everything about the system, except the key, is public knowledge.

Thus, security calls for openness. And the viceversa is also true, openness means trust. This is likely why we all love open source projects, because instinctively we tend to trust them more.

Let’s take the classic example of iOS vs Android. If I were to ask which one is more open? Of course everybody agrees it’s Android. Even though, if we zoom into Android, we know that not everything is open source. Some parts are proprietary, typically the closer we go to the hardware. And if we ask why? and we dig deeper, the reason for obscurity is often… security!

This is pretty ironic and paradoxical. Security calls for openness, openness means trust, some parts of the systems can’t be open and why is that!? Because of security.

This cycle clearly has one good part that we want to perpetuate, and another one that we should interrupt. As a community, we should strive to make open source alternatives. Can you imagine a world without an open source operating system? And I’m not saying that everything should be open, certainly that can’t be. I’m saying that for everything there should be an open alternative, for users to choose from. This, to me, is especially important in the field I care about — security — and as we mentioned before this isn’t the case the closer we go to the hardware, for example for hardware security keys.

In August 2018, together with a group of friends, we founded SoloKeys with the goal to make open source hardware for secure applications, starting from user login.

We made Solo. Solo is the first security key to be open source and implement the newest standard FIDO2, that offers the strongest level of security for two-factor authentication, and works great with Google, Facebook, Github, and many more.

In October we launched a Kickstarter, raising $123K from about $3K backers, which is amazing for a security product, while almost all other similar campaigns unfortunately failed.

In November we participated in the FIDO Alliance Interoperability Testing Event is Seul, passing all tests. We’re morally FIDO2 certified, pending paying the certification fee.

In December we shipped our first batch, and at least in the US many people got their Solo key by Christmas.

Finally, in January we were at Shmoocon, presenting our journey for the first time.

In addition to Solo, the consumer security key, we also offer Solo Hacker, a key with the same open source hardware, and an unlocked firmware, so you can reprogram it whether you want to learn about embedded devices or explore our security features.

A big thank you to the two event hosts: HackerNoon which is where we launched Solo for the first time, and GitHub which is where we host our open source firmware and hardware.

And a final invitation to join our community, and help us making security more open, in hardware like in software.

P.S: If you’re interested in getting Solo, check out the slides or the video for the discount code — we have extended the validity for an extra month or so. And as always, if you have any feedback or suggestions please use the comments below or find me @0x0ece.

Security, Obscurity, Openness was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.