KEK und FEK erklärt: warum Verschlüsselung pro Datei zählt

Kurze Antwort. KEK (Key Encryption Key) und FEK (File Encryption Key) bilden eine zweistufige Schlüsselhierarchie, die ernstzunehmende verschlüsselte Apps verwenden. Der FEK, ein Zufallsschlüssel, verschlüsselt die Daten; der KEK, aus Ihrem Passwort abgeleitet, verschlüsselt („verpackt“) den FEK. Dieses Muster heißt Envelope Encryption und wird von Signal, BitLocker, AWS KMS und Apples File Protection verwendet; in der Lehrbuchform bekommt jede Datei ihren eigenen FEK. Filarr nutzt die beiden Ebenen anders: ein zufälliger FEK pro Konto, unter dem Ihre Dateien und Notizen verschlüsselt werden, jede mit einem neuen Zufallswert. Ein Passwortwechsel packt nur diesen FEK neu ein, und eine gestohlene Kopie der Serverdaten öffnet nichts.

Wenn eine verschlüsselte Notiz-App sagt „Ihre Daten sind mit AES-256 verschlüsselt“, steckt dahinter eine verborgene Architekturentscheidung, die mehr zählt als die Chiffre: Wie viele Schlüssel gibt es, und wie sind sie organisiert?

Das naive Design verwendet einen Schlüssel für alles – Ihr Passwort, zu einem Hauptschlüssel gestreckt, verschlüsselt jede Datei. Das bessere Design verwendet zwei Ebenen: einen zufälligen Datenschlüssel, der den Inhalt verschlüsselt, verpackt von einem aus Ihrem Passwort abgeleiteten Schlüssel. Das nennt man Envelope Encryption (Umschlagverschlüsselung), und die beiden Ebenen haben eigene Namen: KEK (Key Encryption Key) und FEK (File Encryption Key). In der Lehrbuchanordnung bekommt sogar jede Datei ihren eigenen FEK.

Dieser Artikel erklärt, warum es das zweistufige Design gibt, wie es Schritt für Schritt funktioniert, gegen welche Angriffe es schützt und woran Sie eine korrekt entworfene verschlüsselte App erkennen.

Was sind KEK und FEK?

Die Begriffe stammen aus Schlüsselverwaltungssystemen und der Literatur zu Cloud-KMS. Die Definitionen:

FEK (File Encryption Key): ein zufälliger symmetrischer Schlüssel (meist 256 Bit), der Dateiinhalte verschlüsselt. In der Lehrbuchanordnung hat jede Datei im System ihren eigenen, eindeutigen FEK; manche Designs, darunter das von Filarr, verwenden einen einzigen FEK für ein ganzes Konto.
KEK (Key Encryption Key): ein Hauptschlüssel, meist aus dem Passwort des Nutzers abgeleitet, der FEKs verschlüsselt. Der KEK selbst verschlüsselt nie direkt Dateiinhalte.

In der Lehrbuchanordnung ist das Gefüge hierarchisch: ein KEK, viele FEKs.

                    Nutzerpasswort
                         │
                         ▼
                  KDF (PBKDF2 / Argon2id)
                         │
                         ▼
                  ╔══════════╗
                  ║   KEK    ║   ← nur im Arbeitsspeicher
                  ╚══════════╝
                         │
                         │ verschlüsselt jeden FEK
            ┌────────────┼────────────┐
            ▼            ▼            ▼
        ┌──────┐    ┌──────┐    ┌──────┐
        │ FEK1 │    │ FEK2 │    │ FEK3 │
        └──────┘    └──────┘    └──────┘
            │            │            │
            ▼            ▼            ▼
       ┌────────┐   ┌────────┐   ┌────────┐
       │Datei 1 │   │Datei 2 │   │Datei 3 │
       │verschl.│   │verschl.│   │verschl.│
       └────────┘   └────────┘   └────────┘

Beim Speichern einer Datei:

Einen neuen zufälligen FEK erzeugen
Die Datei mit ihrem FEK per AES-256-GCM verschlüsseln
Den FEK mit dem KEK per AES-256-GCM verschlüsseln
Die verschlüsselte Datei zusammen mit dem verschlüsselten FEK auf der Festplatte speichern (oder in die Cloud hochladen)

Beim Lesen einer Datei:

Mit Ihrem Passwort den KEK neu ableiten
Den FEK mit dem KEK entschlüsseln
Die Datei mit dem FEK entschlüsseln

Der KEK lebt nur im Arbeitsspeicher des Prozesses und wird gelöscht, wenn Sie die App sperren oder schließen. Die FEKs liegen verschlüsselt auf der Festplatte. Das ursprüngliche Passwort wird nirgendwo gespeichert.

Warum nicht einen globalen Schlüssel für alles?

