Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
I don't trust Microsoft BitLocker because it is closed source, which makes it so people can't audit it. But now I'm really interested in how its recovery code works. In my own knowledge, encrypted data can't be decrypted without knowing the key, but BitLocker breaks it.
So, I have three questions want to ask:
In my own knowledge, encrypted data can't be decrypted without knowing the key, but BitLocker breaks it.
That description indicates you might have misunderstood something there. Bitlocker does not break anything* as Microsoft BitLocker uses recovery keys (read again: “keys”), not code! The related code for recovery is pretty similar to the usual decryption code which Bitlocker also uses when you’re using your personal key. No magic or backdoors there. For details, you might want to check “What is a BitLocker recovery key?” and “BitLocker recovery keys: FAQs” as well as the linked pages of the Bitlocker documentation.
The three sub-questions are partly too broad, and partly unanswerable completely for reasons I’ll gladly describe while trying to provide you with some helpful hints nevertheless…
- How does the recovery code work?
You’ve already said it yourself when you wrote I don't trust Microsoft BitLocker because it is closed source, which makes it so people can't audit it. The words “Closed source” are important to remember when asking things like that. Long story short: I won’t break any intellectual rights for you and I’m pretty sure Microsoft will not be very willing to provide anyone with any legal right to do so unless it makes sense to them.
Yet, you could very well decompile the binaries on your own computer to check on its inner workings for yourself. Doing so enables you to engage in some personal auditing efforts too. Yet, your success in doing so will definitely depend on your decompiling abilities as well as your ability to read and understand the minimal ASM source that decompilers tend to spit out.
- How can I implement a recovery code function on any encryption algorithm in a mathematical way?
This question is based on your misunderstanding that Microsoft Bitlocker “breaks” things with a recovery code. As noted above: that’s not how it works.
Microsoft BitLocker uses a recovery key – which is a special key that you can create when you turn on Bitlocker Drive Encryption for the first time on each drive that you encrypt. That recovery key is what enables Bitlocker to recover things for you when you – for example – forgot your usual (non-recovery) key… without a key, you won’t get anywhere – which is why Microsoft puts an emphasis on the fact that you should store the recovery key by printing it, saving it on removable media, or saving it as a file in a secure place.
Personally I would advise against storing secrets like keys on the same computer which you use to host/store your encrypted data. Yet, your security expectations may be different than mine. (More on the related, potential security impacts later when I answer your 3rd sub-question.)
The “code” that Bitlocker uses to recover data for you using that recovery key is pretty much the same as the code it uses when you decrypt things using your usual (non-recovery) key. The differences merely reside in detection of the key-type (regular or recovery) and handling/decrypting things accordingly. There is no magic or hidden unicorns in there… and Bitlocker is definitely not breaking any encryption when you recover an encrypted drive with your recovery key. Think of it as Bitlocker using regular decryption code as usual, merely the key-type is a different one… but a “recovery key” is nothing else than a regular key. It’s a secret to unlock your data in a worst-case-scenario; eg: you tried to memorize your key, but when waking up the next morning you realize you forgot it. That’s where you would need a recovery key, which you hopefully stored in a secure place at the time you created it – which was when you first encrypted the related disk/data.
So, could you implement such a recovery functionality no matter the encryption algorithm? Generally, yes. Just note that that would be more a “software feature” than an algorithm thing. Therefore, asking about a mathematical way to do so doesn’t really make sense as it’s too broad and practically impossible to cover all individual algorithms out there. And describing how to write secure wrappers around a crypt algo core can not really be described mathematically, as it’s more a programmatically thing and not “one mathematically describable formula to rule them all”. If an algorithm can encrypt and decrypt data based on a secret/key, nothing is stopping a programmer from wrapping a functionality around the crypto algo core to offer users an option to use recovery keys to decrypt things. (In case of doubt: I’m assuming such a programmer to have access to the crypto algo sourcode, or at least the API/SDK to be able do so… while ignoring some rare, rather borderlining situations where this might not be the case, yet possible to implement nevertheless.)
Surely, making two different keys decrypt the same data can be explained and described from a cryptographical point of view as there are several options/schemes available to do so. I won’t even start listing them here because Crypto.SE already has several Q&As handling that. The search-box at the top-right of every Crypto.SE page is the perfect tool to help you find them.
- Will it be a possible backdoor/vulnerability to hacker?
A recovery key and related recovery functionality that expects you to enter such a secret before it is able to decrypt the related drive can hardly provide an attack vector unless you really messed up things badly from a security point of view. That’s one of the reasons Microsoft provided ample security advice made available to you as a user.
When thinking beyond that, I’ll have to say that anything is “possible“ if the circumstances allow it. So thinking beyond the obvious renders your question a bit too broad as you can’t possibly expect anyone to handle all the potential scenarios, situations, and potential security glitches you might or might not be thinking about.
To avoid such broadness, I’ll limit my answer to this sub-question by saying that when we assuming the decryption code doesn’t include a backdoor and/or vulnerability, the recovery procedure using recovery key(s) will hardly pose any risk as it mainly uses the same parts of the code Bitlocker also uses for the usual decryption functionality when using your usual (non-recovery) keys.
Whether a “hacker” can gain access to your encrypted drives as well as to the related keys and/or recovery keys ends up being something up for you to evaluate. As long as you keep your keys secure and use Bitlocker correcly (both thing are described in the related manual/documentation which Microsoft provided for a good reason), you should be fine.
Note that the Bitlocker documentation clearly states and advises not to store keys on the same machine hosting encrypted drives/data. If you decide to store keys and (encrypted) data in the same place anyway, you logically have to assume all related risks. Meaning: If an attacker can get access to your key storage (whichever key storage option you may have chosen), you’ll surely be inviting that attacker to walk all over all the encrypted data… if (and only if) that hacker is also able to gain access to the encrypted drives those keys belong to.
Assuming an average, non-state adversary and assuming you’ve followed the ample advice provided within the Bitlocker manual, that’s rather unlikely to happen.
For such an attack to work, an adversary would have to circumvent things like the Microsoft Firewall et al – which a security-aware person like you surely will have updated, correctly configured, and activated for your system protection. Attackers can’t read a single bit of any of any your drives (encrypted or not) unless they either circumventing those barriers (firewall et al) or when they have physical access to your drives.
Additionally, the attacker would also have to get access or knowledge of your keys. Repeating it again: if you follow the Bitlocker docs and contained recommendations, those keys won’t be stored on the same computer system and can therefore not be found on the same computer system that holds your encrypted drives. That makes things hard for an attacker as the attacker would also either need to circumvent other barriers (eg: firewall et al of other system), or be able to gain physical access to the keys.
Surely, things will turn against you if there are incidents like (eg) a burglar stumbling upon your encrypted drives as well as your keys which you’ve printed out but then put neatly into your desktop drawer next to your computer for everyone to find, or (eg) you store keys on another system within the same network but an attacker can access to both encrypted drives as well as the key storage after a successful full-network breach. If you think about it, a bit of human logic can prevent most of such risks… while the rest can be learned by reading the Microsoft Bitlocker manual and following the contained recommendations.
I think it is needless to say that, if you leave your system and/or network wide open (read: in an insecure state) and if you additionally ignore the manual/documentation by leaving at least one of your keys flying around within the reach of a potential attacker, your data could be decrypted without big efforts by near to anyone who is able to gain access to both the encrypted drives as well as related keys.
Bitlocker doesn’t decrypted without knowing the key, so assuming BitLocker breaks anything by using some magic recovery code is wrong. Bitlocker uses recovery keys via related recovery functionalities. Every software out there that offers alike functionalities based on recovery keys works in a somewhat similar way – wrapping that additional functionality around a cryptographic algorithm core. Bitlocker doesn’t contain some magic sauce voiding your key by breaking its own crypto… it’s simply a recovery functionality based on recovery/backup keys. Without a key, Bitlocker won’t be willing nor able decrypt anything. How exactly this was implemented by Microsoft can only be answered in detail when having access to and studying the sourcecode. Even if this would be available, describing the details would break the limits of sanity as it would probably take a small book instead of an answer to talk about every detail of every related function and variable.
As with every encryption: if you store the encrypted data and the key on the same system – your data safety can be considered near to void. Anyone having access (or being able to gain access) to both encrypted data as well as related key(s) can access and decrypt your data. That’s one of the reasons why cryptographers, information security people, and the Bitlocker documentation itself advise to never store encrypted data and its related secret(s)/key(s) in the same location. As long as you keep keys out of reach of potential attackers by storing them in a separate, secure place (at least not on the same machine), the success rate of a potential “hack” and the ability of an attacker to read your decrypted data will be near to or equal to the success rate of a brute-force attack on your encrypted drives.
Actually, you could boil this whole thing down to a simple: “Securing your key(s) is your key to security.” – or, how others might know it: “Always keep your secrets secret.”
To learn about the Microsoft Bitlocker security recommendations related to key storage et al, and to clearly understand how Microsoft Bitlocker (including the recovery of encrypted drives) actually works, you might want to start reading the manual. The two links I provided at the beginning of this answer serve as a pretty good entry point to do so.
For your convenience, I’ll simple mention those links again: “What is a BitLocker recovery key?” and “BitLocker recovery keys: FAQs”. You’ll discover a complete manual when following those links, which will definitely be able to explain all this in more detail.
Since the comments area showed there’s some confusion about the keys and which key en/decrypts what…
Each of those keys (both “regular” keys and “recovery” keys) can be used by Bitlocker. Practically it goes like this: You provide a key which will be used to construct the key-protector key (using a key derivation function – KDF). The output of the KDF is used to decrypt the Volume Master Key (VMK). The VMK is then used to decrypt the “Full Volume Encryption Key” (FVEK), which is the key that actually actually en/decrypt the individual disk/volume.
So, staying in line with the notation used in the comments:
$$\text{pin/recovery key} \rightarrow KDF \rightarrow VMK \rightarrow FVEK \rightarrow \text{volume en/decryption}$$
user typed key -> recovery key -> encryption key?
$\endgroup$
manage-bde C: -protectors -add -rp as admin, you can either specify a 48-digit password (your choice) or enter nothing to have the operating system create a randomly generated password for you (for which the system will use the operating system’s cryptographically secure random number generator).
$\endgroup$
user typed key, recovery key and the encryption key should have no relationships to each other sine recovery key (the prompt said it is a recovery password) is user choice or random generated, then how does BitLocker encrypt the data? Where is the encryption key come from? How BitLocker link up the user typed key & recover key/password to the encryption key?
$\endgroup$
The simple way:
The system uses your 'password' to generate the 'crypto-key' used to encrypt/decrypt your data. Then the 'crypto-key' or a variant of it, is send to you as a 'recovery-key'. The system do not need to know your 'password'. But can restore your data with the 'recovery-key'.
Just it. But it can be done in many, many ways.
