Canali laterali Android: cosa può osservare una app su altre app?

Su piattaforme multi-core almeno (e la maggior parte dei nuovi smartphone sono multi-core), tutti gli attacchi di canale laterale sulla previsione e sulla cache dovrebbero funzionare, a condizione che l'attaccante possa accedere a un orologio con sufficiente precisione. L'architettura ARM ha un "contatore di cicli" che può essere utilizzato dal codice dell'applicazione, ma deve essere prima abilitato dal codice privilegiato (kernel); vedi questa risposta . Il codice nativo è possibile per le app che iniziano con Android 2.3 (con il NDK ).

Non so se il contatore dei cicli è abilitato di default con Android; è disabilitato in una CPU appena avviata, ma Android utilizza un kernel Linux e il contatore di cicli è molto conveniente per una serie di attività, inclusa l'implementazione della chiamata di sistema gettimeofday() , quindi è possibile che il kernel di Linux lo abiliti. Questo dovrebbe essere testato.

SE il contatore di cicli è abilitato, quindi è probabile che il metodo Java System.nanoTime() potrebbe restituire le stesse informazioni, per applicazioni Java pure. Quindi andare nativo potrebbe non essere nemmeno necessario per eseguire un attacco di temporizzazione della cache su Android.

Inoltre , ci possono essere altri orologi precisi. Ad esempio, l'API GPS ne fornisce una, con Location.getElapsedRealtimeNanos () .

Gli attacchi di canale laterale sull'accesso alla cache sono stati dimostrati su implementazioni AES comuni (in condizioni di laboratorio, ma ancora dimostrato). C'è stato un po 'di lavoro su tali attacchi contro l'algoritmo crittografico, ma qui non c'è nulla di veramente specifico della crittografia. Accade semplicemente che gli algoritmi crittografici utilizzino chiavi e le chiavi concentrino i segreti; conoscere la chiave rivela molte cose, quindi le chiavi sono obiettivi di alto valore. Inoltre, tutti questi attacchi sono stati studiati dai crittografi e i crittografi lavorano su algoritmi crittografici. Tuttavia, perdite di canale laterale possono verificarsi su ogni singola implementazione di qualsiasi algoritmo, crittografico o meno. Di solito, quando la crittografia si verifica in un dispositivo, è perché alcuni dati riservati vengono elaborati da quel dispositivo, e tutta quella elaborazione, non solo la crittografia, può fuoriuscire come un matto. Il problema è reale e onnicomprensivo.

In base a questi presupposti, si deve presupporre che molti dati possano essere dedotti da un'app, su ciò che fanno le altre app. Difendersi dagli attaccanti locali, che eseguono il loro codice sullo stesso hardware come te e allo stesso tempo, è difficile.

Un sacco. Non propongo di fornire un elenco esaustivo, solo alcuni esempi rappresentativi.

can app M learn what IP addresses app A is communicating with?

Sì, anche a occhi chiusi e con entrambe le mani legate dietro la schiena. /proc/net/tcp elenca tutte le connessioni TCP aperte. Ecco io. Su Android, l'uid rivela l'applicazione; le stesse informazioni per un determinato processo sono disponibili per tutti in /proc/$pid/net/tcp .

shell@android:/ $ cat /proc/net/tcp                                            
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 3600030A:AF4C 10CEFCC6:0050 01 00000000:00000000 00:00000000 00000000 10004        0 402734 1 00000000 37 3 8 10 -1                            
…

Can app M learn whether app A is currently using some exclusive-access resource/sensor (e.g., the microphone, the camera, etc.)?

Se la risorsa è ad accesso esclusivo, l'app M può quantomeno sondare per vedere se la risorsa è in uso. M può correggere queste informazioni con le statistiche di attività dell'app dell'app in /proc/$pid/stat* .

Can app M infer anything about text being typed into app A through the on-screen soft keyboard?

Sì. Gli smartphone hanno molti dispositivi di input: fotocamera, microfono, accelerometro, ... Con solo l'accelerometro ,

In controlled settings, our prediction model can on average classify the PIN entered 43% of the time and pattern 73% of the time within 5 attempts when selecting from a test set of 50 PINs and 50 patterns. In uncontrolled settings, while users are walking, our model can still classify 20% of the PINs and 40% of the patterns within 5 attempts.

Il tasso di successo è solo tra 50 PIN casuali e il tasso di successo nel decidere tra 1974 e 1975 sarebbe probabilmente inferiore. D'altra parte, questo studio utilizzava l'accelerometro da solo e combinando altri dati come la fotocamera e il timing probabilmente migliorerebbe la velocità.

Le misure di temporizzazione possono perdere molti dati; vedi risposta di Tom Leek .

Le informazioni che arrivano attraverso /proc sono specifiche per Android; altri sistemi operativi possono o meno esporre queste informazioni. Qualcosa come SEAndroid potrebbe impedire a queste informazioni di filtrare ad altre applicazioni. D'altra parte, i problemi relativi ai canali laterali non possono essere sfuggiti semplicemente migliorando l'isolamento del flusso di dati. Richiedono di eliminare funzionalità utili come la possibilità di dire l'ora o di accedere ai dispositivi hardware mentre un'altra applicazione è in esecuzione, il che potrebbe essere accettabile in alcune impostazioni (ad esempio, smartcard) ma non in uno smartphone.