Das Design mit einem einzigen Schlüssel wirkt einfacher. Sie strecken Ihr Passwort zu einem Hauptschlüssel, verschlüsseln jede Datei mit diesem Hauptschlüssel, fertig. Warum eine Ebene hinzufügen?

Drei konkrete Probleme des Designs mit einem einzigen Schlüssel.

1. Schadensradius. Wenn ein Chiffretext den Schlüssel preisgibt (durch einen Fehler, einen Seitenkanal oder eine Nonce-Wiederverwendung), ist jede mit diesem Schlüssel verschlüsselte Datei offengelegt. Mit FEKs pro Datei legt das Leck des Schlüssels einer Datei nur diese eine Datei offen.

2. Schlüsselrotation ist unmöglich. Mit einem einzigen globalen Schlüssel bedeutet das Rotieren des Schlüssels (etwa wegen eines vermuteten Kompromisses), jede Datei neu zu verschlüsseln. Das ist langsam und riskant. Mit KEK/FEK können Sie den KEK rotieren und die FEKs neu verpacken, ohne den Dateiinhalt je zu entschlüsseln und neu zu verschlüsseln.

3. Selektives Teilen ist unmöglich. Wenn Sie eine Datei mit einem anderen Nutzer teilen wollen, müssten Sie den globalen Hauptschlüssel teilen – was ihm Zugriff auf alle Ihre Dateien gibt, für immer. Mit FEKs pro Datei teilen Sie einen einzelnen FEK, verschlüsselt mit dem öffentlichen Schlüssel des Empfängers. Er bekommt genau eine Datei.

Diese Probleme sind nicht theoretisch. Die Geschichte kryptografischer Katastrophen ist zu großen Teilen eine Geschichte von Designs nach dem Motto „ein Schlüssel für alles“, die böse gescheitert sind.

Was bedeutet Envelope Encryption?

„Envelope Encryption“ ist der Name des KEK/FEK-Musters in der Cloud-Sicherheitsbranche. Die Metapher: Jede Datei wird in einem Umschlag mit ihrem eigenen Datenschlüssel (FEK) versiegelt, und dieser Umschlag kommt dann in einen weiteren Umschlag, der mit einem Schlüsselverschlüsselungsschlüssel (KEK) versiegelt ist.

AWS KMS, Google Cloud KMS, Azure Key Vault und HashiCorp Vault implementieren alle Envelope Encryption. Der in der Cloud verwaltete KEK verlässt nie ein Hardware-Sicherheitsmodul; nur die (unter diesem KEK verschlüsselten) FEKs werden an die Anwendung zurückgegeben.

Filarr verwendet dasselbe Muster auf Ihrem Gerät: Ihr Passwort leitet den KEK ab, der KEK lebt nur im Arbeitsspeicher, und er verpackt einen einzigen FEK, den Schlüssel Ihres Kontos, unter dem Ihre Dateien und Notizen verschlüsselt werden (Details unten).

Wie werden KEK und FEK tatsächlich erzeugt?

Die beiden Hälften verwenden unterschiedliche Erzeugungsmethoden, weil sie unterschiedliche Anforderungen haben.

Erzeugung des FEK: kryptografisch sicherer Zufall. Ein FEK ist ein 256-Bit-Zufallswert aus dem sicheren Zufallszahlengenerator des Betriebssystems (crypto.randomBytes in Node, getRandomValues in Browsern, /dev/urandom unter Linux, BCryptGenRandom unter Windows). In der Lehrbuchanordnung bekommt jede neue Datei einen neuen FEK; bei Filarr jedes Konto. So oder so wird der FEK nie aus etwas abgeleitet; er ist reiner Zufall.

Erzeugung des KEK: Schlüsselableitungsfunktion. Der KEK wird über eine langsame Funktion, die Brute-Force-Angriffen widerstehen soll, aus dem Passwort des Nutzers abgeleitet. Zwei Funktionen sind verbreitet:

PBKDF2-SHA-512, mit einem Salt pro Nutzer und mindestens den 210.000 Iterationen, die OWASP empfiehlt für SHA-512 (600.000 ist der Wert für SHA-256).
Argon2id mit mindestens 64 MB Speicheraufwand, 3 Iterationen und 4 parallelen Spuren. Die aktuelle bewährte Praxis (RFC 9106).

Argon2id wird für neue Designs bevorzugt, weil es speicherintensiv ist, was Brute Force mit GPUs und ASICs drastisch teurer macht als bei PBKDF2. Viele verschlüsselte Apps verwenden aus Kompatibilität mit bestehenden Bibliotheken noch PBKDF2, manchmal zusätzlich zu Argon2id als gestaffelte Verteidigung.

Gegen welche Angriffe schützt das KEK/FEK-Design?

Eine gute Methode, eine kryptografische Architektur zu bewerten, ist, konkrete Angriffsszenarien durchzugehen.

