LWN: Comments on "One-time passwords and GnuPG with Nitrokey"

One-time passwords and GnuPG with Nitrokey

Gee-Gee — Sat, 23 Dec 2017 15:49:24 +0000

The article is wrong, one CAN generate the private key on the Yubikey NEO, see https://www.yubico.com/support/knowledge-base/categories/...

One-time passwords and GnuPG with Nitrokey

gdamjan — Thu, 11 Aug 2016 17:54:56 +0000

even if you use gpg-agent to store ssh keys?

One-time passwords and GnuPG with Nitrokey

ras — Thu, 04 Aug 2016 02:14:53 +0000

Precisely. For me the killer feature of Yubikey is it's keyboard emulation. Press the button and it spits out a OTP in very plain text any application can accept. It's gained numerous other features over time, but none are as useful as that particular one. It meant it worked with all hardware on the planet. It was so simple open source didn't really come into it - you didn't need much in the way of source at all.

Give me Yubikey like thingy that did the same trick, albeit with battery and bluetooth keyboard emulation added on (particularly if you could recharge the batter from USB), and I'd be in heaven.

Does anybody know if such a thing exists?

One-time passwords and GnuPG with Nitrokey

davidstrauss — Mon, 01 Aug 2016 18:31:16 +0000

Yep, I use it that way, too. However, the latest OpenKeychain supports USB-based tokens, which most Android devices can run using an adapter (USB OTG for micro USB or a host adapter for USB Class C). Not saying that's great, but it would work.

One-time passwords and GnuPG with Nitrokey

farnz — Mon, 01 Aug 2016 17:21:52 +0000

The button increases the chance of the attacker being noticed - if your token suddenly needs two button presses to make it work instead of the previous one, you're more likely to suspect a problem and investigate. When diagnostics in a clean machine shows that the token is fine, and a fresh token shows the same failure on your compromised machine, the machine becomes questionable, and even if you replace it because you suspect hardware failure (not software), the attacker still loses for a time period. Not something you can rely on in a security analysis, but valuable for the cases where the compromise required the attacker to have physical access (e.g. an opportunistic attack when you left your laptop unlocked in a bar when you went to buy another beer).

