Verfahren zur sicheren Interaktion eines Nutzers mit einem mobilen Endgerät und einer weiteren Instanz

Die Erfindung betrifft ein Verfahren und ein System zur sicheren Interaktion eines Nutzers mit einem mobilen Endgerät und einer weiteren Instanz.

Bei der Verwendung beliebiger mobiler Endgeräte wie zum Beispiel Smartphones für eine sichere Kommunikation mit einem Fahrzeug gibt es hochkritische Anwendungsgebiete, die ein besonderes Sicherheits-Design erfordern. Verwendet man das mobile Endgerät beispielsweise als Fahrzeugschlüssel, ist der IT-Sicherheitsanspruch sehr hoch. In diesem Fall sind neben dem mobilen Endgerät, dem Fahrzeug auch noch ein Schlüsselverwaltungssystem, das zumeist in einem entfernten Backend angeordnet ist, Komponenten des Gesamtsystems. Sowohl die einzelnen Komponenten als auch deren Kommunikationsverbindungen müssen

entsprechenden Sicherheitsrichtlinien genügen.

Es gibt verschiedene sichere Ausführungsumgebungen auf modernen mobilen Endgeräten. Neben softwarebasierten Lösungen existieren grundlegend zwei verschiedene Arten

hardwarebasierter sicherer Ausführungsumgebungen: Secure Element (Sicheres Element oder Sicherheitsmodul), zum Beispiel in Form einer SIM-Karte oder eines eingebetteten sicheren Chips (embedded Secure Element), und Trusted Execution Environment (geschützte

Ausführungsumgebung), zum Beispiel als sicherer Bereich eines Prozessors.

EP 2 713 328 A1 offenbart ein Mobilgerät mit einem sicheren Prozessor, wie einem Trusted Execution Environment oder einem Secure Element, eingerichtet zur sicheren

Gestenerkennung.

GB 2526540 A offenbart ein Mobilgerät mit einem Secure Element, in welches bei der

Produktion kryptographische Schlüssel für eine spätere Nutzung durch zu installierende

Programme eingebracht werden.

US 2014/0317686 A1 offenbart ein Mobilgerät mit einem verteilten Trusted Execution

Environment bestehend aus zwei Komponenten, nämlich einem Trusted Execution Environment in einem Secure Element und einem Trusted Execution Environment Proxy, welcher auf dem Mobilgerät ausgeführt wird.

Der Erfindung liegt nun die Aufgabe zugrunde, eine vollständige Sicherheitskette aller an der Interaktion beteiligten Entitäten auf einfache und zuverlässige Weise bereitzustellen.

Diese Aufgabe wird gelöst durch ein Verfahren gemäß Anspruch 1 beziehungsweise ein System gemäß Anspruch 8.

Das erfindungsgemäße Verfahren zur sicheren Interaktion eines Nutzers mit einem mobilen Endgerät und einer weiteren Instanz, umfasst die Schritte:

Übertragen eines Geheimnisses oder einer durch eine Einwegfunktion erzeugten Abbildung des Geheimnisses und eines individuellen Datums von dem Nutzer an ein Backend;

Übertragen der Abbildung und des individuellen Datums von dem Backend an eine geschützte Ausführungsumgebung eines Prozessors des mobilen Endgeräts;

Anmelden des Nutzers an einer sicheren Benutzerschnittstelle des mobilen Endgeräts, wobei dem Nutzer das individuelle Datum angezeigt wird und wobei der Nutzer sich mit dem Geheimnis authentisiert;

Interaktion des Nutzers mit einem sicheren Element des mobilen Endgeräts, welches mit der geschützten Ausführungsumgebung eine sichere Verbindung aufweist, über die sichere Benutzerschnittstelle und die geschützte Ausführungsumgebung; und

Interaktion des sicheren Elements mit der weiteren Instanz über eine gesicherte

Verbindung.

Das erfindungsgemäße Verfahren hat den Vorteil, dass mindestens ein mobiles Endgerät in ein ganzheitliches Sicherheitsmodell zur Kommunikation mit einem Backend und mindestens einer weiteren Instanz, wie zum Beispiel einem Fahrzeug, eingefügt wird. Dadurch wird eine geschlossene Vertrauenskette aller Entitäten in verteilten Systemen zur Erlangung eines sicheren Gesamtsystems geschaffen. Durch die beidseitige Authentifikation zwischen Nutzer und Benutzeroberfläche des mobilen Endgerätes, zwischen Benutzeroberfläche des mobilen Endgerätes und dem sicheren Element, zwischen dem sicheren Element und dem Backend, sowie zwischen dem sicheren Element und der weiteren Instanz wird eine geschlossene Sicherheitskette gewährleistet. Da die gesamte Kette an Authentifikationen in einem

