Entendiendo la seguridad del certificado

El certificado no contiene el hash; es, de alguna manera, al revés.

Puede ser más sencillo omitir la noción de "hash" y hablar de la firma directamente. Los contenidos del certificado de Bob (en particular, el nombre de Bob y la clave pública de Bob) están firmados por el CA. Trudy no puede modificar un bit de ella sin invalidar la firma; y Trudy no puede arreglar la firma posteriormente porque el algoritmo de la firma es criptográficamente fuerte, y Trudy no conoce la clave privada de CA. Esto es lo que evita el problema al que te estás refiriendo. De hecho, un certificado es inmutable .

Ahora, ¿dónde encaja la función hash en eso? Es un componente técnico de la firma digital. Cuando algunos datos deben firmarse, los datos primero se trocean, lo que da como resultado un valor de hash que luego se utiliza como entrada para el resto del algoritmo de firma. Hacemos esto porque los algoritmos de firma utilizan objetos matemáticos con una estructura pesada que no puede acomodar datos de longitud arbitraria; un valor hash tiene un tamaño corto y fijo (por ejemplo, 20 bytes si la función hash es SHA-1), por lo que el algoritmo de firma funciona bien en eso. El uso de una función hash intermedia también es seguro porque la función hash es resistente a la preimagen de segundo . Este es un término técnico que significa que Trudy no puede modificar los datos sin modificar también el valor hash (y, por lo tanto, invalidar la firma).

No hay un campo de "valor hash" en el certificado, que podría cambiarse de forma independiente; en su lugar, el valor de hash se calcula dinámicamente sobre el certificado completo (es decir, todo lo que está firmado). Este cálculo lo realiza la CA cuando firma el certificado; Lo vuelve a hacer quien verifique la firma.

(Para ser precisos, la presencia de esta función hash también es importante para la seguridad de algunos algoritmos de firma, por ejemplo, DSA, pero eso es técnico. No ocultemos el problema).

El hash del certificado produce una huella digital única para el contenido de los certificados, incluido el nombre, las fechas, el firmante, la clave, todo. Si cambia alguna parte del certificado (que incluye reemplazar la clave pública con la suya propia), el hash almacenado ya no coincide con el contenido.

Entonces, ¿dices que reemplazas el hash también? No del todo: cada certificado está firmado y firmado significa que el hash está cifrado con la clave privada del firmante. No puede reemplazar el hash sin reemplazar la firma (porque el hash es parte de la firma), y no puede reemplazar la firma sin volver a firmar el certificado, y no puede volver a firmar el certificado a menos que tenga la clave privada del firmante.

Así que la única parte que podría reemplazar la llave de Bob con la de Trudy's es la CA. Y el punto central de la PKI es que confías en que la CA no haga eso. Si no puedes confiar en la CA, todo el sistema se desmorona.

Real World Note
Tenga en cuenta que este es precisamente el problema con el SSL PKI global que tenemos hoy. No sabemos si podemos confiar más en las AC. Específicamente, no sabemos si las organizaciones poderosas (gobiernos, etc.) están presionando a las AC para que firmen certificados ilegítimos. Es muy posible que el ejército chino o la NSA de EE. UU. Tengan certificados válidos y firmados para Google, Facebook o cualquier otra organización. Aquí es donde fijación de certificados entra en juego. Y, de hecho, Chrome y varios otros navegadores de manera predeterminada establecen certificados para Google y otros servicios populares, por lo que incluso un certificado válido no se acepta a menos que sea un certificado válido específico , o firmado por un específico CA.