Technischer Beitrag
Entwicklung für EMV, Teil I
ID TECH entwickelt und vertreibt eine breite Palette von Zahlungsgeräten, von denen heutzutage nahezu alle mit „Chipkarten" (auch „Smart Cards" genannt) kompatibel sind. Zahlungen, die mit einer Chipkarte getätigt werden, werden allgemein als „Kontakt-EMV" oder manchmal einfach als „EMV" bezeichnet. (EMV steht bekanntlich für Europay, MasterCard und Visa – das Konsortium der Kartenmarken.)
In der Fachsprache bezeichnet eine EMV-Transaktion eine Transaktion, die den Anforderungen der vierbändigen EMV Integrated Circuit Card Specifications for Payment Systems (erhältlich unter https://www.emvco.com/) entspricht. Es braucht Zeit, sich in diese Spezifikation einzuarbeiten – sie umfasst vier Bände und ist entsprechend umfangreich. ID TECH ist jedoch bestrebt, „EMV-Kompatibilität" zu einem leicht erreichbaren Ziel für Entwickler zu machen, indem eine Vielzahl kostenloser Tools, SDKs, Demos und weiterer Ressourcen bereitgestellt wird, die darauf ausgelegt sind, die Markteinführungszeit für POS-Integratoren und andere zu verkürzen, die schnelle EMV-Konformität.
EMV: Wo anfangen?
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 im Kontext von MSR (MagStripe-Lesern) sehr gut. Einige haben bereits mit EMV gearbeitet, sind jedoch mit kontaktlos EMV. Andere sind neu bei EMV selbst.
Als Orientierungshilfe empfehlen wir Integratoren in der Regel, einen Blick in das kostenlose Whitepaper von ID TECH zu werfen: EMV Transactions with the Universal SDK. Die erste Hälfte dieses 25-seitigen Whitepapers bietet eine Auffrischung zum EMV-Ereignisablauf. Die wichtigsten Ereignisse dieses Ablaufs lassen sich wie folgt zusammenfassen:
In jeder Phase dieses Prozesses kommuniziert das Kartenlesegerät mit dem Chip auf der Smartcard über niedrigschwellige Protokolle, die in ISO-7816 definiert sind. Nahezu die gesamte Kartenleser-Logik hierfür ist in einem sogenannten EMV Level 2 kernelgekapselt. Mit anderen Worten: Sie ist für den Entwickler von Zahlungsanwendungen nicht zugänglich – dieser muss sich lediglich darum kümmern, Befehle an den kernel zu senden (nicht an die Karte selbst). Auch das ist noch nicht ganz präzise formuliert. Der Entwickler der Zahlungsanwendung sendet seine Befehle tatsächlich an den reader; der Reader übernimmt dann die erforderlichen zugrunde liegenden Interaktionen mit dem Kernel, der seinerseits mit der Karte kommuniziert.
Kommunikation mit dem Reader
Wie werden Befehle an das Lesegerät übermittelt? Dafür gibt es zwei Möglichkeiten:
- Stellen Sie eine Verbindung (in der Regel über USB oder RS-232) zum Lesegerät her 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 vergleichsweise wenig Zeit erfordert, die High-Level-Sprachen-APIs des Universal SDK von ID TECH zu erlernen (zudem stellen wir Ihnen zahlreiche Codebeispiele als Ausgangsbasis zur Verfügung). Der Nachteil von Methode Nr. 2 besteht darin, dass sie Ihre Anwendung tendenziell an eine bestimmte Entwicklungssprache und ein bestimmtes Betriebssystem bindet. Bei Methode Nr. 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 alle Verbindungsprobleme selbst handhaben.
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, ist es wichtig zu verstehen, dass eine EMV-Transaktion – gemeint ist hier die herkömmliche kontaktbasierte 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 Transaktionsablaufs zweimal an den Aufrufer zurückgibt: einmal nach Abschluss von „Start Transaction" und ein zweites Mal nach „Authenticate Transaction" (aber vor „Complete Transaction"). Diese Haltepunkte haben wichtige Auswirkungen auf den Datenfluss, denn unter anderem werden nach jeder Transaktionsphase unterschiedliche TLVs (Tag-Länge-Wert-Tripel) zurückgegeben. 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
Eines der wichtigsten Datenelemente in einer EMV-Transaktion ist das Application Cryptogram, das in Tag 9F26. Eine kontaktbasierte EMV-Sitzung erzeugt in der Regel zwei Kryptogramme (9F26 wird zweimal zurückgegeben): eines vor dem Abschluss der Transaktion, das andere danach. Das Ereignis, das die Karte zur Erzeugung des Kryptogramms veranlasst, wird als Gen AC-Anforderung (Generate Application Cryptogram) bezeichnet.
Die Bedeutung dieser Kryptogramme 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 aufgetreten sind.) Zum Zeitpunkt des Gen AC-Vorgangs übermittelt der L2-Kernel der Chipkarte eine Datenobjektliste (mit transaktionsspezifischen Daten), 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 ablehnt). Genau dafür wurden Chipkarten entwickelt, und genau deshalb existiert EMV. MagStripe-Daten lassen sich leicht fälschen. Kryptogramme, die auf Anforderung von einem Chip 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. Nicht verpassen: Teil II!
Haben Sie Fragen zu EMV-Transaktionen? Zu Kartenlesern? Zu Kontaktlostechnologie? Zu digitalen Geldbörsen? Kontaktieren Sie unsere Experten: