Google's OpenSK lets you BYOSK – burn your own security key

OpenSK, a new open-source project from Google, lets folk make their own security key for less than £10. You flash the OpenSK firmware on a Nordic dongle – and voila. The USB dongle includes the nRF52840 SoC (32-bit Arm Cortex-M4), supports Bluetooth Low Energy and NFC (Near Field Communication), as well as a user-programmable …

[Neil Barnes]

It's all very fascinating

and the w3org pages in particular - but my word it's jargon heavy. This makes sense for a standard but doesn't make it obvious for the casual browser... can anyone point me at a simple-to-understand guide to the technology?

As far as I (probably incorrectly) understand it, the security key is registered once with some trusted authority (please let it not be Google) and thereafter can be registered with multiple websites; the web sites require both a normal checkin (e.g. password) and the presence of this tag on the accessing machine?

(which raises two immediate questions: what if you lose the tag: are you then unable to access every site you've registered it with? and: what if the trusted authority decides to no longer offer the service?)

[The Man Who Fell To Earth]

Re: It's all very fascinating

I presume that like with other dongles like Yubikey, one can create functional clone keys if you bothered to record it's internal key when first generated.

[Brian Miller]

Re: It's all very fascinating

OK, clue time here: the private key is generated inside the hardware itself. There is no external generation of the private key. You send the chip a command, it performs the command, and it keeps the results of the command inside it. Then you perform cryptographic operations with that value for external use. There are a few really good crypto chips that do that.

Some chips do, indeed, require a programming step with external data. And some HSMs don't have a lot going on inside them other than running Linux with everything floating around in plain text while the device is in operation.

For simply doing things like 2FA, etc., there's at least two I2C chips that fit that bill. Otherwise, you're running everything in an OS of one flavor or another.

[NullNix]

Re: It's all very fascinating

You always have at least two keys (in different places), and register both of them with everything. If you don't, you will sooner or later be regretting it: USB devices don't last forever even if you don't carry them on your keyring. Any site that doesn't allow registration of multiple tokens against a single user identity is arguably broken: don't use it for 2FA unless it provides some sort of fallback (and even then, the fallback serves as a lower-security way in, reducing the security benefits of the key).

(Currently, I have four, but that's more because I lost one and then found it long after, and my then-backup didn't have NFC and I found I needed NFC on at least two of them, than because having that many keys is actually sane.)

[john.jones.name]

only good if you carry one... watch ?

WHY cant we have this on the iWatch apple ?

if they care about security then why do mac people have to use third party app's for industry standard security keys ?

the iWatch has bluetooth and NFC but they are hobbled in the name of security... yet Apple does not provide for real standard security...

[fidodogbreath]

Re: only good if you carry one... watch ?

iOS 13 supports FIDO2 in Safari. I understand that's not the same as using a watch or phone as the token, but it's a positive step.

Hardware tokens kind of scare me. Suppose I'm traveling. My options are to take both tokens with me and risk losing both; or take one and risk getting locked out of accounts on the road if it's lost or fails.

I use an OTP Auth, which is a TOTP code app that can sync codes between devices using iCloud. Phone lost? Get another one, restore the backup, good to go.

As a previous poster mentioned, most 2FA implementations (all kinds, not just hardware) have an account recovery method if the token is lost, which is another attack surface that could undermine 2FA. Necessary evil, I suppose; but still.

[Anonymous Coward]

Re: It's all very fascinating

What I do on all my personal stuff is register more than one key. I have one on my keyring, one separate one, and one backup smartcard in my safe at home. This way I can always get in. I use multiple modes of authentication (such as PIV, OpenPGP and Fido2).

Many services also offer backup one-time codes. Unfortunately not all sites offer multiple tokens but they really should, for this reason.

[ds6]

Re: It's all very fascinating

There are multiple ways to use security keys like this. The FIDO2 spec is the standard right now so I'd look into that if I were you. There are multiple modes you can use with it, including private/public key-based authentication, one-time keys that cycle based on an algorithm known fully only by the device (and can be solved on the authenticating end using the number yout device spits out), and third party PKIM authentication where you set up a chain of trust like you mentioned and the third party is contacted to verify your identity with a signed root certificate.

Here are some useful links to see how the technology is used in practice from a low but not too low level:

https://docs.microsoft.com/en-us/azure/security/fundamentals/ad-passwordless

https://developers.yubico.com/#learn (features all U2F modes!)

[Neil Barnes]

Re: It's all very fascinating

Thanks for those.

[jelabarre59]

Re: It's all very fascinating

the security key is registered once with some trusted authority (please let it not be Google)

Well you *DID* say "trusted", so that would leave Google out...

[TimMaher]

SIMs

I think my comment on the Twatter leak article is a better solution.

Dongles are easier to loose than phones.

Especially if you are me; or vice versa.

So there!

[Loyal Commenter]

Re: SIMs

SIMs are easier to clone than cryptographically signed security dongles.

Presumably you would arrange for a fallback auth method to revoke a lost dongle, so you're not locked out.

PS. the verb you're looking for is lose, unless you're referring to the dogs of war...

[Flocke Kroes]

Re: pedantry to Bernard Woolley's standards

"Cry 'Havoc!,' and let slip the dogs of war."

[Aladdin Sane]

Re: pedantry to Bernard Woolley's standards

You have not experienced Shakespeare until you have read him in the original Klingon.

[Loyal Commenter]

Re: pedantry to Bernard Woolley's standards

Well indeed, one would "let slip" said hounds by loosing them, to allow them to slip their bounds...

[Sir Runcible Spoon]

Re: pedantry to Bernard Woolley's standards

Gardner: Beggin' yer pardon yer honor, but there's some greenie types pokin' around inside the boundary hedge.

HisNibs: Loose the hounds on them Henry, they haven't been fed for two days.

[phuzz]

Re: SIMs

"PS. the verb you're looking for is lose,"

Explain it like this:

Lose - What you just did.

Loose - Your mum.

Lewes - A town in Sussex.

[dajames]

Re: SIMs

SIMs are easier to clone than cryptographically signed security dongles.

No, SIMs are cryptographically signed security dongles. That's sort-of the point of them.

If SIMs can be cloned it's because they're familiar mass-market cryptographically signed security dongles, and the mechanism of their issuance is weaker than it might be -- because the value that they protect is relatively low (the value of a mobile phone account) -- and it's designed for convenience as well as security.

[dajames]

Re: SIMs

Dongles are easier to loose than phones.

Yes, but phones are more stealable than dongles.

That is to say: The secret you protect with a dongle may be worth more than the cost of a phone, but an opportunist thief won't know how to use the dongle to realize that value ... he'll leave the dongle and walk off with your phone.

[Anonymous Coward]

Re: SIMs

Nah, your average phone thief will lift everything and chuck the bits they don't recognise in a bin, rover, pond, street, wherever.

They aren't likely to try and use the phone or the dongle to access your online accounts/data but they are likely to deprive you of access to them.

[iron]

Ooo those Nordic dongles look very interesting, as does this security key stuff form Google. I'll have to buy a few so I can experiment with them.

[mr_souter_Working]

Ditto

[Anonymous Coward]

"Rolling your own" is generally a bad idea when it comes to crypto. I'd rather spend a bit more on a Yubikey which is designed by experts.

For example: How well is this thing secured against side-channel attacks (e.g. power or timing based?). Real hardware tokens have substantial measures against these types of attacks.

[Kientha]

To the oscilloscope!

[alisonken1]

"Quickly Robin! To the BatScope - there's no time to lose!"

[Brian Miller]

Don't roll, buy

The Nordic dongle is simply a NFC CPU dev kit. This is not a solution I would recommend, and you could substitute just about any CPU on a USB key here. I could probably take the project and dump it on that Linux-on-a-business-card kit without too much difficulty. Good excuse to buy a SMT oven, though.

I do recommend the Microchip ATECC608A and ilk dev kits, though. I wrote a Python interface for their AT88CK590 dev kit, it wasn't that hard. The chips are good.

Yeah, side-channel attacks are a PITA. The company I work for runs tests for that on our chips, and has revved the prototype designs a couple of times to thwart that. All of the crypto operations look exactly the same.

[Anonymous Coward]

We're dooooomed

Our company is producing a similar security key and has been trying to sell/flog it since last year. Between this and Yubikey, I think we now have no chance in hell in breaking into that market.

I'm not working on this, but I appreciate the tech lead working on it and I'm sad to see all the hard work he's put into this go to waste because the product owner had done his market research beforehand.

[PJD]

Doesn't work in settings where devices are banned

The ridiculous problem I've been facing recently is a health data system that needs to be accessed by doctors treating inmates in a jail - the jail has a rigorous ban on phones and usb keys or similar, but local law requires 2FA for accessing health information. Fortunately the jail hasn't noticed that all the docs are sporting iwatches these days, so that's been our unofficial workaround. The official workaround will involve printouts of one-time pin numbers.. Gah.

[Anonymous Coward]

Re: Doesn't work in settings where devices are banned

How's that going to work? The systems that I know of the allow the creation of emergency token codes only allow 10 to be created? Of course, if you use RSA Auth Mgr, you can have your token put into lost mode - until you use your actual token again, and they'd just have to remember to log in using their token once they're back in the parking lot (or their office).

[doublelayer]

Re: Doesn't work in settings where devices are banned

One method I can think of is to use some of the codes, then generate some more (I can usually replace codes I've used as long as there are only a total of ten). The better method would be to have a separate unconnected hardware device approved by the security department so they can be taken in. That would fix all problems and be very logical, so I think we can assume that it will never get approved.

[Anonymous Coward]

How long before it's hacked?

I guess it will have to become popular first but then it will be worth hacking, I can think of a couple of possible vectors.

[Raithmir]

Expensive

Oh that sounds like an interesting project, and cheap compared to the equivalent from Yubico.

"you will also need the following extra hardware:

a Segger J-Link JTAG probe.

a TC2050 Tag-Connect programming cable.

a Tag-Connect TC2050 ARM2010 adaptor

optionally a Tag-Connect TC2050 retainer clip to keep the spring loaded connector pressed to the PCB.

Although OpenOCD should be supported we encountered some issues while trying to flash a firmware with it. Therefore we suggest at the moment to use a Segger J-Link probe instead. This guide does not cover how to setup the JTAG probe on your system."

yyyyeah... ok not so cheap. I'll buy another Yubikey instead.

[Anonymous Coward]

Sorry, no dice.

If I want a hardware key I'll start with not using anything from an outfit that's after my data (that's just a principle), and Yubikeys work in that context just fine and have the stability I need to be sure that the damn thing still works a couple of months down the line (instead of eventually abandoned for a new shiny object, aka "zuned").

Secondly, I like resilience, so I keep it simple and instead just use TOTP. It works on any platform, is well embedded and if the implementation is smart enough to not allow the token to be re-used in the 30 second window it's safe enough. That does, however, require you to lock down the device that generates your access codes but it also allows you to stick the secret in another device as backup.

That said, it depends on your risk model. If you're less worried about losing access than unauthorised access, resilience comes second.