geschlossenen, sicheren Kontext erfolgt, ist eine optimale IT-Sicherheit dieses Gesamtsystems gewährleistet. Als Interaktion werden hier Aktionen wie zum Beispiel der Zugang wie Öffnen/Schließen, das Betätigen von Funktionen, wie zum Beispiel Anlassen, Navigation starten und auch eine uni- oder bidirektionale Kommunikation angesehen. Das sichere Element (SE, Secure Element) kann eine eigenständige Recheneinheit wie zum Beispiel einen Mikrocontroller mit eigenem Betriebssystem umfassen oder es kann die Form einer SIM-Karte oder eines eingebetteten sicheren Chips haben. Die geschützte Ausführungsumgebung (TEE, Trusted Execution Environment) stellt eine sichere oder vertrauenswürdige Laufzeitumgebung für Anwendungen bereit. Die geschützte Ausführungsumgebung kann auf einem separaten Prozessor, auf dem oder den Hauptprozessoren eines Computersystems oder in einem Die eines Multiprozessor- Systems beziehungsweise eines Ein-Chip-System (SoC) ausgeführt werden beziehungsweise implementiert werden. Die Einwegfunktion erzeugt eine Abbildung wie zum Beispiel einen Hashwert.

Während sichere Elemente den Vorteil haben, dass sie als tamper-resistant gelten und damit besondere Vorkehrungen gegenüber invasiven Angriffen, wie zum Beispiel lonenbeschuss, Manipulation von Leiterbahnen durch Ätzen oder Abschleifen, treffen, haben geschützte Ausführungsumgebungen den Vorteil, theoretisch mit den Ressourcen des gesamten Systems oder SoCs des mobilen Endgeräts arbeiten zu können. Da geschützte

Ausführungsumgebungen in der Lage sind, alle möglichen Hardwarekomponenten als sichere Geräte zu deklarieren und somit unterscheiden können, ob Daten von einem als sicher oder unsicher eingestuftem Peripheriegerät bereitgestellt wurden, lässt sich zum Beispiel das Feature "Trusted User Interface" realisieren. Dies bedeutet, dass zum Beispiel die Ein- und Ausgabemöglichkeit eines mobilen Endgeräts wie ein Touchscreen kontextabhängig zu einem sicheren Gerät erklärt werden kann und sämtliche Benutzereingaben nicht mehr vom unsicheren Betriebssystemkernel gesehen werden. Dies kann zum Beispiel dafür genutzt werden, um den Kundenlogin an einer Bank-Webseite abzusichern, in dem das Passwort erst dann einzugeben wird, wenn der Touchscreen vom unsicheren Kernel entkoppelt ist und vollständig an den sicheren Kernel angekoppelt ist. Hier werden die sich ergänzenden Vorteile beider Technologien kombiniert, um für die Interaktion zwischen mobilem Endgerät und der weiteren Instanz, wie zum Beispiel einem Fahrzeug, das Sicherheitsniveau zu erhöhen.

Konkreter können entweder über die Bedatungsprozesse von dem sicheren Element und der geschützten Ausführungsumgebung individuelle kryptographische Schlüssel (entweder asymmetrisch oder symmetrisch) eingebracht werden auf Basis derer das sichere Element mit der geschützte Ausführungsumgebung bidirektional sicher kommunizieren kann. Oder das sichere Element wird nativ von der geschützten Ausführungsumgebung unterstützt. Es kann vorgesehen sein, dass die sichere Benutzerschnittstelle von der geschützten

Ausführungsumgebung als sicheres Gerät deklariert wird. Auf diese Weise kann die Eigenschaft der geschützten Ausführungsumgebung, Geräte oder Komponenten als sicher zu deklarieren und anzubinden genutzt werden, was eine große Flexibilität erlaubt. Die Benutzerschnittstelle kann zum Beispiel ein Touchscreen eines Mobiltelefons sein. Es wird eine sichere

