Formatbevarande kryptering med NIST-rekommendationer

Format Preserving Encryption (FPE) är en krypteringsteknik standardiserad av NIST i SP 800-38G som producerar chiffertext med samma format och längd som klartext. Detta är viktigt eftersom de flesta äldre databaser och applikationer inte kan lagra AES-chiffrerad text utan schemaändringar, vilket gör standardkryptering störande eller omöjlig att distribuera. Den rekommenderade åtgärden är att implementera FPE med hjälp av FF1-algoritmen med en FIPS 140-2-validerad kryptografisk modul, hantera FPE-nyckeln i ett dedikerat nyckelhanteringssystem separat från den krypterade datan och granska varje krypterings- och dekrypteringsoperation mot en autentiserad identitet.

Snabbt svar: När ska man använda formatbevarande kryptering?

Använd FPE när ett system har ett fält med fast längd eller fast format som inte kan ändras för att hantera utökad chiffertext, och där det krypterade värdet måste kunna användas som referensnyckel över flera system. Vanliga användningsfall är att skydda kreditkortsnummer (primära kontonummer eller PAN) enligt PCI DSS, personnummer enligt HIPAA, kontoidentifierare i äldre banksystem och alla strukturerade datafält där schemamigrering inte är möjlig. Använd inte FPE som ersättning för allmän autentiserad kryptering (AES-GCM): FPE tillhandahåller inte autentisering (den kan inte upptäcka manipulering), har lägre säkerhetsmarginaler än AES-GCM för samma nyckellängd och kräver noggrann nyckel- och justeringshantering för att undvika kryptografiska svagheter i FF3-1.

Key Takeaways

• FPE producerar chiffertext med samma format och längd som klartext: Ett 16-siffrigt kreditkortsnummer krypteras till en 16-siffrig chiffertext. Ett 9-siffrigt personnummer krypteras till en 9-siffrig chiffertext. Detta gör att krypterad data kan passera genom system som förväntar sig den ursprungliga datatypen utan schemaändringar eller applikationsmodifieringar.
• NIST SP 800-38G specificerar två godkända FPE-algoritmer, FF1 och FF3-1: Båda är Feistel-nätverkskonstruktioner byggda på AES. FF1 är den rekommenderade algoritmen för nya implementeringar. FF3-1 ersatte FF3 i 2024 års revision efter att säkerhetsbrister i FF3 identifierades; FF3 (originalet) rekommenderas inte längre.
• FPE tillhandahåller inte autentiserad kryptering: Till skillnad från AES-GCM har FPE ingen inbyggd meddelandeautentiseringskod (MAC). En angripare som kan ändra chiffertexten på plats kommer att producera annan giltig chiffertext utan att upptäckas. FPE måste användas tillsammans med integritetskontroller på applikations- eller databaslagret.
• Nyckelrotation för FPE kräver att alla skyddade fältvärden krypteras om: Eftersom chiffertexten måste matcha det ursprungliga fältformatet kräver omkodning att alla värden dekrypteras med den gamla nyckeln och krypteras om med den nya nyckeln. Detta är en planerad databasunderhållsoperation, inte en rotation med transparent bakgrund.
• FPE uppfyller PCI DSS-, HIPAA- och GDPR-kraven när de implementeras korrekt: FPE med en NIST SP 800-38G-kompatibel algoritm som använder en FIPS 140-2-validerad modul uppfyller krypteringskraven i PCI DSS v4.0.1 (krav 3.5.1 för PAN-skydd), HIPAA:s tekniska skyddsåtgärder (164.312(a)(2)(iv)) och GDPR:s pseudonymiseringskrav (artikel 89).

Vad är formatbevarande kryptering?

Format Preserving Encryption (FPE) är en krypteringsalgoritm som omvandlar klartext till chiffertext med exakt samma format och längd som originaldata. Standardkrypteringsalgoritmer som AES i CBC- eller GCM-läge producerar chiffertext som är längre än klartexten och innehåller tecken utanför det ursprungliga alfabetet. FPE, däremot, krypterar ett 16-siffrigt decimaltal till ett 16-siffrigt decimaltal, en 9-teckens alfanumerisk kod till en 9-teckens alfanumerisk kod, och så vidare, med hjälp av det finita symbolalfabet som klartexten använder.

Den här egenskapen är viktig eftersom de flesta produktionsdatabaser och applikationer definierar fält med strikta datatyper och fasta längder. Ett kreditkortsfält som definieras som en numerisk kolumn med 16 tecken kan inte lagra base64-kodad utdata från AES-128-kryptering (0B6X8rMr058Ow+z3Ju5wimxYERpomz402++zNozLhvw= är 44 tecken, inte 16, och innehåller icke-numeriska tecken). Att lagra AES-chiffrerad text i ett sådant fält skulle kräva en schemamigrering över databasen, ändringar i varje applikation som läser eller skriver till den kolumnen och uppdateringar i varje nedströmssystem som förväntar sig det ursprungliga formatet. För äldre system är sådana migreringar ofta tekniskt opraktiska eller oöverkomligt dyra. FPE eliminerar det kravet: det krypterade värdet passar det befintliga fältet utan någon schema- eller applikationsändring.

NIST SP 800-38G: Standarden som styr FPE

