UICC-Mobilfunkanbieterberechtigungen

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: Siehe CarrierConfigManager. finden Sie Anleitungen, siehe Mobilfunkanbieter Konfiguration.

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 der UICC ist kompatibel mit dem <ph type="x-smartling-placeholder"></ph> GlobalPlatform Secure Element-Zugriffssteuerungsspezifikation. 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 aktualisieren über OTA-Updates (Card Over The Air).

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.
    • DeviceAppID-REF-DO (C1) speichert den SHA-1 (20 Byte) oder SHA-256-Signatur (32 Byte) des Zertifikats.
    • 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, alle vom Zertifikat signierten Apps erhält Zugriff, Andernfalls müssen sowohl das Zertifikat als auch der Paketname Übereinstimmung.

Regelbeispiel

Der Name der App lautet com.google.android.apps.myapp und der 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 hexadezimalem String lautet:

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

Unterstützung von Zugriffsregeln

Android 7.0 unterstützt das Lesen von Mobilfunkanbieter-Berechtigungsregeln aus dem Zugriff Regeldatei (ARF) enthält.

Die Android-Plattform versucht zuerst, die Anwendung für Zugriffsregeln auszuwählen (ARA) AID A00000015141434C00. Wenn keine die AID in der UICC, sie greift auf das Formular zur Kontowiederherstellung zurück, indem sie PKCS15 AID auswählt. A000000063504B43532D3135 Android liest dann die Access Control Rules (ACRF) unter 0x4300 sucht nach Einträgen mit AID FFFFFFFFFFFF. Einträge mit unterschiedlichen AIDs werden ignoriert. für andere Anwendungsfälle koexistieren.

Beispiel für den ACRF-Inhalt als hexadezimaler 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 ACCF-Datei (Access Control Condition):

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.

Telefonmanager

Telefonie-Rückruf

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

SubscriptionManager

SMS-Manager

CarrierConfigManager

  • Methode zum Benachrichtigen der Konfiguration: <ph type="x-smartling-placeholder"></ph> notifyConfigChangedForSubId
  • Methode zum Abrufen der Mobilfunkanbieter-Konfiguration für das Standardabo: <ph type="x-smartling-placeholder"></ph> getConfig.
  • Methode zum Abrufen der Mobilfunkanbieter-Konfiguration für das angegebene Abo: <ph type="x-smartling-placeholder"></ph> getConfigForSubId.

Anweisungen finden Sie unter Konfiguration des Mobilfunkanbieters.

FehlerberichtManager

