DE102022002276A1

DE102022002276A1 - Verfahren in einem secure element

Info

Publication number: DE102022002276A1
Application number: DE102022002276.1A
Authority: DE
Inventors: Wolfgang Dirnberger
Original assignee: Giesecke and Devrient Mobile Security GmbH
Current assignee: GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH, DE
Priority date: 2021-08-23
Filing date: 2022-06-23
Publication date: 2023-02-23

Abstract

Die Erfindung betrifft ein Verfahren in einem Secure-Element, SE, zum Erzeugen zumindest eines symmetrischen Schlüssels und/ oder eines SE-individuellen kryptographischen Schlüsselpaars zum Erstellen und Senden einer Antwort auf eine von einem Netzwerk gesendete Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, mit den Verfahrensschritten: Erster Schritt: Erzeugen, in dem SE, von zumindest einem SE-individuellen kryptographischen Schlüsselpaar auf Basis eines ECC-Algorithmus und Ablegen des zumindest einen SE-individuellen kryptographischen Schlüsselpaars in einen nichtflüchtigen Speicher; und/oder Zweiter Schritt: Erzeugen, in dem SE, von dem zumindest einen symmetrischen Schlüssel unter Verwendung des gespeicherten privaten Schlüsselteils des ersten SE-individuellen kryptographischen Schlüsselpaars und eines öffentlichen Schlüsselteils eines Netzwerkschlüsselpaars in dem SE und Ablegen des symmetrischen Schlüssels in den nichtflüchtigen Speicher, wobei der erste Schritt und/ oder der zweite Schritt bereits vor dem Erhalten der von dem Netzwerk gesendeten Identitätsabfrage ausgeführt wird, wobei der im ersten Schritt erzeugte öffentliche Schlüsselteil des SE-individuellen kryptographischen Schlüsselpaars und der im zweiten Schritt erzeugte symmetrische Schlüssel zum Erstellen und Senden der Antwort auf die vom Netzwerk gesendeten Identitätsabfrage verwendet werden, wobei der Start des zweiten Schritts zeitlich entkoppelt nach der Ausführung des ersten Schritts ausgeführt wird. Die Erfindung betrifft zudem ein SE, ein Computerprogrammprodukt und ein System aufweisend ein SE und ein Netzwerk.

Description

