Android 5.1 ha introdotto un meccanismo per concedere privilegi speciali per le API rilevanti per i proprietari di app UICC (Universal Integrated Circuit Card). La piattaforma Android carica i certificati archiviati su un UICC e concede l'autorizzazione alle app firmate da questi certificati per effettuare chiamate a una manciata di API speciali.
Android 7.0 ha esteso questa funzionalità per supportare altre origini di archiviazione per le regole di privilegio dell'operatore UICC, aumentando notevolmente il numero di operatori che possono utilizzare le API. Per un riferimento API, vedere CarrierConfigManager ; per istruzioni, vedere Configurazione del gestore .
I vettori hanno il pieno controllo dell'UICC, quindi questo meccanismo fornisce un modo sicuro e flessibile per gestire le app dall'operatore di rete mobile (MNO) ospitate su canali di distribuzione di app generiche (come Google Play) mantenendo i privilegi speciali sui dispositivi e senza la necessità per firmare le app con il certificato della piattaforma per dispositivo o preinstallare come app di sistema.
Regole su UICC
L'archiviazione su UICC è compatibile con la specifica GlobalPlatform Secure Element Access Control . L'identificativo dell'applicazione (AID) sulla carta è A00000015141434C00
e il comando GET DATA
standard viene utilizzato per recuperare le regole memorizzate sulla carta. Puoi aggiornare queste regole tramite gli aggiornamenti delle carte over-the-air (OTA).
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-DO
o una concatenazione diDeviceAppID-REF-DO
ePKG-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 manifest, codificato ASCII, lunghezza massima 127 byte.
-
-
AR-DO
(E3
) è stato esteso per includerePERM-AR-DO
(DB
), che è una maschera di bit a 8 byte che rappresenta 64 autorizzazioni separate.
Se PKG-REF-DO
non è presente, a qualsiasi app firmata dal certificato viene concesso l'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 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 su UICC nella stringa esadecimale è:
E243 <= 43 is value length in hex E135 C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070 E30A DB08 0000000000000001
Supporto per file di regole di accesso (ARF)
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 prima di selezionare l'identificatore dell'applicazione (AID) dell'applet regola di accesso (ARA) A00000015141434C00
. Se non trova l'AID sull'UICC, ricade su ARF selezionando PKCS15 AID A000000063504B43532D3135
. Android quindi legge il file delle regole di controllo dell'accesso (ACRF) a 0x4300
e cerca le voci con AID FFFFFFFFFFFF
. Le voci con AID diversi vengono ignorate, quindi possono coesistere regole per altri casi d'uso.
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 del file delle condizioni di controllo dell'accesso (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 sopra, 0x4310
è l'indirizzo per ACCF, che contiene l'hash del certificato 61: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 privilegi di operatore.
API abilitate
Android supporta le seguenti API.
TelephonyManager
- Metodo per consentire all'app del gestore di chiedere a UICC una verifica / risposta:
getIccAuthentication
. - Metodo per verificare se all'app chiamante sono stati concessi privilegi di operatore
hasCarrierPrivileges
:hasCarrierPrivileges
. - Metodi per sostituire marca e numero:
- Metodi per la comunicazione diretta UICC:
- Metodi per impostare la modalità del dispositivo su globale:
setPreferredNetworkTypeToGlobal
.
SmsManager
Metodo per consentire al chiamante di creare nuovi messaggi SMS in arrivo: injectSmsPdu
.
CarrierConfigManager
Metodo per notificare la configurazione modificata: notifyConfigChangedForSubId
. Per istruzioni, vedere Configurazione del gestore .
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 di intenti con l'azione #SERVICE_INTERFACE
. I metodi includono:
Provider di telefonia
API del provider di contenuti per consentire modifiche (inserimento, eliminazione, aggiornamento, query) al database di telefonia. I campi dei valori sono definiti in Telephony.Carriers
; per maggiori dettagli, fare riferimento a Riferimento API di telefonia su developer.android.com.
Piattaforma Android
Su un UICC rilevato, la piattaforma costruisce oggetti UICC interni che includono regole di privilegio del gestore come parte dell'UICC. UiccCarrierPrivilegeRules.java
carica le regole, le analizza dalla scheda UICC e le memorizza nella cache. Quando è necessario un controllo dei privilegi, UiccCarrierPrivilegeRules
confronta il certificato del chiamante con le proprie regole una per una. Se l'UICC viene rimosso, le regole vengono eliminate insieme all'oggetto UICC.
Validazione
La Compatibility Test Suite (CTS) include test per API carrier in CtsCarrierApiTestCases.apk
. Poiché questa funzionalità dipende dai certificati sull'UICC, è necessario preparare l'UICC per superare questi test.
Preparare l'UICC
Per impostazione predefinita, CtsCarrierApiTestCases.apk
è firmato dalla chiave sviluppatore Android, con valore hash 61: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 UICC non corrispondono.
Output di esempio:
junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it. Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81
Per convalidare l'implementazione tramite CTS utilizzando CtsCarrierApiTestCases.apk
, è necessario disporre di un UICC per sviluppatori con le regole UICC corrette o il supporto ARF. È possibile chiedere al fornitore della scheda SIM di propria scelta di preparare un UICC per sviluppatori con l'ARF corretto come descritto in questa sezione e utilizzare quell'UICC per eseguire i test. L'UICC non richiede un servizio cellulare attivo per superare i test CTS.
Esecuzione di test
Per comodità, 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 dell'operatore supportano il token del dispositivo sim-card-with-certs
. Ad esempio, il seguente token del dispositivo limita l'esecuzione dei test API abcd1234
solo sul dispositivo abcd1234
:
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
Quando si esegue un test senza utilizzare un token del dispositivo, il test viene eseguito su tutti i dispositivi.
FAQ
Come possono essere aggiornati i certificati sull'UICC?
R: Usa il meccanismo di aggiornamento OTA della carta esistente.
L'UICC può coesistere con altre regole?
A: Va bene avere altre regole di sicurezza sull'UICC sotto lo stesso AID; la piattaforma li filtra automaticamente.
Cosa succede quando l'UICC viene rimosso per un'app che si basa sui certificati su di essa?
R: L'app perde i suoi privilegi perché le regole associate all'UICC vengono distrutte alla rimozione dell'UICC.
C'è un limite al numero di certificati nell'UICC?
R: La piattaforma non limita il numero di certificati; ma poiché il controllo è lineare, troppe regole possono incorrere in una latenza per il controllo.
C'è un limite al numero di API che possiamo supportare con questo metodo?
R: No, ma limitiamo l'ambito alle API correlate al vettore.
Esistono alcune API vietate dall'utilizzo di questo metodo? In caso affermativo, come applicarli? (ovvero, hai test per convalidare quali API sono supportate con questo metodo?)
R: Consulta la sezione "Compatibilità comportamentale API" del documento CDD (Compatibility Definition Document) Android . Abbiamo alcuni test CTS per assicurarci che il modello di autorizzazione delle API non venga modificato.
Come funziona con la funzione multi-SIM?
R: Viene utilizzata la SIM predefinita specificata dall'utente.
Questo interagisce in qualche modo o si sovrappone con altre tecnologie di accesso SE, ad esempio SEEK?
A: Ad 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 dell'operatore?
A: Dopo che lo stato della SIM ha caricato la trasmissione.
Gli OEM possono disabilitare parte delle API del vettore?
R: No. Riteniamo che le API attuali siano l'insieme minimo e prevediamo di utilizzare la maschera di bit per un controllo più preciso della granularità in futuro.
setOperatorBrandOverride
sovrascrive TUTTE le altre forme di stringhe del nome dell'operatore? Ad esempio, SE13, UICC SPN o NITZ basato su rete?
R: Fare riferimento alla voce SPN in TelephonyManager
Cosa fa la chiamata al metodo injectSmsPdu
?
R: Questo metodo facilita il backup / ripristino degli SMS nel cloud. La chiamata injectSmsPdu
abilita la funzione di ripristino.
Per il filtraggio SMS, la chiamata onFilterSms
basata sul filtraggio della porta SMS UDH? Oppure le app del gestore hanno accesso a TUTTI gli SMS in arrivo?
R: I vettori hanno accesso a tutti i dati SMS.
L'estensione di DeviceAppID-REF-DO
per supportare 32 byte sembra essere incompatibile con l'attuale specifica GP (che consente solo 0 o 20 byte), quindi perché stai introducendo questa modifica? Non è sufficiente SHA-1 per evitare collisioni? Hai già proposto questa modifica a GP, poiché potrebbe essere incompatibile con le versioni precedenti di ARA-M / ARF?
R: Per fornire una 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. 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 DeviceAppID-REF-DO
richiedono che DeviceAppID-REF-DO
sia popolato. Essere vuoto è inteso a scopo di test e non è consigliato per le distribuzioni operative.
Secondo le tue 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 di REF-DO
. È apposta? Come si comporta il codice quando viene utilizzato solo PKG-REF-DO
in REF-DO
?
R: L'opzione di avere PKG-REF-DO
come elemento a valore singolo in REF-DO
stata rimossa nell'ultima versione. PKG-REF-DO
dovrebbe verificarsi solo in combinazione con DeviceAppID-REF-DO
.
Partiamo dal presupposto di poter concedere l'accesso a tutte le autorizzazioni basate sull'operatore o di avere un controllo più dettagliato. In caso affermativo, cosa definisce la mappatura tra la maschera di bit e le autorizzazioni effettive? Un permesso per classe? Un permesso per metodo? 64 autorizzazioni separate sono sufficienti a lungo termine?
R: Questo è riservato per il futuro e accogliamo suggerimenti.
Puoi definire ulteriormente DeviceAppID
per Android in modo specifico? Questo è il valore hash SHA-1 (20 byte) del certificato dell'editore utilizzato per firmare l'app data, quindi il nome non dovrebbe riflettere quello scopo? (Il nome potrebbe creare confusione per molti lettori poiché la regola è quindi applicabile a tutte le app firmate con lo stesso certificato dell'editore.)
R: DeviceAppID
archivia i certificati è supportato dalle specifiche esistenti. Abbiamo cercato di ridurre al minimo le modifiche alle specifiche per abbassare la barriera all'adozione. Per i dettagli, vedere Regole su UICC .