NIST SP 800-38G, Rekommendation för blockchifferlägen: Metoder för formatbevarande kryptering, är den auktoritativa NIST-standarden för FPE. Ursprungligen publicerad i mars 2016 och reviderad 2024, specificerar den två godkända FPE-algoritmer: FF1 och FF3-1. Båda är byggda på AES som underliggande blockchiffer, vilket innebär att de ärver AES:s FIPS 140-2-efterlevnadsstatus när de implementeras i en FIPS 140-2-validerad kryptografisk modul.

Standarden definierar FPE formellt: givet ett ändligt alfabet av symboler (såsom decimalsiffrorna 0 till 9, eller de alfanumeriska tecknen), omvandlar en FPE-algoritm en sekvens av symboler från det alfabetet till en annan sekvens av samma längd med samma alfabet, under en hemlig nyckel. Definitionen kräver ett minsta alfabet av två symboler och en minsta klartextlängd på två symboler. Den krypterade utdata kan inte skiljas från en slumpmässig permutation av klartextutrymmet under den givna nyckeln och justeringen, vilket ger säkerhet mot en angripare som inte känner till nyckeln.

Standarden specificerar också att FPE-nycklar måste vara AES-nycklar: 128-bitars, 192-bitars eller 256-bitars. För de flesta reglerade distributioner rekommenderas 256-bitarsnycklar för anpassning till FIPS 140-2 nivå 3-krav och för framåtkompatibilitet med planering efter kvantmigrering. Standarden specificerar inte nyckelhanteringsprocedurer; dessa regleras av NIST SP 800-57 (Rekommendation för nyckelhantering).

FF1 och FF3-1: De två NIST-godkända FPE-algoritmerna

NIST SP 800-38G specificerar två FPE-algoritmer, som var och en är lämpad för olika implementeringsscenarier.

FF1 (Formatbevarande Feistel-baserat krypteringsläge 1)

FF1 är den rekommenderade FPE-algoritmen för nya implementeringar. Det är en Feistel-nätverkskonstruktion som använder AES som rundningsfunktion, med en variabel längdjustering. Justeringen är en ytterligare inmatning (liknande en initialiseringsvektor) som gör att samma nyckel kan producera olika chiffertextutdata för samma klartextvärde när justeringen skiljer sig åt. Justeringen kan vara vilken bytesträng som helst av godtycklig längd, vilket ger FF1 flexibiliteten att införliva kontextuell data såsom en postidentifierare, ett tabellnamn eller ett transaktionsdatum som en del av krypteringsinmatningen utan att ändra nyckeln.

FF1 är lämpligt för de flesta FPE-användningsfall: kryptering av PAN-nummer, personnummer, kontonummer, telefonnummer och andra strukturerade datafält. Den stöder alla alfabetsstorlekar från 2 till 2^32 symboler och alla klartextlängder från 2 till 2^32 symboler (med förbehåll för begränsningen att alfabetsstorleken upphöjt till längden måste vara minst 100). FF1 är beräkningsmässigt något långsammare än FF3-1 på grund av fler Feistel-rundor, men prestandaskillnaden är försumbar för de flesta företagsarbetsbelastningar.

FF3-1 (Formatbevarande Feistel-baserat krypteringsläge 3, revision 1)

FF3-1 är den reviderade versionen av FF3, uppdaterad i 2024 års revision av NIST SP 800-38G efter att säkerhetsforskare identifierat en svaghet i den ursprungliga FF3-specifikationen. Svagheten gör det möjligt för en angripare som kan observera ett stort antal chiffertextvärden krypterade med samma nyckel och justera den att återställa information om nyckeln. 2024 års revision åtgärdar detta genom att kräva att justeringen ska vara exakt 7 byte (56 bitar) och genom att skärpa begränsningarna för hur många krypteringar som får utföras med samma nyckel-justeringspar.

FF3-1:s fasta 7-byte-justering är mer begränsad än FF1:s variabellängdsjustering, vilket gör FF3-1 mindre flexibel för användningsfall som kräver kontextuella justeringar. Den praktiska implikationen är att applikationer som använder FF3-1 måste hantera justeringsdiversitet noggrant för att undvika den kända attacken. För nya implementeringar rekommenderar NIST FF1 om det inte finns en specifik anledning att använda FF3-1. Organisationer som för närvarande använder FF3 (den ursprungliga versionen från före 2024) bör migrera till FF1 eller FF3-1.

Fast egendom	FF1	FF3-1
Standardiserad i	NIST SP 800-38G (2016, reviderad 2024)	NIST SP 800-38G (2016, reviderad 2024)
Underliggande blockchiffer	AES (128-, 192- eller 256-bitarsnyckel)	AES (128-, 192- eller 256-bitarsnyckel)
Justera längden	Variabel (valfri bytesträng)	Fast 7 byte (56 bitar)
Feistel-rundor	10	8
Alfabetstöd	2 till 2^32 symboler	2 till 2^32 symboler
Kända svagheter	Ingen identifierad i gällande specifikation	Ursprungliga FF3 hade svagheter i nyckelåterställning; FF3-1 åtgärdar det med justeringsbegränsningar
NIST-rekommendation för ny användning	Föredragen	Acceptabelt med strikt tweakhantering
Bäst för	De flesta FPE-användningsfall; flexibla tweak-applikationer	Äldre system använder redan FF3; tokenisering med korta fixade justeringar

