UICC-Mobilfunkanbieterberechtigungen

Mit Android 5.1 wurde ein Mechanismus eingeführt, mit dem APIs, die für die Inhaber von UICC-Apps (Universal Integrated Circuit Card) relevant sind, spezielle Berechtigungen gewährt werden können. Die Android-Plattform lädt auf einer UICC gespeicherte Zertifikate und gewährt Apps, die mit diesen Zertifikaten signiert sind, die Berechtigung, eine Handvoll spezieller APIs aufzurufen.

Mit Android 7.0 wurde diese Funktion um die Unterstützung anderer Speicherquellen für UICC-Berechtigungsregeln für Mobilfunkanbieter erweitert. Dadurch konnte die Anzahl der Mobilfunkanbieter, die die APIs verwenden können, deutlich erhöht werden. Eine API-Referenz finden Sie unter CarrierConfigManager; eine Anleitung finden Sie unter Konfiguration des Mobilfunkanbieters.

Mobilfunkanbieter haben die volle Kontrolle über die UICC. Dieser Mechanismus bietet daher eine sichere und flexible Möglichkeit, Apps des Mobilfunkanbieters zu verwalten, die auf generischen App-Vertriebskanälen wie Google Play gehostet werden, während spezielle Berechtigungen auf Geräten beibehalten werden und Apps nicht mit dem gerätespezifischen Plattformzertifikat signiert oder als System-App vorinstalliert werden müssen.

Regeln für UICC

Der Speicher auf der UICC ist mit der GlobalPlatform Secure Element Access Control-Spezifikation kompatibel. Die App-ID (AID) auf der Karte lautet A00000015141434C00. Mit dem Standardbefehl GET DATA werden die auf der Karte gespeicherten Regeln abgerufen. Sie können diese Regeln über OTA-Updates (Over-the-air) aktualisieren.

Datenhierarchie

Für UICC-Regeln wird die folgende Datenhierarchie verwendet (die Kombination aus zwei Buchstaben und einer Zahl in Klammern ist das Objekt-Tag). Jede Regel ist REF-AR-DO (E2) und besteht aus einer Konkatenierung von REF-DO und AR-DO:

  • REF-DO (E1) enthält DeviceAppID-REF-DO oder eine Konkatenierung von DeviceAppID-REF-DO und PKG-REF-DO.
    • DeviceAppID-REF-DO (C1) speichert die SHA-1-Signatur (20 Byte) oder SHA-256 (32 Byte) des Zertifikats.
    • PKG-REF-DO (CA) ist der vollständige String des Paketnamens, der im Manifest definiert ist und ASCII-codiert und darf maximal 127 Byte lang sein.
  • AR-DO (E3) wird um PERM-AR-DO (DB) erweitert. Dabei handelt es sich um eine 8-Byte-Bitmaske, die 64 separate Berechtigungen darstellt.

Wenn PKG-REF-DO nicht vorhanden ist, erhält jede App, die vom Zertifikat signiert wurde, Zugriff. Andernfalls müssen sowohl das Zertifikat als auch der Paketname übereinstimmen.

Beispielregel

Der App-Name ist com.google.android.apps.myapp und das SHA-1-Zertifikat im Hexadezimalstring 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 im Hexadezimalstring lautet:

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

Unterstützung von Zugriffsregeldateien

Android 7.0 unterstützt das Lesen von Berechtigungsregeln für Mobilfunkanbieter aus der Zugriffsregeldatei (Access Rule File, ARF).

Die Android-Plattform versucht zuerst, die AID A00000015141434C00 der Zugriffsregelanwendung (Access Rule Application, ARA) auszuwählen. Wenn die AID in der UICC nicht zu finden ist, wird auf das Kontowiederherstellungsformular zurückgegriffen, indem PKCS15 AID A000000063504B43532D3135 ausgewählt wird. Android liest dann die Access Control Rule File (ACRF) unter 0x4300 und sucht nach Einträgen mit AID FFFFFFFFFFFF. Einträge mit unterschiedlichen AIDs werden ignoriert, sodass Regeln für andere Anwendungsfälle nebeneinander existieren können.

Beispiel für ACRF-Inhalt im Hexadezimalformat:

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

Beispielinhalt einer Datei mit Zugriffssteuerungsbedingungen:

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 Zertifikats-Hash 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 enthält. Apps, die mit diesem Zertifikat signiert sind, erhalten Berechtigungen des Mobilfunkanbieters.

Aktivierte APIs

