PDF 941kB - Hochschule Ulm

Aufbau eines sicheren Kanals über NFC
6.3 Möglicher Implementierungsansatz
In diesem Kapitel wird ein möglicher Implementierungsansatz beschrieben, wie die Kommunikation
zwischen einem Reader und einer App abgesichert werden kann. Die Kommunikation
erfolgt im Peer-To-Peer Mode. Der grobe Ablauf zum Aufbau eines sicheren
Kanals könnte in etwa so aussehen: Der Reader sendet sein digital signiertes Teilgeheimnis
an die App. Die App empfängt und überprüft die digitale Signatur des Teilgeheimnisses.
Dies ist möglich, da der Public Key vom Reader in der App hardgecodet
ist. Dadurch, dass beim TrustCenter der Private Key und Public Key auf dem Dateisystem
gespeichert werden müssten, wird auf ein TrustCenter aus Sicherheitsgründen
verzichtet. Die Konsequenz beim Empfang eines Public Keys vom Reader wäre, dass
die Identität nicht geprüft werden kann. Aus diesem Grund wird der Public Key vom
Reader in der App hardgecodet. Andernfalls bestünde auch die Gefahr, dass ein aktiver
Man-In-The-Middle den Public Key vom Reader abfängt und seinen eigenen an die App
weiter schickt. Bestätigt die Überprüfung der digitalen Signatur die Echtheit der Daten
vom Reader, signiert die App mit ihrem Private Key ihr Teilgeheiminis und sendet die
Daten an den Reader weiter. An dieser Stelle gibt es jedoch ein Problem: Woher weiß der
Reader, dass die Daten wirklich von der App stammen? Der Reader als target könnte
zu dem Zeitpunkt Daten von einem Angreifer empfangen. Aus diesem Grund muss die
App einmalig beim ersten Start der App, ein Schlüsselpaar generieren und den Public
Key sicher an den Reader übertragen.
6.3.1 Sichere Übertragung des generierten Public Keys der App
Beim ersten Start der App wird ein Private Key und Public Key Schlüsselpaar erzeugt.
Dieses Schlüsselpaar muss jedoch sicher abgespeichert werden. In Windows Phone 8 besteht
die Möglichkeit, das Schlüsselpaar z.B. im Cryptographic Service Provider (CSP)
abzuspeichern. Der CSP ist eine Softwarekomponente, die es zulässt kryptografische
Operationen durchzuführen und die sichere Speicherung von Schlüsselpaaren ermöglicht.
Microsoft rät davon ab, Schlüsselpaare auf dem Dateisystem zu speichern und empfiehlt
stattdessen diese in einem Container im CSP abzulegen [Mic]. Um ein Schlüsselpaar
in einem CSP Container abzuspeichern, muss der Programmierer zunächst den Container
benennen. Beim nächsten Start der App gibt der Programmierer den Bezeichner
des Containers an, um auf das Schlüsselpaar zugreifen zu können. Im Gegensatz
zu Windows 8.1 Pro Preview, kann eine App A unter Windows Phone 8 nicht auf
den CSP Container der App B zugreifen, um das Schlüsselpaar von App B zu entwenden,
sofern App A weiß, wie App B den Container benannt hat. D.h. dass jede
App einen eigenen CSP Container in ihrem Chamber hat und nicht in der Lage ist
den Chamber zu verlassen, um auf den CSP Container einer anderen App zuzugreifen.
Da der CSP Container benannt werden muss, empfiehlt es sich die PublisherHostId
Property von Windows.Phone.System.Analytics.HostInformation der Windows
Phone Runtime abzufragen. Damit lässt sich ein Gerät für einen Herausgeber eindeutig
identifizieren. D.h. wenn eine andere App diese API aufruft, bekommt sie einen
anderen Rückgabewert. Daher bietet sich an, PublisherHostId als Bezeichner für den
41