29

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?

  • 4
    Possibly, unless you overwrite the entire disk with random data. – AndrolGenhald Nov 10 '17 at 16:15
  • Possibly how? Assume the entire disk has not been overwritten with random data. – Total Fde Nov 10 '17 at 16:21
  • 6
    By outward appearances any properly implemented crypto scheme will be seemingly random data that can't be reversed without the encryption key. So essentially "Possibly, unless you overwrite the entire disk with random data." could be re-written as "No, unless you do encryption wrong." – Adonalsium Nov 10 '17 at 16:21
  • 6
    @Fistbeard The file was not encrypted originally. I've never used Veracrypt, but with LUKS you'll be creating a new filesystem on top of the encrypted device, however the existing data won't be overwritten (except in a few spots like the LUKS header and the new filesystem data). – AndrolGenhald Nov 10 '17 at 16:49
  • 8
    This is the kind of thing that ends up in news articles talking about how the criminal was looking for ways to cover their tracks prior to committing the crime. – Engineer Toast Nov 10 '17 at 21:27
45

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.

  • 14
    Conclusion : you don't do a full disk encryption. – Whysmerhill Nov 10 '17 at 18:44
  • 4
    @Whysmerhill Why you don't think this is full disk encryption? This is quite standard. – AndrolGenhald Nov 10 '17 at 18:46
  • 6
    This answers assumes that encryption software does not wipe the disk. The one I'm most familiar with, Truecrypt/Veracrypt, does offer to wipe the disk on creation of the encrypted volume. – Martin Argerami Nov 11 '17 at 3:19
  • 9
    @MartinArgerami The question asks about full disk encryption in general. Veracrypt may have the option to wipe the disk, but it can still be used without that option, and LUKS has no such option. – AndrolGenhald Nov 11 '17 at 3:25
  • 3
    @Whysmerhill : You have conflated "deleted files" with "whatever data happened to be on the disk prior to establishing an encrypted filesystem on it". FDE does not change the contents of a block on the disk until writing new, encrypted data to that block. Until overwriting writes occur, those blocks still contain whatever was last written to them via the unencrypted filesystem. – Eric Towers Nov 12 '17 at 1:34
26

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.

  • 3
    So the "depending on whether or not it was overwritten by later writes" with lazy encryption is just the same situation as with the disk left unencrypted – Hagen von Eitzen Nov 10 '17 at 22:03
  • Even if you encrypt the entire disk, it may still be possible to recover it using magnetic traces (assuming a magentic drive), correct? – Nathan Merrill Nov 10 '17 at 23:05
  • 5
    @NathanMerrill, not if the drive was manufactured any time in the past quarter-century or so. Reading residual magnetic traces stopped being viable sometime in the mid-1980s. – Mark Nov 10 '17 at 23:30
9

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.

  • 3
    Not just temp files; the contents could be in a page file, too. – David Ehrmann Nov 11 '17 at 6:36
  • 2
    Note however that some modern disks implement the ATA Secure Erase standard, and can (assuming the manufacturer implemented it correctly) securely wipe all data from a disk, including anti-wear-levelling sectors. – James_pic Nov 13 '17 at 12:45
  • @James_pic True, but I don't think it is done by default by FDE-software. As far as I can remember, it requires specialized tools from the drive manefacturer. – H. Idden Nov 13 '17 at 20:15
  • It doesn't require specialised tools from the drive manufacturer. It uses standard ATA commands, and can be done using hdparm on Linux. There is no technical reason why FDE software cannot support it. – James_pic Nov 15 '17 at 11:17
  • good to know that it got standardized. I just remembered that every manufacturer distributed their own tool for this task. – H. Idden Nov 15 '17 at 21:09
1

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.

  • I don't think you can make a blanket statement like that, since different tools offer to encrypt the blank space, or not. As we all learned in just the answers above. – YetAnotherRandomUser Nov 12 '17 at 14:12
  • 1
    "Blank space encryption" would typically refer to software that encrypts at the block level rather than the file level, and encrypts both used and unused blocks during use. This does not mean that the entire disk is overwritten during initial setup, and I cannot think of any encryption algorithm/protocol/standard/system that would involve overwriting the entire disk as part of the setup process. It's possible that some software offers this as an additional feature but that doesn't mean that "full disk encryption" involves overwriting the entire disk. – Micheal Johnson Nov 12 '17 at 15:12
0

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.

0

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.

-1

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.

  • 1
    Data remnance on magnetic media hasn't been an issue for about a quarter-century. These days, a single zero-wipe pass is enough to render the data unrecoverable even by magnetic-force microscopy. – Mark Nov 13 '17 at 9:58
  • @Mark - Quarter century? Sounds about when I last looked at it. Thanks for the note. – jleach Nov 13 '17 at 10:15
-3

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.

  • 4
    As specified in the question, the data was originally stored in the clear, and none of the subsequent steps is guaranteed to erase it. The use of encryption is irrelevant in this situation. – Mark Nov 10 '17 at 23:27
-4

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.

  • Moving data around may overwrite the secret file information… or not, using instead a different free spot. – Ángel Nov 11 '17 at 23:55
  • 1
    This runs contrary to most information I've come across. Can you elaborate and cite your sources, methods, etc? – YetAnotherRandomUser Nov 12 '17 at 14:11
  • 2
    @YetAnotherRandomUser The described actions might overwrite the file. Or Not. The answer assumes that the deleted file is the only free space on the drive. If there is more free space, some algorithm chooses which free space to use and which not. Doing the described actions just increases the chances to overwrite it, so you should avoid them if you want to recover the file to increase your chances to recover it. But doing them is not enough to make sure they are overwritten. Or just look at my answer for another example security.stackexchange.com/a/173241/94428 – H. Idden Nov 12 '17 at 15:32
  • You're trying to give honor to your user name, don't you? Very silly approach. – Thomas Weller Nov 12 '17 at 21:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.