SOWIE VERFAHREN

TECHNISCHES GEBIET DER ERFINDUNG

Die Erfindung bezieht sich auf eine Universal Integrated Chip Card, UICC, bevorzugt ein Teilnehmeridentitätsmodul, ein Verfahren zur Verwaltung wenigstens eines Profils einer solchen UICC und auf ein in einer solchen UICC ausführbar installiertes Computerprogramm-Produkt.

Zur Nutzung von Diensten eines Kommunikationsnetzes enthält ein Endgerät, beispielsweise ein Mobilfunktelefon oder ein Maschine-zu-Maschine-Gerät, englisch: Machine-to-Machine-Device, kurz M2M-Gerät, oder ein Gerät zur Nutzung von Technologien des Intemets-der-Dinge, englisch: Internet-of-Things, kurz: loT, eine UICC. Der Begriff „UICC“ wird in dieser Beschreibung synonym zu den Begriffen „eUICC“, „Teilnehmeridentitätsmodul“, „Chipkarte“, „iUICC“, „Integrated eUICC“, „Integrated Secure Element“, „embedded Secure Element“, „Secure Element“ oder „SIM“ verwendet. Die UICC umfasst in der Regel eine oder mehrere Profile, die dazu eingerichtet ist/sind, die UICC oder ein Gerät, in dem die UICC betrieben wird, gegenüber dem Kommunikationsnetz, beispielsweise einem Mobilfunk Netzwerk, zu authentisieren.

TECHNISCHER HINTERGRUND

Die UICC umfasst in der Regel ein oder mehrere Profile, die dazu eingerichtet ist/sind, die UICC oder ein Gerät, in dem die UICC betrieben wird, gegenüber dem Kommunikationsnetz, beispielsweise einem Mobilfunk Netzwerk, zu authentisieren. Auf der UICC kann in der Regel höchstens ein Profil zu einem bestimmten Zeitpunkt aktiv sein.

Insbesondere wenn mehrere solcher Profile auf einer UICC vorhanden sind, besteht der Bedarf, diese Profile zu verwalten.

Aus der Druckschrift EP 3 108 674 Bl ist beispielsweise ein sicheres Element bekannt, das mit zwei virtuellen Profilen versehen ist und ein erstes Basisband und ein zweites Basisband umfasst. Das erste virtuelle Profil und das erste Basisband bilden ein erstes Paar, das eindeutig mit einem ersten logischen Kommunikationskanal verbunden ist. Das zweite virtuelle Profil und das zweite Basisband bilden ein zweites Paar, das eindeutig mit einem zweiten logischen Kommunikationskanal verbunden ist. Das sichere Element umfasst eine Kommunikationskomponente, die so konfiguriert ist, dass sie eingehende Daten, die über die physische Kommunikations Schnittstelle empfangen werden, demultiplexiert und ausgehende Daten, die über die physische Kommunikationsschnittstelle gesendet werden, multiplexiert. Aus der Druckschrift EP 3 080 960 B 1 ist ein weiteres sicheres Element bekannt, welches eine Vielzahl an emulierten bzw. virtuellen Profilen umfasst. Eine Kommunikationskomponente des sicheren Elements kann einen Befehl empfangen, der einen Identifikator umfasst, mittels welchem das Profil, das das Ziel des Befehls ist, eindeutig identifizierbar ist. Die Kommunikationskomponente fungiert dabei als Multiplexer/Demultiplexer für diese Befehle.

Die zuvor genannten aus dem Stand der Technik bekannten Verwaltungen sicherer Elemente basieren auf logischen Kanälen. Diese auf logischen Kanälen basierenden Verwaltungen sind jedoch aufwändig in der Umsetzung, im Betrieb und im Support, insbesondere wenn eine Verwaltung benötigt wird, welche mit der GSMA Spezifikation in Einklang ist.

Aus der Druckschrift US 2019 / 0034 662 Al aus dem Stand der Technik ist ein sicheres Element bekannt, welches mehrere als Kontexte gestaltete Profile mit darin enthaltenen Applets aufweist, sowie ein spezielles System-Profil. Generell ist es nur Applets aus demselben Kontext erlaubt Zugriff aufeinander auszuüben. Das System-Profil hat die Berechtigung auf ein Applet eines gewöhnlichen Kontext bzw. Profils zuzugreifen, sofern das Applet ein Shareable-Interface aufweist.

Aus der Druckschrift DE 102018 001 565 Al aus dem Stand der Technik ist ein sicheres Element bekannt, welches mehrere Partitionen aufweist.

Aus der Druckschrift US 8 196 131 Bl aus dem Stand der Technik ist ein sicheres Element bekannt, das in ein Kontaktlosgerät wie beispielweise eine NFC-SIM-Karte integriert ist, und das mehrere Applikationen aufweist, die als Karten-Applikation (und hierbei beispielsweise als Banking- Applikation), PPSE-Directory- Applikation oder Control-Software- Applikation gestaltet sind, und wobei die Applikationen jeweils ein Schnittstellenobjekt, Shareable Interface Object, aufweisen, wobei das Schnittstellenobjekt der Karten-Applikation (Banking- Applikation) und das Schnittstellenobjekt der Control-Software- Applikation miteinander kommunizieren.

ZUSAMMENFASSUNG DER ERFINDUNG

Der Erfindung liegt die Aufgabe zugrunde, eine UICC und ein Verfahren zu schaffen, mit welchen es in einfacher und sicherer Weise möglich ist, Profile der UICC in einfacher Weise zu verwalten, und welche mit der GSMA Spezifikation in Einklang sind.

Die Aufgabe wird durch die in den unabhängigen Patentansprüchen beschriebenen Merkmale gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angegeben. Erfindungsgemäß wird eine UICC, bevorzugt ein Teilnehmeridentitätsmodul, vorgeschlagen, welches wenigstens ein Profil und eine Subskriptionsverwaltung umfasst, wobei das oder jedes Profil einen Zustand aufweist, der aktiv oder inaktiv ist. Das wenigstens eine Profil weist ferner ein freigebbares Schnittstellenobjekt (englisch: shareable interface object, SIO) auf, welches der Subskriptionsverwaltung den Zugriff auf jedes Profil unabhängig von dem Zustand des jeweiligen Profils ermöglicht.

Ein Schnittstellenobjekt, SIO, ist bevorzugt ein Objekt zum Implementieren einer Schnittstellenfunktionalität des Profils auf der UICC. Das Schnittstellenobjekt ist freigebbar (=shareable), es können andere Instanzen, insbesondere die Subskriptionsverwaltung, mittels dieses Objekts auf jedes Profil zugreifen.

Mittels eines SIO kann eine Subskriptionsverwaltung ungeachtet eines Zustands eines Profils auf das Profil zugreifen. Das Profil kann dabei aktiv sein oder inaktiv sein. Das SIO ermöglicht es, dass die Subskriptionsverwaltung nicht nur auf Elemente eines aktivierten Profils zugreifen, sondern sie kann mittels der SIO auch auf Elemente eines inaktiven Profils zugreifen.

Ein Profil ist insbesondere im Zustand aktiv (=enabled, activated, active), wenn die im Profil enthaltenen Subskriptionsdaten aktuell verwendet werden, um sich in ein Mobilfunknetz einzubuchen.

Ein Profil ist insbesondere im Zustand inaktiv (=disabled, non-activated, non-active), wenn die im Profil enthaltenen Subskriptionsdaten aktuell nicht verwendet werden, um ein Endgerät, in dem die UICC betriebsbereit eingebracht ist, in ein Mobilfunknetz einzubuchen.

