Privilegi dell'operatore UICC

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 l'autorizzazione alle app firmate da questi certificati 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 dell'operatore UICC, aumentando notevolmente il numero di operatori che possono utilizzare le API. Per un riferimento API, vedi CarrierConfigManager; per le istruzioni, vedi Configurazione dell'operatore.

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 delle app generici (come Google Play), mantenendo privilegi speciali sui dispositivi e senza la necessità di firmare le app con il certificato della piattaforma per dispositivo o di preinstallarle come app di sistema.

Regole relative alla UICC

L'archiviazione sulla UICC è compatibile con la specifica di controllo dell'accesso all'elemento sicuro di GlobalPlatform. L'identificatore dell'app (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 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 oggetto). Ogni regola è REF-AR-DO (E2) e consiste in una concatenazione di REF-DO e AR-DO:

  • REF-DO (E1) contiene DeviceAppID-REF-DO o una concatenazione di DeviceAppID-REF-DO e PKG-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, codificata in ASCII, lunghezza massima 127 byte.
  • AR-DO (E3) è esteso per includere PERM-AR-DO (DB), che è una maschera di bit di 8 byte che rappresenta 64 autorizzazioni separate.

Se PKG-REF-DO non è presente, viene concesso l'accesso a qualsiasi app firmata dal certificato; in caso contrario, devono corrispondere sia il certificato sia il nome del pacchetto.

Esempio di regola

Il nome dell'app è com.google.android.apps.myapp e il certificato SHA-1 in formato esadecimale è:

AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4

La regola relativa all'UICC nella stringa esadecimale è:

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 dell'applicazione della regola di accesso (ARA) A00000015141434C00. Se non trova l'AID sulla UICC, torna all'ARF selezionando l'AID PKCS15 A000000063504B43532D3135. Android legge 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, quindi 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 di 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 dell'operatore.

API abilitate

Android supporta le seguenti API.

TelephonyManager

TelephonyCallback

TelephonyCallback ha interfacce con un metodo di callback per notificare all'app chiamante quando cambiano gli stati registrati:

SubscriptionManager

SmsManager

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, vedi Configurazione dell'operatore.

BugreportManager

Metodo per avviare una segnalazione di bug relativi a connettività, ovvero una versione specializzata della segnalazione di bug che include solo informazioni per il debug dei problemi relativi alla connettività: startConnectivityBugreport

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

ProvisioningManager

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 funzionalità specifiche dell'operatore al sistema. Per estendere questa classe, 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 un binding di lunga durata, imposta android.service.carrier.LONG_LIVED_BINDING su true nei metadati del servizio.

La piattaforma associa CarrierService a flag speciali per consentire l'esecuzione del servizio di operatore in un bucket di standby dell'app� speciale. In questo modo, l'app di servizio dell'operatore è esente dalla limitazione dell'inattività delle app ed è più probabile che rimanga attiva quando la memoria del dispositivo è quasi piena. Tuttavia, se l'app del servizio di telefonia mobile si arresta in modo anomalo per qualsiasi motivo, perde tutti i privilegi sopra indicati finché l'app non viene riavviata e il binding non viene ristabilito. È quindi fondamentale mantenere stabile l'app Servizi operatore.

I metodi in CarrierService includono:

  • Per eseguire l'override 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 telefonia

API del fornitore 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 il riferimento alla classe Telephony.

WifiNetworkSuggestion

Quando crei un oggetto WifiNetworkSuggestion, utilizza i seguenti metodi per impostare un ID sottoscrizione o un gruppo di sottoscrizioni:

Piattaforma Android

Su una UICC rilevata, la piattaforma crea oggetti UICC interni che includono regole di privilegio dell'operatore come parte della 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 la UICC viene rimossa, le regole vengono eliminate insieme all'oggetto UICC.

Convalida

Per convalidare l'implementazione tramite Compatibility Test Suite (CTS) utilizzando CtsCarrierApiTestCases.apk, devi disporre di una UICC per sviluppatori con le regole UICC corrette o il supporto ARF. Chiedi al fornitore di schede SIM di tua scelta di preparare una UICC per sviluppatori con l'ARF corretto, come descritto in questa sezione, e utilizza questa UICC per eseguire i test. La UICC non richiede un servizio 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 CTS carrier in Android 12, il dispositivo deve utilizzare una SIM con privilegi CTS carrier che soddisfino i requisiti specificati nell'ultima versione della specifica GSMA TS.48 Test Profile di terze parti.

La stessa SIM può essere utilizzata anche per le versioni precedenti di Android 12.

