Planteamiento y contexto
El entrevistador pregunta: “El sistema depende de NTP y un atacante puede falsificar respuestas de tiempo. ¿Cómo asegurarías la sincronización? Tras implementar NTS, ¿podemos asumir que el reloj local es absolutamente correcto?”. Responde para roles de backend, plataforma, redes, seguridad o SRE, y cubre registros dependientes del tiempo, validez de certificados y expiración de tokens.
El NIST explica que el NTP ordinario suele no estar cifrado, por lo que las respuestas falsificadas pueden suministrar una hora falsa al cliente; el RFC 8915 define NTS como un mecanismo de seguridad en el estándar para el modo cliente-servidor de NTP. Las preguntas de evaluación pública de redes también evalúan la jerarquía de NTP, la selección de fuentes y el impacto en la seguridad.
Qué evalúa el entrevistador
- ¿Puedes separar la identidad de la fuente, la integridad del mensaje, la protección contra reproducción y que “la hora sea realmente precisa”?
- ¿Puedes explicar por qué NTS-KE está separado de los campos de extensión de NTP y cómo las cookies permiten que el servidor de tiempo se mantenga sin estado por cliente?
- ¿Puedes identificar ataques de retardo, eliminación de NTS (NTS stripping), compromiso de claves, fuentes únicas y la desviación del oscilador local?
- Una respuesta sólida ofrece selección de múltiples fuentes, monitoreo de desfasaje (offset)/latencia, reglas de rechazo y degradación segura. Una respuesta débil dice “poner NTP dentro de TLS”.
Preguntas de aclaración antes de responder
¿Qué modo de NTP debe protegerse?
El RFC 8915 especifica el modo cliente-servidor. Los modos simétrico, de difusión (broadcast) y de control tienen requisitos diferentes, por lo que el flujo NTS cliente-servidor no puede aplicarse a ciegas a todos los modos.
¿Qué garantía de tiempo necesita el sistema?
El ordenamiento de registros puede requerir un tiempo aproximado comparable; las firmas, certificados y concesiones (leases) pueden necesitar un límite de desfasaje más estricto. Define el desfasaje máximo, el tiempo de detección y el comportamiento cuando el tiempo de confianza no esté disponible.
¿Debe el fallo cerrar el acceso (fail-closed) o continuar operando?
Un captcha o la actualización de caché pueden usar brevemente un reloj monotónico y el último valor de confianza. La emisión de un token de seguridad, la validación de una firma o la realización de una acción irreversible deben rechazarse o requerir intervención humana. No asignes a todos los flujos de trabajo la misma política vaga de “tiempo no disponible”.
Una respuesta de 30 segundos
“Comenzaría con el límite de desfasaje requerido y la política ante fallos. NTS no es un TLS ordinario envolviendo a NTP: NTS-KE utiliza TLS para autenticar al servidor y establecer claves, luego los paquetes NTP utilizan AEAD y campos de extensión para la autenticación y la detección de reproducción. El cliente transporta cookies, por lo que el servidor de tiempo no mantiene una sesión para cada cliente. Configuraría fuentes de tiempo independientes, monitorearía el desfasaje, el retardo, los cambios de fuente y los fallos de NTS-KE, y rechazaría decisiones de tiempo de alto riesgo cuando falle la autenticación o las fuentes discrepen. Los flujos de bajo riesgo pueden usar un reloj monotónico acotado o el último valor de confianza. NTS demuestra que los paquetes provinieron de una fuente autenticada y no fueron modificados; no demuestra que la fuente esté en buen estado, ni elimina el retardo de la red, ni corrige la desviación del reloj local”.
Solución paso a paso
- Separar los objetivos de seguridad. La identidad y la autenticación responden quién envió el paquete y si cambió; la protección contra reproducción responde si se está reutilizando un paquete antiguo; la precisión evalúa qué tan lejos está la fuente del reloj local. NTS cubre principalmente los dos primeros y protege los campos de transferencia de NTP.
- Ejecutar NTS-KE. El cliente se conecta a un servicio NTS-KE mediante TLS, valida el certificado y negocia los parámetros. El servidor suministra cookies y la dirección del servidor NTP posterior. La sesión TLS puede cerrarse sin retener el estado del cliente.
- Proteger el intercambio NTP. El cliente incluye una cookie y una etiqueta de autenticación en los campos de extensión de NTP. El servidor recupera el material de claves a partir de la cookie y devuelve una respuesta autenticada. El cliente comprueba la coherencia de la solicitud-respuesta, el estado de reproducción y la muestra de tiempo.
- Mantener fuentes independientes. Utiliza fuentes de tiempo con diferentes rutas u operadores, y compara el desfasaje, el retardo de ida y vuelta (round-trip delay), el jitter y la accesibilidad. Una fuente comprometida o con desviación debe ser visible mediante discrepancias y verificaciones de estado.
- Definir el comportamiento de rechazo y degradación. Ante un fallo de autenticación, eliminación de NTS, retardo anormal, discrepancia de fuentes o desfasaje local excesivo, pausa la emisión de tokens y los cambios en las políticas de seguridad. Un flujo de trabajo puede medir la duración con un reloj monotónico, pero no debe tratarlo como una nueva marca de tiempo de reloj de pared.
- Ensayar la recuperación. Prueba caídas de NTS-KE, expiración de cookies, rotación de certificados, revocación de claves, cambio de fuentes, segundos intercalares y un salto grande del reloj local. Registra los motivos de rechazo y el tiempo de recuperación, y evita que un atacante convierta la autenticación bloqueada en reintentos infinitos.
Respuesta modelo
Separaría el origen de confianza de la hora precisa. NTS-KE autentica el servicio de tiempo sobre TLS y establece claves; los paquetes NTP posteriores transportan una cookie y una etiqueta de autenticación AEAD. El cliente puede detectar respuestas falsificadas, modificadas, reproducidas o discordantes sin requerir que el servidor mantenga una sesión para cada cliente.
Configuraría múltiples fuentes independientes y observaría el desfasaje, el retardo de ida y vuelta, el jitter, los cambios de fuente y los fallos de NTS-KE. Las acciones de alto riesgo, como la emisión de tokens, la verificación de certificados y la autorización basada en tiempo, deben rechazarse cuando falte el tiempo de confianza o las fuentes discrepen. La medición ordinaria de tiempos de espera (timeouts) puede usar un reloj monotónico, pero no debe convertirse en una marca de tiempo de reloj de pared no verificada.
El límite es fundamental: NTS no repara un servicio de tiempo defectuoso, el retardo de red, la desviación del oscilador local ni todos los ataques de denegación de servicio. El compromiso de claves, la degradación de NTS y el uso de una sola fuente requieren alertas, conmutación y ensayos de recuperación. Esta respuesta explica tanto el protocolo como el comportamiento seguro cuando no se puede confiar en el tiempo.
Errores comunes
- Decir “añadir TLS a NTP” → pasa por alto la separación entre NTS-KE y los campos de extensión de NTP → explica el establecimiento de claves de una sola vez, las cookies y la autenticación AEAD.
- Equiparar autenticación con precisión → una fuente autenticada aún puede desviarse o estar mal configurada → compara el desfasaje, el retardo y el estado de múltiples fuentes.
- Implementar una sola fuente de tiempo → esa fuente se convierte en un punto único de fallo del sistema → utiliza rutas y operadores independientes con arbitraje y aislamiento.
- Usar el reloj de pared para tiempos de espera → los saltos de reloj pueden terminar un tiempo de espera antes o después de tiempo → mide la duración con un reloj monotónico y utiliza el tiempo de reloj de pared solo para marcas de tiempo verificadas.
- Reintentar NTS-KE indefinidamente → un atacante puede amplificar los costos de conexión y de criptografía → delimita el retroceso (backoff), cambia de fuente y registra los motivos de rechazo.
Preguntas de seguimiento y respuestas
¿Puede NTS evitar que un atacante en la ruta retrase los paquetes?
No por completo. La autenticación detecta modificaciones y ciertas reproducciones, pero un atacante en la ruta aún puede retrasar o descartar paquetes. Comprueba el retardo de ida y vuelta, el desfasaje y la frescura de la muestra, y rechaza decisiones de alto riesgo más allá de un umbral.
¿Qué ocurre si el servicio NTS-KE no está disponible?
Un cliente con cookies válidas puede continuar el intercambio de tiempo durante una ventana acotada, mientras monitorea la vida útil de las cookies y las claves. Los clientes nuevos cambian a una fuente NTS-KE de respaldo; una vez que expire la ventana de confianza, detén las operaciones de seguridad que dependan del tiempo de reloj de pared.
¿Por qué no usar GPS o PTP directamente para todos los servicios?
GPS, PTP y NTP difieren en precisión, costo de despliegue, límite de red y modo de fallo. Elige según el límite de desfasaje requerido. Un enlace de alta precisión aún necesita fuentes independientes, monitoreo y autenticación; la precisión por sí sola no elimina los cuestionamientos sobre la confianza.
¿Qué sucede si la clave o el servidor de tiempo se ven comprometidos?
Revoca o rota las claves de cifrado de cookies, aísla las fuentes afectadas, cambia a fuentes independientes y audita la ventana de tiempo afectada. Preserva el ID de origen, el desfasaje y el resultado de verificación para firmas, tokens y registros, de modo que las decisiones puedan recalcularse.