Proposal: Optional TPM-backed Header Sealing with Non-Derived Recovery Fallback

[Sébastien]

Hi everyone,

I would like to propose a significant enhancement to VeraCrypt’s security model: Optional TPM-wrapped Header Sealing. This feature is designed to protect users against sophisticated physical attacks (theft, "Evil Maid") by anchoring the volume's accessibility to the specific hardware.

The Problem

Currently, an attacker who steals a disk can perform an offline brute-force attack on the header using unlimited GPU/FPGA clusters. The only defense is the user's password entropy and the PIM.

The Proposal: "Hardware-Wrapped Headers"
The concept is to optionally wrap the encrypted VeraCrypt header in an additional layer of encryption that is "sealed" within the TPM (Trusted Platform Module).

The Workflow:

1. TPM Sealing: During volume creation, VeraCrypt generates a unique hardware key stored inside the TPM.
2. Accessing the Volume: When mounting, the user enters their password. The software uses a derivation of this password to request the hardware key from the TPM.
3. Anti-Hammering: The attacker is now forced to interact with the TPM chip itself. Because of the TPM’s anti-hammering logic (lockout after X failed attempts), offline brute-forcing becomes impossible.

Portability & The "Infinite" Barrier (Non-Derived Recovery Key)

To prevent the TPM from becoming a single point of failure (hardware failure), I propose a decoupled recovery system that cannot be bypassed by software calculations:

• Non-Derived Recovery Key: VeraCrypt would generate a random, high-entropy Recovery Key (e.g., a 256-bit string) during encryption.
• Decoupled Security: Crucially, this key is NOT derived from the user's password. It is a completely independent secret.
• The Math: An attacker without the original TPM chip cannot use the user's password to "calculate" the TPM layer's key. They would be forced to brute-force a random 256-bit string, which is mathematically infeasible.

Why this is a major security upgrade:

1. From Virtual to Physical: It shifts the attack surface from an offline software attack (unlimited speed) to a throttled, hardware-dependent physical attack.
2. Enhanced Personal Safety (Rubber-hose Cryptanalysis): This system provides a unique tactical advantage. If a user is coerced into revealing their password, they can truthfully state that the volume is hardware-locked and they do not know the 256-bit Recovery Key by heart.
3. Strategic Delay: By storing the Recovery Key in a secure off-site location (e.g., a bank vault), the user creates a mandatory physical delay. This forces a captor to move into a public or high-security area to retrieve the key, providing an opportunity to seek help.
4. No Single Point of Failure: If a TPM vulnerability is discovered, the security simply reverts to the current VeraCrypt standard. It adds a layer of "armor" without replacing the core cryptographic principles.

I believe this would make VeraCrypt the most resilient open-source encryption tool available, effectively neutralizing the advantage of offline brute-force clusters while adding a layer of physical safety for the user.

Looking forward to your thoughts.

Best regards.

[Sébastien]

Hi everyone,

To follow up on the proposal for TPM-wrapped headers, I’ve synthesized the technical requirements to ensure this feature meets VeraCrypt’s high security standards while addressing common hardware-related vulnerabilities (Evil Maid, Bus Sniffing, and Portability).

1. Integrity Binding via PCR Sealing

To neutralize "Evil Maid" attacks, the TPM-wrapped secret should be sealed against PCRs 0, 1, 2, and 7. The TPM will strictly refuse to participate in the decryption process if the BIOS, Secure Boot state, or Bootloader has been modified.

2. Blind Key Wrapping (Eliminating the Confirmation Oracle)

A major concern with TPMs is that they can act as a "confirmation oracle" (letting an attacker know a password is correct simply because the TPM released a secret).

• The Solution: I propose a Non-Interactive Blind Wrapping. The password-derived entropy is sent to the TPM, which performs a cryptographic transformation and returns a result regardless of the input's validity.
• The Benefit: There is no "Access Denied" or "Success" signal from the TPM. The attacker must complete the entire decryption chain to verify a password, making bus-sniffing or TPM-monitoring useless for password validation.

3. Protection Against Bus Sniffing & Cold Boot

• Encrypted Sessions: Communication between the CPU and TPM must use TPM 2.0 Salted & Encrypted Sessions to prevent sniffing secrets on the motherboard traces (LPC/SPI bus).
• Memory Encryption: When active, VeraCrypt should leverage hardware memory encryption (Intel TME / AMD SME) to ensure that master keys are never stored in "plain" RAM, protecting against Cold Boot forensic attacks.

4. The "Non-Deterministic Recovery Key" (NDRK)

To prevent data loss due to motherboard failure, a dual-slot header is used:

• Slot A (TPM-Bound): Requires the physical TPM + User Password.
• Slot B (Recovery): Requires a random 256-bit string (NDRK) generated at creation + User Password.
• This NDRK is not derived from the password, ensuring that an attacker with the laptop cannot bypass the TPM throttled-path. The user stores this NDRK safely off-site.

5. Active Defense: Policy-Based "Auto-Nuke"

Leveraging TPM Authorization Policies, we can implement a hardware-enforced self-destruct:

• Hardware Lockout/Wipe: After $X$ failed attempts, the TPM is instructed to permanently invalidate the sealed secret.
• Bypass-Proof: Since this logic resides within the TPM's firmware, it cannot be bypassed by recompiling a modified version of VeraCrypt.
• Duress Wipe: A specific "Duress Password" can trigger an immediate wipe of the TPM-resident secret, rendering the volume inaccessible on that machine.

6. Philosophy & Compatibility

• Plausible Deniability: The TPM remains agnostic to the existence of hidden volumes.
• Optional Armor: This is a strictly "opt-in" layer that adds hardware-dependent security without replacing VeraCrypt's proven cryptographic foundations.

I believe this architecture would make VeraCrypt the most resilient tool against professional-grade physical and offline attacks.

Best regards.