Where is my bitlocker .BEK file?

I have an internal hard drive-- my G drive--(Win10) that behaves differently from all my other drives in regards to bitlocker (both internal and portable USB drives). First, I can't do anything through the bitlocker UI in Win10; I have to do things through the manage-bde command line. So I figured out how to get it encrypted via command line by doing this:

manage-bde -on G: -RecoveryKey F:

I'm not sure what the F: does; it seems to do nothing. But when I omit -RecoveryKey F:, I'm unable to run the following after drive encryption without getting an error:

manage-bde -protectors -get g:

So, now when I run the above command I get the following:

BitLocker Drive Encryption: Configuration Tool version 10.0.19041
Copyright (C) 2013 Microsoft Corporation. All rights reserved.
Volume G: [C-BAK]
All Key Protectors External Key: ID: {1F82A2C4-9408-4422-92A0-ECA7D278D18B} External Key File Name: 1F82A2C4-9408-4422-92A0-ECA7D278D18B.BEK Password: ID: {810D2BDB-A273-4C46-9CAC-DC4E17F65E6E}

Presumably that .BEK file is somewhere on my computer. But I cannot find it. It's certainly not on my F drive, which is where I assumed the key would be stored.

Where can I find the .BEK file? Or alternatively, how can I find the bitlocker recovery key for my G drive?

I have read in a few places that the '.BEK' is stored on a USB thumb drive. I put in a thumb drive (my OS forced me to encrypt it first with bitlocker to make it writable). I ran the above command again. No file written any place that I can find. No idea where that BEK file exists. Please help.

Thanks in advance for any advice.

1 Answer

According to documentation, this command would create the recovery key on what was the current working directory of the F: drive at the time you rand that command.

There is a difference between F:\ and F:: the former refers to the root directory of the F: drive, the latter refers to the current working directory of the F: drive in your current command prompt session.

Since the days of MS-DOS, the DOS/Windows command prompt has remembered one working directory per drive. So, if before running the manage-bde -on command, you had been doing something on the F: drive and had issued a command like:

F:\> cd some\directory\deep\in\the\hierarchy

then using just F: without the backslash would still refer to F:\some\directory\deep\in\the\hierarchy, even if you had switched to a different drive after that. And if you really used just F: without the backslash in the command to enable Bitlocker for drive G:, that's where the recovery key file would have been created.

So, the external key file would have to be on the F: drive, but not necessarily in the root directory of that drive. Or if your F: is a removable drive, the key file would be on the drive that was F: at the time you ran the command to enable BitLocker on G:.

If you have already searched your entire F: drive for *.BEK files and found nothing, it's possible that you have accidentally deleted the recovery key file. If so, then you should create a new recovery key file right now, before you do anything else.

If anything bad happens to your system disk, this single action might be worth all the data you currently have on your G: drive, since without a usable recovery key, the data will be as good as gone if the system disk fails.

manage-bde -protectors -add G: -recoverykey X:\some\directory\you\will\definitely\remember\from\now\

Choose a path for the recovery key directory that will be appropriate to your environment.

Once you have verified that the new recovery key has been successfully created, and have backed up the recovery key file securely, it is time to invalidate the old recovery key file:

manage-bde -protectors -delete G: -id {1F82A2C4-9408-4422-92A0-ECA7D278D18B}

Explanation: like several other disk encryption solutions, Bitlocker has a master key that is actually used to encrypt the data on a drive. Changing the master key is a slow and difficult operation as it requires decrypting and re-encrypting the whole drive. So, the user is never allowed to access this master key directly.

Instead, the encrypted drive holds the master key in an encrypted form (or optionally several copies of it in several encrypted forms). Each method to unlock the encryption acts as a key to decrypt just one particular encrypted copy of the master key, which in turn allows using the master key to unlock the disk encryption.

If your system has a TPM, your encrypted disk can be unlocked automatically for you since one copy of the encrypted master key is stored so that only the individual TPM chip in your system can provide the decryption key for it.

Each recovery key file actually holds a secondary key that can decrypt its assigned copy of the master key on the encrypted disk. This allows you to create multiple recovery key files - and also to invalidate any one them with only the recovery key ID being known, without having to change the actual master key, by just destroying the corresponding copy of the master key on the encrypted drive.