Resumen

  • RFC 9684 define RPC YANG para solicitar quotes TPM 1.2 y 2.0 con nonce fresco y recuperar logs de BIOS, IMA o arranque de equipos de red.
  • Una quote auténtica y un replay coherente describen las mediciones escogidas; no garantizan que el TPM, los PCR, la política de medición ni las Reference Values sean los adecuados.
  • Evidence, appraisal, Attestation Result, decisión del Relying Party, ejecución y efecto de red necesitan comprobantes propios.

La actualización terminó a las 02:00. A las 02:03, el TPM produjo una quote nueva y correctamente firmada. El Verifier la comparó con valores de referencia también correctamente firmados y marcó el equipo como no conforme. La criptografía no había fallado: el catálogo de referencia seguía describiendo la imagen retirada tres minutos antes.

Ese caso muestra por qué la atestación no es una propiedad almacenada dentro de una firma. Es una evaluación situada entre una medida, una referencia, una política y una decisión. RFC 9684 hace interoperable el transporte de la primera. No fusiona las demás.

El reto conserva la pregunta original

El módulo ietf-tpm-remote-attestation obliga al cliente YANG a aportar un nonce fresco con entropía adecuada. La respuesta del Attester queda ligada al reto, de modo que una quote antigua no pueda presentarse como si respondiera a la nueva solicitud.

La frescura tiene un sujeto preciso: la Evidence de esa interacción. No significa que el dispositivo permanecerá igual. Tampoco amplía la selección de PCR, añade ficheros que la política IMA no midió ni explica qué TPM corresponde a cada tarjeta de un equipo compuesto.

RFC 9684 reconoce que la relación entre un TPM individual y el componente medido está fuera de alcance. Cuando existe mtpm, omitir certificate-name puede hacer que respondan todos los TPM compatibles; indicar uno reduce el conjunto, pero solo una cartografía externa fiable demuestra que era el que debía representar el plano de control o la unidad de reenvío observada.

Por eso el recibo del reto debe retener nonce, dispositivo, RPC, versión TPM, certificado, banco hash, índices PCR, tipo de log y versión de configuración. Guardar solo “pass” elimina el alcance y hace imposible reconstruir qué pregunta contestó el hardware.

Verificar la firma no basta para autorizar la clave

En TPM 2.0, la respuesta puede incluir TPMS_QUOTE_INFO, firma, nombre de certificado, tiempo activo y valores PCR sin firma auxiliares. La firma protege la estructura; los valores permiten analizarla; el certificado intenta vincular la clave con el TPM y el rol esperados.

El receptor debe comprobar que el certificado TPM 1.2 corresponde a una AIK activa o que la clave TPM 2.0 es una AK activa, con prueba de control de la clave privada por una entidad legítima para atestar el TPM objetivo. Una firma matemáticamente correcta de otra clave no resuelve esa identidad.

Las estructuras de apoyo también pueden configurarse mal. Un certificado puede no corresponder a la AK. Un tipo de clave puede representarse de manera incorrecta. La lista de algoritmos puede anunciar capacidades que el TPM físico no tiene. Se pueden seleccionar PCR que el software nunca extiende. El RPC seguirá siendo un RPC válido y el canal seguirá cifrado.

NETCONF y RESTCONF protegen el intercambio de gestión según sus perfiles. Esa protección no decide qué clave tenía autoridad, qué componente medía o qué baseline debía aplicarse. Confundir transporte y appraisal convierte la seguridad del conducto en una conclusión sobre el contenido.

El PCR es un compromiso con lo medido, no con todo lo ejecutado

Los PCR acumulan extensiones mediante hashes. El log de medición aporta la secuencia que permite al Verifier repetir el cálculo y comparar el resultado con la quote. Después puede cotejar cada medida con Reference Values e identificar entradas divergentes.

La consistencia no equivale a cobertura. La política IMA elige qué ficheros se miden y las plantillas determinan qué campos guarda cada registro. RFC 9684 señala que, sin política IMA, no se toman medidas y IMA queda efectivamente desactivado. Un log corto puede ser coherente porque el sistema decidió no mirar.

Los logs BIOS/UEFI, IMA y de arranque de equipos de red cubren superficies diferentes. La ejecución paralela puede alterar el orden esperado. Un parche autorizado cambia hashes y obliga a actualizar el Reference Integrity Manifest. Un valor distinto puede revelar manipulación, una transición legítima o un baseline equivocado; la quote por sí sola no atribuye la causa.

La evidencia operacional debe conservar la versión de la política de medición, cobertura declarada, log íntegro, replay, identificador y vigencia de las Reference Values, excepciones y política de appraisal. Solo así un equipo puede revisar la conclusión sin depender del color que eligió una consola.

El resultado de atestación todavía no es una acción

RFC 9334 separa al Attester que produce Evidence, al Verifier que la aprecia y al Relying Party que usa el Attestation Result para una transacción concreta. RFC 9683 aplica ese esquema a equipos de red y a los proveedores de Endorsements y Reference Values.

RFC 9684 ocupa sobre todo el trayecto de recogida. No concede al Verifier poder universal. La misma Evidence puede ser suficiente para inventario y no para admitir una sesión de control. Un resultado negativo puede abrir mantenimiento, limitar una función o exigir revisión humana; no contiene automáticamente una orden de aislamiento.

Después hace falta el recibo del punto de ejecución. ¿Cambió el control de acceso? ¿Se retiró una sesión? ¿Se movió tráfico? ¿La redundancia sostuvo el servicio? El TPM no observa esos efectos. Presentar la quote como prueba del resultado confunde el sensor con la institución que decide y con el sistema que actúa.

La interfaz de lectura también requiere límites

Los logs de atestación revelan hashes, versiones y configuración útiles para identificar vulnerabilidades. Pedir grandes volúmenes puede consumir recursos y contribuir a denegación de servicio. RFC 9684 indica que los RPC deben protegerse mediante NACM con denegación predeterminada, permitiendo acceso únicamente a Verifiers autorizados.

Una estrategia madura no pide “todo, siempre”. Define quién puede consultar, qué componentes, con qué frecuencia y volumen, y cómo se protege el archivo de Evidence. La falta de cobertura crea falsa confianza; la extracción excesiva crea exposición y carga. El control debe permanecer visible en ambos extremos.

La doctrina de especificación inicial mínima justifica normalizar el intercambio sin imponer una única política futura. Las capas de realidad impiden que “atestado” sustituya a nonce, scope, clave, baseline y decisión. La primacía del código ejecutado exige finalmente mirar la aplicación real.

CHARRA permite obtener una respuesta comprobable. La afirmación responsable sigue siendo más larga: esta clave protegió estas medidas, seleccionadas bajo esta política, comparadas con estas referencias, para esta decisión y en este instante.

Fuentes