Autenticidad de la información que se muestra en un dispositivo que no es de confianza

La idea de usar un fondo reconocible es bastante buena. Sin embargo, T. Pornin ha tenido la amabilidad de señalar algunos problemas con ese enfoque.

Corto: Use MobiCore u otras implementaciones de TrustZone cuando estén disponibles. Para los dispositivos que no son de confianza sin TEE, actualmente solo necesita utilizar Rich OS. En el futuro, quizás más dispositivos ofrezcan TEE.

Problemas con confianza y confirmación

En última instancia, el problema es: si no puede confiar en los componentes y el software que se ejecutan en el dispositivo, no puede confiar en que el dispositivo no cambie el mensaje / botón de confirmación que se muestra al usuario.

No hay una solución perfecta para este problema (solicitar confirmación en un dispositivo que no es de confianza). Este es un hecho ampliamente conocido. Incluso, ocasionalmente, hay problemas con los dispositivos que generalmente se consideran "confiables" (por ejemplo, ATM). Por lo tanto, los negocios bancarios y crediticios siempre están esperando algún tipo de fraude y están preparados para enfrentarlos.

Dispositivos no confiables

Para muchas aplicaciones, actualmente se considera lo suficientemente seguro al tener aplicaciones que se ejecutan directamente en dispositivos móviles que no son de confianza. (Como la banca en línea, etc.)

Entorno de ejecución de confianza

¿Qué pasaría si fuera posible tener un entorno confiable para casos de uso que necesiten más confianza? (Para casos de uso de comercio móvil, BYOD, etc.)

Los operadores de red y los fabricantes de hardware formalizaron gran parte de los requisitos de Trusted Execution Environment, que son útiles para ejecutar "software confiable" en un entorno confiable en un dispositivo que no es de confianza (también conocido como HLOS, Rich OS, General Purpose OS o Normal World OS ). Estos documentos son OMTP TR0 y OMTP TR1. Son una de las mejores presentaciones de los requisitos habituales para TEE.

TrustZone

ARM + Trusted Logic comenzó a trabajar en esta idea hace unos diez años. Los procesadores ARM obtuvieron TrustZone, que ha estado allí desde entonces. Aunque en gran medida era una buena idea en la práctica, el gran problema era: hay soporte en hardware, pero las soluciones de software lo utilizaron mucho hasta hace poco.

Técnicamente, es posible considerar TrustZone como un soporte limitado de HW para la virtualización, con la intención de usar un sistema operativo rico y un sistema operativo seguro.

G & D MobiCore ha sido una de las pocas implementaciones que ha llegado a los principales teléfonos móviles, está disponible en Samsung S3, S4. Samsung Note III tiene Samsung Knox. Creo que también se basa en MobiCore en TrustZone.

Algunos otros teléfonos tienen algún otro software. En muchos casos, no hay detalles disponibles sobre qué hacen los teléfonos con el software que podrían cargar o cargar en TrustZone, que está disponible en casi todos los teléfonos inteligentes actuales.

Para obtener el soporte SW adecuado para TrustZone, G & D, ARM y Trusted Logic Mobility juntos fundamos Trustonic, que está creando la siguiente generación de sistemas operativos de confianza.     

Entiendo su pregunta de la siguiente manera: hay un dispositivo tangible que puede producir datos y enviarlos por radio (Bluetooth); y otro dispositivo (por ejemplo, un teléfono inteligente) que recibe dichos datos y los muestra; El problema es que no se puede confiar en el segundo dispositivo. Entonces, la pregunta es: ¿podemos hacer algo al respecto, de modo que podamos ganar algo de confianza en los datos que se muestran como una representación fiel como lo que envió el primer dispositivo?

Hablando genéricamente, no, no podemos; los mentirosos mienten. A menos que los datos que envía el primer dispositivo vengan con algún tipo de suma de comprobación o firma que el segundo dispositivo no puede falsificar o falsificar ( firmas digitales y MAC pueden ser herramientas criptográficas útiles para eso), y que el observador humano verifica independientemente del teléfono inteligente no confiable. Este último punto es el verdadero problema: un observador humano normal no computará en su cabeza una verificación de firma o un MAC.

Las soluciones alternativas para este tipo de situación vienen en dos tipos:

