Inertial HSMs thwart advanced physical attacks
tches.iacr.org
tches.iacr.org
But when I saw the first picture I immediately understood were this is going. Actually it's quite clever - as is the subliminal self-irony of the authors. The Swivel Chair Attack made me laugh harder than it should (someone here in the comments already rightfully called for an ig nobel price for that). And still this idea might be a unconventional but working solution.
It's kind of a refreshing read.
>If we assume whoever integrates the payload into an IHSM has done adequate work and prevented all contactless attacks, we are left with attacks that aim at mechanically bypassing the IHSM’s security mesh. The first type of attack we will consider is the most basic of all attacks: a human attacker holding a soldering iron trying to rotate herself along with the mesh using a very fast swivel chair.
this is amazing. is there an ig nobel for computer science?
Aim and fire a gun at just the right moment in space and time so as to destroy the circuit onboard that is in charge of data deletion.
would be wild to see that project.
Well, one should build an HSM to have multiple tamper detection sensors:
- accelerometers
- light sensors (the HSM should
be sealed in an opaque box)
- vibration sensors
- temperature sensors
- air pressure sensors (the HSM
should be sealed in a
pressurized airtight box)
- moisture sensors (the HSM
could be an air- and watertight
box inside a water-tight box
full of water)
- water (for cooling)
- optical ethernet (to avoid
electrical attacks on wire
ethernet)
- an inductive coupling plate
to power everything but the
water pump
- power for the water pump
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.
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!
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.)
If it fails often that itself becomes an attack vector. "Oh? it failed again... happens once a month when they move the piano next door. just reset it"
I'm curious what folks feel like they are really getting when they buy a physical hsm in 2023?
Do we really believe HSM vendors have a greater incentive to patch vulnerabilities than cloud providers who build services on top of them?
I 100% trust google more than Thales to keep things patched, and provide the most trustworthy logs.
If you just use them as glorified key derivation/unwrapping functions and expose the resulting keying material to your application servers, you don’t gain much from using either a hardware or cloud HSM (since your trusted domain includes your cloud-hosted application servers anyway).
But for high-level operations, e.g. “validate whether the CVC of card 1234 really is 987” or “generate a signed command to top up this stored-value smartcard by $5” (or the equivalent in your domain), I’m not aware of any alternative that is as secure as a physically managed HSM. And arguably, that’s where HSMs make most sense.
I guess the cases you mentioned are similar to bulk crypto in the sense you just get the answer back, rather than the ability to compute it yourself?
Curious what the model is for an attacker who creates tools that rotate at the same speed as the HSM dynamo, and then controls it remotely in a seemingly stationary reference frame.
Note: the security barrier (the cylindrical mesh) rotates; the HSM inside the cylinder does not. So you must not just get your robot past the mesh, you must in fact modify the mesh (which is in motion) so that it thinks it is still moving, and then halt the motion of the mesh.
Until you do this, the mesh and the payload are in different (edit: possibly-non-)intertial reference frames.
>Besides power transfer from stator to rotor, we need a reliable, bidirectional data link to transmit mesh status and a low-latency heartbeat signal. We chose to transport an 115 kBd UART signal through a simple IR link for a quick and robust solution. The link’s transmitter directly drives a standard narrow viewing angle IR led.
https://en.wikipedia.org/wiki/Random_number_generator_attack...
There are plenty of well-research PRNG algorithms out there, some of which are used in very high-profile applications like TLS and have been exposed to hostile parties for over a decade. If you are building an HSM you are almost guaranteed to already have a battle-hardened implementation of one lying around.
Like others, I didn't expect it to be a computer in a washing machine. A lot of the talk felt surreal due to its "that's insane ... but you have a point" kind of vibe.
The idea is that tampering is turned into destruction. The attacker's goal is to get access without triggering the auto-wipe.
anyway, give it 2 axles or you would be able to rotate a pcb into it
Like the inertially-secure module would be an AI and occupy the top several floors of a tall building.