UICC-Beförderungsrechte

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Android 5.1 hat einen Mechanismus eingeführt, um spezielle Privilegien für APIs zu gewähren, die für die Besitzer von Universal Integrated Circuit Card (UICC)-Apps relevant sind. Die Android-Plattform lädt Zertifikate, die auf einer UICC gespeichert sind, und erteilt Apps, die von diesen Zertifikaten signiert wurden, die Erlaubnis, eine Handvoll spezieller APIs aufzurufen.

Android 7.0 hat diese Funktion erweitert, um andere Speicherquellen für die UICC-Berechtigungsregeln für Netzbetreiber zu unterstützen, wodurch die Anzahl der Netzbetreiber, die die APIs verwenden können, dramatisch erhöht wurde. Eine API-Referenz finden Sie unter CarrierConfigManager ; Anleitungen finden Sie unter Trägerkonfiguration .

Carrier haben die volle Kontrolle über die UICC, sodass dieser Mechanismus eine sichere und flexible Möglichkeit bietet, Apps vom Mobilfunknetzbetreiber (MNO) zu verwalten, die auf allgemeinen App-Vertriebskanälen (wie Google Play) gehostet werden, während besondere Privilegien auf Geräten und ohne die Notwendigkeit beibehalten werden um Apps mit dem Plattformzertifikat pro Gerät zu signieren oder als System-App vorzuinstallieren.

Regeln für UICC

Die Speicherung auf der UICC ist mit der GlobalPlatform Secure Element Access Control - Spezifikation kompatibel . Die Anwendungskennung (AID) auf der Karte ist A00000015141434C00 und der Standardbefehl GET DATA wird verwendet, um auf der Karte gespeicherte Regeln abzurufen. Sie können diese Regeln über OTA-Updates (Card Over-the-Air) aktualisieren.

Datenhierarchie

UICC-Regeln verwenden die folgende Datenhierarchie (die Kombination aus zwei Buchstaben und Zahlen in Klammern ist das Objekt-Tag). Jede Regel ist REF-AR-DO ( E2 ) und besteht aus einer Verkettung von REF-DO und AR-DO :

  • REF-DO ( E1 ) enthält DeviceAppID-REF-DO oder eine Verkettung von DeviceAppID-REF-DO und PKG-REF-DO .
    • DeviceAppID-REF-DO ( C1 ) speichert die SHA-1 (20 Bytes) oder SHA-256 (32 Bytes) Signatur des Zertifikats.
    • PKG-REF-DO ( CA ) ist die vollständige Zeichenfolge des Paketnamens, die im Manifest definiert ist, ASCII-codiert, maximale Länge 127 Bytes.
  • AR-DO ( E3 ) wird um PERM-AR-DO ( DB ) erweitert, bei dem es sich um eine 8-Byte-Bitmaske handelt, die 64 separate Berechtigungen darstellt.

Wenn PKG-REF-DO nicht vorhanden ist, wird jeder mit dem Zertifikat signierten App Zugriff gewährt; Andernfalls müssen sowohl das Zertifikat als auch der Paketname übereinstimmen.

Regelbeispiel

Der App-Name lautet com.google.android.apps.myapp und das SHA-1-Zertifikat in hexadezimaler Zeichenfolge lautet:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

Die Regel für UICC in Hex-String lautet:

E243 <= 43 is value length in hex
  E135
    C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
    CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
  E30A
    DB08 0000000000000001

Unterstützung für Zugriffsregeldateien

Android 7.0 fügt Unterstützung für das Lesen von Netzbetreiber-Berechtigungsregeln aus der Zugriffsregeldatei (ARF) hinzu.

Die Android-Plattform versucht zunächst, die Zugriffsregelanwendung (ARA) AID A00000015141434C00 . Wenn es die AID auf der UICC nicht findet, greift es auf ARF zurück, indem es PKCS15 AID A000000063504B43532D3135 . Android liest dann die Zugriffskontrollregeldatei (ACRF) bei 0x4300 und sucht nach Einträgen mit AID FFFFFFFFFFFF . Einträge mit unterschiedlichen AIDs werden ignoriert, sodass Regeln für andere Anwendungsfälle koexistieren können.

