Android 5.1 ha introdotto un meccanismo per concedere privilegi speciali per le API pertinenti ai proprietari di app per schede a circuito integrato universali (UICC). La piattaforma Android carica i certificati memorizzati su una UICC e concede alle app firmate da questi certificati l'autorizzazione per effettuare chiamate a una serie di API speciali.
Android 7.0 ha esteso questa funzionalità per supportare altre origini di archiviazione per le regole dei privilegi degli operatori UICC, aumentando notevolmente il numero di operatori che possono utilizzare le API. Per un riferimento all'API, consulta CarrierConfigManager; per le istruzioni, consulta Carrier Configuration.
Gli operatori hanno il pieno controllo della UICC, quindi questo meccanismo fornisce un modo sicuro e flessibile per gestire le app dell'operatore di rete mobile (MNO) ospitate su canali di distribuzione di app generici (come Google Play), mantenendo al contempo i privilegi speciali sui dispositivi e senza dover firmare le app con il certificato della piattaforma per dispositivo o preinstallarle come app di sistema.
Regole relative alla UICC
Lo spazio di archiviazione sulla UICC è compatibile con la
GlobalPlatform
specifica di controllo dell'accesso all'elemento di sicurezza. L'identificatore app (AID) sulla scheda è A00000015141434C00 e il comando GET DATA standard viene utilizzato per recuperare le regole memorizzate nella scheda. Puoi aggiornare queste regole tramite gli aggiornamenti OTA (over-the-air) della carta.
Gerarchia dei dati
Le regole UICC utilizzano la seguente gerarchia di dati (la combinazione di lettere e numeri di due caratteri tra parentesi è il tag dell'oggetto). Ogni regola è
REF-AR-DO (E2) e consiste in una concatenazione di
REF-DO e AR-DO:
REF-DO(E1) contieneDeviceAppID-REF-DOo una concatenazione diDeviceAppID-REF-DOePKG-REF-DO.DeviceAppID-REF-DO(C1) memorizza la firma SHA-1 (20 byte) o SHA-256 (32 byte) del certificato.PKG-REF-DO(CA) è la stringa del nome completo del pacchetto definita nel file manifest, con codifica ASCII e lunghezza massima di 127 byte.
AR-DO(E3) viene esteso per includerePERM-AR-DO(DB), che è una maschera di bit di 8 byte che rappresenta 64 autorizzazioni distinte.
Se PKG-REF-DO non è presente, a qualsiasi app firmata dal certificato viene concesso l'accesso. In caso contrario, sia il certificato sia il nome del pacchetto devono corrispondere.
Esempio di regola
Il nome dell'app è com.google.android.apps.myapp e il
certificato SHA-1 in stringa esadecimale è:
AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4
La regola sulla stringa esadecimale UICC è:
E243 <= 43 is value length in hex
E135
C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
E30A
DB08 0000000000000001
Supporto dei file delle regole di accesso
Android 7.0 aggiunge il supporto per la lettura delle regole dei privilegi dell'operatore dal file delle regole di accesso (ARF).
La piattaforma Android tenta innanzitutto di selezionare l'AID A00000015141434C00 dell'applicazione di regole di accesso (ARA). Se non trova
l'AID sulla UICC, passa all'ARF selezionando l'AID PKCS15
A000000063504B43532D3135. Android legge quindi il file delle regole di controllo dell'accesso (ACRF) in 0x4300 e cerca le voci con AID FFFFFFFFFFFF. Le voci con AID diversi vengono ignorate, pertanto le regole per altri casi d'uso possono coesistere.
Esempio di contenuti ACRF in stringa esadecimale:
30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10
Esempio di contenuti del file delle condizioni di controllo degli accessi (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
Nell'esempio precedente, 0x4310 è l'indirizzo dell'ACCF, che contiene l'hash del certificato61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. Alle app
firmate da questo certificato vengono concessi i privilegi dell'operatore.
API abilitate
Android supporta le seguenti API.
TelephonyManager
- Metodo per consentire all'app dell'operatore di richiedere una verifica/risposta all'UICC:
getIccAuthentication. - Metodo per verificare se all'app di chiamata sono stati concessi i privilegi dell'operatore:
hasCarrierPrivileges. - Metodi per sostituire il brand e il numero:
- Metodi per la comunicazione diretta con la UICC:
- Metodo per impostare la modalità del dispositivo su globale:
setPreferredNetworkTypeToGlobal. - Metodi per ottenere le identità del dispositivo o della rete:
- Identificativo IMEI (International Mobile Equipment Identifier):
getImei - Mobile Equipment Identifier (MEID):
getMeid - Network Access Identifier (NAI):
getNai - Numero di serie della SIM:
getSimSerialNumber
- Identificativo IMEI (International Mobile Equipment Identifier):
- Metodo per ottenere la configurazione dell'operatore:
getCarrierConfig - Metodo per ottenere il tipo di rete per la trasmissione dei dati:
getDataNetworkType - Metodo per ottenere il tipo di rete per il servizio vocale:
getVoiceNetworkType - Metodi per ottenere le informazioni sull'app UICC SIM (USIM):
- Numero di serie della SIM:
getSimSerialNumber - Dati della carta:
getUiccCardsInfo - GID1 (ID gruppo a livello 1):
getGroupIdLevel1 - Stringa del numero di telefono per la riga 1:
getLine1Number - Rete mobile terrestre pubblica vietata (PLMN):
getForbiddenPlmns - PLMN equivalente per il paese di residenza:
getEquivalentHomePlmns
- Numero di serie della SIM:
- Metodi per ottenere o impostare il numero di segreteria:
- Metodo per inviare un codice speciale del tastierino:
sendDialerSpecialCode - Metodo per reimpostare il modem radio:
rebootModem - Metodi per ottenere o impostare le modalità di selezione della rete:
- Metodo per richiedere una ricerca di rete:
requestNetworkScan - Metodi per ottenere o impostare i tipi di rete consentiti/preferiti:
- Metodi per verificare se i dati mobili o il roaming sono attivati in base alle impostazioni utente:
- Metodi per controllare o impostare la connessione dati con il motivo:
- Metodo per ottenere l'elenco dei numeri di emergenza:
getEmergencyNumberList - Metodi per controllare le reti opportunistiche:
- Metodi per impostare o cancellare la richiesta di aggiornamento dell'intensità del segnale cellulare:
TelephonyCallback
TelephonyCallback ha interfacce con un metodo di callback per informare l'app chiamante quando gli stati registrati cambiano:
- L'indicatore dei messaggi in attesa è cambiato:
onMessageWaitingIndicatorChanged - L'indicatore di inoltro di chiamata è cambiato:
onCallForwardingIndicatorChanged - La causa di disconnessione delle chiamate del sistema multimediale IP (IMS) è cambiata:
onImsCallDisconnectCauseChanged - Lo stato preciso della connessione dati è cambiato:
onPreciseDataConnectionStateChanged - L'elenco attuale dei numeri di emergenza è cambiato:
onEmergencyNumberListChanged - L'ID abbonamento ai dati attivo è cambiato:
onActiveDataSubscriptionIdChanged - La rete dell'operatore è cambiata:
onCarrierNetworkChange - La registrazione della rete o un aggiornamento della posizione/del percorso/dell'area di monitoraggio
non è riuscita:
onRegistrationFailed - Le informazioni sul blocco cambiano:
onBarringInfoChanged - La configurazione attuale del canale fisico è cambiata:
onPhysicalChannelConfigChanged
SubscriptionManager
- Metodi per ottenere varie informazioni sull'abbonamento:
- Metodo per ottenere il numero di abbonamenti attivi:
getActiveSubscriptionInfoCount - Metodi per gestire i gruppi di abbonamenti:
- Metodi per ottenere o impostare la descrizione del piano di relazione con l'operatore tra un operatore e un abbonato specifico:
- Metodo per ignorare temporaneamente il piano di relazione di fatturazione tra un operatore e un abbonato specifico in modo che sia considerato senza misurazione:
setSubscriptionOverrideUnmetered - Metodo per ignorare temporaneamente il piano del rapporto di fatturazione tra un operatore e un abbonato specifico per considerarlo in stato di congestione:
setSubscriptionOverrideCongested - Metodo per verificare se l'app con il contesto specificato è autorizzata a gestire l'abbonamento in questione in base ai relativi metadati:
canManageSubscription
SmsManager
- Metodo per consentire all'utente che chiama di creare nuovi messaggi SMS in arrivo:
injectSmsPdu. - Metodo per inviare un messaggio SMS di testo senza scrivere nel fornitore di servizi SMS:
sendTextMessageWithoutPersisting
CarrierConfigManager
- Metodo per notificare la modifica della configurazione:
notifyConfigChangedForSubId. - Metodo per ottenere la configurazione dell'operatore per l'abbonamento predefinito:
getConfig - Metodo per ottenere la configurazione dell'operatore per l'abbonamento specificato:
getConfigForSubId
Per le istruzioni, consulta Configurazione dell'operatore.
BugreportManager
Metodo per avviare una segnalazione di bug relativa alla connettività, ovvero una versione specializzata della segnalazione di bug che include solo le informazioni per il debug dei problemi relativi alla connettività:
startConnectivityBugreport
NetworkStatsManager
- Metodo per eseguire query sul riepilogo dell'utilizzo della rete:
querySummary - Metodo per eseguire query sulla cronologia di utilizzo della rete:
queryDetails - Metodi per registrare o annullare la registrazione del callback relativo all'utilizzo della rete:
ImsMmTelManager
- Metodi per registrare o annullare la registrazione del callback di registrazione IMS MmTel:
ImsRcsManager
- Metodi per registrare o annullare la registrazione del callback di registrazione IMS RCS:
- Metodi per ottenere lo stato di registrazione IMS o il tipo di trasporto:
ProvisioningManager
- Metodi per registrare e annullare la registrazione del callback per gli aggiornamenti del provisioning delle funzionalità IMS:
- Metodi relativi allo stato del provisioning per la funzionalità IMS MmTel o RCS:
EuiccManager
Metodo per passare all'abbonamento specificato (attivarlo):
switchToSubscription
CarrierMessagingService
Servizio che riceve chiamate dal sistema quando vengono inviati o ricevuti nuovi SMS e MMS. Per estendere questa classe, dichiara il servizio nel file manifest con
l'autorizzazione android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE
e includi un filtro per intent con l'azione #SERVICE_INTERFACE. I metodi includono:
- Metodo per filtrare i messaggi SMS in entrata:
onFilterSms - Metodo per intercettare i messaggi SMS inviati dal dispositivo:
onSendTextSms - Metodo per intercettare i messaggi SMS binari inviati dal dispositivo:
onSendDataSms - Metodo per intercettare gli SMS lunghi inviati dal dispositivo:
onSendMultipartTextSms - Metodo per intercettare i messaggi MMS inviati dal dispositivo:
onSendMms - Metodo per scaricare i messaggi MMS ricevuti:
onDownloadMms
CarrierService
Servizio che espone al sistema funzionalità specifiche dell'operatore. Per estendere questo corso, dichiara il servizio nel file manifest dell'app con l'autorizzazione android.Manifest.permission#BIND_CARRIER_SERVICES e includi un filtro per intent con l'azione CARRIER_SERVICE_INTERFACE.
Se il servizio ha una associazione a lungo termine, imposta
android.service.carrier.LONG_LIVED_BINDING su
true nei metadati del servizio.
La piattaforma lega CarrierService a flag speciali per consentire l'esecuzione del processo del servizio dell'operatore in un
bucket di app in standby speciale. In questo modo, l'app del servizio dell'operatore è esente dalla
limitazione di inattività dell'app e ha maggiori probabilità di rimanere attiva quando la memoria del dispositivo è in esaurimento. Tuttavia, se l'app del servizio dell'operatore si arresta in modo anomalo per qualsiasi motivo, perde tutti i privilegi sopra indicati finché l'app non viene riavviata e il legame non viene reintegrato. È quindi fondamentale mantenere stabile l'app del servizio dell'operatore.
I metodi in CarrierService includono:
- Per sostituire e impostare le configurazioni specifiche dell'operatore:
onLoadConfig - Per informare il sistema di un imminente cambio intenzionale della rete dell'operatore da parte dell'app dell'operatore:
notifyCarrierNetworkChange
Fornitore di servizi di telefonia
API di fornitori di contenuti per consentire modifiche (inserimento, eliminazione, aggiornamento, query) al database di telefonia. I campi dei valori sono definiti in
Telephony.Carriers; per ulteriori dettagli, consulta
la documentazione di riferimento della classe Telephony
WifiNetworkSuggestion
Quando crei un oggetto WifiNetworkSuggestion, utilizza i seguenti metodi per impostare un ID abbonamento o un gruppo di abbonamenti:
- Metodo per impostare un ID abbonamento:
setSubscriptionId - Metodo per impostare un gruppo di abbonamenti:
setSubscriptionGroup
Piattaforma Android
In una UICC rilevata, la piattaforma crea oggetti UICC interni che includono le regole dei privilegi dell'operatore come parte della UICC.
UiccCarrierPrivilegeRules.java
carica le regole, le analizza dalla scheda UICC e le memorizza nella cache in memoria. Quando è necessaria una verifica dei privilegi, UiccCarrierPrivilegeRules confronta il certificato dell'autore della chiamata con le proprie regole una per una. Se la UICC viene rimossa, le regole vengono distrutte insieme all'oggetto UICC.
Convalida
Per convalidare l'implementazione tramite
Compatibility Test Suite (CTS) utilizzando CtsCarrierApiTestCases.apk,
devi disporre di un UICC sviluppatore con le regole UICC corrette o il supporto ARF.
Chiedi al fornitore di schede SIM che preferisci di preparare un'UICC per sviluppatori con l'ARF corretto come descritto in questa sezione e utilizzala per eseguire i test. L'UICC non richiede un servizio di telefonia cellulare attivo per superare i test CTS.
Prepara la UICC
Per Android 11 e versioni precedenti, CtsCarrierApiTestCases.apk è firmato da aosp-testkey, con valore hash 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81.
A partire da Android 12, CtsCarrierApiTestCases.apk è firmato da cts-uicc-2021-testkey, valore hash 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.
Per eseguire i test dell'API dell'operatore CTS in Android 12, il dispositivo deve utilizzare una SIM con privilegi dell'operatore CTS che soddisfino i requisiti specificati nella versione più recente della specifica Profilo di test GSMA TS.48 di terze parti.
La stessa SIM può essere utilizzata anche per le versioni precedenti ad Android 12.
Modificare il profilo SIM CTS
- Aggiungi:i privilegi dell'operatore CTS nell'app master delle regole di accesso (ARA-M) o nell'ARF. Entrambe le firme devono essere
codificate nelle regole dei privilegi del corriere:
- 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):
- Crea: file elementari (EF) ADF USIM non presenti nel TS.48 e necessari per il CTS:
- EF_MBDN (6FC7), dimensione del record: 28, numero di record: 4
- Contenuti
- Rec1: 566F696365204D61696CFFFFFFFF0691515555555FF…FF
- Rec2-n: FF…FF
- Contenuti
- EF_EXT6 (6FC8), dimensione record:13, numero record: 1
- Contenuti: 00FF…FF
- EF_MBI (6FC9), dimensione record: 4, numero record: 1
- Contenuti: Rec1: 01010101
- EF_MWIS (6FCA), dimensione record: 5, numero record: 1
- Contenuti: 0000000000
- Contenuti: 00FF…FF
- EF_MBDN (6FC7), dimensione del record: 28, numero di record: 4
- Modifica: tabella dei servizi USIM: attiva i servizi n. 47 e 48
- EF_UST (6F38)
- Contenuti:
9EFFBF1DFFFE0083410310010400406E01
- Contenuti:
- EF_UST (6F38)
- Modifica: file DF-5GS e DF-SAIP
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Contenuti:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Contenuti:
- DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
- Contenuti:
FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
- Contenuti:
- DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
- Contenuti:
A0020000FF…FF
- Contenuti:
- DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
- Contenuti:
A0020000FF…FF
- Contenuti:
- DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
- Modifica:utilizza la stringa del nome dell'operatore Android CTS
nei rispettivi EF contenenti questa designazione:
- EF_SPN (USIM/6F46)
- Contenuti:
01416E64726F696420435453FF..FF
- Contenuti:
- EF_PNN (USIM/6FC5)
- Contenuti:
Rec1 430B83413759FE4E934143EA14FF..FF
- Contenuti:
- EF_SPN (USIM/6F46)
Corrispondenza alla struttura del profilo di test
Scarica e abbina la versione più recente delle seguenti strutture di profili di test generici. Per questi profili non verrà personalizzata la regola CTS Carrier Privilege né verranno apportate altre modifiche elencate sopra.
Esegui test
Per praticità, CTS supporta un token del dispositivo che limita l'esecuzione dei test solo sui dispositivi configurati con lo stesso token. I test CTS dell'API Carrier supportano il token del dispositivo sim-card-with-certs. Ad esempio,
il seguente token dispositivo limita l'esecuzione dei test dell'API dell'operatore solo sul dispositivoabcd1234:
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
Quando esegui un test senza utilizzare un token dispositivo, il test viene eseguito su tutti i dispositivi.
Domande frequenti
Come possono essere aggiornati i certificati sulla UICC?
R: Utilizza il meccanismo di aggiornamento OTA della scheda esistente.
L'UICC può coesistere con altre regole?
R: Non è un problema avere altre regole di sicurezza nell'UICC con lo stesso AID; la piattaforma le filtra automaticamente.
Cosa succede quando la UICC viene rimossa per un'app che si basa sui relativi certificati?
R: l'app perde i suoi privilegi perché le regole associate all'UICC vengono distrutte al momento della rimozione dell'UICC.
Esiste un limite al numero di certificati sulla UICC?
R: la piattaforma non limita il numero di certificati, ma poiché il controllo è lineare, troppe regole potrebbero comportare una latenza per il controllo.
Esiste un limite al numero di API che possiamo supportare con questo metodo?
R: No, ma limitiamo l'ambito alle API correlate all'operatore.
Esistono API per le quali è vietato l'utilizzo di questo metodo? Se sì, come li applichi? (ovvero, hai test per convalidare quali API sono supportate con questo metodo?)
R: consulta la sezione Compatibilità comportamentale dell'API del Compatibility Definition Document (CDD) di Android. Eseguiamo alcuni test CTS per assicurarci che il modello di autorizzazione delle API non sia cambiato.
Come funziona con la funzionalità multi-SIM?
R: viene utilizzata la SIM predefinita specificata dall'utente.
Questa tecnologia interagisce o si sovrappone in qualche modo ad altre tecnologie di accesso ai SE, ad esempio SEEK?
R: Ad esempio, SEEK utilizza lo stesso AID della UICC. Pertanto, le regole coesistono e vengono filtrate da SEEK o UiccCarrierPrivileges.
Qual è un buon momento per controllare i privilegi dell'operatore?
R: Dopo la trasmissione dello stato della SIM caricato.
Gli OEM possono disattivare parte delle API dell'operatore?
R: No. Riteniamo che le API attuali siano l'insieme minimo e prevediamo di utilizzare la maschera di bit per un controllo più granulare in futuro.
setOperatorBrandOverride sostituisce TUTTE le altre forme di stringhe di nomi di operatori? Ad esempio, SE13, SPN UICC o NITZ basato sulla rete?
Sì, l'override del brand dell'operatore ha la priorità più alta. Se è impostato, sostituisce TUTTE le altre forme di stringhe di nomi degli operatori.
A cosa serve la chiamata al metodo injectSmsPdu?
R: questo metodo facilita il backup/ripristino degli SMS nel cloud. La chiamata
injectSmsPdu attiva la funzione di ripristino.
Per il filtro degli SMS, la chiamata onFilterSms si basa sul filtro delle porte UDH degli SMS? In alternativa, le app dell'operatore hanno accesso a TUTTI gli SMS in arrivo?
R: gli operatori hanno accesso a tutti i dati degli SMS.
L'estensione di DeviceAppID-REF-DO per supportare 32 byte sembra essere incompatibile con le specifiche GP attuali (che consentono solo 0 o 20 byte). Perché state introducendo questa modifica? SHA-1 non è sufficiente per evitare collisioni? Hai già proposto questa modifica a GP, in quanto potrebbe essere
incompatibile con le versioni precedenti di ARA-M/ARF?
R: per garantire una sicurezza adatta al futuro, questa estensione introduce SHA-256 per DeviceAppID-REF-DO, oltre a SHA-1, che al momento è l'unica opzione nello standard GP SEAC. Ti consigliamo vivamente di utilizzare SHA-256.
Se DeviceAppID è 0 (vuoto), applichi la regola a tutte le app del dispositivo non coperte da una regola specifica?
R: le API dell'operatore richiedono l'inserimento di DeviceAppID-REF-DO.
Lo stato vuoto è previsto per scopi di test e non è consigliato per le implementazioni operative.
Secondo le tue specifiche, PKG-REF-DO utilizzato da solo, senza DeviceAppID-REF-DO, non deve essere accettato. Tuttavia, nella tabella 6-4 della specifica è ancora descritto come un'estensione della definizione di REF-DO. È intenzionale? Come si comporta il codice quando in REF-DO viene utilizzato solo PKG-REF-DO?
R: l'opzione di avere PKG-REF-DO come singolo elemento di valore in REF-DO è stata rimossa nell'ultima versione.
PKG-REF-DO deve comparire solo in combinazione con
DeviceAppID-REF-DO.
Presumiamo di poter concedere l'accesso a tutte le autorizzazioni basate sull'operatore o di avere un controllo più granulare. In questo caso, cosa definisce la mappatura tra la maschera di bit e le autorizzazioni effettive? Un'autorizzazione per corso? Un'autorizzazione per metodo? 64 autorizzazioni separate sono sufficienti a lungo termine?
R: Questa funzionalità è riservata al futuro e accettiamo suggerimenti.
Puoi definire ulteriormente DeviceAppID per Android
in modo specifico? Si tratta del valore hash SHA-1 (20 byte) del certificato del publisher utilizzato per firmare l'app in questione, quindi il nome non dovrebbe riflettere questo scopo? Il nome potrebbe creare confusione per molti lettori, in quanto la regola è applicabile a tutte le app firmate con lo stesso certificato del publisher.
R: la memorizzazione dei certificati DeviceAppID è supportata dalla specifica esistente. Abbiamo cercato di ridurre al minimo le modifiche alle specifiche per abbassare la barriera all'adozione. Per maggiori dettagli, vedi Regole per UICC.