We have two types of encryption here, "file based encryption" and "full disk encryption". There are documented forensics methods and software (e.g. EnCase) that help us detect the schemes and programs used to encrypt the disk.
I'm going to take a list of popular tools and standards and see if they leave any traces with which we can determine that they've been used:
Bitlocker is a full disk encryption standard available on windows operating system from Windows 7 onwards; this tool uses AES256 to encrypt the disk. A disk encrypted by bitlocker is different than a normal NTFS disk. The signature of "-FVE-FS-" can be found at the beginning of bitlocker encrypted volumes.
These volumes can also be identified by a GUID:
- for BitLocker: 4967d63b-2e29-4ad8-8399-f6a339e3d00
- for BitLocker ToGo: 4967d63b-2e29-4ad8-8399-f6a339e3d01
DiskCryptor is based on TrueCrypt. For both DiskCryptor and TrueCrypt we can detect their presence with the following criteria:
- size of file or collection of clusters object is a multiple of 512,
- minimum size of object is 19KB, although by default is minimum 5MB,
- contains no specific file signature throughout the entire object, and
- has a high Shannon entropy or passes Chi-squared distribution test.
Note that since there's no specific signature or header left behind we can't tell for sure if TrueCrypt (or its siblings) were used, by combination of several methods we can try to make better guess about its presence.
Filevault is Bitlocker's equivalent on Mac and offers full disk encryption. The signature of "encrdsa" or hex value of "65 6E 63 72 63 64 73 61" can be found at the beginning of FileVault encrypted volumes.
- cryptsetup with LUKS
Linux Unified Key Setup is a disk encryption specification and can be used in cryptsetup on Linux which is a common tool for storage media volumes encryption. It is optional and users can choose not to use this format but if used we can detect its presence with "LUKS\xba\xbe" signature at the beginning of the volumes.
- Check Point Full Disk Encryption
At sector offset 90 of the VBR, the product identifier "Protect" can be found. Hex value "50 72 6F 74 65 63 74"
- GuardianEdge Encryption Plus/Anywhere/Hard Disk Encryption and Symantec Endpoint Encryption
At sector offset 6 MBR, the product identifier "PCGM" can be found. Hex value "50 43 47 4D"
- McAfee Safeboot/Endpoint Encryption
At sector offset 3 MBR, the product identifier "Safeboot" can be found. Hex value "53 61 66 65 42 6F 6F 74"
- Sophos Safeguard Enterprise and Safeguard Easy
For Safeguard Enterprise, at sector offset 119 of the MBR, the product identifier "SGM400" can be found. Hex value "53 47 4D 34 30 30 3A"
- Symantec PGP Whole disk Encryption
At sector offset 3 MBR, the product identifier "ëH|PGPGUARD" can be found. Hex value "EB 48 90 50 47 50 47 55 41 52 44"
Measuring File Randomness To Detect Encryption
Methods discussed earlier may not be feasible for every disk/file encryption scheme since not all of them have specific properties that we can exploit to detect them. One other method is to measure the randomness of files and the closer they are to random, the more certain we are that encryption is used.
To do this we can use a Python script named file_entropy.py. The closer the entropy value is to 8.0, the higher the entropy.
We can extend this further and draw plots to visualize the distribution of bytes. (calculate-file-entropy)
One other pointer to detect encryption is that no known file signature will be spotted in the volume. (No jpg, no office documents, no known file types) And since compression methods (e.g. gzip, rar and zip) have known signatures we can differentiate them from encryption for the most part.
- Use known signatures to detect encryption (if possible)
- Use special characteristics (minimum file size, high entropy, absence of any special file signature, etc.) to detect encryption
- Rule out compressed files using their signature
So going back to the main question, "Is it that easy to tell?", this falls under forensics methods, we may be dealing with steganography techniques. In a normal case where user isn't trying to fool us, it is somehow easy to tell encryption is in place but in real world scenarios where user's may try to hide things and deceive us they may just pipe /dev/urandom to a file! It's not gonna be easy.