Smartcardemulation@Watch

Android Virtual Smart Card Emulator

Heutige Smartphones mit NFC-Chips sind in der Lage, das Verhalten von kontaktlosen Smartcards zu emulieren. Dieser Mechanismus nennt sich Host Card Emulation<ref name="Android HCE">Google (2016): Host-based Card Emulation. Online verfügbar unter https://developer.android.com/guide/topics/connectivity/nfc/hce.html, zuletzt geprüft am 12.10.206.</ref> Eine Smartphone-App, die diese Schnittstelle verwendet, ist so in der Lage, sich wie eine an ein Terminal angelegte Smartcard zu verhalten.

Heutzutage gibt es auch Smart Watches, die über eine NFC-Schnittstelle verfügen. Idee des Projektes war es, eine solche Smart Watch als "NFC-Antenne" für den virtuellen Smart Card Reader auf einem Android-Telefon zu verwenden. Die Smart Watch sollte also ausschließlich die Datenübertragung vom und zum Terminal übernehmen, während die Verarbeitung der gelesenen Daten weiterhin über die Android-App stattfinden sollte. Als Ausgangspunkt dieses Projekts diente die von Frank Morgner entwickelte App Android Smart Card Emulator<ref name="Android Smart">Morgner, Frank (2016): Android Smart Card Emulator. Online verfügbar unter https://frankmorgner.github.io/vsmartcard/ACardEmulator/README.html, zuletzt geprüft am 13.10.2016.</ref>. Diese ist in der Lage, entweder in der App selber über eine eingebaute jCardSim-Runtime JavaCard-Applets auszuführen, oder die gelesenen Daten an einen virtuellen SmartCard-Leser, der auf einem PC läuft, weiterzuleiten.

Android Virtual Smart Card Emulator mit Smart Watch

Technische Grundlagen

Dieser Abschnitt bietet einen Überblick über die technischen Grundlagen der verwendeten Technologien. Eine hervorragende Einführung zum Thema Smartcards bieten Rankl und Effing mit ihrem Smart Card Handbook<ref name="SmartBook">Rankl, Wolfgang; Effing, Wolfgang (2003): Smart Card Handbook. Chichester: Wiley.</ref> (auch auf deutsch verfügbar). Es wird im Folgenden davon ausgegangen, dass der_die Leser_in weiß, was eine Smartcard ist und wie sie verwendet werden kann.

Smartcardkommunikation

Smartcards können grundsätzlich kontaktbehaftet oder kontaktlos kommunizieren. Darüber hinaus gibt es hybride Smartcards, die beide Kommunikationsarten nutzen. Die Kommunikation findet zwischen Terminal und einer eingesteckten beziehungsweise sich in der Nähe befindenden Smartcard statt.

Smart Card Pins

Kontaktbehaftete Smartcards

Kontaktbehaftete Smartcards nutzen ein Kontaktfeld, über das die Betriebsspannung sowie die Datenübertragung sichergestellt werden. Diese Art von Smartcards werden durch den ISO-Standard 7816 standardisiert<ref name="ISO7816">ISO (2007): ISO/IEC 7816. Identification cards -- Integrated circuit cards.</ref>. Da es in diesem Projekt ausschließlich um kontaktlose Smartcards geht, wird dieser Standard nicht weiter vorgestellt.

Kontaktlose Smartcards

Kontaktlose Smartcards werden durch drei verschiedene ISO-Standards spezifiziert: ISO/IEC 10536<ref name="ISO10536">ISO (2000): ISO/IEC 10536. Identification cards -- Contactless integrated circuit(s) cards -- Close-coupled cards.</ref>, ISO/IEC 14443<ref name="ISO14443">ISO (2016): ISO/IEC 14443. Identification cards -- Contactless integrated circuit cards -- Proximity cards.</ref> und ISO/IEC 15693<ref name="ISO15693">ISO (2010): ISO/IEC 15693. Identification cards -- Contactless integrated circuit cards -- Vicinity cards</ref>. Diese Standards unterscheiden sich hauptsächlich darin, über welche Distanz die kontaktlose Kommunikation stattfinden kann. Während beim ISO/IEC 10536 die Kommunikation nur bis ungefähr 1cm Abstand zwischen Karte und Terminal stattfinden kann, bietet ISO/IEC 14443 die Möglichkeit, über Distanzen von bis ungefähr 10cm zu kommunizieren. ISO/IEC 15693 bietet darüber hinaus Kommunikation bis zu ungefähr 1m Abstand<ref name="SmartBook" />.

Kommunikationsprotokoll(e)

Answer To Reset (ATR)

Bevor Terminal und Smartcard korrekt miteinander kommunizieren können, sendet das Terminal ein Reset Signal. Die Smartcard antwortet darauf mit einer sogenannten Answer to Reset (ATR), die aus einigen Bytes besteht und bestimmt, welches Kommunikationsprotokoll genutzt wird sowie diverse Protokollspezifika festlegt.

Für die Kommunikation von Smartcard und Terminal sind verschiedene Kommunikationsprotokolle spezifiziert<ref name="ISO7816" />. Diese Protokolle heißen T=0 bis T=15, wobei nur T=0, T=1 und T=2 von der ISO spezifiziert sind <ref name="SmartBook" />. Das T=1-Protokoll wird im Folgenden etwas genauer erläutert.

T=1-Protokoll

Kommunikation einer Smartcard mit einem Terminal über APDUs

Im T=1-Protokoll findet die Kommunikation blockweise über ein Halb-Duplex-Verfahren statt. Terminal und Smartcard tauschen also wechselweise Datenpakete aus. Das Protokoll lässt sich im OSI-Schichtenmodell auf der zweiten Ebene, dem Link Layer, ansiedeln.

T=1-Protokoll Block<ref name="SmartBook 410">Rankl, Wolfgang; Effing, Wolfgang (2003): Smart Card Handbook. Chichester: Wiley. S. 410.</ref>

Die Datenpakete bestehen aus einem Prolog, dem Informationsfeld und dem Epilog. Der Prolog beinhaltet Informationen über die Quell- und Zieladresse, ein Kontrollbyte, das das Protokoll kontrollieren kann, sowie ein Längenfeld, das die Länge des Informationsfeldes bestimmt. Das Informationsfeld beinhaltet die Daten, die an die Anwendung jeweils auf Smartcard- und Terminalseite weitergegeben werden. Ein solches Datenpaket heißt APDU (Application Protocol Data Unit). Im Epilog schließlich findet sich eine Prüfsumme, anhand derer Fehler bei der Übertragung festgestellt werden können.

Es gibt drei Arten von Kommunikationsblocks, die ausgetauscht werden: I-Blöcke, R-Blöcke und S-Blöcke. I-Blöcke werden genutzt, um Daten mittels APDUs an die Anwendungsschicht zu übertragen. R-Blöcke werden genutzt, um fehlerfreie oder fehlerhafte Empfangsmeldungen zurückzugeben. S-Blöcke werden genutzt, um Kontrollinformationen auszutauschen, beispielsweise um eine Verlängerung der Block Waiting Time (s.u.) anzufragen. Die Unterscheidung dieser Blöcke findet im Protocol Control Byte (PCB) im Prolog statt.

Da die Kommunikation über ein Halb-Duplex-Verfahren stattfindet, tauschen Terminal und Smartcard abwechselnd APDUs aus. Die APDU, die vom Terminal gesendet wird, wird dabei als C-APDU (Command Application Protocol Data Unit) bezeichnet, die Antwort vom Terminal als R-APDU (Response Application Protocol Data Unit).

Aufbau einer C-APDU<ref name="SmartBook 422">Rankl, Wolfgang; Effing, Wolfgang (2003): Smart Card Handbook. Chichester: Wiley. S. 422.</ref>

Eine C-APDU besteht aus einem Header und einem optionalen Body. Im Header werden ein Class Byte (CLA), ein Instruction Byte (INS) sowie zwei Parameterbytes (P1 und P2) übertragen. Diese bestimmen, welche Instruktion von der Smartcard ausgeführt werden soll. Im Body werden durch zwei Felder zu Anfang und zu Ende des Informationsfeldes angegeben, wie lang die gesendeten Informationen und wie lang die die erwartete Antwort sind.

Aufbau einer R-APDU<ref name="SmartBook 424">Rankl, Wolfgang; Effing, Wolfgang (2003): Smart Card Handbook. Chichester: Wiley. S. 424.</ref>

Klassifikation der Statuswörter einer R-APDU<ref name="SmartBook 425">Rankl, Wolfgang; Effing, Wolfgang (2003): Smart Card Handbook. Chichester: Wiley. S. 425.</ref>

Eine R-APDU besteht aus einem optionalen Body und einem Trailer. Im Body werden die von der Smartcard zurückgegebenen Daten übertragen, während im Trailer ein Statuswort Auskunft darüber gibt, ob der Befehl erfolgreich ausgeführt wurde oder ob Fehler oder Warnungen auftraten.

Die maximale Zeit, die zwischen Senden einer C-APDU und Empfang einer R-APDU verstreichen darf, nennt man Block Waiting Time (BTW). Die wird durch Protokollparameter festgelegt und vom Terminal durch die ATR bestimmt. In der Praxis liegt diese Zeit bei den meisten Karten im Bereich von 0.8s<ref name="SmartBook 415">Rankl, Wolfgang; Effing, Wolfgang (2003): Smart Card Handbook. Chichester: Wiley. S. 415.</ref>.

Literaturverzeichnis

<references/>