Methode zum Starten eines Fehlerberichts über Verbindungen (eine spezielle Version von Der Fehlerbericht, der nur Informationen zur Fehlerbehebung im Zusammenhang mit der Konnektivität enthält Probleme: <ph type="x-smartling-placeholder"></ph> startConnectivityBugreport

NetzwerkStatsManager

ImsMmTelManager

ImsRcsManager

Bereitstellungsmanager

EuiccManager

Methode, um zum angegebenen Abo zu wechseln bzw. dieses zu aktivieren: <ph type="x-smartling-placeholder"></ph> switchToSubscription.

Nachrichtendienst des Mobilfunkanbieters

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: <ph type="x-smartling-placeholder"></ph> onFilterSms.
  • Methode zum Abfangen von SMS-Nachrichten, die vom Gerät gesendet wurden: <ph type="x-smartling-placeholder"></ph> onSendTextSms.
  • Methode zum Abfangen von binären SMS-Nachrichten, die vom Gerät gesendet wurden: onSendDataSms.
  • Methode zum Abfangen langer SMS, die vom Gerät gesendet wurden: <ph type="x-smartling-placeholder"></ph> onSendMultipartTextSms.
  • Methode zum Abfangen von MMS, die vom Gerät gesendet wurden: <ph type="x-smartling-placeholder"></ph> onSendMms.
  • Methode zum Herunterladen empfangener MMS: <ph type="x-smartling-placeholder"></ph> onDownloadMms.

Versandservice

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, legen Sie android.service.carrier.LONG_LIVED_BINDING bis true in den Metadaten des Dienstes.

Die Plattform bindet CarrierService mit speziellen Flags, um den Prozess des Transportunternehmens-Service in einem speziellen <ph type="x-smartling-placeholder"></ph> Standby-Bucket der Anwendung Dadurch wird die App des Mobilfunkanbieters von der <ph type="x-smartling-placeholder"></ph> 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, Alle oben genannten Berechtigungen gehen verloren, bis die App neu gestartet und die Bindung wiederhergestellt werden. 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: <ph type="x-smartling-placeholder"></ph> onLoadConfig.
  • Um das System über eine beabsichtigte bevorstehende Änderung des Mobilfunknetzes zu informieren, über die Mobilfunkanbieter-App: <ph type="x-smartling-placeholder"></ph> notifyCarrierNetworkChange.

Telefonieanbieter

Contentanbieter-APIs, die Änderungen zulassen (Einfügen, Löschen, Aktualisieren, Abfragen) mit der Telefonie-Datenbank. Wertefelder sind definiert unter <ph type="x-smartling-placeholder"></ph> Telephony.Carriers finden Sie weitere Informationen unter <ph type="x-smartling-placeholder"></ph> Klassenreferenz 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. <ph type="x-smartling-placeholder"></ph> UiccCarrierPrivilegeRules.java. lädt Regeln, parst sie von der UICC-Karte und speichert sie im Cache. Wann? eine Berechtigungsprüfung erforderlich ist, vergleicht UiccCarrierPrivilegeRules mit seinen eigenen Regeln einzeln nacheinander aufrufen. 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. Die Für UICC ist kein aktiver Mobilfunkdienst erforderlich, um 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 ist CtsCarrierApiTestCases.apk unterzeichnet von cts-uicc-2021-testkey, 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

So führen Sie CTS-Carrier API-Tests unter Android aus: 12, für das Gerät muss eine SIM-Karte des Mobilfunkanbieters mit CTS verwendet werden. Berechtigungen, die den Anforderungen der aktuellen Version von der Drittanbieter <ph type="x-smartling-placeholder"></ph> GSMA TS.48-Testprofilspezifikation.

Dieselbe SIM kann auch für Versionen vor Android 12

CTS-SIM-Profil ändern

  1. Hinzufügen: CTS-Mobilfunkanbieterberechtigungen in ARF (Access Regel App Master) oder das Formular zur Kontowiederherstellung. Beide Signaturen müssen in den Mobilfunkanbieter-Berechtigungsregeln codiert: <ph type="x-smartling-placeholder">
      </ph>
    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
    <ph type="x-smartling-placeholder">
  2. Erstellen: ADF USIM Elementary Files (EFs) sind in folgenden Dateien nicht vorhanden: TS.48 und für CTS erforderlich: <ph type="x-smartling-placeholder">
      </ph>
    1. EF_MBDN (6FC7), Datensatzgröße: 28, Datensatznummer: 4 <ph type="x-smartling-placeholder">
        </ph>
      • Inhalt <ph type="x-smartling-placeholder">
          </ph>
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF...FF
        2. Rec2-n: FF...FF
    2. EF_EXT6 (6FC8), Datensatzgröße:13, Datensatznummer: 1 <ph type="x-smartling-placeholder">
        </ph>
      • Inhalt: 00FF...FF <ph type="x-smartling-placeholder">
          </ph>
        1. EF_MBI (6FC9), Datensatzgröße: 4, Datensatznummer: 1
      • Inhalt: Rec1: 01010101 <ph type="x-smartling-placeholder">
          </ph>
        1. EF_MWIS (6FCA), Datensatzgröße: 5, Datensatznummer: 1
      • Inhalt: 0000000000
  3. Ändern: USIM-Servicetabelle: Dienste aktivieren n°47, n°48 <ph type="x-smartling-placeholder">
      </ph>
    1. EF_UST (6F38) <ph type="x-smartling-placeholder">
        </ph>
      • Videos: 9EFFBF1DFFFE0083410310010400406E01
  4. Ändern: DF-5GS- und DF-SAIP-Dateien <ph type="x-smartling-placeholder">
      </ph>
    1. DF-5GS: EF_5GS3GPPLOCI (USIM/5FC0/4F01) <ph type="x-smartling-placeholder">
        </ph>
      • Videos: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS: EF_5GSN3GPPLOCI (USIM/5FC0/4F02) <ph type="x-smartling-placeholder">
        </ph>
      • Videos: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS – EF SUCI_Calc_Info (USIM/5FC0/4F07) <ph type="x-smartling-placeholder">
        </ph>
      • Videos: A0020000FF…FF
    4. DF-SAIP – EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01) <ph type="x-smartling-placeholder">
        </ph>
      • Videos: A0020000FF…FF
  5. Ändern: Verwenden Sie den String für den Namen des Mobilfunkanbieters Android CTS. in den jeweiligen EFs mit dieser Kennzeichnung: <ph type="x-smartling-placeholder">
      </ph>
    1. EF_SPN (USIM/6F46) <ph type="x-smartling-placeholder">
        </ph>
      • Videos: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5) <ph type="x-smartling-placeholder">
        </ph>
      • Videos: Rec1 430B83413759FE4E934143EA14FF..FF