Eingabemöglichkeit geschaffen. Dazu kann zum Beispiel die geschützte Ausführungsumgebung im sicheren Bereich eine virtuelle Maschine für die sichere Benutzerschnittstelle, auch TUI (Trusted User Interface) genannt, anlegen und/oder betreiben. So kann unter anderem sicher gestellt werden, dass ein Framebuffer nur im sicheren Kontext bleibt, also nicht unberechtigt ausgelesen werden kann.

Es kann weiter vorgesehen sein, dass die Verbindung zwischen der geschützten

Ausführungsumgebung und dem sicheren Element mittels aus dem Backend bezogener Schlüssel geschützt wird. Dies kann eine symmetrische oder asymmetrische Verschlüsselung sein. Da die Schlüssel aus dem Backend stammen, wo eine sichere Ableitung oder Erzeugung garantiert ist, ist ein hoher Sicherheitsstandard gegeben. Zudem müssen so weder die geschützte Ausführungsumgebung noch das sichere Element die für eine Ableitung oder Erzeugung der Schlüssel notwendige Hard- oder Software aufweisen.

Es kann ferner vorgesehen sein, dass in einem Betriebssystem des mobilen Endgeräts ein Programm zur Interaktion mit der weiteren Instanz ausgeführt wird und dass das Programm über das sichere Element mit der weiteren Instanz interagiert. Dieses Programm, wie zum Beispiel eine App, kann zur Steuerung von Funktionen der weiteren Instanz dienen. Da das Betriebssystem des mobilen Endgeräts üblicherweise nicht als sicher gelten kann, kann über die Proxyfunktion des sicheren Elements trotzdem eine sichere Verbindung zwischen dem Programm und der weiteren Instanz aufgebaut werden, zum Beispiel um Funktionen der weiteren Instanz sicher zu bedienen.

Zwischen dem Backend und dem Programm kann eine über das sichere Element laufende sichere Verbindung aufgebaut werden. Da das Betriebssystem des mobilen Endgeräts üblicherweise nicht als sicher gelten kann, kann über die Proxyfunktion des sicheren Elements trotzdem eine sichere Verbindung zwischen dem Programm und dem Backend aufgebaut werden, zum Beispiel um Daten auszutauschen, Berechtigungen zu verwalten oder Updates und weitere Software-Installationen auszuführen. Es kann vorgesehen sein, dass das sichere Element eine Kommunikationsschnittstelle für das Programm und eine Kommunikationsschnittstelle für die weitere Instanz aufweist und dass in Abhängigkeit von der Interaktion des Nutzers die Fähigkeiten mindestens einer

Kommunikationsschnittstelle konfiguriert werden. So kann zum Beispiel vorgesehen sein, dass nach einer Eingabe oder Anmeldung des Nutzers nur eine oder beide

Kommunikationsschnittstellen für einen bestimmten Zeitraum, zum Beispiel von wenigen Minuten Daten senden beziehungsweise empfangen kann. Dies kann die Sicherheit durch eine Verringerung von Angriffsmöglichkeiten erhöhen. Die Kommunikationsschnittstelle kann logisch sein, zum Beispiel in Form eines Ports oder Protokollstacks, die dann mit einer physikalischen Schnittstelle wie zum Beispiel einem NFC-Controller in Verbindung steht. Andererseits kann die Kommunikationsschnittstelle eine physikalische Schnittstelle wie zum Beispiel einen NFC- Controller umfassen.

Es kann ferner vorgesehen sein, dass für eine sichere Kommunikation zwischen dem mobilen Endgerät und der weiteren Instanz ein Schlüssel in dem Backend und in der weiteren Instanz vorhanden ist, dass eine Ableitung des Schlüssels in das sichere Element eingebracht wird und dass für eine authentische Verbindung eine Ableitung des Schlüssels in der weiteren Instanz vorgenommen wird. Hierzu können symmetrische oder asymmetrische kryptographische Verfahren verwendet werden. Symmetrische Kryptographie hat den Vorteil, dass nur ein Geheimnis in der weiteren Instanz vorhanden sein muss und die jeweils benötigte Ableitung bei Bedarf erstellt wird. Das potentiell unsichere mobile Endgerät erhält nur eine Ableitung, woraus das Geheimnis nicht rekonstruiert werden kann.

