1

Short explanation

It's a Dell Inspiration 15 7000 which ran the original factory Windows 10 installation from Dell that came with the Notebook. It won't boot from it's internal SSD anymore after temporary removal of the drive. Checking the drive via command-line tools shows the drive as being encrypted.

And here is the full explanation:

Sorry for being so lengthy, I tried to structure it as good as possible...

What happened:

The drive was removed (to create a clone which failed due to insufficient space on the target drive) and plugged back in afterward, nothing else has changed. Trying to turn the notebook back on the boot-up just failed.

Preliminary checks:

Checking the BIOS (the screen called "Bootsequenz") shows the SSD's Partition 1 as the UEFI entry, but the "Windows Boot Manager" entry is missing. I think it used to look either similar to this or it just had the Windows Boot Manager entry (the image is from the internet): enter image description here

Checking via the command line tool using a Window 10 installations image via USB I get the following entry:

C:\>manage-bde -status G:
BitLocker Drive Encryption: Configuration Tool version 10.0.22000
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Volume G: []
[Data Volume]

    Size:                 Unknown GB
    BitLocker Version:    2.0
    Conversion Status:    Used Space Only Encrypted
    Percentage Encrypted: 100,0%
    Encryption Method:    XTS-AES 128
    Protection Status:    Protection Off
    Lock Status:          Unlocked
    Identification Field: Unknown
    Automatic Unlock:     Disabled
    Key Protectors:       None Found

Further analysis:

Bitlocker was not enabled by the user through Windows/Bitlocker so no recovery key was saved. So I wonder what happened here. I tried manage-bde -protectors -get c: which should give me the identification of the recovery key but it says it can't find any security measures. manage-bde -off C: is not possible either. I also read that it doesn't have to be Bitlocker itself just a Bitlocker-based implementation.

Additional background info:

  • The device/laptop has PPT is implemented, not TPM (no TPM option in the BIOS). PPT is activated in the BIOS.

  • In the BIOS the option Secure Boot is enabled, Secure Boot Mode is "Deployed Mode". In Expert Key Management the "Custom mode" is not enabled but there seem to be a few keys stored under the "PK" selection.

  • The encrypted partition is the Windows system partition (460 GB), the disk layout had more or less the standard Windows partitioning, the same if you would install Windows manually. The EFI System Partition at the beginning, followed by the system partition. Although were are two additional recovery partitions, probably used for Dell recovery options, and the EFI partition didn't have the regular 100MB but 650MB. Here's a screenshot from diskmgmt.msc (plugged in as an external USB drive):

    enter image description here

  • The cloning was attempted with Clonezilla and Acronis

  • An additional strange thing: I'm pretty sure since I took a screenshot but please take it with a little grain of salt (in case I confused something): After the removal of the SSD it was tested in a different Win 11 system as an external USB drive and files were accessible (but a Bitlocker symbol was shown on the drive icon). If this is true then the partition must have been either unencrypted or it was encrypted but the data was accessible anyway! That sound a little strange to me. Especially when I plug the SSD into the same Win 11 system, just shows a Bitlocker encrypted partition in the disc manager (see screenshot above). Here's the screenshot from when I accessed the root dir through Win 11:

    enter image description here

  • I don't remember the C drive having some kind of "lock" symbol attached in the explorer when it was still booting up. Is it possible that the encryption/decryption wasn't done within Windows but through some BIOS features (based on Bitlockertech) thus invisible to Windows itself? I found an old screenshot and there is no lock symbol on this partition, only the regular partition disk symbol and a shared symbol:

    enter image description here

My thoughts on the problem:

I'm not too familiar with the security measures so I read up a little bit (e.g. here) and as far as I understand the BIOS can handle the encryption via TPM or PPT in my case (BitLocker activation without a PIN: TPM only). So to my understanding the SSD was encrypted from the very beginning, is this correct? If so what handled the decryption? PPT since TPM is not activated in the BIOS? Why doesn't it handle it any more? As far as the system is concerned nothing changed after I reinserted the SSD into the original laptop.

It seems strange though that I could access the drive in the other system. This leads me to believe that some kind of security measure triggered the encryption to be enabled. Can the data somehow be encrypted and still readable in the first place when the drive is mounted as an external USB drive?

Possible solutions:

I discovered various causes and solutions to this type of problem on the net (e.g. restoring factory setting in the Expert Key Management in the BIOS or adding a protector via manage-bde -protectors -add c: -tpm), but I don't want to try out anything before I have an thorough understanding of what will happen so I don't make things worse.

