1

I built a PC from scratch a while ago, and after learning the recommended requirements for UEFI Secure Boot and Microsoft's Bitlocker, I installed an Infineon TPM in my motherboard. My understanding is that a TPM is supposed to be a software-independent source of trust which securely stores encryption keys (and possibly certificates?). I have a basic understanding of the "public key authentication idea" and I'm not looking for an explanation of the cryptography at work here, but I am wondering what is being referred to when the UEFI system asks me to "initialize factory default keys"? I did this, and doing so seems to have satisfied the Secure Boot requirements, but:

  1. Are these factory default keys something created by the TPM manufacturer?
  2. Shouldn't I generate my own keys? 2b. If I initialize Bitlocker using these factory default keys, does that mean I'm using Infineon (TPM manufacturer) private keys?
  3. In my research for this question I have found several guides to Secure Boot/TPMs for various Linux distributions, but the only guide I could find for Windows was this, which A) appears to be intended for OEM PC manufacturers, and B) is more of a conceptual guide than an explanation of how to properly set up a TPM for Secure Boot and Bitlocker encryption.

Edit:

Motherboard: MSI Z390-A PRO

TPM: Infineon SLB 9665 TT2.0

The TPM & motherboard support the TPM2.0 specs

Output of tpmtool getdeviceinformation command:

-TPM Present: True
-TPM Version: 2.0
-TPM Manufacturer ID: IFX
-TPM Manufacturer Full Name: Infineon
-TPM Manufacturer Version: 5.63.3353.0
-PPI Version: 1.3
-Is Initialized: True
-Ready For Storage: True
-Ready For Attestation: True
-Is Capable For Attestation: True
-Clear Needed To Recover: False
-Clear Possible: True
-TPM Has Vulnerable Firmware: False
-PCR7 Binding State: 0
-Maintenance Task Complete: True
-TPM Spec Version: 1.16
-TPM Errata Date: Wednesday, September 21, 2016
-PC Client Version: 1.00
-Is Locked Out: False
u1686_grawity
  • 452,512

1 Answers1

1

It sounds like you're not initializing BitLocker at all – these keys are for Secure Boot only, i.e. the PK/KEK/db/dbx variables. The default set configures Secure Boot to allow only operating systems signed by Microsoft (and sometimes by Canonical Ltd.), plus drivers signed by the PC manufacturer.

Secure Boot variables only store public certificates, not private keys, and they are not used for encrypting any data (only verifying signatures). Some firmwares might store them in the TPM-provided NVRAM in order to satisfy the "tamper-resistant" requirement that's in the spec, but other than that, these keys have nothing to do with TPMs.

Shouldn't I generate my own keys? 2b. If I initialize Bitlocker using these factory default keys, does that mean I'm using Infineon (TPM manufacturer) private keys?

TPM 2.0 has "user generated" and "factory default" as two separate worlds (aka key hierarchies) – it is not a toggle switch between the two, but each is used for a different purpose:

  • The "Owner" root key is used to encrypt further keys (including sealing the BitLocker volume key). It is always generated fresh when the user performs the "Take ownership" step. Windows does this step automatically at boot time (Is Initialized: True) and if you clear the TPM then Windows will generate a new key again.

    Certain operations on the "Owner" root key are password-protected (e.g. Windows generates a random password and throws it away). For that reason, initializing the Owner hierarchy is left to the OS – without knowing the password, the firmware can only clear it.

  • The "Endorsement" root key is used to sign attestation certificates (i.e. proofs that a real genuine Infineon TPM is performing the operation). It is factory-set and essentially read-only. BitLocker does not use this key.

  • There is also a "Platform" hierarchy that is used by the firmware itself. Your firmware might use it to store Secure Boot variables within the TPM's NVRAM. I believe HP laptops also store the firmware "setup" password this way.

If you're given a choice between "custom" and "factory default" keys, then it's most likely for Secure Boot, not for the TPM.


(Should you generate your own Secure Boot keys? Probably not. Doing so won't give you additional security for BitLocker or when booting Windows in general. But it can be useful for implementing BitLocker-alike systems on Linux.)

u1686_grawity
  • 452,512
  • Thank you very much for the detailed response! So it sounds like loading those factory default keys was fine/the way I was supposed to do it. I'm just wondering, I've read lots of horror stories of data loss related to people not backing up certain keys used in their Bitlocker encryption - how do I know which of these keys are being used for Bitlocker? And more generally, if I'm not generating any new keys, where is the uniqueness coming from that makes Bitlocker secure? – the_midnight_developer Nov 26 '20 at 22:57
  • In a sense, they all are, but at the same time, none of them are. What BitLocker does is use the TPM to bind to a specific system state – run manage-bde c: -protectors -get and it'll show you the TPM PCR list that it uses. Each PCR records specific events (e.g. PCR[7] records the contents of PK/KEK/db/dbx), and what matters is that they're byte-for-byte identical. – u1686_grawity Nov 26 '20 at 23:05
  • As for data loss, BitLocker supports multiple independent "protectors" – the same disk can have a TPM-sealed key, a numeric recovery key, a recovery key stored on USB stick, and so on. The horror stories are usually either from people who didn't write down the recovery key when enabling BitLocker manually, or from people who didn't know BitLocker was enabled since day one (under the name of "Device Encryption"). In the latter case, unfortunately, Windows only uses the TPM and doesn't seem to offer a recovery key by default, unless manually added, so it's a bit risky. – u1686_grawity Nov 26 '20 at 23:08