Festplattenverschlüsselung, wirklich?

Ich habe einmal zugesehen, wie ein Firmen-Laptop in einem Kontrollraum in weniger als fünf Minuten leergeräumt wurde. Das Gerät war „verschlüsselt” — die IT hatte es zertifiziert, der Konformitätsaufkleber klebte auf der Rückseite. Nur befand es sich im Ruhezustand, der Deckel war zugeklappt, es lag in einer Tasche im Auto des Geschäftsführers, während dieser zu Mittag aß. Die Schlüssel lagen im RAM, die Sitzung war offen. Die Person, die sich die Tasche holte, musste das Passwort nicht kennen. Sie schloss eine Box an, umging den Sperrbildschirm und kopierte, was sie wollte. Die Festplatte war verschlüsselt. Die Daten nicht.

Die übliche Falle

„Meine Festplatte ist verschlüsselt.” Das ist einer der am meisten missverstandenen Sätze der gesamten IT-Sicherheit. In 95 % der Fälle bedeutet er „ich habe in den Einstellungen ein Häkchen gesetzt” oder „die IT hat beim Rollout BitLockerMicrosoft-Lösung zur Festplattenverschlüsselung, in Windows Pro/Enterprise integriert.Zum Glossar aktiviert”. Er bedeutet nicht „meine Daten sind in diesem Moment geschützt”. Das sind zwei verschiedene Aussagen, und genau auf die Verwechslung der beiden setzt ein Angreifer mit physischem Zugriff.

Die Festplattenverschlüsselung schützt Ihre Daten in einem einzigen, ganz bestimmten Zustand: wenn das Gerät ausgeschaltet ist. Das ist alles. Sobald das System hochgefahren und Sie angemeldet sind, werden die Entschlüsselungsschlüssel in den Arbeitsspeicher geladen, und jede Datei ist lesbar, als gäbe es die Verschlüsselung nicht. Das Betriebssystem entschlüsselt fortlaufend im laufenden Betrieb, völlig transparent — genau das ist das Ziel: dass Sie im Gebrauch keinen Unterschied spüren. Aber diese Transparenz für Sie ist auch eine Transparenz für jeden, der das Gerät in diesem Zustand in die Hände bekommt.

Die richtige Frage lautet daher niemals „ist es verschlüsselt?”. Sie lautet „in welchem Zustand befindet sich mein Gerät in dem Moment, in dem ein Dritter darauf zugreifen kann?”. Ausgeschaltet, im Ruhezustand, im Standby, mit gesperrtem Bildschirm: Diese vier Zustände bieten bei exakt derselben aktivierten Verschlüsselung radikal unterschiedliche Schutzniveaus. Der vorherrschende Diskurs — „aktivieren Sie die Verschlüsselung und Sie sind sicher” — unterschlägt diese ganze Nuance. Und genau in dieser unterschlagenen Nuance verstecken sich nahezu alle erfolgreichen Datenexfiltrationen von angeblich „verschlüsselter” Hardware.

Die andere Hälfte der Falle besteht darin zu glauben, die Verschlüsselung verteidige gegen Bedrohungen, die abzudecken sie nie vorgesehen war. Die Festplattenverschlüsselung tut nichts gegen Malware, die in Ihrer Sitzung läuft: Das Schadprogramm liest Ihre entschlüsselten Dateien genau wie Sie. Sie tut nichts gegen Phishing, gegen einen Passwortdiebstahl, gegen einen Fernzugriff auf Ihr eingeschaltetes Gerät, gegen ein schlecht geschütztes Cloud-Backup. Sie schützt Ihre Daten auch nicht mehr, sobald diese die Festplatte verlassen haben — versendeter Anhang, auf einen USB-Stick kopierte Datei, in einer synchronisierenden Anwendung geöffnetes Dokument. Die Festplattenverschlüsselung beantwortet eine einzige, enge, aber reale Frage: „Jemand bekommt mein Gerät physisch in die Hände — was kann er daraus ziehen?”. Diesen punktuellen Schutz mit einem allgemeinen Schutz zu verwechseln, heißt zu glauben, ein Türschloss schütze Sie, während das Fenster offen steht.

