DE102020002658A1

DE102020002658A1 - Verfahren zum Betreiben einer Universal Integrated Chip Card, UICC, sowie UICC

Info

Publication number: DE102020002658A1
Application number: DE102020002658.3A
Authority: DE
Inventors: Stefan Eckardt
Original assignee: Giesecke and Devrient Mobile Security GmbH
Current assignee: GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH, DE
Priority date: 2019-05-03
Filing date: 2020-05-04
Publication date: 2020-11-05

Abstract

Die Erfindung betrifft ein Verfahren zum Betreiben einer Universal Integrated Chip Card, UICC, bevorzugt einer embedded UICC, mit den folgenden Verfahrensschritten: Aktivieren der UICC mittels eines Geräts zum Starten einer neuen UICC-Sitzung; Senden, von der UICC, einer Aktivierungsbestätigung an das Gerät ohne vorheriges Aushandeln und/oder Initialisieren von Parametern in der UICC; Empfangen, in der UICC, eines ersten Kommandos, nach dem Senden der Aktivierungsbestätigung; Prüfen, durch die UICC, ob das erste Kommando ein Wiederherstellen-Kommando ist; Falls das Prüfen ergibt, dass das erste Kommando ein Wiederherstellen-Kommando ist, Wiederherstellen eines in einem nicht-flüchtigen Speicherbereich der UICC abgelegten Zustands einer vorhergehenden UICC-Sitzung; und Falls das Prüfen ergibt, dass das erste Kommando ein vom Wiederherstellen-Kommando verschiedenes Kommando ist, Aushandeln und/oder Initialisieren von zumindest denjenigen Parametern, die zur Bearbeitung dieses ersten Kommandos benötigt werden. Zudem ist auch eine entsprechende UICC und ein Computerprogramm-Produkt vorgesehen.

Description

