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 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 le istruzioni, vedere Configurazione del gestore.

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 su 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 delle carte over-the-air (OTA).

Gerarchia dei dati

Le regole UICC utilizzano la seguente gerarchia di dati (la combinazione di due caratteri e numero 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 del pacchetto completo definita nel manifest, codificata ASCII, lunghezza massima 127 byte.
  • AR-DO ( E3 ) è stato esteso per includere PERM-AR-DO ( DB ), che è una maschera di bit a 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 su UICC nella stringa esadecimale è:

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

Accedi al supporto del file delle regole

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'applicazione regola 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 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 nella 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.

Gestore di telefonia

Richiamata telefonica

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

Subscription Manager

SMS Manager

Gestore configurazione portante

  • Metodo per notificare la configurazione modificata: 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 del gestore .

Bug report Manager

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

ImsMmTel Manager

ImsRcs Manager

Responsabile dell'approvvigionamento

Euicc Manager

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

Servizio di messaggistica dell'operatore

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 intento 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 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 del vettore. 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 intento 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 con flag speciali per consentire l'esecuzione del processo del servizio del corriere in uno speciale bucket di standby dell'app . Ciò esenta l'app del servizio del corriere dalla restrizione di inattività dell'app e rende più probabile 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 di cui sopra fino al riavvio dell'app e al ristabilimento dell'associazione. Quindi è fondamentale mantenere stabile l'app del servizio operatore.

I metodi in CarrierService includono:

  • Per ignorare e impostare le configurazioni specifiche del vettore: onLoadConfig
  • Per informare il sistema di una modifica intenzionale della rete del vettore da parte dell'applicazione del vettore: notifyCarrierNetworkChange

Gestore 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 alla classe Telephony di riferimento

Suggerimenti per la rete Wi-Fi

Quando si crea un oggetto WifiNetworkSuggestion , utilizzare i seguenti metodi per impostare un ID 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 una per una. Se l'UICC viene rimosso, le regole vengono distrutte insieme all'oggetto UICC.

Convalida

Per convalidare l'implementazione tramite Compatibility Test Suite (CTS) utilizzando CtsCarrierApiTestCases.apk , è necessario disporre di un UICC sviluppatore con le regole UICC corrette o il supporto ARF. Chiedi al fornitore della scheda SIM di tua scelta di preparare un UICC per sviluppatori con l'ARF corretto come descritto in questa sezione e utilizza 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 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 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 del profilo di test GSMA TS.48 di terze parti.

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

Modifica del profilo SIM CTS

  1. Aggiungere: privilegi dell'operatore CTS nel master dell'applicazione delle regole di accesso (ARA-M) o ARF. Entrambe le firme devono essere codificate nelle regole dei 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
  2. Creare: File elementari (EF) ADF USIM 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
  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: usa la stringa del nome del vettore 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 con la struttura del profilo di prova

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

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 token del dispositivo seguente limita l'esecuzione dei test API del vettore 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 si possono aggiornare i certificati sull'UICC?

R: Usa 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 alla 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 potrebbero 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 al vettore.

Ci sono alcune API vietate dall'utilizzo di questo metodo? Se sì, come li fai rispettare? (ovvero, hai dei test per convalidare quali API sono supportate con questo metodo?)

R: Consulta la sezione Compatibilità comportamentale delle API del documento di definizione della compatibilità di 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. Quindi le regole coesistono e vengono filtrate da SEEK o UiccCarrierPrivileges .

Quando è un buon momento per controllare i privilegi dell'operatore?

R: Dopo la trasmissione dello stato della SIM caricata.

Gli OEM possono disabilitare parte delle API del vettore?

R: No. Riteniamo che le attuali API siano 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 sulla rete?

Sì, l'override del marchio dell'operatore ha la massima priorità. Quando è impostato, sovrascrive TUTTE le altre forme di stringhe dei nomi degli operatori.

Che 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 degli SMS, la chiamata onFilterSms è basata sul filtraggio della porta UDH degli SMS? O le app dell'operatore hanno accesso a TUTTI gli SMS in arrivo?

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

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

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 carrier richiedono che DeviceAppID-REF-DO sia popolato. Essere vuoto è inteso a scopo di test e non è consigliato per 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 della specifica come un'estensione della definizione di REF-DO . Questo è apposta? Come si comporta il codice quando PKG-REF-DO 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 avere un controllo più dettagliato. In tal caso, 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?

A: Questo è riservato per il futuro e accogliamo con favore i suggerimenti.

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

R: I certificati di archiviazione DeviceAppID sono supportati dalle specifiche esistenti. Abbiamo cercato di ridurre al minimo le modifiche alle specifiche per abbassare la barriera all'adozione. Per i dettagli, vedere Regole sull'UICC .