Privilegi dell'operatore 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 dell'operatore UICC, aumentando notevolmente il numero di operatori che possono utilizzare le API. Per un riferimento API, vedi CarrierConfigManager ; per le istruzioni, vedere Configurazione Carrier .

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 generiche (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.

Regole sull'UICC

Stoccaggio sul UICC è compatibile con il GlobalPlatform Fissare specifiche Elemento di controllo di accesso . L'identificatore di applicazione (AID) sulla carta è A00000015141434C00 , e lo standard GET DATA comando viene utilizzato per recuperare le regole memorizzate sulla scheda. Puoi aggiornare queste regole tramite gli aggiornamenti della carta 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 ) contiene DeviceAppID-REF-DO o una concatenazione di DeviceAppID-REF-DO e PKG-REF-DO .
    • DeviceAppID-REF-DO ( C1 ) memorizza lo SHA-1 (20 byte) o SHA-256 (32 byte) firma del certificato.
    • PKG-REF-DO ( CA ) è la stringa piena nome del pacchetto definito nel manifesto, ASCII codificati, lunghezza max 127 byte.
  • AR-DO ( E3 ) è esteso per includere PERM-AR-DO ( DB ), che è una maschera di 8 byte bit che rappresenta 64 autorizzazioni separati.

Se PKG-REF-DO non è presente, qualsiasi applicazione firmato dal certificato è concesso l'accesso; altrimenti sia il certificato che il nome del pacchetto devono corrispondere.

Esempio di regola

Il nome dell'applicazione è 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 su UICC in 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 sui privilegi dell'operatore dal file delle regole di accesso (ARF).

I primi tentativi di piattaforma Android per selezionare l'identificatore di applicazione (AID) regola di accesso applet (ARA) A00000015141434C00 . Se non trova l'aiuto sulla UICC, cade di nuovo a ARF selezionando PKCS15 AID A000000063504B43532D3135 . Android quindi legge il file di regole di controllo dell'accesso (ACRF) a 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 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 è la piattaforma ACCF, che contiene l'hash 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.

Gestore di telefonia

SMSManager

Metodo per consentire al chiamante di creare nuovi messaggi SMS in arrivo: injectSmsPdu .

Gestore della configurazione dell'operatore

Metodo di notificare la configurazione modificata: notifyConfigChangedForSubId . Per istruzioni, vedere Configurazione Carrier .

Servizio di messaggistica dell'operatore

Servizio che riceve chiamate dal sistema quando vengono inviati o ricevuti nuovi SMS e MMS. Per estendere questa classe, dichiarare il servizio nel vostro file manifesto con android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE permesso e comprendono un filtro intenti con la #SERVICE_INTERFACE azione. I metodi includono:

Fornitore di telefonia

API del provider di contenuti per consentire modifiche (inserimento, eliminazione, aggiornamento, query) al database di telefonia. Campi Valori sono definiti a Telephony.Carriers ; per maggiori dettagli, vedere Telephony API reference su developer.android.com.

Piattaforma Android

Su un UICC rilevato, la piattaforma costruisce oggetti UICC interni che includono regole di privilegio dell'operatore come parte dell'UICC. UiccCarrierPrivilegeRules.java carica regole, li analizza dalla scheda UICC, e li memorizza nella cache in memoria. Quando è necessario un controllo di privilegio, UiccCarrierPrivilegeRules confronta il certificato chiamante con le proprie regole uno per uno. Se l'UICC viene rimosso, le regole vengono eliminate insieme all'oggetto UICC.

Convalida

Per convalidare l'attuazione attraverso Compatibility Test Suite (CTS) utilizzando CtsCarrierApiTestCases.apk , è necessario avere un'UICC sviluppatore con le regole UICC corrette o di supporto ARF. Puoi chiedere al fornitore della carta SIM di tua 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.

Preparazione dell'UICC

Per Android 11 ed inferiore, CtsCarrierApiTestCases.apk è firmato da aosp-testkey , con valore di hash 61:ED:37:7E:85:D3:86:A8:DF:EE:6B:86:4B:D8:5B:0B:FA:A5:AF:81 .

A partire dal 12 Android, 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 CTS vettore API in Android 12, il dispositivo ha bisogno di utilizzare una SIM con CTS privilegi carrier soddisfare i requisiti specificati nella versione più recente di terze parti GSMA TS.48 Profilo prova specifica.

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

Modifica del profilo della SIM CTS

  1. Aggiungere: Privilegi CTS portante in ARA-M o ARF. Entrambe le firme devono essere codificate nelle regole sui privilegi del vettore:
    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
  1. Crea: ADF USIM EF non presenti in TS.48 e necessari per CTS:
    1. EF_MBDN (6FC7), Dimensione record: 28, Numero record: 4
      • Contenuto
        1. Rec1: 566F696365204D61696CFFFFFFFF06915155555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), Dimensione record:13, Numero record: 1
      • Contenuto: 00FF…FF
        1. EF_MBI (6FC9), Dimensione record: 4, Numero record: 1
      • Contenuto: Rec1: 01010101
        1. EF_MWIS (6FCA), Dimensione record: 5, Numero record: 1
      • Contenuto: 0000000000
  2. Modifica: USIM Servizio Tabella: Abilita servizi n ° 47, n ° 48
    1. EF_UST (6F38)
      • Contenuto: 9EFFBF1DFFFE0083410310010400406E01
  3. Modificare: DF-5GS e DF-SAIP Files
    1. DF-5GS - EF_5GS3GPPLOCI (USIM/5FC0/4F01)
      • Contenuto: FFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    2. DF-5GS - EF_5GSN3GPPLOCI (USIM/5FC0/4F02)
      • Contenuto: FFFFFFFFFFFFFFFFFFFFFFFF42F618FFFFFE01
    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
  4. Modifica: Nome Carrier stringhe devono essere Android CTS in rispettivi EF contengono questa denominazione:
    1. EF_SPN (USIM/6F46)
      • Contenuto: 01416E64726F696420435453FF..FF
    2. EF_PNN (USIM/6FC5)
      • Contenuto: Rec1 430B83413759FE4E934143EA14FF..FF