TECHNISCHES GEBIET DER ERFINDUNG
Die Erfindung bezieht sich auf ein Verfahren zum Betreiben einer Universal Integrated Chip Card, UICC, eine entsprechende UICC und ein Computerprogramm-Produkt.
Zur Nutzung von Diensten enthält ein Gerä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 Internets-der-Dinge, englisch: Internet-of-Things, kurz: IoT, eine UICC. Die UICC wird auch als „Chipkarte“ oder „Teilnehmeridentitätsmodul“ oder „SIM“ bezeichnet. In der UICC sind Benutzerdaten abgelegt, um einen Teilnehmer (Person oder Gerät) für einen Service oder an einem Kommunikationsnetz eindeutig zu identifizieren und/oder zu authentisieren. Damit ist es einem Betreiber der Dienstleistung oder des Kommunikationsnetzwerks möglich, die Nutzung seines angebotenen Dienstes, jedem Teilnehmer eindeutig zuzuordnen. Weiterhin ist es dem Betreiber eines Kommunikationsnetzes möglich, einen Netzzugang, also das Einbuchen in das Kommunikationsnetz, zu ermöglichen, sobald eine Authentisierung des Teilnehmers stattgefunden hat. Er kann zudem den Netzzugang verweigern, falls eine Authentisierung des Teilnehmers nicht möglich ist.
TECHNISCHER HINTERGRUND
Beim Betreiben einer UICC kann es vorkommen, dass für eine bestimmte Zeitspannung kein Zugriff auf die UICC notwendig ist. Um in einem derartigen Fall Energie einsparen zu können, wird die UICC für diese bestimmte Zeitspanne in einen Ruhezustand versetzt, was nachfolgend auch als Suspendieren bezeichnet wird. In diesem Ruhezustand wird der UICC keine Energie für ihren Betrieb zur Verfügung gestellt. Damit in einer darauffolgenden UICC-Sitzung keine zeitaufwendige oder energieverbrauchende Initialisierung der UICC erfolgen muss, kann eine sogenannte „Suspendieren - Wiederherstellen“ Kommandofolge angewendet werden, also das Verwenden eines Suspendieren-Kommandos und anschließendes Verwenden eines Wiederherstellen-Kommandos.
Dabei wird mittels des Suspendier-Kommandos (= „Suspend UICC“) ein interner Zustand einer UICC-Sitzung in der UICC abgespeichert und danach die Betriebsspannung für die UICC abgeschaltet. Mittels des Wiederherstellen-Kommandos (= „UICC resume“) wird der abgespeicherte interne Zustand der vorhergehenden UICC-Sitzung wiederhergestellt, wobei nach einem (Wieder-)Anschalten der Betriebsspannung der abgespeicherte interne Zustand der UICC wiederhergestellt, ohne zeitaufwendige und energieverbrauchende Prozeduren durchzuführen. Weitere Details zu der „Suspendieren - Wiederherstellen“ Kommandofolge können beispielsweise dem Abschnitt 11.1.22 „Suspend UICC“ der ETSI TS 102 221 ab der Version 14.0.0 entnommen werden.
Es ist gemäß technischer Spezifikation vorgesehen, dass die UICC nach einem Suspendieren-Kommando und dem (Wieder-)Anschalten der Betriebsspannung alle Kommandos verarbeiten können soll. Somit muss die UICC nach dem (Wieder-)Anschalten der Betriebsspannung eine normale Start-Prozedur mit dem dazugehörigen Aushandeln und Initialisieren von Parametern durchführen. Durch die normale Startprozedur wird das UICC Betriebssystem dazu eingerichtet, auch alle Kommandos ungleich einem Wiederherstellen-Kommando abarbeiten zu können. Wird dann nach der Start-Prozedur der UICC aber bloß ein Wiederherstellen gewünscht, also ein Wiederherstellen-Kommando als erstes Kommando in der UICC empfangen, werden die im Rahmen der normalen Startprozedur ausgehandelten und/oder initialisierten Parameter sofort wieder überschrieben. Die durchgeführte normale Start-Prozedur war dann unnötig, zeitaufwendig und energieverbrauchend.
Aus der EP 3468261 A1 ist ein Verfahren zur Suspendierung einer UICC bekannt, bei dem die UICC den Zustand bei Suspendierung speichert und UICC und Terminal ein Passwort vereinbaren. Nach Aufhebung der Suspendierung durch Wiederherstellung der Betriebsspannung durch das Terminal läuft die UICC hoch, um gegebenenfalls Kommandos ausführen zu können, die vom Terminal noch vor dem Wiederaktivierungskommando selbst eingehen, wie z.B. ein Kommando zum Lesen einer Elementardatei (Elementary File) der UICC. Nach Eingang des Wiederaktivierungskommandos, das ein Passwort enthält, prüft die UICC, ob das Passwort korrekt ist und stellt im Gutfall den gespeicherten Zustand wieder her.
WO2019/180262 offenbart ein Verfahren zur Verbesserung eine üblichen Wiederaktivierungs-Vorgehensweise mittels einer Suspend-Resume-Kommandofolge. Im Rahmen des Suspendierungsprozesses wird dazu in der UICC ein Kontext-Datenpaket erzeugt und im Terminal hinterlegt. Nachdem die UICC ein Wiederaktivierungs-Kommando akzeptiert hat, schreibt das Terminal das gespeicherte Kontext-Datenpaket auf die UICC. Indem der Zustand der UICC nicht intern in der UICC abgelegt sondern aus Sicht des UICC extern gespeichert wird, ist die Lösung nicht konform mit dem Standard ETSI TS 102 221. Das vorgeschlagene Verfahren kann nur genutzt werden, wenn UICC und Terminal es unterstützen.
In den bekannten Anwendungsfällen, in denen das Senden eines Wiederherstellen-Kommandos nach Anschalten der Betriebsspannung erfolgt, wird in unnötiger Weise Energie und Zeit verbraucht.
ZUSAMMENFASSUNG DER ERFINDUNG
Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren zum Betreiben einer UICC und eine entsprechende UICC zu schaffen, bei der ein Wiederherstellen einer UICC-Sitzung energie- und zeitsparender erfolgt.
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 ein Verfahren zum Betreiben einer Universal Integrated Circuit Card, UICC, bevorzugt einer embedded UICC, mit den folgenden Verfahrensschritten vorgesehen: Aktivieren der UICC mittels eines Geräts zum Starten einer neuen UICC-Sitzung; Senden, von der UICC, einer Aktivierungsbestätigung an das Gerät ohne vorheriges Aushandeln und/oder Initialisieren von Parametern in der UICC; Empfangen, in der UICC, eines ersten Kommandos nach dem Senden der Aktivierungsbestätigung; Prüfen, durch die UICC, ob das erste Kommando ein Wiederherstellen-Kommando ist; Falls das Prüfen ergibt, dass das erste Kommando ein Wiederherstellen-Kommando ist, Wiederherstellen eines in einem nicht-flüchtigen Speicherbereich der UICC abgelegten Zustands einer vorhergehenden UICC-Sitzung; und Falls das Prüfen ergibt, dass das erste Kommando ein vom Wiederherstellen-Kommando verschiedenes Kommando ist, Aushandeln und/oder Initialisieren von zumindest denjenigen Parametern, die zur Bearbeitung dieses ersten Kommandos benötigt werden.
Ein Empfangen von Kommandos ist dabei eine Signalübertragung zum wechselseitigen Steuern zwischen dem Gerät und der UICC. Dabei erfolgt der Kommandoaustausch unter anderem durch das Sender-Empfänger-Modell: Daten bzw. Informationen werden in Zeichen kodiert und dann von einem Sender (Gerät) über einen Übertragungskanal (Schnittstelle) an einen Empfänger (UICC) übertragen. Dabei ist entscheidend, dass Sender und Empfänger dieselbe Kodierung verwenden, damit der Empfänger die Nachricht versteht, d.h. die auszutauschenden Daten dekodieren kann.
Bei einer UICC im Sinne der Erfindung handelt es sich 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äß ETSI TS 102 221 bzw. ISO-7816. Die UICC weist einen sicheren nicht-flüchtigen Speicherbereich auf, in dem Teilnehmeridentitätsdaten sicher eingebracht sind, um Manipulation- und/oder Missbrauchsversuche bei der Identifizierung und/oder Authentisierung am Netzwerk zu verhindern. Diese UICC weist einen Speicherbereich auf, in dem interne Zustände einer UICC-Sitzung abgelegt werden können. Die UICC ist mittels eines Geräts betriebsfähig, wobei die UICC bis auf Versorgungssignale, wie Versorgungsspannung, Takt, Reset etc. autark ist.
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 sind auch USIM, TSIM, ISIM, CSIM oder R-UIM gemäß dem Standard ETSI TS 102 223 gefasst.
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 (eUICC - embedded universal integrated circuit card) oder als integrated Secure Elements (iUICC - integrated universal integrated circuit card) 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 der Fernüberwachung, -kontrolle und -wartung von Geräten wie Maschinen, Anlagen und Systemen dienen. Es kann für Zähleinheiten wie Stromzähler, Warmwasserzähler etc. verwendet werden. Die UICC ist beispielsweise Bestandteil der Technologie des „Internets der Ding“ (IoT).
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 Kommunikationsnetzes, 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 dem Begriff zu fassen. Unter dem Gerät können beispielsweise 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 Automat und/oder einem Fahrzeug eingebracht. Ist das Gerät in einem Kraftfahrzeug eingebracht, hat es beispielsweise eine UICC integriert. Die UICC kann mittels des Geräts, beispielsweise 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.
Eine UICC-Sitzung, auch als „Card Session“ bezeichnet, ist beispielsweise ein Zeitrahmen, beginnend mit dem Senden einer Aktivierungsbestätigung durch die UICC, beispielsweise der Bestätigung einer Rücksetzprozedur, englisch Answer-to-Reset, kurz ATR. Der Zeitrahmen endet beispielsweise mit einem Deaktivieren der UICC oder durch eine spätere Rücksetzprozedur, initialisiert durch das Gerät. Innerhalb dieses Zeitrahmens können Kommandos zwischen dem Gerät und der UICC ausgetauscht werden, was auch als „link between UICC and terminal“ bezeichnet wird.
Eine Aktivierungsbestätigung wird gesendet, um dem Gerät anzuzeigen, dass es für Kommandos vom Gerät empfangsbereit ist. Die UICC signalisiert demnach mit der Aktivierungsbestätigung, dass sie betriebsbereit ist. Erfindungsgemäß wird diese Aktivierungsbestätigung ohne vorheriges Aushandeln von Parametern mit dem Gerät und/oder ohne vorheriges Initialisieren von Parametern in der UICC gesendet. Somit zeigt die UICC dem Gerät die Betriebsbereitschaft bereits vor Ablauf einer normalen Startprozedur an. Die normale Startprozedur wird beispielsweise auch als Rücksetzprozedur (Reset) bezeichnet, wobei dabei erfindungsgemäß Ausdrücklich nicht nur ein ATR, sondern auch das dem ATR folgende Aushandeln von Parametern (sogenannte PPS-Session) und Initialisieren von Parametern verstanden wird.
Durch das Senden der Aktivierungsbestätigung signalisiert die UICC dem Gerät, dass es betriebsbereit und kommandoempfangsbereit ist. Im Empfangen-Schritt wird ein erstes Kommando von dem Gerät in der UICC empfangen. Das erste Kommando ist dabei das erste Kommando in der mit der Aktivierungsbestätigung beginnenden UICC-Sitzung. Dabei ist nach dem Senden der Aktivierungsbestätigung und vor dem Empfangen des ersten Kommandos kein anderes Kommando in der UICC von dem Gerät empfangen worden. Bevorzugt ist dieses Kommando ein erstes Kommando nach dem Senden eines ATR.
Ein Kommando ist dabei eine Anweisung, ein Befehl oder eine Instruktion, die vom Gerät gesendet wird. Dieses Kommando ist dabei ein vom Protokolltyp-Auswahl-Kommando (PTS) verschiedenes Kommando. 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.
Das erste Kommando wird in der UICC dahingehend geprüft, ob es ein Wiederherstellen-Kommando ist. Das Wiederherstellen-Kommando, auch „UICC resume“ Kommando, ist bevorzugt ein in der ETSI TS 102 221 ab Version 14.0.0 beschriebenes Wiederherstellen-Kommando.
Wird im Prüfen-Schritt festgestellt, dass das erste Kommando ein Wiederherstellen-Kommando ist, wird ein in einem nicht-flüchtigen Speicherbereich der UICC abgelegter Zustand einer vorhergehenden UICC-Sitzung wiederhergestellt. Eine vorhergehende UICC-Sitzung ist dabei eine UICC-Sitzung, die vor dem Aktivieren Schritt beendet wurde. Der abgelegte Zustand ist dabei beispielsweise ein Datensatz von Parametern, der unmittelbar vor einem Deaktivieren der vorhergehenden UICC-Sitzung in der UICC vorlag und bereits mit dem Gerät ausgehandelt wurde bzw. mit dem die UICC initialisiert wurden. Der abgelegte Zustand wurde dabei beispielsweise im Rahmen der Bearbeitung eines von dem Gerät gesendeten Suspendieren-Kommandos erstellt und abgelegt. Dieser Datensatz von Parametern wird dann anstelle der während einer normalen Startprozedur auszuhandelnden und/oder zu initialisierenden Parameter verwendet. Auf diese Weise ist die Startprozedur für ein Wiederherstellen einer UICC-Sitzung stark verkürzt worden und somit Zeit- und Energie eingespart worden.
Wird im Prüfen-Schritt festgestellt, dass das erste Kommando kein Wiederherstellen-Kommando ist (also ein vom Wiederherstellen-Kommando verschiedenes Kommando), erfolgt ein Aushandeln und/oder Initialisieren von zumindest denjenigen Parametern, die zur Bearbeitung dieses ersten Kommandos benötigt werden.
In einem ersten Fall wird zum Aushandeln/Initialisieren der zumindest für das Abarbeiten des ersten Kommandos benötigte Parameter, das Aushandeln/Initialisieren aller Parameter gemäß einer normalen Startprozedur nachgeholt. In diesem ersten Fall wird im Ergebnis die Startprozedur normal ausgeführt und die UICC kann alle Kommandos ausführen.
In einem anderen Fall wird zum Aushandeln/Initialisieren der zumindest für das Abarbeiten des ersten Kommandos benötigten Parameter zunächst durch die UICC ermittelt, welche Parameter für das erste Kommando (kein Wiederherstellen-Kommando) initialisiert werden müssen und dann in der Folge die ermittelten Parameter mit dem Gerät ausgehandelt oder initialisiert. In diesem anderen Fall ist die Startprozedur ebenfalls verkürzt und somit Zeit- und Energie eingespart worden.
Durch das erfindungsgemäße Verfahren wird also eine verkürzte Startprozedur (bzw. verkürzte Rücksetzprozedur) der UICC nach Aktivieren durch das Gerät erhalten, bei der dem Gerät eine schnellere Betriebs- und Empfangsbereitschaft für Kommandos angezeigt wird. Wird dann als erstes Kommando ein Wiederherstellen Kommando in der UICC empfangen, so wird der zuvor abgelegte interne Zustand einer vorhergehenden UICC-Sitzung wiederhergestellt, ohne dass zuvor mühsam alle Parameter ausgehandelt und/oder initialisiert werden. Da diese mühsam ausgehandelten/initialisierten Parameter im Rahmen einer Abarbeitung des Wiederherstellen-Kommandos wieder überschrieben würden, kann durch das Weglassen des Aushandelns/Initialisieren der Parameter enorm Zeit und Energie gespart werden.
Wird dennoch ein vom Wiederherstellen-Kommando verschiedenes Kommando empfangen, wird die Start-Prozedur durch nachholen der Parametrisierung vervollständigt (Nachholen des Aushandeln/ Initialisieren der Parameter), wodurch das vom Wiederherstellen-Kommando verschiedene Kommando ausgeführt werden kann.
Es wird also eine verkürzte Startprozedur erhalten, die nach dem Aktivieren der UICC eine zügige Bereitschaft signalisiert, um ein Wiederherstellen-Kommando ausführen zu können.
In dem nichtflüchtigen Speicher können auch verschiedene interne Zustände abgelegt sein, wobei ein interner Zustand jeweils eine UICC-Sitzung repräsentiert. Somit könnten verschiedene UICC-Sitzungen gesichert worden sein. Im Rahmen eines Wiederherstellungs-Kommandos kann die UICC vom Gerät dann aufgefordert werden eine bestimmte UICC-Sitzung wiederherzustellen und fordert dazu das Laden eines entsprechenden internen Zustands auf.
In einer bevorzugten Ausgestaltung hat die UICC vor dem Aktivieren, ein erfolgreiches Ausführen eines Suspendier-Kommandos an das Gerät bestätigt. Dabei wurde zuvor ein in der UICC empfangenes Suspendier-Kommando ausgeführt und abgearbeitet und dabei ein interner Zustand der laufenden UICC-Sitzung im nichtflüchtigen Speicherbereich der UICC abgelegt. In der Folge der Bestätigung des erfolgreichen Ausführens des Suspendier-Kommandos erfolgte dann seitens des Geräts ein Deaktivieren der UICC, bevorzugt gemäß Standard ISO 7816-3. Das Deaktivieren beendete sodann die vorhergehende UICC-Sitzung und startete eine Suspendier-Zeit, also eine Zeitdauer, in der die UICC deaktiviert ist. Mit Suspendieren ist das zeitweise Deaktivieren der UICC gemeint.
In einer bevorzugten Ausgestaltung werden das Suspendier-Kommando und das erste Kommando als APDU Kommandos in der UICC empfangen. Ein APDU ist ein kombinierter Kommando-/Datenblock eines Verbindungsprotokolls zwischen der UICC und dem Gerät. Die Struktur der APDU ist durch den Standard ISO-7816-4 definiert. APDUs stellen ein Informationselement der Anwendungsebene (Schicht 7 des OSI-Schichtenmodels) dar. Im Unterschied zur konventionellen Art, werden also nicht im Rahmen der Aktivierung der UICC Verbindungsparameter ausgehandelt, sondern es erfolgt ein Kommando-Austausch in der Annahme, dass das erste Kommando ein Wiederherstellen-Kommando gemäß ETSI Standard TS 102 221, Abschnitt 11.1.22 ist.
In einer bevorzugten Ausgestaltung ist die Aktivierungsbestätigung ein Answer-to-Reset, kurz ATR. Ein ATR signalisiert das Ende einer Rücksetzprozedur (=Reset). Das ATR ist dabei der erste Datensatz von der UICC an das Gerät nach der Aktivierung der UICC. Beim ATR handelt es sich bevorzugt um ein ATR nach einem Kalt-Reset der UICC. Im Anschluss an den ATR könnte das Gerät PTS-Kommandos senden, um Verbindungsparameter auszuhandeln. Im Rahmen dieser Erfindung ist bevorzugt, dass das Gerät auf derartige Kommandos zum Aushandeln von Verbindungsparametern mit der UICC und/oder Auffordern zum Initialisieren bzw. Mitteilen von Verbindungsparametern durch die UICC verzichtet, um eine verkürzte Startprozedur zu ermöglichen. Bevorzugt wird also direkt nach dem Empfangen eines ATR im Gerät ein Kommando vom Gerät gesendet, dass kein PTS-Kommando ist.
In einer bevorzugten Ausgestaltung sind die Parameter einer oder mehrere der folgenden: Verbindungsparameter; Anwendungsparameter; und/oder Betriebssystemparameter. Als Verbindungsparameter sind insbesondere die Art eines Übertragungs-Protokolls (T=0, T=1), Übertragungsgeschwindigkeitsparameter; ein Takt-Stopp-Parameter; eine Bit- und Zeichendauer; eine Abtastrate; und/oder ein Fehlerbehandlungsparameter vorgesehen. Der Parameter kann zudem ein Anwendungsparameter für eine Anwendung (=Applet) der UICC sein. Der Parameter kann zudem ein Betriebssystemparameter für das Betriebssystem der UICC sein. Zumindest einer dieser Parameter wird nur ausgehandelt oder initialisiert, wenn kein Wiederherstellen-Kommando als erstes Kommando gesendet wird.
In einer bevorzugten Ausgestaltung wird das Verfahren durch eine Betriebssystem-Routine der UICC ausgeführt. Damit ist das Verfahren als Programmcode für eine native UICC vorgesehen und kann auf einer großen Anzahl unterschiedlicher UICC Ausführungsformen ausgeführt werden. Insbesondere muss für das Verfahren keine Laufzeitumgebung, beispielsweise eine Javacard Laufzeitumgebung, bereitgestellt werden, um die Verfahrensschritte auszuführen.
In einer bevorzugten Ausgestaltung ist der abgelegte UICC-Zustand eine Variable; eine Datei; ein Dateizeiger (=Filepointer); ein Anwendungsparameter; ein Status einer Anwendung eines logischen Kanals der UICC; ein Sicherheitsaspekt einer Anwendung (authentisierte Anwendung/nicht-authentisierte Anwendung); und/oder ein Sicherheitsaspekt einer Datei. Diese waren Teil der UICC-Sitzung vor dem Suspendieren der UICC, insbesondere unmittelbar vor dem Suspendieren der UICC. Dies ermöglicht, dass der interne Zustand einer aufwendig parametrisierten UICC in einem nicht-flüchtigen Speicherbereich der UICC gespeichert werden kann und dass dieser interne Zustand ohne Zeit- und Energieaufwand wiederhergestellt, also der vorhergehende Betrieb mit der UICC fortgesetzt werden kann.
In einer bevorzugten Ausgestaltung wird nach dem Aushandeln und/oder Initialisieren von den zumindest denjenigen Parametern, die zur Bearbeitung dieses ersten Kommandos benötigt werden, das vom Wiederherstellen-Kommando verschiedenen ersten Kommando ausgeführt.
In einer bevorzugten Ausgestaltung ist das Aktivieren der UICC ein Reaktivieren der UICC nach einem Suspendier-Kommando. Damit ist sichergestellt, dass zuvor mittels eines Suspendier-Kommando ein interner Zustand einer vorhergehenden UICC-Sitzung im nicht-flüchtigen Speicher abgelegt wurde.
In einer bevorzugten Ausgestaltung umfasst das Aktivieren der UICC das Aktivieren von Kontakten einer kontaktbehafteten Schnittstelle unter Anlegen einer Betriebsspannung an die UICC. Das Aktivieren der Kontakte der UICC erfolgt beispielsweise gemäß der technischen Spezifikation ISO 7816-3 in folgender Reihenfolge: Setzen des „Reset“ Kontakts auf logisch „LOW“; Anschalten der Betriebsspannung Vcc; Setzen des Dateneingangs auf I/O in einen Empfangsmodus und Anlegen eines stabilen Takts; Setzen des „Reset“ Kontakts auf logisch „HIGH“. Mit einem derartigen Aktivieren der UICC wird der ordnungsgemäße Betrieb der UICC aufgenommen und ein geregeltes Hochfahren der Steuereinheit (µP) der UICC ermöglicht.
In einer alternativen Ausgestaltung umfasst das Aktivieren der UICC das Aktivieren einer kontaktlosen Schnittstelle unter Empfangen eines Energiefelds zum Wandeln in eine Betriebsspannung durch die UICC. Dabei erfolgt das Aktivieren der UICC durch Bereitstellen eines elektromagnetischen Feldes, aus dem die UICC eine Betriebsspannung generieren kann, um einen Betrieb aufzunehmen.
In einem weiteren Aspekt weist eine UICC, bevorzugt ein Teilnehmeridentitätsmodul, folgendes auf: eine Schnittstelle zur Datenkommunikation mit einem Gerät, eingerichtet zum Empfangen einer Betriebsspannung zum Aktivieren der UICC; einen nicht-flüchtigen Speicher, eingerichtet zum Ablegen eines UICC-Zustands; und eine Steuereinheit, eingerichtet zum: Senden einer Aktivierungsbestätigung an das Gerät ohne vorheriges Aushandeln und/oder Initialisieren von Parametern in der UICC; Empfangen eines ersten Kommandos, nach dem Senden der Aktivierungsbestätigung; Prüfen, ob das erste Kommando ein Wiederherstellen-Kommando ist; falls das Prüfen ergibt, dass das erste Kommando ein Wiederherstellen-Kommando ist, Wiederherstellen eines im Rahmen eines Suspendier-Kommandos im nicht-flüchtigen Speicher der UICC abgelegten UICC-Zustands; und falls das Prüfen ergibt, dass das erste Kommando ein vom Wiederherstellen-Kommando verschiedenes Kommando ist, Aushandeln und/oder Initialisieren von zumindest denjenigen Parametern, die zur Bearbeitung dieses ersten Kommandos benötigt werden.
Bevorzugt wird die Aktivierungsbestätigung in der Steuereinheit erstellt bevor diese gesendet wird.
Bevorzugt umfasst die UICC weiter ein Betriebssystem, welches ausführbar in dem nicht-flüchtigen Speicher abgelegt ist und was dazu eingerichtet ist, die Schritte der Steuereinheit durchzuführen.
In einem weiteren Aspekt ist ein Computerprogramprodukt ausführbar in der UICC installiert und weist Mittel zum Ausführen der Verfahrensschritte des vorhergehend beschriebenen Verfahrens auf.
Die UICC ist beispielsweise dazu eingerichtet, eine logische Datenverbindung zu einem Server über ein Kommunikationsnetz aufzubauen, um Dienste eines Servers zu nutzen und mit diesem Server 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 102 226 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 Provisionierungs-Server, um Aktualisierungen für Software, Firmware oder/und Betriebssystem des eUICC in das eUICC zu laden.
Teilnehmeridentitätsdaten, 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, auch International Mobile Subscriber Identity, kurz IMSI und/oder teilnehmerspezifische Daten. Die IMSI ist das in einem Mobilfunkkommunikationsnetzwerk eindeutige Teilnehmeridentitätsdatei. Sie setzt sich zusammen aus dem Landescode MCC (Mobile Country Code), dem Netzwerkcode MNC (Mobile Network Code) und einer laufenden Nummer, die vom Netzbetreiber vergeben wird. Zudem sind Teilnehmeridentitätsdaten beispielsweise Daten, die einen Teilnehmer eindeutig am Kommunikationsnetz authentisieren, 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 ist betriebsbereit in das Gerät eingebracht. 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 auszutauschen.
Figurenliste
Nachfolgend wird 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 werden mit gleichen Bezugszeichen versehen. Die Figuren sind nicht als maßstabsgetreu anzusehen, es können einzelne Elemente der Figuren übertrieben groß bzw. übertrieben vereinfacht dargestellt sein.

