uso del certificado para la firma y el cifrado

Un certificado es simplemente una clave pública que ha sido firmada por un tercero y es parte de un par de claves como usted describió. (o en el caso de certificados autofirmados, está firmado por la primera parte). También vale la pena señalar que el remitente solo necesita un par de llaves si necesita autenticación (es decir, el destinatario sabe que el mensaje proviene del remitente) además de la confidencialidad.

El remitente cifraría el mensaje con una clave secreta y luego cifraría esa clave secreta con la clave pública del destinatario. La clave secreta cifrada y el mensaje cifrado pueden enviarse y solo el destinatario puede descifrar el mensaje descifrando la clave secreta del mensaje. Si se necesita verificación, el HMAC del mensaje se puede cifrar con la clave pública del remitente y el certificado incluido con el mensaje. Si el certificado está firmado por un tercero de confianza, el destinatario sabe que la clave pública es válida y puede usarla para verificar el HMAC, verificando así que el remitente tiene la clave privada que corresponde al certificado.

El destinatario del mensaje cifrado debe poder verificar la firma del mensaje aplicada por el remitente del mensaje. La firma del mensaje se calcula como un hash del contenido del mensaje, cifrado con la clave PRIVADA del remitente. Lo que el destinatario debe hacer para verificar la firma es descifrar el mensaje (usando la clave privada del destinatario), calcular el hash del contenido del mensaje y luego descifrar el valor de la firma provisto con la clave PÚBLICA del remitente. Si la versión descifrada de la firma coincide con el hash calculado localmente del mensaje, entonces la firma es "válida" y el destinatario puede estar seguro de que el mensaje no se ha modificado desde que se cifró.

Aquí es donde los certificados entran en este escenario: el destinatario necesitaba usar la clave PÚBLICA del remitente para verificar la firma. Para hacer esto, el destinatario debe tener el certificado del remitente, firmado por una Autoridad de Certificación de confianza (por ejemplo, Verisign, GoDaddy, etc.).

Entonces, el único absoluto en este escenario es que el destinatario del mensaje debe tener el certificado del remitente y confiar en el firmante de ese certificado.

Los certificados son útiles porque incluso si tiene un par de claves, eso no significa que solo puede enviar a alguien su clave pública y el receptor sabrá que usted controla la clave privada correspondiente. Debe haber alguna forma para que el receptor asocie esa clave con su identidad (su "yo"). De lo contrario, un atacante podría simplemente enviar al servidor su clave pública, afirmando que es suya, y el mensaje se le enviaría a él (o, a la inversa, podría recibir una clave pública de un servidor falso y recibir un mensaje que esté correctamente cifrado). , firmado, pero no vino de quien crees que vino).

Una forma de intercambiar las claves de forma segura sería en persona, pero eso es engorroso y no siempre es factible. Otra opción es utilizar un tercero de confianza en el proceso: la Persona A firmó las claves públicas de la Persona B y la Persona C y asoció cada clave con el ID del titular, siempre que B tenga una copia de la clave pública de A puede verificar que la clave de C coincide con la ID de C (incluso si esa clave / certificado se envió a través de un canal inseguro). Por lo tanto, B puede enviar mensajes confidenciales a C (y, como se señala en la la respuesta de AJ Henderson , lo contrario también es necesario si B quiere firmar el mensaje: C debe tener la clave pública de A para verificar la identidad de B).

Entonces, respondiendo a su pregunta, los certificados juegan un papel en su proceso en la fase de intercambio de claves públicas, todo lo demás es como lo describió. El contenido de un certificado es una clave pública asociada a un identificador (ya sea un nombre de dominio u otra cosa que lo identifique de manera única, y que un tercero honesto no firmaría si no lo conociera / no confiara en usted). Y para quién posee qué, normalmente ambos poseen una lista de terceros de confianza, utilizada para la verificación, pero nada le impide tener también una lista de certificados conocidos de personas de confianza (en cuyo caso no importa si un tercero o no) partido los firmó).

Actualización: un ejemplo completo, diseñado para adaptarse a su escenario:

Alice (Servidor A) quiere enviar un mensaje a Bob (Persona B), con la ayuda de su conocido común Charles Augustus . Cada uno tiene un par de claves, compuesto por una clave privada (AA, BA y CA) y una clave pública (AB, BB y CB), y un certificado que asocia su clave pública a sus nombres (AC, BC y CC). Charlie firmó su propio certificado (CC $ C) con su clave privada.