TECHNISCHES GEBIET DER ERFINDUNG
Die Erfindung bezieht sich auf verschiedene Verfahren in einem Secure Element, SE, bevorzugt einem Teilnehmeridentitätsmoduls der fünften Generation, ein entsprechendes SE, ein Computerprogrammprodukt und ein System aufweisend ein SE und ein Netzwerk.
Zur Nutzung von Diensten 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 Internets-der-Dinge, englisch: Intemet-of-Things, kurz: IoT, ein SE. In dem SE sind Identitätsdaten (Teilnehmeridentitätsdaten, Teilnehmerkennung, Subskription) abgelegt, um einen Teilnehmer (Person oder Gerät) für die Nutzung eines Diensts eines Kommunikationsnetzes 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
Die Welt ist mobil vernetzt, und die mobile Vernetzung schreitet weiter. Mobilfunkfähige Endgeräte kommunizieren über Mobilfunknetze.
Zur Nutzung eines mobilfunkfähigen Endgeräts, wie Smartphone oder Mobiltelefon, in einem Mobilfunknetzwerk eines Netzbetreibers enthält das Endgerät ein SE, das zumindest eine Subskription enthält. Die Subskription umfasst beispielsweise einen kryptographischen Authentisierungs-Schlüssel, Ki, und eindeutige Identitätsdaten, wie International Mobile Subscriber Identity, IMSI oder die Network Specific ID, NSI. Die USIM-Applikation bewerkstelligt Aufbau, Betrieb und Abbau von Verbindungen des Endgeräts im Mobilfunknetz, unter Verwendung der Identitätsdaten.
In der Standardisierung für Kommunikationsnetzwerke der 2. bis 4. Generation wurde die IMSI für ein Einbuchen des Endgeräts in das Kommunikationsnetz vom Netzwerk abgefragt. Das Endgerät bzw. das SE sendet daraufhin die IMSI unverschlüsselt, also im Klartext, in einer NAS-Nachricht. Diese unverschlüsselte IMSI stellt ein Sicherheitsproblem dar, denn sogenannte IMSI-Abfang-Geräte (IMSI-Catcher) können diese IMSI abfangen, um eine Position des Endgeräts zu orten.
Zur Vermeidung von IMSI-Catcher-Angriffen, wurde für das Kommunikationsnetzwerk der 5. Generation festgelegt, dass jegliche Identitätsdaten zum Einbuchen in das Netzwerk verschlüsselt zu übertragen sind, siehe beispielsweise ETSI TS 102 221 Version 15 oder 3GPP TS 31.102 Version 15 oder 3GPP TS 33.501 Version 15. In diesen 5G-Netzwerken werden die Identitätsdaten (insbesondere IMSI, NSI) als SUbscription Permanent Identifier, SUPI, bezeichnet und im 5G-Netzwerk verschlüsselt als SUbscription Concealed Identifier, SUCI, übertragen, siehe Punkte 5.2.5 und 6.12 in der 3GPP TS 33.501, Version 15.2.0.
Zur Identifizierung und Authentisierung im Netzwerk kann das Netzwerk eine Identitätsabfrage oder gegebenenfalls eine Registrierungsabfrage stellen. Eine Registrierungsabfrage beinhaltet eine Identitätsabfrage, ihr Ablauf ist prinzipiell in der 3GPP TS 23.501 beschrieben. Eine Identitätsabfrage muss innerhalb eines kurzen Zeitrahmens, beispielsweise binnen 6 Sekunden, erwidert werden. In dieser Zeit müssen die Identitätsdaten aufwendig verschlüsselt und an das Netzwerk als Antwort auf die Identitätsfrage gesendet werden.
Die Verschlüsselung der SUPI zu einer SUCI ist rechen- und zeitaufwendig, da aufwendige Verschlüsselungsalgorithmen vorgesehen sind, siehe etwa C.3.2.1 der 3GPP TS 33.501, Version 15.2.0. Es hat sich herausgestellt, dass der dafür auch mit Blick auf die Anwenderfreundlichkeit vorgegebene Zeitrahmen knapp bemessen ist und insbesondere von ressourcenschwachen SE kaum erfüllt werden kann. Wird der Zeitrahmen nicht eingehalten („timeout“) gilt die Identitätsabfrage als nicht beantwortet, eine Netzeinbuchung kann dann nicht erfolgen.
In einem Lösungsansatz werden ressourcenstärkere SE eingesetzt, die beispielsweise einen Krypto-Co-Prozessor oder einen Multiplikationsbeschleuniger aufweisen. Diese SE sind teuer.
Um den vorgegebenen Zeitrahmen einzuhalten, wird in der WO 2019 / 068 731 A1 vorgeschlagen, die SUCI komplett vorab zu berechnen und in einem SE abzuspeichern. In Erwiderung auf eine im Rahmen der regulären Nutzung des SE erhaltene Identitätsabfrage des Netzwerks wird dann eine komplett vorberechnete SUCI aus dem Speicher des SE geladen und in einer Antwort auf die Identitätsabfrage verwendet. Eine solche permanente Speicherung der SUCI ist aber ein Sicherheitsrisiko. Sie setzt zudem voraus, dass die in die Berechnung der SUCI einfließenden Parameter stets unverändert bleiben. Das ist aber nicht immer der Fall.
ZUSAMMENFASSUNG DER ERFINDUNG
Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren in einem SE anzubieten, bei dem die Berechnungszeit zum Erstellen und Senden einer Antwort auf die Identitätsabfrage eines Netzwerks verkürzt werden kann, ohne dass die dazu benötigten verschlüsselten Identitätsdaten vorab permanent abgespeichert werden. Dabei soll auch ein mehrfaches Erstellen und Senden einer Antwort auf eine oder mehrere Identitätsabfragen des Netzwerks in verkürzter Zeit ermöglicht werden. Weiter ist es eine Aufgabe der Erfindung die Ausführungsschritte, die vor einer Identitätsabfrage ausgeführt werden und ein verkürztes Erstellen und Senden einer Antwort auf die Identitätsabfrage ermöglichen, an eine Ressourcenauslastung des SE anzupassen und damit die Ausführung anderer Aufgaben, Tasks oder Programme auf dem SE nicht zu blockieren. Auf ressourcenstarke SE (mit entsprechender Krypto-Prozessor-Arithmetik oder Multiplikationsbeschleuniger, zum Beispiel Montgomery, etc.) soll aus Kostengründen verzichtet werden.
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 in einem Secure-Element, SE, zum Erzeugen zumindest eines symmetrischen Schlüssels und/ oder eines SE-individuellen kryptographischen Schlüsselpaars zum Erstellen und Senden der Antwort auf die von dem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, mit den folgenden Verfahrensschritten angegeben: Erster Schritt: Erzeugen, in dem SE, von zumindest einem SE-individuellen kryptographischen Schlüsselpaar auf Basis eines ECC-Algorithmus und Ablegen des zumindest einen SE-individuellen kryptographischen Schlüsselpaars in einen nichtflüchtigen Speicher; und/ oder Zweiter Schritt: Erzeugen, in dem SE, von dem zumindest einen symmetrischen Schlüssel unter Verwendung des gespeicherten privaten Schlüsselteils des ersten SE-individuellen kryptographischen Schlüsselpaars und eines öffentlichen Schlüsselteils eines Netzwerkschlüsselpaars in dem SE und Ablegen des symmetrischen Schlüsselteils in den nichtflüchtigen Speicher, wobei der erste Schritt und/ oder der zweite Schritt bereits vor dem Erhalten der von dem Netzwerk gesendeten Identitätsabfrage ausgeführt wird, wobei der erzeugte symmetrische Schlüssel zum Erstellen und Senden der Antwort auf die vom Netzwerk gesendeten Identitätsabfrage verwendet wird, wobei der Start der Ausführung des zweiten Schritts zeitlich entkoppelt nach der Ausführung des ersten Schritts erfolgt.
Mit diesem Verfahren werden Teilschritte zum Erstellen und Senden der Antwort auf die Identitätsabfrage des Netzwerks bereits vor dem Erhalt der Identitätsabfrage ausgeführt. Durch die Ausführung der Teilschritte werden Teilrechenergebnisse, die zum Erstellen und Senden der Antwort auf die Identitätsabfrage des Netzwerks verwendet werden, auf dem SE oder dem Endgerät abgelegt. Wird eine Identitätsabfrage des Netzwerks im SE erhalten, werden nur noch die letzten Rechenschritte zum Erstellen und Senden der Antwort auf die Identitätsabfrage des Netzwerks ausgehend von den abgelegten Teilrechenergebnissen berechnet. Diese letzten Rechenschritte können in kurzer Zeitdauer ausgeführt werden und gefährden eine zu unterschreitende Gesamtzeitdauer zum Senden der Antwort auf die Identitätsabfrage nicht.
Der Rechen- und damit auch der Zeitaufwand zum Erstellen und Senden einer Antwort mit verschlüsselten Identitätsdaten bei Erhalt der Identitätsabfrage des Netzwerks ist damit stark verringert.
Es können im Ergebnis viel einfachere und damit kostengünstigere SE im 5G Netzwerk betrieben werden, da ein Co-Prozessor zur Berechnung der SUCI nun nicht mehr notwendig ist, um die maximale Zeitdauer zur Antwort auf eine Identitätsabfrage einzuhalten. Mit Hilfe von Vorberechnungen von Schlüsseln können technische Spezifikationen gemäß 3GPP und ETSI eingehalten werden und die Leistung zur Erwiderung/ Abarbeitung einer Identitätsabfrage wird deutlich gesteigert.
Bevorzugt wird das SE-individuelle kryptographische Schlüsselpaar vor dem Erhalt der Identitätsabfrage von dem SE erzeugt. Das SE-individuelle kryptographische Schlüsselpaar umfasst den privaten Schlüsselteil (zum Erzeugen des symmetrischen Schlüssels) und einen öffentlichen Schlüsselteil. Der öffentliche Schlüsselteil ist bevorzugt Teil der Antwort auf die Identitätsabfrage und wird im Senden-Schritt des Erstellen und Senden der Antwort auf die Identitätsabfrage des Netzwerks in die Antwort integriert. Der öffentliche Schlüsselteil kann der „Eph. public key of UE“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein.
Dieses Erzeugen kann dem Schritt „1. Eph. key pair generation“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 entsprechen, mit dem Unterschied, dass dieses Schlüsselpaar bereits vor dem Erhalt der Identitätsabfrage des Netzwerks erzeugt wurde. Das Erzeugen kann auf Basis einer Verschlüsselung mit elliptischen Kurven erfolgen, beispielsweise nach einem „Elliptic Curve Integrated Encryption Scheme, ECIES“, beispielsweise nach einem Curve25519-Algorithmus nach RFC7748 oder einem secp256r1-Algorithmus nach SEC-2-Standard. Die Parameter des ECIES können beispielsweise dem Anhang C3.4 der 3GPP TS 33.501, Version 15.2.0 entnommen werden.
Allein das Erzeugen des SE-individuellen kryptographischen Schlüsselpaars kann im SE eine gewisse Zeit, beispielsweise mehr als 1 Sekunde oder mehr als 2 Sekunden oder mehr als 3 Sekunden dauern. Durch das Erzeugen dieses SE-individuellen kryptographischen Schlüsselpaars vor dem Erhalt der Identitätsabfrage vom Netzwerk kann die Zeitdauer zum Erstellen und Senden der Antwort auf die Identitätsabfrage des Netzwerks um die Zeitdauer zum Erstellen des SE-individuellen kryptographischen Schlüsselpaars verkürzt werden, die Identitätsabfrage des Netzwerks kann damit zeitgerecht beantwortet werden.
Der symmetrische Schlüssel ist ein Schlüssel eines symmetrischen Kryptosystems, bei dem im Gegensatz zu einem asymmetrischen Kryptosystem beide Teilnehmer, hier SE und das Netzwerk, denselben Schlüssel verwenden, um Nachrichten/ Daten zu ver- bzw. entschlüsseln.
Das Erzeugen des symmetrischen Schlüssels kann dem Schritt „2. Key-Agreement“ gemäß C.3.2-1 der TS 33.501 V 15.2.0 entsprechen, mit dem Unterschied, dass dieser symmetrische Schlüssel bereits vor dem Erhalt der Identitätsabfrage erzeugt wird. Das Erzeugen kann auf Basis von Schlüsseln einer elliptischen Kurve erfolgen, beispielsweise nach einem „Elliptic Curve Integrated Encryption Scheme, ECIES“, beispielsweise nach einem Curve25519-Algorithmus nach RFC7748 oder einem secp256r1-Algorithmus nach SEC 2-Standard. Die Parameter des ECIES können beispielsweise dem Anhang C3.4 der 3GPP TS 33.501, Version 15.2.0 entnommen werden.
Der symmetrische Schlüssel kann unter Verwendung eines öffentlichen Schlüsselteils eines kryptografischen Schlüsselpaars des Netzwerks erzeugt werden. Dieser öffentliche Schlüsselteil wird dem SE vorab zur Verfügung gestellt und kann ein öffentlicher Schlüsselteil eines kryptographischen Schlüsselpaars eines Netzwerkanbieters sein. Dieser öffentliche Schlüsselteil kann dem SE während einer Personalisierung des SE zur Verfügung gestellt werden.
Der symmetrische Schlüssel kann unter Verwendung eines privaten Schlüsselteils eines SE-individuellen kryptographischen Schlüsselpaars erzeugt worden sein.
Allein das Erzeugen des symmetrischen Schlüssels kann im SE eine gewisse Zeit, beispielsweise mehr als 1 Sekunde oder mehr als 2 Sekunden oder mehr als 3 Sekunden dauern. Durch das Erzeugen dieses symmetrischen Schlüssels vor dem Erhalt der Identitätsabfrage vom Netzwerk kann die Zeitdauer zum Erstellen und Senden der Antwort auf die Identitätsabfrage des Netzwerks um diese Zeitdauer zum Erstellen des symmetrischen Schlüssels verkürzt werden, die Identitätsabfrage kann damit zeitgerecht beantwortet werden.
Es ist vorgesehen, dass entweder das Erzeugen des symmetrischen Schlüssels oder das Erzeugen des SE-individuellen kryptographischen Schlüsselpaars oder das Erzeugen des symmetrischen Schlüssels und das Erzeugen des SE-individuellen kryptographischen Schlüsselpaars jeweils bereits vor dem Erhalt der Identitätsabfrage vom Netzwerk im SE durch das SE erfolgt.
Der erzeugte symmetrische Schlüssel und/ oder das erzeugte SE-individuelle kryptographische Schlüsselpaar wird in einen nichtflüchtigen Speicherbereich des SE oder des Endgeräts abgelegt und bei Ausführung des Verfahrens aus dem Speicherbereich des SE geladen. Bei dem Speicherbereich handelt es sich um einen Speicherbereich eines nichtflüchtigen Speichers, vorzugsweise werden in den Speicherbereich Objekte vom Typ „high update objects“ - kurz HUO, abgelegt. Die erfindungsgemäß erzeugten Schlüssel werden auch als Datenobjekte vom Typ HUO angesehen und werden dann auch in dem speziellen NVM-Speicherbereich abgelegt werden. Eine Maximalanzahl von Schreib-Lesezugriffen für das Ablegen und Auslesen der erfindungsgemäß erzeugten Schlüssel kann damit wesentlich erhöht werden.
Der Zeitpunkt des Erzeugens des symmetrischen Schlüssels und/ oder des Erzeugens des SE-individuellen kryptographischen Schlüsselpaars kann unmittelbar vor dem Erhalt der Identitätsabfrage des Netzwerks sein.
Der Zeitpunkt des Erzeugens des symmetrischen Schlüssels und/ oder des Erzeugens des SE-individuellen kryptographischen Schlüsselpaars kann unmittelbar vor oder nach dem Senden einer Registrierungsanfrage durch das Netzwerk sein.
Der Zeitpunkt des Erzeugens des symmetrischen Schlüssels und/ oder des Erzeugens des SE-individuellen kryptographischen Schlüsselpaars kann weit im Vorfeld des Erhalts der Identitätsabfrage des Netzwerks sein.
Der symmetrische Schlüssel und/ oder das SE-individuelle kryptographische Schlüsselpaar kann in Antwort an ein STATUS Kommando oder in Antwort an ein SELECT Kommando im SE erzeugt worden sein.
Das Erzeugen des SE-individuellen kryptographischen Schlüsselpaars in dem SE und/ oder das Erzeugen des symmetrischen Schlüssels kann vor dem Senden einer Registrierungsanfrage an das Netzwerk erfolgen.
Das Erzeugen der SE-individuellen kryptographischen Schlüsselpaare und des symmetrischen Schlüssels kann zeitlich voneinander entkoppelt erfolgen.
Mit zeitlich entkoppelt ist gemeint, dass nicht direkt nach dem Erzeugen eines SE-individuellen kryptographischen Schlüsselpaares mit dem Erzeugen eines dazugehörigen symmetrischen Schlüsselteils und/ oder nicht direkt nach dem Erzeugen eines symmetrischen Schlüsselteils mit dem Erzeugen eines weiteren SE-individuellen kryptographischen Schlüsselpaars begonnen werden muss. Somit kann in Abhängigkeit von der Ressourcenauslastung des SE und damit von der aktuellen Anzahl und Komplexität von Aufgaben, Tasks oder Programmen, die auf dem SE ausgeführt werden, das Erzeugen des SE-individuellen kryptographischen Schlüsselpaars und das Erzeugen des symmetrischen Schlüsselteils oder das Erzeugen des symmetrischen Schlüssels und eines weiteren SE-individuellen kryptographischen Schlüsselpaars zeitlich unterbrochen werden. Die Dauer dieser zeitlichen Unterbrechung kann beliebig lang oder beliebig kurz sein.
Der Task ist eine in sich geschlossene Aufgabe, die durch einen Teil des Programms oder eines ganzen Programms dargestellt wird. Ein Task kann weiter ein Prozess oder eine Aufgabe für ein Betriebssystem und damit ein Thread, (Kernel-) Thread oder User Thread sein.
Vorzugsweise wird der erste Schritt und/ oder der zweite Schritt mindestens zweimal ausgeführt, bevor im SE die von dem Netzwerk gesendete Identitätsabfrage erhalten wird.
Daher können mehrere SE-individuelle kryptographische Schlüsselpaare und/ oder symmetrische Schlüssel in einem permanenten bzw. nichtflüchtigen Speicher auf dem SE oder dem Endgerät gespeichert werden. Vorzugsweise erfolgt die Ausführung des ersten Schritts und/ oder des zweiten Schritts 10-mal, bevor das SE vom Netzwerk eine Identitätsabfrage erhält.
Dies ermöglicht, dass das SE bzw. das Endgerät hintereinander und/oder zeitlich auf mehrere Anfragen eine GET IDENTITY Kommandos in verkürzter Zeit eine Antwort erstellen und senden kann. Vorzugsweise registriert das Netzwerk, ob das Erstellen und Senden einer Antwort auf ein GET IDENTITY Kommando eine maximale Zeitspanne überschritten hat und sendet gegebenenfalls erneut eine Registrierungsanfrage an das SE. Basierend auf den im nichtflüchtigen Speicher abgelegten SE-individuellen kryptographischen Schlüsselpaaren und/ oder symmetrischen Schlüsseln kann das SE bzw. das Endgerät direkt erneut in verkürzter Zeit eine Antwort auf das GET IDENTITY Kommando erstellen und senden. Die maximale Zeitspanne ist vorzugsweise die maximale Zeitdauer, die das Netzwerk erlaubt, um eine Identitätsantwort auf die Identitätsabfrage zu erhalten. Vorzugsweise ist bei der Bestimmung der maximalen Zeitdauer die Dauer zum Übertragen der Identitätsabfrage vom Netzwerk zum Endgerät bzw. zum SE und der Identitätsantwort vom Endgerät bzw. vom SE zum Netzwerk mitberücksichtigt.
Vorzugsweise kann die Ausführung des ersten Schritts und/ oder des zweiten Schritts zumindest zeitweise pausiert und/ oder abgebrochen werden, wenn zumindest ein weiterer Task auf dem SE ausgeführt wird.
Mit Pausieren ist eine zeitlich begrenzte Unterbrechung eines Vorgangs gemeint. In diesem Fall ist der Vorgang das Ausführen des ersten und/ oder des zweiten Schritts. Daher kann der erste Schritt und/ oder der zweite Schritt zeitlich begrenzt unterbrochen werden, wenn zumindest ein weiterer Task auf dem SE ausgeführt wird. Dabei kann das Pausieren beliebig lang oder kurz dauern.
Damit werden weitere Tasks, die beispielsweise auf dem SE ausgeführt werden müssen, nicht von der Ausführung des ersten Schritts und/ oder zweiten Schritts blockiert. Dies ist vor allem vorteilhaft, wenn bereits zumindest ein symmetrischer Schlüssel und/ oder ein SE-individuelles kryptographisches Schlüsselpaar im nichtflüchtigen Speicher vorhanden ist. Denn durch den bereits im nichtflüchtigen Speicher vorhandenen symmetrischen Schlüssel, kann bereits Rechenzeit beim Erstellen und Senden einer Antwort auf die Identitätsabfrage des Netzwerks eingespart werden.
Vorzugsweise wird in Abhängigkeit einer Priorisierung bestimmt wird, ob der erste Schritt und/ oder der zweite Schritt ausgeführt und/ oder pausiert und/ oder abgebrochen wird, um zumindest einen weiteren Task auszuführen.
Die Priorisierung bestimmt eine Priorität, mit der der erste Schritt und/ oder der zweite Schritt im Vergleich zu anderen Aufgaben, Tasks oder Programmen auf dem SE ausgeführt werden. Umso höher die Priorität des ersten Schritts und/ oder des zweiten Schritts gewählt wird, umso eher wird die Ausführung des ersten Schritts und/ oder des zweiten Schritts der Ausführung von anderen Aufgaben, Tasks oder Programmen vorgezogen.
Die Priorität des ersten Schritts und/ oder des zweiten Schritts im Vergleich zu zumindest einer weiteren Aufgabe, eines weiteren Tasks oder Programms auf dem SE kann von der Anzahl der bereits im nichtflüchtigen Speicher abgelegten SE-individuellen kryptographischen Schlüsselpaare und/ oder von der Anzahl der bereits im nichtflüchtigen Speicher abgelegten symmetrischen Schlüssel abhängen.
Vorzugweise wird die Priorisierung des ersten Schritts und/ oder des zweiten Schritts im Vergleich zu zumindest einer weiteren Aufgabe, eines weiteren Tasks oder Programms auf dem SE derart gewählt, das die Priorität umso niedriger im Vergleich zu anderen vom den SE ausgeführten Tasks oder Programmen wird, je mehr SE-individuelle kryptographische Schlüsselpaare und/ oder symmetrische Schlüssel bereits auf dem SE in einem nichtflüchtigen Speicher, beispielsweise SSDs, EPROM, Flash-Speicher abgelegt wurden. Alternativ kann die Priorität aber auch von und/oder bis zu einer Anzahl von bereits erzeugten symmetrischen Schlüsseln gleich gewählt werden.
Dies ermöglicht, dass der erste symmetrische Schlüssel und/ oder das erste SE-individuelle kryptographische Schlüsselpaar, sehr zeitnah im nichtflüchtigen Speicher abgelegt wird. Damit steigt die Wahrscheinlichkeit, dass bei der ersten Identitätsabfrage des Netzwerks bereits zumindest ein symmetrischer Schlüssel und/ oder zumindest ein erstes SE-individuelles kryptographisches Schlüsselpaar zum Erstellen und Senden der Antwort auf die Identitätsabfrage im nichtflüchtigen Speicher des SE abgelegt wurde. Das weitere Erzeugen von symmetrischen Schlüsseln und/ oder SE-individuellen kryptographischen Schlüsselpaaren kann mit niedrigerer Priorität erfolgen. Es können aber auch mehrere symmetrische Schlüssel und/ oder SE-individuelle kryptographische Schlüsselpaare mit hoher Priorität erzeugt werden. Die Priorität hängt beispielsweise davon ab, wie viele Registrierungsanfragen und/ oder wie viele Identitätsabfragen das Netzwerk an das Endgerät bzw. das SE stellt und/ oder vom Netzwerk erwartet werden.
Vorzugsweise führt das SE ein Verfahren zum Erstellen und Senden einer Antwort auf eine von einem Netzwerk gesendete Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, mit den folgenden Verfahrensschritten durch: Erhalten, im SE, der von dem Netzwerk gesendeten Identitätsabfrage; Prüfen, ob zumindest ein gültiger symmetrischer Schlüssel oder zumindest ein gültiger öffentlicher Schlüsselteil eines Netzwerkschlüsselpaars im nichtflüchtigen Speicher vorhanden ist; Erzeugen des symmetrischen Schlüssels durch das Ausführen eines zweiten Schritts, wenn im Prüfen-Schritt kein gültiger symmetrischer Schlüssel jedoch zumindest ein gültiger öffentlicher Schlüsselteil eines Netzwerkschlüsselpaars im nichtflüchtigen Speicher vorhanden ist, wobei der zweite Schritt ein Erzeugen, in dem SE, von dem zumindest einen symmetrischen Schlüssel unter Verwendung eines gespeicherten privaten Schlüsselteils des ersten SE-individuellen kryptographischen Schlüsselpaars und eines öffentlichen Schlüsselteils eines Netzwerkschlüsselpaars in dem SE umfasst; oder Erzeugen des symmetrischen Schlüssels durch das Ausführen eines ersten Schritts und des zweiten Schritt, in dem SE, wenn im Prüfen-Schritt kein gültiger symmetrischer Schlüssel und kein gültiger öffentlicher Schlüsselteil eines Netzwerkschlüsselpaars im nichtflüchtigen Speicher vorhanden ist, wobei der erste Schritt ein Erzeugen, in dem SE, von dem zumindest einen SE-individuellen kryptographischen Schlüsselpaar auf Basis eines ECC-Algorithmus umfasst; Verschlüsseln von auf dem SE gespeicherten Identitätsdaten durch das SE, zum Erzeugen von verschlüsselten Identitätsdaten unter Verwenden des in einem der vorherigen Erzeugen-Schritte erzeugten symmetrischen Schlüssel oder von einem symmetrischen Schlüssel, der im nichtflüchtigen Speicher vorhanden ist; Anwenden eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten durch das SE zum Erhalten eines MAC; und Senden einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Antwort den öffentlichen Schlüsselteil des SE-individuellen kryptographischen Schlüsselpaares, dessen privates Schlüsselteil des SE-individuellen kryptographischen Schlüsselpaars zum Erstellen des symmetrischen Schlüssels verwendet wurde, der wiederum zum Erstellen der Antwort verwendeten wurde, die verschlüsselten Identitätsdaten, und den MAC enthält.
In dem Prüfen-Schritt wird vom SE geprüft, ob sich Systembedingungen so geändert haben, dass das SE-individuelle kryptographische Schlüsselpaar und/ oder der symmetrische Schlüssel nicht mehr gültig ist.
Zum Beispiel könnte sich der verwendete öffentliche Schlüsselteil des kryptografischen Schlüsselpaars des Netzwerks zum Erzeugen des symmetrischen Schlüssels zwischenzeitlich geändert haben, wodurch der symmetrische Schlüssel ungültig wäre und neu berechnet werden muss. Oder es ist möglich, dass der ECC Algorithmus zum Erzeugen des SE-individuellen kryptographischen Schlüsselpaars im ersten Schritt nicht mehr gültig ist, da sich beispielsweise der ECC Algorithmus geändert hat, wodurch neue Schlüsselpaare und damit neue symmetrische Schlüssel berechnet werden müssen.
Eine Änderung nur des öffentlichen Schlüsselteils eines Netzwerkschlüsselpaars ohne Algorithmusänderung bedingt lediglich die Durchführung des zweiten Schrittes zur Neuberechnung der symmetrischen Schlüssel, da die kryptographischen Schlüsselpaare unverändert nach wie vor noch gültig sind.
Der vorab erzeugte symmetrische Schlüssel wäre damit ab dem Zeitpunkt der Änderung/ Aktualisierung des öffentlichen Schlüsselteils des kryptografischen Schlüsselpaars des Netzwerks und/ oder einer geänderten Verschlüsselung im ersten und/ oder zweiten Schritt ungültig. Eine mit diesem ungültigen Schlüssel erzeugte Antwort auf die Identitätsabfrage des Netzwerks wäre somit ebenfalls ungültig, da die Antwort nicht entschlüsselt werden kann, die Einbuchung ins Netzwerk würde fehlschlagen.
Mit dem Prüfen-Schritt wird dieser Fehlerfall verhindert. Wird festgestellt, dass sich gegenüber dem letztmaligen Erzeugen eines symmetrischen Schlüssels der öffentliche Schlüsselteil des kryptografischen Schlüsselpaars des Netzwerks oder der Algorithmus zum Erzeugen des SE-individuellen kryptographischen Schlüsselpaars geändert haben, wird das Verfahren zum Erzeugen der Antwort basierend auf dem zweiten Schritt und/ oder dem ersten Schritt und dem zweiten Schritt auf die Identitätsabfrage ausgeführt.
Liegt kein gültiger öffentlicher Schlüsselteil des kryptografischen Schlüsselpaars und damit kein gültiger symmetrischer Schlüssel vor kann durch Ausführen nur des zweiten Schritts mittels eines gültigen privaten Teils des SE-individuellen kryptographischen Schlüsselpaars, und einem aktuellen gültigen öffentlichen Schlüsselteil des kryptografischen Schlüsselpaars des Netzwerks ein neuer symmetrischer Schlüssel erzeugt werden. Damit wird zumindest die Zeit zum Ausführen des ersten Schritts gespart. Der symmetrische Schlüssel kann bei diesem Erzeugen-Schritt auch in einem flüchtigen Speicher, beispielsweise im RAM, abgelegt werden.
Liegt kein gültiger privater Teil des SE-individuellen kryptografischen Schlüsselpaars im nichtflüchtigen Speicher, wird durch das Ausführen des ersten Schritts und des zweiten Schritts zunächst ein SE-individuelles kryptographisches Schlüsselpaar und darauf aufbauend mithilfe eines gültigen öffentlichen Schlüsselteils eines kryptografischen Schlüsselpaars ein symmetrischer Schlüssel erzeugt. Das SE-individuelle kryptographische Schlüsselpaar und/ oder der symmetrische Schlüssel können bei diesem Erzeugen-Schritt auch im flüchtigen Speicher beispielsweise im RAM abgelegt werden. Damit wird sichergestellt, dass nur wenn kein symmetrischer Schlüssel und kein gültiges SE-individuelles kryptografisches Schlüsselpaar im nichtflüchtigen Speicher abgelegt ist, diese auf eine Identitätsabfrage neu erstellt werden. Ansonsten kann eine niedrigere Rechenzeit erzielt werden. Weiter ermöglicht dieser Erzeugen-Schritt dass immer ein gültiger Schlüssel vorliegt, damit die Antwort auf die Identitätsabfrage des Netzwerks nicht ungültig wird, indem eine Antwort nicht entschlüsselt werden kann und damit die Einbuchung ins Netzwerk fehlschlägt.
Der Verschlüsseln-Schritt kann dem Schritt „4. Symmetrie Encryption“ gemäß C.3.2-1 der TS 33.501 V 15.2.0 entsprechen, mit dem Unterschied, dass dieser symmetrische Schlüssel bereits vor dem Erhalt der Identitätsabfrage erzeugt wird. Das Ergebnis des Verschlüsseln-Schritts ist beispielsweise der „Cipher-text value“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0.
Als Eingangsparameter dieses Verschlüsseln-Schritts können die Identitätsdaten aus einem Speicher des SE geladen werden. Diese Identitätsdaten sind unverschlüsselt. In einem 5G-Netzwerk werden die Identitätsdaten beispielsweise als SUPI bezeichnet. Die SUPI beinhaltet die IMSI oder den NSI, welche zur Identifikation im 5G Netzwerk verwendet wird. Die (unverschlüsselten) Identitätsdaten stellen die zu verschlüsselnden Daten dar und besteht zumindest aus Teilen der IMSI. Die (unverschlüsselten) Identitätsdaten können dem „Plain Text Block“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 entsprechen.
Die unverschlüsselten Identitätsdaten können in zumindest einer Datei des SE abgelegt sein, wobei zumindest eine Datei bevorzugt, die Datei EF_IMSI oder EF_NSI ist, die eine internationale Mobilfunk-Teilnehmerkennung, IMSI/NSI, beinhaltet, wobei bevorzugt die Antwort auf die Identitätsabfrage eine Subscription Concealed Identifier-, SUCI-, umfasst.
Der Anwenden-Schritt kann dem Schritt „5. MAC Function“ gemäß C.3.2-1 des Standards TS 33.501 V 15.2.0 entsprechen. Ein Nachrichtenauthentifizierungscode, englisch Message Authentication Code, kurz MAC, dient dazu, Gewissheit über den Ursprung der Identitätsdaten zu erhalten und ihre Integrität zu überprüfen. Der MAC wird gemäß dem Standard über die verschlüsselten Daten erzeugt. Der Empfänger, d.h. das Netzwerk verwendet den MAC, um den beim Netzwerk erzeugten symmetrischen Schlüssel zu überprüfen, indem das Netzwerk den MAC mit dem erzeugten symmetrischen Schlüssel nachrechnet und mit dem erhaltenen MAC vergleicht. Der MAC-Algorithmus benötigt das Ergebnis des Verschlüsseln-Schritts und einen geheimen Schlüssel, beispielsweise dem „Eph. Mac Key“ gemäß C.3.2-1 der TS 33.501 V 15.2.0, als Eingangsparameter und berechnet aus beidem eine Prüfsumme, den erhaltenen MAC, beispielsweise den „MAC-tag value“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0.
Der symmetrische Schlüssel kann vor dem Verwenden im Verschlüsseln-Schritt noch aufgeteilt werden, beispielsweise in einen ersten Teilschlüssel, der im Verschlüsseln-Schritt zum Erzeugen der verschlüsselten Identitätsdaten verwendet wird und in einen zweiten Teilschlüssel, der im Anwenden-Schritt zum Erzeugen des MAC verwendet wird. Dieses Aufteilen kann dem Schritt „3. Key Derivation“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 entsprechen. Der erste Teilschlüssel kann der „Eph. enc Key, ICB“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein. Der zweite Teilschlüssel kann der „Eph. mac Key“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein. Bei diesem Aufteilen kann eine Schlüssellänge angepasst werden.
Das SE muss nun keinen Verschlüsselungs-Co-Prozessor und auch keinen Multiplikationsbeschleuniger mehr aufweisen. Diese Art von SE benötigt einen besonders großen Zeitrahmen, beispielsweise mehr als 2 Sekunden oder mehr als 3 Sekunden oder mehr als 4 Sekunden oder mehr als 5 Sekunden zum Erstellen und Senden einer Antwort nach dem konventionellen Verfahren. Das Vorab-Erzeugen des symmetrischen Schlüssels und/ oder das Vorab-Erzeugen des SE-individuellen kryptografischen Schlüsselpaars kann diesen Zeitrahmen signifikant verringern und so Abweisungen des Netzwerks wegen Zeitüberschreitung zum Senden einer Antwort auf eine Identitätsabfrage verhindern.
Vorzugsweise erkennt das Netzwerk, ob das Erstellen und Senden der Antwort auf die von dem Netzwerk gesendete Identitätsabfrage eine maximale Zeitdauer überschreitet oder stellt fest, dass die Identitätsabfrage vom Netzwerk bereits nicht angenommen wurde. In diesem Fall sendet das Netzwerk erneut einer Registrierungsanfrage an das SE und das SE reagiert durch erneutes Erstellen und Senden einer Antwort nach dem vorgehend beschriebenen Verfahren auf ein Erhalten einer von dem Netzwerk gesendeten Identitätsabfrage
Vorzugsweise registriert das Netzwerk, dass das Erstellen und Senden einer Antwort auf ein GET IDENTITY Kommando eine maximale Zeitspanne überschritten hat und sendet erneut eine Registrierungsanfrage an das SE. Basierend auf den im nichtflüchtigen Speicher abgelegten SE-individuellen kryptographischen Schlüsselpaaren und/ oder der symmetrischen Schlüssel kann das SE und/ oder das Endgerät direkt erneut in verkürzter Zeit eine Antwort auf das GET IDENTITY Kommando erstellen und senden. Hat das SE keinen weiteren gültigen symmetrischen Schlüssel wird vorzugweise direkt nach dem Senden der erneuten Registrierungsanfrage mit dem Ausführen des ersten und /oder zweiten Schritts begonnen.
Die maximale Zeitspanne ist vorzugsweise die maximale Zeitdauer, die das Netzwerk erlaubt, um eine Identitätsantwort auf die Identitätsabfrage zu erhalten. Vorzugsweise ist bei der Bestimmung der maximalen Zeitdauer die Dauer zum Übertragen der Identitätsabfrage vom Netzwerk zum Endgerät bzw. zum SE und die Dauer zum Übertragen der Identitätsantwort vom Endgerät bzw. vom SE zum Netzwerk mitberücksichtigt.
Damit kann bei zeitlich längerer Dauer zum Erstellen und Senden der Antwort auf die Identitätsabfrage des Netzwerks, beispielsweise durch ein schlechtes Modem, schlechten Empfang oder durch höher priorisierte Tasks oder Aufgaben auf dem SE direkt eine neue Identitätsabfrage gestellt werden, ohne dass eine Fehlermeldung des Netzwerks abgewartet werden muss.
Zweckmäßig wird der symmetrische Schlüssel und/ oder der öffentliche Teil und/ oder der private Teil des SE-individuellen kryptographischen Schlüsselpaars gelöscht, nachdem zumindest einer dieser Schlüssel zum Erstellen und Senden der Antwort auf die von dem Netzwerk gesendeten Identitätsabfrage verwendet wurde.
Beispielsweise wird der symmetrische Schlüssel und/ oder das SE-individuelle kryptographische Schlüsselpaar gelöscht, nachdem die Schlüssel zum Erstellen und Senden einer Antwort verwendet wurden. Beispielsweise ist es auch möglich den privaten Teil des SE-individuellen kryptographischen Schlüsselpaars zu löschen, nachdem dieser zum Erstellen eines symmetrischen Schlüssels verwendet wurde. Alternativ zum Löschen, können die Schlüssel beispielsweise auch als bereits verwendet markiert werden und beispielsweise für eine weitere Überprüfung im nichtflüchtigen Speicher verbleiben.
Vorzugsweise wird nur ein neuer symmetrischer Schlüssel und/ oder ein neues SE-individuelles kryptographisches Schlüsselpaar erstellt und im nichtflüchtigen Speicher abgelegt, wenn eine maximale Anzahl von symmetrischen Schlüsseln und/ oder SE-individuellen kryptographischen Schlüsselpaaren im nichtflüchtigen Speicher noch nicht überschritten ist und/ oder ein Speicherplatzbedarf für die symmetrischen Schlüssel und/ oder die SE-individuellen kryptographischen Schlüsselpaare einen vordefinierten Speicherplatz im nichtflüchtigen Speicher noch nicht überschreitet.
Damit wird sichergestellt, dass die Anzahl der vorgehaltenen symmetrischen Schlüssel und/ oder die Anzahl der vorgehaltenen SE-individuellen kryptographischen Schlüsselpaare begrenzt ist und beispielsweise den vordefinierten Speicherplatz nicht überschreitet. Weiter kann festgelegt werden, welcher vordefinierte Speicherplatz von den symmetrischen Schlüsseln und/ oder den SE-individuellen kryptographischen Schlüsselpaaren im nichtflüchtigen Speicher eingenommen werden darf.
Vorzugsweise wird die maximale Anzahl der zu erzeugenden symmetrischen Schlüssel und/ oder der SE-individuellen kryptographischen Schlüsselpaare bei einer Initialisierung und/ oder einer Aktivierung der SE oder des Endgeräts festgelegt und/ oder der vordefinierte Speicherplatz im nicht flüchtigen Speicher bei der Initialisierung und/ oder der Aktivierung reserviert.
Dadurch kann bei der Initialisierung und/ oder der Aktivierung der SE oder des Endgeräts die Größe des vordefinierten Speicherplatzes geändert werden bzw. definiert werden, die für das Ablegen der symmetrischen Schlüssel und/ oder der SE-individuellen kryptographischen Schlüsselpaare reserviert ist, um das SE und/ oder das Endgerät an neue Bedingungen, wie zum Beispiel neue Netzwerke, anzupassen.
Vorzugsweise weist das SE keinen Verschlüsselungs-Co-Prozessor und/ oder keinen Multiplikationsbeschleuniger auf, um Kosten bei der Herstellung des Endgeräts bzw. bei der verwendeten SE zu sparen.
Vorzugsweise erfolgt die Ausführung des ersten Schritts und/ oder des zweiten Schritts nach einem Erhalten eines STATUS Kommando oder eines SELECT Kommando in dem SE mindestens einmal.
Damit ist es möglich, dass beispielsweise der Nutzer im SE, das Netzwerk im SE oder das Endgerät im SE die Ausführung des ersten und/ oder des zweiten Schritts triggern kann, um die Ausführung auf den Wunsch des Nutzers, durch Anfragen vom Netzwerk oder aufgrund von internen Prozessen auf dem Endgerät anzupassen.
In einem weiteren Aspekt der Erfindung ist ein Secure Element, bevorzugt ein Teilnehmeridentitätsmodul der fünften Generation, vorgesehen. Das SE weist auf: eine Schnittstelle, eingerichtet zum Erhalten einer von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos; einen nicht-flüchtigen Speicher, eingerichtet zum Ablegen von Identitätsdaten, bevorzugt in zumindest einer Datei; und eine Steuereinheit, die zum Ausführen von mindestens einem der vorhergehend beschriebene Verfahrensschritte eingerichtet ist.
Das SE kann weiter umfassen ein Betriebssystem, ausführbar abgelegt in dem nicht-flüchtigen Speicher und dazu eingerichtet, wenn in der Steuereinheit ausgeführt, die Verfahrensschritte der vorhergehend beschriebenen Verfahren durchzuführen.
In einem weiteren Aspekt ist ein Computerprogramprodukt ausführbar in einem SE installiert, bevorzugt einem Teilnehmeridentitätsmodul der fünften Generation, und weist Mittel zum Ausführen der Verfahrensschritte der vorhergehend beschriebenen Verfahren auf.
In einem weiteren Aspekt ist ein System vorgesehen, aufweisend ein SE, bevorzugt ein Teilnehmeridentitätsmodul der fünften Generation, und ein Netzwerk, wobei das System zum Ausführen der Verfahrensschritte der vorhergehend beschriebenen Verfahren eingerichtet ist.
Bei einem SE im Sinne der Erfindung handelt es sich um ein in Baugröße und Ressourcenumfang reduziertes elektronisches Modul, welches eine Steuereinheit (Mikrocontroller) aufweist.
Der Begriff „SE“ ist synonym zum Begriff „UICC“, „eUICC“, „Teilnehmeridentitätsmodul“, „Chipkarte“, „iUICC“, „Integrated eUICC“, „Integrated Secure Element“, „embedded Secure Element“, „Secure Element“ oder „SIM“. Bei dem SE handelt es sich beispielsweise um eine Chipkarte oder eine SIM-Karte oder ein Teilnehmeridentitätsmodul. Das SE dient dazu, mit den im sicheren nicht-flüchtigen Speicherbereich gespeicherten maschinenlesbaren Identitätsdaten einen Teilnehmer in einem Kommunikationsnetz zu identifizieren und für das Nutzen von Diensten zu authentifizieren. Unter SE sind auch USIM, TSIM, ISIM, CSIM oder R-UIM gefasst. So ist beispielsweise ein SE als eine USIM Anwendung in der ETSI TS 131 102 definiert. So ist beispielsweise ein SE als eine SIM Anwendung in der ETSI TS 151 011 definiert. So ist beispielsweise ein SE als eine TSIM Anwendung gemäß ETSI TS 100 812 definiert. So ist beispielsweise ein SE als eine ISIM Anwendung gemäß ETSI TS 131 103 definiert. So ist beispielsweise ein SE als eine CSIM Anwendung gemäß 3GPP2 C.S0065-B definiert. So ist beispielsweise ein SE als eine R-UIM Anwendung gemäß 3GPP2 C.S0023-D definiert.
Das SE kann ein integraler Bestandteil innerhalb des Endgeräts sein, beispielsweise ein fest verdrahteter elektronischer Baustein. Derartige SE werden auch als eUICC bezeichnet. In dieser Bauform sind diese SE nicht für eine Entnahme aus dem Endgerät vorgesehen und können prinzipiell nicht einfach ausgetauscht werden. Derartige SE können auch als embedded Secure Elements ausgestaltet sein und sind eine sichere Hardwarekomponente im Gerät.
Das SE kann auch eine Softwarekomponente in einem vertrauenswürdigen Teil eines Betriebssystems, einer sogenannten Trusted Execution Environment, kurz TEE, des Endgerätes sein. Das SE ist beispielsweise innerhalb einer gesicherten Laufzeitumgebung in Form von darin ablaufenden Programmen, sogenannten „Trustlets“ oder „Trusted Applications“, ausgebildet.
Das SE kann auch ein integraler Bestandteil eines größeren integrierten Schaltkreises, beispielsweise eines Modems oder Applikationsprozessors sein. Derartige SE werden als „integrated UICC“, „integrated TRE“, „integrated eUICC“ oder „Integrated SE“ bezeichnet. Derartige SE werden als integrierter Prozessorblock in ein SoC fest integriert und können über einen chipinternen Bus angebunden werden. Das SE weist beispielsweise einen internen oder externen sicheren nicht-flüchtigen Speicherbereich auf, in dem die Identitätsdaten sicher eingebracht sind, um Manipulation- und/oder Missbrauchsversuche bei der Identifizierung und/oder Authentisierung am Netzwerk zu verhindern.
Das SE kann in einer Ausgestaltung mittels eines Endgeräts betriebsfähig sein, wobei das SE in dieser Ausgestaltung bis auf Versorgungssignale, wie Versorgungsspannung, Takt, Reset etc. autark ist. Dann kann das SE eine Schnittstelle (Datenschnittstelle) zur Kommunikation mit dem Endgerät aufweisen, in das das SE ggf. betriebsbereit eingebracht ist. Diese Kommunikation erfolgt bevorzugt über ein Verbindungsprotokoll, insbesondere einem Protokoll gemäß dem Standard ETSI TS 102 221 bzw. ISO-7816.
Der Begriff „Endgerät“ wird hier bevorzugt verwendet, da das Endgerät in der Kommunikationstechnik vorrangig ein „terminal“ sein kann. Das schließt nicht aus, dass das „Endgerät“ ein „Gerät“ in einer anderen Technik sein kann. Die Begriffe „Endgerät“ und „Gerät“ werden hierbei synonym verwendet.
Das SE 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. Das SE ist beispielsweise Bestandteil der Technologie des IoT.
Bei einem Endgerä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 Endgerät wie ein Smartphone, ein Tablet-PC, ein Notebook, ein PDA unter dem Begriff zu fassen. Unter dem Endgerä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 Endgerät in einer Maschine, einem Automaten und/oder einem Fahrzeug eingebracht. Ist das Endgerät in einem Kraftfahrzeug eingebracht, hat es beispielsweise ein SE integriert. Das SE kann mittels des Endgeräts, beispielsweise eines Modems des Endgeräts, eine Datenverbindung zu einem Server über das Kommunikationsnetz aufbauen. Mit dem Endgerät kann beispielsweise ein Server des Endgeräteherstellers kontaktiert werden, um Steuereinheiten, z.B. ECUs (ECU = Electronic Control Unit) für Funktionalitäten des Endgerä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 des Betriebssystems des SE in das SE zu laden.
Zu den mobilfunkfähigen Endgeräten zählen neben den Smartphones und Mobiltelefonen auch Regelungsgeräte (Steuerungsgeräte oder Messgeräte oder kombinierte Steuer/Messgeräte) für industrielle Einrichtungen im kommerziellen oder im privaten Umfeld. Industrielle Einrichtungen sind beispielsweise Produktionsanlagen, die ein oder mehrere Regelungsgeräte (Endgeräte) haben, die über ein Mobilfunknetz mit einem Hintergrundsystem oder/und miteinander kommunizieren können. Weitere industrielle Einrichtungen sind Smart Home Einrichtung wie z.B. Heizungen oder Stromverbraucher mit Endgeräten in Gestalt von Regelungsgeräten.
Ein Kommando kann beispielsweise eine Anweisung, ein Befehl oder eine Instruktion sein, die vom Gerät gesendet wird. Das Kommando ist bevorzugt ein Kommando gemäß ETSI TS 102 221 bzw. ISO/IEC 7816 Standard. In einer bevorzugten Ausgestaltung werden Kommandos 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.
Bevorzugt ist das SE eine USIM der fünften Generation, auch als „5G USIM“ bezeichnet. Damit kann das Identifizieren eines Teilnehmers nach dem 5G-Standard erfolgen.
In einer weiter bevorzugten Ausgestaltung ist die zumindest eine Datei die EF_IMSI, die eine internationale Mobilfunk-Teilnehmerkennung, IMSI, beinhaltet. Diese IMSI gilt es zu schützen, sie sollte - wenn möglich - nicht im Klartext an das Endgerät oder im Netzwerk übertragen werden. In einem 5G-Netzwerk wird die IMSI nicht im Klartext zwischen SE und dem Kommunikationsnetz ausgetauscht.
In einer weiter bevorzugten Ausgestaltung ist die zumindest eine Datei die Datei EF_NSI, die eine permanente Teilnehmerkennung, englisch „Subscription Permanent Identifier“, kurz SUPI, beinhaltet. Diese SUPI gilt es zu schützen, sie sollte - wenn möglich - nicht im Klartext an das Endgerät oder im Netzwerk übertragen werden. Diese SUPI in der EF_NSI ist bevorzugt nicht die IMSI. Diese SUPI kann eine Netzzugangskennung, englisch „Network Access Identifier“, kurz NAI sein, wie sie im Standard 3GPP TS 23.003 definiert ist.
In einer weiter bevorzugten Ausgestaltung ist die zumindest eine Datei, die Datei EFRouting identicator, die einen Routingindikator zur SUCI-Berechnung beinhaltet. Mit Hilfe dieses Parameters kann ein Endgerät oder das SE das erfindungsgemäße Verfahren durchführen und im Ergebnis eine SUCI Erstellen und an das Netzwerk senden. Diese Datei EF_{Routing Identicator} enthält den Routingindikator, der es zusammen mit einer MCC und einem MNC ermöglicht, Netzwerksignalisierung mit SUCI an AUSF- und UDM-Instanzen weiterzuleiten, die in der Lage sind, den Teilnehmer zu bedienen, wie sie im Standard 3GPP TS 23.003 definiert ist.
Im 5G-Netz wird beispielsweise ein Subscription Permanent Identifier, kurz SUPI, als Identitätsdaten verwendet. Die SUPI ist in der 3GPP - Spezifikation TS 23.501 definiert. Ein gültiger SUPI kann dabei eine IMSI sein oder ein Network Access Identifier, kurz NAI, so wie er in der RFC 4282 in Verbindung mit 3GPP TS 23.003 definiert ist. Der SUPI kann dann unter Verwendung der 5G USIM in einen Subscription Concealed Identifier, kurz SUCI, umgewandelt werden (verschlüsseltes SUPI). Der SUCI ist eine die Privatsphäre schützende NetzwerkKennung, die den darin verborgenen SUPI enthält. Die 5G-USIM generiert eine SUCI anhand des hier beschriebenen Verfahrens und unter Verwendung dieses oben dargestellten ECIES-basierten Schutzschemas mit dem zuvor erzeugten symmetrischen Schlüssel. Die IMSI (, die Teil der SUPI ist,) wird dann verschlüsselt als SUCI in Antwort an die Identitätsabfrage des Netzwerks versendet.
Zudem sind Identitä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 Identitä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.
Ein Kommunikationsnetz (das Netzwerk) 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 der 5. Generation „5G“ als ein Kommunikationsnetz verstanden.
Figurenliste
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 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 Ablaufdiagramm eines erfindungsgemäßen Verfahrens in einem SE;
2 zeigt ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens in einem SE;
3 zeigt ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens in einem SE;
4 zeigt ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens zwischen einem SE, einem Gerät und einem Netzwerk;
5 zeigt ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens zwischen einem SE, einem Gerät und einem Netzwerk;
6 zeigt ein Ablaufdiagramm eines erfindungsgemäßen Verfahrens zwischen einem SE, einem Gerät und einem Netzwerk;
7 zeigt ein Ausführungsbeispiel eines Systems bestehend aus einem Gerät mit SE und einem Netzwerk; und
8 zeigt ein Ausführungsbeispiel eines SE.