Das erfindungsgemäße System zur sicheren Interaktion eines Nutzers mit einem mobilen Endgerät und einer weiteren Instanz, eingerichtet zur Ausführung eines wie zuvor

beschriebenen Verfahrens, umfasst

ein Backend, in welchem ein Geheimnis oder eine durch eine Einwegfunktion erzeugte Abbildung des Geheimnisses und eines individuellen Datums von einem Nutzer gespeichert ist; ein mobiles Endgerät mit einer geschützten Ausführungsumgebung eines Prozessors, eingerichtet zur Speicherung der Abbildung und des individuellen Datums;

eine sichere Benutzerschnittstelle des mobilen Endgeräts, eingerichtet zur Anmeldung und authentischen Interaktion des Nutzers;

ein sicheres Element des mobilen Endgeräts, welches mit der geschützten

Ausführungsumgebung eine sichere Verbindung aufweist; und

eine weitere Instanz, eingerichtet zur geschützten Kommunikation mit dem sicheren Element des mobilen Endgeräts. Das System kann eine oder mehrere der beschriebenen Komponenten umfassen. Insbesondere können mehrere mobile Endgeräte wie zum Beispiel Mobilfunkgeräte und/oder mehrere weitere Instanzen vorgesehen sein. Die weiteren Instanzen können auch

unterschiedliche Geräte sein, mit denen gesichert kommuniziert werden soll oder muss. Es gelten die gleichen Vorteile und Modifikationen wie zuvor beschrieben.

Das mobile Endgerät und die weitere Instanz können eine Kommunikationsschnittstelle eines drahtlosen Kommunikationsstandards aufweisen. Dies können zum Beispiel eine oder mehrere Standards wie NFC (Near Feld Communication), Bluetooth, insbesondere LE (Low Energy), WLAN oder ähnliches sein.

Die weitere Instanz kann ein Fahrzeug sein. Das hier vorgestellte Verfahren und System eigenen sich insbesondere für Fahrzeuge, da bei Fahrzeugen sowohl ein flexibler und komfortabler Zugang als auch hohe Sicherheit von Bedeutung sind.

Weitere bevorzugte Ausgestaltungen der Erfindung ergeben sich aus den übrigen, in den Unteransprüchen genannten Merkmalen.

Die verschiedenen in dieser Anmeldung genannten Ausführungsformen der Erfindung sind, sofern im Einzelfall nicht anders ausgeführt, mit Vorteil miteinander kombinierbar.

Die Erfindung wird nachfolgend in Ausführungsbeispielen anhand der zugehörigen

Zeichnungen erläutert. Es zeigen:

Figur 1 eine schematische Darstellung eines Systems und Verfahrens zur sicheren

Interaktion eines Nutzers mit einem mobilen Endgerät und einer weiteren Instanz.

Figur 1 zeigt eine schematische Darstellung eines Systems 10 zur sicheren Interaktion eines Nutzers 12 mit einem mobilen Endgerät 14, einer weiteren Instanz 16 und einem Backend 18. Der Nutzer 12 ist Nutzer und/oder Inhaber des mobilen Endgeräts 14, wie zum Beispiel einem Smartphone oder Tablet, sowie der weiteren Instanz 16. Im Folgenden wird die weitere Instanz als Fahrzeug 16 bezeichnet. Das Fahrzeug 16 kann zum Beispiel ein PKW, ein Nutzfahrzeug oder ein Motorrad sein. Alternativ kann die weitere Instanz jedoch auch ein beliebiges Gerät wie zum Beispiel ein Geldautomat oder ähnliches sein. Das Backend 18 kann zum Beispiel ein Zentralrechner oder Server sein oder diesen umfassen. Das Backend 18 gehört zu einem Hersteller des Fahrzeugs 16 oder zu einem Dienstanbieter.

Im Folgenden werden das System 10 sowie ein auf dem System 10 laufendes Verfahrens zur sicheren Interaktion beschrieben.

