Before BitLocker we used the DELL disk protection through the BIOS. This protection is not very efficient and the user needs a PIN to unlock the computer. With BitLocker I guarantee the protection of the disk and the configuration is transparent to the user.
The implementation of BitLocker is not simple. There are many prerequisites and hours of study and testing. We have had some communication problems between Windows 10 and TMP and, in some cases, the computer does not work and we need to generate a new key in MBAM.
We tested the solution for four months on all computer models we have before placing it in the production environment.
Yes. We had communication problems between the OS and TPM 1.2 of the computer. It is best to use computers with TPM 2.0.
No. We have 1200 computers and the environment, with one MBAM server and one SQL, is supporting the environment. I do not know how scalability is using Active Directory to store the encryption keys.
There is a lot of documentation in English and Brazilian Portuguese. To date, we have not needed Microsoft technical support.
No. Symantec, Dell and McAfee solutions for disk encryption are expensive and some of them use BitLocker behind the solution, but are very expensive.
The initial setup is simple. You have the task of turning on the TPM of all computers before attempting to use the BitLocker. When using MBAM + SCCM + SQL it is important to have a CA root in your environment to issue the digital certificate to the MBAM.
BitLocker is already in Windows 10 and its price has already been "paid". To use another disk encryption solution you have to analyze well the needs of each company and how much data is critical to the business.
I evaluated solutions from DELL, Symantec and McAfee. Among all, Symantec has a good solution, but very expensive.
We are using BitLocker for Windows 10 (which depends on TPM 1.2 or greater) being managed by MBAM 2.5 with SQL Server database to store the encryption keys. BitLocker is configured to use Active Directory or SQL to store the encryption keys. When using AD, the keys are stored in an unprotected directory. When using SQL, the stored keys are stored in an encrypted database.
I recommend that you study many hours before you start testing. Take the MBAM test at Microsoft's website.
Study TPM 1.2 and 2.0.
Use SQL to store the encryption keys and not the Active Directory, so you leave the AD free of high processing and add a layer of protection with the encryption of the database.
It is important to test on ALL models of computers, there is always a model that will not work.
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.
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.
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.
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:
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.
This post originally appeared on the Random Oracle blog at https://randomoracle.wordpress.com/2013/03/02/ironkey-verses-bitlocker-to-go-with-smart-cards-part-1/
IronKey is one of the better known examples of “secure flash drive,” a category of products targeted at enterprises and security-conscious users for portable storage with hardware encryption. From a certain perspective, this entire category owes its existence to a failure of smart card adoption in the same target market. All of the functionality of dedicated hardware encryption products can be implemented with equal or better security, at much lower cost and greater flexibility using general purpose smart cards and off-the-shelf software.
Case in point: BitLocker-To-Go (“B2LG” for short) available in Windows 7 and later versions, provides full disk encryption for any old USB drive, with keys managed externally. B2LG is closely related to the original Bitlocker feature introduced in Vista, which protected boot volumes with the help of a trusted platform module. The latter is a more difficult proposition, as booting a modern OS involves several stages, each depending on executing code from the encrypted disk. Maintaining integrity of this code loaded during boot is as much of a concern as confidentiality, because altering the operating system can be an avenue of bypass against disk encryption. By contrast B2LG is concerned strictly with reading data after the OS has been already booted into a steady state.
BL2G can be configured to use either passwords or smart card for encryption:
The first configuration is susceptible to the usual offline guessing attacks, much like Android disk encryption, because keys are derived from a low-entropy secret chosen by the user. In the second configuration, the bulk-data encryption key is randomly and sealed using a public-key associated with the smart card. Unsealing that to recover the original key can only be done by asking the card to perform a private key operation, which is what smart cards are designed to implement with high security.
Comparing a USB drive with built-in encryption with B2LG coupled to smart cards card, these solutions achieve similar but not identical, security profiles:
The second part of this post will look at other dimensions, such as performance, cost effectiveness and scaling, where BitLocker & smart card combination enjoys a decisive advantage over dedicated hardware.
