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 …
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?)
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.
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.)
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...
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.
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.
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!)
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.
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.
"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.
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.
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.
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.
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).
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.
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
