4 ms·

I wonder if it would be worth checksumming public keys and re-checking the checksum each time it's used?

by caf 10y ago

quickben 10y ago
Something like Perspectives for Firefox?
- caf 10y ago
  No, much simpler - store a checksum alongside public keys in places like .ssh/authorized_keys, and have the software like sshd recompute the checksum of the in-memory key each time it uses it for authentication. The attack relies on glitching the in-memory key.
  - kccqzy 10y ago
    This doesn't sound correct. What if the attacker times the operation so that the bit corruption occurs after the checksumming but before being actually used for cryptographic operations?
    - caf 10y ago
      Yes, to be safe you'd have to do the checksum after performing the RSA operation.
runeks 10y ago
That's security by obscurity (which may work to delay the attacker). If an attacker can modify your public keys he can modify your checksums as well. Seems to me that a public key should be identified by a cryptographic hash of it, rather than the public keys itself. Then the attacker would need to replace the entire hash, rather than just a few bits, because the hash changes completely just by flipping a single bit in the input.
- caf 10y ago
  The attacker isn't making targeted modifications to your public keys, though: they're randomly glitching it, and using the page sharing implemented by the hypervisor to read out and factor the glitched version. Even with say a 64 bit checksum then there's only a 1 in 2^64 chance of the randomly modified key/checksum pair matching. But you could use a cryptographic hash as your checksum if you wanted. I only suggest this not because I think it would be a complete defence against all Rowhammer attacks - it wouldn't - but because the general fragility of the RSA construction means that doing it with any potentially corrupted input gives me the willies. There are other sources of bitflips other than Rowhammer and it just strikes me as a generally good idea not to leak the results of RSA operations performed on potentially bitflipped inputs.
jameshart 10y ago
If your threat model now includes 'the attacker can at arbitrary times make arbitrary alterations to the working memory of my process' then no, this won't help. You can't trust the checksum, you can't trust that the data you just check summed hasn't subsequently changed, and you can't trust that data which passes a checksum wasn't previously different. Also you can't trust the checksum code itself. Or the operating system you're running on. Or anything.

I wonder if it would be worth checksumming public keys and re-checking the checksum each time it's used?

by caf 10y ago

I wonder if it would be worth checksumming public keys and re-checking the checksum each time it's used?

quickben 10y ago

Something like Perspectives for Firefox?

caf 10y ago
No, much simpler - store a checksum alongside public keys in places like .ssh/authorized_keys, and have the software like sshd recompute the checksum of the in-memory key each time it uses it for authentication. The attack relies on glitching the in-memory key.
- kccqzy 10y ago
  This doesn't sound correct. What if the attacker times the operation so that the bit corruption occurs after the checksumming but before being actually used for cryptographic operations?
  - caf 10y ago
    Yes, to be safe you'd have to do the checksum after performing the RSA operation.

runeks 10y ago

That's security by obscurity (which may work to delay the attacker). If an attacker can modify your public keys he can modify your checksums as well. Seems to me that a public key should be identified by a cryptographic hash of it, rather than the public keys itself. Then the attacker would need to replace the entire hash, rather than just a few bits, because the hash changes completely just by flipping a single bit in the input.

caf 10y ago
The attacker isn't making targeted modifications to your public keys, though: they're randomly glitching it, and using the page sharing implemented by the hypervisor to read out and factor the glitched version. Even with say a 64 bit checksum then there's only a 1 in 2^64 chance of the randomly modified key/checksum pair matching. But you could use a cryptographic hash as your checksum if you wanted. I only suggest this not because I think it would be a complete defence against all Rowhammer attacks - it wouldn't - but because the general fragility of the RSA construction means that doing it with any potentially corrupted input gives me the willies. There are other sources of bitflips other than Rowhammer and it just strikes me as a generally good idea not to leak the results of RSA operations performed on potentially bitflipped inputs.

jameshart 10y ago

If your threat model now includes 'the attacker can at arbitrary times make arbitrary alterations to the working memory of my process' then no, this won't help. You can't trust the checksum, you can't trust that the data you just check summed hasn't subsequently changed, and you can't trust that data which passes a checksum wasn't previously different. Also you can't trust the checksum code itself. Or the operating system you're running on. Or anything.