CSE Laptop Encryption Guide

This document discusses how encryption works once installed and how it affects the use of an encrypted device.  Details presented in the “CSE Laptop Pre-Encryption Guide” have been omitted.  Please read the pre-encryption documentation first.  The first section provides an overview of the two methods of data encryption: disk encryption and content encryption along with some specific notes concerning the impact of encryption.  The second section discusses the use and operation of the SafeBoot content encryption product.  Most systems at this time will utilize that solution.  Any details specific to the other encryption technologies are noted when required.  The final section discusses what to do in the event that the system is no longer accessible because the boot authentication is lost or something else happens to stop the system from booting normally.

Encryption Methods

There are two encryption methods: disk encryption and content encryption.  Each solves a different problem through encrypting restricted data.  This section describes how each method works, how it affects usability, and what protection it provides.

Disk Encryption

Disk encryption provides transparent encryption and decryption on a disk partition or a virtual file system “loopback” device used as a disk partition would be in the operating system.  Transparency come from a kernel level driver (or its equivalent) that handles the task of encryption and decryption on the device block level so the operating system software itself does not have to.  From the operating system software point of view, interacting with the encrypted disk containing a file system works in exactly the same way it does on an unencrypted disk.  All aspects of encryption and decryption are automatic.  Full disk encryption refers to systems where an entire disk partition containing the operating system has been encrypted.  In the full disk encryption scenario the operating system must be boot-strapped into operation so that it can read the partition where it resides.  Partial disk encryption refers to systems where only part of the file system has been encrypted, usually through a virtual “loopback” device.  In this scenario the operating system does not require any additional startup procedure, but it contains software capable of providing transparent encryption and decryption at the point where the encrypted file system is needed.  SafeBoot and BitLocker in Windows provide full disk encryption solutions.  Other operating systems use partial disk encryption technology to provide encryption on only part of the file system, though it has been determined that this type of disk encryption can be used in these cases to satisfy the restricted data encryption requirement if the part of the file system encrypted is where most user data resides.

Disk encryption has little effect on general usability.  When booting a device using full disk encryption, a loader program requires some sort of authentication to enable the operating system to read and write to the disk partition, otherwise the system cannot boot.  SafeBoot for non-Vista Windows systems uses a SafeBoot account with a username and password, which in most cases will be tied to one of the local accounts using Single Sign On (SSO) on the device to allow the initial boot login to automatically log the user into that account.  BitLocker for Windows Vista systems might require a password unless there is a Trusted Platform Module (TPM) available in the BIOS.  BitLocker can be configured to use a USB device as an authentication mechanism, but this is too insecure to meet the requirements.  The BitLocker authentication mechanism will depend on the device hardware configuration.  Partial disk encryption solutions require a password at the point where the operating system tries to use the encrypted device.  The transparent encryption and decryption overhead should be negligible in most cases given the nature of the devices that will require encryption.  Full disk encryption does impact certain actions, such as installing another operating system in a new partition on the device after it is encrypted and booting off of CD live/rescue disks and interacting with the encrypted disk partition.  If this is desired after encryption, please consult with CSE computing staff before attempting any such installation procedures.  Certain types of software that interacts with the Windows login authentication system are not compatible with certain solutions like SafeBoot, such as biometric fingerprint authentication systems which have to be disabled in most instances.  CSE computing staff will address specific cases on an individual basis while performing the encryption procedure.

Disk encryption protects against device theft.  Without the authentication credentials to enable transparent encryption and decryption, the partition data cannot be read.  Disk encryption provides the easiest and most transparent method to protect against data loss due to device theft.  However, it does not protect data from hacking.  Because of the transparency afforded to the operating system software, hacking into a running system allows an attacker to access the encrypted disk with the same freedom as the host operating system.  Physical access to a device left in an open user session also allows access to data in a similar manner.

Content Encryption

Content encryption explicitly encrypts data before it is placed on the file system.  This method of encryption is not transparent in many cases.  Using content encryption involves selecting the data to be encrypted, encrypting the data using a key or passphrase, and storing that data on the file system above the kernel block device level.  It is not possible to interact with this data without first decrypting the content.  There are various tools available that do content encryption, and many of them are free software.

Content encryption provides the best protection.  Accessing encrypted data requires explicit decryption.  This protects data against device theft and operating system hacking, as long as there is not an unencrypted version of the same data present on the device.  Due to the additional protection provided through content encryption, it is best practice to encrypt known restricted data directly using content encryption tools, even if the system is protected by disk encryption.

Content encryption can have direct effects on usability.  A typical usage scenario might involve:

· Decrypting file content to an unencrypted version of the file.

· Working with the unencrypted file.

· Encrypting the modified unencrypted file to an encrypted file.

· Removing the unencrypted version of the file.

