Crittografia Android L e crittografia iOS 8

14

Recentemente, il nuovo sistema di crittografia full-disk del sistema operativo iOS 8 di Apple è stato nelle notizie . E poco dopo il rilascio di Apple, Google ha annunciato che abiliteranno anche la crittografia per impostazione predefinita nella prossima versione del proprio sistema operativo Android.

La mia domanda è: dal punto di vista della sicurezza, i due sistemi sono simili o diversi (supponendo che usi la stessa password o il codice PIN)? Precisamente come funziona la crittografia di Android sotto controllo?

In termini più concreti: se uso una password a 8 lettere minuscole casuali, che presumibilmente richiede ca. 265 anni per la forza bruta nel caso di dispositivi iOS, quanto sono sicuro con una configurazione simile su un telefono Android?

Per informazioni sull'approccio adottato da Apple con iOS 8, vedi questo documento . Se ho capito bene, il punto chiave sembra essere che ci sia un pezzo speciale di hardware a prova di manomissione che contiene un identificatore segreto specifico del dispositivo. Presumibilmente, l'unico modo per recuperare la chiave di crittografia è quello di alimentare il codice pin a questo pezzo di hardware, attendere 80ms e vedere cosa viene fuori. Per forzare questo, dovrai continuare a inserire i codici PIN su questo singolo pezzo unico di hardware (e ogni tentativo richiede 80ms, e non puoi parallelizzare questo, dato che c'è solo uno di questi chip nel mondo), o lo farai devi anche forzare l'identificatore (che è molto lungo).

In che modo si confronta a ciò che Google (e i produttori di telefoni Android) stanno facendo con i telefoni Android?

    
posta Jukka Suomela 27.09.2014 - 18:49
fonte

2 risposte

6

Attualmente, la crittografia dei dispositivi Android utilizza dm-crypt e in effetti sembra essere suscettibile al tipo di attacco a forza bruta menzionato, perché il PIN / password è più o meno direttamente utilizzato per ricavare la chiave che decrittografa la chiave AES memorizzata nell'intestazione del volume.

Per proteggersi da tali attacchi di forza bruta, la password deve essere sufficientemente entropia (proprio come sui sistemi di crittografia desktop). Sfortunatamente, Android non consente l'impostazione di una password diversa per la decodifica del disco e il blocco dello schermo. Questa è solo una limitazione dell'interfaccia utente, tuttavia: È facilmente possibile a utilizzare una password complessa per la decrittografia del disco di avvio, ma richiede l'accesso root.

Tuttavia, tutto questo potrebbe cambiare con Android L: nulla è pubblicamente conosciuto al momento, ma ci sono suggerimenti che Android si sposterà su uno schema che utilizza una parte hardware "fidata", come iOS.

A proposito, la derivazione della chiave hardware iOS che descrivi sembra essere stata sostituita da qualcos'altro per i dispositivi che utilizzano un SoC A7 (o più recente). Apple sembra eseguire (e limitare la velocità) la verifica del PIN / password all'interno di Secure Enclave, che teoricamente sarebbe ancora più sicuro. Dal documento a cui hai fatto riferimento:

On a device with an A7 or later A-series processor, the key operations are performed by the Secure Enclave, which also enforces a 5-second delay between repeated failed unlocking requests. This provides a governor against brute-force attacks in addition to safeguards enforced by iOS.

Dovrai attendere che l'intero codice di Android L sia rilasciato per essere sicuro (e anche allora, potrebbe essere qualcosa che dovrà essere implementato dai produttori di dispositivi), ma a partire da ora, alcuni dispositivi Android già supportano gli archivi di chiavi hardware per le chiavi asimmetriche ; questo meccanismo sembra basato sull'ambiente di analisi TrustZone ARM e potrebbe Teoricamente verrà esteso alle chiavi di crittografia dei dispositivi, simile al concetto Secure Enclave di Apple.

    
risposta data 28.09.2014 - 13:55
fonte
0

Le diverse architetture di crittografia tra Android (crittografia a livello di blocco) e iOS (crittografia a livello di file) creano comportamenti diversi quando un file viene cancellato:

  • Con la crittografia a livello di blocco, quando un file viene eliminato, il filesystem scollega i blocchi dal filesystem ma in realtà non distrugge i dati. Poiché la maggior parte dei dispositivi Android utilizza il flash NAND che contiene "wear-leveling", in genere è impossibile sovrascrivere dati specifici in modo che i file sensibili possano essere cancellati.
  • Con la crittografia a livello di file, la chiave per file viene distrutta quando l'inode è scollegato, causando la distruzione effettiva dei dati non referenziati e quindi la cancellazione non è possibile.
risposta data 15.12.2014 - 05:27
fonte

Leggi altre domande sui tag