Smartcardemulation@Watch - Revision history

Pienjanc at 17:18, 20 October 2016

2016-10-20T17:18:23Z

← Older revision		Revision as of 17:18, 20 October 2016
Line 1:		Line 1:
	[[File:android_virtual_smartcard.png\|Android Virtual ~~Smart Card~~ Emulator\|thumb]]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.		[[File:android_virtual_smartcard.png\|Android Virtual Smartcard Emulator\|thumb]]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 ~~Smart Card~~ 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.		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 [https://github.com/frankmorgner 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 [https://jcardsim.org/ jCardSim-Runtime] JavaCard-Applets auszuführen, oder die gelesenen Daten an einen virtuellen SmartCard-Leser, der auf einem PC läuft, weiterzuleiten.		Als Ausgangspunkt dieses Projekts diente die von [https://github.com/frankmorgner 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 [https://jcardsim.org/ jCardSim-Runtime] JavaCard-Applets auszuführen, oder die gelesenen Daten an einen virtuellen SmartCard-Leser, der auf einem PC läuft, weiterzuleiten.
Line 11:		Line 11:
	===Smartcardkommunikation===		===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.		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.
	[[File:smart-card-pins.png\|~~Smart Card~~ Pins\|thumb]]		[[File:smart-card-pins.png\|Smartcard Pins\|thumb]]
	====Kontaktbehaftete Smartcards====		====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.		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.

Pienjanc: /* Fehlerhafte R-APDUs der Gear S2 */

2016-10-20T17:16:06Z

Fehlerhafte R-APDUs der Gear S2

← Older revision		Revision as of 17:16, 20 October 2016
Line 124:		Line 124:
	[[File: apdu-smartphone.png\|R-APDU eines Samsung Galaxy S6 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID\|thumb\|right]][[File: apdu-smartwatch.png\|R-APDU einer Samsung Gear S2 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID\|thumb\|right]]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.		[[File: apdu-smartphone.png\|R-APDU eines Samsung Galaxy S6 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID\|thumb\|right]][[File: apdu-smartwatch.png\|R-APDU einer Samsung Gear S2 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID\|thumb\|right]]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> ~~fällt~~ auf, dass die Gear S2 eine andere Antwort auf Befehle, die eine nicht registrierte Anwendung selektieren sollen, liefert. So liefert die Gear die Antwort <code>69 99</code>, während im ISO 7816-Standard eigentlich die Antwort <code>6A 82</code> 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.		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 <code>69 99</code>, während im ISO 7816-Standard eigentlich die Antwort <code>6A 82</code> 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 <code>6A 82</code> 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.		Als Lösungsversuch habe ich eine Anwendung geschrieben, die bei Empfang einer C-APDU nur <code>6A 82</code> 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.

Pienjanc: /* Fehlerhafte R-APDUs der Gear S2 */

2016-10-20T17:15:34Z

Fehlerhafte R-APDUs der Gear S2

← Older revision		Revision as of 17:15, 20 October 2016
Line 122:		Line 122:

	===Fehlerhafte R-APDUs der Gear S2===		===Fehlerhafte R-APDUs der Gear S2===
	[[File: apdu-smartphone.png\|R-APDU eines Samsung Galaxy S6 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID\|thumb\|right]][[File: apdu-smartwatch.png\|R-APDU einer Samsung Gear S2 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID\|thumb\|right]]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. ~~Dazu~~ 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.		[[File: apdu-smartphone.png\|R-APDU eines Samsung Galaxy S6 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID\|thumb\|right]][[File: apdu-smartwatch.png\|R-APDU einer Samsung Gear S2 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID\|thumb\|right]]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> fällt auf, dass die Gear S2 eine andere Antwort auf Befehle, die eine nicht registrierte Anwendung selektieren sollen, liefert. So liefert die Gear die Antwort <code>69 99</code>, während im ISO 7816-Standard eigentlich die Antwort <code>6A 82</code> 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.		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> fällt auf, dass die Gear S2 eine andere Antwort auf Befehle, die eine nicht registrierte Anwendung selektieren sollen, liefert. So liefert die Gear die Antwort <code>69 99</code>, während im ISO 7816-Standard eigentlich die Antwort <code>6A 82</code> 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 <code>6A 82</code> 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.		Als Lösungsversuch habe ich eine Anwendung geschrieben, die bei Empfang einer C-APDU nur <code>6A 82</code> 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===		===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.		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.

Pienjanc: /* Bekannte Probleme */

2016-10-20T17:14:53Z

Bekannte Probleme

← Older revision		Revision as of 17:14, 20 October 2016
Line 119:		Line 119:
	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.		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==		==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.		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===		===Fehlerhafte R-APDUs der Gear S2===
Line 132:		Line 132:
	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.		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.
	<div style="clear: both"></div>		<div style="clear: both"></div>

	==Fazit und Ausblick==		==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.		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.

Pienjanc: /* Service Profile */

2016-10-20T17:04:54Z

Service Profile

← Older revision		Revision as of 17:04, 20 October 2016
Line 72:		Line 72:
	Leider sind die Angaben, die man in diesem Profil machen muss, nur sehr oberflächlich dokumentiert. So wird beispielsweise das Attribut <code>dataRate</code> im Element <code>serviceChannel</code> 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 <code>reliability</code> wird etwas genauer erläutert. So wird bei einem Paketverlust das Datenpaket erneut geschickt, wenn dieses Attribut den Wert <code>enable</code> besitzt<ref name="SAP Programming 21" />.		Leider sind die Angaben, die man in diesem Profil machen muss, nur sehr oberflächlich dokumentiert. So wird beispielsweise das Attribut <code>dataRate</code> im Element <code>serviceChannel</code> 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 <code>reliability</code> wird etwas genauer erläutert. So wird bei einem Paketverlust das Datenpaket erneut geschickt, wenn dieses Attribut den Wert <code>enable</code> besitzt<ref name="SAP Programming 21" />.

	Das Attribut <code>id</code> im Element <code>serviceProfile</code> 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.		Das Attribut <code>id</code> im Element <code>serviceProfile</code> 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.
	<div style="clear: both"></div>		<div style="clear: both"></div>

Pienjanc: /* Service Profile */

2016-10-20T17:04:12Z

Service Profile

← Older revision		Revision as of 17:04, 20 October 2016
Line 46:		Line 46:

	====Service Profile====		====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.		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.
	<source lang="xml">		<source lang="xml">
	<resources>		<resources>

Pienjanc: /* Service Profile */

2016-10-20T17:04:04Z

Service Profile

← Older revision		Revision as of 17:04, 20 October 2016
Line 46:		Line 46:

	====Service Profile====		====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.		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.
	<source lang="xml">		<source lang="xml">
	<resources>		<resources>
Line 74:		Line 74:
	Das Attribut <code>id</code> im Element <code>serviceProfile</code> 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.		Das Attribut <code>id</code> im Element <code>serviceProfile</code> 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.
	<div style="clear: both"></div>		<div style="clear: both"></div>

	==Erste Schritte==		==Erste Schritte==
	Um mit der Programmierung zu beginnen, ist zunächst einmal die Installation des [https://developer.android.com/studio/index.html Android Studios] (für die Entwicklung der Smartphone-App) sowie des [http://developer.samsung.com/gear/develop/sdk 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 mit der Programmierung zu beginnen, ist zunächst einmal die Installation des [https://developer.android.com/studio/index.html Android Studios] (für die Entwicklung der Smartphone-App) sowie des [http://developer.samsung.com/gear/develop/sdk 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.

Pienjanc: /* Sicherheitsmechanismen */

2016-10-20T17:02:58Z

Sicherheitsmechanismen

← Older revision		Revision as of 17:02, 20 October 2016
Line 41:		Line 41:
	[[File: sap.png\|Sequenzdiagramm des Samsung Accessory Protocol Frameworks\|thumb\|left\|500px]]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 <b>Service Provider</b> Anbieter eines zu definierenden Services ist, zu dem sich 1 bis n <b>Service Consumer</b> verbinden können. Sowohl Service Provider als auch Service Consumer registrieren ihre [[#Service_Profile\|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.		[[File: sap.png\|Sequenzdiagramm des Samsung Accessory Protocol Frameworks\|thumb\|left\|500px]]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 <b>Service Provider</b> Anbieter eines zu definierenden Services ist, zu dem sich 1 bis n <b>Service Consumer</b> verbinden können. Sowohl Service Provider als auch Service Consumer registrieren ihre [[#Service_Profile\|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====		====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.		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.		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====		====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.		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.

Pienjanc: /* T=1-Protokoll */

2016-10-20T17:01:21Z

T=1-Protokoll

← Older revision		Revision as of 17:01, 20 October 2016
Line 28:		Line 28:
	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 <b>C-APDU (Command Application Protocol Data Unit)</b> bezeichnet, die Antwort vom Terminal als <b>R-APDU (Response Application Protocol Data Unit)</b>.		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 <b>C-APDU (Command Application Protocol Data Unit)</b> bezeichnet, die Antwort vom Terminal als <b>R-APDU (Response Application Protocol Data Unit)</b>.
	<div style="clear: both"></div>		<div style="clear: both"></div>
	[[File: c-apdu.png\|Aufbau einer C-APDU<ref name="SmartBook 422">Rankl, Wolfgang; Effing, Wolfgang (2003): Smart Card Handbook. Chichester: Wiley. S. 422.</ref>\|thumb\|right]]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.		[[File: c-apdu.png\|Aufbau einer C-APDU<ref name="SmartBook 422">Rankl, Wolfgang; Effing, Wolfgang (2003): Smart Card Handbook. Chichester: Wiley. S. 422.</ref>\|thumb\|right]]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.
	<div style="clear: both"></div>		<div style="clear: both"></div>
	[[File: r-apdu.png\|Aufbau einer R-APDU<ref name="SmartBook 424">Rankl, Wolfgang; Effing, Wolfgang (2003): Smart Card Handbook. Chichester: Wiley. S. 424.</ref>\|thumb\|right]][[File: response-codes.png\|Klassifikation der Statuswörter einer R-APDU<ref name="SmartBook 425">Rankl, Wolfgang; Effing, Wolfgang (2003): Smart Card Handbook. Chichester: Wiley. S. 425.</ref>\|thumb\|right]]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.		[[File: r-apdu.png\|Aufbau einer R-APDU<ref name="SmartBook 424">Rankl, Wolfgang; Effing, Wolfgang (2003): Smart Card Handbook. Chichester: Wiley. S. 424.</ref>\|thumb\|right]][[File: response-codes.png\|Klassifikation der Statuswörter einer R-APDU<ref name="SmartBook 425">Rankl, Wolfgang; Effing, Wolfgang (2003): Smart Card Handbook. Chichester: Wiley. S. 425.</ref>\|thumb\|right]]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.
Line 35:		Line 35:

	<div style="clear: both"></div>		<div style="clear: both"></div>

	===Samsung Accessory Protocol===		===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 [https://play.google.com/store/apps/details?id=com.samsung.accessory]. Die Kommunikation im SAP-Protokoll findet über Bluetooth statt.		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 [https://play.google.com/store/apps/details?id=com.samsung.accessory]. Die Kommunikation im SAP-Protokoll findet über Bluetooth statt.

Pienjanc at 16:57, 20 October 2016

2016-10-20T16:57:02Z

← Older revision		Revision as of 16:57, 20 October 2016
Line 1:		Line 1:
	[[File:android_virtual_smartcard.png\|Android Virtual Smart Card Emulator\|thumb]]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.		[[File:android_virtual_smartcard.png\|Android Virtual Smart Card Emulator\|thumb]]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~~ ~~[https://github~~.~~com/frankmorgner~~ ~~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~~ ~~[https://jcardsim~~.~~org/~~ ~~jCardSim-Runtime]~~ ~~JavaCard-Applets~~ ~~auszuführen,~~ ~~oder~~ ~~die~~ ~~gelesenen~~ ~~Daten~~ an ~~einen~~ ~~virtuellen~~ ~~SmartCard-Leser~~, ~~der~~ ~~auf~~ ~~einem~~ PC ~~läuft,~~ ~~weiterzuleiten~~.		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 Smart Card 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 [https://github.com/frankmorgner 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 [https://jcardsim.org/ jCardSim-Runtime] JavaCard-Applets auszuführen, oder die gelesenen Daten an einen virtuellen SmartCard-Leser, der auf einem PC läuft, weiterzuleiten.

	[[File:android_virtual_smartcard_watch.png\|thumb\|Android Virtual Smart Card Emulator mit Smart Watch]]		[[File:android_virtual_smartcard_watch.png\|thumb\|Android Virtual Smart Card Emulator mit Smart Watch]]
Line 119:		Line 121:
	[[File: apdu-smartphone.png\|R-APDU eines Samsung Galaxy S6 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID\|thumb\|right]][[File: apdu-smartwatch.png\|R-APDU einer Samsung Gear S2 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID\|thumb\|right]]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. Dazu 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.		[[File: apdu-smartphone.png\|R-APDU eines Samsung Galaxy S6 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID\|thumb\|right]][[File: apdu-smartwatch.png\|R-APDU einer Samsung Gear S2 auf einen Befehl zur Anwendungsselektion mit nicht registrierter AID\|thumb\|right]]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. Dazu 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> fällt auf, dass die Gear S2 eine andere Antwort auf Befehle, die eine nicht registrierte Anwendung selektieren sollen, liefert. So liefert die Gear die Antwort <code>69 99</code>, während im ISO 7816-Standard eigentlich die Antwort <code>6A 82</code> 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 <code>6A 82</code> 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.
	<div style="clear: both"></div>		<div style="clear: both"></div>
	==Ausblick==		==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 [[#Registrierung_der_AIDs\|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 [[#Sicherheitsmechanismen\|verschlüsselte Senden]] hat und wie genau diese Verschlüsselung stattfindet.
	==Literaturverzeichnis==		==Literaturverzeichnis==
	<references/>		<references/>