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 La piattaforma Android carica i certificati archiviati su un UICC e concede l'autorizzazione a 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 dei privilegi degli operatori UICC, aumentando notevolmente il numero di operatori che possono utilizzare le API. Per un riferimento all'API, consulta CarrierConfigManager; per le istruzioni, consulta Carrier Configuration.

Gli operatori hanno il controllo completo dello UICC, quindi questo meccanismo fornisce una un modo sicuro e flessibile per gestire le app dall'operatore di rete mobile (MNO) ospitati su canali di distribuzione generici di app (come Google Play) mentre che conservano privilegi speciali sui dispositivi e senza la necessità di firmare le app con il certificato della piattaforma per dispositivo o preinstallarla come app di sistema.

Regole relative alla UICC

Lo spazio di archiviazione sulla UICC è compatibile con la specifica di controllo dell'accesso all'elemento di sicurezza GlobalPlatform. L'identificatore app (AID) sulla scheda è A00000015141434C00 e il comando standard GET DATA viene utilizzato per recuperare le regole memorizzate nella scheda. Puoi aggiornare queste regole tramite aggiornamenti OTA (card over-the-air).

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) ed è costituito da 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) archivia l'algoritmo SHA-1 (20 byte) o una firma SHA-256 (32 byte) del certificato.
    • PKG-REF-DO (CA) è la stringa del nome completo del pacchetto definita nel file manifest, con codifica ASCII e lunghezza massima di 127 byte.
  • AR-DO (E3) viene esteso per includere PERM-AR-DO (DB), che è una maschera di bit di 8 byte che rappresenta 64 autorizzazioni distinte.

Se PKG-REF-DO non è presente, qualsiasi app firmata dal certificato se un utente dispone dell'autorizzazione di accesso. altrimenti sia il certificato che il nome del pacchetto corrispondono.

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 sull'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 A00000015141434C00 dell'applicazione di regole di accesso (ARA). Se non trova l'AID sulla UICC, quest'ultimo torna all'ARF selezionando l'AID PKCS15 A000000063504B43532D3135. Android legge quindi file delle regole di controllo dell'accesso (ACRF) all'indirizzo 0x4300 e cerca le voci con AID FFFFFFFFFFFF. Le voci con AID diversi vengono ignorate, quindi per altri casi d'uso possono coesistere.

Esempio di contenuto ACRF nella 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 dell'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 vengono concessi i privilegi dell'operatore.

API abilitate

Android supporta le API riportate di seguito.

TelephonyManager

TelephonyCallback

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

Gestore abbonamenti

Gestore SMS

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

BugreportManager

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

GestoreStats

ImsMmTelManager

ImsRcsManager

ProvisioningManager

Gestore Euicc

Metodo per passare all'abbonamento specificato (attivarlo): switchToSubscription

Servizio di messaggistica dell'operatore

Servizio che riceve chiamate dal sistema quando vengono inviati nuovi SMS ed MMS ricevuto. Per estendere questa classe, dichiara il servizio nel file manifest con android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE e includi un filtro per intent con #SERVICE_INTERFACE un'azione. I metodi includono:

  • Metodo per filtrare i messaggi SMS in entrata: onFilterSms
  • Metodo per intercettare messaggi SMS inviati dal dispositivo: onSendTextSms
  • Metodo per intercettare i messaggi SMS binari inviati dal dispositivo: onSendDataSms
  • Metodo per intercettare lunghi messaggi SMS 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 questo corso, 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'associazione di lunga durata, imposta Da android.service.carrier.LONG_LIVED_BINDING a true nei metadati del servizio.

La piattaforma associa CarrierService a flag speciali per consentire il processo di servizio del corriere eseguito in uno speciale del bucket in standby dell'app. In questo modo l'app di servizio dell'operatore viene esclusa limitazione relativa all'inattività delle app e le rende più attive quando il dispositivo è in esaurimento. 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 il legame non viene reintegrato. È quindi fondamentale mantenere stabile l'app del servizio dell'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 modifica intenzionale della rete dell'operatore da parte dell'app dell'operatore: notifyCarrierNetworkChange

Fornitore di telefonia

API del fornitore di contenuti per consentire le modifiche (inserimento, eliminazione, aggiornamento, query) al database della telefonia. I campi dei valori sono definiti Telephony.Carriers; per ulteriori dettagli, consulta il riferimento del corso Telephony

Suggerimento rete Wi-Fi

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

Piattaforma Android

Su un UICC rilevato, la piattaforma genera oggetti UICC interni che Includere regole sui privilegi dell'operatore come parte della UICC. UiccCarrierPrivilegeRules.java carica le regole, le analizza dalla scheda UICC e le memorizza nella cache in memoria. Quando è necessaria una verifica dei privilegi, UiccCarrierPrivilegeRules confronta il certificato dell'autore della chiamata con le proprie regole una per una. Se la UICC viene rimossa, le regole vengono distrutte insieme all'oggetto UICC.

Convalida

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

Prepara 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.

Eseguire i test dell'API dell'operatore CTS in Android 12, il dispositivo deve utilizzare una SIM con l'operatore CTS che soddisfano i requisiti specificati nella versione più recente di la terza parte Specifica del profilo di test GSMA TS.48.

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

Modificare il profilo SIM CTS

  1. Aggiungi: privilegi dell'operatore CTS in app master (ARA-M) o ARF per la regola di accesso. Entrambe le firme devono essere codificati nelle regole dei privilegi dell'operatore:
    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 ADF USIM elementari (EF) non presenti in TS.48 e richiesti per CTS:
    1. EF_MBDN (6FC7), dimensione record: 28, numero record: 4
      • Content (Contenuti)
        1. Rec1: 566F696365204D61696CFFFFFFFF0691515555555FF…FF
        2. Rec2-n: FF…FF
    2. EF_EXT6 (6FC8), dimensione record:13, numero record: 1
      • Contenuti: 00FF…FF
        1. EF_MBI (6FC9), dimensione record: 4, numero di record: 1
      • Contenuto: Rec1: 01010101
        1. EF_MWIS (6FCA), dimensione record: 5, numero di record: 1
      • Contenuti: 0000000000
  3. Modifica: tabella dei servizi USIM: attiva i servizi n. 47 e 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

Abbina la struttura del profilo di test

Scarica e abbina la versione più recente delle seguenti strutture di profili di test generici. Per questi profili non verrà personalizzata la regola CTS Carrier Privilege né verranno apportate altre modifiche elencate sopra.

Esegui test

Per praticità, CTS supporta un token del dispositivo che limita in modo che vengano eseguiti solo su 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 del 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: Usa il meccanismo di aggiornamento OTA della carta esistente.

L'UICC può coesistere con altre regole?

R: Non è un problema avere altre regole di sicurezza nell'UICC con lo stesso AID; la piattaforma le filtra automaticamente.

Cosa succede quando lo UICC viene rimosso per un'app che si basa sul certificati?

R: L'app perde i suoi privilegi a causa delle regole associate al UICC viene eliminato alla rimozione UICC.

Esiste un limite al numero di certificati sulla UICC?

R: La piattaforma non limita il numero di certificati; ma poiché Il controllo è lineare, troppe regole possono 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 per le quali l'utilizzo di questo metodo è vietato? Se sì, come li applichi? (ovvero, hai test per convalidare quali API sono supportate con questo metodo?)

R: consulta la sezione Comportamento compatibile con le API del Compatibility Definition Document (CDD) di Android. Abbiamo dei test CTS per assicurarci di autorizzazione delle API rimane invariato.

Come funziona con la funzionalità multi-SIM?

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

Questa tecnologia interagisce o si sovrappone in qualche modo ad altre tecnologie di accesso ai SE, ad esempio SEEK?

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

Qual è un buon momento per verificare i privilegi dell'operatore?

R: Dopo il caricamento dello stato della SIM, la trasmissione.

Gli OEM possono disattivare parte delle API dell'operatore?

R: No. Riteniamo che le API attuali siano l'insieme minimo e prevedono di utilizzare la maschera di bit per un controllo più granulare in futuro.

setOperatorBrandOverride sostituisce TUTTE le altre forme di stringhe di nomi di operatori? Ad esempio, SE13, SPN UICC o NITZ basato sulla rete?

Sì, l'override del brand dell'operatore ha la massima priorità. Una volta impostato, sostituisce TUTTI con altre forme di stringhe con i nomi degli operatori.

A cosa serve la chiamata al metodo injectSmsPdu?

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

Per il filtro degli SMS, la chiamata onFilterSms si basa sul filtro delle porte UDH degli SMS? Oppure le app degli operatori 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 essere incompatibile con le specifiche GP attuali (che consentono solo 0 o 20 byte). Perché state 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?

R: per garantire una sicurezza adatta al futuro, questa estensione introduce SHA-256 per DeviceAppID-REF-DO, oltre a SHA-1, che al momento è 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 che DeviceAppID-REF-DO sia compilato. Il campo vuoto è a scopo di test e non è consigliato per scopi operativi deployment di machine learning.

Secondo le tue specifiche, PKG-REF-DO utilizzato da solo, senza DeviceAppID-REF-DO, non deve essere accettato. Tuttavia, nella tabella 6-4 della specifica è ancora descritto come un'estensione della definizione di REF-DO. È intenzionale? In che modo il codice Si comportano quando solo PKG-REF-DO viene utilizzato in REF-DO?

R: l'opzione di avere PKG-REF-DO come singolo elemento di valore in REF-DO è stata rimossa nell'ultima versione. PKG-REF-DO deve 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ù 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? 64 autorizzazioni separate sono sufficienti nel lungo periodo?

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

Puoi definire ulteriormente DeviceAppID per Android in modo specifico? Questo è il valore hash SHA-1 (20 byte) del publisher. utilizzato per firmare l'app in questione, quindi il nome non dovrebbe rispecchiare che che non ha uno scopo specifico? (Il nome potrebbe confondere molti lettori, in quanto la regola è quindi applicabile a tutte le app firmate con lo stesso certificato del publisher.)

R: Il DeviceAppID per l'archiviazione dei certificati è supportato dalla specifica esistente. Abbiamo cercato di ridurre al minimo le modifiche alle specifiche per abbassare la barriera e all'adozione dei nuovi strumenti. Per maggiori dettagli, consulta l'articolo Regole per UICC.