Zunächst wählt der Nutzer 12 ein Geheimnis 20 aus, das zum Beispiel ein Passwort und/oder ein biometrisches Merkmal wie ein Fingerabdruck sein kann. Dazu wählt er ein individuelles Datum 22, wie einen Text, ein Bild oder ähnliches. Bei einer Registrierung des Nutzers 12 an dem Backend 18 für eine Nutzung des Fahrzeugs 16 werden sowohl das Geheimnis 20 als auch das individuelle Datum 22 an das Backend 18 übertragen und dort in einer Datenbank 24 gespeichert. Anstelle des Geheimnisses 20 wird bevorzugt aus Sicherheitsgründen nicht das Geheimnis 20 gespeichert sondern eine Abbildung 26 des Geheimnisses 20. Die Abbildung 26 wird durch eine Einwegfunktion erzeugt, also kann das Geheimnis 20 nicht aus der Abbildung 26 zurückgerechnet werden. Die Abbildung 26 ist zum Beispiel eine Hashwert.

Danach findet ein Übertragen der Abbildung 26 und des individuellen Datums 22 von dem Backend 19 an eine geschützte Ausführungsumgebung 28 eines Prozessors oder SoCs des mobilen Endgeräts 14 statt. Dieses Übertragen ist durch gestrichelte Pfeile angedeutet und bedeutet, wie für alle gestrichelten Pfeile eine sichere Übertragung der im Backend 18 durch Registrierung hinterlegten oder dort generierten Geheimnisse in entsprechende Teilsysteme des mobilen Endgerätes 14 oder des Fahrzeuges 16. Die Absicherung dieser

Datenübertragung geschieht zum Beispiel über während des Produktionsvorganges eingebrachte Geheimnisse.

Nun kann sich der Nutzer 12 an einer sicheren Benutzerschnittstelle 30 des mobilen Endgeräts 14 anmelden, wobei dem Nutzer 12 das individuelle Datum 22 angezeigt wird und wobei der Nutzer 12 sich mit dem Geheimnis 20 authentisiert. Die sichere Benutzerschnittstelle 30 ist zum Beispiel ein Touchscreen, der von der geschützten Ausführungsumgebung 28 als sicheres Gerät deklariert wurde oder wird und entsprechend behandelt wird.

Über das individuelle Datum 22 kann die geschützte Ausführungsumgebung 28 dem Nutzer 12 beweisen, dass seine Eingabemöglichkeit vertrauenswürdig ist. Der Nutzer 12 kann über sein Geheimnis 20 der geschützten Ausführungsumgebung 28 seine Identität beweisen. In der wird dann aus dem Geheimnis 20 eine Ableitung oder Abbildung vorgenommen und mit der Abbildung 26 verglichen. Wenn diese übereinstimmen ist die Identität des Nutzers 12 bewiesen. Somit findet eine gegenseitige Authentifizierung statt.

Somit ist eine sichere Verbindung zwischen dem Nutzer 12 und der geschützten

Ausführungsumgebung 28 via der sicheren Benutzerschnittstelle 30 und mit Unterstützung des Backends 18 aufgebaut. Weder der Nutzer 12 noch das mobile Endgerät 14 müssen dauerhaft mit dem Backend 18 in Verbindung stehen. Es genügt theoretisch eine einmalige Verbindung, zum Beispiel über das Internet oder während der Produktion, um diese sichere Verbindung vorzubereiten.

Nach dem Aufbau dieser Verbindung kann die eigentliche Interaktion, wie eine Kommunikation oder die Übertragung von Daten oder Befehlen, stattfinden. Dazu interagiert der Nutzer 12 mit einem sicheren Element 32 des mobilen Endgeräts 14, welches mit der geschützten

Ausführungsumgebung 28 eine sichere Verbindung aufweist. Diese Interaktion läuft wie zuvor beschrieben über die sichere Benutzerschnittstelle 30 und die geschützte

Ausführungsumgebung 28. Das sichere Element 32 ist eine Recheneinheit zum Beispiel mit einer zumindest rudimentären Java-Umgebung, auf der unterschiedliche Cardlets laufen, welche zum Beispiel Steuerungen oder Bereiche des Fahrzeugs 16 abbilden.

Die bidirektionale Verbindung zwischen dem sicheren Element 32 und der geschützten

Ausführungsumgebung 28 ist kryptographisch gesichert, zum Beispiel über ein Geheimnis 34, das oder dessen Ableitung sowohl in die sichere Benutzerschnittstelle 30 als auch in die geschützte Ausführungsumgebung 28 eingebracht wird. Denkbar ist eine symmetrische

Kryptographie, zum Beispiel mit symmetrischen pre-shared Schlüsseln, oder eine

