Cold boot attack mitigation

Since the data stored in RAM takes some time to degrade once power is lost, unencrypted data stored in RAM can be recovered if an actor can physically access the modules.

What (hypothetical) solutions could realistically make this attack vector irrelevant?

While you could put physical barriers in place (like soldering RAM to the board, or a locking case), these are still vulnerable.

Maybe you could redesign a RAM module to have a battery, like for CMOS, and use that power to zero-fill the RAM when primary power is lost. This way, even if an attack is carried out, no useful data could be recovered.

Attached: frozen ram.jpg (814x364, 487K)

Other urls found in this thread:

software.intel.com/en-us/blogs/2017/12/22/intel-releases-new-technology-specification-for-memory-encryption
twitter.com/SFWRedditVideos

Full RAM encryption.

Just add a capacitor and zap the ram once the computer is turned off :D

The key is not to possess any data that would make someone want to retrieve it so badly.

>some time to degrade
Keyword is, how long?
EVERYTHING takes - "some time" - to degrade.

This. You just need to have nothing to hide

a few minutes maximum. the traditional attack is to cool down the RAM to slow the degradation process and buy some more time.

I doubt anyone would go through such an effort to steal my anime collection, but some people, or organizations, are. It's an attack vector that universally affects computers, and as far as I am aware there's not really a solution in place.

drop to runlevel 3, unmount your encrypted partitions, mount a tmpfs that's almost the size of your RAM and write random data to it before shutdown

Isn't flushing the ram trivial in terms of software? malloc or whatever.

that has been done before, i believe to validate spectre attack (or maybe it was the rowhammer one, cant recall for sure), but im almost sure i saw a video of someone freezing the modules and quickly swapping boards, i think it was even a live one

yeah, but cutting the power would immediately halt that process.

so don't cut the power then

Use Intel TME (Total Memory Encryption). software.intel.com/en-us/blogs/2017/12/22/intel-releases-new-technology-specification-for-memory-encryption

this relies on the user being in control of the device. you don't even have to go through that. if you shut down your pc, and just wait 5 minutes for the RAM to degrade, you're safe.

The nature of the attack is that it occurs on a locked but powered system under the control of a bad actor.

>The nature of the attack is that it occurs on a locked but powered system under the control of a bad actor.
don't leave the computer on if you're out then

>5 minutes
Only if your using cheap AF DDR2 RAM modules. DDR3 will be unrecoverable after a few seconds, 30 seconds max.

while that's a useful heuristic, it's not really applicable for cases where you would actually be under threat of this attack. As in, security agencies, banks, healthcare, etc. You can't just rely on every individual that interfaces with the system never fucking up. Beyond that, why should you rely on it, if the problem can be solved with a hardware change instead of a behavioral change.

TAILS floods the RAM with zeros after you shut it down (which can be achieved by unplugging the live USB drive you booted from)

Hell, attach the drive to a string and tie it to your wrist. Just don't yawn and stretch while saving something important lol

>Data remanence has also been observed in dynamic random-access memory (DRAM). Modern DRAM chips have a built-in self-refresh module, as they not only require a power supply to retain data, but must also be periodically refreshed to prevent their data contents from fading away from the capacitors in their integrated circuits. A study found data remanence in DRAM with data retention of seconds to minutes at room temperature and "a full week without refresh when cooled with liquid nitrogen."[11] The study authors were able to use a cold boot attack to recover cryptographic keys for several popular full disk encryption systems, including Microsoft BitLocker, Apple FileVault, dm-crypt for Linux, and TrueCrypt.[11](p12)

>Despite some memory degradation, authors of the above described study were able to take advantage of redundancy in the way keys are stored after they have been expanded for efficient use, such as in key scheduling. The authors recommend that computers be powered down, rather than be left in a "sleep" state, when not in physical control of the owner. In some cases, such as certain modes of the software program BitLocker, the authors recommend that a boot password or a key on a removable USB device be used.[11](p12) TRESOR is a kernel patch for Linux specifically intended to prevent cold boot attacks on RAM by ensuring encryption keys are neither user accessible nor stored in RAM.

based retard

Attached: 1530664730859.jpg (645x729, 82K)

>What (hypothetical) solutions could realistically make this attack vector irrelevant?
Bro that nigga gotta be SANIC fast. Like milliseconds?

>data remanence in DRAM with data retention of seconds to minutes at room temperature and "a full week without refresh when cooled with liquid nitrogen.

you can take your time if you've got the tools. a week is a while.

Second layer of contacts above the ones normally used that will zap the ram as it is removed if the machine is turned on
Can I have a job now Mr glowinthedark CIA?

Use a 7980XE or 9980XE with Noctua L9i. Makes the RAM so hot it degrades too fast after power off

Op is asking how to defend against ram attacks, not how to beam a dump directly to Israel and the nsa