Ein Profil ist ein in der UICC zugewiesener Speicherbereich (Container, Slot). In dem Profil werden unter anderem Subskriptionsdaten (Berechtigungsdaten, Netzzugangsdaten, Network Access Credential Daten, Credentials) abgelegt, die es einem Benutzer (Teilnehmer) erlauben, Dienste, wie Sprach- und/oder Datendienste, eines Mobilfunknetzwerks zu verwenden. Die Verwendung dieser Dienste wird nach einem erfolgreichen Einbuchen in das Mobilfunknetzwerk ermöglicht.

Zum Einbuchen in ein Mobilfunknetzwerk werden Subskriptionsdaten eines aktiven Profils verwendet, um einen Benutzer (Teilnehmer) eines Endgeräts, in dem die UICC betriebsbereit eingebracht ist, an dem Mobilfunknetz eindeutig zu identifizieren und/oder zu authentifizieren.

Gemäß einer bevorzugten Ausgestaltung der UICC ist die Subskriptionsverwaltung eine Anwendung der UICC zum Verwalten der Profile einer UICC. Die Subskriptionsverwaltung kann ein Root Issuer Security Domain (ISD-R) sein. Dabei ist besonders bevorzugt, dass die Subskriptionsverwaltung ein Root Issuer Security Domain (ISD-R) gemäß der Spezifikation GSM SGP.22, insbesondere gemäß der Spezifikation GSM SGP.22 in der Version 2.3 vom 30 Juni 2021 ist.

Vorzugsweise ist das freigebbare Schnittstellenobjekt ein Bootstrap Issuer Security Domain Profile (ISD-P) innerhalb des Profils. Ein Bootstrap ist ein Ladeprogramm, auch als Urlader oder Lader bezeichnet. Dabei ist besonders bevorzugt, dass die Bootstrap Issuer Security Domain Profile (ISD-P) ein Issuer Security Domain Profile (ISD-P) gemäß der Spezifikation GSM SGP.22, insbesondere gemäß der Spezifikation GSM SGP.22 in der Version 2.3 vom 30 Juni 2021 ist.

Gemäß einer bevorzugten Ausgestaltung der UICC umfasst das wenigstens eine Profil einen Installationsverwalter (englisch: Installer), der in ein Systemregister (englisch: System Registry) eintragbar (schreibbar) ist, wobei vorzugsweise der Installationsverwalter durch das freigebbare Schnittstellenobjekt in das Systemregister eintragbar ist.

Gemäß einer bevorzugten Ausgestaltung der UICC umfasst das wenigstens eine Profil einen Löschungsverwalter (englisch: Deletion Manager), der in ein Systemregister (englisch: System Registry) eintragbar ist, wobei vorzugsweise der Löschungsverwalter durch das freigebbare Schnittstellenobjekt in das Systemregister eintragbar ist.

Gemäß einer bevorzugten Ausgestaltung der UICC umfasst das wenigstens eine Profil einen Installationsverwalter (englisch: Installer) und einen Löschungsverwalter (englisch: Deletion Manager), die jeweils in ein Systemregister (englisch: System Registry) eintragbar sind, wobei vorzugsweise der Installationsverwalter und der Löschungsverwalter durch das freigebbare Schnittstellenobjekt in das Systemregister eintragbar sind.

Ein Systemregister kann die Global Registry sein. Bevorzugt ist das Systemregister eine Global Registry gemäß der Spezifikation GSM SGP.22, insbesondere gemäß der Spezifikation GSM SGP.22 in der Version 2.3 vom 30 Juni 2021 ist.

Ein Systemregister kann die Local Registry sein. Bevorzugt ist das Systemregister eine Local Registry gemäß der Spezifikation GSM SGP.22, insbesondere gemäß der Spezifikation GSM SGP.22 in der Version 2.3 vom 30 Juni 2021 ist.

Ein Systemregister kann ein Register des Endgeräts sein. Ein Systemregister kann ein Register des Mobilfunknetzwerkes sein. Vorzugsweise umfasst das wenigstens eine Profil eine weitere Issuer Security Domain Profile (ISD-P). Dabei ist besonders bevorzugt, dass das weitere Issuer Security Domain Profile (ISD-P) ein Issuer Security Domain Profile (ISD-P) gemäß der Spezifikation GSM SGP.22, insbesondere gemäß der Spezifikation GSM SGP.22 in der Version 2.3 vom 30 Juni 2021 ist.

Die UICC weist beispielsweise ein Dateisystem auf, wie es in der 3GPP TS 11.11 oder der 3GPP TS 11.14 beschrieben ist. Das Dateisystem weist Dateien, bspw. Elementary Files, EF, auf. Ein EF beinhaltet Kopfdaten und Hauptdaten und kommt in drei Arten vor: Transparent EF, Linear Fixed EF und Cyclic EF. Das Dateisystem der UICC umfasst beispielsweise Dedicated Files, DF, die Kopfdaten mit einer hierarchischen Struktur von Elementardateien, EF, auf der UICC aufweisen. DFs haben keine eigenen Daten. Man kann sich ein DF vorstellen wie eine Verzeichnisstruktur. Das Dateisystem der UICC weist mindestens eine Masterdatei, Master File, MF, auf und stellt die Stammdatei im UICC-Dateisystem dar.

Bei einer UICC im Sinne der Erfindung handelt es sich beispielsweise um ein in Baugröße und Ressourcenumfang reduziertes elektronisches Modul, welches eine Steuereinheit (Mikrocontroller) und mindestens eine Schnittstelle (Datenschnittstelle) zur Kommunikation mit dem Gerät aufweist. Diese Kommunikation erfolgt bevorzugt über ein Verbindungsprotokoll, insbesondere einem Protokoll gemäß dem Standard ETSI TS 102 221 bzw. ISO-7816.

Bei UICC-Bauformen, die als integriertes System auf einem Chip, System on Chip, kurz SoC, realisiert sind, wie der „iUICC“, „Integrated eUICC“, „Integrated SE“ oder dem „Integrated TRE“, erfolgt die Kommunikation über einen SoC internen Bus. Die UICC weist einen internen oder externen sicheren nicht- flüchtigen Speicherbereich auf, in dem Teilnehmeridentitätsdaten und Authentisierungsdaten sicher eingebracht sind, um Manipulation- und/oder Missbrauchsversuche bei der Identifizierung und/oder Authentisierung am Netzwerk zu verhindern.

Die UICC kann in einer Ausgestaltung mittels eines Geräts betriebsfähig sein, wobei die UICC in dieser Ausgestaltung bis auf Versorgungssignale, wie Versorgungs Spannung, Takt, Reset etc. autark ist.

Der Begriff „UICC“ ist synonym zum Begriff „eUICC“, „Teilnehmeridentitätsmodul“, „Chipkarte“, „iUICC“, „Integrated eUICC“, „Integrated Secure Element“, „embedded Secure Element“, „Secure Element“ oder „SIM“. Bei der UICC handelt es sich beispielsweise um eine Chipkarte oder eine SIM-Karte oder ein Teilnehmeridentitätsmodul. Die UICC dient dazu, mit den im sicheren nicht-flüchtigen Speicherbereich gespeicherten maschinenlesbaren Teilnehmeridentitätsdaten einen Teilnehmer in einem Kommunikationsnetz zu identifizieren und für das Nutzen von Diensten zu authentifizieren. Unter UICC zu verstehen sind auch USIM, TSIM, ISIM, CSIM oder R-UIM. So ist beispielsweise eine UICC als eine USIM Anwendung in der ETSI TS 131 102 definiert. So ist beispielsweise eine UICC als eine SIM Anwendung in der ETSI TS 151 011 definiert. So ist beispielsweise eine UICC als eine TSIM Anwendung gemäß ETSI TS 100 812 definiert. So ist beispielsweise eine UICC als eine ISIM Anwendung gemäß ETSI TS 131 103 definiert. So ist beispielsweise eine UICC als eine CSIM Anwendung gemäß 3GPP2 C.S0065- B definiert. So ist beispielsweise eine UICC als eine R-UIM Anwendung gemäß 3GPP2 C.S0023- D definiert.

