The second post in this series described how to map storage at an arbitrary cloud storage provider as an ordinary local drive in Windows, using virtual hard disks. This post will look at how to encrypt that drive such that any information data backed up to the cloud remains private under the worst-case scenario: the service provider going rogue and deciding to rifle through user data. While there are many ways to encrypt storage locally, we are primarily interested in options supported out-of-the-box on common operating systems such as Windows. It turns out that there is a built-in feature with exactly the right properties for this job: BitLocker-To-Go disk encryption or BL2G for short.
BitLocker and BitLocker-To-Go
Some context is required to distinguish BL2G from its better known cousin, BitLocker for boot volumes. There is plenty in common as the shared branding suggests. Both variants are full-disk encryption schemes; they operate at the level of an entire drive. This is contrast with a much older Windows feature called Encrypting File System, which operates at the level of files and directories. With EFS it is possible to designate particular directories or even individual files for encryption. For BitLocker that choice is made at the granularity level of a complete drive. (Strictly speaking these are logical drives, rather than physical instances. A single physical drive may be formatted with multiple partitions, each appearing as independent logical volumes.)
Both vanilla BitLocker and BL2G use similar formats and cryptographic primitives such as AES block cipher. Where they differ is the way encryption keys are derived, a difference rooted in the usage scenarios. Ordinary BitLocker protects boot volumes and is often used in conjunction with a built-in TPM that is part of that machine. One interesting corollary is that BitLocker can not encrypt everything. At least part of the boot-loader and core filesystem code responsible for decrypting the rest of the drive must be accessible in the clear. This poses a problem, since an attacker could then replace these pieces with a malicious bootloader/OS combination to obtain the. To thwart such attacks, BitLocker requires a verified boot process, where disk encryption keys are derived as a function of the code executed during the boot sequence. If any of those pieces change– such as the OS bootloader– TPM will generate different keys and disk can not be encrypted. Implicit in this design is the assumption that decryption only needs to happen locally. There is no expectation that the same drive can be removed from that laptop, popped into a different one– which contains a different TPM– and successfully decrypted on that new host.
BitLocker-To-Go is specifically aimed at solving that mobility scenario. While internal drives are rarely migrated between machines, USB thumb-drives are frequently used as low-tech high-latency network to carry data around. Unfortunately their size and mobility also makes them frequent subjects of theft or accidental loss. This is where BL2G comes in, providing full-disk encryption on removable media. In many ways BL2G has a simpler design because there is no boot sequence to worry about. On the other hand the mobility requirement rules out using an on-board TPM as the source of encryption keys, since TPM is bound to a single machine by design.
Encryption options
Instead BL2G gives users the option of a passphrase or smart cards. Ordinary BitLocker can also work with passphrases in the absence of a TPM but that leads to a situation where the burden is placed on users to pick “good” passwords. The difficulty of recovering the key is a function of user’s ability to pick random sequences of letters. This is exactly the weakness in SpiderOak client-side encryption described earlier. The same problem plagues OS X FileVault design, since Apple never quite figured out how to incorporate TPMs into their hardware. (Making matters worse FileVault uses the same secret for disk encryption as login to the OS. That means the secret will be typed often, for unlocking the screen for example, further discouraging choice of high-entropy ones.)
On Windows the smart card option is only available for BL2G. This is because the operating system is fully booted and running with all bells and whistles. By contrast ordinary BitLocker decryption takes place early on in the boot sequence, before smart card functionality has been initialized. Using this option requires a suitable “card” and/or reader combination but the options are quite diverse. Most common are plastic cards requiring insertion into a card reader, but contactless cards using NFC, USB tokens with embedded card or even an Android phone with embedded secure element can function as smart card as far as Windows is concerned. To confuse matters, starting in Windows 8 it is also possible to create a virtual smart card out of the TPM but doing that would break roaming.
One catch is that BL2G can not be applied to any old drive. For example SMB network shares can not be encrypted this way because such shares are not addressed as raw devices at the block level. Access to network drives is mediated by a remote server which presents a high-level abstraction of a file system, instead of a physical storage medium divided up into sectors. By contrast when a flash drive is attached, the OS takes direct control over its filesystem and manipulates the underlying media directly.
Enabling BitLocker-To-Go
Luckily VHD file mounted as local drive looks very much like that removable USB drive as far as the operating system is concerned. BL2G is enabled in exactly the same way: right-clicking on the mounted VHD image shows a context menu with the option to turn on BitLocker:
Enabling BitLocker-To-Go
As the shield icon suggests, the command requires administrator privileges. Selecting that and confirming the UAC prompt leads to a wizard walking the user through the steps of encrypting the drive and backing up the encryption key:
When the smart card option is selected, the wizard will require that a card is already inserted in the reader and search for a certificate with suitable properties. After encryption is complete, the drive icon changes to show a gray open padlock superimposed. This signals that the volume is protected by BL2G and that it is currently unlocked to allow access to the data.
Once BL2G encryption is complete, all data written to the virtual disk– which is represented by a single VHD file as far as the cloud service goes– is protected. There is no user chosen passphrase that can be brute-forced. (There is a usually a PIN set on the card for additional security but this PIN is only known to the card; it is never part of the encrypted disk image or shared with the cloud.)
The next post in the series will look at the experience of accessing that data from another machine, and some important limitations of this approach which make it impractical for large volumes.
CP
Random Oracle 