¿Cómo protegen los sistemas contra un certificado de firma de código robado después de que el certificado expira?

Esta es la razón por la que Microsoft recomienda nunca eliminar certificados de firma de código caducados de CRL. Un escenario alternativo: el atacante firma su malware antes del vencimiento del certificado. Si pueden permanecer sin ser descubiertos después del vencimiento del certificado, entonces el certificado no se agregará a la CRL ni siquiera en el momento del descubrimiento, y su malware nunca se bloqueará. Por lo tanto, el estado de revocación de los certificados de firma de código debe seguirse para siempre .

De Mejores prácticas de firma de código de Microsoft documento:

  

En la mayoría de las implementaciones de PKI, solo los certificados que aún no han caducado se colocan en la CRL. Esto significa que cuando un certificado revocado expira, finalmente se elimina de la CRL. Sin embargo, la marca de tiempo permite que las firmas de Authenticode sigan siendo válidas indefinidamente. Como resultado, los certificados de firma de código revocados no deben eliminarse de la CRL. Este documento recomienda siempre revocar los certificados comprometidos que se usaron para firmar el software publicado públicamente y mantener estas entradas en la CRL por tiempo indefinido.

     

Microsoft Certificate Server permite a los administradores configurar la CA para mantener todos los certificados revocados en la CRL. Sin embargo, la CA no distingue entre los certificados de firma de código y otros certificados. Por esta razón, los administradores deben dedicar una CA con el único propósito de manejar los certificados de producción de firma de código.

Entonces, para responder a su pregunta, sí, el malware puede ejecutarse de nuevo si la CRL para los certificados de firma de código no se administra correctamente.

Tratar con firmas digitales es más complejo de lo que podemos suponer a primera vista.

Su escenario es correcto: si no tiene un comprobante de la fecha / hora de la firma, no puede estar seguro de que no se haya realizado después de la revocación y vencimiento del certificado. También puede observar que, incluso si el certificado no ha sido revocado, una firma realizada después de la expiración del certificado no debe considerarse válida.

Primera solución

Agregar una marca de tiempo a la firma del software. Este sello de tiempo se denomina sello de tiempo de firma . Este sello de tiempo proporciona una prueba de que la firma existía en una fecha determinada. Se demuestra que la firma se ha calculado antes de la expiración del certificado. Pero no resuelve el segundo problema: ¿qué sucede si se revocó el certificado?

Segunda solución

Junto con el sello de tiempo de la firma también puede adjuntar una copia de la CRL (o una respuesta de OCSP) a la firma. Probará que el certificado no fue revocado cuando se produjo la firma.

Pero los tokens de sello de tiempo y las CRL también son objetos firmados. También necesitan ser validados. Entonces, ¿también deberíamos obtener la CRL que demuestre que el sello de tiempo de la firma ha sido firmado por un certificado válido? Respuesta corta: sí, las cosas parecen complicarse más.

Tercera solución

Algunos estándares de firma (como CAdES ) han propuesto una mejor solución: junto con el sello de tiempo de la firma , debe recopilar todos los elementos necesarios para validar la firma off-line (es decir, poder validar el certificado sin tener que descargar ningún objeto adicional). Incluye todos los certificados intermedios de CA y CRL. Este no es un proceso sin fin, ya que eventualmente llegará a una o varias CA de confianza, pero puede ser bastante complejo (tenga en cuenta que un buen algoritmo de validación X.509 debería generar todos estos elementos junto con el estado de validez del certificado). Y después de haber recuperado todos estos objetos, debes ponerle una marca de tiempo. Este sello de tiempo se llama archivar sello de tiempo

Ahora el proceso de validación de la firma es el siguiente:

1. Valida la marca de tiempo global en línea . Significa que descarga todo el elemento necesario para garantizar que la firma de sello de tiempo sea válida. Ahora tiene una prueba de que todo el objeto adjunto (CRL ...) existía en la fecha de la marca de tiempo del archivo.
2. Valida la firma fuera de línea solo con los elementos cubiertos por la marca de tiempo del archivo como si la fecha actual fuera la fecha de la marca de tiempo del archivo .

Con esta solución, el escenario que presentaba no es posible ya que el verificador de firmas tiene una prueba de la caducidad y el estado de validez del certificado en la fecha de la firma.

Esta solución se está implementando actualmente para la validación de la firma de documentos a largo plazo, pero desafortunadamente, por lo que yo sé, no para la validación de la firma de código. En la actualidad, los proveedores utilizan otros mecanismos, como listas negras de certificados robados, que son más fáciles de implementar.

ACTUALIZACIÓN, 25 de septiembre de 2014 (después de leer el comentario de @maureen)

Primero, su comprensión del proceso es correcta: dado que cada certificado se elimina de la CRL después de la fecha de vencimiento, no puede evaluar si un certificado ha sido revocado o no en el pasado. Por lo tanto, no es posible validar una firma después de la expiración de un certificado.

Pero incluso si un certificado ha sido comprometido (o simplemente se ha revocado porque, por ejemplo, el cliente perdió su token de cifrado USB), todas las firmas creadas anteriormente deben considerarse válidas. El proceso que describí en mi respuesta trata de explicar cómo es posible responder today (es decir, incluso después de la expiración del certificado) esa pregunta: "¿Fue válida la firma si se creó?". p>