Die UICC kann ein integraler Bestandteil innerhalb des Geräts sein, beispielsweise ein fest verdrahteter elektronischer Baustein. Derartige UICC werden auch als eUICC bezeichnet. In dieser Bauform sind diese UICC nicht für eine Entnahme aus dem Gerät vorgesehen und können prinzipiell nicht einfach ausgetauscht werden. Derartige UICC können auch als embedded Secure Elements ausgestaltet sein und sind eine sichere Hardwarekomponente im Gerät.

Die UICC kann auch eine Softwarekomponente in einem vertrauenswürdigen Teil eines Betriebssystems, einer sogenannten Trusted Execution Environment, kurz TEE, des Gerätes sein. Die UICC ist beispielsweise innerhalb einer gesicherten Laufzeitumgebung in Form von darin ablaufenden Programmen, sogenannten „Trustlets“, ausgebildet.

Die UICC kann auch ein integraler Bestandteil eines größeren integrierten Schaltkreises, beispielsweise eines Modems oder Applikationsprozessors sein. Derartige UICC werden als „integrated UICC“, „integrated TRE“, „integrated eUICC“ oder „Integrated SE“ bezeichnet. Derartige UICC werden als integrierter Prozessorblock in ein SoC fest integriert und können über einen chipinternen Bus angebunden werden.

Die UICC kann der Fernüberwachung, -kontrolle und -Wartung von Geräten wie Maschinen, Anlagen und Systemen dienen. Sie kann für Zähleinheiten wie Stromzähler, Warmwasserzähler etc. verwendet werden. Die UICC ist beispielsweise Bestandteil der Technologie des loT.

Bevorzugt wird hier der Begriff „Endgerät“ verwendet, wobei das Endgerät in der Kommunikationstechnik vorrangig ein „Terminal“ sein kann. Das schließt nicht aus, dass ein „Endgerät“ ein „Gerät“ in einer anderen Technik sein kann. Die Begriffe „Endgerät“ und „Gerät“ werden synonym verwendet.

Bei einem Gerät im Sinn der Erfindung handelt es sich prinzipiell um ein Gerät oder eine Gerätekomponente mit Mitteln zur Kommunikation mit einem Kommunikationsnetz, um Dienste des Kommunikationsnetzes nutzen zu können oder um Dienste eines Servers über ein Gateway des Kommunikationsnetzes nutzen zu können. Beispielsweise ist ein mobiles Gerät wie ein Smart Phone, ein Tablet-PC, ein Notebook, ein PDA unter den Begriff zu fassen. Als Gerät können auch Multimedia- Geräte wie digitale Bilderrahmen, Audiogeräte, Fernsehgeräte, E-Book-Reader verstanden werden, die ebenfalls Mittel zur Kommunikation mit dem Kommunikationsnetzwerk aufweisen.

Insbesondere ist das Gerät in einer Maschine, einem Automaten und/oder einem Fahrzeug eingebracht. Ist das Gerät in einem Kraftfahrzeug eingebracht, besitzt es typischerweise eine integrierte UICC. Die UICC kann über das Gerät, etwa mittels eines Modems des Geräts, eine Datenverbindung zu einem Server über das Kommunikationsnetz aufbauen. Mit dem Gerät kann beispielsweise ein Server des Geräte-Herstellers kontaktiert werden, um Steuereinheiten, z.B. ECUs (ECU = Electronic Control Unit) für Funktionalitäten des Geräts anzusprechen. Über die UICC lässt sich ein Server im Hintergrundsystem des Mobilfunknetz-Betreibers, MNO, kontaktieren, beispielsweise ein Server, um Aktualisierungen für Software, Firmware oder/und Betriebssystem der UICC in die UICC zu laden.

Ein Kommando ist dabei eine Anweisung, ein Befehl oder eine Instruktion, die vom Gerät gesendet wird. Das Kommando ist bevorzugt ein Kommando gemäß ETSI TS 102 221 bzw. ISO/IEC 7816 Standard. Es kann dabei einen Kommandokopf und einen Kommandokörper aufweisen.

Bevorzugt umfasst die UICC ein Betriebssystem, das ausführbar in dem Datenspeicher abgelegt ist und eingerichtet ist, die Schritte der Steuereinheit durchzuführen.

In einem weiteren Aspekt wird ein Verfahren zum Verwalten wenigstens eines Profils einer UICC, bevorzugt eines Teilnehmeridentitätsmoduls gemäß der Erfindung, vorgeschlagen. Das Verfahren umfasst die Schritte:

Erhalten eines Befehls, der der Durchführung einer Operation an einem Profil entspricht;

Bestimmen des Zustands des Profils;

Aufrufen einer Funktion des freigebbaren Schnittstellenobjektes zur Durchführung der Operation an dem Profil, wenn der Zustand des Profils inaktiv ist.

Gemäß einer bevorzugten Ausgestaltung des Verfahrens erfolgt ein Aufruf einer Funktion des Profils zur Durchführung der Operation an dem Profil, wenn der Zustand des jeweiligen Profils aktiv ist.

Vorzugsweise umfasst die Operation ein Aktivieren des Profils, ein Deaktivieren des Profils, ein Erstellen des Profils, ein Löschen des Profils, ein Aktivieren eines mit dem Profil verknüpften Anwendungspakets und/oder ein Deaktivieren des mit dem Profil verknüpften Anwendungspakets .

Gemäß einer bevorzugten Ausgestaltung wird das Verfahren durch eine Betriebssystem-Routine der UICC ausgeführt.

Die Erfindung betrifft ferner ein Computerprogramprodukt ausführbar installiert in einer UICC und aufweisend Mittel zum Ausführen der Verfahrens schritte des erfindungsgemäßen Verfahrens.

Die UICC ist beispielsweise dazu eingerichtet, eine logische Datenverbindung zu einem Server des Kommunikationsnetzes aufzubauen, um Dienste des Servers oder eines anderen Servers zu nutzen und Daten auszutauschen. Beim Aufbau einer derartigen Datenverbindung von einer UICC zu einem Server werden Verbindungsparameter, beispielsweise eine eindeutige Server-Adresse und das zu verwendende Datenverbindungs-Protokoll benötigt. Zum Aufbau, Abbau und Betrieb einer Datenverbindung wird beispielsweise ein Karten-Applikations-Werkzeugkasten, englisch Card Applikation Toolkit, kurz CAT, des Teilnehmeridentitätsmoduls gemäß dem ETSI Standard TS 102 223 verwendet.

Ein Kommunikationsnetz ist eine technische Einrichtung, auf der die Übertragung von Signalen unter Identifizierung und/oder Authentisierung des Teilnehmers stattfindet. Das Kommunikationsnetz bietet eigene Dienste an (eigene Sprach- und Datendienste) und/oder ermöglicht das Nutzen von Diensten von externen Instanzen. Das Kommunikationsnetz ist bevorzugt ein Mobilfunknetz. Eine Gerät-zu-Gerät Kommunikation unter Aufsicht des Kommunikationsnetzes ist dabei möglich. Insbesondere wird hier ein Mobilfunknetz beispielsweise das „Global System for Mobile Communications”, kurz GSM als Vertreter der zweiten Generation oder das „General Packet Radio Service”, kurz GPRS bzw. „Universal Mobile Telecommunications System”, kurz UMTS als Vertreter der dritten Generation, das „Long Term Evolution”, kurz LTE, als Vertreter der vierten Generation als Mobilfunknetz verstanden oder ein Mobilfunknetz der 5. Generation mit dem derzeitigen Arbeitstitel „5G“ als ein Kommunikationsnetz verstanden. Die Kommunikation im Kommunikationsnetz kann über einen sicheren Kanal erfolgen, beispielsweise so, wie es in den technischen Standards ETSI TS 102 225 und/oder ETSI TS 102226 definiert ist, beispielsweise SCP80, SCP81 oder eine Transport-Layer- Security, TLS.

