Cómo prevenir un ataque de DoS computacional en sistemas criptográficos de clave pública

1

Estoy diseñando un servidor que acepta mensajes anónimos usando ECIES: al igual que en, los usuarios anónimos envían al servidor una clave pública EC efímera, y el servidor usa ECDH para derivar un secreto compartido, y algunos KDF para obtener una clave simétrica compartida para descifrar el mensaje real. El problema es que ECDH, que se encuentra entre el intercambio de claves más rápido disponible, es realmente lento. A partir de algunas pruebas rápidas, mi computadora solo puede manejar aproximadamente 3000 intercambios de teclas por segundo.

Un atacante podría estar constantemente calculando intercambios de claves y enviándolos al servidor. No estoy muy preocupado por esto si el atacante realmente ha hecho los intercambios de claves. Al menos de esa manera, el atacante estará haciendo tanto trabajo (un poco más con ECDH) como el servidor. El problema es que un atacante puede enviar una clave de basura y hacer que el servidor realice un gran trabajo para realizar el intercambio de claves en la basura. Mi primera pregunta es que, en una implementación razonable como OpenSSL, ¿el intercambio de claves volverá rápidamente con un error o tardará mucho tiempo en realizar cálculos inútiles?

Suponiendo que lo anterior sea fijo, hay dos problemas más: un atacante podría usar la misma clave efímera una y otra vez, manteniendo el secreto compartido pero haciendo que el servidor realice el intercambio de claves repetidamente; y un atacante podría calcular de antemano muchas claves efímeras y enviarlas todas a la vez.

Un intento de una solución a ambos problemas es que el servidor mantenga su propio par de claves efímero que cambia cada ~ 10 minutos. Puede publicar su clave pública efímera firmada con su clave privada permanente. Entonces no sería irrazonable que el servidor recuerde las claves y los secretos correspondientes recibidos durante este período. Sin embargo, esto realmente no resuelve el ataque de precomputación porque las claves EC generadas correctamente seguirán funcionando con un intercambio de claves, solo producirían datos de basura. ¿Existe alguna forma rápida para que un servidor sepa que una clave determinada descifra el mensaje?

Lo siento por el largo post, y gracias de antemano por cualquier comentario.

    
pregunta tomKPZ 30.07.2014 - 07:47
fuente

2 respuestas

1

Su índice de referencia posiblemente esté incompleto. Tengo un servidor que cuenta con una CPU reportada como: "Intel (R) Xeon (R) CPU E3-1220 V2 a 3.10GHz". Tiene cuatro núcleos. En esa máquina, OpenSSL 1.0.1f informa (con openssl speed ecdhp224 ) que puede realizar 9096 instancias de ECDH por segundo, utilizando la curva NIST P-224 (una curva fina, de seguridad clasificada en "112 bits", comparable a RSA- 2048). Esto es en un solo núcleo : la máquina tiene cuatro núcleos, por lo que puede hacer 36000 ECDH por segundo, 12 veces más que los números que informa.

Recibir 36000 mensajes individuales por segundo puede ser un desafío. Un servidor habitual similar a Unix puede tener problemas de E / S mucho antes de aceptar 36000 conexiones TCP por segundo. Incluso con UDP, es muy posible que los costos de E / S dominen, no la criptografía. Esto requiere de puntos de referencia.

Uno puede notar que estas cifras implican un costo elemental de aproximadamente 340000 ciclos por multiplicación de puntos EC. Otras curvas con implementaciones optimizadas pueden hacerlo mejor. Este artículo informa sobre velocidades de cálculo de hasta 55000 ciclos de reloj para la curva K-233 (que ofrece seguridad similar a P-224), lo que se traduciría a más de 225000 ECDH por segundo en mi servidor (creo que vi un artículo más reciente que lo optimizó aún más, hasta aproximadamente 40000 ciclos de reloj, pero no lo encuentro en este momento ). Lo que muestran estas cifras es que debería poder lograr un rendimiento mucho mejor mientras se adhiere a las ECIES estándar (con curvas estándar).

Por lo tanto, recomiendo invertir el camino de "implementación optimizada", en lugar de recurrir a modificaciones de protocolo: parece probable que pueda llevar el costo relacionado con la criptografía muy por debajo de los costos de E / S.

    
respondido por el Thomas Pornin 30.07.2014 - 16:57
fuente
1

Llevará mucho tiempo hacer cálculos inútiles.
Uno podría utilizar un verificador designado no interactivo computacional
Argumento de conocimiento cero de que el resto del mensaje está bien formado.

Más útil, use pruebas de trabajo y PKE con descifrado rápido .

    
respondido por el user49075 30.07.2014 - 08:02
fuente

Lea otras preguntas en las etiquetas