misusing USB keycards?

Posted Oct 4, 2017 16:20 UTC (Wed) by faramir (subscriber, #2327)
Parent article: Strategies for offline PGP key storage

If you enable USB on a system so you can use a USB based keycard, aren't you leaving that system open to BadUSB or similar attacks?
If an attacker has control over the computer in which the keycard is installed, they can subvert your data before it is sent to the card. Or simply just use the card directly.

If the keycard caches your password, could they wait until you authenticate to the card and then piggyback on that authentication for their own operations? Is there any indication on the keycard when it is being actively used?

Or maybe they capture the password as you enter it and exfiltrate it. Next time you go to Starbucks, they mug you and steal your keycard as well as your wallet. Depending on how high value a target you are, this seems reasonable. If you are a developer, you might be a much higher value target then you realize; depending on who uses the software that you write.

to post comments

misusing USB keycards?

Posted Oct 4, 2017 20:52 UTC (Wed) by anarcat (subscriber, #66354) [Link] (10 responses)

If you enable USB on a system so you can use a USB based keycard, aren't you leaving that system open to BadUSB or similar ttacks?

Yes, it's one of my core criticism of "airgapped" systems: they are never really airgapped. If you are referring to normal systems, I frankly don't know if you can still run an interactive terminal *without* USB these days. Unless you have a PS/2 mouse and keyboard (and port!), you're pretty much forced to use USB and therefore exposed to that vector anyways.

If an attacker has control over the computer in which the keycard is installed, they can subvert your data before it is sent to the card. Or simply just use the card directly.

Yep. They can use the card to do any operations it requires. But the point is they can do that only when it's plugged in: the second the key is unplugged, they can't do their evil thing anymore. Furthermore, they can't "steal" the key from you, unless they can find a way to subvert the keycard controller somehow, which is a critical difference with having the key on-disk.

If the keycard caches your password, could they wait until you authenticate to the card and then piggyback on that authentication for their own operations? Is there any indication on the keycard when it is being actively used?

Yes, they could and no, there's *generally* no visual indicator (although the Yubikey NEO does have a neat little LED in the middle that buzzes when things are happening on the key. It's hardly usable as an indicator, however.

I would rather see a keycard that would force me to tap it to confirm operations. Really, if you're concerned about that level of attacks, you should use one of those card readers that requires a PIN to be entered before operations are allowed on the key.

Or maybe they capture the password as you enter it and exfiltrate it. Next time you go to Starbucks, they mug you and steal your keycard as well as your wallet. Depending on how high value a target you are, this seems reasonable. If you are a developer, you might be a much higher value target then you realize; depending on who uses the software that you write.

I'm not sure there are such great protections against mugging. Pipewrench cryptography beats any design you can create, really - if that's your threat model, it seems to me you're setting yourself up to failure.

I'm not claiming offline key storage is the silver bullet, but it does solve *some* attack scenarios. The question is if the tradeoffs are worth it for *you*.

misusing USB keycards?

Posted Oct 4, 2017 21:43 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

My Yubikey prompts me to tap on it when it needs to do a U2F or OTP signature.

misusing USB keycards?

Posted Oct 13, 2017 13:34 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

GPG operations (CCID operations in general) are different from U2F/OTP/HMAC-SHA1. No tap is required.

misusing USB keycards?

Posted Oct 13, 2017 14:03 UTC (Fri) by johill (subscriber, #25196) [Link] (1 responses)

You can configure the Yubikey (at least 4) to do that too.

misusing USB keycards?

Posted Oct 17, 2017 21:23 UTC (Tue) by nix (subscriber, #2304) [Link]

Yeah, this is a new feature in the 4.

misusing USB keycards?

Posted Oct 4, 2017 21:44 UTC (Wed) by karkhaz (subscriber, #99844) [Link] (2 responses)

> Yes, they could and no, there's *generally* no visual indicator (although the Yubikey NEO does have a neat little LED in the middle that buzzes when things are happening on the key. It's hardly usable as an indicator, however. I would rather see a keycard that would force me to tap it to confirm operations.

Is the touch-to-sign feature on YubiKey 4 what you're looking for?

> YubiKey 4 introduces a new touch feature that allows to protect the use of the private keys with an additional layer. When this functionality is enabled, the result of a cryptographic operation involving a private key (signature, decryption or authentication) is released only if the correct user PIN is provided _and_ the YubiKey touch sensor is triggered

https://developers.yubico.com/PGP/Card_edit.html

misusing USB keycards?

Posted Oct 5, 2017 12:55 UTC (Thu) by anarcat (subscriber, #66354) [Link] (1 responses)

That's pretty neat, i gotta say. :)

misusing USB keycards?

Posted Oct 13, 2017 3:46 UTC (Fri) by ras (subscriber, #33059) [Link]

The consensus on Debian seemed to be Yubikey is in general very neat. It's amazingly robust, it's got all the features you want, and if they begged and pleaded enough they could probably get it at the right price. It's a consensus I agree with, as I use the things in my day job.

The fly in the ointment is its proprietary. Ergo some assume it's probably backdoor'ed. I'd be acting on the assumption too, even though I think on the balance of probabilities it's not. Add closed + proprietary and Debian don't mix well, and it doesn't look like Yubikey would fly with Debian.

misusing USB keycards?

Posted Oct 5, 2017 10:44 UTC (Thu) by tao (subscriber, #17563) [Link] (2 responses)

I always figured air-gapped meant that the system isn't accessible remotely, not that local attackers aren't able to reach it. If you have local access to hardware, generally all bets are off. An airgapped system isn't connected by WIFI, BT, ethernet, or whatever other means you use to connect to a network, and is preferably kept in a shielded environment. This is the kind of spec needed for things like machines used for signing top level certificates, etc.

The term I'd normally associate with a system that can withstand things like badUSB would be tamper-proof. An ATM, for instance.

Sometimes there's an overlap, and there are degrees of airgapping and tamper-proofing. You probably don't want wifi, BT, etc. for your ATM, but it's definitely connected to the Internet, though hopefully on a VLAN.

misusing USB keycards?

Posted Oct 5, 2017 12:57 UTC (Thu) by anarcat (subscriber, #66354) [Link] (1 responses)

if you're connected anyways, where's the gap then?

I could have written a whole article about air-gapped computers - that wasn't my purpose here. It's one of the approaches you can use, and i know it has its merits. the problem is the tradeoffs seem off to me. if you're connected to the internet anyways, how does it differ from a workstation behind a LAN?

the definitions of "air-gapped" sure seem pretty flexible around here... :p which is another problem: if we don't have a clear definition of what an "air gap" is, you're going to have trouble creating a proper threat model analysis...

misusing USB keycards?

Posted Oct 5, 2017 15:05 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> if you're connected to the internet anyways, how does it differ from a workstation behind a LAN? ... the definitions of "air-gapped" sure seem pretty flexible around here...

It doesn't. You and tao are both saying that an "air-gapped" system is not connected to either the Internet or a LAN. The difference is that tao's definition of "air-gapped" (reasonably, IMHO) does not encompass protection against a local attacker with physical access to the system, e.g. the BadUSB attack. That threat model requires a system which is "tamper-proof", which is a separate consideration from "air-gapped". A "tamper-proof" system can have network links (e.g. ATMs) and an "air-gapped" system can have USB ports. (Suitably restricted, of course—you don't your air-gapped system to automatically establish an Internet connection just because someone plugged a USB network adapter into the port intended for security keys. However, that can be addressed by limiting the USB drivers available, and/or configuring a whitelist of allowed devices.)