Beispiel-ACRF-Inhalt in Hex-String:

30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10

Beispiel für den Inhalt einer Zugriffskontrollbedingungsdatei (ACCF):

30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81

Im obigen Beispiel ist 0x4310 die Adresse für ACCF, die den Zertifikat-Hash 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Apps, die mit diesem Zertifikat signiert sind, werden Betreiberprivilegien gewährt.

Aktivierte APIs

Android unterstützt die folgenden APIs.

TelefonieManager

TelefonieRückruf

TelephonyCallback hat Schnittstellen mit einer Callback-Methode, um die anrufende App zu benachrichtigen, wenn sich die registrierten Zustände ändern:

SubscriptionManager

SMSManager

CarrierConfigManager

  • Methode zum Benachrichtigen der geänderten Konfiguration: notifyConfigChangedForSubId .
  • Methode zum Abrufen der Netzbetreiberkonfiguration für das Standardabonnement: getConfig
  • Methode zum Abrufen der Netzbetreiberkonfiguration für das angegebene Abonnement: getConfigForSubId

Anweisungen finden Sie unter Trägerkonfiguration .

BugreportManager

Methode zum Starten eines Konnektivitätsfehlerberichts, bei dem es sich um eine spezialisierte Version des Fehlerberichts handelt, die nur Informationen zum Debuggen von Verbindungsproblemen enthält: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

Bereitstellungsmanager

EuiccManager

Methode zum Wechseln (Aktivieren) des angegebenen Abonnements: switchToSubscription

CarrierMessagingService

Dienst, der Anrufe vom System entgegennimmt, wenn neue SMS und MMS gesendet oder empfangen werden. Um diese Klasse zu erweitern, deklarieren Sie den Dienst in Ihrer Manifestdatei mit der android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE und fügen Sie einen Absichtsfilter mit der Aktion #SERVICE_INTERFACE ein. Zu den Methoden gehören:

  • Methode zum Filtern eingehender SMS-Nachrichten: onFilterSms
  • Methode zum Abfangen von Text-SMS-Nachrichten, die vom Gerät gesendet werden: onSendTextSms
  • Methode zum Abfangen von binären SMS-Nachrichten, die vom Gerät gesendet werden: onSendDataSms
  • Methode zum Abfangen langer SMS-Nachrichten, die vom Gerät gesendet werden: onSendMultipartTextSms
  • Methode zum Abfangen von MMS-Nachrichten, die vom Gerät gesendet werden: onSendMms
  • Methode zum Herunterladen empfangener MMS-Nachrichten: onDownloadMms

CarrierService

Dienst, der dem System netzbetreiberspezifische Funktionen zur Verfügung stellt. Um diese Klasse zu erweitern, deklarieren Sie den Dienst in der App-Manifestdatei mit der android.Manifest.permission#BIND_CARRIER_SERVICES und fügen Sie einen Absichtsfilter mit der Aktion CARRIER_SERVICE_INTERFACE ein. Wenn der Dienst eine langlebige Bindung hat, setzen android.service.carrier.LONG_LIVED_BINDING in den Metadaten des Dienstes auf „ true “.

Die Plattform bindet CarrierService mit speziellen Flags, um den Carrier-Service-Prozess in einem speziellen App-Standby-Bucket laufen zu lassen. Dadurch wird die Carrier-Service-App von der App-Leerlaufbeschränkung ausgenommen und es ist wahrscheinlicher, dass sie am Leben bleibt, wenn der Gerätespeicher niedrig ist. Wenn die Carrier-Service-App jedoch aus irgendeinem Grund abstürzt, verliert sie alle oben genannten Berechtigungen, bis die App neu gestartet und die Bindung wiederhergestellt wird. Daher ist es wichtig, die Carrier-Service-App stabil zu halten.

