4 ms·
The majority of email comes from major email providers (think Google, Microsoft, etc). They certainly own HSMs. Hence my statement that this scheme only really
by LeonM 3y ago
The majority of email comes from major email providers (think Google, Microsoft, etc). They certainly own HSMs.
Hence my statement that this scheme only really works for self-hosted solutions, because you won't be able to obtain the keys from third-party email providers.
- gsich 3y agoIf it's used for DKIM is another matter. You don't have only 1 mailserver with a HSM if you are this big. Having 1 HSM with the private key would create a massive bottleneck and SPOF. If they have a HSM for each server with the same private key, the key can obviously be extracted from the HSM, making publishing it possible.
- nmadden 3y agoThat’s not necessarily true. You can cluster and replicate HSMs to provide scalability but it is common practice to forbid extraction of private key material. In many cases you can’t change that setting without a complete reset of the device. Edit: to expand on this a bit. The clustering will involve exchanging key material in encrypted form between each HSM. But that exchange is typically protected and authenticated by keys that are themselves attested as having been created securely in hardware. You can’t just inject your own keys to mitm that connection.
- gsich 3y agoFor mailservers though? It this scaleable if you start/stop machines on demand.
- nmadden 3y agoIt can be scalable if you’re prepared to chuck enough money at it. (Response time latencies are another matter, but that is somewhat less important in email). I have no experience at all of securing production mail servers, so whether they do this or not I don’t know and other replies here suggest they don’t use HSMs at all. If they do use HSMs then it’s not crazy to assume that they can’t easily publish old private keys, but if they don’t use HSMs then that is irrelevant.
- LeonM 3y ago> the key can obviously be extracted from the HSM, making publishing it possible. As I understand it, it should be impossible to export a private key from an HSM. I'm not very familiar with HSMs though, so I might be wrong about this.
- nmadden 3y agoThe PKCS#11 standard, which is implemented by most HSMs defines two attributes that control this: - Marking a key as “sensitive” means that the raw key material cannot be exported, except in encrypted (“wrapped”) form. Such an encrypted key can then be unwrapped to install it on another HSM. This key-wrapping facility is largely to allow backup or replication (but see below). - Marking a key as “non-extractable” also means that it cannot be exported even in encrypted/wrapped form. You generally configure a policy on the HSM to say that all private keys must be sensitive etc. It is pretty common (in my experience, dealing with banks primarily) to enable a policy that enforces all private keys to be sensitive and non-extractable. Proprietary mechanisms are then used to replication and backup of those keys (that effectively ignore those attributes/work at a lower level).
- gsich 3y ago>As I understand it, it should be impossible to export a private key from an HSM. This is my understanding too. But if you have several HSMs which should all have the same key (needed for DKIM) then there needs to be some sync/export/import mechanism.
- peanut-walrus 3y agoI can with almost 100% certainty tell you that none of the major providers use HSMs for their DKIM keys.
- tbrownaw 3y agoUse how? From what I understand, they can do more different things than "private key never leaves the device" asymmetric stuff.