UICC Carrier Privileges

Android 5.1 führte einen Mechanismus ein, um spezielle Privilegien für APIs zu gewähren, die für die Besitzer von Universal Integrated Circuit Card (UICC) Apps relevant sind. DieAndroid-Plattform lädt Zertifikate, die auf einer UICC gespeichert sind, und gewährt von diesen Zertifikaten signierten Apps die Erlaubnis, eine Handvoll spezieller APIs aufzurufen.

Android 7.0 hat diese Funktion erweitert, um andere Speicherquellen für UICC-Trägerprivilegierungsregeln zu unterstützen, wodurch sich die Anzahl der Träger, die die APIs verwenden können, drastisch erhöht hat. Eine API-Referenz finden Sie unter CarrierConfigManager; Anweisungen finden Sie unter CarrierConfiguration.

Betreiber haben die volle Kontrolle über die UICC, so dass dieser Mechanismus eine sichere und flexible Möglichkeit bietet, Apps des Mobilfunkbetreibers (MNO) zu verwalten, die auf allgemeinen App-Vertriebskanälen (wie Google Play) gehostet werden, während spezielle Privilegien auf Geräten beibehalten werden und Apps nicht mit dem Plattformzertifikat pro Gerät signiert oder als System-App vorinstalliert werden müssen.

Regeln auf der UICC

Die Speicherung auf der UICC ist mit der GlobalPlatformSecure Element Access Control Spezifikation kompatibel. Die Anwendungskennung (AID) auf der Karte lautet A00000015141434C00, und der StandardbefehlGET DATA wird verwendet, um die auf der Karte gespeicherten Regeln abzurufen. Sie können diese Regeln durch Over-the-Air (OTA)-Updates der Karte aktualisieren.

Datenhierarchie

UICC-Regeln verwenden die folgende Datenhierarchie (die zweistellige Buchstaben- und Zahlenkombination in Klammern ist das Objekt-Tag). Jede Regel istREF-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 Byte) oder SHA-256 (32 Byte) Signatur des Zertifikats.
  • PKG-REF-DO (CA) ist die im Manifest definierte vollständige Zeichenfolge des Paketnamens, ASCII-kodiert, maximale Länge 127 Bytes.
• AR-DO (E3) wird um PERM-AR-DO (DB) erweitert, eine 8-Byte-Bit-Maske, die 64 separate Berechtigungen repräsentiert.

Wenn PKG-REF-DO nicht vorhanden ist, wird jeder mit dem Zertifikat signierten Anwendung Zugriff gewährt; andernfalls müssen sowohl das Zertifikat als auch der Paketname übereinstimmen.

Regelbeispiel

Der App-Name ist com.google.android.apps.myapp und dasSHA-1-Zertifikat in der Hex-Zeichenkette ist:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

Die Regel auf der UICC in der Hex-Zeichenkette ist:

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

Unterstützung der Zugriffsregeldatei (ARF)

Android 7.0 fügt Unterstützung für das Lesen von Carrier-Privilege-Regeln aus der Zugriffsregel-Datei (ARF) hinzu.

Die Android-Plattform versucht zunächst, das Zugriffsregel-Applet (ARA)-Anwendungskennzeichen (AID) A00000015141434C00 auszuwählen. Wenn sie die AID auf der UICC nicht findet, greift sie auf ARF zurück, indem sie PKCS15 AIDA000000063504B43532D3135 auswählt. Android liest dann die Zugriffskontrollregeldatei (ACRF) unter 0x4300 und sucht nach Einträgen mit der AID FFFFFFFFFFFF. Einträge mit anderen AIDs werden ignoriert, sorules für andere Anwendungsfälle können nebeneinander bestehen.

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 Zugriffskontrollbedingungsdatei (ACCF) Inhalt:

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 Zertifikathash61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 enthält. Apps, die von diesem Zertifikat signiert sind, erhalten Trägerprivilegien.

Aktivierte APIs

Android unterstützt die folgenden APIs.

TelephonyManager

• Methode, die es der Träger-App ermöglicht, die UICC um eine Herausforderung/Antwort zu bitten:getIccAuthentication.
• Methode, die überprüft, ob der aufrufenden App Trägerprivilegien gewährt wurden:hasCarrierPrivileges.
• Methoden zum Überschreiben von Marke und Nummer:
  • setOperatorBrandOverride
  • setLine1NumberForDisplay
  • setVoiceMailNumber
