¿Cómo podría asegurar totalmente una conexión entre dos nodos?

0

Estoy creando un servidor de autenticación en Python, y me preguntaba cómo podría asegurar una conexión totalmente entre dos pares. No puedo ver de qué manera un usuario malintencionado no podría copiar paquetes y simplemente analizarlos si entiende qué viene en qué orden.

Admitiendo un esquema de servidor cliente. El cliente pide una cuenta. Aunque SRP, los paquetes se pueden copiar y enviar más tarde para permitir el inicio de sesión.

Entonces, ahora, si agrego el cifrado de la clave pública - privada, ¿cómo me envío la clave pública sin pasarla en un canal no cifrado?

Lo siento si mis preguntas siguen siendo noobish o parece que no me ha importado la pregunta, pero realmente me cuesta entender cómo puedo crear un proceso de autenticación sin tener varios agujeros de seguridad.

    
pregunta cp151 05.08.2013 - 20:54
fuente

4 respuestas

2

Básicamente, la solución que está buscando implicará algún tipo de transferencia sin conexión. Las dos computadoras que son los nodos de punto final de su túnel seguro deben ser "introducidas" una a la otra, intercambiando algún secreto que permita que un lado inicie una conexión de tal manera que solo el otro nodo pueda entenderlo.

Si bien este secreto compartido podría ser la clave simétrica en sí misma, esto puede ser problemático; Los algoritmos simétricos son más seguros cuando no se sabe nada acerca de la clave, incluso el hecho de que es la misma clave que se usó para otra comunicación. Un atacante podría ver múltiples "conversaciones" entre los nodos, y si sabe que las conversaciones usan la misma clave y IV, y si puede adivinar el texto sin formato (que es probable que haga como la información enviada en las etapas iniciales de la comunicación). es bastante repetitivo), puede usar el texto cifrado para aplicar ingeniería inversa a la clave. Por este motivo, la clave simétrica debe renegociarse con frecuencia, incluso en el mismo canal seguro, dependiendo de la cantidad de datos que se envíen.

La solución de acceso es la criptografía de clave pública o asimétrica. Entiende una cosa; Las claves públicas están destinadas a ser públicas. Puede pintar su llave pública en el costado de su automóvil y conducirla a través de Black Hat o DEF CON, y todo lo que cualquier persona podría hacer es intentar conectarse a su punto final de forma segura (lo cual no es más de lo que podría hacer con cualquier otro TLS -seguro endpoint, y no llegarían muy lejos aquí; seguir leyendo). La clave privada es necesaria en cualquier esquema de clave pública para descifrar los datos de manera eficiente (y, por lo tanto, para que la información esté en riesgo).

Ahora, no puede distribuir públicamente este certificado; usted podría, de manera bastante plausible, implementar una variante simple del esquema TLS básico donde el servidor ignoraría el primer paso normal, la solicitud del cliente para el certificado del servidor. En su lugar, el cliente ya debe tener un certificado para el servidor "anclado" en el almacén de certificados del sistema operativo, y no podría (no podría) verificar que tenía la última versión. Entonces sería capaz de negociar una conexión segura sin que se envíe un solo bit de los datos reales (los datos del paquete aún estarían en un paquete IP bien formado).

