¿Por qué PKI usa una función hash?

3

Comenzaré mi pregunta con mi comprensión de PKI en caso de que tenga alguna idea errónea.

  1. El propietario del dominio D genera un par de claves público-privadas (d, e) y construye un certificado c que consiste en (d, D, rango de tiempo, otros metadatos).

  2. D convence a la autoridad de certificación X de que la información en c es precisa.

  3. X calcula H (c) usando una función criptográfica de troceo H.

  4. X cifra H (c) utilizando su clave privada para generar c ', y le devuelve esto a D.

  5. Intento acceder a D, y D me envía (c, c ')

  6. Mi navegador aplica la clave pública de X a c 'y se compara con H (c).

  7. Si coinciden, mi navegador confía c condicionalmente en confiar en X. Repita hasta una autoridad de certificado raíz de confianza implícita.

Los problemas con H pueden debilitar el esquema; esta es la razón por la que las personas dejaron de usar MD5 y se están alejando de SHA1. Entonces, ¿por qué no saltarse el paso 3 y cifrar c directamente?

A mi entender, una razón es limitar la longitud del mensaje a cifrar / descifrar en los pasos 4, 6. Sin embargo, mi navegador solo necesita realmente (d, D, rango de tiempo) (y ni siquiera D para CA intermedias) ). Esto está limitado, probablemente < 10 veces la longitud de H (c), y generalmente mucho más corta que el contenido de la página que mi navegador probablemente descifre de todos modos. Los metadatos podrían ser útiles para auditar las CA para mantenerlos honestos, pero esa información podría ser proporcionada por separado por la CA (p. Ej., Escrita en este solo anexar registro ).

    
pregunta stewbasic 30.05.2016 - 01:13
fuente

3 respuestas

0

Su pregunta principal es:

  

Los problemas con H pueden debilitar el esquema; esta es la razón por la que las personas dejaron de usar MD5 y se están alejando de SHA1. Entonces, ¿por qué no saltarse el paso 3 y cifrar c directamente?

Sí, el MD5 actualmente se puede dividir en aproximadamente 2 24.1 conjeturas (24.1 bits de seguridad). SHA1 actualmente ofrece alrededor de 80 bits de seguridad contra los mismos ataques. ¿Estás diciendo que eliminar el hash por completo y obtener 0 bits de seguridad es de alguna manera una mejora?

Tu comprensión es cercana, pero parece que te faltan algunos conceptos básicos.

La respuesta de @ReyRyan da la respuesta directa: que el criptográfico asimétrico como RSA solo puede funcionar con una entrada de longitud fija.

Para ampliar eso, dijiste:

  

[el certificado es] generalmente mucho más corto que el contenido de la página que mi navegador probablemente descifre de todos modos.

Estás mezclando un montón de ideas erróneas diferentes aquí y comparando manzanas con naranjas.

  1. Lo que estás describiendo con "cifrar el hash" se llama un firma RSA . Estoy enojado incluso por llamarlo "cifrar el hash" porque técnicamente estás descifrando el hash usando la clave descifrado .

  2. En la práctica, las Autoridades de certificados reales utilizan Algoritmo de firma digital (DSA) o Elliptic Curve DSA que se basan en matemáticas completamente diferentes y que definitivamente no pueden describirse como "cifrar el hash".

  3. Comparando los tiempos de ejecución de "descifrar el hash" (también conocido como "verificar la firma") con el tiempo de ejecución de descifrar el contenido de la página web son manzanas y naranjas porque la firma se realiza con un criptográfico asimétrico (RSA o Criptografía de curva elíptica (ECC)), que como dijo @LieRyan, solo puede cifrar un solo bloque de longitud fija, mientras que el contenido de la página web está cifrado con simétrico cryto (generalmente AES ) que está diseñado para cifrar / descifrar datos en masa muy rápidamente.

Ignorando todo lo anterior, todavía hay una buena respuesta a la pregunta:

  

Entonces, ¿por qué no omitir el paso 3 y cifrar c directamente?