• Agregue una pantalla directamente en el primer dispositivo, para que el dispositivo pueda mostrar sus datos directamente, sin la interacción del teléfono inteligente potencialmente hostil. Esto es lo que se hace con terminales de pago : aunque están vinculados con una caja registradora que es, básicamente, una PC, como Los terminales aún tienen su propia pantalla y teclado porque la caja registradora no es confiable.

• Agrega un tercer dispositivo al baile. Dele al usuario un dispositivo en el que confíe, y eso verificará cualquier MAC o firma que haya calculado el primer dispositivo. Mutatis mutandi , esto es Internet, con el mapeo de teléfonos inteligentes no confiable a simples enrutadores; algunos SSL entre el origen y el destino protegen la integridad (y la confidencialidad) de los datos de la manipulación incorrecta por parte de los enrutadores.

(Podemos observar que este problema también es un problema inherente con las tarjetas inteligentes insertadas en la PC a través de lectores dedicados o puertos USB. Cuando ingresamos el código PIN, está en la PC; no podemos saber realmente qué pregunta le pide la PC al PC). tarjeta inteligente para firmar.)

El esquema para superponer texto en una imagen conocida es inteligente, pero no seguro. No hace nada para evitar que un atacante agregue contenido (piense en agregar ceros al final de un número, esto podría ser perjudicial). Además, depende del secreto de la imagen de origen y la capacidad humana para distinguir las partes que se han "completado", lo que es riesgoso.

La mejor solución sería simplemente mostrar el mensaje normalmente junto con un HMAC y luego transcribir todo el mensaje con el HMAC a otro dispositivo para su verificación.

Si no hay otro dispositivo disponible, lo que necesitaría es una firma digital que pueda ser verificada por un ser humano, pero que no puede ser cambiada por una computadora sin que la persona se dé cuenta. Tal cosa aún no existe. Sin embargo, teóricamente podría funcionar algo como lo siguiente, aunque sería realmente engorroso y no sería seguro contra la manipulación por parte de un humano:

1. Cree una palabra de seguridad que el dispositivo seguro y el humano conozcan.
2. Agregue la palabra de seguridad al final del mensaje.
3. Cree un algoritmo de suma de verificación verificable manualmente y calcule la suma de verificación del mensaje. (Esta suma de comprobación no necesita ser criptográficamente segura, por lo que algo como CRC32 que se modifica para facilitar el cálculo manual sería correcto).
4. Agregue la suma de comprobación al final del mensaje
5. Escriba el mensaje completo usando una biblioteca CAPTCHA para que una computadora no pueda leer nada de él.

Cualquier alteración del mensaje rompería la suma de control, y el reemplazo mayorista eliminaría la palabra de seguridad. La palabra de seguridad podría copiarse, pero como una computadora no puede leerla, no sería posible calcular una suma de comprobación correcta en un mensaje que la incluya. Si desea protegerse contra la repetición y reordenación de mensajes, también puede agregar un nonce (un contador de mensajes que aumenta monótonamente). Si te preocupa la frescura, puedes agregar una marca de tiempo (antes de aplicar la suma de comprobación, por supuesto).

Advertencia: El éxito de este esquema basado en el cabello no solo se basa en la seguridad de los CAPTCHA (que han sido atacados con éxito muchas veces), sino en que el usuario puede leer el completo mensaje sin cometer errores. Dado que las tasas de error humano en los CAPTCHA de una sola palabra no son triviales, esto podría llevar a una tasa de éxito de verificación bastante baja, lo que causaría frustración. El mismo mensaje podría escribirse varias veces para disminuir la tasa de error humano, pero esto también facilitaría que una computadora rompa el CAPTCHA.

Los demás ya han cubierto el detalle técnico. Para responder a su pregunta directamente desde los principios básicos:

"[Después de que algo se transfiere por bluetooth.] ¿Existe un método simple y efectivo para garantizar que la información mostrada no haya sido alterada por el malware en esa PC o teléfono receptor?"

La respuesta es no, no puedes.

Su esquema es inteligente, pero fundamentalmente, si la PC o el teléfono se ven comprometidos, nunca se puede confiar. En el caso del malware bancario, vemos que van tan lejos como para "emular" el comportamiento correcto, pero en realidad hacen otra cosa. En el caso de su esquema, podría guardar una copia no contaminada de lo que se transfiere e incluso generar su imagen con eso, pero supongo que lo importante es que, después de esto, se verá comprometido con un segundo conjunto de datos malintencionados.

