Microsoft BitLocker Reviews

This post originally appeared on the Random Oracle blog at http://randomoracle.wordpress.com/2013/03/05/ironkey-verses-bitlocker-to-go-with-smart-cards-part-2/

The first post in this series described how the BitLocker-To-Go feature built into Windows can be used in conjunction with smart cards to encrypt removable drives, and offer an alternative to dedicated hardware such as IronKey devices with comparable security. In this second and final part, we continue the comparison focusing on scaling, cost effectiveness and ease of deployment.

From a cost perspective, BL2G wins hands down:

• BL2G works for any external drive, as well as logical volumes and non-bootable partitions of internal drives. There is no need to acquire new hardware. Existing plain USB drives can be leveraged, avoiding new capital spending.
• Even when buying new drives,  there is a huge premium for models with built-in encryption.  Data point from March 2013: 16GB model of IronKey Basic S250 retails for around $300. By comparison a plain USB thumb drive at that capacity costs less than $20, or one-fifteenth the price. Not to mention those vanilla drives boast USB 3.0 support, unlike the IronKey stuck with slower USB v2. The price discrepancy only gets worse with increasing capacity– a phenomenon that can only be explained by wide profit margins, considering that the addition of secure element to vanilla drive is fixed overhead.
  • For BL2G there is the additional expense of card and reader. Basic contact-only readers can be had for less than $20. (On the splurge side, even fanciest dual-interface readers with contact and NFC  retail top out around $130.) The cost of the card itself is noise; plastic cards cost around $10 in volume. Alternatively one can opt for USB tokens such as GoldKey that function as combined card-in-reader.
  • It is also worth pointing out that card and reader are not unique to a drive: the same combination can protect any number of drives. Not to mention, enable other useful scenarios including machine logon,  secure email and remote authentication. In short the one-time investment in issuing cards and readers is far more economical than buying dedicated drives.
• Speaking of space, BL2G scales better to large capacities because it operates on commodity hardware. IronKey comes in different sizes but the largest ones in thumb-drive form factor max out at 64GB currently. Meanwhile plain 256GB drives have reached market, and are starting their inevitable drop in price. Because BL2G effectively implements the ”bring-your-own-drive” approach, it is not constrained by any particular manufacturer’s offerings.

From an administration perspective, the MSFT focus on enterprise scenarios leads to a more manageable solution:

• The IronKey requires yet one more password to remember and does not fit into any existing enterprise authentication infrastructure. (For users with drives, consider the challenge of updating the password on all of them.) By contrast the same smart card used for logon to Active Directory can be used for BL2G encryption if provisioned with a suitable certificate. The user experience is one versatile credential, good for multiple scenarios.
• Basic IronKey models can not recover from a forgotten PIN, unless the user activated an online account. Not even if the user is willing to lose all data and start from a clean slate with blank drive. (This conveniently translates into more sales for the manufacturer, so there is not exactly a lot of economic incentive to solve the “problem.”)  BL2G volumes have no such constraint. They can be wiped clean and reformatted as plain drives if desired.
• BL2G can be integrated with Active Directory in managed environments. Group policy can be configured to back up encryption keys to AD, to allow for data recovery by IT administrators in case the primary (smart card) and secondary (printed key) unlock mechanisms both fail.

On the downside, there are deployment challenges to using smart cards:

• BitLocker remains a Windows-only solution, while IronKey and its brethren have decent cross-platform support. In principle there is no reason why software could not be written to mount such volumes on OS X and Linux. (It is not clear Wine emulation will help. While there is a reader application available downlevel for XP,  recognizing BL2G volumes is part of core system functionality. There is no stand-alone executable to run in emulation mode to get same effect.)
• BL2G requires smart card and card reader, or equivalent combined form factor as USB token. While plug-and-play support and developments in the Windows smart card stack for recognizing common cards has made this simpler, it is one more piece of hardware to consider for deployment.
• Cards need to be provisioned with a suitable certificate. BitLocker can use self-signed certificates obviating the need for CA, but that assumes the card can support user-driven provisioning. This is true for GIDS for example, but not PIV which requires administrative privilege for card management and more suitable for enterprise setting.

Finally it is worth pointing out some options that try to integrate removable storage with a smart card reader. For example the @Maxx Prime combines a SIM-sized smart card reader with a slot that can accommodate microSD drives. Typically that SIM slot would be permanently occupied by a small form-factor card with support for certificates and public-key cryptography. Then interchangeable microSD cards can go in the microSD side to provide access to encrypted data, with the entire rig connected to a USB port.

This post originally appeared on the Random Oracle blog at https://randomoracle.wordpress.com/2013/07/29/using-cloud-services-as-glorified-drive-bitlocker-to-go-part-iii/

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.

BitLocker uses your computer's TPM device, if it has one. If it does not, you'll be forced to use a USB memory stick to keep your key on. You can choose to use the USB option instead of the TPM. - Pro for TPM - easy to use. turn the PC on and it's ready to use. - Con for TPM - windows is super easy to get into even when a password is used. attacker can steal your whole computer and get into your system if they know what they're doing. it's not an advanced attack. - Pro for USB - take the drive with you wherever you go, attacker can't get in if you shutdown your PC when you leave your place. - Con for USB - if you lose the drive, you lose the key. you could, of course, print the key and keep it in a fireproof box. if you leave the USB drive with the PC, then it's like the "Con for TPM" scenario. [tin-foil-hat] "We have been able to provide police, law enforcement, and private investigators with a tool that allows bypassing BitLocker encryption for seized computers.” source: http://www.thetechherald.com/articles/New-software-will-break-BitLocker-encryption/8538/ [/tin-foil-hat] edit: Volume-level encryption, which BitLocker employs and so can TrueCrypt (in addition to containers and partition-level encryption), is not as good as Full Disk Encryption, but still good. The most popular use of TrueCrypt is creating encrypted containers within unencrypted (or encrypted) partitions. - Pro's to TrueCrypt - it's vetted and regarded as one of the best platforms to use. good, long passwords stored in your brain are hard to brute force. - Con's to TrueCrypt - don't forget your password. theoretically, and especially if a short password is in use, the container can be brute-forced fairly easily. Longer passwords are better than more complicated passwords when it comes to encrypted containers. (see *However* below) *However* TrueCrypt also supports the use of keyfiles, which means you can create an encrypted volume, partition, or container, store the keyfile on a USB memory stick, and store a good, long password in your brain. the container in this scenario can't be brute-forced without the keyfile, but you need the keyfile and the corresponding password to unlock the container.

Valuable Features:

Room for Improvement:

Other Advice:

Valuable Features:

Room for Improvement:

Other Advice:

Valuable Features:

Room for Improvement:

Other Advice:

What is our primary use case?

What is most valuable?

What needs improvement?

For how long have I used the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How was the initial setup?

What's my experience with pricing, setup cost, and licensing?

What other advice do I have?