The problem is that this would only work if you didn't know about it. "security through obscurity". bypass power to the RAM and it doesn't matter anymore. Then you've just got a normal stick of RAM, proceed as normal.

The classic "thermite in the case" works, of course.

I'm trying to imagine a hardware solution that either delays access, or forces a wipe. After all, the problem is a hardware issue. It's hypothetical though. encasing your computer in concrete could theoretically prevent anyone from getting in before the RAM degrades, but it's not a practical solution.

>hardware solution that either delays access, or forces a wipe.
case open sensor attached to some kind of plastic explosive.
>but if you knew about
multiple sensors
To disable the sensors the system must be turned off but if turned off RAM decays if case is opened with power on plastic explosive triggers hopefully destroying RAM and or PSU and delaying recovery with shockwave from explosion

dont let anyone near your computer

Correct

Found the person who doesn't know what they are taking about.

I work at a place were people have shelled out to have hardware encryption of the DDR to mitigate freeze can attacks. It's extremely costly and I only know of military applications were this is actually is a valid concern.

For consumers though its total overkill, only a extremely well funded government agency can even pull off a freeze can attack anyways.

Nuts. FPGA board with DIMM slots plus CO2 tube. $1000 should be enough.

Well the other problem is most computers the military is worried about being captured have soldered DDR and they may even have blind and buried traces to the DDR parts on the PCB.

Just getting to the DDR traces without fucking up the signal integrity would be very difficult.

lock your computer case in a way that takes longer to open it than data would remain in RAM

the downside is if the computer catches fire, you may not be able to open it to use a fire extinguisher. you may need a way to work around that (inner sprinkler system?)

Attached: maxresdefault.jpg (1280x720, 101K)

Cover it in semen?

>data retention of seconds to minutes at room temperature
so you just have to close the machine 2 mins earlier and when the 2 mins have passed, you can then leave the place.

why freeze the ram, instead of reading directly from your cache, since that memory is non-volatile?

How about instead of getting mad ar hardware for doing something it's supposed, you get mad at the software for doing things it's not.

how would you implement a software solution to this?

the problem is:
data is stored in RAM
when power is cut to RAM, that data is still there for a few minutes
software can't do anything if power is cut unexpectedly.

>all this destructive stuff and expensive encryption
>no drain resistor

What about that memory encryption that AMD added in Epyc? Is it only for isolating VMs or can it be used to prevent this kind of attacks?

>cache
>non-volatile

Or you can just avoid Nvidia.

you might want to open your EE books and stay away from wiki for a bit.
sram retains for a long period of time the charge and you can get the stored data even if you shut it down.
How long? depends on the leakage and the node.
sram doesn't need to get "refreshed" like dram, so that should make you wonder.

according to normie websites, everything is volatile, even nand memory (ssds), most companies on nand chips give you up to one year before you start losing charge inside each cell.
you cpu's cache _is_ non-volatile.

i mean define fucking volatile. everything is volatile in the long term. storage media degrades. i get what you're saying, but the CPU cache isn't relevant, and it is volatile in the sense that it's not hard storage like an HDD is. a cold boot attack targets DRAM because that's where encryption keys are stored.

theoretically if cold enough you can have it take weeks before full degradation happens.
Further, it degrades in a predictable manner, so if you retrieve enough of the bits in the memory, you have a good chance of reconstructing the majority, even if it's already been degraded.

So what? The CPU cache serves a different purpose anyway. Unless the user had just entered their key, it would surely be purged from the cpu cache. realize a cpu cache is like, 8 MB. As soon as any other operation occurred, the key would be pushed off, and reside in DRAM. You'd have to be actively monitoring the CPU cache to catch it that way.

sram is NON volatile.
It doesn't need periodic charging to retain its data/state.
nand memory is NON volatile.
It doesn't need periodic charging to retain its data.
dram IS volatile.
you have to periodically charge it to retain its data/state.

how much time can dram store your data before it gets erased? a few μs.
how much time can nand keep your data before it gets lost? a few months.
how much time can sram store your data before it gets erased? depends on the node which affects the leakage, it can be from several minutes to days.

there are cpu attacks that during boot up, and before the cpu's microcode flags everything in the cache and registers as "dirt", it reads everything where the dirty bit is 0 and tries to extract sensitive data.


I am not surprised that wikipedia claims that sram is volatile, they also claim that linux is an operating system, which the last years changed to "linux nowadays refers to the operating systems using linux"

also, IPC is Instructions per Clock and have nothing to do with single core performance. ...and that's again taken from comp. arch books.

A program can clear the memory it was using before exiting, dumb-dumb.
>b-but muh contrived situation!
A random act of nature isn't an excuse to not de-allocate memory properly.

it doesn't get to exit gracefully. it's a forced power cut. that's the "cold" in a "cold boot attack".

>if an actor can physically access the module
Every single method that already exists for physical security is tight enough to not need something to handle this extremely specific case. If you have someone that has already made it through your other physical security to directly access the RAM module, you've got serious issues elsewhere that need to be immediately addressed before something this incredibly specific.
If an adversary/bad actor can get physical access to your information systems long enough to get to the RAM modules, remove them without damaging them or throwing off some kind of other sign of tampering that would immediately notify someone, and then super cool them so that the data is stable long enough to do something with it, your physical security is so absolutely terrible that people are going to be walking out with your literal money in their pockets constantly.
The situation you're accounting for is basically almost the equivalent of asking how you ensure stolen gold is valueless so people won't want to steal it after you've should have already built Fort Knox to hold it.

spbp

>so you just have to close the machine 2 mins earlier and when the 2 mins have passed, you can then leave the place.
Yeah it's a physical security problem. You have to detect an intruder and delay him long enough to put the machine in a safe state. DDR3-1600 has a peak transfer speed of about 12GB/s. So you put a lot of RAM in a safe state in 5 seconds. If all your data, besides a few keys, is encrypted, then you just have to overwrite the keys. Shutting off the power will fix it eventually. Set any time limit and you're relying on undefined behavior.

>why do banks put dye-packs in money for thieves
>why encrypt data on a drive if you can just keep people from accessing the drive

>there are cpu attacks that during boot up, and before the cpu's microcode flags everything in the cache and registers as "dirt", it reads everything where the dirty bit is 0 and tries to extract sensitive data.
>what is Intel Boot Guard, Secure Boot, Measured Boot
Why should someone worry, unless the official BIOS is compromised?

once you pull the plug from your computer, within a few milliseconds your dram is almost filled with gibberish.
if you are on windows and shutdown your machine, you have to delay the guy with the liquid nitrogen for about 30 mins before all updates are installed and the machine can then shutdown.

the whole thread is about "security concerns for cases that are never going to happen".
If someone came to my office and could extract data from my dram, i'd be impressed.

Schizo thread.

Shit happens, life sucks, get used to it.

FPBP. Ebin supports this if I'm not mistaken.

turn it off, pull the plug and press power button a few times, this will discharge the capacitors and that's it.

>why are you afraid of human rights violation, just stop existing XD

This only works if the attacker gets their hands on the hardware physically without being intercepted. You can knock this out the park with a simple dead man / kill switch you can build with a $10 USB-connected button without writing a single line of code. If you're really worried, booby trap the environment you're in. A single push forced shutdown and you're done.

hahahaha this is gold
and if they get the usb?

By raping the cyberdelinquant in the anus, showing dominance.

>sram is NON volatile.
NVRAM means that it retains its contents even when power is lost, NAND and NOR flash memory are examples of NVRAM. SRAM is a kind of volatile memory, it doesn't require constant refreshing but if you cut the power the contents of the memory will be immediately lost. I think SRAM would actually be cleared even faster than DRAM.

>you might want to open your EE books and stay away from wiki for a bit.
>sram retains for a long period of time the charge and you can get the stored data even if you shut it down.
>sram doesn't need to get "refreshed" like dram, so that should make you wonder.

What the fuck

SRAM doesn't need to be refreshed but that's fucking irrelevant to the definition of non-volatile. If you cut the power on SRAM it loses its contents immediately. SRAM only holds its state as long as power is maintained.

This. I can't believe there isn't any ram marketed as high security that has this. Although to be actually secure you'd need to put the clearing capacitor on die so it can't just be clipped of desoldered before performing the attack.

>open ram compartment
>pour a healthy amount of epoxy covering the dimms
>destroy the screw heads after screwing on the cover glued shut

Attached: 1555310711459.jpg (640x733, 82K)

serious question, how can such attacks be useful in real life? let's say we managed to copy the entire RAM, how can we extract for instance a private SSH key or a password that is only used in some program?

the whole thing seems too chaotic at least from what I understand about linux kernels for these attacks to be really effective out of academia

encryption keys are stored in plaintext in RAM. so in the case of FDE, you have full access if you can read the RAM.

It's perfectly possible. You can analyze the system state at the time of the attack and determine where it would look to get the key, or find the process memory for the application you're interested in and do the same thing. Stuff can be obfuscated, but at the end of the day if the program could get the key then you can. Everything is frozen in glass for you to see.

This is also why DRM always gets cracked. Put the keys in the hands of decent attackers and they'll figure it out no matter how hard you try to hide it.

I know, I just want to understand how to know that this memory location and that memory range exactly has something valuable like an encryption key, private key, password, etc..

what I don't understand is let's say we have a snapshot from a running linux machine, let's say that the machine was running Firefox and Firefox did store the symmetric key that is used to encrypt and decrypt messages after the handshake for some website. How can you know that these 8 bytes are actually what you need while you got a 8GB of mostly random shit, most of them garbage that was deallocated by programs prior to the snapshot

Just cover your ram with an inch thick layer of epoxy glue