-
Die Erfindung betrifft ein Verfahren zum Einrichten eines Containers zur Aufnahme von Software, insbesondere eines virtuellen Secure Element, in einem Chip eines mobilen Endgeräts.
-
Unter einem mobilen Endgerät wird ein Mobiltelefon, Smartphone oder ähnliches Endgerät mit der Fähigkeit, über ein Mobiltelefonnetz zu kommunizieren, verstanden.
-
Das mobile Endgerät enthält einen Mikroprozessor-Chip, durch den die elektronischen Funktionalitäten des Endgeräts bereitgestellt werden. Im Chip ist unter anderem zumindest ein Betriebssystem implementiert.
-
Zur Nutzeridentifizierung und Authentisierung bei der Kommunikation mit dem mobilen Endgerät über das Mobilfunknetz wird ein Secure Element verwendet. Z. B. im GSM Mobilfunksystem wird als Secure Element die baulich vom Endgerät getrennte, entfernbare (plug-in) Chipkarte SIM-Karte (SIM = Subscriber Identity Module) verwendet. Im 3G-Mobilfunksystem wird als Secure Element die USIM (Universal SIM) verwendet, implementiert in der zur SIM-Karte analogen UICC (Universal Integrated Circuit Card). Daneben existieren in Endgeräten festimplementierte Secure Elements. Zudem werden virtuelle Secure Elements vorgeschlagen, bei denen das Secure Element als Software im Chip des mobilen Endgeräts implementiert ist.
-
Unter der Bezeichnung Trustzone Architektur ist eine zweigeteilte Laufzeit-Architektur für ein Mikroprozessorsystem bekannt, die zwei Laufzeitumgebungen umfasst. Eine erste, „Normal Zone” oder „Normal World” genannte unsichere Laufzeitumgebung ist durch ein Normalbetriebssystem gesteuert. Eine zweite, „Trustzone” oder „Trusted World” oder „Secure World” genannte gesicherte oder vertrauenswürdige Laufzeitumgebung ist durch ein Sicherheitsbetriebssystem gesteuert.
-
Das Normalbetriebssystem kann beispielsweise ein gängiges Betriebssystem wie Android, Windows Phone, Symbian oder dergleichen sein.
-
Durch die Anmelderin der vorliegenden Patentanmeldung wird ein Sicherheitsbetriebssystem für in mobile Endgeräte implementierte oder zu implementierende Chips hergestellt. Insbesondere sicherheitskritische Applikationen und manche Peripherie-Funktionen (z. B. Tastaturtreiber) werden durch das Sicherheitsbetriebssystem auf sichere Weise gesteuert. Applikationen unter dem Sicherheitsbetriebssystem werden auch als Trustlets bezeichnet, in Anlehnung an die Begriffe „Trust” (Vertrauen) und „Applet”.
-
WO-2011/115407-A2 offenbart ein Verfahren zum Laden eines virtuellen Secure Element (embedded UICC, umfassend eine international mobile subscriber identity IMSI, von einem Operatornetzwerk in ein mobiles Endgerät. Dabei erzeugt ein Schlüsselverwaltungsserver, z. B. ein Verkäufer des virtuellen Secure Element oder ein Endgeräte-Hersteller, unter Verwendung einer gerätespezifischen Idenfitikationsnummer MID (machine identifier) des Endgeräts Sicherheits-Schlüssel für die Datenübertragung vom Operatornetzwerk zum Endgerät. Das Operatornetzwerk erzeugt eine IMSI und überträgt sie unter Verwendung der Sicherheits-Schlüssel an das Endgerät.
-
WO-2010/027765-A2 beschreibt ein mobiles Endgerät mit einem in einer entfernbaren Chipkarte (UICC) integrierten Secure Element, z. B. einer virtuellen SIM-Karte. Die Chipkarte UICC hat mehrere isolierte Domänen, darunter eine Herausgeber-Domäne (UICC issuer domain) des Herausgebers der Chipkarte, sowie mehrere remote user Domänen, in welchen Dritte, autorisiert durch die Herausgeber-Domäne, eigene Applikationen abspeichern und ausführen können. Die Herausgeber-Domäne ist den remote user Domänen hierarchisch übergeordnet. Somit kann ein Zugriff Dritter auf die remote user Domänen nur erfolgen, wenn der Dritte durch die Herausgeber-Domäne zum Zugriff autorisiert ist. Dem Inhaber einer übergeordneten Domäne, also z. B. der Herausgeber-Domäne, kann dabei weiter der Zugriff auf untergeordnete Domänen, die Dritten zugewiesen, verwehrt sein, so dass also der autorisierte Dritte, nicht der Herausgeber, die Kontrolle über die in seiner eigenen Domäne abgespeicherten Inhalte hat. Die isolierten Domänen sind dabei in einer entfernbaren Chipkarte des Endgeräts vorgesehen, nicht direkt im Endgerät.
-
-
Die Global Platform Organisation hat sich weiter in diversen Dokumenten mit dem delegierten Laden von Inhalten in Chipkarten beschäftigt. Das Dokument
„Global Platform Card Specification, Version 2.1.1, March 2003" (kurz „GP2.1.1") beschreibt in Kapitel 6.5 das Konzept des delegated management für Chipkarten. Demzufolge werden in einer Chipkarte Sicherheitsdomänen für Applikationsanbieter angelegt, innerhalb derer die jeweiligen Applikationsanbieter autorisiert vom Herausgeber der Chipkarte Applikationen selbst verwalten können, insbesondere laden und löschen. In dem GP Dokument
„Global Platform System: Messaging Specification for Management of Mobile-NFC Services, Version 1.0 Draft, Draft for Public Review, December 2010, Document Reference: GPS_SPE_002" werden in Kapitel 1.5.2 drei Varianten des delegierten Ladens von Inhalten in Secure Elements (auch Embedded Secure Elements, Kapitel 1.4) für mobile Endgeräte vorgeschlagen, darunter der Dual Mode, demzufolge innerhalb eines begrenzten Bereichs des Secure Element die Karteninhaltsverwaltung (Card Contents Managment CCM) vollständig an einen autorisierten Dritten, nämlich den Trusted Service Mager TSM, delegiert ist.
-
Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren zu schaffen, um in einem Chip eines mobilen Endgeräts einen abgegrenzten Container zur Aufnahme von Software zu erzeugen, in dem ein autorisierter Dritter unabhängig vom Erzeuger des Containers Software verwalten kann, insbesondere Software laden und Software aktualisieren. Insbesondere, aber nicht nur, soll als Container ein virtuelles Secure Element geschaffen werden. Als Software können z. B. Applikationen vorgesehen sein. Unter einem Container wird hierbei eine abgegrenzte Sicherheits-Domäne im Chip verstanden.
-
Die Aufgabe wird gelöst durch ein Verfahren nach Anspruch 1. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angegeben.
-
Das Verfahren nach Anspruch 1 ist zum Einrichten eines Containers zur Aufnahme von Software in einem Chip eines mobilen Endgeräts eingerichtet. Der Container wird durch einen Endgeräteherausgeber erzeugt. Der Endgeräteherausgeber ist nicht notwendig, und sogar in der Regel nicht der Endgerätehersteller oder Original Equipment Manager OEM. Der Herausgeber ist beispielsweise ein Hersteller oder Verkäufer von körperlichen und/oder virtuellen Secure Elements. In den Container soll später eine Software-Anbieter, beispielsweise ein Trusted Service Manger, Software laden können.
-
Das Verfahren zeichnet sich dadurch aus, dass durch den Endgeräteherausgeber (also z. B. Secure Element Hersteller oder Verkäufer)
- – unter Verwendung eines für das Endgerät spezifischen Containerschlüssels ein Container in dem mobilen Endgerät erzeugt wird; und
- – unter Verwendung des Containerschlüssels ein Herausgeber-Verwaltungsschlüssel zur Verwaltung von Software innerhalb des Containers autorisiert wird;
und dass weiter durch den Software-Anbieter aus dem Herausgeber-Verwaltungsschlüssel ein Anbieter-Verwaltungsschlüssel abgeleitet wird, der vor dem Herausgeber geheim gehalten ist, und mit dem der Anbieter Software innerhalb des Containers verwalten kann.
-
Dadurch, dass der Container mit dem für das Endgerät spezifischen Containerschlüssel erzeugt wird, ist er sicher an das Endgerät gebunden. Bedarfsweise wird der Containerschlüssel für die Containererzeugung vorab von einem Endgerätehersteller OEM an den Endgeräteherausgeber übermittelt, und zudem beim Endgerätehersteller vorab der Containerschlüssel im Endgerät implementiert. Dadurch, dass der Herausgeber-Verwaltungsschlüssel zur Verwaltung von Software mit dem an das Gerät gebundenen Containerschlüssel autorisiert wird, ist auch die Softwareverwaltung sicher an das Endgerät gebunden. Dadurch, dass der Software-Anbieter aus dem Herausgeber-Verwaltungsschlüssel einen Anbieter-Verwaltungsschlüssel ableitet, der vor dem Endgeräteherausgeber geheim gehalten ist, kann der Software-Anbieter losgelöst vom Herausgeber Software in den Container laden. Der Software-Anbieter hat also die Schlüsselgewalt über den Container erlangt.
-
Somit ist gemäß Anspruch 1 ein Verfahren geschaffen, um in einem Chip eines mobilen Endgeräts einen abgegrenzten Container zur Aufnahme von Software zu erzeugen, in dem ein autorisierter Dritter, nämlich der Software-Anbieter, unabhängig vorn Erzeuger des Containers, nämlich dem Endgeräteherausgeber, Software verwalten kann.
-
Die Autorisierung des einen Schlüssels durch den anderen wird z. B. durch Verknüpfung der Schlüssel erzeugt, z. B. durch Erstellen eines Zertifikats. Wahlweise wird der Container folgendermaßen mit dem Containerschlüssels in dem mobilen Endgerät erzeugt wird: unter Verwendung des Containerschlüssels wird ein Herausgeber-Verwaltungsschlüssel zur Verwaltung von Software innerhalb des Containers autorisiert, und der Container wird unter Verwendung des autorisierten Herausgeber-Verwaltungsschlüssels erzeugt. Hierbei wird also der Containerschlüssel mittelbar zur Container-Erzeugung verwendet, nämlich indem mit dem Containerschlüssel der Herausgeber-Verwaltungsschlüssel autorisiert wird, mit dem dann der Container erzeugt wird. Falls die Autorisierung durch Verknüpfung von dem Containerschlüssel und Herausgeber-Verwaltungsschlüssel erfolgt, wird der Container mit dem Ergebnis der Verknüpfung erzeugt.
-
Als Software können insbesondere Applikationen vorgesehen sein. Als Verwaltung kann insbesondere Laden, Aktualisieren, Löschen von Software, z. B. Applikationen, vorgesehen sein.
-
Wahlweise verwaltet weiter, nachdem der Container erzeugt ist, der Software-Anbieter unter Verwendung des Anbieter-Verwaltungsschlüssels Software, insbesondere ein oder mehrere Applikationen, in dem Container, z. B. lädt er Software wie z. B. Applikationen in den Container aktualisiert oder löscht sie.
-
Die Verwaltung der Software im Container kann insbesondere wahlweise über die Luftschnittstelle erfolgen, also over the air OTA.
-
Wahlweise wird als Container ein virtuelles Secure Element des Endgeräts erzeugt. Dadurch, dass der Software-Anbieter das erfindungsgemäß erzeugte virtuelle Secure Element (Container) unabhängig verwalten kann, kann das virtuelle Secure Element wie ein körperliches Secure Element, z. B. SIM-Karte, an den Software-Anbieter verkauft werden und künftig nur noch durch den Software-Anbieter, z. B. Trusted Service Manager TSM, verwaltet werden, um z. B. bedarfsweise Software wie z. B. Algorithmen innerhalb des virtuellen Secure Element zu aktualisieren.
-
Gemäß einer ersten, asymmetrischen Alternative erzeugt der Software-Anbieter ein Public-Private-Schlüsselpaar, umfassend einen öffentlichen Schlüssel und einen privaten Schlüssel, einer Public-Key-Infrastruktur übermittelt und den öffentlichen Schlüssel an den Endgeräteherausgeber. Dabei wird als Herausgeber-Verwaltungsschlüssel der öffentliche Schlüssel verwendet und als Anbieter-Verwaltungsschlüssel der private Schlüssel verwendet. Dadurch, dass der private Schlüssel einer PKI-Infrastruktur als Anbieter-Verwaltungsschlüssel verwendet wird, kennt der Endgeräteherausgeber den Anbieter-Verwaltungsschlüssel nicht, und dennoch ist der Anbieter-Verwaltungsschlüssel automatisch für den Container autorisiert, da er über die PKI-Infrastruktur mit dem öffentlichen Schlüssel verbunden ist.
-
Gemäß einer zweiten, symmetrischen Alternative erzeugt der Endgeräteherausgeber einen ersten symmetrischen Schlüssel und übermittelt ihn an den Software-Anbieter. Dabei wird der erste symmetrische Schlüssel als Herausgeber-Verwaltungsschlüssel verwendet, und als Anbieter-Verwaltungsschlüssel wird ein durch den Software-Anbieter ausgewählter zweiter symmetrischer Schlüssel verwendet, wobei durch den Software-Anbieter der zweite symmetrische Schlüssel durch den ersten symmetrischen Schlüssel autorisiert wird. Hierbei ist der zweite symmetrische Schlüssel dadurch vor dem Endgeräteherausgeber geheim, dass er durch den Software-Anbieter frei ausgewählt wird und geheimgehalten wird. Da der erste symmetrische Schlüssel mit dem Containerschlüssel autorisiert worden ist, führt die Autorisierung des zweiten symmetrischen Schlüssels mit dem ersten Schlüssel zu einer hierarchischen Unterautorisierung des zweiten symmetrischen Schlüssels auf Grundlage des Containerschlüssels. Hierbei wird vorausgesetzt, dass die Autorisierung des ersten symmetrischen Schlüssels mit dem Containerschlüssel eine hierarchische Unterautorisierung zulässt.
-
Wahlweise sind in dem Chip des Endgeräts implementiert:
- – ein Normalbetriebssystem, z. B. ein herkömmliches Rich OS, das zum Erzeugen und Unterhalten einer unsicheren Laufzeitumgebung eingerichtet ist, und
- – ein Sicherheitsbetriebssystem, Sicherheits-OS, das zum Erzeugen und Unterhalten einer gesicherten Laufzeitumgebung eingerichtet ist,
und wobei der Container in der gesicherten Laufzeitumgebung eingerichtet wird.
-
Wahlweise wird als Containerschlüssel ein Aktivierungsschlüssel zur Aktivierung der gesicherten Laufzeitumgebung, z. B. für das Sicherheitsbetriebssystem, verwendet.
-
Wahlweise wird in dem Chip eine Mehrzahl von voneinander isolierten Containern erzeugt, z. B. für mehrere Software-Anbieter, oder/und z. B. für mehrere virtuelle Secure Elements.
-
Ein erfindungsgemäßer Chip für ein mobiles Endgerät ist gekennzeichnet:
durch einen Container, der zur Aufnahme von Software eingerichtet ist, und der mit einem für das Endgerät spezifischen Containerschlüssel erzeugt ist,
durch ein Schlüsselverwaltungssystem für den Container, das einen Herausgeber-Verwaltungsschlüssel zur Verwaltung von Software innerhalb des Containers umfasst, wobei der Herausgeber-Verwaltungsschlüssel unter Verwendung des Containerschlüssels autorisiert ist, und
durch einen von einem Software-Anbieter aus dem Herausgeber-Verwaltungsschlüssel abgeleiteten Anbieter-Verwaltungsschlüssel, der vor dem Herausgeber geheim gehalten ist, und mit dem der Anbieter Software innerhalb des Containers verwalten kann.
-
Im Folgenden wird die Erfindung an Hand von Ausführungsbeispielen und unter Bezugnahme auf die Zeichnung näher erläutert, in der zeigen:
-
1 eine asymmetrische Alternative eines erfindungsgemäßen Verfahrens;
-
2 eine symmetrische Alternative eines erfindungsgemäßen Verfahrens.
-
1 zeigt eine asymmetrische Alternative eines erfindungsgemäßen Verfahrens. In einem vorbereitenden Schritt 0 sendet ein Endgeräteherausgeber MEI ein Sicherheitsbetriebssystem zur Implementierung in ein Endgerät ME an einen Endgerätehersteller OEM. Der Endgerätehersteller OEM implementiert das Sicherheitsbetriebssystem im Endgerät ME, erzeugt in einem Hardware Security Module HSM unter Verwendung der Endgeräteseriennummer des Endgeräts ME einen Aktivierungsschlüssel K.SP.AuthDevice und implementiert ihn in einem Schritt 1 in das Endgerät ME, um das Sicherheitsbetriebssystem zu aktivieren. Der Endgerätehersteller OEM sendet in einem Schritt 2 den erzeugten Aktivierungsschlüssel K.SP.AuthDevice an den Endgeräteherausgeber MEI. In einem Schritt VKC, der an unterschiedlichen Stellen im Verfahrensablauf erfolgen kann, einigen sich ein Software-Anbieter TSM und der Endgeräteherausgeber MEI über den Verkauf eines Containers C vom Endgeräteherausgeber MEI an den Software-Anbieter TSM, mit dem Ziel, dass der Software-Anbieter TSM in dem Container C, unabhängig vom Endgeräteherausgeber MEI, TSM-eigene Software verwalten kann. Der Container C ist beispielsweise ein virtuelles Secure Element, das wie eine körperliche SIM-Karte vom MEI an den TSM verkauft und vollständig übertragen werden soll. In einem Schritt 3 erzeugt der Software-Anbieter TSM zwei Schlüssel einer PKI, nämlich einen öffentlichen Schlüssel (public key) PuK.SP und eine privaten Schlüssel (private key) PrK.SP und sendet den öffentlichen Schlüssel PuK.SP an den Endgeräteherausgeber MEI. In einem Schritt 4 autorisiert der Endgeräteherausgeber MEI mit dem Aktivierungsschlüssels K.SP.AuthDevice den empfangenen öffentlichen Schlüssel PuK.SP für das Endgerät ME, zur Verwaltung von Software im Container C auf dem Endgerät ME. Genauer verknüpft der Endgeräteherausgeber MEI den empfangenen öffentlichen Schlüssel PuK.SP mit dem Aktivierungsschlüssels K.SP.AuthDevice des spezifischen Endgeräts ME und übermittelt ihn an das Endgerät ME. In einem Schritt 5 erzeugt der Endgeräteherausgeber MEI unter Verwendung des mit dem öffentlichen Schlüssel Puk.SP verknüpften Aktivierungsschlüssels K.SP.AuthDevice im Endgerät ME einen Container C zur Aufnahme von Software, z. B. das virtuelle Secure Element. Da der private Schlüssel PrK.SP mit dem öffentlichen Schlüssel PuK.SP über die PKI verknüpft ist, kann nun der Software-Anbieter ohne weiters mit dem privaten Schlüssel PrK.SP Software im Container C verwalten. Da der private Schlüssel PrK.SP definitionsgemäß geheim ist, ist er insbesondere vor dem Endgeräteherausgeber MEI geheim, so dass der Software-Anbieter TSM unabhängig vom Endgeräteherausgeber MEI den Container C verwalten kann.
-
2 zeigt eine symmetrische Alternative eines erfindungsgemäßen Verfahrens. Schritte 0, 1 und 2 erfolgen wie bei 1 beschrieben. In einem Schritt 3 erzeugt der Endgeräteherausgeber MEI einen ersten symmetrischen Schlüssel K.SP.Auth1 und autorisiert ihn mit dem gerätespezifischen Aktivierungsschlüssel K.SP.AuthDevice für das Endgerät ME, indem er die beiden Schlüssel verknüpft. In einem Schritt 4 erzeugt der Endgeräteherausgeber MEI mit dem mit dem Aktivierungsschlüssel K.SP.AuthDevice verknüpften symmetrischen Schlüssel K.SP.Auth1 im Endgerät ME einen Container C. In einem Schritt 5 übermittelt der Endgeräteherausgeber MEI den autorisierten ersten symmetrischen Schlüssel K.SP.Auth1 an den Software-Anbieter TSM. Der Software-Anbieter wählt beliebig einen zweiten symmetrischen Schlüssel K.SP.Auth2 aus und autorisiert ihn mit dem ersten symmetrischen Schlüssel K.SP.Auth1. Nun kann der Software-Anbieter mit dem zweiten symmetrischen Schlüssel K.SP.Auth2 Software im Container C verwalten, z. B. laden, aktualisieren oder löschen.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- WO 2011/115407 A2 [0008]
- WO 2010/027765 A2 [0009]
-
Zitierte Nicht-Patentliteratur
-
- „Global Platform Device Technology: TEE System Architecture, Version 0.4, Public Review Draft October 2011, Document Reference: GPD_SPE_009” beschreibt ein mobiles Endgerät mit einer normalen oder unsicheren Ausführungsumgebung „Rich Execution Environment (REE)” und einer sicheren Ausführungsumgebung „Trusted Execution Environment (TEE)” (vgl. Kapitel 1) [0010]
- „Global Platform Card Specification, Version 2.1.1, March 2003” (kurz „GP2.1.1”) beschreibt in Kapitel 6.5 [0011]
- „Global Platform System: Messaging Specification for Management of Mobile-NFC Services, Version 1.0 Draft, Draft for Public Review, December 2010, Document Reference: GPS_SPE_002” werden in Kapitel 1.5.2 drei Varianten des delegierten Ladens von Inhalten in Secure Elements (auch Embedded Secure Elements, Kapitel 1.4) [0011]