Användningsfall för formatbevarande kryptering

FPE är mest värdefullt i användningsfall där dataformat och längd måste bevaras genom krypteringsprocessen. Följande är de primära användningsfallen för företag:

Skydd av betalkortsdata (PCI DSS PAN-kryptering): Primära kontonummer (PAN) är 16-siffriga nummer som flödar genom betalningssystem med strikta formatkrav. FPE tillåter att PAN krypteras vid inmatningspunkten och flödar som krypterade 16-siffriga värden genom alla nedströmssystem, inklusive äldre betalningsleverantörer, bedrägeriupptäcktsmotorer och rapporteringsdatabaser, utan någon systemmodifiering. PCI DSS v4.0.1 Krav 3.5.1 erkänner uttryckligen FPE som en acceptabel metod för att skydda lagrade PAN.

Skydd av patientidentifierare inom hälso- och sjukvården (HIPAA): Personnummer (9-siffriga), patientkontonummer och andra strukturerade identifierare som används i hälso- och sjukvårdsdatabaser är naturliga kandidater för FPE. Kryptering av ett 9-siffrigt personnummer med FPE returnerar ett 9-siffrigt krypterat värde som fortsätter att fungera som en söknyckel över länkade databaser utan att exponera den underliggande PII. Detta uppfyller HIPAA:s krav att skydda elektronisk skyddad hälsoinformation (ePHI) i vila enligt 45 CFR 164.312(a)(2)(iv).

Kryptering av äldre databaser utan schemamigrering: Organisationer med äldre databaser definierade med tecken- eller numeriska kolumner med fast längd kan använda FPE för att kryptera känsliga fält utan någon schemaändring, datamigrering eller applikationsmodifiering. Det krypterade värdet är av samma typ och längd som originalet, så alla befintliga frågor, index, lagrade procedurer och applikationer fortsätter att fungera. Kryptering kan tillämpas på applikationslagret eller, i vissa databassystem, på kolumnnivå genom användardefinierade funktioner.

Avidentifiering av data för analys och testning: Organisationer som behöver dela produktionsdatautdrag med analysteam, utvecklingsmiljöer eller revisorer kan använda FPE för att avidentifiera känsliga fält. De krypterade värdena bibehåller referensintegritet (samma klartext krypteras alltid till samma chiffertext under samma nyckel och justering), så kopplingar och aggregeringar mellan tabeller fortsätter att fungera korrekt på den avidentifierade informationen, medan den underliggande PII är skyddad. FPE är särskilt användbart för GDPR-pseudonymisering enligt artikel 89 när FPE-nyckeln lagras separat från den pseudonymiserade datamängden.

Molnmigrering av känsliga data: Vid migrering av känsliga data från lokala databaser till molnlagring tillåter FPE att data krypteras före uppladdning utan att schemat eller molndatabasens konfiguration behöver ändras. De krypterade värdena i molndatabasen förblir av samma typ och längd som originalen, vilket bibehåller kompatibilitet med alla programfrågor, medan de faktiska känsliga värdena skyddas av FPE-kryptering med en nyckel som lagras lokalt eller i en BYOK-konfiguration.

FPE-nyckelhantering: Native, BYOK och HYOK

Säkerheten för en FPE-implementering beror helt på skyddet av FPE-nyckeln. En komprometterad FPE-nyckel gör det möjligt för en angripare att dekryptera alla skyddade fältvärden i hela databasen. Nyckelhantering för FPE följer samma tremodellramverk som andra krypteringsanvändningsfall.

Inbyggd nyckelhantering (leverantörshanterad)

I en nativ nyckelhanteringsmodell genererar och hanterar molnleverantören eller FPE-tjänsten AES-nyckeln som används för FPE-åtgärder. Din applikation anropar FPE-tjänstens API med klartextvärdet och tar emot det krypterade värdet; själva nyckeln hanteras av tjänsten. Fördelen är minimal driftsomkostnad. Nackdelen är att tjänsteleverantören har operativ åtkomst till nyckeln och, i förlängningen, möjligheten att dekryptera alla FPE-skyddade värden. För de flesta allmänna efterlevnadsarbetsbelastningar är denna modell acceptabel när leverantören befinner sig inom din efterlevnadsgräns och tjänsten omfattas av lämpliga avtalskontroller (BAA för HIPAA, DPA för GDPR). För reglerade data som kräver kundnyckelns ursprung är nativ nyckelhantering otillräcklig.

BYOK (Ta med egen nyckel) för FPE

BYOK för FPE innebär att generera AES FPE-nyckeln i din egen hårdvarusäkerhetsmodul (HSM) eller nyckelhanteringssystem och importera den till FPE-tjänsten eller moln-KMS. FPE-nyckelmaterialet genereras under din kontroll, och din organisation kan oberoende verifiera dess ursprung. Molntjänsten använder ditt importerade nyckelmaterial för att utföra FPE-åtgärder, men du behåller originalnyckeln i din HSM och kan återkalla den genom att ta bort den importerade kopian från tjänsten. BYOK uppfyller myndighetskrav som föreskriver kundgenererat nyckelmaterial för kryptering av reglerad data (vissa PCI DSS QSA-tolkningar av krav 3.7.1, vissa FedRAMP-kontroller). Specifikt för FPE använder BYOK-implementeringar vanligtvis en lokal HSM eller en tredjeparts-HSM som en tjänst som nyckelgenereringskälla, med nyckeln importerad till moln-FPE-tjänsten.

