it-swarm-es.com

¿Por qué no se debe usar la misma clave asimétrica para el cifrado que para la firma?

En un respuesta a una pregunta sobre RSA y PGP, PulpSpy señaló esto:

Es posible generar un par de claves RSA utilizando GPG (tanto para el cifrado como para la firma; no debe utilizar la misma clave para ambos).

¿Cuál es el razonamiento detrás de esto?

Quizás mi comprensión del cifrado de clave pública es defectuosa, pero pensé que las operaciones fueron algo similar a esto:

  • Cuando Bob quiere cifrar un mensaje a Alice, usa la clave pública de Alice para el cifrado. Luego, Alice usa su clave privada para descifrar el mensaje.
  • Cuando Alice quiere firmar digitalmente un mensaje a Bob, usa su clave privada para firmarlo. Bob luego usa la clave pública de Alice para verificar la firma.

¿Por qué es importante usar diferentes claves para el cifrado y la firma? ¿No significa esto también que necesita distribuir dos claves públicas a todas las personas con las que desea comunicarse? Me imagino que esto fácilmente podría generar cierta confusión y mal uso de las teclas.

100
Iszi

Es principalmente que los enfoques de gestión y los plazos difieren para el uso de claves de firma y cifrado.

Para no repudiar, nunca querrá que otra persona controle su clave de firma, ya que podría suplantarlo. Pero su lugar de trabajo puede querer guardar su clave de cifrado para que otros que lo necesiten puedan acceder a la información que ha cifrado.

También es posible que desee que una clave de firma sea válida durante mucho tiempo para que las personas de todo el mundo puedan verificar las firmas del pasado, pero con una clave de cifrado, a menudo desea renovarla antes y poder revocar las antiguas sin muchas molestias.

69
nealmcb

Es potencialmente inseguro usar el mismo par de claves tanto para la firma como para el cifrado. Hacerlo puede permitir ataques, dependiendo del esquema particular de clave pública que use. Este tipo de uso no es para lo que se diseñó el sistema, por lo que usar el sistema de una manera que no fue diseñada "anula la garantía".

No lo hagas Está pidiendo problemas.

34
D.W.

Hay algunas razones por las que no debemos usar la misma clave para el cifrado y la firma.

  1. Necesitamos hacer una copia de seguridad de nuestra clave secreta para datos cifrados. Más adelante queremos descifrar algunos mensajes cifrados antiguos, pero no necesitamos hacer una copia de seguridad de nuestra clave secreta para firmar. Si el atacante encuentra la clave, podemos decirle a nuestra CA que la revoque y obtenga una nueva clave secreta para firmar sin necesidad de respaldo.

  2. Más importante: Si usamos la misma clave para el cifrado y la firma, el atacante puede usar esto para descifrar nuestro mensaje cifrado. Esto es lo que él/ella haría:

    El atacante debe elegir un número aleatorio r, donde

    r debe tener GDC(N, r) = 1,
    Y N es el número utilizado para crear la clave pública y privada (N = pq)

    Luego, el atacante elige un nuevo mensaje (m′) Y lo envía para firmar al remitente:

    m′ = m^e.r^e ... (aquí (e,n) Es la clave pública)

    Cuando el remitente firma m′ Obtenemos

    m′^d ≡ (m^e.r^e)^d ≡ m.r (mod N)

    Ahora el atacante solo necesita "dividirlo" entre r para obtener m (el mensaje secreto).

12
Am1rr3zA

Razones para usar claves separadas para la firma y el cifrado:

  1. Útil en la organización donde la clave de cifrado debe respaldarse o mantenerse en custodia para descifrar los datos una vez que un empleado/usuario de la organización ya no esté disponible. A diferencia de la clave de cifrado, la clave de firma nunca debe ser utilizada por nadie más que el empleado/usuario y no debe ni debe mantenerse en custodia.
  2. Permite tener diferentes tiempos de vencimiento para firmar una clave de cifrado.
  3. Dado que las matemáticas subyacentes son las mismas para el cifrado y la firma, solo a la inversa, si un atacante puede convencer/engañar a un titular de clave para que firme un mensaje cifrado sin formato utilizando la misma clave, entonces el atacante obtiene el original.

¡Referencias

  1. https://www.entrust.com/what-is-pki/

  2. https://www.gnupg.org/gph/en/manual/c235.html

  3. http://www.di-mgt.com.au/rsa_alg.html

7
moo

Para mí, las razones principales están relacionadas con la administración de claves, en lugar de la seguridad criptográfica per se.

Para la criptografía asimétrica, especialmente el período durante el cual desea que una clave pública sea válida puede depender en gran medida del uso previsto de esa clave. Por ejemplo, considere un sistema en el que un componente debe autenticarse ante otros componentes. Además de eso, ese componente también debe crear regularmente una firma sobre algunos datos. En teoría, una sola clave privada podría usarse para ambos propósitos. Sin embargo, suponga que la Autoridad de Certificación PKI por razones de seguridad quiere limitar el período durante el cual puede llevarse a cabo una autenticación exitosa basada en un solo certificado a dos años. Al mismo tiempo, las leyes de retención de datos pueden requerir que los datos se conserven durante cinco años, y que la firma sobre esos datos debe ser verificable durante todo ese período. La única forma (sólida) de resolver este problema es darle al componente dos claves privadas: una para la autenticación y otra para la firma. El certificado de la primera clave caducará después de dos años, el certificado de firma caducará después de cinco años.

