¿Qué exige este criterio?
El serialNumber del TSTInfo debe ser único (sin reutilización) e impredecible (no secuencial puro). La unicidad se garantiza con una base de datos de series emitidas o con un contador persistente. La impredecibilidad se consigue añadiendo bits aleatorios o usando un UUID como base. El serialNumber se incluye en el comprobante de integridad del token; si se reutilizara, dos tokens distintos tendrían el mismo identificador.

¿Qué hay que revisar al cliente?

• Mecanismo de generación del serialNumber (contador, UUID, CSPRNG).
• Garantía de unicidad: ¿se verifica contra base de datos?
• Impredecibilidad: ¿no es secuencial puro ni derivable del timestamp?
• Recuperabilidad: ¿qué pasa si el contador se pierde tras un fallo del sistema?

Preguntas clave para las entrevistas

• ¿Cómo se generan los serialNumbers de los tokens? ¿Contador, UUID, CSPRNG?
• ¿Se verifica que no se reutiliza ningún serialNumber?
• ¿El serialNumber es predecible a partir del timestamp o de otra información pública?
• ¿Qué pasa con la unicidad si el TSA falla y se reinicia?

¿Por qué es esencial para QERDS y TSA?
La reutilización de un serialNumber podría permitir confundir dos tokens distintos, lo que podría usarse para falsificar evidencias. La impredecibilidad evita ataques de precomputación. El CAB puede verificar la unicidad pidiendo múltiples tokens y comparando sus series.

Evidencia que demostraría conformidad

• Especificación del generador de serialNumber.
• Evidencia de unicidad (base de datos o secuencia persistente).
• Verificación de impredecibilidad (no secuencial puro).