2 ms·

You don't want operation to stop because someone dropped something in the floor, bumped into the rack or if a minor earthquake occurred. Resin is common, but a

You don't want operation to stop because someone dropped something in the floor, bumped into the rack or if a minor earthquake occurred. Resin is common, but attackers have gone as far as decapping and done wire bonding on FIB workstations to get past tamper resistance - a solic block of epoxy is only a minor inconvenience. Most of the other things are simple to circumvent for someone already in the business of tampering with operational HSMs (pressurized work area, dark work area with particular wavelength light that doesn't trigger thubgsu, etc.), and without any direct compounding effect they end up not really being relevant outside padding a sales deck. The rotation is interesting because there so far is no practical solution. You would either need some seriously wacky robotry or find a way to externally glitch the device to not detect the change.

cryptonector 3y ago
> You don't want operation to stop because someone dropped something in the floor, bumped into the rack or if a minor earthquake occurred. Correct, that's why you need some software/firmware to integrate sensor outputs into an ignore vs. self-destruct-recoverably vs. self-destruct-unrecoverably (perhaps) decision. That's obviously a lesson from the 737MAX case. > Resin is common, but attackers have gone as far as decapping and done wire bonding on FIB workstations to get past tamper resistance - a solic block of epoxy is only a minor inconvenience. In a way that fails to trip the other sensors? Sure, if the device is powered down and its internal battery has run down, then the sensors will not help in any way, but then the devices should have gone into recovery mode where an admin and/or vendor unlock procedure is required. > Most of the other things are simple to circumvent for someone already in the business of tampering with operational HSMs (pressurized work area, dark work area with particular wavelength light that doesn't trigger thubgsu, etc.), and without any direct compounding effect they end up not really being relevant outside padding a sales deck. Yes, pressure and water sensors can be defeated, but first you need to either move the device or prepare the space where it is, and that's where the accelerometers and vibration detectors come in. Altogether the whole thing can be defeated, but there's enough to make the process slower and more likely to fail. But at least now I understand the motivation for the spinning thing. Thanks!
derefr 3y ago
> You don't want operation to stop because someone dropped something in the floor, bumped into the rack or if a minor earthquake occurred. Sounds like you just need a fault-tolerant cluster of HSMs distributed across regions/AZs. The fact that you only need one up and signing for the cluster to serve its function, would mean that any given HSM would be free to be as finicky as it wants, and thereby lock up and need to be reset+re-enrolled into the cluster as often as it wants. (I would note that Google Cloud, at least, seems to use this "cluster of HSMs" approach for Identity-Aware Proxy request-signing — there's no other reason that their JWKS endpoint would be serving 8+ distinct active keys.)

cryptonector 3y ago

> You don't want operation to stop because someone dropped something in the floor, bumped into the rack or if a minor earthquake occurred. Correct, that's why you need some software/firmware to integrate sensor outputs into an ignore vs. self-destruct-recoverably vs. self-destruct-unrecoverably (perhaps) decision. That's obviously a lesson from the 737MAX case. > Resin is common, but attackers have gone as far as decapping and done wire bonding on FIB workstations to get past tamper resistance - a solic block of epoxy is only a minor inconvenience. In a way that fails to trip the other sensors? Sure, if the device is powered down and its internal battery has run down, then the sensors will not help in any way, but then the devices should have gone into recovery mode where an admin and/or vendor unlock procedure is required. > Most of the other things are simple to circumvent for someone already in the business of tampering with operational HSMs (pressurized work area, dark work area with particular wavelength light that doesn't trigger thubgsu, etc.), and without any direct compounding effect they end up not really being relevant outside padding a sales deck. Yes, pressure and water sensors can be defeated, but first you need to either move the device or prepare the space where it is, and that's where the accelerometers and vibration detectors come in. Altogether the whole thing can be defeated, but there's enough to make the process slower and more likely to fail. But at least now I understand the motivation for the spinning thing. Thanks!

derefr 3y ago

> You don't want operation to stop because someone dropped something in the floor, bumped into the rack or if a minor earthquake occurred. Sounds like you just need a fault-tolerant cluster of HSMs distributed across regions/AZs. The fact that you only need one up and signing for the cluster to serve its function, would mean that any given HSM would be free to be as finicky as it wants, and thereby lock up and need to be reset+re-enrolled into the cluster as often as it wants. (I would note that Google Cloud, at least, seems to use this "cluster of HSMs" approach for Identity-Aware Proxy request-signing — there's no other reason that their JWKS endpoint would be serving 8+ distinct active keys.)