Habiendo generado parámetros DH de 2048 bits, ¿necesito regenerarlos regularmente? Si es así, ¿con qué frecuencia debo hacer esto?
Habiendo generado parámetros DH de 2048 bits, ¿necesito regenerarlos regularmente? Si es así, ¿con qué frecuencia debo hacer esto?
En términos generales, no, no tiene que volver a crear los parámetros con regularidad.
Diffie-Hellam se rompe al resolver el problema logaritmo discreto (técnicamente, no hay pruebas de que uno debo resolver DL para romper DH, pero sigue siendo el método más conocido). Sucede que si puede romper una instancia de DL, entonces puede reutilizar gran parte del trabajo para romper otras instancias de DL, siempre que todos usen el mismo módulo (es decir, el mismo "DH parámetros "). En el caso del reciente " ataque Logjam "esto se puso en uso: dado que algunos clientes y servidores aceptan usar un módulo débil (de 512 bits) y, además, todos parecen usar el módulo same , los atacantes, después de haber roto DL una vez (a través de un esfuerzo significativo), ahora puede hacer lo mismo nuevamente para ese módulo específico en tiempo casi real, que luego hace que MitM práctico.
Sin embargo, el "si" inicial es grande. Normalmente, usaría parámetros de DH que son lo suficientemente grandes como para evitar que tenga lugar el esfuerzo inicial de romper el DL. No quieres que los atacantes amplíen un éxito inicial en MitM fácil, pero tampoco quieres que logren ese éxito inicial. Al usar un módulo de 2048 bits, ya está bastante lejos en la zona "no se puede romper". Consulte este sitio para obtener más información. Además, incluso en un escenario de ciencia ficción donde su DH se rompe, estos seguirán siendo los parámetros sus , y el esfuerzo de ataque no será aplicable a otros servidores, lo que significa que los esfuerzos de ruptura en el Los parámetros DH de otras personas no afectarán a usted . Al utilizar los parámetros que genera usted mismo, ya obtiene la mayor parte de la protección. De hecho, incluso con un módulo de 512 bits, usar sus propios parámetros en lugar de los "estándar" ya ofrecería una gran protección, ya que si bien la interrupción inicial de un módulo de 512 bits es factible, todavía es una esfuerzo que los atacantes probablemente no realicen si solo desbloquea el acceso a un solo servidor (el suyo).
Otra forma de ver esa pregunta es considerar la clave del servidor. En SSL / TLS con DHE, el cliente y el servidor realizan un intercambio de claves Diffie-Hellman, pero el servidor también firma lo que envía (generalmente con RSA). La clave del servidor no debe estar también hecha por los atacantes, ya que de lo contrario ese atacante podría hacerse pasar por el servidor y, nuevamente, ejecutar ataques MitM sencillos. Por lo tanto, independientemente de lo que haga con los parámetros DH, aún debe cuidar su clave de servidor; en otras palabras, no es útil hacer que la parte DH sea realmente más fuerte que la parte de firma (RSA). Esto se extiende a la noción de renovación de clave: si siente que debe renovar su clave RSA cada tres años (esto es un ejemplo), es posible que desee renovar sus parámetros DH en el mismo horario. Es inútil renovarlo más a menudo que eso. De manera similar, dado que las claves DH y RSA parecen ofrecer una resistencia similar para la misma longitud, deseará usar un módulo DH de 2048 bits si también usa una clave RSA de 2048 bits.
Técnicamente, la renovación de claves es inútil, pero la gente tiende a creer que las renovaciones clave otorgan beneficios de seguridad supremos de una manera muy específica, y les gusta mucho. Si siente que necesita renovar su clave RSA de manera regular, para poder dormir mejor por la noche, entonces hágalo. Las mismas razones psicológicas se aplicarían a los parámetros de DH, por lo que si lo suyo es la renovación, entonces renueve los parámetros el mismo día.
(Si queremos entrar en detalles complicados, podemos argumentar que la clave RSA del servidor es para un modelo de seguridad diferente a los parámetros DH, ya que las firmas son para la autenticación inmediata del servidor, mientras que el DH debe resistir la grabación y la ruptura ulterior, posiblemente años después, dependiendo del tipo y el valor de los datos que están protegidos. Sin embargo, una conversación grabada en el pasado no se ve afectada por renovaciones posteriores, por lo que este argumento no se aplica en última instancia a la pregunta actual.)
Lea otras preguntas en las etiquetas diffie-hellman