Hacker News Reader

Comment by _almosnow | Hacker News Reader

Mmm, how is it less secure to add another "employee" to the equation?

The court order is the bar, not the second employee.

Google's keyservers also don't have single employee control. The ones used for encrypting gmail behind the scenes, and other Google services. This is just table stakes for any large system.

This is in contrast to something like Azure Key Vault, which is HSM backed. A court order should not be sufficient to compel Microsoft to turn over a key from Azure Key Vault; it should be impossible for them (or for nCipher) to do so.

Can you explain the difference between HSM and HSA, or at least point to a good resource for understanding the difference? Thanks.

HSMs are tamper-resistant/tamper-responding devices with memory/processor inside the protected envelope. With an HSM, your key lives inside, and all operations happen on the security processor.

HSA is an Amazon term for a PC with an HSM inside. The data-at-rest might be protected by the HSM (full disk crypto with a dongle used to decrypt at boot), but the actual keys get decrypted into the host PC's RAM, and further customer-accessible calculations happen in the PC CPU.

Anyone who can tamper with the PC can read the keys!

There are two risks this exposes you to:

1) Someone goes into the datacenter and physically attacks the HSA.

2) Someone legally compels the owner of the HSA to subvert the HSA.

I'm not as worried about #1 (these are equinix tier-4 datacenters; someone rolling in with some M4s and a bulldozer and such is great for Hollywood. Insider threat probably still exists with the HSA even though normal operation is two-employee, though.) I'm incredibly worried about #2, since the bar for #2 is hella low for emails older than 6mo.

I believe ECPA older-than-6mo would be sufficient to compel the email KMS key as mere instrumentality, so even a the fairly low bar today of warrant wouldn't be required.

There's a third risk here.

3) Exploit programmatic access or side-channel attacks on the data.

If the server can decrypt the data and this is driven by code on the box, then you're in a DRM-like situation trying to hide data from a program that has legitimate access.

As you alluded to earlier protecting data at rest doesn't protecting during use.

It isn't impossible to unwrap a key from an nCipher system. Getting out the master HSM key is harder but still possible. Really the important part if the steps required to get it out to prove authorization, aka a quorum on the security world. The quorum size is an implementation/configuration detail and only MS would know that on hand to speak to that depth.

If it can be done through policy they can be ordered to do it, but they don't have to physically subvert their hardware. (not a lawyer, but this is an opinion a lot of people have had...)

It depends on how you configure the HSMs whether you can extract and decrypt keys.

Unless Microsoft manages the HSM for you, of course (which is the option most companies will probably choose).

>it should be impossible for them (or for nCipher) to do so.

Why does it matter? They can certainly be compelled to use the HSM to decrypt data, even if they can't extract keys.

This.

If you aren't doing client-side encryption and keeping the keys private, the server has access one way or another.

It's not less secure, it's just not really more secure. If you're hiding from a government, you're screwed either way.

Well, it prevents a single rogue employee from peeking at/stealing data. It now requires a conspiracy between employees.

And it is way better than just leaving keys in VMs.

From a practical perspective, yes. From a threat model perspective not really.

It protects from a bunch of lesser threats, like backups leaking keys, anyone hacking a front end box getting keys, needing to rotate keys when employees change, etc.

Reply on news.ycombinator.com