Formatbewahrende Verschlüsselung gemäß den NIST-Empfehlungen

Formatbewahrende Verschlüsselung (FPE) ist ein vom NIST in SP 800-38G standardisiertes Verschlüsselungsverfahren, das Chiffretext mit demselben Format und derselben Länge wie der Klartext erzeugt. Dies ist wichtig, da die meisten älteren Datenbanken und Anwendungen AES-Chiffretext nicht ohne Schemaänderungen speichern können, was die Implementierung herkömmlicher Verschlüsselungsmethoden erschwert oder unmöglich macht. Es wird empfohlen, FPE mithilfe des FF1-Algorithmus und eines nach FIPS 140-2 validierten kryptografischen Moduls zu implementieren, den FPE-Schlüssel in einem separaten Schlüsselverwaltungssystem zu verwalten und jeden Verschlüsselungs- und Entschlüsselungsvorgang anhand einer authentifizierten Identität zu prüfen.

Kurzantwort: Wann sollte man formatbewahrende Verschlüsselung verwenden?

Verwenden Sie FPE, wenn ein System ein Feld mit fester Länge oder festem Format aufweist, das nicht an einen erweiterten Chiffretext angepasst werden kann und dessen verschlüsselter Wert als Referenzschlüssel in mehreren Systemen verwendbar bleiben muss. Typische Anwendungsfälle sind der Schutz von Kreditkartennummern (Primäre Kontonummern oder PANs) gemäß PCI DSS, Sozialversicherungsnummern gemäß HIPAA, Kontokennungen in älteren Bankensystemen und alle strukturierten Datenfelder, bei denen eine Schema-Migration nicht möglich ist. Verwenden Sie FPE nicht als Ersatz für die allgemeine authentifizierte Verschlüsselung (AES-GCM): FPE bietet keine Authentifizierung (es kann Manipulationen nicht erkennen), weist bei gleicher Schlüssellänge geringere Sicherheitsmargen als AES-GCM auf und erfordert ein sorgfältiges Schlüssel- und Tweak-Management, um kryptografische Schwächen in FF3-1 zu vermeiden.

Wichtige Erkenntnisse

• FPE erzeugt einen Chiffretext mit demselben Format und derselben Länge wie den Klartext: Eine 16-stellige Kreditkartennummer wird zu einem 16-stelligen Geheimtext verschlüsselt. Eine 9-stellige Sozialversicherungsnummer wird zu einem 9-stelligen Geheimtext verschlüsselt. Dadurch können verschlüsselte Daten Systeme passieren, die den ursprünglichen Datentyp erwarten, ohne dass Schemaänderungen oder Anwendungsanpassungen erforderlich sind.
• NIST SP 800-38G spezifiziert zwei zugelassene FPE-Algorithmen, FF1 und FF3-1: Beide sind Feistel-Netzwerkkonstruktionen, die auf AES basieren. FF1 ist der empfohlene Algorithmus für neue Implementierungen. FF3-1 ersetzte FF3 in der Revision von 2024, nachdem Sicherheitslücken in FF3 identifiziert wurden; FF3 (das Original) wird nicht mehr empfohlen.
• FPE bietet keine authentifizierte Verschlüsselung: Im Gegensatz zu AES-GCM verfügt FPE über keinen integrierten Message Authentication Code (MAC). Ein Angreifer, der den Chiffretext direkt verändern kann, erzeugt unbemerkt unterschiedliche gültige Chiffretexte. FPE muss daher in Verbindung mit Integritätskontrollen auf Anwendungs- oder Datenbankebene eingesetzt werden.
• Die Schlüsselrotation für FPE erfordert die erneute Verschlüsselung jedes geschützten Feldwertes: Da der Chiffretext dem ursprünglichen Feldformat entsprechen muss, erfordert die Schlüsselerneuerung die Entschlüsselung aller Werte mit dem alten Schlüssel und deren anschließende Verschlüsselung mit dem neuen Schlüssel. Dies ist eine geplante Datenbankwartungsmaßnahme und keine transparente Rotation im Hintergrund.
• FPE erfüllt bei ordnungsgemäßer Implementierung die Anforderungen von PCI DSS, HIPAA und DSGVO: FPE mit einem NIST SP 800-38G-konformen Algorithmus unter Verwendung eines FIPS 140-2 validierten Moduls erfüllt die Verschlüsselungsanforderungen von PCI DSS v4.0.1 (Anforderung 3.5.1 für PAN-Schutz), HIPAA Technical Safeguards (164.312(a)(2)(iv)) und den DSGVO-Pseudonymisierungsanforderungen (Artikel 89).

Was ist formatbewahrende Verschlüsselung?

Formatbewahrende Verschlüsselung (FPE) ist ein Verschlüsselungsalgorithmus , der Klartext in Geheimtext umwandelt, dessen Format und Länge exakt mit den Originaldaten übereinstimmen. Standardverschlüsselungsalgorithmen wie AES im CBC- oder GCM-Modus erzeugen Geheimtext, der länger als der Klartext ist und Zeichen außerhalb des ursprünglichen Alphabets enthält. FPE hingegen verschlüsselt beispielsweise eine 16-stellige Dezimalzahl in eine 16-stellige Dezimalzahl, einen 9-stelligen alphanumerischen Code in einen 9-stelligen alphanumerischen Code usw., wobei das im Klartext verwendete endliche Symbolalphabet verwendet wird.

Diese Eigenschaft ist wichtig, da die meisten Produktionsdatenbanken und -anwendungen Felder mit strengen Datentypen und festen Längen definieren. Ein Kreditkartenfeld, das als 16-stellige numerische Spalte definiert ist, kann die Base64-kodierte Ausgabe der AES-128-Verschlüsselung nicht speichern (0B6X8rMr058Ow+z3Ju5wimxYERpomz402++zNozLhvw= (Das Feld ist 44 Zeichen lang, nicht 16, und enthält nicht-numerische Zeichen.) Die Speicherung von AES-Chiffretext in einem solchen Feld würde eine Schema-Migration in der gesamten Datenbank, Änderungen an jeder Anwendung, die diese Spalte liest oder schreibt, sowie Aktualisierungen in allen nachgelagerten Systemen, die das ursprüngliche Format erwarten, erfordern. Für ältere Systeme sind solche Migrationen oft technisch nicht praktikabel oder extrem kostspielig. FPE beseitigt diese Notwendigkeit: Der verschlüsselte Wert passt ohne Schema- oder Anwendungsänderungen in das bestehende Feld.

NIST SP 800-38G: Der Standard für FPE

NIST SP 800-38G, „Empfehlung für Betriebsmodi von Blockchiffren: Methoden zur formaterhaltenden Verschlüsselung“, ist der maßgebliche NIST-Standard für formaterhaltende Verschlüsselung (FPE). Er wurde ursprünglich im März 2016 veröffentlicht und 2024 überarbeitet. Darin werden zwei zugelassene FPE-Algorithmen FF1 und FF3-1 spezifiziert. Beide basieren auf AES als zugrundeliegender Blockchiffre, wodurch sie, wenn sie in einem FIPS-140-2-validierten kryptografischen Modul implementiert werden, die FIPS-140-2-Konformität von AES übernehmen.

Der Standard definiert FPE formal wie folgt: Gegeben ein endliches Alphabet von Symbolen (z. B. die Dezimalziffern 0 bis 9 oder die alphanumerischen Zeichen), transformiert ein FPE-Algorithmus eine Symbolfolge aus diesem Alphabet mithilfe eines geheimen Schlüssels in eine andere Folge gleicher Länge, wobei dasselbe Alphabet verwendet wird. Die Definition erfordert ein Alphabet von mindestens zwei Symbolen und eine Klartextlänge von mindestens zwei Symbolen. Die verschlüsselte Ausgabe ist unter Verwendung des gegebenen Schlüssels und der entsprechenden Anpassungen nicht von einer zufälligen Permutation des Klartextraums zu unterscheiden und bietet somit Schutz vor Angreifern, die den Schlüssel nicht kennen.

Der Standard legt außerdem fest, dass FPE-Schlüssel AES-Schlüssel sein müssen: 128-Bit, 192-Bit oder 256-Bit. Für die meisten regulierten Implementierungen werden 256-Bit-Schlüssel empfohlen, um die Anforderungen von FIPS 140-2 Level 3 zu erfüllen und die zukünftige Kompatibilität mit der Migrationsplanung nach der Quantenintegration zu gewährleisten. Der Standard spezifiziert keine Verfahren für das Schlüsselmanagement; diese sind in NIST SP 800-57 (Empfehlung für das Schlüsselmanagement) geregelt.

FF1 und FF3-1: Die beiden vom NIST zugelassenen FPE-Algorithmen

NIST SP 800-38G spezifiziert zwei FPE-Algorithmen, die jeweils für unterschiedliche Implementierungsszenarien geeignet sind.

FF1 (Formatbewahrender Feistel-basierter Verschlüsselungsmodus 1)

FF1 ist der empfohlene FPE-Algorithmus für neue Implementierungen. Es handelt sich um eine Feistel-Netzwerkkonstruktion mit AES als Rundenfunktion und einem Tweak variabler Länge. Der Tweak ist eine zusätzliche Eingabe (ähnlich einem Initialisierungsvektor), die es ermöglicht, mit demselben Schlüssel für denselben Klartextwert unterschiedliche Chiffretextausgaben zu erzeugen, wenn sich der Tweak unterscheidet. Der Tweak kann eine beliebige Bytefolge beliebiger Länge sein, wodurch FF1 die Flexibilität erhält, Kontextdaten wie eine Datensatzkennung, einen Tabellennamen oder ein Transaktionsdatum als Teil der Verschlüsselungseingabe zu integrieren, ohne den Schlüssel zu ändern.

FF1 eignet sich für die meisten FPE-Anwendungsfälle: die Verschlüsselung von PANs, SSNs, Kontonummern, Telefonnummern und anderen strukturierten Datenfeldern. Es unterstützt Alphabetgrößen von 2 bis 2^32 Zeichen und Klartextlängen von 2 bis 2^32 Zeichen (wobei die Alphabetgröße hoch der Länge mindestens 100 ergeben muss). FF1 ist aufgrund der höheren Anzahl an Feistel-Runden rechentechnisch etwas langsamer als FF3-1, der Leistungsunterschied ist jedoch für die meisten Unternehmensanwendungen vernachlässigbar.

FF3-1 (Formatbewahrender Feistel-basierter Verschlüsselungsmodus 3, Revision 1)

FF3-1 ist die überarbeitete Version von FF3, die in der Revision 2024 des NIST SP 800-38G aktualisiert wurde, nachdem Sicherheitsforscher eine Schwachstelle in der ursprünglichen FF3-Spezifikation entdeckt hatten. Diese Schwachstelle ermöglicht es einem Angreifer, der eine große Anzahl von mit demselben Schlüssel und derselben Modifikation verschlüsselten Chiffretextwerten beobachten kann, Informationen über den Schlüssel zu gewinnen. Die Revision 2024 behebt dieses Problem, indem sie vorschreibt, dass die Modifikation exakt 7 Byte (56 Bit) lang sein muss, und indem sie die Beschränkungen für die Anzahl der Verschlüsselungen mit demselben Schlüssel-Modifikations-Paar verschärft.

Die feste 7-Byte-Anpassung von FF3-1 ist eingeschränkter als die variable Anpassung von FF1, wodurch FF3-1 für Anwendungsfälle, die kontextbezogene Anpassungen erfordern, weniger flexibel ist. Dies bedeutet, dass Anwendungen, die FF3-1 verwenden, die Vielfalt der Anpassungen sorgfältig verwalten müssen, um den bekannten Angriff zu vermeiden. Für neue Implementierungen empfiehlt das NIST FF1, sofern kein spezifischer Grund für die Verwendung von FF3-1 vorliegt. Organisationen, die derzeit FF3 (die ursprüngliche Version vor 2024) verwenden, sollten auf FF1 oder FF3-1 migrieren.

Eigenschaft	FF1	FF3-1
Standardisiert in	NIST SP 800-38G (2016, überarbeitet 2024)	NIST SP 800-38G (2016, überarbeitet 2024)
Zugrundeliegender Blockchiffre	AES (128-, 192- oder 256-Bit-Schlüssel)	AES (128-, 192- oder 256-Bit-Schlüssel)
Länge anpassen	Variable (beliebige Bytefolge)	Fest 7 Bytes (56 Bit)
Feistel-Runden	10	8
Alphabet-Unterstützung	2 bis 2^32 Symbole	2 bis 2^32 Symbole
Bekannte Schwächen	In der aktuellen Spezifikation sind keine aufgeführt.	Das ursprüngliche FF3 wies eine Schwäche bei der Tastenwiederherstellung auf; FF3-1 behebt diese durch Anpassungen der Beschränkungen.
NIST-Empfehlung für die neue Verwendung	Bevorzugt	Akzeptabel bei strenger Feinabstimmung
Am besten geeignet,	Die meisten FPE-Anwendungsfälle; flexible Anpassungsanwendungen	Ältere Systeme, die bereits FF3 verwenden; Tokenisierung mit kurzen, festen Anpassungen

Anwendungsfälle für formatbewahrende Verschlüsselung

FPE ist besonders wertvoll in Anwendungsfällen, in denen Datenformat und -länge während des Verschlüsselungsprozesses erhalten bleiben müssen. Im Folgenden sind die wichtigsten Anwendungsfälle in Unternehmen aufgeführt:

Schutz von Zahlungskartendaten (PCI-DSS-PAN-Verschlüsselung): Primäre Kontonummern (PANs) sind 16-stellige Nummern, die in Zahlungsverarbeitungssystemen strengen Formatvorgaben unterliegen. FPE ermöglicht die Verschlüsselung von PANs bei der Eingabe und deren Übertragung als verschlüsselte 16-stellige Werte durch alle nachgelagerten Systeme, einschließlich älterer Zahlungsabwickler, Betrugserkennungssysteme und Berichtsdatenbanken, ohne dass Systemänderungen erforderlich sind. PCI DSS v4.0.1, Anforderung 3.5.1, erkennt FPE ausdrücklich als zulässige Methode zum Schutz gespeicherter PANs an.

Schutz von Patientenidentifikatoren im Gesundheitswesen (HIPAA): Sozialversicherungsnummern (9-stellig), Patientenkontonummern und andere strukturierte Identifikatoren in Gesundheitsdatenbanken eignen sich besonders für die Verschlüsselung mit dem FPE-Verfahren. Die Verschlüsselung einer 9-stelligen Sozialversicherungsnummer mit FPE liefert einen 9-stelligen verschlüsselten Wert, der weiterhin als Suchschlüssel in verknüpften Datenbanken dient, ohne die zugrunde liegenden personenbezogenen Daten preiszugeben. Dies erfüllt die HIPAA-Anforderung zum Schutz elektronischer geschützter Gesundheitsinformationen (ePHI) im Ruhezustand gemäß 45 CFR 164.312(a)(2)(iv).

Legacy-Datenbankverschlüsselung ohne Schema-Migration: Organisationen mit älteren Datenbanken, die Spalten mit fester Zeichen- oder Zahlenlänge verwenden, können FPE anwenden, um sensible Felder ohne Schemaänderungen, Datenmigration oder Anwendungsmodifikation zu verschlüsseln. Der verschlüsselte Wert hat denselben Typ und dieselbe Länge wie das Original, sodass alle bestehenden Abfragen, Indizes, gespeicherten Prozeduren und Anwendungen weiterhin funktionieren. Die Verschlüsselung kann auf Anwendungsebene oder, in einigen Datenbanksystemen, auf Spaltenebene über benutzerdefinierte Funktionen erfolgen.

Datenanonymisierung für Analysen und Tests: Organisationen, die Produktionsdatenextrakte mit Analyseteams, Entwicklungsumgebungen oder Auditoren teilen müssen, können FPE verwenden, um sensible Felder zu anonymisieren. Die verschlüsselten Werte gewährleisten die referenzielle Integrität (derselbe Klartext wird mit demselben Schlüssel und denselben Anpassungen immer zum selben Geheimtext verschlüsselt), sodass Joins und Aggregationen über Tabellen hinweg weiterhin korrekt mit den anonymisierten Daten funktionieren, während die zugrunde liegenden personenbezogenen Daten geschützt sind. FPE ist besonders nützlich für die Pseudonymisierung gemäß Artikel 89 DSGVO, wenn der FPE-Schlüssel getrennt vom pseudonymisierten Datensatz gespeichert wird.

Cloud-Migration sensibler Daten: Bei der Migration sensibler Daten von lokalen Datenbanken in Cloud-Speicher ermöglicht FPE die Verschlüsselung der Daten vor dem Upload, ohne dass Änderungen am Schema oder der Cloud-Datenbankkonfiguration erforderlich sind. Die verschlüsselten Werte in der Cloud-Datenbank behalten denselben Typ und dieselbe Länge wie die Originale, wodurch die Kompatibilität mit allen Anwendungsabfragen erhalten bleibt. Die eigentlichen sensiblen Daten werden durch FPE-Verschlüsselung mit einem lokal gespeicherten Schlüssel oder in einer BYOK-Konfiguration geschützt.

FPE-Schlüsselverwaltung: Native, BYOK und HYOK

Die Sicherheit einer FPE-Implementierung hängt vollständig vom Schutz des FPE-Schlüssels ab. Ein kompromittierter FPE-Schlüssel ermöglicht es einem Angreifer, alle geschützten Feldwerte in der gesamten Datenbank zu entschlüsseln. Das Schlüsselmanagement für FPE folgt dem gleichen Drei-Modell-Framework wie andere Verschlüsselungsanwendungen.

Native Schlüsselverwaltung (vom Anbieter verwaltet)

Bei einem nativen Schlüsselverwaltungsmodell generiert und verwaltet der Cloud-Anbieter oder FPE-Dienst den für FPE-Operationen verwendeten AES-Schlüssel. Ihre Anwendung ruft die FPE-Dienst-API mit dem Klartextwert auf und erhält den verschlüsselten Wert; der Schlüssel selbst wird vom Dienst verwaltet. Der Vorteil liegt im minimalen Betriebsaufwand. Der Nachteil besteht darin, dass der Dienstanbieter Zugriff auf den Schlüssel und somit die Möglichkeit hat, alle FPE-geschützten Werte zu entschlüsseln. Für die meisten allgemeinen Compliance-Workloads ist dieses Modell akzeptabel, sofern der Anbieter innerhalb Ihrer Compliance-Grenzen liegt und der Dienst durch entsprechende vertragliche Kontrollen abgedeckt ist (z. B. BAA für HIPAA, DPA für DSGVO). Für regulierte Daten, die die Herkunft des Kundenschlüssels erfordern, ist die native Schlüsselverwaltung unzureichend.

BYOK (Bring Your Own Key) für FPE

BYOK für FPE bedeutet, den AES-FPE-Schlüssel in Ihrem eigenen Hardware-Sicherheitsmodul (HSM) oder Schlüsselverwaltungssystem zu generieren und in den FPE-Dienst oder das Cloud-KMS zu importieren. Das FPE-Schlüsselmaterial wird unter Ihrer Kontrolle generiert, und Ihre Organisation kann dessen Herkunft unabhängig überprüfen. Der Cloud-Dienst verwendet Ihr importiertes Schlüsselmaterial für FPE-Operationen. Sie behalten jedoch den Originalschlüssel in Ihrem HSM und können ihn widerrufen, indem Sie die importierte Kopie aus dem Dienst löschen. BYOK erfüllt regulatorische Anforderungen, die kundengeneriertes Schlüsselmaterial für die Verschlüsselung regulierter Daten vorschreiben (z. B. bestimmte PCI-DSS-QSA-Interpretationen von Anforderung 3.7.1, bestimmte FedRAMP-Kontrollen). Speziell für FPE verwenden BYOK-Implementierungen typischerweise ein lokales HSM oder ein HSM-as-a-Service-System eines Drittanbieters als Schlüsselgenerierungsquelle. Der Schlüssel wird anschließend in den Cloud-FPE-Dienst importiert.

HYOK (Hold Your Own Key) für FPE

HYOK für FPE bedeutet, dass der FPE-Schlüssel niemals in den Cloud-Dienst gelangt. Die FPE-Verschlüsselung und -Entschlüsselung erfolgen in Ihrer eigenen Infrastruktur (einer lokalen Anwendungsschicht oder einer clientseitigen Bibliothek), und nur die FPE-verschlüsselten Werte werden in Cloud-Speicher oder Datenbanken hochgeladen. Der Cloud-Anbieter speichert ausschließlich den Chiffretext und kann keine geschützten Felder entschlüsseln, selbst nicht auf rechtliche Anforderung. HYOK bietet höchste Datensouveränität für FPE-Anwendungsfälle. Der operative Aufwand besteht darin, dass jeder FPE-Verschlüsselungs- und -Entschlüsselungsvorgang einen Roundtrip zu Ihrem lokalen Schlüsselverwaltungssystem erfordert, das für die Funktionsfähigkeit Ihrer Anwendung hochverfügbar sein muss. Diese Architektur eignet sich für klassifizierte Daten, Umgebungen mit strengen Datenschutzauflagen oder Organisationen, in denen der Cloud-Anbieter selbst Teil des Bedrohungsmodells ist.

Abmessungen	Native Key Management	BYOK (Customer-Generated Key in Service)	HYOK (FPE außerhalb der Wolke durchgeführt)
FPE-Schlüssel generiert von	Cloud-Anbieter oder FPE-Dienst	Kunden-HSM (in Betrieb genommen)	Kunde (tritt nie in die Cloud ein)
Anbieterzugriff auf FPE-Schlüssel	Ja	Ja (operativer Zugriff)	Nein
Der Anbieter kann FPE-Felder entschlüsseln	Ja	Ja (während des Betriebs)	Nein
Unabhängiger Schlüsselwiderruf	Nur über die Service-API	Importierten Schlüssel löschen (sofort)	Widerrufen Sie den KMS-Zugriff vor Ort.
Operative Komplexität	Niedrig	Medium	Hoch
PCI-DSS-Anforderung zur Herkunftsnachweispflicht	Hängt von der QSA-Interpretation ab	Erfüllt die wichtigsten Materialanforderungen des Kunden.	Erfüllt voll und ganz
Am besten geeignet,	Allgemeine Compliance-Arbeitslasten mit Anbieterkontrollen	Regulierte Sektoren, die eine unabhängige Herkunftssicherung der Schlüssel erfordern	Geheime, durch staatliche Vorgaben geschützte Zero-Trust-Umgebungen

IAM-Modell für FPE-Zugriffskontrolle

Die Zugriffskontrolle für FPE-Operationen erfordert dieselbe Drei-Rollen-Trennung wie jedes Schlüsselverwaltungssystem. Eine Fehlkonfiguration von IAM für FPE hat besonders schwerwiegende Folgen, da FPE-Schlüssel strukturierte Datenfelder schützen, die sich über Millionen von Datensätzen in mehreren Datenbanken erstrecken können.

Schlüsseladministratorrolle: Erstellt, importiert und verwaltet den FPE-Schlüssellebenszyklus. Autorisiert die Schlüsselerstellung, Rotationsereignisse und Löschung. Darf nicht mit dem Anwendungsdienstkonto identisch sein, das FPE-Operationen ausführt. Aktionen des Schlüsseladministrators (Schlüsselerstellung, Löschplanung, Richtlinienänderungen) müssen protokolliert werden und unterliegen bei kritischen Vorgängen wie Schlüsselgenerierungszeremonien und der Löschung von Schlüsseln zum Schutz von Produktionsdaten der Vier-Augen-Regel.

FPE-Operatorrolle (Krypto-Offizier): Führt die FPE-Verschlüsselungs- und Entschlüsselungs-API-Aufrufe im Auftrag der Anwendung durch. Besitzt die Berechtigung, den FPE-Schlüssel für Verschlüsselungs- und Entschlüsselungsvorgänge zu verwenden, jedoch nicht, den Schlüssel zu erstellen, zu löschen oder zu exportieren. In der Cloud-KMS-Terminologie entspricht dies der Gewährung spezifischer Verschlüsselungs- und Entschlüsselungsberechtigungen für den jeweiligen FPE-Schlüssel an das Anwendungsdienstkonto, nicht aber eines umfassenden KMS-Zugriffs. Für AWS-Bereitstellungen ist dies die kms:Encrypt und kms:Decrypt Berechtigungen nur für den spezifischen Schlüssel-ARN. Service Control Policies (SCPs) in einer AWS-Organisation können sicherstellen, dass keine Anwendungsrolle Berechtigungen zur Schlüsselverwaltung erhält.

Rolle des Datenkonsumenten (schreibgeschützter Zugriff auf verschlüsselte Felder): Anwendungen oder Benutzer, die Datenbankfelder mit FPE-verschlüsselten Werten lesen, diese aber nicht entschlüsseln müssen (z. B. ein Berichtssystem, das den verschlüsselten Wert als undurchsichtigen Bezeichner für Verknüpfungszwecke verwendet), sollten keinerlei FPE-Entschlüsselungsberechtigungen besitzen. Nur das spezifische Anwendungsdienstkonto, das lesbaren Klartext benötigt, sollte Entschlüsselungszugriff auf den FPE-Schlüssel haben.

Schlüsselrotation für FPE: Besondere Überlegungen

Die Schlüsselrotation für FPE unterscheidet sich grundlegend von der Schlüsselrotation für die Standardverschlüsselung. Bei der Standard-Envelope-Verschlüsselung (wie sie von AWS KMS, Azure Key Vault und GCP Cloud KMS verwendet wird) bedeutet die Rotation des Hauptschlüssels, dass neues Schlüsselmaterial für den Hauptschlüssel generiert und damit die Datenverschlüsselungsschlüssel neu verschlüsselt werden. Die eigentlichen Daten müssen nicht neu verschlüsselt werden. Bei FPE gibt es keine Envelope-Verschlüsselungsschicht: Der FPE-Schlüssel verschlüsselt die Feldwerte direkt. Die Rotation des FPE-Schlüssels erfordert daher, dass jeder geschützte Feldwert mit dem alten Schlüssel entschlüsselt und anschließend mit dem neuen Schlüssel neu verschlüsselt wird – und zwar in jeder Tabelle und Spalte, die diesen FPE-Schlüssel verwendet.

Dies hat mehrere betriebliche Konsequenzen. Erstens kann die Rotation von FPE-Schlüsseln nicht transparent im Hintergrund erfolgen; sie erfordert ein geplantes Wartungsfenster oder eine Read-Shadow-Architektur während des Rotationszeitraums (in dem sowohl der alte als auch der neue Schlüssel aktiv sind, neue Schreibvorgänge den neuen Schlüssel verwenden und Lesevorgänge auf den alten Schlüssel zurückgreifen, falls die Entschlüsselung mit dem neuen Schlüssel fehlschlägt). Zweitens ist die Rotationsfrequenz von FPE-Schlüsseln typischerweise niedriger als bei Standard-KMS-Schlüsseln: Die meisten Organisationen rotieren FPE-Schlüssel jährlich oder nach einem festgelegten Zeitplan, der mit der PCI-DSS-Anforderung 3.7.4 übereinstimmt (welche periodische Kryptoperioden für symmetrische Schlüssel vorschreibt). Drittens muss das Schlüsselrotationsverfahren vor der Anwendung auf Produktionsdaten getestet und geübt werden, da eine fehlgeschlagene FPE-Rotation, die Daten in einem inkonsistenten Schlüsselzustand hinterlässt, ganze Datenbankspalten unzugänglich machen kann.

Bewährte Verfahren für die FPE-Schlüsselrotation: Führen Sie neben jedem FPE-verschlüsselten Feld eine Schlüsselversionskennung (eine einzelne Spalte oder ein Flag, das angibt, mit welcher Schlüsselversion der Wert verschlüsselt wurde); konzipieren Sie die Anwendung so, dass sie während des Rotationszeitraums sowohl alte als auch neue Schlüsselversionen akzeptiert; rotieren Sie in Batches, um den Umfang eines Fehlers zu begrenzen; überprüfen Sie die Entschlüsselung mit dem neuen Schlüssel für jeden Batch, bevor Sie alte Werte löschen; und bewahren Sie den alten Schlüssel in einem archivierten, aber unzugänglichen Zustand auf, bis alle Daten als rotiert verifiziert wurden.

Audit-Protokollierung für FPE-Operationen

Jeder FPE-Verschlüsselungs- und Entschlüsselungsvorgang sollte mit der anfragenden Identität, dem Zeitstempel, dem verwendeten Schlüsselbezeichner und dem Feldtyp (ohne Klartext- oder Chiffretextwert) protokolliert werden. Audit-Logs für FPE dienen als Nachweis der Einhaltung der PCI-DSS-Anforderung 10 (Protokollierung und Überwachung) und des HIPAA-Audit-Control-Standards (45 CFR 164.312(b)).

Bei cloudbasierten FPE-Implementierungen, die einen Cloud-KMS als Schlüsselspeicher verwenden, generiert jeder FPE-Vorgang, der den KMS zum Verpacken oder Entpacken eines Datenschlüssels aufruft, ein CloudTrail-Ereignis (in AWS), ein Azure Monitor-Ereignis (in Azure) oder ein Cloud Audit Log-Ereignis (in GCP). Diese pro Vorgang protokollierten Audit-Trails sind ein Grund dafür, dass regulierte Organisationen cloudbasiertes FPE gegenüber anwendungsbasierter Schlüsselspeicherung bevorzugen: Der Audit-Trail wird automatisch generiert, ist manipulationssicher und erfordert keine benutzerdefinierte Protokollierungsinfrastruktur.

Warnung bei folgenden FPE-bezogenen Audit-Ereignissen: Massenentschlüsselungsvorgänge gegen FPE-geschützte Spalten durch eine beliebige Identität, die nicht in der Liste der genehmigten Anwendungsrollen enthalten ist (ein möglicher Datenextraktionsversuch); Löschung oder Planung der Löschung von FPE-Schlüsseln außerhalb eines dokumentierten Rotationsereignisses; jede Änderung der FPE-Schlüsselrichtlinie oder der Zugriffskontrollen; und FPE-Vorgänge, die von IP-Adressen oder IAM-Identitäten ausgehen, die nicht bekannten Anwendungsbereitstellungen zugeordnet sind.

Cloud FPE-Implementierungen

Die FPE-Funktionalität ist über verschiedene Cloud-Anbieter verfügbar und kann auch mithilfe von Open-Source-Bibliotheken und einem Cloud-KMS als Schlüsselspeicher implementiert werden. Der Implementierungsansatz hängt davon ab, ob der Cloud-Dienst native FPE-Unterstützung bietet oder ob FPE auf Anwendungsebene implementiert werden muss.

Google Cloud: Cloud DLP mit FPE-De-Identifizierung

Google Cloud bietet native FPE-Funktionalität über Cloud Data Loss Prevention (Cloud DLP), jetzt Sensitive Data Protection genannt. Die DLP-API ermöglicht es Kunden, FPE-Verschlüsselung und -Entschlüsselung für strukturierte Datenfelder aufzurufen. Der FPE-Schlüssel wird in Cloud KMS verwaltet. Die DLP-API unterstützt FF1-Verschlüsselung über das Dezimalalphabet (für numerische Felder wie Kreditkartennummern und Sozialversicherungsnummern) und über das alphanumerische Alphabet (für Kennungen mit gemischten Zeichen). Der für FPE verwendete Schlüssel kann ein mit der Anfrage gespeicherter Wrapped Key (BYOK, wobei der Wrapping-Vorgang mit dem Cloud-KMS-Schlüssel des Aufrufers erfolgt) oder ein von Cloud KMS verwalteter Schlüssel sein. Cloud DLP FPE erfüllt die PCI-DSS-Anforderungen für den PAN-Schutz und die HIPAA-Anforderungen für die Anonymisierung elektronischer Gesundheitsdaten (ePHI), sofern die entsprechenden Zugriffskontrollen für den Schlüssel konfiguriert sind.

AWS: Anwendungsschicht-FPE mit AWS KMS-Schlüsselunterstützung

AWS bietet keinen nativen FPE-API-Service an. AWS-Implementierungen von FPE verwenden eine FPE-Bibliothek auf Anwendungsebene (z. B. die Open-Source-Implementierungen FF1 oder FF3-1 für Java, Python und Go). Der FPE-Schlüssel wird in AWS KMS gespeichert und von dort abgerufen. Die Anwendung ruft den AES-Schlüssel beim Start oder bei Bedarf von KMS ab, führt FPE-Operationen lokal mit diesem Schlüssel durch und schreibt nur die FPE-verschlüsselten Werte in die Datenbank. Der in AWS KMS gespeicherte FPE-Schlüssel kann ein vom Kunden verwalteter Schlüssel mit BYOK (importiertes Schlüsselmaterial mit Ursprung: EXTERNAL) oder ein von KMS generierter Schlüssel sein. Alle Schlüsselzugriffsvorgänge erzeugen CloudTrail-Ereignisse, die den Prüfpfad für die Schlüsselnutzung bereitstellen. Dieser Ansatz ermöglicht Unternehmen die volle Kontrolle über die Implementierung des FPE-Algorithmus und nutzt gleichzeitig AWS KMS für den Schlüsselschutz und die Protokollierung.

Azure: Anwendungsschicht-FPE mit Azure Key Vault-Schlüsselunterstützung

Azure bietet ebenfalls keinen nativen FPE-API-Dienst. Azure-FPE-Implementierungen verwenden FPE-Bibliotheken der Anwendungsschicht, wobei der AES-Schlüssel in Azure Key Vault (Standard- oder HSM-geschützter Tarif) gespeichert wird. Azure Key Vault unterstützt kundenverwaltete Schlüssel, BYOK (Schlüsselimport aus einem eigenen HSM) und die Speicherung HSM-geschützter Schlüssel in Azure Dedicated HSM für die Validierung gemäß FIPS 140-2 Level 3. Alle Key-Vault-Vorgänge generieren Überwachungsprotokolle in Azure Monitor. Azure Purview (jetzt Microsoft Purview) bietet Funktionen zur Datenklassifizierung, mit denen sensible Felder identifiziert werden können, die FPE-Schutz benötigen. Dadurch eignet es sich als nützliches Erkennungstool vor der FPE-Implementierung.

FPE vs. Tokenisierung: Die richtige Vorgehensweise wählen

FPE und Tokenisierung werden oft für den gleichen Zweck verwendet (Schutz strukturierter Datenfelder ohne Formatänderung), funktionieren aber unterschiedlich und weisen unterschiedliche Sicherheitseigenschaften auf.

Bei der Tokenisierung wird ein sensibler Wert durch einen zufällig generierten Ersatzwert (ein Token) desselben Formats ersetzt. Dieser wird in einem Token-Tresor gespeichert, der Tokens den Originalwerten zuordnet. Der Token steht in keiner mathematischen Beziehung zum Originalwert; die Wiederherstellung des Originals erfordert einen Zugriff auf den Token-Tresor. Tokenisierung bietet hohe Sicherheit, da selbst bei isolierter Kompromittierung des Token-Tresors der Token ohne die vollständige Zuordnungstabelle keine Rückschlüsse auf den Originalwert zulässt. Allerdings benötigt die Tokenisierung einen zentralen Token-Tresor, der hochverfügbar sein muss, zum Engpass werden kann und als primäres Angriffsziel geschützt werden muss.

FPE ist deterministisch und speicherlos: Derselbe Klartextwert, verschlüsselt mit demselben Schlüssel und derselben Modifikation, erzeugt stets denselben Chiffretext – ohne dass eine Suche erforderlich ist. Dadurch ist FPE zustandslos und hoch skalierbar. Allerdings bedeutet dies auch, dass der FPE-Chiffretext einer Häufigkeitsanalyse unterzogen werden kann, wenn der Klartextraum klein ist (beispielsweise erzeugt ein einstelliges Feld mit den Werten 0 bis 9 nur 10 mögliche Chiffretexte, wodurch die Häufigkeitsanalyse trivial wird). FPE eignet sich für Felder mit großen Klartexträumen (16-stellige Kreditkartennummern haben 10^16 mögliche Werte; eine Häufigkeitsanalyse ist hier nicht praktikabel). Für kleine Klartexträume ist die Tokenisierung die geeignetere Wahl.

Compliance-Abdeckung: PCI DSS, HIPAA und DSGVO

PCI DSS v4.0.1 (verpflichtend ab 31. März 2025): Anforderung 3.5.1 verlangt, dass primäre Kontonummern (PANs), die in einer PCI-DSS-relevanten Umgebung gespeichert sind, mithilfe starker Kryptografie unlesbar gemacht werden. FPE mit FF1 oder FF3-1 und einem 256-Bit-AES-Schlüssel sowie ordnungsgemäßem Schlüsselmanagement erfüllt diese Anforderung. Das PCI-DSS-Glossar führt formatbewahrende Verschlüsselung explizit als zulässiges Verfahren zur Unlesbarkeit auf. Die Anforderungen 3.7.1 bis 3.7.9 regeln das Schlüsselmanagement für den FPE-Schlüssel, einschließlich Schlüsselgenerierungsverfahren, Schlüsselverwalterrollen, Schlüsselrotationspläne und Verfahren zur Schlüsselvernichtung. Anforderung 10 regelt die Protokollierung aller Zugriffe auf Karteninhaberdaten, einschließlich der FPE-Verschlüsselungs- und Entschlüsselungsvorgänge.

Technische Sicherheitsvorkehrungen gemäß HIPAA: Der Standard für Verschlüsselung und Entschlüsselung (45 CFR 164.312(a)(2)(iv)) schreibt vor, dass ruhende elektronische Gesundheitsdaten (ePHI) verschlüsselt werden müssen, um sie vor unberechtigtem Zugriff zu schützen. FPE mit NIST SP 800-38G-konformen Algorithmen erfüllt diesen Standard. Die NIST Special Publication 800-111 (Leitfaden für Speicherverschlüsselungstechnologien für Endgeräte) und die HHS-Richtlinien zur Verschlüsselung und Entschlüsselung bestätigen, dass AES-basierte Verschlüsselung den HIPAA-Verschlüsselungsstandard erfüllt; FPE, die auf AES basieren, übernehmen diesen Konformitätsstatus. Der Standard für die Zugriffskontrolle (45 CFR 164.312(b)) fordert die Protokollierung des Zugriffs auf ePHI. Dies wird durch die vom FPE-Schlüsselverwaltungssystem generierten protokollierten Zugriffsprotokolle pro Vorgang gewährleistet.

DSGVO-Pseudonymisierung (Artikel 25 und 89): Artikel 89 DSGVO sieht reduzierte Anforderungen an die Rechte betroffener Personen (Recht auf Löschung, Recht auf Auskunft) für pseudonymisierte Daten vor, die zu Forschungs- oder Statistikzwecken verwendet werden. FPE erfüllt die DSGVO-Definition der Pseudonymisierung (Artikel 4 Absatz 5: Verarbeitung personenbezogener Daten in einer Weise, dass die personenbezogenen Daten ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer bestimmten betroffenen Person zugeordnet werden können), wenn der FPE-Schlüssel getrennt von den pseudonymisierten Daten gespeichert und durch geeignete Zugriffskontrollen geschützt wird. FPE-pseudonymisierte Datensätze können mit Analyseteams oder Forschungspartnern mit reduziertem Compliance-Aufwand geteilt werden, wenn der FPE-Schlüssel nicht in den geteilten Daten enthalten ist.

FPE-Einschränkungen und worauf zu achten ist

FPE weist wichtige Einschränkungen auf, die vor dem Einsatz verstanden werden müssen.

Keine Authentifizierung: FPE bietet keine authentifizierte Verschlüsselung. Ein Angreifer, der FPE-verschlüsselte Werte in der Datenbank verändern kann, erzeugt unbemerkt andere gültige verschlüsselte Werte. Um unautorisierte Änderungen an FPE-geschützten Feldern zu erkennen, sind Integritätskontrollen auf Datenbankebene (Hash-basierte Prüfsummen, MACs auf Anwendungsebene oder Datenbank-Trigger) erforderlich.

Determinismus ermöglicht Häufigkeitsanalysen für kleine Klartextbereiche: Da derselbe Klartext mit demselben Schlüssel und derselben Anpassung stets zum selben Geheimtext verschlüsselt wird, können FPE-verschlüsselte Felder bei kleinen Klartextbereichen einer Häufigkeitsanalyse unterzogen werden. Ein Feld, das nur die Werte 0 bis 9 enthält, erzeugt lediglich 10 verschiedene Geheimtexte. Ein Angreifer, der die Verteilung der ursprünglichen Werte kennt, kann diese oft anhand der Verteilung der verschlüsselten Werte rekonstruieren. Anpassungen mindern dieses Problem, indem sie den Geheimtext sowohl vom Klartext als auch vom Schlüssel abhängig machen. Verwenden Sie daher nach Möglichkeit eine Anpassung pro Datensatz oder pro Transaktion.

Die Schlüsselrotation erfordert eine vollständige Neuverschlüsselung: Wie im Abschnitt zur Schlüsselrotation beschrieben, muss bei der Rotation eines FPE-Schlüssels jeder Wert in jedem geschützten Feld neu verschlüsselt werden. Dies stellt einen erheblichen operativen Aufwand für große Datenbanken dar und muss sorgfältig geplant werden.

FF3 (Originalversion, vor 2024) wird nicht mehr empfohlen: Organisationen, die FF3-Implementierungen (nicht FF3-1) verwenden, sollten auf FF1 oder FF3-1 migrieren. Die Originalversion von FF3 weist eine bekannte Schwachstelle bei der Schlüsselwiederherstellung auf, wenn dieselbe Schlüssel- und Parameterkombination für mehrere Verschlüsselungen wiederverwendet wird. Die meisten kommerziellen FPE-Bibliotheken wurden auf FF3-1 oder FF1 aktualisiert. Überprüfen Sie jedoch Ihre Bibliotheksversion, bevor Sie von der Einhaltung der aktuellen NIST-Richtlinien ausgehen.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting ist ein Beratungsunternehmen für angewandte Kryptografie mit Zertifizierungen nach ISO/IEC 27001:2022 und SOC 2. Wir unterstützen Organisationen bei der Konzeption, Implementierung und Prüfung von FPE-Lösungen (Firewall-Processing Equipment) im Hinblick auf PCI DSS, HIPAA, DSGVO und andere Compliance-Rahmenwerke.

• FPE-Architektur und -Implementierung: Wir entwerfen die FPE-Architektur für Ihre Umgebung, einschließlich der Algorithmusauswahl (FF1 vs. FF3-1), der Optimierungsstrategie, des Schlüsselverwaltungsmodells (nativ, BYOK oder HYOK), der IAM-Rollenstruktur, des Rotationsverfahrens und der Konfiguration der Audit-Protokollierung. Wir implementieren und testen die FPE-Integration für AWS KMS-basierte, Azure Key Vault-basierte oder Google Cloud DLP-Bereitstellungen. Weitere Informationen finden Sie in unserem Datenschutzdienstleistungen.
• HSM als Dienstleistung für die FPE-Schlüsselgenerierung: Für BYOK-FPE-Implementierungen, die eine Schlüsselerzeugung gemäß FIPS 140-2 Level 3 erfordern, bietet Encryption Consulting die entsprechende Lösung an. HSM als Service Es bietet eine dedizierte HSM-Infrastruktur als Quelle für die Schlüsselgenerierung. FPE-Schlüssel werden im HSM generiert, in verschlüsselter Form exportiert und in Ihren Cloud-KMS- oder FPE-Dienst importiert. HSM as a Service ist in AWS-, Azure- und GCP-Umgebungen verfügbar.
• CBOM Secure für FPE Discovery: Vor der Implementierung von FPE müssen Unternehmen alle Felder in ihren Datenbanken identifizieren, die sensible, strukturierte Daten enthalten, die FPE-Schutz erfordern. Encryption Consulting bietet Unterstützung. CBOM Secure Erkennt und inventarisiert alle sensiblen Datenfelder, bestehende Verschlüsselungsimplementierungen und kryptografische Lücken in Cloud- und On-Premises-Umgebungen und erstellt eine kryptografische Stückliste, die die FPE-Implementierung nach Risiko und Dringlichkeit der Compliance priorisiert.
• PCI DSS- und HIPAA-Konformitätshinweis: Wir gleichen Ihre FPE-Implementierung mit den spezifischen Anforderungen von PCI DSS v4.0.1 (Anforderungen 3.5.1, 3.7.1 bis 3.7.9 und Anforderung 10), den technischen Sicherheitsvorkehrungen von HIPAA und den Pseudonymisierungsanforderungen der DSGVO ab. Wir identifizieren Lücken, erstellen die erforderlichen Nachweise zur Einhaltung der Vorschriften und unterstützen Sie bei Anfragen von QSA und Auditoren. Weitere Informationen finden Sie hier. Compliance-Beratungsdienste.
• PQC-Bereitschaft für FPE: FPE-Algorithmen basieren auf AES, das kurzfristig nicht direkt durch Quantencomputer bedroht ist (AES-256 erfordert für Grovers Algorithmus eine Verdopplung des Schlüsselsuchraums, wodurch eine angemessene Sicherheit gewährleistet wird). Die Schlüsselverwaltungsinfrastruktur zum Schutz von FPE-Schlüsseln (RSA-basiertes Key Wrapping, ECDH für den Schlüsselaustausch) muss jedoch möglicherweise vor 2030 auf Post-Quanten-Algorithmen umgestellt werden. (Encryption Consulting) PQC-Bereitschaft Der Service bewertet Ihre FPE-Schlüsselverwaltungsinfrastruktur anhand des Post-Quantum-Migrationszeitplans des NIST (NIST IR 8547, RSA/ECC veraltet ab ca. 2030).

Um Ihre Anforderungen an die FPE-Implementierung zu besprechen, wenden Sie sich an Encryption Consulting.

Fazit

Formatbewahrende Verschlüsselung (FPE) gemäß den Empfehlungen von NIST SP 800-38G bietet einen praktischen Weg zur Verschlüsselung sensibler strukturierter Daten in Umgebungen, in denen Schemaänderungen nicht möglich sind. Die beiden NIST-zugelassenen Algorithmen FF1 und FF3-1 basieren auf AES und sind FIPS 140-2-konform, wenn sie mit einem validierten kryptografischen Modul implementiert werden. FF1 ist der empfohlene Algorithmus für neue Implementierungen; FF3-1 ist mit strengem Diversitätsmanagement akzeptabel. FPE erfüllt die Anforderungen von PCI DSS v4.0.1 (PAN-Schutz), HIPAA (ePHI-Verschlüsselung) und DSGVO (Pseudonymisierung), wenn es mit einem geeigneten Schlüsselmanagement und Audit-Logging kombiniert wird.

Die wichtigsten betrieblichen Aspekte für FPE sind die Trennung von Schlüssel und geschützten Daten, eine sorgfältige Gestaltung der IAM-Rollen, um den Entschlüsselungszugriff auf die erforderlichen Anwendungsidentitäten zu beschränken, und die operative Komplexität der Schlüsselrotation, die eine vollständige Neuverschlüsselung aller geschützten Feldwerte erfordert. Diese Aspekte von Anfang an in der Designphase zu berücksichtigen, anstatt sie nachträglich in eine bestehende FPE-Implementierung einzubauen, ist deutlich einfacher und führt zu einer besseren Einhaltung der Compliance-Vorgaben.

Häufig gestellte Fragen

Was ist formaterhaltende Verschlüsselung (FPE)?

Formatbewahrende Verschlüsselung (FPE) ist ein Verschlüsselungsverfahren, das einen Geheimtext mit demselben Format und derselben Länge wie den Klartext erzeugt. Die Verschlüsselung einer 16-stelligen Kreditkartennummer ergibt einen 16-stelligen Geheimtext; die Verschlüsselung einer 9-stelligen Sozialversicherungsnummer ergibt einen 9-stelligen Geheimtext. NIST SP 800-38G standardisiert zwei FPE-Algorithmen: FF1 (empfohlen für neue Implementierungen) und FF3-1. Beide basieren auf AES und sind FIPS 140-2-konform, wenn sie mit einem validierten kryptografischen Modul implementiert werden.

Was ist NIST SP 800-38G und was spezifiziert es für FPE?

NIST SP 800-38G, „Empfehlung für Betriebsarten von Blockchiffren: Methoden zur formaterhaltenden Verschlüsselung“, ist der maßgebliche NIST-Standard für formaterhaltende Verschlüsselung (FPE). Erstmals 2016 veröffentlicht und 2024 überarbeitet, spezifiziert er FF1 und FF3-1 als die beiden zugelassenen FPE-Algorithmen. Beide benötigen AES-Schlüssel (128-Bit, 192-Bit oder 256-Bit). FF3-1 löste den ursprünglichen FF3 ab, nachdem Sicherheitslücken in FF3 identifiziert wurden; Organisationen, die FF3 verwenden, sollten auf FF1 oder FF3-1 migrieren.

Wann sollte man FPE anstelle der standardmäßigen AES-Verschlüsselung verwenden?

Verwenden Sie FPE, wenn die Anwendung oder Datenbank ein Feld fester Länge besitzt, das keinen erweiterten AES-Chiffretext aufnehmen kann, wenn der verschlüsselte Wert als Referenzschlüssel in mehreren Systemen dienen muss, die das Originalformat erwarten, oder wenn Sie Daten aus Altsystemen ohne Schema-Migration verschlüsseln. Verwenden Sie FPE nicht als universellen Ersatz für authentifizierte Verschlüsselung: FPE bietet keine Authentifizierung (es kann Manipulationen nicht erkennen) und weist bei gleicher Schlüssellänge geringere Sicherheitsmargen als AES-GCM auf.

Worin besteht der Unterschied zwischen FF1 und FF3-1?

FF1 und FF3-1 sind beides Feistel-basierte FPE-Algorithmen mit AES. FF1 verwendet einen Tweak variabler Länge und ist daher flexibler für Anwendungen, die kontextbezogene Eingaben für die Verschlüsselung benötigen. FF3-1 verwendet einen festen 7-Byte-Tweak und wurde für Tokenisierungsanwendungen mit kurzen Kontextwerten entwickelt. FF3-1 überarbeitete den ursprünglichen FF3, nachdem eine Schwachstelle bei der Schlüsselwiederherstellung in FF3 entdeckt wurde, die auftrat, wenn dasselbe Schlüssel-Tweak-Paar für mehrere Nachrichten wiederverwendet wurde. Für neue Implementierungen empfiehlt das NIST FF1.

Erfüllt FPE die HIPAA- und PCI-DSS-Konformitätsanforderungen?

Ja. FPE mit NIST SP 800-38G-konformen Algorithmen (FF1 oder FF3-1) unter Verwendung von FIPS 140-2-validierten Modulen erfüllt die technischen Sicherheitsvorkehrungen des HIPAA (45 CFR 164.312(a)(2)(iv)) für ruhende elektronische Gesundheitsdaten (ePHI). PCI DSS v4.0.1, Anforderung 3.5.1, erkennt formaterhaltende Verschlüsselung ausdrücklich als zulässige Methode zum Schutz gespeicherter PANs an. Gemäß DSGVO erfüllt FPE die Pseudonymisierungsanforderungen (Artikel 89), wenn der FPE-Schlüssel getrennt von den pseudonymisierten Daten gespeichert wird.

Wie werden FPE-Schlüssel verwaltet und rotiert?

FPE-Schlüssel sind AES-Schlüssel, die getrennt von den geschützten Daten in einem dedizierten KMS oder HSM gespeichert werden müssen. Die Schlüsselrotation für FPE erfordert die Entschlüsselung jedes geschützten Feldwertes mit dem alten Schlüssel und die anschließende Verschlüsselung mit dem neuen Schlüssel (im Gegensatz zur Standard-Envelope-Verschlüsselung, bei der nur der Hauptschlüssel rotiert wird, ohne die Daten zu verändern). Dies ist eine geplante Datenbankwartungsmaßnahme und keine transparente Hintergrundrotation. BYOK-Implementierungen generieren den FPE-Schlüssel in einem HSM und importieren ihn in das Cloud-KMS; HYOK-Implementierungen speichern den FPE-Schlüssel vollständig außerhalb des Cloud-Anbieters.