Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yubico announces tiny, cheap YubiHSM 2

yubico.com

Post reply on HN
Print view View original

71–80 of 94 posts

Re: Yubico announces tiny, cheap YubiHSM 2

#71

Post by SomeStupidPoint »

Cyph0n wrote: post #62
SomeStupidPoint wrote: post #60

Earlier quoted context omitted.

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.

I don't follow. Firstly, where is the encrypted request coming from? And more importantly, why would the CPU need to forge a request when it can just send an arbitrary plaintext to the HSM for signing (i.e., using the HSM as a signing oracle)?

How does it get arbitrary requests signed?

The module only supported two interfaces:

1. Network -> Buffer, where it takes a packet with a particular structure and encrypted data and emits a signed plaintext.

2. Buffer -> Network, where it takes a request, result, and proof object and sends them out after signing and encrypting.

We were using it to front solvers that did a lot of work to solve constraints and emitted a proof object, so clients would send us requests (not our problem how they generate them) and then we had to show we did the right thing. The CPU didn't know either key, so it could either:

1. Compute the right thing, have results signed.

2. Compute something that doesn't match the signed request; have its faulty proof signed and returned. (Detected by the consumer when they verify.)

3. Fail to compute.

So this was guarding the case where a CPU was compromised and could possibly emit faulty (or malicious) results.

The point is that HSMs can allow for securing a computation chain if you can securely sign the root, even against compromised CPUs.

Re: Yubico announces tiny, cheap YubiHSM 2

#72

Post by j_s »

Cyph0n wrote: post #62
SomeStupidPoint wrote: post #60

Earlier quoted context omitted.

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.

I don't follow. Firstly, where is the encrypted request coming from? And more importantly, why would the CPU need to forge a request when it can just send an arbitrary plaintext to the HSM for signing (i.e., using the HSM as a signing oracle)?

The technical details need to be answered by someone with hands-on experience, but the YubiHSM1 manual documents use of AEAD (RFC 3610: Authenticated Encryption with Associated Data), and references AEAD/client keys required for two modes of operation (HSM/WSAPI). Also: truckloads of reminders to never re-use a nonce in AES-CCM.

Most interactions with remote servers involve higher-level crypto primitives, but if a secure client has these keys it should be possible to interact securely with a remote YubiHSM (assuming secure initial setup, keys must remain secure, etc.).

Re: Yubico announces tiny, cheap YubiHSM 2

#73

Post by j_s »

wav-part wrote: post #69
j_s wrote: post #55

Earlier quoted context omitted.

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…

> 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). Whats the point ? We already have a secure system. Trezor is an ideal HSM. Chromebook C201 can make most secure (not s…

I appreciate your willingness to voice your concerns and doing so probably has helped many (including myself) to better understand where the "cheap" YubiHSM2 fits into the market.

I would be interested to see a performance comparison between a Trezor and the YubiHSM, v1 and/or v2. I assume the Trezor compares within an order of magnitude to a regular Yubikey of the same vintage. Trezor may even make sense as a "getting started" tool for server security under light load, especially if 6 of them combined even come close to matching the performance characteristics of the YubiHSM2. Perhaps this is the next logical market for the Trezor manufacturer to pursue?

Yubico is very up-front about the limitations of their device once you get to the point of reading the YubiHSM1 manual (couldn't find v2):

https://www.yubico.com/wp-content/uploads/2015/04/YubiHSM-Ma... [PDF] section "2.14 Security Considerations"

Although the physical security is a part of the concept, it should be explicitly underlined that the main design objective for the YubiHSM is to protect symmetrical keys and other sensitive in transit and data stored on servers from being compromised by remote attacks.

...

As a kind of final word on this subject, the reader may wish to bear in mind the practical and theoretical attacks in this realm must be soberly considered both rationally and practically and should neither be exaggerated nor neglected. The intention with YubiHSM is not the right product for all authentication needs, but to provide the most cost efficient vs. security compromise consistent with the YubiKey philosophy.

Re: Yubico announces tiny, cheap YubiHSM 2

#74

Post by morpheuskafka »

Cyph0n wrote: post #48
j_s wrote: post #45

Earlier quoted context omitted.

> 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 you trust this YubiHSM but not Intel CPUs, then it is very useful since encryption/decryption occurs on the YubiHSM, not the connected CPU. Just plug it into a computer with a CPU you do trust first to get the official public key(s) for future verificati…

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.

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

Re: Yubico announces tiny, cheap YubiHSM 2

#75

Post by CaliforniaKarl »

baby wrote: post #28
CaliforniaKarl wrote: post #7

Earlier quoted context omitted.

From a quick check, I'd say the big differences (Yubikey HSM 2 over Nitrokey HSM) are: 4096-bit RSA, curve25519, higher capacity, and smaller form factor. EDIT: On further thought, the small form factor would be good for physical verification. I could get a good, high-quality server, plug this into the front USB port, and then use some sort of transparent epoxy to seal it in. Having it on the front of the server woul…

How is 4k RSA a plus?

Hello! I don't believe I called 4k RSA a "plus", I just called it a difference. But, I do like the fact that it's available, even if it isn't particularly useful right now.

I could put it another way with regards to the EC algorithms. Many people do not trust the P-series curves, or the brainpool curves, and so for them there is support for curve 25519.

Re: Yubico announces tiny, cheap YubiHSM 2

#76

Post by j_s »

hdhzy wrote: post #25

I hope te EdDSA curve 25519 support in YubiHSM2 means we'll see the curve also in Yubikeys (e.g. OpenPGP applet). Currently Yubico's OpenPGP supports only RSA but there are already tokens supporting this modern crypto [0]. [0]: https://debconf17.debconf.org/talks/162/

> there are already tokens supporting this modern crypto

I looked briefly but can anyone link to where to buy one? Thanks in advance (either way: "buy" link or no) for the info.

Re: Yubico announces tiny, cheap YubiHSM 2

#78

Post by j_s »

synicalx wrote: post #12

Never really touched one of these HSMs before, what happens if you're using one in production and it dies?

https://news.ycombinator.com/item?id=12069784

>mdewinter(2016Jul): They [undisclosed HSM vendor] did, with undocumented commands, export the key from the device in an unencrypted format and loaded it into the other model so that we could continue our operation.

(The first comment I ever favorited on HN.)

Re: Yubico announces tiny, cheap YubiHSM 2

#79

Post by [deleted] »

CaliforniaKarl wrote: post #7
confounded wrote: post #3

What's the advantage of this over the ~$100 open source NitroKey HSM? https://www.nitrokey.com/files/doc/Nitrokey_HSM_English.pdf

From a quick check, I'd say the big differences (Yubikey HSM 2 over Nitrokey HSM) are: 4096-bit RSA, curve25519, higher capacity, and smaller form factor. EDIT: On further thought, the small form factor would be good for physical verification. I could get a good, high-quality server, plug this into the front USB port, and then use some sort of transparent epoxy to seal it in. Having it on the front of the server woul…

[deleted]
Post reply on HN