Plus, it makes life harder for the attacker, because they now not only have to account for your smartcard's presence, they also have to account for whether or not you're willing to push the button; while a security analysis has to assume that you pressed the button every time the attacker needed you to (because that's the worst plausible case), the actual chances of getting away unscathed increase (because you might not have actually pushed the button when they needed you to). Again, not something you can rely on in a security analysis, but an improvement in the real world.

One-time passwords and GnuPG with Nitrokey

DigitalBrains — Mon, 01 Aug 2016 16:53:13 +0000

> [...] but it time bounds the attacker's access because the moment they lose access to my machine, they lose access to future session keys. This is enough to be useful - granted, you may be able to access all confidential e-mails sent to me in 2016, but, without having to get my correspondents to change the key they use, I can be assured that you can't get at the 2018 e-mail, as you don't have the private key

I think this is ultimately the use case of a smartcard. It limits access to the key to the time frame where the attacker has access to the smartcard. For this use case, you don't need the button, though, or am I not fully understanding your intention?

By the way, I still keep a backup of my encryption key, it doesn't just exist in the smartcard. So the premise of "no way to copy the key" is weakened, but at least I can store this backup securely, I don't actually need it normally. However, smartcards will die eventually. You can re-issue signature and authentication keys, but loss of your encryption key equals loss of all files that are only encrypted to that key!

One-time passwords and GnuPG with Nitrokey

farnz — Mon, 01 Aug 2016 16:34:49 +0000

I know that my work laptop reports back the use counter from my work Yubikey. I don't know how it's done, but I can see the use count for my Yubikey in internal logging, and I know that IT react to this if the use count jumps too quickly.

And yes, it boils down to "how many accesses does the attacker need to compromise a system"; equally, though, the use of a hardware token and multiple keys (short press for "day-to-day" key, long press for "external release key", for example) means that a compromise does not necessarily reveal the key the attacker needs. Without other means to combat intrusion, it's not enough - as you point out, I can piggyback on a legitimate session - but it time bounds the attacker's access because the moment they lose access to my machine, they lose access to future session keys. This is enough to be useful - granted, you may be able to access all confidential e-mails sent to me in 2016, but, without having to get my correspondents to change the key they use, I can be assured that you can't get at the 2018 e-mail, as you don't have the private key, and I've closed your intrusion vector and rebuilt the compromised systems from trusted media.

One-time passwords and GnuPG with Nitrokey

DigitalBrains — Mon, 01 Aug 2016 16:20:40 +0000

If you check each and every signature on a secure PC, I think you're good for signing. Unless a false signature or authentication is what leads to the compromise of the secure PC :-). And I might simply not think of something clever right now.

For authentication, my impression of what could happen is in the wall of text I just posted above here, near the end.

However, for signatures, realise that what you sign is ultimately a bunch of bytes, and the interpretation of those bytes might differ depending on what program is reading them. What in one file format might be harmless and more importantly unseen metadata like a comment field, might in another format actually do something harmful, something which you just authorized when you signed that binary that the compromised PC presented to you.

One-time passwords and GnuPG with Nitrokey

DigitalBrains — Mon, 01 Aug 2016 16:12:30 +0000

Do you know of any software and infrastructure that actually does all this securely, or is it hypothetical? Because OP said "the *real* killer feature". If you now say that you need more features to make it feasible, and these features aren't actually available, where does that leave Yubikey's killer feature?

Let's assume a user has all this infrastructure in place... and let's assume you want the counter to be correct. If all you're after is limiting the amount of uses of the smartcard, rather than counting them, skip right down to the TL;DR at the bottom ;).

It seems to me you need a proper log of operations. In your example, you discovered the compromise after three days. I'd consider three months more likely, if at all. I'm not talking about a script kiddy, they don't do anything interesting with your smartcard anyway. We're talking about an invested attacker, a good one. They are targetting you and your private keys specifically.

How safe is this log of signatures and decryptions? If it's kept on the same compromised PC, we seem to agree you can cheat. So the user needs a secure PC to check the log, often enough that they can spot discrepancies between what they did and what the log says. You also should check every signature you've made.

> Equally, if you have 4 signs, 2 decrypts, and you can show that each decrypt was of a fresh, previously never decrypted document, you're clear.

I think you'd probably like to be able to access a document multiple times. "Ah, this Thursday we have a meeting." *Closes e-mail*. "Oh wait, was it at 15:00 or 15:30, what did it say again?" *Opens e-mail again*.

So supposing you actually like to read a document multiple times, I think you should save a log of session keys yourself. Do you encrypt this log of session keys? In that case you're back to square one: you still need to use your smartcard, and the trick could be applied again. So you should protect the log of session keys with something like a normal password, not your smartcard. You also need to be able to share this log of session keys between all computers you don't fully trust, since the attacker could control two PC's and share *their* secret log of your session keys.

And what when there's an intermittent failure? USB sticks and especially smartcards have this tendency to once in a while fail. No problem: you press the button again, or replug the stick. Except if you're paranoid enough. Then you need to consider this failure as a compromise: it certainly didn't do the decryption or signature you requested from it. Was it really just a soft failure, or did somebody just decrypt or sign something?

And does the button have good mechanical feedback? Can you tell with 100% certainty whether you pushed it well enough? Or did the stick wiggle in the slot and did you slip over the button?

Anyway, this all requires a major amount of user discipline. Checking the log, making sure a keypress is a keypress, plus the tendency of seasoned computer users that when it fails, you simply try again without giving it much thought.

And I think it's pretty much a lost case in the case of authentication. Surely you'd like to log in to a machine multiple times. The attacker could surf on your legitimate login, and either install a method to do login without smartcard auth or simply leave the connection open. Next time you login, it connects you to the target machine using something else than your smartcard authentication token, and uses your press of the smartcard button as they see fit.

I'm sure you could think of "aha, but what if you do ..." for almost every way an attacker could try to coax you into pressing the button for them, but how realistic is it that someone with a Yubikey actually does *all* those things, each and every time, without fail? And I'm not convinced a suitably clever attacker can't think of something that would instantly become my new favourite because there is no "but what if" to. Unfortunately I would probably never know, since the people spending the most time thinking about this are not always the people to warn others of it.

TL;DR: I think it boils down to: you limit the amount of signatures or decryptions an attacker can do. How many signatures or decryptions does it take to do something really bad? For free software developers: I think you need just one signature to insert a backdoor into some system, and the backdoor does the rest of the job without needing any more signatures.

One-time passwords and GnuPG with Nitrokey

plundra — Mon, 01 Aug 2016 15:00:35 +0000

Ah, interesting - But this would only be for the decryption scenario, surely? Both authentication and signing operations should be done completely on the card, no?
And of course you can still be tricked to do such a thing, but hopefully you notice if the thing you wanted to authenticate against or sign wasn't, and that someone might have "used" the touch confirmation for its own use.

But yes, encryption thing is worth noting for sure, haven't really thought about that.

One-time passwords and GnuPG with Nitrokey

farnz — Mon, 01 Aug 2016 14:17:09 +0000

It does, however, limit the number of uses the attacker can make of the smartcard's function - they are limited to one use for each time you can be convinced to touch the button.

When you combine that with suitable logging, you can produce yourself a timeline of the form "On 29th July 2016, $system logged that it had had 201769 pushes of the button. On 30th July 2016, $system was broken into leaving malware; we detected this on 2nd August 2016, and after removing the button from the compromised system, determined it had had 201775 pushes of the button. We thus can deduce that the attacker could only have performed a maximum of 6 OpenPGP operations with this key".

If you can then identify all 6 operations without trusting the compromised machine, you now know the full extent of the fallout form the compromise - for example, if you can find 6 unique "sign" operations that took place during the compromise, you're clear. Equally, if you have 4 signs, 2 decrypts, and you can show that each decrypt was of a fresh, previously never decrypted document, you're clear. If you have 4 signs, and 2 decrypts of the same document, you now know that the attacker has up to 2 session keys or signatures that are unauthorised.

One-time passwords and GnuPG with Nitrokey

DigitalBrains — Mon, 01 Aug 2016 11:51:50 +0000

No, you cannot reliably prevent key *usage* when your smartcard is connected to a compromised system. The smarcard only generally prevents key *extraction*.

Here's a simple counter-example. You want to open encrypted document A on the compromised PC (you don't know that last bit), but you want to avoid your attacker reading the much more important document B, which you only open on fully trusted PC's. Unfortunately, your attacker got the encrypted document B. No biggy, it's encrypted.

