Praktisk nyckelhantering inom banksektorn

Publicerad: januari 2023. Uppdaterad: augusti 2026. Granskad av Encryption Consultings HSM- och nyckelhanteringsteam.

En bank förlorar inte kundernas förtroende för att en algoritm var svag. Den förlorar förtroendet för att en nyckel hanterades fel: lämnades i klartext på en delad enhet, roterades sent eller laddades av en ingenjör utan något vittne i rummet. Nyckelhantering inom banksektorn är en snävare och strängare disciplin än allmän företagsnyckelhantering, eftersom betalningsnätverk, kortvarumärken och PCI-bedömare alla definierar exakt hur en nyckel kan genereras, delas, transporteras och pensioneras, och av vem. Denna guide är det operativa, dagliga ramverket som ett team för bankefterlevnad eller nyckelförvaltare kör: roller och styrningskadens, betalningsnyckelhierarkin, TR-31- och TR-34-arbetsflöden i praktiken, PCI PIN-kontroller, HA- och DR-testning, logistik för nyckelceremonier, ett integrationsarbetsflöde och de revisionsbevis som en QSA kommer att begära.

Vad innebär praktisk nyckelhantering inom bankverksamhet?

Praktisk nyckelhantering inom banksektorn är den heltäckande disciplinen att generera, distribuera, lagra, rotera och ta bort de symmetriska nycklar som skyddar PIN-koder, kortdata och transaktionsmeddelanden, allt upprätthållet i en validerad hårdvarusäkerhetsmodul (HSM) . Den skiljer sig från den nyckelhantering som de flesta IT-team redan använder för TLS-certifikat eller PKI på ett viktigt sätt: PCI PIN-säkerhetskrav kräver dubbel kontroll och delad kunskap för varje nyckeloperation, så ingen enskild person kan någonsin rekonstruera en aktiv nyckel ensam.

En betalnings-HSM är ankaret för denna disciplin. Det är en manipulationssäker enhet som validerats under PCI PTS HSM-programmet, specialbyggd för att generera nycklar, översätta PIN-block mellan format, verifiera MAC-adresser och upprätthålla de åtkomstkontroller som en generell HSM aldrig var utformad för. Allt nedanför, rollerna, hierarkin, utbytesstandarderna och efterlevnadskontrollerna, finns för att skydda enhetens nycklar från det ögonblick de föds till det ögonblick de förstörs.

Vem äger praktisk nyckelhantering, och hur ofta granskas den?

Ett praktiskt nyckelhanteringsprogram tilldelar namngivna, ansvariga roller till varje nyckeloperation och granskar hela programmet enligt ett fast schema, inte bara när en bedömare ber om det. PCI PIN-säkerhetskrav förutsätter att specifika individer, inte en teambrevlåda, signerar för varje kontroll.

Roll	Ansvar	Granskningskadens
Nyckelförvaltare	Håller en komponent av en delad nyckel under dubbel kontroll; har aldrig tillgång till en komplett nyckel ensam	Ombekräftas årligen; ersätts omedelbart vid rollbyte eller uppsägning
Informationssäkerhetsansvarig eller kryptoansvarig	Äger nyckelhanteringspolicyn, godkänner ceremonimanus och undertecknar kryptoperioder	Policyn ses över minst en gång per år, eller vid väsentliga förändringar av PCI PIN-omfattningen
HSM-administratör	Hanterar enhetskonfiguration, firmware och åtkomstkontrolllistor, separat från viktiga vaktmästareuppgifter	Åtkomst granskas kvartalsvis
Compliance- eller revisionsansvarig	Upprätthåller det viktigaste inventarieregistret och samlar in bevis inför PCI PIN-bedömningen	Lageravstämning sker månadsvis; fullständig bedömningsförberedelsecykel årligen
Oberoende vittne eller internrevision	Observerar viktiga ceremonier och intygar att dubbel kontroll och delad kunskap följdes	Närvarande vid varje ceremoni, inte provtagen

