Why I don't like smartcards, HSMs, YubiKeys, etc.

Post by tluyben2 » Sat, Nov 26, 2016, 8:27 AM UTC

pharaohgeek wrote: post #122

sofaofthedamned wrote: post #34

HSMs are shit. In a previous role we used a major vendor's HSM to protect our private keys. VERY expensive kit, more expensive than the load balancers and servers combined. We needed to use Elliptic Curve keys for a particular customer - so it got even more expensive as we had to buy: 1. A license from the LB vendor to use the HSM 2. A licence from the HSM vendor to use EC with the LB. ... even though they trumpeted…

They're not (necessarily) shit. They're just appropriate for a VERY specific purpose. A lot of companies that use them aren't using them right, or are using them in a scenario in which they are overkill. My company (medium-sized financial firm) uses them to protect the keys for our internal PKI. For these types of high-security situations, an HSM is ideal (if configured and managed properly). But I've seen places tha…

Post by pisipisipisi » Sat, Nov 26, 2016, 8:53 AM UTC

closeparen wrote: post #115

pisipisipisi wrote: post #112

Earlier quoted context omitted.

this "one guy" here. I would say that the availability of open access cards is almost excellent these days, at least in EU. The quality of those easily available cards (chinese) is questionable though. But there are cards available from other vendors as well (most notably NXP)

Haha I love HN. EU might be the differentiator. I do remember seeing a lot of cards that would only ship to EU, or shipping to US was prohibitively expensive. Keep up the awesome work.

Post by matthiasb » Sat, Nov 26, 2016, 2:38 PM UTC

amluto wrote: post #50

pzb wrote: post #35

Earlier quoted context omitted.

Both Smart Cards and HSMs can (and frequently do) contain FIPS validated cryptographic modules and can be USB devices. What seems to set them apart is content capacity and speed. A "HSM" can usually store dozens, hundreds, or even tens of thousands of keys and can do numerous cryptographic operations per second. Most "smart cards" can only store a few keys and frequently 1-2 operations per second. Many HSMs also add…

> The other key feature usually found in HSMs but not smart cards is backup/cloning without exporting the key (in PKCS#11 terms). This means that the key can be moved between HSMs with all the protections in place. I've yet to see a smart card that does this. How does this work? Can an attacker buy an identical HSM, back up the key, and restore it onto the new HSM?

Post by xyzzy123 » Sun, Nov 27, 2016, 9:16 AM UTC

mentat wrote: post #124

xyzzy123 wrote: post #68

Earlier quoted context omitted.

I think one should be really careful making statements like this. In the case where an HSM is used for e.g. database encryption, one absolutely still cares. The attacker can politely ask the HSM to decrypt all the data. On the bright side, you didn't lose the key, and your HSM should at least securely log the fact that all your data just walked out the door. For SSL offload the situation is less dire, but it is total…

As far as I understand heartbleed, the core issue was that you could search memory for the private key and then do whatever you wanted with it. With an HSM, that wouldn't be an issue. However, it's true that you could search for other data as well and that data could be sensitive, just not quite as sensitive (depending on your industry and architecture, of course).

Post by mentat » Mon, Nov 28, 2016, 6:18 PM UTC

xyzzy123 wrote: post #137

mentat wrote: post #124

Earlier quoted context omitted.

As far as I understand heartbleed, the core issue was that you could search memory for the private key and then do whatever you wanted with it. With an HSM, that wouldn't be an issue. However, it's true that you could search for other data as well and that data could be sensitive, just not quite as sensitive (depending on your industry and architecture, of course).

I agree with you -- it depends on your threat model. If state actors or universal mitm or coffee shop attacks are primary threats then loss of private key is a very bad outcome for SSL offload. And this is what SSL is meant to help woth. For many (more?) sites though, the issue was loss of session plaintext (e.g api creds, basic auth creds, pii or credit cards). For a lot of applications where just hitting the webser…