Does a BitLocker recovery key have any use on removable media, a.k.a 'BitLocker to Go'?



  • I understand that there are multiple reasons that a recovery key might be needed on a system partition, but why would I want the extra security risk of having a way of circumventing my password for removable media?

    Why is windows asking for my recovery key?

    Windows will require a BitLocker recovery key when it detects an insecure condition that may be an unauthorized attempt to access the data. This extra step is a security precaution intended to keep your data safe and secure

    If I've understood this correctly, it only applies to fixed drives. Why not write down my password, or a reminder, rather than a key that's impossible to remember and does the same thing?

    This feels like a stupid question, but I've been unable to find a straightforward answer. Have I misunderstood something about how BitLocker to Go works? Does the recovery key offer any protection against the media or data being corrupted?

    VeraCrypt appears to only require a rescue disk for the system partition.


    One scenario I thought of was if law enforcement want you to unlock a drive and you don't want to give up a password that is used elsewhere or key escrow.


    To try and expand upon my confusion, the message when you setup bitlocker on a system partition:

    A recovery key can be used to access your files and folders if you're having problems unlocking your PC. It's a good idea to have more than one and keep each in a safe place other than your PC.

    "safe" here is ambiguous:

    1. Safe from attackers as it can bypass your password
    2. Safe from being lost, because you might need it even if you still have your password due to hardware failure or a change in configuration

    In fact, for system drives, both are true.

    For portable drives, the message reads

    If you forget your password or lose your smart card, you can use your recovery key to access your drive.

    Comparing this with EFS on wikipedia:

    Files encrypted with EFS can only be decrypted by using the RSA private key(s) matching the previously used public key(s). The significance of this is occasionally lost on users, resulting in data loss if a user forgets his or her password, or fails to back up the encryption key.

    Where presumably the private key is still symmetrically encrypted with a password.



  • BitLocker (in all uses) has a master encryption key which is encrypted using keys based on several "protectors". Common protectors for system partitions are TPM, passphrase ("PIN"), file-based key, and so on. BitLocker can also be temporarily "suspended" by writing a plain-text protector to the volume. Across all use cases, the recovery key is an additional protector (it can be disabled if you want to, though you'll probably need to use the command-line manage-bde.exe tool to do it).

    For any version of BitLocker where a PIN/passphrase protector is used, there's a risk of an attacker attempting to brute-force it. BitLocker has standard protections against this (mostly the use of an extremely slow password hashing function), which work both for online and offline attacks. However, in the case of online attacks, BitLocker can also respond to repeated incorrect password attempts by removing the PIN/passphrase protector (deleting the data necessary to derive the protection key for decrypting the master key, even if the correct password is later entered). While this doesn't stop somebody who imaged the BL metadata before attempting their attack, or who is accessing the volume through a write-blocker, it does prevent casual attempts to break into an encrypted flashdrive or external hard disk.

    However, with the PIN/passphrase protector gone, you need some other protector if you want to ever decrypt the drive. That - in addition to "forgot password" cases - is what the recovery key is for. It also provides a long-term secret that can be thrown in a safe or something and doesn't need to be updated even if you change the passphrase.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2