Arbetsuppdelning är den operativa punkten här: personen som administrerar HSM bör inte också vara nyckelförvaltare för de nycklar som HSM skyddar, och personen som godkänner ett ceremonimanus bör inte vara samma person som utför det. En PCI QSA kommer att fråga vem som innehar varje roll med namn, inte enbart med titel.

Hur fungerar betalningsnyckelhierarkin i den dagliga verksamheten?

En betalnings-HSM skyddar en lagerhög hierarki av nycklar, där varje nyckel på högre nivå endast existerar för att skydda nyckeln under den, så att en enskild komprometterad nyckel aldrig exponerar live-transaktionsdata på egen hand. I den dagliga verksamheten är det denna hierarki som en nyckelförvaltare faktiskt hanterar, inte ett abstrakt diagram.

Nyckeltyp	Syfte	Typisk rotationskadens
Zonens huvudnyckel (ZMK)	Skyddar nyckelkrypteringsnycklar som utväxlas mellan två institutioner, såsom en inlösare och en processor, via en delad anslutning som kallas en "zon".	Fastställs genom kontrakt eller nätverkspolicy, vanligtvis vartannat till vartannat år, eller omedelbart vid misstänkt kompromettering
Krypteringsnyckel (KEK)	Krypterar arbetsnycklar för transport och lagring under ZMK	Årligen, eller enligt kryptoperiodens riktlinjer i PCI PIN-säkerhetskrav
Arbetsnyckel (PIN-krypteringsnyckel, MAC-nyckel eller datakrypteringsnyckel)	Krypterar fält för transaktioner i realtid: PIN-block, meddelandeautentiseringskoder eller kortinnehavardata under överföring	Sessionsbaserad, eller härledd per transaktion enligt DUKPT (ANSI X9.24-3)
PIN-nyckel: Base Derivation Key (BDK) och Initial PIN Encryption Key (IPEK)	Skapar en unik nyckel per enhet som DUKPT sedan härleder till en unik nyckel för varje transaktion	Laddas en gång vid tillverkning eller inmatning av enheten; den härledda transaktionsnyckeln återanvänds aldrig

Den sista raden är viktigare än den ser ut. Derived Unique Key Per Transaction, definierad i ANSI X9.24-3-2017 för AES och täckt av den bredare symmetriska nyckelhanteringsstandarden ANSI X9.24-1-2017, låter en POS-enhet använda en ny nyckel för varje enskild transaktion utan att någon sida behöver synkronisera en delad nyckel efter varje användning. Det är därför en stulen POS-terminal inte komprometterar varje transaktion som enheten någonsin behandlat. För den djupare kryptografin bakom denna hierarki, inklusive DUKPT-derivering och symmetrisk algoritmval, se vårt tillhörande inlägg, Vilka är utmaningarna med symmetrisk kryptografi?

Hur fungerar TR-31- och TR-34-arbetsflöden i den dagliga verksamheten?

TR-31 slår ihop en nyckel med dess användningsattribut för transport mellan två enheter som redan delar en nyckelkrypteringsnyckel, medan TR-34 använder asymmetrisk, offentlig nyckelkryptografi för att etablera den allra första delade nyckeln utan en manuell, personlig ceremoni. För ett driftteam är den praktiska skillnaden vilken man använder en given dag: TR-31 är det som körs under rutinmässig nyckelrotation, och TR-34 är det som körs vid onboarding av en ny enhet eller motpart. För den fullständiga tekniska mekaniken för båda standarderna, se vårt tillhörande inlägg, Vilka är utmaningarna med symmetrisk kryptografi?; det här avsnittet behandlar när och hur ett driftteam använder var och en.

