¿Debo personalizar la huella digital / huella digital de mi Root CA? (SHA1 o MD5)

Forzar a los "bits de vanidad" a asumir que un valor específico no disminuye la seguridad (la segunda resistencia de preimagen es la segunda resistencia de preimagen) pero es costosa. Es decir, para obtener n "bits de vanidad" en un valor específico, debe probar (en promedio) 2ⁿ hasta que haya una coincidencia encontró. Cada intento implica realizar una pequeña variación en el contenido del certificado (por ejemplo, en la extensión Subject Key Identifier , que contiene bytes opacos), luego firmar el certificado y luego modificarlo. La parte de la firma no se puede evitar (pero ver más abajo), porque la huella digital también se calcula sobre ella.

Esta operación de firma será, con mucho, la parte más cara. Puede esperar, de manera realista, dos mil intentos por segundo o más (con algunas PC, dependiendo del tipo y tamaño de la clave). Esto significa que tomará una quincena de cómputo para obtener 30 "bits de vanidad", y cada bit adicional duplica el costo. No obtendrás ocho bytes ; a lo sumo cuatro. Por lo tanto, los beneficios son leves: un hash SHA-1 es de 20 bytes, lo que equivale a un máximo del 20% del esfuerzo guardado.

Además, incluso si se establece en un valor específico, estos bits aún deben comprobarse.

El proceso puede mejorarse sustancialmente al hacer que el certificado no tenga su propia firma. Dado que un certificado "autoemitido" es confiable a priori (es decir, por magia, no por un über-CA), no hay ningún punto real en la verificación de la autofirma. Para que la firma no tenga que ser realmente correcta; solo necesita, para fines de decodificación, ser una secuencia de bytes de aproximadamente el tamaño correcto.

Por lo tanto, puede crear sus "certificados de prueba" simplemente modificando los últimos bytes de la firma. Dado que el campo de firma es el último, este proceso puede llegar a ser tan rápido como una invocación de hash elemental por intento. Incorpore una GPU y algo de programación, y puede probar miles de millones por segundo.

Un billón se ve muy bien desde lejos, pero eso es realmente solo 30 bits. Con un buen grupo de GPU y algo de paciencia, puede esperar, por ejemplo, 52 bits de vanidad o algo así. Esto se traduce en 13 caracteres hexadecimales de los 40 de un hash SHA-1. En mi opinión, esto no vale la pena, pero bueno, esa es su CPU.

En la parte técnica, si quieres hacer eso, sugiero que implementes tu propio SHA-1-on-GPU. Deberá dominar la programación de GPU de todos modos, incluso si intenta reutilizar una implementación existente; y la parte SHA-1 en sí no es difícil.

Esto es comparable a la opción VisualHostKey de ssh para mostrar representaciones gráficas de las huellas digitales del certificado .

  

¿Esto aumentaría la seguridad para los certificados raíz que no son de confianza y que necesitan verificación manual?

Existe el riesgo de crear una falsa sensación de seguridad. Si su navegador / ssh client / etc aparece diciendo "¡Peligro de peligro, certificado no confiable!" pero luego su única confirmación es verificar los primeros bytes, en lugar de toda la huella digital, está facilitando mucho el trabajo de su atacante. Todo lo que tienen que hacer es generar un certificado autofirmado que comienza con esos bits.

Por otra parte, si el atacante no nota tu esquema, puedes ver fácilmente que no es tu certificado.

Para un cliente que muestra la huella digital, esto es muy similar a la situación con VisualHostKeys, pero es más fácil para un atacante generar un certificado falso compatible.

Entonces: contra un atacante que note que esto te va a lastimar más que ellos; contra un atacante que no se da cuenta, es útil para ti.

  

¿Qué pasa con [los certificados que se encadenan de nuevo a una raíz de confianza]?

Si su cliente se conecta sin la intervención del usuario cuando se valida el certificado (por ejemplo, un navegador web), diría que no es útil. La única forma de saber si estaba siendo MITMed sería si fuera a consultar la información del certificado después de conectarse. En este punto, el atacante ya tiene su cookie de sesión segura, pero es probable que no realice esta comprobación.

Además, es muy probable que un atacante que haya hecho todo lo posible para obtener un certificado con firma válida para su dirección haya examinado el certificado original en detalle, haya observado el esquema y lo haya copiado.