Der Struktur des Testprofils entsprechen

Laden Sie die neueste Version der folgenden generischen Testprofilstrukturen herunter und passen Sie sie an. Für diese Profile gilt die personalisierte CTS-Regel für die Mobilfunkanbieterprivilegierung nicht bzw. nicht für andere Änderungen oben aufgeführt.

Tests ausführen

Der Einfachheit halber unterstützt CTS ein Gerätetoken, Tests nur auf Geräten auszuführen, die mit demselben Token konfiguriert wurden. Carrier API CTS Die Tests unterstützen das Gerätetoken sim-card-with-certs. Beispiel: Das folgende Gerätetoken schränkt die Ausführung von API-Tests des Mobilfunkanbieters nur auf dem Gerät ein abcd1234:

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.

FAQ

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.

Ist die Anzahl der APIs begrenzt, die wir dabei 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 mit dieser Methode unterstützt?)

A: Sehen Sie sich die <ph type="x-smartling-placeholder"></ph> Abschnitt „API-Verhaltenskompatibilität“ des Abschnitts „Android-Kompatibilität“ Definition Document (CDD). Wir führen einige CTS-Tests durch, um sicherzustellen, das Berechtigungsmodell der APIs nicht geändert wird.

Wie funktioniert das mit der Funktion für mehrere SIM-Karten?

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 die gleiche AID wie auf der UICC. Die Regeln und zwar nach SEEK oder SEEK gefiltert, UiccCarrierPrivileges

Wann solltest du die Berechtigungen deines Mobilfunkanbieters prüfen?

A: Nach der Übertragung des SIM-Status-Ladevorgangs

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 es festgelegt ist, werden ALLE andere Arten von Strings für Operatornamen.

Was bewirkt der Methodenaufruf injectSmsPdu?

A: Diese Methode erleichtert die Sicherung/Wiederherstellung von SMS in der Cloud. 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 eingehende SMS?

A: Mobilfunkanbieter haben Zugriff auf alle SMS-Daten.

Die Erweiterung von DeviceAppID-REF-DO zur Unterstützung 32 Byte scheinen nicht kompatibel mit der aktuellen GP-Spezifikation, die nur 0 oder 20 Byte zulässt. Warum? führst du diese Änderung ein? SHA-1 ist nicht ausreichend, um Kollisionen zu vermeiden? Haben Sie GP bereits diese Änderung vorgeschlagen, nicht abwärtskompatibel mit dem vorhandenen ARA-M/ARF?

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, SHA-256 zu verwenden.

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äß deiner Spezifikation wird PKG-REF-DO nur von ohne DeviceAppID-REF-DO nicht akzeptiert werden. Aber wird trotzdem in Tabelle 6-4 der Spezifikation beschrieben, dass die Definition von REF-DO. Ist das beabsichtigt? Wie funktioniert der Code Wenn nur PKG-REF-DO in REF-DO verwendet wird?

A: Die Option, PKG-REF-DO als einzelnen Wert zu verwenden Element 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 Berechtigungen des Mobilfunkanbieters gewähren können oder eine präzisere Kontrolle haben. Wenn ja, was definiert die Zuordnung zwischen dem Bit und die tatsächlichen Berechtigungen? Eine Berechtigung pro Kurs? Eine Berechtigung pro ? Sind 64 separate Berechtigungen auf lange Sicht ausreichend?

A: Das ist für die Zukunft reserviert und wir freuen uns über Vorschläge.

Können Sie DeviceAppID für Android näher definieren? konkret? Dies ist der SHA-1-Hashwert (20 Byte) des Publishers. Zertifikat, mit dem die jeweilige App signiert wurde. Daher sollte der Name nicht darauf hinweisen, den Zweck haben? (Der Name könnte für viele Leser verwirrend sein, da die Regel gelten für alle Apps, die mit demselben Publisher-Zertifikat signiert wurden.)

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.