Die vier Zustände: wann es schützt, wann nicht

Dieselbe Verschlüsselung, einmal aktiviert, schützt Sie je nach Zustand des Geräts vollständig oder gar nicht. Hier sind die vier, vom sichersten zum ungeschütztesten.

Gerät ausgeschaltet (Cold State). Der einzige Zustand, in dem die Verschlüsselung ihre Arbeit vollständig erledigt. Die Festplatte enthält nur verschlüsselte Daten, der Schlüssel liegt nirgends im Speicher, und wer die Festplatte oder das Gerät stiehlt, liest ohne die Passphrase oder den Wiederherstellungsschlüssel nichts. Das ist das Szenario, für das die Festplattenverschlüsselung konzipiert wurde: der Diebstahl ausgeschalteter Hardware. Genau in diesem Fall halten FileVaultIn macOS seit OS X Lion integrierte Festplattenverschlüsselung.Zum Glossar, BitLocker und LUKSLinux-Standard zur Festplattenverschlüsselung, normalerweise via cryptsetup und dm-crypt.Zum Glossar ihre Versprechen.

Gerät im Ruhezustand (Hibernation). Der Ruhezustand schreibt den Inhalt des RAM auf die verschlüsselte Festplatte und unterbricht dann die Stromzufuhr. Richtig konfiguriert ist das fast so solide wie ein vollständiges Herunterfahren, weil der Arbeitsspeicher geleert und verschlüsselt auf der Festplatte abgelegt wird. Unter Windows mit BitLocker und PIN schützt der Ruhezustand angemessen. Auf Macs mit Apple Silicon sperrt der Tiefschlaf die Schlüssel in der Secure Enclave. Die Falle: Viele Geräte sind so konfiguriert, dass sie nie in den Ruhezustand wechseln und unbegrenzt im einfachen Standby bleiben.

Gerät im Standby (Sleep / Suspend). Der Standardzustand, wenn Sie den Deckel zuklappen. Der RAM bleibt unter Spannung, also sind die Entschlüsselungsschlüssel dort vorhanden, im Klartext. Ein Angreifer mit physischem Zugriff kann sie extrahieren — per Speicher-ForensikDisziplin, die nach einem Vorfall digitale Spuren analysiert, um zu rekonstruieren, was passiert ist.Zum Glossar, per DMAAuf dem Mainboard verlöteter Kryptochip, der Schlüssel speichert und die Boot-Integrität bestätigt.Zum Glossar-Angriff über einen schlecht abgesicherten Thunderbolt-Port oder per Cold Boot — und die Festplatte entschlüsseln, ohne Ihr Passwort je zu kennen. Das ist der gefährlichste Zustand, gerade weil es der Zustand ist, in dem Ihr Laptop den Großteil seines Lebens verbringt.

Gerät eingeschaltet, Bildschirm gesperrt. Die Volumes sind eingehängt und entschlüsselt. Der Sperrbildschirm ist eine Software-Tür vor einer bereits geöffneten Festplatte. Das Umgehen dieses Bildschirms berührt die Verschlüsselung überhaupt nicht — es greift das Authentifizierungssystem der Sitzung an, das seine eigene Angriffsfläche hat (lokale Konten, Exploits des Login-Bildschirms, Debug-Ports). Die Verschlüsselung spielt hier keine schützende Rolle.

Die praktische Konsequenz ist brutal und kontraintuitiv: Das Gerät, das Sie für „geschützt, weil verschlüsselt und gesperrt” halten, in Ihrer Tasche, im Meeting, im Hotel, befindet sich im am wenigsten geschützten Zustand überhaupt. Den Deckel zuzuklappen sichert nichts. Nur ein vollständiges Herunterfahren bringt das Gerät zurück in den Cold State.