Se pueden aplicar razonamientos similares a la criptografía simétrica: si usa diferentes claves para diferentes propósitos, puede decidir sobre todas las cuestiones de administración de claves (por ejemplo, la frecuencia de la transferencia de la clave maestra, el período para hacer una copia de seguridad de las claves, etc.) según sobre los requisitos de un solo propósito. Si usa una sola tecla (maestra) para múltiples propósitos, puede terminar con requisitos conflictivos.

5
David Bakker

El cifrado RSA se basa en una función Trapdoor, es decir, un par de funciones. Los llamaré D y E. Las funciones están diseñadas de modo que D(E(x)) = x y E(D(x)) = x (para cualquier x). En otras palabras, D y E son inversas. Lo que la convierte en una función Trapdoor es que si tiene una clave pública, solo puede calcular E (prácticamente hablando). Si tiene una clave privada, puede calcular tanto D como E.

La forma en que funciona el cifrado es bastante obvia a partir de esa descripción. Si Bob quiere enviarle un mensaje cifrado a Alice, calcula ciphertext := E(plaintext). Entonces Bob envía ciphertext a Alice. Alice calcula D(ciphertext), que es D(E(plaintext)), que es solo plaintext.

Ahora, hablemos sobre cómo funciona la firma. Si Alice quiere firmar message, entonces calcula signature := D(message). Luego envía tanto message como signature a Bob. Bob luego calcula validation := E(signature). Como signature es D(message), entonces validation = E(D(message)) = message.

En otras palabras: para firmar un mensaje, actúas como si lo estuvieras descifrando, y esa es tu firma. Para verificar su firma, las personas pueden encriptar la firma y asegurarse de recuperar su mensaje original.

Lo diré nuevamente: la firma es la misma operación que el descifrado.

Esta es la preocupación fundamental sobre la separación de las claves de firma y cifrado. Si alguien puede hacer que firmes algo, entonces te acaba de descifrar.

Supongamos que dirige una empresa notarial. Si alguien le da $ 10 y un mensaje (por ejemplo, la letra de la canción), entonces firmará ese mensaje y se lo devolverá. Si luego alguien copia la letra de su canción, puede producir la firma de la compañía notarial de confianza para demostrar que escribió la letra de la canción.

Ahora suponga que Eve interceptó un mensaje cifrado a su notario. ¿Cómo puede ella subvertir el cifrado? ¡Ella te envía el mismo mensaje para la notarización! Ahora ejecuta la operación de firma (que, recuerde, es lo mismo que la operación de descifrado) y le envía el resultado. Ella ahora tiene el mensaje descifrado.

En la práctica, los protocolos tienen pasos que hacen que este ataque sea más difícil. Por ejemplo, PGP (con lo que me refiero al protocolo; gpg es la implementación más común aquí) no firma el mensaje original; Firma un hash del mensaje. Pero las pruebas de seguridad son mejores en situaciones simples. No desea que su prueba sobre la seguridad de RSA dependa de la función hash. (Por ejemplo, muchas personas usaron MD5 como el hash preferido durante mucho tiempo, pero hoy se considera que MD5 está bastante roto). Solo, la seguridad de RSA depende de la idea de que no firmará mensajes arbitrarios con una clave que se usa para el cifrado. Mantener ese requisito en su lugar es la mejor manera de garantizar la seguridad de PGP. (Como recuerdo, esta es la advertencia más frecuente sobre el cifrado asimétrico en el libro de Bruce Scheier Criptografía aplicada .)

Ahora, hablemos de otra pregunta que hizo: "¿Esto no significaría también que necesita distribuir dos claves públicas a todas las personas con las que desea comunicarse?"

Una "clave" significa una cosa para los usuarios y otra diferente para las implementaciones de cifrado. Solo necesita comunicar una "clave" de nivel de usuario, aunque puede contener muchas claves públicas RSA.

PGP tiene un concepto de subclaves. Mi clave maestra es una clave de solo firma. Tengo una subclave de cifrado separada. Esa subclave está firmada por mi clave maestra. Si importa mi clave PGP de los servidores de claves o la descarga de mi sitio web, obtendrá mi clave maestra y todas mis subclaves. Aunque es posible que haya firmado solo mi clave maestra, mi clave maestra ha firmado mi subclave de cifrado, por lo que sabe que también me pertenece. Eso significa que al descargar mi clave PGP (que abarca muchas claves públicas RSA), ahora tiene todo lo que necesita tanto para verificar mis firmas como para cifrarme mensajes.

Con las subclaves, la administración de claves es más compleja desde un punto de vista criptográfico (hay que seguir un paso de verificación de clave adicional), pero no desde un punto de vista práctico (mi clave PGP incluye mi clave maestra, así como todas mis subclaves). La complejidad adicional está oculta en la implementación y no está expuesta al usuario.

2
Piquan