Erfindungsgemäß ist ein Server eine räumlich von dem Gerät entfernte Instanz. Der Server kann ein Teil des Kommunikationsnetzes sein. Alternativ oder zusätzlich ist der Server eine externe Instanz (also keine Instanz des Kommunikationsnetzes). Der Server ist bevorzugt ein Server des Geräte-Herstellers, um Steuereinheiten, z.B. ECUs (ECU = Electronic Control Unit), für Funktionalitäten des Geräts anzusprechen. Alternativ oder zusätzlich ist der Server ein Server zur Fernverwaltung der eUICC, beispielsweise ein sogenannter OTA-Server, um Aktualisierungen für Software, Firmware oder/und Betriebssystem des eUICC in das eUICC zu laden.

Teilnehmeridentitätsdaten (=Subskriptionsdaten), so wie sie beispielsweise im nicht-flüchtigen Speicherbereich der UICC abgelegt sind, sind beispielsweise Daten, die einen Teilnehmer (eine Person oder ein Gerät) eindeutig im Kommunikationsnetz identifizieren. Dazu zählt beispielsweise eine Teilnehmerkennung, beispielsweise International Mobile Subscriber Identity, kurz IMSI oder Subscription Permanent Identifier, SUPI und/oder teilnehmerspezifische Daten. Die IMSVSUPI ist das in einem Mobilfunkkommunikationsnetzwerk eindeutige Teilnehmeridentitätsdatei. Zudem sind Teilnehmeridentitätsdaten beispielsweise Parameter und/oder Daten, die es ermöglichen, dass sich ein Teilnehmer eindeutig am Kommunikationsnetz authentifizieren kann, beispielsweise ein Authentisierungsalgorithmus, spezifische Algorithmus-Parameter, ein kryptografischer Authentisierungsschlüssel Ki und/oder ein kryptografischer Over-The-Air, kurz OTA, Schlüssel. Zudem sind Teilnehmeridentitätsdaten beispielsweise Daten, die einen Teilnehmer eindeutig an einem Dienst (=Service) authentisieren, beispielsweise eine eindeutige Kennung oder Signatur. Ein Dienst ist insbesondere ein Sprachdienst oder ein Datendienst eines Servers, mit dem Informationen und/oder Daten über das Kommunikationsnetzwerk übertragen werden.

Die UICC kann betriebsbereit in das Gerät eingebracht sein. Die Kommunikation zwischen UICC und Gerät basiert auf einem Verbindungsprotokoll. Das Gerät kann zusätzlich zudem auch dazu eingerichtet sein, eigenständig eine Datenverbindung zu dem räumlich entfernten Server aufzubauen, um ebenfalls dessen Dienste zu nutzen und mit diesem Server Daten au szu tau sehen.

KURZE BESCHREIBUNG DER FIGUREN

Nachfolgend werden anhand von Figuren die Erfindung bzw. weitere Ausführungsformen und Vorteile der Erfindung näher erläutert, wobei die Figuren lediglich Ausführungsbeispiele der Erfindung beschreiben. Gleiche Bestandteile in den Figuren sind mit gleichen Bezugszeichen versehen. Die Figuren sind nicht als maßstabsgetreu anzusehen, insbesondere können einzelne Elemente der Figuren übertrieben groß bzw. übertrieben vereinfacht dargestellt sein.

Fig. 1 zeigt ein Zustandsdiagramm einer UICC mit einer Vielzahl an Profilen gemäß einem Ausführungsbeispiel der Erfindung;

Fig. 2a zeigt ein Diagramm eines Anwendungsbündels, welches wenigstens ein Profil der UICC umfasst;

Fig. 2b zeigt ein Diagramm für eine erfindungsgemäße Profilverwaltung; Fig. 3 zeigt ein Ausführungsbeispiel eines Systems aus Netzwerk, Gerät und erfindungsgemäßer UICC;

Fig. 4 zeigt ein Ausführungsbeispiel einer erfindungsgemäßen UICC;

Fig. 5 zeigt ein weiteres Ausführungsbeispiel einer erfindungsgemäßen UICC;

Fig. 5a zeigt ein weiteres Ausführungsbeispiel einer erfindungsgemäßen UICC; und

Fig. 6 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens in einer UICC.

DETAILLIERTE BESCHREIBUNG VON AUS FÜHRUNGS BEISPIELEN

Fig. 1 zeigt ein Zu Standsdiagramm einer UICC 1 mit einer Vielzahl an Profilen 173a-c gemäß einem Ausführungsbeispiel der Erfindung. Die Vielzahl an Profilen 173a-c wird anhand eines erfindungsgemäßen Verfahrens verwaltet. In Fig. 1 sind beispielhaft ein erstes Profil 173a, ein zweites Profil 173b und ein drittes Profil 173c dargestellt. Jedes Profil 173a-c weist jeweilige eigene Subskriptionsdaten. Die Subskriptionsdaten verschiedener Profile 173a-c können sich unterscheiden, sodass ein Teilnehmer unter Verwendung eines aktiven Profils 173a sich in ein erstes Mobilfunknetzwerk einbuchen kann und der Teilnehmer unter Verwendung eines aktiven Profils 173b sich in das erste Mobilfunknetzwerk oder in ein zweites Mobilfunknetzwerk einbucht.

Fig. 2a zeigt ein Diagramm eines Anwendungsbündels (englisch: Application Bundle), auch als Container oder Slot bezeichnet, welches wenigstens ein Profil der UICC umfasst. Das oder die Profile der UICC werden in der Regel in ein solches Anwendungsbündel installiert. Das Anwendungsbündel kann dabei eine (virtuelle) Laufzeitumgebung, insbesondere eine Javacard Laufzeitumgebung, JCRE (gemäß dem Standard Java Card Classic Edition) sein.

Die UICC kann mehrere Anwendungsbündel umfassen. Diese Anwendungsbündel sollen nach GSMA-Standard streng voneinander getrennt sein und sollen voneinander „abgeschirmte“ Anwendungen aufweisen. Ein Anwendungsbündel kann derart ausgestaltet sein, dass es keine eigenen Elemente einem anderen Anwendungsbündel exponiert (aufdeckt).

In Fig. 2a sind in dem Anwendungsbündel neben dem Profil noch beispielhaft ein GSM-Applet mit einem Dateisystem und Ereignisse (Events), ein Remote-File-Management, kurz RFM, Applet und weitere Applets gezeigt. Anwendungsbündel können als leere Anwendungsbündel auf der UICC vorinstalliert sein oder dynamisch mittels eines Aufrufes über eine Systemprogrammierschnittstelle (englisch: System API) erzeugt werden. Als System- API wird bevorzugt eine API der UICC verstanden.

Fig. 2b zeigt ein Diagramm für eine erfindungsgemäße Profilverwaltung. Dabei sind die Profile 173a-c jeweils mit App-Modul-Klassenladem ausgestattet, um auf Applet-Modul-Klassen zuzugreifen. Dabei sind die Profile 173a-c jeweils mit Bibliotheks-Klassenladem ausgestattet, um auf Bibliotheks-Klassen zuzugreifen. Dabei sind die Profile 173a-c jeweils mit SIO-Klassenladern ausgestattet, um auf SIO zuzugreifen. Auf ein Profil 173a-c kann dabei sowohl im aktiven Zustand als auch im inaktiven Zustand des Profils 173a-c zugegriffen werden, dank der SIO. Ein Bootstrap- ISD-P stellt diese SIO zur Verfügung, um eine Installation und Löschung von extern zu ermöglichen, ungeachtet vom Profilzu stand. Das Profil 173a-c führt die jeweilige Aktion (insbesondere Installation, Löschung) fernverwaltet von der Subskriptionsverwaltung ISD-R aus.

