Google 致力于为黑人社区推动种族平等。查看具体举措
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

UICC-Trägerrechte

Mit Android 5.1 wurde ein Mechanismus eingeführt, mit dem APIs, die für Besitzer von UICC-Apps (Universal Integrated Circuit Card) relevant sind, besondere Berechtigungen gewährt werden. Die Android-Plattform lädt auf einer UICC gespeicherte Zertifikate und erteilt Apps, die mit diesen Zertifikaten signiert sind, die Berechtigung, eine Handvoll spezieller APIs aufzurufen.

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

Carrier haben die volle Kontrolle über die UICC, sodass dieser Mechanismus eine sichere und flexible Möglichkeit bietet, Apps des Mobilfunknetzbetreibers (MNO) zu verwalten, die auf generischen App-Vertriebskanälen (wie Google Play) gehostet werden, während spezielle Berechtigungen auf Geräten und ohne Notwendigkeit beibehalten werden um Apps mit dem Plattformzertifikat pro Gerät zu signieren oder als System-App vorinstallieren.

Regeln zur UICC

Der Speicher auf der UICC ist mit der GlobalPlatform Secure Element Access Control-Spezifikation kompatibel. Die Anwendungskennung (AID) auf der Karte lautet A00000015141434C00 , und der Standardbefehl GET DATA wird zum Abrufen der auf der Karte gespeicherten Regeln verwendet. Sie können diese Regeln durch OTA-Updates (Card Over-the-Air) aktualisieren.

Datenhierarchie

UICC-Regeln verwenden die folgende Datenhierarchie (die zweistellige Buchstaben- und Zahlenkombination 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 SHA-256-Signatur (32 Byte) des Zertifikats.
    • PKG-REF-DO ( CA ) ist die vollständige Paketnamenzeichenfolge, die im Manifest definiert ist, ASCII-codiert, maximale Länge 127 Byte.
  • AR-DO ( E3 ) wird um PERM-AR-DO ( DB ) erweitert, eine 8-Byte-Bitmaske, die 64 separate Berechtigungen darstellt.

Wenn PKG-REF-DO nicht vorhanden ist, wird jeder vom 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 hexadezimaler Zeichenfolge 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 bietet Unterstützung für das Lesen von Trägerberechtigungsregeln aus der Zugriffsregeldatei (ARF).

Die Android-Plattform versucht zunächst, die ARA-Anwendungskennung (AID) A00000015141434C00 . Wenn die AID auf der UICC nicht gefunden wird, wird durch Auswahl von PKCS15 AID A000000063504B43532D3135 auf ARF A000000063504B43532D3135 . Android liest dann die Datei mit den Zugriffssteuerungsregeln (ACRF) um 0x4300 und sucht nach Einträgen mit AID FFFFFFFFFFFF . Einträge mit unterschiedlichen AIDs werden ignoriert, sodass Regeln für andere Anwendungsfälle nebeneinander existieren können.

Beispiel für einen ACRF-Inhalt in einer Hex-Zeichenfolge:

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

Beispiel für einen Inhalt der ACCF-Datei (Access Control Conditions File):

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 . Mit diesem Zertifikat signierte Apps erhalten Netzbetreiberrechte.

Aktivierte APIs

Android unterstützt die folgenden APIs.

Telefonie-Manager

SmsManager

Methode, mit der der Anrufer neue eingehende SMS-Nachrichten erstellen kann: injectSmsPdu .

CarrierConfigManager

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

CarrierMessagingService

Dienst, 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_SERVICE und #SERVICE_INTERFACE Aktion #SERVICE_INTERFACE einen Absichtsfilter #SERVICE_INTERFACE . Methoden umfassen:

Telefonieanbieter

Inhaltsanbieter-APIs, um Änderungen (Einfügen, Löschen, Aktualisieren, Abfragen) an der Telefoniedatenbank zu ermöglichen. Wertefelder werden bei Telephony.Carriers definiert. Weitere Informationen finden Sie in der Telefonie- API-Referenz auf developer.android.com.

Android-Plattform

Auf einer erkannten UICC erstellt die Plattform interne UICC-Objekte, die Trägerberechtigungsregeln als Teil der UICC enthalten. UiccCarrierPrivilegeRules.java lädt Regeln, analysiert sie von der UICC-Karte und speichert sie im Speicher zwischen. Wenn eine Berechtigungsprüfung erforderlich ist, vergleicht UiccCarrierPrivilegeRules das UiccCarrierPrivilegeRules mit seinen eigenen Regeln. Wenn die UICC entfernt wird, werden die Regeln zusammen mit dem UICC-Objekt zerstört.

Validierung

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

UICC vorbereiten

Standardmäßig ist CtsCarrierApiTestCases.apk vom Android-Entwicklerschlüssel mit dem Hashwert 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 . Die Tests drucken auch den erwarteten Zertifikat-Hash aus, wenn Zertifikate nicht mit UICC übereinstimmen.

Beispielausgabe:

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

Um die Implementierung über CTS mithilfe von CtsCarrierApiTestCases.apk zu validieren, CtsCarrierApiTestCases.apk Sie eine Entwickler-UICC mit den richtigen UICC-Regeln oder ARF-Unterstützung. Sie können den SIM-Kartenhersteller Ihrer Wahl bitten, eine Entwickler-UICC mit dem richtigen ARF vorzubereiten, wie in diesem Abschnitt beschrieben, und diese UICC zum Ausführen der Tests zu verwenden. Die UICC benötigt keinen aktiven Mobilfunkdienst, um CTS-Tests zu bestehen.

Ausführen von Tests

Der Einfachheit halber unterstützt CTS ein Geräte-Token, das die Ausführung von Tests auf Geräten einschränkt, die mit demselben Token konfiguriert sind. Carrier API CTS-Tests unterstützen die Geräte-Token- sim-card-with-certs . Das folgende Geräte-Token beschränkt beispielsweise die Ausführung von Carrier-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äte-Tokens 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 vorhandenen OTA-Aktualisierungsmechanismus für Karten.

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 auf den darauf befindlichen Zertifikaten basiert?

A: Die App verliert ihre Berechtigungen, da die mit der UICC verknüpften Regeln beim Entfernen der UICC zerstört werden.

Gibt es eine Begrenzung für die Anzahl der Zertifikate auf der UICC?

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 für die Prüfung kommen.

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 Umfang 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 überprüfen, welche APIs mit dieser Methode unterstützt werden?)

