It is considered an essential security measure, where personal data is stored on a portable device or transmitted over a public network. As with passwords, this measure is pointless unless the key to decrypt the data is kept secure.
Irish Office of the Data Protection Commissioner on encryption
Many large organisations have copious amounts of sensitive data stored on employee laptops and other portable storage devices. Most encryption applications are trouble-free. However, there are circumstances when the encryption application itself will go corrupt or the disk will fail. If the user has no backup and the data is of importance – data recovery will often be needed.
Since NTFS 3.1 (which was introduced at the same time as the Windows XP operating system) the only native encryption option that Microsoft has offered has been EFS (encrypted file system). The major problem with EFS is that the key is stored in the user's profile and is used as their logon password and passphrase. This means that an intruder can crack the SAM (quite easily), obtain the password and decrypt the files.
By the time Microsoft was developing their Vista operating system, there was an impetus from corporate and governmental customers that they should offer a native encryption feature for their Enterprise and Ultimate editions, which was a little more robust than EFS. Enter Bitlocker – Microsoft's replacement for EFS. Its default encryption algorithm is 128-Bit AES CBC (Cipher Block Chaining) with an additional diffuser.
A Full Volume Encryption Key (FVEK) is used to protect the data. Furthermore, this key itself is encrypted using another key called the Volume Master Key (VMK). Several copies of this can be stored on the protected volume.
The Bitlocker Encryption Process
Encrypted FVEK key, as seen in binary format
The default implementation of Bitlocker is AES 128-bit with diffuser.
However, there are several other (more secure) variations which can be deployed as illustrated by the table below.
Different implementations of Bitlocker
Data recovery is possible from a Bitlocker encrypted disk by using a valid encryption key.
There are a number of identifiers which indicate to the data recovery technician that Bitlocker encryption has been enabled.
The Bitlocker volume will always start with "-FVE-FS-" instead of the NTFS signature at the start of the volume.
The Logical Cluster Number of the Master File Table is normally stored at the offset "0x38".
The volume header will always point to a block of Bitlocker metadata.
Microsoft introduced a feature known as Bitlocker to Go on their Window 7 operating system.
The developers of Bitlocker have (rather thoughtfully) included three identical metadata blocks for redundancy. This means that if one or two metadata blocks get damaged due to, for instance, file system corruption or bad sectors, there should be at least one more metadata block that can be used for data recovery.
To find these blocks, the data recovery technician must search the volume for the signature "-FVE-FS-". At offset "0x50", you can find the volume’s Global Unique Identifier. At offset 0x60, you can find the counter value for key encryption nonces. This can be a useful signature for figuring out how many access devices have been created for a volume.
One of our clients, a user from an Irish Government department, had a Bitlocker-protected disk from a Lenovo laptop. The volume became inaccessible. Their I.T. department removed the 500GB HGST disk from the laptop and attached it to another Windows 7 Entreprise system with an onboard TPM chip. The disk would not mount and was "invisible" to the system.
The data was of critical importance and of a confidential nature. Due to confidentiality concerns, the user was not backing up to the department's server.
We examined the drive and by using specialised tools our technicians accessed the Host Protected Area of the HGST disk. The G-List and Translator tables were all corrupt. Using our equipment, which can access the HPA directly, our technicians repaired the corrupt firmware.
This made the drive bootable again. This time, when connected to one of our recovery systems, a Bitlocker volume could now be mounted. A promising sign! The client emailed us their 48 digit Bitlocker key and after having been inputted, the volume's partitions appeared. We invited the client to login to our systems remotely to view and verify their data.
All of their files were present on the volume – intact. Even though their drive was bootable again, we extracted a copy of the data onto a USB external drive as a precaution.
FileVault 1 was introduced with Mac OS X Panther (10.3). This application used AES with CBC chaining. However, there were a number of problems with its implementation. Firstly, FileVault 1 only encrypted the user's Home Folder. Any folders outside this remained unprotected. Another issue that users experienced with FileVault 1 was its interference with network file sharing and automatic backups, but perhaps one of the application’s greatest weaknesses was its cipher-block chaining (CBC) cipher mode. There were widespread reports that it was being compromised by experienced hackers. Apple would have to do their homework again and find a more robust solution.
This more robust solution arrived in the form of FileVault 2, which was first introduced by Apple in their OS X 10.7 (Lion) operating system.
Like Microsoft's Bitlocker, FileVault uses an AES (Advanced Encryption Standard) encryption algorithm. But, instead of using AES-CBC, it uses AES-XTS and an elephant diffuser.
FileVault 2 encrypts blocks in multiples of 128-bits. The volume master key is stored in what is known as an "encrypted blob". This can only be decrypted using another intermediary key, which is derived from the user password or security token. The intermediary key is called the Key-Encryption-Key (KEK).
When File Vault 2 encryption is applied to a HFS+ volume the now encrypted volume gets renamed CoreStorage.
Data recovery is usually possible for a hard disk which is encrypted with FileVault version 1 or 2.
However, if the disk has impediments to data access, such as physical damage, extensive bad sector or firmware corruption, these must first be resolved using standard data recovery methodology.
When the encrypted disk or volume is accessible again, the file “EncryptedRoot.plist” must be decrypted. Once this has been extracted we can extract the full disk encryption tweak key. We can now use the volume master key and the full disk encryption tweak key with AES-XTS to decrypt the volume.
1) Download the Disk Mount Utility from the Checkpoint website onto a computer which is not encrypted.
2) Now using a USB caddy or using a direct connection to the motherboard attach the encrypted hard disk drive from the failed laptop to your recovery system.
3) Launch the Disk Mount Utility.
4) The utility should now ask for your authentication. Input your passphrase or hexadecimal passkey.
5) Once authentication has been completed, you should how be able to access your files again.
If the above process does not work. It is possible the disk or the encryption program itself is corrupted.
PGP (Pretty Good Privacy) was developed by Phil Zimmermann in 1991. It was one of the world’s first major implementations of public-key cryptography.
PGP whole disk encryption can be configured as:
The most popular implementation of PGP by IT administrators is PGP whole disk encryption. Using PGP WDE, all files get encrypted by default – even temporary files. This removes the administrative onus on the user to continually have to decide which files need protection.
Users who do not require whole disk encryption can choose to have just a portion of their disk encrypted. PGP's Virtual Volume works a lot like the TrueCrypt container – just a small proportion of the hard disk is encrypted. Users however must be disciplined in ensuring that confidential files are saved in the right location.
There are three principle encryption algorithms which can be deployed within PGP:
Disk signature for Symantec PGP :eH|PGPGUARD
PGP AES 256-bit is the most popular encryption standard and offers preboot authentication.
Most installations of PGP WDE are trouble-free. However, some installations will experience issues. These include:
The Master Boot Record can get corrupted.
The error message “Error loading operating system_” is displayed after you have entered the PGP passphrase, which prevents access to the volume.
The PGP decryption process will not complete.
Even after a valid password has been entered at the PGP Bootguard screen, the authentication process refuses you access to the disk.
If you are experiencing these problems, it should still be possible to decrypt your disk in most cases.
The main challenge is usually posed by a damaged MBR or damage to PGP files that need to authenticate the volume. A damaged MBR will hinder operating system repair options. When the files needed to authenticate PGP gets damaged, the user will enter their (correct) passphrase but might still be refused access, as the damaged PGP assumes the authentication information is incorrect. From this juncture, there are still some viable options open to gain access to the data again. For example, the data recovery technician can “force decrypt” the volume using the PGPWDE utility. If this is unsuccessful, it can be often symptomatic of sector damage, media damage or corrupt firmware.
Checkpoint Encryption (formerly PointSec)
Checkpoint’s disk encryption is used by businesses, government bodies and individuals throughout the world to secure confidential data. It works with Windows and Linux systems.
A simplified model of Checkpoint whole disk encryption
Checkpoint FDE (full-disk encryption) can be configured to use four different encryption algorithms: These include:
Disk signature: Protect
AES-256 is probably one of the most popular implementations of Checkpoint full disk encryption.
The second principle way in which a Checkpoint implementation can be differentiated is by its authentication method. These include:
The login screen for Checkpoint Endpoint
Common Checkpoint FDE (Endpoint) error messages include:
“Unable to start encrypting”
“Failed mounting encrypted media”
“Encrypted Media Non Bootable”
“Unexpected problem occurred, FDE_DA_EW needs to close”
If your Checkpoint encrypted disk will not decrypt (using a valid passphrase), you will have to access the disk by using a special mount utility or by trying to repair the disk.
Checkpoint provide their own utility (Dynamic Mount Utility) which will help you access your data when the operating system will not boot properly.
If you still cannot access the data using the Dynamic Mount Utility, it is likely that your disk has physical, electronic, firmware or file system damage. For example, a damaged drive head or corrupt firmware will interrupt or prevent the decryption process. These issues will have to be resolved first.
McAfee Endpoint uses Advanced Encryption Standard block-cipher to encrypt a hard disk.
Pre-boot authentication is used to act as an extension of the BIOS, which helps to protect the operating system from tampering.
Encryption algorithm used:
In order to access the encrypted data, the user must authenticate via the Safeboot file system. Access to the disk is controlled by Safeboot's own filesystem driver.
Authentication by means of:
Should your McAfee Endpoint Safeboot file system become corrupted, McAfee provides a number of methods for data recovery.
However, if your disk or McAfee Endpoint files are corrupt, you might have to use a recovery disk, such as the SafeTech disk, which can be used to force decrypt the damaged volume (assuming you have a valid key).
If your disk has extensive sector damage, PCB, media or firmware issues, these will have to be resolved first.
TrueCrypt is one of the best known open source applications that provides full disk encryption.
The data is stored in a TrueCrypt container. This contains the encrypted data and the volume header. There are three encrypted volume types – a standard volume, a hidden volume and an operating system volume. The purpose of the hidden volume is provide the user with “plausible deniability”. It lets the user disclose the encryption key to a decoy volume while the real data remains secure in the decoy's unused file system area.
TrueCrypt can be configured to use a number of different algorithms including:
Common TrueCrypt error messages
“Incorrect password or not a Truecrypt volume”
fs type, bad
option, bad superblock on /dev/mapper/truecrypt3,
missing codepage or helper program, or other error”
Data recovery from a TrueCrypt volume.
A TrueCrypt volume can become corrupt for a multitude of reasons. These include:
A volume header file has been deleted, overwritten or corrupted.
Physical failure of the disk, e.g. head disk assembly or electronic failure.
Assuming the disk is healthy, there are some viable options which you can use to access a damaged TrueCrypt volume:
You can use a rescue CD with TrueCrypt on it. This would (should) have been created when you or your IT administrator first installed TC.
Use another system with TrueCrypt installed on it. When mounting the volume make sure that “mount without preboot authentication” is enabled.
Burn a new “rescue disk” – you can usually find an .ISO copy of it in the (Windows) operating system directory %ProgramFiles%\TrueCrypt