DE102017215230A1

DE102017215230A1 - Sichere kontrolle von profilrichtlinienregeln

Info

Publication number: DE102017215230A1
Application number: DE102017215230.3A
Authority: DE
Inventors: Xiangying Yang
Original assignee: Apple Inc
Current assignee: Apple Inc
Priority date: 2016-09-16
Filing date: 2017-08-31
Publication date: 2018-03-22
Anticipated expiration: 2037-09-01
Also published as: US20180084426A1; DE102017215230B4; CN107835204A; US10506439B2; CN107835204B

Abstract

Ein sicheres Element (SE) in einer Vorrichtung verarbeitet Aktualisierungsinformationen von Profilrichtlinienregeln (PPR) in einer Nachricht. Das SE verwendet eine Regelberechtigungstabelle (RAT) beim Verarbeiten der Nachricht, um zu kontrollieren, ob ein PPR-EIN/AUS-Zustand angepasst wird. Die PPR-Informationen identifizieren ein Profil. Zum Beispiel kann ein Mobilfunkbetreiber (MNO), der die Kontrolle über das Profil hat, eine Richtlinie festlegen, die angibt, dass das Profil zu löschen ist, wenn das Profil deaktiviert wird. Das SE konsultiert die RAT, um Überprüfungsregeln für die identifizierte Richtlinie zu bestimmen. In einigen Ausführungsformen werden Infrastrukturtechniken für öffentliche Schlüssel zum Authentifizieren einer Signatur verwendet, um zu überprüfen, dass der MNO die Nachricht signiert hat. Wenn die Überprüfung der Signatur nicht erfolgreich ist, wird keine Änderung am PPR-EIN/AUS-Zustand vorgenommen.

Description

GEBIET
Die beschriebenen Ausführungsformen betreffen eine Sicherheitsverbesserung für die Einstellung von Profil-(eSIM-)Richtlinienregeln (eSIM = electronic Subscriber Identity Module).
HINTERGRUND
Ein eSIM oder Profil schließt Software und Authentifizierungsfunktionen ein, die einen Mobilfunkbetreiber (MNO) betreffen. Das Profil kann auf einem sicheren Element (SE) innerhalb einer Drahtlosvorrichtung vorhanden sein, die Dienste von dem MNO empfängt. Der MNO kann eine Richtlinie von Aktionen haben, die im Hinblick auf das Profil zum Beispiel zum Zeitpunkt eines Profilverwaltungsereignisses unternommen werden sollen. Ein Beispiel eines Profilverwaltungsereignisses ist das Deaktivieren eines Profils. Der Ein/Aus-Zustand der Richtliniendurchsetzung sollte der Kontrolle des MNO unterliegen.
Universal Integrated Circuit Cards (UICCs) und eingebettete UICCs (eUICCs) sind SEs zum Hosten von Profilen. Bei einem Profil handelt es sich um eine Kombination aus Betreiberdaten und Anwendungen, die auf einer SE in einer Vorrichtung zum Zweck des Bereitstellens von Diensten durch einen Betreiber, zum Beispiel einen MNO, bereitgestellt werden. Ein Universal Subscriber Identity Module (USIM) ist ein Profiltyp. Ein Profil kann durch eine eindeutige Nummer gekennzeichnet werden, die ICCID (Integrated Circuit Card Identifier) genannt wird. Bei einem Drahtlosbetreiber handelt es sich um ein Unternehmen, das drahtlose Mobilfunknetzdienste bereitstellt. Ein MNO ist eine Entität, die ihren Teilnehmern durch eine Mobilnetzwerkinfrastruktur Zugangsfähigkeit und Kommunikationsdienste bereitstellt. Eine Drahtlosvorrichtung kann hierin auch einfach als Vorrichtung bezeichnet werden. Bei einem Endbenutzer oder Kunden handelt es sich um eine Person, die eine Vorrichtung verwendet. Ein aktiviertes Profil kann Dateien und/oder Anwendungen einschließen, die über eine Schnittstelle zwischen SE und Vorrichtung auswählbar sind. Zum Verwenden der Vorrichtung wird das Profil mit dem MNO aktiviert. Ein Dokument in Bezug auf das Verwalten von Profilen in Verbrauchervorrichtungen ist das Dokument der GSM Association, GSMA SGP.22: „RSP Technical Specification", Version 1.1, 9. Juni 2016 (hierin nachstehend „SGP.22"). Zwei Dokumente in Bezug auf SEs in Maschine-zu-Maschine-Vorrichtungen, die Richtlinien enthalten, sind das Dokument der GSM Association, GSMA SGP.01: „Embedded SIM Remote Provisioning Architecture", Version 1.1, 30. Januar 2014 (nachstehend „SGP.01"), und das Dokument der GSM Association, GSMA SGP.02: „Remote Provisioning Architecture for Embedded UICC Technical Specification", Version 3.1, 27. Mai 2016 (nachstehend „SGP.02"). Eine Vorrichtung kann eine Regelberechtigungstabelle einschließen und die Berechtigung einer angeforderten Zustandsänderung einer Profilrichtlinienregel (PPR) auf der Grundlage eines Vergleichs mit einer MNO-Kennung in der Regelberechtigungstabelle bewerten. Dieser Ansatz ist anfällig für Betrug, da jede Partei eine passende MNO-Kennung angeben kann.
ZUSAMMENFASSUNG
Repräsentative Ausführungsformen, die hierin dargelegt sind, offenbaren verschiedene Systeme und Techniken für sichere Kontrolle von Profilrichtlinienregeln.
Ein MNO erstellt in einigen Fällen Richtlinien zum Bestimmen von Aktionen, die in Bezug auf ein Profil infolge des Auftretens eines bestimmten Ereignisses zu unternehmen sind. In einigen Fällen werden Richtlinien durch eine Richtlinienregeln-Durchsetzungsfunktion durchgesetzt, die vom Betriebssystem des SE durchgeführt wird. Eine Regelberechtigungstabelle (RAT) kann in dem SE vorhanden sein. Ein EIN/AUS-Zustand jeder Richtlinie ist in einigen Ausführungsformen in dem SE gespeichert. Eine PPR kann von einem MNO, der die Kontrolle über das zugehörige Profil hat, aktualisiert werden, oder in einigen Fällen kann eine PPR von einer anderen Partei aktualisiert werden. Ein Bewerten der Berechtigung zum Aktualisieren der PPR beruht in einigen Ausführungsformen auf PKI-Parametern, die mithilfe der RAT zu finden sind.
Wenn das SE PPR-Aktualisierungsinformationen empfängt, prüft es eine Prüfpunktspalte der Infrastruktur des öffentlichen Schlüssels (PKI) in der RAT, um zu bestimmen, ob der PKI-Prüfpunkt für die spezielle PPR, die in den PPR-Aktualisierungsinformationen angegeben ist, definiert ist. Die PPR-Aktualisierungsinformationen sind in einigen Ausführungsformen in einer Richtlinienregelbeschreibung eines Profils, das auf das SE heruntergeladen wird, enthalten. Der PKI-Prüfpunkt gibt an, wie eine Berechtigungsprüfung der PPR-Aktualisierungsmeldung auf der Grundlage von PKI-Kryptografiemethoden durchzuführen ist. Für eine bestimmte PPR in der Tabelle beziehen sich die entsprechenden Zeileneinträge auf eine oder mehrere vertrauenswürdige Entitäten in Bezug auf die spezielle PPR.
In einigen Ausführungsformen löst das SE ein PPR-Aktualisierungsinformationsereignis aus, indem ein TLS-Kanal (Transport Layer Security, Transportschichtsicherheit) mit einem MNO-Server errichtet wird, ohne zwangsläufig ein entsprechendes Profil zu aktivieren.
Diese Zusammenfassung wird lediglich zu Zwecken des Zusammenfassens mancher Beispielausführungsformen bereitgestellt, um ein grundlegendes Verständnis mancher Aspekte des hierin beschriebenen Gegenstandes bereitzustellen. Dementsprechend ist ersichtlich, dass die vorstehend beschriebenen Merkmale lediglich Beispiele darstellen und nicht als den Umfang oder Geist des hierin beschriebenen Gegenstands in irgendeiner Weise einengend aufgefasst werden sollten. Weitere Merkmale, Aspekte und Vorteile des beschriebenen Gegenstands werden anhand der folgenden detaillierten Beschreibung, der Figuren und der Ansprüche ersichtlich.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die eingeschlossenen Zeichnungen sind lediglich für veranschaulichende Zwecke und dienen nur dazu, Beispiele möglicher Strukturen und Anordnungen für die offenbarten Systeme und Techniken zum intelligenten und effizienten Verwalten von Anrufen und anderer Kommunikation zwischen mehreren zugeordneten Benutzervorrichtungen bereitzustellen. Diese Zeichnungen schränken in keiner Weise Änderungen von Form und Details ein, die an den Ausführungsformen durch den Fachmann vorgenommen werden können, ohne vom Geist und Umfang der Ausführungsformen abzuweichen. Die Ausführungsformen werden leicht durch die folgende detaillierte Beschreibung in Verbindung mit den begleitenden Zeichnungen verstanden, in denen gleiche Bezugsziffern gleiche strukturelle Elemente bezeichnen.
1 veranschaulicht ein beispielhaftes System zur sicheren Kontrolle über Profilrichtlinienregeln gemäß einigen Ausführungsformen.
2 veranschaulicht beispielhafte Logik zur sicheren Kontrolle über Profilrichtlinienregeln gemäß einigen Ausführungsformen.
3 veranschaulicht einen beispielhaften Nachrichtenfluss, der eine Profilrichtlinienregel-(PPR-)Nachricht enthält, die an einem sicheren Element (SE) eintrifft, gemäß einigen Ausführungsformen.
4 veranschaulicht ein beispielhaftes System zur sicheren Kontrolle über Profilrichtlinienregeln mithilfe einer Authentifizierungsfunktion gemäß einigen Ausführungsformen.
5A veranschaulicht ein beispielhaftes binäres großes Objekt (BLOB), das bei einer Vorrichtung eintrifft, gemäß einigen Ausführungsformen.
5B veranschaulicht ein beispielhaftes BLOB, das eine PPR-Aktualisierungsnachricht und ein gebundenes Profilpaket (BPP) einschließt, gemäß einigen Ausführungsformen.
5C veranschaulicht ein beispielhaftes BLOB, das eine PPR-Aktualisierungsnachricht und kein BPP einschließt, gemäß einigen Ausführungsformen.
5D veranschaulicht eine beispielhafte PPR-Aktualisierungsnachricht mit einer Signatur gemäß einigen Ausführungsformen.
5E veranschaulicht beispielhafte Authentifizierungsvariablen, von denen eine oder mehrere in einem Authentifizierungsparameter einer PPR-Aktualisierungsnachricht vorhanden sein können, gemäß einigen Ausführungsformen.
6 veranschaulicht eine beispielhafte Logik für ein SE zum Verarbeiten einer PPR-Aktualisierungsnachricht gemäß einigen Ausführungsformen.
7 veranschaulicht eine beispielhafte Logik für ein SE zum Verarbeiten einer PPR-Aktualisierungsnachricht und, in einigen Fällen, Installieren eines Profils gemäß einigen Ausführungsformen.
8A veranschaulicht ein beispielhaftes System zur Kommunikation zwischen einem Server und einem SE mithilfe eines Kanals, der mit PKI-Techniken eingerichtet wurde, gemäß einigen Ausführungsformen.
8B veranschaulicht eine beispielhafte Logik, die von dem SE von 8A während des Kommunizierens mit dem Server von 8A verwendet wird, um eine Profilrichtlinienregel zu kontrollieren, gemäß einigen Ausführungsformen.
9 veranschaulicht eine beispielhafte Logik für ein SE zum Verarbeiten einer PPR-Aktualisierungsnachricht mithilfe einer Regelberechtigungstabelle (RAT) gemäß einigen Ausführungsformen.
10 veranschaulicht ein beispielhaftes Profil, das auf einem SE in einer Vorrichtung in Kommunikation mit einem eSIM-Server vorhanden ist, gemäß einigen Ausführungsformen.
11 veranschaulicht beispielhafte Verbindungsmethoden verschiedener in dieser Anmeldung beschriebener Entitäten gemäß einigen Ausführungsformen.
12 veranschaulicht eine beispielhafte Einrichtung zur Implementierung der hierin offenbarten Ausführungsformen gemäß einigen Ausführungsformen.
DETAILLIERTE BESCHREIBUNG
Stellvertretende Anwendungen von Einrichtungen, Systemen und Verfahren gemäß den vorliegend beschriebenen Ausführungsformen werden in diesem Abschnitt bereitgestellt. Diese Beispiele werden lediglich bereitgestellt, um Kontext hinzuzufügen und beim Verständnis der beschriebenen Ausführungsformen zu helfen. Es ist daher für den Fachmann ersichtlich, dass die vorliegend beschriebenen Ausführungsformen ohne manche oder alle dieser spezifischen Details ausgeführt werden können. In anderen Fällen wurden allgemein bekannte Prozessschritte nicht detailliert beschrieben, um ein unnötiges Verschleiern der vorliegend beschriebenen Ausführungsformen zu vermeiden. Andere Anwendungen sind möglich, sodass die folgenden Beispiele nicht als einschränkend verstanden werden sollten.
Profilrichtlinien
Wie vorstehend genannt, erstellt ein MNO in einigen Fällen Richtlinien zum Bestimmen von Aktionen, die in Bezug auf ein Profil infolge des Auftretens eines bestimmten Ereignisses zu unternehmen sind. Richtlinienprinzipien werden in einem Satz von Regeln widergespiegelt, die das Verhalten eines SE (z. B. einer eUICC) und/oder von Entitäten, die bei der Remote-Verwaltung des SE beteiligt sind, vorschreiben. Eine Richtlinienregel definiert eine atomische Aktion einer Richtlinie und die Bedingungen, unter denen die Aktion ausgeführt wird. Eine atomische Aktion ist eine, die entweder fehlerfrei abgeschlossen wird oder bei der, wenn ein Fehler auftritt, das Profil unverändert belassen wird. Beispiele für Richtlinien sind: i) Deaktivieren eines Profils ist nicht zulässig, ii) Löschen eines Profils ist nicht zulässig und/oder iii) Profillöschung ist zwingend, wenn das Profil deaktiviert wird.
Ein Profil kann eine Kombination aus Dateistruktur, Daten und Anwendungen sein, die auf einem SE, wie zum Beispiel einer eUICC, vorgesehen oder vorhanden sind. Das Profil ermöglicht bei Aktivierung Zugriff einer Vorrichtung auf eine spezifische Mobilnetzwerkinfrastruktur. Eine MNO-SD-Entität in dem Profil stellt, wenn das Profil aktiviert ist, einen sicheren OTA-Kanal (Over The Air) für den MNO, der dem Profil zugeordnet ist, bereit.
Die Profilrichtlinienregeln (PPRs) können in dem Profil, zu dem sie gehören, gespeichert sein. Der Zustand eines gegebenen Profils, aktiviert oder deaktiviert, ist in einer Zustandsvorrichtung in dem gegebenen Profil gespeichert. Eine ISD-P ist eine Sicherheitsdomäne, die zum Hosten eines Profils erstellt wird.
Wie vorstehend genannt, werden in einigen Fällen Richtlinien durch eine Richtlinienregeln-Durchsetzungsfunktion durchgesetzt, die vom Betriebssystem des SE durchgeführt wird. Eine Regelberechtigungstabelle (RAT) kann in dem SE vorhanden sein. Die Werte in der RAT können vom Hersteller des SE oder auf der Grundlage von Werten, die vom Hersteller der Vorrichtung, die das SE enthalten soll, oder von einem MNO in einer Geschäftsbeziehung mit dem Hersteller der Vorrichtung eingetragen werden. Ein EIN/AUS-Zustand jeder Richtlinie ist in einigen Ausführungsformen in dem SE gespeichert. Der EIN/AUS-Zustand einer gegebenen Richtlinie wird in einigen Ausführungsformen in dem Profil gespeichert, zu dem die gegebene Richtlinie gehört.

