PDF 941kB - Hochschule Ulm

Zusammenfassung und Ausblick
Damit die digitale Signatur der App überprüft werden kann, benötigt der Reader den
Public Key der App. In dieser Arbeit wurde ein Ansatz vorgestellt, bei dem die App
ihren Public Key sicher an den Reader übertragen kann, damit dieser die App als vertrauenswürdigen
Client vormerken kann. Um das zu realisieren, muss dazu der Public
Key vom Reader in der App hardgecodet werden. Andernfalls müsste dieser übertragen
werden und es bestünde die Gefahr, dass ein aktiver Man-In-The-Middle seinen Public
Key weiterleitet. Ein weiteres Problem an dieser Stelle ist die Prämisse, dass Smartphone
Betriebssysteme kompromittierbar sind und dadurch Quellcode dekompiliert werden
kann. Wenn ein Angreifer den Public Key des Readers erfahren sollte, ist dieser in der
Lage selbst Nachrichten an den Reader zu senden und kann durch einen Bruteforce-
Angriff versuchen den Code zu erraten. Allerdings kann die Gefahr eines Bruteforce-
Angriffs in Grenzen gehalten werden, wie bereits erwähnt wurde. In der Implementierung
wird auf das anfängliche Übertragen des Public Key der App verzichtet, indem der
Public Key der App im Reader hardgecodet wird. Dennoch wird der Schlüsselaustausch
über NFC mit Elliptic Curve Diffie-Hellman durchgeführt und anschließend eine Textnachricht
mit AES-Verschlüsselung ausgetauscht. An dieser Stelle sei angemerkt, dass
in der Implementierung auf eine Code-Abfrage, um Relay-Angriffe zu verhindern, verzichtet
wird. Daher wird empfohlen, bei sicherheitskritischen Anwendungen, vor einer
Transaktion einen Code abzufragen. Des Weiteren wird in der Implementierung auf den
Cryptographic Service Provider zur sicheren Speicherung des Schlüsselpaars gesetzt. Allerdings
ist dies eine Betriebssystem-API von Windows und Windows Phone und ist
somit auf anderen Plattformen nicht verfügbar. Ein anderer, denkbarer Ansatz wäre,
ein Secure Element zu verwenden, welches für die Erzeugung und sichere Speicherung
von Schlüsselpaaren und anderen sicherheitskritischen Informationen konzipiert worden
ist. Allerdings ist ein Problem an dieser Stelle, das der Zugriff auf das Secure Element
von den Betriebssystemherstellern kontrolliert wird und nicht für jeden Entwickler frei
verfügbar ist. Des Weiteren muss das Secure Element Hardwaremodul in dem eingesetzten
Smartphone auch verfügbar sein. An dieser Stelle muss noch Untersucht werden,
welche Möglichkeiten andere Plattformen zur sicheren Speicherung von Schlüsselpaaren
anbieten und ob ein interoperabler Ansatz realisierbar wäre. Falls es ermöglicht werden
sollte, dass ein Schlüsselpaar sicher auf dem lokalen Dateisystem der App gespeichert
werden kann, kann auf das hardcoden des Public Key verzichtet werden, indem sowohl
der Reader als die App ein TrustCenter verwenden um beim Erhalt eines Public Key die
Vertrauenswürdigkeit prüfen zu können.
72