7 ms·

Passive SSH Key Compromise via Lattices [pdf]

98 points by Animux 3y ago

fergie 3y ago
Can anybody ELI5?
- blueflow 3y ago
  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.
  - yard2010 3y ago
    What are the methods used by these baddies?
  - clbrmbr 3y ago
    How frequently do such faults occur?
    - temac 3y ago
      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.
    - sebstefan 3y ago
      > 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. Seems like over long periods, it can occur a spoopy amount of time.
  - mackman 3y ago
    Does each bit flip reveal a bit or less or does somehow a single flip compromise the entire key?
    - SAI_Peregrinus 3y ago
      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.
    - sebstefan 3y ago
      It's akin to me having the secret number 17, giving you 221 (17*13) and then, during a solar flare, fucking it up once and giving you 187 (17*11). You know that the numbers are the product of a multiplication, and you know that a common factor is my private secret number. You figure out that the only way to get to 187 and 221 while keeping a common factor is if that factor is 17. That's just computing the GCD. >An RSA public key consists of a public exponent 𝑒 and a modulus 𝑁 = 𝑝𝑞 that is the product of two primes. The private key consists of the private exponent 𝑑 = 𝑒 −1 mod 𝜙 (𝑁) and 𝑁 . A textbook RSA signature on a message 𝑚 is the value 𝑠 = 𝑚𝑑 mod 𝑁 . To verify the signature, a user checks if 𝑠𝑒 mod 𝑁 = 𝑚 > these attacks exploit the fact that if an error is made while computing modulo one prime, say 𝑞, then the resulting invalid signature ˆ𝑠 is equivalent to the correct signature modulo one prime factor 𝑝, but not 𝑞. 2.2.1 GCD attack on fully known messages. Boneh, DeMillo, and Lipton noted [11] that if an attacker had a correct signature 𝑠 and an incorrect signature ˆ𝑠 of this form then the attacker could compute gcd(𝑁, ˆ𝑠 − 𝑠) = 𝑝
      - gonzo 3y ago
        you have to flip two bits to get from 13 (1101) to 11 (1011).
- javajosh 3y ago
  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 seem an unlikely attack, it's probably more real than you'd think, given the number of times any single server does TLS negotiation using a given private key. The attack becomes even more likely when you realize that multiple servers will be using the private key. In practice, this gives middle boxes more power, and raises their profile in the threat model significantly. This also opens up the possibility of simply collecting failed transient failed tls negotation data from a large number of (legitimate) clients to reconstruct a private key.
  - gosub100 3y ago
    > 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?
magicalhippo 3y ago
RSA digital signatures can reveal a signer’s secret key if a computational or hardware fault occurs during signing with an unprotected implementation using the Chinese Remainder Theorem and a deterministic padding scheme like PKCS#1 v1.5. [...] In this context, a passive adversary can quietly monitor legitimate connections without risking detection until they observe a faulty signature that exposes the private key. The attacker can then actively and undetectably impersonate the compromised host to intercept sensitive data. And they say crypto is hard, sheesh... Seriously though, almost every time I hear about some new (to me) attack, I get amazed at the ingenuity of people.
- nonrandomstring 3y ago
  > using the Chinese Remainder Theorem Damn those Chinese hackers again!
  - wuiheerfoj 3y ago
    Those Chinese hackers from the 3rd century AD no less ;)
- GTP 3y ago
  Crypto is hard, and part of the hardness is implementing it correctly.
  - timschmidt 3y ago
    I think GP's point is that one vulnerable hardware or software implementation in the entire network of implementations being passively observed by the attacker can reveal the private keys. So it's not just your implementations which must be perfect, but all your neighbors, and all theirs too.
    - magicalhippo 3y ago
      I read it as "only" the signing machine needs faulty hardware. Still, bit errors occur, even with ECC, and this allows for a passive hence very unobtrusive attack.