Fig. 3 zeigt ein Ausführungsbeispiel eines Systems bestehend aus einem Gerät 2 und einer erfindungsgemäßen UICC 1. In der UICC läuft das Verfahren gemäß Fig. 6 ab. Das Gerät 2 ist beispielsweise ein M2M-Gerät in einer loT Umgebung. Das Gerät 2 kann eine Mehrzahl von ECUs aufweisen, die hier nicht dargestellt sind. Durch diese ECUs werden die Funktionalitäten des Geräts 2 gesteuert. Wenn das Gerät 2 ein Kfz ist, könnten die ECUs Motorsteuerung, Getriebesteuerung, Klimasteuerung, und dergleichen sein.

Die UICC 1 ist betriebsbereit in das Gerät 2 eingebracht und wird vom Gerät 2 mit einer Versorgungsspannung Vcc und einem Takt CLK versorgt. Die UICC 1 ist in Fig. 3 detaillierter dargestellt. In Fig. 2 ist angedeutet, dass die UICC 1 einen Speicher 17 aufweist. In diesem Speicher 17 können Applets, ein Card Application Toolkit, CAT, Authentisierungsdatensätze 172 und eine Authentisierungsdatenverwaltung 171 abgelegt sein. Unterschiedliche APDU- Kommandos 11 können mittels der Applets, der CAT und dem Betriebssystem (nicht dargestellt) zwischen der UICC 1 und dem Gerät 2 ausgetauscht werden.

Das Gerät 2 umfasst beispielsweise - aber nicht zwingend - ein Modem 3. Das Modem 3 kann beispielsweise als eine logische Einheit zum Umsetzen von Daten zwischen der UICC 1 und einem Server 40 eines Netzwerks 4 angesehen werden. Das Gerät 2 kann durch das Modem 3 eine Kommunikationsverbindung 12 zur UICC 1 aufbauen. Die Kommunikation 12 zwischen dem Gerät 2 und der UICC 1 erfolgt gemäß den in der internationalen Normen ISO/IEC 7816-3 und ISO/IEC 7816-4 definierten Protokollen, auf die hiermit ausdrücklich Bezug genommen wird.

Der gesamte Datenaustausch zwischen der UICC 1 und dem Gerät 2 findet bevorzugt unter Verwendung von sogenannten APDUs (application protocol data units) gemäß der Norm ISO/IEC 7816-4 statt. Eine APDU stellt eine Dateneinheit der Anwendungsschicht dar, also eine Art Container, mit dem Kommandos und/ oder Daten an die UICC 1 übertragen werden. Man unterscheidet zwischen Kommando- APDUs, die von einem Gerät 2 an die UICC 1 gesendet werden, und Antwort- APDUs, die von der UICC 1 in Reaktion auf eine Kommando-APDU an das Gerät 2 gesendet werden.

Das Modem 3 ist eine Kommunikationseinheit des Geräts 2, um auch Daten des Geräts 2 oder der UICC 1 mit dem Kommunikationsnetz 4 und dem darin befindlichen Server 40 au szutau sehen. Die ausgetauschten Daten zwischen UICC 1 und Modem 3 können im Modem 3 in ein IP -basiertes Verbindungsprotokoll umgesetzt werden.

Fig. 4 zeigt ein Blockschaltbild einer erfindungsgemäßen UICC 1, vorzugsweise eine fest verdrahtete eUICC. Alternativ ist die UICC 1 ein portabler Datenträger mit einer anderen Bauform. Die UICC 1 hat ein Betriebssystem 15, in dem das Verfahren 100 gemäß Fig. 6 abläuft. Das Betriebssystem 15 ist beispielsweise ein natives Betriebssystem. Es ist zudem denkbar, dass das Betriebssystem 15 eingerichtet ist, eine Javacard Eaufzeitumgebung, JCRE, 16 zu betreiben, die sodann in dem Speicher 17 zusammen mit dem Betriebssystem 17 abgelegt ist.

Die UICC 1 ist dazu ausgestaltet mit dem Gerät 2 gemäß Fig. 3 Daten au szutau sehen. Zur Datenübertragung bzw. Kommunikation zwischen der UICC 1 und dem Gerät 2 weisen sowohl die UICC 1 als auch das Gerät 2 jeweils geeignete Kommunikations Schnittstellen 12 auf. Die Schnittstellen können beispielsweise so ausgestaltet sein, dass die Kommunikation zwischen diesen bzw. zwischen der UICC 1 und dem Gerät 2 galvanisch, d.h. kontaktbehaftet, verbunden werden. Die Kontaktbelegung ist in der ISO/IEC 7816 definiert. In einer nicht dargestellten Ausführungsform ist die Kommunikationsschnittstelle kontaktlos, beispielsweise gemäß einem RFID oder NFC oder WEAN Standard.

Die UICC 1 hat zudem eine zentrale Prozessor- bzw. Steuereinheit, CPU 19, die in Kommunikationsverbindung mit der Schnittstelle 12 steht. Zu den primären Aufgaben der CPU 19 gehören das Ausführen von arithmetischen und logischen Funktionen und das Fesen und Schreiben von Datenelementen, wie dies durch von der CPU 19 ausgeführten Programmcode definiert wird. Die CPU 19 steht ferner mit einem flüchtigen Arbeitsspeicher, RAM 18, und einem nichtflüchtigen wiederbeschreibbaren Speicher 17 in Verbindung. Vorzugsweise handelt es sich bei dem nichtflüchtigen Speicher 17 um einen Flash-Speicher (Flash-EEPROM). Dabei kann es sich beispielsweise um einen Flash-Speicher mit einer NAND- oder einer NOR- Architektur handeln. Bei der in Fig. 4 dargestellten bevorzugten Ausführungsform ist in dem nichtflüchtigen Speicher 17 der Programmcode gespeichert, der von der CPU 19 ausgeführt werden kann. Insbesondere kann in dem nichtflüchtigen Speicher 17 der Programmcode des Chipkarten-Betriebssystems, OS, 15, der Java Card Laufzeitumgebung, JCRE, 16 (bestehend aus Java Card Virtual Machine, JCVM und Java Card Application Programming Interfaces, JCAPI), Applikation 13 zur Authentisierungsdatenverwaltung sowie zumindest zwei Authentisierungsdatensätze 171a, 171b abgelegt sein. Dabei liegt eine Applikation vorzugsweise in Form von Java Card™ Applets vor. Zudem kann ein nicht gezeigtes CAT gemäß ETSI TS 102 223 eingebracht sein. Statt einer Applikation kann auch ein in nativem Code, etwa in C oder in Assembler geschriebenes Programmelement vorgesehen sein.

Fig. 5 zeigt ein weiteres Ausführungsbeispiel einer UICC 1, genauer eines Speicherbereichs 17 einer UICC 1. Der Speicherbereich 17 ist ein nichtflüchtiger Speicher, kann aber auch ein flüchtiger Speicher (RAM) sein. Der Speicherbereich 17 kann ein exklusiv zugewiesener Speicherbereich 17 sein, der Teil einer größeren Speichereinheit ist. Der Speicherbereich 17 kann ein Remote-Speicherbereich sein. Mit Speicherbereich 17 der UICC 1 wird ein Speicherbereich beschrieben, auf den die UICC 1 bzw. die Steuereinheit 19 der UICC exklusiv Zugriff hat. Die Zugriffsrechte auf den Speicherbereich 17, also das Lesen, Schreiben, Überschreiben, können in einer Sicherheitsdomäne (SD) definiert sein, sodass unterschiedliche Untereinheiten der UICC 1 auf unterschiedliche Bereiche des Dateisystems 175 Zugriff haben oder eben nicht.