TR-31 i daglig drift: ASC X9 TR-31-2018, ”Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms”, binder en nyckel till metadata som beskriver dess algoritm, användning och exportrestriktioner inuti ett enda autentiserat nyckelblock, och krypterar sedan MAC:er som blockerar under den befintliga KEK:n. Två HSM:er som redan delar en ZMK eller KEK använder TR-31 för varje rutinmässigt nyckelutbyte därefter: rotera en arbetsnyckel enligt schema, skicka en ny PIN-krypteringsnyckel eller flytta en nyckel mellan ett HSM-klusters noder under underhåll. Ett driftteam kör vanligtvis detta som ett schemalagt jobb med låg beröring när den initiala relationen existerar. Den ANSI-publicerade efterföljande standarden, X9.143-2021, ”Retail Financial Services, Interoperable Secure Key Block Specification”, är nu positionerad för att ersätta TR-31 för nya distributioner, så bekräfta vilket format din HSM-leverantör och ditt betalningsnätverk för närvarande stöder innan du standardiserar.

TR-34 i daglig verksamhet: ASC X9 TR-34-2019, ”Interoperabel metod för distribution av symmetriska nycklar med hjälp av asymmetriska tekniker”, löser bootstrap-problemet: hur upprättar två parter en första delad hemlighet när de aldrig har utbytt en nyckel förut? TR-34 använder RSA-baserad unilateral nyckeltransport så att en nyckel kan laddas på distans, autentiseras med ett digitalt certifikat, utan att någon nyckelförvaltare fysiskt närvarande är vid den mottagande enheten. För ett driftteam är detta arbetsflödet som utlöses av en ny utrullning av bankomater, en ny utrullning av POS-flottan eller en ny inlösarrelation, snarare än något som körs enligt ett återkommande schema.

Standard	Kryptografi används	Problemet det löser	Typiskt användningsfall
ASC X9 TR-31-2018	Symmetrisk (nyckelblocksomslutning under en befintlig KEK)	Utbyte av en nyckel plus dess användningsattribut när en KEK-relation redan finns	Rutinmässigt HSM-till-HSM-nyckelutbyte inom en etablerad nätverksrelation
ASC X9 TR-34-2019	Asymmetrisk (RSA-baserad ensidig nyckeltransport)	Laddar den första nyckeln eller KEK:n på en enhet utan tidigare delad hemlighet	Fjärrinläsning av nyckel och initial nyckelinmatning för nya POI-enheter eller nya institutionella relationer

Vad är checklistan för PCI PIN-kontroller för ett operationsteam?

PCI PIN-säkerhetskrav version 3.1, publicerade av PCI Security Standards Council och trädde i kraft den 12 mars 2021, grupperar sina kontroller i två domäner: hur PIN-koder och nycklar hanteras och hur enheterna som bearbetar dem säkras. Ett complianceteam kan spåra dessa som en återkommande operativ checklista snarare än en engångsbedömning.

• Dubbel kontroll och delad kunskap bekräftad för varje nyckelgenerering, inläsning och förstörelsehändelse, så ingen enskild person känner till eller innehar en komplett kryptografisk nyckel.
• Knappblock eller motsvarande kontroller verifierad för varje symmetriskt nyckelutbyte, vilket binder varje nyckel till dess tillåtna användning.
• Dokumenterade viktiga ceremonier arkiverad för varje aktiv zonhuvudnyckel och nyckelkrypteringsnyckel, med namngivna förvaltare och vittnen.
• PCI PTS-godkända HSM:er bekräftad ström på PCI SSC-godkända enhetslista, driftsatt i en kontrollerad eller säker miljö enligt PCI SSC-riktlinjerna.
• Formella avtal om viktiga förvaringsinstitut undertecknad och aktuell, vilket begränsar installation av och åtkomst till specifika, ansvariga individer.
• Ingen kunskap om klartextnyckel av en enskild individ när som helst under nyckelns livstid, från generering till förstörelse, verifierad genom logggranskning.

Version 3.1 skrev också om sin normativa bilaga om nyckelstorlekar och algoritmstyrka för att bättre anpassa den till NIST-riktlinjerna, och den införlivade de uppskjutna ikraftträdandedatumen för implementering av nyckelblock som PCI SSC hade tillkännagivit 2020. Om din senaste PIN-bedömning föregår 2021, anta att kontrollspråket du bedömdes mot har ändrats och kör denna checklista mot din nuvarande miljö före ditt nästa bedömningsfönster, inte under det.

Hur testar man HA och DR för betalnings-HSM:er kontinuerligt?

Hög tillgänglighet och katastrofåterställning löser två olika problem för en HSM-fastighet för betalningar: HA håller transaktioner auktoriserade under ett enskilt nodfel, och DR håller själva nyckelmaterialet återställbart efter att en webbplats har gått förlorad helt. En produktionsdistribution behöver båda, och båda behöver en testkadens, inte bara en initial design.

För HA, klustra betalnings-HSM:er i en aktiv-aktiv eller aktiv-passiv topologi bakom en lastbalanserad switchintegration, så att ett hårdvarufel eller underhållsfönster inte stoppar PIN-översättning eller MAC-verifiering. Testa nod-redundans med ett återkommande schema, vanligtvis kvartalsvis, och logga den faktiska tiden till återställning mot ditt mål. För DR är det svårare kravet nyckelhållbarhet: exportera nyckelkomponenter under samma dubbla kontroll- och delade kunskapsregler som används vid generering, förvara dem i manipuleringssäker förpackning på en fysiskt separerad säker plats och testa den faktiska återställningsprocessen, inte bara redundansnätverksvägen, minst en gång per år. Ett kluster som redundansväxlar direkt men inte kan återställa sina nycklar efter en platsförlust har löst den enkla halvan av problemet. Ställ in din återställningstid och dina mål för återställningspunkt mot verkliga betalnings-SLA:er och öva på redundansväxlingen enligt en fast kalender, med resultat som rapporteras till kryptoansvarig eller informationssäkerhetsansvarig, och inte lämnas som ett oprövat antagande i ett designdokument.

Hur schemalägger och genomför man en banknyckelceremoni?

En nyckelceremoni är den bevittnade, skriptade process som används för att generera eller ladda en zonmasternyckel eller nyckelkrypteringsnyckel under dubbel kontroll, så att ingen enskild person någonsin innehar en komplett, användbar nyckel. Det är den procedurmässiga kontrollen som gör resten av PCI PIN:s nyckelhanteringskrav verkliga snarare än teoretiska, och den måste schemaläggas och logistiskt planeras som alla andra granskade händelser, inte köras ad hoc.

1. Skriv och godkänn ceremonimanuset i förväg, och namnge varje steg, roll och obligatoriskt godkännande.
2. Schemalägg ceremonin med tillräckligt med förberedelsetid för att bekräfta alla vårdnadshavares tillgänglighet, eftersom en ceremoni inte kan genomföras med en ersättande vårdnadshavare som inte ingick i det godkända manuset.
3. Samla de viktigaste förvaltarna, minst två och ofta tre eller fler vid en m-of-n-uppdelning, plus ett oberoende vittne eller revisor.
4. Generera nyckeln inuti HSM:s certifierade slumptalsgenerator, aldrig utanför den.
5. Dela upp nyckeln i komponenter under dubbel kontroll, så att varje förvaltare bara ser eller innehar sin egen komponent.
6. Registrera förvaltarens identiteter, komponenternas serienummer och vittnesunderskrifter i ceremoniloggen.
7. Förvara fysiska komponenter i manipulationssäker förpackning på separata, åtkomstkontrollerade platser och logga förvaringsplatsen som en del av beviskedjan.
8. Behåll den ifyllda ceremoniloggen som den primära revisionsartefakten under nyckelns hela livscykel och kalenderlägg nästa schemalagda ceremoni mot nyckelns kryptoperiod så att den aldrig blir en nödceremoni för omceremonin.

Hur integrerar man en betalnings-HSM? Ett steg-för-steg-arbetsflöde