Zu den Methoden in CarrierService gehören:

  • So überschreiben und setzen Sie die betreiberspezifischen Konfigurationen: onLoadConfig
  • So informieren Sie das System über einen absichtlich bevorstehenden Wechsel des Netzbetreibers durch die Netzbetreiberanwendung: notifyCarrierNetworkChange den Netzbetreiber

Telefonanbieter

Inhaltsanbieter-APIs, um Änderungen (Einfügen, Löschen, Aktualisieren, Abfragen) an der Telefoniedatenbank zu ermöglichen. Wertefelder werden bei Telephony.Carriers definiert; Weitere Einzelheiten finden Sie in der Referenz zur Telephony

WifiNetworkVorschlag

Verwenden Sie beim Erstellen eines WifiNetworkSuggestion Objekts die folgenden Methoden, um eine Abonnement-ID oder eine Abonnementgruppe festzulegen:

Android-Plattform

Auf einer erkannten UICC erstellt die Plattform interne UICC-Objekte, die Befördererprivilegienregeln als Teil der UICC enthalten. UiccCarrierPrivilegeRules.java lädt Regeln, parst sie von der UICC-Karte und speichert sie im Arbeitsspeicher. Wenn eine Berechtigungsprüfung erforderlich ist, vergleicht UiccCarrierPrivilegeRules das Anruferzertifikat nacheinander mit seinen eigenen Regeln. Wenn die UICC entfernt wird, werden die Regeln zusammen mit dem UICC-Objekt zerstört.

Validierung

Um die Implementierung durch die Compatibility Test Suite (CTS) mit CtsCarrierApiTestCases.apk zu validieren, müssen Sie über eine Entwickler-UICC mit den richtigen UICC-Regeln oder ARF-Unterstützung verfügen. Bitten Sie den SIM-Kartenanbieter Ihrer Wahl, eine Entwickler-UICC mit dem richtigen ARF wie in diesem Abschnitt beschrieben vorzubereiten, und verwenden Sie diese UICC, um die Tests durchzuführen. Die UICC erfordert keinen aktiven Mobilfunkdienst, um CTS-Tests zu bestehen.

Bereiten Sie die UICC vor

Für Android 11 und niedriger ist CtsCarrierApiTestCases.apk von aosp-testkey mit dem Hashwert 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 .

Ab Android 12 ist CtsCarrierApiTestCases.apk mit cts-uicc-2021-testkey , Hashwert CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0 .

Um CTS-Betreiber-API-Tests in Android 12 auszuführen, muss das Gerät eine SIM-Karte mit CTS-Betreiberrechten verwenden, die die Anforderungen erfüllen, die in der neuesten Version der GSMA TS.48 -Testprofilspezifikation des Drittanbieters angegeben sind.

Dieselbe SIM-Karte kann auch für Versionen vor Android 12 verwendet werden.

Ändern des CTS-SIM-Profils

  1. Hinzufügen: CTS-Carrier-Privilegien im Access Rule Application Master (ARA-M) oder ARF. Beide Signaturen müssen in den Carrier Privilege Rules verschlüsselt werden:
    1. Hash1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. Hash2(SHA256): CE:7B:2B:47:AE:2B:75:52:C8:F9:2C:C2:91:24:27:98:83:04:1F:B6:23:A5:F1:94:A8:2C:9B:F1:5D:49:2A:A0
  2. Erstellen: ADF USIM-Elementardateien (EFs), die in TS.48 nicht vorhanden sind und für CTS benötigt werden:
    1. EF_MBDN (6FC7), Datensatzgröße: 28, Datensatznummer: 4
      • Inhalt
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), Datensatzgröße: 13, Datensatznummer: 1
      • Inhalt: 00FF…FF
        1. EF_MBI (6FC9), Satzgröße: 4, Satznummer: 1
      • Inhalt: Rec1: 01010101
        1. EF_MWIS (6FCA), Datensatzgröße: 5, Datensatznummer: 1
      • Inhalt: 0000000000
  3. Ändern: USIM-Diensttabelle: Dienste Nr. 47, Nr. 48 aktivieren
    1. EF_UST (6F38)
      • Inhalt: 9EFFBF1DFFFE0083410310010400406E01
  4. Ändern: DF-5GS- und DF-SAIP-Dateien
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Inhalt: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Inhalt: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Inhalt: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Inhalt: A0020000FF…FF
  5. Modifizieren: Verwenden Sie die Trägernamenzeichenfolge Android CTS in den jeweiligen EFs, die diese Bezeichnung enthalten:
    1. EF_SPN (USIM/6F46)
      • Inhalt: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Inhalt: Rec1 430B83413759FE4E934143EA14FF..FF