1, 2 und 3 zeigen jeweils anhand eines Ablaufdiagrams ein Ausführungsbeispiel eines erfindungsgemäßen Verfahrens 100 mit den Schritten zum Erstellen und Ablegen 200 der Schlüssel zeitlich vor dem Empfangen einer Identitätsabfrage bzw. einer Registrierungsanfrage mit einer Identitätsabfrage und dem Erstellen und Senden 300 einer Antwort auf die Identitätsabfrage des Netzwerks in einem SE. 1, 2 und 3 werden nachfolgend zusammen beschrieben.
Ein Teil einer Routine zum Erstellen und Ablegen 200 der Schlüssel vor dem Empfangen einer Identitätsabfrage des Netzwerks sind ein erster Schritt 101 und ein zweiter Schritt 102.
Im ersten Schritt 101 (gezeigt in 1 und 2, nicht in 3) wird ein SE-individuelles kryptographischen Schlüsselpaar PubK_SE, PrivK_SE in dem SE auf Basis eines ECC-Algorithmus erzeugt. Das SE-individuelle kryptographische Schlüsselpaar PubK_SE, PrivK_SE ist abhängig von der Art der Verschlüsselung, die benutzt werden soll. Die Art der Verschlüsselung wird durch das Netzwerk festgelegt. Grundsätzlich kann sich die Art der Verschlüsselung ändern. Um sicherzustellen, dass das SE dieselbe Art Verschlüsselung benutzt wie das Netzwerk, übermittelt das Netzwerk dem SE beispielsweise eine Konfigurationsdatei, die eine Angabe über die anzuwendende kryptographische Verschlüsselung enthält. Eine Ausführung einer Konfigurationsdatei ist beispielsweise in der simalliance-Spezifikation „eUICC Profile Package: Interoperable Format“, Version 2.3.1, November 2019, Annex D, beschrieben.
Die Konfigurationsdatei wird vom SE zu bestimmten Zeitpunkten ausgelesen, etwa beim Hochfahren; zweckmäßig wird sie stets auf jeden Fall dann ausgelesen, wenn das SE ein GET IDENTITY Kommando erhält.
Als Verschlüsselungsverfahren kommt beispielsweise ein Curve25519 / X25519 -Algorithmus zum Einsatz. Es kann ein im Anhang C3.4 des Standards 3GG TS 33.501 verwendeter ECIES-Profil-Parameter verwendet werden. Das Verschlüsselungsverfahren kann vom Typ ECIES Profile A oder ECIES Profile B sein.
Vor Durchführung des ersten Schrittes 101 wird das anzuwendende Verschlüsselungsverfahren ermittelt, indem beispielsweise die Konfigurationsdatei ausgelesen wird. Mit dem festgestellten Verschlüsselungsverfahren wird das SE-individuelle kryptographische Schlüsselpaar PubK_SE, PrivK_SE berechnet.
Im Ergebnis des ersten Schritts 101 ist ein privater Schlüsselteil PrivK_SE des SE-individuellen kryptographischen Schlüsselpaars erzeugt. Dieser Schritt kann dem ersten Schritt „1. Eph key pair generation“ des Ablaufverfahrens gemäß C.3.2-1 der TS 33.501 V 15.2.0 entsprechen.
In einem SE ohne Crypto-Co-Prozessor oder ohne Multiplikationsbeschleuniger kann dieser erste Schritt 101 bis zu 3 Sekunden dauern.
Im folgenden zweiten Schritt 102 (gezeigt in 1 und 2, nicht in 3) wird ein symmetrischer Schlüssel SharedK_SE-HN in dem SE erzeugt. Dieser symmetrische Schlüssel SharedK_SE-HN wird unter Verwendung des im ersten Schritt 101 erzeugten privaten Schlüsselteils PrivK_SE des SE-individuellen kryptographischen Schlüsselpaars und eines öffentlichen Schlüsselteils PubK_HN eines kryptographischen Schlüsselpaars eines Netzwerks erzeugt.
Der öffentliche Schlüsselteil PubK_HN ist dem SE vor dem Ausführen des zweiten Schrittes 102 bekannt und im SE vorhanden. Wie das Verschlüsselungsverfahren kann sich der öffentliche Schlüsselteil PubK_HN ändern. Beispielsweise kann das Netzwerk dem SE über OTA einen neuen, aktuellen öffentliche Schlüsselteil PubK_HN mitgeteilt haben.
Zweckmäßig ist der öffentliche Schlüsselteil PubK_HN in der Konfigurationsdatei enthalten. Ein initialer öffentlicher Schlüsselteil PubK_HN kann bereits bei Personalisierung des SE im Speicher des SE abgelegt sein.
Vor Ausführung des zweiten Schrittes 102 prüft das SE, ob der zuletzt verwendete öffentliche Schlüsselteil PubK_HN mit dem aktuellen öffentlichen Schlüsselteil PubK_HN übereinstimmt. Ist das der Fall verwendet das SE den gespeicherten öffentlichen Schlüsselteil PubK_HN, anderenfalls aktualisiert es den gespeicherten öffentlichen Schlüsselteil PubK_HN mit dem aktuellen gespeicherten öffentlichen Schlüsselteil PubK_HN und verwendet anschließend diesen.
Der zweite Schritt 102 kann dem Schritt „2. Key agreement“ des Ablaufverfahrens gemäß C.3.2-1 der TS 33.501 V 15.2.0 entsprechen. In einem SE ohne Crypto-Co-Prozessor oder ohne Multiplikationsbeschleuniger kann dieser Schritt bis zu 3 Sekunden dauern.
Die Ausführung des ersten Schritts 101 und des zweiten Schritts 102 können zeitlich entkoppelt voneinander erfolgen. Daher kann eine Zeit Zeit₁ zwischen der Ausführung des ersten Schritts 101 und des zweiten Schritts 102 auf dem SE verstreichen. Die Zeit Zeit₁ zwischen der Ausführung des ersten Schritts 101 und des zweiten Schritts 102 kann von einer Priorisierung der Ausführung des ersten Schritts 101 und des zweiten Schritts 102 auf dem SE im Vergleich zu weiteren Tasks, die auf dem SE ausgeführt werden, definiert werden. Auch ist es möglich, dass nicht sofort, sondern erst nach Verstreichen einer Zeit Dauere nach einem Start, einer Aktivierung und/ oder einer Initialisierung des SE der erste Schritt 101 ausgeführt wird. Ebenso ist es möglich, dass zwischen der Beendigung der Ausführung des ersten Schritts 101 und/ oder des zweiten Schritts 102 eine längere Zeit Dauer₁ verstreicht, bis das SE eine Identitätsabfrage des Netzwerks erhält.
Es ist auch möglich, dass das Ausführen des ersten Schritts 101 oder des zweiten Schritts 102 bei Erhalt einer Identitätsabfrage (gezeigt in 1 und 2, nicht in 3) abgebrochen wird, damit das SE mit dem Erstellen und Senden 300 einer Antwort auf die Identitätsabfrage des Netzwerks beginnen kann. Dies erfolgt vorzugweise nur dann, wenn zumindest ein gültiger symmetrischer Schlüssel im nichtflüchtigen Speicher vorhanden ist.
Weiter ist es möglich, den ersten Schritt 101 und/ oder den zweiten Schritt 102 mehrfach auszuführen (gezeigt in 2, nicht in 1 und 3). Entsprechend können mehrere SE-individuelle kryptographische Schlüsselpaare PubK_SE, PrivK_SE und/ oder symmetrische Schlüssel SharedK_SE-HNv im nichtflüchtigen Speicher abgelegt werden. Vor jeder Ausführung des ersten Schritts 101 kann die Priorisierung 202 erneut festgelegt werden. Der erste Schritt 101 und/ oder der zweite Schritt 102 wird so oft ausgeführt bis ausreichend SE-individuelle kryptographische Schlüsselpaare PubK_SE, PrivK_SE und/ oder symmetrische Schlüssel SharedK_SE-HNv im nichtflüchtigen Speicher abgelegt sind. Dies wird im Schritt 201 geprüft.
Nachfolgend wird eine Routine zum Erstellen und Senden 300 einer Antwort auf einer Identitätsabfrage beschrieben.
Im Schritt 104 (gezeigt in 1 und 3 nicht in 2) wird geprüft, ob ein gültiger symmetrischer Schlüssel SharedK_SE-HN im nichtflüchtigen Speicher vorhanden ist. Hierzu wird geprüft, ob sich das kryptographische Berechnungsverfahren, das zur Bestimmung des im nichtflüchtigen Speicher 17 vorhandenen SE-individuellen kryptographischen Schlüsselpaares PubK_SE, PrivK_SE verwendet wurde, zwischenzeitlich geändert hat. Das kann zum Beispiel der Fall sein, wenn sich die Art der Verschlüsselung oder Parameter der Verschlüsselung geändert haben.
Zweckmäßig sind über das Netzwerk verwaltete Randbedingungen in einer Konfigurationsdatei hinterlegt, die auf dem SE geführt wird und ebenfalls im nichtflüchtigen Speicher 17 abgelegt ist. Eine Ausführung einer Konfigurationsdatei ist beispielsweise in der simalliance-Spezifikation „eUICC Profile Package: Interoperable Format“, Version 2.3.1, November 2019, Annex D, beschrieben. In der Konfigurationsdatei sind zweckmäßig zumindest das aktuell anzuwendende kryptographische Berechnungsverfahren bezeichnet und der aktuelle öffentliche Schlüsselteil PubK_HN enthalten. Die Konfigurationsdatei wird stets aktuell gehalten und kann vom Netzwerk jederzeit aktualisiert werden.
Für die Prüfung des kryptographischen Schlüsselpaares PubK_SE, PrivK_SE liest das SE zweckmäßig die Konfigurationsdatei aus. Den ausgelesenen Eintrag für das anzuwendende kryptographische Berechnungsverfahren vergleicht das SE mit dem Berechnungsverfahren, das zur Berechnung des im nichtflüchtigen Speicher 17 befindlichen individuellen kryptografischen Schlüsselpaars PubK_SE, PrivK_SE verwendet wurde. Eine Nichtübereinstimmung kann beispielsweise eintreten, wenn die Art der Verschlüsselung vom Typ ECIES Profile A auf den ECIES Profile B umgestellt wurde.
Hat sich das Berechnungsverfahren geändert dann ist der symmetrische Schlüssel SharedK_SE-HN nichtflüchtigen Speicher 17 nicht mehr gültig und es muss ein neues SE-individuelles kryptographisches Schlüsselpaar PubK_SE, PrivK_SE berechnet werden. Dazu wird, wie in 3 dargestellt, ab dem Punkt „A“ weiterverfahren.
Wird bei der Prüfung 104 festgestellt, dass sich das Berechnungsverfahren nicht geändert hat, wird weiter geprüft, ob der zur Berechnung des im nichtflüchtigen Speicher 17 vorhandene öffentliche Schlüsselteil PubK_HN gültig ist. Dazu wird geprüft, ob sich der im zweiten Schritt 102 zur Berechnung des im nichtflüchtigen Speicher 17 vorhandenen symmetrischen Schlüssels SharedK_SE-HN verwendete öffentliche Schlüsselteil PubK_HN zwischenzeitlich geändert hat, z.B. durch Aktualisierung, Parameteranpassung oder Ersetzen. Hierzu vergleicht das SE zweckmäßig den aus der Konfigurationsdatei entnehmbaren aktuellen öffentlichen Schlüsselteil PubK_HN mit dem öffentlichen Schlüsselteil PubK_HN, der zur Berechnung des im nichtflüchtigen Speicher 17 gespeicherten symmetrische Schlüssel SharedK_SE-HN verwendet wurde. Ergibt sich danach eine Änderung, speichert das SE den in der Konfigurationsdatei enthaltenen aktuellen öffentlichen Schlüsselteil PubK_HN als neuen gültigen öffentlichen Schlüsselteil PubK_HN im nichtflüchtigen Speicher 17.
Haben sich das Berechnungsverfahren und der verwendete öffentliche Schlüsselteil PubK_HN nicht geändert wird geprüft, ob alle gespeicherten symmetrischen Schlüssel SharedK_SE-HN bereits verwendet wurden. Ist das nicht der Fall wird, wie in 3 dargestellt, ab dem Punkt „B“ weiterverfahren.
Hat sich der verwendete öffentliche Schlüsselteil PubK_HN zwischenzeitlich geändert ist der symmetrische Schlüssel SharedK_SE-HN im Speicher nicht mehr gültig und muss neu berechnet werden. Da in diesem Fall jedoch das SE-individuelle kryptographische Schlüsselpaar PubK_SE, PrivK_SE unverändert gültig ist muss lediglich der auf die Bereitstellung des SE-individuellen kryptographischen privaten Schlüssel PrivK_SE aufsetzende Teil der Schlüsselberechnung, d.h. lediglich der zweite Schritt 102 ausgeführt werden. Für die Berechnung wird der aktuelle öffentliche Schlüsselteil PubK_HN verwendet.
Der erste Schritt 101 und der zweite Schritt 102, die ab dem Punkt „A“ ausgeführt werden, und der zweite Schritt 102, der ab dem Punkt „B“ ausgeführt wird, entsprechen dem ersten Schritt 101 und dem zweiten Schritt 102 zum Erstellen und Ablegen 200 der Schlüssel vor dem Empfangen einer Identitätsabfrage des Netzwerks. Das im ersten Schritt 101 erstellte SE-individuelle kryptographische Schlüsselpaar PubK_SE, PrivK_SE und/oder der im zweiten Schritt 102 erstellte symmetrische Schlüssel SharedK_SE-HN können auch in einem flüchtigen Speicherbereich 18, beispielsweise einem RAM, abgelegt werden. K
Im optionalen Schritt 105 (gezeigt in 1 und 3 aber nicht in 2) erfolgt ein Ableiten eines ersten Teilschlüssels und eines zweiten Teilschlüssels von dem symmetrischen Schlüssel SharedK_SE-HN. Dieser Schritt 105 kann dem Schritt „3. Key derivation“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 entsprechen. Der erste Teilschlüssel kann der „Eph. enc Key, ICB“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein. Der zweite Teilschlüssel kann der „Eph. mac Key“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein. Bei diesem Aufteilen 105 kann auch eine Schlüssellänge angepasst werden.
Im Schritt 106 (gezeigt in 1 und 3 aber nicht in 2) erfolgt ein Verschlüsseln von Identitätsdaten, die in dem SE abgespeichert sind. Dabei werden Dateiinhalte der Datei EF_IMSI als Eingangsdaten der Verschlüsselung 106 verwendet. Dieses Verschlüsseln 106 kann der Schritt „4. Symmetrie Encryption“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein. Im Ergebnis dieses Schritts werden verschlüsselte Identitätsdaten erhalten. Die verschlüsselten Identitätsdaten aus dem Schritt 106 werden (auch) als Teil einer Antwort auf eine Identitätsabfrage vom Netzwerk an das Netzwerk gesendet.
Im Schritt 107 (gezeigt in 1 und 3 aber nicht in 2) erfolgt ein Anwenden eines MAC-Algorithmus. Dabei werden die verschlüsselten Identitätsdaten aus dem Schritt 106 als ein Eingangsparameter des MAC-Algorithmus verwendet. Zudem kann der zweite Teilschlüssel „Eph. mac Key“ als ein weiterer Eingangsparameter des MAC-Algorithmus verwendet werden. Dieses Anwenden 107 kann der Schritt „5. MAC function“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein. Im Ergebnis dieses Schritts 107 wird ein MAC erhalten, der auch als „MAC-tag value“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 15.2.0 sein kann. Der MAC aus dem Schritt 107 wird (auch) als Teil einer Antwort auf eine Identitätsabfrage vom Netzwerk an das Netzwerk gesendet.
Im Schritt 108 (gezeigt in 1 und 3 aber nicht in 2) erfolgt ein Senden einer Antwort auf die Identitätsabfrage des Netzwerkes. Die Antwort umfasst beispielsweise eine Konkatenation aus dem öffentlichen Teil PubK_SE (Schritt 101), den verschlüsselte Identitätsdaten (Schritt 106) und dem MAC (Schritt 107). Zusätzliche Parameter können ebenfalls in der Antwort enthalten sein. $Antwort = {PubK}_{SE} {‖ Identit \ddot{a} tsdaten}_{verschl \ddot{u} sselt} ‖ MAC ‖ o p t i o n a l e P a r a m e t e r$
Die Antwort 108 ist bevorzugt das Ergebnis des GET IDENTITY Kommandos.
Im optionalen Schritt 109 (gezeigt in 1, aber nicht in 2 und 3) wird das verwendete SE-individuelle kryptographische Schlüsselpaar PubK_SE, PrivK_SE und/ oder der verwendete symmetrische Schlüssel SharedK_SE-HN zum Erstellen und Senden 300 einer Antwort auf die Identitätsabfrage aus dem nichtflüchtigen Speicher gelöscht oder als verwendet markiert, sofern die Werte im nichtflüchtigen Speicher gespeichert wurden.
Die Routine zum Erstellen und Senden 300 der Antwort auf eine Identitätsabfrage des Netzwerkes darf nicht länger als eine maximale Zeit dauern. Ansonsten wird die Antwort vom Netzwerk nicht mehr angenommen. Dauert die Routine zum Erstellen und Senden 300 der Antwort auf die Identitätsabfrage länger als die maximale Zeit kann von dem Netzwerk direkt eine neue Registrierungsanfrage 103 an das SE gesendet werden (gezeigt in 2 aber nicht in 1 und 3). Darauf folgend kann direkt mit der erneuten Festlegung der Priorisierung 202 und dem Ausführen des ersten Schritts 101 und des zweiten Schritts 102 begonnen werden. Oder es kann direkt mit dem Ausführen des ersten Schritts 101 und des zweiten Schritts 102 begonnen werden, um die Zeit zwischen der Registrierungsanfrage 103 und einer Identitätsabfrage des Netzwerks bzw. einer Transition T1, die die Identitätsabfrage des Netzwerks beinhaltet, welche vorzugsweise das Endgerät an das SE weiterleitet, zum Erstellen von neuen SE-individuellen kryptographischen Schlüsselpaaren PubK_SE, PrivK_SE und/ oder symmetrischer Schlüssel SharedK_SE-HN zu nutzen.
Insbesondere der Standard ETSI TS 102 221, ab Version 15, und der Standard 3GPP TS 31.102, ab Version 15, definieren das Kommando GET IDENTITY. Dieses Kommando wird in 5G-Netzwerken zur Erzeugung einer SUCI verwendet. Der SUCI Kontext beinhaltet eine IMSI (Intern. Mobile Subscription ID) oder NSI (Network specific ID) als Identitätsdaten, welche zur Identifikation eines Teilnehmers in einem 5G Netzwerk verwendet wird.
Das GET IDENTIY Kommando wird vom Netzwerk gesendet und muss innerhalb von sechs Sekunden beantwortet werden, einschließlich der Übertragungsdauer. Dies stellt ein großes Problem für SE dar, die keinen Krypto-Co-Prozessor oder keinen Multiplikationsbeschleuniger haben.
Nachfolgend werden einige Vergleiche der Berechnung der SUCI auf unterschiedlichen SE dargestellt, aus denen der Effekt der Zeiteinsparung bei Vorabberechnung des ersten Schritts 101 und/oder des zweiten Schritts 102 ersichtlich wird.
Zur Berechnung beispielsweise in einem SE „S3FW9FJ“ eines „Profile A“ mit AVIOR 700k benötigt der erste Schritt 101 1100 Millisekunden und der zweite Schritt 102 1101 Millisekunden. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach dem ersten Schritt 101 und dem zweiten Schritt 102 ausgeführt wird, werden nur 23 Millisekunden benötigt. Zur Berechnung in einem SE „S3FW9FJ“ eines Profile B mit AVIOR 700k benötigt der erste Schritt 101 2934 Millisekunden und der zweite Schritt 102 2938 Millisekunden. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach dem ersten Schritt 101 und nach dem zweiten Schritt 102 ausgeführt wird, werden nur 23 Millisekunden benötigt. Somit kann mit Hilfe der Vorberechnung im ersten Schritt 101 bzw. zusätzlicher Voraberzeugung des symmetrischen Schlüssels im zweiten Schritt 102 eine deutliche Geschwindigkeitssteigerung erzielt werden. Es können im Ergebnis viel einfachere und damit auch kostengünstigere SE Karten im 5G Netzwerk betrieben werden, da ein Co-Prozessor zur Berechnung der SUCI nun nicht mehr notwendig ist, um die maximale Zeitdauer Zeit_MAX einzuhalten. Mit Hilfe von Vorberechnung von Schlüsseln kann die 3GPP und ETSI Spezifikation eingehalten werden und die Leistung zur Erwiderung/ Abarbeitung eines GET IDENTITY Kommandos deutlich gesteigert werden.
4, 5 und 6 zeigen Ablaufdiagramme von bevorzugten Ausführungsbeispielen zur Durchführung des erfindungsgemäßen Verfahrens 100. Die Verfahrensschritte 101 bis 109 entsprechen den Verfahrensschritten 101 bis 109 der 1 oder 2. Das SE der 3, 5 und 6 kann eine 5G USIM sein. Die 3, 5 und 6 werden nachfolgend zusammen beschrieben.
In 4 werden der erste Schritt 101 und der zweite Schritt 102 jeweils einmal im SE ausgeführt, bevor das Endgerät eine Registrierungsanfrage von dem Netzwerk erhält. Die Zeit zwischen dem Start der SE und der ersten Ausführung des ersten Schritts 101 ist die Zeit Dauer₀. Die Zeit zwischen der ersten Ausführung des ersten Schritts 101 und der ersten Ausführung des zweiten Schritts 102 ist die Zeit Zeit₁.
In 5 werden der erste Schritt 101 und der zweite Schritt 102 jeweils k-mal durchgeführt, bevor das Netzwerk die Registrierungsanfrage an das Endgerät stellt. Die Zeit zwischen der k-ten Ausführung des ersten Schritts 101 und der k-1-ten Ausführung des zweiten Schritts 102 ist eine Zeit Zeit_k. Die Zeit zwischen dem k+1-ten Ausführung des zweiten Schritts 102 und der k-ten Ausführung des ersten Schritts 102 ist eine Zeit Zeit_k+1.
In 6 werden der erste Schritt 101 und der zweite Schritt 102 jeweils 2-mal durchgeführt, bevor das Netzgerät die Registrierungsanfrage an das Endgerät stellt. Die Zeit zwischen der ersten Ausführung des zweiten Schritts 102 und der zweiten Ausführung des ersten Schritts 101 ist eine Zeit Zeit₂. Die Zeit zwischen der zweiten Ausführung des ersten Schritts 101 und der zweiten Ausführung des zweiten Schritts 102 ist eine Zeit Zeit₃.
Die Anzahl der Ausführungen des ersten Schritts 101 und des zweiten Schritts 102 ist exemplarisch und nicht beschränkt. Es ist auch möglich, dass der erste Schritt 101 und der zweite Schritt 102 in unterschiedlicher Anzahl ausgeführt wird oder nicht komplett ausgeführt wird. Zwischen der letzten Ausführung des ersten Schritts 101 oder des zweiten Schritts 102 und der Identitätsabfrage kann eine Zeit Dauer₁ verstreichen, da die Ausführung des ersten Schritt 101 und/ oder des zweiten Schritts 102 von der Identitätsabfrage bzw. einer davor erfolgten Registrierungsanfrage entkoppelt erfolgt.
Die Registrierungsanfrage soll es dem Endgerät ermöglichen (dargestellt in 4, 5 und 6) Dienste des Netzwerks nutzen zu können. Dazu prüft das Netzwerk die Identität des Endgeräts und fordert es zur Authentisierung/Identifizierung auf. Der Ablauf einer Registrierungsanfrage und Authentisierungs-/Identifizierungsaufforderung ist prinzipiell in der 3GPP TS 23.501 beschrieben. Im Verlauf der Identifizierung wird vom Netzwerk eine Identifikationsabfrage an das Endgerät gesendet. Diese wird im Endgerät in ein Kommando GET IDENTITY umgesetzt und an das SE weitergeleitet. Im 5G Netz ist das SE nun gezwungen, die Identitätsdaten, die als SUPI bezeichnet werden und beispielsweise die IMSI, NSI, NAI umfassen, in einen SUCI umzuwandeln und dem Netzwerk binnen einer Zeitspanne Zeit_MAX (beispielsweise 6 Sekunden) zurückzusenden.
Wird die Zeitspanne Zeit_MAX überschritten, kann das Netzwerk erneut eine Registrierungsanfrage an das Endgerät schicken, (dargestellt in 6, aber nicht in 3 und 4). Daraufhin kann das SE direkt mit der Ausführung des ersten Schritts 101 und/ oder des zweiten Schritts 102 gegebenenfalls mit einer hohen Priorisierung starten oder wenn noch eine ausreichende Anzahl symmetrischer Schlüssel SharedK_SE-HN im nichtflüchtigen Speicher vorhanden ist, die nächste Identitätsabfrage des Netzwerks abwarten und darauffolgend erneut mit der Berechnung der Schritte 104 bis 109 beginnen.
Eine IMSI ist Teil einer Teilnehmerkennung und sollte - wenn möglich - nicht ausgelesen werden. Die UICC 1 ist eine 5G USIM und ist daher eingerichtet zum Erzeugen einer SUCI basierend auf der IMSI. Das Verwenden der SUCI anstelle der IMSI ist vorteilhaft, da beim Senden der SUCI die IMSI nicht im Klartext an das Endgerät bzw. das Netzwerk gesendet wird. Das Senden der SUCI würde demnach die sicherheitsrelevante und/oder personenbezogene Information aus der Datei EF_IMSI schützen. Zweckmäßig wird deshalb die SUCI anstelle der IMSI als Netzwerkkennung gesendet.
Um anstelle einer IMSI eine SUCI als Antwort auf die Identitätsabfrage zu senden, muss die SUCI berechnet werden. Dazu wird das Verfahren in 1, 2 und 3 mit den Schritten 101 bis 109 angewendet. Diese Berechnung kann den standardisierten Vorgehensweisen gemäß 3GPP 23.501 entsprechen und wird erfindungsgemäß durch das Vorabausführen des ersten Schritts 101 und des zweiten Schritts 102 wesentlich verbessert, um zeitaufwendige Berechnungen nach dem Schritt 103 bzw. der Identitätsabfrage des Netzwerks T1 zu vermeiden.
Der Teilnehmer-Identifikationsmechanismus gemäß dem 5G Netzen ermöglicht die Identifizierung eines Endgerätes auf der Over-the-Air-Funkschnittstelle (Schnittstelle 41 der 4) mit Hilfe der generierten SUCI. Wenn das Endgerät zum ersten Mal versucht, sich zu registrieren, verschlüsselt das SE die SUPI in eine SUCI auf Basis des Kommandos GET IDENTITY und stellt diese SUCI dem Endgerät im Schritt 108 zur Verfügung.
Der SUCI ist dabei ein datenschutzfreundlicher Bezeichner, der die verborgene SUPI enthält. Es wird auf 1, 2 und 3 verwiesen. Das SE erzeugt im ersten Schritt 101 und im zweiten Schritt 102 unter Verwendung des ECIES-basierten Schutzschemas mit dem öffentlichen Schlüssel des Heimatnetzes PubK_HN, der dem SE während der USIM-Registrierung oder bei Personalisierung sicher zur Verfügung gestellt wurde.
Nur der MSIN-Teil der SUPI wird verschlüsselt, während die Kennung des Heimatnetzes, d. h. MCC/MNC, weiterhin im Klartext übertragen wird. Die Datenfelder, aus denen die SUCI besteht, sind „SUPI Type“; „Home Network Identifier (bei IMSI = MCC+MNC, bei NAI = Domain-Namen“; „Routing-Indikator“; „Kennung des Schutzschemas: Null-Schema oder Profil A oder Profil B“; „Kennung für den öffentlichen Schlüssel des Heimnetzwerks PubK_HN“; „Zeichenkette mit variabler Länge oder hexadezimalen Ziffern, abhängig vom verwendeten Schutzschema.“
Das Verfahren 100 wird dabei in ein Betriebssystem 15 des SE integriert und kann so in jeder nativen SE eingesetzt und verwendet werden.
7 zeigt ein Ausführungsbeispiel eines Systems aus Endgerät und SE, in der das Verfahren der 1, 2 und 3 abläuft. Das Endgerät ist beispielsweise ein M2M-Gerät in einer IoT Umgebung. Das Endgerät kann eine Mehrzahl von ECUs 21 aufweisen, hier stellvertretend sind zwei ECUs 21a und 21b dargestellt. Durch diese ECUs 21 werden die Funktionalitäten des Endgeräts gesteuert.
Das SE ist betriebsbereit in das Endgerät eingebracht und wird vom Endgerät mit einer Versorgungsspannung Vcc und einem Takt CLK versorgt. Das SE ist in 8 detaillierter dargestellt. In 7 ist angedeutet, dass das SE Applets 13 aufweist. Diese Applets 13 können über eine Card Application Toolkit, CAT, 12, unterschiedliche APDU-Kommandos 11 an das Endgerät senden.
Das Endgerät umfasst auch ein Modem 22. Das Modem 22 kann beispielsweise als eine logische Einheit zum Umsetzen von Daten zwischen dem SE und einem Netzwerk 4 angesehen werden. Das Endgerät kann durch das Modem 22 eine Kommunikationsverbindung 3 zum SE aufbauen. Die Kommunikation 3 zwischen dem Endgerät und dem SE erfolgt beispielsweise gemäß den in den 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 SE und dem Endgerät findet bevorzugt unter Verwendung sogenannter 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 das SE übertragen werden. Man unterscheidet zwischen Kommando-APDUs, die von einem Endgerät an das SE gesendet werden, und Antwort-APDUs, die von dem SE in Reaktion auf eine Kommando-APDU an das Endgerät gesendet werden.
Das Modem 22 ist eine Kommunikationseinheit des Endgeräts, um auch Daten des Endgeräts oder des SE über eine Kommunikationsschnittstelle 41 mit dem Netzwerk, beispielsweise ein Server eines Netzbetreibers, auszutauschen. Die ausgetauschten Daten zwischen SE und Modem 22 können im Modem 22 in ein IP-basiertes Verbindungsprotokoll umgesetzt werden.
8 zeigt ein Blockschaltbild eines erfindungsgemäßen SE, vorzugsweise eine fest verdrahtete eUICC. Alternativ ist das SE ein portabler Datenträger mit einer anderen Bauform. Das SE hat ein Betriebssystem 15, in dem das Verfahren 100 gemäß 1, 2 und 3 abläuft. Das Betriebssystem 15 ist beispielsweise ein natives Betriebssystem. Es ist zudem denkbar, dass das Betriebssystem 15 eingerichtet ist, eine Java Card Laufzeitumgebung, JCRE, 16 zu betreiben.
Das SE ist dazu ausgestaltet mit dem Endgerät gemäß 7 Daten auszutauschen. Zur Datenübertragung bzw. Kommunikation zwischen dem SE und dem Endgerät weisen sowohl die SE als auch das Endgerät jeweils geeignete Kommunikationsschnittstellen 31 auf. Die Schnittstellen können beispielsweise so ausgestaltet sein, dass die Kommunikation zwischen diesen bzw. zwischen dem SE und dem Endgerät 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. Das Endgerät kann eine Identitätsabfrage des Netzwerks an das SE weiterleiten (Transition T1 des Verfahrens 100 in der 1, 2 oder 3).
Das SE 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 Zugreifen (Lesen, Schreiben, Ändern, Überschreiben, Anlegen und/oder Löschen) von Dateien in dem SE, wie dies durch von der CPU 19 ausgeführten Programmcode definiert wird. Die Dateien sind beispielsweise Elementare Dateien, Elementary Files, EF, in einem Dateiverzeichnis, Directory Files, DF, eines Root-Verzeichnisses oder eines Profilverzeichnisses des SE eines nicht-flüchtigen Speichers 17. Die CPU 19 steht ferner mit einem flüchtigen Arbeitsspeicher, RAM 18 und dem 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. Die Steuereinheit 19 ist zudem dazu eingerichtet, die Schritte 101 bis 108 des Verfahrens der 1, 2 und 3 auszuführen, wenn entsprechender Programmcode ausgeführt wird.
Bei der in 8 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 hinterlegt sein. Dabei liegt die Applikation 13 vorzugsweise in Form von Java Card™ Applets vor. Zudem ist der in 7 gezeigte CAT 12 gemäß ETSI TS 102 223 eingebracht.
Heutige Endgeräte, wie Smartphones, enthalten ein Chipset, das eine Mehrzahl von Chips oder Prozessoren umfassen kann, speziell einen Applikations-Prozessor, einen Baseband-Prozessor, und ggf. eine speziell gesicherte Secure Processing Unit SPU (allesamt nicht dargestellt in 1, 2 und 3). Für den derzeit in Entwicklung befindlichen künftigen 5G-Mobilfunkstandard wird das Konzept des integrated UICC, iUICC, vorgeschlagen, bei dem die Funktionalität einer USIM-Karte oder eines UICC verteilt in das Chipset, d.h. in ein oder mehrere Chips oder Prozessor(en), des Endgeräts integriert ist. Es ist von großem Kostenvorteil, wenn dieses Chipset keinen Kryptoprozessor oder Hardwarebeschleuniger aufweist, was durch das vorliegende Verfahren ermöglicht ist.
Im Rahmen der Erfindung können alle beschriebenen und/ oder gezeichneten und/ oder beanspruchten Elemente beliebig miteinander kombiniert werden.
Bezugszeichenliste

SE, UICC, eUICC, Teilnehmeridentitätsmodul, SIM

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

3

Kommunikationsverbindung zwischen Gerät und SE

31

Schnittstelle der SE
Netzwerk

41

Schnittstelle Gerät - Netzwerk
Verfahren

101-109

Verfahrensschritte

201-202

Verfahrensschritte

PubKHN

Öffentlicher Schlüsselteil des Netzwerk-Schlüsselpaars, Public Key of HN

PrivKHN

Privater Schlüsselteil des Netzwerk-Schlüsselpaars, Privat Key of HN

PubKSE

Öffentlicher Schlüsselteil des SE-Schlüsselpaars, Eph. public key

PrivKSE

Privater Schlüsselteil des SE-Schlüsselpaars, Eph. privat key

SharedKSE-HN

Symmetrischer Schlüssel zw. SE und Netzwerk, Eph. shared key

MAC-KSE

MAC-Schlüssel des SE, Eph. mac. Key

Dauer0

Zeitspanne zwischen der Initialisierung und/ oder Aktivierung und der ersten Ausführung des ersten Schritts

Dauer1

Zeitspanne zwischen der letzten Ausführung des zweiten Schritts und der Identitätsabfrage des Netzwerks

Zeit1

Zeitspanne zwischen der ersten Erstellung des SE-Schlüsselpaars und des zugehörigen ersten symmetrischen Schlüssels

Zeit2

Zeitspanne zwischen der ersten Erstellung des symmetrischen Schlüssels und des zweiten SE-Schlüsselpaars

Zeit3

Zeitspanne zwischen der zweiten Erstellung des SE-Schlüsselpaars und des zugehörigen zweiten symmetrischen Schlüssels

Zeitk

Zeitspanne zwischen der k-1-ten Erstellung des symmetrischen Schlüssels und des k-ten des SE-Schlüsselpaars

Zeitk+1

Zeitspanne zwischen der k-ten Erstellung des SE-Schlüsselpaars und des k+1-ten symmetrischen Schlüssels

ZeitAntwort

Zeitspanne zwischen Identitätsabfrage und -antwort

ZeitMax

Zulässige Zeitspanne zwischen Identitätsabfrage und -antwort

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

WO 2019068731 A1 [0010]

Claims

Ein Verfahren in einem Secure-Element, SE, zum Erzeugen zumindest eines symmetrischen Schlüssels (SharedK_SE-HN) und/ oder eines SE-individuellen kryptographischen Schlüsselpaars (PubK_SE, PrivK_SE) zum Erstellen und Senden (300) einer Antwort auf eine von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, mit den Verfahrensschritten: Erster Schritt (101): Erzeugen, in dem SE, von zumindest einem SE-individuellen kryptographischen Schlüsselpaar (PubK_SE, PrivK_SE) auf Basis eines ECC-Algorithmus und Ablegen des zumindest einen SE-individuellen kryptographischen Schlüsselpaars (PubK_SE, PrivK_SE) in einen nichtflüchtigen Speicher (17); und/oder Zweiter Schritt (102): Erzeugen, in dem SE, von dem zumindest einen symmetrischen Schlüssel (SharedK_SE-HN) unter Verwendung des gespeicherten privaten Schlüsselteils des ersten SE-individuellen kryptographischen Schlüsselpaars (PrivK_SE) und eines öffentlichen Schlüsselteils (PubK_HN) eines Netzwerkschlüsselpaars in dem SE und Ablegen des symmetrischen Schlüssels (SharedK_SE-HN) in den nichtflüchtigen Speicher (17), wobei der erste Schritt (101) und/ oder der zweite Schritt (102) bereits vor dem Erhalten (T1) der von dem Netzwerk gesendeten Identitätsabfrage ausgeführt wird, wobei der im zweiten Schritt (102) erzeugte symmetrische Schlüssel (SharedK_SE-HN) zum Erstellen und Senden (300) der Antwort auf die vom Netzwerk gesendeten Identitätsabfrage verwendet wird, wobei der Start der Ausführung des zweiten Schritts (102) zeitlich entkoppelt nach der Ausführung des ersten Schritts (101) erfolgt, und wobei für die Durchführung des ersten Schrittes (101) ein zu verwendender ECC-Algorithmus ermittelt wird, und/oder für die Durchführung des zweiten Schrittes (102) ein aktueller öffentlicher Schlüsselteil (PubK_HN) eines Netzwerkschlüsselpaars ermittelt wird.
Verfahren nach Anspruch 1, wobei die Ausführung des ersten Schritts (101) und/ oder des zweiten Schritts (102) zumindest zeitweise pausiert und/ oder abgebrochen werden kann, wenn zumindest ein weiterer Task auf dem SE ausgeführt wird.
Verfahren nach Anspruch 1 oder 2, wobei in Abhängigkeit einer Priorisierung (220) bestimmt wird, ob der erste Schritt (101) und/ oder der zweite Schritt (102) ausgeführt und/ oder pausiert und/ oder abgebrochen wird, um zumindest einen weiteren Task auszuführen, wobei bevorzugt die Priorisierung (220) des ersten Schritts (101) und/ oder des zweiten Schritts (102) im Vergleich zu dem zumindest einen weiteren Task auf dem SE von der Anzahl der bereits im nichtflüchtigen Speicher (17) abgelegten SE-individuellen kryptographischen Schlüsselpaare (PubK_SE, PrivK_SE) und/ oder von der Anzahl der bereits im nichtflüchtigen Speicher (17) abgelegten symmetrischen Schlüssel (SharedK_SE-HN) abhängt.
Ein Verfahren in einem Secure-Element, SE, zum Erstellen und Senden (300) einer Antwort auf eine von einem Netzwerk gesendete Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, mit den Verfahrensschritten: Erhalten (T1), im SE, der von dem Netzwerk gesendeten Identitätsabfrage; Prüfen (104), ob zumindest ein im nichtflüchtigen Speicher (17) vorhandenes SE-individuelles kryptographisches Schlüsselpaar (PubK_SE, PrivK_SE) gültig ist, und/oder Prüfen (104), ob zumindest ein zur Bestimmung eines im nichtflüchtigen Speicher (17) vorhandenen symmetrischen Schlüssels (SharedK_SE-HN) verwendeter öffentlicher Schlüsselteil (PubK_HN) eines Netzwerkschlüsselpaars gültig ist, Erzeugen eines symmetrischen Schlüssels (SharedK_SE-HN) durch das Ausführen eines zweiten Schritts (102), wenn im Prüfen-Schritt (104) kein gültiger öffentlicher Schlüsselteil (PubK_HN) eines Netzwerkschlüsselpaars festgestellt wurde jedoch zumindest ein gültiges SE-individuelles kryptographisches Schlüsselpaar (PubK_SE, PrivK_SE) im nichtflüchtigen Speicher (17) vorhanden ist, wobei der zweite Schritt (102) ein Erzeugen, in dem SE, von dem zumindest einen symmetrischen Schlüssel (SharedK_SE-HN) unter Verwendung eines gespeicherten privaten Schlüsselteils des ersten SE-individuellen kryptographischen Schlüsselpaar (PrivK_SE) und eines aktuellen öffentlichen Schlüsselteils (PubK_HN) eines Netzwerkschlüsselpaars umfasst; oder Erzeugen des symmetrischen Schlüssels (SharedK_SE-HN) durch das Ausführen eines ersten Schritts (101) und des zweiten Schritts (102), in dem SE, wenn im Prüfen-Schritt (104) kein gültiges SE-individuelles kryptographisches Schlüsselpaar (PubK_SE, PrivK_SE) im nichtflüchtigen Speicher (17) vorhanden ist, wobei der erste Schritt (101) ein Erzeugen, in dem SE, von dem zumindest einen SE-individuellen kryptographischen Schlüsselpaar (PubK_SE, PrivK_SE) auf Basis eines ECC-Algorithmus umfasst; Verschlüsseln (106) von auf dem SE gespeicherten Identitätsdaten durch das SE, zum Erzeugen von verschlüsselten Identitätsdaten (Identitätsdaten_{verschlüsselt}) unter Verwendung des in einem der vorherigen Erzeugen-Schritte erzeugten symmetrischen Schlüssels (SharedK_SE-HN) oder eines symmetrischen Schlüssels (SharedK_SE-HN), der im nichtflüchtigen Speicher vorhanden ist; Anwenden (107) eines Nachrichtenauthentifizierungscode-Algorithmus auf die erzeugten verschlüsselten Identitätsdaten (Identitätsdaten_{verschlüsselt}) durch das SE zum Erhalten eines MAC; und Senden einer Antwort (108) auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Antwort den öffentlichen Schlüsselteil des SE-individuellen kryptographischen Schlüsselpaares (PubKsE), die verschlüsselten Identitätsdaten (Identitätsdaten_{verschlüsselt}) und den MAC (MAC) enthält.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass für die Prüfung (104), ob zumindest ein im nichtflüchtigen Speicher (17) vorhandenes SE-individuelles kryptographisches Schlüsselpaar (PubK_SE, PrivK_SE) gültig ist, geprüft wird, ob sich das Berechnungsverfahren zur Ermittlung geändert hat.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass für die Prüfung (104), ob zumindest ein zur Bestimmung eines im nichtflüchtigen Speicher (17) vorhandenen symmetrischen Schlüssels (SharedK_SE-HN) verwendeter öffentlicher Schlüsselteil (PubK_HN) eines Netzwerkschlüsselpaars gültig ist, geprüft wird, ob sich der öffentliche Schlüsselteil (PubK_HN) des Netzwerkschlüsselpaars geändert hat.
Verfahren nach einem der vorherigen Ansprüche mit den Verfahrensschritten: Erkennen, dass das Erstellen und Senden (300) der Antwort auf die von dem Netzwerk gesendete Identitätsabfrage eine maximale Zeitdauer überschreitet oder dass die Identitätsabfrage vom Netzwerk bereits nicht angenommen wurde, Senden einer Registrierungsanfrage (103) durch das Netzwerk und erneutes Erstellen und Senden einer Antwort (300) nach Anspruch 4 durch das SE auf den Erhalt der Registrierungsanfrage (103) von dem Netzwerk.
Verfahren nach einem der vorherigen Ansprüche, wobei der symmetrische Schlüssel (SharedK_SE-HN) und/ oder der öffentliche Teil (PubK_SE) und/ oder der private Teil (PrivK_SE) des SE-individuellen kryptographischen Schlüsselpaars gelöscht wird, nachdem zumindest einer dieser Schlüssel zum Erstellen und Senden (300) der Antwort auf die von dem Netzwerk gesendeten Identitätsabfrage verwendet wurde.
Verfahren nach einem der vorherigen Ansprüche, wobei nur ein neuer symmetrischer Schlüssel (SharedK_SE-HN) und/ oder ein neues SE-individuelles kryptographisches Schlüsselpaar (PubK_SE, PrivK_SE) erstellt und im nichtflüchtigen Speicher (17) abgelegt wird, wenn eine maximale Anzahl von symmetrischen Schlüsseln und/ oder SE-individuellen kryptographischen Schlüsselpaaren im nichtflüchtigen Speicher (17) noch nicht überschritten ist und/ oder ein Speicherbedarf für den symmetrischen Schlüssel (SharedK_SE-HN) und/ oder die SE-individuellen kryptographischen Schlüsselpaare (PubK_SE, PrivK_SE) einen vordefinierten Speicherplatz im nichtflüchtigen Speicher (17) noch nicht überschreitet.
Verfahren nach einem der vorherigen Ansprüche, wobei die maximale Anzahl der zu erzeugenden symmetrischen Schlüssel (SharedK_SE-HN) und/ oder der SE-individuellen kryptographischen Schlüsselpaare (PubK_SE, PrivK_SE) bei einer Initialisierung und/ oder einer Aktivierung der SE oder des Endgeräts festgelegt wird und/ oder der vordefinierte Speicherplatz im nicht flüchtigen Speicher (17) bei der Initialisierung reserviert wird.
Verfahren nach einem der vorherigen Ansprüche, wobei die Ausführung des ersten Schritts (101) und/ oder des zweiten Schritts (102) nach einem Erhalten eines STATUS Kommando oder eines SELECT Kommando in dem SE mindestens einmal erfolgt.
Ein Secure Element, SE, bevorzugt ein Teilnehmeridentitätsmodul der fünften Generation, aufweisend: - eine Schnittstelle (31), eingerichtet zum Erhalten (T1) einer von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos; - einen nicht-flüchtigen Speicher (17), eingerichtet zum Ablegen von Identitätsdaten, bevorzugt in zumindest einer Datei (EF_IMSI); und - eine Steuereinheit (19), die zum Ausführen eines der Verfahren nach den vorherigen Ansprüchen eingerichtet ist.
Das SE gemäß Anspruch 12, weiter umfassend: - ein Betriebssystem (15), ausführbar abgelegt in dem nicht-flüchtigen Speicher (17) und dazu eingerichtet, wenn in der Steuereinheit (19) ausgeführt, die Schritte des Verfahrens (100) gemäß einer der vorherigen Ansprüche durchzuführen.
Ein Computerprogramprodukt ausführbar in einem SE installiert, bevorzugt einem Teilnehmeridentitätsmodul der fünften Generation, und aufweisend Mittel zum Ausführen der Verfahrensschritte des Verfahrens (100) gemäß einer der vorherigen Ansprüche.
Ein System aufweisend ein SE, bevorzugt ein Teilnehmeridentitätsmodul der fünften Generation, und ein Netzwerk, wobei das System zum Ausführen der Verfahrensschritte des Verfahrens (100) gemäß einer der vorherigen Ansprüche vorbereitet ist.