Yubico announces tiny, cheap YubiHSM 2 | Hacker News Reader

Yubico announces tiny, cheap YubiHSM 2

yubico.com

138 pointsprocrastinatus83 comments

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://libreboot.org/faq.html#intel

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.

Does the recent successes of disabling Intel ME essentially solve this? https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Di... It's not easy, but for a security firm where the data on each computer is worth millions, it might be worth it.

Completely useless.

If you make that assumption then you have already lost.

However that is no reason not to use good security otherwise.

> And how did Western society just accept all of this anti-democratic craziness?

Because people buy it voluntary.

> And how did Western society just accept all of this anti-democratic craziness?

Western societies, so as not to upset the guise of freedom and personal rights to privacy, do so in secret but it's not exclusive to them. China publicly mandates government backdoors into their equipment too.

Computer security engineering is a branch of economics. If you try to think of it in all-or-nothing terms, you’re going to come up with silly ideas like “we shouldn’t bother trying to stop malware because the NSA could theoretically spend $1,000,000 and hack my laptop anyway”.

> 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 verifications!

If you don't trust this YubiHSM because of the example of Intel CPUs, then please share at what point you do trust third party hardware, so we can discuss how to get to useful encryption from there.

Would you only trust RAM you wire-wrapped yourself?

Would you only trust a motherboard you built from 7400 series logic gates, each of which you personally verified using X-rays?

The line has to be drawn somewhere, but without knowing where you want to do so your comment serves mostly to hijack discussion (which is fine).

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

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.

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.

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

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.

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

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.

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

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.

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

If your computer is backdoored, then a HSM does not protect effectively against that attacker. At some point the computer will see the data, at which point it can be extracted. The key is not important to the attacker which can read the unencrypted data.

A HSM does make attacks more difficult, and that is important. On the other hand, computers without backdoors would be _the_ significant step, though, to change the game.

I fundamentally dislike Intel and AMD for their stance on this. And I'm not alone.

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

Or they mailed a letter to a stranger with a wad of cash asking them to post this comment so they can avoid using computers completely

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 would make it easy to quickly confirm that it's in place (instead of hunting around the back of the server, and it would be small enough to seal into the USB port.

How is 4k RSA a plus?

Sometimes you're stuck needing RSA for something. When you are, you want 4k RSA.

Is 2048 RSA broken? I think that's what ssh-keygen creates by default, right?

> Is 2048 RSA broken?

Today(-ish)? HN's anointed crypto expert says no.

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

>tptacek(2017May): The point of modern RSA is that we use a modulus that can't be factored by any conceivable computer, with limits derived from the physics of computation and projected far out into the future. We aren't a supercomputer advance away from factoring 2048 bit moduli.

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.

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.

4096-bit RSA keys, for one.

No mention of the actual hardware (processor) they've used. I guess the bill of materials would be funny (although of course I realize that the value is in their expertise and software etc).

The performance specs [1] say "HMAC-SHA-(1|256): ~4ms avg" which I guess is for 256 bits [2], compared to [3] which list a 6th gen Skylake 3.1 GHz doing it at 535 MB/s.

[1]: https://www.yubico.com/products/yubihsm/

[2]: But I have no idea, perhaps this is a stupid interpretation, in which case I'll turn around and blame them for being unclear.

[3]: https://www.cryptopp.com/benchmarks.html

I must add this post https://plus.google.com/+gregkroahhartman/posts/WK6ZLEhfQo5 Is it open source? "Yubico has replaced all open-source components that made yubikey NEOs so awesome with proprietary closed-source code in Yubikey 4s"

An even lower cost (and open-source) alternative:

https://sc4.us/hsm

The SC4-HSM also includes dedicated I/O (a display and two buttons) which makes it more secure than the Yubikey.

Disclosure: this is my product.

[edit] Disclosure?

Done. It's my product.

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

You retrieve the backup HSM and continue on.

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

Wow thanks for the link, that's a bit concerning. Not an expert on HSMs, but this does seem like a fairly serious design flaw?

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!

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.

Errr, I was referring to Gnuk [0] that claims support, but it's rather a DIY project [1] than something to be mass manufactured. Sorry to disappoint you but from my shallow research in this matter the hardware used has several flaws (e.g. no secure element).

[0]: https://github.com/RaymiiOrg/gnuk/blob/master/README

[1]: http://www.fsij.org/gnuk/howto-make-gnuk-usb-token-by-stm32-...

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

