The only way this makes sense is if the old disk was replaced,
so the new disk is empty, yet the bitlocker key is still
found in the TPM so the BIOS is still insisting
on it, although the new disk isn't encrypted at all.
However, the technician cannot access the disk without
the password in order to install Windows.
If you know the password, giving it might help the technician,
although the whole situation is unclear to me and I have
doubts that this will help.
Otherwise, the simplest solution to use the new disk
would be to clear the TPM.
This would require knowledge of the exact model of your
motherboard and your BIOS version,
but in general this is an option inside the BIOS, perhaps found
inside a "TPM security" section.
Since I was attacked and this answer was downvoted on the basis
that the UEFI has nothing to do with Bitlocker, here are some
facts that will throw some light on the question.
I was criticized for saying that the Windows bootloader
uses the UEFI to turn off Bitlocker, so here are some facts about
the sizes of the involved softwares as gathered for one Windows 10
computer:
- The Windows bootloader (
bootmgfw.efi
) : 1 590 640 bytes
- The Windows Bitlocker interface (
manage-bde
) : 222 KB
- The UEFI download file (
BIOS_IMG.rcv
) : 27.06 MB
This small bootloader is also called "stub" in some Microsoft
documentation, and it's clear that it must rely heavily on
services supplied by the UEFI.
In fact, the
Unified Extensible Firmware Interface (UEFI) Specification
says this very clearly in section "2.1.3 UEFI OS Loaders":
A UEFI OS loader is a special type of UEFI application that normally takes over control of the system from firmware
conforming to this specification. When loaded, the UEFI OS loader behaves like any other UEFI application in that
it must only use memory it has allocated from the firmware and can only use UEFI services and protocols to access
the devices that the firmware exposes.
A certificate may contain information identifying its
intended usage. For example, the Microsoft article
BitLocker group policy settings
says:
The object identifier is specified in the extended key usage (EKU) of a certificate. BitLocker can identify which certificates can be used to authenticate a user certificate to a BitLocker-protected drive by matching the object identifier in the certificate with the object identifier that is defined by this policy setting.
This means that it's possible for the UEFI to identify
Bitlocker-intended keys inside the TPM (unfortunately
not much information is publicly available about which are
the exact mechanisms used by Bitlocker for the TPM).
It can be concluded that indeed it's the UEFI that controls all
device accesses and every resource request issued by the
bootloader. It can be said that the UEFI is the guarantee that
Secure Boot is indeed secure - for each and every action,
the bootloader must pass through the UEFI.
This certainly includes verifying digital signatures and
also Bitlocker and TPM.
I believe that I have answered here all the criticism that was
directed at me in the comments.