Android unterstützt die folgenden APIs.

TelephonyManager

TelephonyCallback

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

SubscriptionManager

SmsManager

CarrierConfigManager

Eine Anleitung finden Sie unter Konfiguration des Mobilfunkanbieters.

BugreportManager

Methode zum Starten eines Fehlerberichts zur Verbindungsqualität. Dies ist eine spezielle Version des Fehlerberichts, die nur Informationen zur Fehlerbehebung bei Verbindungsproblemen enthält: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

Methode zum Wechseln zu (Aktivieren von) dem jeweiligen Abo: switchToSubscription

CarrierMessagingService

Dienst, der Anrufe vom System empfängt, wenn neue SMS und MMS gesendet oder empfangen werden. Wenn Sie diese Klasse erweitern möchten, deklarieren Sie den Dienst in Ihrer Manifestdatei mit der Berechtigung android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE und fügen Sie einen Intent-Filter mit der Aktion #SERVICE_INTERFACE hinzu. Zu den Methoden gehören:

  • Methode zum Filtern eingehender SMS-Nachrichten: onFilterSms
  • Methode zum Abfangen von SMS, die vom Gerät gesendet wurden: 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, die vom Gerät gesendet wurden: onSendMms
  • So laden Sie empfangene MMS herunter: onDownloadMms

Versandservice

Dienst, der anbieterspezifische Funktionen für das System bereitstellt. Deklarieren Sie zum Erweitern dieser Klasse den Dienst in der App-Manifestdatei mit der Berechtigung android.Manifest.permission#BIND_CARRIER_SERVICES und schließen Sie einen Intent-Filter mit der Aktion CARRIER_SERVICE_INTERFACE ein. Wenn der Dienst eine langlebige Bindung hat, setzen Sie in den Metadaten des Dienstes android.service.carrier.LONG_LIVED_BINDING auf true.

Die Plattform bindet CarrierService mit speziellen Flags, damit der Mobilfunkdienstprozess in einem speziellen App-Standby-Bucket ausgeführt werden kann. Dadurch wird die App des Mobilfunkanbieters von der Einschränkung für inaktive Apps ausgenommen und ist bei wenig Gerätespeicher eher aktiv. Wenn die App des Mobilfunkanbieters 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, dass die App des Mobilfunkanbieters stabil bleibt.

Zu den Methoden in CarrierService gehören:

  • So überschreiben und legen Sie die anbieterspezifischen Konfigurationen fest: onLoadConfig
  • So informieren Sie das System über eine beabsichtigte Änderung des Mobilfunknetzes durch die App des Mobilfunkanbieters: notifyCarrierNetworkChange

Telefonanbieter

APIs von Contentanbietern, die Änderungen an der Telefondatenbank ermöglichen (Einfügen, Löschen, Aktualisieren, Abfragen). Wertefelder werden unter Telephony.Carriers definiert. Weitere Informationen finden Sie in der Referenz zur Klasse Telephony.

WifiNetworkSuggestion

Verwende beim Erstellen eines WifiNetworkSuggestion-Objekts die folgenden Methoden, um eine Abo-ID oder eine Abogruppe festzulegen:

Android-Plattform

Bei einer erkannten UICC erstellt die Plattform interne UICC-Objekte, die Berechtigungsregeln des Mobilfunkanbieters als Teil der UICC enthalten. UiccCarrierPrivilegeRules.java lädt Regeln, parst sie von der UICC-Karte und speichert sie im Cache. Wenn eine Berechtigungsprüfung erforderlich ist, vergleicht UiccCarrierPrivilegeRules das Zertifikat des Aufrufers einzeln mit seinen eigenen Regeln. Wenn die UICC entfernt wird, werden die Regeln zusammen mit dem UICC-Objekt gelöscht.

Zertifizierungsstufe

Wenn Sie die Implementierung mit CtsCarrierApiTestCases.apk über die Compatibility Test Suite (CTS) validieren möchten, benötigen Sie eine Entwickler-UICC mit den richtigen UICC-Regeln oder ARF-Unterstützung. Bitte den Anbieter deiner SIM-Karte, eine Entwickler-UICC mit dem richtigen Formular zur Kontowiederherstellung gemäß der Beschreibung in diesem Abschnitt vorzubereiten und diese UICC zum Ausführen der Tests zu verwenden. Für die UICC ist kein aktiver Mobilfunkdienst erforderlich, um die CTS-Tests zu bestehen.

UICC vorbereiten

Bei Android 11 und niedriger wird 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 signiert.