Angriff 1: Der Schlüssel einer Datei wird offengelegt. Ein Fehler in der Anwendung schreibt kurzzeitig einen FEK in ein Protokoll auf der Festplatte. Ein Angreifer mit Zugriff auf die Festplatte liest das Protokoll. Was er bekommt: den Inhalt einer Datei. Was er nicht bekommt: den Hauptschlüssel, irgendeine andere Datei. Das Design mit einem einzigen Schlüssel fällt bei diesem Test katastrophal durch.

Angriff 2: Ein Nutzer teilt eine Datei. Mit FEKs pro Datei bedeutet Teilen, einen FEK für den öffentlichen Schlüssel des Empfängers zu verschlüsseln. Der Empfänger bekommt Zugriff auf eine Datei, nicht mehr. Mit einem einzigen globalen Schlüssel können Sie nichts teilen, ohne alles zu teilen.

Angriff 3: Ein Nutzer ändert sein Passwort. Mit KEK/FEK leiten Sie aus dem neuen Passwort einen neuen KEK ab und verpacken jeden FEK mit dem neuen KEK neu. Kein Dateiinhalt wird berührt. Der Vorgang ist schnell (Millisekunden) und atomar. Mit einem einzigen Schlüssel müssen Sie jede Datei von Grund auf neu verschlüsseln – ein zerstörerischer, langsamer, fehleranfälliger Vorgang.

Angriff 4: Der Cloud-Server ist kompromittiert. Der Angreifer liest alle verschlüsselten Blobs auf der Festplatte. Was er bekommt: Chiffretext + verschlüsselte FEKs. Was er nicht bekommt: den KEK (er liegt nur im Arbeitsspeicher Ihres Geräts) – er kann die FEKs also nicht entschlüsseln und damit gar nichts entschlüsseln.

Angriff 5: Forensische Wiederherstellung einer gelöschten Datei. Mit FEKs pro Datei können Sie eine Datei „schreddern“, indem Sie nur ihren FEK löschen. Der verschlüsselte Dateiinhalt wird dauerhaft unlesbar, selbst wenn die Bytes auf der Festplatte bleiben. Mit einem einzigen Schlüssel bleibt eine Datei auch nach dem Löschen ihrer Metadaten entschlüsselbar – sicheres Löschen verlangt, die Bytes zu überschreiben.

In jedem Szenario verhält sich das zweistufige Design besser als das Design mit einem einzigen Schlüssel.

Gibt es andere Namen für dieses Muster?

Ja. Dasselbe Architekturmuster taucht an vielen Stellen unter verschiedenen Namen auf:

Envelope Encryption – AWS, Google Cloud, Azure
Key Wrapping – Terminologie des NIST
DEK + KEK – „Data Encryption Key“ statt „File Encryption Key“
Hauptschlüssel + Dateischlüssel – Apples File Protection in iOS/macOS
Tresorschlüssel + Eintragsschlüssel – 1Password
VMK + FVEK – Microsoft BitLocker (Volume Master Key + Full Volume Encryption Key)

All das ist dasselbe Muster: ein Hauptschlüssel, der Datenschlüssel verschlüsselt, wobei die Datenschlüssel die eigentlichen Daten berühren. Die Namen unterscheiden sich, die Struktur bleibt gleich.

Woran erkenne ich, ob eine Notiz-App Verschlüsselung pro Datei verwendet?

Wenn Sie eine verschlüsselte Notiz- oder Dateispeicher-App bewerten, achten Sie auf diese Signale:

Architekturdokumentation, die Key Wrapping, Envelope Encryption oder Schlüssel für jede einzelne Datei erwähnt. Eine ernstzunehmende App erklärt ihr Verschlüsselungsgefüge öffentlich. Wenn die Dokumentation nur „AES-256“ sagt, ist das eine Marketingaussage, keine Architektur.
Unabhängige Auditberichte. Prüfer halten ausdrücklich fest, ob Schlüssel für jede einzelne Datei verwendet werden. Die Erwähnung von „KEK und FEK“ in einem Auditbericht ist ein starkes positives Signal.
Fähigkeit zum selektiven Teilen. Wenn die App das Teilen einzelner Dateien unterstützt, ohne dem Empfänger Zugriff auf Ihren gesamten Tresor zu geben, verwendet sie mit ziemlicher Sicherheit gesonderte Schlüssel für das Geteilte. Designs mit einem einzigen Schlüssel können nicht selektiv teilen.
Schneller Passwortwechsel. Wenn das Ändern Ihres Hauptpassworts Sekunden dauert und nicht verlangt, Ihre gesamte Bibliothek neu zu verschlüsseln, verwendet das Design Key Wrapping (der KEK wird aktualisiert; FEKs und Dateien bleiben unberührt).
Öffentlicher Quellcode. Mit öffentlichem Quellcode können Sie die Architektur direkt prüfen. Suchen Sie nach Begriffen wie wrapKey, wrappedFek, unwrapKey, kekId, keyEncryptionKey.

