# Full Disk Encryption (FDE) Strategy: LUKS trifft auf TPM 2.0

TL;DR / Management Summary Festplattenverschlüsselung ist kein optionales Feature, sondern eine Compliance-Anforderung (BSI / ISO 27001). Während die manuelle Passworteingabe (Artikel 021) sicher ist, skaliert sie nicht für hunderte Laptops oder Remote-Server. In diesem Modul lernen wir die Enterprise FDE-Strategie: Wir binden LUKS an das hardwareseitige TPM 2.0 (Trusted Platform Module). Das Ergebnis: Der Server bootet automatisch, solange die Hardware unmanipuliert ist, bleibt aber bei Diebstahl der Disk verschlüsselt.

# 1. Einführung & Architektur

Die Bindung an die Hardware.

TPM 2.0 ist ein Chip auf dem Mainboard, der kryptografische Schlüssel sicher verwahren kann. Wir nutzen ihn, um das LUKS-Passwort erst freizugeben, wenn der Bootloader und die Firmware-Integrität (Secure Boot) verifiziert sind.

# Die Vertrauenskette (Mermaid)

graph TD
    A[Hardware: TPM 2.0] --> B[Secure Boot Check]
    B -->|Verified| C[systemd-cryptenroll]
    C -->|Extract Secret| D[LUKS Header]
    D -->|Unlock| E[Encrypted Root FS]
    subgraph "Protection"
        F[Anti-Tamper]
        G[Brute Force Protection]
    end
    A --- F
    A --- G

# 2. Implementierung: LUKS an TPM binden

Kein Passwort mehr beim Booten.

Voraussetzung: Ein modernes Linux (Arch, SLES 15 SP4+, RHEL 9) mit Systemd v248+.

# Schritt 1: Hardware-Check

# Prüfen, ob TPM 2.0 erkannt wurde
systemd-cryptenroll --tpm2-device=list

# Schritt 2: Bindung durchführen

Wir fügen einen neuen LUKS-Slot hinzu, der den Schlüssel aus dem TPM bezieht.

# PCR 7 steht für 'Secure Boot State'
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sda2

# Schritt 3: Dracut / Mkinitcpio anpassen

Stellen Sie sicher, dass tpm2-tss in Ihr Initramfs eingebaut wird (siehe Artikel 012).

# 3. Compliance & Compliance-Reporting

Nachweis der Verschlüsselung.

Bei einem Audit müssen Sie beweisen, dass alle Server verschlüsselt sind.

# Automatisierter Check via Ansible

- name: Verify Encryption Status
  shell: cryptsetup isLuks /dev/sda2 && echo "ENCRYPTED"
  register: encrypt_status
  failed_when: encrypt_status.stdout != "ENCRYPTED"

# 4. Day-2 Operations: Rekonstruktion & Recovery

Der Notfallplan.

TPM-Bindung ist gefährlich bei Hardware-Defekten. Wenn das Mainboard stirbt, ist der TPM-Key weg.

# Die Recovery-Strategie

1. Recovery Key: Nutzen Sie systemd-cryptenroll --recovery-key, um einen langen Recovery-String zu generieren.
2. Zentrales Backup: Speichern Sie diesen Key in einem zentralen Tresor (z.B. HashiCorp Vault oder Bitwarden).
3. Slot-Hygiene: Behalten Sie immer einen Slot mit einem klassischen Admin-Passwort.

# 5. Troubleshooting & “War Stories”

Wenn der TPM-Unlock scheitert.

# Story 1: “Der BIOS-Update Schock”

Symptom: Nach einem BIOS-Firmware-Update fragt der Server plötzlich wieder nach dem Passwort. Ursache: Das BIOS-Update hat die PCR-Werte im TPM verändert. Da die Messung nun nicht mehr zum gespeicherten Stand passt, gibt das TPM den Schlüssel nicht frei. Lösung: Passwort manuell eingeben, den TPM-Slot in LUKS löschen und mit den neuen PCR-Werten neu binden.

# Story 2: “Der falsche PCR-Satz”

Symptom: Der Admin hat den Key an PCR 0, 1, 7 gebunden. Nun führt jede Änderung an der Boot-Reihenfolge (z.B. Einstecken eines USB-Sticks) dazu, dass der Server nicht mehr automatisch bootet. Ursache: PCR 0 und 1 reagieren auf Hardware-Änderungen. Lösung: Nutzen Sie für Laptops und Server in der Regel nur PCR 7 (Secure Boot State). Das ist der beste Kompromiss aus Sicherheit und Wartungsfreundlichkeit.

# 6. Fazit & Empfehlung

• Pflicht: FDE ist die Basis für jede Security-Zertifizierung.
• Wahl: Nutzen Sie TPM 2.0 Bindung für Laptops und Edge-Server. Für Core-RZ-Server ist NBDE (Artikel 086) oft flexibler.
• Wichtig: Testen Sie den Recovery-Key einmal pro Jahr!

# Anhang: Cheatsheet