Porque esto sería mucho más fácil para un atacante falsificar. Usted está proponiendo que el servidor web proporcione una versión cifrada de su certificado que puedo descifrar con la clave pública de la AC. Como atacante puedo cambiar un byte del texto cifrado, descifrarlo con la clave pública de la CA y ver lo que dice, repetirlo varios miles de millones de veces hasta que tenga lo que parece ser un certificado legítimo de esa CA que dice ser el propietario del sitio web (es decir, la clave pública es una que tengo).

Agregar un hash al proceso detiene ese tipo de ataque porque también tienes que comprobar cuál es la imagen previa del hash del texto cifrado modificado e intentarlo de nuevo si no coincide. Al agregar un paso hash, hemos aumentado el costo de realizar este ataque de "un par de meses en una computadora portátil y ~ $ 10,000 en electricidad" a "siglos en una supercomputadora y una central eléctrica al tamaño del sol".

(estoy exagerando un poco, suponiendo que pudiéramos hacer cálculos de un solo electrón, solo construir un contador de 0 a 2 ^ 256 requeriría una energía equivalente a la mitad de la materia en la galaxia Vía Láctea ).

    
respondido por el Mike Ounsworth 30.05.2016 - 20:25
fuente
3

La razón principal de esto es que el algoritmo de cifrado asimétrico utilizado en la firma (RSA) no se puede usar para cifrar una gran cantidad de datos y es extremadamente lento. En particular, RSA no puede cifrar datos que son más grandes que su tamaño de clave :

  

RSA, como lo define PKCS # 1, encripta   "Mensajes" de tamaño limitado. Con el   comúnmente utilizado "v1.5 relleno" y un   Clave RSA de 2048 bits, el tamaño máximo de   Datos que pueden ser encriptados con RSA.   es de 245 bytes . No más.

La mayor parte de los datos cifrados cuando se utiliza el cifrado asimétrico se cifra realmente mediante un cifrado simétrico, como AES, con una clave generada aleatoriamente que luego se cifra mediante RSA y se envía junto con los datos. Así es como funcionan TLS, PGP, S / MIME y la mayoría de los otros sistemas de cifrado basados en PKI.

Un certificado PKI generalmente contiene más datos de los que caben en el límite de tamaño RSA porque un certificado contiene una clave pública RSA, que generalmente es del mismo tamaño que la propia clave RSA de la CA. Por lo tanto, necesitamos una forma de reducir el tamaño de los datos cifrados, mientras que seguimos representando fielmente todos los datos. Por lo tanto, el uso de hashing. El hash puede ser encriptado usando RSA directamente, en lugar de usar el método RSA + AES.

Si insistimos en que todo el certificado se firme con RSA simple, entonces la CA solo podrá firmar certificados cuya longitud de clave sea estrictamente más corta que la clave de la CA. Y cada paso de las CA intermedias solo podría firmar claves consecutivamente más pequeñas.

  

Los metadatos podrían ser útiles para auditar CAs para mantenerlos honestos

Los metadatos no se usan en realidad para mantener la honestidad de CA. Los metadatos en un certificado también codifican:

  1. el propósito del certificado (certificado de firma de código, certificado S / MIME, certificado de cliente, certificado de servidor),
  2. información de identificación sobre el propietario clave que la CA pudo verificar (nombre legal, identificador de la organización, dirección de la organización y jurisdicción legal), esto debe ser utilizado por el par para decidir si se está comunicando con la entidad correcta
  3. cómo encontrar la lista de revocación de certificados o el respondedor de OCSP, y
  4. el proceso que usó la CA para verificar el certificado, que representa la solidez de la certificación (EV, OV o DV).

Alguna información como CRL / OCSP no se puede comunicar de forma segura en un canal lateral, ya que anularía el propósito del campo.

    
respondido por el Lie Ryan 30.05.2016 - 17:46
fuente
0

Debido a que el cifrado asimétrico (también conocido como clave pública) es LENTO ... Literalmente, miles de veces más lento que el cifrado simétrico. Es más rápido simplemente cifrar una pequeña cantidad de datos (el hash) que una gran cantidad de datos.

    
respondido por el Swashbuckler 30.05.2016 - 21:02
fuente

Lea otras preguntas en las etiquetas