fguerraz 3y ago
So the vast majority of servers is not at risk because OpenSSH is not vulnerable to these attacks?
- tptacek 3y ago
  Correct. You are almost certainly not at risk. OpenSSL isn't vulnerable to this attack; your stack needs to be seriously archaic to have a vulnerable RSA implementation.
  - slt2021 3y ago
    Industrial IoT: hold my beer
  - fweimer 3y ago
    Some OpenSSL deployments use RSA plugins that do not contain the check—it's not in generic OpenSSL or OpenSSH code, so every engine plugin needs to implement its own check.
    - tptacek 3y ago
      Which plugins are you aware of that are used for RSA signatures and don't check signature validity? Just curious, from your comment it seemed like there might be specific ones.
pera 3y ago
> 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
- hannob 3y ago
  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.
  - hedora 3y ago
    In particular, all the hosts they recovered keys for seem to be some sort of embedded thing, and over 99.9% were from one vendor.
hannob 3y ago
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-perfect-forward-secrecy 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.
- supriyo-biswas 3y ago
  FWIW, RSA is well known to be difficult to get right because you have to select the primes very carefully, and must take explicit steps to avoid padding oracle attacks[1], and perhaps it's better to avoid it entirely. [1] https://blog.trailofbits.com/2019/07/08/fuck-rsa/ https://blog.trailofbits.com/2019/07/08/fuck-rsa/
  - tptacek 3y ago
    This attack works regardless of how well you've selected your primes and relies on valid padding.
  - upofadown 3y ago
    Well, sure, but the alternatives are more complex and harder to get right. You can literally just pick two random numbers of the right magnitude, find the closest primes, and be good for RSA. My comments on "Seriously, stop using RSA": * https://articles.59.ca/doku.php?id=pgpfan:rsabad https://articles.59.ca/doku.php?id=pgpfan:rsabad
lindseyconcerns 3y ago
[dead]
tux3 3y ago
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
- hannob 3y ago
  Well, yeah, you can: https://www.plundervolt.com/doc/plundervolt.pdf https://www.plundervolt.com/doc/plundervolt.pdf Paper is from 2019.
  - tux3 3y ago
    I remember they fixed that one, but plundervolt is more finely targeted, like a traditional glitch attack. The fun thing with this attack is we just need a little bit of corruptions everywhere, and some broken signatures might make it through! DVFS aside, there's plenty of ways to stress and CPU and cause random errors. I don't know whether their RSA implementation protects against this attack, though.
  - hedora 3y ago
    It also works against the analogous technology for ARM (2017): https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/tang https://www.usenix.org/conference/usenixsecurity17/technical... The researchers made an app that can run as a normal user and extract the hardware enclave’s private key.