Cuando Alice y Charlie se conocieron en persona, Charlie firmó el certificado de Alice usando su clave privada (AC $ C), luego de confirmar que Alice controlaba la clave privada correspondiente (AA), que el certificado contenía el nombre de Alice (el nombre de dominio del servidor ) más la clave pública (AB) y que ella no era una impostora. Alice también recibió una copia del certificado de Charlie. Algún tiempo después, Bob hizo lo mismo (obtener BC $ C, usar su identificación o alguna otra prueba de identidad, ya que las personas no tienen nombres de dominio).

Cuando Alice quiere enviar un mensaje a Bob, esto es lo que sucede:

1. Bob envía su certificado (BC $ C) a Alice;
2. Alice confirma que el certificado tiene el nombre de Bob y que fue firmado por Charlie;
3. Como Alice tiene el certificado de Charlie (CC $ C), usa la clave pública (CB) que contiene para verificar la firma (hecha con la clave privada CA);
   • ahora confía en que Bob controla la clave privada (BA) que empareja la clave pública (BB) que contenía el certificado de Bob.
4. "Ahora firmo el mensaje con la clave privada AA y lo cifro con la clave pública BB en el servidor A. La persona B verifica la firma con la clave pública AB y la desencripta con la clave privada BA".
5. Ahora Bob tiene el mensaje, pero necesita estar seguro de que realmente vino de Alice. Por cierto, Alice también envió su certificado (AC $ C) junto con el mensaje (así es como Bob obtuvo la clave pública AB);
6. Bob confirma que el certificado tiene el nombre de Alice y que fue firmado por Charlie;
7. Como Bob tiene el certificado de Charlie (CC $ C), usa la clave pública (CB) que contiene para verificar la firma (hecha con la clave privada CA);
   • ahora confía en que Alice controla la clave privada (AA) que empareja la clave pública (AB) que contiene su certificado de Alicia.

Se han realizado certificados para servir como transporte para las claves públicas. Además, se pueden utilizar para agregar confianza.

TL; DR: su escenario no cambia un poco con el certificado si no necesita autenticación.

Por ahora, supongamos que un certificado contiene una clave pública. Entonces puedes compartirlo públicamente con la galaxia afirmando que esta es la clave pública que pertenece a Obi-Wan Kenobi. Ya que tiene la clave privada correspondiente en su computadora, podrá descifrar cualquier mensaje cifrado con la clave pública del certificado y firmar el mensaje con su clave privada.

Sin embargo, nadie puede confirmar que eres quien dices ser, es decir, Obi-Wan ("eso no es cierto, eso es imposible"). Para que esto suceda, es necesario que el mundo pueda autenticar que su certificado pertenece a Obi-Wan Kenobi. Ahora supongamos que la galaxia puede confiar en que la República y la administración de la República publiquen una clave pública y mantengan su clave privada. Son una entidad emisora de certificados raíz. Este certificado público será autofirmado y para que ocurra la confianza, toda la galaxia DEBE confiar en este certificado.

Dado que toda la galaxia confía en un solo certificado raíz, ahora uno puede ir a la oficina de la República con su ID y su propia clave pública generada. Después de verificar la identidad de la persona, digamos que usted es el verdadero Obi-Wan Kenobi (¡guau!), La oficina creará su certificado. Este certificado indicará su identidad e incrustará su clave pública. Finalmente, utilizando las claves privadas de la República, firmarán su certificado, por lo tanto, vincularán su identidad a su clave pública. Cualquier persona que tenga su certificado y la clave pública de la República podrá verificar la firma de la República. Suponiendo que sea válido y que confíen en el certificado raíz de Repuplic, ahora pueden estar seguros de que el certificado que obtienen pertenece a Obi-Wan Kenobi y a nadie más.

Finalmente, su certificado contiene su clave pública Y se puede demostrar que pertenece a Obi-Wan. Por lo tanto, cualquier persona que cifre cosas con esa clave pública en particular tiene la garantía de que solo puede ser leído por dicho Obi-Wan Kenobi, el único propietario de la clave privada.

Nota: eventualmente, para su caso con dos actores, deberá repetir el proceso de registro dos veces.