Der Speicherbereich 17 der Fig. 5 hat beispielsweise (aber nicht zwingend) eine Subskriptionsverwaltung 174 (ISD-R), die verschiedene Subskriptionsprofile 173a-c verwalten kann. Mittels einer OTA- Kommunikation zwischen Servern 40 des Kommunikationsnetzes, beispielsweise Subskriptionsservem SM-SR oder Datenbereitstellungsservem SM-DP, SM-DP+ gemäß den GSMA Spezifikationen SGP.02 und SGP.22, kann ein Profil 173 a-c verwaltet werden, wozu beispielsweise SMS, CAT_TP oder HTTPS für die Over-The-Air, OTA, Kommunikation mit der UICC 1 verwendet wird. Dieses Profilverwalten - das nicht Teil dieser Beschreibung ist - umfasst das „Erstellen“, „Laden“, „Aktivieren“, „Deaktivieren“, „Löschen“ und „Aktualisieren“. Für Details wird auf die genannten GSMA-Spezifikationen verwiesen.

Ein Profil 173a-c weist Profil-Daten auf. Beispielsweise kann eine der folgenden Komponenten als Profil-Datei pro Profil 173a-c vorhanden sein: eine MNO-Sicherheitsdomäne (MNO-SD) mit den OTA-Schlüsselsätzen von OTA-Servem; mindestens ein Authentisierungsparameter (Ki, OP, RAND, SGN) oder zumindest ein Verweis 176 (Pointer oder Adresse) auf einen entsprechenden Eintrag 172 im Dateisystem 175 der UICC 1; eine Netzwerkzugriffsanwendung, Richtlinienregeln; ein profilspezifisches Dateisystem beinhaltend DFs, EFs für das jeweilige Profil 173a-c; Verbindungsparameter des Profils; Anwendungen; eine Teilnehmerkennung, IMSI, eine Teilnehmeridentitätsmodulkennung ICCID und ggf. Profilaktualisierungen.

Die UICC 1 umfasst gemäß dem Ausführungsbeispiel wenigstens ein Profil 173a-c, insbesondere eine Vielzahl an Profilen 173a-c und eine Subskriptionsverwaltung 174, wobei das oder jedes Profil 173a-c einen Zustand aufweist, der aktiv oder inaktiv ist. Das wenigstens eine Profil 173a- c weist ferner ein freigebbares Schnittstellenobjekt SIO auf, welches der Subskriptionsverwaltung 174 den Zugriff auf jedes Profil 173a-c unabhängig von dem Zustand des jeweiligen Profils 137a- c ermöglicht.

Die Subskriptionsverwaltung 174 kann ein Root Issuer Security Domain (ISD-R) sein, vorzugsweise eine ein Root Issuer Security Domain (ISD-R) gemäß der Spezifikation GSM SGP.22, insbesondere gemäß der Spezifikation GSM SGP.22 in der Version 2.3 vom 30 Juni 2021 sein.

Das freigebbare Schnittstellenobjekt SIO kann ein Bootstrap Issuer Security Domain Profile (ISD-P) innerhalb des Profils 173a-c sein, vorzugsweise ein Bootstrap Issuer Security Domain Profile (ISD-P) gemäß der Spezifikation GSM SGP.22, insbesondere gemäß der Spezifikation GSM SGP.22 in der Version 2.3 vom 30 Juni 2021 sein. Demgemäß kann das freigebbare Schnittstellenobjekt SIO ein Bootstrap ISD-P innerhalb des Profils 173a-c sein.

Das wenigstens eine Profil 173a-c kann einen Installationsverwalter und einen Löschungsverwalter umfassen, die jeweils in ein Systemregister eintragbar sind, wobei vorzugsweise der Installationsverwalter und der Löschungsverwalter über das freigebbare Schnittstellenobjekt SIO in das Systemregister eintragbar sind.

Das wenigstens eine Profil 173a-c kann ein weiteres Issuer Security Domain Profile (ISD-P) umfassen. Eine entsprechende mögliche Ausführungsform der Erfindung ist in Fig. 5a im Detail dargestellt, und in der Figurenbeschreibung zu Fig. 5a näher erläutert. Vorzugsweise ist das weitere Issuer Security Domain Profile (ISD-P) ein Issuer Security Domain Profile (ISD-P) gemäß der Spezifikation GSM SGP.22, insbesondere gemäß der Spezifikation GSM SGP.22 in der Version 2.3 vom 30 Juni 2021.

Die UICC 1 weist weiterhin eine Authentisierungsdatenverwaltung 171 auf. Diese kann in Form eines Java-Applets (siehe Fig. 3) ausführbar im Speicherbereich 17 der UICC 1 abgelegt sein. Die Datenverwaltung 171 kann auch nur als nativer Programmcode ausführbar im Speicherbereich 17 der UICC 1 abgelegt sein. Die Steuereinheit 19 führt die Authentisierungsdatenverwaltung 171 bei Bedarf aus. Weiterhin sind im Speicher 17 der UICC 1 Authentisierungsdatensätze 172 abgelegt. Beispielhaft sind zwei Authentisierungsdatensätze 172a und 172b dargestellt, die Anzahl ist aber nicht beschränkt. Ein Authentisierungsdatensatz 172 kann verschiedene Authentisierungsdaten umfassen. Dies ist in Fig. 4 beispielhaft dargestellt anhand des ersten Authentisierungsdatensatzes

172a. Er weist einen Authentisierungsalgorithmus (Milenage, TUAK) mit entsprechenden

Authentisierungsparametem, einen oder mehrere Authentisierungsschlüssel (CK, IK, Ki), ggf.,

Sequenzparameter (Zähler SGN-MS, SGN-HE, andere Zähler) und Authentisierungsaktualisierungen etc. auf. Neben den angeführten kann ein

Authentisierungsdatensatz 172 weitere Authentisierungsdaten enthalten. Die

Authentisierungsdaten sind bevorzugt, wie in Fig. 5 angedeutet, im Dateisystem 175 strukturiert abgelegt. Es können aber auch proprietäre Dateien erstellt werden, um die Authentisierungsdatensätze 172 abzulegen.

Mit einem Verweis 176 können die Authentisierungsdatensätze 172 einem jeweiligen Profil 173 zugeordnet werden. Dazu ist in einer Ausgestaltung der Erfindung im Dateisystem 175 ein Bereich definiert, in dem die aktivierten Authentisierungsdaten abgelegt werden. Ein Profil 173 greift dann auf diesen Bereich zu, um die UICC 1 beim Server 40 des Kommunikationsnetzes 4 zu authentisieren.

In einer anderen Ausgestaltung werden die Authentisierungsdaten nach dem in den jeweiligen Speicherbereich des Dateisystems geschrieben.

Implementierungsdetails dazu sind in den technischen Berichten TR 33.834 und TR 133.935 ausführlich beschrieben und auf die Implementierungen, insbesondere die Aktualisierung gemäß den Lösungen 4b und 5 wird hierin Bezug genommen. Werden Aktualisierungen empfangen, so werden sie mit Hilfe der Authentisierungsdatenverwaltung 171 in einen Speicherbereich der UICC abgelegt. Dazu wird entweder eine neue Datei bzw. eine neue Dateistruktur im Dateisystem 175 erstellt oder ein entsprechender Authentisierungsdatensatz 172 aktualisiert, z.B. überschrieben oder erweitert. Zudem kann ein Verweis 176 auf die Authentisierungsdaten aktualisiert werden, beispielsweise indem eine Speicheradresse aktualisiert, ein Pointer aktualisiert oder das aktualisierte Authentisierungsdatum in den entsprechenden Bereich des Profils kopiert wird. Es kann immer nur ein Authentisierungsdatensatz aktiviert sein, sodass die UICC 1 gegenüber dem Kommunikationsnetz eine eindeutige Authentisierung vornimmt.

