Technischer Beitrag
Entwicklung für EMV, Teil I
ID TECH entwickelt und vermarktet eine breite Palette von Zahlungsgeräten, von denen heutzutage nahezu alle mit „Chipkarten" (auch „Smartcards" genannt) kompatibel sind. Zahlungen mit einer Chipkarte werden allgemein als „Contact EMV" oder manchmal einfach nur als „EMV" bezeichnet. (EMV steht bekanntlich für Europay, MasterCard und Visa – das Konsortium der Kartenmarken.)
In der Branche bezeichnet eine EMV-Transaktion eine Transaktion, die den Anforderungen der vierbändigen EMV Integrated Circuit Card Specifications for Payment Systems (verfügbar unter https://www.emvco.com/) entspricht. Das vollständige Durchdringen dieser Spezifikation erfordert Zeit. Mit vier Bänden ist sie ein äußerst umfangreiches Regelwerk. ID TECH möchte „EMV-Kompatibilität" jedoch zu einem leicht erreichbaren Ziel für Entwickler machen und bietet daher eine Vielzahl kostenloser Tools, SDKs, Demos und weiterer Ressourcen an, die darauf ausgelegt sind, die Time-to-Market für POS-Integratoren und andere zu beschleunigen, die schnell EMV-Konformität.
EMV: Wo fängt man an?
Die meisten neuen ID TECH-Kunden sind technisch versiert. Dennoch variiert das EMV-Wissen, das Kunden in ein neues Projekt einbringen, erheblich. Die meisten Kunden kennen Zahlungssysteme sehr gut im Kontext von MSR (Magnetstreifenlesern). Einige haben bereits mit EMV gearbeitet, kennen jedoch kontaktloses EMV nicht. Andere sind mit EMV selbst noch nicht vertraut.
Als Orientierungshilfe empfehlen wir Integratoren in der Regel, einen Blick auf das kostenlose White Paper von ID TECH zu werfen: EMV Transactions with the Universal SDK. Die erste Hälfte dieses 25-seitigen White Papers bietet eine Auffrischung zum EMV-Transaktionsablauf. Die wichtigsten Schritte dieses Ablaufs lassen sich wie folgt zusammenfassen:
In jeder Phase dieses Prozesses kommuniziert das Kartenlesegerät mit dem Chip der Smartcard über Low-Level-Protokolle, die in ISO-7816 definiert sind. Der größte Teil der Kartenleser-Logik hierfür ist in einem sogenannten EMV Level 2 kernelgekapselt. Das bedeutet, er ist für den Entwickler der Zahlungsanwendung nicht direkt zugänglich – dieser muss sich lediglich darum kümmern, Befehle an den kernel zu senden (nicht an die Karte selbst). Auch das ist genau genommen nicht ganz präzise formuliert. Der Entwickler der Zahlungsanwendung sendet Befehle tatsächlich an den reader; der Reader übernimmt dann die erforderlichen Interaktionen mit dem Kernel, der seinerseits mit der Karte kommuniziert.
Kommunikation mit dem Reader
Wie sendet man Befehle an den Reader? Es gibt zwei Möglichkeiten:
- Stellen Sie eine Verbindung zum Lesegerät her (in der Regel über USB oder RS-232) und senden Sie Firmware-Befehle direkt daran. Oder alternativ:
- Schreiben Sie mithilfe eines High-Level-Sprachen-SDK Code (in C/C++, C#, Objective-C, Java oder Swift), der die entsprechende ID TECH SDK-Bibliothek nutzt, um die zugrunde liegenden Firmware-Befehle auszuführen.
Die zweite Methode ist im Allgemeinen einfacher, da es verhältnismäßig wenig Zeit erfordert, die High-Level-Sprachen-APIs des ID TECH Universal SDK zu erlernen (zudem stellen wir Ihnen umfangreiches Beispielcode-Material zur Verfügung, auf dem Sie aufbauen können). Der Nachteil von Methode 2 besteht darin, dass Ihre Anwendung tendenziell an eine bestimmte Entwicklungssprache und ein bestimmtes Betriebssystem gebunden ist. Bei Methode 1 liegt die Wahl der Sprache (und des Betriebssystems) bei Ihnen, allerdings müssen Sie die Firmware-Befehls-API auf Byte-Ebene des jeweiligen Geräts erlernen und sämtliche Verbindungsprobleme selbst lösen.
Unabhängig davon, ob Sie sich entscheiden, direkt mit dem Kartenlesegerät zu kommunizieren (über eine serielle Verbindung mit rohen Firmware-Befehlen) oder die integrierte Konnektivität und die High-Level-Befehle des Universal SDK zu nutzen – es ist wichtig zu verstehen, dass eine EMV-Transaktion (und hier spreche ich von herkömmlichem Kontakt- EMV, nicht kontaktlos) in drei Phasen abläuft. In der Terminologie des Universal SDK bezeichnen wir diese Phasen als „Start Transaction", „Authenticate Transaction" und „Complete Transaction". (Jede Phase verfügt über eine entsprechende Methode oder Funktion im USDK.) Aus Sicht des Programmablaufs bedeutet dies, dass der Kernel die Kontrolle während des Transaktionsflusses zweimal an den Aufrufer zurückgibt: einmal nach Abschluss von „Start Transaction" und ein zweites Mal nach „Authenticate Transaction" (jedoch vor „Complete Transaction"). Diese Haltepunkte haben wichtige Auswirkungen auf den Datenfluss, da nach jeder Transaktionsphase unterschiedliche TLVs (Tag-Länge-Wert-Tripel) zurückgegeben werden. Es ist daher wichtig, die benötigten TLVs zum Zeitpunkt ihrer Verfügbarkeit abzurufen, da sie in einer späteren Phase möglicherweise nicht mehr verfügbar sind. Ein typisches Beispiel: Tag 57 (Track-2-Daten) ist am Ende von „Start Transaction" verfügbar, nicht jedoch am Ende von „Complete Transaction".
Kryptogramme in EMV
Einer der wichtigsten Datenpunkte in jeder EMV-Transaktion ist das Application Cryptogram, das in Tag 9F26zurückgegeben wird. Eine Kontakt-EMV-Sitzung erzeugt typischerweise zwei Kryptogramme (9F26 wird zweimal zurückgegeben): eines vor „Complete Transaction" und eines danach. Das Ereignis, das die Karte zur Erzeugung des Kryptogramms veranlasst, wird als Gen AC (Generate Application Cryptogram)-Anforderung bezeichnet.
Der Grund, warum diese Kryptogramme so wichtig sind, liegt darin, dass sie den unwiderlegbaren Nachweis erbringen, dass eine echte, legitime Chipkarte bei einer bestimmten Transaktion physisch vorhanden war. (Sie bestätigen zudem die konkreten Datenwerte, die während dieser Transaktion entstanden sind.) Zum Zeitpunkt der Gen AC präsentiert der L2-Kernel der Chipkarte eine Datenobjektliste (die transaktionsspezifische Daten enthält), woraufhin die Chipkarte mithilfe ihres privaten Schlüssels – der ausschließlich dem Chip bekannt ist – diese Daten signiert und ein nicht fälschbares digitales Artefakt (ein 8-Byte-Kryptogramm) erzeugt, das die Echtheit der Karte und der Daten bestätigt. Die Gültigkeit des Kryptogramms kann von der Online-Instanz überprüft werden, die die Transaktion letztendlich autorisiert (oder je nach Ergebnis ablehnt). Genau dafür wurden Chipkarten entwickelt, und genau das ist der Zweck von EMV. MagStripe-Daten lassen sich leicht fälschen. Kryptogramme, die von einem Chip auf Anfrage erzeugt werden, hingegen nicht.
In meinem nächsten Beitrag setzen wir diese Diskussion fort und betrachten, welche Arten von Kryptogrammen die Karte erzeugen kann, was sie bedeuten, was der Zahlungsanwendungsentwickler damit tun muss und wie sie den Erfolg oder Misserfolg einer Transaktion beeinflussen. Teil II darf nicht verpasst werden!
Haben Sie Fragen zu EMV-Transaktionen? Zu Kartenlesegeräten? Zu kontaktloser Technologie? Zu digitalen Geldbörsen? Wenden Sie sich an unsere Experten: