UICC-Anbieterberechtigungen

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

Mit Android 7.0 wurde diese Funktion erweitert, um andere Speicherquellen für UICC-Regeln für Betreibervorrechte zu unterstützen. Dadurch hat sich die Anzahl der Betreiber, die die APIs verwenden können, erheblich erhöht. Eine API-Referenz finden Sie unter CarrierConfigManager. Eine Anleitung finden Sie unter Carrier Configuration.

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 allgemeinen App-Vertriebskanälen wie Google Play gehostet werden. Gleichzeitig behalten sie spezielle Berechtigungen auf Geräten und müssen Apps nicht mit dem gerätespezifischen Plattformzertifikat signieren oder als System-App vorinstallieren.

Regeln für UICC

Der Speicher auf der UICC ist mit der GlobalPlatform Secure Element Access Control-Spezifikation kompatibel. Die Anwendungs-ID (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 (Over-the-Air) für Karten aktualisieren.

Datenhierarchie

Für UICC-Regeln wird die folgende Datenhierarchie verwendet (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-Signatur (20 Byte) oder die SHA-256-Signatur (32 Byte) des Zertifikats.
    • PKG-REF-DO (CA) ist der vollständige Paketnamensstring, der im Manifest definiert ist, ASCII-codiert, maximale Länge 127 Byte.
  • 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 mit dem Zertifikat signiert ist, 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 Hex-String lautet:

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

Unterstützung von Dateien mit Zugriffsregeln

Unter Android 7.0 wird das Lesen von Regeln für Betreiberberechtigungen aus der ARF-Datei (Access Rule File) unterstützt.

Die Android-Plattform versucht zuerst, die ARA-AID (Access Rule Application) A00000015141434C00 auszuwählen. Wenn die AID auf der UICC nicht gefunden wird, wird auf ARF zurückgegriffen, indem die PKCS15-AID A000000063504B43532D3135 ausgewählt wird. Android liest dann die Datei mit den Regeln für die Zugriffskontrolle (Access Control Rules File, ACRF) unter 0x4300 und sucht nach Einträgen mit der AID FFFFFFFFFFFF. Einträge mit anderen AIDs werden ignoriert, sodass Regeln für andere Anwendungsfälle nebeneinander bestehen können.

Beispiel für ACRF-Inhalte im Hexadezimalstring:

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

Beispiel für den Inhalt einer Datei mit Zugriffssteuerungsbedingungen (Access Control Conditions File, 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 Zertifikathash 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 für Mobilfunkanbieter.

Aktivierte APIs

Android unterstützt die folgenden APIs.

TelephonyManager

TelephonyCallback

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

SubscriptionManager

SmsManager

CarrierConfigManager

Eine Anleitung finden Sie unter Carrier Configuration.

BugreportManager

Methode zum Starten eines Fehlerberichts zur Konnektivität, einer speziellen Version des Fehlerberichts, die nur Informationen zur Behebung von Problemen im Zusammenhang mit der Konnektivität enthält: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

Methode zum Wechseln zum angegebenen Abo (Aktivieren des Abos): 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 ein. Folgende Methoden können dafür verwendet werden:

  • Methode zum Filtern eingehender SMS-Nachrichten: onFilterSms
  • Methode zum Abfangen von SMS, die vom Gerät gesendet werden: onSendTextSms
  • Methode zum Abfangen binärer SMS, die vom Gerät gesendet werden: onSendDataSms
  • Methode zum Abfangen langer SMS, die vom Gerät gesendet werden: onSendMultipartTextSms
  • Methode zum Abfangen von MMS-Nachrichten, die vom Gerät gesendet werden: onSendMms
  • So laden Sie empfangene MMS herunter: onDownloadMms

CarrierService

Dienst, der dem System anbieterspezifische Funktionen zur Verfügung stellt. Wenn Sie diese Klasse erweitern möchten, deklarieren Sie den Dienst in der App-Manifestdatei mit der Berechtigung android.Manifest.permission#BIND_CARRIER_SERVICES und fügen Sie einen Intent-Filter mit der Aktion CARRIER_SERVICE_INTERFACE ein. Wenn der Dienst eine langlebige Bindung hat, setzen Sie android.service.carrier.LONG_LIVED_BINDING in den Metadaten des Dienstes auf true.

Die Plattform bindet CarrierService mit speziellen Flags, damit der Prozess des Mobilfunkanbieterdienstes in einem speziellen App-Standby-Bucket ausgeführt werden kann. Dadurch wird die Carrier-Service-App von der Einschränkung für inaktive Apps ausgenommen und es ist wahrscheinlicher, dass sie aktiv bleibt, wenn der Gerätespeicher knapp ist. 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 Carrier Services App stabil ist.

Zu den Methoden in CarrierService gehören:

  • So überschreiben und legen Sie die anbieterspezifischen Konfigurationen fest: onLoadConfig
  • So informieren Sie das System über eine bevorstehende Änderung des Mobilfunknetzwerks durch die Mobilfunkanbieter-App: notifyCarrierNetworkChange

Telefonieanbieter

Contentanbieter-APIs, die Änderungen (Einfügen, Löschen, Aktualisieren, Abfragen) an der Telefoniedatenbank ermöglichen. Wertfelder werden unter Telephony.Carriers definiert. Weitere Informationen finden Sie in der Klassenreferenz für Telephony.

WifiNetworkSuggestion

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

Android-Plattform

Wenn eine UICC erkannt wird, erstellt die Plattform interne UICC-Objekte, die Betreiberberechtigungsregeln 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 Anruferzertifikat 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 über die Compatibility Test Suite (CTS) mit CtsCarrierApiTestCases.apk validieren möchten, benötigen Sie eine Entwickler-UICC mit den richtigen UICC-Regeln oder ARF-Unterstützung. Bitten Sie den SIM-Kartenanbieter Ihrer Wahl, eine Entwickler-UICC mit dem richtigen ARF vorzubereiten, wie in diesem Abschnitt beschrieben, und verwenden Sie diese UICC, um die Tests auszuführen. Für die UICC ist kein aktiver Mobilfunkdienst erforderlich, um CTS-Tests zu bestehen.

UICC vorbereiten

Bei Android 11 und niedriger ist CtsCarrierApiTestCases.apk von aosp-testkey signiert und hat den Hashwert 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81.

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.

Wenn Sie CTS Carrier API-Tests in Android 12 ausführen möchten, muss auf dem Gerät eine SIM-Karte mit CTS-Carrier-Berechtigungen verwendet werden, die den Anforderungen der neuesten Version der GSMA TS.48 Test Profile-Spezifikation von Drittanbietern entspricht.

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

CTS-SIM-Profil ändern

  1. Hinzufügen:CTS-Carrier-Berechtigungen in ARA-M (Access Rule App Master) oder ARF (Access Rule File). Beide Signaturen müssen in den Regeln für Transportunternehmenrechte codiert 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 
      • Inhalte
        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), Datensatzgröße: 4, Datensatznummer: 1
      • Inhalt: Rec1: 01010101
        1. EF_MWIS (6FCA), Datensatzgröße: 5, Datensatznummer: 1
      • Inhalt: 0000000000
  3. Ändern:USIM-Diensttabelle: Aktiviere die Dienste Nr. 47 und Nr. 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 für den Namen 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

Testprofilstruktur anpassen

Laden Sie die neueste Version der folgenden generischen Testprofilstrukturen herunter und passen Sie sie an. Diese Profile enthalten keine personalisierte CTS Carrier Privilege-Regel oder andere oben aufgeführte Änderungen.

Tests ausführen

Zur Vereinfachung unterstützt CTS ein Gerätetoken, mit dem Tests nur auf Geräten ausgeführt werden können, die mit demselben Token konfiguriert sind. CTS-Tests für Carrier APIs unterstützen das Gerätetoken sim-card-with-certs. Mit dem folgenden Gerätetoken werden beispielsweise Carrier-API-Tests auf das Gerät abcd1234 beschränkt:

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

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

Häufig gestellte Fragen

Wie können Zertifikate auf der UICC aktualisiert werden?

A: Verwenden Sie den vorhandenen OTA-Aktualisierungsmechanismus für Karten.

Kann die UICC-Regel mit anderen Regeln kombiniert werden?

A: Es ist in Ordnung, wenn auf der UICC unter derselben AID andere Sicherheitsregeln vorhanden sind. 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, weil die mit der UICC verknüpften Regeln beim Entfernen der UICC zerstört werden.

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

A: Die Plattform begrenzt die Anzahl der Zertifikate nicht. Da die Prüfung jedoch linear erfolgt, kann eine zu große Anzahl von Regeln zu einer Latenz bei der Prüfung führen.

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

A: Nein, aber wir beschränken den Umfang auf APIs, die mit Mobilfunkanbietern zusammenhängen.

Gibt es APIs, für die diese Methode nicht verwendet werden darf? Wenn ja, wie setzen Sie sie durch? (Haben Sie Tests, um zu prüfen, welche APIs mit dieser Methode unterstützt werden?)

A: Informationen dazu finden Sie im Abschnitt API Behavioral Compatibility des Android-Dokuments zur Kompatibilitätsdefinition (CDD). Wir haben einige CTS-Tests, um sicherzustellen, dass sich das Berechtigungsmodell der APIs nicht ändert.

Wie funktioniert das mit der Dual-SIM-Funktion?

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

Gibt es Überschneidungen oder Interaktionen mit anderen SE-Zugriffstechnologien wie SEEK?

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

Wann ist der richtige Zeitpunkt, um die Berechtigungen des Mobilfunkanbieters zu prüfen?

A: Nach dem Laden des SIM-Status.

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

A: Nein. Wir sind der Meinung, dass die aktuellen APIs die Mindestanforderungen erfüllen. Wir planen, die Bitmaske in Zukunft für eine genauere Steuerung zu verwenden.

Überschreibt setOperatorBrandOverride ALLE anderen Formen von Betreibernamen-Strings? Zum Beispiel SE13, UICC SPN oder netzwerkbasiertes NITZ?

Ja, die Überschreibung der Betreibermarke hat die höchste Priorität. Wenn er festgelegt ist, werden ALLE anderen Formen von Betreibernamen-Strings überschrieben.

Was bewirkt der Aufruf der Methode injectSmsPdu?

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

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

A: Mobilfunkanbieter haben Zugriff auf alle SMS-Daten.

Die Erweiterung von DeviceAppID-REF-DO zur Unterstützung von 32 Byte scheint nicht mit der aktuellen GP-Spezifikation kompatibel zu sein (die nur 0 oder 20 Byte zulässt). Warum führen Sie diese Änderung ein? Reicht SHA-1 nicht aus, um Kollisionen zu vermeiden? Hast du diese Änderung bereits GP vorgeschlagen, da sie möglicherweise nicht abwärtskompatibel mit bestehenden ARA-M/ARF ist?

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

Wenn DeviceAppID = 0 (leer) ist, wird die Regel dann auf alle Geräte-Apps angewendet, die nicht durch eine bestimmte Regel abgedeckt sind?

A: Für Carrier-APIs muss DeviceAppID-REF-DO ausgefüllt sein. Ein leerer Wert ist für Testzwecke vorgesehen und wird für operative Bereitstellungen nicht empfohlen.

Gemäß Ihrer Spezifikation sollte PKG-REF-DO allein ohne DeviceAppID-REF-DO nicht akzeptiert werden. Sie wird jedoch in Tabelle 6‑4 der Spezifikation weiterhin 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 einzelnes Wertelement in REF-DO zu verwenden, wurde in der neuesten Version entfernt. PKG-REF-DO sollte nur in Kombination mit DeviceAppID-REF-DO verwendet werden.

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

A: Das ist für die Zukunft reserviert. Wir freuen uns über Vorschläge.

Kannst du DeviceAppID für Android genauer definieren? Dies ist der SHA-1-Hashwert (20 Bytes) des Herausgeberzertifikats, mit dem die angegebene App signiert wurde. Sollte der Name das nicht 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: Die DeviceAppID-Speicherung von Zertifikaten wird von der bestehenden Spezifikation unterstützt. Wir haben versucht, die Spezifikationsänderungen zu minimieren, um die Akzeptanz zu erleichtern. Weitere Informationen finden Sie unter Regeln für UICC.