Conceptualmente, funcionaría de la siguiente manera; el cliente tendría la clave pública del servidor, que se le dio fuera de línea (aquí, la única diferencia entre "cliente" y "servidor" que nos importa es que el cliente es el que inicia la comunicación; ambas computadoras pueden ser "servidores" "en otros sentidos de la palabra, como servidores de archivos en la nube). El servidor tendría la clave pública del cliente, que it recibió fuera de línea. El cliente encripta una solicitud usando la clave pública del servidor, que contendrá el certificado del cliente. Esa solicitud va a la dirección IP del servidor, y solo el servidor puede descifrarla, incluso si alguien más estaba olfateando o falsificando el tráfico en esa misma dirección IP. La solicitud puede contener un nonce, como un simple valor de contador, que evita los ataques de reproducción (el servidor puede ignorar varias solicitudes del mismo cliente con el mismo nonce, aunque debe descifrar cada solicitud que recibe para determinar esto, lo que podría hacerla vulnerable). a DDoS).

El servidor luego usaría el certificado del cliente, que puede verificar de forma independiente como un cliente autorizado porque una copia exacta del certificado del cliente se encuentra en el almacén del sistema operativo del servidor, para enviar una negociación de clave simétrica. Desde este punto, el esquema es virtualmente idéntico a la negociación TLS de dos certificados; el servidor envía al cliente la solicitud de negociación de clave, el cliente recibe, configura su cifrado y devuelve un acuse de recibo cifrado simétricamente o la otra mitad del protocolo de intercambio de claves para que el servidor sepa que hablan el mismo idioma. A partir de ese momento, el cliente y el servidor pueden comunicarse utilizando el canal simétrico. Todo esto, sin que un observador externo vea ningún paquete de datos en texto sin formato.

Ahora, esto es solo para crear un canal seguro. Incluso si el nodo cliente tiene una IP estática, siempre es bueno verificar posteriormente, después de negociar el túnel seguro, que la persona que controla la computadora en el otro extremo es alguien autorizado para usar el sistema. El intercambio de credenciales como nombre de usuario / contraseña, o la entrada de un valor de clave de tiempo limitado generado por un control remoto, son medios comunes y perfectamente factibles para autenticar al usuario de la (s) computadora (s) autentificada (s). >     

respondido por el KeithS 05.08.2013 - 22:00
fuente
1

Si una clave simétrica se comparte previamente, entonces se puede usar un contador simple para evitar la reproducción. Solo los mensajes que tengan sentido y tengan un conteo válido deben ser respetados y un atacante puede ser intermedio, pero no podría dar sentido al tráfico ni agregar ninguna instrucción a la serie.

Del mismo modo, para el cifrado asimétrico, las claves públicas son públicas y simplemente se pueden compartir a la vista. Luego se pueden usar para intercambiar una clave simétrica para la comunicación real y se puede usar la respuesta de desafío para evitar la reproducción de la autenticación asimétrica. La clave principal es que la confianza en la clave pública debe establecerse, esto se hace verificando la huella digital de la clave pública a través de un canal seguro (como hacer una llamada telefónica) o firmando la clave pública en un certificado ( tal como se hace con certificados SSL de una Autoridad de Certificación). Alternativamente, se puede usar una red de confianza para dar confianza de que la clave privada correspondiente de una clave pública la posee la persona para la que está el público.

    
respondido por el AJ Henderson 05.08.2013 - 21:18
fuente
1

No reinvente la rueda y no complique demasiado las cosas.

Simplemente configure una VPN IPSec entre los dos nodos y pase tráfico sobre eso.

Deje las cosas de seguridad a las personas que saben cómo codificar la seguridad, y centre sus esfuerzos en los bits de su código Python que se requieren para el negocio real en lugar de perder tiempo en codificar, probar y depurar los canales TLS o lo que sea .

    
respondido por el user3083 04.08.2014 - 19:20
fuente
0

Un mínimo absoluto de tráfico no seguro sería un (tal vez autofirmado, tal vez una sola vez o certificado único por usuario). Todo el tráfico en curso se puede enviar a través de un canal cifrado con SSL. Se puede proporcionar seguridad adicional mediante las claves de sesión y / o de una sola vez para una capa de cifrado adicional sobre el túnel SSL. La autenticación con desafío / respuesta y el acuerdo de clave de sesión de Diffie-Hellmann deben bloquear la mayoría de los atacantes sin acceso físico a ambos lados del enlace de comunicación.

    
respondido por el AlexR 05.08.2013 - 21:50
fuente

Lea otras preguntas en las etiquetas