Smartcardemulation@Watch

Android Virtual Smartcard 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> (HCE). 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. Dies ermöglicht eine komfortablere Nutzung dieser Funktion, da nur die Smart Watch an das Terminal angelegt werden muss, das Telefon aber bspw. in der Hosentasche verbleiben kann. Gegen die komplette Implementierung auf Smart Watch-Seite spricht hingegen, dass die Smartphone App zur Smartcard Emulation viel komfortabler zu bedienen ist als eine entsprechende App auf Smart Watch-Seite, außerdem sind die Rechen-, Speicher- und Energieressourcen auf Smartphoneseite um einiges größer. Des Weiteren bieten viele Smartphones heute die Möglichkeit, ein Secure Element einzubauen, so dass sich auch sicherheitskritischere Anwendungen wie mobiles Bezahlen realisieren lassen.

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.

Smartcard 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) bzw. Answer To Select (ATS)

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) (bei kontaktbehafteten Karten) bzw. Answer To Select (bei kontaktlosen Karten), 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 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). Diese wird durch Protokollparameter festgelegt und vom Terminal durch die ATR/ATS 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>. Empfängt das Terminal nach Senden einer C-APDU innerhalb dieser Zeit keine Antwort von der Smartcard, geht dieses davon aus, dass die Smartcard defekt ist und bricht die Kommunikation ab.

Samsung Accessory Protocol

Das Samsung Accessory Protocol wird genutzt, um Android-Smartphones mit "smartem" Zubehör wie Smart Watches oder Smart TVs zu verbinden. Es ist bereits vorinstalliert auf Samsung Smartphones, kann aber auf anderen Android-Smartphones ab Android-Version 4.0.3 nachinstalliert werden [1]. Die Kommunikation im SAP-Protokoll findet über Bluetooth statt.

Sequenzdiagramm des Samsung Accessory Protocol Frameworks

Das Accessory Protocol sieht ein Provider-Consumer-Muster vor, dies bezieht sich jedoch nicht auf den eigentlichen Datenaustausch, sondern bestimmt, wer die Verbindung initiiert. So sieht das Protokoll vor, dass ein sogenannter Service Provider Anbieter eines zu definierenden Services ist, zu dem sich 1 bis n Service Consumer verbinden können. Sowohl Service Provider als auch Service Consumer registrieren ihre Serviceprofile bei Installation der Anwendung beim Service Framework. Möchte ein Service Consumer nun eine Verbindung zu einem Service Provider aufbauen, erfragt dieser beim Service Framework, ob entsprechende Service Provider registriert sind. Wenn ja, kann der Service Consumer eine Verbindungsanfrage absenden. Der Service Provider akzeptiert oder lehnt diese Verbindungsanfragen ab.

Sicherheitsmechanismen

Das SAP-Framework bietet dabei die Möglichkeit, die Informationen des anfragenden Service Consumers zu überprüfen. So können beispielsweise Hersteller oder Gerätebezeichnung des eine Verbindung herstellenden Geräts abgefragt werden, aber auch der öffentliche Schlüssel des zur Signierung des App-Pakets verwendeten Zertifikats. Dieser kann mit dem öffentlichen Schlüssel des zur Signierung der Provider-App verwendeten Zertifikats verglichen werden<ref name="samsung cert">Samsung (2016): Getting the Certificates. Online verfügbar unter http://developer.samsung.com/gear/develop/getting-certificates, zuletzt geprüft am 20.10.2016.</ref><ref name="android cert">Google (2016): Sign Your App | Android Studio. Online verfügbar unter https://developer.android.com/studio/publish/app-signing.html, zuletzt geprüft am 20.10.2016.</ref>. So kann überprüft werden, ob es wirklich die gewünschte App ist, die die Verbindung initiiert.