Anpassen der Testprofilstruktur

Laden Sie die neueste Version der folgenden generischen Testprofilstrukturen herunter und passen Sie sie an. Bei diesen Profilen wird die CTS-Carrier-Privilege-Regel nicht personalisiert oder andere oben aufgeführte Modifikationen haben.

Laufende Tests

Der Einfachheit halber unterstützt CTS ein Geräte-Token, das Tests darauf beschränkt, nur auf Geräten ausgeführt zu werden, die mit demselben Token konfiguriert sind. Carrier-API-CTS-Tests unterstützen das Geräte-Token sim-card-with-certs . Beispielsweise schränkt das folgende Geräte-Token die Ausführung von Netzbetreiber-API-Tests nur auf dem Gerät abcd1234 :

cts-tradefed run cts  --device-token abcd1234:sim-card-with-certs

Wenn Sie einen Test ohne Verwendung eines Gerätetokens ausführen, wird der Test auf allen Geräten ausgeführt.

FAQ

Wie können Zertifikate auf der UICC aktualisiert werden?

A: Verwenden Sie den bestehenden Karten-OTA-Aktualisierungsmechanismus.

Kann UICC mit anderen Regeln koexistieren?

A: Es ist in Ordnung, andere Sicherheitsregeln auf der UICC unter derselben AID zu haben; die Plattform filtert sie automatisch heraus.

Was passiert, wenn die UICC für eine App entfernt wird, die sich auf die Zertifikate darauf verlässt?

A: Die App verliert ihre Berechtigungen, da die mit der UICC verknüpften Regeln beim Entfernen der UICC zerstört werden.

Ist die Anzahl der Zertifikate auf der UICC begrenzt?

A: Die Plattform beschränkt die Anzahl der Zertifikate nicht; Da die Prüfung jedoch linear ist, können zu viele Regeln eine Wartezeit für die Prüfung verursachen.

Gibt es eine Begrenzung für die Anzahl der APIs, die wir mit dieser Methode unterstützen können?

A: Nein, aber wir beschränken den Geltungsbereich auf Carrier-bezogene APIs.

Gibt es einige APIs, die diese Methode nicht verwenden dürfen? Wenn ja, wie setzen Sie sie durch? (Das heißt, haben Sie Tests, um zu validieren, welche APIs mit dieser Methode unterstützt werden?)

A: Siehe den Abschnitt API Behavioral Compatibility des Android Compatibility Definition Document (CDD). Wir haben einige CTS-Tests, um sicherzustellen, dass das Berechtigungsmodell der APIs nicht geändert wird.

Wie funktioniert das mit der Multi-SIM-Funktion?

A: Die vom Benutzer angegebene Standard-SIM wird verwendet.

Interagiert oder überschneidet sich dies in irgendeiner Weise mit anderen SE-Zugangstechnologien, z. B. SEEK?

A: Zum Beispiel verwendet SEEK die gleiche AID wie auf der UICC. Die Regeln koexistieren also und werden entweder durch SEEK oder UiccCarrierPrivileges gefiltert.

Wann ist es ein guter Zeitpunkt, die Privilegien der Transportunternehmen zu überprüfen?

A: Nach dem SIM-Status wurde die Sendung geladen.

Können OEMs einen Teil der Carrier-APIs deaktivieren?

A: Nein. Wir glauben, dass die aktuellen APIs der minimale Satz sind, und wir planen, die Bitmaske in Zukunft für eine feinere Granularitätssteuerung zu verwenden.