You open document A on the compromised PC. Your smartcard decrypts when you press the button. The attacker controls the PC and saves the symmetric encryption key for document A.

Two days later, you wish to read something in document A again. The attacker-controlled PC asks the smartcard to decrypt document B, and you press the button, so it does. Meanwhile the PC uses the symmetric key it logged earlier to open document A for you, and you are under the impression you only ever authorized two decryptions of document A. You think you never decrypted document B so conclude your attacker can't have it, but they do.

There are more methods that will likely succeed. This is just my favourite one.

One-time passwords and GnuPG with Nitrokey

plundra — Mon, 01 Aug 2016 09:42:10 +0000

The *real* killer feature of the Yubikey 4, which made us give up smartcards, is the ability to require a physical touch, like generating an OTP, for any PGP-operation.
So in case your computer is compromised, an attack may sniff the password to unlock the card, but won't be able to sign, decrypt or authenticate using the card willy nilly.

One-time passwords and GnuPG with Nitrokey

kreijack — Fri, 29 Jul 2016 17:04:22 +0000

> To me this isn't a big deal if you are using it for OTP as part of a two-factor authentication.
> Even if you lose the card it doesn't mean that they gain access. They still need to get your password.

If so, in what nitrokey is different from a... mass storage usb key equipped with a program which is executed by the host ? or an app in your phone ?

I think that to be not cloneable is the key factor for this kind of gadget.

One-time passwords and GnuPG with Nitrokey

misc — Fri, 29 Jul 2016 10:53:10 +0000

Just to be clear, yubikey 4 support bigger keys, and ECC based ones too, if I am not wrong.