1 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams einer konventionellen Suspendieren - Wiederherstellen Kommandofolge in einer UICC;
2 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens in einer UICC;
3 zeigt ein Ausführungsbeispiel eines Systems aus Gerät und erfindungsgemäßer UICC; und
4 zeigt ein Ausführungsbeispiel einer erfindungsgemäßen UICC.

DETAILLIERTE BESCHREIBUNG VON AUSFÜHRUNGSBEISPIELEN
1 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams einer konventionellen Suspendieren - Wiederherstellen Kommandofolge in einer UICC. Im Schritt 101 wird ein Suspendieren-Kommando in der UICC 1 empfangen. Dieses Suspendieren-Kommando ist ein APDU Kommando. Dieses Kommando veranlasst die UICC, einen internen Zustand einer UICC-Sitzung abzulegen. Dieser interne Zustand wird in einen nicht-flüchtigen Speicherbereich abgelegt. Im Folgeschritt 102 wird eine Betriebsspannung abgeschaltet. Die UICC ist somit stromlos bzw. spannungslos und verbraucht ab diesem Zeitpunkt keine Energie. Nachdem eine gegebene Suspendierzeit verstrichen ist, wird im Schritt 103 die Betriebsspannung wieder angeschaltet. Dieses Anschalten der Betriebsspannung führt in der UICC im Schritt 104 zu einer Rücksetzprozedur (=Reset). Im Ergebnis der Rücksetzprozedur wird ein ATR im Schritt 105 gesendet. Im Schritt 106 erfolgt dann im direkten Anschluss an das ATR ein Empfangen von weiteren Informationen vom Gerät, um die UICC weiter zu parametrisieren, wobei insbesondere Verbindungsparameter ausgehandelt und initialisiert werden, um einen ordnungsgemäßen Empfang von Kommandos sicherzustellen. Im Rahmen dieser normalen Startprozedur, dargestellt durch die Schritte 103 bis 106 wird die UICC parametrisiert und ist nach dem Schritt 106 dazu eingerichtet, jegliche Kommandos gemäß Spezifikation TS 102 221, die von dem Gerät gesendet werden, auch auszuführen. Nachfolgend wird eine Liste derjenigen Parameter aufgelistet, die in der UICC zwischen den Schritten 103 bis 106 initialisiert und/oder ausgehandelt werden: Zeitdaueroder Symbolrate; Symbolaufbau; Fehlersignal- bzw., Symbolwiederholung; Verbindungsprotokoll-Auswahl und-Parametrisierung (sogenanntes Protocol and Parameter Selection, kurz PPS); Übertragungsmodus (Halbduplex oder Duplex, T=0; T=1). Diese Parameter werden auch in der ISO/IEC 7816-3 im Abschnitt 7, 9, 10 und 11 beschrieben und definiert. Erst nachdem diese Parameter ausgehandelt/initialisiert wurden, erfolgt im Schritt 107 der Empfang eines Wiederherstellen-Kommandos (UICC resume). Dieses Wiederherstellen-Kommando veranlasst die UICC, den internen Zustand aus dem nichtflüchtigen Speicher zu laden. Im Rahmen dieses Ladevorgangs werden alle zuvor ausgehandelten/initialisierten Parameter überschrieben, um den internen Zustand einer UICC-Sitzung, der unmittelbar vor dem Suspendier-Kommando im Schritt 101 in der UICC vorlag, wiederherzustellen.
Diese Kommandofolge dient vor allem dazu den vorliegenden Zustand einer UICC-Sitzung, also beispielsweise Dateizeiger, interne Variablen, Variablen von JavaCard Applets, etc. der UICC abzuspeichern und die UICC dann zu deaktivieren, um einen Stromverbrauch zu reduzieren. Damit können batteriebetriebene Geräte energieeffizient betrieben werden. Nach dem (Wieder-)Anschalten der Betriebsspannung wird der vorhergehende interne Zustand wiederhergestellt, indem er aus dem Speicher geladen wird. Damit wird ein Datensatz an Parametern geladen, um die vorherige UICC-Sitzung wieder zu erhalten.
Problematisch bei diesem Ablauf gemäß 1 ist die standardgemäße Forderung, dass die UICC in der Lage sein muss, dass nach dem (Wieder-)Anschalten der Betriebsspannung in Folge eines Suspendier-Kommandos jegliches Kommando abarbeiten zu können. Damit soll einen Betriebsfall abgebildet werden können, der das Wiederherstellen-Kommando nach dem Suspendieren-Kommando überflüssig macht. Diese standardgemäß geforderte Flexibilität der Kommando-Abarbeitung bedingt aber immer eine komplette normale Startprozedur gemäß Schritten 103 bis 106 mit vollständiger Parametrisierung der UICC. Diese Parameter werden im Fall des Empfangs eines Wiederherstellen-Kommandos im Schritt 107 sofort wieder überschrieben, um den vorhergehenden internen Zustand wiederherzustellen. Für die klassische Anwendung der Kommandofolge (erst Suspendieren, dann Wiederherstellen) wird also in unnötiger Weise Energie und Zeit verbraucht, da beim Wiederherstellen-Kommando viele Parameter, die im Rahmen der normalen Startprozedur in den Schritten 103 bis 106 mühsam ausgehandelt und initialisiert wurden, überschrieben werden müssen. Dieser Energieverbrauch wirkt sich nachteilig auf jeweilige Anwendungsfälle aus, insbesondere wird eine Batterielaufzeit eines IoT-Gerätes oder eines Smartphones stark verkürzt.
2 zeigt ein Ausführungsbeispiel eines Ablaufdiagrams eines Verfahrens 200 in einer UICC 1 gemäß der Erfindung. Im Schritt 201 wird ein Suspendieren-Kommando (Suspend UICC) gemäß TS 102 221 in der UICC 1 empfangen. Dieses Suspendier-Kommando ist ein APDU Kommando, mittels dem ein interner Zustand einer UICC 1 gespeichert wird. Ein APDU Kommando besteht aus 5 Byte großen Kopfdaten (= Header), mit CLA, INS, P1, P2 und P3 Bytes. Beim Suspend UICC Kommando wird das letzte Bit im Byte „P1“ auf „0“ gesetzt. Mit diesem Kommando wird der interne Zustand einer UICC der aktuellen UICC-Sitzung (Card Session) in den nichtflüchtigen Speicher der UICC abgelegt. Dieser Speicher ist beispielsweise ein EEPROM oder Flash Speicher. Nach dem Empfangen des APDU-Kommando im Schritt 201 der UICC 1 werden alle Daten die benötigt werden, um die UICC 1 in den exakt gleichen Zustand zu versetzen, abgespeichert. Der abgespeicherte interne Zustand soll den Betrieb der UICC in einer folgenden UICC-Sitzung derart ermöglichen, als wäre eine Betriebsspannung nie abgeschaltet worden. Diese Daten beinhalten einen Zustand einer ausgewählten Anwendung eines jeden logischen Kanals; Sicherheitsaspekte, die eine Authentisierung (PIN-Verifizierung) einer jeden Anmeldung betreffen, also ob eine Authentisierung erfolgt ist oder nicht; die jeweils ausgewählten Elementardaten (Elementary Files, EF), bzw. die Dateizeiger (Filepointer) darauf sowie den Status der jeweiligen Toolkit-Applikation.
Eine erfolgreiche Ausführung eines Suspendier-Kommandos wird insbesondere mit einer Kommando-Antwort „91 00“ von der UICC beantwortet. Diese Antwort signalisiert dem Gerät, dass die UICC den internen Zustand erfolgreich abgelegt hat und dass die UICC deaktiviert werden kann.
Im Schritt 202 erfolgt sodann ein Deaktivieren der UICC durch Abschalten der Betriebsspannung. Dabei werden die Kontakte einer kontaktbehafteten Schnittstelle gemäß ISO/IEC 7816-3 deaktiviert. Dazu wird seitens des Geräts ein Reset-Kontakt auf logisch „LOW“ gesetzt, dann der Takt-Kontakt CLK auf logisch „LOW“ gesetzt, dann der Daten-Kontakt I/O auf logisch „LOW“ gesetzt und schließlich die Betriebsspannung vom Kontakt Vcc entkoppelt. Sodann befindet sich die UICC in einem Suspendiert-Modus, in dem keine Energie verbraucht wird. Diese Suspendiert-Modus dauert beispielsweise eine vordefinierte Suspendier-Zeit an.
Im Schritt 203 wird nach dem Verstreichen der Suspendier-Zeit, die UICC (re-)aktiviert. Das Aktivieren gemäß Schritt 203 erfolgt dabei im Rahmen der technischen Spezifikation ISO/IEC 7816-3, wobei zunächst der Reset-Kontakt auf logisch „LOW“ gesetzt, dann die Betriebsspannung an den Kontakt Vcc angeschaltet wird; dann der Daten-Kontakt I/O auf Empfangen-Modus; dann der Takt-Kontakt CLK einen stabilen Takt liefert; und schließlich der Reset-Kontakt auf logisch „HIGH“ gesetzt wird. Dies entspricht einer Kalt-Rücksetzprozedur (Cold Reset) für eine UICC.
In Schritt 204 sendet die UICC eine Aktivierungsbestätigung. Diese Aktivierungsbestätigung kann ein ATR sein, also ein Signalisieren der UICC an das Gerät, dass die UICC betriebsbereit und kommandoempfangsbereit ist. Im Unterschied zur konventionellen Kommandofolge (gemäß 1) wird im Rahmen der Aktivierung und der damit ausgelösten Rücksetzprozedur die UICC 1 nicht parametrisiert und es werden keine Parameter ausgehandelt. Es gilt zudem zu beachten, dass im Verfahrensablauf gemäß 2 kein vergleichbarer Schritt 106 (gemäß 1) vorhanden ist. Somit erfolgt vor dem Schritt 205 kein Empfangen von weiteren Informationen vom Gerät, um die UICC weiter zu parametrisieren. Insbesondere wird keines der folgenden Parameter in der UICC 1 initialisiert und/oder ausgehandelt werden, bevor ein erstes Kommando vom Gerät in der UICC im Schritt 205 empfangen wird: Zeitdauer oder Symbolrate; Symbolaufbau; Fehlersignal- bzw. Symbolwiederholung; Verbindungsprotokoll-Auswahl und -Parametrisierung (sogenanntes Protocol and Parameter Selection, kurz PPS); Übertragungsmodus (Halbduplex oder Duplex, T=0; T=1). Keines dieser Parameter (siehe auch ISO/IEC 7816-3 im Abschnitt 7, 9, 10 und 11) wird in dieser Phase der Kommandofolge initialisiert oder definiert.
Im Schritt 205 wird ein erstes Kommando empfangen. Das Kommando ist bevorzugt ein APDU Kommando. Es ist das erste Kommando von dem Gerät in der aktuellen UICC-Sitzung, also das erste Kommando nach dem Schritt 204. Das erste Kommando ist beispielsweise gemäß ISO/IEC 7816-3 Abschnitt 12 aufgebaut und eines der in ETSI TS 102 221 V14.0.0 beschriebenen Kommandos. Im Folgeschritt 206 wird in der UICC geprüft, ob das erste Kommando ein Wiederherstellen-Kommando (UICC resume) ist.
Wenn es sich beim ersten Kommando um ein Wiederherstellen-Kommando (UICC resume) handelt (Ja-Fall des Schritts 206), so wird im Schritt 207 dieses Wiederherstellen-Kommando abgearbeitet. Dieses APDU-Wiederherstellen-Kommando wird anhand des letzten Bits des P1-Bytes im APDU-Header definiert, wobei für das Wiederherstellen, dieses letzte Bit auf logisch „HIGH“ gesetzt wird. Dabei wird der interne Zustand der UICC-Sitzung aus dem nichtflüchtigen Speicher geladen wird. Im Ergebnis des Schritts 207 ist eine UICC-Sitzung erhalten, die der vor dem Abschalten der Betriebsspannung gemäß Schritt 201 entspricht. Optional wird dann der wiederhergestellte Zustand im Speicher gelöscht. Das Wiederherstellen-Kommando kann eines aus einer Vielzahl von abgelegten Zuständen wiederherstellen.
Wenn es sich beim ersten Kommando nicht um ein Wiederherstellen-Kommando handelt (Nein-Fall des Schritts 206), so wird im Schritt 208 das Aushandeln/Initialisieren der Parameter nachgeholt. Nachfolgend wird eine Liste derjenigen Parameter aufgelistet, die in der UICC 1 initialisiert und/oder ausgehandelt werden könnten, nachdem ein erstes Kommando (vom Wiederherstellen-Kommando verschieden) vom Gerät 2 in der UICC 1 empfangen wird: Zeitdauer oder Symbolrate; Symbolaufbau; Fehlersignal- bzw. Symbolwiederholung; Verbindungsprotokoll-Auswahl und -Parametrisierung (sogenanntes Protocol and Parameter Selection, kurz PPS); Übertragungsmodus (Halbduplex oder Duplex, T=0; T=1). Diese Parameter werden auch in der ISO/IEC 7816-3 im Abschnitt 7, 9, 10 und 11 beschrieben und definiert. Im Anschluss an das Parametrisieren gemäß Schritt 208 wird dann im Schritt 209 das empfangene erste Kommando abgearbeitet.
Das Verfahren 200 wird dabei in einem Betriebssystem (OS) der UICC 1 integriert und kann so, in jeder nativen UICC eingesetzt und verwendet werden. Dieses verbesserte UICC-OS führt nach dem (Wieder-)Anschalten also keine normale Startprozedur gemäß 1 durch, sondern es wird eine kürzere und damit schnellere Startprozedur durchgeführt. Nur wenn, das erste Kommando ein vom Wiederherstellen-Kommando verschiedenes Kommando ist, wird die Startsequenz vervollständigt, indem das Parametrisieren der UICC nachgeholt wird, um anschließend dieses erste Kommando abarbeiten zu können. Die verkürzte Startprozedur ermöglicht für das klassische Anwenden der Suspendieren-Wiederherstellen Kommandofolge (also Wiederherstellen nach vorhergehendem Suspendieren) eine viel kürzere Zeitdauer zwischen Anlegen der Betriebsspannung und Kommandoempfangsbereitschaft. Damit wird ein Energieverbrauch in der UICC erheblich reduziert, wodurch batteriebetriebene Geräte, wie insbesondere Internet-der-Dinge Geräte, die eine UICC beinhalten, entscheidende Energie einsparen können.
3 zeigt ein Ausführungsbeispiel eines Systems aus Gerät 2 und UICC 1, in der das Verfahren der 2 abläuft. Das Gerät 2 ist beispielsweise ein M2M-Gerät in einer IoT Umgebung. Das Gerät 2 kann eine Mehrzahl von ECUs 21 aufweisen, hier stellvertretend sind zwei ECUs 21a und 21b dargestellt. Durch diese ECUs 21 wird die Funktionalitäten des Geräts 2 gesteuert. Wenn das Gerät 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 4 detaillierter dargestellt. In 3 ist angedeutet, dass die UICC 1 Applets 13 aufweist. Diese Applets 13 können über eine Card Application Toolkit, CAT, 12, unterschiedliche APDU-Kommandos 11 an das Gerät 2 senden.
Das Gerät 2 umfasst auch ein Modem 22. Das Modem 22 kann beispielsweise als eine logische Einheit zum Umsetzen von Daten zwischen der UICC 1 und einem Server (nicht dargestellt) angesehen werden. Das Gerät 2 kann durch das Modem 22 eine Kommunikationsverbindung 3 zur UICC 1 aufbauen. Die Kommunikation 3 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 der 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 eUICC 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 22 ist dabei eine Kommunikationseinheit des Geräts 2, um auch Daten des Geräts 2 oder der UICC 1 über ein Kommunikationsnetz (nicht dargestellt) auszutauschen. Die ausgetauschten Daten zwischen UICC 1 und Modem 22 können im Modem 22 in ein IP-basiertes Verbindungsprotokoll umgesetzt werden.
4 zeigt ein Blockschaltbild einer UICC 1, vorzugsweise eine fest verdrahtete eUICC 1. Alternativ ist die eUICC 1 ein portabler Datenträger mit einer anderen Bauform. Die UICC 1 hat ein Betriebssystem 15, in dem das Verfahren 200 gemäß 2 abläuft. Das Betriebssystem 15 ist beispielsweise ein natives Betriebssystem. Es ist zudem denkbar, dass das Betriebssystem 15 eingerichtet ist, eine Javacard Laufzeitumgebung, JCRE, 16 zu betreiben.
Die UICC 1 ist dazu ausgestaltet mit dem Gerät 2 gemäß 3 Daten auszutauschen. 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 Kommunikationsschnittstellen 31 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 WLAN Standard.
Die UICC 1 hat zudem eine zentrale Prozessor- bzw. Steuereinheit, CPU 19, die in Kommunikationsverbindung mit der Schnittstelle 31 steht. Zu den primären Aufgaben der CPU 19 gehören das Ausführen von arithmetischen und logischen Funktionen und das Lesen 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 wieder beschreibbaren 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 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), einer ersten und zweiten Applikation 13a, 13b hinterlegt sein. Dabei liegen die Applikationen 13a, 13b vorzugsweise in Form von Java Card™ Applets vor. Zudem ist der in 3 gezeigte CAT 12 gemäß ETSI TS 102 223 eingebracht. Zudem wird im Rahmen des Suspendier-Kommandos (Suspend UICC) gemäß ETSI TS 102 221 ein interner Zustand 20 einer UICC Sitzung in den nichtflüchtigen Speicher 17 eingebracht, so wie es zuvor beschrieben ist. Der interne Zustand 20 entspricht dabei dem internen Zustand wie er in 2 beschrieben wurde.
Im Rahmen der Erfindung können alle beschriebenen und/oder gezeichneten und/oder beanspruchten Elemente beliebig miteinander kombiniert werden.
Bezugszeichenliste

