Smartcardemulation@Watch: Difference between revisions
No edit summary |
|||
| Line 93: | Line 93: | ||
==Implementierung== |
==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>. Der Quellcode der 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>. |
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>. Der Quellcode der 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=== |
|||
In der Android-App wurden im Vergleich zur Referenzimplementierung nur wenige Änderungen vorgenommen. |
|||
====Authentifizierung der Smart Watch-App==== |
|||
Es wurde eine Authentifizierung der Service Consumer, die eine Verbindung aufbauen wollen, eingebaut. Dazu wird, wie unter [[#Sicherheitsmerkmale]] 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. |
|||
==Ausblick== |
==Ausblick== |
||
Revision as of 13:12, 20 October 2016
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.
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.
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
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.
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).
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.
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 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.
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 wirklich 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 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.
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>. Der Quellcode der 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
In der Android-App wurden im Vergleich zur Referenzimplementierung nur wenige Änderungen vorgenommen.
Authentifizierung der Smart Watch-App
Es wurde eine Authentifizierung der Service Consumer, die eine Verbindung aufbauen wollen, eingebaut. Dazu wird, wie unter #Sicherheitsmerkmale 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.
Ausblick
Literaturverzeichnis
<references/>