Auch eine Verschlüsselung des Sendevorgangs ist möglich. Das Samsung Accessory-SDK<ref name="samsung accessory sdk">Samsung (2016): Accessory | SAMSUNG Developers. Online verfügbar unter http://developer.samsung.com/galaxy/accessory, zuletzt geprüft am 20.10.2016.</ref> spezifiziert allerdings nicht genauer, was für eine Art von Verschlüsselung dabei verwendet wird. Es ist zum Beispiel ebenso denkbar, dass hierbei nur auf eine Bluetooth-Verschlüsselung zurückgegriffen wird.

Service Profile

Damit Provider und Consumer miteinander kommunizieren können, müssen sie ein sogenanntes Service Profile veröffentlichen. Dies enthält eine ID, Angaben über die Rolle der App (Provider oder Consumer), Angaben über die verwendeten Kommunikationskanäle und darüber, zu wie vielen Providern oder Consumern sich gleichzeitig verbunden werden kann.

<resources>
	<application name="VirtualSmartCardReader">
		<serviceProfile
		  serviceImpl="com.vsmartcard.acardemulator.SmartcardProviderService"
		  role="provider"
		  name="VirtualSmartCardReaderProvider"
		  id="/com/smartcard"
		  version="1.0"
		  serviceLimit="any"
		  serviceTimeout="10">
			<supportedTransports>
				<transport type="TRANSPORT_BT"/>
			</supportedTransports>
			<serviceChannel
			  id="104"
			  dataRate="low"
			  priority="high"
			  reliability="enable"/>
		</serviceProfile>
	</application>
</resources>

Leider sind die Angaben, die man in diesem Profil machen muss, nur sehr oberflächlich dokumentiert. So wird beispielsweise das Attribut dataRate im Element serviceChannel wie folgt beschrieben: "The throughput at which data traffic originated from the Accessory Agent. NOTE. The value must be either “low” or “high”."<ref name="SAP Programming 21">Samsung Electronics (2016): Samsung Accessory SDK Programming Guide. Online verfügbar unter http://developer.samsung.com/galaxy/accessory/guide, zuletzt geprüft am 20.10.2016. S. 21.</ref> Lediglich das Attribut reliability wird etwas genauer erläutert. So wird bei einem Paketverlust das Datenpaket erneut geschickt, wenn dieses Attribut den Wert enable besitzt<ref name="SAP Programming 21" />.

Das Attribut id im Element serviceProfile legt fest, unter welchem Bezeichner sich Provider und Consumer finden. Dies ist der Wert, der auf beiden Seiten übereinstimmen muss, damit eine Verbindung aufgebaut werden kann. Dies ermöglicht, dass auch verschiedene Anwendungen mit einem Service Provider bzw. Consumer kommunizieren können, solange sie die selbe ID nutzen.

Erste Schritte

Um mit der Programmierung zu beginnen, ist zunächst einmal die Installation des Android Studios (für die Entwicklung der Smartphone-App) sowie des Tizen Studios (für die Entwicklung der Smart Watch-App) erforderlich. Nach der Installation können Debug-Verbindungen sowohl zu einem Android-Smartphone als auch zu einer Smart Watch aufgebaut werden. Die Verbindung zur Smart Watch ist allerdings recht instabil, häufig muss die Verbindung neu aufgebaut werden oder die Uhr neu gestartet werden, nachdem die Verbindung einmal abgebrochen ist.