Die Datensätze sind beispielsweise in EF-Dateien der UICC 1 abgelegt sein. Alternativ oder zusätzlich können die Authentisierungsdaten in Datenobjekten, beispielsweise in Datenobjekten der UICC 1, abgelegt sein. Alternativ oder zusätzlich können die Authentisierungsdaten in reservierten Speicherbereichen des Betriebssystems, OS, der UICC abgelegt sein. Diese verschiedenen Ablageorte bedingen möglicherweise eine Veränderung der Struktur der Datensätze.

Die Datensätze können also entsprechend ihres Ablageorts in verschieden strukturierten Datensätzen 172a, 172b abgelegt sein. Die Authentisierungsdatenverwaltung 171 ist insbesondere dazu eingerichtet, die abgelegten Authentisierungsdaten, insbesondere die Datensätze 172a, 172b der Authentisierungsdaten, jeweils entsprechend umzu strukturieren und anzupassen, um sie einerseits für eine bestimmungsgemäße Authentisierung verwendet zu können und um sie andererseits an dem gewünschten Ablageort abzulegen.

Das Verfahren gemäß dem Ausführungsbeispiel dient zum Verwalten wenigstens eines Profils 173a-c einer UICC 1 nach dem Ausführungsbeispiel. Das Verfahren umfasst die Schritte:

- Erhalten 101 eines Befehls, der der Durchführung einer Operation an einem Profil 173a-c entspricht;

- Bestimmen 102 des Zustands des Profils 173a-c;

- Aufrufen 103 einer Funktion des freigebbaren Schnittstellenobjekt SIO zur Durchführung der Operation an dem Profil 173a-c, wenn der Zustand des Profils 173a-c inaktiv ist.

Ein Aufruf 104 einer Funktion des Profils 173a-c zur Durchführung der Operation an dem Profil 173a-c kann erfolgen, wenn der Zustand des jeweiligen Profils 173a-c aktiv ist.

Die Operation kann ein Aktivieren des Profils 173a-c, ein Deaktivieren des Profils 173a-c, ein Erstellen des Profils 173a-c, ein Löschen des Profils 173a-c, ein Aktivieren eines mit dem Profil 173a-c verknüpften Anwendungspakets und/oder ein Deaktivieren des mit dem Profil 173a-c verknüpften Anwendungspakets umfassen.

Gemäß einer bevorzugten Ausgestaltung kann das Verfahren 100 durch eine Betriebssystem- Routine der UICC 1 ausgeführt werden.

Fig. 5a zeigt ein weiteres Ausführungsbeispiel einer UICC 1, genauer eines Speicherbereichs 17 einer UICC 1.

Der Speicherbereich 17 ist ein nichtflüchtiger Speicher, kann aber auch ein flüchtiger Speicher (RAM) sein. Der Speicherbereich 17 kann ein exklusiv zugewiesener Speicherbereich 17 sein, der Teil einer größeren Speichereinheit ist. Der Speicherbereich 17 kann ein Remote-Speicherbereich sein. Mit Speicherbereich 17 der UICC 1 wird ein Speicherbereich beschrieben, auf den die UICC 1 bzw. die Steuereinheit 19 der UICC exklusiv Zugriff hat. Die Zugriffsrechte auf den Speicherbereich 17, also das Lesen, Schreiben, Überschreiben, können in einer Sicherheitsdomäne (SD) definiert sein, sodass unterschiedliche Untereinheiten der UICC 1 auf unterschiedliche Bereiche des Dateisystems 175 Zugriff haben oder eben nicht.

Der Speicherbereich 17 der Fig. 5a hat beispielsweise (aber nicht zwingend) eine Subskriptionsverwaltung 174 (ISD-R), die verschiedene, jeweils über eine Issuer Security Domain Profile (ISD-P) angebundene Subskriptionsprofile 173a-c verwalten kann. Mittels einer OTA- Kommunikation zwischen Servern 40 des Kommunikationsnetzes, beispielsweise Subskriptionsservern SM-SR oder Datenbereitstellungsservern SM-DP, SM-DP+ gemäß den GSMA Spezifikationen SGP.02 und SGP.22, und unter Verwendung von in der Subskriptionsverwaltung 174 ISD-R vorgehaltener Schlüssel zur Profilverwaltung, kann eine Issuer Security Domain Profile (ISD-P), und damit ein Profil 173 a-c verwaltet werden, wozu beispielsweise SMS, CAT_TP oder HTTPS für die Over- The- Air, OTA, Kommunikation mit der UICC 1 verwendet wird. Dieses Profilverw alten - das nicht Teil dieser Beschreibung ist - umfasst das „Erstellen“, „Laden“, „Aktivieren“, „Deaktivieren“, „Löschen“ und „Aktualisieren“. Für Details wird auf die genannten GSMA-Spezifikationen verwiesen.

Ein Profil 173a-c weist Profil-Daten auf, beispielsweise wie im Ausführungsbeispiel der Fig. 5 beschrieben. Beispielsweise kann eine der folgenden Komponenten als Profil-Datei pro Profil 173a-c vorhanden sein: eine MNO-Sicherheitsdomäne (MNO-SD) mit MNO-Schlüsseln von Servern desjenigen MNO, der Eigentümer des Profils ist, und mit einer Profil-Identität; mindestens ein Authentisierungsparameter (Ki, OP, RAND, SGN) oder zumindest ein Verweis 176 (Pointer oder Adresse) auf einen entsprechenden Eintrag 172 im Dateisystem 175 der UICC 1; eine Netzwerkzugriffsanwendung, Richtlinienregeln; ein profilspezifisches Dateisystem beinhaltend DFs, EFs für das jeweilige Profil 173a-c; Verbindungsparameter des Profils; Anwendungen; eine Teilnehmerkennung, IMSI, eine Teilnehmeridentitätsmodulkennung ICCID und ggf. Profilaktualisierungen.

Die UICC 1 umfasst gemäß dem Ausführungsbeispiel wenigstens eine Issuer Security Domain Profile (ISD-P) und ein dazu gehöriges Profil 173a-c, insbesondere eine Vielzahl an Issuer Security Domain Profilen (ISD-P) und Profilen 173a-c und eine Subskriptionsverwaltung 174, wobei das oder jedes Profil 173a-c einen Zustand aufweist, der aktiv oder inaktiv ist. Das wenigstens eine Profil 173a-c weist ferner ein freigebbares Schnittstellenobjekt SIO auf, welches der Subskriptionsverwaltung 174 den Zugriff auf jedes Profil 173a-c unabhängig von dem Zustand des jeweiligen Profils 137a-c ermöglicht. Die Subskriptionsverwaltung 174 kann ein Root Issuer Security Domain (ISD-R) sein, vorzugsweise eine ein Root Issuer Security Domain (ISD-R) gemäß der Spezifikation GSM SGP.22, insbesondere gemäß der Spezifikation GSM SGP.22 in der Version 2.3 vom 30 Juni 2021 sein.

Das freigebbare Schnittstellenobjekt SIO kann ein Bootstrap Issuer Security Domain Profile (ISD-P) innerhalb des Profils 173a-c sein, vorzugsweise ein Bootstrap Issuer Security Domain Profile (ISD-P) gemäß der Spezifikation GSM SGP.22, insbesondere gemäß der Spezifikation GSM SGP.22 in der Version 2.3 vom 30 Juni 2021 sein. Demgemäß kann das freigebbare Schnittstellenobjekt SIO ein Bootstrap ISD-P innerhalb des Profils 173a-c sein.

