La autoridad de certificación india eMudhra Limited afirma que dejará el negocio global de certificados SSL/TLS. La decisión llega después de que se descubrieran ocho certificados TLS intermedios cuyas claves privadas eran tan débiles que podían recuperarse casi al instante. Quien recuperara una de esas claves podía emitir certificados TLS para cualquier sitio web o servidor de correo. Una de las claves tenía un valor de apenas 4.
La empresa anunció la decisión en una publicación del jueves, dos días después de que los investigadores revelaran el problema, según el informe de Ars Technica. El presidente, V. Srinivasan, citó el aumento de los costes y de los requisitos de cumplimiento normativo. También afirmó que el SSL/TLS representa solo alrededor del 1 % de los ingresos de la compañía y que los proveedores de certificados TLS gratuitos habían reducido la rentabilidad del negocio en comparación con otros productos y servicios de eMudhra. En la publicación, la empresa señaló que la atención en redes sociales había puesto el foco sobre el incidente de forma desproporcionada respecto al papel que desempeña el TLS en sus operaciones, y que su consejo de administración había concluido que retirarse era lo más conveniente para la empresa y sus accionistas.
Tamaños de clave muy por debajo de la fortaleza esperada
Los investigadores comprobaron que los ocho certificados se emitieron con claves privadas de entre 3 y 8 bits. Las claves debían ser de curva elíptica NIST P-384, que deberían tener unos 384 bits de entropía. Los valores de las claves defectuosas eran 4, 56, 66, 115, 155, 156, 230 y 237. La más fuerte de ellas permitía como máximo 256 posibilidades, frente a las unas 2^384 que debería ofrecer una clave correcta, un número de 116 dígitos.
Según el relato de los investigadores, la vulnerabilidad era fácil de explotar. Recuperar una clave tardaba solo milisegundos. Una vez obtenida la clave, un atacante podía usarla para crear certificados en los que confiarían los principales navegadores, y esos certificados podían a su vez ser aceptados por un número grande y desconocido de servidores de correo, dispositivos IoT, contenedores Docker, equipos Linux antiguos y herramientas de línea de comandos sin mantenimiento, que incorporan sus propias copias de los certificados raíz.
Los fabricantes de navegadores bloquearon los certificados emitidos bajo las autoridades intermedias afectadas en el plazo de uno o dos días tras el descubrimiento. Ars Technica señaló que otros dispositivos que dependen de los mismos certificados podrían necesitar mucho más tiempo para dar el mismo paso, y que algunos dispositivos embebidos quizá nunca puedan bloquearlos. Ars también indicó que eMudhra probablemente se enfrentaba a la posibilidad de que el CA/Browser Forum, el grupo industrial que establece las normas del programa de certificados TLS, le retirara su autoridad. Esta última idea es una valoración de Ars y no una decisión anunciada.
La explicación de eMudhra
El miércoles, eMudhra publicó una breve explicación. Indicó que los certificados se crearon bajo su raíz ECC durante una ceremonia de generación de claves (KGC) celebrada el 30 de abril de 2025, utilizando módulos de seguridad de hardware (HSM) con certificación FIPS 140-2 nivel 3. Según la compañía, un fallo en la KGC hizo que un paso de wrap/unwrap produjera un segundo conjunto de claves débiles junto a las claves originales robustas, y que fueron precisamente las claves débiles las que se publicaron en los almacenes de certificados raíz de los navegadores. eMudhra afirmó que seguía trabajando para establecer la causa raíz.
Los HSM son dispositivos dedicados al almacenamiento de claves de cifrado y otros datos sensibles, y normalmente están aislados de la mayor parte de la red. El wrap/unwrap es el proceso que se usa para trasladar una clave entre HSM: el dispositivo emisor la cifra con una clave de envoltorio independiente, y el dispositivo receptor la descifra al recibirla.
En un hilo de Mozilla Bugzilla, eMudhra ofreció más detalles. Explicó que el script de KGC utilizado ese día contenía un fallo. Las claves ECC originales se generaron en el dispositivo como se esperaba. Después se introdujo un cambio aprobado respecto al procedimiento habitual, destinado a probar un wrap/unwrap para claves previstas para exportación. Un error de código hizo entonces que se generara en el dispositivo un segundo par de claves, más débil. Como las etiquetas de las claves eran parecidas, el par más débil se usó por error para crear la solicitud de firma de certificado (CSR), que la raíz firmó después. eMudhra dijo que la CSR elaborada con las claves débiles también se envió a Sectigo para una firma cruzada y que la empresa había revisado los archivos que envió.
eMudhra también indicó que sus listas de revocación de certificados (CRL) se firmaron primero con las claves privadas originales, generadas correctamente. Esas firmas salieron incorrectas, así que las CRL se volvieron a firmar con las claves defectuosas. Ars Technica preguntó por qué la empresa no investigó antes la causa de ese fallo de firma. La compañía respondió que errores humanos en varias fases habían provocado debilidades importantes en el proceso de integridad del ciclo de vida de las claves en esa ceremonia. Afirmó que estaba examinando fallos de código, lagunas de procesos y controles maker/checker, y que en la semana siguiente volvería a verificar todas las ceremonias de generación de claves que había realizado.
