In Android 11, gli aggiornamenti OTA possono essere applicati utilizzando l'aggiornamento A/B o di aggiornamento A/B virtuale, in combinazione con RecoverySystem metodi della classe. Al riavvio di un dispositivo per applicare un aggiornamento OTA: La funzionalità Riprendi al riavvio (RoR) sblocca lo spazio di archiviazione con crittografia CE del dispositivo.
Sebbene i partner possano abbinare questa procedura a una funzionalità di sistema OTA applicabile si aggiorna quando il dispositivo dovrebbe rimanere inattivo in Android 11, in I partner di Android 12 non hanno bisogno di un sistema OTA aggiuntivo funzionalità. Il processo RoR fornisce maggiore sicurezza e comodità agli utenti perché gli aggiornamenti possono essere effettuati durante i tempi di inattività, mentre Android 12 le funzionalità di aggiornamento multi-client e basate su server insieme forniscono della sicurezza a livello di hardware.
Devi però fornire l'autorizzazione di accesso al dispositivo per android.hardware.reboot_escrow
per supportare il RoR in Android 11, non è necessario farlo per abilitare
il RoR basato su server in Android 12 e versioni successive,
non utilizzano l'HAL.
Premessa
A partire da Android 7, Android supportava l'Avvio diretto, che consente alle app su un dispositivo di avviarsi prima che l'archiviazione CE venga sbloccata per l'utente. L'implementazione del supporto dell'Avvio diretto ha fornito agli utenti una migliore precedente prima dell'inserimento del fattore di conoscenza della schermata di blocco (LSKF) dopo l'avvio.
La funzionalità RoR consente di sbloccare l'archiviazione CE di tutte le app su un dispositivo, inclusi quelle che non supportano l'Avvio diretto, quando viene avviato un riavvio in seguito a aggiornamento OTA. Questa funzionalità consente agli utenti di ricevere notifiche da tutti i loro dopo il riavvio.
Modello di minaccia
L’implementazione del RoR deve garantire che quando un dispositivo rientri nella mano, è estremamente difficile per l'aggressore recuperare la crittografia lato client dell'utente dati criptati, anche se il dispositivo è acceso, l'archiviazione CE è sbloccata e Il dispositivo viene sbloccato dall'utente dopo aver ricevuto un aggiornamento OTA. Addetto ai lavori la resistenza agli attacchi deve essere efficace anche se l'aggressore ottiene l'accesso al per la trasmissione delle chiavi di firma crittografica.
Nello specifico, l'archiviazione CE non deve essere letta da un utente malintenzionato che ha fisicamente dispositivo e presenta le seguenti funzionalità e limitazioni:
Funzionalità
- Puoi usare la chiave di firma di qualsiasi fornitore o azienda per firmare messaggi arbitrari.
- Il dispositivo potrebbe ricevere un aggiornamento OTA.
- Può modificare il funzionamento di qualsiasi hardware (ad esempio un processore di applicazioni, o memoria flash), ad eccezione di quanto descritto nella sezione Limitazioni di seguito. (Tuttavia, tale modifica comporta un ritardo di almeno un'ora e un e riaccensione e spegnimento che distruggi i contenuti della RAM).
Limitazioni
- Non può modificare il funzionamento dell'hardware antimanomissione (ad esempio, una Titan M).
- Impossibile leggere la RAM del dispositivo in uso.
- Non può indovinare le credenziali dell'utente (PIN, sequenza, password) o causare in altro modo da inserire.
Soluzione
Il sistema di aggiornamento RoR di Android 12 garantisce la sicurezza contro i malintenzionati più sofisticati, e lo fa quando le password sul dispositivo I PIN rimangono sul dispositivo e non vengono mai inviati ai server di Google né memorizzati sui server. Questo una panoramica del processo che garantisce che i livelli di sicurezza forniti siano in modo simile a un sistema RoR a livello di dispositivo e basato su hardware:
- Android applica protezioni crittografiche ai dati archiviati su un dispositivo.
- Tutti i dati sono protetti da chiavi archiviate nell'ambiente di esecuzione attendibile (TEE).
- Il TEE rilascia le chiavi solo se il sistema operativo in esecuzione supera autenticazione crittografica (avvio verificato).
- Il servizio RoR in esecuzione sui server Google protegge i dati CE archiviando un secret che è possibile recuperare solo per un periodo di tempo limitato. Questa opzione funziona in tutto l'ecosistema Android.
- Una chiave di crittografia, protetta dal PIN di un utente, viene utilizzata per sbloccare il dispositivo
e decriptare l'archiviazione CE.
- Quando viene programmato un riavvio notturno, Android chiede all'utente di inserire il PIN, quindi calcola una password sintetica (SP).
- Quindi cripta l'SP due volte: una con una chiave
K_s
archiviata nella RAM e di nuovo con una chiaveK_k
archiviata in TEE. - L'SP con doppia crittografia è archiviato su disco e l'SP viene cancellato dalla RAM. Entrambe le chiavi sono state generate di recente e utilizzate per un solo riavvio.
- Al momento del riavvio, Android affida
K_s
al server. La ricevuta conK_k
viene criptato prima di essere archiviato su disco. - Dopo il riavvio, Android utilizza
K_k
per decriptare la ricevuta, quindi la invia a il server per recuperareK_s
.K_k
eK_s
vengono utilizzati per decriptare l'SP archiviato sul disco.- Android utilizza l'SP per sbloccare lo spazio di archiviazione CE e consentire il normale avvio dell'app.
K_k
eK_s
vengono eliminati.
Gli aggiornamenti per proteggere il tuo smartphone possono avvenire in un momento conveniente per te: mentre dormi.
Riproduzione PIN SIM
In determinate condizioni, il codice PIN di una scheda SIM viene verificato da una cache, tramite una procedura chiamata ripetizione PIN della SIM.
Una scheda SIM con un PIN attivo deve inoltre essere sottoposta a un codice PIN senza interruzioni verifica (riproduzione del PIN della SIM) dopo un riavvio automatico per ripristinare la rete cellulare Connettività (necessaria per telefonate, SMS e servizi dati). Il PIN della SIM e le relative informazioni corrispondenti (ICCID e slot della SIM) di Google) vengono archiviati insieme in modo sicuro. Il PIN memorizzato può essere recuperato e utilizzato per la verifica solo dopo un riavvio automatico riuscito. Se il dispositivo è protetto, il PIN della SIM viene memorizzato con chiavi protette dall'LSKF. Se la SIM ha PIN abilitato, l'interazione con il server RoR richiede una connessione Wi-Fi per l'aggiornamento OTA e il RoR basato su server, che garantisce la funzionalità di base (con rete cellulare) dopo il riavvio.
Il PIN della SIM viene criptato e memorizzato nuovamente ogni volta che l'utente abilita la verifica o la modifica. Il PIN della SIM viene ignorato se: si verifica:
- La SIM è stata rimossa o reimpostata.
- L'utente disattiva il PIN.
- Si è verificato un riavvio non avviato da RoR.
Il PIN della SIM memorizzato può essere utilizzato solo una volta dopo il riavvio Avviato dal sistema RoR. solo per un periodo di tempo molto breve (20 secondi), se i dettagli della SIM corrispondenza di schede. Il PIN della SIM memorizzata non viene mai trasferito dall'app TelephonyManager non possono essere recuperati da moduli esterni.
Linee guida per l'implementazione
In Android 12, il RoR multi-client e basato su server forniscono un carico più leggero ai partner quando pubblicano gli aggiornamenti OTA. Gli aggiornamenti necessari possono avvenire durante i comodi tempi di inattività del dispositivo, ad esempio durante le ore di sonno designate.
Per assicurarti che gli aggiornamenti OTA durante questi periodi di tempo non interrompano gli utenti,
Impiegare la modalità Buio per ridurre le emissioni di luce. Per farlo, chiedi al dispositivo
ricerca bootloader per il motivo della stringa unattended
. Se unattended
è true
,
attivare la modalità Buio sul dispositivo. Tieni presente che è responsabilità di ogni OEM
mitigare le emissioni sonore e luminose.
Se esegui l'upgrade ad Android 12 o avvii Sui dispositivi Android 12, non devi fare nulla di implementare la nuova funzionalità RoR.
C'è una nuova chiamata nel flusso multi-cliente: isPreparedForUnattendedUpdate
,
come mostrato di seguito:
@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)
Non è necessario implementarla perché l'HAL è stato ritirato a partire dal giorno Android 12.
Gestore telefonia
Il client OTA richiama l'API di sistema TelephonyManager
quando è imminente un riavvio
in Android 12. Questa API sposta tutti i codici PIN memorizzati nella cache da
dallo stato AVAILABLE
allo stato REBOOT_READY
. Il sistema TelephonyManager
L'API è protetta dall'elemento REBOOT
esistente
Autorizzazione dei file manifest.
/**
* The unattended reboot was prepared successfully.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_SUCCESS = 0;
/**
* The unattended reboot was prepared, but the user will need to manually
* enter the PIN code of at least one SIM card present in the device.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED = 1;
/**
* The unattended reboot was not prepared due to generic error.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_ERROR = 2;
/** @hide */
@Retention(RetentionPolicy.SOURCE)
@IntDef(prefix = {"PREPARE_UNATTENDED_REBOOT_"},
value = {
PREPARE_UNATTENDED_REBOOT_SUCCESS,
PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED,
PREPARE_UNATTENDED_REBOOT_ERROR
})
public @interface PrepareUnattendedRebootResult {}
/**
* Prepare TelephonyManager for an unattended reboot. The reboot is
* required to be done shortly after the API is invoked.
*
* Requires system privileges.
*
* <p>Requires Permission:
* {@link android.Manifest.permission#REBOOT}
*
* @return {@link #PREPARE_UNATTENDED_REBOOT_SUCCESS} in case of success.
* {@link #PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED} if the device contains
* at least one SIM card for which the user needs to manually enter the PIN
* code after the reboot. {@link #PREPARE_UNATTENDED_REBOOT_ERROR} in case
* of error.
* @hide
*/
@SystemApi
@RequiresPermission(android.Manifest.permission.REBOOT)
@PrepareUnattendedRebootResult
public int prepareForUnattendedReboot()
L'API di sistema TelephonyManager viene utilizzata dagli APK con privilegi.
Test
Per testare la nuova API, esegui questo comando:
adb shell cmd phone unattended-reboot
Questo comando funziona solo quando la shell è in esecuzione come root (adb root
).
Solo Android 11
Il resto di questa pagina riguarda Android 11.
A partire da luglio 2020, le implementazioni del RoR HAL rientrano in due categorie:
- Se l'hardware del SoC supporta la persistenza della RAM tra i riavvii, gli OEM possono utilizzare implementazione predefinita in AOSP (Default RAM Escrow).
- Se l'hardware o il SoC del dispositivo supporta un'enclave hardware sicura (un insieme
coprocessore di sicurezza con la propria RAM e ROM), inoltre deve eseguire le
seguenti:
- Essere in grado di rilevare un riavvio principale della CPU.
- Avere un'origine timer hardware che persiste durante i riavvii. Vale a dire che enclave deve essere in grado di rilevare il riavvio e far scadere un timer impostato prima del riavvio.
- Supporto per l'archiviazione di una chiave depositata nella memoria RAM/ROM dell'enclave in modo che non possono essere recuperate con gli attacchi offline. Deve archiviare la chiave RoR in modo che impedisce agli addetti ai lavori o agli aggressori di recuperarlo.
Deposito a garanzia RAM predefinita
AOSP ha un'implementazione dell'HAL RoR utilizzando la persistenza della RAM. Affinché questo comando funzioni, gli OEM devono garantire che i SoC supportino la persistenza della RAM tra i riavvii. Alcuni SoC non sono in grado di rendere persistenti i contenuti della RAM durante un riavvio, Consigliamo agli OEM di consultare i propri partner SoC prima di attivare questo HAL predefinito. Il riferimento canonico a questo argomento nella sezione seguente.
Flusso di aggiornamento OTA tramite RoR
L'app client OTA sul telefono deve avere
Manifest.permission.REBOOT
e Manifest.permission.RECOVERY
per chiamare i metodi necessari
implementare il RoR. Con questo prerequisito, il flusso di una
l'aggiornamento segue questa procedura:
- L'app client OTA scarica l'aggiornamento.
- chiamate dell'app client OTA a
RecoverySystem#prepareForUnattendedUpdate
, attiva la richiesta all'utente del PIN, della sequenza o della password schermata di blocco al prossimo sblocco. - L'utente sblocca il dispositivo nella schermata di blocco e il dispositivo è pronto per applicare l'aggiornamento.
- chiamate dell'app client OTA a
RecoverySystem#rebootAndApply
, che vengono immediatamente un riavvio.
Al termine di questo flusso, il dispositivo si riavvia e il RoR sblocca l'archiviazione con crittografia delle credenziali (CE). Per le app, questo appare come un normale sblocco dell'utente, quindi riceve tutti i segnali, come ACTION_LOCKED_BOOT_COMPLETED e AZIONE_BOOT_COMPLETATA che fanno normalmente.
Modificare le configurazioni dei prodotti
Un prodotto contrassegnato come supporto della funzionalità RoR in Android 11 deve includere un dell'HAL RiavviaEscrow e includi il file XML degli indicatori di funzionalità. L'implementazione predefinita funziona bene sui dispositivi che utilizzano il riavvio a caldo (quando l'alimentazione della DRAM rimane accesa durante il riavvio).
Indicatore della funzione di riavvio del deposito a garanzia
L'indicatore degli elementi deve essere presente anche:
PRODUCT_COPY_FILES += \
frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml
Implementazione predefinita dell'HAL per il reboot escrow
Per utilizzare l'implementazione predefinita, è necessario prenotare 65.536 (0x10000) byte. Mai scrivere questi byte nello spazio di archiviazione permanente per garantire che le proprietà di sicurezza rimangono invariate.
Modifiche alla struttura ad albero dei dispositivi kernel Linux
Nella struttura dei dispositivi del kernel Linux, devi riservare la memoria per una regione pmem
.
L'esempio seguente mostra che 0x50000000
è prenotato:
reserved-memory {
my_reservation@0x50000000 {
no-map;
reg = <0x50000000 0x10000>;
}
}
reboot_escrow@0 {
compatible = "pmem-region";
reg = <0x50000000 0x10000>;
};
Verifica di avere un nuovo dispositivo nella directory dei blocchi con un nome simile a
/dev/block/pmem0
(ad esempio pmem1
o pmem2
).
Modifiche device.mk
Supponendo che il nuovo dispositivo del passaggio precedente sia denominato pmem0
, devi
assicurati che le nuove voci seguenti vengano aggiunte a vendor/<oem>/<product>/device.mk
:
# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
android.hardware.rebootescrow-service.default
Regole SELinux
Aggiungi queste nuove voci alle file_contexts
del dispositivo:
/dev/block/pmem0 u:object_r:rebootescrow_device:s0
/vendor/bin/hw/android\.hardware\.rebootescrow-service\.default u:object_r:hal_rebootescrow_default_exec:s0