Cifrado de capas en la parte superior de HTTPS [duplicado]

Puede usar HTTPS con fijación de clave pública . De esta manera, solo su certificado es válido para la comunicación. Un atacante hombre en el medio ya no puede crear un certificado válido para detectar el tráfico.

La fijación de teclas es bastante común para las aplicaciones móviles. Debe comprobar si el marco HTTP que utiliza lo admite.

Si su preocupación es un dispositivo con jailbreak, entonces agregar el cifrado encima de TLS no agregaría ningún beneficio: un atacante podría robar las claves de la memoria o usar herramientas como frida para secuestrar el control de la aplicación y parchear las partes "criptográficas" para revelar su contenido. Si está utilizando PKI por encima de TLS, entonces es solo un desperdicio de recursos, y existen muchas posibilidades de que lo implemente incorrectamente (piense en la fijación de claves, el mantenimiento de las listas de revocación de certificados, etc.)

En otras palabras, si la seguridad del transporte es su única protección, entonces necesita rediseñar su aplicación. Si tiene algún tipo de información confidencial almacenada en el lado del cliente, tal vez codificada en su aplicación, la cual, si se expone, podría poner en peligro toda su red, entonces lo está haciendo mal.

Hay pautas para iOS y Android sobre cómo almacenar" secretos "en un teléfono, además del habitual OWASP REST security guía

Si bien hay varios ejemplos de servicios que hacen este tipo de cosas, ninguno de ellos realmente resuelve el problema de un punto final comprometido. Como dice la frase:

  

si el atacante compromete su dispositivo, ya no es su dispositivo

En efecto, cualquier cosa que haga no tiene sentido una vez que el atacante tiene el control de ese dispositivo, ya que pueden leer o falsificar cualquier certificado, clave o frase de contraseña que pueda usar en él.

Esta es el área donde los módulos de hardware de confianza pueden marcar la diferencia. Si el dispositivo tiene un chip o módulo que no se puede abrir (y no puede, quiero decir, no por un atacante esperado), entonces cualquier secreto que necesite usar puede almacenarse allí. Esto todavía requiere una arquitectura que evite que el atacante intercepte comunicaciones en el dispositivo, o subvierta el proceso de intercambio de claves.

Sin embargo, en su ejemplo, sugeriría que no es realista agregar una capa adicional de cifrado, ya que no lo protegerá contra su modelo de amenaza establecido. En su lugar, ¿puede impedir la conexión desde dispositivos rooteados?

El problema con su propuesta es que ninguna cantidad de capas agregadas de encriptación / validación PKI haría que el dispositivo comprometido sea seguro, porque el dispositivo está comprometido.

Supongo que la pregunta (formulada por otros) es contra qué está tratando de protegerse exactamente: si su preocupación es que alguien "falsifique" a un usuario, agregar un segundo factor, y uno relacionado con algún otro dispositivo / token, Parece el enfoque más realista.

Puede ser útil comprobar cómo algunos de los clientes de chat seguro disponibles manejan el cifrado y la privacidad: la mayoría termina suponiendo que se puede confiar en el dispositivo de un usuario (consulte, por ejemplo, enlace ), y construye a partir de ese hecho.

A falta de introducir la comprobación de aserción para dispositivos de usuario, no hay mucho que pueda hacer para protegerse contra usuarios con dispositivos comprometidos. No está claro si debería estar necesariamente preocupado por eso, es necesario que exista algún tipo de demarcación, y asumir que el dispositivo es seguro es muy común.