With data breach announcements occurring on an almost weekly basis, the issue of encryption has moved to the top of the security agenda. In the past, Full Disk Encryption (FDE), software that encrypts the entire drive sector by sector, has been regarded as the main software approach for protecting data on hard drives. It was seen as the logical answer for organisations to encrypt the entire hard drive and never worry about it again.
Why would a CIO want to be concerned with whether or not they want a file encrypted every time they save it? While points such as this are often used to proclaim FDE as the Holy Grail of data security, here we de-bunk some ‘myths’ on the full disk approach and consider the alternative of full data encryption, software that encrypts all data files while leaving program and operating system (OS) files untouched, rather than encrypting the entire hard drive:
Myth # 1
Full Disk Encryption creates fewer issues for the help-desk
The common perception is that, whilst Full Disk Encryption may be difficult to deploy the trade-off is that it is easier to manage than other methods of encryption. This, however, is not the case. For example, one of the most common help desk requests from users is re-setting forgotten passwords. Most encryption products mandate the use of a custom procedure, which requires a long, and error prone, response procedure and requires additional training for both end user and help desk personnel.
Furthermore, setting up an FDE solution also requires the user to define several passwords or tokens and they might have to create their own user management system in case they are sharing the computer with other users. This means having to create an emergency boot CD, in case something goes wrong and the user will be required to install a new boot loader. There are now full data encryption products available on the market which circumvent these issues and which come with management and device control as well as encrypting sensitive data stored on the endpoint.
Myth # 2
Windows has many vulnerabilities; the Operating System used for FDE Pre-Boot Authentication does not
A system relying on security by obscurity is never a good measure. A considerable amount of work around Windows, and Rainbow Tables, a lookup table offering a time-memory tradeoff used in recovering the plaintext password from a password hash, have been published for old Win2000 local password file encryption methods. Win2000 used to store hashes of the user’s password in 7 character chunks. Rainbow tables are a brute force attack on those hashes as they contain all possible permutation results. However, no such exploits exist for the latest Microsoft authentication methods, despite constant attempts in the past five years. Windows 2003 and 2008 allow longer passwords, do not break the password down into 7 character chunks and in addition, SALT (a random string of data used to modify a password hash). The combination of those measures has been publicly proven to make brute force attacks on windows passwords infeasible. There is little to none public work around vulnerabilities and zero day attacks in PBA operating systems, so we can’t really tell how secure they are.
Myth # 3
Pre-Boot Authentication is more secure than Windows-domain authentication
Previously, Windows authentication enabled local users to authenticate to the machine, and provided an easy way to reset the local administrator password so that any attacker could gain access to the machine within a reasonable time.
However, Microsoft has greatly improved the authentication mechanism in newer versions of XP, and the latest operating systems, so that only domain-authenticated users are allowed in. A centrally managed directory service based authentication system is both more secure and more usable than a local authentication-only system such as PBA.
The ability for a central administrator to add users seamlessly means that passwords are not likely to be shared. Easy central revocation means that users who leave the organisation will not be able to access organisational data after they have left.
Myth # 4
FDE methods are more secure for administration and updates
It is generally perceived that PBA based encryption is secure from a management perspective and it is true to say that FDE products have a very secure method of authenticating the end user – requiring a local user password interaction that is done outside Windows.
However, this interaction is not part of the Windows OS and cannot be done remotely. Therefore, if an IT organisation wants to deploy a new piece of software that requires restarts, it has to completely disable all security measures on all FDE protected machines for the duration of the update. If some machines are not available during the update window, then the update window will need to be reapplied. This can potentially cost an organisation’s IT department valuable time and money. Although the administrator cannot reboot a machine remotely to install software or apply patches, special back doors exist in the software that enable an administrator to reboot remotely at certain times of day, or even indefinitely in some cases. This opens up new vulnerabilities that will not be exposed with a system that encrypts all data, but allows the administrator to Login.
Myth # 5
PBA-based FDE is more ‘user-friendly'
The reality is that PBA-based FDE is anything but easy on the end user; they need to learn a new login screen, and, as outlined above, it presents a cumbersome way to recover access to the computer, should the user forget their password.
All these issues mean the end user is likely to associate any problems they encounter as being encryption-related. In contrast, a ‘silent‘ deployment for a system that encrypts all data but does not change the end user experience will be a lot easier on both the end user and the help desk.