kragen 3y ago
i read the title and thought 'that sounds like nadia heninger' i wasn't wrong
tptacek 3y ago
Headlines: * In (rare) vulnerable targets, this allows you to recover the host's key, and thus impersonate a host. You can't compromise client credentials with this attack, since client credentials are exchanged after the (active) secure channel is established. If you can impersonate a host, as this attack would allow you to do, you could capture client password credentials, and you can drive a forwarded agent. * OpenSSH --- really, SSH servers on any Unix host you've been using in the last 20 years --- isn't vulnerable to this attack. The vulnerability is publishing a signature that is validly signed under RSA p and not under RSA q. Solution: just never do that; when you generate the signature, check it yourself before publishing. This is one of the better-known attacks on RSA, so this is a standard implementation countermeasure. * The things that are vulnerable are crappy middleboxes from Zyxel, Mocana, apparently a rare subset of Cisco devices, and whatever "SSH-2.0-SSHD" is (the authors don't know either). * This is a Nadia Heninger paper, and Heninger is, like, the modern master of the Coppersmith RSA attack, which transforms an RSA problem into a series of polynomials and then transforms those into a linear algebra problem set in a lattice (roughly: a vector space with exclusively integer components; really, when we say "lattice" we mean "some generated basis for that lattice"). You then use the LLL algorithm to reduce the basis, which gives you small vectors that, when reframed back into polynomials or whatever, can tractably solved for their roots. Get the intuition? Yeah, I mean, me neither. Lattice attacks on PQ crypto have a simpler intuition! But the lattices bases here are just R^3 matrices, so, that's pretty simple. * You can get the intuition for the underlying vulnerability much more simply. From the paper: Boneh, DeMillo, and Lipton noted that if an attacker had a correct signature s and an incorrect signature s_hat of this form then the attacker could compute gcd(N, s_hat − s) = p. The complicated math comes from the fact that while we have the incorrect signature we're hoping for, we don't have the correct signature over the same message, or a fully known message. * This attack is made possible by our old friend PKCSv1.5, this time in a signing setting. It works because a P1v1.5 RSA signature has regular format: 00 01 FF ... FF 00 aa .. aa hh .. hh, where aa are the (known) bits of the ASN.1 identifier of the hash, and hh are the (unknown) bits of the hash. Everything but the bit values of hh is known to the attacker. * Amusing detail: the attack relies on a condition of the unknown bits being less than 1/4 of the RSA message (modulus) size, so the attack actually gets harder for RSA-1024 with better hashes, and is impossible for RSA-1024 with SHA2-512, which blows that budget. * Another thing that uses PKCSv1.5-RSA signatures is DNSSEC. You could scan the Internet collecting DNSSEC signatures hoping to find some that don't validate (I think it's RIPE that periodically does surveys looking for invalid DNSSEC records, and routinely finding them?), and because all RSA DNSSEC is in viable parameters for this attack I guess recover keys from it? Or you could just not use DNSSEC. I guess maybe this is particularly problematic for "online-signers"; most DNSSEC signatures are computed offline, so you can't just repeatedly ask for new signatures waiting for a fault, but you could with an online signer.
dist-epoch 3y ago
Can you use row-hammer to force the bit flips to speed up this attack?

98 points by Animux 3y ago

fergie 3y ago

Can anybody ELI5?

blueflow 3y ago
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.
- yard2010 3y ago
  What are the methods used by these baddies?
- clbrmbr 3y ago
  How frequently do such faults occur?
  - temac 3y ago
    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.
  - sebstefan 3y ago
    > 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. Seems like over long periods, it can occur a spoopy amount of time.
- mackman 3y ago
  Does each bit flip reveal a bit or less or does somehow a single flip compromise the entire key?
  - SAI_Peregrinus 3y ago
    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.
  - sebstefan 3y ago
    It's akin to me having the secret number 17, giving you 221 (17*13) and then, during a solar flare, fucking it up once and giving you 187 (17*11). You know that the numbers are the product of a multiplication, and you know that a common factor is my private secret number. You figure out that the only way to get to 187 and 221 while keeping a common factor is if that factor is 17. That's just computing the GCD. >An RSA public key consists of a public exponent 𝑒 and a modulus 𝑁 = 𝑝𝑞 that is the product of two primes. The private key consists of the private exponent 𝑑 = 𝑒 −1 mod 𝜙 (𝑁) and 𝑁 . A textbook RSA signature on a message 𝑚 is the value 𝑠 = 𝑚𝑑 mod 𝑁 . To verify the signature, a user checks if 𝑠𝑒 mod 𝑁 = 𝑚 > these attacks exploit the fact that if an error is made while computing modulo one prime, say 𝑞, then the resulting invalid signature ˆ𝑠 is equivalent to the correct signature modulo one prime factor 𝑝, but not 𝑞. 2.2.1 GCD attack on fully known messages. Boneh, DeMillo, and Lipton noted [11] that if an attacker had a correct signature 𝑠 and an incorrect signature ˆ𝑠 of this form then the attacker could compute gcd(𝑁, ˆ𝑠 − 𝑠) = 𝑝
    - gonzo 3y ago
      you have to flip two bits to get from 13 (1101) to 11 (1011).
