UICC-Anbieterberechtigungen

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, wodurch die Anzahl der Mobilfunkanbieter, die die APIs verwenden können, erheblich gestiegen ist. Eine API-Referenz finden Sie unter CarrierConfigManager. Eine Anleitung findest du unter Mobilfunkanbieterkonfiguration.

Da Mobilfunkanbieter die volle Kontrolle über die UICC haben, bietet dieser Mechanismus 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 dem UICC ist mit der GlobalPlatform-Spezifikation zur Zugriffssteuerung für Secure Elements 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.
    • In DeviceAppID-REF-DO (C1) wird die SHA-1-Signatur (20 Byte) oder SHA-256-Signatur (32 Byte) des Zertifikats gespeichert.
    • PKG-REF-DO (CA) ist der im Manifest definierte String mit dem vollständigen Paketnamen, ASCII-codiert, maximal 127 Byte lang.
  • AR-DO (E3) wird um PERM-AR-DO (DB) erweitert. Das ist 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

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

Die Android-Plattform versucht zuerst, die AID A00000015141434C00 der Zugriffsregelanwendung (Access Rule Application, ARA) auszuwählen. Wenn die AID nicht auf der UICC gefunden wird, wird ARF verwendet und PKCS15-AID A000000063504B43532D3135 wird ausgewählt. Android liest dann die Datei mit den Zugriffskontrollregeln (Access Control Rules File, 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 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

Beispiel für den Inhalt 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 aufrufende 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 Konnektivitä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-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
  • So laden Sie empfangene MMS herunter: onDownloadMms

CarrierService

Dienst, der anbieterspezifische Funktionen für das System bereitstellt. Wenn Sie diese Klasse erweitern möchten, deklarieren Sie den Dienst in der Manifestdatei der App mit der Berechtigung android.Manifest.permission#BIND_CARRIER_SERVICES und fügen Sie einen Intent-Filter mit der Aktion CARRIER_SERVICE_INTERFACE hinzu. 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 eher aktiv, 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 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 bevorstehende Änderung des Mobilfunknetzwerks durch die Mobilfunkanbieter-App: notifyCarrierNetworkChange

Telefonanbieter

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

WifiNetworkSuggestion

Wenn du ein WifiNetworkSuggestion-Objekt erstellst, kannst du mit den folgenden Methoden eine Abo-ID oder eine Abogruppe festlegen:

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, analysiert sie von der UICC-Karte und speichert sie im Arbeitsspeicher. 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. Bitten Sie den SIM-Kartenanbieter Ihrer Wahl, eine Entwickler-UICC mit der richtigen ARF wie in diesem Abschnitt beschrieben vorzubereiten und die Tests mit dieser UICC durchzuführen. 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.

Um CTS-Mobilfunkanbieter-API-Tests in Android 12 auszuführen, muss auf dem Gerät eine SIM-Karte mit CTS-Mobilfunkanbieterberechtigungen verwendet werden, die den Anforderungen der aktuellen Version der Drittanbieterspezifikation GSMA TS.48 Test Profile entsprechen.

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

CTS-SIM-Profil ändern

  1. Hinzufügen:CTS-Mobilfunkanbieterberechtigungen in den Zugriffsregel-App-Master (ARA-M) oder die ARF. Beide Signaturen müssen in den Berechtigungsregeln für Mobilfunkanbieter 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-Diensttabelle: Dienste 47 und 48 aktivieren
    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 werden 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 Tests der Mobilfunkanbieter-API 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 vorhandenen Mechanismus für Over-the-air-Kartenupdates verwenden

Können UICC-Regeln 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 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 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.

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

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

Gibt es APIs, für die diese Methode nicht zulässig ist? Wenn ja, wie setzen Sie sie durch? (d. h., haben Sie Tests, um zu prüfen, welche APIs mit 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 das Berechtigungsmodell der APIs nicht geändert wird.

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 koexistieren also und werden entweder durch SEEK oder UiccCarrierPrivileges gefiltert.

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

A: Nach der Übertragung des SIM-Status

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: Mit dieser Methode können SMS in der Cloud gesichert und wiederhergestellt werden. 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: Diese Erweiterung führt SHA-256 für DeviceAppID-REF-DO zusätzlich zu SHA-1 ein, was derzeit die einzige Option im GP SEAC-Standard ist. So wird eine zukunftssichere Sicherheit gewährleistet. Wir empfehlen dringend die Verwendung von SHA-256.

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äß Ihrer Spezifikation sollte PKG-REF-DO nicht ohne DeviceAppID-REF-DO verwendet werden. In Tabelle 6-4 der Spezifikation wird sie 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? Reichen 64 separate Berechtigungen auf Dauer aus?

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

Können Sie DeviceAppID für Android genauer definieren? Dies ist der SHA-1-Hashwert (20 Byte) des Publisher-Zertifikats, mit dem die betreffende App signiert wurde. Sollte der Name nicht diesen Zweck widerspiegeln? Der Name kann für viele Leser verwirrend sein, da die Regel dann auf alle Apps angewendet wird, 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 finden Sie unter Regeln für UICC.