UICC,: Teilnehmeridentitätsmodul, SIM, eUICC
11: Übertragungskommando, APDU
12: Card Application Toolkit, CAT
13: Applet
15: Betriebssystem, OS
16: Java Laufzeitumgebung, JCRE
17: Nichtflüchtiger Speicher
18: Speicherbereich
19: Steuereinheit, CPU
20: UICC-Zustand Gerät
21a,b: Steuereinheit, ECU
22: Modem
23: Übertragungskommando, APDU Kommunikationsverbindung zwischen Gerät und UICC
31: Schnittstelle der UICC
101-107: Verfahrensschritte gemäß Stand der Technik
201-209: Verfahrensschritte gemäß der Erfindung

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

EP 3468261 A1 [0006]
WO 2019/180262 [0007]

Zitierte Nicht-Patentliteratur

ISO/IEC 7816-3 [0053, 0058, 0059, 0060, 0061, 0063, 0067]
ISO/IEC 7816-4 [0067, 0068]

Claims

Ein Verfahren (200) zum Betreiben einer Universal Integrated Circuit Card, UICC (1) mit den folgenden Verfahrensschritten: - Aktivieren (203) der UICC (1) mittels eines Geräts (2) zum Starten einer neuen UICC-Sitzung; - Senden (204), von der UICC (1), einer Aktivierungsbestätigung an das Gerät (2) ohne vorheriges Aushandeln und/oder Initialisieren von Parametern in der UICC (1); - Empfangen (205), in der UICC (1), eines ersten Kommandos, nach dem Senden (204) der Aktivierungsbestätigung; - Prüfen (206), durch die UICC (1), ob das erste Kommando ein Wiederherstellen-Kommando ist; - Falls das Prüfen (206) ergibt, dass das erste Kommando ein Wiederherstellen-Kommando ist, Wiederherstellen (207) eines in einem nicht-flüchtigen Speicherbereich (17) der UICC (1) abgelegten Zustands (20) einer vorhergehenden UICC-Sitzung; und - Falls das Prüfen (206) ergibt, dass das erste Kommando ein vom Wiederherstellen-Kommando verschiedenes Kommando ist, Aushandeln und/oder Initialisieren (208) von zumindest denjenigen Parametern, die zur Bearbeitung dieses ersten Kommandos benötigt werden.
Verfahren (200) nach Anspruch 1, wobei die UICC (1) vor dem Aktivieren (203), ein erfolgreiches Ausführen eines Suspendier-Kommandos bestätigt hat.
Verfahren (200) nach Anspruch 1 oder 2, wobei das Suspendier-Kommando und das erste Kommando als APDU Kommandos (11) in der UICC (1) empfangen werden.
Verfahren (200) nach einem der vorhergehenden Ansprüche, wobei die Aktivierungsbestätigung ein Answer-to-Reset, ATR, ist.
Verfahren (200) nach einem der vorhergehenden Ansprüche, wobei die Parameter einer oder mehrere der folgenden sind: - Verbindungsparameter; - Anwendungsparameter; und/oder - Betriebssystemparameter.
Verfahren (200) nach einem der vorhergehenden Ansprüche, wobei das Verfahren (200) durch eine Betriebssystem-Routine der UICC (1) ausgeführt wird.
Verfahren (200) nach einem der vorhergehenden Ansprüche, wobei der abgelegte UICC-Zustand (20): - eine Variable; - eine Datei; - einen Dateizeiger; - einen Anwendungsparameter; - einen Status einer Anwendung eines logischen Kanals der UICC (1); und/oder - einen Sicherheitsaspekt einer Anwendung; und/oder - einen Sicherheitsaspekt einer Datei vor dem Suspendieren der UICC (1) betrifft.
Verfahren (20) nach einem der vorhergehenden Ansprüche, wobei nach dem Aushandeln und/oder Initialisieren (208) von den zumindest denjenigen Parametern, die zur Bearbeitung dieses ersten Kommandos benötigt werden, das vom Wiederherstellen-Kommando verschiedenen ersten Kommando ausgeführt (209) wird.
Verfahren (200) nach einem der vorhergehenden Ansprüche, wobei das Aktivieren (203) ein Reaktivieren nach einem Suspendier-Kommando ist.
Verfahren (200) nach einem der vorhergehenden Ansprüche, wobei das Aktivieren (203) der UICC (1) das Aktivieren von Kontakten einer kontaktbehafteten Schnittstelle (31) unter Empfangen einer Betriebsspannung an der UICC (1) umfasst.
Verfahren nach einem der Ansprüche 1 bis 10, wobei das Aktivieren (203) der UICC (1) das Aktivieren einer kontaktlosen Schnittstelle unter Empfangen eines Energiefelds zum Wandeln in eine Betriebsspannung durch die UICC (1) umfasst.
Eine UICC (1), bevorzugt ein Teilnehmeridentitätsmodul, aufweisend - eine Schnittstelle (31) zur Datenkommunikation mit einem Gerät (2), eingerichtet zum Empfangen einer Betriebsspannung zum Aktivieren (203) der UICC (1); - einen nicht-flüchtigen Speicher (17), eingerichtet zum Ablegen eines UICC-Zustands (20); und - eine Steuereinheit (19), eingerichtet zum: o Senden (204) einer Aktivierungsbestätigung an das Gerät (2) ohne vorheriges Aushandeln und/oder Initialisieren von Parametern in der UICC (1); o Empfangen (205) eines ersten Kommandos, nach dem Senden (204) der Aktivierungsbestätigung; o Prüfen (206), ob das erste Kommando ein Wiederherstellen-Kommando ist; o Falls das Prüfen (206) ergibt, dass das erste Kommando ein Wiederherstellen-Kommando ist, Wiederherstellen (207) eines im Rahmen eines Suspendier-Kommandos im nicht-flüchtigen Speicher (17) der UICC (1) abgelegten UICC-Zustands (20); und ◯ Falls das Prüfen (206) ergibt, dass das erste Kommando ein vom Wiederherstellen-Kommando verschiedenes Kommando ist, Aushandeln und/oder Initialisieren (208) von zumindest denjenigen Parametern, die zur Bearbeitung dieses ersten Kommandos benötigt werden.
Die UICC (1) gemäß Anspruch 12, wobei das Suspendier-Kommando und das erste Kommando APDU-Kommandos (11) sind.
Die UICC (1) gemäß Anspruch 12 oder 13, weiter umfassend: - ein Betriebssystem (15), ausführbar abgelegt in dem nicht-flüchtigen Speicher (17) und eingerichtet, die Schritte der Steuereinheit (19) durchzuführen.
Ein Computerprogramprodukt ausführbar installiert in einer UICC (1) und aufweisend Mittel zum Ausführen der Verfahrensschritte des Verfahrens (200) gemäß einer der Ansprüche 1 bis 11.