Eine PPR kann von einem MNO, der die Kontrolle über das zugehörige Profil hat, aktualisiert werden, oder in einigen Fällen kann eine PPR von einer anderen Partei aktualisiert werden. Kontrolle über die Fähigkeit zum Aktualisieren der PPR ist in der RAT angegeben. Tabelle 1 stellt eine beispielhafte RAT gemäß einigen Ausführungsformen bereit. Tabelle 1. Beispielhafte Regelberechtigungstabelle (RAT).

Kennung der Profilrichtlinienregel (PPR)	MNO-Name	PKI-Prüfpunkt
Richtlinie Nr. 1	MCC1, MNC1, GID1-1, GID2-1	Objektbezeichner Nr. 1 (OID1)
Richtlinie Nr. 2	MCC2, MNC2, GID1-2, GID2-2	PKI-Parameter
Richtlinie Nr. 3	MCC3, MNC3, GID1-3, GID2-3	Nicht definiert
Richtlinie Nr. 4	Beliebige	-
Richtlinie Nr. 5	Beliebige	OID2 (CA-OID)
Richtlinie Nr. 6	Keine	-

Wenn das SE PPR-Aktualisierungsinformationen (hier auch als PPR-Aktualisierungsnachricht bezeichnet) empfängt, prüft es die PKI-Prüfpunktspalte von Tabelle 1, um zu bestimmen, ob der PKI-Prüfpunkt für die PPR, die in der Aktualisierungsnachricht angegeben ist, definiert ist. Die PPR-Aktualisierungsnachricht ist in einigen Ausführungsformen in einer Richtlinienregelbeschreibung eines Profils, das auf das SE heruntergeladen wird, enthalten. Der PKI-Prüfpunkt gibt an, wie eine Berechtigungsprüfung der PPR-Aktualisierungsmeldung auf der Grundlage von PKI-Kryptografiemethoden durchzuführen ist (Zertifikatprüfung). Für eine gegebene PPR in der Tabelle beziehen sich die entsprechenden Zeileneinträge auf vertrauenswürdige Entitäten in Bezug auf die PPR. Das mit der PPR-Nachricht verbundene Profil muss nicht aktiviert sein, damit der MNO den PPR-EIN/AUS-Zustand aktualisieren kann. Dies hat den Grund, dass der PKI-Prüfpunkt auf den PKI-Methoden beruht und nicht auf Pre-Shared Keys (vorher vereinbarten Schlüsseln), die nur bei aktiviertem Profil verfügbar sind.
Die PPR-Aktualisierungsnachricht ist in einigen Ausführungsformen in einem binären großen Objekt (BLOB) enthalten, das einem eSIM-Paketformat ähnlich ist, zum Beispiel dem Metadatenteil (siehe SGP.22). In einigen Ausführungsformen sind die Inhalte des BLOB leer, mit Ausnahme der PPR-Informationen oder -Nachricht. Ähnlich der Profilbereitstellung endet der Transportkanal an der Vorrichtung, und die Vorrichtung sendet und empfängt Datennachrichten an das bzw. von dem SE.
In einigen Ausführungsformen löst das SE eine PPR-Aktualisierungsnachricht aus, indem ein TLS-Kanal (Transport Layer Security, Transportschichtsicherheit) mit einem MNO-Server über eine ES6-Schnittstelle errichtet wird. In diesem Szenario endet der Transport an dem SE, und die Art des Nachrichtenflusses ist für die Vorrichtung transparent. Die ES6-Schnittstelle ist in SGP.22 erläutert, und TLS ist in RFC 5246 erläutert. In einigen Ausführungsformen authentifizieren sich das SE und der MNO-Server gegenseitig mithilfe von PKI-Methoden. TLS bietet Mechanismen zum Errichten eines oder mehrerer Sitzungsschlüssel für sichere Kommunikation, falls gewünscht.
Bezugnehmend auf Tabelle 1 ist Richtlinie Nr. 1 mit einem MNO verbunden, der durch ein spezielles Variablenpaar MCC, MNC (Mobile Country Code, Mobile Network Code) mit den Werten MCC1, MNC1 gekennzeichnet ist. Der MNO für Richtlinie Nr. N ist möglicherweise ferner durch GID1-N und GID2-N gekennzeichnet. GID steht für Gruppenkennung; GID1 steht für Gruppenkennung Ebene 1. Richtlinie Nr. 1 ist auch mit einem Objektbezeichner Nr. 1 verbunden, der hier als OID1 bezeichnet wird. Das SE kann das PKI-Zertifikat verwenden, das den Wert OID1 enthält, um einen öffentlichen Schlüssel zu erhalten, und dann die Signatur auf der PPR-Aktualisierungsnachricht mit dem öffentlichen Schlüssel mithilfe von PKI-Methoden prüfen. Richtlinie Nr. 2 ist mit einem öffentlichen Schlüssel des MNO und Schlüsselparametern verbunden, die bereits auf das SE geladen und in Tabelle 1 als PKI-Parameter angegeben sind.
Richtlinie Nr. 5 ist mit einer bestimmten Zertifizierungsstelle (CA) verbunden. Dies sorgt für Detailgenauigkeit an der vertrauenswürdigen Basis-CA. Für Richtlinie Nr. 5 führt das SE in einigen Ausführungsformen keine Prüfung an einer spezifischen Kontrollentität (z. B. MNO) durch. Es ist jedoch notwendig, dass dieser Entität (z. B. MNO) Anmeldeinformationen (z. B. ein öffentlicher Schlüssel) zugeordnet sind, die von einer vertrauenswürdigen CA von einem bestimmten Markt geprüft werden. Durch diesen Ansatz stellen hierin dargestellte Ausführungsformen eine flexible Richtlinienkontrolle innerhalb von Märkten bereit, die nur Verbindungen mit vertrauenswürdigen CAs haben, wenn das Ökosystem von Vorrichtungen und Servern mehrere Basis-CAs in verschiedenen Märkten aufweisen kann. Für Richtlinie Nr. 3 ist der PKI-Prüfpunkt nicht definiert. Das SE verwendet in einigen Ausführungsformen die RAT von Tabelle 1 für Richtlinie Nr. 3 durch Vergleichen der MNO-Kennungsparameter in der PPR-Aktualisierungsnachricht mit den Zeileneinträgen entsprechend Richtlinie Nr. 3, d. h. MMC3, MNC3 (und möglicherweise GID1-3 und GID2-3).
Einige Informationen in Bezug auf Profil-(eSIM-)bereitstellung, SEs und PKI-Verfahren sind hier bereitgestellt.
Ein SE schließt ein Betriebssystem ein, und das Betriebssystem kann eine Fähigkeit einschließen, Netzwerkzugangsanwendungen, die einem gegebenen Betreiber zugeordnet sind, Authentifizierungsalgorithmen bereitzustellen. Eine Sicherheitsdomäne innerhalb einer SE enthält die OTA-Schlüssel (Over The Air) des Betreibers und stellt einen sicheren OTA-Kanal bereit. Bei OTA-Schlüsseln handelt es sich um Anmeldeinformationen, die durch einen Betreiber für eine Fernverwaltung von Betreiberprofilen auf einer SE verwendet werden.
Verfahren einer Infrastruktur für öffentliche Schlüssel (PKI)
Kommunikationen eines SE können unter Verwendung von PKI-Verfahren authentifiziert werden. Für Authentifizierungs- und Vertraulichkeitszwecke verwendete Zertifikate können durch einen Zertifikataussteller (CI) erzeugt werden. Ein Zertifikat eines öffentlichen Schlüssels kann hierin auch einfach als ein Zertifikat bezeichnet werden. Eine Vorrichtung, ein SE und/oder ein Profil können eine Kopie eines Zertifikats speichern, wobei das Zertifikat den Namen einer gegebenen Partei (Benutzeridentität) trägt. Der Name kann in der Form eines Objektbezeichners (OID) angegeben sein. Der im Zertifikat festgehaltene öffentliche Schlüssel kann verwendet werden, um die Signatur auf einer Nachricht zu prüfen, die unter Verwendung eines privaten PKI-Schlüssels der gegebenen Partei signiert wurde. Ein Beispiel für ein PKI-Zertifikat ist ein X.509-Zertifikat. X.509 ist in Request For Comments (RFC) 5280 von der Internet Engineering Task Force (IETF) beschrieben.
System
1 veranschaulicht ein System 100 zur sicheren Kontrolle über Profilrichtlinienregeln. Das System schließt ein SE 110, einen MNO-Server 130, einen eSIM-Server 140 und eine Zertifizierungsstelle (CA) 150 ein. Das SE 110 ist beim Empfangen einer PPR-Aktualisierungsnachricht 101 mit einer als Richtlinienkontrolle 111 bezeichneten Funktion dargestellt. Die PPR-Aktualisierungsnachricht ist in diesem Beispiel mit dem Profil 120 von 1 verbunden. Die PPR-Aktualisierungsnachricht 101 meint in einigen Ausführungsformen PPR-Aktualisierungsinformationen in den Metadaten von Profil 120, die vom eSIM-Server 140 heruntergeladen werden. In einigen Ausführungsformen ist die PPR-Aktualisierungsnachricht mit dem Profil 120 verbunden, und das Profil 120 ist auf dem SE 110 bereits vorhanden. 1 veranschaulicht das Profil 120, wie es bereits auf dem SE 110 vorhanden ist. Das Profil 120 auf dem SE 110 ist mit einer Sicherheitsdomäne ISD-P 115 verbunden.
Die Richtlinienkontrolle 111 ist in einigen Ausführungsformen eine Funktion, die vom Betriebssystem (OS) des SE 110 verwendet wird. Die Richtlinienkontrolle 111 greift auf die RAT 114 (in Tabelle 1 beispielhaft erläutert) über eine Schnittstelle 103 zu. Die Richtlinienkontrolle 111 bestimmt, welche Zeile der RAT für die PPR-Aktualisierungsnachricht 101 gilt, und agiert entsprechend. In dem Beispiel von 1 ist der PKI-Prüfpunkt von Tabelle 1 definiert, und die Richtlinienkontrolle 111 fährt mit dem Zugriff auf die Authentifizierungsfunktion 113 über die Schnittstelle 104 fort, um eine Signatur einer PPR-Aktualisierungsnachricht 101 zu prüfen. Die Authentifizierungsfunktion 113 wird in einigen Ausführungsformen durch einen sicheren Prozessor und einen sicheren Speicher des SE 110 durchgeführt. Die Signaturprüfung ist in einigen Ausführungsformen von einem PKI-Zertifikat des MNO-Servers 130, von der CA 150 signiert, abhängig. Wenn die Signaturprüfung angibt, dass die PPR-Aktualisierungsnachricht mit einem privaten Schlüssel des MNO im Zusammenhang mit dem Profil 120 und der International Mobile Subscriber Identity (IMSI) 121 signiert ist, dann wird durch die Verbindung 105 ein PPR-EIN/AUS-Zustand 123 im Zusammenhang mit einer PPR 122 des Profils 120 wie erforderlich gemäß Nutzdaten oder Informationen der PPR-Aktualisierungsnachricht angepasst (ein- oder ausgeschaltet).
Eine Zuordnung des Profils 120 zu dem MNO, der in der RAT genannt ist, beruht auf der IMSI 121. Eine IMSI enthält MNC- und MCC-Felder entsprechend dem zugeordneten Betreiber und GID1- und GID2-Felder, die unter der Kontrolle des Betreibers sind.
Der PPR-EIN/AUS-Zustand kann in einer Datei des Profils 120 gespeichert sein oder kann in dem SE 110, zum Beispiel im Speicher 112, gespeichert sein. Obwohl sich die Beschreibung hier auf eine Nachricht und Nutzdaten bezieht, ist die PPR-Aktualisierungsnachricht im Allgemeinen in einigen Ausführungsformen keine separate Nachricht, sondern kann zum Beispiel aus Feldern oder Daten in einem BLOB bestehen, die an das SE 110 übertragen werden.
Prüflogik
2 veranschaulicht eine beispielhafte Logik 200 zur sicheren Kontrolle über Profilrichtlinienregeln. Bei 201 empfängt ein SE eine PPR-Aktualisierungsnachricht. Bei 202 überprüft das SE eine Signatur in der Nachricht. Wenn die Signatur gültig ist, geht die Logik über 203 zu 204, und das SE passt den PPR-EIN/AUS-Zustand so an, dass er der PPR-Aktualisierungsnachricht entspricht. Wenn die PPR-Aktualisierungsnachricht oder -informationen beispielsweise anzeigen, dass die Richtlinie eingeschaltet sein soll, dann setzt das SE einen Wert in einem Speicher durch, um dies anzugeben. Bei 202, wenn die Prüfung fehlschlägt, geht die Logik über 205 („keine gültige Signatur“) zu 206, und es wird keine Änderung am PPR-EIN/AUS-Zustand vorgenommen.
Zum Beispiel wird in einigen Ausführungsformen die Logik 200 durch das folgende Verfahren realisiert, das von einem SE durchgeführt wird. Das Verfahren umfasst: i) Empfangen eines ersten Abschnitts eines Profils, ii) Parsen einer ersten Kennung eines MNO aus dem ersten Abschnitt, ii) Parsen einer Signatur aus dem ersten Abschnitt, iii) Erhalten eines Schlüssels von einem SE-Speicher, wobei der Schlüssel dem MNO zugeordnet ist, und iv) Überprüfung der Signatur mit dem Schlüssel, um ein Überprüfungsergebnis zu bestimmen. Wenn das Überprüfungsergebnis angibt, dass die Signatur von dem MNO erstellt wurde, schreitet das Verfahren durch Identifizieren einer Richtlinienregel des Profils und durch Installieren des Profils in dem SE mit aktivierter Richtlinienregel fort. Wenn jedoch das Überprüfungsergebnis angibt, dass die Signatur nicht von dem MNO erstellt wurde, fährt das Verfahren durch Beenden einer Installation des Profils in dem SE fort. In einigen Ausführungsformen des Verfahrens ist der erste Abschnitt des Profils ein Segment eines BLOB. In einigen Ausführungsformen des Verfahrens schließt das Beenden ein Verwerfen des ersten Abschnitts des Profils ein.
Nachrichtenfluss
3 veranschaulicht ein beispielhaftes Nachrichtenflussdiagramm 300 zur sicheren Kontrolle über Profilrichtlinienregeln. Die Zeit schreitet von oben nach unten voran, und Entitäten sind oben von links nach rechts beschriftet. Die PPR-Aktualisierungsnachricht 101 ist bei ISD-R 330 des SE 110 eintreffend (Bezugszahl 323) dargestellt. In 3 realisiert zum Beispiel ISD-R 330 die Funktionsrichtlinienkontrolle 111. Die PPR-Aktualisierungsnachricht stammt zum Beispiel vom MNO-Server 130 (Bezugszahl 321) oder einer dritten Partei 310 (Bezugszahl 322). Die dritte Partei 310 ist in einigen Ausführungsformen der eSIM-Server 140. Die ISD-R 330 führt eine Signaturüberprüfung, wie durch das Ereignis 324 angegeben, durch. In dem Beispiel von 3 ist die Signaturüberprüfung erfolgreich, und eine Nachricht 325 wird an eine ISD-P 115 gesendet, um den PPR-EIN/AUS-Zustand entsprechend einzurichten, was bei Ereignis 326 erfolgt. Diese Funktionen können von anderen Komponenten des SE 110 ausgeführt werden, die Rollen von ISD-R 330, ISD-P 115 und dem Profil 120 sind zur Veranschaulichung dargestellt. Zum Beispiel kann das Profil 120 den PPR-EIN/AUS-Zustand nach Anweisung vom Betriebssystem (OS) des SE 110 oder nach Anweisung von der eUICC-Zertifizierungsstellen-Sicherheitsdomäne (ECASD) des SE 110 speichern und aktualisieren (siehe 10). Weitere Einzelheiten zu SE, ISD-R, ISD-P und Profileigenschaften und -beziehungen sind in SGP.22 zu finden.
Ausführliches System
4 veranschaulicht ein System 400, das das SE 110 mit einem zweiten Profil 420 in oder im Zusammenhang mit einer ISD-P 415 einschließt. 4 veranschaulicht auch Zustandsinformationen 461 und 462, die angeben, ob eines der Profile 120 bzw. 420 aktiviert ist. In 4 ist der PPR-EIN/AUS-Zustand 123 im Zusammenhang mit PPR 122 als innerhalb der ISD-P 115 dargestellt. Ähnlich ist der Zustand 423 der PPR 422 des Profils 420 als innerhalb der ISD-P 415 dargestellt. Der Speicherort dieser Zustandsinformationen ist nicht entscheidend. Eine MNO-Sicherheitsdomäne, MNO-SD 425, des Profils 420 ist ebenfalls dargestellt, sowie zwei IMSI-Werte: IMSI 421 und IMSI 424. Das SE 110 ist auch mit einer Funktion dargestellt, die Richtliniendurchsetzung 412 genannt wird. Richtliniendurchsetzung 412 setzt, wie erforderlich, die Profilrichtlinienregeln 122 und 422 auf der Grundlage bestimmter Ereignisse und auf der Grundlage dessen, ob die betreffende Richtlinie eingeschaltet ist, durch.
Wenn zum Beispiel PPR 122 den Profilaktivierungszustand 461 „EIN“ aufweist und ein ordnungsgemäßer Befehl zum Deaktivieren des Profils 120 empfangen wird und PPR 122 angibt, dass das Profil bei Deaktivierung gelöscht werden soll, und der PPR-EIN/AUS-Zustand 123 EIN ist, dann führt das Richtliniendurchsetzungs-Dienstprogramm 412 die Profilrichtlinienregel (PPR) 122 durch Löschen des Profils 120 durch, wenn der Befehl zum Deaktivieren empfangen wird.
Die Richtlinienkontrolle 111 parst in einigen Ausführungsformen zuerst einen MNO-Namen von der PPR-Aktualisierungsnachricht 101 und überprüft dann die Spalte der MNO-Namen von Tabelle 1 (RAT 114), wenn die PPR-Aktualisierungsnachricht 101 verarbeitet wird. Wenn erfolgreich eine MNO-Namensübereinstimmung gefunden wurde, überprüft die Richtlinienkontrolle 111 dann die PKI-Prüfpunktspalte der RAT. In einigen Ausführungsformen stimmt eine MNO-Kennung in der RAT nicht mit dem ersten IMSI-Wert, der von der Richtlinienkontrolle 111 überprüft wird, überein. Zum Beispiel kann die PPR-Aktualisierungsnachricht 101 dem Profil 420 zugeordnet sein. Die Richtlinienkontrolle 111 versucht in einigen Fällen zunächst, den MNO-Namen der RAT dem der IMSI 421 entsprechenden MNO zuzuordnen und findet keine Übereinstimmung. Als Beispiel betrachte man einen Fall, in dem die IMSI 421 kein MNC/MCC-Paar findet, das mit der RAT für diese Richtliniennummer übereinstimmt. Die Richtlinienkontrolle 111 durchsucht dann das Profil 420 nach weiteren IMSI-Werten und findet die IMSI 424. Zum Beispiel kann die IMSI 424 eine Entsprechung zum MNO-Namen der RAT für diese Profilnummer angeben. Nach dem Erfüllen der MNO-Namensprüfung bestimmt die Richtlinienkontrolle 111, ob der PKI-Prüfpunkt definiert ist. Wenn er definiert ist, dann versucht die Richtlinienkontrolle 111, mithilfe der Authentifizierungsfunktion 113 eine Signatur in PPR-Aktualisierungsnachricht oder -informationen 101 zu überprüfen, und wenn die Überprüfung erfolgreich ist, dann passt die Richtlinienkontrolle 111 den PPR-EIN/AUS-Zustand 423 wie erforderlich so an, dass er der Anweisung der PPR-Aktualisierungsnachricht 101 entspricht. Die Richtlinienkontrolle 111 kann ohne die Hilfe von MNO-SD 425 betrieben werden, da die Richtlinienkontrolle 111 PKI-basiert ist und keinen Zugriff auf vorher vereinbarte OTA-Schlüssel, durch MNO-SD 425 unterstützt, benötigt.
Empfangen eines BLOB
5A stellt eine beispielhafte Darstellung eines Systems 500 bereit, das das SE 110 einschließt, das ein BLOB empfängt, das PPR-Aktualisierungsinformationen enthält. 5B, 5C, 5D und 5E stellen beispielhafte BLOB-, Nachrichten- und Parameterformate und -inhalte bereit. In 5A stellt der eSIM-Server 140 ein BLOB 502 an das SE 110 innerhalb einer Vorrichtung 501 bereit. In einigen Ausführungsformen wird das BLOB 502 von dem MNO-Server 130 bereitgestellt. Das BLOB 502 wird von dem SE 110 geparst, und die ISD-R 330 nimmt Einfluss darauf. In einigen Ausführungsformen nimmt das OS des SE 110 oder ein anderes funktionelles Modul des SE 110 Einfluss auf das BLOB 502.
Variablen und Werte
5B stellt eine schematische Darstellung eines BLOB 504 bereit, das beispielhaft für das BLOB 502 ist. BLOB 504 weist eine PPR-Aktualisierungsnachricht 101 und ein gebundenes Profilpaket (BPP) 503 auf. Die PPR-Aktualisierungsnachricht 101 ist repräsentativ für Informationen, um ein SE 110 zu einem Zustand anzuweisen, in den eine Profilrichtlinienregel eines bestimmten Profils gesetzt werden soll oder dem sie entspricht. Das BPP kann ein bestimmtes Profil in verschlüsselter Form einschließen.
5B entspricht einer Ausführungsform, wobei ein Profil in ein BPP heruntergeladen wird und ein Profilrichtlinienregel-EIN/AUS-Zustand in Informationen innerhalb des BLOB, das das BPP enthält, angegeben wird.
5C veranschaulicht im Gegensatz zu 5B eine beispielhafte Ausführungsform, wobei ein BLOB 505, das die PPR-Aktualisierungsnachricht 101 enthält, kein BPP enthält. 5C ist zum Beispiel auf eine Situation anwendbar, in der das Profil, das von der PPR-Aktualisierungsnachricht 101 angesteuert wird, bereits auf dem SE 110 vorhanden ist. Zum Beispiel wird die PPR-Nachricht 101 von 5C in einigen Ausführungsformen an PPR 122 des Profils 120 von 4 geleitet. Der Profilaktivierungszustand 461 von Profil 120 kann EIN oder AUS sein. Die Richtlinienkontrolle 111 verarbeitet die PPR-Aktualisierungsnachricht 101 von 5C in Bezug auf die RAT 114 (siehe auch Tabelle 1), überprüft die Signatur (siehe 5D, Bezugszahl 516) und passt den PPR-EIN/AUS-Zustand 123 entsprechend an.
5D veranschaulicht beispielhafte Datenfelder in der PPR-Aktualisierungsnachricht 101. Die PPR-Aktualisierungsnachricht 101 stellt Informationen dar, sie muss nicht als separate Nachricht formatiert sein. Die PPR-Aktualisierungsnachricht 101 enthält in einigen Ausführungsformen i) eine MNO-Kennung 511, ii) eine SE-Kennung 512, iii) eine Profilkennung ICCID 513, iv) einen neuen PPR-EIN/AUS-Zustand 514, v) einen Authentifizierungsparameter (Vektor) 515 und/oder vi) eine Signatur 516. Die dimensionale Beschreibung „Vektor“ macht deutlich, dass der Authentifizierungsparameter 515 mehr als eine Variable darstellen kann. Die Felder von 5D entsprechen 4 in einem Falle wie folgt: Die MNO-Kennung 511 ist dem MNO-Server 130 und den Eigentumsrechten oder der Kontrolle des Profils 120 und/oder des Profils 420 zugeordnet. Die MNO-Kennung 511 ist auch IMSI 121, IMSI 421 und/oder IMSI 424 zugeordnet. Die SE-Kennung 512 identifiziert SE 110. Die ICCID 513 identifiziert das Profil 120 oder Profil 420. Der neue PPR-EIN/AUS-Zustand 514 stellt den Wert dar, falls erfolgreich überprüft, in den der PPR-EIN/AUS-Zustand 123 (oder PPR-EIN/AUS-Zustand 423) zu setzen ist oder dem er entspricht. Der Authentifizierungsparameter (Vektor) 515 stellt Authentifizierungsinformationen dar, die zusammen mit Informationen aus der RAT 114 in die Richtlinienkontrolle 111 eingegeben werden, wenn bestimmt wird, ob die PPR-Aktualisierungsnachricht von einer Partei ist, die zur Kontrolle über den EIN/AUS-Zustand von PPR 122 oder PPR 422 autorisiert ist.
5E stellt beispielhafte Variablen dar, die in dem Authentifizierungsparameter (Vektor) 515 in einigen Ausführungsformen vorhanden sind. Der Authentifizierungsparameter 515 schließt in einigen Ausführungsformen Folgendes ein: i) ein Zertifikat 521, ii) eine Kennung einer vertrauenswürdigen Entität, die als OID 522 dargestellt ist, iii) Schlüsselparameter 523 und/oder iv) eine Zertifizierungsstellen-(CA-)OID 524.
Logik, Profil bereits vorhanden
6 veranschaulicht beispielhafte Logik 600 zur sicheren Kontrolle über Profilrichtlinienregeln, wenn das Zielprofil bereits auf einem SE vorhanden ist, gemäß einigen Ausführungsformen. 3–4, 5A und 5C–5E stellen den Hintergrund für die Logik 600 bereit. Bei 601 empfängt ein SE ein BLOB mit einer PPR-Aktualisierungsnachricht, die an ein bestimmtes Profil gerichtet ist. Bei 602 parst das SE eine MNO-Kennung und eine Signatur aus dem BLOB. Bei 603 erhält das SE einen Schlüssel, und bei 604 erzeugt das SE ein Überprüfungsergebnis durch Bereitstellen des Schlüssels und der Signatur als Eingaben in eine Authentifizierungsfunktion. Beim Erhalten des richtigen Schlüssels zur Signaturüberprüfung hängen entweder der vorgeladene öffentliche Schlüssel (PK) der CA, der PK der entsprechenden Entität von dem Zertifikat oder der vorgeladene PK der entsprechenden Entität von der in Tabelle 1 definierten Konfiguration ab. Wenn das Überprüfungsergebnis angibt, dass die Signatur von dem MNO erstellt wurde, der zur Kontrolle über die PPR für ein bestimmtes Profil berechtigt ist, geht die Logik über 605 zu 606. Bei 606 wird eine Profilrichtlinienregelaktualisierung im Zusammenhang mit einer PPR bestimmt. Bei 607 wird der PPR-EIN/AUS-Zustand der PPR so eingestellt, dass er der Aktualisierung entspricht. Wenn das Überprüfungsergebnis angibt, dass keine gültige Signatur vorhanden ist, dann geht die Logik von 604 entlang 608 zu 609, und es erfolgt eine Änderung an einem PPR-EIN/AUS-Zustand.
Logik mit Profilinstallation
7 veranschaulicht eine beispielhafte Logik 700 für die sichere Kontrolle über eine Profilrichtlinienregel, einschließlich der Installation eines Profils, auf das sich die Profilrichtlinienregel bezieht. Die Logik von 7 ist, anders als bei der Profilinstallation, wie die Logik von 6. Bei 701 wird ein Abschnitt des Profils an einem SE empfangen. Bei 702 parst das SE eine MNO-Kennung und eine Signatur aus dem Profilabschnitt. Bei 703 erhält ein SE einen Schlüssel im Zusammenhang mit einem MNO, der in einer RAT identifiziert ist. Bei 704 verwendet das SE den Schlüssel und die Signatur zum Erzeugen eines Überprüfungsergebnisses. Beim Erhalten des richtigen Schlüssels zur Signaturüberprüfung hängen entweder der vorgeladene öffentliche Schlüssel (PK) der CA, der PK der entsprechenden Entität von dem Zertifikat oder der vorgeladene PK der entsprechenden Entität von der in Tabelle 1 definierten Konfiguration ab. Wenn das Überprüfungsergebnis angibt, dass die Signatur von dem durch die RAT identifizierten MNO erstellt wurde, dann geht die Logik über 705 zu 706. Bei 706 identifiziert das SE eine PPR im Zusammenhang mit dem Profil. Bei 707 installiert das SE das Profil auf dem SE, wobei die Richtlinienregel zum Beispiel aktiviert ist. Wenn das Überprüfungsergebnis bei 704 angibt, dass keine gültige Signatur in den vom Profilabschnitt geparsten Informationen vorhanden ist, dann geht die Logik über 708 zu 709, und eine Installation des Profils auf dem SE wird beendet.
PKI-basierter Kanal
8A veranschaulicht eine beispielhafte Authentifizierung und sichere Kanalanordnung 820, die zum Beispiel kein aktiviertes Profil erfordert. Ein PKI-basierter Kanal 821 verbindet den MNO-Server 130 (oder den eSIM-Server 140) mit dem SE 110. Der PKI-basierte Kanal 821 ist für die Vorrichtung 501 transparent. In 8A wird der PKI-basierte Kanal 821 durch die ISD-R 330 beendet. Eine andere funktionelle Entität in dem SE 110, wie das OS des SE 110, beendet in einigen Ausführungsformen den PKI-basierten Kanal 821. Der Kanal ist PKI-basiert, da er nicht auf Pre-Shared Keys (vorher vereinbarten Schlüsseln) beruht. Stattdessen authentifizieren sich der eSIM-Server 140 und das SE 110 gegenseitig mit PKI-Verfahren und können zum Beispiel mit TLS einen sicheren Kanal einrichten.
8B veranschaulicht eine beispielhafte Logik 800 zur Verwendung durch das SE 110 von 8A, um eine Änderung im PPR-EIN/AUS-Zustand auszulösen. Bei 801 bildet das SE 110 in einigen Ausführungsformen Nutzdaten, die einen PPR-Aktualisierungsauslösewert einschließen. Bei 802 berechnet ein SE eine SE-Signatur durch Signieren eines privaten Schlüssels über die Nutzdaten. Bei 803 bildet das SE eine Nachricht, die die Nutzdaten und die Signatur enthält. Bei 804 sendet das SE die Nachricht an einen MNO-Server, zum Beispiel den MNO-Server 130. Bei 805 empfängt das SE eine Antwort von dem MNO-Server. Bei 806 parst das SE eine MNO-Signatur aus der Antwortnachricht. Bei 807 überprüft das SE die MNO-Signatur, zum Beispiel mithilfe von Informationen aus einer RAT, wie in Tabelle 1 dargestellt, um ein Überprüfungsergebnis zu erzeugen. Wenn die MNO-Signatur geprüft ist, geht die Logik über 808 zu 809. Bei 809 parst das SE Antwort-Nutzdaten aus der Antwortnachricht, und bei 810 aktualisiert das SE einen PPR-EIN/AUS-Zustand auf der Grundlage der Antwort-Nutzdaten. Bei 811, wenn die MNO-Signatur nicht erfolgreich geprüft ist, geht die Logik über 811 zu 812, und es wird keine Änderung am PPR-EIN/AUS-Zustand vorgenommen.
Logik mit mehr als einer IMSI
9 veranschaulicht eine Logik 900 zur sicheren Kontrolle über Profilrichtlinienregeln. Die Logik 900 schließt die Überprüfung einer MNO-Kennung und die Überprüfung einer Signatur ein, wenn Signaturüberprüfung gemäß einer RAT definiert ist. Bei 901 empfängt ein SE eine PPR-Aktualisierungsnachricht, die auf ein Profil gerichtet ist und eine Profilrichtlinienregelkennung enthält. Die Nachricht kann mit dem Profil eintreffen (z. B. 5B und 7), oder die Nachricht kann an ein bereits installiertes Profil gerichtet sein (z. B. 5C und 6). In 9 wird das Beispiel des Profils, das mit der Nachricht eintrifft, zur Veranschaulichung erläutert.
Bei 902 bestimmt das SE, ob eine MNO-Kennung in dem Profil mit einer MNO-Kennung in einer RAT übereinstimmt. Diese Diskussion folgt erfolgreichen Überprüfungen und kehrt dann im Falle keiner Übereinstimmung zu 902 zurück. Wenn eine MNO-Kennung in dem Profil mit einer MNO-Kennung in der RAT übereinstimmt, geht die Logik über 903 zu 904. Bei 904 bestimmt die SE, ob eine PKI-Regel für diese Profilrichtlinienregelkennung und MNO-Kennung in der RAT definiert ist. Wenn ja, geht die Logik über 905 zu 906, und das SE führt eine Überprüfung einer von der PPR-Aktualisierungsnachricht geparsten Signatur durch. Die Überprüfung kann zum Beispiel von der Richtlinienkontrolle 111 von 4 mithilfe der Authentifizierungsfunktion 113 durchgeführt werden, wie in Bezug auf 4 oder andere Figuren erörtert. Bei erfolgreicher Überprüfung geht die Logik über 907 zu 908, und das SE passt den PPR-EIN/AUS-Zustand der PPR entsprechend dem neuen Zustand, wie in der PPR-Nachricht angegeben, an. Bei nicht erfolgreicher Überprüfung geht die Logik über 913 zu 915, und der PPR-Zustandsaktualisierungsversuch wird abgelehnt.
Die Diskussion kehrt nun zu 902 zurück. Wenn die im Profil bei 902 bewertete MNO-Kennung nicht mit einer MNO-Kennung in der RAT übereinstimmt, dann geht die Logik über 909 zu 910, und das SE bewertet, ob eine zusätzliche MNO-Kennung in dem Profil, zum Beispiel eine zweite IMSI in einem USIM, mit einer MNO-Kennung in der RAT übereinstimmt. Wenn ja, geht die Logik über 911 zu 904 und schreitet wie vorstehend beschrieben voran. Bei 904 geht die Logik, wenn keine PKI-Regel definiert ist, über 912 zu 908, und der PPR-EIN/AUS-Zustand wird auf der Grundlage der Stärke der MNO-Übereinstimmung von 902 oder 910 angepasst. Wenn der angegebene Zustand EIN ist, wird die PPR zum Beispiel durch Richtliniendurchsetzung 412 von 4 durchgesetzt, wenn Ereignisbedingungen die PPR aufrufen.
Die Diskussion kehrt nun zu 910 zurück. Wenn eine weitere MNO-Kennung nicht mit der RAT übereinstimmt, geht die Logik über 914 zu 915, und das SE lehnt die PPR-EIN/AUS-Zustandsaktualisierung ab. Im Allgemeinen kann ein Profil in einigen Ausführungsformen während des Vorgangs der Logik 900 installiert werden. Wenn ein Profil installiert ist und die Logik, die bei 901 beginnt, bei 915 endet, dann wird der PPR ein AUS-Zustand zugeordnet, und die PPR wird für das Profil nicht durchgesetzt (außer wenn eine nachfolgende PPR-Aktualisierungsnachricht eintrifft und erfolgreich geprüft wird).
Zum Beispiel wird in einigen Ausführungsformen die Logik 900 durch das folgende Verfahren realisiert, das von einer in einer Vorrichtung untergebrachten eUICC durchgeführt wird. Das Profil ist auf der eUICC vorhanden, und die eUICC enthält eine RAT. Das Verfahren umfasst: i) Empfangen einer Nachricht, die eine Aktualisierung einer Profilrichtlinienregel (PPR) umfasst, wobei die PPR-Aktualisierung dem Profil zugeordnet ist, ii) Erhalten der ersten Mobilfunkbetreiber-(MNO-)Kennung von dem Profil und iii) Vergleichen der MNO-Kennung mit Zeileneinträgen in der RAT, um ein erstes Übereinstimmungsergebnis zu erzeugen.
Wenn das erste Übereinstimmungsergebnis angibt, dass die RAT die erste MNO-Kennung umfasst, fährt das Verfahren mit der Bestimmung fort, ob ein Authentifizierungsschritt für die erste MNO-Kennung definiert ist, und erzeugt ein erstes Definitionsergebnis. Wenn das erste Definitionsergebnis angibt, dass ein Authentifizierungsschritt nicht definiert ist, fährt das Verfahren mit der Aktualisierung einer PPR, die von der PPR-Aktualisierung identifiziert wird, fort. Wenn das erste Definitionsergebnis jedoch angibt, dass ein Authentifizierungsschritt definiert ist, umfasst das Verfahren i) Parsen einer Signatur aus der Nachricht und ii) Überprüfen der Signatur, um ein erstes Überprüfungsergebnis zu erzeugen. Wenn das erste Überprüfungsergebnis angibt, dass die PPR-Aktualisierung echt ist, fährt das Verfahren mit dem Aktualisieren der PPR, die von der PPR-Aktualisierung identifiziert wird, fort. Wenn das erste Überprüfungsergebnis jedoch angibt, dass die PPR-Aktualisierung nicht echt ist, aktualisiert das Verfahren die von der PPR-Aktualisierung identifizierte PPR nicht.
Wenn andererseits das erste Übereinstimmungsergebnis angibt, dass die RAT nicht die erste MNO-Kennung angibt, fährt das Verfahren mit dem Bestimmen fort, ob das Profil eine zweite MNO-Kennung umfasst. Wenn das Profil keine zweite MNO-Kennung umfasst, aktualisiert das Verfahren die von der PPR-Aktualisierung identifizierte PPR nicht. Jedoch schließt das Verfahren das Aktualisieren der von der PPR-Aktualisierung identifizierten PPR ein, wenn die folgenden Bedingungen zutreffen: i) Das Profil umfasst eine zweite MNO-Kennung, ii) die zweite MNO-Kennung stimmt mit einem Zeileneintrag in der RAT überein, iii) der Authentifizierungsschritt ist für die zweite MNO-Kennung definiert und iv) die Signatur von der Nachricht wurde von einer zweiten MNO erstellt, die durch die zweite MNO-Kennung identifiziert wurde. In einigen Ausführungsformen ist die erste MNO-Kennung einer ersten in dem Profil zu findenden IMSI zugeordnet. In einigen Ausführungsformen ist die zweite MNO-Kennung einer zweiten in dem Profil zu findenden IMSI zugeordnet.
SE-Details
10 veranschaulicht weitere Details des SE 110, das in der Vorrichtung 501 in einem System 1000 untergebracht ist. Die Vorrichtung weist die LPA 1001 (die in Software realisiert sein kann) und den Speicher 1002 auf. Das SE 110 weist ein Betriebssystem 1003 auf. Innerhalb des Betriebssystems 1003 ist ein Telekommunikations-Framework 1094, das Authentifizierungsalgorithmen für Netzwerkzugangsanwendungen (NAAs) bereitstellt. Ein Interpretierprogramm 1095 übersetzt Profilpaketdaten in ein installiertes Profil mithilfe eines spezifischen internen Formats des SE 110. ISD-P 415 hostet das Profil 420. Ein Ereignis, das von der Vorrichtung 501 mit dem SE 110 verarbeitet wird, kann zum Beispiel das Installieren, Aktivieren oder Deaktivieren des Profils 420 einschließen.
Die ISD-P ist ein sicherer Container (Sicherheitsdomäne) zum Hosten des Profils 420. Die ISD-P wird zum Herunterladen und Installieren eines Profils in Zusammenarbeit mit dem Interpretierprogramm 1095 zum Dekodieren eines empfangenen gebundenen Profilpakets verwendet. Das SE 110 weist auch einen Speicher 1009 und die ECASD 1004 auf. ECASD 1004 stellt sichere Speicherung von Anmeldeinformationen bereit, die zum Unterstützen der Sicherheitsdomänen auf dem SE 110 erforderlich sind. MNO-SD 425 ist auf dem SE 110 die Repräsentative eines Betreibers, der Dienste für einen Endbenutzer bereitstellt. Die MNO-SD 425 enthält die OTA-Schlüssel des Betreibers und stellt einen sicheren OTA-Kanal bereit.
Der eSIM-Server 140 kommuniziert in einigen Ausführungsformen mit dem SE 110 auf der Schnittstelle 1031. Der eSIM-Server 140 kann auch über den lokalen Profilassistenten 1001 mithilfe der Schnittstellen 1032 und 1033 kommunizieren. Der MNO-Server 130 kommuniziert auch direkt mit dem SE oder indirekt durch die Vorrichtung 501 (diese Schnittstellen sind in 10 nicht dargestellt).
Beispielvorrichtungsverbindungen
11 veranschaulicht beispielhafte Verbindungsmethoden zur sicheren Kontrolle über Profilrichtlinienregeln in einem System 1100. Der Endbenutzer 1150 kann die Vorrichtung 501 mithilfe der Schnittstelle 1121, die Benutzerschnittstelleneingaben unterstützen kann, verwalten. Der Endbenutzer 1150 kann die Vorrichtung 501 auch extern unter Verwendung einer Schnittstelle 1118 über das Internet 1102 verwalten. Die Vorrichtung 501 ist mit einer drahtlosen Basisstation 1104 über eine Drahtlosverbindung 1106 oder mit dem Internet 1102 über eine kabelgebundene Verbindung 1122 verbunden dargestellt. Bei der drahtlosen Basisstation 1104 kann es sich um einen „Wireless Fidelity“-Zugangspunkt (AP) gemäß dem Standard 802.11 des „Institute of Electronic and Electrical Engineers" („IEEE 802.11"-Wi-Fi) handeln; bei der drahtlosen Basisstation 1104 kann es sich zum Beispiel um eine Mobilfunknetz-Basisstation handeln. Beispiele von Mobilfunknetz-Basisstationen stellen 2G- oder 3G-Basisstationen oder ein LTE-eNODE-B dar.
Drahtlose Vorrichtungen, und insbesondere mobile Vorrichtungen, können mehrere unterschiedliche Funkzugangstechnologien beinhalten, um durch unterschiedliche drahtlose Netzwerke, die unterschiedliche Dienste und/oder Fähigkeiten bieten, Verbindungen bereitzustellen. Eine drahtlose Vorrichtung kann Hardware und Software einschließen, um ein drahtloses persönliches Netzwerk (wireless personal area network („WPAN“)) gemäß einen WPAN-Kommunikationsprotokoll zu unterstützen, wie beispielsweise die durch die „Bluetooth^® Special Interest Group“ („SIG“) standardisierten und/oder die durch Apple entwickelten, die als eine drahtlose direkte Verbindung von Apple (Apple Wireless Direct Link (AWDL)) bezeichnet werden. Die drahtlose Vorrichtung kann kompatible drahtlose Peripherievorrichtungen erkennen und kann Verbindungen mit diesen drahtlosen Peripherievorrichtungen herstellen, die angeordnet sind, um durch ein WPAN spezifische Kommunikationsdienste bereitzustellen. In manchen Situationen kann die drahtlose Vorrichtung als eine Kommunikationsnabe (hub) agieren, die einer breiten Vielfalt von Diensten, die durch vielfältige Anwendungen unterstützt werden können, die auf der drahtlosen Vorrichtung ausgeführt werden, Zugang zu einem drahtlosen lokalen Netzwerk (wireless local area network („WLAN“)) und/oder zu einem drahtlosen Weitverkehrsnetzwerk (wireless wide area network („WWAN“) bereitstellt. Somit kann eine Kommunikationsfähigkeit für eine drahtlose Zubehörvorrichtung, z. B. ohne und/oder nicht für WWAN-Kommunikation konfiguriert, unter Verwendung einer Verbindung eines lokalen WPAN (oder WLAN) zu einer drahtlosen Gegenstück- oder Primärvorrichtung erweitert werden. Alternativ dazu kann die drahtlose Zubehörvorrichtung auch eine Drahtlos-Schaltlogik für eine WLAN-Verbindung einschließen und kann Ausgangs- und/oder Endpunkt von Verbindungen über eine WLAN-Verbindung sein. Ob eine direkte Verbindung oder eine vermittelte Verbindung verwendet werden soll, kann von Leistungsfähigkeits-Charakteristika einer oder mehrerer Verbindungen einer aktiven Kommunikationssitzung zwischen der drahtlosen Zubehörvorrichtung und einer entfernt angeordneten Vorrichtung abhängen. Weniger Verbindungen (oder Sprünge) können eine geringere Latenz bereitstellen, und somit kann eine direkte Verbindung bevorzugt werden; anders jedoch als eine leitungsvermittelte Altbestandsverbindung, die eine dedizierte Verbindung bereitstellt, kann die direkte Verbindung über ein WLAN Bandbreite mit anderen drahtlosen Vorrichtungen auf demselben WLAN und/oder mit der Backhaul-Verbindung von dem Zugangspunkt aus, der das WLAN verwaltet, gemeinsam nutzen. Wenn sich eine Leistungsfähigkeit auf der lokalen WLAN-Verbindung und/oder der Backhaul-Verbindung verschlechtert, kann eine vermittelte Verbindung über eine drahtlose Gegenstückvorrichtung bevorzugt werden. Durch Überwachen einer Leistungsfähigkeit einer aktiven Kommunikationssitzung und einer Verfügbarkeit und von Fähigkeiten von zugeordneten drahtlosen Vorrichtungen (wie beispielsweise einer Nähe zu einer drahtlosen Partnervorrichtung) kann eine drahtlose Zubehörvorrichtung einen Transfer einer aktiven Kommunikationssitzung zwischen einer direkten Verbindung und einer vermittelten Verbindung oder umgekehrt anfordern.
Gemäß verschiedenen hierin beschriebenen Ausführungsformen können die Begriffe „drahtlose Kommunikationsvorrichtung“, „drahtlose Vorrichtung“, „mobile Vorrichtung“, „mobile Station“, „drahtlose Station“, „drahtloser Zugangspunkt“, „Station“, „Zugangspunkt“ und „Benutzerausrüstung“ (UE) hierin verwendet werden, um eine oder mehrere verbreitete elektronische Verbrauchervorrichtungen zu beschrieben, die zu einem Durchführen von Prozeduren fähig sein können, die verschiedenen Ausführungsformen der Offenbarung zugeordnet sein können. Gemäß verschiedenen Implementierungen kann sich jede dieser elektronischen Verbrauchervorrichtungen beziehen auf: ein Mobiltelefon oder ein Smartphone, einen Tablet-Computer, einen Laptop-Computer, einen Notebook-Computer, einen persönlichen Computer (PC), einen Netbook-Computer, eine Medienwiedergabevorrichtung, eine Vorrichtung eines elektronischen Buchs, eine MiFi^®-Vorrichtung, eine am Körper tragbare Rechenvorrichtung sowie jeden anderen Typ von elektronischer Rechenvorrichtung mit einer Fähigkeit zu drahtloser Kommunikation, die eine Kommunikation über ein oder mehreren Protokolle für drahtlose Kommunikation einschließt, wie beispielsweise für eine Kommunikation verwendet auf: einem drahtlosen Weitverkehrsnetzwerk (WWAN), einem drahtlosen Metronetzwerk (wireless metro area network (WMAN)), einem drahtlosen lokalen Netzwerk (WLAN), einem drahtlosen persönlichen Netzwerk (WPAN), einer Nahfeldkommunikation (near field communication (NFC)), einem drahtlosen Mobilfunknetz, einem Netz von LTE der vierten Generation (4G), „LTE Advanced“ (LTE-A) und/oder einem 5G-Netz oder anderen derzeitigen oder zukünftig entwickelten fortschrittlichen drahtlosen Mobilfunknetzen.
Die drahtlose Vorrichtung kann in manchen Ausführungsformen auch als Teil eines Systems für drahtlose Kommunikation arbeiten, das einen Satz von Client-Vorrichtungen, die auch als Stationen bezeichnet werden können, drahtlose Client-Vorrichtungen oder drahtlose Client-Vorrichtungen, die mit einem Zugangspunkt (AP), z.B. als Teil eines WLAN, oder miteinander, z.B. als Teil eines WPAN und/oder eines drahtlosen Ad-hoc-Netzwerks, wie beispielsweise einer direkten Wi-Fi-Verbindung, verbunden sind, einschließen kann. In manchen Ausführungsformen kann es sich bei der Client-Vorrichtung um jede drahtlose Vorrichtung handeln, die zu einem Kommunizieren über eine WLAN-Technologie, z.B. gemäß einem Kommunikationsprotokoll eines drahtlosen lokalen Netzwerks, fähig ist. In manchen Ausführungsformen kann die WLAN-Technologie ein drahtloses Wi-Fi (oder allgemeiner WLAN)-Kommunikationsuntersystem oder eine solche Funkeinheit einschließen, wobei die Wi-Fi-Funkeinheit eine Technologie des Standards 802.11 des „Institute of Electrical and Electronics Engineers" (IEEE) implementieren kann, wie beispielsweise eines oder mehrere von: IEEE 802.11a; IEEE 802.11b; IEEE 802.11g; IEEE 802.11-2007; IEEE 802.11n; IEEE 802.11-2012; IEEE 802.11ac; IEEE 802.11ax oder anderen derzeitigen oder zukünftig entwickelten IEEE 802.11-Technologien.
Zusätzlich sollte es sich verstehen, dass die hierin beschriebenen drahtlosen Vorrichtungen als drahtlose Mehrfachmodus-Kommunikationsvorrichtungen konfiguriert sein können, die zudem zur Kommunikation über unterschiedliche Funkzugangstechnologien der dritten Generation (3G) und/oder der zweiten Generation (2G) fähig sind. In diesen Szenarios kann eine drahtlose Mehrfachmodusvorrichtung oder -UE konfiguriert sein, eine Anbindung an LTE-Netze zu bevorzugen, die verglichen mit anderen 3G-Altbestandsnetzen, die niedrigere Datenübertragungsgeschwindigkeits-Durchsätze bieten, einen schnelleren Datenübertragungsgeschwindigkeits-Durchsatz bieten. Zum Beispiel kann in manchen Implementierungen eine drahtlose Mehrfachmodusvorrichtung oder -UE konfiguriert sein, wieder auf ein 3G-Altbestandsnetz zurückzugreifen, z.B. ein „Evolved High Speed Packet Access“ (HSPA+)-Netz oder ein „Code Division Multiple Access“ (CDMA)-2000-„Evolution-Data Only“ EV-DO)-Netz, wenn LTE- und LTE-A-Netze anderweitig nicht verfügbar sind.
Stellvertretende beispielhafte Einrichtung
12 veranschaulicht in einem Blockdiagrammformat eine beispielhafte Rechenvorrichtung 1200, die verwendet werden kann, um die verschiedenen hierin beschriebenen Komponenten und Techniken gemäß manchen Ausführungsformen zu implementieren. Insbesondere veranschaulicht die detaillierte Ansicht der beispielhaften Rechenvorrichtung 1200 verschiedene Komponenten, die in der Vorrichtung 501, dem SE 110, dem eSIM-Server 140 und/oder dem MNO-Server 130, wie in 1, 4, 5A, 8A und 11 dargestellt, enthalten sein können. Wie in 12 gezeigt, kann die Rechenvorrichtung 1200 einen Prozessor 1202 einschließen, der für einen Mikroprozessor oder eine Steuereinheit zum Steuern des gesamten Betriebs der Rechenvorrichtung 1200 steht. Die Rechenvorrichtung 1200 kann zudem eine Benutzereingabevorrichtung 1208 einschließen, die es einem Benutzer der Rechenvorrichtung 1200 erlaubt, mit der Rechenvorrichtung 1200 zu interagieren. Zum Beispiel kann das Benutzereingabegerät 1208 eine Vielzahl an Formen annehmen, wie eine Taste, ein Tastenfeld, eine Wählscheibe, einen Berührungsbildschirm, eine Audioeingabeschnittstelle, eine visuelle/Bildaufnahmeeingabeschnittstelle, Eingabe in der Form von Sensordaten etc. Darüber hinaus kann die Rechenvorrichtung 1200 eine Anzeige 1210 (Bildschirmanzeige), die durch den Prozessor 1202 gesteuert werden kann, beinhalten, um Informationen an den Benutzer anzuzeigen (zum Beispiel Informationen bezüglich eingehender, ausgehender oder aktiver Kommunikationssitzungen). Ein Datenbus 1216 kann eine Datenübertragung zwischen mindestens einer Datenspeichervorrichtung 1240, dem Prozessor 1202 und einer Steuereinheit 1213 ermöglichen. Die Steuereinheit 1213 kann verwendet werden, um durch einen Ausrüstungssteuerbus 1214 über eine Schnittstelle eine Verbindung mit anderer Ausrüstung herzustellen und diese zu steuern. Die Rechenvorrichtung 1200 kann auch eine Netzwerk-/Busschnittstelle 1211 einschließen, die an eine Datenverbindung 1212 gekoppelt ist. Im Fall einer drahtlosen Verbindung kann die Netzwerk-/Busschnittstelle 1211 eine Drahtlos-Schaltlogik, wie beispielsweise einen Drahtlos-Transceiver und/oder einen Basisbandprozessor einschließen. Die Rechenvorrichtung 1200 kann auch ein sicheres Element 1250 einschließen. Das sichere Element 1250 kann eine eUICC oder eine UICC einschließen. In einigen Ausführungsformen schließt die Rechenvorrichtung 1200 einen Basisbandprozessor, einen oder mehrere Funkfrequenz-(RF-)Sendeempfänger und eine oder mehrere Antennen (nicht dargestellt) ein.
Die Rechenvorrichtung 1200 schließt auch eine Datenspeichervorrichtung 1240 ein, die einen einzigen Datenspeicher oder eine Mehrzahl von Datenspeichern (z.B. Festplattenlaufwerke) umfassen kann, und schließt ein Datenspeicherverwaltungsmodul ein, das eine oder mehrere Partitionen innerhalb der Datenspeichervorrichtung 1240 verwaltet. In manchen Ausführungsformen kann die Datenspeichervorrichtung 1240 einen Flash-Speicher, einen Halbleiter(solid state)-Speicher oder Ähnliches einschließen. Die Rechenvorrichtung 1200 kann auch einen Speicher mit wahlfreiem Zugriff (Random Access Memory („RAM“)) 1220 und einen Nur-Lese-Speicher (Read-Only Memory („ROM“)) 1222 einschließen. Der ROM 1222 kann Programme, Dienstprogramme oder Prozesse speichern, die auf eine nichtflüchtige Weise auszuführen sind. Der RAM 1220 kann einen flüchtigen Datenspeicher bereitstellen, und in ihm werden Anweisungen in Zusammenhang mit dem Betrieb der Rechenvorrichtung 1200 gespeichert.
Die verschiedenen Aspekte, Ausführungsformen, Implementierungen oder Merkmale der beschriebenen Ausführungsformen können separat oder in beliebiger Kombination verwendet werden. Verschiedene Aspekte der beschriebenen Ausführungsformen können durch Software, Hardware oder eine Kombination aus Hardware und Software implementiert werden. Die beschriebenen Ausführungsformen können auch als computerlesbarer Code auf einem computerlesbaren Medium enthalten sein. Bei dem computerlesbaren Medium handelt es sich um eine beliebige Datenspeichervorrichtung, die Daten speichern kann, welche danach durch ein Computersystem gelesen werden können. Beispiele des computerlesbaren Mediums schließen einen Nur-Lese-Speicher, einen Speicher mit wahlfreiem Zugriff, CD-ROMs, DVDs, Magnetband, Festplattendatenspeicherlaufwerke, Halbleiterlaufwerke und optische Datenspeichervorrichtungen ein. Das computerlesbare Medium kann auch über netzwerkgekoppelte Computersysteme verteilt werden, sodass der computerlesbare Code auf eine verteilte Weise gespeichert und ausgeführt wird.
Die vorhergehende Beschreibung verwendete zu Zwecken der Erklärung eine spezifische Nomenklatur, um ein vollständiges Verständnis der beschriebenen Ausführungsformen bereitzustellen. Es ist jedoch für den Fachmann ersichtlich, dass die spezifischen Details nicht benötigt werden, um die beschriebenen Ausführungsformen auszuführen. Somit werden die vorhergehenden Beschreibungen spezifischer Ausführungsformen zu Zwecken der Veranschaulichung und Beschreibung vorgelegt. Sie sollen nicht erschöpfend sein oder die beschriebenen Ausführungsformen auf die präzisen offenbarten Formen begrenzen. Es ist für den Fachmann ersichtlich, dass viele Modifikationen und Variationen angesichts der vorstehenden Lehren möglich sind.
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 Nicht-Patentliteratur

