4 ms·

Yes, if you the manufacturer want to make sure that nobody but you can alter the data. If you're providing cryptographic hardware for somebody else, they're gon

Yes, if you the manufacturer want to make sure that nobody but you can alter the data. If you're providing cryptographic hardware for somebody else, they're gonna want to set their own.

deleted 8y ago
[deleted]
gmueckl 8y ago
If you do this, you weaken your device against hostile tempering as well, don't you? The key update mechanism becomes part of the attack surface.
- excalibur 8y ago
  Yes, but if implemented in a secure manner the key update mechanism presents a smaller risk than that of a hardcoded key becoming known to an adversarial party.
lclarkmichalek 8y ago
In my experience, that's not usually a requirement. From an implementation perspective, you just say 'this certificate is the root' and trust it explicitly without needing access to the key on the HSM. From a security perspective, adding the ability to set your own key is a risk (adds RW storage to a previously immutable system, changes the model from 'no one ever sees the key' to 'no one ever sees the key as long as it was written correctly and any non hsm stored copy is deleted'), and doesn't really improve the security of the system - you trust the HSM manufacturer already, seeing as it's their hardware.
- excalibur 8y ago
  Clearly we run in different circles. In my experience keys need to be generated regularly and rotated on a predetermined schedule. Immutable systems are kind of the antithesis of that.
  - lclarkmichalek 8y ago
    You might/should rotate the leaf keys regularly, but root keys are a massive pain to rotate (when you change a root key, you need to reprovision the corresponding cert onto every machine, as they're the root of trust for your PKI). You can buy a new HSM every 3 years to rotate those root keys, which fits fairly well into most organisation's decommissioning cycles.
    - excalibur 8y ago
      Root keys are more of a pain to swap out, but AD does a pretty good job of handling the grunt work of distributing them across the organization. And the leaf keys should live on HSMs as well. You might be able to get by with a hardcoded root key if you're willing to accept the tradeoff, but that situation isn't going to work for the rest.
      - lclarkmichalek 8y ago
        AD and similar things def help, but it's still hard, especially once your deployment gets big or complicated - at the last place I worked we had tons of linux hosts + google cloud load balancers + aws load balancers + a tiny AD domain + various others. I think once you hit a certain size, it's incredibly hard to keep homogeneity. Leaf keys on HSMs is interesting. Personally, I view HSM and TPM stored keys about having an immutable identity for the device. Leaf keys are usually a bit more complicated - in the environments I work in, leaf keys are often tied to a service, not the host. The short lived nature also reduces the impact of ex-filtration. Anyway, yeah, depends on the deployment and the org.

Yes, if you the manufacturer want to make sure that nobody but you can alter the data. If you're providing cryptographic hardware for somebody else, they're gonna want to set their own.

deleted 8y ago

[deleted]

gmueckl 8y ago

If you do this, you weaken your device against hostile tempering as well, don't you? The key update mechanism becomes part of the attack surface.

excalibur 8y ago
Yes, but if implemented in a secure manner the key update mechanism presents a smaller risk than that of a hardcoded key becoming known to an adversarial party.

lclarkmichalek 8y ago

In my experience, that's not usually a requirement. From an implementation perspective, you just say 'this certificate is the root' and trust it explicitly without needing access to the key on the HSM. From a security perspective, adding the ability to set your own key is a risk (adds RW storage to a previously immutable system, changes the model from 'no one ever sees the key' to 'no one ever sees the key as long as it was written correctly and any non hsm stored copy is deleted'), and doesn't really improve the security of the system - you trust the HSM manufacturer already, seeing as it's their hardware.

excalibur 8y ago
Clearly we run in different circles. In my experience keys need to be generated regularly and rotated on a predetermined schedule. Immutable systems are kind of the antithesis of that.
- lclarkmichalek 8y ago
  You might/should rotate the leaf keys regularly, but root keys are a massive pain to rotate (when you change a root key, you need to reprovision the corresponding cert onto every machine, as they're the root of trust for your PKI). You can buy a new HSM every 3 years to rotate those root keys, which fits fairly well into most organisation's decommissioning cycles.
  - excalibur 8y ago
    Root keys are more of a pain to swap out, but AD does a pretty good job of handling the grunt work of distributing them across the organization. And the leaf keys should live on HSMs as well. You might be able to get by with a hardcoded root key if you're willing to accept the tradeoff, but that situation isn't going to work for the rest.
    - lclarkmichalek 8y ago
      AD and similar things def help, but it's still hard, especially once your deployment gets big or complicated - at the last place I worked we had tons of linux hosts + google cloud load balancers + aws load balancers + a tiny AD domain + various others. I think once you hit a certain size, it's incredibly hard to keep homogeneity. Leaf keys on HSMs is interesting. Personally, I view HSM and TPM stored keys about having an immutable identity for the device. Leaf keys are usually a bit more complicated - in the environments I work in, leaf keys are often tied to a service, not the host. The short lived nature also reduces the impact of ex-filtration. Anyway, yeah, depends on the deployment and the org.