Migliori pratiche per la sicurezza del sistema

Questa sezione contiene consigli per garantire la sicurezza del sistema operativo e dei dispositivi Android principali.

Autenticazione biometrica

Acquisisci, archivia ed elabora attentamente i dati biometrici per l'autenticazione dell'utente. Dovresti:

  • Imporre il metodo di autenticazione principale prima di utilizzare qualsiasi altra forma di autenticazione (inclusa la biometria).
  • Richiedere una conferma esplicita per indicare l'intenzione quando si utilizzano modalità biometriche passive, come il riconoscimento facciale, per transazioni (ad esempio pagamenti) che coinvolgono chiavi legate all'autenticazione.
  • Richiedi il metodo di autenticazione principale ogni 72 ore.
  • Utilizza una pipeline completamente sicura per tutti i dati biometrici e la loro gestione.
  • Non inviare mai dati biometrici (incluse misurazioni grezze del sensore e funzionalità derivate) fuori dal dispositivo. Se possibile, conserva questi dati in un ambiente sicuro e isolato, come Trusted Execution Environment (TEE) o Secure Element.

I dispositivi con dati biometrici dovrebbero supportare l' API BiometricPrompt , che offre un'interfaccia comune e coerente affinché gli sviluppatori di app possano sfruttare l'autenticazione basata sulla biometria nelle loro app. Solo dati biometrici avanzati possono integrarsi con BiometricPrompt e le integrazioni devono seguire le linee guida CDD ( Android Compatibility Definition Document ).

Per ulteriori linee guida biometriche, vedere Linee guida per l'implementazione dell'HAL biometrico .

SELinux

SELinux fornisce la definizione e l'applicazione di gran parte del modello di sicurezza di Android. L'utilizzo corretto di SELinux è fondamentale per la sicurezza dei dispositivi Android e può aiutare a mitigare l'impatto delle vulnerabilità della sicurezza. Per questo motivo tutti i dispositivi Android dovrebbero implementare una solida politica SELinux .

  • Implementare una politica di privilegi minimi.
  • Evitare di concedere le autorizzazioni CAP_DAC_OVERRIDE , CAP_SYS_ADMIN e CAP_NET_ADMIN .
  • Non registrare i dati di sistema sulla scheda SD.
  • Utilizza i tipi forniti per l'accesso al driver, come gpu_device , audio_device , ecc.
  • Utilizza nomi significativi per processi, file e tipi SELinux.
    • Assicurarsi che le etichette predefinite non vengano utilizzate e che non venga loro concesso l'accesso.
  • La policy specifica per il dispositivo dovrebbe rappresentare il 5-10% della policy complessiva in esecuzione su un dispositivo. Le personalizzazioni nell'intervallo superiore al 20% quasi certamente contengono domini con privilegi eccessivi e policy obsolete. Una policy inutilmente grande spreca memoria, spreca spazio su disco rendendo necessaria un'immagine di avvio più grande e influisce negativamente sui tempi di ricerca della policy di runtime.

Caricamento dinamico della policy SELinux

Non caricare dinamicamente la policy SELinux sui dispositivi Android. Ciò potrebbe causare problemi come:

  • Impedire l'accettazione di patch di sicurezza critiche.
  • Esponendo la possibilità di eseguire il root di un dispositivo ricaricando le policy.
  • Esporre un vettore per attacchi man-in-the-middle contro il programma di aggiornamento delle policy.
  • Il risultato sono dispositivi in ​​muratura a causa di errori con gli aggiornamenti dei criteri.

Backdoor

Le app Android non dovrebbero avere backdoor o modi per accedere al sistema o ai dati che eludono i normali meccanismi di sicurezza. Ciò include l'accesso speciale alla diagnostica, al debug, allo sviluppo o alla riparazione in garanzia, protetto da segreti noti allo sviluppatore. Per evitare backdoor:

  • Esegui la scansione di tutte le app di terze parti utilizzando uno strumento di scansione delle vulnerabilità delle app riconosciuto nel settore.
  • Esegui revisioni del codice di tutto il codice con accesso sensibile, incluse le librerie di terze parti.
  • Utilizza Google Play Protect caricando app su Google Play per la scansione. Puoi caricare app per la scansione senza pubblicarle su Google Play.
  • Non precaricare strumenti incentrati sulla diagnostica o sulla riparazione nelle build di rilascio. Installa questi strumenti solo su richiesta per risolvere problemi specifici. Inoltre, questi strumenti non devono operare o caricare dati specifici dell'account.

Strumenti di sviluppo

