¿El uso del elemento seguro de un teléfono inteligente realmente ofrece beneficios de seguridad para una aplicación bancaria?

8

La aplicación de Android de mi banco permite a los usuarios realizar transacciones financieras sin el uso del generador físico de token (que requiere que se inserte una tarjeta de cajero automático y que se proporcione un PIN válido) que normalmente se requiere al usar la interfaz web del banco. Sin embargo, esto solo se admite cuando se utiliza la aplicación en un teléfono que viene con un elemento seguro de hardware en el que puede almacenar claves criptográficas y demás.

Inicialmente, me pareció una buena decisión, ya que los dispositivos sin un Elemento seguro tendrían que almacenar las claves en la memoria o en el almacenamiento persistente, y por lo tanto son vulnerables a los ataques de malware instalado en el mismo dispositivo.

Sin embargo, al pensar esto, tengo la impresión de que usar el Elemento seguro en realidad dejaría a uno tan vulnerable a estos ataques que cuando solo protege las claves a través del software ; compara estos dos enfoques:

  • El sistema se basa en el sistema operativo para restringir el acceso a las claves: otras aplicaciones no pueden acceder a ellas mientras se encuentran en la zona de usuario, pero cuando un atacante logra obtener acceso de root al dispositivo, puede robar las claves y firmar o cifrar lo que sea. Ellos quieren, haciéndose pasar por la aplicación bancaria. Esto les permite forjar transacciones.
  • El sistema almacena las claves en el SE y confía en el sistema operativo para restringir el acceso a este hardware: otras aplicaciones no pueden acceder a ellas mientras se encuentran en la zona de usuario, pero cuando un atacante logra obtener acceso de root puede instruirlo para firmar y cifrar lo que quieran , simulando ser la aplicación bancaria. Esto les permite forjar transacciones.

Debido a esto, el uso del chip de hardware para este propósito me parece bastante inútil. Lo mismo se aplica a aplicaciones similares que confían en él para almacenar material confidencial.

¿Me estoy perdiendo algo aquí? ¿Existe alguna situación en la que el elemento seguro ofrezca un beneficio de seguridad claro para esta aplicación bancaria, por lo que es razonable exigirlo?

    
pregunta AardvarkSoup 23.06.2016 - 21:45
fuente

1 respuesta

6

Por lo tanto, ambos escenarios dependen de que el atacante tenga acceso root al teléfono. En seguridad, generalmente se considera que una vez que un atacante tiene acceso de root, se termina el juego. Dicho esto, todavía hay cosas interesantes que decir sobre su pregunta.

Has preguntado:

  

¿Existe una situación en la que el elemento seguro ofrece un beneficio de seguridad claro para esta aplicación bancaria, por lo que es razonable exigirlo?

Siendo un poco descarado: Sí, los casos de uso normales donde el usuario tiene una contraseña / bloqueo de pin, y el atacante no tiene acceso de root.

Yendo un poco más en profundidad:

Cuando dices "razonable para exigirlo" asumo que te refieres a ofrecer la misma funcionalidad a los usuarios con dispositivos que no son elementos seguros al almacenar la clave en el software. Algunas cosas vienen a la mente:

  1. En Android > 6.0 (y creo que con iOS) el cifrado ocurre dentro del Elemento seguro / Enclave seguro, por lo que la clave privada nunca ingresa en el territorio del usuario, por lo que es inmune a posibles vulnerabilidades / codificación descuidada en la aplicación bancaria o en las bibliotecas criptográficas de software que utilizan. (generalmente una buena práctica).

  2. Debido a que las claves privadas nunca abandonan el almacén de claves del elemento seguro, es imposible extraerlas del dispositivo y ejecutar la falsificación desde un servidor; Necesitas hacerlo desde el dispositivo físico. Si el propietario descubre que el dispositivo ha sido robado, puede hacer un borrado remoto, que eliminará las claves privadas, ataque sobre.

  3. Si el almacén de claves está protegido por contraseña, entonces, en el caso de un almacén de claves de software, puede extraer el archivo en un servidor y forzar la contraseña al contenido de su corazón. En el caso de un elemento seguro, después de una serie de intentos de fuerza bruta, pueden borrar las claves.

  4. Aunque todavía es un poco experimental, Android y iOS están comenzando a ofrecer mecanismos de control de acceso ordenados cuando el almacén de claves de hardware desbloquea las claves y realiza la criptografía. Por ejemplo, puede programar su aplicación para solicitar criptografía desde el SE de la siguiente manera: "Firme estos datos, pero solo si el dispositivo se desbloqueó con una contraseña, huella digital o PIN, y si el dispositivo se desbloqueó hace más de 5 minutos. volver a solicitarlos para su inicio de sesión primero ". Ese nivel de control es fundamentalmente imposible con las claves basadas en software.

Ninguna de estas cosas es 100% infalible contra un atacante con acceso de root al dispositivo, pero creo que muestran que un módulo de almacenamiento de claves / criptografía de hardware agrega algún valor. Mi opinión profesional es que es una opción defendible para una aplicación bancaria que le permita omitir un generador físico de token solo si su dispositivo tiene un elemento seguro.

[Descargo de responsabilidad: el elemento seguro de Android se sometió a una revisión importante en Android 6.0, por lo que lo que dije anteriormente no se aplica a Android < 6.0 que no hizo ninguna criptografía en el SE y devolvió las claves privadas al usuario.]

    
respondido por el Mike Ounsworth 23.06.2016 - 22:14
fuente

Lea otras preguntas en las etiquetas