Recover deleted file despite full disk encryption

Question

This might be a stupid question, but I'll go ahead and ask it anyway.

Say I am on Windows and I create a file, secret_financial_plan.txt, where I store all my company's black market financial operations. Once my operations are all finished, I delete the file and empty the recycle bin to cover my tracks.

A few days later I realize "permanently" deleted files in Windows are fairly easily recoverable. So, I decide to apply full disk encryption (FDE) on my device by switching over to Linux and using LUKS or by encrypting the drive in Windows with Veracrypt or by using some other piece of FDE-software. Would it be possible for a forensics expert, who does NOT have access to the decryption key, to recover the secret_financial_plan.txt file after having applied FDE, or not?

Answer 1

In addition to Moshe's answer, I'm going to provide an example with LUKS since some people seem unconvinced. Also, see here for why overwriting may not be 100% effective (although it certainly helps).

Example

Make a sparse file, create a filesystem, and mount it:

$ truncate -s 100G /tmp/device
$ mkfs.ext4 /tmp/device
$ sudo mount /tmp/device /mnt
$ sudo chown user:user -R /mnt

Make a few confidential files:

$ echo "super secret data" > /mnt/secret
$ echo "super secret data" > /mnt/confidential
$ echo "super secret data" > /mnt/top-secret

Get inodes for files:

$ ls -li /mnt
total 28
13 -rw-rw-r-- 1 user user    18 Nov 10 11:34 confidential
11 drwx------ 2 user user 16384 Nov 10 11:33 lost+found
12 -rw-rw-r-- 1 user user    18 Nov 10 11:34 secret
14 -rw-rw-r-- 1 user user    18 Nov 10 11:34 top-secret

Ensure files are written to disk, then get extents for inodes:

