UICC-Beförderungsrechte

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

Android 7.0 hat diese Funktion erweitert, um andere Speicherquellen für UICC-Berechtigungsregeln für Netzbetreiber zu unterstützen, wodurch die Anzahl der Netzbetreiber, die die APIs verwenden können, drastisch erhöht wird. Eine API-Referenz finden Sie unter CarrierConfigManager ; Anweisungen finden Sie unter Carrier-Konfiguration .

Betreiber haben die volle Kontrolle über die UICC, daher bietet dieser Mechanismus eine sichere und flexible Möglichkeit, Apps vom Mobilfunknetzbetreiber (MNO) zu verwalten, die auf generischen App-Vertriebskanälen (wie Google Play) gehostet werden, während besondere Privilegien auf Geräten beibehalten werden und dies nicht erforderlich ist um Apps mit dem Plattformzertifikat pro Gerät zu signieren oder als System-App vorzuinstallieren.

Regeln zur UICC

Die Speicherung 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 verwendet, um auf der Karte gespeicherte Regeln abzurufen. Sie können diese Regeln durch Karten-Over-the-Air-Updates (OTA) aktualisieren.

Datenhierarchie

UICC-Regeln verwenden die folgende Datenhierarchie (die Kombination aus zwei Zeichen aus 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 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 durch das 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 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 in Hex-String lautet:

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

Unterstützung für Zugriffsregeldateien

Android 7.0 bietet Unterstützung für das Lesen von Betreiberprivilegienregeln aus der Zugriffsregeldatei (ARF).

Die Android-Plattform versucht zunächst, die Zugriffsregelanwendung (ARA) AID A00000015141434C00 auszuwählen. Wenn die AID nicht auf der UICC gefunden wird, greift sie auf ARF zurück, indem sie PKCS15 AID A000000063504B43532D3135 auswählt. Android liest dann die Zugriffskontrollregeldatei (ACRF) bei 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 bestehen 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

Beispielinhalt 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 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 Trägerrechte.

Aktivierte APIs

Android unterstützt die folgenden APIs.

TelefonieManager

TelefonieRückruf

TelephonyCallback verfügt über Schnittstellen mit einer Rückrufmethode, um die anrufende App zu benachrichtigen, wenn sich die registrierten Zustände ändern:

Abonnement-Manager

SMSManager

CarrierConfigManager

  • Methode zur Benachrichtigung geänderter Konfiguration: notifyConfigChangedForSubId .
  • Methode zum Abrufen der Netzbetreiberkonfiguration für das Standardabonnement: getConfig
  • Methode zum Abrufen der Netzbetreiberkonfiguration für das angegebene Abonnement: getConfigForSubId

Anweisungen finden Sie unter Carrier-Konfiguration .

BugreportManager

Methode zum Starten eines Konnektivitätsfehlerberichts, einer speziellen Version des Fehlerberichts, die nur Informationen zum Debuggen von Konnektivitätsproblemen enthält: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

EuiccManager

Methode zum Wechseln (Aktivieren) des angegebenen Abonnements: switchToSubscription

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 Berechtigung android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE und fügen Sie einen Absichtsfilter mit der Aktion #SERVICE_INTERFACE hinzu. Zu den Methoden gehören:

  • Methode zum Filtern eingehender SMS-Nachrichten: onFilterSms
  • Methode zum Abfangen von vom Gerät gesendeten Text-SMS-Nachrichten: onSendTextSms
  • Methode zum Abfangen binärer 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 vom Gerät gesendeten MMS-Nachrichten: onSendMms
  • Methode zum Herunterladen empfangener MMS-Nachrichten: onDownloadMms

CarrierService

Dienst, der dem System betreiberspezifische Funktionalitäten zur Verfügung stellt. Um diese Klasse zu erweitern, deklarieren Sie den Dienst in der App-Manifestdatei mit der Berechtigung android.Manifest.permission#BIND_CARRIER_SERVICES und fügen Sie einen Absichtsfilter mit der Aktion CARRIER_SERVICE_INTERFACE hinzu. Wenn der Dienst über eine langlebige Bindung verfügt, setzen Sie android.service.carrier.LONG_LIVED_BINDING in den Metadaten des Dienstes auf true .

Die Plattform bindet CarrierService mit speziellen Flags, damit der Carrier-Service-Prozess in einem speziellen App-Standby-Bucket ausgeführt werden kann. Dies befreit die Carrier-Service-App von der App-Leerlaufbeschränkung und erhöht die Wahrscheinlichkeit, dass sie aktiv bleibt, wenn der Gerätespeicher knapp wird. Wenn die Carrier-Service-App 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, die Netzbetreiber-Service-App stabil zu halten.

Zu den Methoden in CarrierService gehören:

  • Um die betreiberspezifischen Konfigurationen zu überschreiben und festzulegen: onLoadConfig
  • Um das System über eine beabsichtigte bevorstehende Änderung des Netzbetreibernetzwerks durch die Netzbetreiberanwendung zu informieren: notifyCarrierNetworkChange

Telefonanbieter

Inhaltsanbieter-APIs, um Änderungen (Einfügen, Löschen, Aktualisieren, Abfragen) an der Telefoniedatenbank zu ermöglichen. Wertefelder werden unter Telephony.Carriers definiert; Weitere Einzelheiten finden Sie in der Referenz zur Telephony

WifiNetworkSuggestion

Verwenden Sie beim Erstellen eines WifiNetworkSuggestion Objekts die folgenden Methoden, um eine Abonnement-ID oder eine Abonnementgruppe festzulegen:

Android-Plattform

Auf einer erkannten UICC erstellt die Plattform interne UICC-Objekte, die Betreiberprivilegierungsregeln 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 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, 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 diese UICC zum Ausführen der Tests zu verwenden. Die UICC erfordert keinen aktiven Mobilfunkdienst, um CTS-Tests zu bestehen.

Bereiten Sie die UICC vor

Für Android 11 und niedriger ist CtsCarrierApiTestCases.apk von aosp-testkey 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 von 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-Carrier-API-Tests in Android 12 auszuführen, muss das Gerät eine SIM-Karte mit CTS-Carrier-Berechtigungen verwenden, die den Anforderungen der neuesten Version der GSMA TS.48 Test Profile- Spezifikation des Drittanbieters entspricht.

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

Ändern des CTS-SIM-Profils

  1. Hinzufügen: CTS-Trägerrechte im Access Rule Application Master (ARA-M) oder ARF. Beide Signaturen müssen in den Carrier-Privilege-Regeln kodiert sein:
    1. 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. 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
      • 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
  3. Ändern: USIM-Diensttabelle: Aktivieren Sie die Dienste Nr. 47 und Nr. 48
    1. EF_UST (6F38)
      • Inhalt: 9EFFBF1DFFFE0083410310010400406E01
  4. Ä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
  5. Ändern: Verwenden Sie die Trägernamenzeichenfolge Android CTS in den jeweiligen EFs, die diese Bezeichnung enthalten:
    1. EF_SPN (USIM/6F46)
      • Inhalt: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Inhalt: Rec1 430B83413759FE4E934143EA14FF..FF

Passend zur Testprofilstruktur

Laden Sie die neueste Version der folgenden generischen Testprofilstrukturen herunter und passen Sie sie an. Bei diesen Profilen werden weder die CTS Carrier Privilege-Regel noch die anderen oben aufgeführten Änderungen personalisiert.

Laufende Tests

Der Einfachheit halber unterstützt CTS ein Geräte-Token, das die Ausführung von Tests nur auf Geräten einschränkt, die mit demselben Token konfiguriert sind. Carrier API CTS-Tests unterstützen das 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ätetokens ausführen, wird der Test auf allen Geräten ausgeführt.

FAQ

Wie können Zertifikate auf der UICC aktualisiert werden?

A: Nutzen Sie den vorhandenen 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 auf den darauf enthaltenen Zertifikaten basiert?

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

Gibt es eine Begrenzung der Anzahl der Zertifikate bei 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 Latenzzeit bei der Prüfung kommen.

Gibt es eine Grenze 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 einige APIs, denen die Verwendung dieser Methode untersagt ist? Wenn ja, wie setzen Sie sie durch? (Das heißt, verfügen Sie über Tests, um zu überprüfen, welche APIs mit dieser Methode unterstützt werden?)

A: Weitere Informationen finden Sie im Abschnitt „API-Verhaltenskompatibilität“ im 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: Es wird die vom Benutzer angegebene Standard-SIM-Karte verwendet.

Interagiert oder überschneidet sich dies in irgendeiner Weise mit anderen SE-Zugriffstechnologien, zum Beispiel SEEK?

A: Beispielsweise verwendet SEEK dieselbe AID wie die UICC. Die Regeln existieren also nebeneinander und werden entweder nach SEEK oder UiccCarrierPrivileges gefiltert.

Wann ist es ein guter Zeitpunkt, die Betreiberprivilegien zu prüfen?

A: Nachdem der SIM-Status geladen wurde, wird er übertragen.

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

A: Nein. Wir glauben, dass es sich bei den aktuellen APIs um den minimalen Satz handelt, und wir planen, in Zukunft die Bitmaske für eine feinere Granularitätssteuerung zu verwenden.

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

Ja, die Überschreibung der Betreibermarke hat die höchste Priorität. Wenn es festgelegt ist, überschreibt es ALLE anderen Formen von Operatornamenzeichenfolgen.

Was bewirkt der Methodenaufruf injectSmsPdu ?

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

Basiert der onFilterSms Aufruf für die 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 zur Unterstützung von 32 Byte scheint mit der aktuellen GP-Spezifikation (die nur 0 oder 20 Byte zulässt) nicht kompatibel zu sein. Warum führen Sie diese Änderung ein? Reicht SHA-1 nicht aus, um Kollisionen zu vermeiden? Haben Sie GP diese Änderung bereits vorgeschlagen, da sie möglicherweise nicht rückwärtskompatibel mit dem bestehenden ARA-M/ARF ist?

A: Um zukunftssichere Sicherheit zu bieten, führt diese Erweiterung zusätzlich zu SHA-1 SHA-256 für DeviceAppID-REF-DO ein, was 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 werden?

A: Für Carrier-APIs muss DeviceAppID-REF-DO ausgefüllt werden. Das Leersein dient Testzwecken und wird für betriebliche Bereitstellungen nicht empfohlen.

Gemäß Ihrer Spezifikation sollte PKG-REF-DO , das allein ohne DeviceAppID-REF-DO verwendet wird, nicht akzeptiert werden. In Tabelle 6-4 der Spezifikation wird es jedoch 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 differenziertere Kontrolle haben können. Wenn ja, was definiert die Zuordnung zwischen der Bitmaske und den tatsächlichen Berechtigungen? Eine Erlaubnis pro Klasse? Eine Berechtigung pro Methode? Reichen 64 separate Berechtigungen auf Dauer?

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 jeweiligen App verwendet wird. Sollte der Name diesen Zweck nicht 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 zum Speichern von Zertifikaten wird von der vorhandenen Spezifikation unterstützt. Wir haben versucht, Spezifikationsänderungen auf ein Minimum zu beschränken, um die Hürde für die Einführung zu senken. Einzelheiten finden Sie unter Regeln zur UICC .