Versetzen Sie sich zwei Minuten in die Lage des Angreifers, das ist der einzige Weg zu verstehen, warum der Zustand wichtiger ist als die Verschlüsselung. Sie holen einen Laptop aus einer Tasche. Das Erste, was Sie tun: Sie prüfen, ob er warm ist, ob die LED blinkt, ob ein Bildschirm aufleuchtet, wenn Sie die Maus bewegen. Ein lauwarmes Gerät im Standby ist ein Geschenk. Sie schließen es ans Stromnetz an, damit es nicht ausgeht, legen es auf eine Analysestation und arbeiten an einem Ziel, dessen Schlüssel bereits im Speicher liegen. Das Sitzungspasswort interessiert Sie nicht einmal. Umgekehrt lässt Sie ein kaltes, ausgeschaltetes Gerät vor einem verschlüsselten Block stehen: Sie können es monatelang behalten, Brute-Force laufen lassen, das bringt nichts, wenn die Passphrase korrekt ist. Genau diese Asymmetrie heben die meisten Menschen auf, indem sie einfach den Deckel zuklappen, statt herunterzufahren.

Das korrekte Bedrohungsmodell lautet daher nicht „riskiere ich den Diebstahl meiner nackten SSD?” — ein seltenes Szenario, das voraussetzt, dass man Ihr Gerät aufschraubt —, sondern „in welchen Situationen verlässt mein Gerät meine Kontrolle, und in welchem Zustand ist es dann?”. Ehrliche Antwort für die meisten: im Meeting (gesperrt, eingehängt), im Zug (Standby), im Hotel beim Frühstück (Standby), einem Techniker übergeben (eingeschaltet oder im Standby), an einer Grenze beschlagnahmt (je nach Ihrer Disziplin). In fast allen diesen Fällen dominieren Standby oder Sperrung, und die Verschlüsselung spielt keine reale schützende Rolle.

Nach Betriebssystem: was wirklich umgesetzt ist und wo es bricht

Alle drei Systeme verschlüsseln. Was sie unterscheidet, ist das, was beim Start und beim Entsperren passiert — und genau dort entscheiden sich die echten Schutzunterschiede.

macOS — FileVault 2. XTS-AES-128-Verschlüsselung auf APFS-Volumes. Auf Macs mit T2-Chip (gehobene Intel-Modelle seit 2018) und allen Apple-Silicon-Geräten werden die Hardwareschlüssel von der Secure Enclave verwaltet und gelangen nie exponiert in den RAM. Konkret: Auf einem MacBook der M-Serie löst das Zuklappen des Deckels eine echte Sperrung der Schlüssel durch die Secure Enclave aus; der schnelle Neustart kommt von einer Neubeschaffung des Schlüssels beim Entsperren, nicht von einem im Speicher verbliebenen Schlüssel. Das ist architektonisch deutlich solider als alles vor dem T2.

Ein Detail, das viele Mac-Nutzer überrascht: Auf Apple Silicon ist das Systemvolume in Wirklichkeit dauerhaft auf Hardwareebene verschlüsselt, unabhängig von FileVault. Was FileVault hinzufügt, ist die Anforderung einer Benutzerkennung, um den Schlüssel beim Start freizugeben. Ohne FileVault ist der Schlüssel ohne Passwort ableitbar, und ein gestohlener Mac startet direkt auf den Desktop eines passwortlosen Kontos. Anders gesagt: „die Festplatte ist verschlüsselt” ist technisch sogar bei deaktiviertem FileVault wahr — und völlig irreführend, denn ohne FileVault schützt Sie die Verschlüsselung vor nichts. Das ist das perfekte Beispiel für die Kluft zwischen „verschlüsselt” und „geschützt”. Die verbleibende Schwachstelle ist nicht technisch, sondern organisatorisch: Beim Aktivieren schlägt macOS vor, den Wiederherstellungsschlüssel in iCloud zu speichern. Wenn Sie zustimmen, wird der Schutz Ihrer Festplatte so stark wie Ihr Apple-Konto — und nicht stärker. Eine gephishte Apple-ID, und der Schlüssel folgt.