Como ya lo han indicado otros, no puede confiar en nada que un dispositivo no confiable le diga o muestre. Necesitas una interfaz confiable para eso, o algún mecanismo de verificación que hayas intentado crear, pero me temo que reparar un fondo es demasiado fácil para eso. No quisiera que algo como la marca de agua de un fotógrafo fuera todo lo que se interponga entre mí y el envío de miles de euros a la cuenta bancaria de otra persona.

Hay una solución que está en uso (al menos) en Alemania para banca en línea, llamada ChipTAN: el dispositivo no confiable muestra una representación gráfica (puede usar QR, ChipTAN usa una animación con cinco barras parpadeantes, porque el lector está mucho más barato de construir) y tenga un dispositivo confiable (aquí, una pequeña caja de lectores con cinco fotosensores y una pantalla que se conecta al chip de su tarjeta bancaria) lea y muestre esa información. Los dispositivos ChipTAN le permiten crear un número de autorización de transacción vinculado a la información que acaba de ver.

¿Teme que el mensaje se pierda accidentalmente y no se vea? ¿Teme que el mensaje se modifique y le diga a alguien que solo gastó $ 10 cuando realmente gastó $ 10,000? ¿O tiene miedo de que el malware actúe de manera confiable en cualquier cantidad inferior a $ 1,000, pero de repente deje de exigir confirmación si el malo transfiere $ 10,000? Si ese es el caso, tal vez el lado de su servidor no tenga que lidiar con dispositivos no confiables cuando su riesgo supera un cierto umbral. Por ejemplo, podría requerir una autenticación de dos factores para montos superiores a $ 1,000, por lo que no confía completamente en el teléfono para cada transacción. Establezca sus límites en función de cuánto confía (o no confía) en los dispositivos del teléfono.

Y las cosas que no se pueden controlar con soluciones tecnológicas a menudo se pueden abordar con auditorías.

El usuario podría ocasionalmente (y aleatoriamente) validar la información en la pantalla que es realmente lo que el servidor envió. Pueden hacerlo de varias maneras diferentes: pueden ir físicamente al servidor y mirar su pantalla nativa; pueden usar un segundo dispositivo (quizás un teléfono modelo diferente provisto por un proveedor diferente); pueden conectarse al servidor a través del navegador web y realizar una doble comprobación de esa manera; o pueden volver más tarde y revisar los registros del servidor. O el servidor ocasionalmente puede enviar la información de dos maneras, utilizando canales laterales como SMS o correo electrónico para proporcionar confirmación.

Si un usuario marca uno de cada cuatro mensajes, el dispositivo no confiable tiene un 25% de posibilidades de ser atrapado cada vez que presenta un mensaje falso. Si eres el tipo malo que tiene el control del dispositivo que no es de confianza, esas son muy malas probabilidades de ser capaz de causar daños a largo plazo a los mensajes sin que te atrapen. (Esto requiere que el usuario sea aleatorio en sus comprobaciones de auditoría: volver a verificar cada vez que el último dígito sea cero representa un patrón que el atacante podría explotar).

Por supuesto, como con cualquier solución que involucre a personas frágiles, el problema es la diligencia. Si un sistema es confiable durante el primer mes, la mayoría de las personas dejarán de verificarlo después de dos meses. Esa es la naturaleza humana. La autenticación de dos factores en situaciones de alto riesgo ayuda a resolver ese problema.

Podría pensar en una pequeña pantalla en el dispositivo que muestre la información más importante (por ejemplo, un identificador de llamadas, una huella dactilar o una cantidad, según el caso de uso). En otras situaciones, puede usar algo difícil de falsificar, como por ejemplo, hay auriculares de cifrado que hacen una huella dactilar "verificada".

Y lo que también puede hacer es usar un código QR para que un usuario sensible pueda ver y validar una firma digital en un dispositivo personal confiable (pero limitado) y seguir utilizando el dispositivo más grande que no es de confianza para realizar el procesamiento normal (piense en imprimir en Internet cafe).

El problema principal es que, una vez que se comprometa su único canal de comunicación, todo lo que sale de él es sospechoso. Usted está esperando que el punto final sea capaz de detectar, recuperarse del problema. Además, una vez que el punto final en sí está comprometido, entonces el compromiso de tráfico es discutible. Aunque el compromiso de punto final es algo que no se debe intentar, porque hay una posibilidad real de ser atrapado. Es por eso que las soluciones basadas en token OTP implican cálculos fuera de banda del token.