I'm not quite sure what happened in my brain when I read the title (probably some kind of lost in translation, translating between my mother tongue and back again), but I didn't expect a spinning device.
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.
>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?
Why aren't MEMS accelerometers enough by themselves?
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)
Encase the whole thing in a thick layer of resin, leaving only connections for:
- 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
Put this in a locked cabinet in a locked cage in a locked access-controlled room.
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.
> 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.)
> 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!
I've tried the accelerometer trick and found that it was difficult to set thresholds such that careful attack would be prevented while seismic upsets wouldn't make the device unreliable (or at least where it was easy to be confident that seismic upsets wouldn't trigger it).
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"
Right, it's not that acceleration exceeded some small threshold, but either it has exceeded a large threshold or that an integral of acceleration over the last N seconds indicates motion of more than a few centimeters. But you really want to integrate all sensors.
If there is one thing I learned working with dedicated and eventually advocating for shared hsm (kms, managed hsm, etc) it's that HSM routinely have zero days that invalidate the ability to prove the key never left.
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.
I agree that for low-level key operations (“wrap this key”, “sign that hash” etc.), there isn’t a lot of difference between trusting Thales or AWS/Google:
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.
Thanks for this - I have to admit I've never really seen an HSM doing the two operations you mention. The two cases
I have seen are bulk crypto operations for SSL offload (costly, performance critical) and key wrap/unwrap/derive (less costly, less perf impact, but keys exposed to app).
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?
Everything regarding encryption keys, certificates, passwords, etc is really only as effective as how quickly you can replace them. Sure a HSM is really secure and powerful, but if it will take you a year to replace everything it generated after a breach, it's not an effective solution IMO. Build and implement this stuff with change and iteration in mind.
Their talk was quite nice, they talk about experiences with other HSMs, their history, what lead them to design their own, the many aspects of their design and then go through potential attacks:
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.
Just crazy enough to work! I love it. One hole I can poke in the concept is to copy the IR heartbeat signal and retransmit while destroying the mesh.
>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.
Yeah. They did flag up earlier that wireless transmission between HSM and monitor would have to be encrypted. I wonder whether they missed that out in the prototype due to time issues, or whether the microcontroller they chose made it infeasible.
Just because potential attacks exist doesn't mean it isn't a solved problem in practice.
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.
It really depends on what you expect as a threat. Ask a Casino owner if they fully trust an RNG system and you will get laughed at. Randomness is not encryption and can be broken with enough knowledge of the system.
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.
When it stops turning it reliably wipes its storage if its correctly engineered. E.g. static ram with continual debiasing and a capacitor powered circuit that fills it with garbage in its dying gasp.
The idea is that tampering is turned into destruction. The attacker's goal is to get access without triggering the auto-wipe.
Suggest changing the title to "Inertial HW Security Modules Mitigate Physical Attacks" or something as "HSM" is an overloaded term(I thought it was hierarchical state machines).
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.