DE102021004115A1 - Verfahren in einem secure element - Google Patents

Abstract

Die Erfindung betrifft ein Verfahren in einem Secure Element, SE, mit folgenden Verfahrensschritten: Erhalten, im SE, einer von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos; Verschlüsseln von auf dem SE gespeicherten Identitätsdaten durch das SE, zum Erzeugen von verschlüsselten Identitätsdaten unter Verwenden eines vor dem Erhalten-Schritt im SE erzeugten symmetrischen Schlüssels; Anwenden eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten durch das SE zum Erhalten eines MAC; und Erstellen und Senden einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Nachricht die verschlüsselten Identitätsdaten und den MAC enthält. 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 Verfahren in einem Secure Element, SE, bevorzugt einem Teilnehmeridentitätsmodul der fünften Generation, ein entsprechendes SE, ein Computerprogrammprodukt und ein entsprechendes 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: Internet-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 Dienst 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 Smartphones oder Mobiltelefons, 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 oder deren Verhalten zu analysieren.
• 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 stellen. Diese 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, siehe beispielsweise C.3.2.1 der 3GPP TS 33.501, Version 15.2.0, vorgesehen sind. Es hat sich herausgestellt, dass dieser vorgegebene Zeitrahmen knapp bemessen ist und insbesondere von ressourcenschwachen SE (insbesondere mit Chips ohne Krypto-Co-Prozessor und/oder ohne Multiplikationsbeschleuniger) kaum erfüllt werden kann. Wird der Zeitrahmen nicht eingehalten („timeout“), so gilt die Identitätsabfrage als nicht beantwortet, eine Netzeinbuchung kann dann nicht erfolgen. Des Weiteren ist spezifiziert, dass das PKI Schlüsselpaar, welches zur Verschlüsselung der SUCI herangezogen wird, nur einmal verwendet werden soll und daher bei jeder neuen Anfrage neu erzeugt werden soll.
• In einem Lösungsansatz werden ressourcenstärkere SE eingesetzt, die beispielsweise einen Krypto-Co-Prozessor oder einen Multiplikationsbeschleuniger aufweisen. Diese SE sind vergleichsweise teuer.
• Um diesen vorgegebenen Zeitrahmen einzuhalten, wird in der WO 2019 / 068731 A1 vorgeschlagen, die SUCI komplett vorab zu berechnen und in einem SE abzuspeichern. In Erwiderung auf eine - nach der Berechnung erhaltene - Identitätsabfrage des Netzwerks wird diese vorberechnete SUCI aus dem Speicher des SE geladen und in einer Antwort auf die Identitätsabfrage verwendet.
• ZUSAMMENFASSUNG DER ERFINDUNG
• Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren in einem SE anzubieten, bei dem die Berechnungszeit zum Erstellen und Versenden einer Antwort auf die Identitätsanfrage verkürzt werden kann, ohne dass die dazu benötigten verschlüsselten Identitätsdaten vorab permanent abgespeichert wird. Auf ressourcenstärkere SE (mit entsprechender KryptoProzessor-Arithmetik oder Multiplikationsbeschleunigung) 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, mit folgenden Verfahrensschritten verwendet: Erhalten, im SE, einer von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos; Verschlüsseln von auf dem SE gespeicherten Identitätsdaten durch das SE, zum Erzeugen von verschlüsselten Identitätsdaten unter Verwenden eines vor dem Erhalten-Schritt im SE erzeugten symmetrischen Schlüssels; Anwenden eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten durch das SE zum Erhalten eines MAC; und Erstellen und Senden einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Antwort die verschlüsselten Identitätsdaten und den MAC enthält.
• Mit diesem Verfahren werden Teilschritte zum Erhalten einer Antwort auf eine Identitätsabfrage des Netzwerks vorab, vor Erhalt einer Identitätsabfrage, berechnet, die ggf. (permanent oder nicht-permanent) auf dem SE gespeichert sind. Wird dann eine Identitätsabfrage des Netzwerks im SE erhalten, werden nur noch die letzten Rechenschritte zur Berechnung der Antwort ausgehend von den gespeicherten Teilrechenergebnissen berechnet.
• Der Rechen- und damit auch Zeitaufwand zum Erstellen und Versenden einer Antwort mit verschlüsselten Identitätsdaten bei Erhalt der Identitätsabfrage ist damit stark verringert.
• Es können im Ergebnis viel einfachere und damit auch 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 Vorberechnung von Schlüsseln kann die 3GPP und ETSI Spezifikation eingehalten werden und die Leistung zur Erwiderung/Abarbeitung einer Identitätsabfrage deutlich gesteigert werden.
• Wahlweise enthält die Antwort-Nachricht zusätzlich zu den Identitätsdaten und dem MAC zudem den public key des SE, welcher zur Ableitung des symmetrischen Schlüssels verwendet wurde, insbesondere den ECC ephemeral public key des SE gemäß 3GPP TS 33.501. Der public key SE kann aber auch auf anderem Weg an das Netzwerk bereitgestellt werden.
• 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 „Plaintext 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 die 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 der 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-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 ist ein Schlüssel eines symmetrischen Kryptosystems, bei welchem im Gegensatz zu einem asymmetrischen Kryptosystem, beide Teilnehmer, hier SE und das Netzwerk, denselben Schlüssel verwenden, um Nachrichten/Daten zu ver/entschlüsseln.
• Der symmetrische Schlüssel kann vor der Verwendung 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.
• Der vor dem Erhalt der Identitätsabfrage erzeugte symmetrische Schlüssel wird aus einem Speicherbereich des SE entnommen, um den Verschlüsseln-Schritt durchzuführen. Das Erzeugen kann dem Schritt „2. Key-Agreement“ gemäß C.3.2-1 der 3GPP TS 33.501, Version 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 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.
• 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 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 an das Netzwerk um diese Zeitdauer zum Erstellen des symmetrischen Schlüssels verkürzt werden, die Identitätsabfrage wird damit zeitgerecht beantwortet.
• 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 Erstellen-und-Senden-Schritt in die Antwort integriert. Der öffentliche Schlüsselteil kann der „Eph. public key“ 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 erzeugt wird. 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 an das Netzwerk um diese Zeitdauer zum Erstellen des SE-individuellen kryptographischen Schlüsselpaars verkürzt werden, die Identitätsabfrage wird damit zeitgerecht beantwortet.
• Es ist vorgesehen, dass entweder das Erzeugen des symmetrischen Schlüssels oder das Erzeugen des SE-individuelle kryptographische Schlüsselpaars oder das Erzeugen des symmetrischen Schlüssels und das Erzeugen des SE-individuelle kryptographische 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 Speicherbereich des SE abgelegt und bei Ausführung des Verfahrens aus dem Speicherbereich des SE geladen. Das Ablegen im Speicherbereich des SE kann wahlweise ein permanentes (nicht-flüchtiges) oder ein flüchtiges Speichern sein, und der Speicherbereich entsprechend entweder ein nichtflüchtiger Speicher, NVM, oder ein flüchtiger Speicher, beispielsweise RAM.
• Der Zeitpunkt des Erzeugens des symmetrischen Schlüssels und/oder des erzeugten 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 Erzeugen des SE-individuellen kryptographischen Schlüsselpaars kann unmittelbar vor oder nach dem Senden einer Registrierungsanfrage an das Netzwerk vor dem Erhalt der Identitätsabfrage des Netzwerks sein.
• Der Zeitpunkt des Erzeugens des symmetrischen Schlüssels und/oder des Erzeugen 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.
• Vor dem Verschlüsseln-Schritt kann in einem Prüfen-Schritt vom SE geprüft werden, ob der zum Erzeugen des symmetrischen Schlüssels verwendete öffentliche Schlüsselteil des kryptografischen Schlüsselpaars des Netzwerks zwischenzeitlich geändert wurde, wobei der Verschlüsseln-Schritt nur ausgeführt wird, wenn der öffentliche Schlüsselteil des kryptografischen Schlüsselpaars des Netzwerks nicht geändert wurde. Mit diesem Prüfen-Schritt wird geprüft, ob der erzeugte symmetrische Schlüssel noch aktuell ist. Zum Erzeugen dieses symmetrischen Schlüssels wird ein öffentlicher Schlüsselteil des kryptografischen Schlüsselpaars des Netzwerks verwendet. Dieser öffentliche Schlüsselteil kann im Lebenszyklus eines SE aktualisiert oder geändert werden. Der vorab erzeugte symmetrische Schlüssel ist ab dem Zeitpunkt der Änderung/Aktualisierung des öffentlichen Schlüsselteils des kryptografischen Schlüsselpaars des Netzwerks 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. Bei festgestellter Änderung des öffentlichen Schlüsselteils des kryptografischen Schlüsselpaars des Netzwerks wird das konventionelle Verfahren zum Erzeugen der Antwort auf die Identitätsabfrage ausgefiihrt., Je nach Rahmenbedingungen, beispielsweise ob die zu Grunde liegende elliptische Kurve beibehalten wurde oder geändert wurde, können manche (private) Schlüssel weiterverwendet werden, oder alle Schlüssel müssen geändert werden. Eventuell kann insbesondere der private Schlüsselteil des SE-individuellen kryptographischen Schlüsselpaars wiederverwendet werden.
• Die Änderung dieses Schlüsselteils betrifft einen Zeitraum zwischen dem Erzeugen des symmetrischen Schlüssels und dem Verschlüsseln-Schritt.
• 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 Versenden einer Antwort gemäß 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.
• In einem weiteren Aspekt umfasst die Erfindung ein Verfahren in einem Secure Element, SE, mit den Verfahrensschritten: Erzeugen eines SE-individuellen kryptographischen Schlüsselpaars in dem SE auf Basis eines ECC-Algorithmus; Erzeugen eines symmetrischen Schlüssels unter Verwendung eines privaten Schlüsselteils des SE-individuellen kryptographischen Schlüsselpaars und eines öffentlichen Schlüsselteils eines Netzwerk-Schlüsselpaars in dem SE; Erhalten einer von einem Netzwerk an das SE gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, erst nach dem Erzeugen-Schritt zum Erzeugen des SE-individuellen kryptographischen Schlüsselpaars oder (!) nach dem Erzeugen-Schritt des symmetrischen Schlüssels; Verschlüsseln von auf dem SE gespeicherten Identitätsdaten durch das SE, zum Erzeugen von verschlüsselten Identitätsdaten unter Verwenden des erzeugten symmetrischen Schlüssels; Anwenden eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten durch das SE zum Erhalten eines MAC; und Erstellen und Senden einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Nachricht die verschlüsselten Identitätsdaten und den MAC enthält.
• Das Erzeugen des SE-individuellen kryptographischen Schlüsselpaars in dem SE und/oder das Erzeugen des symmetrischen Schlüssels kann nach einem Erhalten eines STATUS Kommando oder eines SELECT Kommando in dem SE erfolgen.
• 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.
• 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 Speichern von Identitätsdaten, bevorzugt in zumindest einer Datei; und eine Steuereinheit, eingerichtet zum: Verschlüsseln der gespeicherten Identitätsdaten zum Erzeugen von verschlüsselten Identitätsdaten unter Verwenden eines vor dem Erhalt der Identitätsabfrage erzeugten symmetrischen Schlüssels; Anwenden eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten zum Erhalten eines MAC; und Erstellen und Senden einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Nachricht die verschlüsselten Identitätsdaten und den MAC enthält.
• 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 installiert in einem SE, 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 Modem 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 Kommunikationsnetzes, um Dienste des Kommunikationsnetzes nutzen zu können oder um Dienste eines Servers über ein Gateway des Kommunikationsnetzes nutzen zu können. Beispielsweise ist ein mobiles 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 Automat 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 Betriebssystem 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 EF_{Routing 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 versenden. 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 Netzwerk-Kennung, die den darin verborgenen SUPI enthält. Die 5G-USIM generiert eine SUCI anhand dieses 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 wird anhand von Figuren die Erfindung bzw. weitere Ausführungsformen und Vorteile der Erfindung näher erläutert, wobei die Figuren lediglich Ausführungsbeispiele der Erfindung beschreiben. Gleiche Bestandteile in den Figuren werden mit gleichen Bezugszeichen versehen. Die Figuren sind nicht als maßstabsgetreu anzusehen, es können einzelne Elemente der Figuren übertrieben groß bzw. übertrieben vereinfacht dargestellt sein. Optionale Elemente sind gestrichelt dargestellt.
• 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 zwischen einem SE, einem Gerät und einem Netzwerk; und
• 4 zeigt ein Ausführungsbeispiel eines Systems bestehend aus einem Gerät mit SE und einem Netzwerk; und
• 5 zeigt ein Ausführungsbeispiel eines SE.
• DETAILLIERTE BESCHREIBUNG VON AUSFÜHRUNGSBEISPIELEN
• 1 und 2 zeigen jeweils ein Ausführungsbeispiel eines Ablaufdiagrams eines erfindungsgemäßen Verfahrens 100 in einem SE der 4 und 5. Die 1 und 2 werden nachfolgend zusammen beschrieben. Die 2 entspricht einer vereinfachten Version der C.3.2-1 der 3GPP TS 33.501 in der Version 15.2.0 und zeigt bei Durchlaufen des Verfahrens am Punkt Ⓐ das konventionelle Verfahren (vereinfacht im Schritt „Erzeuge PubK_SE PrivK_SE 101), bei Durchlaufen des Verfahrens am Punkt Ⓑ eine bevorzugte Variante des erfindungsgemäßen Verfahrens (ebenfalls vereinfacht im Schritt „Ableiten 105).
• Im Schritt 101 wird ein SE-individuellen kryptographischen Schlüsselpaar PubK_SE, PrivK_SE in dem SE auf Basis eines ECC-Algorithmus erzeugt. Beispielsweise kommt 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. Im Ergebnis des Schritts 101 wurde ein privater Schlüsselteil PrivK_SE des SE-individuellen kryptographischen Schlüsselpaars erzeugt. Dieser Schritt kann dem Schritt „1. Eph key pair generation“ des Ablaufverfahrens gemäß C.3.2-1 entsprechen.
• Das SE-individuelle kryptographische Schlüsselpaar PubK_SE, PrivK_SE ist lediglich abhängig von der Art der Verschlüsselung die benutzt werden soll. Diese Art ist durch einen öffentlichen Schlüsselteil PubK_HN eines kryptographischen Schlüsselpaars eins Netzwerks vorgegeben. Dieser öffentliche Schlüsselteil PubK_HN ist dem SE vor dem Ausführen des Schritts 101 bekannt.
• In einem SE ohne Crypto-Co-Prozessor oder ohne Multiplikationsbeschleuniger kann dieser Schritt bis zu 3 Sekunden dauern, siehe Tabellen 1 bis 6.
• Nicht dargestellt in 1 ist ein Abspeichern-Schritt, zum Ablegen des SE-individuellen kryptographischen Schlüsselpaar PubK_SE, PrivK_SE in einem Speicherbereich des SE zur späteren Verwendung.
• Der öffentliche Teil PubK_SE wird als Teil einer Antwort 108 auf eine Identitätsabfrage des Netzwerks an das Netzwerk gesendet.
• Im darauffolgenden Schritt 102 wird ein symmetrischer Schlüssel SharedK_SE-HN in dem SE erzeugt. Dieser symmetrische Schlüssel SharedK_SE-HN wird unter Verwendung des in Schritt 101 erzeugten öffentlichen 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üsselteils PubK_HN ist im SE vorhanden und kann bereits bei Personalisierung des SE im Speicher des SE abgelegt sein. Dieser Schritt kann dem Schritt „2. Key agreement“ des Ablaufverfahrens gemäß C.3.2-1 entsprechen. In einem SE ohne Crypto-Co-Prozessor oder ohne Multiplikationsbeschleuniger kann dieser Schritt bis zu 3 Sekunden dauern, siehe Tabellen 1 bis 6.
• Nicht dargestellt in 1 ist ein Abspeichern-Schritt, zum Ablegen des symmetrischen Schlüssels SharedK_SE-HN in einem Speicherbereich des SE zur späteren Verwendung.
• In einem darauffolgenden Schritt 103 (gezeigt in 1, aber nicht gezeigt in 2) wird eine Identitätsabfrage im Rahmen eines GET IDENTITY Kommandos im SE empfangen. Zwischen dem Schritt 102 und dem Schritt 103 kann eine größere Zeitspanne „Zeit“ liegen, die Schritte 101/102 können zu dem Schritt 103 zeitlich unkorreliert sein. Erfindungsgemäß ist vorgesehen, dass zumindest einer der beiden Schritte 101 und 102 (in 1 sind es beide Schritte 101, 102) bereits vor dem Erhalten-Schritt 103 der Identitätsabfrage durchgeführt wurde, um die Zeitspanne zur Erzeugung einer Antwort auf die Identitätsabfrage zu verkürzen.
• Im optionalen Schritt 104 (gezeigt in 1, aber nicht gezeigt in 2) wird geprüft, ob der im Erzeugen-Schritt 102 verwendete öffentliche Schlüsselteil PubK_HN zwischenzeitlich geändert wurde. Wird bei dem Prüfen 104 festgestellt, dass der im Erzeugen-Schritt 102 verwendete öffentliche Schlüsselteil PubK_HN zwischenzeitlich geändert (Aktualisierung, Parameteranpassung, Ersetzen) wurde (Ja-Fall), so wird der Schritt „Erzeuge SharedK_SE-HN 102“ erneut ausgeführt. Sollte sich sogar die Verschlüsselungsart geändert haben (Umschalten von Curve25519 auf secp256r1 oder umgekehrt), so wird das konventionelle Verfahren zum Erzeugen einer Antwort auf die Identitätsabfrage durchgeführt, so wie es in 2 ab dem Punkt „A“ dargestellt ist.
• Wird bei dem Prüfen 104 festgestellt, dass der im Erzeugen-Schritt 102 verwendete öffentliche Schlüsselteil PubK_HN zwischenzeitlich nicht geändert (Aktualisierung, Parameteranpassung, Ersetzen) wurde (Nein-Fall), so wird das erfindungsgemäße Verfahren zum Erzeugen einer Antwort auf die Identitätsabfrage weiter durchgeführt, so wie es in den 1 und 2 ab dem Punkt „B“ dargestellt ist.
• Die Schritte 101 und 102 sind in 1 gestrichelt dargestellt, da jeweils nur einer der beiden Schritte 101, 102 vor dem Schritt 103 ausgeführt sein muss, um eine maximale Zeitspanne Zeit_max zwischen Identitätsabfrage und Antwort nicht zu überschreiten. Es wird auf die Zeitwerte der Tabellen 1 bis 6 verwiesen. Dort sind die Zeiten gegenübergestellt, die benötigt werden, die Antwort 108 zu erstellen (Antwort auf GET IDENTITY) mit/ohne vorabberechnete Schlüssel. Es wird dort auch der Einfluss des Vorabberechnen des Schritts 101, des Schritts 102 und beider Schritte 101+102 dargestellt.
• Im optionalen Schritt 105 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 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 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 erfolgt ein Erstellen und Senden einer Antwort auf die Identitätsabfrage des Netzwerkes. Diese 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. $$\text{Antwort}={\text{PubK}}_{\text{SE}}\Vert {\text{Identit}\ddot{\text{a}}\text{tsdaten}}_{\text{verschl}\ddot{\text{u}}\text{sselt}}\Vert \text{MAC}\Vert optionaleParameter$$

  
• Diese Antwort 108 ist bevorzugt das Ergebnis des GET IDENTITY Kommandos.
• 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 die 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 der Schritte 101 und/oder 102 ersichtlich wird.
• In der Tabelle 1 wird ein SE ohne Krypto-Koprozessor und ohne Multiplikationsbeschleuniger, mit Hardware AES (Advanced Encryption Standard), SC000 Architektur zur Berechnung eines Profile A (Curve25519) mit IMSI SUCI Berechnung veranschaulicht. Der Schritt 101 benötigt bereits 1100 Millisekunden, der Schritt 102 benötigt 1101 Millisekunden. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach Schritt 101 und 102 ausgeführt wird, werden nur 23 Millisekunden benötigt. Wenn das Kommando GET IDENTITY (nur) mit vorausberechnetem Schlüssel nach Schritt 101 ausgeführt wird, werden nur 1120 Millisekunden benötigt. Wenn das Kommando GET IDENTITY ohne vorausberechnete Schlüssel nach Schritt 101 oder 102 ausgeführt wird, werden 2217 Millisekunden benötigt. D.h. das vorgestellte Verfahren schafft ein fast 100fach schnelleres Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn die Schritte 101 und 102 vorab berechnet werden und die entsprechenden Schlüssel aus dem Speicher des SE geladen werden. D.h. das vorgestellte Verfahren schafft ein fast doppelt so schnelles Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn der Schritt vorabberechnet wird und das Schlüsselpaar aus dem Speicher des SE geladen wird. Tabelle 1 - Berechnung mit SE mit SC000 Architektur mit HW-AES

  SC000 mit HW-AES Profile A	Zeit in ms	Anmerkungen
  Schritt 101 (pubK SE+privK SE)	1100	Schritt 101 während eines vorhergehenden STATUS oder SELECT Kommando
  Schritt 102 (Shared K SE-HN)	1101	Schritt 102 während eines vorhergehenden STATUS oder SELECT Kommando
  GET IDENTITY mit vorausberechnetem PubK SE + PrivK SE + Shared K SE-HN	23	Schritt 101 und Schritt 102 vor dem GET IDENTITY Kommando
  GET IDENTITY mit vorausberechnetem PubK SE + PrivK SE	1120	Schritt 102 erst nach GET IDENTITY Kommando
  GET IDENTITY ohne vorausberechnetem PubK SE + PrivK SE + Shared K SE-HN	2217	konventionelle GET IDENTITY Kommandoabarbeitung

• In der Tabelle 2 wird ein SE „ohne Krypto-Koprozessor, ohne Multiplikationsbeschleuniger, mit Hardware AES, SC000 Architektur“ zur Berechnung eines Profile B (secp256r1) mit einer IMSI SUCI Kalkulierung veranschaulicht. Der Schritt 101 benötigt bereits 2934 Millisekunden, der Schritt 102 benötigt 2938 Millisekunden. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach Schritt 101 und 102 ausgeführt wird, werden nur 23 Millisekunden benötigt. Wenn das Kommando GET IDENTITY (nur) mit vorausberechnetem Schlüssel nach Schritt 101 ausgeführt wird, werden nur 2957 Millisekunden benötigt. Wenn das Kommando GET IDENTITY ohne vorausberechnete Schlüssel nach Schritt 101 oder 102 ausgeführt wird, werden 5884 Millisekunden benötigt. D.h. das vorgestellte Verfahren schafft ein fast 250fach schnelleres Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn die Schritte 101 und 102 vorab berechnet werden und die entsprechenden Schlüssel aus dem Speicher des SE geladen werden. D.h. das vorgestellte Verfahren schafft ein fast doppelt so schnelles Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn der Schritt vorabberechnet wird und das Schlüsselpaar aus dem Speicher des SE geladen wird. Tabelle 2 - Berechnung mit SE mit SC000 Architektur mit HW-AES

  SC000 mit HW-AES Profile B	Zeit in ms	Remarks
  Schritt 101 (pubK SE+privK SE)	2934	Schritt 101 während eines vorhergehenden STATUS oder SELECT Kommando
  Schritt 102 (Shared K SE-HN)	2938	Schritt 102 während eines vorhergehenden STATUS oder SELECT Kommando
  GET IDENTITY mit vorausberechnetem PubK SE + PrivK SE + Shared K SE-HN	23	Schritt 101 und Schritt 102 vor dem GET IDENTITY Kommando
  GET IDENTITY mit vorausberechnetem PubK SE + PrivK SE	2957	Schritt 102 erst nach GET IDENTITY Kommando
  GET IDENTITY ohne vorausberechnetem PubK SE + PrivK SE + Shared K SE-HN	5884	konventionelle GET IDENTITY Kommandoabarbeitung

• In der Tabelle 3 wird ein SE „ohne Krypto-Koprozessor, SC300 Architektur (beinhaltet Multiplikationsbeschleuniger)“ zur Berechnung eines Profile A (Curve25519) mit einer IMSI SUCI Kalkulierung veranschaulicht. Der Schritt 101 benötigt bereits 119 Millisekunden, der Schritt 102 benötigt 96 Millisekunden. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach Schritt 101 und 102 ausgeführt wird, werden nur 23 Millisekunden benötigt. Wenn das Kommando GET IDENTITY (nur) mit vorausberechnetem Schlüssel nach Schritt 101 ausgeführt wird, werden nur 117 Millisekunden benötigt. Wenn das Kommando GET IDENTITY ohne vorausberechnete Schlüssel nach Schritt 101 oder 102 ausgeführt wird, werden 234 Millisekunden benötigt. D.h. das vorgestellte Verfahren schafft ein fast 10fach schnelleres Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn die Schritte 101 und 102 vorabberechnet werden und die entsprechenden Schlüssel aus dem Speicher des SE geladen werden. D.h. das vorgestellte Verfahren schafft ein fast doppelt so schnelles Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn der Schritt vorab berechnet wird und das Schlüsselpaar aus dem Speicher des SE geladen wird. Tabelle 3 - Berechnung mit SE mit SC300 Architektur

  SC300 Profile A	Zeit in ms	Anmerkungen
  Schritt 101 (pubK SE+privK SE)	119	Schritt 101 während eines vorhergehenden STATUS oder SELECT Kommando
  Schritt 102 (Shared K SE-HN)	96	Schritt 102 während eines vorhergehenden STATUS oder SELECT Kommando
  GET IDENTITY mit vorausberechnetem PubK SE + PrivK SE + Shared K SE-HN	23	Schritt 101 und Schritt 102 vor dem GET IDENTITY Kommando
  GET IDENTITY mit vorausberechnetem PubK SE + PrivK SE	117	Schritt 102 erst nach GET IDENTITY Kommando
  GET IDENTITY ohne vorausberechnetem PubK SE + PrivK SE + Shared K SE-HN	234	konventionelle GET IDENTITY Kommandoabarbeitung

• In der Tabelle 4 wird ein SE „ohne Krypto-Koprozessor, SC300 Architektur (beinhaltet Multiplikationsbeschleuniger)“ zur Berechnung eines Profile B (secp256r1) mit einer IMSI SUCI Kalkulierung veranschaulicht. Der Schritt 101 benötigt bereits 424 Millisekunden, der Schritt 102 benötigt 406 Millisekunden. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach Schritt 101 und 102 ausgeführt wird, werden nur 23 Millisekunden benötigt. Wenn das Kommando GET IDENTITY (nur) mit vorausberechnetem Schlüssel nach Schritt 101 ausgeführt wird, werden nur 427 Millisekunden benötigt. Wenn das Kommando GET IDENTITY ohne vorausberechnete Schlüssel nach Schritt 101 oder 102 ausgeführt wird, werden 848 Millisekunden benötigt. D.h. das vorgestellte Verfahren schafft ein fast 40fach schnelleres Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn die Schritte 101 und 102 vorabberechnet werden und die entsprechenden Schlüssel aus dem Speicher des SE geladen werden. D.h. das vorgestellte Verfahren schafft ein fast doppelt so schnelles Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn der Schritt vorab berechnet wird und das Schlüsselpaar aus dem Speicher des SE geladen wird. Tabelle 4 - Berechnung mit SE mit SC300 Architektur

  SC300 Profile B	Zeit in ms	Anmerkungen
  Schritt 101 (pubK SE+privK SE)	424	Schritt 101 während eines vorhergehenden STATUS oder SELECT Kommando
  Schritt 102 (Shared K SE-HN)	406	Schritt 102 während eines vorhergehenden STATUS oder SELECT Kommando
  GET IDENTITY mit vorausberechnetem PubK SE + PrivK SE + Shared K SE-HN	23	Schritt 101 und Schritt 102 vor dem GET IDENTITY Kommando
  GET IDENTITY mit vorausberechnetem PubK SE + PrivK SE	427	Schritt 102 erst nach GET IDENTITY Kommando
  GET IDENTITY ohne vorausberechnetem PubK SE + PrivK SE + Shared K SE-HN	848	konventionelle GET IDENTITY Kommandoabarbeitung

• In der Tabelle 5 wird ein SE ohne Krypto-Koprozessor und ohne Multiplikationsbeschleuniger, ohne Hardware AES, SC000 Architektur“ zur Berechnung eines Profile A veranschaulicht. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach Schritt 101 und 102 ausgeführt wird, werden nur 38 Millisekunden benötigt. Wenn das Kommando GET IDENTITY (nur) mit vorausberechnetem Schlüssel nach Schritt 101 ausgeführt wird, werden nur 1303 Millisekunden benötigt. Wenn das Kommando GET IDENTITY ohne vorausberechnete Schlüssel nach Schritt 101 oder 102 ausgeführt wird, werden 2606 Millisekunden benötigt. D.h. das vorgestellte Verfahren schafft ein fast 70fach schnelleres Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn die Schritte 101 und 102 vorab berechnet werden und die entsprechenden Schlüssel aus dem Speicher des SE geladen werden. D.h. das vorgestellte Verfahren schafft ein fast doppelt so schnelles Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn der Schritt vorabberechnet wird und das Schlüsselpaar aus dem Speicher des SE geladen wird. Tabelle 5 - Berechnung mit SE mit SC000 Architektur ohne HW-AES

  SC000 ohne HW-AES Profile A	Zeit in ms	Anmerkungen
  GET IDENTITY mit vorausberechnetem PubK SE + PrivK SE + Shared K SE-HN	38	Schritt 101 und Schritt 102 vor dem GET IDENTITY Kommando
  GET IDENTITY mit vorausberechnetem PubK SE + PrivK SE	1303	Schritt 102 erst nach GET IDENTITY Kommando
  GET IDENTITY ohne vorausberechnetem PubK SE + PrivK SE + Shared K SE-HN	2606	konventionelle GET IDENTITY Kommandoabarbeitung

• In der Tabelle 6 wird ein SE ohne Krypto-Koprozessor und ohne Multiplikationsbeschleuniger, ohne Hardware AES, SC000 Architektur“ zur Berechnung eines Profile A veranschaulicht. Wenn das Kommando GET IDENTITY mit vorausberechneten Schlüsseln nach Schritt 101 und 102 ausgeführt wird, werden nur 38 Millisekunden benötigt. Wenn das Kommando GET IDENTITY (nur) mit vorausberechnetem Schlüssel nach Schritt 101 ausgeführt wird, werden nur 3251 Millisekunden benötigt. Wenn das Kommando GET IDENTITY ohne vorausberechnete Schlüssel nach Schritt 101 oder 102 ausgeführt wird, werden 6464 Millisekunden benötigt. D.h. das vorgestellte Verfahren schafft ein 280fach schnelleres Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn die Schritte 101 und 102 vorab berechnet werden und die entsprechenden Schlüssel aus dem Speicher des SE geladen werden. D.h. das vorgestellte Verfahren schafft ein fast doppelt so schnelles Erstellen einer Antwort auf das GET IDENTITY Kommando, wenn der Schritt vorabberechnet wird und das Schlüsselpaar aus dem Speicher des SE geladen wird. Tabelle 6 - Berechnung mit SC000 ohne HW-AES

  SC000 ohne HW-AES Profile B	Zeit in ms	Anmerkungen
  GET IDENTITY mit vorausberechnetem PubK SE + PrivK SE + Shared K SE-HN	38	Schritt 101 und Schritt 102 vor dem GET IDENTITY Kommando
  GET IDENTITY mit vorausberechnetem PubK SE + PrivK SE	3251	Schritt 102 erst nach GET IDENTITY Kommando
  GET IDENTITY ohne vorausberechnetem PubK SE + PrivK SE + Shared K SE-HN	6464	konventionelle GET IDENTITY Kommandoabarbeitung

• Die gemessenen Zeiten sind Beispielwerte welche selbstverständlich von verschiedenen Faktoren abhängig sind, wie z.B. Spannungsklassen, Frequenzen und Implementierung der jeweiligen kryptografischen Funktionen. So kann lediglich ein Zeitverhalten zueinander jedoch nicht eine exakte Berechnungsdauer für spezifische Fälle abgeleitet werden.
• Mit Hilfe der Vorberechnung im Schritt 101 bzw. zusätzlicher Voraberzeugung des symmetrischen Schlüssels im Schritt 102 kann 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.
• Die Identitätsabfrage ist beispielsweise ein APDU-Kommando eines Endgeräts der 4, in dem das SE eingebracht ist und mittels dem das SE eine SUCI erstellt. Die Identitätsabfrage muss nicht vom Endgerät ursprünglich initiiert worden sein, es kann eine Anfrage sein, die vom Netzwerk (4) über die Kommunikationsschnittstelle 41 an das Endgerät herangetragen wurde. Beispielsweise wird eine Netzwerkkennung abgefragt. Beispielsweise werden personenbezogene Daten abgefragt, die in dem SE abgespeichert sind.
• Die SUCI-Berechnung in der 5G USIM-Funktionalität, wie in ETSI TS 102.221, ab Version 15 und 3GPP TS 31.102, ab Version 15, definiert, sollte vom SE unterstützt werden.
• In der 3 wird nun ein Ablaufdiagramm eines bevorzugtes Ausführungsbeispiel zur Durchführung des erfindungsgemäßen Verfahrens 100 beschrieben. Die Verfahrensschritte 101 bis 108 entsprechen den Verfahrensschritten 101 bis 108 der 1 oder 2. Das SE ist in 3 eine 5G USIM.
• Nach dem Schritt 102 wird vom Endgerät eine Registrierungsanfrage an das Netzwerk gestellt. Diese Registrierungsanfrage soll es dem Endgerät ermöglichen, 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.
• 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 Versenden der SUCI der MSIN Teil der IMSI nicht im Klartext an das Endgerät bzw. das Netzwerk gesendet wird. Das Versenden der SUCI würde demnach die sicherheitsrelevante und/oder personenbezogene Information aus der Datei EF_IMSI schützen, sodass die SUCI anstelle der IMSI als Netzwerkkennung zu versenden.
• 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 und 2 mit den Schritten 101 bis 108 angewendet. Diese Berechnung kann den standardisierten Vorgehensweisen gemäß 3 GPP 23.501 und wird erfindungsgemäß durch das Vorabberechnen in den Schritten 101 und 102 wesentlich verbessert, um zeitaufwendige Berechnungen nach dem Schritt 103 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 und 2. Das SE erzeugt im Schritt 101 und 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.
• 4 zeigt ein Ausführungsbeispiel eines Systems aus Endgerät und SE, in der das Verfahren der 1 und 2 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 wird 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 5 detaillierter dargestellt. In 4 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 zur SE aufbauen. Die Kommunikation 3 zwischen dem Endgerät und der SE erfolgt beispielsweise gemäß den in der internationalen Normen ISO/IEC 7816-3 und ISO/IEC 7816-4 definierten Protokollen, auf die hiermit ausdrücklich Bezug genommen wird.
• Der gesamte Datenaustausch zwischen SE und dem Endgerät findet bevorzugt unter Verwendung der sogenannten APDUs (application protocol data units) gemäß der Norm ISO/IEC 7816-4 statt. Eine APDU stellt eine Dateneinheit der Anwendungsschicht dar, also eine Art Container, mit dem Kommandos und/ oder Daten an 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 dabei 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.
• 5 zeigt ein Blockschaltbild einer 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 und 2 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äß 4 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 Ausfuhrungsform 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 (Schritt 103 des Verfahrens 100 in der 1 oder 2).
• 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 und 2 auszuführen, wenn entsprechender Programmcode ausgeführt wird.
• Bei der in 5 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 4 gezeigte CAT 12 gemäß ETSI TS 102 223 eingebracht.
• Heutige Endgeräte, wie Smartphones, enthalten ein Chipset, die 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 und 2). 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