Corrispondenza con la struttura del profilo di prova

Scarica e abbinare la versione più recente delle seguenti strutture profilo di prova generica. Questi profili non avranno la regola Privilege Carrier CTS personalizzata o altre modifiche elencate sopra.

Test in corso

Per comodità, CTS supporta un token del dispositivo che limita l'esecuzione dei test solo su dispositivi configurati con lo stesso token. Test vettore API CTS supportano la periferica token sim-card-with-certs . Ad esempio, la seguente periferica token test API limita portanti per eseguito solo su 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: Utilizza il meccanismo di aggiornamento OTA della carta esistente.

L'UICC può coesistere con altre regole?

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 si basa sui certificati su di essa?

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

C'è un limite al numero di certificati sull'UICC?

R: 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?

R: No, ma limitiamo l'ambito alle API relative agli operatori.

Ci sono alcune API a cui è vietato utilizzare questo metodo? Se sì, come li applichi? (ovvero, hai test per convalidare quali API sono supportate con questo metodo?)

A: Vedere la sezione "API comportamentale Compatibility" della definizione di documento di compatibilità Android (CDD) . 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 ad altre tecnologie di accesso SE, ad esempio, SEEK?

R: Ad esempio, SEEK utilizza lo stesso AID dell'UICC. Così il co-esistono regole e vengono filtrati da una sollecitare o UiccCarrierPrivileges .

Quando è il momento giusto per controllare i privilegi dell'operatore?

A: Dopo che lo stato della SIM ha caricato la trasmissione.

Gli OEM possono disabilitare parte delle API dell'operatore?

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

Non setOperatorBrandOverride sostituiscono tutte le altre forme di stringhe dei nomi dell'operatore? Ad esempio, SE13, UICC SPN o NITZ basato su rete?

R: Fare riferimento alla voce SPN in TelephonyManager

Che cosa significa injectSmsPdu chiamata al metodo fare?

R: Questo metodo facilita il backup/ripristino degli SMS nel cloud. injectSmsPdu chiamata attiva la funzione di ripristino.

Per il filtraggio SMS, è onFilterSms chiamata in base filtraggio delle porte SMS UDH? Oppure le app dell'operatore hanno accesso a TUTTI gli SMS in arrivo?

R: I gestori hanno accesso a tutti i dati SMS.

L'estensione della DeviceAppID-REF-DO per supportare 32 byte appare incompatibile con l'attuale GP spec (che permette 0 o 20 byte solo), quindi perché stai introducendo questo cambiamento? SHA-1 non è sufficiente per evitare collisioni? Hai già proposto questa modifica a GP, poiché potrebbe essere incompatibile all'indietro con l'ARA-M/ARF esistente?

R: Per garantire la 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), non si applica la regola per tutti i dispositivi non apps coperto da una norma specifica?

A: API Carrier richiedono DeviceAppID-REF-DO essere popolato. Essere vuoto è destinato a scopi di test e non è consigliato per le distribuzioni operative.

Secondo la vostra spec, PKG-REF-DO usato proprio da sola, senza DeviceAppID-REF-DO , non dovrebbe essere accettato. Ma è ancora descritto nella Tabella 6-4 estendendo la definizione di REF-DO . è apposta? Come funziona il codice si comportano quando soltanto PKG-REF-DO è utilizzato in REF-DO ?

A: La possibilità di avere PKG-REF-DO come un unico elemento valore REF-DO è stato rimosso nella versione più recente. PKG-REF-DO deve avvenire solo in combinazione con DeviceAppID-REF-DO .

Partiamo dal presupposto che possiamo concedere l'accesso a tutte le autorizzazioni basate sull'operatore telefonico o 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 accettiamo suggerimenti.

Si può definire ulteriormente DeviceAppID per Android in particolare? Questo è il valore hash SHA-1 (20 byte) del certificato dell'editore utilizzato per firmare l'app specificata, quindi il nome non dovrebbe riflettere quello scopo? (Il nome potrebbe confondere molti lettori poiché la regola è quindi applicabile a tutte le app firmate con lo stesso certificato Publisher.)

A: I DeviceAppID certificati memorizzazione è supportato dalle specifiche esistenti. Abbiamo cercato di ridurre al minimo le modifiche alle specifiche per abbassare la barriera all'adozione. Per dettagli, vedere Regole di UICC .