Privilegi del vettore UICC

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 fonti di archiviazione per le regole sui privilegi degli operatori UICC, aumentando notevolmente il numero di operatori che possono utilizzare le API. Per un riferimento API, vedere CarrierConfigManager ; per istruzioni, vedere Configurazione operatore .

Gli operatori hanno il pieno controllo dell'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 privilegi speciali sui dispositivi e senza la necessità per firmare le app con il certificato della piattaforma per dispositivo o preinstallarle come app di sistema.

Norme sull'UICC

L'archiviazione sull'UICC è compatibile con la specifica GlobalPlatform Secure Element Access Control . L'identificatore 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 over-the-air (OTA) della carta.

Gerarchia dei dati

Le regole UICC utilizzano la seguente gerarchia dei dati (la combinazione di lettere e numeri di due caratteri tra parentesi costituisce il tag dell'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 ASCII, lunghezza massima 127 byte.
  • AR-DO ( E3 ) viene esteso per includere PERM-AR-DO ( DB ), che è una maschera di bit da 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 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 nella stringa esadecimale è:

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

La regola sull'UICC nella stringa esadecimale è:

E243 <= 43 is value length in hex
  E135
    C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
    CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
  E30A
    DB08 0000000000000001

Supporto per i file delle regole di accesso

Android 7.0 aggiunge il supporto per la lettura delle regole sui privilegi dell'operatore dal file delle regole di accesso (ARF).

La piattaforma Android tenta innanzitutto di selezionare l'applicazione delle regole di accesso (ARA) AID A00000015141434C00 . Se non trova l'AID sull'UICC, torna ad ARF selezionando PKCS15 AID A000000063504B43532D3135 . Android quindi legge il file delle regole di controllo degli accessi (ACRF) su 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 contenuto ACRF in una 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 i privilegi dell'operatore.

API abilitate

Android supporta le seguenti API.

Responsabile della telefonia

TelefoniaRichiamata

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

Gestore degli abbonamenti

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 istruzioni, vedere Configurazione operatore .

Gestore segnalazioni di bug

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

NetworkStatsManager

ImsMmTelManager

ImsRcsManager

Responsabile del provisioning

EuiccManager

Metodo per passare a (abilitare) l'abbonamento specificato: switchToSubscription

CarrierMessagingService

Servizio che riceve le 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 intent con l'azione #SERVICE_INTERFACE . I metodi includono:

  • Metodo per filtrare i messaggi SMS in entrata: onFilterSms
  • Metodo per intercettare i messaggi SMS di testo inviati dal dispositivo: onSendTextSms
  • Metodo per intercettare i messaggi SMS binari inviati dal dispositivo: onSendDataSms
  • Metodo per intercettare i messaggi 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 questa classe, dichiara il servizio nel file manifest dell'app con l'autorizzazione android.Manifest.permission#BIND_CARRIER_SERVICES e includi un filtro intent con l'azione CARRIER_SERVICE_INTERFACE . Se il servizio ha un'associazione 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 processo del servizio del corriere in uno speciale bucket di standby dell'app . Ciò esonera l'app del servizio dell'operatore dalla limitazione dell'app inattiva e aumenta le probabilità che rimanga attiva quando la memoria del dispositivo è insufficiente. 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 l'associazione non viene ristabilita. Pertanto è fondamentale mantenere stabile l'app del servizio dell'operatore.

I metodi in CarrierService includono:

  • Per sovrascrivere e impostare le configurazioni specifiche dell'operatore: onLoadConfig
  • Per informare il sistema di un'imminente modifica intenzionale della rete dell'operatore da parte dell'applicazione dell'operatore: notifyCarrierNetworkChange

Fornitore di telefonia

API del fornitore di contenuti per consentire modifiche (inserimento, eliminazione, aggiornamento, query) al database della telefonia. I campi dei valori sono definiti in Telephony.Carriers ; per maggiori dettagli fare riferimento al riferimento alla classe Telephony

Suggerimento rete Wifi

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

Piattaforma Android

Su un UICC rilevato, la piattaforma costruisce oggetti UICC interni che includono regole sui privilegi del vettore 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 uno per uno. Se l'UICC viene rimosso, le regole vengono distrutte insieme all'oggetto UICC.

Validazione

Per convalidare l'implementazione tramite Compatibility Test Suite (CTS) utilizzando CtsCarrierApiTestCases.apk , è necessario disporre di uno sviluppatore UICC con le regole UICC corrette o il supporto ARF. Chiedi al fornitore della carta SIM di tua scelta di preparare un UICC per sviluppatori con l'ARF corretto come descritto in questa sezione e di utilizzare tale UICC per eseguire i test. L'UICC non richiede il servizio cellulare attivo per superare i test CTS.

Preparare l'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 API dell'operatore CTS in Android 12, il dispositivo deve utilizzare una SIM con privilegi dell'operatore CTS che soddisfi i requisiti specificati nell'ultima versione della specifica GSMA TS.48 Test Profile di terze parti.

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

Modifica Profilo SIM CTS

  1. Aggiunta: privilegi dell'operatore CTS nel master dell'applicazione delle regole di accesso (ARA-M) o ARF. Entrambe le firme devono essere codificate nelle regole sui 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. 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. Creare: file elementari ADF USIM (EF) non presenti in TS.48 e necessari per CTS:
    1. EF_MBDN (6FC7), dimensione del record: 28, numero del record: 4
      • Contenuto
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Reg2-n: FF…FF
    2. EF_EXT6 (6FC8), dimensione record: 13, numero record: 1
      • Contenuto: 00FF…FF
        1. EF_MBI (6FC9), dimensione del record: 4, numero del record: 1
      • Contenuto: Rec1: 01010101
        1. EF_MWIS (6FCA), dimensione del record: 5, numero del record: 1
      • Contenuto: 0000000000
  3. Modifica: Tabella servizi USIM: Abilita servizi n°47, n°48
    1. EF_UST (6F38)
      • Contenuto: 9EFFBF1DFFFE0083410310010400406E01
  4. Modifica: file DF-5GS e DF-SAIP
    1. DF-5GS-EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Contenuto: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS-EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Contenuto: FFFFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    3. DF-5GS - EF SUCI_Calc_Info (USIM/5FC0/4F07)
      • Contenuto: A0020000FF…FF
    4. DF-SAIP - EF SUCI_Calc_Info_USIM (USIM/5FD0/4F01)
      • Contenuto: A0020000FF…FF
  5. Modifica: utilizzare la stringa del nome dell'operatore Android CTS nei rispettivi EF contenenti questa designazione:
    1. EF_SPN (USIM/6F46)
      • Contenuto: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Contenuto: Rec1 430B83413759FE4E934143EA14FF..FF

Corrispondenza alla struttura del profilo di test

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

Esecuzione di test

Per comodità, CTS supporta un token dispositivo che limita l'esecuzione dei test solo su dispositivi configurati con lo stesso token. I test CTS 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 dell'operatore solo sul dispositivo abcd1234 :

cts-tradefed run cts  --device-token abcd1234:sim-card-with-certs

Quando si esegue un test senza utilizzare un token dispositivo, il test viene eseguito su tutti i dispositivi.

FAQ

Come si aggiornano i certificati sull'UICC?

R: Utilizza il meccanismo di aggiornamento OTA della carta esistente.

L’UICC può coesistere con altre norme?

R: 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 fa affidamento sui certificati presenti su di essa?

R: L'app perde i suoi privilegi perché le regole associate all'UICC vengono distrutte alla rimozione dell'UICC.

Esiste un limite al numero di certificati sull'UICC?

R: La piattaforma non limita il numero di certificati; ma poiché il controllo è lineare, troppe regole potrebbero subire una latenza nel controllo.

Esiste un limite al numero di API che possiamo supportare con questo metodo?

R: No, ma limitiamo l'ambito alle API relative all'operatore.

Ad alcune API è vietato utilizzare questo metodo? Se sì, come applicarli? (ovvero, hai test per convalidare quali API sono supportate con questo metodo?)

R: Consulta la sezione relativa alla compatibilità comportamentale dell'API del documento CDD (Android Compatibility Definition Document). 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.

Interagisce o si sovrappone in qualche modo con altre tecnologie di accesso SE, ad esempio SEEK?

R: Ad esempio, SEEK utilizza lo stesso AID dell'UICC. Pertanto le regole coesistono e vengono filtrate da SEEK o UiccCarrierPrivileges .

Quando è il momento giusto per verificare i privilegi del corriere?

R: Dopo il caricamento dello stato della SIM trasmesso.

Gli OEM possono disabilitare parte delle API dell'operatore?

R: No. Riteniamo che le API attuali costituiscano il set minimo e prevediamo di utilizzare la maschera di bit per un controllo della granularità più preciso in futuro.

setOperatorBrandOverride sovrascrive TUTTE le altre forme di stringhe dei nomi degli operatori? Ad esempio, SE13, UICC SPN o NITZ basato su rete?

Sì, la sostituzione del marchio dell'operatore ha la massima priorità. Quando è impostato, sovrascrive TUTTE le altre forme di stringhe dei nomi degli 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 filtraggio SMS, la chiamata onFilterSms è basata sul filtraggio della porta SMS UDH? Oppure le app dell'operatore hanno accesso a TUTTI gli SMS in arrivo?

R: Gli operatori hanno accesso a tutti i dati SMS.

L'estensione di DeviceAppID-REF-DO per supportare 32 byte sembra essere incompatibile con le attuali specifiche GP (che consentono solo 0 o 20 byte), quindi perché stai introducendo questa modifica? SHA-1 non è sufficiente per evitare collisioni? Avete già proposto questa modifica a GP, in quanto potrebbe essere incompatibile con le versioni precedenti di ARA-M/ARF?

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. 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 DeviceAppID-REF-DO sia popolato. Il valore vuoto è destinato a scopi di test e non è consigliato per le distribuzioni operative.

Secondo le tue specifiche, PKG-REF-DO utilizzato da solo, senza DeviceAppID-REF-DO , non dovrebbe essere accettato. Ma è ancora descritto nella Tabella 6-4 delle specifiche come un'estensione della definizione di REF-DO . È fatto apposta? Come si comporta il codice quando in REF-DO viene utilizzato solo PKG-REF-DO -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 avere un controllo più preciso. In tal caso, cosa definisce la mappatura tra la maschera di bit e le autorizzazioni effettive? Un permesso per classe? Un'autorizzazione per metodo? 64 permessi separati sono sufficienti nel lungo periodo?

R: Questo è riservato per il futuro e accogliamo con favore 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 specifica, quindi il nome non dovrebbe riflettere tale scopo? (Il nome potrebbe creare confusione a molti lettori poiché la regola è quindi applicabile a tutte le app firmate con lo stesso certificato editore.)

R: Il DeviceAppID che memorizza i certificati è supportato dalle specifiche esistenti. Abbiamo cercato di ridurre al minimo le modifiche alle specifiche per abbassare la barriera per l'adozione. Per i dettagli, vedere Regole sull'UICC .