HYOK (Håll din egen nyckel) för FPE

HYOK för FPE innebär att FPE-nyckeln aldrig kommer in i molntjänsten alls. FPE-kryptering och dekryptering utförs i din egen infrastruktur (ett lokalt applikationslager eller ett klientbibliotek), och endast de FPE-krypterade värdena laddas upp till molnlagring eller databaser. Molnleverantören lagrar endast chiffertext och kan inte dekryptera något skyddat fält, inte ens som svar på ett lagligt krav. HYOK ger den starkaste datasuveräniteten för FPE-användningsfall. Driftskostnaden är att varje FPE-krypterings- och dekrypteringsoperation måste göra en tur och retur till ditt lokala nyckelhanteringssystem, vilket måste vara mycket tillgängligt för att din applikation ska fungera. Denna arkitektur är lämplig för sekretessbelagda data, suveränitetsmandatmiljöer eller organisationer där molnleverantören själv ingår i hotmodellen.

Dimensionera	Inbyggd nyckelhantering	BYOK (kundgenererad nyckel i tjänst)	HYOK (FPE utförd utanför molnet)
FPE-nyckel genererad av	Molnleverantör eller FPE-tjänst	Kundens HSM (importerad till tjänst)	Kund (kommer aldrig in i molnet)
Leverantörsåtkomst till FPE-nyckel	Ja	Ja (operativ åtkomst)	Nej
Leverantören kan dekryptera FPE-fält	Ja	Ja (under drift)	Nej
Oberoende nyckelåterkallelse	Endast via tjänstens API	Ta bort importerad nyckel (omedelbart)	Återkalla vid lokal KMS
Operationell komplexitet	Låg	Medium	Hög
Krav på PCI DSS-nyckelns ursprung	Beror på QSA-tolkning	Uppfyller kundens viktigaste materialkrav	Tillfredsställer helt
Bäst för	Allmänna efterlevnadsarbetsbelastningar med leverantörskontroller	Reglerade sektorer som kräver oberoende nyckelproveniens	Hemliga, suveränitetsmandaterade miljöer med noll förtroende

IAM-modell för FPE Access Control

Åtkomstkontroll för FPE-operationer kräver samma trerollsseparation som gäller för alla nyckelhanteringssystem. Felaktig konfiguration av IAM för FPE är särskilt allvarlig eftersom FPE-nycklar skyddar strukturerade datafält som kan omfatta miljontals poster över flera databaser.

Roll som nyckeladministratör: Skapar, importerar och hanterar FPE-nyckelns livscykel. Auktoriserar skapande, rotationshändelser och borttagning av nyckel. Får inte vara samma identitet som det applikationstjänstkonto som utför FPE-åtgärder. Åtgärder för nyckeladministratör (skapande av nyckel, schemaläggning av borttagning, policyändringar) måste loggas och omfattas av dubbel kontroll för åtgärder med högt värde, såsom nyckelgenereringsceremonier och borttagning av nycklar som skyddar produktionsdata.

FPE-operatörsroll (kryptoansvarig): Utför API-anrop för FPE-kryptering och -dekryptering för applikationens räkning. Har behörighet att använda FPE-nyckeln för krypterings- och dekrypteringsåtgärder men inte att skapa, ta bort eller exportera nyckeln. I moln-KMS-termer mappas detta till att endast ge applikationstjänstkontot specifika krypterings- och dekrypteringsbehörigheter för den specifika FPE-nyckeln, inte bred KMS-åtkomst. För AWS-distributioner är detta kms:Encrypt och kms:Decrypt behörighet endast på den specifika nyckel-ARN:n. Tjänstkontrollpolicyer (SCP:er) i en AWS-organisation kan säkerställa att ingen applikationsroll erhåller nyckelhanteringsbehörigheter.

Datakonsumentroll (skrivskyddad åtkomst till krypterade fält): Program eller användare som läser databasfält som innehåller FPE-krypterade värden men inte behöver dekryptera dem (till exempel ett rapporteringssystem som behandlar det krypterade värdet som en ogenomskinlig identifierare för anslutningsändamål) ska inte ha FPE-dekrypteringsbehörighet alls. Endast det specifika programtjänstkonto som kräver läsbar klartext ska ha dekrypteringsåtkomst till FPE-nyckeln.

Nyckelrotation för FPE: Särskilda överväganden

Nyckelrotation för FPE skiljer sig fundamentalt från nyckelrotation för standardkryptering. I standardkuvertkryptering (som används av AWS KMS, Azure Key Vault och GCP Cloud KMS) innebär rotation av huvudnyckeln att man genererar nytt nyckelmaterial för huvudnyckeln och använder det för att ompaketera datakrypteringsnycklarna. Själva data behöver inte krypteras om. Med FPE finns det inget kuvertkrypteringslager: FPE-nyckeln krypterar fältvärdena direkt. Att rotera FPE-nyckeln kräver därför att varje skyddat fältvärde dekrypteras med den gamla nyckeln och krypteras om med den nya nyckeln, över varje tabell och kolumn som använder den FPE-nyckeln.