Um eine App auf einer Smart Watch zu installieren, muss sie mit einem Zertifikat signiert werden, das die Hardware-Geräte-ID der entsprechenden Smart Watch enthält<ref name="sap cert watch">Samsung (2016): Creating Certificates | Samsung Developers. Online verfügbar unter http://developer.samsung.com/gear/develop/getting-certificates/create, zuletzt geprüft am 20.10.2016.</ref>. Um später die Authentifizierung über die öffentlichen Schlüssel zu ermöglichen, sollte beim Erzeugen des neuen Zertifikates der Keystore, der auch vom Android Studio zum Signieren der App gewählt wurde, als Author Certificate gewählt werden. Konfiguriert man dann noch die Android-App so, dass auch beim Erstellen eines Debug-Pakets dieses Zertifikat und nicht das standardmäßig verwendete Debug-Zertifikat verwendet wird, funktioniert die Authentifizierung beim SAP-Verbindungsaufbau problemlos. Dazu muss in der build.gradle folgendes angepasst werden:

    signingConfigs {
        config {
            keyAlias [key_alias]
            keyPassword [key_password]
            storeFile [store_file]
            storePassword [store_password]
        }
    }
    buildTypes {
        ...
        debug {
            signingConfig signingConfigs.config
        }
    }

Die entsprechenden Konfigurationswerte in eckigen Klammern müssen mit den korrekten Werten versehen werden. Es empfiehlt sich, diese in einer Extra-Konfigurationsdatei zu lagern, da die Passwörter für den Store und den privaten Schlüssel im Klartext gespeichert werden.

Implementierung

Die Implementierung basiert auf der von Frank Morgner entwickelten Virtual Smart Card Architecture<ref name="github morgner">Morgner, Frank (2016): Virtual Smart Card Architecture. Online verfügbar unter https://github.com/frankmorgner/vsmartcard/tree/GearS2, zuletzt geprüft am 20.10.2016.</ref>. Diese Referenzimplementierung sieht vor, dass die APDUs, die vom Terminal an die Smart Watch geschickt werden, per SAP-Verbindung an die Smartphone App weitergeleitet werden, sie dort im entsprechenden Emulator verarbeitet werden und die R-APDU über den SAP-Kanal wieder zurückgeschickt wird. Die Smart Watch überträgt sie dann per NFC an das Terminal.

Der Quellcode meiner Implementierung ist ebenfalls auf GitHub zu finden<ref name="github pien">Pien, Jan-Christopher (2016): Virtual Smart Card Architecture. Online verfügbar unter https://github.com/jessepeng/vsmartcard/tree/GearS2, zuletzt geprüft am 20.10.2016.</ref>.

Android-App

Authentifizierung der Smart Watch-App

Es wurde eine Authentifizierung der Service Consumer, die eine Verbindung aufbauen wollen, eingebaut. Dazu wird, wie unter Sicherheitsmechanismen beschrieben, der öffentliche Schlüssel des Zertifikats, mit dem die Smart Watch App signiert ist, mit dem öffentlichen Schlüssel des Zertifikats, mit dem die Smartphone-App signiert ist, verglichen. Nur wenn beide Schlüssel übereinstimmen, wird die Verbindung akzeptiert. Das soll verhindern, dass Angreifer_innen eine modifizierte App schreiben, die mit dem Virtual Smart Card Emulator kommuniziert, um so an Daten, die auf den virtuellen Smartcards gespeichert sind, heranzukommen.

Übertragung der registrierten Application IDs

Smartcard-Anwendungen werden über eine Application ID angesprochen. Möchte ein Terminal eine bestimmte Anwendung ausführen, sendet es eine C-APDU mit den Werten 00 A4 04 und der gewünschten Application ID. Wird nun Host Card Emulation verwendet, müssen die Application IDs, die emuliert werden, vorher registriert werden. Unter Android wird dazu eine XML-Datei genutzt, in der die entsprechenden AIDs angegeben sind. In der Smart Watch App muss ein API-Aufruf verwendet werden, um die AIDs zu registrieren. Damit die Smart Watch App weiß, welche AIDs sie registrieren soll, wurde das Kommunikationsprotokoll zwischen Smartphone und Smart Watch im Vergleich zur Referenzimplementierung erweitert. In der Referenzimplementierung wurden ausschließlich C-APDUs und R-APDUs hin und her geschickt. Um nun zu ermöglichen, dass die Smart Watch App erfragt, welche AIDs sie registrieren soll, wurde das Protokoll um ein erstes Kontrollbyte erweitert:

• Enthält dieses Byte den Wert d, so enthält der Rest der Nachricht eine APDU.
• Enthält dieses Byte den Wert a, so ist diese Nachricht entweder eine Anfrage nach den registrierten AIDs (wenn sie von der Smart Watch App gesendet wird) oder enthält der Rest der Nachricht eine kommaseparierte Liste von AIDs, die die Smart Watch App registrieren soll (als Antwort von der Smartphone App).

Um festzustellen, welche AIDs übertragen werden sollen, liest die Smartphone App die entsprechende XML-Datei ein.

Verschlüsseltes Senden

Außerdem wurde das unter Sicherheitsmechanismen angesprochene verschlüsselte Senden implementiert. Dazu musste nur der send()-Befehl durch die verschlüsselte Variante secureSend() ersetzt werden.

Smart Watch App

Verbindungsaufbau

Da die Smart Watch App in C programmiert wird, ist die Programmierung sehr eventgesteuert. Beim Aufrufen der App bzw. des Services werden entsprechende Callbacks registriert, um auf die HCE- sowie SAP-Ereignisse reagieren zu können. Wird die Smart Watch mit aktiviertem NFC beispielsweise an ein Terminal angelegt, so wird der registrierte HCE-Callback mit dem Event NFC_HCE_EVENT_ACTIVATED aufgerufen. Die Referenzimplementierung sah vor, erst bei Eintreffen eines solchen Events eine SAP-Verbindung zur Smartphone-App aufzubauen, um die APDUs weiterzuleiten. Wie sich herausstellte, war dieses Verfahren jedoch zu zeitaufwendig, außerdem war die Reihenfolge, in der die HCE- bzw. SAP-Callbacks aufgerufen wurden, nicht fest definiert. So konnte es passieren, dass erst nach Ablauf der BWT eine SAP-Verbindung erfolgreich hergestellt wurde. Das Terminal ging daher davon aus, dass die Smartcard defekt ist, und deaktivierte die NFC-Verbindung wieder.

Als Lösung wird die SAP-Verbindung nun sofort aufgebaut, wenn die Smart Watch App gestartet wird. Nur wenn die Verbindung zwischenzeitlich verloren geht (zum Beispiel, da die Smartphone und Smart Watch entkoppelt wurden oder sich das Smartphone außer Reichweite befindet), wird eine Verbindung bei erstmaligem Aktivieren des HCE-Modus aufgebaut.

Registrierung der AIDs

Analog zur Ermöglichung der Übertragung der AIDs, die registriert werden sollen, musste auf Smart Watch-Seite der entsprechende API-Aufruf realisiert werden, der die AIDs für den HCE-Modus registriert.

Bekannte Probleme

Nach Implementierung oben genannter Features konnte die Smart Watch App erfolgreich mit der Smartphone App kommunizieren. Eingehende C-APDUs wurden weitergeleitet, in der Smartphone App verarbeitet und entsprechende R-APDUs wieder an die Smart Watch und anschließend an das Terminal zurück übertragen. Es konnte so beispielsweise erfolgreich eine OpenPGP-Karte<ref name="openpgp">Pietig, Achim (2014): OpenPGP Card specification - version 2.1.1. PPC Card Systems GmbH. Online verfügbar unter http://g10code.com/docs/openpgp-card-2.1.pdf, zuletzt geprüft am 20.10.2016.</ref> emuliert werden.

Fehlerhafte R-APDUs der Gear S2

R-APDU eines Samsung Galaxy S6 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID

R-APDU einer Samsung Gear S2 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID

Im Gegensatz zur Nutzung ohne die Smart Watch, also durch direktes Anlegen des Smartphones an das Terminal, gelang es jedoch nicht, dass Windows 10 die Smartcard korrekt erkennt. Um dies zu testen wurde ein GIDS-Applet<ref name="gids">Microsoft (2012): Generic Identity Device Specification. Online verfügbar unter https://msdn.microsoft.com/en-us/library/windows/hardware/dn642100(v=vs.85).aspx, zuletzt geprüft am 20.10.2016.</ref> registriert und aktiviert. Mit direkter Nutzung der Smartphone App war es möglich, dieses GIDS-Applet mit einem privaten Schlüssel zu versehen, mittels dessen man sich bei Windows 10 anmelden konnte. Nutzte man nun anstattdessen die Smart Watch als Antenne, erkannte Windows die Smartcard nicht mehr als GIDS-Smartcard.

Nach Analyse der durch die Geräte gesendeten und empfangenen APDUs mittels OpenSC<ref name="opensc">OpenSC (2016): Open SC documentation. Online verfügbar unter https://github.com/OpenSC/OpenSC, zuletzt geprüft am 20.10.2016.</ref> fiel auf, dass die Gear S2 eine andere Antwort auf Befehle, die eine nicht registrierte Anwendung selektieren sollen, liefert. So liefert die Gear die Antwort 69 99, während im ISO 7816-Standard eigentlich die Antwort 6A 82 vorgesehen ist für Selektionsanfragen nach Dateien oder Anwendungen, die nicht vorhanden sind<ref name="ISO7816" /> (siehe Screenshots rechts). Die Vermutung liegt nahe, dass dies dafür sorgt, dass Windows die Smartcard nicht korrekt erkennt und daher nicht die korrekten Anwendungen selektieren kann.

Als Lösungsversuch habe ich eine Anwendung geschrieben, die bei Empfang einer C-APDU nur 6A 82 zurück gibt, und diese auf sämtlichen Application IDs registriert, die bei Anlegen der Smart Watch an das Terminal abgefragt werden. Leider lieferte dies auch nicht den gewünschten Erfolg, im Gegenteil, es wurden nun ganz andere Kommandos geschickt als vorher.

Answer To Select

Ein weiterer Unterschied im Verhalten von Smartphone und Smart Watch liegt in der Answer To Select, die nach Anlegen an das Terminal geschickt wird. Sie unterscheidet sich je nach Gerät. Auch hier liegt die Vermutung nahe, dass dies dafür sorgt, dass Windows die Gear S2 nicht korrekt als Smartcard erkennt.

Leider sind diese beiden Probleme außerhalb des Einflusses des Programmierers, da die Antworten auf nicht vorhandene Anwendungsselektion sowie die ATS hardwareseitig programmiert werden. Es ließ sich daher zumindest während der Projektlaufzeit keine Lösung für diese beiden Probleme finden.

Fazit und Ausblick

Es konnte mit diesem Projekt gezeigt werden, dass das SAP-Protokoll prinzipiell dafür geeignet ist, die gestellte Projektaufgabe zu lösen. Die Kommunikation ist zwar langsamer als bei direktem Anlegen des Smartphones an das Terminal, aber dennoch schnell genug, um innerhalb der BWT zu reagieren. Allerdings wurde auch gezeigt, dass nicht sämtliche Probleme zu lösen waren, was eine uneingeschränkte Nutzung dieser Funktion verhindert.

Eine mögliche Weiterentwicklung der App wäre zum Beispiel das Verwenden von benutzerdefinierten APDUs, um die registrierten AIDs auszutauschen, anstatt das Protokoll wie oben beschrieben anzupassen. Diese Möglichkeit wird auch heute bereits genutzt, zum Beispiel um Daten zwischen Terminal und PC auszutauschen, ohne dass APDUs überhaupt an eine angelegte Smartcard weitergeleitet werden. Es wäre darüber hinaus interessant, zu analysieren, welchen Performanceeinfluss das verschlüsselte Senden hat und wie genau diese Verschlüsselung stattfindet.

Literaturverzeichnis

<references/>