1. Omfatta distributionen och bekräfta att HSM-betalningsmodellen är PCI PTS HSM-godkänd för ditt avsedda användningsfall.
2. Definiera viktiga förvaltarroller och procedurer för dubbel kontroll och delad kunskap innan någon nyckel genereras.
3. Kör den första nyckelceremonin för att generera zonens huvudnyckel och eventuella nödvändiga nyckelkrypteringsnycklar.
4. Upprätta det första nyckelutbytet med TR-34-fjärrinläsning av nyckel, eller en personlig inläsning där ingen certifikatinfrastruktur ännu finns, och flytta sedan pågående utbyten till TR-31-nyckelblock.
5. Segmentera nätverket kring HSM och begränsa administrativ åtkomst till endast namngivna, ansvariga förvaltare.
6. Integrera HSM med betalningsväxeln, PIN-översättningstjänsten eller applikationen via dess värdkommandouppsättning eller API.
7. Konfigurera HA-klusterning och en testad DR-redundansväxlingssökväg före driftsättning, inte efter.
8. Testa transaktionsflöden från början till slut, inklusive PIN-översättning, formatkonvertering och MAC-verifiering, i en icke-produktionsmiljö.
9. Dokumentera policyn för nyckelhantering, ceremoniregister och HSM-konfiguration enligt den bevisstandard som PCI PIN-bedömare förväntar sig.
10. Schemalägg löpande nyckelrotation, firmware- och valideringskontroller, HA/DR-testcykler och regelbundna omceremonier när nycklarna löper ut.

Vilka revisionsbevis bör ett bankefterlevnadsteam upprätthålla kontinuerligt?

En PCI QSA som bedömer PIN-säkerhet vill ha dokumenterat bevis på processen, inte bara en betalnings-HSM som fungerar korrekt i produktion. Bevisen nedan bör vara en levande uppsättning register som ett compliance-team kontinuerligt underhåller, så ett bedömningsfönster blir en fråga om att exportera det som redan finns snarare än att sammanställa det under deadline.

• Viktiga ceremonimanuskript och ifyllda vittnesbevis för varje ZMK och KEK som för närvarande används.
• Undertecknade avtal om viktiga förvaltare som namnger varje individ och deras specifika ansvarsområden.
• Ett nyckelregister som listar algoritm, längd, syfte, ägare och rotationsdatum för varje nyckel.
• Dubbel kontroll och delade kunskapsloggar som täcker händelser för nyckelgenerering, inläsning och förstörelse.
• PCI PTS-enhetsvalideringscertifikat för varje HSM inom omfattningen.
• Åtkomstkontroll och ändringsloggar för HSM-administration, som visar vem som rörde vad och när.
• TR-31- eller TR-34-konfigurationsposter som visar hur nycklar utbyttes, inte bara att de gjorde det.
• Certifikat för förstöring av nyckelkomponenter för alla uttjänta nycklar.
• Resultat från HA-redundanstest och DR-återställningstestresultat, daterade mot den testkadens som beskrivs ovan.

Operativ uppgift, frekvens, ägare och framtagen bevis

Tabellen nedan kartlägger de återkommande operativa uppgifterna i den här guiden utifrån vem som äger dem, hur ofta de körs och vilka bevis de lämnar efter sig för nästa PCI PIN-bedömning.

Operativ uppgift	Frekvens	Ägare	Bevis framlagda
Omintyg för nyckelförvaltare	Årligen, eller vid rollbyte	Kryptoansvarig / informationssäkerhetsansvarig	Undertecknat förvaltaravtal
Granskning av administrativ åtkomst till HSM	Kvartals	HSM-administratör	Åtkomstkontroll och ändringslogg
Avstämning av viktig lager	En gång i månaden	Compliance-/revisionsansvarig	Nyckelregister för inventering
ZMK/KEK-rotationsceremoni	Per kontrakt eller nätverkspolicy, vanligtvis 1 till 2 år	Nyckelförvaltare plus oberoende vittne	Ceremonilogg och vittnesbevis
TR-31 rutinmässig nyckelutbyte	Schemalagd, per rotationspolicy	HSM-administratör	TR-31 konfiguration och utbytespost
TR-34 fjärrnyckelladdning	Vid onboarding av ny enhet eller motpart	Nyckelförvaltare plus HSM-administratör	TR-34 konfigurationspost och enhetscertifikat
HA-failover-test	Kvartals	HSM-administratör	Resultat från redundanstest med återställningstid
Test av återställning av DR-nyckel	Årligen	Kryptoansvarig plus nyckelförvaltare	Resultat av DR-restaureringstest
Checklista för PCI PIN-kontroller	Kontinuerligt, formellt före varje bedömning	Compliance-/revisionsansvarig	Färdigställd checklista mappad till bevis