Ab Android 12 wird CtsCarrierApiTestCases.apk von cts-uicc-2021-testkey mit dem 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 signiert.

Zum Ausführen von CTS-Mobilfunkanbieter-API-Tests in Android 12 muss das Gerät eine SIM-Karte mit CTS-Mobilfunkanbieterberechtigungen verwenden, die die Anforderungen der aktuellen Version der GSMA TS.48-Testprofilspezifikation eines Drittanbieters erfüllt.

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

CTS-SIM-Profil ändern

  1. Hinzufügen:CTS-Mobilfunkanbieterberechtigungen im Master für Access Rule App Master (ARA-M) oder im Formular zur Kontowiederherstellung. Beide Signaturen müssen in den Berechtigungsregeln des Mobilfunkanbieters codiert sein:
    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 nicht in TS.48 enthalten sind und für CTS erforderlich sind:
    1. EF_MBDN (6FC7), Datensatzgröße: 28, Datensatznummer: 4 
      • Inhalt
        1. Rec1: 566F696365204D61696CFFFFFFFF0691515555555FF…FF
        2. Rec2-n: FF...FF
    2. EF_EXT6 (6FC8), Datensatzgröße:13, Datensatznummer: 1
      • Inhalt: 00FF...FF
        1. EF_MBI (6FC9), Datensatzgröße: 4, Datensatznummer: 1
      • Inhalt: Rec1: 01010101
        1. EF_MWIS (6FCA), Datensatzgröße: 5, Datensatznummer: 1
      • Content: 0000000000
  3. Ändern: USIM-Servicetabelle: Dienste aktivieren, n°47, n°48
    1. EF_UST (6F38)
      • Videos: 9EFFBF1DFFFE0083410310010400406E01
  4. Ändern:DF-5GS- und DF-SAIP-Dateien
    1. DF-5GS – EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Videos: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS – EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Videos: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS – EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Videos: A0020000FF…FF
    4. DF-SAIP – EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Videos: A0020000FF…FF
  5. Ändern:Verwenden Sie den String „Name des Mobilfunkanbieters“ Android CTS in den entsprechenden EFs, die diese Bezeichnung enthalten:
    1. EF_SPN (USIM/6F46)
      • Videos: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Videos: Rec1 430B83413759FE4E934143EA14FF..FF

Struktur des Testprofils abgleichen

Laden Sie die aktuelle Version der folgenden Strukturen für generische Testprofile herunter und gleichen Sie sie ab. Für diese Profile wird die CTS-Berechtigungsregel für Mobilfunkanbieter nicht personalisiert und es werden keine anderen oben aufgeführten Änderungen vorgenommen.

Tests ausführen

Für den Komfort unterstützt CTS ein Gerätetoken, das die Ausführung von Tests auf Geräten einschränkt, die mit demselben Token konfiguriert sind. CTS-Tests der Carrier API unterstützen das Gerätetoken sim-card-with-certs. Mit dem folgenden Gerätetoken werden beispielsweise Carrier API-Tests nur auf dem Gerät abcd1234 ausgeführt:

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

Wenn Sie einen Test ohne Gerätetoken ausführen, wird er auf allen Geräten ausgeführt.

Häufig gestellte Fragen

Wie können Zertifikate auf der UICC aktualisiert werden?

A: Den bestehenden Mechanismus zur OTA-Aktualisierung für Karten verwenden

Kann UICC mit anderen Regeln gleichzeitig verwendet werden?

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 auf die darauf befindlichen Zertifikate angewiesen ist?

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

Gibt es eine Beschränkung für die Anzahl der Zertifikate auf der UICC?

A: Die Plattform schränkt die Anzahl der Zertifikate nicht ein. Da die Prüfung jedoch linear ist, kann es bei zu vielen Regeln zu einer Verzögerung bei der Prüfung kommen.

Ist die Anzahl der APIs begrenzt, die mit dieser Methode unterstützt werden können?

A: Nein, aber wir beschränken den Umfang auf APIs des Mobilfunkanbieters.

Gibt es APIs, für die diese Methode nicht zulässig ist? Wenn ja, wie setzen Sie sie durch? Gibt es also Tests, um zu prüfen, welche APIs von dieser Methode unterstützt werden?

A: Im Abschnitt API-Verhaltenskompatibilität des Android Compatibility Definition Document (CDD) Wir führen einige CTS-Tests durch, um sicherzustellen, dass sich das Berechtigungsmodell der APIs nicht ändert.

