Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Passive SSH Key Compromise via Lattices [pdf]

eprint.iacr.org

Post reply on HN
Print view View original

11–20 of 57 posts

Re: Passive SSH Key Compromise via Lattices [pdf]

#11

Post by temac »

clbrmbr wrote: post #5
blueflow wrote: post #3

Earlier quoted context omitted.

Random hardware bit flips can cause invalid RSA signatures, which baddies can use to deduce private keys. Edit: Don't ask me questions, i don't know shit, i just rephrased stuff from the linked paper.

How frequently do such faults occur?

Virtually never in practice (they are corrected) if you use ECC. A server that doesn't is weird. TBH any computer that doesn't is weird but the industry seems to consider it normal to have random computational unreliability because of that pretty much only unprotected component (Ram without ECC) in consumer hw.

Re: Passive SSH Key Compromise via Lattices [pdf]

#12

Post by yard2010 »

blueflow wrote: post #3
fergie wrote: post #2

Can anybody ELI5?

Random hardware bit flips can cause invalid RSA signatures, which baddies can use to deduce private keys. Edit: Don't ask me questions, i don't know shit, i just rephrased stuff from the linked paper.

What are the methods used by these baddies?

Re: Passive SSH Key Compromise via Lattices [pdf]

#13

Post by pera »

> We also carry out a retrospective analysis of historical SSH scan data collected over the course of seven years, and find that these invalid signatures and vulnerable devices are surprisingly common over time.

> Our combined dataset of around 5.2 billion SSH records contained more than 590,000 invalid RSA signatures.

Am I reading this right? This is about 1 in 10_000, this is way more common that what I would have imagined

Re: Passive SSH Key Compromise via Lattices [pdf]

#14

Post by SAI_Peregrinus »

mackman wrote: post #9
blueflow wrote: post #3

Earlier quoted context omitted.

Random hardware bit flips can cause invalid RSA signatures, which baddies can use to deduce private keys. Edit: Don't ask me questions, i don't know shit, i just rephrased stuff from the linked paper.

Does each bit flip reveal a bit or less or does somehow a single flip compromise the entire key?

A single bit flip reveals the entire private key, for RSA with PKCS#1v1.5. RSA with PKCS#1v2 (aka RSA-PSS) is not vulnerable.

Re: Passive SSH Key Compromise via Lattices [pdf]

#15

Post by hannob »

To give some easier explanation: This is an attack against faulty RSA implementations. There is a common optimization in RSA signature implementations that splits up an expensive mathematical operation into two smaller operations. If one of these throws out a bad result then you can break the key.

Why does this happen? Multiple reasons. Implementations of big number math can and does contain bugs. (I used to hunt for those via fuzzing, which turned up an amazing number of them.) Hardware failures. Other bugs that corrupt numbers in memory.

The basic attack is well known. Florian Weimer has demonstrated this against TLS in the wild: https://www.redhat.com/en/blog/factoring-rsa-keys-tls-perfec...

The new thing this paper adds is applying this attack to SSH.

There is a countermeasure against this attack, and this is to verify the signature before revealing it. It works. As the paper says, openssh uses openssl's RSA implementation, and it has been doing that since forever (2001).

So in summary: Applying a well-known attack against RSA to its use in SSH. Only works if you have an RSA implementation that outputs results of flawed computations. Countermeasures exist, and RSA implementations should use them.

Re: Passive SSH Key Compromise via Lattices [pdf]

#16

Post by hannob »

pera wrote: post #13

> We also carry out a retrospective analysis of historical SSH scan data collected over the course of seven years, and find that these invalid signatures and vulnerable devices are surprisingly common over time. > Our combined dataset of around 5.2 billion SSH records contained more than 590,000 invalid RSA signatures. Am I reading this right? This is about 1 in 10_000, this is way more common that what I would have…

It is a lot, but it's explainable.

Such bugs tend to show up in crappy IoT hardware. IoT hardware often comes in large numbers.

If you scan the IPv4 space for SSH hosts, most of the ones you'll find are IoT hardware.

Re: Passive SSH Key Compromise via Lattices [pdf]

#18

Post by tux3 »

I wonder if I can use this against Intel SGX/AMD SEV-SNP :)

These are hardware features where a private key is hardcoded in the chip and never supposed to be revealed. You can ask the chip to sign things for you. It has some anti-tampering measures, but it might be possible to induce faults without too much effort, if you apply heat, EM ("cosmic rays"), and play with voltage/frequency a little

Re: Passive SSH Key Compromise via Lattices [pdf]

#19

Post by hannob »

tux3 wrote: post #18

I wonder if I can use this against Intel SGX/AMD SEV-SNP :) These are hardware features where a private key is hardcoded in the chip and never supposed to be revealed. You can ask the chip to sign things for you. It has some anti-tampering measures, but it might be possible to induce faults without too much effort, if you apply heat, EM ("cosmic rays"), and play with voltage/frequency a little

Well, yeah, you can: https://www.plundervolt.com/doc/plundervolt.pdf Paper is from 2019.

Re: Passive SSH Key Compromise via Lattices [pdf]

#20

Post by gosub100 »

javajosh wrote: post #6
fergie wrote: post #2

Can anybody ELI5?

How about ELI precocious 10 year old? Cosmic rays and thermal effects cause random bit flips in memory very infrequently. If you sit on a network and listen to TLS handshakes for long enough, you'll find that any given server will issue the wrong signature occasionally, because of these bit flips. If you record the wrong signature(s) and use a fancy algorithm, you can recover the private key. While at first it may se…

> Cosmic rays and thermal effects

now put your tinfoil hat on and suppose you worked for a paramilitary organization that had infiltrated the top 2 semiconductor manufacturers. You persuade the silicon designers, when implementing hardware accelerated crypto (or "management engines") to not do their jobs quite perfectly, no just leave room for a tiny bit of....error. Could never happen, right?

Post reply on HN