Gli strumenti di sviluppo, come gli strumenti di debug, test e diagnostica, possono spesso creare lacune di sicurezza involontarie sul tuo dispositivo rivelando il modo in cui funzionano e i dati che raccolgono. Per assicurarti che gli strumenti di sviluppo non vengano inseriti nelle build di produzione:

  • Sviluppa una lista nera di hash degli strumenti di debug e test interni ed esegui la scansione delle build per questi APK prima di utilizzare l'immagine di sistema.
  • Esegui la scansione di tutte le app proprietarie utilizzando uno strumento di scansione delle vulnerabilità delle app riconosciuto nel settore.
  • Assumi una società di test di sicurezza delle app di terze parti per valutare tutte le app diagnostiche critiche sul dispositivo prima di qualsiasi aggiornamento importante, soprattutto se l'app è sviluppata da terze parti.
  • Assicurati che solo l'utente possa abilitare lo strumento, verbalmente o tramite chat, durante una sessione di supporto. Memorizza gli artefatti del consenso e disabilita lo strumento dopo aver raccolto le informazioni diagnostiche necessarie.
  • Archivia il record di utilizzo di questo strumento in un registro accessibile all'utente nel proprio account dell'operatore.
  • Garantire che tutte le informazioni di identificazione personale (PII) o i dati di telemetria del dispositivo raccolti dallo strumento siano soggetti alle pratiche di anonimizzazione, conservazione ed eliminazione pertinenti al Paese. Dovrebbero essere raccolti solo i dati rilevanti per la chiamata di supporto. Questi dati dovrebbero essere cancellati dopo ogni chiamata.
  • Assicurarsi che le tecniche che possono essere utilizzate per lo spyware, come la registrazione dei tasti premuti, l'utilizzo del microfono o l'utilizzo della fotocamera, non vengano utilizzate senza il consenso esplicito dell'utente. Le app che utilizzano questi metodi potenzialmente invasivi della privacy dovrebbero essere divulgate molto chiaramente insieme a un'informativa sulla privacy a cui l'utente deve acconsentire. App come questa non dovrebbero essere abilitate senza il consenso esplicito dell'utente.

Ecco alcuni suggerimenti aggiuntivi a cui fare riferimento quando si implementa l'informativa e il consenso:

Informativa in-app

  • Visualizza il normale utilizzo dell'app direttamente nell'app. Non è necessario che l'utente navighi in un menu o nelle impostazioni.
  • Descrivere il tipo di dati raccolti e spiegare come verranno utilizzati i dati.
  • Idealmente non incorporare queste informazioni in un'informativa sulla privacy o nei termini di servizio. Non includerlo con altre informative non correlate alla raccolta di dati personali o sensibili.
  • Il consenso deve essere affermativo. Non considerare come consenso l'allontanamento dall'informativa, compreso il tocco o la pressione del pulsante Indietro o Home.
  • Presenta la finestra di dialogo del consenso in modo chiaro e inequivocabile.
  • Richiedere un'azione affermativa da parte dell'utente, ad esempio toccare per accettare o pronunciare un comando per accettare.
  • Non raccogliere dati personali o sensibili prima di aver ottenuto il consenso affermativo.
  • Non utilizzare messaggi con chiusura automatica o con scadenza.

Funzionalità incorporata in AOSP

L'incorporamento di funzionalità aggiuntive in AOSP può spesso avere comportamenti e conseguenze imprevisti; procedi con cautela.

  • Assicurati che all'utente venga richiesto se desidera utilizzare app predefinite diverse (ad esempio motore di ricerca, browser Web, avvio) e divulgare l'invio dei dati dal dispositivo.
  • Assicurati che gli APK AOSP siano firmati con il certificato AOSP.
  • Esegui test di regressione e conserva un registro delle modifiche per determinare se agli APK AOSP è stato aggiunto del codice.

Aggiornamenti di sicurezza

I dispositivi Android dovrebbero ricevere un supporto di sicurezza continuo per almeno due anni dal lancio. Ciò include la ricezione di aggiornamenti regolari che risolvono le vulnerabilità di sicurezza note.

  • Collabora con i partner hardware, come i fornitori di SoC, per stipulare accordi di supporto adeguati per tutti i componenti del tuo dispositivo Android.
  • Assicurati che gli aggiornamenti di sicurezza possano essere installati con un'interazione minima da parte dell'utente per aumentare la probabilità che gli utenti accettino e installino gli aggiornamenti sul proprio dispositivo Android. Si consiglia vivamente di implementare aggiornamenti di sistema continui o una funzionalità di sicurezza equivalente.
  • Assicurati di comprendere i requisiti cumulativi del livello di patch di sicurezza Android (SPL) come dichiarato nel Bollettino sulla sicurezza di Android . Ad esempio, i dispositivi che utilizzano il livello di patch di sicurezza 2018-02-01 devono includere tutti i problemi associati a quel livello di patch di sicurezza, nonché le correzioni per tutti i problemi segnalati in tutti i bollettini di sicurezza precedenti.

Aggiornamenti dinamici del kernel

Non modificare dinamicamente i componenti critici del sistema. Sebbene alcune ricerche suggeriscano che gli aggiornamenti dinamici del kernel aiutano a proteggere dalle minacce di emergenza, il costo stimato attualmente supera i benefici. Crea invece un solido metodo di aggiornamento OTA per distribuire rapidamente le protezioni dalle vulnerabilità.