Wie setzt Filarr KEK/FEK um?

Filarr verwendet beide Ebenen, mit einem Unterschied zur Lehrbuchanordnung: Der FEK ist der Schlüssel Ihres Kontos, nicht der Schlüssel einer einzelnen Datei.

Ableitung des KEK. Ihr Passwort durchläuft PBKDF2-SHA-512 (600.000 Iterationen, weit über den 210.000, die die OWASP für PBKDF2-SHA512 empfiehlt), um einen 256-Bit-KEK zu erzeugen. Der KEK lebt nur im Arbeitsspeicher des Prozesses; er wird nie im Klartext auf die Festplatte geschrieben.
Erzeugung des FEK. Jedes Konto bzw. jedes lokale Profil erhält einen zufälligen 256-Bit-FEK aus dem sicheren Zufallszahlengenerator des Betriebssystems. Der FEK wird nie aus Ihrem Passwort abgeleitet.
Dateiverschlüsselung. Ihre Dateien und Notizen werden mit AES-256-GCM unter dem FEK verschlüsselt, mit einem neuen Zufallswert (der Nonce oder dem IV) für jede Datei und jede Verschlüsselung. Zwei Formate gehen einen Schritt weiter und leiten per HKDF und einem zufälligen Salt einen gesonderten Schlüssel aus dem FEK ab: große, am Desktop importierte Dateien und synchronisierte Blöcke. Warum dieser Modus wichtig ist, lesen Sie in Was ist AES-256-GCM?.
Verpacken des FEK. Der FEK wird mit dem KEK per AES-256-GCM verschlüsselt und ein zweites Mal unter Ihrer Wiederherstellungsphrase (24 Wörter bei einem Cloud-Konto). Bei einem Cloud-Konto behält der Server beide verpackten Kopien, damit ein neues Gerät Ihre Daten öffnen kann.
Isolierung mehrerer Profile. Jedes lokale Filarr-Profil hat seinen eigenen FEK und seinen eigenen KEK, abgeleitet aus einem anderen Passwort. Der KEK von Profil A kann den FEK von Profil B nicht entschlüsseln – obwohl beide demselben Nutzer gehören.
Upload in die Cloud. Wenn die Cloud-Synchronisation aktiviert ist, lädt Filarr die verschlüsselten Datei-Blobs hoch, und der Server behält den verpackten FEK. Eine gestohlene Kopie der Serverdaten öffnet ohne Ihr Passwort oder Ihre Wiederherstellungsphrase nichts. Auch die Anmeldung gibt nicht preis, was nötig wäre, um den KEK zu rekonstruieren: Seit dem 16. Oktober 2026 sendet eine aktuelle App einen Schlüssel, der mit einem anderen Salt aus Ihrem Passwort abgeleitet wird, nicht das Passwort selbst. Während einer Übergangszeit von etwa zwei Monaten senden ein Konto, das sich noch nicht erneut angemeldet hat, oder eine ältere App-Version noch das Passwort (über HTTPS), wo ein kompromittierter Server es abfangen könnte.

Gemessen an den Angriffen oben gibt Ihnen dieses Gefüge zwei Dinge. Ein Passwortwechsel verpackt nur den FEK neu, er ist also sofort erledigt und berührt keine Datei (Angriff 3). Eine gestohlene Kopie der Serverdaten liefert Chiffretext und verpackte Schlüssel, nichts Lesbares (Angriff 4). Was es Ihnen nicht gibt, ist ein Schadensradius pro Datei: Der FEK öffnet das ganze Konto, weshalb er Ihr Gerät nie im Klartext verlässt und immer nur verpackt gespeichert wird (Angriff 1). Auch das Teilen beruht nicht auf FEKs pro Datei: Ein Freigabelink trägt nach dem # einen gesonderten Schlüssel, und ein geteilter Tresor hat einen gesonderten Schlüssel, der für jedes Mitglied versiegelt wird (Angriff 2).

Lesen Sie die vollständige Sicherheitsarchitektur von Filarr für die genauen Parameter und das Bedrohungsmodell.

Weiterführende Literatur

NIST SP 800-38F – Methods for Key Wrapping – der Standard für Envelope Encryption
RFC 9106 – Argon2 password hashing – die moderne KDF
OWASP Password Storage Cheat Sheet – aktuelle Empfehlungen
Was ist AES-256-GCM und warum es zählt
Zero-Knowledge-Verschlüsselung erklärt
Ende-zu-Ende- vs. Zero-Knowledge-Verschlüsselung
Was ist Local-First-Software?
Die Sicherheitsarchitektur von Filarr