My best guess is manage-bde -protectors -add c: -tpm could do the trick, basically adding the tpm as a valid key protector again (since currently it shows Key Protectors: None Found). But again, I don't just wanna try things out since my understanding is somewhat limited at the moment.

But it seems that a few people had success recovering the data. So I'm hopping to get some helpful insights.

11
  • “Can the data somehow be encrypted and still readable in the first place?” - It can only be read if you decrypted the drive. There is absolutely no other software on Windows that is like BitLocker. “This leads me to believe that some kind of security measure triggered the encryption to be enabled.” - This didn’t happen. My guess is that BitLocker came enabled on the device, since you indicated you do have the recovery key, and when you removed the drive the key was accidentally wiped from the TPM, hence the reason you have no protectors.
    – Ramhound
    Mar 31, 2022 at 12:15
  • You should have suspended BitLocker protection BEFORE trying to clone the drive. Cloning the drive with BitLocker protection enabled, would have never worked, if the key to BitLocker was stored in the TPM. There is no recovery from this state, if Windows cannot determine the protector (or even the size of the partition), there is absolutely no way to decrypt the encrypted partition
    – Ramhound
    Mar 31, 2022 at 12:19
  • It’s also possible the Windows 11 system enabled BitLocker on the drive, if that’s the case, you can use that same system to decrypt the drive. Try that and edit your question
    – Ramhound
    Mar 31, 2022 at 12:24
  • "It can only be read if you decrypted the drive." -> So what exactly decrypted the drive prior to the problem? || "My guess is that BitLocker came enabled on the device" -> that was my first thought but then I shoudn't have been able to read the file at all when I plugged it into a different system. || "since you indicated you do have the recovery key" -> no, that's a misunderstanding. There is no recovery key, since the drive was not manually encrypted.
    – Albin
    Mar 31, 2022 at 17:04
  • "when you removed the drive the key was accidentally wiped from the TPM" -> how and why? It should be still there. The question is, can I enable it's usage again during bootup. || "hence the reason you have no protectors" -> that's a "common" message, also in use cases where the problem was solved || "Cloning the drive with BitLocker protection enabled, would have never worked" -> why is that? || "There is no recovery from this state, if Windows cannot determine the protector (or even the size of the partition)" -> but it has been solved in other cases (if you believe the posts).
    – Albin
    Mar 31, 2022 at 17:08

2 Answers 2

1

The device/laptop has PPT is implemented, not TPM (no TPM option in the BIOS). PPT is activated in the BIOS.

Intel PTT is an implementation of TPM 2.0, and to the OS it's the same thing as a discrete TPM device.

So to my understanding the SSD was encrypted from the very beginning, is this correct?

Most likely, yes, I suspect that it was encrypted but in "open" or "suspended" mode – that is, with the volume key being stored in clear on the disk itself, waiting for you to fully activate it sometime later (giving you a chance to store the recovery key, or waiting for a MS account to be attached, or something). The TPM isn't involved yet.

I've seen Windows do this for its "Device Encryption" feature because from the user's perspective it allows the disk to be "encrypted" instantly (no need to wait a few hours until the encryption process happens) – the system just replaces the clear key with actual protectors.

Note how it says:

Protection Status:    Protection Off
Lock Status:          Unlocked

indicating that the data is already accessible.

(Encrypting an existing disk would also raise the question of whether the previous unencrypted data gets securely overwritten during the encryption process; that's no longer an issue if there's no unencrypted data in the first place.)

Cloning the drive with BitLocker protection enabled, would have never worked, if the key to BitLocker was stored in the TPM.

For most systems which use CPU-based encryption (rather than OPAL) this is complete nonsense. Encrypted data is still only data: it doesn't become un-copyable. It doesn't matter how it was encrypted, nor where the key is – the same bytes will decrypt to the same thing.

My best guess is manage-bde -protectors -add c: -tpm could do the trick, basically adding the tpm as a valid key protector again

No, that's not exactly how it works. Protectors aren't just config entries, they also hold copies of the actual master encryption key – if the disk were locked and the key unknown, you couldn't just generate a working protector out of nowhere.

The TPM doesn't store individual BitLocker keys directly; instead Windows asks it to encrypt the disk key using the TPM's internal key, and the sealed version is returned back to the OS for storage, which in this case means the BitLocker header. So in other words, it's not enough for a BitLocker protector to merely reference the TPM, it can't do anything unless it has the original sealed data.

On the other hand, if the disk is unlocked (indicating the master key is currently known), you can certainly add a new TPM protector, but it doesn't seem like it would be actually useful in your situation.