Because it is a clever way of not considering that MITM but man in the machine (which is almost the same in my opinion in the case of possible damage but has more attack vectors). Most companies consider MITM an external compromise since the malicious actor is not on the machine itself or has no-longer access to the machine(s).

Even most 'dedicated' systems do NOT have a direct link to the input terminals most of the times since they are simple usb keypads. Some smartcard readers for PC have pin-pads but this is rarely the case and they are way more expensive than a keyboard and a regular reader. The normal way is to process transaction data through the hsm, and onto the terminal after which the user has to see/check (on the terminal) if the data is correct. This is how the better (not best) Bank-transaction-verifiers work. A secure connection to the pinpad/terminal has and can be set up (either in advance, via a pre-known mechanism or ad-hoc), but there are some attack vectors there as well.

HSMs are not "MITM proof", the system at-large has to be. Using a HSM does not give you MITM proofness, but makes it sure the old-fashioned 'steal the private key and act like nothing happened' won't happen. Stupid design choices or even simple "call them and ask for a new intermediary certificate" sometimes cause more harm. You CA Root/CSP keys are safe but you are still screwed. Unless you steal the usb drive of course. There are still other ways to do a mitm though.

The main advantage is for small and medium businesses that they won't have to buy a hugely expensive ethernet/pcie HSMs from the known companies which are hugely overpriced (I have several on my desk and they range from 1-2K to 10K+, which are the cheap ones). It also helps with some legal compliance if YubiCo can get it FIPS 140-2 approved (which I doubt).

Considering they made it small, I guess they need to provide some form of duplication/backup since people are going to lose them.

An ideal HSM serve only one purpose: store secrets (privatekeys/passwords) and give specific access (sign/spend/login).

> Most companies consider MITM an external compromise since the malicious actor is not on the machine itself or has no-longer access to the machine(s).

Securing HSM+Laptop is impossible compared to HSM. If laptop is secure, why even need HSM ?

> Even most 'dedicated' systems do NOT have a direct link to the input terminals most of the times since they are simple usb keypads. Some smartcard readers for PC have pin-pads but this is rarely the case and they are way more expensive than a keyboard and a regular reader.

If usbkeypad is not connected to a network and not attacked by evil maid, HSM+usbkeypad is still secure. But laptop is complex system, always connected to internet and has loosly regulated physical access.

> HSMs are not "MITM proof", the system at-large has to be.

Again if whole system is secure why need HSM ?

If user satisfy few conditions of using HSM, such as being rubberhose attack proof, the secrets MUST be secure irregardless of how insecure the larger system is.

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.

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

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.

Just spamming here a bit later to mention the ideal configuration may be Trezor/similar for a root CA cert, and using it to generate certs for an HSM providing production performance.

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.

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

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

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

It looks like the original YubiHSM wasn't FIPS 140-2 certified either.

https://www.yubico.com/support/knowledge-base/categories/art...

Presumably, the original YubiHSM sold well enough to justify the R&D to make the YubiHSM 2, even one that's not FIPS 140-2!

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.

Everybody who isn't working for us gov. It's a big market.

Everything in the mid to small market commercial space, basically.

I've worked on several FIPS projects, and there's not a big demand for FIPS 140-2 unless the customer is handling government contracts and/or data. It's a good checkmark to have though.

I know very little about hardware security. What are some of the issues that HSMs address that make R&D so challenging?

Regulations & compatibility.

$650 is cheap?

For a security product for enterprise data centers, this is cheap.

I'm talking about absolute price, not relative to competitors. What's so complicated about this device to justify the cost?

High development costs (security experts don't come cheap) spread over a small amount of sold devices?

It may be priced in value, rather than cost.

Why should yubi price it any cheaper? It will never compete on cost with storing your private keys insecurely.

Yup. Hsm pcie cards are around $5k, maybe more. The pizza box versions are upwards of 10k... that’s the last price I seen.

Well, certainly the number of keys you can manage is the downside here.

This HSM has limited key storage capabilities to a hundred or so security objects.

The "pizza box vendors" stores hundreds to thousands of keys.

We typically employ key wrapping to reduce HSM key storage requirements, but only in certain situations.

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.

More generally why is this not $3. Can we get a Kickstarter for this please?

It is not $3 because it provides more than $3 of value to the small audience that has a need for a HSM.

If you--not "we"--want a Kickstarter for something like this, you should go try it. It's much, much more difficult than you think, even without FIPS compliance.

An open source project, called SC-4, actually does that - although it won't offer the same level of security. https://sc4.us/hsm/

It was also featured on HN: https://news.ycombinator.com/item?id=12053181

Reply on news.ycombinator.com