asymmetrische Kryptographie, zum Beispiel mit privaten und öffentlichen Schlüsseln.

Aufgrund der sicheren Übertragung von Daten zwischen dem sicheren Element 32 und der geschützten Ausführungsumgebung 28 über das Geheimnis 34 können die Vorteile einer geschützte Ausführungsumgebung 28 mit der eines sicheren Elements 34 kombiniert werden. Die vertrauenswürdige Benutzerschnittstelle 30 mit ihrer geschützten Ausführungsumgebung 28 mit der Manipulationssicherheit des sicheren Elements 32. Erst wenn der Bedienwunsch des Nutzers 12 über eine beidseitig authentifizierte Relation Kunde zu geschützter

Ausführungsumgebung 28 erfolgt ist, wird dies über den sicheren Pfad zwischen der geschützten Ausführungsumgebung 28 und dem sicheren Element 32 an das sichere Element 32 gemeldet. Das sichere Element 32 kann nun zum Beispiel in einem bestimmten Zeitfenster Anfragen von einem Programm 36 in einem Betriebssystem 38 entgegen nehmen, das für sich dem sicheren Element 32 seine Identität nicht beweisen kann. Anders ausgedrückt erlaubt man Apps oder Programmen 36 den authentischen Zugriff auf das sichere Element 32 dadurch, dass zuvor eine authentische Benutzereingabe an der geschützten Ausführungsumgebung 28 erfolgt sein muss, die diesen Status gesichert an das sichere Element 32 weitergibt.

Das sichere Element 32 ist mit einer Schnittstelle 40, wie zum Beispiel einem NFC Controller verbunden. Das Fahrzeug 16 hat eine entsprechende Schnittstelle 42, so dass diese beiden Entitäten miteinander kommunizieren können. Das Fahrzeug 16 hat zudem mindestens ein Steuergerät 44, das zur Steuerung der Schnittstelle 42 beziehungsweise der Kommunikation und/oder der Steuerung weiterer Funktionen des Fahrzeugs 16 dienen kann.

Im Folgenden wird beschrieben wie die Verbindung zwischen dem sicheren Element 32 und dem Fahrzeug 16 geschützt ist. Hier ist ein Schlüssel 46 in dem Backend 18 erstellt sowie ein durch eine Ableitung erstellter abgeleiteter Schlüssel 48 vorhanden. Wie in Figur 1 gezeigt, wird nur das abgeleitete Geheimnis oder der abgeleitete Schlüssel 48 in das sichere Element 32 des mobilen Endgerätes 14 Kunden eingebracht. Das Fahrzeug 16 bekommt allerdings das Ursprungsgeheimnis oder den Schlüssel 46 eingebracht. Die Idee ist hier, dass sich das Fahrzeug 16 den abgeleiteten Schlüssel 48 im Rahmen des Authentisierungsvorganges selbst ad-hoc herleiten kann. Dazu muss die im Backend 18 verwendete Konstante zur Ableitung des abgeleiteten Schlüssels 48 von dem Schlüssel 46 zusätzlich in das sichere Element 32 eingebracht werden. Die Schlüsselableitungsfunktion liefert bei Eingabe dieser Konstante und des Schlüssels 46 immer eindeutig zum Ergebnis den abgeleiteten Schlüssel 48. Diese Konstante muss bei jedem Authentisierungsvorgang zwischen dem sicheren Element 32 und dem Fahrzeug 16 im Klartext vom sicheren Element 32 an das Fahrzeug 16 gesendet werden. Das Fahrzeug 16 kann sich daraufhin ad-hoc den abgeleiteten Schlüssel 48 herleiten, da der Schlüssel 46 bekannt ist. Nach Herleitung kann das Fahrzeug 16 den Authentisierungsbeweis vom sicheren Element 32 mit dem abgeleiteten Schlüssel 48 verifizieren und somit das sichere Element 32 authentifizieren. Der Vorteil dieser Idee liegt darin, dass das Fahrzeug 16 nur den Schlüssel 46 persistieren muss. Selbst wenn eine Vielzahl verschiedener mobiler Endgeräte gesicherte Verbindungen zum Fahrzeug 16 herstellen sollen, ist nur der Schlüssel 46 im Fahrzeug 16 zu speichern. Wie beschrieben hat jedes sichere Element 32 eine unterschiedliche einzigartige Konstante wie einen Byte String, die es dem Fahrzeug 16 bei der Authentisierung mitteilt, sodass sich dieses daraufhin den entsprechenden abgeleiteten Schlüssel 48 herleiten kann. Somit kann eine Interaktion des sicheren Elements 32 mit der weiteren Instanz beziehungsweise dem Fahrzeug 16 über die oben beschriebene gesicherte Verbindung stattfinden. Zum Beispiel kann eine Sequenz zum Öffnen des Fahrzeugs 16 mittels eines Challenge-Response-Verfahrens durchgeführt werden.