• Methoden für direkte UICC-Kommunikation:
  • iccOpenLogicalChannel
  • iccCloseLogicalChannel
  • iccExchangeSimIO
  • iccTransmitApduLogicalChannel
  • iccTransmitApduBasicChannel
  • sendEnvelopeWithStatus
• Methoden zum Setzen des Gerätemodus auf global:setPreferredNetworkTypeToGlobal.

SmsManager

Methode, um dem Anrufer zu erlauben, neue eingehende SMS-Nachrichten zu erstellen: injectSmsPdu.

CarrierConfigManager

Methode um Konfigurationsänderungen zu melden: notifyConfigChangedForSubId. Anweisungen finden Sie unterTrägerkonfiguration.

CarrierMessagingService

Service, der Anrufe vom System empfängt, 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_SERVICEErlaubnis und schließen Sie einen Absichtsfilter mit der #SERVICE_INTERFACEAktion ein. Die Methoden umfassen:

• onFilterSms
• onSendTextSms
• onSendDataSms
• onSendMultipartTextSms
• onSendMms
• onDownloadMms

Telefonieanbieter

Content-Provider-APIs, um Änderungen (Einfügen, Löschen, Aktualisieren, Abfragen) an der Telefoniedatenbank zu ermöglichen. Wertefelder sind definiert unterTelephony.Carriers; für weitere Details siehe Telefonie-API-Referenz auf developer.android.com.

Android-Plattform

Auf einer erkannten UICC konstruiert die Plattform interne UICC-Objekte, die Carrier-Privilege-Regeln als Teil der UICC enthalten.UiccCarrierPrivilegeRules.javaLädt Regeln, parst sie von der UICC-Karte und speichert sie im Speicher. Wenn eine Berechtigungsprüfung erforderlich ist, vergleicht UiccCarrierPrivilegeRules das Anruferzertifikat mit seinen eigenen Regeln, eine nach der anderen. Wenn die UICC entfernt wird, werden die Regeln zusammen mit dem UICC-Objekt zerstört.

Validierung

Die Compatibility Test Suite (CTS) umfasst Tests für Carrier-APIs inCtsCarrierApiTestCases.apk. Da diese Funktion von Zertifikaten auf der UICC abhängt, müssen Sie die UICC vorbereiten, um diese Tests zu bestehen.

Vorbereiten der UICC

Standardmäßig ist CtsCarrierApiTestCases.apk mit dem Androiddeveloper-Schlüssel signiert, mit dem Hash-Wert61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Die Tests geben auch den erwarteten Zertifikatshash aus, wenn die Zertifikate auf der UICC nicht übereinstimmen.

Beispielausgabe:

junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81

Um die Implementierung durch CTS mit CtsCarrierApiTestCases.apk zu validieren, müssen Sie eine Entwickler-UICC mit den richtigen UICC-Regeln oder ARF-Unterstützung haben. Sie können den SIM-Kartenhersteller Ihrer Wahl bitten, eine Entwickler-UICC mit der richtigen ARF, wie in diesem Abschnitt beschrieben, vorzubereiten und diese UICC zur Durchführung der Tests zu verwenden. Die UICC benötigt keinen aktiven Mobilfunkdienst, um die CTS-Tests zu bestehen.

Ausführung von Tests

Zur Vereinfachung unterstützt CTS ein Gerätetoken, das die Ausführung von Tests auf Geräte beschränkt, die mit demselben Token konfiguriert sind. Carrier API CTS-Tests unterstützen das Gerätetoken sim-card-with-certs. Mit dem folgenden Gerätetoken werden Carrier-API-Tests beispielsweise nur auf dem Gerät abcd1234 ausgeführt:

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

Wenn ein Test ohne Gerätetoken ausgeführt wird, läuft der Test auf allen Geräten.

FAQ

Wie können Zertifikate auf der UICC aktualisiert werden?

A: Verwenden Sie den vorhandenen OTA-Aktualisierungsmechanismus der Karte.

Kann die 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 Anwendung entfernt wird, die sich auf die darauf befindlichen Zertifikate verlässt?

A: Die Anwendung verliert ihre Berechtigungen, da die mit der UICC verbundenen Regeln beim Entfernen der UICC zerstört werden.

Ist die Anzahl der Zertifikate auf der UICC begrenzt?

