Betalnings-HSM:er: Framtiden för betalningssäkerhet

Att behålla kunddata är oerhört viktigt för att skapa en känsla av säkerhet hos dina kunder och för att säkerställa att inga illvilliga aktörer kan missbruka deras information. Detta är ännu viktigare inom betalningsbranschen. Institutioner som banker, bankomattjänster och andra organisationer som hanterar kundbetalningsdata måste säkerställa att dessa kundbetalningsdata förvaras säkert och skyddat, särskilt om dessa data lagras i deras databaser. Betalnings-HSM:er (Hardware Security Modules) är certifierade hårdvaruenheter som genererar, lagrar och tillämpar kryptografiska nycklar exklusivt inom en manipulationssäker gräns, och förvarar PIN-block, kortverifieringsvärden och nyckelutbytesmaterial inuti hårdvara där ingen programvaruprocess kan extrahera dem i klartext. Den rekommenderade åtgärden för alla betalningsleverantörer, inlösande banker eller kortnätverk är att driftsätta PCI PTS HSM-certifierad hårdvara och implementera TR-31-nyckelblock för all symmetrisk nyckelutbyte, som uppfyller PCI PIN-säkerhetskraven före nästa bedömningscykel.

Snabbt svar: Vad är en betalnings-HSM och varför krävs den?

En betalnings-HSM är en FIPS 140-2- eller 140-3- och PCI PTS HSM-certifierad hårdvaruenhet som utför kryptografiska betalningsoperationer: PIN-översättning, generering av kortverifieringsvärden, nyckelutbyte med TR-31 och TR-34 och ATM-nyckelinjektion. Den skiljer sig från en generell HSM genom att varje nyckel inuti den skrivs in och är bunden till en specifik operation, vilket förhindrar missbruk mellan funktioner. Betalnings-HSM:er krävs enligt PCI PIN-säkerhetskrav och är baslinjekontrollen för alla organisationer som bearbetar PIN-baserade transaktioner. För den specifika roll som betalnings-HSM:er spelar för att förhindra dataintrång, se Betalnings-HSM:ers roll i att förhindra dataintrång . För HSM-hosting utan lokal hårdvara, se HSM-as-a-Service.

Attacker fokuserade på betalningsområdet

Många olika standarder och regler finns inom betalningsbranschen, specifikt för att säkerställa att organisationer inom denna bransch följer korrekta rutiner för att skydda kunddata. Standarder som PCI-DSS (Payment Card Industry Data Security Standard) , SOX (Sarbanes-Oxley Act) och GDPR (General Data Protection Regulation) , tillsammans med NIST:s (National Institute of Standards and Technology) standarder, finns för att skydda kunders betalningsdata och annan känslig kunddata.

Det finns ett antal olika typer av attacker som riktar sig mot betalningsområdet. På grund av detta har cybersäkerhetsexperter och tillsynsmyndigheter utformat många olika metoder för att motverka dessa attacker.

• Man i mitten attackerar

  "Man in the Middle"-attacker är vanliga i alla branscher. Dessa attacker stoppas med rätt skydd på plats. Sättet en "Man in the Middle"-attack sker på är precis som namnet antyder: när källan till en fil skickar data till sin destination, fångar hotbildsaktören upp informationen under överföring och stjäl den innan den kan nå destinationen. Om data krypteras innan den skickas under överföring kan en "Man in the Middle"-attack inträffa, men angriparen kommer inte att kunna läsa eller använda informationen om de inte också stjäl krypteringsnyckeln.

• Stulna inloggningsuppgifter / nätfiskeattacker

  Nätfiskeattacker innebär att förfalskade e-postmeddelanden skickas med länkar till vad som verkar vara en betrodd webbplats. När en användare anger inloggningsuppgifter samlas dessa inloggningsuppgifter in av angriparen och används för att komma åt offrets konto. Det är därför användarutbildning och flerfaktorsautentisering är viktiga komplement till HSM-baserade kryptografiska kontroller.

• Sårbarhetsutnyttjande

  Programvarubaserad lagring av krypteringsnycklar gör nycklarna öppna för sårbarhetsattacker var som helst på en dator. Den enda tillförlitliga åtgärden är att använda en hårdvarusäkerhetsmodul som lagrar nycklar i hårdvara och aldrig exponerar dem för operativsystemet eller applikationslagret, där sårbarheter i någon programvarukomponent skapar en extraktionsväg.