Das Programm 36 kann eine Proxy-Funktion 50 umfassen, die es dem Programm 36 erlaubt, über das sichere Element 32 gesichert mit dem Fahrzeug 16 zu kommunizieren. Dazu werden zum einen die abgeleiteten Schlüssel 48 verwendet und zum anderen kann vorgesehen sein, dass wie zuvor beschrieben, das Programm 36 und/oder das Fahrzeug 16 an einer

Kommunikation mit dem sicheren Elemente 32 nur teilnehmen dürfen, wenn durch den Nutzer 12 oder die geschützte Ausführungsumgebung 28 eine entsprechende Freigabe oder Vorgabe erfolgt ist.

Als weiteres Sicherheitselement ist die gesicherte authentische Verbindung zwischen dem Programm 36 und dem Backend 18 vorgesehen. Hierfür wird wie in Figur 1 gezeigt ein Geheimnis 52 verwendet, das im Backend 18 generiert und an das sichere Element 32 übertragen wird. Über das Geheimnis 52 kann das Programm 36 Daten von dem sicheren Element 32 verschlüsseln und/oder signieren lassen und anschließend zu dem Backend 18 senden, zum Beispiel per Mobilfunk wie LTE oder per WLAN zum Beispiel über das Internet. Diese Verbindung kann auch bidirektional ausgelegt sein.

Allein die sichere bidirektionale Kommunikation zwischen dem sicheren Element 30 und der geschützten Ausführungsumgebung 28 kann beispielsweise zahlreiche Angriffe verhindern und das generelle Sicherheitsniveau erhöhen. Für eine besonders sicherheitskritische Funktion, wie zum Beispiel die Verwendung des mobilen Endgeräts 14 als digitalen Fahrzeugschlüssel zum Beispiel über BTLE (Bluetooth Low Energy), werden im Folgenden exemplarisch drei mögliche Angriffe und deren Abwehr durch das beschriebene System und Verfahren erklärt.

In einem ersten Fall hat ein Angreifer Malware auf dem mobilen Endgerät 14 des Nutzers 12 installiert. Der Angreifer begibt sich nun in BTLE-Reichweite zum Fahrzeug 16 des Nutzers und lässt die Malware auf dem mobilen Endgerät 14 das Entriegeln-Kommando ausführen. Nun lässt sich der Angreifer von der Malware den Funkbefehl zum Entriegeln der Türen zumailen. Schließlich kann der Angreifer von seinem Smartphone das Entriegeln-Kommando per BTLE zum Fahrzeug 16 senden und sein Smartphone sich somit als korrekter Schlüssel ausgeben. Die hier vorgeschlagene sichere Übertragungskette kann das obige Szenario verhindern. Eine App-Oberfläche mit Entriegeln-Buttons liegt im sicheren Bereich, das heißt dem sicheren Element 32 und/oder der geschützten Ausführungsumgebung 28. Eine Bedienung des sicheren Bereiches ist nur über die sichere Benutzerschnittstelle 30 möglich. Nur wenn die Bedienung über die sichere Benutzerschnittstelle 30 erfolgt, wenn diese an den sicheren Bereich angebunden ist, wird ein Signal oder Bit gesetzt. Dieses Bit wird authentisch von der geschützten Ausführungsumgebung 28 zu dem sicheren Element 32 übermittelt. Das sichere Element 32 berechnet nur dann eine Response auf die Challenge von dem Fahrzeug 16, wenn es kurz zuvor ein von der der geschützten Ausführungsumgebung 28 authentisch übermitteltes Bit erhalten hat.

In einem zweiten Fall meldet sich der Nutzer 12 mit einer App an einem Dienst an, um