Detta har flera operativa konsekvenser. För det första kan FPE-nyckelrotation inte ske transparent i bakgrunden; det kräver ett planerat underhållsfönster eller en läs-skugga-arkitektur under rotationsperioden (där både den gamla och den nya nycklaren är aktiva, nya skrivningar använder den nya nyckeln och läsningar återgår till den gamla nyckeln om den nya nyckeln inte dekrypteras korrekt). För det andra är FPE-nyckelrotationsfrekvensen vanligtvis lägre än för vanliga KMS-nycklar: de flesta organisationer roterar FPE-nycklar årligen eller enligt ett definierat schema i linje med PCI DSS-krav 3.7.4 (som kräver periodiska kryptoperioder för symmetriska nycklar). För det tredje måste nyckelrotationsproceduren testas och repeteras innan den körs på produktionsdata, eftersom en misslyckad FPE-rotation som lämnar data i ett inkonsekvent nyckeltillstånd kan göra hela databaskolumner oåtkomliga.

Bästa praxis för FPE-nyckelrotation: underhåll en nyckelversionsidentifierare bredvid varje FPE-krypterat fält (en enda kolumn eller flagga som anger vilken nyckelversion som krypterade värdet); utforma applikationen för att acceptera både gamla och nya nyckelversioner under rotationsperioden; rotera i batchar för att begränsa omfattningen av eventuella fel; verifiera dekryptering med den nya nyckeln för varje batch innan gamla värden tas bort; och behåll den gamla nyckeln i ett arkiverat men oåtkomligt tillstånd tills all data har verifierats som roterad.

Granskningsloggning för FPE-operationer

Varje FPE-krypterings- och dekrypteringsoperation bör loggas med den begärande identiteten, tidsstämpeln, den nyckelidentifierare som används och fälttypen (utan värdet för klartext eller chiffertext). Granskningsloggar för FPE uppfyller kraven för efterlevnadsbevis enligt PCI DSS-krav 10 (loggning och övervakning) och HIPAA:s standard för revisionskontroll (45 CFR 164.312(b)).

För molnbaserade FPE-implementeringar som använder ett moln-KMS som nyckellager genererar varje FPE-operation som anropar KMS för att radbryta eller packa upp en datanyckel en CloudTrail-händelse (i AWS), en Azure Monitor-händelse (i Azure) eller en Cloud Audit Log-händelse (i GCP). Dessa revisionsspår per operation är en anledning till att reglerade organisationer föredrar moln-KMS-baserad FPE framför nyckellagring på applikationsnivå: revisionsspåret genereras automatiskt, är manipulationssäkert och kräver ingen anpassad logginfrastruktur.

Aviseringar om följande FPE-relaterade granskningshändelser: massdekrypteringsåtgärder mot FPE-skyddade kolumner av en identitet som inte finns i den godkända programrolllistan (ett möjligt dataextraktionsförsök); borttagning eller schemaläggning av FPE-nycklar för borttagning utanför en dokumenterad rotationshändelse; alla ändringar av FPE-nyckelpolicyn eller åtkomstkontrollerna; och FPE-åtgärder som kommer från IP-adresser eller IAM-identiteter som inte är associerade med kända programdistributioner.

Molnbaserade FPE-implementeringar

FPE-funktionalitet är tillgänglig via flera molnleverantörstjänster och kan även implementeras med hjälp av öppen källkodsbibliotek med ett moln-KMS som nyckellager. Implementeringsmetoden beror på om molntjänsten tillhandahåller inbyggt FPE-stöd eller om FPE måste implementeras på applikationslagret.

Google Cloud: Cloud DLP med FPE-avidentifiering

Google Cloud tillhandahåller inbyggd FPE-funktionalitet genom Cloud Data Loss Prevention (Cloud DLP), numera kallat Sensitive Data Protection. DLP API:et gör det möjligt för kunder att anropa FPE-kryptering och -dekryptering på strukturerade datafält, där FPE-nyckeln hanteras i Cloud KMS. DLP API:et stöder FF1-kryptering över decimalsiffrorna (för numeriska fält som kreditkortsnummer och personnummer) och över det alfanumeriska alfabetet (för identifierare med blandade tecken). Nyckeln som används för FPE kan vara en omsluten nyckel som lagras bredvid begäran (BYOK, där omslutningen görs av uppringarens Cloud KMS-nyckel) eller en Cloud KMS-hanterad nyckel. Cloud DLP FPE uppfyller PCI DSS-kraven för PAN-skydd och HIPAA-kraven för ePHI-avidentifiering när den konfigureras med lämpliga nyckelåtkomstkontroller.

AWS: Applikationslager-FPE med AWS KMS-nyckelstöd

AWS erbjuder inte en inbyggd FPE API-tjänst. AWS-implementeringar av FPE använder ett FPE-bibliotek på applikationslagret (som de öppna källkodsimplementeringarna FF1 eller FF3-1 som är tillgängliga för Java, Python och Go) med FPE-nyckeln lagrad i och hämtad från AWS KMS. Applikationen hämtar AES-nyckeln från KMS vid start eller på begäran, utför FPE-operationer lokalt med den hämtade nyckeln och skriver endast de FPE-krypterade värdena till databasen. FPE-nyckeln som lagras i AWS KMS kan vara en kundhanterad nyckel med BYOK (importerat nyckelmaterial med Origin: EXTERNAL) eller en KMS-genererad nyckel. Alla nyckelåtkomstoperationer genererar CloudTrail-händelser som tillhandahåller revisionsloggen för nyckelanvändning. Denna metod ger organisationer full kontroll över FPE-algoritmimplementeringen samtidigt som AWS KMS utnyttjar för nyckelskydd och revisionsloggning.

