Resumen

  • Un measured component guarda nombre, versión opcional, valor bruto o digest con algoritmo y, de forma opcional, identificadores de quienes pueden firmar o identificar ese componente con autoridad. Esos identificadores no nombran al attester que firma el EAT exterior.
  • El perfil aplicable debe explicar cada posición del array authorities, su orden y los flags locales. Si el consumidor no conoce el perfil y encuentra esos campos, RFC 10013 le ordena rechazar el token.
  • La decisión reproducible une componente y muestra, firma del componente, perfil, firma exterior, frescura, referencias, política y resultado del verificador, y la autorización independiente de la relying party.

La pregunta «¿quién lo firmó?» tiene al menos tres respuestas dentro de una plataforma de atestación.

Alguien pudo firmar el firmware. Un entorno de atestación firmó la evidencia sobre el estado observado. Un verificador puede firmar o proteger el resultado que entrega a quien decide el acceso. Las tres firmas pueden ser correctas y pertenecer a entidades distintas.

RFC 10013 se ocupa de la primera separación. El estándar, publicado en julio de 2026, define el componente medido para EAT y fue escrito por Simon Frost, Thomas Fossati, Hannes Tschofenig y Henk Birkholz. El registro del IETF sitúa a Tschofenig en este RFC y en una larga trayectoria de seguridad; la Universidad de la Bundeswehr de Múnich lo presenta como profesor de Secure Networks desde marzo de 2026. Es atribución verificable, no propiedad individual del protocolo.

Medir no equivale a evaluar

Un componente medido puede ser firmware, un boot loader, software cargado, un archivo, una configuración o un registro de CPU. La estructura de RFC 10013 intenta describir la muestra sin decidir todavía su valor operativo.

El nombre es obligatorio y conviene que sea estable entre versiones. La versión es opcional. La medida adopta dos formas: bytes sin procesar o un digest acompañado por el algoritmo. También pueden aparecer un array de authorities y 64 bits de flags definidos por el perfil.

La precisión del contenedor no convierte la muestra en prueba completa. El digest no dice qué código tomó la medida, si el entorno objetivo pudo mentir, cuándo ocurrió, qué nonce la vincula a esta sesión o contra qué conjunto de referencia se comparará. Un hash coincidente puede ser antiguo, pertenecer a otro objetivo o corresponder a una versión aprobada para una tarea distinta.

RFC 9711 separa formato y fuerza de seguridad. EAT exige autenticidad e integridad, pero no promete que todos los attesters protejan igual sus claves ni recojan claims con la misma resistencia. El receptor necesita conocer la implementación y el trabajo del verificador.

El authority ID responde a una pregunta interior

Para RFC 10013, una autoridad puede identificar un componente de manera autoritativa mediante su firma digital. La comprobación suele realizarse al instalarlo o ejecutarlo. La clave puede identificarse con certificado X.509, clave pública, thumbprint u otro valor único.

La norma añade una frase que debería aparecer en toda consola: esa firma no guarda relación necesaria con la firma del attester sobre la evidencia EAT. El identificador de autoridad no señala por sí solo al firmante del token exterior.

El autor del firmware habla sobre el artefacto que produjo. El operador de flota puede aprobar su despliegue. Un auditor puede añadir un aval. El entorno de atestación habla sobre lo que observó en un dispositivo. Compartir token no mezcla los mandatos.

La arquitectura de actualización de RFC 9019 ofrece un paralelo útil. Autenticar a quien firma una imagen o un manifest no concede automáticamente permiso de instalación. Un sistema crítico puede pedir dos firmas: autor y operador. La criptografía identifica voces; la política define qué puede decidir cada voz.

Por eso una interfaz no debería resumir las claves como «trusted authority». Debe distinguir autoridad de componente, attester de evidencia, verificador de resultado y propietario de la decisión.

El perfil impide que el orden se vuelva superstición

Un array admite varias autoridades. Quizá la primera sea el proveedor, la segunda el dueño de flota y la tercera un auditor. Otra instalación puede usar un orden diferente. Los flags también pueden codificar condiciones locales sin un diccionario universal.

