
Everybody Be Cool, This Is a Robbery - hsnewman
https://www.blackhat.com/us-19/briefings/schedule/?hootPostID=db681a52c6a321681e1f9281b5124457#everybody-be-cool-this-is-a-robbery-16233
======
neatmonster
If you speak French, the authors already gave the presentation at SSTIC 2019.

Their material is online.

Paper: [https://www.sstic.org/media/SSTIC2019/SSTIC-
actes/hsm/SSTIC2...](https://www.sstic.org/media/SSTIC2019/SSTIC-
actes/hsm/SSTIC2019-Article-hsm-campana_bedrune_neNSDyL.pdf)

Video:
[https://static.sstic.org/videos2019/1080p/SSTIC_2019-06-05_P...](https://static.sstic.org/videos2019/1080p/SSTIC_2019-06-05_P07.mp4)

~~~
godelski
For those that don't speak French is there a translation or a good summary?

~~~
MrXOR
[https://cryptosense.com/blog/how-ledger-hacked-an-
hsm/](https://cryptosense.com/blog/how-ledger-hacked-an-hsm/)

------
kbenson
While somewhat interesting, I'm not sure there's much to discuss unless the
presentation or details are already available.

Interestingly, this reminds me of two Defcon talks I watched in the last day
or two, which also cover vulnerability through additional processors
onboard.[1][2]

1:
[https://www.youtube.com/watch?v=jmTwlEh8L7g](https://www.youtube.com/watch?v=jmTwlEh8L7g)

2:
[https://www.youtube.com/watch?v=XH0F9r0siTI](https://www.youtube.com/watch?v=XH0F9r0siTI)

------
jedberg
Is this just a link to talk description for a talk that hasn't happened yet?

I'm curious how this got so high on HN with so little actual content.

------
Sohcahtoa82
I've always been skeptical about HSMs. They're treated as some sort of magic
bullet to solve the problem of storing private keys and the like, but they run
software written by humans just like anything else and are still subject to
bugs that create vulnerabilities.

EDIT: grammar

~~~
wahern
It depends on the HSM. In principle they can use specialized ICs that prevent
direct access to the secret. This is how many so-called "secure elements" work
--the hardware provides specialized operations, for both symmetric and
asymmetric keys, like "generate", "sign", or "encrypt" that access the secret
key. Software, on- or off-chip, simply can't read the key. See, e.g.,
[https://www.microchip.com/wwwproducts/en/ATsha204a](https://www.microchip.com/wwwproducts/en/ATsha204a)

Further up the stack, ARM and some other embedded chips commonly have
dedicated AES instructions that operate on a 128-bit or 256-bit non-volatile
register that cannot be directly read. They include a generate instruction
that sets a write-once register[1] to a random value--hopefully using a
hardware RNG. This effectively creates a unique key that cannot be cloned but
can be used by software to be build more complex primitives (hardware
attestation, exporting secret keys off the device, etc). See, e.g.
[https://www.xilinx.com/support/documentation/sw_manuals/xili...](https://www.xilinx.com/support/documentation/sw_manuals/xilinx11/pim_c_introduction_efuse.htm)

"Web scale" HSMs don't usually implement the strongest method discussed above.
You need to be able to export ("wrap") and load ("unwrap") an arbitrary number
of keys, perform a high rate of operations, and handle significant throughput.
They may use something like the non-cloneable AES key for wrapping and
unwrapping, but for whatever reason (hardware cost, development time,
laziness, ineptitude, lack of demand) everything else is usually controlled by
software, with the unwrapped secret keys visible to the software. Sometimes
this software runs on a separate chip or within a different privilege domain
(e.g. TrustZone); sometimes not, as I presume is the case with the hacked
Gemalto HSM device. But in any event it's a distinction without a difference--
it's a pile of buggy software when not even a single line of potentially buggy
software should be able to read the keys. In principle they could use formal
verification techniques, but apparently not many do. They don't even seem to
make use of projects like seL4, which would get them 80% of the way there.[2]

Anyhow, it _can_ be done properly. And some HSMs may do it properly. It's hard
to tell because the industry is so opaque. You're right to be skeptical, just
don't assume nobody is doing it properly, though it's probably true very few
are.

[1] These registers are often implemented as so-called
eFuses--[https://en.wikipedia.org/wiki/IBM_eFUSE](https://en.wikipedia.org/wiki/IBM_eFUSE)

[2] Hardware can have bugs, too. The best way to approach the problem is
probably to find the right mix of hardware and software that permits you to
formally verify most if not all the critical components and semantics. Again,
seL4 is an obvious choice here as a core architectural component; it's
outright negligent seL4 or something with similar guarantees isn't more
commonly used.

------
hsnewman
Here is a way to translate the paper:
[https://translate.google.com/translate?hl=&sl=auto&tl=en&u=h...](https://translate.google.com/translate?hl=&sl=auto&tl=en&u=https%3A%2F%2Fwww.sstic.org%2Fmedia%2FSSTIC2019%2FSSTIC-
actes%2Fhsm%2FSSTIC2019-Article-hsm-campana_bedrune_neNSDyL.pdf&sandbox=1)

------
password4321
related anecdata:
[https://news.ycombinator.com/item?id=12069784](https://news.ycombinator.com/item?id=12069784)

 _with undocumented commands, export the key from the device in an unencrypted
format and loaded it into the other model_

------
cferr
Leave it to Blackhat to implement a site which won't let you go back a page.

~~~
jakeogh
Or read it with executing an arbitrary program.

