This only opens a very small window of opportunity for an attacker-the time during which the Bitlocker encryption is disabled. This overwrites the unencrypted key and old VMK encrypted key on disk making any software data recovery of the old keys likely impossible. Microsoft automatically disables BitLocker encryption in this way during OS upgrades so reboots can occur unattended (note: not on Windows Updates, just full OS upgrades such as Win 8 -> 8.1).Īfter restoring the image, you then re-enable Bitlocker encryption in the settings which then re-keys the encryption for the Volume Master Key to whatever setup is present on the current computer the image was restored to. Encryption operations continue to take place as normal via the Volume Master Key at the block level. At no time does the Volume Master Key end up unencrypted on the drive, only the key to decrypt the VMK does. It instead writes the encryption key used to decrypt the Volume Master Key (the actual key responsible for your drive encryption) in the clear so no credentials are required to decrypt the Volume Master Key-and by extension-the drive. With Bitlocker there's no need to decrypt the drive, but it is highly recommended you disable Bitlocker for the volume in question in its settings before making the image otherwise you'll need to perform a recovery via the recovery key (you did print it out when enabling BitLocker encryption right?).ĭisabling Bitlocker is not the same as decrypting the drive. The provide a very efficient solution that will avoid the problems that Caballo is having, and also elminate the performance overhead that software encryption runs into. This is why I think in the future you are going to see SEDs (spinning media or solid state) being so important. It is evident that the case-in-point from Caballo is a software implementation. The host-side computer has to do the decryption AFTER the read operation.įor the most recent versions of Windows (server and desktop), BitLocker can do either one (hardware or software). If you are doing software encryption, when you are reading from the disk, the data is encrypted when read. For hardware-encrypted SEDs, on the other hand, all of the encryption happens in the drive, so CPU impact is pretty much zero. Not very fun! If you are doing software encryption, by definition, the encryption is happening on the host side. For example, in a notebook or desktop system, software encryption will rob you of roughly 15% to 20% of your IO bandwidth. Well, "vary greatly" could include systems where the encryption process can be handled with little impact to IOs, all the way to systems where the impact is quite measurable.
0 kommentar(er)