RFC 10013 exige que el perfil declare si usa authorities, qué representa cada entrada y cómo se interpreta. Debe hacer lo mismo con los flags. No basta con reconocer la forma binaria.

Si el perfil es desconocido y estos campos están presentes, el EAT se rechaza. El consumidor no puede ignorarlos como extensiones decorativas, copiar el significado de otro producto ni aceptar porque la firma exterior sea válida.

Ese límite evita una falsa compatibilidad. El mínimo común contiene nombre, medida, codificación y una regla explícita para no adivinar. Los significados que solo existen en una flota se mantienen en su perfil. Así la coordinación no usurpa decisiones locales y la decisión local no se disfraza de estándar universal.

El orden de despliegue pasa a ser parte del control. Si productores emiten perfiles antes de distribuirlos, verificadores conformes rechazan. Si un verificador aplica fallback silencioso, acepta bytes sin poder explicar su semántica. El primer fallo es visible; el segundo crea confianza sin recibo.

Del token a la operación hay dos propietarios más

El attester genera Evidence y la protege. La frescura llega mediante nonce u otro mecanismo. El verificador autentica, asocia la evidencia con el entorno correcto, consulta endorsements o claves, compara claims con valores de referencia y ejecuta una política.

Su salida es un Attestation Result. RFC 9334 reserva a la relying party la decisión sobre el recurso y la operación. Incluso un resultado de conformidad puede ser insuficiente: un portátil sano del fabricante correcto puede no pertenecer a la empresa; un dispositivo aprobado puede pedir datos fuera de su tenant; una versión segura para telemetría puede no estar autorizada para control.

También importa el sentido contrario. Un rechazo por perfil desconocido no acusa al firmware de manipulación. Un digest inesperado no demuestra que la firma exterior sea falsa. Una negación de acceso no contradice necesariamente al verificador. Cada actor responde por una proposición diferente.

La distinción de agencia de Heng Lu encaja aquí con precisión. El firmante del componente no representa al attester; el attester no escribe la política del verificador; el verificador no posee el recurso. Una firma permite atribuir una declaración, no apropiarse de la decisión siguiente.

Identidad estable, privacidad inestable

Mantener el nombre del componente entre releases ayuda a rastrear actualizaciones y explicar un resultado. La misma estabilidad permite correlación. RFC 10013 avisa que nombre y versión revelan software o configuración y que un nombre persistente puede facilitar seguimiento.

Los identificadores de autoridad también pueden repetirse entre sesiones y servicios. El perfil debe definir quién necesita ese detalle. Un verificador especializado puede recibir mediciones y claves; la relying party puede recibir un resultado reducido con operación, alcance y caducidad.

Minimizar no significa borrar el expediente interno. Significa impedir que una prueba necesaria para seguridad se convierta en identificador global de dispositivo sin justificación.

Un recibo con columnas que no se prestan entre sí

Guarde el EAT exacto o su objeto por hash, formato, codificación, perfil y versión. Conserve algoritmo exterior, clave del attester, procedencia de la clave, nonce, tiempo de muestreo, recepción y verificación.

Por componente, registre nombre, versión, objetivo y frontera de muestreo. Distinga raw y digested; guarde algoritmo y valor. Mantenga las autoridades en su orden original, la definición del perfil que asigna roles, la prueba de firma del componente y el resultado. Preserve los ocho bytes de flags además de su lectura.

El bloque del verificador contiene proveedor y versión de referencias, comparaciones, ausencias, política y versión, identidad del verificador y Attestation Result exacto. El bloque final nombra relying party, recurso, operación, política, decisión, restricciones, expiración y reparación.

Así un operador puede diferenciar seis fallos: perfil desconocido, firma de componente no aceptada, firma EAT inválida, evidencia vieja, medida fuera de referencia o dispositivo no autorizado. Una sola etiqueta roja no permite arreglar ninguno sin arriesgar los demás.

Running-Code Primacy no pide creer en el estándar por su número. Pide observar el sistema ejecutado. Para hacerlo, el código debe dejar un rastro de inputs, roles y políticas, no solo un veredicto.

Fuentes