Windows — BitLocker. Das im Unternehmen am häufigsten ausgerollte System und dasjenige, das bei der Konfiguration am häufigsten scheitert. BitLocker kann im reinen TPMAuf dem Mainboard verlöteter Kryptochip, der Schlüssel speichert und die Boot-Integrität bestätigt.Zum Glossar-Modus laufen: Der Schlüssel wird beim Start aus dem TPM 2.0 abgeleitet, und wenn die Integritätsmessungen des Boots stimmen, entschlüsselt sich die Festplatte von selbst, ohne jede Eingabe. Das ist die bequeme Voreinstellung vieler großer Bestände, weil kein Support gern Tickets „ich habe meine PIN vergessen” bearbeitet. Es ist auch das Loch: Ein gestohlenes Gerät mit geladenem Akku startet und entschlüsselt sich selbst bis zum Login-Bildschirm, und manche Angriffe (DMA, Abhören des Busses zwischen TPM und CPU auf ungesicherter Hardware) bergen den Schlüssel, ohne irgendetwas zu kennen. Forscher haben öffentlich BitLocker-Schlüssel extrahiert, indem sie den LPC- oder SPI-Bus zwischen einem diskreten TPM und dem Prozessor auf billigen Geräten abhörten — die Operation erfordert einen Lötkolben und ein paar Dutzend Euro Material, kein staatliches Labor.

Der Modus TPM + PIN dagegen verlangt einen Code vor dem Laden des Betriebssystems: Der Schlüssel wird gemeinsam aus dem TPM und dem, was Sie tippen, abgeleitet. Die PIN verlässt nie den Perimeter des sicheren Starts, und ohne sie gibt das TPM nichts frei. Das ist die einzige BitLocker-Konfiguration, die ich gegen Gerätediebstahl als ernsthaft betrachte. Aktivierung per Gruppenrichtlinie (Zusätzliche Authentifizierung beim Start anfordern) oder per Befehlszeile als Administrator: manage-bde -protectors -add C: -TPMAndPIN. Eine noch strengere Variante, TPM + PIN + USB-Startschlüssel, existiert für stark exponierte Profile, zum Preis einer lästigen Ergonomie im Alltag.

Linux — LUKS / dm-crypt. Die Standardschicht unter Linux und konzeptionell die transparenteste: kein stilles automatisches Entsperren als Voreinstellung, der Schutz beruht auf der beim Boot eingegebenen Passphrase. Was Sie tippen, ist das, was schützt, Punkt. LUKS2 (Standard unter Ubuntu 20.04+, Fedora 33+) verwendet Argon2id als Ableitungsfunktion — resistent gegen Angriffe per GPU und ASIC, anders als das alte PBKDF2. Konkret zwingt Argon2id den Angreifer, bei jedem Passwortversuch Speicher und Zeit aufzuwenden, was massenhaftes Brute-Force auf Grafikkarten wirtschaftlich uninteressant macht; PBKDF2 dagegen brach bei industriellen Taktraten. LUKS verwaltet außerdem bis zu acht Schlüsselplätze (Keyslots): Sie können eine menschliche Passphrase, einen langen, offline gespeicherten Wiederherstellungsschlüssel und einen Netzwerk-Unlock-Mechanismus (Clevis/Tang) für Server haben, jeweils im eigenen Slot, unabhängig widerrufbar.

Die klassische Falle unter Linux ist nicht die Verschlüsselung der Hauptfestplatte, sondern das, was daneben passiert: Swap und /boot. Ist Ihre Auslagerungspartition nicht verschlüsselt, lecken Fragmente von Schlüsseln und sensiblen Daten im Klartext auf die Festplatte — ein ganzer Speicherauszug kann bei einem Ruhezustand dort landen. Die /boot-Partition ist traditionell im Klartext, weil der Bootloader sie vor jeder Entschlüsselung lesen muss; ein Angreifer kann dort den Kernel oder das initramfs verändern (sogenannter „Evil-Maid”-Angriff), um Ihre Passphrase beim nächsten Start abzufangen. Die Konfiguration LVM-on-LUKS (die gesamte Volume-Gruppe, Swap inklusive, in einem verschlüsselten Container) löst das Swap-Problem; die Signierung des Boots per Secure Boot oder ein /boot auf einem USB-Stick, den Sie bei sich tragen, adressiert die Evil Maid. Schnelle Prüfung: lsblk -f muss Ihre sensiblen Partitionen als crypto_LUKS zeigen, nicht als nacktes ext4.

Der richtige Ansatz: für den Zustand konfigurieren, nicht für das Häkchen

