Attacking Encryption vs. Memory: A Practical Guide

TL;DR

Attacking encrypted storage (like a hard drive) is generally slower and harder than attacking data in memory (RAM). Encrypted storage requires breaking the encryption, which takes time and resources. Attacking memory means finding sensitive information that’s already unencrypted or decrypting it quickly while it’s being used. This guide explains how these attacks differ and what you can do to protect yourself.

1. Understanding the Difference

Think of it like this:

• Encrypted Storage: A locked safe. You need the key (encryption key) to get inside.
• Memory: Your desk while you’re working. Papers are out in the open, and someone could read them if they have access.

Attacking encrypted storage is about finding or cracking that key. Attacking memory is about looking for information directly.

2. Attacking Encrypted Storage

1. Full Disk Encryption (FDE): This protects the entire drive. Attacks involve:
   • Brute-force attacks: Trying every possible key combination – very slow without weaknesses in the encryption.
   • Keylogging: Recording keystrokes to steal passwords used for decryption.
   • Exploiting vulnerabilities: Finding flaws in the encryption software itself (rare but serious).
   • Offline attacks: Gaining physical access to the drive and attempting to crack it.
2. File-level Encryption: Only specific files are encrypted. Attacks focus on those files:
   • Targeted keylogging: Stealing passwords for specific encrypted files.
   • Exploiting vulnerabilities in the encryption application.

Cracking strong encryption (like AES-256) is computationally expensive and often impractical without significant resources.

3. Attacking Memory

1. Cold Boot Attacks: When a computer shuts down, RAM retains data for a short time. Attackers can quickly reboot the system from a USB drive to dump the contents of memory before it’s lost.
   • Tools: Tools like Memory Forensics can be used to analyse dumped memory images.
2. Process Memory Dumps: Attackers can access the memory of running processes.
   • Tools: Debuggers (like OllyDbg or x64dbg) allow you to inspect process memory.
   • Example (using a debugger): You might find sensitive data like passwords, API keys, or encryption keys stored in plain text within a running application’s memory space.
3. Kernel Memory Dumps: Accessing the core operating system’s memory can reveal even more secrets.
   • Requires higher privileges: Usually requires administrator or root access.
4. Side-Channel Attacks (e.g., Spectre, Meltdown): These exploit hardware vulnerabilities to leak data from memory indirectly.
   • Complex and require specialized knowledge.

Attacking memory is often faster because the data may already be unencrypted or easier to decrypt than a whole disk.

4. Protecting Yourself: Encryption

1. Use Strong Encryption: AES-256 is widely considered secure.
2. Strong Passwords/Passphrases: Essential for protecting encryption keys. Use a password manager.
3. Keep Software Updated: Patches often fix security vulnerabilities in encryption software.
4. Full Disk Encryption (FDE): Protects all data on your drive, even if it’s stolen. BitLocker (Windows), FileVault (macOS), and LUKS (Linux) are good options.

5. Protecting Yourself: Memory

1. Enable Full Disk Encryption: Even if memory is compromised, the data on disk remains protected.
2. Use Secure Boot: Prevents attackers from loading malicious code during startup (helps against cold boot attacks).
3. Reduce Attack Surface: Minimize the number of running processes and applications.
4. Memory Protection Features: Enable features like Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR).
   • Example (Linux): Check ASLR status with

     cat /proc/sys/kernel/randomize_va_space

     . A value of ‘2’ is generally considered secure.

5. Regularly Clear Sensitive Data: Overwrite memory when no longer needed (difficult to guarantee complete removal).
6. Virtualization and Sandboxing: Run sensitive applications in isolated environments.