Das wenigstens eine Profil 173a-c kann einen Installationsverwalter und einen Löschungsverwalter umfassen, die jeweils in ein Systemregister eintragbar sind, wobei vorzugsweise der Installationsverwalter und der Löschungsverwalter über das freigebbare Schnittstellenobjekt SIO in das Systemregister eintragbar sind.

Das wenigstens eine Profil 173a-c umfasst in der Darstellung von Fig. 5a ein weiteres Issuer Security Domain Profile (ISD-P). Vorzugsweise ist das weitere Issuer Security Domain Profile (ISD-P) ein Issuer Security Domain Profile (ISD-P) gemäß der Spezifikation GSM SGP.22, insbesondere gemäß der Spezifikation GSM SGP.22 in der Version 2.3 vom 30 Juni 2021.

Die UICC 1 weist weiterhin eine Authentisierungsdatenverwaltung 171 auf. Diese kann in Form eines Java-Applets (siehe Fig. 3) ausführbar im Speicherbereich 17 der UICC 1 abgelegt sein. Die Datenverwaltung 171 kann auch nur als nativer Programmcode ausführbar im Speicherbereich 17 der UICC 1 abgelegt sein. Die Steuereinheit 19 führt die Authentisierungsdatenverwaltung 171 bei Bedarf aus.

Weiterhin sind im Speicher 17 der UICC 1 Authentisierungsdatensätze 172 abgelegt. Beispielhaft sind zwei Authentisierungsdatensätze 172a und 172b dargestellt, die Anzahl ist aber nicht beschränkt. Ein Authentisierungsdatensatz 172 kann verschiedene Authentisierungsdaten umfassen. Dies ist in Fig. 4 beispielhaft dargestellt anhand des ersten Authentisierungsdatensatzes 172a. Er weist einen Authentisierungsalgorithmus (Milenage, TUAK) mit entsprechenden Authentisierungsparametem, einen oder mehrere Authentisierungsschlüssel (CK, IK, Ki), ggf., Sequenzparameter (Zähler SGN-MS, SGN-HE, andere Zähler) und Authentisierungsaktualisierungen etc. auf. Neben den angeführten kann ein Authentisierungsdatensatz 172 weitere Authentisierungsdaten enthalten. Die

Authentisierungsdaten sind bevorzugt, wie in Fig. 5 angedeutet, im Dateisystem 175 strukturiert abgelegt. Es können aber auch proprietäre Dateien erstellt werden, um die Authentisierungsdatensätze 172 abzulegen.

Mit einem Verweis 176 können die Authentisierungsdatensätze 172 einem jeweiligen Profil 173 zugeordnet werden. Dazu ist in einer Ausgestaltung der Erfindung im Dateisystem 175 ein Bereich definiert, in dem die aktivierten Authentisierungsdaten abgelegt werden. Ein Profil 173 greift dann auf diesen Bereich zu, um die UICC 1 beim Server 40 des Kommunikationsnetzes 4 zu authentisieren.

Fig. 6 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens 100 in einer UICC 1. Im Schritt 101 wird ein Befehl, der der Durchführung einer Operation an einem Profil 173a-c entspricht, erhalten. In Schritt 102 wird der Zustand des Profils 173a-c bestimmt. Das heißt, es wird insbesondere bestimmt, ob ein Profil 173a-c aktiv ist oder inaktiv ist.

In Abhängigkeit des Zustands des Profils 173a-c, welches für die Durchführung der Operation bestimmt ist, wird die Operation an diesem Profil 173a-c ausgeführt, indem eine Funktion des freigebbaren Schnittstellenobjekt SIO auf dem Profil 173a-c ausgeführt wird, wenn das Profil 173a-c in einem inaktiven Zustand ist, oder indem eine Funktion des Profils 173a-c selbst auf dem Profil 173a-c ausgeführt wird, wenn das Profil 173a-c in einem aktiven Zustand ist.

Anhand des Verfahrens 100 wird der Subskriptionsverwaltung 174 ermöglicht, auf jedes Profil 173a-c unabhängig von dessen Zustand zuzugreifen. Wenn die Subskriptionsverwaltung 174 zum Verwalten eines aktiven Profils 173a-c auf dieses zugreifen will, kann die Subskriptionsverwaltung 174 das Profil 173a-c unmittelbar aufrufen. Wenn die Subskriptionsverwaltung 174 zum Verwalten eines inaktiven Profils 173 a-c auf dieses zugreifen will, kann die Subskriptionsverwaltung 174 das Profil 173a-c mittelbar über das freigebbare Schnittstellenobjekt SIO, insbesondere mittels eines Aufrufs des freigebbaren Schnittstellenobjekts SIO (Shareable-Interface-Object-Call) aufrufen. Dabei kann das Profil 173a- c, welches das Ziel der Operation ist (Zielprofil), anhand eines Bezeichners (Identifyier) angegeben und/oder identifiziert werden. Der Aufruf des freigebbaren Schnittstellenobjekts SIO kann den Bezeichner und/oder einen Inhalt und/oder eine Natur der an dem Profil 173 a-c durchzuführenden Operation umfassen (beispielsweise eine Anwendung/ein Profil 173 a-c installieren oder löschen, Installation/Löschung eines lokalen Issuer Security Domain, die Aktivierung/Deaktivierung eines Profils oder andere in GSMA SGP.22 definierte Operationen). Das freigebbare Schnittstellenobjekt SIO greift dabei von Innen auf das Zielprofil 173a-c zu und leitet die im Zielprofil auszuführende Operation ein. Das als Bootstrap Issuer Security Domain (ISD-P) ausgestaltete freigebbare Schnittstellenobjekt SIO verhält sich wie eine übliche Issuer Security Domain (ISD-P). Während der Aktivierung/Deaktivierung registriert/deregistriert sich das Anwendungsbündel bei einem Communication Manger, z.B. in Form eines Ereignis Frameworks (englisch: Event Framework). Als besondere Ausgestaltung könnten der Installationsverwalter und der Löschungsverwalter Teil des freigebbaren Schnittstellenobjekts SIO sein.

Die UICC 1 kann ein Register umfassen. In diesem Register können Daten abgelegt werden, mittels derer alle Entitäten eindeutig referenziert werden können. Diese Daten umfassen einen Bezeichner des entsprechenden Anwendungsbündels und einen Bezeichner des entsprechenden Zielprofils (gemäß ISO/IEC 7816). Gemäß dieser Ausgestaltung können, ausgehend von dem aktiven Anwendungsbündel, die Entitäten herausgefiltert werden, die dem Bezeichner des aktiven Anwendungsbündels und der Subskriptionsverwaltung 174 entsprechen. Darüber hinaus kann ein Nicht-UICC-Anwendungsbündel erstellt werden, das die gleiche Schnittstelle hat, aber nicht vom der Subskriptionsverwaltung 174 verwaltet wird.

Im Rahmen der Erfindung können alle beschriebenen und/oder gezeichneten und/oder beanspruchten Elemente beliebig miteinander kombiniert werden.

BEZUGSZEICHENLISTE

1 UICC, Teilnehmeridentitätsmodul, SIM

11 Kommando, APDU

12 Schnittstelle

13 Applet

15 Betriebssystem, OS

16 Java Laufzeitumgebung, JCRE

17 Nichtflüchtiger Speicher

18 Flüchtiger Speicher

19 Steuereinheit, CPU

2 Gerät

21a,b Steuereinheit, ECU

22 Modem

23 Übertragungskommando, APDU

3 Modem zwischen Gerät und UICC

4 Kommunikationsnetz

40 Server

5 Over-The-Air Kommunikation

SIO freigebbares Schnittstellenobjekt