Die Verschlüsselung zu aktivieren ist eine Fünf-Minuten-Entscheidung, die man einmal trifft. Sie tatsächlich schützend zu machen, hängt an drei Einstellungen, die man fast systematisch vergisst.

Erste Einstellung: die Pre-Boot-Sperre. Bei BitLocker ist das die PIN (Modus TPM + PIN). Bei LUKS ist es die Passphrase beim Boot (bereits Standard). Auf macOS Apple Silicon übernimmt die Secure Enclave diese Rolle nativ, sobald FileVault aktiv ist. Ohne diese Sperre vor dem Laden des Betriebssystems schützt die Verschlüsselung nur gegen den Diebstahl der nackten, aus dem Gerät ausgebauten Festplatte — nicht gegen den Diebstahl des ganzen Geräts, was doch das realistische Szenario ist. Das ist der Unterschied zwischen „geschützt gegen jemanden, der meine SSD ausbaut” und „geschützt gegen jemanden, der mit meinem Laptop davongeht”.

Zweite Einstellung: das Verhalten beim Zuklappen des Deckels. Erzwingen Sie für jeden mobilen Kontext den Ruhezustand oder das Herunterfahren statt des einfachen Standbys. Unter Windows den Ruhezustand nach kurzer Inaktivität. Unter Linux konfigurieren Sie suspend-then-hibernate oder deaktivieren Sie den Standby zugunsten des Ruhezustands. Das Ziel: dass das Gerät von selbst den Zustand verlässt, in dem die Schlüssel im RAM leben, ohne von Ihrer Disziplin abzuhängen.

Dritte Einstellung, die am häufigsten sabotierte: die Aufbewahrung des Wiederherstellungsschlüssels. Der Wiederherstellungsschlüssel gewährt vollständigen Zugriff auf die Festplatte ohne weitere Prüfung. Er ist ein Generalschlüssel. Ihn in iCloud auf genau dem Gerät zu speichern, das er schützt, in einem Microsoft-Konto ohne MFA, in einer Textdatei auf dem Desktop oder in einer „an sich selbst gesendeten” Mail, hebt die Verschlüsselung durch die Hintertür auf. Die Regel ist einfach: Der Wiederherstellungsschlüssel lebt auf einem vom Gerät getrennten Träger. Papierkopie in einem Tresor oder Passwort-ManagerAnwendung, die einzigartige Passwörter für jeden Dienst speichert und generiert.Zum Glossar, verschlüsselt mit starker MFA, installiert auf einem anderen Gerät. Nie auf dem betroffenen Gerät.

Ein letzter Punkt zum Wiederherstellungsschlüssel, den man fast immer zu erklären vergisst: Er dient nicht nur dazu, ein vergessenes Passwort zu beheben. Bei BitLocker misst das TPM den Startzustand; jedes Firmware-Update, jede Änderung der Boot-Reihenfolge oder jeder BIOS-Reset verändert diese Messungen und löst beim nächsten Einschalten eine Abfrage des Wiederherstellungsschlüssels aus. Das ist normales Verhalten, kein Angriff — aber wenn der Schlüssel nirgends liegt, sind Sie nach einem schlichten, etwas aggressiven Windows-Update aus Ihrem eigenen Gerät ausgesperrt. Daher die Bedeutung eines sauberen Escrows: Der Schlüssel muss von Ihnen wiederherstellbar sein, an einem Ort, den Sie kontrollieren, und für jeden anderen unzugänglich. Diese beiden Anforderungen ziehen in entgegengesetzte Richtungen, und genau darin liegt die ganze Herausforderung seiner Aufbewahrung.

Und vor all dem: Prüfen Sie, dass es wirklich aktiv ist. Auf übernommenen, migrierten oder neu bereitgestellten Geräten deaktiviert sich die Verschlüsselung manchmal, ohne dass es jemand bemerkt — eine Systemneuinstallation, die FileVault nicht reaktiviert, ein hinzugefügtes unverschlüsseltes Volume, ein aus einer Übernahme geerbter Bestand. sudo fdesetup status auf macOS muss FileVault is On anzeigen. Get-BitLockerVolume -MountPoint C: unter Windows muss ProtectionStatus: On mit einem Protector vom Typ TpmPin zeigen — sehen Sie nur Tpm, sind Sie im Modus ohne PIN, das ist zu korrigieren. sudo cryptsetup luksDump /dev/sdaX unter Linux bestätigt das Format (LUKS2) und die Ableitungsfunktion (argon2id). Man prüft, man nimmt nicht an — und man prüft nach jeder schweren Wartungsoperation erneut.

