UICC-Anbieterberechtigungen

Mit Android 5.1 wurde ein Mechanismus eingeführt, mit dem besondere Berechtigungen für APIs gewährt werden können. relevant für Besitzer von UICC-Apps (Universal Integrated Circuit). Die Die Android-Plattform lädt Zertifikate, die auf einer UICC gespeichert sind, und gewährt die Berechtigung für Apps, die mit diesen Zertifikaten signiert sind, um Aufrufe an eine Handvoll spezieller APIs zu senden.

Unter Android 7.0 wurde diese Funktion erweitert, um weitere Speicherquellen für UICC zu unterstützen. von Mobilfunkanbietern die Anzahl der Netzbetreiber zu erhöhen, die die APIs nutzen können. Eine API-Referenz finden Sie unter CarrierConfigManager. Eine Anleitung findest du unter Mobilfunkanbieterkonfiguration.

Mobilfunkanbieter haben die volle Kontrolle über die UICC, daher bietet dieser Mechanismus eine eine sichere und flexible Möglichkeit, Apps über den MNO zu verwalten die auf allgemeinen App-Vertriebskanälen (wie Google Play) gehostet werden, Sie behalten besondere Berechtigungen auf Geräten, ohne dass Apps mit das gerätespezifische Plattformzertifikat oder die Vorinstallation als System-App.

Regeln in 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 und der Standard- GET DATA wird verwendet, um auf der Karte gespeicherte Regeln abzurufen. Sie können diese Regeln über OTA-Updates (Over-the-air) aktualisieren.

Datenhierarchie

UICC-Regeln verwenden die folgende Datenhierarchie (der zweistellige Buchstabe 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.
    • 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 vollständige Paketname Im Manifest definierter String, ASCII-codiert, max. Länge: 127 Byte.
  • AR-DO (E3) wird erweitert um PERM-AR-DO (DB), ein 8-Byte-Bit Maske für 64 verschiedene Berechtigungen.

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

Android 7.0 unterstützt das Lesen von Berechtigungsregeln des Mobilfunkanbieters aus der Zugriffsregeldatei (Access Rule File, ARF).

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. für andere Anwendungsfälle koexistieren.

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

Beispielinhalt 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, was enthält den Zertifikats-Hash. 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Apps mit diesem Zertifikat signiert, erhalten Mobilfunkanbieter-Berechtigungen.

Aktivierte APIs

Android unterstützt die folgenden APIs.

TelephonyManager

TelephonyCallback

TelephonyCallback hat Schnittstellen mit einer Callback-Methode, die Benachrichtigen Sie die aufrufende App, wenn sich der registrierte Status ändert:

SubscriptionManager

SmsManager

CarrierConfigManager

Anweisungen finden Sie unter Konfiguration des Mobilfunkanbieters.

FehlerberichtManager

Methode zum Starten eines Fehlerberichts zur Verbindungsqualität. Dies ist eine spezielle Version des Fehlerberichts, die nur Informationen zur Fehlerbehebung bei Verbindungsproblemen enthält: startConnectivityBugreport

NetzwerkStatsManager

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 werden, oder erhalten haben. Deklariere den Dienst in deiner Manifestdatei mit android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE Berechtigung und einen Intent-Filter mit der #SERVICE_INTERFACE Aktion ausführen. Folgende Methoden sind verfügbar:

  • Methode zum Filtern eingehender SMS: 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 dem System anbieterspezifische Funktionen zur Verfügung stellt. Bis um diese Klasse zu erweitern, deklarieren Sie den Dienst in der Manifest-Datei der App mit dem android.Manifest.permission#BIND_CARRIER_SERVICES Berechtigung und Schließen Sie einen Intent-Filter mit der Aktion CARRIER_SERVICE_INTERFACE ein. 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, um den Prozess des Transportunternehmens-Service in einem speziellen Standby-Bucket der Anwendung Dadurch wird die App des Mobilfunkanbieters von der App-Inaktivitätsbeschränkung und erhöht die Wahrscheinlichkeit, dass die App aktiv bleibt, wenn das Gerät nur noch wenig Arbeitsspeicher. 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, die App des Mobilfunkanbieters stabil zu halten.

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

Telefonieanbieter

Contentanbieter-APIs, die Änderungen zulassen (Einfügen, Löschen, Aktualisieren, Abfragen) mit der Telefonie-Datenbank. Wertefelder werden unter Telephony.Carriers definiert. Weitere Informationen finden Sie in der Referenz zur Klasse Telephony.

Wifi-Netzwerkvorschlag

Verwenden Sie beim Erstellen eines WifiNetworkSuggestion-Objekts Folgendes: Methoden zum Festlegen einer Abo-ID oder einer Abogruppe:

Android-Plattform

Auf einer erkannten UICC erstellt die Plattform interne UICC-Objekte, die die Mobilfunkanbieter-Berechtigungsregeln als Teil der UICC einschließen. 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

So validieren Sie die Implementierung über : Compatibility Test Suite (CTS) mit CtsCarrierApiTestCases.apk, Du benötigst einen Entwickler-UICC mit den richtigen UICC-Regeln oder Unterstützung bei der Kontowiederherstellung. Bitten Sie den SIM-Kartenanbieter Ihrer Wahl, eine Entwickler-UICC mit dem wie in diesem Abschnitt beschrieben, und verwenden Sie diese UICC, um die Tests durchzuführen. Für die UICC ist kein aktiver Mobilfunkdienst erforderlich, um die CTS-Tests zu bestehen.

UICC vorbereiten

Für Android 11 und niedriger ist CtsCarrierApiTestCases.apk signiert von aosp-testkey, mit Hashwert 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81

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.

Wenn Sie CTS-Mobilfunkanbieter-API-Tests in Android 12 ausführen möchten, muss auf dem Gerät eine SIM-Karte mit CTS-Mobilfunkanbieterberechtigungen verwendet werden, die die in der aktuellen Version der Drittanbieterspezifikation GSMA TS.48 Test Profile angegebenen Anforderungen erfüllen.

Dieselbe SIM kann auch für Versionen vor Android 12

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 des Mobilfunkanbieters 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
      • Inhalt: 0000000000
  3. Ändern: USIM-Servicetabelle: Dienste aktivieren n°47, n°48
    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

Der Struktur des Testprofils entsprechen

Laden Sie die aktuelle Version der folgenden Strukturen für generische Testprofile herunter und gleichen Sie sie ab. Für diese Profile wird 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äte.

Häufig gestellte Fragen

Wie können Zertifikate in der UICC aktualisiert werden?

A: Den vorhandenen Mechanismus zur OTA-Aktualisierung für Karten verwenden.

Kann UICC mit anderen Regeln gleichzeitig verwendet werden?

A: Es ist in Ordnung, andere Sicherheitsregeln auf der UICC unter derselben AID zu haben. und filtert sie automatisch heraus.

Was passiert, wenn die UICC für eine App entfernt wird, die auf dem Zertifikate darauf?

A: Die App verliert ihre Berechtigungen, weil die mit der UICC werden beim Entfernen aus UICC zerstört.

Ist die Anzahl der Zertifikate auf der UICC begrenzt?

A: Die Anzahl der Zertifikate ist auf der Plattform nicht begrenzt. aber weil die „check“ ist linear, zu viele Regeln können eine Latenz für die Prüfung verursachen.

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 APIs des Mobilfunkanbieters.

Ist die Verwendung dieser Methode für einige APIs unzulässig? Wenn ja, wie können Sie wenn Sie sie durchsetzen? (d. h., gibt es Tests, um zu prüfen, welche APIs diese Methode unterstützt?)

A: Sehen Sie sich die Abschnitt „API-Verhaltenskompatibilität“ des Abschnitts „Android-Kompatibilität“ 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 Nutzer angegebene Standard-SIM verwendet.

Trägt dies in irgendeiner Weise zu einer Wechselwirkung oder Überschneidung mit anderen SE-Zugriffen bei? wie z. B. SEEK?

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

Wann solltest du die Berechtigungen deines Mobilfunkanbieters prüfen?

A: Nach der Übertragung des SIM-Status

Können OEMs Teile von APIs von Mobilfunkanbietern deaktivieren?

A: Nein. Wir sind der Meinung, dass die aktuellen APIs nur die Mindestanforderungen erfüllen. planen, die Bitmaske für eine genauere Steuerung in Zukunft zu verwenden.

Überschreibt setOperatorBrandOverride ALLE anderen Formulare des Operators Namensstrings? Beispiel: SE13, UICC SPN oder netzwerkbasierte NITZ?

Ja, die Operator-Markenüberschreibung hat die höchste Priorität. Wenn diese Option festgelegt ist, werden ALLE anderen Formen von Operatornamen-Strings überschrieben.

Was bewirkt der Methodenaufruf injectSmsPdu?

A: Mit dieser Methode können SMS in der Cloud gesichert und wiederhergestellt werden. Die Der injectSmsPdu-Aufruf aktiviert die Wiederherstellungsfunktion.

Für die SMS-Filterung: Basiert der onFilterSms-Aufruf auf 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: Mit dieser Erweiterung wird SHA-256 eingeführt, um für zukunftssichere Sicherheit zu sorgen. für DeviceAppID-REF-DO zusätzlich zu SHA-1, die derzeit im GP SEAC-Standard die einzige Option. Wir empfehlen dringend die Verwendung von SHA-256.

Wenn DeviceAppID 0 ist (leer), wenden Sie die Regel auf alle Geräte-Apps, die keiner bestimmten Regel unterliegen?

A: Für Mobilfunkanbieter-APIs muss DeviceAppID-REF-DO ausgefüllt sein. Das Feld ist für Testzwecke gedacht und wird für den Betrieb nicht empfohlen Bereitstellungen.

Gemäß Ihrer Spezifikation sollte PKG-REF-DO nicht ohne DeviceAppID-REF-DO verwendet werden. Aber wird trotzdem in Tabelle 6-4 der Spezifikation beschrieben, dass die Definition von REF-DO. 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 Zugriffssteuerung 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? Sind 64 separate Berechtigungen auf lange Sicht ausreichend?

A: Das ist für die Zukunft geplant. 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 DeviceAppID-Zertifikat zum Speichern von Zertifikaten wird vom der vorhandenen Spezifikation. Wir haben versucht, Änderungen an Spezifikationen so gering wie möglich zu halten, Akzeptanz von Daten. Weitere Informationen findest du unter Regeln auf UICC.