„RSP Technical Specification“, Version 1.1, 9. Juni 2016 (hierin nachstehend „SGP.22“) [0003]
„Embedded SIM Remote Provisioning Architecture“, Version 1.1, 30. Januar 2014 (nachstehend „SGP.01“) [0003]
„Remote Provisioning Architecture for Embedded UICC Technical Specification“, Version 3.1, 27. Mai 2016 (nachstehend „SGP.02“) [0003]
Richtlinie Nr. 1 [0032]
Richtlinie Nr. 2 [0032]
Richtlinie Nr. 3 [0032]
Richtlinie Nr. 4 [0032]
Richtlinie Nr. 5 [0032]
Richtlinie Nr. 6 [0032]
RFC 5246 [0035]
Richtlinie Nr. 1 [0036]
Richtlinie Nr. N [0036]
Richtlinie Nr. 1 [0036]
Richtlinie Nr. 2 [0036]
Richtlinie Nr. 5 [0037]
Richtlinie Nr. 5 [0037]
Richtlinie Nr. 3 [0037]
Richtlinie Nr. 3 [0037]
Richtlinie Nr. 3 [0037]
(RFC) 5280 [0040]
Standard 802.11 des „Institute of Electronic and Electrical Engineers“ („IEEE 802.11“-Wi-Fi) [0071]
Standards 802.11 des „Institute of Electrical and Electronics Engineers“ (IEEE) [0074]
IEEE 802.11a [0074]
IEEE 802.11b [0074]
IEEE 802.11g [0074]
IEEE 802.11-2007 [0074]
IEEE 802.11n [0074]
IEEE 802.11-2012 [0074]
IEEE 802.11ac [0074]
IEEE 802.11ax [0074]
IEEE 802.11-Technologien [0074]