javajosh 3y ago
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 seem an unlikely attack, it's probably more real than you'd think, given the number of times any single server does TLS negotiation using a given private key. The attack becomes even more likely when you realize that multiple servers will be using the private key. In practice, this gives middle boxes more power, and raises their profile in the threat model significantly. This also opens up the possibility of simply collecting failed transient failed tls negotation data from a large number of (legitimate) clients to reconstruct a private key.
- gosub100 3y ago
  > 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?

magicalhippo 3y ago

RSA digital signatures can reveal a signer’s secret key if a computational or hardware fault occurs during signing with an unprotected implementation using the Chinese Remainder Theorem and a deterministic padding scheme like PKCS#1 v1.5. [...] In this context, a passive adversary can quietly monitor legitimate connections without risking detection until they observe a faulty signature that exposes the private key. The attacker can then actively and undetectably impersonate the compromised host to intercept sensitive data. And they say crypto is hard, sheesh... Seriously though, almost every time I hear about some new (to me) attack, I get amazed at the ingenuity of people.

nonrandomstring 3y ago
> using the Chinese Remainder Theorem Damn those Chinese hackers again!
- wuiheerfoj 3y ago
  Those Chinese hackers from the 3rd century AD no less ;)
GTP 3y ago
Crypto is hard, and part of the hardness is implementing it correctly.
- timschmidt 3y ago
  I think GP's point is that one vulnerable hardware or software implementation in the entire network of implementations being passively observed by the attacker can reveal the private keys. So it's not just your implementations which must be perfect, but all your neighbors, and all theirs too.
  - magicalhippo 3y ago
    I read it as "only" the signing machine needs faulty hardware. Still, bit errors occur, even with ECC, and this allows for a passive hence very unobtrusive attack.

fguerraz 3y ago

So the vast majority of servers is not at risk because OpenSSH is not vulnerable to these attacks?

tptacek 3y ago
Correct. You are almost certainly not at risk. OpenSSL isn't vulnerable to this attack; your stack needs to be seriously archaic to have a vulnerable RSA implementation.
- slt2021 3y ago
  Industrial IoT: hold my beer
- fweimer 3y ago
  Some OpenSSL deployments use RSA plugins that do not contain the check—it's not in generic OpenSSL or OpenSSH code, so every engine plugin needs to implement its own check.
  - tptacek 3y ago
    Which plugins are you aware of that are used for RSA signatures and don't check signature validity? Just curious, from your comment it seemed like there might be specific ones.

pera 3y ago

> 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

hannob 3y ago
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.
- hedora 3y ago
  In particular, all the hosts they recovered keys for seem to be some sort of embedded thing, and over 99.9% were from one vendor.

hannob 3y ago

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-perfect-forward-secrecy 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.

supriyo-biswas 3y ago
FWIW, RSA is well known to be difficult to get right because you have to select the primes very carefully, and must take explicit steps to avoid padding oracle attacks[1], and perhaps it's better to avoid it entirely. [1] https://blog.trailofbits.com/2019/07/08/fuck-rsa/ https://blog.trailofbits.com/2019/07/08/fuck-rsa/
- tptacek 3y ago
  This attack works regardless of how well you've selected your primes and relies on valid padding.
- upofadown 3y ago
  Well, sure, but the alternatives are more complex and harder to get right. You can literally just pick two random numbers of the right magnitude, find the closest primes, and be good for RSA. My comments on "Seriously, stop using RSA": * https://articles.59.ca/doku.php?id=pgpfan:rsabad https://articles.59.ca/doku.php?id=pgpfan:rsabad

lindseyconcerns 3y ago

[dead]

tux3 3y ago

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

