4 ms·

Everybody Be Cool, This Is a Robbery

64 points by hsnewman 7y ago

kbenson 7y ago
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
neatmonster 7y ago
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/SSTIC2019-Article-hsm-campana_bedrune_neNSDyL.pdf https://www.sstic.org/media/SSTIC2019/SSTIC-actes/hsm/SSTIC2... Video: https://static.sstic.org/videos2019/1080p/SSTIC_2019-06-05_P07.mp4 https://static.sstic.org/videos2019/1080p/SSTIC_2019-06-05_P...
- godelski 7y ago
  For those that don't speak French is there a translation or a good summary?
  - MrXOR 7y ago
    https://cryptosense.com/blog/how-ledger-hacked-an-hsm/ https://cryptosense.com/blog/how-ledger-hacked-an-hsm/
  - nickpsecurity 7y ago
    You can always run them through Google Translate. Some get good results. Here's what it gave me for that pdf: https://translate.googleusercontent.com/translate_c?depth=1&nv=1&rurl=translate.google.com&sl=auto&sp=nmt4&tl=en&u=https://www.sstic.org/media/SSTIC2019/SSTIC-actes/hsm/SSTIC2019-Article-hsm-campana_bedrune_neNSDyL.pdf&xid=17259,15700023,15700186,15700190,15700256,15700259&usg=ALkJrhhXMALamw78vDWalYtHFXbOVA1DgA https://translate.googleusercontent.com/translate_c?depth=1&...
jedberg 7y ago
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.
- ebg13 7y ago
  > I'm curious how this got so high on HN with so little actual content. I think we both know the answer is that people don't read before voting. Instead they say "Blackhat is cool, and I want to be cool too."
cferr 7y ago
Leave it to Blackhat to implement a site which won't let you go back a page.
- jakeogh 7y ago
  Or read it with executing an arbitrary program.
Sohcahtoa82 7y ago
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
- rdl 7y ago
  Their main purpose is resistance to insider threats in an environment with lots of other controls. Otherwise, it's really really hard to trust that a sysadmin hasn't copied a key (voluntarily or while compelled).
- sdenton4 7y ago
  True! But reducing the scope of the device to just a few crypto primitives should allow much tighter control over the attack surface, at least...
- wahern 7y ago
  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/xilinx11/pim_c_introduction_efuse.htm https://www.xilinx.com/support/documentation/sw_manuals/xili... "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 7y ago
Here is a way to translate the paper: 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 https://translate.google.com/translate?hl=&sl=auto&tl=en&u=h...
password4321 7y ago
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

64 points by hsnewman 7y ago

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

neatmonster 7y ago

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/SSTIC2019-Article-hsm-campana_bedrune_neNSDyL.pdf https://www.sstic.org/media/SSTIC2019/SSTIC-actes/hsm/SSTIC2... Video: https://static.sstic.org/videos2019/1080p/SSTIC_2019-06-05_P07.mp4 https://static.sstic.org/videos2019/1080p/SSTIC_2019-06-05_P...

godelski 7y ago
For those that don't speak French is there a translation or a good summary?
- MrXOR 7y ago
  https://cryptosense.com/blog/how-ledger-hacked-an-hsm/ https://cryptosense.com/blog/how-ledger-hacked-an-hsm/
- nickpsecurity 7y ago
  You can always run them through Google Translate. Some get good results. Here's what it gave me for that pdf: https://translate.googleusercontent.com/translate_c?depth=1&nv=1&rurl=translate.google.com&sl=auto&sp=nmt4&tl=en&u=https://www.sstic.org/media/SSTIC2019/SSTIC-actes/hsm/SSTIC2019-Article-hsm-campana_bedrune_neNSDyL.pdf&xid=17259,15700023,15700186,15700190,15700256,15700259&usg=ALkJrhhXMALamw78vDWalYtHFXbOVA1DgA https://translate.googleusercontent.com/translate_c?depth=1&...

jedberg 7y ago

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.

ebg13 7y ago
> I'm curious how this got so high on HN with so little actual content. I think we both know the answer is that people don't read before voting. Instead they say "Blackhat is cool, and I want to be cool too."

cferr 7y ago

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

jakeogh 7y ago
Or read it with executing an arbitrary program.

Sohcahtoa82 7y ago

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

rdl 7y ago
Their main purpose is resistance to insider threats in an environment with lots of other controls. Otherwise, it's really really hard to trust that a sysadmin hasn't copied a key (voluntarily or while compelled).
sdenton4 7y ago
True! But reducing the scope of the device to just a few crypto primitives should allow much tighter control over the attack surface, at least...
wahern 7y ago
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/xilinx11/pim_c_introduction_efuse.htm https://www.xilinx.com/support/documentation/sw_manuals/xili... "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 7y ago

Here is a way to translate the paper: 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 https://translate.google.com/translate?hl=&sl=auto&tl=en&u=h...

password4321 7y ago

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