Claims

Verfahren eines sicheren Elements (SE), wobei das Verfahren Folgendes umfasst: i) Empfangen eines binären großen Objekts (BLOB); ii) Parsen einer ersten Kennung eines Mobilfunkbetreibers (MNO) aus dem BLOB; iii) Parsen einer Signatur aus dem BLOB; iv) Erhalten eines Schlüssels; v) wenn eine Überprüfung der Signatur mit dem Schlüssel angibt, dass die Signatur von dem MNO erstellt wurde: a) Parsen von Aktualisierungsinformationen einer Profilrichtlinienregel (PPR) aus dem BLOB und b) Einstellen einer Richtlinienregelvariablen auf einen aktivierten Zustand oder deaktivierten Zustand auf der Grundlage der PPR-Aktualisierungsinformationen, wobei die Richtlinienregelvariable einem auf dem SE vorhandenen Profil zugeordnet ist; und vi) wenn die Überprüfung der Signatur mit dem Schlüssel angibt, dass die Signatur nicht von dem MNO erstellt wurde: Vornehmen keiner Änderung in der Richtlinienregelvariablen.
Verfahren nach Anspruch 1, ferner umfassend: wenn die Überprüfung der Signatur mit dem Schlüssel angibt, dass die Signatur nicht von dem MNO erstellt wurde: Verwerfen des BLOB.
Verfahren nach Anspruch 1, wobei eine International Mobile Subscriber Identity (IMSI) im Zusammenhang mit dem Profil dem MNO zugeordnet ist.
Verfahren nach Anspruch 1, wobei: i) das BLOB von einem eSIM-Server (electronic Subscriber Identity Module) über eine Vorrichtung empfangen wird und ii) das SE in der Vorrichtung untergebracht ist.
Verfahren nach Anspruch 1, wobei das Parsen einer Profilkennung das Parsen der Profilkennung aus einem Metadatenabschnitt des BLOB umfasst.
Verfahren nach Anspruch 1, wobei: i) das BLOB kein gebundenes Profilpaket (BPP) umfasst und ii) das auf dem SE vorhandene Profil in einem deaktivierten Zustand ist.
Verfahren nach Anspruch 1, wobei das Erhalten eines Schlüssels Folgendes umfasst: Erhalten von Parametern eines öffentlichen Schlüssels von dem BLOB, wobei die Parameter eines öffentlichen Schlüssels mit dem MNO verbunden sind.
Verfahren nach Anspruch 1, wobei das Erhalten eines Schlüssels Folgendes umfasst: Erhalten des Schlüssels von einem SE-Speicherort.
Verfahren nach Anspruch 8, wobei das Erhalten eines Schlüssels Folgendes umfasst: Parsen eines Objektbezeichners (OID) aus dem BLOB; Zugreifen auf einen SE-Speicherort auf der Grundlage der OID; und Erhalten des Schlüssels von einem SE-Speicherort.
Verfahren nach Anspruch 9, wobei die OID mit einer Zertifizierungsstelle (CA) verbunden ist.
Verfahren nach Anspruch 9, wobei die OID mit dem MNO verbunden ist.
Verfahren nach Anspruch 1, wobei das Erhalten eines Schlüssels Folgendes umfasst: Erhalten des Schlüssels von einem Zertifikat, wobei: i) das BLOB das Zertifikat umfasst und ii) das Zertifikat eine Kennung des MNO umfasst.
Verfahren nach Anspruch 12, wobei: i) das Zertifikat von einem Zertifikataussteller (CI) signiert ist und ii) eine vertrauenswürdige Liste, die in dem SE gespeichert ist, eine Kennung des CI umfasst.
Sicheres Element (SE), umfassend: einen Speicher; und einen Prozessor, wobei der Speicher Anweisungen enthält, die bei Ausführung durch den Prozessor veranlassen, dass das SE das Verfahren nach einem der Ansprüche 1–13 durchführt.
Nichttransitorisches computerlesbares Medium, das Anweisungen einschließt, die, wenn sie von einem sicheren Element (SE) ausgeführt werden, veranlassen, dass das SE das Verfahren nach einem der Ansprüche 1–13 durchführt.