OnlyKey: Open-Source Alternative to YubiKey | Hacker News Reader

OnlyKey: Open-Source Alternative to YubiKey

onlykey.io

448 pointsmcone211 comments

Security keys are the heart of security and we desperately need open-source solutions on this. Kudos for doing it.

Now, I must point out a few things:

1. Please don't call your solution "Open-source", when you do not have not even the schematics uploaded to github.

2. (this item is an open problem without a solution yet) how do I make sure the source code and the (still missing) hardware information actually corresponds to the hardware I'm buying?

If we do take item 2 seriously, one may say that buying Yubico is actually "safer" than your open-source solution, mainly due to company reputation and credibility.

Again, sorry the harsh words, but I take my keys seriously.

The "security" of this device is a joke, just look at how randomness is derived:

  unsigned int analog1 = analogRead(ANALOGPIN1);
  RNG.stir((uint8_t *)analog1, sizeof(analog1), sizeof(analog1)*2);
  unsigned int analog2 = analogRead(ANALOGPIN2);
  RNG.stir((uint8_t *)analog2, sizeof(analog2), sizeof(analog2)*2);

(See [0] for a comprehensive summary of why this is a terrible thing to do)

And yeah, analogRead() is a function from the Arduino library because .. well, apparently there's an Arduino compatible chip inside that does all the cryptographic operations. Meaning that there is no hardware security whatsoever and it's trivial to extract all your keys from the device if you ever lose it. Whoops.

[0] https://arxiv.org/pdf/1212.3777.pdf

It seems this is literally written in the horrible Arduino "everything in one huge file" style:

https://github.com/trustcrypto/OnlyKey-Firmware/blob/master/...

The funny thing is they have a "Source code reviewed by Codacy" badge on the readme claiming the code is grade A... but if you actually click through, of course Codacy didn't pick up the .ino file at all, so in fact nothing of substance is being reviewed. That .ino file wouldn't pass any style review... it's a mess.

Anyway, looks like that firmware is incomplete (e.g. "onlykey.h" is missing). Just a quick scroll through the code gives me zero confidence in this thing, code quality wise. Someone who can't consistently indent code almost certainly isn't qualified to be writing security-critical software.

Edit: looks like the rest of the code is here, and yeah, it doesn't inspire much confidence (7000+ lines of code in okcore.cpp, ouch): https://github.com/trustcrypto/libraries/tree/master/onlykey

> The funny thing is they have a "Source code reviewed by Codacy" badge on the readme claiming the code is grade A... but if you actually click through, of course Codacy didn't pick up the .ino file at all, so in fact nothing of substance is being reviewed. That .ino file wouldn't pass any style review... it's a mess.

Meanwhile Nitrokey has actually been audited by Cure53.

The "security" of Nitrokey is a joke.

As others have mentioned they were actually hacked https://old.reddit.com/r/crypto/comments/bis3pf/extract_pgp_...

Nitrokey does not support half of the features OnlyKey does and even the users on their own forum prefer OnlyKey -https://support.nitrokey.com/t/nitrokey-vs-onlykey/638

I understand the Arduino model is different than other projects but we proudly use Arduino as it's open source and has lots of great features. As we use the Arduino model you can find that our source consists of the .ino you mentioned here https://github.com/trustcrypto/OnlyKey-Firmware as well as libraries here https://github.com/trustcrypto/libraries. Our code is reviewed by Codacy and yes, it does receive a grade of A. For the .ino grading you will need to look at the OnlyKey-Firmware Github repo and for the libraries check out the libraries library. I think some of the confusion in your comment here may be related to how Arduino works, all source can be found on Github.

It seems you're confused as to what Codacy is reviewing. Look at their dashboard for the OnlyKey-Firmware repo. They are not reviewing your .ino file at all, because they do not consider that file extension as code. Only the toplevel C files are covered.

The .ino file is included in Codacy review and receives a grade of A. You can find that here - https://app.codacy.com/manual/onlykey/OnlyKey-Firmware/dashb...

All libraries are included and also receive a grade of A.

You just changed that. It was not included when I looked, and this fact is obvious by the "OnlyKey-Firmware has decreased 1% in quality in the last 7 days." banner. You have made no commits to the repo since Oct 23, so the only way the quality would decrease in the past week is if you changed the settings to include the .ino file.

I wanted to make sure I clearly address these comments, one of the issues in reading a post like this in an online thread is the most upvoted post can also be the most incorrect, and misleading.

#1 > The "security" of this device is a joke, just look at how randomness is derived:

Unfortunately, this commenter posted this without reviewing any of the security documentation available for OnlyKey. Had they reviewed they would see that we specifically address how analog input alone is not sufficient entropy for a cryptographically secure number generator and one of the unique features used with OnlyKey is using capacitive touch input for our RNG. This random input is generated every time you touch a button on OnlyKey, it's different for every person, and its truly random. https://docs.crp.to/security.html#cryptographically-secure-r...

#2 > Meaning that there is no hardware security whatsoever and it's trivial to extract all your keys from the device if you ever lose it. Whoops.

Again, had the commenter taken the time to read a bit they would see that this is completely false. As others have already mentioned, OnlyKey is not an Arduino, OnlyKey uses some of the great Arduino software libraries that are available open source and the Arduino IDE. This is completely unrelated to hardware. As for the OnlyKey hardware security we use Freescale Kinetis flash security to securely lock data on the key. As for side channel attack countermeasures we list several that are in use. For full details read this - https://docs.crp.to/security.html#hardware-security

When it comes to security questions, trust an expert, not the top post on a thread. For more information about CryptoTrust, the makers of OnlyKey you can find our team with internationally recognized security credentials here - https://crp.to/t/

For more info on OnlyKey:

Get started - https://onlykey.io/start

General documentation - https://docs.crp.to/

FAQs - https://docs.crp.to/faq.html

Compare to Yubikey - https://crp.to/p/

Setup and User's Guide - https://docs.crp.to/usersguide.html

Features - https://docs.crp.to/features.html

Support - https://forum.onlykey.io/

List of supported services - https://onlykey.io/pages/works-with-onlykey

If you're so confident in your experts, maybe respond to my comment where I point out a major bug? https://news.ycombinator.com/item?id=21889302

Sure thing. Thanks for reviewing the code, we are always happy to get additional eyes on it. For your major bug I have to disagree about the major part, the RNG works well but yes it could work better, I will put the long answer in your comment below. As for the short answer I created a video showing how the OnlyKey uses capacitive touch for RNG. The blue arrow in the video points to the values that change as the buttons are pressed, you will see the four values per button providing random entropy, this is what goes into RNG.stir. Keep in mind the RNG is slowed down for the video, actual entropy gathering is much faster in use - https://vimeo.com/381733010

And I am going to have to give Codacy a grade of F but if this is what they consider grade A.

As a Codacy user for $DAYJOB I can guarantee you that Codacy deserves worst than grade F.

I can safely say that a lot of proprietary crypto code (as in, stuff that is in very widespread use and costs $$$) is not unlike this either. In some ways this is actually more straightforward to read and understand since it's in one file and not wrapped in a dozen layers of abstraction.

Definitely true, anyone who has ever seen proprietary crypto code knows this. Reviewing one file that is 7000 lines long is more straight forward than reviewing 7000 lines of code split in multiple files. It's open source and we will continue to make it better. If the biggest criticism here is the large file size, RNG complaint (top post is incorrect about analog read, they missed that we also use 6 touch buttons to seed RNG), and code style then it's a safe bet that OnlyKey source is better than most of the proprietary security keys out there. Of course it's not possible to know for sure as they are closed source, but you can look at past vulnerabilities. Like this one https://crocs.fi.muni.cz/public/papers/rsa_ccs17 it's not a theoretical RNG issue like the criticism here has been, it's an actual exploitable vulnerability that affected Yubikey and tons of smart cards. This exploit was on devices that were already FIPS and CC certified. Another thing to consider is the way the researchers found this was by statistically testing a bunch of keys, they didn't even review the source so you can imagine how many more security vulnerabilities they would find if they did.