Schlüssel zu verwalten. Ein Angreifer hat Malware auf dem mobilen Endgerät 14 installiert und schneidet die Zugangsdaten des Nutzers 12, wie zum Beispiel die E-Mail Adresse, das

Passwort und eine Super-PIN, mit. Dann loggt sich der Angreifer im Namen des Nutzers 12 bei dem Dienst ein und schickt Fahrzeugschlüssel an sein eigenes Smartphone. Schließlich stiehlt der Angreifer das Fahrzeug 16 des Nutzers 12.

Die hier vorgeschlagene sichere Übertragungskette kann auch dieses Szenario verhindern. Der Nutzer 12 muss sich bei der Registrierung zu dem Dienst einmalig beim Dienstanbieter verifizieren lassen. In diesem Kontext wählt sich der Nutzer 12 ein individuelles Datum 22 aus, zum Beispiel ein selbst gezeichnetes Bild. Dieses wird vom Händler über eine eigene

Backendverbindung in die Backendsysteme 18 übertragen und für den Nutzer 12 gespeichert. Bei der Provisionierung des mobilen Endgeräts 14 wird diese Grafik in die geschützte

Ausführungsumgebung 28 des mobilen Endgeräts 14 übertragen. Wenn der Nutzer 12 sich in die App des Dienstes einloggt, wird der Login-Screen über die sichere Benutzerschnittstelle 30 dargestellt. Damit der Nutzer 12 dies weiß, wird seine individuelle Grafik angezeigt. Der Nutzer 12 kann nun E-Mail und Kennwort eingeben, aber keine Malware kann diese Daten

mitschneiden, da sie über die sichere Benutzerschnittstelle 30 eingegeben werden, die in der geschützten Ausführungsumgebung 28 ein getrennten und sicheren Speicherbereich hat.

In einem dritten Fall hat ein Angreifer Malware auf dem mobilen Endgerät 14 installiert. Der Angreifer nutzt das sichere Element 32 als Orakel, um möglichst viele Challenge/Response Paare zu sammeln. Wenn der Angreifer genügend Paare gesammelt hat, begibt sich zum Fahrzeug 16 und entriegelt es. Die hier vorgeschlagene sichere Übertragungskette kann auch dieses Szenario verhindern. Hier kann zum Beispiel eine Eigenschaft der drahtlosen Übertragung zwischen dem mobilen

Endgerät 14 und dem Fahrzeug 16 genutzt werden. Zum Beispiel hat ein NFC-System den Vorteil, dass ein Cardlet einer zumindest rudimentären Java-Umgebung unterscheiden kann, ob eine Anfrage von dem Host OS oder einer Antenne stammt. Um ein äquivalentes

Sicherheitsniveau bei BTLE zu erreichen, müssten die geschützte Ausführungsumgebung 28 und das sichere Element 32 authentisch und vertraulich miteinander Daten austauschen können, was hier gegeben ist. Somit würde man nur den Zugriff auf das sicheren Element 32 durch die geschützten Ausführungsumgebung 28 erlauben. Und die geschützte

Ausführungsumgebung 28 muss sich dem sicheren Element 32 gegenüber authentisiert haben (und umgekehrt). Nutzt man dies mit der sicheren Benutzerschnittstelle 30, also dem Schalten des Touchscreens in die Secure World, kann nur nach erfolgter Interaktion mit der eigentlichen App ein Trigger erfolgen. Und jeglicher Trigger durch Software, also Malware im Host OS kann von dem sicheren Element 32 abgelehnt werden, da er nicht über die geschützte

Ausführungsumgebung 28 erfolgt ist.

Wie zuvor gezeigt, fügt die Erfindung mobile Endgeräte in ein ganzheitliches Sicherheitsmodell zur Kommunikation mit einem Backend und Fahrzeugen ein, so dass eine sichere

Übertragungskette entsteht, welche die Sicherheit verbessert.

Bezugszeichenliste

System

Nutzer

mobiles Endgerät

weitere Instanz

Backend

Geheimnis

individuelles Datum

Datenbank

Abbildung

geschützte Ausführungsumgebung sichere Benutzerschnittstelle

sicheres Element

Geheimnis

Programm

Betriebssystem

Schnittstelle

Schnittstelle

Steuergerät

Schlüssel

abgeleiteter Schlüssel

Proxy

Geheimnis