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?
> 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.
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:
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.
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.
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.
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.
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”.
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.
> 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.
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.
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.
>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.
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.
>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.
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].
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).
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):
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.
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)
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.
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 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.
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.
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