• Brutal tvångsförsök

  Brute forcing-attacker försöker utföra alla kombinationer av lösenord eller nycklar tills ett korrekt värde hittas. För betalnings-HSM:er förhindrar anti-manipulationsmekanismer och hårdvarubaserade gränser för återförsök denna typ av attack mot nycklar som lagras i hårdvara. För användarautentisering till betalningsportaler är kontoutlåsning efter ett litet antal misslyckade försök standardåtgärden.

Vad är HSM:er?

Hårdvarusäkerhetsmoduler, eller HSM, är enheter som lagrar kryptografiska nycklar och utför kryptografiska operationer inom en manipulationssäker, certifierad gräns. Kryptering är en process där känslig data omvandlas till chiffertext med hjälp av en krypteringsnyckel så att endast behöriga parter som innehar motsvarande nyckel kan återställa klartexten. Med hjälp av krypteringsnycklar kan kunddata skickas genom en krypteringsalgoritm som sedan döljer informationen genom att ändra den till chiffertext som endast nyckelinnehavaren kan återställa.

Det finns två olika typer av kryptering: symmetrisk och asymmetrisk kryptering . Symmetrisk kryptering använder en enda delad nyckel för både kryptering och dekryptering och används för skydd av bulkdata och inom betalningsnyckelhierarkier för arbetsnycklar. Asymmetrisk kryptering använder ett matematiskt länkat nyckelpar: en offentlig nyckel, tillgänglig för alla parter, och en privat nyckel, som hålls hemlig av ägaren. Den offentliga nyckeln krypterar eller verifierar, och den privata nyckeln dekrypterar eller signerar. Betalnings-HSM:er stöder båda typerna och använder dem för olika delar av betalningsarbetsflödet.

Själva HSM-enheten nollställer när den upptäcker manipulering eller obehörig rörelse. Nollställning innebär att allt nyckelmaterial raderas från enheten, och behöriga användare måste återställa dessa nycklar från en säkerhetskopia av HSM eller säkerhetskopior av nyckelkomponenter. Denna manipuleringsmekanismen är det som gör stöld av fysiska nycklar från en HSM operativt omöjlig.

Betalningsnyckelhierarkin

Betalningsnyckelhierarkin definierar det strukturerade förhållandet mellan kryptografiska nycklar som skyddar varje steg i en betalningstransaktion. Att förstå denna hierarki är viktigt eftersom varje lager avgör vilka nycklar som kan dekryptera vilka data och vilka operationer dessa nycklar är behöriga att utföra.

Nyckeltyp	Förkortning	Plats	Syfte
Lokal huvudnyckel	LMK	Endast inuti HSM; exporteras aldrig i klartext	Nyckelkrypteringsnyckel för alla andra nycklar i HSM; fastställd vid nyckelceremoni
Zonens huvudnyckel	ZMK	Utväxlas mellan betalningsenheter; krypterad under LMK i vila	Utbyter säkert fungerande nycklar mellan inlösande banker, betalningsprocessorer och kortnätverk
Zonens PIN-kod	ZPK	Krypterad under ZMK under utbyte; dekrypterad under LMK i HSM	Krypterar PIN-block under PIN-översättning mellan betalningsnoder
Kortverifieringsnyckel	CVC	Lagras krypterat under LMK	Genererar och verifierar kortverifieringsvärden (CVV/CVC) under transaktionsauktorisering
Terminalens huvudnyckel	TMK	Laddas in i bankomat eller kassaterminal; krypterad under LMK under injektion	Används på terminalnivå för PIN-kryptering; roteras enligt schema eller vid kompromiss
Meddelandeautentiseringskodnyckel	MAK	Krypterad under LMK	Genererar och verifierar MAC-adresser på transaktionsmeddelanden för att upptäcka manipulering under överföring

TR-31 och TR-34 nyckelutbytesarbetsflöden

TR-31: Interoperabelt säkert nyckelblock

TR-31, publicerad av ASC X9, definierar ett format för att omsluta en symmetrisk nyckel tillsammans med dess användningsattribut inuti ett kryptografiskt bundet nyckelblock. Nyckelblocket inkluderar nyckeltyp, algoritm, användningsbegränsningar och nyckelvärdet, allt skyddat tillsammans så att attributen inte kan separeras från nyckelmaterialet. Detta förhindrar nyckelmissbruk: en ZPK som endast ska användas för PIN-översättning kan inte extraheras och tillämpas på en MAC-operation, eftersom dess användningsattribut är kryptografiskt bundna.

PCI PIN-säkerhetskraven kräver TR-31 för allt symmetriskt nyckelutbyte mellan betalningsenheter. Alla organisationer som överför ZMK:er eller arbetsnycklar mellan inlösande banker, processorer eller kortnätverk med hjälp av äldre Clear-Key-metoder eller pre-TR-31-metoder uppfyller inte nuvarande PCI PIN-krav. TR-31-nyckelblock måste valideras under PCI PIN-bedömningar.

TR-34: Asymmetrisk nyckeldistribution

TR-34 är en ASC X9-standard för distribution av symmetriska nycklar med hjälp av asymmetrisk kryptografi, vanligtvis RSA eller ECDH. Den används för initiala nyckeletableringsscenarier där två parter inte har något redan existerande delat symmetriskt nyckelmaterial. Nyckeldistributionscentret (KDC) krypterar nyckeln som distribueras under mottagarens publika nyckel, och mottagarens HSM dekrypterar den med motsvarande privata nyckel. Hela operationen sker inom HSM-gränsen i båda ändar, så nyckeln exponeras aldrig i klartext utanför hårdvaran. TR-34 testas under PCI PIN-bedömningar och krävs för kompatibel initial nyckeletablering i förvärvs- och bearbetningsmiljöer.

PCI PIN-säkerhetskontroller och vad revisorer granskar

PCI PIN-säkerhetskrav gäller för alla enheter som hanterar PIN-koder för ett betalkortsnätverk. De definierar kontroller för hårdvarusäkerhet, nyckelhantering, personal och procedurer. Följande kontroller är direkt kopplade till implementeringen av betalnings-HSM:

• HSM-certifiering: HSM:en måste vara certifierad enligt PCI PTS HSM-standarder. Certifieringsstatus och version måste dokumenteras och verifieras.
• Dubbel kontroll och delad kunskap: All nyckelgenerering, laddning och utbyte måste uppfylla kraven för dubbel kontroll (två eller fler behöriga personer krävs) och delad kunskap (ingen enskild individ har tillgång till hela nyckeln).
• TR-31 nyckelblock: Allt symmetriskt nyckelutbyte måste använda kompatibla TR-31-nyckelblock. Äldre metoder för distribution av tydliga nyckelringar är inte kompatibla.
• Begränsning av tangenttypning och användning: Varje nyckel i HSM måste vara skriven och begränsad till sin definierade operation. Allmän nyckelanvändning är inte tillåten i en betalnings-HSM.
• Nyckelförvaring och inventarier: En aktuell inventering av alla nycklar, nyckelförvaltare, nyckelkontrollvärden och nyckelanvändning måste upprätthållas och vara tillgänglig för bedömningsgranskning.
• Fysisk säkerhet: HSM:er måste vara inrymda i en fysiskt säker miljö med åtkomstkontroller, besöksloggning och miljöövervakning.
• Viktigt kompromisssvar: En dokumenterad procedur för nyckelkompromettering måste finnas och testas, som specificerar hur komprometterade nycklar identifieras, återkallas och ersätts.

Betalnings-HSM-nyckelceremoni: Procedur och dokumentation

En HSM-nyckelceremoni för betalning är en kontrollerad procedur för att generera och ladda den lokala huvudnyckeln (LMK) eller zonhuvudnycklarna (ZMK) under dubbel kontroll och delad kunskap. Följande steg beskriver en representativ LMK-genereringsceremoni:

1. Förberedelser inför ceremonin: identifiera viktiga vårdnadshavare (minst två, vanligtvis tre vid en M-of-N-delning); inhämta undertecknad fullmakt från varje vårdnadshavare; förbereda manuskriptet för ceremonin; ordna med ett vittne och en revisor om det krävs enligt policyn.
2. HSM-initialisering: gå in i HSM:s administrativa läge under dubbel kontroll (båda förvaltarna närvarande samtidigt); rensa allt befintligt nyckelmaterial; bekräfta att HSM:s granskningslogg är aktiv.
3. Komponentgenerering: Varje förvaltare genererar sin nyckelkomponent inuti HSM eller på en dedikerad säker enhet; komponenten krypteras till varje förvaltares kort eller nyckeldelningsenhet; ingen förvaltare ser en annans komponent.
4. Komponentkombination: förvaltare presenterar sina komponenter samtidigt; HSM kombinerar komponenterna för att bilda LMK inom hårdvarugränsen; ingen klartext-LMK är någonsin tillgänglig utanför HSM.
5. Verifiering av nyckelkontrollvärde (KCV): HSM matar ut KCV för den kombinerade LMK:n; vårdnadshavare verifierar att KCV:n matchar det förväntade värdet som dokumenterats i ceremonimanuskriptet.
6. Dokumentation: Varje vårdnadshavare signerar ceremoniloggen och bekräftar att deras komponent genererades och laddades korrekt; vittnet och revisorn signerar; loggen bevaras enligt PCI PIN-dokumentationskraven.
7. Lagring av säkerhetskopieringskomponenter: Nyckelkomponenter förvaras i förseglade, manipuleringssäkra kuvert på fysiskt separata, säkra platser; åtkomst till säkerhetskopiorna kräver dubbel kontroll och loggas.

Hög tillgänglighet och katastrofåterställning för betalnings-HSM:er

Betalningshantering är en tidskritisk infrastruktur. HSM-driftstopp leder direkt till misslyckade transaktioner. Konfigurationer för hög tillgänglighet (HA) och katastrofåterställning (DR) för betalnings-HSM:er kräver noggrann planering:

• LMK-synkronisering: Alla HSM:er i ett kluster måste ha en identisk LMK. LMK-replikering mellan HSM:er använder leverantörens säkra replikeringsprocedur och måste utföras under dubbel kontroll med dokumenterade bevis.
• Lastbalansering: En lastbalanserare för hårdvara eller mjukvara distribuerar kryptografiska förfrågningar över tillgängliga HSM-noder. Applikationer ansluter till lastbalanserarens slutpunkt och är omedvetna om vilken fysisk HSM som bearbetar varje förfrågan.
• Geografisk separation: Primära och sekundära HSM-kluster bör finnas i fysiskt separata datacenter, med nätverksanslutning och replikering utformad för att uppfylla återställningstidsmålet (RTO) som definieras i DR-planen.
• Kall standby HSM: En reserv-HSM laddad med samma LMK (via återställning av säkerhetskopia) bör vara tillgänglig för snabb distribution om en primär HSM slutar fungera utanför den klustrade konfigurationen.
• Årlig DR-testning: Proceduren för att återställa HSM-tillstånd från säkerhetskopierade nyckelkomponenter måste dokumenteras och testas årligen. Testresultaten bör behållas som revisionsbevis.

Betalnings- kontra allmänna HSM:er

Betalnings-HSM:er , till skillnad från allmänna HSM:er, krävs i många olika typer av betalningsorganisationer. Banker kommer särskilt att vara skyldiga att använda dessa typer av hårdvarusäkerhetsmoduler, eftersom banker följer strikta riktlinjer och regler i alla länder.

Attribut	Betalning HSM	Allmänt HSM
certifiering	PCI PTS HSM + FIPS 140-2 eller 140-3	FIPS 140-2 eller 140-3 (ingen PCI PTS HSM-certifiering)
Tangentskrivning	Varje nyckel är bunden till en specifik betalningsoperation; användningsbegränsningar tillämpas i hårdvara	Nycklar har flera funktioner; användningsbegränsningar tillämpas av programpolicyn
Exponerade operationer	Betalningsoperationer på hög nivå: PIN-översättning, CVV/CVC, TR-31-nyckelblockering, nyckelinjektion	Lågnivåprimitiver: kryptera, dekryptera, signera, verifiera, härleda
Dubbel kontrolltillämpning	Hårdvaruförstärkt för nyckelgenerering och inläsning	Policybaserad; beror på applikations- och arbetsflödesdesign
Hantering av PIN-blockering	Inbyggt stöd för ISO 9564 PIN-blockformat	Kräver anpassad applikationskod för att hantera PIN-blockformat
Regelmässig anpassning	Krävs för PCI PIN-efterlevnad; uppfyller betalningsnätverkets HSM-krav	Lämplig för PKI, kodsignering, TLS och allmän kryptering; inte tillräcklig för PCI PIN PIN-hanteringsfunktioner

Integrationssteg: Implementera en betalnings-HSM

1. Bekräfta HSM-certifiering: Kontrollera att HSM:en har ett giltigt PCI PTS HSM-godkännande och ett FIPS 140-2- eller 140-3-valideringscertifikat. Bekräfta att den inbyggda programvarans version i produktion matchar den validerade konfigurationen.
2. Utforma nyckelhierarkin: definiera vilka nyckeltyper som behövs för transaktionsflödena inom scopet (ZMK, ZPK, CVK, TMK, MAK); dokumentera nyckeltyper, algoritmer och användningsbegränsningar innan några nycklar genereras.
3. Utför LMK-nyckelceremonin: generera och ladda LMK:n under dubbel kontroll och delad kunskap enligt ceremoniproceduren ovan; dokumentera och behålla alla ceremonijournaler.
4. Konfigurera TR-31 och TR-34: distribuera stöd för TR-31-nyckelblock för allt symmetriskt nyckelutbyte med motparter; konfigurera TR-34 för initial nyckeletablering med nyckeldistributionscentraler; testa end-to-end-nyckelutbyte innan anslutning till produktionstrafik.
5. Integrera applikationen: ansluta betalningsprogramservrar till HSM API:et (vanligtvis PKCS#11 eller ett leverantörsspecifikt värd-API); konfigurera programmet för att dirigera PIN-översättning, CVV-operationer och nyckelutbyte genom HSM; testa alla transaktionsflöden i en mellanlagringsmiljö.
6. Konfigurera HA och DR: replikera LMK till det sekundära HSM-klustret under dubbel kontroll; konfigurera lastbalansering; dokumentera och testa DR-proceduren.
7. Dokumentrevisionsbevis: producera och behålla viktiga ceremoniregister, HSM-konfigurationsregister, TR-31-implementeringsregister, loggar för dubbla kontrollåtgärder och register över fysiska säkerhetsuppgifter för PCI PIN- och PCI DSS-bedömningsberedskap.

Andra metoder för att skydda betalningssystem

Hårdvarusäkerhetsmoduler är inte det enda sättet att försvara betalningssystem. Flera kompletterande kontroller krävs för ett omfattande skydd av betalningsdata:

• tokenization

  Tokenisering ersätter känsliga betalningsdata med en icke-känslig token som inte har någon matematisk relation till det ursprungliga värdet. Vid valvlös tokenisering är processen oåterkallelig utan tokeniseringssystemet; vid valvbaserad tokenisering kan det ursprungliga värdet återställas via valvet. Betalningsbranschen använder tokenisering för kort-på-filen och återkommande betalningsscenarier eftersom en token inte kan användas för bedrägliga transaktioner hos handlare som inte har tillgång till avtokeniseringstjänsten. Relaterat: Vad är tokenisering?

• hashing

  Hashning producerar en sammanfattning av indata med fast längd som inte kan återställas. Den används för att verifiera dataintegritet och för att lagra lösenordsverifierare. Hashning ensam är inte tillräckligt för att skydda betalningsdata eftersom den inte ger konfidentialitet, utan endast integritetsverifiering.

• Fysisk säkerhet

  Servrar och datorer som lagrar kunders betalningsdata måste vara placerade i fysiskt säkrade miljöer med åtkomstkontroller, besöksloggning, miljöövervakning och manipuleringssäkra förseglingar på kritisk hårdvara. Fysiska säkerhetskrav för betalnings-HSM:er utvärderas under PCI PIN- och PCI DSS-bedömningar.

Slutsats

Att skydda data i varje steg, särskilt inom betalningsbranschen, är avgörande för säkerheten för kunddata. Betalnings-HSM:er är den certifierade hårdvarukontrollen i centrum för PCI PIN-efterlevnad, och tillhandahåller den manipulationssäkra miljön, nyckeltypning, dubbel kontrolltillämpning och TR-31/TR-34-nyckelutbyteskapacitet som betalningsregler kräver. För organisationer som utvärderar implementering av betalnings-HSM, värdbaserade alternativ eller rådgivande support för PCI PIN-bedömningar, tillhandahåller Encryption Consulting HSM-as-a-Service och krypteringsrådgivningstjänster som täcker HSM-design, nyckelceremonikörning och efterlevnadsberedskap. För den roll som betalnings-HSM:er spelar specifikt för att förhindra dataintrång, se Rollen av säkerhetsmoduler för betalningshårdvara för att förhindra dataintrång . För PKI-implementeringar som kompletterar implementeringar av betalnings-HSM, se PKI-as-a-Service.

Vanliga frågor om partihandel med mat och dryck

Vad är en betalnings-HSM och hur skiljer den sig från en generell HSM?

En betalnings-HSM är en manipulationssäker apparat som är certifierad enligt PCI PTS HSM och FIPS 140-2 eller 140-3-standarder och som utför betalningsoperationer på hög nivå, såsom PIN-blockkryptering, PIN-översättning, generering av kortverifieringsvärden och TR-31/TR-34-nyckelutbyte. Till skillnad från en generell HSM, som exponerar lågnivåkryptografiska primitiver, buntar en betalnings-HSM dessa primitiver i betalningsoperationer som körs helt inom hårdvarugränsen med nycklar som skrivits och bundna till specifika operationer.

Vad är betalningsnycklarnas hierarki och varför är det viktigt?

Betalningsnyckelhierarkin är det strukturerade förhållandet mellan kryptografiska nycklar som skyddar betalningstransaktioner: den lokala huvudnyckeln (LMK) högst upp, zonhuvudnycklar (ZMK) för nyckelutbyte mellan betalningsenheter och arbetsnycklar (ZPK för PIN-översättning, CVK för kortverifiering, TMK för terminalinjektion, MAK för meddelandeautentisering) på operativ nivå. Varje nivå är krypterad under nivån ovanför, vilket definierar attackytan för eventuella kompromisshändelser.

Vad är TR-31 och TR-34 och när krävs de?

TR-31 är en ASC X9-standard som omsluter en symmetrisk nyckel med dess användningsattribut i ett kryptografiskt bundet nyckelblock, vilket förhindrar nyckelmissbruk genom att göra användningsattribut oskiljbara från nyckelmaterialet. TR-34 är en ASC X9-standard för att distribuera symmetriska nycklar med asymmetrisk kryptografi där ingen tidigare delad nyckel finns. PCI PIN-säkerhetskrav kräver TR-31 för allt symmetriskt nyckelutbyte och TR-34 för initial nyckelupprättande.

Vad innebär en HSM-nyckelceremoni med betalning?

En nyckelceremoni för en betalnings-HSM är en kontrollerad, dokumenterad procedur för att generera och ladda den lokala huvudnyckeln (LMK) under dubbel kontroll och delad kunskap. Flera förvaltare genererar varsin nyckelkomponent, HSM kombinerar komponenterna inom sina gränser så att ingen enskild förvaltare någonsin innehar hela nyckeln, och förvaltarna verifierar nyckelkontrollvärdet mot den förväntade referensen. Ceremonin dokumenteras med förvaltarens signaturer och sparas för granskning av PCI PIN-koden.

Vilka revisionsbevis behöver en implementering av HSM för betalningar producera?

Nödvändiga revisionsbevis inkluderar: manuskript för viktiga ceremonier och register över slutförande med förvaltarens underskrifter; HSM-certifieringsregister (PCI PTS HSM och FIPS 140-2 eller 140-3); TR-31-implementeringsregister; TR-34-nyckelutbytesregister; dokumentation och utbildningsregister för policyer med dubbel kontroll och delad kunskap; viktiga inventeringsregister; export av HSM-revisionsloggar; och fysiska säkerhetsregister.

Hur bör betalnings-HSM:er konfigureras för hög tillgänglighet och katastrofåterställning?

Betalnings-HSM:er bör distribueras i en klustrad konfiguration över fysiskt separata rack eller datacenter med en identisk LMK över alla noder, laddas via samma nyckelceremoni eller replikeras säkert med leverantörens procedur. Applikationer ansluter via en lastbalanserare som dirigerar förfrågningar till tillgängliga HSM-noder. En kall standby-HSM och en dokumenterad DR-procedur som testas årligen kompletterar HA/DR-positionen.