Begränsningar

Denna guide täcker det operativa ramverket för hantering av symmetriska betalningsnycklar vad gäller hantering av PIN- och transaktionsnycklar under en betalnings-HSM. Den ersätter inte en formell PCI PIN-bedömning av en kvalificerad QSA, och den går inte djupt in på den underliggande kryptografin för TR-31-, TR-34- och DUKPT-nyckelderivering; för detta, se vårt kompletterande inlägg om symmetriska kryptografiutmaningar. Den täcker inte heller EMV-chip- och kontaktlös nyckelderivering (ICC-masternycklar och nyckelderivering per session definierade i EMV Book 2), vilket är en relaterad men separat disciplin från ZMK- och KEK-hierarkin som beskrivs här. Rotationskadenser och granskningsfrekvenser i tabellerna ovan är typiska, inte universella; bekräfta de faktiska kryptoperioderna och testkadenserna som din inlösare, processor, kortnätverksavtal eller interna policy kräver. Och eftersom ANSI X9.143-2021 gradvis ersätter TR-31 för nya implementeringar, bekräfta nuvarande leverantörs- och nätverksstöd innan du standardiserar något av nyckelblocksformaten.

Vad skulle krypteringskonsulter rekommendera?

Börja med rollerna, styrningskadensen och mallen för nyckelceremonin innan någon hårdvara kasseras. Att eftermontera förvaringskontroller och en granskningskalender efter att en PCI-bedömning upptäcker en lucka kostar mycket mer, både i tid och i granskningsresultat, än att designa dem in från den första nyckeln.

För team som etablerar eller moderniserar en HSM-betaltjänst utan att äga och driva hårdvaran direkt, tillhandahåller vår HSM-as-a-Service- plattform validerad, högtillgänglig HSM-kapacitet med de nyckelhanteringskontroller som beskrivs i den här guiden redan inbyggda. För banker och betalningsleverantörer som behöver praktisk driftsättning, nyckelceremonikörning och förberedelse av PCI PIN-bedömning, driver vårt HSM- och HSM- tjänstteam för betalningar som arbetar direkt tillsammans med era ingenjörer. Och för institutioner som utvärderar sin bredare kryptografiska nyckelhanteringsposition utöver betalningar, inklusive styrningskadens och revisionsberedskapspraxis som behandlas här, bedömer våra krypteringsrådgivningstjänster , inklusive efterlevnadsrådgivning, ert program mot PCI DSS, PCI PIN och er egen interna policy.

Det här inlägget är en del av vårt kluster för betalnings-HSM. För det bredare affärsargumentet för betalnings-HSM:er, se 5 viktiga fördelar med säkerhetsmodulen för betalningshårdvara . För grunderna i symmetrisk kryptografi och den djupgående tekniska djupdykningen i TR-31, TR-34 och DUKPT under denna nyckelhierarki, se Vilka är utmaningarna med symmetrisk kryptografi?

Slutsats

Praktisk nyckelhantering inom banksektorn handlar inte om ett enskilt produktbeslut. Det är en betalningsnyckelhierarki som upprätthålls av en validerad HSM, namngivna roller som granskas i en styrningskadens, en nyckelutbytesmetod som matchas med huruvida en delad hemlighet redan finns, en PCI PIN-kontrolluppsättning som antar att ingen enskild person kan anförtros en hel nyckel, en HA- och DR-arkitektur som tar nyckelhållbarhet lika seriöst som drifttid och testar båda enligt ett fast schema, och en revisionslogg som bevisar att allt hände som policyn sa att det skulle. Få rollerna, hierarkin och ceremonin rätt först. Efterlevnadsbevisen följer naturligt från en operativ process som var sund från början, snarare än att den sammanställdes i efterhand för att tillfredsställa en bedömare.

