Understanding the term “default” in the realm of computer security, especially when discussing Secure Boot and Trusted Platform Modules (TPMs), can be crucial. Often, users encounter options related to “default keys” during system setup or security configurations, leading to questions about their implications. This article aims to clarify what “default” signifies in these contexts, particularly addressing the common confusion surrounding Secure Boot keys and TPM keys.
It’s important to first distinguish between Secure Boot and TPMs, as they serve different but complementary security functions. Secure Boot is a feature of the Unified Extensible Firmware Interface (UEFI) that ensures your PC boots using only software that is trusted by the Original Equipment Manufacturer (OEM). On the other hand, a TPM is a hardware module designed to secure hardware by integrating cryptographic keys into devices.
When you encounter mentions of “default keys” in relation to Secure Boot, it’s highly likely referring to the keys that are pre-installed by the manufacturer to enable Secure Boot functionality out-of-the-box. These are not related to BitLocker encryption keys, which is a common misconception.
Secure Boot and Factory Default Keys
Secure Boot operates using cryptographic keys to validate the digital signatures of bootloaders, operating systems, and UEFI drivers. The “default set” of keys in Secure Boot typically includes:
- Platform Key (PK): Manages the secure boot process and can be used to update or replace other keys.
- Key Exchange Key (KEK): Authorizes updates to the database (db) and forbidden signature database (dbx). In typical scenarios, Microsoft and sometimes Canonical Ltd. (for Ubuntu) KEKs are included by default, allowing their signed operating systems to boot.
- Signature Database (db): Also known as the “allowed signature database,” this list contains the digital signatures of trusted bootloaders, OS loaders, and drivers. By default, it includes signatures from Microsoft and potentially the PC manufacturer.
- Forbidden Signature Database (dbx): This database contains signatures of known malicious or vulnerable software that should be blocked from booting.
These “default” Secure Boot keys are essentially public certificates. They are not private keys used for encryption, and crucially, they are not involved in encrypting your data. Their sole purpose is to verify the digital signatures of software during the boot process, ensuring that only trusted and authorized software is allowed to run.
Firmware might store these Secure Boot variables in the TPM’s Non-Volatile RAM (NVRAM) as a security measure to meet the “tamper-resistant” requirement of the specification. However, this is a storage implementation detail and doesn’t change the fundamental purpose of these keys.
TPM Key Hierarchies and the Concept of “Default”
The TPM 2.0 specification defines different key hierarchies, each with its own purpose. Understanding these hierarchies helps clarify the meaning of “default” within the TPM context:
1. Owner Hierarchy and User-Generated Keys
The “Owner” hierarchy in TPM is managed by the operating system. The root key of this hierarchy, the Owner key, is paramount for securing further keys within the TPM, including those used for BitLocker volume encryption. This Owner key is always generated anew when the user, or in most cases, the operating system, takes “ownership” of the TPM.
In Windows, this “take ownership” step happens automatically during the boot process if the TPM is detected and initialized (Is Initialized: True). If you clear the TPM, Windows will again generate a new Owner key upon the next boot. This automatic generation by the OS can be considered the “default” behavior for the Owner hierarchy.
Certain operations related to the Owner root key are protected with a password. Windows typically generates a random password for this purpose and discards it, managing the Owner hierarchy internally. This is why firmware usually doesn’t initialize the Owner hierarchy; it’s left to the OS to manage securely.
2. Endorsement Hierarchy and Factory Default Keys
The “Endorsement” hierarchy is different. Its root key, the Endorsement Key (EK), is factory-set by the TPM manufacturer, like Infineon. This EK is essentially read-only and is used to sign attestation certificates. Attestation is the process of cryptographically proving that a genuine TPM, manufactured by a specific vendor, is performing an operation.
The Endorsement Key and its associated certificates are used to verify the authenticity and integrity of the TPM itself. BitLocker, however, does not directly use the Endorsement Key. It primarily relies on the Owner hierarchy for securing encryption keys. The factory-set nature of the EK is the “default” for attestation and TPM identity verification purposes.
3. Platform Hierarchy
The “Platform” hierarchy is utilized by the system firmware itself. Firmware might use this hierarchy to store Secure Boot variables within the TPM’s NVRAM for enhanced security. Some laptop manufacturers, like HP, might also store firmware “setup” passwords within the TPM using this hierarchy. The usage and “default” settings of the Platform hierarchy are largely dependent on the specific firmware implementation.
Custom vs. Factory Default Keys: Context Matters
When you are presented with a choice between “custom” and “factory default” keys in system settings, it’s crucial to understand the context. In most scenarios, especially within the UEFI/BIOS settings, this choice likely pertains to Secure Boot keys, not TPM keys.
Choosing “factory default” for Secure Boot will typically install the standard set of keys that allow booting of Windows and other common operating systems. Opting for “custom” keys would imply that you intend to manage the Secure Boot keys yourself, which is generally not necessary nor recommended for typical users wanting to use BitLocker or simply boot Windows securely.
Should You Generate Your Own Keys?
The question of generating your own keys depends heavily on what keys you are referring to.
-
Secure Boot Keys: For most users running Windows, generating custom Secure Boot keys is not necessary and offers no additional security benefits for BitLocker or general Windows booting. Sticking with factory default Secure Boot keys is usually the best and most straightforward approach. Managing custom Secure Boot keys is a complex task and is primarily relevant in very specific scenarios, such as creating a highly locked-down system or implementing custom secure boot solutions, often in Linux environments.
-
TPM Owner Key: You do not manually generate the TPM Owner key. This process is automatically handled by the operating system when it takes ownership of the TPM. User intervention in Owner key generation is generally not required or even possible in standard operating system usage.
In conclusion, “default” in the context of Secure Boot and TPM can have different meanings depending on whether you are referring to Secure Boot keys or TPM key hierarchies. Factory default Secure Boot keys are designed for ease of use and compatibility with standard operating systems, while the “default” behavior for the TPM Owner hierarchy is automatic generation by the OS. Understanding these distinctions is key to correctly configuring system security and avoiding potential misconfigurations.
