7

The thread title says it, i would like to know how long a system encryption key will stay in RAM or CPU and will be therefore be extractable using boot attacks. I read somewhere that encryption in case of Linux and LUKS is handled by virtual memory which is handled by the CPU afaik...

I don't really know how disk encryption or system encryption works, when i enter the password during boot process will my system be completely decrypted until i shut the computer down, or is it still in an encrypted state and will the system consistently need the key to work on documents? In the last case it would be logical that the key is often in use of RAM or CPU and will be therefore extractable.

The background behind the question is, that i would like to have a little surveillance system on my PC that will resist boot attacks and DMA attacks. I'd like to record the pictures offline because as we all know an internet connection can suddenly break down.

I am thinking a netbook without pci slots which would make DMA attacks impossible and patching the linux kernel to let CPU handle encrytion plus a sdmem script that overwrites possible remnants of the screenlocker password out of RAM - would this suffice?

Junior J. Garland
  • 677
  • 5
  • 15
  • It depends on what software you're using – Stephane May 06 '15 at 12:22
  • You can also write a script to do stress tests on your machine until you get higher temperatures( lets say 70°C or 80°C) and then you turn off the PC i've read somewhere that whatever is on RAM will decay faster at higher temperatures – Freedo May 06 '15 at 15:52
  • I agree with the answers here suggesting that you don't store the private key needed to decrypt on the system at all, given your use case. Don't use full-disk encryption such as LUKS (or, at least, don't rely on it exclusively, if you're concerned about this attack model); instead use GnuPG or similar. – Charles Duffy May 06 '15 at 17:19
  • BTW, if this is an attack model that worries you, I'd suggest being extremely careful of an attacker using an easier way of reading your system's memory -- FireWire provides direct access to the lower 4GB, for instance. Frankly, an attacker getting in via a software exploit and escalating privileges to read physical memory directly is much more likely than a cold-boot attack. – Charles Duffy May 06 '15 at 17:21
  • [Cold Boot Attacks on Encryption Keys](https://www.usenix.org/event/sec08/tech/full_papers/halderman/halderman.pdf) (pdf) is a good read on this topic. –  May 07 '15 at 00:06

1 Answers1

9

Disk encryption is about keeping data on disk encrypted at all times; writing back the decrypted files onto the disk would incur the risk of leaking that data (if the machine is stolen at that point) and would require re-encrypting it upon shutdown. Note that a typical mechanical hard disk reads and writes data at about 120 MB/s, so a mere 128 GB hard disk would take more than 15 minutes to be decrypted entirely, even assuming that the decryption process is faster than that and that the disk is the bottleneck. You certainly don't wait for 15 minutes when you boot your machine up.

All this implies that decryption occurs on-the-fly, when files are read. A consequence is that decryption occurs as long as the machine is up and running, so the decryption key MUST be somewhere in RAM, and stay there.

Similarly, if you modify some files and want to save them (so as to get the new files back after the next reboot), then the encryption key must necessarily be used.

However, there are (at least) two methods by which you could envision not to keep the key in RAM:

  • You could read and decrypt a complete filesystem into a RAM-based disk. There, decryption could be done once and then the key discarded. Of course, this limits the total filesystem size to what can fit in RAM, e.g. 1 or 2 gigabytes. Moreover, all writes will be discarded (conceptually, one could use asymmetric encryption to save modifications, to be incorporated into the encrypted filesystem upon next boot, but that's likely to be a significant design and development effort).

  • The TRESOR project aims at doing encryption and decryption by keeping the keys in the CPU registers, and not allowing these registers to be flushed to RAM. This is for defence against cold boot attacks, in which attackers can take a good view at the whole RAM contents but not at the CPU registers as they were prior to the attack. It has been noted that attackers that can do DMA can inject malicious code that extracts the keys from the registers, so the protection cannot be considered as complete in that case.

An important point to consider is that you use disk encryption to keep the confidentiality of your data -- but when you access your data, you still pull it into RAM in order to process it. For instance, if you look at the contents of some text document, then, when you look at it, the document data necessarily exists unencrypted in the viewer application space, and the graphic card memory as well. Protecting the encryption key is all fine, but if the attacker is assumed to be able to read your RAM then he may plunder the data directly. Therefore, concentrating on the whereabouts of the encryption key without addressing the larger picture of the data kind of misses the point. In most practical contexts, it does not make a lot of sense to worry about cold boot attacks retrieving the disk encryption key -- even with all the TRESORs in the world, cold boot attacks would still be almost as worrisome.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • The method you are stating usinf a RAM-based disk sounds very interesting. My computer has 8 gigabytes of RAM and would need only need 2,48 for my surveillance machine to work properly. So i could use the rest of the RAM as disk space? Is there a tutorial somewhere on how to implement this method? – Junior J. Garland May 06 '15 at 13:21
  • Another option is to keep the key in a TPM device rather than the RAM. Currently most software copies it to ram however I don't see why a disk driver couldn't be created to pull the key post TPM unlock and not copy it to ram. – Jim B May 06 '15 at 15:18
  • A TPM is basically a smart card -- usually the same hardware, and, crucially, the same performance. You won't do bulk encryption with a TPM. What you _can_ do is to store an RSA key pair in the TPM, and keep the actual disk encryption key encrypted with that RSA key. However, whenever the OS must read or write files (i.e. just about all the time), it will need the disk encryption key somewhere in its RAM. – Thomas Pornin May 06 '15 at 15:29
  • 1
    I guess you are looking at the wrong way...instead of trying to do everything to not store the key somewhere why not keep your laptop secure? Only with psychical access this is possible...are you worried if someone break in your house and steal your laptop? If yes, why not justing powering it off would not be enough? IF you do walk on streets with your laptop why not powering it down 10 minutes before you go to street not enough?If you use it on public places(very bad idea) you need a software script or however that can quickly turn OFF your pc after doing a stress test to increase temperature – Freedo May 06 '15 at 16:03
  • @JuniorJ.Garland but then the unencrypted disk contents are in RAM, and the attacker doesn't need to steal the key. – OrangeDog May 06 '15 at 16:09