¿Cuál es la estrategia de mitigación cuando se roba la clave privada de un CA?

Una clave privada CA robada es una mala situación. La respuesta depende del alcance de la violación y del contexto.

Primero, puede ser que la clave privada de CA no sea exactamente robada , sino que simplemente se use de forma incorrecta. Por ejemplo, en el caso del evento Comodo , el compromiso fue en cuentas de la Autoridad de Registro . El RA es el componente que le dice a la CA qué colocar en los certificados; La RA es la parte que realmente asigna identidades físicas al mundo físico. En ese caso, la clave de CA no fue robada y, aunque se emitieron certificados con contenido incorrecto, la CA aún tenía un conocimiento confiable de todos los certificados emitidos. Por lo tanto, bastaba con revocar los certificados falsos, no la CA. Este es el buen caso, donde el daño está contenido.

Si se usó la clave de CA y no hay una forma confiable de tener una lista exhaustiva de los certificados falsos, o si la clave privada de CA se robó y ahora está bajo el control del atacante, entonces el certificado correspondiente deberá ser revocado Esto no lo hace la propia CA, sino su CA superior.

Luego, para reparar todos los sitios honestos que simplemente "desaparecieron" a través de dicha revocación, se puede instalar una nueva CA y automáticamente emitir nuevos certificados para todos los clientes anteriores (esto supone que todavía tenemos todos los "honestos" emitidos certificados en algún lugar). Basta con copiar las identidades y los nombres del certificado anterior al nuevo.

Por motivos comerciales, se puede negociar para retrasar la revocación de la CA comprometida hasta que se hayan creado e implementado la nueva CA y los nuevos certificados de cliente. Sin embargo, no hay mucho margen para eso.

Un plan de acción para esto es tener un monitoreo y auditoría regular en todas las solicitudes.

Un poco sobre cómo funcionan las CA de SSL (fuente: Fox-IT Post Breach of DigiNotar)

  

Los navegadores actuales realizan una comprobación de OCSP tan pronto como el navegador se conecta   a un sitio web protegido por SSL a través del protocolo https3. El serial   Número del certificado presentado por el sitio web que un usuario visita es   Enviar al CA OCSP-respondedor emisor. El respondedor OCSP solo puede   responda ya sea con "bueno", "revocado" o "desconocido". Si un certificado   el número de serie se presenta al OCSP-respondedor y no hay registro de este   se encuentra una serie, la respuesta normal de OCSP-respondedor sería "buena" 4.   La respuesta de OCSP-respondedor "revocada" solo se devuelve cuando el número de serie   es revocado por la CA.

TL; DR: si no se encuentra un número de serie = > Bien, si se revoca la serie = > Revocado

Con el monitoreo adecuado implementado, esto podría haberse identificado en un intervalo mucho más rápido y un plan de respuesta a incidentes podría haberse implementado para mostrar un certificado como revocado cuando no se encontró dentro del CASP-respondedor.

Y aquí está lo que incluye el plan de IR (fuente: nuevamente de la Infracción de publicación)

  

Con el fin de evitar el uso indebido de las publicaciones seriadas desconocidas, el   OCSP-respondedor de DigiNotar se ha configurado para responder "revocado" cuando   Presentó cualquier certificado desconocido en serie sobre el que tiene autoridad. Esta   Se realizó el 1 de septiembre. El sensor de respuesta a incidentes inmediatamente.   informa si un número de serie de un certificado emitido fraudulentamente conocido   está siendo mal utilizado. Además, todas las solicitudes de números de serie desconocidos pueden ser   Analizado y utilizado en la investigación. Todo gran número de peticiones.   a un solo número de serie es sospechoso y será detectado.

Más o menos, esto dice que implementaron un monitoreo y una auditoría que deberían haber estado en su lugar desde el principio, y que habría sido identificable a través de una solución SIEM en cuanto a lo que ocurrió o lo que estaba ocurriendo.

Si quieres leerlo todo: enlace