Android 5.1 ha introdotto un meccanismo per concedere privilegi speciali per le API rilevanti per i proprietari di applicazioni UICC (Universal Integrated Circuit Card). La piattaforma Android carica i certificati memorizzati su un UICC e concede il permesso alle app firmate da questi certificati di effettuare chiamate a una manciata di API speciali.
Android 7.0 ha esteso questa funzione per supportare altre fonti di memorizzazione per le regole di privilegio UICCcarrier, aumentando notevolmente il numero di vettori che possono utilizzare le API. Per un riferimento API, vedere CarrierConfigManager; per le istruzioni, vedere CarrierConfiguration.
I vettori hanno il pieno controllo della UICC, quindi questo meccanismo fornisce un modo sicuro e flessibile per gestire le applicazioni dall’operatore di rete mobile (MNO) ospitato su canali di distribuzione generici app (come Google Play) mentre mantenendo privilegi speciali sui dispositivi e senza la necessità di firmare le applicazioni con il certificato di piattaforma per dispositivo o preinstallare come app di sistema.
Regole su UICC
Il salvataggio sulla UICC è compatibile con la specifica GlobalPlatformSecure Element Access Control. L’identificatore dell’applicazione (AID) sulla scheda è A00000015141434C00, e il comando standardGET DATA viene utilizzato per recuperare le regole memorizzate sulla scheda. Puoi aggiornare queste regole attraverso gli aggiornamenti over-the-air (OTA) della scheda.
Gerarchia dei dati
Le regole UICC usano 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 completa del nome del pacchetto definito nel manifesto, codificato ASCII, lunghezza massima 127 byte.
-
-
AR-DO(E3) è esteso per includerePERM-AR-DO(DB), che è una maschera di bit a 8 byte che rappresenta 64 permessi separati.
Se PKG-REF-DO non è presente, qualsiasi applicazione firmata dal certificato ha accesso; altrimenti sia il certificato che il nome del pacchetto devono corrispondere.
Esempio di regola
Il nome dell’app è com.google.android.apps.myapp e il certificatoSHA-1 nella stringa hex è:
AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4
La regola su UICC nella stringa hex è:
E243 <= 43 is value length in hex E135 C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070 E30A DB08 0000000000000001
Access rule file (ARF) support
Android 7.0 aggiunge il supporto per la lettura delle regole di privilegio del vettore dal file delle regole di accesso (ARF).
La piattaforma Android tenta prima di selezionare l’applet delle regole di accesso (ARA), identificatore di applicazione (AID) A00000015141434C00. Se non trova l’AID sull’UICC, ripiega su ARF selezionando PKCS15 AIDA000000063504B43532D3135. Android legge quindi il file delle regole di controllo dell’accesso (ACRF) a 0x4300 e cerca le voci con AID FFFFFFFFFFFF. Le voci con AID differenti sono ignorate, sorules per altri casi d’uso possono coesistere.
Esempio di contenuto ACRF in stringa esadecimale:
30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10
Esempio di contenuto ACCF (access control conditions file):
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 sopra, 0x4310 è l’indirizzo per 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 sono concessi i privilegi di portatore.
Api abilitate
Android supporta le seguenti API.
TelephonyManager
- Metodo per permettere all’app portatore di chiedere all’UICC una sfida/risposta:
getIccAuthentication. - Metodo per controllare se all’app chiamante sono stati concessi i privilegi di portatore:
hasCarrierPrivileges. - Metodi per annullare marca e numero:
-
setOperatorBrandOverride -
setLine1NumberForDisplay -
setVoiceMailNumber
-
- Metodi per comunicazione diretta UICC:
-
iccOpenLogicalChannel -
iccCloseLogicalChannel -
iccExchangeSimIO -
iccTransmitApduLogicalChannel -
iccTransmitApduBasicChannel -
sendEnvelopeWithStatus
-
- Metodi per impostare la modalità dispositivo su globale:
setPreferredNetworkTypeToGlobal.
SmsManager
Metodo per permettere al chiamante di creare nuovi messaggi SMS in arrivo: injectSmsPdu.
CarrierConfigManager
Metodo per notificare la configurazione modificata: notifyConfigChangedForSubId. Per le istruzioni, vedere Configurazione portante.
CarrierMessagingService
Servizio che riceve le chiamate dal sistema quando vengono inviati o ricevuti nuovi SMS e MMS. Per estendere questa classe, dichiarate il servizio nel vostro file manifest con la android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICEpermissione e includete un filtro intenzionale con la #SERVICE_INTERFACEazione. I metodi includono:
-
onFilterSms -
onSendTextSms -
onSendDataSms -
onSendMultipartTextSms -
onSendMms -
onDownloadMms
Telephony provider
API del provider per permettere modifiche (inserimento, cancellazione, aggiornamento, interrogazione) al database della telefonia. I campi dei valori sono definiti aTelephony.Carriers; per maggiori dettagli, fare riferimento aTelephony API reference su developer.android.com.
Piattaforma Android
Su un UICC rilevato, la piattaforma costruisce oggetti UICC interni che includono regole di privilegio del vettore come parte dell’UICC.UiccCarrierPrivilegeRules.javacarica le regole, le analizza dalla scheda UICC e le cache in memoria. Quando è necessario un controllo dei privilegi, UiccCarrierPrivilegeRules confronta il certificato del chiamante con le proprie regole una per una. Se la UICC viene rimossa, le regole vengono distrutte insieme all’oggetto UICC.
Validazione
La Compatibility Test Suite (CTS) include test per le API del vettore inCtsCarrierApiTestCases.apk. Poiché questa funzione dipende dai certificati sull’UICC, devi preparare l’UICC per passare questi test.
Preparazione dell’UICC
Per default, CtsCarrierApiTestCases.apk è firmato dalla chiave Androiddeveloper, con valore hash61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81. I test stampano anche l’hash del certificato previsto se i certificati su UICCmismatch.
Esempio di output:
junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it.Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81
Per validare l’implementazione tramite CTS usandoCtsCarrierApiTestCases.apk, è necessario avere un UICC sviluppatore con le regole UICC corrette o il supporto ARF. Potete chiedere al fornitore di schede SIM di vostra scelta di preparare un UICC sviluppatore con il giusto ARF come descritto in questa sezione e usare quell’UICC per eseguire i test. L’UICC non richiede un servizio cellulare attivo per passare i test CTS.
Eseguire i test
Per comodità, CTS supporta un token di dispositivo che limita i test da eseguire solo sui dispositivi configurati con lo stesso token. I test di Carrier API CTS supportano il token di dispositivo sim-card-with-certs. Per esempio, il seguente token di dispositivo limita i test API del vettore da eseguire solo sul dispositivoabcd1234:
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
Quando si esegue un test senza utilizzare un token di dispositivo, il test viene eseguito su tutti i dispositivi.
FAQ
Come possono essere aggiornati i certificati sull’UICC?
A: Utilizzare il meccanismo di aggiornamento OTA della scheda esistente.
La UICC può coesistere con altre regole?
A: Va bene avere altre regole di sicurezza sulla UICC sotto lo stesso AID; la piattaforma le filtra automaticamente.
Cosa succede quando la UICC viene rimossa per un’app che si basa sui certificati su di essa?
A: L’app perde i suoi privilegi perché le regole associate alla UICC vengono distrutte alla rimozione della UICC.
C’è un limite al numero di certificati sulla UICC?
A: La piattaforma non limita il numero di certificati; ma poiché il controllo è lineare, troppe regole possono comportare una latenza per il controllo.
C’è un limite al numero di API che possiamo supportare con questo metodo?
A: No, ma limitiamo lo scopo alle API relative al vettore.
Ci sono alcune API che non possono usare questo metodo? Se sì, come le fate rispettare? (cioè, avete dei test per convalidare quali API sono supportate con questo metodo?)
A: Vedere la sezione “API Behavioral Compatibility” delAndroid Compatibility DefinitionDocument (CDD). Abbiamo alcuni test CTS per assicurarci che il permissionmodel delle API non sia cambiato.
Come funziona con la funzione multi-SIM?
A: Viene utilizzata la SIM predefinita specificata dall’utente.
In qualche modo questo interagisce o si sovrappone con altre tecnologie di accesso SE, per esempio, SEEK?
A: Come esempio, SEEK utilizza lo stesso AID dell’UICC. Quindi le regole coesistono e sono filtrate da SEEK o UiccCarrierPrivileges.
Quando è un buon momento per controllare i privilegi del vettore?
A: Dopo la trasmissione caricata stato SIM.
Gli OEM possono disabilitare parte delle API del vettore?
A: No. Crediamo che le attuali API siano il set minimo, e pensiamo di usare la maschera di bit per un controllo di granularità più fine in futuro.
Il setOperatorBrandOverride sovrascrive TUTTE le altre forme di stringhe operatorname? Per esempio, SE13, UICC SPN, o NITZ basato sulla rete?
A: Fai riferimento alla voce SPN inTelephonyManager
Cosa fa la chiamata al metodo injectSmsPdu?
A: Questo metodo facilita il backup/ripristino degli SMS nel cloud. La chiamatainjectSmsPdu abilita la funzione di ripristino.
Per il filtraggio degli SMS, la chiamata onFilterSms è basata sul filtraggio della porta UDH degli SMS? O le app dei carrier hanno accesso a TUTTI gli SMS in arrivo?
A: I carrier hanno accesso a tutti i dati SMS.
L’estensione di DeviceAppID-REF-DO per supportare32 byte sembra essere incompatibile con le attuali specifiche GP (che consentono solo 0 o 20 byte), quindi perché state introducendo questo cambiamento? Lo SHA-1 non è sufficiente per evitare collisioni? Avete già proposto questo cambiamento a GP, dato che questo potrebbe essere incompatibile all’indietro con l’attuale ARA-M/ARF?
A: Per fornire sicurezza a prova di futuro, questa estensione introduce SHA-256 per DeviceAppID-REF-DO oltre a SHA-1, che è attualmente l’unica opzione nello standard GP SEAC. Raccomandiamo vivamente di usare SHA-256.
Se DeviceAppID è 0 (vuoto), si applica la regola a tutte le applicazioni del dispositivo non coperte da una regola specifica?
A: Le API del vettore richiedono che DeviceAppID-REF-DO sia popolato.Essere vuoto è inteso per scopi di test e non è raccomandato per implementazioni operative.
Secondo le vostre specifiche, PKG-REF-DO usato da solo, senza DeviceAppID-REF-DO, non dovrebbe essere accettato. Ma è ancora descritto nella tabella 6-4 come estensione della definizione diREF-DO. È fatto apposta? Come si comporta il codice quando solo PKG-REF-DO è usato in REF-DO?
A: L’opzione di avere PKG-REF-DO come un singolo elemento di valore in REF-DO è stata rimossa nell’ultima versione. PKG-REF-DO dovrebbe verificarsi solo in combinazione con DeviceAppID-REF-DO.
Supponiamo che possiamo concedere l’accesso a tutte le autorizzazioni basate sul vettore o avere un controllo più fine. Se è così, cosa definisce la mappatura tra la bitmask e i permessi effettivi? Un permesso per classe? Un permesso per metodo? 64 permessi separati sono sufficienti nel lungo periodo?
A: Questo è riservato per il futuro, e accogliamo suggerimenti.
Puoi definire ulteriormente DeviceAppID per Androidspecificamente? Questo è il valore SHA-1 (20 byte) dell’hash del certificato Publisher usato per firmare l’app data, quindi il nome non dovrebbe riflettere quello scopo? (Il nome potrebbe confondere molti lettori in quanto la regola è applicabile a tutte le app firmate con lo stesso certificato Publisher.)
A: La memorizzazione dei certificati DeviceAppID è supportata dalla specifica esistente. Abbiamo cercato di ridurre al minimo le modifiche alle specifiche per abbassare la barriera per l’adozione. Per i dettagli, vedere Regole su UICC.