Some content encryption solutions, including SafeBoot, make this easier by encrypting and decrypting a file in place so there are no extraneous versions that have to be dealt with manually.  Encrypting and decrypting can be handled through right click context menu options.  SafeBoot even goes a step further and offers similar transparency to disk encryption by allowing editing of files directly by double clicking on them.  This still provides much of the extra protection gained through content encryption because authentication is required the first time this is attempted, and subsequent attempts use cached credentials.  The details on usability aspects vary with each product, but the example given above reflects the general worst case scenario.

External Storage Devices

External storage devices are not encrypted in any way by default.  External storage devices include USB disks, USB pen/key drives, Firewire drives, optical storage media, etc.  Files not encrypted using content encryption will not be encrypted when copied to an external storage device, even if they come from a disk utilizing disk encryption.  Restricted data copied to an external storage device must be encrypted using content encryption tools.  Additionally, it is against OSU policy to store restricted data on any media that is not owned by The Ohio State University.

TPM and BitLocker

Microsoft Vista systems will be encrypted using BitLocker, which can utilize the TPM if present in the BIOS.  This is the best solution with respect to security and usability for Vista systems.  The TPM monitors BIOS changes to prevent third parties from attempting to circumvent the additional security BitLocker provides, so on Vista systems using BitLocker and a TPM module, it will be important to not change BIOS settings arbitrarily or a recovery action might be necessary.

Using SafeBoot Content Encryption

This section discusses using the SafeBoot content encryption product.  There are various free software solutions and built-in solutions that work in a similar ways, though most are not as transparent as the SafeBoot solution.  Systems employing SafeBoot encryption are tied to a SafeBoot user account.  This account is used to boot the device into its full disk encrypted drive and to interact with the content encryption software component installed on the device.  Each user will be assigned their own content encryption key.  The content encryption key requires authentication using the SafeBoot account.  When interacting with any data encrypted using the content encryption product and a content encryption key, the system will present the SafeBoot user login dialog shown below:

The SafeBoot user authentication dialog is similar to the boot login dialog and the same as the authentication dialog that appears when exiting the screensaver, sleep mode, or resuming from hibernation.  Logging into the SafeBoot user authentication dialog will enable the use of the cached user content encryption key on the device.  The system will only prompt for a login once during an active session.  This is cleared when returning from the screensaver, sleep mode, or resuming from hibernation, causing another login prompt when interacting with content encryption during the next active session.

The system must download the user content encryption key from the SafeBoot server at least once before it can be used.  This should have been done during the post-encryption part of the encryption process when the device was returned.  If ever necessary, the SafeBoot content encryption component can be synchronized with the SafeBoot server as long as the device is connected to a network.  To synchronize with the SafeBoot server, right click on the SafeBoot content encryption icon in the system tray:

and choose Synchronize --> All:

Once the system has synchronized with the SafeBoot server once, the key is cached on the device for further use.  The key requires authenticating with the previously mentioned SafeBoot user authentication dialog before it can be used.

Files and directories can be encrypted by right clicking on them and choosing SafeBoot Content Encryption --> Encrypt… from the context menu as shown below:

The “Encrypt…” option displays the encryption key selection dialog:

The “Key name:” selected should match the local laptop user (and SafeBoot user) account.  Pressing the “OK” button encrypts the file or directory.  Encrypted files and directories appear with a special lock icon as shown below:

Encrypting a directory causes all content placed within that directory to be encrypted with the same user content encryption key.  Right clicking on an encrypted file or directory will show information about the content encryption key used on the “Encryption” properties dialog tab:

SafeBoot content encryption is integrated into the operating system to provide a transparent user experience.  It is possible to open, edit, and save encrypted files without explicitly decrypting the files first as in many other content encryption solutions.  It is also possible to explicitly decrypt a file by selecting “Decrypt” from the right click context menu, but this should only be explicitly done on files or directories that do not contain restricted data.

The “Self-Extractor” options encrypt data using only a passphrase.  Using this option will cause the system to prompt for an encryption passphrase for encryption, and data encrypted this way can be shared with other users who do not have the same user content encryption key.  These options create an executable file, which when clicked prompts for the encryption passphrase.  If the passphrase is entered correctly, a decrypted version of the file is placed on the file system in the same location.  Sharing encrypted data in this way requires sharing the encryption passphrase in some manner, which should not include sending the passphrase over email or other insecure means or transferring the encrypted data along with the encryption passphrase in any way.  Restricted data should not be shared between users in the general case.

The “Self-Extractor” executable file is not transparent in the same way as normal content encryption using the user content encryption key, but it does allow content to be shared in some fashion.  In cases where a need to share among numerous users is required, a group key can be requested to facilitate secure data sharing.  This is not the default case however.

External storage devices do not utilize disk encryption in any way.  Content encryption must be used for any restricted data stored on external storage devices.  In addition, it is against OSU policy to store restricted data on media not owned by The Ohio State University.

System Recovery

In the rare event that it becomes impossible to authenticate at the boot authentication prompt, contact the CSE computing staff Help Desk for further assistance.  In most cases, numeric codes can be used to enable access to the system.