Live data from Hacker News

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

devever.net

61–70 of 139 posts

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

#61

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…

Don't forget broken HA features. HSMs are a great idea in theory that are ruined by incompetent companies making them. They soon become a gun your org holds to its own head with the outcome of a data loss incident or a hack because of their janky OpenSSL integrations.

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

#62

What is the problem to take a 10$ stm32f discovery board and use it as TPM. There are different flash protections: 1) you can read/write flash via JTAG 2) you can only write flash, but not read the old one 3) you can't rewrite flash, neigher can you read it. You will still have to implement USB communication, but there is already a lib from STM for it. Some models also have generous flash (in MB ranges). You can use…

Send me a locked STM32F1 chip and I'll send you back the binary contained in it. Not kidding. The problem with general purpose MCUs is that they are trivial to break.

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

#65
This is the key quote:

  The feature table also lists various supported 
  applications, demonstrating the interest of the 
  manufacturer in programming the device for specific 
  applications, rather than providing a platform for others 
  to do so. (Imagine if manufacturers of USB drives made USB 
  drives for text files and USB drives for image files and 
  USB drives for MP3 files and so on, and the idea of selling 
  a USB block device was alien to these people. If you wanted
  to store a new kind of file on a USB drive, you had to 
  convince the manufacturer to implement support for it.) The 
  draw of the Nitrokey then is the possibility the 
  manufacturer merely incidentally allows alternate firmware 
  to be flashed, rather than the manufacturer explicitly 
  capitalising on the premise of an HSM as a general-purpose 
  platform.
Great point, and completely lost on manufacturers.

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

#66
post #62

What is the problem to take a 10$ stm32f discovery board and use it as TPM. There are different flash protections: 1) you can read/write flash via JTAG 2) you can only write flash, but not read the old one 3) you can't rewrite flash, neigher can you read it. You will still have to implement USB communication, but there is already a lib from STM for it. Some models also have generous flash (in MB ranges). You can use…

Send me a locked STM32F1 chip and I'll send you back the binary contained in it. Not kidding. The problem with general purpose MCUs is that they are trivial to break.

I would be very interested in the information on how can you do this :) We already use a Cypress PSoC5LP MCU with a flash protection feature as a License Manager(Essentially a TPM with encyption keys in locked flash) because we had a surplus of those. I am just trying to estimate if it is dangerous an should be changed. Our case is to prohibit Customers (mostly industry) from pirating firmware for new devices.

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

#68
post #59
post #40

Earlier quoted context omitted.

Why do you have your HSM where Heartbleed matters?

This exactly. You use a HSM so it doesn't matter if your server gets popped.

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 totally realistic that heartbleed might cause issues for a system with HSM assisted offload (e.g. leaking plaintext) because the protocol processing happens in software. Any sane architecture should protect the actual private key though.

In general, the right way to think about HSMs is that they protect your keys, not your data. If you care more about the data than the keys, you absolutely need to care about the security of your host.

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

#69
post #50
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?

Theoretically yes, though you would have to explicitly switch the original HSM into backup mode, an operation that requires one or more admins to be present and strongly authenticated, most often with smart cards.
Post reply on HN