17
  • When I indicated that BitLocker should protection should have been suspended, there is a very good reason for that, because the cloning was performed in an environment that did not support BitLocker. The author is also attempting to clone the disk I presume with the attention of cloning that drive to other systems. Which is the reason BitLocker protection could not be enabled, with a key stored in the TPM, since Windows would be unable to boot into the OS due to the encrypted status.
    – Ramhound
    Mar 31, 2022 at 21:19
  • @user1686 So if it actually was in suspended mode, can it be activated without the option to store the recovery key or be attached to a MS account? So did it just remove the key without adding a protector?
    – Albin
    Mar 31, 2022 at 21:36
  • @Albin - The drive is still encrypted when it's suspended. It's just the key is stored on the drive, however, you cannot go from machine to machine with a BitLocker protected storage drive that is suspended. The drive is still encrypted, and in order to boot into the drive, Windows still has to decrypt the drive. There is no way to suspend BitLocker protection and NOT store the key on the drive. A BitLocker protected drive must have a protector, I suspect your second machine, simply is unable to detect what that protector is rather then it's missing.
    – Ramhound
    Mar 31, 2022 at 22:37
  • @Ramhound +user1686: I think you are right, the partition was already encrypted from the start (probable in what you call suspended mode). What I don't understand is why I was able to read from the drive the first time I plugged it into the windows 11 machine as an external drive and why it shows up as an encrypted drive the second time (possibly triggered by the cloning process). So the question is can I revert this or access the Data in another way? manage-bde -protectors -add c: -tpm did not work.
    – Albin
    May 16, 2022 at 11:43
  • 1
    @Albin - If you are unable to mount the drive you cannot retrieve the key in order to decrypt the drive.
    – Ramhound
    May 16, 2022 at 16:42
1

After a few hours of continuous reading about BitLocker on the internet, I managed to retrieve the "Recovery Key". Actually, it was quite "easy" using PS manage-bde -on g: -recoverypassword. This triggered the option to enter a (new) password and gave me the chance to save the recovery key.

I guess this would have worked through the GUI as well choosing the option to activate Bitlocker through the password option since there was no password set I suspect it would have accepted a new one.

This was the state of the drive afterwards manage-bde -status g: :

Volume G: []
[Data Volume]

    Size:                 Unknown GB
    BitLocker Version:    2.0
    Conversion Status:    Used Space Only Encrypted
    Percentage Encrypted: 100,0%
    Encryption Method:    XTS-AES 128
    Protection Status:    Protection On
    Lock Status:          Unlocked
    Identification Field: Unknown
    Automatic Unlock:     Disabled
    Key Protectors:
        Password
        Numerical Password
        External Key

I could get the partition to mount under Windows yet (I get an error message, that it's unreadable or corrupt) but mounting it on Linux via dislocker works fine.

Update: I managed to retrieve the data through Windows via recovering from the encrypted partition: repair-bde g: h: -force -rp 111111-222222-333333-444444-555555-666666-777777-888888. Not sure why Linux is able to mount the partition but Windows is not.

5
  • The "external key" is still not the master key; it's just another protector on the same level as the password. The actual master key is never revealed by the standard tools (Dislocker can display it, but it's not all that useful when you have a working passphrase) May 18, 2022 at 12:22
  • @user1686 thanks for the correction, I always assumed that by "master key" you meant the "recovery key" (which I needed to recover my data). Just to clarify, by "master key" you mean the "volume master key" here, correct?
    – Albin
    May 19, 2022 at 6:56
  • Yes, by "master key" I mean either the VMK specifically or VMK+FVEK collectively (the split between the two is a BitLocker-specific detail). Meanwhile, the "external key" item in your protector list is also called "startup key" or "recovery key" in Fig.1 (lots of names for the same .BEK files); note that it's different from "recovery password" (which is a numeric password in a text file). Finally "clear key" is what you had in the beginning, when protection was disabled; a clear key would also be stored if you used the -suspend option. May 19, 2022 at 7:11
  • For comparison you can also search about LUKS used on Linux; what BitLocker calls "protectors", LUKS calls "keyslots" and "tokens" (and instead of VMK + FVEK it has just a single "master key"). Recent cryptsetup versions also recognize BitLocker volumes and have cryptsetup bitlkDump [--dump-master-key], which I think outputs the FVEK. May 19, 2022 at 7:14
  • @user1686 yeah, the different names are a bit confusing in the beginning, thanks for the explanation! I'll have a look at LUKS.
    – Albin
    May 19, 2022 at 7:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .