PDF 941kB - Hochschule Ulm

Aufbau eines sicheren Kanals über NFC
CSP Container zu verwenden. Um jedoch diese API zu verwenden, muss die Capability
ID CAP IDENTITY DEVICE angefordert werden.
Angenommen es gelingt einem Angreifer aus der App A auf den CSP Container einer
App B zuzugreifen und er hat zumindest lesenden Zugriff auf den Chamber der App B.
Er wird versuchen herauszufinden, wie App B ihren CSP Container benannt hat, um
das Schlüsselpaar entwenden zu können. Dadurch, dass die App B die PublisherHostId
API verwendet, um den Container zu benennen, müsste der Angreifer Code im Kontext
der App B ausführen, um den Rückgabewert der PublisherHostId zu erfahren. Dies
funktioniert jedoch nicht, da wie in Kapitel 4.1 beschrieben wurde, alle ausführbaren
Dateien dem Code Signing von Windows Phone 8 unterliegen.
Der Sicherheitsgewinn, der durch Verwendung der PublisherHostId Property entsteht,
besteht darin, dass, auch wenn der Angreifer in der Lage ist auf den CSP Container
der App zuzugreifen und den Quellcode zu analysieren, er nicht weiß, wie der CSP
Container benannt wurde. Ein anderer Interoperabler Ansatz wäre, das Schlüsselpaar
in einem Secure Element zu erzeugen und abzuspeichern. Wie bereits kurz in Kapitel
2.4.3 erwähnt wurde, ist ein Secure Element in der Lage, kryptografische Operationen
durchzuführen und Dateien sicher zu speichern. Da in Kapitel 6.2 festgestellt wurde, dass
sensible Daten nicht auf dem Dateisystem der App gespeichert werden sollten, bietet sich
an dieser Stelle an, die vertrauenswürdigen Informationen von einem Secure Element zu
erzeugen und dort sicher aufbewahren. Dadurch, dass ein Secure Element kryptografische
Operationen durchführen kann, muss ein Private Key diesen Geschützen Bereich nie
verlassen [Zef12]. Ein Problem besteht jedoch: Entwickler haben normalerweise keinen
Zugriff auf die Secure Element Betriebssystem APIs. D.h. Zugriff muss vom Entwickler
beim Betriebssystemhersteller angefordert werden.
Nachdem das Schlüsselpaar erzeugt wurde, wird der Anwender aufgefordert einen Code
in der App einzugeben, welchen der Reader dem Anwender anzeigt. Dieser Code wird
als Salt verwendet, indem der Salt, dem Public Key von der App angehängt wird und
davon ein Hash gebildet wird. Dadurch, dass der Public Key vom Reader in der App
hardgecodet ist und der Anwender einen Code in der App eingeben muss, entspricht diese
einer starken Authentifizierung. Diese Kombination Besitz (Public Key vom Reader) und
Wissen (Code, den der Anwender in die Appeingibt) schließt zunächst einen erfolgreichen
Man-In-The-Middle Angriff aus, da dem Angreifer das Wissen über den Code fehlt. Der
generierte Hash und der Public Key von der App wird mit dem hardgecodeten Public
Key des Readers verschlüsselt und zum Reader übertragen. Der Reader entschlüsselt
mit seinem Private Key den erhaltenen Public Key der App und den Hashwert. Der
Reader fügt den Salt dem erhaltenen Public Key hinzu und generiert daraus den Hash.
Anschließend überprüft der Reader beide Hashwerte ob diese identisch sind. Ist dies der
Fall, fügt der Reader den Public Key der App der Liste der vertrauenswürdigen Clients
hinzu. In Abbildung 22 wird der Ablauf nochmal verdeutlicht.
42