Wie Banken sensible Nutzerdaten am sichersten im Smartphone speichern können – ohne Secure Element
MagicCube
Nachdem die Mobilfunkprovider vor einigen Jahren den Startschuss für das mobile Bezahlen in Deutschland setzten (Stichwort NFC-Sticker), legten die ersten Banken mit eigenen Wallet-Apps für das mobile kontaktlose Bezahlen nach. Der echte Durchbruch gelang im letzten Jahr: Seit 2018 stehen Bankkunden der Volksbanken oder Sparkassen eigene Mobile-Payment-Wallets zur Verfügung und Kunden vieler anderer Institute können Google Pay und Apple Pay nutzen. In diesem Zusammenhang haben wir 2018 viel über die Token-Technologie gehört, die das mobile Bezahlen durch eine zusätzliche Sicherheitsebene absichert. Wie die Platzhalter echter Kartendaten – und analog sonstige kryptografische Schlüssel oder die Kartendaten selbst – allerdings sicher auf Smartphones von Bankkunden gespeichert werden, ist selten Gegenstand der Diskussion.
von Sam Shawki, CEO MagicCube
Kann man kryptografische Schlüssel oder die Kartendaten selbst sicher auf dem Smartphone ablegen? Ja, es gibt verschiedene Optionen – aber auch erhebliche Unterschiede. Die Implikationen betreffen einerseits die Datensicherheit und andererseits die Operabilität für Banken beim Mobile Payment – insbesondere bei jenen Instituten, die Lösungen ohne Tokenization nutzen.Unabhängig vom Bezahlen ist die sichere Speicherung kryptografischer Schlüssel für alle Banken relevant, die Banking-Apps anbieten, in denen ihre Kunden Einsicht in ihren Bankkonten bekommen.”
White-Box-Kryptographie
Die gängigste Lösung für die Speicherung von Bezahlschlüsseln und anderen hochsensiblen Daten ist das sogenannte White-Box-Kryptographie-Verfahren (WBC), auch unter dem Oberbegriff „Obfuscation“ bekannt. WBC ist ein software-basierter Mechanismus, der Daten verschlüsselt und die kryptografischen Codes im Geräte-Speicher verteilt. Bildlich gesprochen wird der sensible Datenteil wie die Nadel im Heuhaufen versteckt. Das Problem bei dieser Technologie:
Sofern ein Mobilgerät vollständig gerootet ist und ein Angreifer damit Zugriff auf Speicher und Prozessor hat, sind per WBC geschützte Daten nicht mehr sicher.”
In dem Moment, in dem ein Verschlüsselungsvorgang stattfindet, wird der entsprechende Key auf dem Speicher des Geräts abgelegt und kann damit von Angreifern gestohlen werden. Ganz so einfach ist das Auslesen natürlich nicht, denn die WBC bettet Teile ihres Schlüssels in den gesamten Speichercode ein. Selbst bei Ausführung des Schlüssels wird der gesamte Key niemals eindeutig offengelegt. Eine Decodierung per Reverse Engineering kann entsprechend Monate dauern.
Sam Shawki ist Gründer und CEO von MagicCube. 2014 gründete der ehemalige Global Head of Remote Payments von Visa das Silicon-Valley-Start-up gemeinsam mit seiner Frau Nancy Zayed, die zuvor über 10 Jahre als Senior Tech Lead bei Apple beschäftigt war und heute CTO bei MagicCube ist. In früheren Positionen war Shawki Chief Innovation Officer bei VimpelCom sowie Gründungsmitglied im Führungsteam von Obopay, einem weltweiten Pionier im Bereich Mobile Payments. Darüber hinaus spielte er eine Schlüsselrolle bei der Einführung einer Reihe von erfolgreichen Start-up-Produkten, darunter ArtBeat, Netscape Navigator, VisualPage, Siebel und Shoretel.Allerdings existieren auch effizientere Methoden: Durch softwarebasierte Verfahren wie Fault Injections oder Side-Channel-Attacks – bei denen zum Beispiel der Energieverbrauch des Prozessors während der Verschlüsselung analysiert wird – können entsprechend geschützte Systeme in zwei bis vier Wochen vollständig geknackt und Daten ausgelesen werden. Die dafür benötigten Ressourcen lassen sich inzwischen kostengünstig auf einschlägigen Websites erwerben und erfordern keine weitreichende Kryptographie-Expertise beim Angreifer.
Secure Element
Eine sicherere Lösung als WBC ist die Speicherung von kryptografischen Schlüsseln in einem so genannten Secure Element (SE). Hierbei handelt es sich um ein vom Gerätespeicher separierten Hardware-Chip. Dieser kann fest im Gerät als Teil eines SoC (System on Chip) verbaut werden, oder als Chip-Partition direkt in den NFC-Chip oder die SIM-Karte integriert werden. Abhängig vom Chip sind unterschiedliche Sicherheitsniveaus möglich. Einige Chips können mit relativ wenig Aufwand kompromittiert werden, bei anderen ist dies nur mit Spezial-Equipment denkbar und extrem aufwändig.
Was allerdings alle SEs gemein haben: Angreifer müssen physischen Zugriff auf das Endgerät erlangen, um das Gerät kompromittieren zu können. Das SE ist weder für Gerätenutzer noch für App-Entwickler zugänglich und kann von außen ausschließlich vom Gerätehersteller (OEM), bzw. im Falle einer SIM-Karte von Mobilfunkanbietern, kontrolliert werden.
Die Entscheidung, ein SE zu verbauen, liegt im Ermessen der OEMs. Einige Betreiber von Betriebssystemen, wie z. B. Google, unterstützen SEs zugunsten der Hardwareunabhängigkeit von Android nicht mehr.”
Selbst wenn es einem Angreifer gelingen sollte, Zugriff auf ein SE zu erlangen, sind maliziöse Anwendungen schwierig einzuschleusen, da Anwendungsart und -größe strikt limitiert sind: Das SE ist in der Regel auf die Speicherung von Schlüsseln und die Performance-Optimierung von Verschlüsselungsvorgängen beschränkt. Dadurch ist das SE für Dritte kaum nutzbar, sofern sie keine Kooperation mit der Organisation eingehen, die den Chip kontrolliert. Die Anzahl der Geräte, die überhaupt über ein SE verfügen, ist gegenüber Geräten ohne diesen Chip relativ klein, was Angriffsszenarien zusätzlich unattraktiv macht.
Trusted Execution Environment
Auf die Trusted Execution Environment (TEE) möchte ich an dieser Stelle nicht im Detail eingehen. Stark vereinfacht ausgedrückt, handelt es sich hierbei um eine große Version eines hardware-basierten Secure Elements. Die TEE unterhält ihr eigenes Betriebssystem und bietet erheblich mehr Speicherplatz und Funktionalitäten als ein Secure Element – unter anderem steuert sie viele Gerätetreiber, wie zum Beispiel den Fingerabdrucksensor.
Virtuelle Trusted Execution Environment
Die vierte und zugleich neueste Lösung, um Bezahltokens und andere kryptografische Schlüssel sicher zu speichern, ist die so genannte virtuelle Trusted Execution Environment (vTEE). Hierbei handelt es sich um eine TEE-Plattform mit einem eigenen Betriebssystem, das wie ein eigenständiges Device mit vom Smartphone entkoppelter Sicherheitsarchitektur agiert und über eine proprietäre Befehlsarchitektur (ISA) verfügt. Wenn sie als Programmbibliothek für Anwendungen angelegt wird, liefert sie ein Sicherheitsniveau, das mit einer Hardware-basierten Lösung vergleichbar ist; mit dem Unterschied, dass App-Entwickler die vollständige Kontrolle über die Sicherheit (ausschließlich) ihrer Anwendung haben. vTEE können App-Anbieter auf jedem Gerät jedes Herstellers selbst einsetzen und müssen dafür weder vorab vertragliche noch logistische Kooperationen und Verpflichtungen mit OEMs oder Mobilfunkunternehmen eingehen.
MagicCube
Eine vTEE lässt sich „Huckepack“ beim App-Download mit herunterladen und dazu remote steuern. Auf dem Gerät liegt der autarke Software-Container, der wie ein „virtueller Chip“ funktioniert. Er kommuniziert über ein spezielles Protokoll mit einem Server, den Anbieter in ihrem eigenen Rechenzentrum überall auf der Welt unterbringen können. Das Protokoll kann ausschließlich mit proprietären SDKs benutzt werden. Der „Root of Trust“ liegt in diesem speziellen Server im Backend, nicht im Gerät selbst.
Im Unterschied zu einer Hardware-basierten Lösung lassen sich die Software-Container in vTEE-Umgebungen im Falle einer Kompromittierung einfach deaktivieren und mit veränderten Anmeldeinformationen neu ausgeben. Das bedeutet, dass Hacker einen neuen Angriff bei Null starten müssten. Die vTEE kann somit mehr als ein grundlegendes Sicherheitssystem sein und aktiv als Gegenmaßnahme eingesetzt werden. Grundsätzlich kann sie als Präventionsmaßnahme flexibel und jederzeit ausgetauscht werden – um die Angreifbarkeit beispielsweise turnusmäßig weiter zu reduzieren. Der Server im Backend fungiert parallel als permanente Feedbackschleife, die den Zustand und die Sicherheit der lokalen vTEE überwacht und auch andere Risikosysteme proaktiv alarmieren kann.
Schlussfolgerungen für mobile Bezahllösungen von Banken
Welche Implikationen gehen nun mit den einzelnen Alternativen einher? Beim mobilen Bezahlen setzen viele Wallets zur Speicherung von Bezahlschlüsseln heute noch auf White-Box-Kryptographie. Die wesentliche Ursache war lange Zeit schlicht der Mangel an Alternativen.
WBC ist nicht die sicherste, sondern die praktikabelste Lösung. Das heißt nicht, dass Mobile-Payment-Wallets durch die Verwendung von WBC automatisch unsicher sind.”
Dennoch sind sie wenig operational: Sie erfordern von den Banken einen sehr hohen Folgeaufwand. Nach Entwicklung und Einführung entsprechender Apps, sind kontinuierliche Software-Updates notwendig – Bezahlschlüssel müssen im zwei- bis vierwöchigen Turnus ausgetauscht werden. Die Updates müssen von jedem Gerät und jeder neuen Betriebssystemversion unterstützt werden.
Die Hardware-basierten Lösungen sind außerordentlich sicher. Leider sind sie für Banken und andere Wallet-Anbieter jedoch nur eingeschränkt verfügbar.”
Da Android keine Secure Elements unterstützt und die meisten Android-betriebenen Smartphones daher keine entsprechende Hardware verbaut haben, fällt diese Option als Lagerstätte für Bezahlschlüssel auf der Mehrzahl der Endgeräte weg. Beispielsweise iOS-Geräte verfügen zwar über ein Secure Element, um dies als App-Anbieter allerdings nutzten zu können, muss zunächst eine Einigung mit Apple erzielt werden. Hier gespeicherte Daten können zudem im fortlaufenden Prozess nicht anbieterseitig ausgetauscht werden, weil ihnen keine Remote-Steuerung offensteht.
Eine zukunftsfähige Alternative bietet das vTEE-Verfahren. Mit dem virtuellen Chip können Banken Bezahlschlüssel auf Telefonen aller Hersteller speichern, ohne in langwierige Verhandlungsprozesse einsteigen zu müssen.
… Damit werden theoretisch sogar weitere mobile Bezahllösungen auf dem iPhone denkbar. Da Apple den NFC-Chip für kontaktlose Zahlungen jedoch nicht freigibt, müsste ein anderes Verfahren – z. B. QR-Codes – verwendet werden.”
EMVCo prüft vTEE und schafft neue Kategorie für software-basiertes mobiles Bezahlen
Die EMVCo hat Ende 2018 eigens eine neue Sicherheitskategorie für software-basiertes mobiles Bezahlen (SBMP) eingeführt. Die Einführung einer neuen Sicherheitskategorie ist nicht alltäglich. In der Regel zertifiziert die Dachorganisation der Kartenorganisationen Hardware und schafft keine gänzlich neuen Software-basierten Kategorien. Die Zertifizierung der vTEE-Lösung unseres IoT-Start-ups MagicCube wird innerhalb der SBMP-Spezifikation aktuell geprüft. Ein von der EMVCo akkreditiertes Testlabor hatte sie bereits über fünf Monate überprüft.
Mit vTEE können Banken sensible Daten weit sicherer als mit WBC-Verfahren auf Endgeräten von Verbrauchern speichern – der Sicherheitsgrad kann es mit Hardware-basierten Lösungen aufnehmen.
Dabei kann der virtuelle Chip von Banken nicht nur für Payment-Wallets genutzt werden, sondern auch für Banking-Apps, mit denen sie die exklusive Beziehung zu ihren Kunden erhalten und frei entscheiden können, wann sie neue Features wie zum Beispiel Loyalty-Programme einführen wollen.”
Darüber hinaus bietet der virtuelle Chip Potenziale für künftige bankeigene Lösungen für das Internet of Things. Er bietet die Sicherheitsbasis für eigene IoT-Apps und Connected-Payments-Anwendungen von Banken im Bereich Connected Car oder Smart Cities, bei denen hochsensible Daten sicher gespeichert werden müssen.aj
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/83669
Schreiben Sie einen Kommentar