Cryogenically frozen RAM bypasses disk encryption methods (2008)
zdnet.com
zdnet.com
https://www.dfrws.org/2016eu/proceedings/DFRWS-EU-2016-7.pdf
Essentially, with newer RAM (DDR3), the location things end up on the physical chip is scrambled to improve reliability:
> Storage of bit streams which are strongly biased towards zero or one can lead to a multitude of practical problems: Modification of data within such a biased bit stream can lead to comparatively high peak currents when bits are toggled. These current spikes cause problems in electronic systems such as stronger electromagnetic emission and decreased reliability. In contrast, when streams without DC-bias are used, the current when working with those storage semiconductors is, on average, half of the expected maximum.
So once you image the RAM you have to figure out the scrambling and undo it.
Related: https://github.com/IAIK/DRAMA
Note: Nice shortcut link to the blog and research on it. LAVA is still on my backlog to check out although some itch in me suggests it has potential in high-assurance for testing tools, mechanisms for recovery-oriented architectures, or even teams with simulated subversion. Just haven't had time so far after work and looking at preventative stuff.
1. Inject flaws into formal specification of problem. Knowledge-based methods might do that for modifications in domain representing slip-ups of experts. Semantic methods might modify specs directly to flip a logical property. Preferably one similar to it to increase odds that they overlook it.
2. Formal policy of safety or security. This is a policy, type system, info flow labels, access control matrix... any of that. The injections would deliberately weaken the policy. This would combine templates that ensure common flaws got represented plus truly random ones. Lean more toward templates here as opponents will want to create things that break policy in catastrophic ways. That likely, but not certainly, means they'll focus on specific areas of policy for mods.
3. Formal verification. Similar to above or code-level tests but for intermediate forms or verification conditions. Maybe for proof tactics too if someone is trying to design a prover that doesn't get lost for too long. I think a simple time-out with trace log would suffice for that, though.
4. Code is the next part. You people largely have it covered in isolation. However, it must map to specs or requirements in high-assurance products. So, the mappings could be screwed up where code is tweaked to mis-match the spec similar to how specs are tweaked above. Also, the Design-by-Contract or other invariants might be modified to mislead an evaluator like SPARK Examiner or Astree Analyzer. If it supports it, the compiler instructions or pragma's might be modified to make compiler inadvertently break the code.
5. Testing. There's already a lot of work on this one where compilers, analyzers, tests, and/or fuzzers are mixed. I'll leave them to it as only basics are really needed for high-assurance. Other benefits or methods are still debated.
6. Effects of optimizations on source to object translation. Starts with equivalence checking ability. From there, different optimizations are used to try to break safety/security/correctness properties of the code with tool attempting detection. Goal of injector is to prevent that. Eventually, a corpus would be generated here of software fragments, transformation, and result that could tell us more via machine learning techniques. That's true of above in general but SSA etc is low level & small.
7. Covert channel analysis. Step most "secure" software misses although mainstream rediscovering it slowly as "side channels." Mainly focus on storage, timing, and resource exhaustion channels. Create tools to find the connections automatically in software either statically or dynamically with a test suite in progress. Inject covert channels all over the place. See what it finds.
8. Type systems. They're usually eyeballed or analyzed with formal methods. Often abstractly. I'd like to see above code- and formal-level injection combined to produce and test possible failures of executable, formal spec of type system and/or implementations of it. I bet it would find something.
So, there's what's off top of my head as I apply my mental framework for high-assurance security onto the abstract of your LAVA tool. Much potential for research and results if this grows into its own field. All I ask if you or one of your PhD's turns this into real papers is credit for contributing the idea to do so. :)
Regardless, what do you think of these? Are other people doing them? Are they novel? Which you see most bang for buck? Far as I can tell & based on current market share, biggest impact in order are static analysis, compiler optimizations, type systems, covert channels to stop memory leaks, and improved formal policies to support type systems and design-by-contract. The rest possibly useful but less so.
Note: The short-cut link on your Twitter to your blog was hilariously named. If it was intentional.
scrambling is done in a lot of systems, especially in telecom to condition the signal to have some special signals processing property (reducing DC level, changing spectrum shape, etc)
https://people.csail.mit.edu/devadas/pubs/aegis-istr-august6...
Joshua Edmison's dissertation lists a number of others along with his own, interesting scheme:
https://theses.lib.vt.edu/theses/available/etd-10112006-2048...
Nobody has learned anything different since for the fundamentals. The fundamentals are still to use authenticated crypto of some sort on RAM to detect attacks there to fail safe at worst. Also, use special IO/MMU's, SOC mechanisms, and software protected by them to handle stuff on disks. Stopping cold boot attack is straight-forward on such architectures that don't trust RAM in the first place.
From there, we move into cat and mouse game of SOC attack and defense. Most of those require physical possession for more than a few minutes, though, with often destruction of the chip as a result. So, this is a significant step forward in security vs just snatching the RAM out of the system.
OS X has a setting called "destroy FileVault key on standby" in `pmset` which mitigates cold boot attacks.
I kinda want the CPU/MMU to support loading encryption keys to transparently encrypt some or all of RAM (could also toss in error checking while we're at it). SGX has this in the trusted containers, but I think it makes sense for general use too.
Anyone know if this is true or not?
Is there some reason that RAM has to be zeroed serially? It seems like nothing's theoretically stopping the entirety of a RAM memory module from being erased, in parallel, in a single memory write cycle.
Would it be very much more costly to design a memory module with a signal line that, when high, would e.g. turn a write into a write on every memory cell on the module?
1) Rent an entire rack with a 19" rackmount UPS, as well as locks connected to the server to signal if the rack has been opened, and motion sensors, as well as a compass
2) If either the power from outside goes down, or the lock/cage alarm triggers, or the motion sensor/compass detects motion, wipe the RAM section that contains the HDD encryption keys and power down the machine.
Why a compass? Because in case the cops try to move the entire rack carefully (to not trigger a motion sensor with false-alarm filtering), and they rotate the rack, the compass will detect it.
Also, spoof the GPS signal to avoid your next attack, wrap you in a faraday cage and broadcast an identical set of WiFi/Cellular signals.
My point isn't that any of this is more or less practical, simply that any protection you can dream up can be defeated if they know about it and are expecting it.
Also, your password was 'lovesexsecretgod' and you left SSH open :)
Is this sarcasm or did you actually get this from the above poster?
Such a strong magnet can be detected, too, e.g. with four 3-axis compasses.
> Also, spoof the GPS signal to avoid your next attack, wrap you in a faraday cage and broadcast an identical set of WiFi/Cellular signals.
Nice idea, but in case you're using a cellular uplink, as soon as the faraday cage is in place, your trigger fires. Also, spoofing GPS signals requires expensive equipment and IIRC also cooperation of the Feds.
> My point isn't that any of this is more or less practical, simply that any protection you can dream up can be defeated if they know about it and are expecting it.
Which is why you don't publish every detail of how your farm is protected ;)
You can also avoid the UPS requirement by using an internal battery that just wipes the RAM (10KV discharge? Thermite charge? C4?) when case integrity is compromized or when a thermometer/barometer/accelerometer/gyro threshold is exceeded.
Any evidence of it in the wild in the past 8 years, like, you know, actually used once?
By simply plugging in a bootable USB that we made, powercycling the computer [0], and selecting boot from USB in the BIOS we were able to get a memory dump from the computer.
By analyzing this memory dump, we were able to reconstruct the HTML of webpages that were open, and generate a list of password looking strings, which did contain several actual passwords.
I guess this isn't really in the wild, as it was one of our own laptops, but their was nothing stopping us from doing it on school computers to hack into other people's accounts if we wanted to; and, the person whose computer we used did end up changing her passwords.
More importantly, if a couple of highschoolers could turn this idea into a usable exploit, I would be amazed if this was never done for actual attacks.
[0] Most of the time it worked if we manually powered the computer down then up, but it worked consistently when we rebooted from within the OS.
I have heard confirmation of this from friends arrested in the UK (by Scotland Yard) and in the USA (by the FBI). I don't believe they actually witnessed it being done,just that they had what was needed. Though my infosec instructor in university was in the RCMP (Canada) and mentioned hqving done it himself so I'm rather confident law enforcement globally has had this in their arsenal for awhile.
I have never gotten to use it irl though.
[0] http://www.arcticsilver.com/arctic_alumina_thermal_adhesive....
I'm not entirely sure I understand what it means by capacitive in this context, but, not conductive and the overall sentence there seems to strongly indicate that it specifically will not short out.