A: Siehe den Abschnitt "API Behavioral Compatibility" im 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, beispielsweise SEEK?

A: Als Beispiel verwendet SEEK dieselbe AID wie auf der UICC. Die Regeln existieren also nebeneinander und werden entweder von SEEK oder UiccCarrierPrivileges gefiltert.

Wann ist ein guter Zeitpunkt, um die Netzbetreiberrechte zu überprüfen?

A: Nachdem der SIM-Status die Sendung geladen hat.

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

A: Nein. Wir glauben, dass die aktuellen APIs die minimale Menge sind, und wir planen, die Bitmaske in Zukunft für eine feinere Granularitätskontrolle zu verwenden.

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

A: Siehe SPN-Eintrag in TelephonyManager

Was macht der Methodenaufruf injectSmsPdu ?

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

onFilterSms der onFilterSms Aufruf für die SMS-Filterung auf der SMS-UDH- onFilterSms ? Oder haben Carrier-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 nicht mit der aktuellen GP-Spezifikation kompatibel zu sein (die nur 0 oder 20 Bytes zulässt). Warum führen Sie diese Änderung ein? Reicht SHA-1 nicht aus, um Kollisionen zu vermeiden? Haben Sie diese Änderung bereits GP vorgeschlagen, da diese möglicherweise nicht mit dem vorhandenen ARA-M / ARF kompatibel ist?

A: Um zukunftssichere Sicherheit zu bieten, wird mit dieser Erweiterung zusätzlich zu SHA-1 SHA-256 für DeviceAppID-REF-DO , das derzeit die einzige Option im GP SEAC-Standard ist. Wir empfehlen 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 werden?

A: Für Carrier-APIs muss DeviceAppID-REF-DO sein. Leer zu sein ist für Testzwecke gedacht und wird für betriebliche Bereitstellungen nicht empfohlen.

Gemäß Ihrer Spezifikation sollte PKG-REF-DO das allein ohne DeviceAppID-REF-DO , nicht akzeptiert werden. In Tabelle 6-4 wird die Definition von REF-DO . Ist das absichtlich? 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 wurde in der neuesten Version entfernt. PKG-REF-DO sollte nur in Kombination mit DeviceAppID-REF-DO .

Wir gehen davon aus, dass wir Zugriff auf alle Carrier-basierten Berechtigungen gewähren oder eine genauere Kontrolle haben können. Wenn ja, was definiert die Zuordnung zwischen der Bitmaske und den tatsächlichen Berechtigungen? Eine Erlaubnis pro Klasse? Eine Erlaubnis pro Methode? Reichen auf lange Sicht 64 separate Berechtigungen aus?

A: Dies ist für die Zukunft reserviert 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 angegebene App signiert wurde. Sollte der Name also nicht diesen Zweck widerspiegeln? (Der Name kann 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 Speichern von Zertifikaten wird von der vorhandenen Spezifikation unterstützt. Wir haben versucht, Spezifikationsänderungen zu minimieren, um die Barriere für die Übernahme zu senken. Weitere Informationen finden Sie unter Regeln für UICC .