Was das konkret bedeutet

Fehler, die man ständig sieht

• BitLocker ohne PIN, Standard beim Rollout. Das Gerät entschlüsselt sich beim Start von selbst. Schutz nur gegen den Diebstahl der nackten Festplatte, nicht gegen den Diebstahl des Geräts.
• FileVault-Wiederherstellungsschlüssel in iCloud, auf dem Mac, den er schützt. Die Apple-ID zu kompromittieren genügt, um den Schlüssel zu bergen. Die Verschlüsselung wird so stark wie das iCloud-Passwort.
• Gerät vor einer Grenze in den Standby versetzt. „Es ist verschlüsselt, ich klappe nur den Deckel zu.” Nein: Die Schlüssel liegen im RAM, die Durchsuchung im warmen Zustand liest die Festplatte. Vollständiges Herunterfahren, immer.
• Unverschlüsselter Swap unter Linux. Die Hauptfestplatte ist in LUKS, der Swap im Klartext, und sensible Fragmente landen dort. Prüfen Sie mit lsblk -f.
• Annehmen, ohne zu prüfen. Die Verschlüsselung war vor sechs Monaten aktiv, also ist sie es heute. Falsch nach jeder Migration, Neuinstallation oder Geräteübernahme.

Umsetzbare Checkliste

• N1 Prüfen, dass FileVault / BitLocker / LUKS wirklich aktiv ist (fdesetup status, Get-BitLockerVolume, cryptsetup luksDump)
• N1 Aktuelles Verhalten beim Zuklappen des Deckels identifizieren: Standby, Ruhezustand oder Herunterfahren
• N1 Den Wiederherstellungsschlüssel auf einem vom Gerät getrennten Träger aufbewahren
• N2 Eine Pre-Boot-Sperre aktivieren: BitLocker-PIN (TPM+PIN), LUKS-Passphrase, Secure Enclave auf dem Mac
• N2 Ruhezustand oder Herunterfahren beim Zuklappen des Deckels in der Mobilität erzwingen (≤ 5 Min.)
• N2 Verschlüsselung des Swap unter Linux prüfen (lsblk -f) oder auf LVM-on-LUKS umstellen
• N2 Cloud-Speicherung des Wiederherstellungsschlüssels für exponierte Profile deaktivieren
• N3 Vor Grenze, Zoll oder Zone mit ausgereifter Interception systematisch vollständig herunterfahren
• N3 Für stark exponierte Profile: LUKS mit starker Passphrase, kein automatisches Entsperren
• N3 Jährliches Audit des Unternehmens-Escrows: wer die Schlüssel liest, Protokollierung, Hardware-MFA auf dem Tresor

Zum Weiterlesen

Die Implementierungen entwickeln sich schnell — prüfen Sie immer die offizielle Dokumentation für Ihre genaue Version. Die FileVault-Dokumentation von Apple(opens in a new tab) beschreibt die Rolle der Secure Enclave je nach Hardware, und die BitLocker-Dokumentation von Microsoft(opens in a new tab) deckt die Konfiguration TPM + PIN per GPO ab. Für Linux bleibt die Projektseite von cryptsetup(opens in a new tab) die Referenz zu LUKS2 und Argon2id. Das BSI liefert mit seinem IT-Grundschutz-Material zur Festplattenverschlüsselung(opens in a new tab) den deutschsprachigen Rahmen aus Sicht einer Unternehmenspolitik. Und um zu verstehen, warum das vollständige Herunterfahren keine Paranoia ist, bleibt das Princeton-Paper zu den Cold-Boot-Angriffen(opens in a new tab) fünfzehn Jahre nach seiner Veröffentlichung aktuell.