Modificare il profilo SIM CTS

  1. Aggiungi:privilegi dell'operatore CTS in ARA-M (app master per le regole di accesso) o ARF. Entrambe le firme devono essere codificate nelle regole dei privilegi del corriere:
    1. Hash1(SHA1): 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81
    2. 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
  2. Crea: file elementari (EF) USIM ADF non presenti in TS.48 e necessari per CTS:
    1. EF_MBDN (6FC7), dimensione record: 28, numero record: 4 
      • Contenuti
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), dimensione record:13, numero record: 1 
      • Contenuti: 00FF…FF
        1. EF_MBI (6FC9), dimensioni record: 4, numero di record: 1
      • Contenuti: Rec1: 01010101
        1. EF_MWIS (6FCA), dimensione record: 5, numero record: 1
      • Contenuti: 0000000000
  3. Modifica: tabella dei servizi USIM: attiva i servizi n. 47 e n. 48
    1. EF_UST (6F38)
      • Contenuti: 9EFFBF1DFFFE0083410310010400406E01
  4. Modifica: file DF-5GS e DF-SAIP
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Contenuti: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Contenuti: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Contenuti: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Contenuti: A0020000FF…FF
  5. Modifica:utilizza la stringa del nome dell'operatore Android CTS nei rispettivi EF contenenti questa designazione:
    1. EF_SPN (USIM/6F46)
      • Contenuti: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Contenuti: Rec1 430B83413759FE4E934143EA14FF..FF

Corrispondere alla struttura del profilo di test

Scarica e abbina la versione più recente delle seguenti strutture di profili di test generici. Questi profili non avranno la regola CTS Carrier Privilege personalizzata o altre modifiche elencate sopra.

Esegui test

Per comodità, CTS supporta un token 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 dispositivo abcd1234:

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 carta esistente.

La UICC può coesistere con altre regole?

R: È possibile avere altre regole di sicurezza sulla UICC con lo stesso AID; la piattaforma le filtra automaticamente.

Cosa succede quando la UICC viene rimossa per un'app che si basa sui certificati presenti?

R: L'app perde i suoi privilegi perché le regole associate alla UICC vengono eliminate al momento della rimozione della UICC.

Esiste un limite al numero di certificati sulla UICC?

R: La piattaforma non limita il numero di certificati, ma poiché il controllo è lineare, un numero eccessivo di regole può 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 a cui è vietato utilizzare questo metodo? Se sì, come le fai rispettare? ovvero, hai test per convalidare quali API sono supportate con questo metodo?

R: Consulta la sezione API Behavioral Compatibility del Compatibility Definition Document (CDD) di Android. Abbiamo alcuni test CTS per assicurarci che il modello di autorizzazione delle API non venga modificato.

Come funziona con la funzionalità multi-SIM?

R: Viene utilizzata la SIM predefinita specificata dall'utente.

Questa funzionalità interagisce o si sovrappone in qualche modo con altre tecnologie di accesso SE, ad esempio SEEK?

R: Ad esempio, SEEK utilizza lo stesso AID della UICC. Pertanto, le regole coesistono e vengono filtrate in base a SEEK o UiccCarrierPrivileges.

Quando è 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 il set minimo e prevediamo di utilizzare la maschera di bit per un controllo più granulare in futuro.

setOperatorBrandOverride esegue l'override di TUTTE le altre forme di stringhe con il nome dell'operatore? Ad esempio, SE13, UICC SPN o NITZ basato sulla rete?

Sì, l'override del brand dell'operatore ha la priorità più alta. Una volta impostato, sostituisce TUTTE le altre forme di stringhe di nomi di operatori.

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 filtro SMS, la chiamata onFilterSms si basa sul filtraggio delle porte UDH degli SMS? Oppure 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 incompatibile con la specifica GP attuale (che consente solo 0 o 20 byte), quindi perché stai 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 esistenti?

R: Per garantire 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. 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 il popolamento di DeviceAppID-REF-DO. L'assenza di valore è pensata per scopi di test e non è consigliata per le implementazioni operative.

Secondo le tue specifiche, PKG-REF-DO utilizzato da solo, senza DeviceAppID-REF-DO, non dovrebbe essere accettato. Tuttavia, nella tabella 6-4 della specifica viene ancora descritto come estensione della definizione di REF-DO. È intenzionale? Come si comporta il codice quando viene utilizzato solo PKG-REF-DO in REF-DO?

R: L'opzione di avere PKG-REF-DO come singolo elemento in REF-DO è stata rimossa nell'ultima versione. PKG-REF-DO deve verificarsi 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? A lungo termine, 64 autorizzazioni separate sono sufficienti?

R: Questa funzionalità è riservata al futuro e accettiamo suggerimenti.

Puoi definire meglio DeviceAppID per Android nello specifico? Si tratta del valore hash SHA-1 (20 byte) del certificato del publisher utilizzato per firmare l'app specificata, quindi il nome non dovrebbe riflettere questo scopo? (Il nome potrebbe confondere molti lettori, in quanto la regola è applicabile a tutte le app firmate con lo stesso certificato dell'editore.)

R: L'archiviazione dei certificati DeviceAppID è supportata dalla specifica esistente. Abbiamo cercato di ridurre al minimo le modifiche alla specifica per abbassare la barriera all'adozione. Per maggiori dettagli, vedi Regole relative alla UICC.