The 7000 lines don't bother me as much as the complete lack of refactoring, heavy use of magic numbers repeated throughout, and logical expressions that duplicate logic over and over again.

Some examples...

Compare these two blocks of assignments and memcpy calls:

https://github.com/trustcrypto/libraries/blob/5bd1f8eb15eb04...

Yes, they are as identical as they appear. The only differences (other than a couple of lines commented out in one) are the use of 'data' in the first and 'large_resp_buffer+offset' in the second, along with some arbitrary whitespace differences. (The first uses spaces around the + operators, the second does not.) And all the hard coded numbers! What do they mean?

Or this block of code that appears to be a limited version of a decimal number formatter:

https://github.com/trustcrypto/libraries/blob/5bd1f8eb15eb04...

Or this code that keeps checking the same flags over and over again instead of combining the tests:

https://github.com/trustcrypto/libraries/blob/5bd1f8eb15eb04...

(Scroll horizontally to see all the repeated tests!)

Or this code with the same logic repeated 24 times:

https://github.com/trustcrypto/libraries/blob/5bd1f8eb15eb04...

The next function after that one also has 24 copies of duplicate logic.

Well, the logic isn't entirely duplicated. The individual cases call functions like onlykey_eeget_urllen1, onlykey_eeget_urllen2, ... onlykey_eeget_urllen24, and onlykey_eeset_urllen1, onlykey_eeset_urllen2, ... onlykey_eeset_urllen24. Here are those functions:

https://github.com/trustcrypto/libraries/blob/527113dfeeb20e...

Yes, they are all identical except for the different constants each one uses:

https://github.com/trustcrypto/libraries/blob/527113dfeeb20e...

This pattern of "24 copies of the same logic with different constants" occurs all through the code. Look through okeeprom.h/cpp for several other examples.

None of this inspires confidence that the code can be trusted.

> None of this inspires confidence that the code can be trusted.

It's a shame this code isn't so good out of the box, but for all we know there are proprietary devices purporting to do the same job which also have poor code. The difference between the devices is we can review, edit/improve, share, and run the improved code for this device. The software freedom is a feature unto itself. So one is still better off with this device (or another device that runs on entirely FLOSS) over any proprietary device that purports to do the same job.

You have no access to hardware schematics. You have no idea what hardware defects are present that may compromise security no matter how much code you write. FLOSS means shit here.

This is incorrect, a schematic only shows what electronics should contain. It doesn't provide any proof of what hardware actually contains. For that the best way to verify is to visually look at the hardware, we made OnlyKey hardware easy to verify with a clear transparent coating. When you look at OnlyKey you will see one Freescale K20 MCU, you can read the manufacturer number on it and know exactly what is in your key.

The microcontroller isn't the only thing that matters in your design. For example, since you're dependant on the ADC for seeding the RNG, it'd be nice to know what is connected to those pins, which a schematic would reveal. I can't tell that just by looking through your clear epoxy.

Even if I did drill holes in the casing and probe components, I have no way of knowing if what I'm seeing is expected or not without a schematic.

I have to agree with you.

What impresses me even more is that they are selling it already, and marketing as “open-source”. I would leave a note here that if anybody is interested in doing something similar, please get some feedback from community before starting commercialization.

There's a dead simple "quack/crank" test for security products. If it hasn't been publicly discussed and analyzed for at least year, but is already for sale as a "usable device" not a "prototype", the seller is either fraud or a fool, and regardless of which, is not to be trusted.

OnlyKey has been in use for about 4 years. It has thousands of active users and is in use in over 40 countries world wide. This is not a new product, and it has a great user community which is not afraid to test, hack, and prove the security of devices.

>OnlyKey has been in use for about 4 years. It has thousands of active users and is in use in over 40 countries world wide. This is not a new product, and it has a great user community which is not afraid to test, hack, and prove the security of devices.

Like literally the first issue was already linked above. Using the psuedo RNG with some analog pin seed isn't really acceptable. It should have a true rng IC that can generate real random numbers from diode bandgap noise or other sources.

Like literally the first post issue is completely incorrect, thats one of the issues in reading a post like this in an online thread, literally that user copied part of but not all of the function that is used for RNG. The part they copied uses analog input as one of the sources of entropy, they failed to also include the 6 capacitive touch inputs that are also inputs to the RNG. Those touch inputs literally change every time you press a button and even with atmospheric changes, i.e. it's cloudy out today, your RNG has changed.

RNG.stir((uint8_t )analog1, sizeof(analog1), sizeof(analog1) 4);

touchread1 = touchRead(TOUCHPIN1);

RNG.stir((uint8_t )touchread1, sizeof(touchread1), sizeof(touchread1));

delay((analog1 % 3) + ((touchread1 + touchread2 + touchread3) % 3)); //delay 0 - 6 ms integrityctr1++;

touchread2 = touchRead(TOUCHPIN2); RNG.stir((uint8_t )touchread2, sizeof(touchread2), sizeof(touchread2));

touchread3 = touchRead(TOUCHPIN3);

RNG.stir((uint8_t )touchread3, sizeof(touchread3), sizeof(touchread3));

touchread4 = touchRead(TOUCHPIN4);

RNG.stir((uint8_t )touchread4, sizeof(touchread4), sizeof(touchread4));

touchread5 = touchRead(TOUCHPIN5);

RNG.stir((uint8_t )touchread5, sizeof(touchread5), sizeof(touchread5)); touchread6 = touchRead(TOUCHPIN6);

RNG.stir((uint8_t )touchread6, sizeof(touchread6), sizeof(touchread6));

unsigned int analog2 = analogRead(ANALOGPIN2);

RNG.stir((uint8_t )analog2, sizeof(analog2), sizeof(analog2) 4);

// Perform regular housekeeping on the random number generator.

RNG.loop();

delay((analog2 % 3) + ((touchread6 + touchread5 + touchread4) % 3)); //delay 0 - 6 ms

integrityctr2++;