A: Die Plattform begrenzt die Anzahl der Zertifikate nicht; da die Prüfung jedoch linear ist, kann es bei zu vielen Regeln zu einer Latenz bei der Prüfung kommen.

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

A: Nein, aber wir beschränken den Anwendungsbereich auf betreiberbezogene APIs.

Gibt es einige APIs, die diese Methode nicht verwenden dürfen? Wenn ja, wie setzen Sie diese durch? (Das heißt, haben Sie Tests, um zu überprüfen, welche APIs mit dieser Methode unterstützt werden?)

A: Siehe den Abschnitt „API Behavioral Compatibility“ des Android Compatibility DefinitionDocument (CDD). Wir haben einige CTS-Tests, um sicherzustellen, dass das Berechtigungsmodell der APIs nicht geändert wird.

Wie funktioniert dies mit der Multi-SIM-Funktion?

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

Wirkt dies in irgendeiner Weise mit anderen SE-Zugangstechnologien zusammen oder überschneidet es sich mit ihnen, z. B. mit SEEK?

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

Wann ist es ein guter Zeitpunkt, die Carrier-Privilegien zu überprüfen?

A: Nachdem der SIM-Status übertragen wurde.

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

A: Nein. Wir glauben, dass die aktuellen APIs das Minimum sind, und wir planen, die Bitmaske für eine feinere Granularität in der Zukunft zu verwenden.

Setzt setOperatorBrandOverride ALLE anderen Formen von Operatornamen-Strings außer Kraft? Zum Beispiel SE13, UICC SPN oder netzwerkbasiertes NITZ?

A: Siehe den SPN-Eintrag inTelephonyManager

Was bewirkt der Methodenaufruf injectSmsPdu?

A: Diese Methode erleichtert die Sicherung/Wiederherstellung von SMS in der Cloud. Der Aufruf injectSmsPdu aktiviert die Wiederherstellungsfunktion.

Basiert der Aufruf onFilterSms für die SMS-Filterung auf der Filterung des SMS-UDH-Ports? Oder haben die Anwendungen der Netzbetreiber Zugriff auf ALLE eingehenden SMS?

A: Die Netzbetreiber haben Zugriff auf alle SMS-Daten.

Die Erweiterung von DeviceAppID-REF-DO auf die 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? Ist SHA-1 nicht ausreichend, um Kollisionen zu vermeiden? Haben Sie diese Änderung bereits für GP vorgeschlagen, da dies rückwärtskompatibel mit dem bestehenden ARA-M/ARF 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, gilt die Regel dann für alle Geräteanwendungen, die nicht von einer spezifischen Regel abgedeckt werden?

A: Carrier-APIs erfordern, dass DeviceAppID-REF-DO ausgefüllt wird. Die leere Angabe ist für Testzwecke gedacht und wird für betriebliche Implementierungen nicht empfohlen.

Nach Ihrer Spezifikation sollte PKG-REF-DO allein, ohne DeviceAppID-REF-DO, nicht akzeptiert werden. Dennoch wird es in Tabelle 6-4 als Erweiterung der Definition von REF-DO beschrieben. Ist dies beabsichtigt? Wie verhält sich der Code, wenn nur PKG-REF-DO in REF-DO verwendet wird?

A: Die Möglichkeit, PKG-REF-DO als einzelnes Wertelement in REF-DO zu haben, 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 trägerbasierten Berechtigungen gewähren können oder eine feinere Kontrolle haben. Wenn ja, wie wird die Zuordnung zwischen der Bitmaske und den tatsächlichen Berechtigungen definiert? Eine Berechtigung pro Klasse? Eine Berechtigung pro Methode? Sind 64 separate Berechtigungen auf lange Sicht ausreichend?

A: Dies ist für die Zukunft reserviert, und wir begrüßen Vorschläge.

Können Sie DeviceAppID für Android-spezifisch näher definieren? Dies ist der SHA-1 (20 Bytes) Hash-Wert des Publisher-Zertifikats, das zum Signieren der gegebenen 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 Publisher-Zertifikat signiert sind.)

A: Die DeviceAppID Speicherung von Zertifikaten wird von der bestehenden Spezifikation unterstützt. Wir haben versucht, die Änderungen an der Spezifikation zu minimieren, um die Hürde für die Einführung zu senken. Für Details siehe Regeln für UICC.