It is a shame that openssh agent do not support ECDSA key with pkcs11 yet ( https://bugzilla.mindrot.org/show_bug.cgi?id=2474 ).

One-time passwords and GnuPG with Nitrokey

Lekensteyn — Fri, 29 Jul 2016 10:50:00 +0000

According to the hardware description at [1], an OpenPGP smartcard is embedded. Thus your PGP keys should be as safe as with other OpenPGP smart cards using a dedicated reader. This does not prevent attacks where the firmware on the device gets replaced by a a malicious one that logs pin codes though, akin to an Evil Maid attack on laptops with FDE.

[1]: https://github.com/Nitrokey/nitrokey-pro-hardware/blob/ma...

One-time passwords and GnuPG with Nitrokey

ballombe — Fri, 29 Jul 2016 08:59:46 +0000

Off-the-shelf secure microcontrollers are not off-limit to well-resourced attackers.

"monitor the input layer"

Gollum — Fri, 29 Jul 2016 08:50:00 +0000

Yes, that is not what the OP was looking for.

More like something that intelligently directs traffic from the host to the targeted USB device ONLY, rather than broadcasting it to all devices on the same hub (as the spec indicates should happen).

From a security perspective, this could hypothetically allow a malicious device to snoop on things like passwords being sent to a security token to unlock it, scrape data being written to a flash drive. eavesdrop on network traffic sent to a 3G dongle, etc, etc.

One-time passwords and GnuPG with Nitrokey

roc — Fri, 29 Jul 2016 05:34:37 +0000

I was thinking more like leaving it in a hotel room in China.

I agree this is not something most people would have to worry about.

One-time passwords and GnuPG with Nitrokey

nakato — Fri, 29 Jul 2016 02:33:21 +0000

The current G10 OpenPGP Smartcard's sold by KernelConcepts support 4096 bit keys.

One-time passwords and GnuPG with Nitrokey

corsac — Thu, 28 Jul 2016 21:49:45 +0000

I honestly don't care about the OTP part, what I'm worried about is the GPG part, because leaking the keys is really not something you want, either way. The “breaking in your house” part is a bit too much. Like nobody ever lost her keys, or left her backpack unattended in a train or in a bar… As always, it depends on your trust model and your own little paranoia, but people need to know that the fact it's a microcontroller in a token doesn't make it secure against everything.

One-time passwords and GnuPG with Nitrokey

drag — Thu, 28 Jul 2016 21:31:52 +0000

You are talking about somebody breaking into your house or your office, disassembling your key, cloning it, repairing it, and then returning it to you without your knowledge then stealing your password later one. That's some ninja-level stuff right there. I don't think it matters how much money they have. At that point probably having a 'secure processor' isn't going to help a whole lot. There are hundreds of other things they can do to you at that point that is worse then getting access to your accounts.

Getting the key stolen/lost is a issue, I think, with GnuPG type things, but it's really not a issue with OTP.

However having a secure processor is certainly 'nice to have' and would probably increase the usefulness of the device in the long run. I am curious what barriers to adoption it has right now; cost? practical limits to reprogramming the device?

"monitor the input layer"

mathstuf — Thu, 28 Jul 2016 21:07:02 +0000

More advanced KVM switches do USB since mice and keyboards tend to use those these days.

One-time passwords and GnuPG with Nitrokey

roc — Thu, 28 Jul 2016 20:21:54 +0000

That does make it easier for an attacker to clone your key without your knowledge and obtain your password later, or obtain your password first and maintain persistent access to your account. Agreed this isn't a big deal for most users, who hopefully won't ever face such a well-resourced attacker.

"monitor the input layer"

corsac — Thu, 28 Jul 2016 19:29:24 +0000

That also means a rogue USB device can get the PIN code sent to your smartcard in your USB smartcard reader if it doesn't use secure messaging.

"monitor the input layer"

JanC_ — Thu, 28 Jul 2016 18:32:27 +0000

USB switches exist, but are more like KVM switches: connect a number of client devices to 1 of 2 (or more?) host devices.

One-time passwords and GnuPG with Nitrokey

mjg59 — Thu, 28 Jul 2016 15:33:23 +0000

You can also buy a generic Javacard such as http://www.smartcardfocus.com/shop/ilp/id~707/j3a081-80k/... , build the Yubico PGP applet and install it with GlobalPlatformPro. We do this so our signing cards can contain both GPG keys and do RSA signing for Secure Boot (via IsoApplet)

"monitor the input layer"

Beolach — Thu, 28 Jul 2016 15:18:56 +0000

Now I'm wondering if there are USB "switches", analogous to network switches. This is pretty much the distinction between network hubs & switches too. Hubs broadcast to all connected devices, while switches learn the MAC addresses of the attached devices & only send on the port the destination MAC is connected to.

I'm guessing there aren't any USB switches, since USB has a much stronger host/device directionality in its link layer specification than ethernet does, so the extra expense of a switch instead of a hub wouldn't be worth it. But if there are I'd be interested to know.

One-time passwords and GnuPG with Nitrokey

drag — Thu, 28 Jul 2016 14:18:55 +0000

To me this isn't a big deal if you are using it for OTP as part of a two-factor authentication. Even if you lose the card it doesn't mean that they gain access. They still need to get your password.

For GnuPG applications, I donno. For personal use I don't see it as a big problem provided you never let the thing off your person while in public with it. If you are paranoid then I suppose you could use potting material or epoxy to encase the board (beware of differentials in thermal expansion for surface mount components) to make the device tamper-resistant and tamper-evident.

One-time passwords and GnuPG with Nitrokey

mricon — Thu, 28 Jul 2016 13:40:29 +0000

For those looking for PGP functionality, there are also several other worthy mentions.

1. The old-school PGP SmartCard (G10) and reader (Gemalto) from KernelConcepts.de -- unless you have a builtin reader. Most standard smartcard readers will do, I believe -- definitely for the 2048-bit cards. The only downside of buying from kernelconcepts.de is having to wait for 3 weeks for the shipment from Germany, so I would order 2 and make sure I have a backup card.
2. If you're in the US and don't want to wait for your PGP smartcard, you can alternatively get a Sigilance smartcard (https://www.sigilance.com/). Due to crypto export laws, they won't ship internationally. You'll also need a reader, and their cards are capable of maximum 2048-bit keys.
3. There's Gnuk (http://www.fsij.org/category/gnuk.html), which looks interesting but it's not a product you can buy. It's software you can install on a DYI-type board.
4. Finally, if you're already into cryptocurrency and are looking to get a hardware wallet, Trezor (https://bitcointrezor.com/) has builtin PGP functionality. It's both rather expensive and on the large side, so it's not something I would recommend for someone just for PGP storage.

"monitor the input layer"

Gollum — Thu, 28 Jul 2016 13:16:16 +0000

Wow, that *is* interesting. Thanks!

"monitor the input layer"

cladisch — Thu, 28 Jul 2016 12:34:52 +0000

Section 11.1.2.1 of the USB 2.0 specification says:

In the downstream direction, hubs operate in a broadcast mode. When a hub detects the start of a packet on its upstream facing port, it establishes connectivity to all enabled downstream facing ports.

However, when hubs translate between the different bit rates (low/full/high/super/super+ speed), they do care about the destination port.

One-time passwords and GnuPG with Nitrokey

nix — Thu, 28 Jul 2016 12:09:03 +0000

I'd buy this except that I use the OTP feature of the Yubikey a great deal, from multiple different OSes, and the lack of an OTP-generating button on the Nitrokey makes it a whole lot less convenient on that score.

"monitor the input layer"

Gollum — Thu, 28 Jul 2016 11:35:29 +0000

Citation needed, I think. I thought the whole point of having a hub was to direct the messages to the relevant device/port on the hub, and prevent the unnecessary broadcast of data.

"monitor the input layer"

mfuzzey — Thu, 28 Jul 2016 10:18:59 +0000

Not as far as I know.

However a USB device can intercept traffic from the same host controller to other devices. But it doesn't work in the other direction (a device can't intercept data from other devices to the host controller). This means that a rogue device connected to the same host controller / root hub could, for example, intercept data you are writing to a thumb drive but not data you are reading. The asymmetry is because hubs broadcast everything in the host=>device direction. I think this has changed in USB 3 though.

Also a USB device can enumerate as a keyboard whilst pretending to be something else. That allows it to inject fake keystrokes, but not intercept real keystrokes.

"monitor the input layer"

kruemelmo — Thu, 28 Jul 2016 10:06:33 +0000

the strange key sequence... *facepalm
thanks!!

"monitor the input layer"

Gollum — Thu, 28 Jul 2016 09:05:44 +0000

No, not really.

A USB Keyboard will receive notifications from the OS that another keyboard has pressed the toggle buttons, so that all keyboards can stay in sync in that regard. That doesn't give the other devices access to any of the other keys that were pressed.

"monitor the input layer"

kruemelmo — Thu, 28 Jul 2016 08:40:04 +0000

Today I learned that a USB device can intercept keystrokes from any USB keyboard. Really?

One-time passwords and GnuPG with Nitrokey

raymii — Thu, 28 Jul 2016 03:57:21 +0000

I'm became a huge fan of the Nitrokey HSM/SmartCard-HSM recently. It's not an OpenPGP smartcard but a smartcard (in USB formfactor) specifically for PKCS#11 applications, likeyour private keys in OpenSSH, S/MIME email certificate, general file encryption or to use with Apache and mod_nss. I'm not sure if I'm allowed to link, but I've written a few guides on the HSM: https://raymii.org/s/articles/Get_Started_With_The_Nitrok...

I've also got in contact with Jan from Nitrokey (and Andreas from SmartCard-HSM) and they've been very friendly and helpfull in answering questions and general feedback on the product.

The hardware quality of the Nitrokey is superb as well. It doesn't feel like flimsy chinese crap at al, but a sturdy, quality made USB device. I do believe it's made in germany, I saw a youtube video once on it.

The forum is also great for information, questions and guides: https://www.nitrokey.com/forum/

One-time passwords and GnuPG with Nitrokey

jhoblitt — Wed, 27 Jul 2016 23:51:37 +0000

As a yubikey/android user, I'm baffled that there isn't a stronger market demand for NFC capable devices. I may have to pick up a spare yubikey neo while they are still on the market.