Überschreibt setOperatorBrandOverride ALLE anderen Formen von Zeichenfolgen für Operatornamen? Zum Beispiel SE13, UICC SPN oder netzwerkbasiertes NITZ?

Ja, die Überschreibung der Betreibermarke hat die höchste Priorität. Wenn es gesetzt ist, überschreibt es ALLE anderen Formen von Zeichenfolgen für Operatornamen.

Was bewirkt der Methodenaufruf injectSmsPdu ?

A: Diese Methode erleichtert die Sicherung/Wiederherstellung von SMS in der Cloud. Der injectSmsPdu -Aufruf aktiviert die Wiederherstellungsfunktion.

Basiert für die SMS-Filterung der onFilterSms -Aufruf auf der SMS-UDH-Portfilterung? Oder haben Mobilfunkanbieter-Apps Zugriff auf ALLE eingehenden SMS?

A: Netzbetreiber haben Zugriff auf alle SMS-Daten.

Die Erweiterung von DeviceAppID-REF-DO zur Unterstützung von 32 Bytes scheint mit der aktuellen GP-Spezifikation (die nur 0 oder 20 Bytes zulässt) nicht kompatibel zu sein. Warum also führen Sie diese Änderung ein? Reicht SHA-1 nicht aus, um Kollisionen zu vermeiden? Haben Sie GP diese Änderung bereits vorgeschlagen, da dies mit dem bestehenden ARA-M/ARF abwärtsinkompatibel sein könnte?

A: Um zukunftssichere Sicherheit zu bieten, führt diese Erweiterung SHA-256 für DeviceAppID-REF-DO zusätzlich zu SHA-1 ein, das derzeit die einzige Option im GP SEAC-Standard ist. Wir empfehlen dringend die Verwendung von SHA-256.

Wenn DeviceAppID 0 (leer) ist, wenden Sie die Regel auf alle Geräte-Apps an, die nicht von einer bestimmten Regel abgedeckt sind?

A: Carrier-APIs erfordern das Auffüllen von DeviceAppID-REF-DO . Leer zu sein ist für Testzwecke vorgesehen und wird für betriebliche Bereitstellungen nicht empfohlen.

Gemäß Ihrer Spezifikation sollte PKG-REF-DO nur für sich allein verwendet werden, ohne DeviceAppID-REF-DO , sollte nicht akzeptiert werden. Aber es wird immer noch in Tabelle 6-4 der Spezifikation als Erweiterung der Definition von REF-DO beschrieben. Ist das Absicht? Wie verhält sich der Code, wenn in REF-DO nur PKG-REF-DO verwendet wird?

A: Die Option, PKG-REF-DO als Einzelwertelement in REF-DO zu haben, wurde in der neuesten Version entfernt. PKG-REF-DO sollte nur in Kombination mit DeviceAppID-REF-DO auftreten.

Wir gehen davon aus, dass wir Zugriff auf alle betreiberbasierten Berechtigungen gewähren oder eine feinere Kontrolle haben können. Wenn ja, was definiert die Zuordnung zwischen der Bitmaske und den tatsächlichen Berechtigungen? Eine Berechtigung pro Klasse? Eine Berechtigung pro Methode? Reichen 64 Einzelberechtigungen auf Dauer aus?

A: Dies ist für die Zukunft reserviert und wir freuen uns über Vorschläge.

Können Sie DeviceAppID speziell für Android weiter definieren? Dies ist der SHA-1-Hashwert (20 Byte) des Herausgeberzertifikats, das zum Signieren der angegebenen App verwendet wird. Sollte der Name also nicht diesen Zweck widerspiegeln? (Der Name könnte für viele Leser verwirrend sein, da die Regel dann für alle Apps gilt, die mit demselben Herausgeberzertifikat signiert sind.)

A: Die DeviceAppID , die Zertifikate speichert, wird von der bestehenden Spezifikation unterstützt. Wir haben versucht, Spezifikationsänderungen zu minimieren, um die Hürde für die Einführung zu senken. Einzelheiten finden Sie unter UICC-Regeln .