Azure: Applikationslager-FPE med Azure Key Vault-nyckelbackup

Azure tillhandahåller inte heller en inbyggd FPE API-tjänst. Azure FPE-implementeringar använder FPE-bibliotek på applikationsnivån med AES-nyckeln lagrad i Azure Key Vault (standard- eller HSM-skyddad nivå). Azure Key Vault stöder kundhanterade nycklar, BYOK (nyckelimport från din egen HSM) och HSM-skyddad nyckellagring i Azure Dedicated HSM för FIPS 140-2 nivå 3-validering. Alla Key Vault-åtgärder genererar Azure Monitor-granskningsloggar. Azure Purview (nu Microsoft Purview) tillhandahåller dataklassificeringsfunktioner som kan identifiera känsliga fält som kräver FPE-skydd, vilket gör det till ett användbart identifieringsverktyg före FPE-implementering.

FPE kontra tokenisering: Att välja rätt metod

FPE och tokenisering används ofta för samma syfte (skydda strukturerade datafält utan att ändra deras format) men fungerar olika och har olika säkerhetsegenskaper.

Tokenisering ersätter ett känsligt värde med ett slumpmässigt genererat surrogatvärde (en token) i samma format, lagrat i ett tokenvalv som mappar tokens tillbaka till ursprungliga värden. Tokenen har ingen matematisk relation till det ursprungliga värdet; att återställa originalet kräver en sökning i tokenvalvet. Tokenisering ger stark säkerhet eftersom även om tokenvalvet komprometterats isolerat avslöjar token ingenting om det ursprungliga värdet utan den fullständiga mappningstabellen. Tokenisering kräver dock ett centraliserat tokenvalv som måste vara mycket tillgängligt, kan bli en flaskhals och måste skyddas som ett primärt mål för angripare.

FPE är deterministiskt och valvlöst: samma klartextvärde krypterat med samma nyckel och justering producerar alltid samma chiffertext, utan att någon sökning krävs. Detta gör FPE tillståndslös och mycket skalbar, men det betyder också att FPE-chiffrerad text kan utsättas för frekvensanalys om klartextutrymmet är litet (till exempel producerar ett ensiffrigt fält med värdena 0 till 9 endast 10 möjliga chiffertexter, vilket gör frekvensanalys trivial). FPE är lämpligt för fält med stora klartextmellanrum (16-siffriga kreditkortsnummer har 10^16 möjliga värden; frekvensanalys är inte praktiskt). För små klartextmellanrum är tokenisering det lämpligaste valet.

Regelefterlevnad: PCI DSS, HIPAA och GDPR

PCI DSS v4.0.1 (obligatoriskt sedan 31 mars 2025): Krav 3.5.1 kräver att primära kontonummer (PAN) som lagras i alla miljöer som omfattas av PCI DSS ska göras oläsliga med hjälp av stark kryptografi. FPE med FF1 eller FF3-1 med en 256-bitars AES-nyckel och korrekt nyckelhantering uppfyller detta krav. PCI DSS-ordlistan listar uttryckligen formatbevarande kryptering som en acceptabel renderingsmetod. Krav 3.7.1 till 3.7.9 styr nyckelhantering för FPE-nyckeln, inklusive nyckelgenereringsprocedurer, nyckelförvaltarroller, nyckelrotationsscheman och nyckelförstöringsprocedurer. Krav 10 styr revisionsloggning för all åtkomst till kortinnehavardata, inklusive FPE-krypterings- och dekrypteringsoperationer.

HIPAA Tekniska Säkerhetsåtgärder: Krypterings- och dekrypteringsstandarden (45 CFR 164.312(a)(2)(iv)) kräver att vilande ePHI krypteras med hjälp av en mekanism för att skydda den från obehörig åtkomst. FPE med NIST SP 800-38G-kompatibla algoritmer uppfyller denna standard. NIST Special Publication 800-111 (Guide to Storage Encryption Technologies for End User Devices) och HHS-vägledningen om kryptering och dekryptering erkänner båda AES-baserad kryptering som uppfyllande av HIPAA-krypteringsstandarden; FPE byggd på AES ärver den efterlevnadsstatusen. Audit Control-standarden (45 CFR 164.312(b)) kräver loggning av åtkomst till ePHI, vilket uppfylls av de revisionsloggar per operation som genereras av FPE-nyckelhanteringssystemet.

GDPR-pseudonymisering (artiklarna 25 och 89): GDPR-artikel 89 medger minskade krav på registrerades rättigheter (rätt till radering, rätt till tillgång) för pseudonymiserade uppgifter som används för forsknings- eller statistiska ändamål. FPE uppfyller GDPR:s definition av pseudonymisering (artikel 4(5): behandling av personuppgifter på ett sådant sätt att personuppgifterna inte längre kan hänföras till en specifik registrerad utan användning av ytterligare information) när FPE-nyckeln lagras separat från de pseudonymiserade uppgifterna och skyddas med lämpliga åtkomstkontroller. FPE-pseudonymiserade datamängder kan delas med analysteam eller forskningspartners med minskad efterlevnadsbörda när FPE-nyckeln inte ingår i de delade uppgifterna.

