Can you run Side-Channel-Attacks against a PC which was found properly shutdown and powered off?

The attacker knows the cryto-tools used to encrypt the data. The attacker has full and unlimited physical access to the whole system. The system is not infected with any malware. The user who knows the passwords will not interact with this system anymore. The system is working perfectly fine - except the wanted data is encrypted and the password is unknown.

Considering the System (Laptop or Desktop) using 2 Harddrives.

  • HDD#1: using LUKS encrypted filesystem
  • HDD#2: using Truecrypt AES-256 encrypted container-file on non-encrypted filesystem

So for example can the attacker replace the harddrive, boot the system then use the same crypto tools again to encrypt some data with a known password while observing the side-channels and then use this information to break the other encryption? Are there other ways to still break it regarding side-channels or else?

2 Answers 2


No. A side channel attack is one that monitors a cryptographic process while it's operating, and uses leaked information to determine the secrets. Examples include: monitoring the CPU for RF emissions while it is encrypting, monitoring the power consumption of the CPU while it is encrypting, monitoring the time it takes to encrypt, monitoring the noise the CPU makes while it is encrypting. In every case, the encryption it is monitoring is already legitimately in possession of the key.

A powered off system that does not have the key will never perform a legitimate encryption/decryption operation. Therefore it has no attack surface for a side channel attack.

It is still susceptible to other attacks such as password guessing, forensically examining the swap file to see if the legitimate password was ever stored in memory that was swapped out, or threatening the former keyholder until he reveals the key. Just not side channel attacks.


A comment below asks if the attacker could extract the password from components.

Generally the key bits won't remain in dynamic electronic components for very long (exclusive of freezing the DRAM chips as @TomLeek points out.) Components such as bus latches, network adapters, etc., won't typically ever house the key, and even if they did, their memory buffers are generally very short, dynamic, and designed only for transient data.

Some people have theorized that a key stored for an extended duration in the same physical cells of RAM might cause a "burn-in" effect such that the memory cells could be differentiated with some specialized equipment or software. The theory is that if you knew which cells held the key bits, you could determine how long they can hold a charge before requiring refresh. The idea is that a bit that held a 1 might decay from a 1 state slower than from a 0 state. Such attacks have been demonstrated in a laboratory environment, and who knows, perhaps a government may be able to use them in a high profile spy case, but are not within the capabilities of an ordinary police investigation. Criminal organizations are not yet known to have these capabilities.

PGP Desktop marketing calls this effect "static ion migration" and attempts to mitigate this avenue of attack by keeping two copies of the key, and periodically inverting the key bits of each. (Ironically, it turns out to be a blessing for side channel attacks, as a RAM scraper can efficiently look for memory that is the bit inverse of another area of memory.)

See this paper, RAM is KEY for more on finding keys in volatile memory.

If the key was ever stored to permanent storage, such as HDD, flash, or CMOS, though, recovery becomes possible. The application has to keep track of every place it might have been written, and overwrite it. That's almost impossible with flash memory, because the wear leveling algorithms continually move where data is stored.

  • Thanks for the bit on swap space, that lead me to this post on how to clear swap when shutting down. Very interesting topic. security.stackexchange.com/questions/29350/… Feb 7, 2014 at 19:59
  • Could the attacker 'extract' the password somehow either from PC components or from the LUKS encrypted HDD like it can be done at non-temper-resistant chips? Feb 12, 2014 at 20:37

Side-channel attacks exploit leakage of secret information through non-obvious physical mechanisms. This can happen only if there is, within the running system, some secret information; and it can happen only when the system is actually running. In your scenario, the password and the key derived from the password are no longer in the system (they were in RAM, but this disappeared when the system was shut down) so there is no secret to leak anymore. Basically, there cannot be a leak if there is nothing to leak.

Now there can be details...

What was in RAM at some point can still linger around for some time. That's the principle of cold boot attacks. The time window is very narrow, but not so narrow that it cannot be demonstrated in lab condition. Namely, if the PC was shut down less than one minute ago, then an attacker can reapply power to the RAM chips and the data will still be there, mostly undamaged.

A more plausible scenario involves virtual memory, aka "swap space", as pointed out by @John. What an application sees as "RAM" can be transparently copied to the disk by the operating system, so that applications may use more RAM than is physically present in the machine. That way, secret values may leak to the disk, and still be there in an "off" machine. In this case, you may claim that it is a "side-channel attack" where the attack was actually enacted by the OS itself at the time the password was processed. Good crypto-aware systems use the mlock() system call (or its equivalent in the local OS) to instruct the OS not to do that. For an hard disk encryption system where the encryption actually happens within the kernel space, virtual memory is unlikely to be an issue.

(Arguably, given the RAM size in today's computers, and given the trend for using programming languages which don't interact well with the virtual memory heuristics, in particular GC-based languages like Java, C#, Javascript or Python, a case can be made that not using swap space at all could be a nice idea, and that has benefits for security in general.)


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .