DRAM is not a safe place to store your secrets due to cold boots, so it gets stored in SRAM (which includes registers and L1/L2 cache) instead.
Buuuuut, you might be able to dump SRAM across boots with this technique.
If I understand correctly: SRAM/cache/registers all require a lower voltage to maintain their state than the cpu requires to run.
So attach that intermediate voltage on the VCC pin closest to/running the SRAM and pull the plug on everything else. I guess they’re either not cross-connected internally or the choice of voltage stops that from being a problem. Just don’t let your voltage sag lower than required to maintain the SRAM.
Now your cache/registers/SRAM are maintained. Power up with JTAG or a custom/debugging bootrom/mode that hopefully doesn’t overwrite much/any and dump away.
> Our experiments across various devices reveal that hardware SRAM resets during boot are uncommon. Most boot with undefined SRAM states, persisting until overwritten by software.
Chips often have multiple VCC pins exactly because otherwise there is voltage drop across the chip. This is a hard problem. For chips where this is a security issue, I guess one answer may be to do voltage distribution on the interposer, since fewer attackers can deal with a raw die.
If I understood the article correctly; the different on-chip elements have separate power supplies.
Makes sense: you might want to turn off the CPU but keep the SRAM/cache/etc running for hibernation, and that’s controlled externally for some reason (?)
You're right, that was the hole here. The reply by Tuna-Fish gives the correct reason for this setup (different voltages). The actual power converter usually needs at least an off-chip capacitor, even if the logic is integrated, because that's too large to be cost-efficient in silicon; so there might be an opening even if as much as possible was integrated - haven't thought that through though.
It's not normally controlled externally, but the power comes from an external source, and as the different parts of the chip want different voltages, they connect to different power sources. If you control everything outside the chip and cut the supply to parts of it, there is little that the chip can do about it, even if it normally controls distribution.
> Now your cache/registers/SRAM are maintained. Power up with JTAG or a custom/debugging bootrom/mode that hopefully doesn’t overwrite much/any and dump away.
If you care about security, you'd be disabling these. Every product I've worked on disables JTAG and other debug features on production boards and enables secure boot.
The use case for this is similar to the cold boot attack, e.g. disk is encrypted but memory is not. (And I don't know how encrypted DRAM works, but I wouldn't be surprised if some implementations put the key in SRAM that can be dumped using this technique.) Anyway, there may be valuable secrets that exist in SRAM but but not on disk.
Layman’s article: https://cacm.acm.org/research-highlights/technical-perspecti...
Also seems like ACM republished the author’s paper from 2022? https://dl.acm.org/doi/pdf/10.1145/3503222.3507710
My summary:
DRAM is not a safe place to store your secrets due to cold boots, so it gets stored in SRAM (which includes registers and L1/L2 cache) instead.
Buuuuut, you might be able to dump SRAM across boots with this technique.
If I understand correctly: SRAM/cache/registers all require a lower voltage to maintain their state than the cpu requires to run.
So attach that intermediate voltage on the VCC pin closest to/running the SRAM and pull the plug on everything else. I guess they’re either not cross-connected internally or the choice of voltage stops that from being a problem. Just don’t let your voltage sag lower than required to maintain the SRAM.
Now your cache/registers/SRAM are maintained. Power up with JTAG or a custom/debugging bootrom/mode that hopefully doesn’t overwrite much/any and dump away.
> Our experiments across various devices reveal that hardware SRAM resets during boot are uncommon. Most boot with undefined SRAM states, persisting until overwritten by software.
Oops.