FPE-begränsningar och vad man ska se upp med

FPE har viktiga begränsningar som måste förstås före driftsättning.

Ingen autentisering: FPE tillhandahåller inte autentiserad kryptering. En angripare som kan modifiera FPE-krypterade värden i databasen kommer att producera olika giltiga krypterade värden utan att upptäckas. Integritetskontroller på databasnivå (hashbaserade kontrollsummor, MAC:er på applikationslagret eller databasutlösare) behövs för att upptäcka obehörig modifiering av FPE-skyddade fält.

Determinism möjliggör frekvensanalys för små klartextutrymmen: Eftersom samma klartext alltid krypteras till samma chiffertext under samma nyckel och justering, kan FPE-krypterade fält utsättas för frekvensanalys när klartextutrymmet är litet. Ett fält som endast innehåller värdena 0 till 9 producerar endast 10 distinkta chiffertexter; en angripare som känner till fördelningen av de ursprungliga värdena kan ofta identifiera dem igen från fördelningen av de krypterade värdena. Justeringar mildrar detta genom att göra chiffertexten beroende av justeringen såväl som klartexten och nyckeln; använd en justering per post eller per transaktion när det är möjligt.

Nyckelrotation kräver fullständig omkryptering: Som beskrivs i avsnittet om nyckelrotation kräver rotation av en FPE-nyckel att varje värde i varje skyddat fält omkrypteras. Detta är en betydande driftsbörda för stora databaser och måste planeras noggrant.

FF3 (original, före 2024) rekommenderas inte längre: Organisationer som använder FF3-implementationer (inte FF3-1) bör migrera till FF1 eller FF3-1. Den ursprungliga FF3 har en känd svaghet i nyckelåterställning när samma nyckel- och tweak-kombination återanvänds över många krypteringar. De flesta kommersiella FPE-bibliotek har uppdaterats till FF3-1 eller FF1, men verifiera din biblioteksversion innan du antar att den följer gällande NIST-riktlinjer.

Hur krypteringskonsulting kan hjälpa

Encryption Consulting är ett företag inom tillämpad kryptografi med ISO/IEC 27001:2022- och SOC 2-certifieringar. Vi hjälper organisationer att designa, implementera och granska FPE-implementeringar för PCI DSS, HIPAA, GDPR och andra efterlevnadsramverk.

• FPE-arkitektur och implementering: Vi utformar FPE-arkitekturen för din miljö, inklusive algoritmval (FF1 vs. FF3-1), justeringsstrategi, nyckelhanteringsmodell (native, BYOK eller HYOK), IAM-rollstruktur, rotationsprocedur och konfiguration för granskningsloggning. Vi implementerar och testar FPE-integrationen för AWS KMS-baserade, Azure Key Vault-baserade eller Google Cloud DLP-distributioner. Se vår dataskyddstjänster.
• HSM som en tjänst för FPE-nyckelgenerering: För BYOK FPE-implementeringar som kräver FIPS 140-2 nivå 3-nyckelgenerering, Encryption Consultings HSM som en tjänst tillhandahåller dedikerad HSM-infrastruktur som källa för nyckelgenerering. FPE-nycklar genereras i HSM, exporteras i inpackad form och importeras till din moln-KMS eller FPE-tjänst. HSM as a Service är tillgänglig i AWS-, Azure- och GCP-miljöer.
• CBOM säker för FPE-upptäckt: Innan FPE implementeras måste organisationer identifiera alla fält i sin databas som innehåller känsliga strukturerade data som kräver FPE-skydd. Encryption Consultings CBOM-säkerhet upptäcker och inventerar alla känsliga datafält, befintliga krypteringsimplementeringar och kryptografiska luckor i moln- och lokala miljöer, och genererar en kryptografisk materiallista som prioriterar FPE-implementering efter risk och brådska i efterlevnaden.
• Råd om efterlevnad av PCI DSS och HIPAA: Vi anpassar er FPE-implementering till de specifika kraven i PCI DSS v4.0.1 (krav 3.5.1, 3.7.1 till 3.7.9 och krav 10), HIPAA:s tekniska skyddsåtgärder och GDPR:s pseudonymiseringskrav. Vi identifierar luckor, tar fram ett paket med efterlevnadsbevis och hjälper till med QSA- och revisorförfrågningar. Se våra Rådgivning om efterlevnad.
• PQC-beredskap för FPE: FPE-algoritmer bygger på AES, vilket inte direkt hotas av kvantberäkning inom kort (AES-256 kräver att nyckelsökningsutrymmet för Grovers algoritm fördubblas, samtidigt som tillräcklig säkerhet bibehålls). Emellertid kan nyckelhanteringsinfrastrukturen som skyddar FPE-nycklar (RSA-baserad nyckelomslagning, ECDH för nyckelutbyte) behöva migreras till postkvantalgoritmer före 2030. Encryption Consultings PQC-beredskap Tjänsten utvärderar din FPE-nyckelhanteringsinfrastruktur mot NISTs tidslinje efter kvantmigrering (NIST IR 8547, RSA/ECC föråldrad ~2030).

