¿Cifrado de usuario a usuario además de SSL para teléfonos móviles?

Al encriptar máquina a máquina, usted (más o menos) protege los datos en tránsito, pero la encriptación de usuario a usuario protege los datos en tránsito de partes de la máquina (más arriba en la pila), así como Protegiéndolo en almacenaje. Un beneficio adicional para el cifrado a nivel de usuario es un mejor control sobre el proceso de cifrado, en caso de que no tenga control sobre el proceso SSL en ningún momento.

La pregunta se convierte en "¿de quién estás protegiendo los datos?"

El cliente de chat Pidgin, por ejemplo, puede configurarse para usar el cifrado a nivel de usuario, y obtiene los beneficios que describí .

SSL establece un túnel de datos protegidos sobre un túnel de datos no protegido. Puede hacer SSL entre dos máquinas (incluso si las máquinas son teléfonos inteligentes) pero la configuración práctica puede ser difícil: las conexiones directas de teléfono inteligente a teléfono inteligente son raras, porque en una conexión normal, una máquina tiene la función de cliente y el otro es un servidor (el "cliente" es el que habla primero, el "servidor" es el que espera al cliente para hablar). Iniciar una conexión de este tipo requiere que el cliente "sepa" de alguna manera la dirección IP del servidor. Los proveedores de red para teléfonos inteligentes no lo hacen tan fácil (y, a este respecto, tampoco lo hacen los ISP para usuarios domésticos).

Los usos comunes de SSL desde teléfonos inteligentes son entre el teléfono y un servidor. Si dos teléfonos se conectan al mismo servidor, entonces ese servidor podría actuar como un relevo para los paquetes de datos enviados de un teléfono a otro, permitiendo cualquier protocolo de comunicación, incluso SSL. El cifrado de usuario a usuario, o al menos el cifrado de teléfono a teléfono, tiene mucho sentido si no confía en el servidor de retransmisión. Este es exactamente el modelo de seguridad para el "envío seguro de correo electrónico" tal como lo expresa PGP.

Schroeder lo explica correctamente, y esta sola frase realmente puede (casi por sí sola) responder a su pregunta .

  

La pregunta se convierte en "¿de quién estás protegiendo los datos?"

Me gustaría ampliar eso solo un poco, sin embargo.

Si su única preocupación es proteger los datos de escuchas informales ocasionales (p. ej., ese tipo espeluznante que está a su lado en la cafetería), las tecnologías de seguridad de conexión de máquina a máquina como SSL son generalmente suficientes. Suponiendo que el mecanismo de protección en sí mismo no es débil de alguna manera, generalmente tiene poco que temer de las personas que detectan su tráfico.

Sin embargo, si está preocupado por proteger sus datos de agencias gubernamentales, información interna maliciosa en su ISP, información interna maliciosa en el host de la aplicación, los sistemas de monitoreo de su empleador u otros atacantes avanzados con posicionamiento de intermediario, entonces Las soluciones de extremo a extremo como PGP son el camino a seguir.

SSL generalmente protegerá la conexión entre usted y el host de la aplicación. Sin embargo, si la conexión SSL está comprometida (es decir, su empresa utiliza un proxy SSL para monitorear todo el tráfico en su red como si fuera un texto claro), entonces sus datos son vulnerables. Además, SSL no protege los datos en reposo en los servidores del host de la aplicación donde los usuarios malintencionados pueden explotarlos.

PGP protege los datos a lo largo de toda la ruta, desde su origen hasta su final destino, y protege los datos en reposo. La única forma de comprometer los datos es comprometer una de las máquinas de punto final, obtener una copia de una clave privada autorizada o encontrar una debilidad en los algoritmos de cifrado utilizados. En general, esto lo protegerá de personas internas malintencionadas y ataques de intermediarios. Sin embargo, todavía debe estar alerta contra el malware y los actores maliciosos con acceso físico a cualquiera de los puntos finales.

En ese último punto, es bueno recordar algunas de las Diez leyes inmutables de seguridad :

  

Ley n.º 1: si un malvado puede persuadirte de que ejecutes su programa en tu computadora, ya no es solo tu computadora.
  ...
Ley n.º 3: si un malvado tiene acceso físico sin restricciones a su computadora, ya no es su computadora.
  ...
Ley # 10: La tecnología no es una panacea.

Sin embargo, si realmente le temen a esas agencias gubernamentales u otros "grandes malos", probablemente debería mantener esto en mente.

Respuesta corta, sí, puede haber algunos casos selectos que ayuden cuando se habla directamente entre dos clientes si las aplicaciones están extremadamente endurecidas. También hay muchos cuando los datos deben viajar al aire libre a través de un intermediario que no es de confianza (es decir, el servidor de correo, el servidor de chat, etc.).

Respuesta larga. Hay un par de cosas que vale la pena mencionar aquí. Primero, SSL generalmente solo proporciona la autenticación de una máquina, por lo tanto, no hace nada para garantizar que el cliente que se conecta a un servidor sea un cliente en particular (aparte de certificar que es el mismo cliente que inició la sesión SSL). Solo el servidor generalmente tiene un certificado de confianza. Existe soporte para los certificados del lado del cliente en SSL, que verificarían un cliente en particular, pero se usa muy poco.

A continuación, el cifrado de usuario a usuario tal como lo describió aquí va un poco más, pero no de manera significativa. En un sistema como PGP, tiene autenticación mutua, ya que ambas partes tienen certificados que deberían validarse a través de algún tipo de infraestructura de clave pública (PKI), pero eso se podría hacer solo con SSL. Mover el cifrado a la capa de aplicación (en lugar del transporte) puede ser significativo en algunos casos raros, pero para que alguien comprometa los datos SSL, tendría que haber comprometido uno de los puntos finales (muy probablemente la pila de la red). Si uno de los puntos finales está comprometido, el cliente de software no puede ser realmente confiable, ya que el atacante necesitaría acceso a nivel de kernel a uno de los puntos finales para secuestrar la pila de red y luego podrían secuestrar la E / S desde / hacia la aplicación. Mitigaría unas pocas amenazas seleccionadas si la aplicación está diseñada para ser altamente segura contra cualquier tipo de acceso desde otro programa, pero eso requeriría un enfoque mucho más profundo de la seguridad que simplemente cifrar los datos al nivel de la aplicación.

Lo que es más importante es asegurarse de que SSL esté bien utilizado por una aplicación. La necesidad de inicio de sesión para confirmar el cliente y las sesiones SSL deben cerrarse correctamente si un punto final abandona la sesión. (es decir, no puedo sentarme frente a su computadora y usarlo como usted). Tenga en cuenta que este último punto también es importante incluso si se trata de una aplicación a otra.

En cuanto a pasar por un intermediario que no es de confianza, el problema con SSL es que no se trata de una conexión protegida de forma continua si está atravesando un punto medio o más de un tipo de transporte. El cifrado proporcionado por el cliente final protegerá los datos independientemente del transporte y también los protegerá a través de cualquier manejo. Muchos sistemas usan "sobres" donde la información se encripta con anticipación para los múltiples pasos del viaje. Cada sistema puede abrir el sobre más externo, determinar qué debe hacer con la información y luego pasarlo al siguiente sistema. Eventualmente, el usuario en el otro extremo puede abrir el sobre final y recibir el mensaje original, pero nadie en el medio puede acceder a él.