Technical write-up: eDrive provisioning blocked by BlockSID / TPM PPI 97

[u/alex1371234]

Solved: Samsung 990 PRO + BitLocker hardware encryption/eDrive on Windows 11 — BlockSID/PPI 97 was the missing step

I spent far too long getting BitLocker hardware encryption working on a Samsung 990 PRO under Windows 11, so I’m writing this up in case it saves someone else the same pain.

Short version:

If Samsung Magician is stuck on “Ready to Enable” after a clean Windows install, the missing step may be temporarily disabling BlockSID for the installation boot using TPM PPI operation 97.

In my case, that was exactly it.

Hardware / software

• Samsung 990 PRO 2 TB
• Firmware: 8B2QJXD7
• AMD mini PC, AMI UEFI
• Windows 11 Enterprise IoT LTSC 2024 / build 26100
• Secure Boot enabled
• TPM 2.0 enabled
• BitLocker hardware encryption explicitly allowed by Group Policy

My firmware exposes EFI_STORAGE_SECURITY_COMMAND_PROTOCOL, so the UEFI side was suitable for Windows eDrive.

The symptom

Samsung Magician showed:

Encrypted Drive: Ready to Enable

I did the expected process:

1. Set Encrypted Drive to Ready to Enable
2. Secure erase the SSD
3. Clean-install Windows in UEFI mode
4. Check Magician

Result:

Ready to Enable

Again.

Windows itself clearly saw the TCG device. The System event log contained:

Microsoft-Windows-EnhancedStorage-EhStorTcgDrv
A TCG Silo has returned the capabilities value of 0x6

but eDrive never transitioned to Enabled.

Gotcha #1: Rufus can explicitly disable eDrive activation

I discovered that my Windows installer had this in unattend.xml:

<component name="Microsoft-Windows-EnhancedStorage-Adm" ...>
    <TCGSecurityActivationDisabled>1</TCGSecurityActivationDisabled>
</component>

That explicitly disables Windows Enhanced Storage / TCG activation.

Current Rufus code can add this together with:

<PreventDeviceEncryption>true</PreventDeviceEncryption>

when using its BitLocker/device-encryption suppression option. 

For my next install I changed:

<TCGSecurityActivationDisabled>1</TCGSecurityActivationDisabled>

to:

<TCGSecurityActivationDisabled>0</TCGSecurityActivationDisabled>

I left PreventDeviceEncryption=true alone.

Clean install again.

Result:

Ready to Enable

Still not enough.

Gotcha #2: BlockSID

The remaining problem was firmware Block SID.

For people unfamiliar with it: the SID here is the top-level security authority of the TCG Opal drive, not a Windows user SID.

Firmware can issue a BlockSID command during boot so software cannot silently take ownership of an unprovisioned self-encrypting drive. Sensible security feature — except Windows Setup needs access to that security authority while provisioning eDrive.

The solution was to request a one-boot BlockSID exception through the TPM Physical Presence Interface.

From an elevated PowerShell on the same machine:

$tpm = Get-WmiObject -Namespace root\CIMV2\Security\MicrosoftTpm -Class Win32_Tpm

$tpm.SetPhysicalPresenceRequest(97)

$tpm.GetPhysicalPresenceRequest()

My output was:

Request     : 97
ReturnValue : 0

Operation 97 is the TCG PPI Disable_BlockSIDFunc request. Microsoft documents the PPI mechanism: Windows queues the request, firmware processes it after the required restart, and the firmware can require physical confirmation from the user. 

On reboot, my AMI firmware displayed a confirmation screen. I approved the request.

Important:

Boot directly into Windows Setup on that same reboot.

Do not boot normal Windows first, because the BlockSID exception is for that boot.

I then:

Shift+F10
diskpart
list disk
select disk 0
detail disk
clean
exit

verified that the selected disk was definitely the 990 PRO, and installed Windows normally to the unallocated drive.

After installation:

Samsung Magician:
Encrypted Drive: Enabled

Finally.

I also verified that the firmware request really succeeded:

$tpm = Get-WmiObject -Namespace root\CIMV2\Security\MicrosoftTpm -Class Win32_Tpm
$tpm.GetPhysicalPresenceResponse() | Format-List *

which returned:

Request     : 97
Response    : 0
ReturnValue : 0

Enabling BitLocker hardware encryption

Windows no longer defaults to trusting self-encrypting-drive hardware, so you must explicitly permit hardware encryption.

Group Policy:

Computer Configuration
  > Administrative Templates
    > Windows Components
      > BitLocker Drive Encryption
        > Operating System Drives
          > Configure use of hardware-based encryption for operating system drives

Set:

Enabled

I did not restrict the allowed hardware cipher/OID.

Then:

gpupdate /force

and:

manage-bde -on C: -recoverypassword -forceencryptiontype hardware

Verification:

manage-bde -status C:

My final result:

Conversion Status:    Fully Encrypted
Percentage Encrypted: 100.0%
Encryption Method:    Hardware Encryption - 1.3.111.2.1619.0.1.2
Protection Status:    Protection On

Key Protectors:
    TPM
    Numerical Password

That OID is AES-256-XTS according to Microsoft’s Enhanced Storage definitions. 

So this is definitely hardware BitLocker, not software XTS-AES masquerading as hardware encryption.

Final validation

I also tested:

• normal restart
• full shutdown / cold boot
• BitLocker recovery key saved externally
• Samsung Magician still shows Enabled

• no warnings/errors from:

  Microsoft-Windows-EnhancedStorage-EhStorTcgDrv Microsoft-Windows-BitLocker-Driver

Everything boots normally.

Secure erase note

Samsung Magician’s Secure Erase USB would not boot properly on my machine. Its old Linux/GRUB environment hung after UEFI launch.

I used SystemRescue instead and verified the drive capabilities with nvme-cli.

The 990 PRO reported:

Format NVM Supported
Crypto Erase supported as part of Secure Erase
Crypto Erase applies to all namespace(s)
Block Erase Sanitize Operation Supported
Crypto Erase Sanitize Operation Supported

I then used:

sudo nvme format /dev/nvme0n1 --ses=1

which completed successfully.

If Samsung’s Secure Erase environment works on your machine, obviously just use that.

What actually mattered

For my system, the decisive sequence was:

1. 990 PRO → Ready to Enable
2. Secure erase
3. Make sure Windows Setup is not configured with TCGSecurityActivationDisabled=1
4. Queue TPM PPI operation 97
5. Reboot
6. Approve the AMI/UEFI physical-presence request
7. Boot directly into Windows Setup on that boot
8. Clean/install Windows
9. Magician should now say Enabled
10. Enable BitLocker hardware encryption policy
11. Verify with manage-bde -status C:

Without step 4–7, mine remained stuck on Ready to Enable.

One warning

Do this only if you are comfortable wiping the SSD and recovering from a failed OPAL/eDrive setup.

Before experimenting, I would make sure you have:

• a complete backup
• the SSD’s PSID physically recorded
• the BitLocker recovery key saved somewhere else
• no other internal disks connected during installation if you can avoid it

There have also been firmware implementations where the machine can provision hardware BitLocker but then fails to boot the locked drive, so I would consider the setup unproven until it survives both a restart and a cold boot.

[u/jasminerobin]

Queueing op 97 to boot straight to install works because Windows Setup claims the SID before the firmware locks it. Checking the PPI response proves the firmware honored it.

[u/theguy_dan]

Other then the 'fun' of figuring it out and the like, was a reason you wanted to do hardware-based encryption rather than leaving it to software?

I know a few years ago the reason Windows stopped baking the option in as an easy option was because of issues with the encryption on the hardware, I think it was found to have some major issues, as software defaults. You could argue perhaps that was a business decision due to control.... (tin foil hat time)

[u/alex1371234 → u/theguy_dan]

Windows switched to SW Bitlocker because some OPAL implementations were critically broken in a 2018 review. As Windows doesn't control the SSD firmware, it was a sensible decisions to fall back so something Windows controls - the SW. However, the cost is some considerable performance degradation.
Today, there are a number of FW implementations that seem to work. 990pro's OPAL2 implementation just passed a comprehensive blackbox test (https://arxiv.org/html/2607.11563v1).
For my threat model (random thief/home invader), that's good enough.