fix(bitlocker): add recovery-password protector + save key (TPM+PIN-only was unrecoverable) #12
Reference in New Issue
Block a user
Delete Branch "fix/bitlocker-recovery-key"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
VM e2e milestone + a real product fix.
Milestone: with the Explorer pivot (#11), the full wizard ran end-to-end — rendered, flavour → account → prefs → apply, enrolled BitLocker TPM+PIN, rebooted to the pre-boot PIN prompt. 🎉
Bug it exposed:
BitLockerServiceenrolled TPM+PIN with no recovery-password protector and removed the TPM-only one — so a forgotten/mistyped PIN leaves the drive unrecoverable. We hit exactly that on the VM (PIN rejected at pre-boot, no way back). On real hardware that's a brick.Fix: after confirming the TPM+PIN protector, add a
RecoveryPasswordprotector and save the 48-digit key toC:\ProgramData\SilverMetal\bitlocker-recovery.txtand to the unencrypted EFI System Partition (Q:\SilverMetal-Recovery.txt) — the ESP is readable even when the OS volume is BitLocker-locked, so the key is recoverable offline (and lets me verify the enrolled state on the next VM run).The PIN-capture path itself is verified correct (string →
ConvertTo-SecureString→Enable-BitLocker -Pin, named args, no mangling) — the VM pre-boot rejection was an input artifact (masked field over noVNC / OVMF F-key mapping), not a code bug.Follow-up (product): escrow the recovery key to SilverSync + display it in the wizard's Done step so the end-user records it before finishing. Tracked, not in this PR.
Verified: welcome solution builds, 29/29 tests pass. Next: rebuild → restage → retest the wizard with a deliberate PIN; the recovery key is now the safety net.
🤖 Generated with Claude Code