Android 10 modifica le autorizzazioni di
per proteggere tutti gli identificatori dei dispositivi mediante
l'autorizzazione READ_PRIVILEGED_PHONE_STATE
. Prima del
Android 10, identificatori dei dispositivi persistenti
(IMEI/MEID, IMSI, SIM e numero seriale) erano protetti tramite
Autorizzazione di runtime READ_PHONE_STATE
.
L'autorizzazione READ_PRIVILEGED_PHONE_STATE
è disponibile
concesse alle app firmate con la chiave della piattaforma e alle app di sistema con privilegi.
Per ulteriori informazioni sui nuovi requisiti di autorizzazione, consulta la Pagine Javadoc per TelephonyManager.java e Build.java.
Questa modifica interessa le seguenti API:
- TelephonyManager#getDeviceId
- TelephonyManager#getImei
- TelephonyManager#getMeid
- TelephonyManager#getSimSerialNumber
- TelephonyManager#getSubscriberId
- Build#getSerial
Accesso alle app dell'operatore senza autorizzazione READ_PRIVILEGED_PHONE_STATE
App dell'operatore precaricate che non sono idonee per
READ_PRIVILEGED_PHONE_STATE
può implementare una delle opzioni indicate nella tabella seguente.
Opzione | Descrizione | Limitazioni |
---|---|---|
Privilegi degli operatori UICC | La piattaforma Android carica i certificati archiviati nell'UICC e concede l'autorizzazione alle app firmate da questi certificati per effettuare chiamate a di machine learning. | Gli operatori precedenti dispongono di un ampio e consolidato numero di SIM, che non facilmente aggiornabili. Inoltre, gli operatori che non dispongono dei diritti di authoring per i nuovi Le SIM (ad esempio, gli MVNO con SIM emesse dagli MNO) non possono aggiungere o aggiorna i certificati sulle SIM. |
Inserimento nella lista consentita degli OEM | Gli OEM possono utilizzare OP_READ_DEVICE_IDENTIFIER per fornire il dispositivo
alle app dell'operatore incluse nella lista consentita. |
Questa soluzione non è scalabile per tutti gli operatori. |
Codice di allocazione del tipo (TAC) | Utilizza la
getTypeAllocationCode
, introdotto in
Android 10, per esporre il TAC che restituisce il produttore e il modello.
informazioni. |
Le informazioni nel TAC non sono sufficienti per identificare un dispositivo specifico. |
MSISDN | Gli operatori possono utilizzare il numero di telefono (MSISDN), disponibile in
TelephonyManager con l'autorizzazione PHONE
per cercare l'IMEI nei sistemi di backend. |
Ciò richiede un investimento significativo per gli operatori. Operatori che mappano e le chiavi di rete usando IMSI richiedono risorse tecniche per passare a MSISDN. |
Tutte le app dell'operatore possono accedere agli identificatori dei dispositivi tramite l'aggiornamento
il file CarrierConfig.xml
con l'hash del certificato di firma
l'app dell'operatore. Quando l'app dell'operatore chiama un metodo per la lettura dei privilegi
informazioni, la piattaforma cerca una corrispondenza con il certificato di firma dell'app
(firma SHA-1 o SHA-256 del certificato) nella
CarrierConfig.xml
file. Se viene trovata una corrispondenza, l'oggetto
quando le informazioni vengono restituite. Se non viene trovata alcuna corrispondenza, viene applicata un'eccezione di sicurezza
restituito.
Per implementare questa soluzione, gli operatori DEVONO seguire questi passaggi:
- Aggiorna
CarrierConfig.xml
con l'hash del certificato di firma del l'app dell'operatore e invia una patch. - Richiedi agli OEM di aggiornare la build con QPR1+ (opzione consigliata) OPPURE questi
le patch della piattaforma richieste e quella contenente
ha aggiornato
CarrierConfig.xml
file dal passaggio 1 precedente.
Implementazione
Aggiorna la lista consentita di autorizzazioni con privilegi per concedere
Autorizzazione READ_PRIVILEGED_PHONE_STATE
per gli utenti con privilegi
app che richiedono l'accesso agli identificatori dei dispositivi.
Per scoprire di più sull'inserimento nella lista consentita, consulta la sezione Con privilegi Autorizzazione alla lista consentita.
Per richiamare le API interessate, un'app deve soddisfare uno dei seguenti requisiti: requisiti:
- Se l'app è un'app con privilegi precaricata, deve avere il
READ_PRIVILEGED_PHONE_STATE
autorizzazione dichiarata in AndroidManifest.xml. L'app deve anche essere inclusa nella lista consentita questa autorizzazione con privilegi. - Le app distribuite tramite Google Play richiedono i privilegi dell'operatore. Scopri di più sulla concessione dei privilegi dell'operatore nell'operatore UICC Privilegi.
- Un'app del proprietario di un dispositivo o di un profilo a cui è stato concesso il
Autorizzazione
READ_PHONE_STATE
.
Un'app che non soddisfa nessuno di questi requisiti ha i seguenti requisiti comportamento:
- Se l'app ha come target pre-Q e non presenta
Autorizzazione
READ_PHONE_STATE
concessa,SecurityException
viene attivato. questo è il comportamento precedente alla domanda come questa autorizzazione per richiamare queste API. - Se l'app ha come target l'opzione pre-Q e presenta
Autorizzazione
READ_PHONE_STATE
concessa, riceve un valore nullo per tutte le API TelephonyManager eBuild.UNKNOWN
per il metodoBuild#getSerial
. - Se l'app ha come target Android 10 o versioni successive e non soddisfa nessuno dei nuovi di sicurezza, riceve un'eccezione SecurityException.
Convalida e test
La Compatibilità La Test Suite (CTS) include test per verificare l'identificatore del dispositivo previsto comportamento di accesso per le app con privilegi di operatore, dispositivo e proprietari del profilo e le app che non dovrebbero avere accesso al dispositivo o identificatori univoci.
I seguenti test CTS sono specifici per questa funzionalità.
cts-tradefed run cts -m CtsCarrierApiTestCases -t android.carrierapi.cts.CarrierApiTest
cts-tradefed run cts -m CtsTelephonyTestCases -t android.telephony.cts.TelephonyManagerTest
cts-tradefed run cts -m CtsTelephony3TestCases
cts-tradefed run cts -m CtsPermissionTestCases -t android.permission.cts.TelephonyManagerPermissionTest
cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testDeviceOwnerCanGetDeviceIdentifiers
cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.ManagedProfileTest#testProfileOwnerCanGetDeviceIdentifiers
cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.ManagedProfileTest#testProfileOwnerCannotGetDeviceIdentifiersWithoutPermission
cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testDeviceOwnerCannotGetDeviceIdentifiersWithoutPermission
Domande frequenti
Quante app possono essere inserite nella lista consentita in CarrierConfig.xml
per un determinato (Centro clienti, MNC)?
Non c'è limite al numero di hash dei certificati inclusi nell'array.
Quali parametri CarrierConfig devo utilizzare in CarrierConfig.xml
affinché un'app venga inclusa nella lista consentita?
Utilizza il seguente elemento di configurazione di primo livello nell'ambito
CarrierConfig.xml
dalle opzioni AOSP che stai configurando:
<string-array name="carrier_certificate_string_array" num="2"> <item value="BF02262E5EF59FDD53E57059082F1A7914F284B"/> <item value="9F3868A3E1DD19A5311D511A60CF94D975A344B"/> </string-array>
Esiste un modello CarrierConfig di base che posso utilizzare?
Utilizza il seguente modello. Dovrebbe essere aggiunto al asset pertinente.
<?xml version="1.0" encoding="utf-8" standalone="yes"?> <carrier_config> <string-array name="carrier_certificate_string_array" num="1"> <item value="CERTIFICATE_HASH_HERE"/> </string-array> </carrier_config>
La SIM dell'operatore deve essere inserita nel dispositivo per accedere agli identificatori del dispositivo?
Il valore di CarrierConfig.xml
utilizzato è determinato in base a
SIM attualmente inserita. Ciò significa che se l'app dell'operatore X tenta di
ottenere privilegi di accesso mentre la SIM dell'operatore Y è inserita, il dispositivo non troverà
per l'hash e restituisce un'eccezione di sicurezza.
Sui dispositivi multi-SIM, l'operatore n. 1 dispone soltanto dei privilegi di accesso per le SIM n. 1 e vice versa.
In che modo gli operatori convertono il certificato di firma di un'app in un hash?
Per convertire i certificati di firma in un hash prima di aggiungerli a
CarrierConfig.xml
, segui questi passaggi:
- Converti la firma del certificato di firma in un array di byte utilizzando
toByteArray
. - Utilizza
MessageDigest
per convertire l'array di byte in un hash byte[]. -
Converti l'hash da byte[] in un formato stringa esadecimale. Ad esempio, consulta
IccUtils.java
.List<String> certHashes = new ArrayList<>(); PackageInfo pInfo; // Carrier app PackageInfo MessageDigest md = MessageDigest.getInstance("SHA-256"); for (Signature signature : pInfo.signatures) { certHashes.add(bytesToHexString(md.digest(signature.toByteArray())); }
Se
certHashes
è un array di dimensioni2
con un valore di12345
e54321
, aggiungi quanto segue alla di configurazione del gestore telefonico.<string-array name="carrier_certificate_string_array" num="2"> <item value="12345"/> <item value="54321"/> </string-array>