¿La revocación del certificado de D-Link realmente solo invalidó 1 día (de una exposición de seis meses)?

Navega tus respuestas
11

Estoy tratando de envolver mi cabeza alrededor de OCSP revocationTime para el certificado de D-Link.

I contesté recientemente otra pregunta y terminó redactando una línea de tiempo.

Esa línea de tiempo es básicamente esto: 

Jul  5 00:00:00 2012 GMT. Validity: Not Before
Feb 27          2015      Inadvertent disclosure
--- six months of nothing ---
Sep  3 00:00:00 2015 GMT. OCSP "revocationTime" backdated to this.
--- one day of invalidity (?) ---
Sep  3 23:59:59 2015 GMT. Validity: Not After 
Sep 17          2015      Tweakers.net report 
Sep 18          2015      TheRegister.co.uk report
Sep 20 14:00    2015      Is-it-revoked-yet?-question posted.
Sep 20          2015      Answer posted. OCSP 'good'
Sep 22          2015      Update answer posted. OCSP 'revoked'

Y la pregunta es esta:

  • ¿El movimiento de D-Link invalida retroactivamente solo 1 día de posible uso / mal uso de su clave?

O preguntado de manera diferente:

  • ¿Funcionará un EXE (hipotético) firmado el 2 de septiembre con la clave AUSENTE robada a pesar de la revocación?

Y como una pregunta de lado / fondo:

  • ¿Cuál es la idea general con revocationTime de OCSP? ¿Debes suponer una fecha retroactiva para el primer momento en el que crees que la clave se vio comprometida? (Traté de hacer mi investigación. Pero estoy atascado. No pude encontrar la explicación en el OCSP RFC . Y un publicación de 2012 en la lista de correo PKIX de Martin Rex , no aclarar exactamente las cosas para mí tampoco.)
pregunta StackzOfZtuff 02.10.2015 - 16:02
fuente

1 respuesta

5

OCSP proporciona un mecanismo dinámico para verificar si un certificado dado se ha comprometido o no y, en caso de que se haya comprometido, después de la fecha (y la hora) en que las firmas que usan este certificado se consideran inseguras (básicamente, es una versión dinámica). de CRLs).

Esto tiene varias consecuencias:

  • Las respuestas de OCSP DEBEN estar actualizadas en caso de que indiquen un estado "revocado". El motivo es simple: generalmente se descubre que una clave está comprometida mucho después de que se haya perdido el control real de esa clave. Por lo tanto, es lógico proporcionar una manera de informar a los usuarios de ese certificado si la firma antigua también debe considerarse inválida (sin revocar TODAS las firmas).
  • Una vez que un certificado ha sido revocado, NO PUEDE considerarse válido nuevamente.

Todo esto se hace más complejo por el hecho de que las respuestas de OCSP pueden ser 1) en caché y 2) preproducidas. Esto significa que, durante un período de tiempo después de que se haya emitido un estado de revocación de certificado, es posible que diferentes clientes de OCSP reciban respuestas diferentes. Esta situación puede durar hasta que se alcance la fecha indicada por el campo nextUpdate de la última respuesta "certificado válido".

Entonces:

  

¿El movimiento de D-Link invalida retroactivamente solo 1 día de posible uso / mal uso de su clave?

No. Ellos invalidaron retroactivamente el certificado a partir de las 00: 00: 000 de ese día.

  

¿Funcionará un EXE (hipotético) firmado el 2 de septiembre con la clave robada TODAVÍA, a pesar de la revocación?

Sí, porque se firmó antes del tiempo de revocación del certificado.

  

¿Se supone que debes dar una fecha anterior al primer momento en el que crees que se comprometió la clave?

Sí y no: se supone que debes hacer una fecha anterior a la fecha en que se supo por última vez que la clave es segura .

    
respondido por el Stephane 05.10.2015 - 16:11
fuente

Lea otras preguntas en las etiquetas

Administrador de red que conoce todas las contraseñas de los usuarios Base de datos de SQL Server en línea para una aplicación de negocios. Consideraciones de Seguridad