[HN Gopher] Inertial HSMs thwart advanced physical attacks
___________________________________________________________________
Inertial HSMs thwart advanced physical attacks
Author : luu
Score : 60 points
Date : 2023-08-29 23:00 UTC (1 days ago)
(HTM) web link (tches.iacr.org)
(TXT) w3m dump (tches.iacr.org)
| cryptonector wrote:
| 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.
| arghwhat wrote:
| 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 wrote:
| > 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!
| p1mrx wrote:
| with a sign on the door saying "Beware of the Leopard"
| saagarjha wrote:
| I'll try spinning-that's a good trick!
|
| 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.
| KirillPanov wrote:
| The paper spends several pages discussing this.
|
| 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.
| [deleted]
| lisper wrote:
| Minor nit: the mesh is in a non-inertial (rotating) frame.
| _dain_ wrote:
| _> 4.3 The Swivel Chair Attack_
|
| _> 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?
| beardedwizard wrote:
| 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.
| lxgr wrote:
| 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.
| lallysingh wrote:
| This looks like it was published just to be the MacGuffin in a
| movie later.
| [deleted]
| marshray wrote:
| My thoughts exactly!
|
| Like the inertially-secure module would be an AI and occupy the
| top several floors of a tall building.
| jareklupinski wrote:
| "If we spin the IHSM in the opposite direction using negative
| mass, the encryption will be weakened enough to make the attack
| feasible!"
| Arrath wrote:
| -Quote from Lt. Cmdr LaForge as engineering shakes and
| control panels explode in showers of sparks in the background
| mplewis9z wrote:
| That's Commodore LaForge to you now!
| 1970-01-01 wrote:
| 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.
| 01100011 wrote:
| 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).
| Retr0id wrote:
| Are hierarchical state machines ever subjected to advanced
| physical attacks?
| saagarjha wrote:
| Yes, I typically run them through a shredder whenever I
| encounter them.
| aetherspawn wrote:
| I use these in my job so I lol'd.
| 01100011 wrote:
| One could employ a hierarchical state machine to detect and
| respond to an attack.
| shiftingleft wrote:
| 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:
|
| https://youtu.be/zD5EdvGs98U?t=13m23s
| notpushkin wrote:
| [pdf]
___________________________________________________________________
(page generated 2023-08-30 23:00 UTC)