Intill helt nyligen var det lika enkelt att läsa kreditkortsdata som att dra kortet genom en läsare (t.ex. en av de många läsare som tillverkas av ID TECH) och låta en virtuell terminalapp (eller andra appar) ta upp spårdata som kommer direkt från läsaren. Uppgifterna i fråga skulle helt enkelt visas som tangenttryckningar på en skärm, okrypterade.

Det var på den tiden!

Det räcker med att säga att saker och ting har förändrats. I dag ger magnetremsläsare i allmänhet ut krypterade data via USB (ofta i HID-läge snarare än tangentbordsläge), och de flesta kortläsare måste i dag hantera chipkort utöver magnetremsor. Chipkortsdata har formen av TLV:er (tags, length, values) och kan se ganska annorlunda ut än ”vanlig gammal magstripe-data” från förr i tiden. Dessutom är de alltid krypterade.

I de senaste inläggen visade jag hur man dekrypterar kreditkortsdata med hjälp av industristandardiserade TDES- och AES-dekrypteringsalgoritmer i kombination med industristandardiserade (ANSI X9.24) DUKPT-nyckelavledningstekniker, men vi har inte talat om hur man får tag på avkodade magstripe-data i första hand. Hur ser ”magstripe-data för kreditkort” ut nu? Hur kan man få tag på dem och avkoda dem? Hur vet man vilka delar som är krypterade?

Svaret på den första frågan (hur ser magstripe-data ut?) varierar mycket, inte bara beroende på vilket märke och vilken modell av kortläsningsutrustningen du använder, utan också beroende på om transaktionen i fråga gjordes via mag swipe, dip (kontakt EMV) eller kontaktlös/NFC-interaktion. I allmänhet gör du mycket mer än att bara läsa råa spårdata. Du får också ett KSN (Key Serial Number), som behövs för dekryptering, och samlar in olika typer av metadata om transaktionen. Det är sant att du kanske bara är intresserad av att få (låt oss säga) råa spår 2-data, men i processen för att få fram dem måste du också hantera många andra data.

Låt oss ta en snabb titt på ett exempel från verkligheten där vi använder ett Starbucks-presentkort som jag fick av en barista med skuldkänslor som en lösning efter att oväntat ha fått slut på Mesopotamian Kumquat-Absinthe Latte. Om vi drar Starbucks-kortet genom ID TECHs Augusta-kortläsare i tangentbordsläge, med Notepad-fönstret öppet (och markören i textfönstret), får vi följande data i Notepad:

02ED01801F4C2800839B%*6010********8765^0254/SERVICERECOVERYUSD^*******************************?*;6010********8765=********************?*95025C86987E4F7DD07D58730EB79FDFB90AB7F23E6ECA6F4F04A67BF511EE13F950903BDE77624680C460E9C36C4F9136256BB93A38CB98F95626DCFAF9335CE0A213074CC1CD84CC911398E06756C464AB036B694228ADA7EC018F495A013AF8A04C976288FE2F80271E6E53D987DE19ACA2707BFF2C78000000000000000000000000000000000000000000000000000000000000000000000000000000003631335435333536313862994900750002A00308108E03

Detta är mycket mer än ”råa spårdata”. Du kan känna igen de maskerade spårdata (som börjar med B% och innehåller många asterisker, som slutligen slutar med ?*), men det döljer det primära kontonumret (Primary Account Number, PAN), som faktiskt är krypterat. Det mesta av det du ser här är en hexadecimal representation av de binära data som kommer ut från läsaren.

Det är lätt att tolka detta stora block av saker om du har kunskap. Det snabbaste sättet att avkoda det är att köra data genom ID TECHs kostnadsfria Parsomatic-verktyg, som är ett HTML-formulär som kan återge alla delar av data på ett begripligt sätt.

Varje kortläsare har sitt eget sätt att representera kortdata. ID TECH representerar magstripe-data i ett format som kallas Enhanced Encrypted MSR-format. Formatet omfattar 26 datafält; alla 26 fält beskrivs i detalj i dokument P/N 80000502-001, ID TECH Encrypted Data Output.

För att ge dig en uppfattning om vad som finns på kortet kan vi betrakta de första 5 bytesna av data (02 ED 01 80 80 1F). Enligt Parsomatic innehåller dessa 5 bytes följande information:

0------- 0 Reserved for future use-0------ 1: Field 10 optional bytes length exists (0: No Field 10)--0----- 1: Track 3 sampling data exists (0: Track 3 sampling data does not exist)---1---- 1: Track 2 sampling data exists (0: Track 2 sampling data does not exist)----1--- 1: Track 1 sampling data exists (0: Track 1 sampling data does not exist)-----1-- 1: Track 3 decode success (0: Track 3 decode fail)------1- 1: Track 2 decode success (0: Track 2 decode fail)-------1 1: Track 1 decode success (0: Track 1 decode fail)

Den första byte (02) är helt enkelt STX, ”start” byte. De två följande bytena (ED 01) representerar längden, i hexagram, på den totala datanyttolasten (little-endian: ED 01 betyder egentligen 0x01ED eller 493 byte data). Card Encode type är 0x80, vilket (på engelska) innebär att vår läsare anser att detta är ett finansiellt kort. Spårstatus (värde: 0x1F) är en statusbyte som innehåller åtta bitars flaggor för att informera dig om vilka spår som fanns på magnetremsan (det kan finnas upp till tre) och vilka som lästes framgångsrikt. I det här fallet lästes alla tre fysiska spår framgångsrikt, men data finns bara på spår 1 och 2.

Vi tittar snabbt på nästa 5 byte. Enligt Parsomatic är dessa bytes och deras betydelser följande:

1------- Bit 7: 1 Serial Number present; 0 not present-0------ Bit 6: 1 PIN Encryption Key; 0 Data Encryption Key--0----- Bit 5: 1 Chip present on card. (First byte of service code was '2' or '6'.) Use EMV transaction if possible.---0---- Bit 4: 0 TDES; 1 AES----0--- Bit 3: 1 if fixed key; 0 DUKPT Key Management-----0-- Bit 2: 1 if Track3 clear/mask data present------1- Bit 1: 1 if Track2 clear/mask data present-------1 Bit 0: 1 if Track1 clear/mask data present

1------- Bit 7: if 1, KSN present-0------ Bit 6: if 1, session ID present --0----- Bit 5: if 1, track3 hash data (SHA digest) present---1---- Bit 4: if 1, track2 hash data (SHA digest) present----1--- Bit 3: if 1, track1 hash data (SHA digest) present-----0-- Bit 2: if 1, track3 encrypted data present------1- Bit 1: if 1, track2 encrypted data present-------1 Bit 0: if 1, track1 encrypted data present

På ett finansiellt kort, Spår 1 kan vara upp till 79 byte långt; Spår 2 kan vara upp till 40 byte långt och spår 3 kan vara upp till 107 byte långt. I det här fallet har vi 76 byte (hex 0x4C) data för spår 1 och 40 byte (0x28) data för spår 2. (Spår 3 hade noll byte.) Dessa längder är viktiga att känna till, inte bara för att analysera de maskerade spårdata utan också för att bestämma längderna på de krypterade versionerna av spåren. Den krypterade längden skiljer sig från den faktiska ursprungliga spårlängden eftersom spårdata måste fyllas på till en slutlängd som är en multipel av 8 för TDES-kryptering, eller en multipel av 16 för AES.

Hur vet vi om data är TDES-krypterade respektive AES-krypterade? Den informationen finns i bit 4 i Clear/Mask Data Sent Status byte (som visas ovan). Det finns också en Encrypted/Hash Data Sent status byte (som visas ovan) för att låta dig veta om krypterade spårdata (och valideringshashar) finns och om ett KSN existerar.

Nu kommer vi till Spår 1 och Spår 2 maskerade data, följt av de krypterade versionerna av dessa, följt av några hashdata (i det här fallet alla nollor) och några andra data (beskrivs nedan). Observera att Parsomatic har konverterat ASCII-spårdata till en hexadekvat representation nedan:

Bemärk att Parsomatic infogar en länk ”Avkryptera dessa data” bredvid krypterade data (se ovan). Om du klickar på länken kommer du till ID TECH:s verktyg för kryptering och dekryptering, där uppgifterna i fråga kan ses i dekrypterad form.

De sista datafälten omfattar läsarens serienummer, nyckelns serienummer (KSN), en LRC, en kontrollsumma och ETX (sändningens slut). LRC är helt enkelt ett bytevärde som representerar XOR (exclusive OR) av alla byte av data i nyttolasten, medan kontrollsumman är en aritmetisk summa på en byte (utan hänsyn till överflöd, naturligtvis) av alla byte i nyttolasten. LRC- och kontrollsumman kan användas för att kontrollera integriteten hos nyttolasten. (De är något enklare och snabbare att beräkna än en riktig CRC.)

Slutsats

Så som du kan se finns det mycket mer i en magstripe-data än ”spårdata”. Vi har inte ens berört betydelsen av vissa av datafälten (vi kanske kan gå in på det i ett framtida inlägg). Vi har inte heller sagt något om EMV-data (vilket definitivt kommer att kräva ett annat inlägg). Men detta borde hjälpa dig att komma igång om du försöker avkoda data som kommer från en ID TECH-kreditkortsläsare.

För mer information, se till (som jag sa tidigare) att konsultera vår tekniska dokumentation om Enhanced Encrypted MSR-dataformatet: ID TECH Encrypted Data Output. ELLER klicka på länken nedan för att ta det första steget mot effektiviserade betalningar!