undefined | Better HN

0 pointsCyph0n8y ago0 comments

If an attacker controls your computer, there is always the possibility of a man in the middle, even if you use a Yubikey. The attacker could simply wait for a request to the HSM and intercept the response.

0 comments

j_s8y ago

But they don't have the private key, that's the whole point of the hardware device! They can't MITM the encrypted data without it.

  plaintext <-> crypto <-> blob <-> *compromised server/anything but quantum computing* <-> blob <-> crypto / YubiHSM

Edit: I'm not talking about this:

  *my compromised PC* <-> plaintext <-> crypto <-> blob <-> crypto / Yubikey

In practice, getting anything done involves some CPU doing something useful with plaintext, if that's what you're getting at. As I said, you have to draw the line somewhere. Without sharing where you do this there is little point in talking about it. Personally, I can't see any problem with an Intel CPU (or any other hardware) acquired with cash in person, then never networked and if I wanted to go ultra paranoid: a chain of custody from the time of my acquisition demonstrating continuous physical surveillance.

My point is that I could securely "crypto" from my academic-dreamland/whatever secure computer through any transport to a YubiHSM connected to a compromised PC, if I trust Yubico (and the supply chain delivering their hardware) and the YubiHSM's initial/one-time setup.

Cyph0nOP8y ago

There are two potential attack scenarios, assuming some attacker A has full control of the PC connected to the Yubikey:

1. A somehow convinces the remote party that the actual public key is X' instead of X. Ciphertext comes in, attacker decrypts it. Done.

2. A intercepts ciphertext, feeds it to Yubikey for decryption, and gets the resulting plaintext over USB (or whatever). Note: this is assuming that the Yubikey doesn't have encrypted filesystem support or similar.

Combining 1&2, A can use the Yubikey as an oracle to perform unlimited authentications, signing, and decryptions.

The only advantage provided by a Yubikey is that your keys cannot be remotely exfiltrated. Physical attacks on the hardware are still possible though.

j_s8y ago

I don't understand what option one has to do with any of this, if you can switch keys there's nothing any amount of extra hardware can do. In that case, just use the key you switched to.

It is true that hardware tokens without an integrated external I/O (not through the PC it is plugged into) are vulnerable to this type of attack during initial key setup. Maybe they should support using the indicator LED to morse code thumbprints or something, but if you can't trust I/O to the device during setup you're going to have a bad time. I will quote my original caveat here:

> Just plug it into a computer with a CPU you do trust first to get the official public key(s) for future verifications!

Your second point seems to be that the plaintext has to be exposed (either going in or coming out) at the USB/hardware interface level, which makes more sense to discuss. The sales page promises the following, but I didn't quickly find any details on how it works:

https://www.yubico.com/products/yubihsm/

Secure session between HSM and application

The integrity and privacy of commands and data in transit between the HSM and applications are protected using a mutually authenticated, integrity and confidentiality protected tunnel.

1 more reply

SomeStupidPoint8y ago

We didn't use Yubikeys, but I've used a hardware module to go from encrypted request -> signed plaintext request. A compromised CPU has no way to emit a new signed request, so it can't forge a a request + computation, only fail to compute or emit an invalid proof object.

I don't know about Yubikeys, but if they can sign their emitted plaintext, they could be used to similar effect.

1 more reply

fgonzag8y ago

The only advantage of the Yubikey is absolutely massive though. It means not having to worry about revocating private keys or dealing with recurring forgeries after a security breach.

As long as you mitigate the current exploit, you've stopped any forgeries from that point forward.

morpheuskafka8y ago

MITM can't capture something that is never sent, like the private key. Same thing with a TPM.

j / k navigate · click thread line to collapse

0 comments

j_s8y ago

But they don't have the private key, that's the whole point of the hardware device! They can't MITM the encrypted data without it.

  plaintext <-> crypto <-> blob <-> *compromised server/anything but quantum computing* <-> blob <-> crypto / YubiHSM

Edit: I'm not talking about this:

  *my compromised PC* <-> plaintext <-> crypto <-> blob <-> crypto / Yubikey

Cyph0nOP8y ago

There are two potential attack scenarios, assuming some attacker A has full control of the PC connected to the Yubikey:

1. A somehow convinces the remote party that the actual public key is X' instead of X. Ciphertext comes in, attacker decrypts it. Done.

Combining 1&2, A can use the Yubikey as an oracle to perform unlimited authentications, signing, and decryptions.

The only advantage provided by a Yubikey is that your keys cannot be remotely exfiltrated. Physical attacks on the hardware are still possible though.

j_s8y ago

I don't understand what option one has to do with any of this, if you can switch keys there's nothing any amount of extra hardware can do. In that case, just use the key you switched to.

> Just plug it into a computer with a CPU you do trust first to get the official public key(s) for future verifications!

https://www.yubico.com/products/yubihsm/

Secure session between HSM and application

The integrity and privacy of commands and data in transit between the HSM and applications are protected using a mutually authenticated, integrity and confidentiality protected tunnel.

1 more reply

SomeStupidPoint8y ago

I don't know about Yubikeys, but if they can sign their emitted plaintext, they could be used to similar effect.

1 more reply

fgonzag8y ago

The only advantage of the Yubikey is absolutely massive though. It means not having to worry about revocating private keys or dealing with recurring forgeries after a security breach.

As long as you mitigate the current exploit, you've stopped any forgeries from that point forward.

morpheuskafka8y ago

MITM can't capture something that is never sent, like the private key. Same thing with a TPM.

j / k navigate · click thread line to collapse