if (integrityctr1 != integrityctr2) { //Integrity Check unlocked = false; CPU_RESTART(); return; }

https://github.com/trustcrypto/libraries/blob/5bd1f8eb15eb04...

Even if that analog pin provides a reasonable amount of entropy (which I'm skeptical of), you have a major bug: you're casting the ADC reading to a pointer, and then dereferencing it inside RNG.stir.

Let me say it again: you're taking an ADC reading (in the range of 0-1023) and accessing it as if it's a memory address.

To make things worse, addresses 0 through 1023 on the Kinetis you're using are the vector table. Take a look at that part of your firmware: it's extremely predictable, and only contains a small number of possible values.

Here is the long answer to the comment provided above, as mentioned there its probably easier to take a look at the video first, the blue arrow in the video points to the values that change as the buttons are pressed, you will see the four values per button providing random entropy, this is what goes into RNG.stir - https://vimeo.com/381733010

You will notice that as you mentioned the analog read values don't change much, that is because it is reading the memory address. Keep in mind that the analog read is only an additional source of entropy, not the primary source, that comes from the capacitive touch buttons. The RNG does not need or require this entropy, but you can never really have too much entropy so that's why it was included. So with reading the analog address values what you get is only a small amount of entropy, these address values do change based on user behavior so its still an unpredictable source of entropy, you wouldn't know on any given day how a user will use their key. I.e. I log in to two sites in a different order on two days, it's going to mix in some non-predictable data.

But you are absolutely right, it would be better to mix in the analog read value. For our next firmware release we will update this to include mixing in both the value and the memory address. Thanks again for bringing this up and feel free to create an issue on Github if you see anything else.

You're right. I tried to give this code a charitable read, but it's horrifically wrong, and not just the ADC, but seemingly all inputs here.

At least we now have a better sense of what an A grade from Codacy actually counts for.

To be fair to Codacy, it's not even checking the file that people are pulling all these examples of bad code from.

Just because on your testbench they changed enough for you to guesstimate they provide enough entropy doesn't mean they provide enough entropy for everyone under all circumstances. They are not designed for that purpose and unless you have performed extensive adversarial testing to gain confidence that they can be used as such, you cannot guarantee anything.

You seem to have zero runtime sanity checks too, so if for whatever reason they are not providing entropy for someone, they will be none the wiser.

Sorry, but this is a terrible RNG.

Your "delay 0-6 ms" only delays 0-4 ms.

Not to mention the fact that the only obvious effect of that delay is to expose entropy information to timing analysis.

The delay is 0-2 + 0-2 so yes combining six possible values for a possible delay up to 4ms. The delay inside of an RNG loop obviously does not expose entropy to timing analysis, it does the opposite. As the loop has a small random delay interval the RNG seeds are never predictably read in, adding to the effectiveness of the unpredictability of the RNG which is a good thing.

You might want to check out this - https://docs.crp.to/security.html#cryptographically-secure-r...

If you read further into the source you will see that analog read is only one of the sources of entropy, it uses capacitive touch from a user's skin and this TRNG passed dieharder tests - https://webhome.phy.duke.edu/~rgb/General/dieharder.php

Passing dieharder doesn't mean anything at all with respect to cryptographic security. It's trivial to define a random bit generator that passes randomness tests and has no real security.

You cn literally run the number 0 through a modern hash function and pass dieharder without having any entropy.

> Passing dieharder doesn't mean anything at all with respect to cryptographic security.

Technically, doesn't not passing dieharder mean something with respect to cryptographic security, though?

I would like to learn more about practical cryptographic issues, and I need some help: what are the tests that can prove or disprove stronger guarantees for cryptographic security of a PRG than diehard? A wikipedia page doesn't give me much info about which one provides stronger guarantee and in which criteria:

https://en.wikipedia.org/wiki/Randomness_tests

Also, which level of security of a PRG is sufficient for keys like this?

There aren't such tests, at least not that work like dieharder. You analyze a CSPRNG the same way you'd analyze a cipher construction (they are essentially the same thing, and often we draw our conclusions about the strength of a CSPRNG by noticing that it's built on and thus inherits the formal security commitments of ciphers and hashes run in modes and constructions that themselves have been shown to be trustworthy).

There are no automated tests for this, since cryptographic randomness requires unpredictability. A statistical test can only tell you when a random number generator is broken, but no statistical test can tell you whether a random number generator is cryptographically sound.

And so the only test is to analyse all known knowledge for any method that is capable of predicting some portion of the random numbers. If none exists, the process is "random".

> what are the tests that can prove or disprove stronger guarantees for cryptographic security of a PRG than diehard?

None. The difference between a good CSPRNG and a broken one might not even be in the construction at all, but in who knows the seed. For example, a keystream generated using Chacha20 or AES-CTR makes for a good CSPRNG... except if the attacker knows the key.

The responses you've gotten so far are pretty bleak even if they are accurate. It's true that once you start mixing randomness, or get into algorithms the only thing statistical tests can really tell you is if it's broken.

Those tests can be used on raw sources to learn about the quality of those inputs. In this case applying those tests directly to the analogRead() on a specific source of hardware (your entire circuit and manufacturing process will effect this, and will even vary from board to board) can give you an estimate as to how much entropy you can expect from each call.

Understanding your where that entropy is coming from is significantly more important, gate voltage breakdown, fluctuations from the pins acting as antennas, in the current temperature and humidity is where analogRead() on a floating pin largely comes from. Other sources can be radioactive decay of particles, timing of events that are outside of the system (such as the time between a device being plugged in and the first time a person touches a key).

These all provide small amounts of entropy (except for radioactive decay, that's a really good one). The next step is mixing entropy. There is a lot of good math showing that with proper mixing, even adding known inputs from an attacker into an entropy pool doesn't decrease the entropy in the pool (it's no less random). If time isn't an issue you can add in a large number of readings from the same source, though sampling faster than the source changes won't get you anything.

That mixing allows you get to up to a minimum threshold of randomness (the seed) where you can use a cryptographically secure pseudorandom number generator (CSRNG). These also have proofs of a different type showing that input bits have an equal chance of modifying any bit of the output which can then be mixed back into the seed getting a very very large amount of effectively good randomness that can be used for keys and the like.

The trick here is that you're effectively at war with attackers, the more of your entropy sources an attacker can predict or control, the weaker your overall input to the CSRNG is going to be. If they can get this down to a small possibility space they can predict the input to the CSRNG and in turn fully predict its output which will reveal your keys.

If an attacker has a way to measure timings on the device a large number of times they may be able to infer the internal state of the system and once again get your keys.

So it's not really about the quality of that final output that is the problem and that's largely what people doing these projects analyze with these tests.

One final bit I'd like to cover. These tests can provide you some information about the final quality of the output (mostly whether it's broken or not) but even for that they're usually used incorrectly. If the CSRNG is implemented correctly but say you always seed it with the value "0", it will pass the tests with flying colors.

For devices like these they should be fully reset, have a small amount of randomness output, fully reset, sampled again... thousands to millions of times. This will help you determine if the range of possible inputs to the system is inherently flawed and most projects I've seen (including this one) don't seem to do that.

for i in range(1,1000): print sha256("lol what's entropy" + i)

This passes dieharder. Completely meaningless.

According to the K2x family guide, some devices have an hardware RNG available -- is it right this project uses a K20 without this?

It seems pretty bad that merely grounding 8 pins on this device will reduces its entropy to basically to a handful of noise bits from the ADC?

Yes it uses the K20, I think you may be confusing the threat model here. If you grounded the 6 capacitive touch buttons the device would not work at all so there would be no need for an RNG. The RNG is used for things like creating keys, in order to get to the point where you are creating keys you would have to be able to enter a PIN on your device by physically touching the capacitive touch buttons. As you do this the readings from your skin is input to the RNG. I hope this explanation makes it clear why this attack isn't possible.

https://docs.crp.to/security.html#cryptographically-secure-r...

It's not 'trivial' to extract the keys - all modern uCs have flash readout protection bits. It's probably easier to do than to read the secure element from your iPhone or extract keys from your SIM card or your credit cards, but it's not something you can do without specialized skills and equipment (although there are companies that provide commercial flash readout services).

Flash readout protection on most microcontrollers is a joke. They are almost always vulnerable to attacks ranging from power/clock glitching to asking nicely with the right combination of flash management commands (I'm looking at you, some PICs from the PIC18 series with blockwise erasable Flash including protection bits). I've seen some things disable their read protection by accident because the power supply wasn't hooked up properly and they glitched themselves.

There's a reason we have real secure elements with anti-tamper mechanisms. The problem is that as far as I know there aren't any that you can develop for without signing an NDA.

I've signed a ot of these NDAs. Dirty little secret, most of them are DUAL_ED_DRBG which is backdoored. None of them have any meaningful protection, and usually they have sidehcannels the size of mountains. There's none of the secure element chips I would consider to be stronger than cryptography in software. They're the same as passing certifications, good to corporate management but a joke to anybody who knows what they're talking about.

Can you talk us through a scenario where you'd exploit Dual_EC to break encrypted flash storage?

It's indicative more than a break of encrypted storage.

For example ATECC508A, a common secure element chip used in a lot of designs. It does ECDSA signing, using DUAL_EC_DRBG (based on the description, it's not mentioned) and produces non-deterministic ECDSA signatures. You can establish this by asking it to sign the same message twice, and the nonce selection is random rather than static for the two requests. This is a very strong indicator that the chip is significantly weak as it's not using the standard RFC6979 which was specified in 2013.

Commonly a lot of "secure" software implementations use the output of the STM32's "TRNG" as a source of entropy, such as many Bitcoin hardware wallets. I don't believe that this is a strong design, based on the documentation that has been made public. It is supposedly based on the output of multiple synchronized ring oscillators which are XOR'd to produce a output into a 32 bit buffer. The documentation goes to a huge length to try and justify it as a secure source of entropy, but the speed of it (the RNG RDY flag) is much too fast for it to possibly be true.

    uint32_t random32(void) {
      static uint32_t last = 0, new = 0;
      while (new == last) {
        if ((RNG_SR & (RNG_SR_SECS | RNG_SR_CECS | RNG_SR_DRDY)) == RNG_SR_DRDY) {
          new = RNG_DR;
        }
      }
      last = new;
      return new;
    }

A common implementation of reading the output of the STM32 RNG is this snippet, which has a single bit of bias, which is enough to break things like ECDSA signatures if used for the selection of k.

The general comment is that people seem to be far too trusting in these devices actually implementing what they say they are, or using output from hardware RNGs in a way that directly exposes the application if they were to fail or be producing predictable output.

I don't really trust any of these microcontroller designs, but the comment I replied to, on a thread about Flash protection, said that the designs weren't trustworthy because they used Dual_EC. I'm wondering if there's some direct connection between Dual_EC and storage protection. It's clear to me how Dual_EC compromises cryptographic protocol handshakes, where its output, which can be decrypted to reveal RNG state, is exposed to attackers.

For my comment, it's just indicative of design issues. Some designs do trust these devices to make RSA and ECDSA keys though, which we've seen in the past can be majorly screwed up by accident.

https://www.ria.ee/en/news/possible-security-vulnerability-d...

I don't know which SE you're talking about, but the ones I've worked with are pretty secure, for one, side channel attacks are extremely difficult

I believe this is mostly down to the obscurity of them rather than good implementation. The implementations of ECDSA predominantly are almost always not constant time, which directly leaks the size of the nonce that has been chosen. That none of them implement RFC6979 deterministic nonces is a very good indication that they have put zero care into their implementation.

Can you comment, perhaps vaguely, on the Infineon SLE 78 series?

I don't have any information about this secure element.

This brings up an interesting conversation. As a user which should you pick, a device like Yubikey that is closed source and unverifiable or a device like OnlyKey that is open source and verifiable but without a traditional secure element? Its not a new question as this is essentially like the Trezor vs. Ledger debate. We try to provide information here https://docs.crp.to/security.html that is clear and gives user's the ability to make a choice. There are actual exploitable vulnerabilities that have occurred with "secure elements" while there are potential and theoretical vulnerabilities mentioned in this HN post.

I̶ ̶t̶h̶i̶n̶k̶ ̶i̶t̶'̶s̶ ̶u̶n̶l̶i̶k̶e̶l̶y̶ ̶f̶l̶a̶s̶h̶ ̶r̶e̶a̶d̶o̶u̶t̶ ̶p̶r̶o̶t̶e̶c̶t̶i̶o̶n̶ ̶i̶s̶ ̶e̶v̶e̶n̶ ̶s̶e̶t̶ ̶f̶o̶r̶ ̶t̶h̶i̶s̶ ̶p̶r̶o̶d̶u̶c̶t̶,̶ ̶a̶s̶ ̶i̶t̶ ̶a̶p̶p̶e̶a̶r̶s̶ ̶t̶o̶ ̶b̶e̶ ̶p̶r̶o̶g̶r̶a̶m̶m̶e̶d̶ ̶u̶s̶i̶n̶g̶ ̶t̶h̶e̶ ̶d̶e̶f̶a̶u̶l̶t̶ ̶A̶r̶d̶u̶i̶n̶o̶ ̶I̶D̶E̶.̶ And even if not, most are trivially attackable with hardware access, for example the ESP32 secure boot stack: https://limitedresults.com/2019/09/pwn-the-esp32-secure-boot...

EDIT: Spoke too soon, claims Kinetis Flash Security is enabled (https://docs.crp.to/security.html#flashsecurity). This looks like it also disables JTAG access, so that is a plus ("8.3.2 Security Interactions with Debug", https://www.pjrc.com/teensy/K20P64M72SF1RM.pdf).

Other than that, this C code has a lot of smell - for example, the repeated use of the ptr variable looks like what something someone unfamiliar with the C type system would use: https://github.com/trustcrypto/OnlyKey-Firmware/blob/c71d207...

Trivial for a motivated attacker, true. But also do note that you don't need to readout the entire flash, it's enough to be able to extract the hash of the PIN (or cut power before the eprom is updated after an attempt) and that is fairly easy given there are next to no side-channel protections.

Given that they're using the Arduino APIs, what are the chances they know what flash readout protection is?

You probably will be getting at least one bit of randomness out of it if the input is not saturated (As in not below 0 or above reference voltage ADC is using), just because pretty much all ADC are noisy enough that the last bit will be flipping. Of course that doesn't excuse every other problem with it

> Meaning that there is no hardware security whatsoever and it's trivial to extract all your keys from the device if you ever lose it. Whoops.

Most micros, ones used in various Arduinos included have fuse bits so there is at least the minimal level of protection. Question whether they used it even...

Doing a quick look through the library repository, I spotted another more scary function. It doesn't appear (at a quick glance) to be used anywhere, but still...

https://github.com/trustcrypto/libraries/blob/master/randomb...

For anyone wanting to try this out (it will compile with plain GCC if you add):

    #include <stdlib.h>
    #include <stdio.h>

to the start of the file, and declare a main function:

    void main() {
      unsigned char* buffer;
      buffer = malloc(32 * sizeof(char));
      randombytes(buffer, 32);
      for (int i=0; i < 32; i++) {
        printf("%02x", buffer[i]);
      }
      printf("\n");
      free(buffer);
    }

And you'll (of course) get some rather deterministic output. As I say though, doesn't look to be used (that I could see), but strange to have something like this there.

RE the RNG implementation, looks to be at https://github.com/trustcrypto/libraries/blob/master/Crypto/..., and looks to have some support for hardware RNGs on certain boards, but not others. Does sound like there's no hardware protection involved.

If you search the repo you can see the randombytes library is just there for reference and isn't used, that library was created by the same guy who made NaCl https://en.wikipedia.org/wiki/NaCl_(software)

The linked paper breaks analogRead-based encryption in section 5 at the end.

But I wonder if you could get better randomnes by, instead of naively pulling one low entropy 10-bit value from analogRead, you pulled 128 bits from successive analogReads and only kept the lowest significant bit.

A very simple hardware entropy source is a noisy diode. I wonder why so few people are using it

Did I misunderstand the article or is it just wrong? Although a certain entropy source might not be completely random, it can still be a part of of a complete solution, right?

Network packet timings aren’t random either and might be attacker controlled as well.

Uh that is treating the value from the A/D conversion as an address, and reading that location for data to stir in.

Unless HN markup ate the &s that are missing.

That is very bad code indeed.

Thanks for the Kudos! We are going to continue to strive to make the best security keys out there, I understand taking security keys seriously and thats exactly why we started OnlyKey. If you are looking for reputation, the members of our small team have internationally recognized security credentials - https://crp.to/t/. We recently won 2nd in the Virtru Privacy competition https://crp.to/2019/12/onlykey-webcrypt-2-0-feature-highligh... and we will continue to make OnlyKey better with each release. One advantage to consider with OnlyKey is you buy a key once, and your key is upgradeable. As technology changes or as required secure upgrades are provided directly in the OnlyKey app to add new features to your key.

For #2, it'd be nice if there were kits sold to create your own physical keys. You can flash code from github to it yourself, and then assembly the casing together.

Optionally for first line of defense, the assembly could be fastened with some less common like a torx or square screw head and it could come with a pack of small holographic security stickers to place over the screw.

Edit: You'd want it to be an unassembled kit so that you can provide your own hardware if you wanted instead of relying on what is provided for you if you wanted to be super cautious.

There’s the U2F Zero https://github.com/conorpp/u2f-zero/wiki/Building-a-U2F-Toke... but of course there’s always a reflections-on-trusting-trust issue: you’ve got to get your CPU, CPU design, compiler, firmware and chip programmer somewhere!

Of course, an accidental software bug is probably more likely than intentionally backdoored hardware targeting you personally...

That all sounds to me like security theater. It would not increase my confidence in the device, its firmware, or its design.

Why?

Backdooring a shipment of security tokens could open interesting possibilities at a relatively low cost. Or the government may force you if you happen to be in Australia.

Flashing your own firmware which you have checked (or at least checked its signature) may make sense.

Also, you guys should definitely do some research about side-channel attacks. I quickly inspect the source code and did not find any counter-measure.

Countermeasures listed here - https://docs.crp.to/security.html#technical-specifications

Sorry that your account was being rate-limited. HN's software filters that do that, based on past activity by trolls. Unfortunately it also sometimes prevents project creators from showing up to discuss their work. I hate that!

We've marked your account legit so this won't happen again.

It is open source, not to be confused with open hardware which it is not. The hardware is transparent, literally, it has a clear protective coating on the hardware which allows visually verifying everything. For security things check out https://docs.crp.to/security.html - TL;DR Before you enter the PIN its not doing any crypto which means lots of side-channel attacks don't apply, you would have to know the PIN to even attempt many types of side-channel attacks.

> The hardware is transparent, literally, it has a clear protective coating on the hardware which allows visually verifying everything

Right and that's bullshit. How do I know you aren't embedding a advanced joule thiefing silicon die disguised as a pull-up resistor to manipulate usb communication or even interface with the micro in a backdoor?

How do I know

Fair question. But it makes me wonder: what would be the accepted way to provide schematics/PCBs and prove the provided ones are also what gets used to create the actually sold hardware? Same question for the source code actually.

I don't think humanity has been able to solve that problem. There's isn't an md5 checksum for hardware yet.

When you say open-source it's rather general. I.e. not open-source software or hardware, so it does imply it's open-source both (e.g. https://en.wikipedia.org/wiki/Open-source_hardware not "open hardware")

I'm having a rough time even finding the "open source" embedded software running on the onlykey. This site definitely needs an "open source" section linking to the relevant github/gitlab repos, or at least cross links/references to source within their documentation. I see tons of claims, but no way to validate them.

Thanks for all of the interest in OnlyKey! Full disclosure, I work for CryptoTrust and am on the team that makes OnlyKey. I wanted to try to address the questions/concerns in this thread in one place and provide some useful links for more information. OnlyKey started from a successful kickstarter launch in 2016 and has grown to become a popular product for businesses and individuals.

- OPEN SOURCE - If you are looking for OnlyKey source you will find it here https://github.com/trustcrypto all of our apps and firmware is open source. OnlyKey is not open hardware, however the hardware design is very transparent, literally. The device has a clear protective coating on the hardware which in addition to adding durability allows visually verifying everything.

- ABOUT SECURITY - Security documentation is here https://docs.crp.to/security.html and provides information on how OnlyKey random number generator works, supply chain, side-channel attacks etc. One thing that you will notice about OnlyKey that differentiates it from other security keys is the on key PIN entry. While no device is immune to hacking, this feature mitigates many traditional threat models. We are always open to discussing specific threat models openly on our support forum.

- WHERE TO GO FOR MORE INFO Get started - https://onlykey.io/start General documentation - https://docs.crp.to/ FAQs - https://docs.crp.to/faq.html Compare to Yubikey - https://crp.to/p/ Setup and User's Guide - https://docs.crp.to/usersguide.html Features - https://docs.crp.to/features.html Support - https://forum.onlykey.io/ List of supported services - https://onlykey.io/pages/works-with-onlykey

Any chance that key can be used for windows login?

I'm searching for a key that also works as a smartcard for winows on prem active directory authentication, as well as FIDO2 support.

Or a key that has software which allows this.

edit: changes should be chance

One of the nice things about OnlyKey is you have options. - You can use OnlyKey to store a password up to 56 characters long for Windows login. You don't remember this password OnlyKey types it for you. - You can use OnlyKey as a FIDO2 security key to login to Windows with Azure AD.

Thanks for the answer!

So it basically registers itself as a keyboard?

Even if the Windows PC is locked?

How does it know which password to type?

Unfortunately everything that is more complicated than "take that stick and stick it in the usb port" is gonna be difficult.

I know about the FIDO2 with azure AD, but I need it for on prem AD, which doesn't support fido2.

Yes, OnlyKey appears to the computer/mobile device as a keyboard. That is why it works on all computers and even iPhone/Android with an adapter available in our store - https://onlykey.io/collections/accessories-1

Yes, it would type the password to unlock your Windows PC.

You assign password/login info to a button, you press that button. I.e. Button number 1 is my Windows login so I would press the 1 button to login. After the OnlyKey is unlocked that is, a PIN is required to be entered on the same buttons providing physical security.

Feitian advertises one here https://www.ftsafe.com/Products/FIDO/NFC and they say you can request a dev version so you can install your own applets, but I can't vouch for it yet personally.

Looks interesting, thanks for the link!

Apparently K9 Dev version is basically like eJavaToken, without applets installed, so no U2F, only CCID. Unless you specifically want that don't order.

Setting aside problems with this particular device, the whole "trust the open-source hardware" model is inherently flawed. Every useful security hardware will be commoditized, then faked and/or trojaned. We can't take the open-source software approach and rely on many volunteer eyes catching vulnerabilities and backdoors. First, there just aren't enough skilled professionals capable of proper hardware review. And second, how can you be sure the device in your hand strictly meets its specs? there's no such things as digital signatures and reproducible builds for hardware. Vendor reputation is all we have for now.

Can we do something about this?

If someone sells you a quantum computer, there exists protocols that allow you to check if the QC is working as intended without inspecting the internals [1]. You merely have to pass some special (randomized) inputs and check the outputs.

Does anybody know what sort of verification protocols exist for classical security devices, where you can verify that the device is working as intended without inspecting the hardware?

[1] https://arxiv.org/abs/1911.08101

To do something about this requires supply chain security that you won't find outside governments that are able to realize economies of scale.

Librem is working towards such a supply chain, right? The Librem 5 costs $2k but is made entirely in the US

Assembled, not made.

I really like the concept. I bought 4 of them a while ago (maybe a couple of years?) mostly to support them. I used one onlykey as my daily driver, I tried to integrate it with pass (my password manager at that time) without much luck. The software itself was very rough, the key was not meant to be used in your keychain: clear signs of usage after about a month, the usb port started to "fade", it was hard to use the touch buttons, it factory resetted at some point (out of nowhere). Overall: I'm going to keep an eye, try them again in the future, but I fee the product needs one or two more iterations before I can depend on them as my daily security driver. Oh, and LED lights stopped working after a few weeks.

one huge disadvantage (which is the same for yubikey) is that I use programmers dvorak as my keyboard layout: had to change it every time to English to input the passwords/token.

There's currently an issue (and an open PR) in to add dvorak support, though, I'm not sure if/when it'll be merged.

https://github.com/trustcrypto/OnlyKey-Firmware/issues/85

There are many, many keyboard layouts out there. Maybe it's time for an input standard that acknowledges this fact, instead of endlessly putting the onus on OS developers and users. Maybe keyboards should output UTF8 instead of messy keycodes.

This would require new hardware.

If one is already going to be purchasing new hardware, one may as well get a QMK keyboard. This way you can program it with any keyboard layout you would like, and it will work on any computer without having to change the system defaults.

Clearly this doesn't help with built-in keyboards such as found on laptops; the clear workaround for this specific product is to allow it to import keyboard layouts in the various OS-specific forms they exist in.

Sadly it doesn't seem to work that way. BE/AZERTY keyboards, for instance, have a physical key that US/QWERTY keyboards do not (<>\). The OS will ignore that key unless it's set up to use a layout that includes the key. There is no way to program a QMK keyboard to fix that (unless you change the OS to run the BE layout), because QMK does not map keypresses to characters. It maps keypresses to keycodes, which depend on OS keyboard layouts, specifically US/QWERTY and sometes DVORAK. At least that's how I see it.

Sorry to hear that you had issues with the LED. We did receive reports of some user's having issue with LEDs on some computers years back. With the latest OnlyKey hardware there have been no issues reported, you can check out the reviews on Amazon as if there is any issue at all there will usually be negative reviews on Amazon - https://www.amazon.com/OnlyKey-Stealth-Black-Case-Communicat...

This seems to predate FIDO2. https://solokeys.com/ would be a better option if you prefer separate keys for each site (via FIDO2) and open source hardware.

Given that only key appears to support FIDO2 it seems unlikely that it pre-dates FIDO2.

>"Onlykey supports multiple methods of two-factor authentication including FIDO2 / U2F, Yubikey OTP, TOTP, Challenge-response."

It predates FIDO2, the OnlyKey has been around since 2016 and before FIDO2 it supported FIDO U2F.

Bought 4 Solos in the first Kickstarter drop, can confirm they work very well.

SoloKey doesn't support everything this does. It is primarily a U2F key, and OpenPGP support is still WIP[0]

[0]: https://github.com/solokeys/openpgp

Yeah, I've been happy with my SoloKey, but OnlyKey's integration with a software password manager + OpenPGP + SSH keys is really enticing. I'm on the same boat as a lot of others here, however, that the lack of open hardware is a deal breaker.

Just wondering, what additional security would you expect from open hardware vs. open software with transparently designed hardware? From a threat modeling perspective it seems that if the device is just using one chip onboard there are no clear security advantages of open hardware. Open hardware would only be provide a security benefit if you are planning to make your own security key, which most people won't be doing. And by being open hardware there is an additional threat model created where it is now easy for adversary to create identical clones of security key that can be used maliciously.

Ultimately, it's just a personal belief that all knowledge should be free as in freedom. SoloKey Hacker Edition in particular lets you run custom firmware, so you can at least be confident in the software side of things, and build upon it.

Open hardware has the benefit of being able to build it yourself, which is the only completely secure option. The downside is, indeed, the ability to easily create malicious clones, and the fact that you simply won't be able to build it yourself for any remotely modern hardware. So yeah, there's really no security benefit to it in terms of hardware.

Proprietary hardware has the upside of needing reverse-engineering to create a malicious clone / part, and the transparent design helps you make sure that they can't do a sloppy job at it.

It's a shame that tradeoffs have to be made once technology reaches a certain level of complexity, but alas.

I've got a few SoloKey. This project seems like a joke comparatively as solo is actually open source hardware[0] and this is not. You can look above to see how OnlyKey might be more trouble on the software side than it's worth and potentially is just a liability.

[0] https://github.com/solokeys/solo-hw

I've got a few SoloKeys too. The USB C one broke in half and looking on Amazon reviews this is an issue for lots of people. Meanwhile my OnlyKey has been running strong 3 years in and has been on my keychain the whole time. Also SoloKey doesn't manage passwords at all, while OnlyKey does.

But it's not open source. Why even bother to call it open source if it's not? Since the Solo is open source hardware if you don't like it, you can change the design and get your own boards cut on OSH Park.

Thanks for the link...just bought two solokeys. Been meaning to do that but lost track of them.

The only true open hardware and open source key is the Nitrokey Start, running Gnuk firmware. Other nitrokeys are open hardware but run a smartcard (hsm or pgpcard) and those firmwares are not fully open. Yubikey is closed source and this posts bugger is closed as well. Go for a Nitrokey if you value true openness.

I've had a great experience with my NitroKey Starts. I'm just bummed that opensc doesn't yet support ed25519 since it seems gnuk does.

I am not sure I follow? I have been using NitroKey Starts with ed25519 and GnuPG for two years without problems?

The NitroKey Start is great! I have switched to YubiKeys, since they are more durable and also support U2F/Fido2 and PIV on the same token. But NitroKey's software being open source and upgradable are great features.

Note that gnuk also works on Blue Pills. So, if a NitroKey is too expensive for you, you can pick up a couple of Blue Pills for a few dollars and flash gnuk on them. [1]

[1] https://blog.dan.drown.org/gnuk-open-source-gpg-ssh-hardware...

FYI OnlyKey already supports ed25519 with their SSH agent https://docs.crp.to/onlykey-agent.html#supported-curves

It's indeed rather 'open'.. https://old.reddit.com/r/crypto/comments/bis3pf/extract_pgp_...

Kidding aside: I'm sure there are many more prodcuts having problems like this. Just goes to show there's no such thing as 100% secure I guess. At least this is open so can be fixed with some effort.

The Nitrokey HSM also has sort of a private key extraction, but that is by design: https://raymii.org/s/articles/Decrypt_NitroKey_HSM_or_SmartC...

I've owned and used an OnlyKey for around a year and a half now and have had a really positive experience using mine. There is one issue, unfortunately the LED lights do not work when the key is plugged into a USB 3 port. The key itself works, but you do not get any LED feedback which can make unlocking and using it a little difficult. Be sure to keep this in mind if you're thinking about purchasing one.

Why does it have LEDs if they don't work?

Are the schematic files and PCB/Gerber files available? I understand that they only claim to be Open-Source and not Open Source Hardware but it would still be nice to see and have the hardware schematics.

No. There isn't because it's not actually open source and this is bullshit.

In concept I like it, but one of the biggest yubikey advantages is how unobtrusive it is. I realize the tradeoff they're going for: Absolute security in the event that it's stolen... but I think that's actually bad for me since I'd rather have a tiny button to press as a second factor, than absolute security with a big dongle.

It'd be great if they just released a direct yubikey style clone.

This is the plan, an OnlyKey pro and a small form factor key similar to the Yubikey nano is in development.

Trezor T is vastly superior solution for U2F / WebAuthn and also fully open source. The main advantage is super mature backup (Shamir's secret sharing) and PIN-locking with exponential escape. Being a Bitcoin hardware wallet, security is very well tested.

> Being a Bitcoin hardware wallet, security is very well tested

Given the history of the cryptocurrency field, A is very far from implying B. And there's at the very least the Ledger analysis[1], which reveals several vulnerabilities. (The core issue for me is the order->backdoor->return issue - it doesn't seem there's a way to verify integrity of device or supply chain)

[1] https://www.ledger.com/our-shared-security-responsibly-discl...

Given the history of reputable Bitcoin hardware wallets, A actually does imply B. Hardware wallets are the only viable way to store cryptocurrency securely, with great track record since inception in 2014.

Regarding the supply chain, there is very little that can be done, and yubikey-like solutions certainly do not excel here. Trezor T at least comes with no firmware (to be installed by the user) and holographic sticker. Basic, but better than Yubikey et al.

It's interesting that Trezor and Solo are mentioned here. We specifically with OnlyKey decided not to go with an STM chip like the ones used in these devices due to the vulnerability that affects these devices described here -https://medium.com/@Zero404Cool/trezor-security-glitches-rev...

Solo was the first open source alternative to YubiKey. I'm using one of their products and have been happy with it so far: https://solokeys.com/

FYI, this is fake news OnlyKey has been around since 2016 and has been open source the whole time. Solo was launched in 2018 and claimed to be the first FIDO2 open source security key, this was only true because at the time OnlyKey wasn't FIDO2. OnlyKey was the first open source security key. Also Solo isn't even a viable alternative to YubiKey as it doesn't support challenge-response, static passwords, or OpenPGP. OnlyKey does support all of those things.

Solo is great, I would personally recommend this key if what you need is a 2nd factor. If you are looking for more features like password management and additional 2FA options then OnlyKey is a good choice.

I couldn't find any open source links on the site (reading from phone), is it open hardware or open config app/firmware?

There is a link to https://github.com/trustcrypto from within what seems to be the footer of (at least) the FAQ page.

Huh. So they have the firmware up, and a forked project that gets FIDO2 working on an Audrino .. I don't see and CAD files or any repos that seem to contain circuit diagrams. Is the hardware something standard they load firmware on, or is only he firmware open and the hardware designs closed?

Looks it. Seems like it might be open firmware and user-space interfacing software. Didn't see any CAD/EDA repos.

The desktop site has a link to https://github.com/trustcrypto in the footer.

I honestly don't understand how a YubiKey is supposed to help me secure my accounts if I get locked out of my accounts when I lose it. I an trivially copy a keepass database anywhere and have dozens of backups. If I want to do the same with a YubiKey I first have to buy multiple YubiKeys and then I have to register each one on each site. This means they cannot be used as a primary authentication method because they always require a fallback option in case you want to reset your credentials because you lost your YubiKey. If I can't use the YubiKey to secure my E-Mail account then what's the point? I'll still need to use password based login and store that E-Mail password in a conventional password manager that I then backup a dozen times.

YubiKeys only seem to make sense in a corporate environment where you can always request a new YubiKey and reregister it based on your ID.

Well, if you have multiple yubikeys on each site, then it can be used as a primary authentication method - because if you lose yubikey A, then the emergency fallback is yubikey B which you can use to revoke the access of yubikey A and add yubikey C instead.

Or, you have a set of one-time codes for recovery. I have accounts with a lot of sites, and all the sites that support proper U2F did have one-time recovery code option, because that's the fallback system that makes a lot of sense together with hardware tokens. Yes, the sites that support only things like phone-based OTP usually don't bother, since their risk model anyway puts all the trust in the phone so they usually just have a phone-based fallback, e.g. SMS with all the security risks related to that.

Or, you initialize two yubikeys so that they're identical; so you use your primary key and store the backup key somewhere safely, this doesn't require you to register multiple keys at each site, so it's a bit more convenient but it makes revoking a lost key a much bigger pain.

I used to a pile of yubikeys like this (yubikey A, B, C) then I replaced them all with one OnlyKey. Each Yubikey only has 2 slots, each OnlyKey has 24 and it has a secure backup feature.

A lot of services, like GSuite and LastPass, allow you to register multiple hardware keys. The best bet is to register several of them with these sites, then put one or two offsite (e.g. in a safety deposit box) just in case.

Then, use GSuite to sign into other services (like Slack) wherever supported to minimize how often you need to do this.

Use TOTP (like Google Authenticator) as a backup method as well. It's helpful for scenarios like having to log in on a phone.

Is Google Authenticator tied to your smartphone, to your account, or a combination of both? Can you transfer it to another smartphone? Is it being backupped automatically?

We're amongst a very technologically educated part of the population here, and honestly, I'm not sure about the scope of Google Authenticator. Quite sure that many aren't.

Google Authenticator implements TOTP, which is actually a very simple standard: https://pthree.org/2014/04/15/time-based-one-time-passwords-...

If you can extract the private key, you can transfer it to another phone or device.

On Android, AndOTP is open source (available on F-Droid) and allows encrypted backups. As for Google Authenticator, I don't think you can create backups.

With Authy, a Google Authenticator, on iOS the codes are backed up in iCloud and protected with a pass code. I’m not sure whether the pass code is used to actually encrypt things or just as a soft lock.

FYI OnlyKey already supports TOTP for up to 24 accounts. No apps required OnlyKey types the 6 digit code for you.

You need it for when you lose the key.

How does it know which OTP to type?

You load the login data to your key using the app, press a button on your OnlyKey and it types any or all of the following: -URL to login page -Username -Password -TOTP

To watch setup videos see https://onlykey.io/watch

The way two factor auth works is that you register your hardware key and you also get 10 one-time-usage recovery codes which you can use instead.

So, if you lose your YubiKey, you can still login 10 times using a recovery code. Presumably during those 10 times you either disable 2FA or register a new YubiKey.

I guess those recovery codes are the new security questions - yes theoretically they are there to recover your account, but in practice, you won't have them at hand unless you stored them in your password manager.

The whole idea of having a hardware token is to separate what's at hand. Having the recovery codes in the password manager seems like a bad idea. Google recommends printing them.

...oh yes, having your passwords printed out is such a great improvement. Considering how likely the "hacker" is to be a person sharing your household, you might as well put them on a post-it note and stick them to the screen.

Recovery codes go straight into the password manager, right next to my mother's maiden name, ASuTeil7quoongak2aeniVar.

Nonsense, the household hacker can also find your YubiKey. Much easier than a single piece of paper.

...there are other 2fa methods that don't disable at least one "personal" factors, whether that's a password or using finger/face/whatever. Not that great against cops, but stands a chance against many abusers, recent exes and terrible flatmates. And the yubikey is, theoretically, worn on you. Are you going to carry around all the printouts?

I'm having a hard time figuring out what kind of scenarios you are securing against.

The recovery code, just like the hardware 2fa, does not work unless you know the password. So you want to secure against people that live with you, know your password and from whom you cannot hide anything anywhere?

The printout is the size of a business card. You could put it in your Bible as a booksign an nobody would find them. Or if you want you could rot13 them or something basic so they can't be used as-is.

Actually, what are you suggesting instead? I'm genuinely curious what flawless solution you found.

The 2fa has to provide something more than a password to be worthwhile. If it's easily defeated by growing through my copy of Capital then it's not worthwhile. Finally, I don't have a single set of recovery codes, I have at least a dozen by now. By using recovery codes you've turned a somewhat harsh but sometimes-useful security scheme (for situations where loss of access is preferable to 3rd party access) into security theatre. Not that it matters, most services will "restore access" if you answer questions not just your flatmates but even an average doxxer will be able to find out.

Also no, you're not genuinely curious, you're trying to waste someone else's time.

But nobody is forcing you to print or use your security codes. If you ignore then and your hardware key is broken/lost you are forever locked out. Which you mention is preferable, sometimes.

So, you are against things. What are you for?

It's still a little better than security questions in that the layman's recovery codes won't be publicly available or easily guessable personal information.

All depending on the discretion of the various services. Of all the services that force me to use 2FA only a tiny minority provides recovery codes.

What services allow U2F security keys but don't provide single-use recovery codes as backup?

I don't know about U2F specifically, but recovery codes are not generally a feature of 2FA.

Edit: And let me just add why I think this is relevant. Even though few people have dedicated hardware keys today, many 2FA schemes depend on being in possession of a particular phone. There are typically no backups and no recovery codes.

I don't think this would necessarily change if specialised key hardware was used more often. In fact, my business bank account and a broker I previously used both require hardware keys and do not provide recovery codes.

I assume your bank has a physical place you can go to in order to get another token and you have a proper business relationship with them and somebody will ID you.

But many other sites have no other alternatives to recover so the recovery codes are a nice solution.

Note that I dislike that my bank gives me their specific hardware token. I am not sure why I couldn't use a 'standard' Yubikey instead.

how many keys to your home have you got? if you rent, how many keys does your landlord have?

home keys and yubikeys are both hardware keys and same rules apply - you absolutely should have more than one.

Good insight. Same goes for 2FA in general. If you lose the "second factor", you're done for, unless there's some backup. My bank pushes a phone-app-based authentication method that doesn't have any recovery or backup options outside of visiting a branch office. That's pretty secure in case of scams or theft, but I reinstalled my phone without thinking this autumn and got locked out of my bank account for months this winter.

This backup you speak of is also a feature of OnlyKey. By using a passphrase you can securely backup your OnlyKey. If you lose the key you can just restore from backup to a new key using the secure backup. With OnlyKey you don't have to worry about getting locked out if you lose your key.

You set one up with backup methods (backup key, TOTP and single-use codes) to avoid getting locked out. You can still get into accounts fine if the key is gone because of the backup methods, you just lose the extra layer of phishing protection.

> I honestly don't understand how a YubiKey is supposed to help me secure my accounts if I get locked out of my accounts when I lose it.

The same way physical keys protect your home even when you lose them - you have spare keys for that event.

What do you do when you lose your house key or car key?

Pay someone to crack the security.

How much would it cost to pay someone to "break open" my GMail account if I lost access to all my second factors? I'm guessing more than the ~$150 a locksmith would charge me to break into my house. Probably a number of zeroes at the end more.

I don't think Google charges anything as long as you can prove you're the owner.

But even in the physical world, how often do you lose your house or car keys? I can't remember if I've ever lost them for good and had to pay a locksmith. It just doesn't happen. I do have a spare of each key (or another type of key like a garage door opener) I'm case it does happen. Why does everyone bring up the problem of lost keys when it comes to computers? It's no t that big of a deal. I know I've lost or forgotten far more passwords than I have physical keys over the course of my life. Am I that different from the average person?

If the device doesn't have a secure element, how can anyone take it seriously as a strong root of trust? The page lists several recent attacks on secure element, but that's not really enough to convince me that no secure element is needed.

This is an interesting question. I would like to see more discussion like this in the security community. Of course this question should be proceeded by the question of what actually qualifies as a secure element? Who decides it's secure? If it's just an MCU with some basic security features you have to sign an N DA to even test is that a secure element? Is it possible to create an open source secure element without an NDA required?

OnlyKey's ability to type passwords differentiates it for my use cases.

I can use OnlyKey to type long BIOS, disc, user and root passwords without worrying about people around or security cameras.

YubiKey can also do this:

https://www.engineerbetter.com/blog/yubikey-static-secret/

It can only store up to 2 passwords, OnlyKey stores 24. For full comparison see https://crp.to/p

YubiKey does it too. I use it to unlock GELI.

Bought two of those last March. Mostly positive experience so far.

Previous firmware didn't restore U2F key from backup, but current one does. It also didn't have any kind of lockdown, so I did it via UDEV rules, luckily current firmware has a lock button, which even sends "Super-l".

I would also love onlykey-cli be ported to Python3.

Somebody mentioned here that onlykey isn't fit for keychain use, yet mine is totally fine and USB port shows virtually no signs of wear.

Another open source security key: https://sc4.us/hsm

Can this device function as an SSD, holding, for example, a Keepass2Android APK file and a KeePass database -- as well as being able to open said datanbase via one of the stored profiles? It doesn't need to have a lot of storage... 640 MB ought to be enough for anyone's KeePass databases.

No it doesn't store files directly, but if you are looking for KeePass support it is now supported directly by KeePassXC - https://keepassxc.org/blog/2019-10-26-2.5.0-released/

I use KeePassXC on macOS, Windows, and Linux and copying the database to the machines in question is easy enough. I was specifically thinking for iOS and Android without going through iCloud.

This [0] may or may not be of interest to you.

0. https://github.com/whs/K2AUSBKeyboard

This thing seems fishy to me. If you want something that is mostly under your control to which you can install open source stuff into then buy some smart cards and card readers e.g. from https://www.javacardsdk.com

Carrying your own smart cards and smart card reader may work for some use cases but I'm sure you can see why a small key attached to your key chain is a better solution in most cases.

There are readers the size of a thumb drive, cards themselves are the standard credit card size or even SIM card size if not contactless. It's not the real issue here, there are a few more important ones such as lack of desktop browser support for U2F NFC use case. U2F applet works fine for me on Android though.

Something way more solid apparently does exist: USB Armory.

https://inversepath.com/usbarmory.html

The hardware is open, the software is mentioned without much detail; I suppose it's not shipping yet.

This product does not meet the same use cases as Onlykey, USB armory not being portable, waterproof, and durable is not something that will fit most users needs.

Why does the code look like a copy-pasted mess? Kudos for making it open, though...

Thanks I guess... We always review PRs

One thing I immediately noticed is that apparently it supports exporting full backups of the device? Surely this is a terrible idea? I'm far from a security expert but I'd have thought you'd want to make it so that it is extremely difficult to extract key material from a security key, not offer it as a feature?

The backups are automatically encrypted with a private key you save onto the device (obviously the key is not part of the backup). To restore a backup onto the same device or a new OnlyKey, you first have to load the same private key that encrypted your backup.

I was interested until I saw the price tag: $46. Seriously, WTH?

Seems reasonable. The cheap YubiKey is $20 (over $30 with tax and shipping) while the series 5 YubiKey is $50-$70.

And I assume Yubico is capable of making much bigger (aka cheaper per unit) orders.

ykpass (https://github.com/noliran/ykpass) takes another approach at this. It generates unique strong passwords for every website, which are fully restorable without needing constant backups, thus providing a solution for non-U2F websites, which is - honestly - most of the internet at the moment

Unless you have a provable chain of trust that the code compiled is the code running on this thing then... Nah.

I trust Google’s Titan keys. shrug.

So Google Titan keys have a pretty bad track record when it comes to security:

https://www.engadget.com/2019/05/15/google-recalls-some-tita...

It's not possible to have a provable chain of trust on hardware as others have mentioned in the thread, even in the device you mentioned there is no proof that the code the manufacturer intended to run on device is the same code running on the device. Also its closed source so you wouldn't even know what code they intended to run.

In fact with Google Titan you have lots of other issues like that it's actually just a rebranded Feitian key, a China based company with unknown supply chain or possibly even China govt mandated backdoor. More on that here https://www.securitynewspaper.com/2018/09/06/experts-ask-goo...

You can check out the hardware of your key here, there is no tamperproofing at all.

http://hexview.com/~scl/titan/

The price seems ridiculous though. $2700?! Exactly what kind of audience is this geared towards?

Let me guess, you are Argentinian, jajajaja.

Where did you get $2700, OnlyKey is $46 USD

The prices are localized. So $2700...ARS

Where are the cad files, bom and other data needed to manufacture the device?

> " promote us and earn"

this doesn't send a good message

Open source is the only way to security in most cases.

Most of the security benefits come from giving the vendor an incentive to update their software quickly. I've often seen proprietary companies delay security critical patches until the next release or sue well meaning people who are reporting vulnerabilities (to the companies) as hackers to hide evidence of vulnerabilities.

There is a reason why so many vulnerabilities are found and reported in Linux compared to e.g. Windows. There is no censorship that tries to make the world look prettier than it is.

Everyone who cared to comment seems to agree that open source is a prerequisite for proper security in software. Interestingly I got down voted :)

Good point that the security of FLOSS stems from the culture surrounding FLOSS...

Sadly much of the implementation is still missing to be audited, things like schematics and hardware design need to be more robust before we can really call this open source hardware.

Older YubiKey are still FOSS. Newer not. From the top of my head anything 4+ is closed source.

If its auditable by anyone.

For one meaning of 'auditable by anyone', this is definitional for open-source systems.

Perhaps you mean 'if there's anyone with the domain-specific knowledge to audit the software successfully', well, the first kind of audit should determine that. If there isn't anyone who can evaluate the security claims, that's a pretty strong signal not to use it, no?

Reply on news.ycombinator.com