Live data from Hacker News

Yubico announces tiny, cheap YubiHSM 2

yubico.com

51–60 of 94 posts

Re: Yubico announces tiny, cheap YubiHSM 2

#51
post #47

How can HSMs be considered MITM-proof if does not have dedicated input system (touchscreen/keyboard) ?

They only have to be accessed using a secure computer once to get the public keys for verification, right? Isn't that the whole point of public key crypto? This can be done using some ultra-slow homebrew whatever-level-you're-willing-to-trust custom hardware is necessary to satisfy the associated degree of paranoia.

Securing computer is lost cause. Thats why HSM exist: a small computer with simple processor, no appstore (only highly tested/secured inbuilt apps), no network access (limited and specific protocol not like IP), very limited functionality. These are what makes HSM very easy to secure.

Any user customization to HSM should be considered unsafe. The new system would be expensive and "brittle".

Re: Yubico announces tiny, cheap YubiHSM 2

#52
post #50
post #48

Earlier quoted context omitted.

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.

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'…

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.

Re: Yubico announces tiny, cheap YubiHSM 2

#53
post #52
post #50

Earlier quoted context omitted.

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'…

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 doe…

[deleted]

Re: Yubico announces tiny, cheap YubiHSM 2

#54
post #52
post #50

Earlier quoted context omitted.

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'…

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 doe…

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.

Re: Yubico announces tiny, cheap YubiHSM 2

#55
post #47

Earlier quoted context omitted.

They only have to be accessed using a secure computer once to get the public keys for verification, right? Isn't that the whole point of public key crypto? This can be done using some ultra-slow homebrew whatever-level-you're-willing-to-trust custom hardware is necessary to satisfy the associated degree of paranoia.

Securing computer is lost cause. Thats why HSM exist: a small computer with simple processor, no appstore (only highly tested/secured inbuilt apps), no network access (limited and specific protocol not like IP), very limited functionality. These are what makes HSM very easy to secure. Any user customization to HSM should be considered unsafe. The new system would be expensive and "brittle".

First you state: "Securing computer is lost cause." Then you give the constraints within which computing becomes "very easy to secure". As I previously stated: use a computer that fits within your definition of "very easy to secure" to setup the YubiHSM; after that, encryption using the HSM is theoretically secure to the degree the CPU accessing the plaintext is secure (this does not have to be the CPU the YubiHSM is plugged into).

The YubiHSM draws the line for "MITM-proof" (per your original comment) after initial key setup, in exchange for an order of magnitude reduction in price. The main difference between this and regular Yubikeys is the performance, things like supporting 16 concurrent connections. Yubico doesn't seem to use "MITM-proof" on their product page; is this basically a straw man? I guess it makes for an interesting discussion about the various theoreticals.

I am very much more interested in details on the tools you (as someone concered enough to ensure no one is misled) use to implement secure computing, most specifically how they have worked out for you in practice. Relatively inexpensive tools like Trezor and others with screens and buttons built-in may meet your criteria and suffice for personal use, but server-level performance isn't going to be there without a couple extra zeroes on the price.

Re: Yubico announces tiny, cheap YubiHSM 2

#56
post #49

I bought a Yubico key once. The thing was so cheap that between the time I set it up and the first time I actually had to use it, it had disintegrated just from sitting in my pocket every day on my keychain. The plastic was brittle and fell apart piece by piece until eventually the electronics fell apart too.

I've had two on my keychain for years now. One of them maybe 8 years and the other one a little over 3 years. Zero problems with them so far. They still work just fine.

Re: Yubico announces tiny, cheap YubiHSM 2

#58
post #22

How useful are such measures when Intel has backdoored each and everyone of their CPUs with its "Intel Management Engine" [0] (and AMD has a similar mechanism)? If Intel/AMD have a backdoor into every PC and server, then so does the US gov't (NSA, CIA, FBI, etc.) and of course other uninvited hackers from even hostile countries. And how did Western society just accept all of this anti-democratic craziness? [0] https:…

So I guess you just use 12345678 as your password everywhere?

Re: Yubico announces tiny, cheap YubiHSM 2

#59
post #9

How much of a market is there for HSMs that are not FIPS 140-2 certified?

FIPS 140-2 is not all that it is cracked up to be these days. Older algorithms, embarrassing failures in certified products, and general distrust of NIST since the Dual EC PRNG catastrophe means that the only folks that should be using FIPS 140-2 are legally required to. (Disclosure: I once took a hardware product through the FIPS process)

FIPS 140-2 also defines requirements around tamper evident, tamper resistant and tamper proof.

https://en.wikipedia.org/wiki/FIPS_140-2#Security_levels

It's a subsection of the larger FIPS 140.

Tamper resistant/Tamper evident (and not being able to simply pop the hsm in your pocket while walking by) are important considerations around physical security.

These look great for home or SMB use, but wouldn't work in PCI-DSS or Classified environments.

Re: Yubico announces tiny, cheap YubiHSM 2

#60
post #52
post #50

Earlier quoted context omitted.

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'…

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 doe…

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.

Post reply on HN