hannob 3y ago
Well, yeah, you can: https://www.plundervolt.com/doc/plundervolt.pdf https://www.plundervolt.com/doc/plundervolt.pdf Paper is from 2019.
- tux3 3y ago
  I remember they fixed that one, but plundervolt is more finely targeted, like a traditional glitch attack. The fun thing with this attack is we just need a little bit of corruptions everywhere, and some broken signatures might make it through! DVFS aside, there's plenty of ways to stress and CPU and cause random errors. I don't know whether their RSA implementation protects against this attack, though.
- hedora 3y ago
  It also works against the analogous technology for ARM (2017): https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/tang https://www.usenix.org/conference/usenixsecurity17/technical... The researchers made an app that can run as a normal user and extract the hardware enclave’s private key.

kragen 3y ago

i read the title and thought 'that sounds like nadia heninger' i wasn't wrong

tptacek 3y ago

Headlines: * In (rare) vulnerable targets, this allows you to recover the host's key, and thus impersonate a host. You can't compromise client credentials with this attack, since client credentials are exchanged after the (active) secure channel is established. If you can impersonate a host, as this attack would allow you to do, you could capture client password credentials, and you can drive a forwarded agent. * OpenSSH --- really, SSH servers on any Unix host you've been using in the last 20 years --- isn't vulnerable to this attack. The vulnerability is publishing a signature that is validly signed under RSA p and not under RSA q. Solution: just never do that; when you generate the signature, check it yourself before publishing. This is one of the better-known attacks on RSA, so this is a standard implementation countermeasure. * The things that are vulnerable are crappy middleboxes from Zyxel, Mocana, apparently a rare subset of Cisco devices, and whatever "SSH-2.0-SSHD" is (the authors don't know either). * This is a Nadia Heninger paper, and Heninger is, like, the modern master of the Coppersmith RSA attack, which transforms an RSA problem into a series of polynomials and then transforms those into a linear algebra problem set in a lattice (roughly: a vector space with exclusively integer components; really, when we say "lattice" we mean "some generated basis for that lattice"). You then use the LLL algorithm to reduce the basis, which gives you small vectors that, when reframed back into polynomials or whatever, can tractably solved for their roots. Get the intuition? Yeah, I mean, me neither. Lattice attacks on PQ crypto have a simpler intuition! But the lattices bases here are just R^3 matrices, so, that's pretty simple. * You can get the intuition for the underlying vulnerability much more simply. From the paper: Boneh, DeMillo, and Lipton noted that if an attacker had a correct signature s and an incorrect signature s_hat of this form then the attacker could compute gcd(N, s_hat − s) = p. The complicated math comes from the fact that while we have the incorrect signature we're hoping for, we don't have the correct signature over the same message, or a fully known message. * This attack is made possible by our old friend PKCSv1.5, this time in a signing setting. It works because a P1v1.5 RSA signature has regular format: 00 01 FF ... FF 00 aa .. aa hh .. hh, where aa are the (known) bits of the ASN.1 identifier of the hash, and hh are the (unknown) bits of the hash. Everything but the bit values of hh is known to the attacker. * Amusing detail: the attack relies on a condition of the unknown bits being less than 1/4 of the RSA message (modulus) size, so the attack actually gets harder for RSA-1024 with better hashes, and is impossible for RSA-1024 with SHA2-512, which blows that budget. * Another thing that uses PKCSv1.5-RSA signatures is DNSSEC. You could scan the Internet collecting DNSSEC signatures hoping to find some that don't validate (I think it's RIPE that periodically does surveys looking for invalid DNSSEC records, and routinely finding them?), and because all RSA DNSSEC is in viable parameters for this attack I guess recover keys from it? Or you could just not use DNSSEC. I guess maybe this is particularly problematic for "online-signers"; most DNSSEC signatures are computed offline, so you can't just repeatedly ask for new signatures waiting for a fault, but you could with an online signer.

dist-epoch 3y ago

Can you use row-hammer to force the bit flips to speed up this attack?