101-108

Verfahrensschritte gemäß der Erfindung

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

Zeit

Zeitspanne zwischen Schlüsselvorberechnung und Anfrage

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 (15)

1. Ein Verfahren (100) in einem Secure Element, SE, mit den Verfahrensschritten: - Erhalten (103), im SE, einer von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos; - 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 Verwenden eines vor dem Erhalten-Schritt (103) im SE erzeugten symmetrischen Schlüssels (SharedK_SE-HN); - Anwenden (105) eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten (Identitätsdaten_{verschlüsselt}) durch das SE zum Erhalten eines MAC (MAC); und - Erstellen und Senden (108) einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Antwort die verschlüsselten Identitätsdaten (Identitätsdaten_{verschlüsselt}) und den MAC (MAC) enthält.
2. Das Verfahren (100) nach Anspruch 1, wobei der symmetrische Schlüssel (SharedK_SE-HN) unter Verwendung eines öffentlichen Schlüsselteils (PubK_HN) eines kryptografischen Schlüsselpaars des Netzwerks erzeugt (102) wurde.
3. Das Verfahren (100) nach Anspruch 1 oder 2, wobei der symmetrische Schlüssel (SharedK_SE-HN) unter Verwendung eines privaten Schlüsselteils (PrivK_SE) eines SE-individuellen kryptographischen Schlüsselpaars erzeugt (102) wurde.
4. Das Verfahren (100) nach Anspruch 3, wobei das SE-individuelle kryptographische Schlüsselpaar (PubK_SE, PrivK_SE) vor dem Erhalt (103) der Identitätsabfrage von dem SE erzeugt wurde, wobei bevorzugt das SE-individuelle kryptographische Schlüsselpaar (PubK_SE, PrivK_SE) auf Basis eines ECC-Algorithmus erzeugt wurde.
5. Das Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei der symmetrische Schlüssel (SharedK_SE-HN) und/oder das SE-individuelle kryptographische Schlüsselpaar (PubK_SE, PrivK_SE) bereits vor oder nach dem Senden einer Registrierungsanfrage des SE an das Netzwerk erzeugt wurde.
6. Das Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei vor dem Verschlüsseln-Schritt (106) in einem Prüfen-Schritt (104) vom SE geprüft wird, ob der zum Erzeugen (102) des symmetrischen Schlüssels (SharedK_SE-HN) verwendete öffentliche Schlüsselteil (PubK_HN) des kryptografischen Schlüsselpaars des Netzwerks zwischenzeitlich geändert wurde, wobei der Verschlüsseln-Schritt (106) nur ausgeführt wurde, wenn der öffentliche Schlüsselteil (PubK_HN) des kryptografischen Schlüsselpaars des Netzwerks nicht geändert wurde.
7. Das Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei das SE keinen Verschlüsselungs-Co-Prozessor und auch keinen Multiplikationsbeschleuniger aufweist.
8. Das Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei die Identitätsdaten in zumindest einer Datei (EF_IMSI, EF_NSI) des SE abgelegt sind, wobei die zumindest eine Datei (EF_IMSI) bevorzugt die Datei EF_IMSI ist, die eine internationale Mobilfunk-Teilnehmerkennung, IMSI/NSI, beinhaltet, wobei bevorzugt die Antwort auf die Identitätsabfrage eine Subscription Concealed Identifier-, SUCI-, umfasst.
9. Ein Verfahren (100) in einem Secure Element, SE, mit den Verfahrensschritten: - Erzeugen (101) eines SE-individuellen kryptographischen Schlüsselpaars (PubK_SE, PrivK_SE) in dem SE auf Basis eines ECC-Algorithmus; - Erzeugen (102) eines symmetrischen Schlüssels (SharedK_SE-HN) unter Verwendung eines privaten Schlüsselteils (PrivK_SE) des SE-individuellen kryptographischen Schlüsselpaars (PubK_SE, PrivK_SE) und eines öffentlichen Schlüsselteils (PubK_HN) eines Netzwerk-Schlüsselpaars in dem SE; - Erhalten (103) einer von einem Netzwerk an das SE gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos, erst nach dem Erzeugen-Schritt (101) zum Erzeugen des SE-individuellen kryptographischen Schlüsselpaars (PubK_SE, PrivK_SE) oder nach dem Erzeugen-Schritt (102) des symmetrischen Schlüssels (SharedK_SE-HN); - 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 Verwenden des erzeugten symmetrischen Schlüssels (SharedK_SE-HN); . - Anwenden (107) eines Nachrichtenauthentifizierungscode, MAC, -Algorithmus auf die erzeugten verschlüsselten Identitätsdaten (Identitätsdaten_{verschlüsselt}) durch das SE zum Erhalten eines MAC (MAC), - Senden (108) einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Nachricht die verschlüsselten Identitätsdaten (Identitätsdaten_{verschlüsselt}) und den MAC (MAC) enthält.
10. Das Verfahren (100) nach Anspruch 9, wobei das Erzeugen (101) des SE-individuellen kryptographischen Schlüsselpaars (PubK_SE, PrivK_SE) in dem SE und/oder das Erzeugen (102) des symmetrischen Schlüssels (SharedK_SE-HN) nach einem Erhalten eines STATUS Kommando oder eines SELECT Kommando in dem SE erfolgt.
11. Das Verfahren (100) nach einem der Ansprüche 8 oder 9, wobei das Erzeugen (101) des SE-individuellen kryptographischen Schlüsselpaars (PubK_SE, PrivK_SE) in dem SE und/oder das Erzeugen (102) des symmetrischen Schlüssels (SharedK_SE-HN) vor dem Senden einer Registrierungsanfrage an das Netzwerk erfolgt.
12. Ein Secure Element, SE, bevorzugt ein Teilnehmeridentitätsmodul der fünften Generation, aufweisend: - eine Schnittstelle (31), eingerichtet zum Erhalten (103) einer von einem Netzwerk gesendeten Identitätsabfrage, insbesondere eines GET IDENTITY Kommandos; - einen nicht-flüchtigen Speicher (17), eingerichtet zum Speichern von Identitätsdaten, bevorzugt in zumindest einer Datei (EF_IMSI); und - eine Steuereinheit (19), eingerichtet zum: ◯ Verschlüsseln (106) der gespeicherten Identitätsdaten zum Erzeugen von verschlüsselten Identitätsdaten (Identitätsdaten_{verschlüsselt}) unter Verwenden eines vor dem Erhalt (103) der Identitätsabfrage erzeugten symmetrischen Schlüssels (SharedK_SE-HN); ◯ Anwenden (107) eines Nachrichtenauthentifizierungscode, MAC, - Algorithmus auf die erzeugten verschlüsselten Identitätsdaten (Identitätsdaten_{verschlüsselt}) zum Erhalten eines MAC (MAC); und ◯ Erstellen und Senden (108) einer Antwort auf die Identitätsabfrage vom SE an das Netzwerk, wobei die Nachricht die verschlüsselten Identitätsdaten (Identitätsdaten_{verschlüsselt}) und den MAC (MAC) enthält.
13. 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äß einem der Ansprüche 1 bis 11 durchzuführen.
14. Ein Computerprogramprodukt ausführbar installiert in einem SE, bevorzugt einem Teilnehmeridentitätsmodul der fünften Generation, und aufweisend Mittel zum Ausführen der Verfahrensschritte des Verfahrens (100) gemäß einem der Ansprüche 1 bis 11.
15. 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äß einem der Ansprüche 1 bis 11 eingerichtet ist.

Images