Android 5.1 hat einen Mechanismus eingeführt, um spezielle Privilegien für APIs zu gewähren, die für die Besitzer von Universal Integrated Circuit Card (UICC)-Apps relevant sind. Die Android-Plattform lädt Zertifikate, die auf einer UICC gespeichert sind, und erteilt Apps, die von diesen Zertifikaten signiert wurden, die Erlaubnis, eine Handvoll spezieller APIs aufzurufen.
Android 7.0 hat diese Funktion erweitert, um andere Speicherquellen für die UICC-Berechtigungsregeln für Netzbetreiber zu unterstützen, wodurch die Anzahl der Netzbetreiber, die die APIs verwenden können, dramatisch erhöht wurde. Eine API-Referenz finden Sie unter CarrierConfigManager ; Anleitungen finden Sie unter Trägerkonfiguration .
Carrier haben die volle Kontrolle über die UICC, sodass dieser Mechanismus eine sichere und flexible Möglichkeit bietet, Apps vom Mobilfunknetzbetreiber (MNO) zu verwalten, die auf allgemeinen App-Vertriebskanälen (wie Google Play) gehostet werden, während besondere Privilegien auf Geräten und ohne die Notwendigkeit beibehalten werden um Apps mit dem Plattformzertifikat pro Gerät zu signieren oder als System-App vorzuinstallieren.
Regeln für UICC
Die Speicherung auf der UICC ist mit der GlobalPlatform Secure Element Access Control - Spezifikation kompatibel . Die Anwendungskennung (AID) auf der Karte ist A00000015141434C00
und der Standardbefehl GET DATA
wird verwendet, um auf der Karte gespeicherte Regeln abzurufen. Sie können diese Regeln über OTA-Updates (Card Over-the-Air) aktualisieren.
Datenhierarchie
UICC-Regeln verwenden die folgende Datenhierarchie (die Kombination aus zwei 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ältDeviceAppID-REF-DO
oder eine Verkettung vonDeviceAppID-REF-DO
undPKG-REF-DO
.-
DeviceAppID-REF-DO
(C1
) speichert die SHA-1 (20 Bytes) oder SHA-256 (32 Bytes) Signatur des Zertifikats. -
PKG-REF-DO
(CA
) ist die vollständige Zeichenfolge des Paketnamens, die im Manifest definiert ist, ASCII-codiert, maximale Länge 127 Bytes.
-
-
AR-DO
(E3
) wird umPERM-AR-DO
(DB
) erweitert, bei dem es sich um eine 8-Byte-Bitmaske handelt, die 64 separate Berechtigungen darstellt.
Wenn PKG-REF-DO
nicht vorhanden ist, wird jeder mit dem 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 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 fügt Unterstützung für das Lesen von Netzbetreiber-Berechtigungsregeln aus der Zugriffsregeldatei (ARF) hinzu.
Die Android-Plattform versucht zunächst, die Zugriffsregelanwendung (ARA) AID A00000015141434C00
. Wenn es die AID auf der UICC nicht findet, greift es auf ARF zurück, indem es PKCS15 AID A000000063504B43532D3135
. Android liest dann die Zugriffskontrollregeldatei (ACRF) bei 0x4300
und sucht nach Einträgen mit AID FFFFFFFFFFFF
. Einträge mit unterschiedlichen AIDs werden ignoriert, sodass Regeln für andere Anwendungsfälle koexistieren 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
Beispiel für den Inhalt 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
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
. Apps, die mit diesem Zertifikat signiert sind, werden Betreiberprivilegien gewährt.
Aktivierte APIs
Android unterstützt die folgenden APIs.
TelefonieManager
- Methode, damit die Spediteur-App UICC nach einer Abfrage/Antwort fragen kann:
getIccAuthentication
. - Methode zum Prüfen, ob der anrufenden App Betreiberrechte gewährt wurden:
hasCarrierPrivileges
. - Methoden zum Überschreiben von Marke und Nummer:
- Methoden für die direkte UICC-Kommunikation:
- Methode zum Festlegen des Gerätemodus auf global:
setPreferredNetworkTypeToGlobal
. - Methoden zum Abrufen der Geräte- oder Netzwerkidentitäten:
- International Mobile Equipment Identity (IMEI):
getImei
- Mobile Equipment Identifier (MEID):
getMeid
- Netzwerkzugriffskennung (NAI):
getNai
- SIM-Seriennummer:
getSimSerialNumber
- International Mobile Equipment Identity (IMEI):
- Methode zum Abrufen der Carrier-Konfiguration:
getCarrierConfig
- Methode zum Abrufen des Netzwerktyps für die Datenübertragung:
getDataNetworkType
- Methode zum Abrufen des Netzwerktyps für den Sprachdienst:
getVoiceNetworkType
- Methoden zum Abrufen von Informationen über die UICC SIM (USIM)-App:
- SIM-Seriennummer:
getSimSerialNumber
- Karteninformationen:
getUiccCardsInfo
- GID1 (Gruppen-ID-Ebene1):
getGroupIdLevel1
- Telefonnummern-String für Leitung 1:
getLine1Number
- Verbotenes öffentliches Landmobilnetz (PLMN):
getForbiddenPlmns
- Äquivalentes Heimat-PLMN:
getEquivalentHomePlmns
- SIM-Seriennummer:
- Methoden zum Abrufen oder Festlegen der Voicemail-Nummer:
- Methode zum Senden eines speziellen Dialer-Codes:
sendDialerSpecialCode
- Methode zum Zurücksetzen des Funkmodems:
rebootModem
- Methoden zum Abrufen oder Festlegen von Netzwerkauswahlmodi:
- Methode zum Anfordern eines Netzwerkscans:
requestNetworkScan
- Methoden zum Abrufen oder Festlegen der zulässigen/bevorzugten Netzwerktypen:
- Methoden zum Überprüfen, ob die mobilen Daten oder das Roaming pro Benutzereinstellung aktiviert sind:
- Methoden zum Überprüfen oder Festlegen der Datenverbindung mit Grund:
- Methode zum Abrufen der Notrufnummernliste:
getEmergencyNumberList
- Methoden zur Kontrolle der opportunistischen Netzwerke:
- Methoden zum Festlegen oder Löschen der Anforderung zur Aktualisierung der Mobilfunksignalstärke:
TelefonieRückruf
TelephonyCallback
hat Schnittstellen mit einer Callback-Methode, um die anrufende App zu benachrichtigen, wenn sich die registrierten Zustände ändern:
- Der Anzeiger für wartende Nachrichten hat sich geändert:
onMessageWaitingIndicatorChanged
- Die Rufumleitungsanzeige hat sich geändert:
onCallForwardingIndicatorChanged
- Die Ursache für die Verbindungsunterbrechung des IP-Multimedia-Systems (IMS) wurde geändert:
onImsCallDisconnectCauseChanged
- Der genaue Datenverbindungsstatus hat sich geändert:
onPreciseDataConnectionStateChanged
- Die aktuelle Notrufnummernliste hat sich geändert:
onEmergencyNumberListChanged
- Die aktive Datenabonnement-ID hat sich geändert:
onActiveDataSubscriptionIdChanged
- Das Trägernetzwerk hat sich geändert:
onCarrierNetworkChange
- Die Netzwerkregistrierung oder eine Standort-/Routing-/Tracking-Bereichsaktualisierung ist fehlgeschlagen:
onRegistrationFailed
- Die Änderung der Sperrinformationen:
onBarringInfoChanged
- Die aktuelle Konfiguration des physischen Kanals hat sich geändert:
onPhysicalChannelConfigChanged
SubscriptionManager
- Methoden zum Abrufen verschiedener Abonnementinformationen:
- Methode zum Abrufen der Anzahl aktiver Abonnements:
getActiveSubscriptionInfoCount
- Methoden zum Verwalten von Abonnementgruppen:
- Methoden zum Abrufen oder Festlegen der Beschreibung des Abrechnungsbeziehungsplans zwischen einem Netzbetreiber und einem bestimmten Abonnenten:
- Methode zum vorübergehenden Überschreiben des Abrechnungsbeziehungsplans zwischen einem Netzbetreiber und einem bestimmten Abonnenten, der als nicht gemessen gilt:
setSubscriptionOverrideUnmetered
- Methode zum vorübergehenden Überschreiben des Abrechnungsbeziehungsplans zwischen einem Netzbetreiber und einem bestimmten Abonnenten, der als überlastet gilt:
setSubscriptionOverrideCongested
- Methode zur Überprüfung, ob die Anwendung mit dem angegebenen Kontext berechtigt ist, das angegebene Abonnement gemäß seinen Metadaten zu verwalten:
canManageSubscription
SMSManager
- Methode, mit der der Anrufer neue eingehende SMS-Nachrichten erstellen kann:
injectSmsPdu
. - Methode zum Senden einer textbasierten SMS-Nachricht, ohne in den SMS-Anbieter zu schreiben:
sendTextMessageWithoutPersisting
CarrierConfigManager
- Methode zum Benachrichtigen der geänderten 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 Trägerkonfiguration .
BugreportManager
Methode zum Starten eines Konnektivitätsfehlerberichts, bei dem es sich um eine spezialisierte Version des Fehlerberichts handelt, die nur Informationen zum Debuggen von Verbindungsproblemen enthält: startConnectivityBugreport
NetworkStatsManager
- Methode zum Abfragen der Zusammenfassung der Netzwerknutzung:
querySummary
- Methode zum Abfragen des Netzwerknutzungsverlaufs:
queryDetails
- Methoden zum Registrieren oder Aufheben der Registrierung von Netzwerknutzungsrückrufen:
ImsMmTelManager
- Methoden zum Registrieren oder Aufheben der Registrierung von IMS MmTel-Registrierungsrückrufen:
ImsRcsManager
- Methoden zum Registrieren oder Aufheben der Registrierung von IMS RCS-Registrierungsrückrufen:
- Methoden zum Abrufen des IMS-Registrierungsstatus oder Transporttyps:
Bereitstellungsmanager
- Methoden zum Registrieren und Aufheben der Registrierung von IMS Feature Provisioning Updates Callback:
- Methoden im Zusammenhang mit dem Bereitstellungsstatus für die IMS MmTel- oder RCS-Funktion:
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 android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE
und fügen Sie einen Absichtsfilter mit der Aktion #SERVICE_INTERFACE
ein. Zu den Methoden gehören:
- Methode zum Filtern eingehender SMS-Nachrichten:
onFilterSms
- Methode zum Abfangen von Text-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
- Methode zum Herunterladen empfangener MMS-Nachrichten:
onDownloadMms
CarrierService
Dienst, der dem System netzbetreiberspezifische Funktionen zur Verfügung stellt. Um diese Klasse zu erweitern, deklarieren Sie den Dienst in der App-Manifestdatei mit der android.Manifest.permission#BIND_CARRIER_SERVICES
und fügen Sie einen Absichtsfilter mit der Aktion CARRIER_SERVICE_INTERFACE
ein. Wenn der Dienst eine langlebige Bindung hat, setzen android.service.carrier.LONG_LIVED_BINDING
in den Metadaten des Dienstes auf „ true
“.
Die Plattform bindet CarrierService
mit speziellen Flags, um den Carrier-Service-Prozess in einem speziellen App-Standby-Bucket laufen zu lassen. Dadurch wird die Carrier-Service-App von der App-Leerlaufbeschränkung ausgenommen und es ist wahrscheinlicher, dass sie am Leben bleibt, wenn der Gerätespeicher niedrig ist. 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 Carrier-Service-App stabil zu halten.
Zu den Methoden in CarrierService
gehören:
- So überschreiben und setzen Sie die betreiberspezifischen Konfigurationen:
onLoadConfig
- So informieren Sie das System über einen absichtlich bevorstehenden Wechsel des Netzbetreibers durch die Netzbetreiberanwendung:
notifyCarrierNetworkChange
den Netzbetreiber
Telefonanbieter
Inhaltsanbieter-APIs, um Änderungen (Einfügen, Löschen, Aktualisieren, Abfragen) an der Telefoniedatenbank zu ermöglichen. Wertefelder werden bei Telephony.Carriers
definiert; Weitere Einzelheiten finden Sie in der Referenz zur Telephony
WifiNetworkVorschlag
Verwenden Sie beim Erstellen eines WifiNetworkSuggestion
Objekts die folgenden Methoden, um eine Abonnement-ID oder eine Abonnementgruppe festzulegen:
- Methode zum Festlegen einer Abonnement-ID:
setSubscriptionId
- Methode zum Festlegen einer Abonnementgruppe:
setSubscriptionGroup
Android-Plattform
Auf einer erkannten UICC erstellt die Plattform interne UICC-Objekte, die Befördererprivilegienregeln als Teil der UICC enthalten. UiccCarrierPrivilegeRules.java
lädt Regeln, parst sie von der UICC-Karte und speichert sie im Arbeitsspeicher. 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, müssen Sie über eine Entwickler-UICC mit den richtigen UICC-Regeln oder ARF-Unterstützung verfügen. Bitten Sie den SIM-Kartenanbieter Ihrer Wahl, eine Entwickler-UICC mit dem richtigen ARF wie in diesem Abschnitt beschrieben vorzubereiten, und verwenden Sie diese UICC, um die Tests durchzuführen. 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
mit dem 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
mit 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
.
Um CTS-Betreiber-API-Tests in Android 12 auszuführen, muss das Gerät eine SIM-Karte mit CTS-Betreiberrechten verwenden, die die Anforderungen erfüllen, die in der neuesten Version der GSMA TS.48 -Testprofilspezifikation des Drittanbieters angegeben sind.
Dieselbe SIM-Karte kann auch für Versionen vor Android 12 verwendet werden.
Ändern des CTS-SIM-Profils
- Hinzufügen: CTS-Carrier-Privilegien im Access Rule Application Master (ARA-M) oder ARF. Beide Signaturen müssen in den Carrier Privilege Rules verschlüsselt werden:
- Hash1(SHA1):
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
- 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
- Hash1(SHA1):
- Erstellen: ADF USIM-Elementardateien (EFs), die in TS.48 nicht vorhanden sind und für CTS benötigt werden:
- EF_MBDN (6FC7), Datensatzgröße: 28, Datensatznummer: 4
- Inhalt
- Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
- Rec2-n: FF…FF
- Inhalt
- EF_EXT6 (6FC8), Datensatzgröße: 13, Datensatznummer: 1
- Inhalt: 00FF…FF
- EF_MBI (6FC9), Satzgröße: 4, Satznummer: 1
- Inhalt: Rec1: 01010101
- EF_MWIS (6FCA), Datensatzgröße: 5, Datensatznummer: 1
- Inhalt: 0000000000
- Inhalt: 00FF…FF
- EF_MBDN (6FC7), Datensatzgröße: 28, Datensatznummer: 4
- Ändern: USIM-Diensttabelle: Dienste Nr. 47, Nr. 48 aktivieren
- EF_UST (6F38)
- Inhalt:
9EFFBF1DFFFE0083410310010400406E01
- Inhalt:
- EF_UST (6F38)
- Ändern: DF-5GS- und DF-SAIP-Dateien
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Inhalt:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Inhalt:
- DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
- Inhalt:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Inhalt:
- DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
- Inhalt:
A0020000FF…FF
- Inhalt:
- DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
- Inhalt:
A0020000FF…FF
- Inhalt:
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Modifizieren: Verwenden Sie die Trägernamenzeichenfolge Android CTS in den jeweiligen EFs, die diese Bezeichnung enthalten:
- EF_SPN (USIM/6F46)
- Inhalt:
01416E64726F696420435453FF..FF
- Inhalt:
- EF_PNN (USIM/6FC5)
- Inhalt:
Rec1 430B83413759FE4E934143EA14FF..FF
- Inhalt:
- EF_SPN (USIM/6F46)
Anpassen der Testprofilstruktur
Laden Sie die neueste Version der folgenden generischen Testprofilstrukturen herunter und passen Sie sie an. Bei diesen Profilen wird die CTS-Carrier-Privilege-Regel nicht personalisiert oder andere oben aufgeführte Modifikationen haben.
Laufende Tests
Der Einfachheit halber unterstützt CTS ein Geräte-Token, das Tests darauf beschränkt, nur auf Geräten ausgeführt zu werden, die mit demselben Token konfiguriert sind. Carrier-API-CTS-Tests unterstützen das Geräte-Token sim-card-with-certs
. Beispielsweise schränkt das folgende Geräte-Token die Ausführung von Netzbetreiber-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: Verwenden Sie den bestehenden 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 sich auf die Zertifikate darauf verlässt?
A: Die App verliert ihre Berechtigungen, da die mit der UICC verknüpften Regeln beim Entfernen der UICC zerstört werden.
Ist die Anzahl der Zertifikate auf der UICC begrenzt?
A: Die Plattform beschränkt die Anzahl der Zertifikate nicht; Da die Prüfung jedoch linear ist, können zu viele Regeln eine Wartezeit für die Prüfung verursachen.
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 Geltungsbereich 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 validieren, welche APIs mit dieser Methode unterstützt werden?)
A: Siehe den Abschnitt API Behavioral Compatibility des 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, z. B. SEEK?
A: Zum Beispiel verwendet SEEK die gleiche AID wie auf der UICC. Die Regeln koexistieren also und werden entweder durch SEEK oder UiccCarrierPrivileges
gefiltert.
Wann ist es ein guter Zeitpunkt, die Privilegien der Transportunternehmen zu überprüfen?
A: Nach dem SIM-Status wurde die Sendung geladen.
Können OEMs einen Teil der Carrier-APIs deaktivieren?
A: Nein. Wir glauben, dass die aktuellen APIs der minimale Satz sind, und wir planen, die Bitmaske in Zukunft für eine feinere Granularitätssteuerung zu verwenden.
Überschreibt setOperatorBrandOverride
ALLE anderen Formen von Zeichenfolgen für Operatornamen? Zum Beispiel SE13, UICC SPN oder netzwerkbasiertes NITZ?
Ja, die Überschreibung der Betreibermarke hat die höchste Priorität. Wenn es gesetzt ist, überschreibt es ALLE anderen Formen von Zeichenfolgen für Operatornamen.
Was bewirkt der Methodenaufruf injectSmsPdu
?
A: Diese Methode erleichtert die Sicherung/Wiederherstellung von SMS in der Cloud. Der injectSmsPdu
-Aufruf aktiviert die Wiederherstellungsfunktion.
Basiert für die SMS-Filterung der onFilterSms
-Aufruf auf der SMS-UDH-Portfilterung? Oder haben Mobilfunkanbieter-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 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? Reicht SHA-1 nicht aus, um Kollisionen zu vermeiden? Haben Sie GP diese Änderung bereits vorgeschlagen, da dies mit dem bestehenden ARA-M/ARF abwärtsinkompatibel 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, wenden Sie die Regel auf alle Geräte-Apps an, die nicht von einer bestimmten Regel abgedeckt sind?
A: Carrier-APIs erfordern das Auffüllen von DeviceAppID-REF-DO
. Leer zu sein ist für Testzwecke vorgesehen und wird für betriebliche Bereitstellungen nicht empfohlen.
Gemäß Ihrer Spezifikation sollte PKG-REF-DO
nur für sich allein verwendet werden, ohne DeviceAppID-REF-DO
, sollte nicht akzeptiert werden. Aber es wird immer noch in Tabelle 6-4 der Spezifikation 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 feinere Kontrolle haben können. Wenn ja, was definiert die Zuordnung zwischen der Bitmaske und den tatsächlichen Berechtigungen? Eine Berechtigung pro Klasse? Eine Berechtigung pro Methode? Reichen 64 Einzelberechtigungen auf Dauer aus?
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 angegebenen 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 Herausgeberzertifikat signiert sind.)
A: Die DeviceAppID
, die Zertifikate speichert, wird von der bestehenden Spezifikation unterstützt. Wir haben versucht, Spezifikationsänderungen zu minimieren, um die Hürde für die Einführung zu senken. Einzelheiten finden Sie unter UICC-Regeln .