encryption - tls - Mejores prácticas para encriptar datos UDP pequeños/continuos
dtls (4)
Esta pregunta es un poco antigua, pero ¿qué hay de usar un enfoque tipo One Time Pad ? Podría usar un mecanismo de transporte seguro y confiable (como HTTPS) para transmitir las claves únicas del servidor a su cliente. Podría haber dos conjuntos de claves: una para el cliente y otra para el servidor. Cada datagrama incluiría un número de secuencia (usado para identificar la clave de una sola vez) y luego el mensaje cifrado. Debido a que cada clave se usa para un solo datagrama, no debe exponerse al problema de los datos pequeños. Dicho esto, no soy un experto en esto, así que definitivamente compruebe esta idea antes de usarla ...
Tengo una aplicación a la que debo enviar varios datos pequeños por segundo a través de la red mediante UDP. La aplicación debe enviar los datos en tiempo real (sin espera). Quiero cifrar estos datos y asegurarme de que lo que estoy haciendo sea lo más seguro posible.
Ya que estoy usando UDP, no hay forma de usar SSL / TLS, por lo que tengo que cifrar cada paquete solo ya que el protocolo es sin conexión / no confiable / no está regulado.
En este momento, estoy usando una clave de 128 bits derivada de una frase de contraseña del usuario y AES en modo CBC (PBE utilizando AES-CBC). Decidí usar una sal aleatoria con la frase de contraseña para derivar la clave de 128 bits (evitar el ataque del diccionario en la frase de contraseña) y, por supuesto, usar IV (para evitar el análisis estadístico de los paquetes).
Sin embargo, me preocupan algunas cosas: cada paquete contiene una pequeña cantidad de datos (como un par de valores enteros por paquete) que harán que los paquetes encriptados sean vulnerables a ataques de texto simple conocidos (lo que hará que sea más fácil descifrar la clave) . Además, dado que la clave de cifrado se deriva de una frase de contraseña, esto hará que el espacio de la clave sea mucho menor (sé que la sal ayudará, pero tengo que enviar la sal a través de la red una vez y cualquiera puede obtenerla). Dadas estas dos cosas, cualquiera puede oler y almacenar los datos enviados e intentar descifrar la clave. Aunque este proceso puede tardar un tiempo, una vez que se craquea la clave, todos los datos almacenados serán descifrados, lo que será un problema real para mi aplicación.
Entonces, mi pregunta es, ¿cuáles son las mejores prácticas para enviar / cifrar datos pequeños continuos usando un protocolo sin conexión (UDP)? ¿Es mi manera la mejor manera de hacerlo? ... fluyó? ... ¿Exagerar?
Tenga en cuenta que no estoy pidiendo una solución 100% segura, ya que no existe tal cosa.
Si su problema es que los datos son demasiado pequeños, ¿qué tal extender los datos con bytes aleatorios? Esto hará que el texto simple sea mucho más difícil de adivinar.
Tienes varias opciones. Puede usar DTLS, que es una versión de TLS adaptada para datagramas. Se especifica en un RFC y se implementa en la biblioteca openssl. También puede usar el protocolo IKE / IPsec y usar una encapsulación UDP de la parte de IPsec. Por lo general, IPsec está disponible a nivel del sistema operativo. También puede usar OpenVPN , que parece ser un híbrido de TLS para el intercambio de claves y un protocolo de cifrado de paquetes patentado basado en UDP.
Use el intercambio de claves Ecdh (use una contraseña para cifrar la clave privada del cliente; se deja en el cliente) en lugar de una contraseña. Esta es una clave muy fuerte.
Aes cbc no te ayuda; los mensajes son demasiado cortos y desea evitar los ataques de reproducción. Rellene su mensaje de 64 bits (dos enteros) con un contador (comenzando con 0) 64 bits significa que se pueden enviar 2 ^ 64 mensajes. Cifre el bloque dos veces (aes ecb) y envíe e (k; m | count) | e (k; e (k; m | count)). El receptor solo acepta conteos monótonamente crecientes donde el segundo bloque es el cifrado del primero. Estos son mensajes de 32 bytes que encajan bien en un paquete udp.
si 2 ^ 64 mensajes es demasiado pequeño; vea si su mensaje podría ser más pequeño (los enteros de 3 bytes significan que el contador puede ser de 80 bits); o vuelva al paso 1 (nuevas claves privadas para al menos un lado) una vez que esté cerca (digamos 2 ^ 64-2 ^ 32) hasta el límite.