Gestione delle chiavi

Mantenere buone politiche e pratiche di gestione delle chiavi per garantire la sicurezza della firma delle chiavi.

  • Non condividere le chiavi di firma con soggetti esterni.
  • Se una chiave di firma viene compromessa, genera una nuova chiave e d'ora in poi esegui una doppia firma su tutte le app.
  • Conserva tutte le chiavi in ​​moduli hardware o servizi ad alta sicurezza che richiedono più fattori per l'accesso.

Firma dell'immagine di sistema

La firma dell'immagine del sistema è fondamentale per determinare l'integrità del dispositivo.

  • Non firmare dispositivi con una chiave nota pubblicamente.
  • Gestisci le chiavi di firma del dispositivo in modo coerente con le pratiche standard del settore per la gestione delle chiavi sensibili, incluso un modulo di sicurezza hardware (HSM) che fornisce un accesso limitato e verificabile.

Bootloader sbloccabili

Molti dispositivi Android supportano lo sblocco, consentendo al proprietario del dispositivo di modificare la partizione di sistema o installare un sistema operativo personalizzato. I casi d'uso comuni includono l'installazione di un'immagine di sistema di terze parti e l'esecuzione dello sviluppo a livello di sistema sul dispositivo. Ad esempio, per sbloccare l'immagine di sistema su Google Nexus o Pixel, un utente può eseguire fastboot oem unlock , che visualizza questo messaggio:

Come best practice, i dispositivi Android sbloccabili devono cancellare in modo sicuro tutti i dati dell'utente prima di essere sbloccati. La mancata eliminazione corretta di tutti i dati allo sblocco può consentire a un utente malintenzionato fisicamente vicino di ottenere l'accesso non autorizzato ai dati riservati degli utenti Android. Per impedire la divulgazione dei dati dell'utente, un dispositivo che supporta lo sblocco deve implementarlo correttamente.

  • Dopo che l'utente ha confermato il comando di sblocco, il dispositivo deve avviare un'immediata cancellazione dei dati. Il flag unlocked non deve essere impostato fino al completamento dell'eliminazione sicura.
  • Se non è possibile completare un'eliminazione sicura, il dispositivo deve rimanere in uno stato bloccato.
  • Se supportato dal dispositivo a blocchi sottostante, è necessario utilizzare ioctl(BLKSECDISCARD) o equivalente. Per i dispositivi MultiMediaCard incorporati (eMMC), ciò significa utilizzare un comando Secure Erase o Secure Trim. Per eMMC 4.5 e versioni successive, ciò significa utilizzare una normale operazione di cancellazione o taglio seguita da un'operazione di sanitizzazione.
  • Se BLKSECDISCARD non è supportato dal dispositivo a blocchi sottostante, è necessario utilizzare invece ioctl(BLKDISCARD) . Sui dispositivi eMMC, questa è una normale operazione di Trim.
  • Se BLKDISCARD non è supportato, è accettabile sovrascrivere i dispositivi a blocchi con tutti zeri.
  • Un utente deve avere la possibilità di richiedere la cancellazione dei dati utente prima di eseguire il flashing di una partizione. Ad esempio, i dispositivi Nexus utilizzano il comando fastboot oem lock per cancellare i dati dell'utente.
  • Un dispositivo può registrare, tramite eFuse o meccanismo simile, se un dispositivo è stato sbloccato e/o ribloccato. Tuttavia, consigliamo vivamente di ribloccare il bootloader con successivo ripristino delle impostazioni di fabbrica per ripristinare la piena funzionalità del dispositivo.

Questi requisiti garantiscono che tutti i dati vengano distrutti al completamento di un'operazione di sblocco. La mancata implementazione di queste protezioni è considerata una vulnerabilità di sicurezza di livello moderato .

Un dispositivo sbloccato può essere successivamente ribloccato utilizzando il comando fastboot oem lock . Il blocco del bootloader fornisce la stessa protezione dei dati utente con il nuovo sistema operativo personalizzato disponibile con il sistema operativo originale del produttore del dispositivo (ad esempio, i dati utente verranno cancellati se il dispositivo viene sbloccato nuovamente).

Pentest del dispositivo

I dispositivi devono essere esaminati da un pentester competente prima della spedizione. Il pentest dovrebbe stabilire che il dispositivo abbia seguito le linee guida sulla sicurezza fornite qui, nonché le linee guida sulla sicurezza OEM interne.

Test di sicurezza

Utilizza gli strumenti di test di sicurezza forniti da AOSP. In particolare

  • Utilizza strumenti di sicurezza della memoria durante lo sviluppo: utilizza MTE dove supportato (ARMv9 e versioni successive) e HWASan dove non lo è. Esegui il maggior numero di test possibile con questi strumenti abilitati.
  • Utilizza GWP-ASan e KFENCE in produzione, per il rilevamento probabilistico dei problemi di sicurezza della memoria.