$ sync /mnt/*
$ debugfs -R "stat <12>" /tmp/device
...
EXTENTS:
(0):33793
$ debugfs -R "stat <13>" /tmp/device
...
EXTENTS:
(0):33794
$ debugfs -R "stat <14>" /tmp/device
...
EXTENTS:
(0):33795

Check those blocks to make sure the data is there:

$ dd if=/tmp/device bs=4096 skip=33793 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 1.9034e-05 s, 215 MB/s
$ dd if=/tmp/device bs=4096 skip=33794 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 1.888e-05 s, 217 MB/s
$ dd if=/tmp/device bs=4096 skip=33795 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 7.1178e-05 s, 57.5 MB/s

Remove the files:

$ rm /mnt/secret
$ rm /mnt/confidential
$ rm /mnt/top-secret
$ ls -l /mnt
total 16
drwx------ 2 user user 16384 Nov 12 17:34 lost+found

Format the device using LUKS, then create a new filesystem:

$ sudo umount /mnt
$ sudo cryptsetup luksFormat /tmp/device

WARNING!
========
This will overwrite data on /tmp/device irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:

$ sudo cryptsetup luksOpen /tmp/device encrypted_device
Enter passphrase for /tmp/device:

$ sudo mkfs.ext4 /dev/mapper/encrypted_device
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 26213888 4k blocks and 6553600 inodes
Filesystem UUID: 279e6c3b-a183-4a94-b06e-78db1665b2a0
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

Now we have a new filesystem:

$ sudo mount /dev/mapper/encrypted_device /mnt
$ sudo ls -lR /mnt
/mnt:
total 16
drwx------ 2 root root 16384 Nov 10 11:37 lost+found

/mnt/lost+found:
total 0

But is our secret data still there?

$ dd if=/tmp/device bs=4096 skip=33793 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 1.8944e-05 s, 216 MB/s
$ dd if=/tmp/device bs=4096 skip=33794 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 2.2056e-05 s, 186 MB/s
$ dd if=/tmp/device bs=4096 skip=33795 count=1
super secret data
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 8.7082e-05 s, 47.0 MB/s

Conclusion

Unless you wipe the disk, it's probable that at least some of the old data remains there unencrypted.

Answer 2

It comes down to the following question: Are the plaintext bytes of secret_financial_plan.txt's contents still stored on the disk?

Let's go through the steps:

I create a file, secret_financial_plan.txt, where I store all my company's black market financial operations

Plaintext is written to the disk

I delete the file and empty the recycle bin to cover my tracks.

File is renamed and then the entry from the NTFS Master File Table is marked as deleted. The plaintext is still on the disk.

I decide to apply full disk encryption (FDE) on my device by switching over to Linux and using LUKS or by encrypting the drive in Windows with Veracrypt or by using some other piece of FDE-software

There are different configuration options there. If you specified to encrypt the entire disk, including unallocated space, the plaintext bytes will be overwritten with the encrypted data. If you only encrypt the allocated space, the deleted file will not be overwritten* and so the plaintext might still be present, depending on whether or not it was overwritten by later writes to the disk.

_{* Note: These are the choices Bitlocker provides. I do not know how the other FDE tools operate.}

Answer 3

Short answer: You cannot be 100% sure that all traces are removed even if you overwrite the whole disk

Modern hard disks typically have more sectors than those that are displayed, especially SSDs for anti-wear-levelling reasons. Depending on the algorithm in the disk controller, it might decide that sector with the data of secret_financial_plan.txt will become a spare one and the data will be written to a previous spare sector.

Next point to take care of: copies might have been written to other location like temp files.

Next point: lets hope that it didn't get uploaded into the cloud. Else your boss might get a call from his boss from the NSA that Isreal secret service reported them that they secretely hacked and watched a Russian antivirus vendor getting your super new secret spy virus uploaded through their cloud scanning technology because you used an virus infected crack for your pirated office suite.

Answer 4

It is possible to recover the files after converting to FDE, but not guaranteed. The key thing is that FDE only provides protection after it is turned on. It doesn't protect anything before then. If the blocks on the drive were not overwritten (cryptographically) when converting to FDE then they are still there and can be recovered. It is possible to wipe the drive before converting to FDE, but then it is the wipe that is making the previous data unaccessible, not the FDE. And even then it is difficult to wipe a drive properly.

Answer 5

Full disk encryption does not equate to overwriting the entire disk. Any data that wasn't wiped from the disk before encrypting will still be on the disk after it's encrypted. Think of setting up full disk encryption like formatting a disk: you write a few new blocks of data here and there but most of the disk remains untouched.

Answer 6

The up-voted answers are all incomplete. The key question is if you encrypted the entire disk or if you just encrypted the parts that are in use.

When enabling full disk encryption you have a choice. You can encrypt just the parts of the disk that are in use by the filesystem. In that case, parts that are unused might contain deleted data and it will remain recoverable. This also leaks other information, such as approximately how much data the filesystem contains.

The other option is to encrypt even the free space, in which case even deleted files will not be recoverable.

Veracrypt/Truecrypt prompts you with this question when enabling FDE.

Answer 7

I'm no expert, but my conclusion as an area of interest many years ago (before the SSD days) was that you cannot completely erase evidence of files on disk without destroying the disk itself.

Encrypting the desk after having deleted the file is a good step, but it may still be possible to recover the file, or parts of it, given sufficient tooling.

Consider a HDD which stores data as magnetic bit fields, on or off. Let's say that piece of data is stored on that disk for some time, and then you come along and do (whatever) to your OS and encrypt everything and overwrite the disk 7 times with random data. Great, right? Except that it still may be possible to read the previous information from the disk, because at least on an HDD, if the data sits in place for long enough, the wear residue of the physical magnetic bits on the disk platter itself can still be read with highly advanced tooling.

Easy? no. Possible? yes.

As with all things digital security related, I think it boils down to: how much effort do you think someone might put into trying to breach youre defenses (naturally balanced with how strong should your defenses be to thwart this)? As with all things security related, the only way to ensure it will never, ever be breached is to make sure it never existed all. My 2cents.

Answer 8

There are a whole bunch of theoretical attacks against whole disk encryption, but to my knowledge every single one of them involves capturing the encryption key when it is used, or exploiting a flaw in a specific encryption implementation. You explicitly specify that the attacker does not have your encryption key, so they will not be able to decrypt your data without another type of attack.

Answer 9

In windows, all you have to do is delete the file, then move data around using defrag or adding new files onto the drive.

Everytime you write data it sees the free space and overwrites it. Alternatively, encrypt the drive BEFORE putting data on it, then do as you please?

Hope this helps.