Vanliga frågor om partihandel med mat och dryck

Vad är skillnaden mellan en zonhuvudnyckel och en arbetsnyckel?
En zonmasternyckel skyddar de krypteringsnycklar som utväxlas mellan två institutioner via en delad anslutning, medan en arbetsnyckel är den nyckel på lägre nivå som faktiskt krypterar transaktionsdata i realtid, såsom en PIN-kod eller en MAC-kod. ZMK:n berör aldrig transaktionsdata direkt; den finns bara för att skydda de nycklar som gör det.

Behöver jag TR-31 eller TR-34 för min HSM-distribution för betalningar?
Använd TR-34 när du behöver upprätta en första delad nyckel med en part som du inte har någon tidigare nyckelrelation med, till exempel när du laddar nycklar till en ny enhet på distans. Använd TR-31 för varje rutinmässigt nyckelutbyte efter att den initiala relationen har existerat, eftersom det är snabbare och inte kräver certifikatbaserade asymmetriska operationer för varje utbyte.

Hur ofta bör bankkrypteringsnycklar roteras enligt PCI PIN-säkerhetskraven?
PCI PIN-säkerhetskraven anger inte ett universellt intervall för varje nyckeltyp; istället kräver de en dokumenterad krypteringsperiod som är lämplig för nyckelns roll, vanligtvis ett till två år för Zone Master Keys och Key Encryption Keys, och rotation per transaktion för DUKPT-härledda arbetsnycklar. Din specifika kadens bör dokumenteras i policyn och bekräftas mot ditt inlösare- eller nätverksavtal.

Vad är DUKPT och när använder banker det istället för en hierarki med delade nyckelringar?
DUKPT, Derived Unique Key Per Transaction, definierad i ANSI X9.24-3 för AES, härleder en unik nyckel för varje enskild transaktion från en enhetsspecifik initial PIN-krypteringsnyckel, så att inga två transaktioner någonsin använder samma nyckel. Banker använder den vid interaktionspunkten, såsom POS-terminaler och obevakade betalningsenheter, där det skulle vara opraktiskt att synkronisera en delad sessionsnyckel efter varje transaktion.

Vad bör en banks compliance-team granska vid varje intern nyckelhanteringsrevision?
Stäm av nyckelregistret mot faktiska HSM-innehavda nycklar, bekräfta att alla nyckelförvaltaravtal är aktuella och matchar individerna med aktiv åtkomst, granska resultat från HA-redundans och DR-återställningstester mot deras erforderliga kadens och verifiera att varje ceremoni som genomförts sedan den senaste granskningen har en komplett, bevittnad loggfil.

Referensprojekt

• PCI:s säkerhetsstandardråd, PIN-säkerhetsstandardoch "Nyligen släppt: Version 3.1 av PCI PIN-säkerhetsstandarden" (gäller 12 mars 2021)
• PCI:s säkerhetsstandardråd, Referensdokument för säkerhetskrav för PCI-PIN
• FFIEC IT-examenshandbok InfoBase, Broschyr om informationssäkerhet, kontroller för hantering av kryptografiska nycklar
• NIST, SP 800-57 Del 1 Revision 5, Rekommendation för nyckelhantering: Allmänt
• ANSI, ASC X9 TR 31-2018, specifikation för interoperabel säker nyckelutbyte av nyckelblock
• ANSI, ASC X9 TR 34-2019, Interoperabel metod för distribution av symmetriska nycklar med hjälp av asymmetriska tekniker
• ANSI, ANSI X9.143-2021, Finansiella tjänster för detaljhandeln, specifikation för interoperabla säkra nyckelblock
• Ackrediterad standardkommitté X9, ANSI X9.24-1-2017, Symmetrisk nyckelhantering för finansiella tjänster inom detaljhandeln och ANSI X9.24-3-2017, DUKPT för AES