How to create a file-based bitlocker protector for recovery and support purposes

Back in the days when BitLocker was introduced in 2006, not many machines were equipped with TPM chips that allowed transparent, hands-free encryption. So what did you do on your Windows Vista machine if you still wanted to use Bitlocker? Right, you used a USB stick that served as some kind of key to the machine. With the stick plugged in, the machines just started, no password needed, nice and easy. But were you aware what was on that stick; how it was prepared behind the scenes?

Let’s talk about file-based encryption keys, or, in Microsoft language, “startup-keys” aka “.bek-files”. The term “startup key” derives from what it was used for back in the days: to start up your machine with. A .bek file (Bitlocker Encryption Key), holds a cryptographic key which can then be copied by the admin to a USB stick (or disk) that you simply insert to start the computer - Bitlocker automatically searches for such a key and Windows boots without further needs, which is a nice alternative to entering the 48-digit recovery key.

The file type .bek is hidden in the file explorer by default and you will only see these files after you have enabled view options to show hidden and system files.

So now you know what the bitlocker wizard did with the USB key of yours, it simply copied a few bytes into a file on it and hid it. :-)

Important: whoever owns the keyfile has full control over the disk, even in recovery mode. Keep these files out of the reach of untrusted persons/non-admins.

Now today with TPM chips around, who still needs startup keys, anyway? Let’s see…

Have you ever wanted to start a bitlocked device, one with pre-boot authentication in the absence of the user, as in "after-hours-maintenance"? You will possibly not have had a chance to ask the user for the PIN or he will have sent it via mail but mistyped it, or the device might even not be startable anymore or could be in Bitlocker recovery mode.

Having to recover a bitlocked device means to work with the bitlocker recovery key, a 48-digit number that hopefully got saved to MBAM or AD when the device was encrypted and that is a pain to type. Is that right? Recover<=>recovery key? No easier way? There is an easier way: the startup key!

Since bitlocker allows multiple keys to be in place, it does not hurt to create an additional protector for us admins. We will keep it guarded and whenever we need it, simply copy it to a USB key that enables to unlock the machine with ease.

The procedure for creating is as follows: In a deployed scheduled task that you let run as a system account or within a domain start script, you use the following code

If not exist %windir%\admin\BEK manage-bde -protectors -add c: -sk \\server\share\%computername% && md %windir%\admin\BEK

which creates the required file. By creating a marker directory c:\windows\admin\BEK, it is ensured that this command runs only once so that only one additional key gets created.

About the share:

Read access to the share must be granted only to administrators. The computer accounts (which are executing the script) don’t get read access but get exclusive write access (only to their own folder ... \% computername%). That means, for each currently active and each new machine, we have to create a folder inside the share named like the machine (=%computername%).

icacls \\server\share\smith


\\server\share\smith
yourdom\smith$:(OI)(CI)(W)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)

This ensures that non-admins cannot gain access to the files and that even those users who may, unfortunately, have been granted local admin privileges who by design may impersonate the system account could not read these files.

Optional, additional protection: To increase safety, consider the following options:

- Enable this share only to set up PCs, 

- Request SMB encryption for this share when SMBv3 is possible

You should use the files only on demand, one by one and not mass-copy all to a stick, because forgetting that stick somewhere would really hurt badly.

Now, how do we safely delete these key files after usage? Remember, USB sticks are flash media and secure deletion on flash media is not really possible. So you better keep that stick either locked away or better, instead, you take a portable, conventional 2,5” HDD to store the keys on. On that portable mechanical and magnetic drive, you can of course also use the standard tools for secure deletion like for example Heidi eraser. [Why couldn’t we just encrypt these sticks / disks with Bitlocker as well? We can’t, because starting a computer works only with a .bek file on an unencrypted storage].

Please note: If someday you want to re-encrypt a machine, then a new .bek file must be created, because the old of course no longer works.

For the rare (and questionable) use case, that different admins should have access to a system and you want to be able to revoke this access later on demand (revoke per admin), you can create several keys in the same way.

Let me provide another code line to list currently active startup keys, together with their IDs:

manage-bde -protectors -get c: -type ExternalKey

If you feel like it, Individual keys can be deleted this way if necessary

manage-bde -protectors c: -delete -id {Key_ID}

Let me close by giving you an idea what content of such a key file ("KeyID.bek ") looks like when opened in Notepad:

œ 0 œ ÷ K (fO ‰ dUò4ï0Š àRä~, Ðl ÷ K (fO ‰ dUò4ï0šð-ß~, Ð E xternal K ey, ÁvèÖ-: ?? '¡Õvý ?? ê ??}} Ý~§U # ºD1ªÄÒ

That’s all, folks. If you need further explanations, let me know or ask a related question.