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

61–70 of 94 posts

Re: Yubico announces tiny, cheap YubiHSM 2

#61

Post by Cyph0n »

j_s wrote: post #54
Cyph0n wrote: post #52

Earlier quoted context omitted.

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

> 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.

Take TLS/HTTPS as an example. The underlying assumption is that your browser's and/or OS certificate store are trusted. If an attacker compromises your machine and adds a new certificate to that "trusted" store, all secure communication is broken. That is the inherent weakness of public-key crypto.

Back to the Yubikey scenario. Let's say a remote server R wants to talk to the Yubikey Y on your PC. Y initially generates a key pair and then (somehow) securely delivers the public key to the remote server R. Clearly, whenever R sends something to Y, an attacker wouldn't be able to decrypt the message unless it has the private key which is securely stored on the HSM.

Scenario (1) above was looking at the case of an attacker who somehow "tricks" R into updating/replacing/revoking the original public key and inserting his own key into the remote key database. If successful, the attacker could then intercept all inbound communication from the remote server and decrypt it.

> The sales page promises the following, but I didn't quickly find any details on how it works:

It looks like marketing speak to me honestly. If the computer/server the Yubikey is talking to is compromised, there really is nothing stopping an attacker from using the Yubikey to perform arbitrary encryptions and decryptions.

Re: Yubico announces tiny, cheap YubiHSM 2

#62

Post by Cyph0n »

SomeStupidPoint wrote: post #60
Cyph0n wrote: post #52

Earlier quoted context omitted.

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.

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)?

Re: Yubico announces tiny, cheap YubiHSM 2

#63

Post by davidpelaez »

This is amazing and literally filling a void for companies aware of the benefits but lacking the budget. There's one last barrier though: how to use this in the cloud? A partnership with AWS to have this as a service would be amazing because their HSM offering is not affordable and also because for many compliance reasons companies use AWS (PCI DSS for example) and there would be no way to include HSM 2 there. Let's hope this happens!

Re: Yubico announces tiny, cheap YubiHSM 2

#64

Post by gumby »

stedaniels wrote: post #20
gumby wrote: post #13

Think there's a chance we could get a Type C key someday that's as small as that (well, literally smaller, but I'm thinking something not much larger than the shell that will stick out of my machine about as much as that Type A one does.

How many servers have you got with Type C being primary accessible/secure ports? You realise this is the HSM and not the key right? Yubico has a Type C Yubikey called the 4C Nano https://www.yubico.com/product/yubikey-4-series/#yubikey-4c-... of you're just looking for keys. Though I can't see why you'd be so interested in a tiny HSM, could you tell me your use case?

Thanks I didn’t notice this was the HSM. I hadn’t seen the Nano when I got a machine and have an ugly leash right now.

Re: Yubico announces tiny, cheap YubiHSM 2

#65

Post by j_s »

Cyph0n wrote: post #61
j_s wrote: post #54

Earlier quoted context omitted.

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

> 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. Take TLS/HTTPS as an example. The underlying assumption is that your browser's and/or OS certificate store are trusted . If an attacker compromises your machine and adds a new certificate to that "trusted" store, all secure communi…

Are we in agreement that no HSM can completely protect against scenario 1? (If I can't verify the key [varying degrees of "hard" when connecting across the internet], it can be replaced.)

[edited] That is why I don't see this as relevant, it is outside the threat model any HSM attempts to protect against. More mitigation is possible than the YubiHSM provides, using a display/inputs on the HSM itself to verify keys and choose/confirm operations.

I appreciate your patience in carefully explaining your perspective, and this issue is definitely something to keep in mind in general.

Re: Yubico announces tiny, cheap YubiHSM 2

#66

Post by gumby »

Xylakant wrote: post #21
gumby wrote: post #13

Think there's a chance we could get a Type C key someday that's as small as that (well, literally smaller, but I'm thinking something not much larger than the shell that will stick out of my machine about as much as that Type A one does.

Like the 4C nano? https://www.yubico.com/product/yubikey-4-series/#yubikey-4c-...

Thanks, i hadn’t noticed they had released that.

Re: Yubico announces tiny, cheap YubiHSM 2

#67

Post by Cyph0n »

j_s wrote: post #65
Cyph0n wrote: post #61

Earlier quoted context omitted.

> 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. Take TLS/HTTPS as an example. The underlying assumption is that your browser's and/or OS certificate store are trusted . If an attacker compromises your machine and adds a new certificate to that "trusted" store, all secure communi…

Are we in agreement that no HSM can completely protect against scenario 1? (If I can't verify the key [varying degrees of "hard" when connecting across the internet], it can be replaced.) [edited] That is why I don't see this as relevant, it is outside the threat model any HSM attempts to protect against. More mitigation is possible than the YubiHSM provides, using a display/inputs on the HSM itself to verify keys an…

> That is why I don't see why this could possibly be relevant, it is outside the threat model the HSM attempts to protect against.

I agree completely. It's just something to keep in mind.

Re: Yubico announces tiny, cheap YubiHSM 2

#68

Post by baby »

benevol wrote: post #39
baby wrote: post #27

Earlier quoted context omitted.

HSMs are not protections against the gocernment. Simple as that

It's not just about the government(s). No backdoor remains exclusive.

> No backdoor remains exclusive

Cryptographically, this is possible (otherwise we wouldn't have public-key crypto. Humanely that's right, at some point in time someone will fuck up and reveal the backdoor.

Re: Yubico announces tiny, cheap YubiHSM 2

#69

Post by wav-part »

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

Earlier quoted context omitted.

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…

> 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 sure if its enough) HSM laptop. And I dont think performence is a requirement.

I more suprised why people are using YubiHSM like devices to store root keys. I dont mean to shit on someoneelse's party.

Re: Yubico announces tiny, cheap YubiHSM 2

#70

Post by EvanAnderson »

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…

For a project we did we put the Nitrokey HSMs on an internal USB port on the server then put a tamper-evident semi-trailer seal band on the built-in lock hasp.
Post reply on HN