För att diskutera dina FPE-implementeringskrav, kontakta Encryption Consulting.

Slutsats

Formatbevarande kryptering med NIST SP 800-38G-rekommendationer ger en praktisk väg att kryptera känslig strukturerad data i miljöer där schemaändringar inte är genomförbara. De två NIST-godkända algoritmerna, FF1 och FF3-1, är båda byggda på AES och är FIPS 140-2-kompatibla när de implementeras med en validerad kryptografisk modul. FF1 är den rekommenderade algoritmen för nya implementeringar; FF3-1 är acceptabel med strikt hantering av tweaks och diversitet. FPE uppfyller PCI DSS v4.0.1 PAN-skyddskrav, HIPAA ePHI-krypteringskrav och GDPR-pseudonymiseringskrav när det kombineras med korrekt nyckelhantering och granskningsloggning.

De viktigaste operativa övervägandena för FPE är nyckelseparation från de data den skyddar, noggrann IAM-rolldesign för att begränsa dekrypteringsåtkomst till endast de applikationsidentiteter som kräver det, och den operativa komplexiteten hos nyckelrotation som kräver fullständig omkryptering av alla skyddade fältvärden. Att få dessa rätt från designtidpunkten, snarare än att eftermontera dem i en distribuerad FPE-implementering, är betydligt enklare och ger en mer försvarbar efterlevnadsposition.

Vanliga frågor om partihandel med mat och dryck

Vad är Format Preserving Encryption (FPE)?

Formatbevarande kryptering (FPE) är en krypteringsteknik som producerar chiffertext med samma format och längd som klartexten. Kryptering av ett 16-siffrigt kreditkortsnummer returnerar ett 16-siffrigt krypterat värde; kryptering av ett 9-siffrigt personnummer returnerar ett 9-siffrigt krypterat värde. NIST SP 800-38G standardiserar två FPE-algoritmer: FF1 (rekommenderas för nya implementeringar) och FF3-1. Båda är byggda på AES och är FIPS 140-2-kompatibla när de implementeras med en validerad kryptografisk modul.

Vad är NIST SP 800-38G och vad specificerar den för FPE?

NIST SP 800-38G, Rekommendation för Block Cipher Modes of Operation: Methods for Format-Preserving Encryption, är den auktoritativa NIST-standarden för FPE. Först publicerad 2016 och reviderad 2024, specificerar den FF1 och FF3-1 som de två godkända FPE-algoritmerna. Båda kräver AES-nycklar (128-bitars, 192-bitars eller 256-bitars). FF3-1 ersatte den ursprungliga FF3 efter att säkerhetsbrister i FF3 identifierades; organisationer som använder FF3 bör migrera till FF1 eller FF3-1.

När bör man använda FPE istället för vanlig AES-kryptering?

Använd FPE när applikationen eller databasen har ett fält med fast längd som inte kan hantera utökad AES-chiffreringstext, när det krypterade värdet måste fungera som en referensnyckel över flera system som förväntar sig originalformatet, eller vid kryptering av äldre systemdata utan schemamigrering. Använd inte FPE som en allmän autentiserad krypteringsersättning: FPE tillhandahåller ingen autentisering (den kan inte upptäcka manipulering) och har lägre säkerhetsmarginaler än AES-GCM för motsvarande nyckellängder.

Vad är skillnaden mellan FF1 och FF3-1?

Både FF1 och FF3-1 är Feistel-baserade FPE-algoritmer som använder AES. FF1 använder en variabel längdjustering, vilket gör den mer flexibel för applikationer som behöver kontextuell inmatning till krypteringen. FF3-1 använder en fast 7-byte-justering och designades för tokeniseringsanvändningsfall med korta kontextuella värden. FF3-1 reviderade den ursprungliga FF3 efter att en svaghet i nyckelåterställning identifierades i FF3 när samma nyckeljusteringspar återanvänds i många meddelanden. För nya implementeringar rekommenderar NIST FF1.

Uppfyller FPE kraven för HIPAA och PCI DSS?

Ja. FPE med NIST SP 800-38G-kompatibla algoritmer (FF1 eller FF3-1) som använder FIPS 140-2-validerade moduler uppfyller HIPAA Technical Safeguards (45 CFR 164.312(a)(2)(iv)) för ePHI i vila. PCI DSS v4.0.1 Krav 3.5.1 erkänner uttryckligen formatbevarande kryptering som en acceptabel metod för att skydda lagrade PAN:er. Enligt GDPR uppfyller FPE pseudonymiseringskraven (artikel 89) när FPE-nyckeln lagras separat från den pseudonymiserade informationen.

Hur hanteras och roteras FPE-nycklar?

FPE-nycklar är AES-nycklar som måste lagras separat från de data de skyddar, i en dedikerad KMS eller HSM. Nyckelrotation för FPE kräver att varje skyddat fältvärde dekrypteras med den gamla nyckeln och krypteras om med den nya nyckeln (till skillnad från standardkuvertkryptering, där endast huvudnyckeln roteras utan att data vidrörs). Detta är en planerad databasunderhållsoperation, inte en transparent bakgrundsrotation. BYOK-implementeringar genererar FPE-nyckeln i en HSM och importerar den till moln-KMS:en; HYOK-implementeringar håller FPE-nyckeln helt utanför molnleverantören.