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 erteilt 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-Carrier-Berechtigungsregeln zu unterstützen. Dadurch hat sich die Anzahl der Carrier, 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. Dabei werden spezielle Berechtigungen auf Geräten beibehalten und Apps müssen nicht mit dem gerätespezifischen Plattformzertifikat signiert oder als System-App vorinstalliert werden.

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 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) der Karte 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. Er ist 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 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 wurde die Unterstützung für das Lesen von Regeln für Mobilfunkanbieterberechtigungen aus der Zugriffsregeldatei (Access Rule File, ARF) hinzugefügt.

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 Zugriffssteuerungsregeln (ACRF) unter 0x4300 und sucht nach Einträgen mit der AID FFFFFFFFFFFF. Einträge mit unterschiedlichen AIDs werden ignoriert, sodass Regeln für andere Anwendungsfälle vorhanden sein können.

Beispiel für ACRF-Inhalte im 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 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.

Build

So ermitteln Sie die Seriennummer der Hardware (falls verfügbar): getSerial

BugreportManager

Methode zum Starten eines Fehlerberichts zur Konnektivität, einer speziellen Version des Fehlerberichts, die nur Informationen zur Fehlerbehebung bei Problemen 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-Nachrichten, 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.

Validierung

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-Testprofilspezifikation eines Drittanbieters mit einem festen ADM1, key = 55555555 / 0x3535353535353535 entspricht.

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

CTS-SIM-Profil ändern

  1. Hinzufügen:CTS-Betreiberberechtigungen in ARA-M (Access Rule App Master) oder ARF (Access Rule File). Beide Signaturen müssen in den Regeln für Transportunternehmen-Berechtigungen 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 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 47 und 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 Transportunternehmens 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 Gerätetoken ausführen, wird er auf allen Geräten ausgeführt.

FAQ

Wie können Zertifikate auf der UICC aktualisiert werden?

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

Kann UICC mit anderen Regeln kombiniert 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, 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 Technologien für den Zugriff auf das sichere Element, z. B. SEEK?

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

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

A: Nach dem Broadcast des geladenen 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 Marke durch den Betreiber hat die höchste Priorität. Wenn er festgelegt ist, werden ALLE anderen Formen von Betreibernamen-Strings überschrieben.

Was bewirkt der Methodenaufruf injectSmsPdu?

A: Diese Methode ermöglicht 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 zusätzlich zu SHA-1, das derzeit die einzige Option im GP SEAC-Standard ist, SHA-256 für DeviceAppID-REF-DO eingeführt. 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. Das Feld ist für Testzwecke leer 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 weiterhin in Tabelle 6-4 der Spezifikation als Erweiterung der Definition von REF-DO beschrieben. Ist das Absicht? Wie verhält sich der Code, wenn nur PKG-REF-DO in 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 Kontrolle haben. 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 Publisher-Zertifikats, mit dem die angegebene App signiert wurde. Sollte der Name 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: 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.