UICC-Beförderungsrechte

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 Card Over-the-Air (OTA)-Updates 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 (ARF).

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

Die Android-Plattform versucht zuerst, die Anwendungskennung (AID) A00000015141434C00 des Zugriffsregel-Applets (ARA) auszuwählen. 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

SMSManager

Methode, um dem Anrufer zu ermöglichen, neue eingehende SMS-Nachrichten zu erstellen: injectSmsPdu .

CarrierConfigManager

Methode zum Benachrichtigen der geänderten Konfiguration: notifyConfigChangedForSubId . Anweisungen finden Sie unter Trägerkonfiguration .

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:

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 Telefonie- API-Referenz auf developer.android.com.

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. Sie können den SIM-Kartenanbieter Ihrer Wahl bitten, eine Entwickler-UICC mit dem richtigen ARF wie in diesem Abschnitt beschrieben vorzubereiten und diese UICC zum Ausführen der Tests zu verwenden. Die UICC erfordert keinen aktiven Mobilfunkdienst, um CTS-Tests zu bestehen.

Vorbereitung der UICC

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 dem Hashwert cts-uicc-2021-testkey 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-Betreiberprivilegien 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 Privileges in 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
  1. Erstellen : ADF USIM 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), Datensatzgröße: 4, Datensatznummer: 1
      • Inhalt: Rec1: 01010101
        1. EF_MWIS (6FCA), Datensatzgröße: 5, Datensatznummer: 1
      • Inhalt: 0000000000
  2. Ändern: USIM-Diensttabelle: Dienste Nr. 47, Nr. 48 aktivieren
    1. EF_UST (6F38)
      • Inhalt: 9EFFBF1DFFFE0083410310010400406E01
  3. Ä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
  4. Modify : Carrier Name-Strings müssen Android CTS in den jeweiligen EFs sein, 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 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 existieren also nebeneinander 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?

A: Siehe den SPN-Eintrag in TelephonyManager

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 in Tabelle 6-4 immer noch 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 .