This is mitigated by a Trusted Computing Group feature - at boot, the OS sets a non-volatile flag, and clears it again on clean shutdown after wiping any sensitive material from RAM. If the system boots with the flag set then the firmware wipes the RAM before booting anything. This doesn't protect you against someone pulling the RAM out of the system and dumping it there, but that's a much harder attack.
Show HN: Simple demo of a cold boot attack using a Raspberry Pi
21–30 of 40 posts
Re: Show HN: Simple demo of a cold boot attack using a Raspberry Pi
#22I'd never even heard of cold boot attacks. Is there any prevention of this?
Keeping secrets out of main memory, either with registers, encrypted memory, or use of a secure enclave (which in turn uses encrypted memory) for sensitive operations.
Re: Show HN: Simple demo of a cold boot attack using a Raspberry Pi
#23It's nice to recover an image but encryption keys are not that. One bit flip and it's game over. This experiment is more useful for human-readable document forensics than anything else.
Alright let's test this hypothesis. Load up a bitcoin wallet and post the private key here with 1 random bit flip :)
You might think you're being clever, but specifying exactly 1 random bit flip makes it a completely different scenario.
Re: Show HN: Simple demo of a cold boot attack using a Raspberry Pi
#24It's nice to recover an image but encryption keys are not that. One bit flip and it's game over. This experiment is more useful for human-readable document forensics than anything else.
If from a 128 bit key 120 are correct, it's trivial to figure out the others, even if you don't know which bits are the flipped ones. Cryptographers worry even when a few key bits are leaked.
> If from a 128 bit key 120 are correct, it's trivial to figure out the others, even if you don't know which bits are the flipped ones.
Can you elaborate a bit? Off the top of my head, I feel like that scenario would leave 128-choose-8 possibilities open, or about 1.4 trillion. Are we calling that "trivial" or am I misunderstanding the attack?
(If you're calling that "trivial", I think that could be reasonable in a cryptography context where you're considering attackers with a lot of resources. It's just different from how I usually use that word. I don't disagree with your conclusion that leakage of even a few bits is worth worrying about.)
Re: Show HN: Simple demo of a cold boot attack using a Raspberry Pi
#25Earlier quoted context omitted.
If from a 128 bit key 120 are correct, it's trivial to figure out the others, even if you don't know which bits are the flipped ones. Cryptographers worry even when a few key bits are leaked.
> If from a 128 bit key 120 are correct, it's trivial to figure out the others, even if you don't know which bits are the flipped ones. Can you elaborate a bit? Off the top of my head, I feel like that scenario would leave 128-choose-8 possibilities open, or about 1.4 trillion. Are we calling that "trivial" or am I misunderstanding the attack? (If you're calling that "trivial", I think that could be reasonable in a c…
If it's 1.4T it depends on what you're using it for. Someone on SO has a verify speed for 512 bit rsa keys at 350k/second which would leave it at I think a month and a half to run 1.4T. That's a random user and a single machine. ECDSA 128 bit verify maybe 6k/s on a single core of a not-great CPU. That puts you about a month or two of a moderate machine assuming there's no fancy gpu things for doing it.
Re: Show HN: Simple demo of a cold boot attack using a Raspberry Pi
#26Earlier quoted context omitted.
> If from a 128 bit key 120 are correct, it's trivial to figure out the others, even if you don't know which bits are the flipped ones. Can you elaborate a bit? Off the top of my head, I feel like that scenario would leave 128-choose-8 possibilities open, or about 1.4 trillion. Are we calling that "trivial" or am I misunderstanding the attack? (If you're calling that "trivial", I think that could be reasonable in a c…
If it's 1.4T it depends on what you're using it for. Someone on SO has a verify speed for 512 bit rsa keys at 350k/second which would leave it at I think a month and a half to run 1.4T. That's a random user and a single machine. ECDSA 128 bit verify maybe 6k/s on a single core of a not-great CPU. That puts you about a month or two of a moderate machine assuming there's no fancy gpu things for doing it.
These are symmetric keys - AES, not ECDSA. Much faster to test.
Re: Show HN: Simple demo of a cold boot attack using a Raspberry Pi
#27Earlier quoted context omitted.
If from a 128 bit key 120 are correct, it's trivial to figure out the others, even if you don't know which bits are the flipped ones. Cryptographers worry even when a few key bits are leaked.
> If from a 128 bit key 120 are correct, it's trivial to figure out the others, even if you don't know which bits are the flipped ones. Can you elaborate a bit? Off the top of my head, I feel like that scenario would leave 128-choose-8 possibilities open, or about 1.4 trillion. Are we calling that "trivial" or am I misunderstanding the attack? (If you're calling that "trivial", I think that could be reasonable in a c…
A NVIDIA 3090 with HashCat can do 3 billion AES decryptions per second. That would test all 1.4 trillion in less than an hour.
Re: Show HN: Simple demo of a cold boot attack using a Raspberry Pi
#28This is mitigated by a Trusted Computing Group feature - at boot, the OS sets a non-volatile flag, and clears it again on clean shutdown after wiping any sensitive material from RAM. If the system boots with the flag set then the firmware wipes the RAM before booting anything. This doesn't protect you against someone pulling the RAM out of the system and dumping it there, but that's a much harder attack.
There is an actual solution - full memory encryption on recent Intel/AMD CPUs.
Re: Show HN: Simple demo of a cold boot attack using a Raspberry Pi
#29Earlier quoted context omitted.
If from a 128 bit key 120 are correct, it's trivial to figure out the others, even if you don't know which bits are the flipped ones. Cryptographers worry even when a few key bits are leaked.
> If from a 128 bit key 120 are correct, it's trivial to figure out the others, even if you don't know which bits are the flipped ones. Can you elaborate a bit? Off the top of my head, I feel like that scenario would leave 128-choose-8 possibilities open, or about 1.4 trillion. Are we calling that "trivial" or am I misunderstanding the attack? (If you're calling that "trivial", I think that could be reasonable in a c…
> scenario would leave 128-choice-8 possibilities open
That only amounts to log2(C(128, 8)) ~= 40.3.
Your encryption key is now just 40-bit strength.
Re: Show HN: Simple demo of a cold boot attack using a Raspberry Pi
#30It's nice to recover an image but encryption keys are not that. One bit flip and it's game over. This experiment is more useful for human-readable document forensics than anything else.
Alright let's test this hypothesis. Load up a bitcoin wallet and post the private key here with 1 random bit flip :)
If you just recovered a secret key, you have no idea how many bits were flipped or their positions or if they were flipped at all or even it if it's actually a key rather than random garbage data. Key strength is therefore maintained.
Posting a secret key here and specifying "exactly one bit was flipped" reduces the problem to N guesses where N is the key length since you know all the other N - 1 bits are correct. Leaking just a few bits has catastrophic consequences, in your example all bits except one are leaked.