Pre clave pública compartida vs Certificado

2

Tengo un sistema en el que los clientes se comunican de forma segura con un servidor remoto a través de Internet mediante TLS. En este escenario, ¿de qué manera los certificados de servidor firmados por CA son mejores que compartir previamente la clave pública del servidor? Cuando la clave privada del servidor se ve comprometida, los nuevos pares de claves reemplazarán a la anterior, por lo que es una tarea agotadora volver a compartir el proceso para todos los clientes. En este caso, asumo que el certificado tiene una ventaja. Pero estoy en lo cierto?

    
pregunta Kumar 19.07.2017 - 15:46
fuente

2 respuestas

2

Comparemos los flujos de trabajo de los dos procesos, específicamente cómo se compromete la clave de manejo.

Secreto precompartido

El servidor genera un par de llaves, lo copia en cada máquina cliente (manualmente, a través de un script, etc.). Al conectarse al servidor, el cliente verificará que la clave pública presentada coincida con la que almacenaron en la memoria caché para ese servidor (conceptualmente, esto es lo mismo que el método de identificación de huellas dactilares de SSH).

Upside : no es necesario que le resulte inconveniente obtener un certificado firmado por CA. Puede generar el par de llaves del servidor y comenzar a implementarlo en los clientes inmediatamente.

Desventaja : la recuperación de un compromiso clave es difícil o imposible porque no hay un mecanismo para que el servidor notifique a los clientes un compromiso clave, excepto al enviar un nuevo par de llaves a todos los clientes. Tenga en cuenta que un atacante tiene la clave privada del servidor y puede interceptar el tráfico entre el cliente y el servidor (tanto para bloquear el empuje del par de llaves actualizado como para la conexión del cliente con el servidor). El cliente confiará en el atacante y creerá que está hablando con el servidor auténtico y no hay nada que pueda hacer para evitarlo porque, en un nivel fundamental, los secretos precompartidos no tienen un mecanismo de revocación.

Certificado

Sí, es molesto (y algunas veces costoso) obtener un certificado, pero la confianza ya no depende de su capacidad de enviar la clave precompartida a los clientes.

Parte del proceso de validación de un certificado es que el cliente se comunique con la CA y se asegure de que no se revoque el certificado y, si no llega a la CA, esto se considera un error. La suplantación de esta comprobación de revocación requiere que el atacante comprometa no solo la clave privada del servidor, sino también la clave privada de la AC. Si el servidor se da cuenta de que su par de llaves se ha comprometido y le pide a la CA que lo revoque, todos los clientes lo sabrán de inmediato porque las comprobaciones de revocación en línea fallarán.

La revocación es la razón principal para usar certificados aquí, pero también considere que un atacante puede interceptar el impulso inicial de la clave pública y reemplazarlo con su propia clave pública. Tal vez usted sea el administrador de la red y pueda garantizar la implementación segura de las claves públicas, pero los certificados lo convierten en un punto discutible porque incluso si el atacante puede interceptar la implementación del certificado, falsificar un certificado requiere comprometer la CA.

    
respondido por el Mike Ounsworth 19.07.2017 - 16:47
fuente
0

Con las claves previamente compartidas, debe proteger TODOS los puntos finales: servidor y clientes. Si uno de los participantes está comprometido, tiene que redistribuir un nuevo conjunto de claves.

Además, la única vez que necesita un canal seguro externo con una PKI es cuando configura inicialmente su cadena de confianza. Después de eso, ya no tendrá que usar un canal seguro a menos que su raíz esté comprometida.

    
respondido por el Stephane 19.07.2017 - 16:39
fuente

Lea otras preguntas en las etiquetas