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ältDeviceAppID-REF-DO
oder eine Verkettung vonDeviceAppID-REF-DO
undPKG-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 umPERM-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
- Methode, mit der die Netzbetreiber-App UICC nach einer Herausforderung/Antwort fragen kann:
getIccAuthentication
. - Methode zum Überprüfen, ob der aufrufenden App Netzbetreiberrechte gewährt wurden:
hasCarrierPrivileges
. - Methoden zum Überschreiben von Marke und Nummer:
- Methoden zur direkten UICC-Kommunikation:
- Methode zum Festlegen des Gerätemodus auf global:
setPreferredNetworkTypeToGlobal
. - Methoden zum Abrufen der Geräte- oder Netzwerkidentitäten:
- Internationale Identität mobiler Geräte (IMEI):
getImei
- Mobile Equipment Identifier (MEID):
getMeid
- Netzwerkzugriffskennung (NAI):
getNai
- SIM-Seriennummer:
getSimSerialNumber
- Internationale Identität mobiler Geräte (IMEI):
- Methode zum Abrufen der Netzbetreiberkonfiguration:
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
- Telefonnummernzeichenfolge für Leitung 1:
getLine1Number
- Verbotenes öffentliches Landmobilfunknetz (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 mobile Daten oder Roaming gemäß Benutzereinstellungen 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
verfügt über Schnittstellen mit einer Rückrufmethode, um die anrufende App zu benachrichtigen, wenn sich die registrierten Zustände ändern:
- Der Nachrichtenwarteindikator hat sich geändert:
onMessageWaitingIndicatorChanged
- Der Anrufweiterleitungsindikator hat sich geändert:
onCallForwardingIndicatorChanged
- Die Ursache für die Anrufunterbrechung des IP-Multimedia-Systems (IMS) hat sich geändert:
onImsCallDisconnectCauseChanged
- Der genaue Datenverbindungsstatus hat sich geändert:
onPreciseDataConnectionStateChanged
- Die aktuelle Notrufnummernliste hat sich geändert:
onEmergencyNumberListChanged
- Die ID des aktiven Datenabonnements hat sich geändert:
onActiveDataSubscriptionIdChanged
- Das Carrier-Netzwerk hat sich geändert:
onCarrierNetworkChange
- Die Netzwerkregistrierung oder eine Standort-/Routing-/Tracking-Bereichsaktualisierung ist fehlgeschlagen:
onRegistrationFailed
- Die Sperrinformationsänderung:
onBarringInfoChanged
- Die aktuelle Konfiguration des physischen Kanals hat sich geändert:
onPhysicalChannelConfigChanged
Abonnement-Manager
- 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 Außerkraftsetzen des Abrechnungsbeziehungsplans zwischen einem Netzbetreiber und einem bestimmten Abonnenten, der als überlastet gilt:
setSubscriptionOverrideCongested
- Methode zum Überprüfen, 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 Schreiben in den SMS-Anbieter:
sendTextMessageWithoutPersisting
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
- Methode zum Abfragen der Netzwerknutzungszusammenfassung:
querySummary
- Methode zum Abfragen des Netzwerknutzungsverlaufs:
queryDetails
- Methoden zum Registrieren oder Aufheben der Registrierung eines Netzwerknutzungsrückrufs:
ImsMmTelManager
- Methoden zum Registrieren oder Aufheben der Registrierung des IMS MmTel-Registrierungsrückrufs:
ImsRcsManager
- Methoden zum Registrieren oder Aufheben der Registrierung des IMS RCS-Registrierungsrückrufs:
- Methoden zum Abrufen des IMS-Registrierungsstatus oder Transporttyps:
ProvisioningManager
- Methoden zum Registrieren und Aufheben der Registrierung von IMS-Feature-Provisioning-Updates-Rückrufen:
- 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 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:
- 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 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
- 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:
-
61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
-
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
-
- 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), Datensatzgröße: 4, Datensatznummer: 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: Aktivieren Sie die Dienste Nr. 47 und Nr. 48
- 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)
- Ändern: 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)
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 .