
Yubico announces tiny, cheap YubiHSM 2 - procrastinatus
https://www.yubico.com/2017/10/yubihsm-2-providing-root-trust-servers-computing-devices/
======
benevol
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](https://libreboot.org/faq.html#intel)

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

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

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

~~~
Cyph0n
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_s
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/](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._

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

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

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

------
confounded
What's the advantage of this over the ~$100 open source NitroKey HSM?

[https://www.nitrokey.com/files/doc/Nitrokey_HSM_English.pdf](https://www.nitrokey.com/files/doc/Nitrokey_HSM_English.pdf)

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

~~~
baby
How is 4k RSA a plus?

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

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

~~~
j_s
> Is 2048 RSA broken?

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

[https://news.ycombinator.com/item?id=14317331](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._

------
unwind
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/](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](https://www.cryptopp.com/benchmarks.html)

------
Shtirlic
I must add this post
[https://plus.google.com/+gregkroahhartman/posts/WK6ZLEhfQo5](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"

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

[https://sc4.us/hsm](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.

~~~
j_s
[edit] Disclosure?

~~~
lisper
Done. It's my product.

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

~~~
j_s
[https://news.ycombinator.com/item?id=12069784](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.)

~~~
synicalx
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?

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

------
hdhzy
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/](https://debconf17.debconf.org/talks/162/)

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

~~~
hdhzy
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](https://github.com/RaymiiOrg/gnuk/blob/master/README)

[1]: [http://www.fsij.org/gnuk/howto-make-gnuk-usb-token-by-
stm32-...](http://www.fsij.org/gnuk/howto-make-gnuk-usb-token-by-stm32-part-
of-stm8s-discovery-kit.html)

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

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

~~~
wav-part
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.

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

~~~
stedaniels
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-...](https://www.yubico.com/product/yubikey-4-series/#yubikey-4c-nano)
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?

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

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

~~~
jnwatson
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)

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

[https://en.wikipedia.org/wiki/FIPS_140-2#Security_levels](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.

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

~~~
jarman
Regulations & compatibility.

------
nikolay
$650 is cheap?

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

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

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

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

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

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

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

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

