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 :)
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 ;)
Is this sarcasm or did you actually get this from the above poster?
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.
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.
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)
[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.
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?
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.
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.
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.
I have never gotten to use it irl though.