Wie funktioniert das mit der Multi-SIM-Funktion?

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

Wird diese Technologie in irgendeiner Weise mit anderen Technologien für den SE-Zugriff wie SEEK interagieren oder sich mit ihnen überschneiden?

A: SEEK verwendet beispielsweise dieselbe AID wie auf der UICC. Die Regeln existieren also nebeneinander und werden entweder nach SEEK oder UiccCarrierPrivileges gefiltert.

Wann solltest du die Berechtigungen des Mobilfunkanbieters prüfen?

A: Nach der Übertragung des SIM-Status-Ladevorgangs

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

A: Nein. Wir sind der Meinung, dass die aktuellen APIs die minimale Anzahl sind. Wir planen, die Bitmaske in Zukunft für eine genauere Kontrolle zu verwenden.

Überschreibt setOperatorBrandOverride ALLE anderen Formen von Operatornamen-Strings? Beispielsweise SE13, UICC-SPN oder netzwerkbasierte NITZ?

Ja, die Überschreibung der Marken des Mobilfunkanbieters hat die höchste Priorität. Wenn diese Option festgelegt ist, werden ALLE anderen Formen von Operatornamen-Strings überschrieben.

Was bewirkt der Aufruf der Methode injectSmsPdu?

A: Diese Methode erleichtert das Sichern und Wiederherstellen von SMS in der Cloud. Mit dem injectSmsPdu-Aufruf wird die Wiederherstellungsfunktion aktiviert.

Basiert der onFilterSms-Aufruf bei der SMS-Filterung auf der SMS-UDH-Portfilterung? Oder haben Mobilfunkanbieter-Apps Zugriff auf ALLE eingehenden SMS?

A: Mobilfunkanbieter haben Zugriff auf alle SMS-Daten.

Die Erweiterung von DeviceAppID-REF-DO auf 32 Byte ist anscheinend nicht mit der aktuellen GP-Spezifikation kompatibel (die nur 0 oder 20 Byte zulässt). Warum führen Sie diese Änderung ein? Reicht SHA-1 nicht aus, um Kollisionen zu vermeiden? Haben Sie diese Änderung bereits an GP vorgeschlagen, da sie nicht abwärtskompatibel mit vorhandenen ARA-M/ARF-Dateien sein könnte?

A: Für zukunftssichere Sicherheit wird mit dieser Erweiterung SHA-256 für DeviceAppID-REF-DO zusätzlich zu SHA-1 eingeführt, was derzeit die einzige Option im GP SEAC-Standard ist. Wir empfehlen dringend, SHA-256 zu verwenden.

Wird die Regel angewendet, wenn DeviceAppID den Wert 0 (leer) hat, auf alle Geräte-Apps, die nicht durch eine bestimmte Regel abgedeckt sind?

A: Für Mobilfunkanbieter-APIs muss DeviceAppID-REF-DO ausgefüllt sein. Eine leere Datei ist für Testzwecke vorgesehen und wird für Produktionsumgebungen nicht empfohlen.

Gemäß deiner Spezifikation sollte PKG-REF-DO, die nur allein ohne DeviceAppID-REF-DO verwendet wird, nicht akzeptiert werden. In Tabelle 6-4 der Spezifikation wird es jedoch weiterhin als Erweiterung der Definition von REF-DO beschrieben. Ist das beabsichtigt? 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 verwenden, wurde in der neuesten Version entfernt. PKG-REF-DO sollte nur in Kombination mit DeviceAppID-REF-DO vorkommen.

Wir gehen davon aus, dass wir Zugriff auf alle anbieterbasierten Berechtigungen gewähren oder eine detailliertere Kontrolle haben können. Wenn ja, was definiert die Zuordnung zwischen der Bitmaske und den tatsächlichen Berechtigungen? Eine Berechtigung pro Kurs? Eine Berechtigung pro Methode? Reicht es auf lange Sicht 64 separate Berechtigungen aus?

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

Kannst du DeviceAppID speziell für Android definieren? Dies ist der SHA-1-Hashwert (20 Byte) des Publisher-Zertifikats, das zum Signieren der jeweiligen Anwendung verwendet wurde. 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 Publisher-Zertifikat signiert sind.)

A: Das Speichern von DeviceAppID-Zertifikaten wird von der bestehenden Spezifikation unterstützt. Wir haben versucht, die Änderungen an der Spezifikation zu minimieren, um die Akzeptanz zu erhöhen. Weitere Informationen findest du unter Regeln auf UICC.