Is it possible to tell if hard drive is encrypted?

  • Is it possible to tell if a hard drive is encrypted, regardless of what software was used, i.e., Truecrypt / VeraCrypt / Bitlocker for AES-256?

    Just the other day, I thought it could be possible to tell if I scan the drive with "Sector View" to read the data. If the data is filled with randomness then that means that it is encrypted. Is it that easy to tell?

    If you can retrieve readable data without a decryption key then it's not encrypted.

    "If the data is filled with randomness then that means that it is encrypted" Of course... it could just be random data.

    If you can record and compare hard drive activity, between one you know is not and one you suspect to be you would notice that one of them is much less performant on data read and perform a lot of read .. while some hardware are optimized for encryption, most of them suffer a performance loss. And there are volume header or apparent total empty or full or unknown volume type.

    You can trivially prove that it is not possible to tell reliably. Consider any possible method of determining that a hard drive is not encrypted, and some input X for which that method says it is not encrypted. (Some X must exist, or it's the trivial method "everything is encrypted", which is useless. Now, imagine some encryption scheme where X is the ciphertext corresponding to plaintext Y. Clearly, such a scheme can exist for any X and any Y. Thus for this encryption scheme, the method is at least wrong for input X.

    In the vast majority of encryption algorithms, it is very easily to identify the data, because it is in the header. Encryption is not the process of HIDING data, that is called Steganography. So in practice, you just search for key signatures...

    @NPSF3000 if the NSA ever investigates me, I'm going to hide a bunch of hard drives with random data on them around my house, just to mess with their heads.

    Don't laugh, steganographic schemes work, as do CHS based filesystems on raw disks, no partitions, no formal filesystem. Good luck getting squat out of that, especially with raid 2 or 3.

    @mckenzm: Easier than you think... *good* steganography is hard. *Bad* steganography is like any other bad security scheme -- you *feel* secure, but are not.

  • Silverfox

    Silverfox Correct answer

    5 years ago

    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
      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/TrueCrypt/VeraCrypt
      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
      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 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.

    Sum up

    1. Use known signatures to detect encryption (if possible)
    2. Use special characteristics (minimum file size, high entropy, absence of any special file signature, etc.) to detect encryption
    3. 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.

    Is it for certain that we can detect TrueCrypt encryption by following the above criteria or it is just a better guess?

    @user12132 its just a guess as you see this is based on entropy and file size which can possibly overlap with other schemes.

    You don't calculate the entropy of the file. Shannon entropy is defined for probability distributions and not for fixed pieces of data. You assume that the bytes in the file are independently drawn from a probability distribution. You then use the frequency of each possible byte value to approximate this probability distribution. Finally you compute the entropy of this probability distribution.

    @CodesInChaos I'm using the term "entropy of the file" as how random the file is or how random it looks like, seems like I'm misusing the term, right?

    @Silverfox That misuse is common, even among cryptographers. The bigger problem is that you only look at biases in the bytewise histogram and ignore all patterns that extend across multiple bytes. For example you'd give the sequence 0 to 255 repeated a perfect score, despite being a super obvious pattern. In theory there is Kolmogorov complexity which is defined for individual files, but it's *completely* unusable in practice. In practice the best we have are test suites like die harder

    @CodesInChaos I understand the point you're making, I'm gonna need further study in this field but I tried to rephrase my answer to try to address it for now. But apart from the academical terms, does it make a difference here? (measuring simple byte distribution vs true randomness) Because here we are only trying to differentiate between normal and encrypted files.

    You can pass `-c` and `-h` to `cryptsetup` and use it without LUKS. Therefore cryptsetup is not exactly the same as LUKS. here is an example of a question on U&L by someone who uses cryptsetup without LUKS. And yes, cryptsetup without LUKS has no signature (that was OPs problem there)

    So basically, you "detect encryption" by using statistical methods to detect randomness. So if I filled a hard-drive with random garbage, it would be detected as "encrypted" using this method. I think that gives the user a fair repudiation :)

    Wouldn't compressed data also look random?

    @CodesInChaos also, encryption doesn't increase kolomgrov complexity much anyways.

    Re: TrueCrypt/VeraCrypt criteria, are all of those items required to positively identify the presence of TrueCrypt, or just one of them? My brain just got this problem now whenever I see a list I'm not sure if they are "ANDs" or "ORs" between items.

    @Celeritas There's an "And" between them, but let me point out again that since there is no specific header or signature left behind by TrueCrypt, we can't tell for sure that it's being used we can just make a guess, we can rule out normal files and compressed file by their signatures, and then use the criteria above to find TrueCrypt encrypted items. You can read further about trial to detect TrueCrypt here

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM