Härledd unik nyckel per transaktion

Inom kryptografi är DUKPT ( Derived Unique Key Per Transaction) ett nyckelhanteringsschema där för varje transaktion används en unik nyckel som härrör från en fast nyckel. Därför, om en härledd nyckel äventyras, är framtida och tidigare transaktionsdata fortfarande skyddade eftersom nästa eller föregående nycklar inte enkelt kan fastställas. DUKPT specificeras i ANSI X9.24 del 1.

Översikt

DUKPT tillåter att behandlingen av krypteringen flyttas bort från enheterna som har den delade hemligheten. Krypteringen görs med en härledd nyckel, som inte återanvänds efter transaktionen. DUKPT används för att kryptera elektroniska handelstransaktioner. Även om det kan användas för att skydda information mellan två företag eller banker, används det vanligtvis för att kryptera PIN-information som förvärvats av Point-Of-Sale (POS)-enheter.

DUKPT är inte i sig en krypteringsstandard; snarare är det en nyckelhanteringsteknik. Funktionerna i DUKPT-schemat är:

• möjliggöra för både ursprungs- och mottagande parter att vara överens om nyckeln som används för en given transaktion,
• varje transaktion kommer att ha en distinkt nyckel från alla andra transaktioner, utom av en slump,
• om en nuvarande härledd nyckel äventyras, förblir tidigare och framtida nycklar (och därmed transaktionsdata krypterad under dem) okompromisslösa,
• varje enhet genererar en annan nyckelsekvens,
• upphovsmän och mottagare av krypterade meddelanden behöver inte utföra ett interaktivt nyckelavtalsprotokoll i förväg.

Historia

DUKPT uppfanns i slutet av 1980-talet på Visa men fick inte mycket acceptans förrän på 1990-talet, när branschpraxis skiftade mot att rekommendera, och senare kräva, att varje enhet har en distinkt krypteringsnyckel.

Innan DUKPT var den senaste tekniken känd som Master/Session , vilket krävde att varje PIN-krypterande enhet initierades med en unik huvudnyckel. Vid hantering av transaktioner som härrörde från enheter som använder huvud-/sessionsnyckelhantering var en oönskad bieffekt behovet av en tabell med lika många krypteringsnycklar som enheterna som distribuerades. Hos en stor köpman kan bordet bli ganska stort. DUKPT löste detta. I DUKPT är varje enhet fortfarande initierad med en distinkt nyckel, men alla initieringsnycklar för en hel familj av enheter härleds från en enda nyckel, basavledningsnyckeln (BDK). För att dekryptera krypterade meddelanden från enheter i fält behöver mottagaren bara lagra BDK.

Nycklar

Som nämnts ovan behöver algoritmen en initial enkel nyckel som i den ursprungliga beskrivningen av algoritmen kallades den superhemliga nyckeln , men som senare döptes om till - på ett mer officiellt klingande sätt - Base Derivation Key ( eller BDK). Det ursprungliga namnet förmedlar kanske bättre den sanna naturen hos denna nyckel, för om den äventyras kommer alla enheter och alla transaktioner att äventyras.

Detta mildras av det faktum att det bara finns två parter som känner till BDK:

• mottagaren av de krypterade meddelandena (vanligtvis en köpman)
• den part som initierar krypteringsenheterna (vanligtvis tillverkaren av enheten).

BDK förvaras vanligtvis inuti en manipuleringssäker säkerhetsmodul (TRSM) eller hårdvarusäkerhetsmodul (HSM). Det måste förbli klart att denna nyckel inte är den som används för att initiera krypteringsenheten som kommer att delta i DUKPT-operationer. Se nedan för den faktiska processen för generering av krypteringsnyckel.

• Först : En nyckel härledd från BDK, denna kallas IPEK (Initial PIN Encryption Key)
• För det andra : IPEK:n injiceras sedan i enheterna, så varje kompromiss av den nyckeln äventyrar bara enheten, inte BDK. Detta skapar ytterligare en uppsättning nycklar (inuti enheten) irreversibelt härledda från den (nominellt kallad Future Keys )
• Fjärde : Efteråt kasseras IPEK omedelbart. OBS: Detta steg motsäger avsnittet "Sessionsnycklar" där det indikerar att endast 21 "Framtidsnycklar" genereras. IPEK måste behållas av terminalen för att generera nästa batch av 21 Future Keys. OBS: Detta är inte sant, de framtida nycklarna används för att härleda nya framtida nycklar, IPEK kasseras faktiskt.
• För det femte : Future Keys används för att kryptera transaktioner i DUKPT-processen.

Vid upptäckt av kompromiss erhåller enheten själv en ny nyckel via processen för generering av härledd nyckel.

Kommunikation

Ursprungs

I ursprungsänden (krypterande) fungerar systemet enligt följande:

1. En transaktion initieras som innebär att data ska krypteras. Typfallet är en kunds PIN-kod.
2. En nyckel hämtas från uppsättningen "Framtidsnycklar"
3. Detta används för att kryptera meddelandet och skapa ett kryptogram .
4. En identifierare känd som "Key Serial Number" (KSN) returneras från krypteringsenheten tillsammans med kryptogrammet. KSN bildas av enhetens unika identifierare och en intern transaktionsräknare.
5. (Kryptogram, KSN)-paret vidarebefordras till den avsedda mottagaren, vanligtvis köpmannen, där det dekrypteras och bearbetas vidare.
6. Internt gör enheten följande:
   1. Ökar transaktionsantalet (med en intern räknare)
   2. Ogiltigförklarar den nyss använda nyckeln, och
   3. Om nödvändigt genererar fler framtida nycklar

Tar emot

På den mottagande (dekrypterande) sidan fungerar systemet enligt följande:

1. (Kryptogram, KSN) paret tas emot.
2. Lämplig BDK (om systemet har fler än en) finns.
3. Det mottagande systemet regenererar först IPEK och går sedan igenom en process som liknar den som används på ursprungssystemet för att komma fram till samma krypteringsnyckel som användes (sessionsnyckeln). Key Serial Number (KSN) ger den information som behövs för att göra detta.
4. Kryptogrammet dekrypteras med sessionsnyckel.
5. Eventuell ytterligare bearbetning görs. För handlare betyder detta vanligtvis kryptering med en annan nyckel för att vidarebefordra till en switch (att göra en "översättning"), men för vissa slutna kretsar kan det innebära att data behandlas direkt, som att verifiera PIN-koden.

Sessionsnycklar

Metoden för att komma fram till sessionsnycklar är något annorlunda på ursprungssidan som på den mottagande sidan. På ursprungssidan finns det avsevärd tillståndsinformation kvar mellan transaktioner, inklusive en transaktionsräknare, ett serienummer och en array med upp till 21 "Framtidsnycklar". På den mottagande sidan finns ingen statlig information bevarad; endast BDK är beständig över bearbetningsoperationer. Detta arrangemang ger bekvämlighet för mottagaren (ett stort antal enheter kan servas medan endast en nyckel lagras). Det ger också en viss extra säkerhet med avseende på upphovsmannen (PIN-infångningsenheter används ofta i miljöer som är avskyvärda för säkerheten; säkerhetsparametrarna i enheterna är "avlägsen" från den känsliga BDK, och om enheten äventyras är det inte andra enheter. implicit äventyras).

Registrerar användning

Säkerhetskopieringsregister

Följande lagringsområden relaterade till nyckelhantering bibehålls från tidpunkten för kommandot "Load Initial Key" under PIN-inmatningsenhetens livstid:

Krypteringsräknare (21 bitar)

En räknare för antalet PIN-krypteringar som har inträffat sedan PIN-inmatningsenheten först initierades. Vissa räknarvärden hoppas över (som förklaras nedan), så att över 1 miljon PIN-krypteringsoperationer är möjliga. Obs! Sammankopplingen (vänster till höger) av det initiala nyckelserienummerregistret och krypteringsräknaren bildar 80-bitars (20 hexadecimala siffror) nyckelserienummerregistret.

Framtida nyckelregister (21 register med vardera 34 hexadecimala siffror)

En uppsättning av 21 register, numrerade #1 till #21, som används för att lagra framtida PIN-krypteringsnycklar. Varje register inkluderar en 2 hexadecimal siffrig longitudinell redundanskontroll (LRC) eller en 2 hexadecimal siffrig cyklisk redundanskontroll (CRC).

Tillfälliga register

Följande lagringsområden relaterade till nyckelhantering krävs på tillfällig basis och kan användas för andra ändamål av andra PIN-bearbetningsrutiner:

Aktuell nyckelpekare (ungefär 4 hexadecimala siffror)

Innehåller adressen till det framtida nyckelregister vars innehåll används i den aktuella kryptografiska operationen. Den identifierar innehållet i det framtida nyckelregister vars adress finns i den aktuella nyckelpekaren.

Skiftregister (21 bitar)

Ett 21-bitars register, vars bitar är numrerade från vänster till höger som #1 till #21. Detta register innehåller normalt 20 "noll" bitar och en enda "en" bit. En användning av detta register är att välja ett av de framtida nyckelregistren. Det framtida nyckelregistret som ska väljas är det som är identiskt numrerat med biten i skiftregistret som innehåller den enda "ettan".

Kryptoregister-1 (16 hexadecimala siffror)

Ett register som används för att utföra kryptografiska operationer.

Kryptoregister-2 (16 hexadecimala siffror)

Ett andra register som används för att utföra kryptografiska operationer.

Nyckelregister (32 hexadecimala siffror)

Ett register som används för att hålla en kryptografisk nyckel.

Praktiska frågor (KSN-schema)

I praktiska tillämpningar skulle man ha flera BDK registrerade, möjligen för olika kunder, eller för att begränsa omfattningen av nyckelkompromisser. Vid bearbetning av transaktioner är det viktigt för mottagaren att veta vilken BDK som användes för att initialisera den ursprungliga enheten. För att uppnå detta är 80-bitars KSN strukturerad i tre delar: som nyckeluppsättnings-ID, ett TRSM-ID och transaktionsräknaren. Algoritmen specificerar att transaktionsräknaren är 21-bitar, men behandlar de återstående 59 bitarna ogenomskinligt (algoritmen specificerar bara att oanvända bitar ska 0-utfyllas till en nibble-gräns och sedan 'f' utfyllas till 80-bitarsgränsen). På grund av detta är den enhet som hanterar skapandet av DUKPT-enheterna (vanligtvis en köpman) fri att dela upp de 59 bitarna enligt deras preferenser.

Branschpraxis är att beteckna partitioneringen som en serie av tre siffror, som anger antalet hexadecimala siffror som används i varje del: Key Set ID, TRSM ID och transaktionsräknaren. Ett vanligt val är '6-5-5', vilket betyder att de första 6 hexadecimala siffrorna i KSN indikerar Key Set ID (dvs vilken BDK som ska användas), de nästa 5 är TRSM ID (dvs en enhetsserie nummer inom intervallet som initieras via en gemensam BDK), och de sista 5 är transaktionsräknaren.

Detta notationsschema är inte strikt korrekt, eftersom transaktionsräknaren är 21 bitar, vilket inte är en jämn multipel av 4 (antalet bitar i en hexadecimal siffra). Följaktligen förbrukar transaktionsräknaren faktiskt en bit av fältet som är TRSM ID (i detta exempel betyder det att TRSM ID-fältet kan rymma 2 ( ^5*4-1) enheter, istället för 2 ^(5*4) , eller cirka en halv miljon).

Det är också vanligt i branschen att endast använda 64-bitar av KSN (troligen av skäl som är relevanta för äldre system och DES-kryptering), vilket skulle innebära att hela KSN är vadderat till vänster med fyra "f" hexadecimaler siffror. De återstående 4 hexade siffrorna (16-bitar) är ändå tillgängliga för system som kan ta emot dem.

6-5-5-schemat som nämns ovan skulle tillåta cirka 16 miljoner BDK, 500 000 enheter per BDK och 1 miljon transaktioner per enhet.