canales laterales de Android: ¿qué puede observar una aplicación sobre otras aplicaciones?

Al menos en las plataformas de múltiples núcleos (y la mayoría de los teléfonos inteligentes nuevos son de múltiples núcleos), todos los ataques de canal lateral en la predicción de ramificaciones y el caché deberían funcionar, siempre que el atacante pueda acceder a un reloj con suficiente precisión. La arquitectura ARM tiene un "contador de ciclos" que el código de la aplicación puede usar, pero primero debe habilitarse desde un código privilegiado (kernel); Consulte esta respuesta . El código nativo es posible para aplicaciones que comienzan con Android 2.3 (con NDK ).

No sé si el contador de ciclos está habilitado de forma predeterminada con Android; está deshabilitado en una CPU recién iniciada, pero Android usa un kernel de Linux y el contador de ciclos es muy conveniente para varias tareas, incluida la implementación de la llamada al sistema gettimeofday() , por lo que es posible que el kernel de Linux lo habilite. Esto debería ser probado.

SI el contador de ciclos está habilitado, entonces es probable que el método Java System.nanoTime() también puede devolver la misma información, para aplicaciones Java puras. Por lo tanto, ser nativo podría no ser necesario para realizar un ataque de sincronización de caché en Android.

También , puede haber otros relojes precisos. Por ejemplo, la API de GPS proporciona una, con Location.getElapsedRealtimeNanos () .

Se han demostrado ataques de canal lateral al acceso a la caché en implementaciones comunes de AES (en condiciones de laboratorio, pero aun así demostrado). Se ha realizado bastante trabajo en tales ataques contra el algoritmo criptográfico, pero aquí no hay nada realmente específico para la criptografía. Simplemente sucede que los algoritmos criptográficos utilizan claves y las claves concentran secretos; conocer la clave revela muchas cosas, por lo que las claves son objetivos de alto valor. Además, todos los ataques fueron investigados por criptógrafos, y los criptógrafos trabajan en algoritmos criptográficos. Sin embargo, las fugas en los canales laterales pueden ocurrir solo en cada implementación de cualquier algoritmo, criptográfico o no. Por lo general, cuando el cifrado se produce en un dispositivo, se debe a que ese datos confidenciales es procesado por ese dispositivo, y todo ese procesamiento, no solo el cifrado, puede filtrarse como una locura. El problema es real y lo abarca todo.

Bajo estas suposiciones, uno debe asumir que se puede inferir una gran cantidad de datos de una aplicación, sobre lo que hacen otras aplicaciones. Defenderse contra los atacantes locales, que ejecutan su código en el mismo hardware que usted y al mismo tiempo, es difícil.

Lotes. No propongo dar una lista exhaustiva, solo algunos ejemplos representativos.

  

¿la aplicación M puede saber con qué direcciones IP se está comunicando la aplicación A?

Sí, incluso con los ojos cerrados y ambas manos atadas detrás de la espalda. /proc/net/tcp lista todas las conexiones TCP abiertas. Aquí estoy yo En Android, el uid revela la aplicación; la misma información para un proceso dado está disponible para todos en /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                            
…

  

¿Puede la aplicación M saber si la aplicación A está utilizando actualmente algún recurso / sensor de acceso exclusivo (por ejemplo, el micrófono, la cámara, etc.)?

Si el recurso es de acceso exclusivo, la aplicación M puede al menos sondear para ver si el recurso está en uso. M puede correlacionar esta información con las estadísticas de actividad de la aplicación A en /proc/$pid/stat* .

  

¿Puede la aplicación M inferir algo sobre el texto que se escribe en la aplicación A a través del teclado virtual en pantalla?

Sí. Los teléfonos inteligentes tienen muchos dispositivos de entrada: cámara, micrófono, acelerómetro,… Con el acelerómetro solo ,

  

En controlado   Configuraciones, nuestro modelo de predicción puede, en promedio, clasificar el PIN ingresado el 43% del tiempo y el patrón el 73% del tiempo en 5 intentos   cuando se selecciona de un conjunto de prueba de 50 PIN y 50 patrones. En configuraciones no controladas, mientras los usuarios caminan, nuestro modelo todavía puede clasificar   20% de los PIN y 40% de los patrones en 5 intentos.

Esa tasa de éxito es solo entre 50 PIN aleatorios y la tasa de éxito al decidir entre 1974 y 1975 probablemente sería menor. Por otro lado, este estudio utilizaba solo el acelerómetro, y la combinación de otros datos, como la cámara y el tiempo, probablemente mejoraría la velocidad.

Las medidas de tiempo pueden filtrar una gran cantidad de datos; vea la respuesta de Tom Leek .

La información que llega a través de /proc es específica de Android; Otros sistemas operativos pueden o no exponer esta información. Algo como SEAndroid podría evitar que esta información se filtre a otras aplicaciones. Por otro lado, los problemas del canal lateral no se pueden escapar simplemente por un mejor aislamiento del flujo de datos. Requieren la eliminación de funciones útiles, como la capacidad de indicar la hora o el acceso a dispositivos de hardware mientras se ejecuta otra aplicación, lo que podría ser aceptable en algunas configuraciones (por ejemplo, tarjetas inteligentes) pero no en un teléfono inteligente.