La crisis de identidad en los límites de la IA con capacidad de gestión de agentes

El mercado global de IA con agentes alcanzó los 7.6 millones de dólares en 2025 y se prevé que supere los 196.6 millones de dólares en 2034. Sin embargo, la mayoría de las implementaciones no tienen una identidad de agente basada en hardware.

Las credenciales de software tradicionales, como las claves API, los tokens OAuth, los certificados mTLS y las identidades de servicio, ayudan a autenticar el software o la carga de trabajo. Demuestran que un proceso ha presentado las credenciales correctas. Sin embargo, no demuestran que el hardware subyacente sea de confianza, que el firmware no haya sido modificado ni que el agente se esté ejecutando en la plataforma esperada.

Este es el principal desafío de seguridad para la IA con capacidad de gestión de agentes.

Un certificado indica que una carga de trabajo tiene la clave privada correcta. Sin embargo, por sí solo, no puede determinar si la máquina que aloja dicha carga de trabajo ha sido comprometida. En términos sencillos, la identidad del software es como una insignia. La identidad basada en hardware se asemeja más a la biometría, ya que está integrada en el propio dispositivo.

La identidad basada en hardware proporciona una base de confianza más sólida al vincular la identidad del agente a una raíz de confianza de hardware. En lugar de simplemente preguntar: "¿Es este el software correcto?", las organizaciones pueden preguntar: "¿Es este el software correcto, ejecutándose en el hardware correcto, con el firmware correcto y en un estado verificado?". Esta distinción cobra suma importancia a medida que la IA con agentes se integra en entornos empresariales y regulados.

La base de este modelo de confianza ya existe gracias a estándares como DICE de TCG, SPDM de DMTF y CMS con certificados X.509 . En conjunto, estos estándares pueden ayudar a establecer una cadena de identidad desde el hardware hasta el agente que demuestre dónde se está ejecutando un agente, en qué estado se encuentra la plataforma y si se puede confiar en ella.

Respuesta rápida: ¿Qué es la identidad basada en hardware para la IA agente?

La identidad basada en hardware para la IA agente ancla la identidad de un agente de IA en el silicio en lugar de en credenciales de software. Mediante DICE (derivación de clave a partir de un secreto integrado en el hardware más la medición del firmware), SPDM (protocolo de atestación en tiempo de ejecución) y perfiles de certificados X.509 , un orquestador puede verificar que un agente se ejecuta en hardware genuino y sin modificar antes de enviar cualquier carga de trabajo. Las credenciales de software por sí solas no ofrecen esta garantía.

Puntos Clave

• El mercado global de IA agente alcanzó los 7600 millones de dólares en 2025 y se prevé que supere los 196 600 millones de dólares en 2034; sin embargo, la mayoría de las implementaciones carecen de una identidad de agente basada en hardware. Las credenciales de software (claves API, tokens OAuth, certificados mTLS) demuestran que un proceso tiene las credenciales correctas, pero no pueden demostrar que el hardware subyacente sea de confianza, que el firmware no haya sido modificado o que el agente se esté ejecutando en la plataforma prevista.
• La encuesta DigiCert Trust Pulse (2 de julio de 2025) reveló que el 45 % de las organizaciones experimentaron interrupciones relacionadas con certificados durante el año anterior. Los fallos en los certificados de identidad de hardware son directamente análogos: un acelerador de IA cuya cadena de certificados DICE no supera la verificación de atestación SPDM queda inoperativo, incapaz de recibir ninguna carga de trabajo del orquestador y sin posibilidad de solución a nivel de software. El conjunto de hardware es el conjunto de certificados.
• Ya existen tres estándares interconectados que se implementan en el hardware empresarial actual. DICE (TCG) crea la derivación de claves con raíz de hardware. SPDM (DMTF) es el protocolo de tiempo de ejecución mediante el cual el hardware demuestra su identidad y estado de medición a un orquestador. CMS con perfiles de certificados X.509 es el envoltorio PKI que vincula la identidad del hardware con las acciones firmadas del agente y la infraestructura de clave pública (PKI) empresarial en general. La brecha no radica en la falta de estándares, sino en la falta de una arquitectura PKI operativa que los conecte para la implementación de IA basada en agentes.
• La infraestructura de clave pública (PKI) de hardware difiere estructuralmente de la PKI de servidor en cinco aspectos fundamentales: las claves están físicamente vinculadas al silicio y no se pueden exportar; la validez del certificado está ligada a la vida útil del dispositivo (no después de 99991231235959Z) en lugar de a ventanas de cumplimiento; las jerarquías PKI del fabricante y del propietario nunca deben compartir una raíz; la revocación activa la cuarentena física del dispositivo en lugar del reemplazo del certificado; y la CA emisora ​​puede estar integrada en el firmware del dispositivo y debe estar certificada en el momento de la fabricación. Una plataforma CA estándar sin configuración específica de DICE producirá certificados que no superen la certificación SPDM.
• Las normas NIST FIPS 203, 204 y 205 (finalizadas el 13 de agosto de 2024) exigen la sustitución de los algoritmos RSA y de curva elíptica en el cronograma de desuso de NIST IR 8547. Los algoritmos de clave CA utilizados en las jerarquías de CA del fabricante DICE y del propietario deben incluirse en la hoja de ruta de migración post-cuántica. Para la planificación de la migración de algoritmos de clave CA post-cuántica, realice un seguimiento de los requisitos a través de la Centro de Excelencia PQC.

¿A quién debería importarle la identidad del hardware para la IA agente?

La identidad del hardware para la IA automatizada abarca la fabricación del hardware, las operaciones de PKI, la arquitectura de seguridad, la gobernanza del cumplimiento y la estrategia ejecutiva. Cada equipo es responsable de una parte distinta de la implementación, y las deficiencias en cualquier área dan como resultado una flota de dispositivos que no supera la certificación SPDM, utiliza certificados no conformes o presenta una superficie de ataque de modificación de firmware indetectable.

Rol	POR QUÉ ES IMPORTANTE	Acción
Proveedores de hardware y equipos de firmware	Gestionar la implementación de IDevID en tiempo de fabricación: aprovisionamiento de UDS, derivación de CDI en cada capa de firmware, generación de claves ECA y certificación ECA por parte de la CA del fabricante antes del envío del dispositivo; si el flujo de trabajo de fabricación no se integra con la CA del fabricante, los dispositivos se envían sin una cadena de certificados DICE válida y ningún procedimiento posterior a la implementación puede restaurar un IDevID emitido correctamente por el fabricante; descubrir que la ECA necesita certificación después de que haya comenzado la fabricación implica rediseñar un flujo de trabajo de producción.	Diseñar el proceso de aprovisionamiento de UDS y derivación de CDI según la especificación de la arquitectura de capas DICE de TCG; integrar el flujo de trabajo de fabricación con la API de CA del fabricante para certificar las claves ECA y emitir certificados IDevID para cada dispositivo en tiempo de producción; confirmar que cada dispositivo se envía con una cadena de certificados completa y verificable desde el dispositivo hoja hasta la CA raíz del fabricante; contratar a Encryption Consulting. PKIaaS para el diseño de CA del fabricante, selección y configuración de HSM, validación del formato de la cadena de certificados SPDM e implementación de la API de fabricación.
Equipos de PKI y certificados	Diseño de jerarquía de CA propia y configuración específica de DICE: jerarquía de CA del fabricante para perfiles de certificados de hardware (IDevID, ECA, Attestation), jerarquía de CA del propietario para LDevID y certificados operativos de agente, validación del formato de cadena SPDM GET_CERTIFICATE, manejo de validez 99991231235959Z, registro de OID tcg-dice-kp e infraestructura CRL/OCSP para certificados ECA; las plataformas de CA estándar sin configuración específica de DICE producen certificados que carecen de los OID requeridos, con un uso de clave incorrecto para ECA, restricciones básicas presentes en certificados hoja que no son ECA o períodos de validez rechazados por los verificadores SPDM.	Configure las plantillas de certificados CA del fabricante para los perfiles IDevID, ECA y Attestation con los requisitos correctos a nivel de campo según los perfiles de certificados TCG DICE v1.1 e IEEE 802.1AR-2018; registre los OID tcg-dice-kp en la base de datos de OID de la plataforma CA; configure el manejo de validez 99991231235959Z; confirme que CRLDistributionPoints esté presente en todos los certificados ECA; implemente la administración del ciclo de vida del certificado operativo del agente a nivel de flota utilizando Administrador de CertSecure; clasificar los algoritmos de clave CA según los hitos de desuso post-cuántico del NIST a través de Preparación para PQC servicios
Arquitectos de seguridad e implementadores de IA empresarial	Gestionar el modelo de gobernanza para la identidad del hardware en implementaciones de IA con agentes: definir el límite entre las credenciales IDevID emitidas por el fabricante y las LDevID emitidas por el propietario, diseñar el puente PKI del propietario que conecta la CA del fabricante y la CA del propietario en la misma cadena de confianza DICE sin fusionar las jerarquías, especificar la política de verificación de atestación SPDM que el orquestador aplica antes de distribuir las cargas de trabajo y garantizar que la arquitectura cumpla con los requisitos de IEEE 802.1AR-2018 para el entorno de implementación; en industrias reguladas que implementan hardware de IA, el modelo de gobernanza también debe cumplir con los requisitos reglamentarios aplicables para la garantía de identidad del hardware.	Defina los controles de gobernanza explícitos para cada fase de identidad: autoridad de CA del fabricante sobre IDevID, autoridad de CA del propietario sobre LDevID y certificados operativos del agente, atestación SPDM como puerta de entrada antes de la emisión del certificado operativo; diseñe la arquitectura del puente PKI del propietario; especifique la política de atestación SPDM, incluyendo qué OID tcg-dice-kp se requieren para cada evento de atestación; planifique la ruta de migración post-cuántica para los algoritmos de clave de CA de hardware (ECDSA a ML-DSA según NIST FIPS 204); utilice CBOM seguro Descubrir y clasificar todos los activos criptográficos en la jerarquía de identidad del hardware.
Equipos de cumplimiento	Debe proporcionar evidencia de auditoría de que el hardware de IA implementado en entornos regulados posee una identidad verificable y anclada al fabricante; las industrias reguladas que implementan aceleradores de IA en atención médica (HIPAA), servicios financieros (PCI DSS, SOX), defensa (CMMC) o infraestructura crítica (NERC CIP) pueden requerir evidencia de que la identidad de cada dispositivo está arraigada en el hardware, medida en el firmware y rastreable a un ancla de confianza del fabricante; la encuesta DigiCert Trust Pulse (2 de julio de 2025) encontró que el 45 por ciento de las empresas experimentaron tiempo de inactividad relacionado con certificados, y las fallas en los certificados de identidad de hardware son una fuente directa de ese tiempo de inactividad en las implementaciones de infraestructura de IA.	Confirme que la implementación del certificado DICE produce una cadena de certificados completa y auditable para cada dispositivo implementado bajo demanda; incluya la gobernanza del certificado de identidad de hardware en el paquete trimestral de evidencia de cumplimiento: integridad de la cadena de certificados, tasa de aprobación de la atestación SPDM por dispositivo, correlación de la versión del firmware y cumplimiento del algoritmo de clave de CA; asigne la migración del algoritmo de clave de CA a los hitos de desuso de NIST IR 8547; verifique que la infraestructura CRL y OCSP para certificados ECA cumpla con los requisitos de disponibilidad de la infraestructura de verificación de atestación.
Los CISO implementan infraestructura de IA	El hardware de IA sin una identidad basada en el hardware representa una brecha de seguridad en la cadena de suministro y en tiempo de ejecución a nivel directivo: los ataques a la cadena de suministro que modifican el firmware del acelerador antes de su implementación son un vector de amenaza documentado, y sin una identidad basada en DICE no existe prueba criptográfica de que el hardware implementado sea auténtico y ejecute el firmware esperado. A medida que las cargas de trabajo de IA manejan datos cada vez más sensibles y acciones autónomas, la garantía de identidad del hardware que ejecuta dichas cargas de trabajo se convierte en un requisito de seguridad y cumplimiento a nivel directivo. El mercado de IA agente, valorado en 7.6 millones de dólares en 2025 y que se expandirá a 196.6 millones de dólares en 2034, significa que esto no es una preocupación de nicho, sino un desafío de seguridad empresarial generalizado que está alcanzando una gran escala.	Exigir la identidad basada en hardware como requisito de adquisición para aceleradores de IA y hardware de borde antes de cualquier implementación en producción; financiar el diseño de la jerarquía de CA del fabricante y la participación de PKIaaS antes de que comience la fabricación del hardware (la certificación ECA no se puede instalar posteriormente a la fabricación); exigir que todo el hardware implementado pase la verificación de atestación SPDM utilizando una cadena de certificados DICE completa antes de que se le confíe una carga de trabajo de producción; evaluar PKI como servicio Para la infraestructura de CA del fabricante y del propietario; se requiere una planificación de migración post-cuántica para los algoritmos de claves de CA de hardware junto con el programa post-cuántico PKI más amplio.

Lista de verificación para la implementación de PKI de hardware: Problema, impacto en el negocio, acción recomendada y responsable.

Utilice esta lista de verificación para identificar qué deficiencias en la implementación de PKI de hardware se aplican a su entorno, comprender el impacto empresarial de cada deficiencia y asignar la responsabilidad de la corrección antes de que una certificación SPDM fallida o un hallazgo de auditoría exponga la deficiencia bajo presión.

Problema	Impacto en el negocio	Acción sugerida	Propietario
Perfiles de certificados CA de servidor utilizados para certificados de dispositivos (perfiles TLS de CA/Browser Forum)	Los certificados IDevID y de atestación que carecen de OID tcg-dice-kp en el uso extendido de claves son rechazados por todos los verificadores SPDM y la infraestructura compatible con 802.1AR; todo el conjunto de hardware falla en la atestación y no puede recibir cargas de trabajo de producción.	Configure plantillas de certificados específicas de DICE separadas para los perfiles IDevID, LDevID, ECA y Attestation con los requisitos correctos a nivel de campo según TCG DICE Certificate Profiles v1.1 (24 de abril de 2025); registre los OID tcg-dice-kp en la base de datos OID de la plataforma CA; nunca utilice perfiles TLS CABF para certificados de identidad de hardware.	Equipo PKI
CA no configurado para 99991231235959Z noDespués de validez	La aplicación del período máximo de validez de la CA empresarial rechaza las solicitudes de certificados IDevID o emite certificados con fechas arbitrariamente largas pero que no cumplen con las especificaciones y que no superan la validación de la certificación SPDM; la flota de hardware no puede inscribirse en el programa de identidad de hardware.	Cree excepciones de configuración de CA explícitas para los perfiles de certificados de hardware que permitan 99991231235959Z notAfter; valide el manejo del valor GeneralizedTime 99991231235959Z por parte de la plataforma de CA antes de la integración de fabricación; pruebe la aceptación de certificados con este valor notAfter por parte del verificador SPDM.	Equipo PKI
Las jerarquías de CA del fabricante y del propietario comparten una CA raíz.	La fusión de las jerarquías otorga al proveedor de hardware autoridad sobre la identidad operativa de la organización que realiza el despliegue, rompiendo el modelo de identidad de dos fases definido en IEEE 802.1AR-2018; un único fallo o compromiso de la CA raíz afecta simultáneamente tanto a la cadena IDevID emitida por el fabricante como a la cadena de certificados operativos y LDevID emitidos por el propietario.	Diseñar y operar jerarquías de CA completamente separadas para la PKI del fabricante (que emite certificados IDevID y ECA) y la PKI del propietario (que emite certificados LDevID y certificados operativos del agente); las dos jerarquías nunca deben compartir una CA raíz; la PKI del propietario confía en la cadena IDevID del fabricante a través de la atestación SPDM, no a través de una raíz compartida.	Arquitecto de seguridad + Equipo de PKI
La certificación ECA no está prevista para el tiempo de fabricación.	Los dispositivos se envían sin una ECA debidamente certificada; la arquitectura de capas DICE no puede funcionar por encima de la capa no certificada; descubrir este requisito después de que haya comenzado la fabricación requiere rediseñar un flujo de trabajo de producción, lo cual es costoso y requiere mucho tiempo.	Incluya la certificación de clave ECA como un paso obligatorio en el diseño del flujo de trabajo de fabricación antes de que comience la producción; la CA intermedia del fabricante debe estar disponible e integrada con la línea de producción para certificar las claves públicas ECA antes del envío de cada dispositivo; valide que el certificado ECA incluya keyCertSign (Uso de clave), cA:TRUE y pathLengthConstraint (Restricciones básicas), id-tcg-kp-eca (EKU) y CRLDistributionPoints (obligatorio).	Proveedor de hardware + Equipo de PKI
El formato de la cadena de certificados SPDM es incorrecto para GET_CERTIFICATE.	La verificación CHALLENGE_AUTH falla para todos los dispositivos de la flota; el orquestador no puede verificar la identidad del hardware y no puede enviar ninguna carga de trabajo al hardware; el fallo aparece como un error del protocolo SPDM en lugar de un error de certificado, lo que ralentiza el análisis de la causa raíz.	Valide el formato de la cadena de certificados SPDM según la especificación DMTF SPDM: longitud total de 2 bytes, longitud del hash raíz de 2 bytes, hash del certificado raíz, certificados DER concatenados; pruebe GET_CERTIFICATE y CHALLENGE_AUTH con un verificador SPDM de referencia antes de la implementación en producción; contacte con el equipo de implementación de SPDM de Encryption Consulting para validar la compatibilidad del formato de la cadena de certificados.	Proveedor de hardware + Equipo de PKI
No existe infraestructura CRL ni OCSP para las CA de hardware.	Los certificados ECA sin CRLDistributionPoints infringen la especificación TCG DICE; cada certificación SPDM valida la cadena de certificados, incluido el estado de revocación; los dispositivos cuyos certificados no se pueden comprobar para verificar su revocación no son de confianza operativa; un dispositivo comprometido no se puede poner en cuarentena mediante procedimientos de revocación estándar.	Implemente la infraestructura CRL y OCSP para todos los niveles de CA de hardware; configure los CRLDistributionPoints en todos los certificados ECA según lo requiera la especificación; dimensione la infraestructura para una alta frecuencia de validación (cada atestación SPDM) y una baja frecuencia de revocación (el compromiso de la clave de hardware es poco frecuente y está físicamente restringido); establezca la frecuencia de publicación de CRL para las CA de hardware de semanal a mensual, con SLA de OCSP lo suficientemente estrictos como para que un fallo de atestación no deje un dispositivo en un estado indeterminado.	Equipo PKI

¿Qué significa realmente “identidad de hardware”?

La identidad del hardware es el principio según el cual la identidad de un dispositivo debe estar anclada en algo que no se pueda extraer del hardware sin su destrucción física: una clave criptográfica integrada durante la fabricación, accesible solo para el firmware que se ejecuta directamente en ese silicio y probablemente vinculada al dispositivo específico producido.

La implementación más consolidada de este principio es el Módulo de Plataforma Segura (TPM), presente en servidores empresariales y portátiles desde hace décadas. Sin embargo, los TPM se diseñaron para un mundo de máquinas relativamente estáticas y aserciones de confianza relativamente simples. El desafío que suponen los agentes de IA con capacidad de gestión que se ejecutan en aceleradores de IA específicos, hardware de inferencia en el borde, silicio basado en la nube y clústeres de GPU requiere un enfoque más flexible y modular para la identidad basada en hardware.

Este enfoque se basa en tres estándares interconectados. Cada uno recibirá su propio análisis en profundidad en esta serie de artículos, pero aquí les explicamos qué hace cada uno:

DICE: Motor de composición de identificadores de dispositivos (TCG)

Desarrollado por Trusted Computing Group, DICE proporciona la base: un mecanismo para derivar una identidad criptográfica única, vinculada al hardware, a partir de un secreto integrado en el momento de la fabricación. Cada capa de firmware añadida sobre esta base se mide e incorpora a la derivación de la identidad, de modo que la identidad que emerge en la capa de aplicación refleja no solo el hardware en sí, sino también el estado específico del firmware que se ejecuta en él. Un agente que ejecuta hardware con firmware modificado tendrá una identidad diferente a la del mismo hardware con firmware sin modificar, y esa diferencia es criptográficamente demostrable.

SPDM: Protocolo de seguridad y modelo de datos (DMTF)

SPDM es el protocolo de comunicación que permite a un componente demostrar su identidad de hardware a otro. Mientras que DICE crea la identidad, SPDM es el mecanismo mediante el cual dicha identidad se presenta y verifica durante una interacción en tiempo real. Un orquestador de IA que utiliza SPDM puede desafiar a un componente de hardware, una GPU, una tarjeta de red o un enclave seguro, y recibir una certificación criptográficamente firmada de la identidad y el estado de medición de dicho componente antes de confiarle cualquier carga de trabajo.

CMS y X.509: El sobre PKI

La Sintaxis de Mensajes Criptográficos (CMS, RFC 5652) y los perfiles de certificados X.509 constituyen la capa donde la identidad del hardware se conecta con el ecosistema PKI más amplio . DICE genera una cadena de certificados basada en el hardware. SPDM certifica la integridad del hardware en tiempo de ejecución. CMS proporciona el marco para firmar acciones, transacciones o mensajes individuales de los agentes, vinculándolos a la identidad del agente que los generó, basada en el hardware. En conjunto, estos tres estándares conforman una cadena de confianza completa, desde el silicio hasta la acción firmada.

Identidad basada en hardware para agentes de IA

DICE, SPDM, IEEE 802.1AR-2018 (Identidad Segura de Dispositivos) y CMS están bien definidos y se implementan activamente en el hardware empresarial actual. Los aceleradores de IA de los principales proveedores de hardware ya implementan DICE. Los servidores empresariales ya son compatibles con SPDM. Los certificados que vinculan estas certificaciones a una infraestructura de clave pública (PKI) utilizable ya cumplen con los perfiles X.509 e IEEE 802.1AR, ampliamente establecidos.

El desafío radica en que nadie ha construido aún la infraestructura operativa que conecta estos estándares a nivel de hardware con el ciclo de vida de implementación de agentes de IA. Las plataformas de emisión de certificados se crearon para servidores, usuarios y dispositivos. No fueron diseñadas para:

• Registre la identidad de hardware de un acelerador de IA utilizando cadenas de certificados derivadas de DICE.
• Verifique la integridad del firmware mediante SPDM antes de emitir un certificado de agente operativo.
• Gestionar ciclo de vida del certificado para identidades de agentes que pueden crearse y eliminarse varias veces al día.
• Vincular las acciones firmadas por el agente a través del CMS con la cadena basada en hardware que prueba la procedencia del agente.

Esa brecha operativa entre los estándares existentes y la infraestructura que los implementa para la IA automatizada es precisamente donde se acumula el riesgo. Nuestra colaboración con una organización Fortune 100 en PKI compatible con SPDM para certificados de dispositivos, alineada con DICE X.509 e IEEE 802.1AR, representa el tipo de implementación real que la mayoría de los proveedores aún consideran un objetivo futuro. Los estándares existen, el hardware los admite y la implementación está en marcha para las organizaciones que deciden exigirla.

Cinco maneras en que la infraestructura de clave pública (PKI) basada en hardware es estructuralmente diferente.

A continuación se presentan las 5 implicaciones de la infraestructura de clave pública (PKI) que son estructuralmente diferentes y que deben tenerse en cuenta durante la fabricación del hardware.

1. La clave privada está físicamente ligada al silicio.

En la infraestructura de clave pública (PKI) de servidor , una clave privada se puede exportar, respaldar, migrar o rotar según un cronograma. En la PKI de identidad de hardware, la clave privada se deriva del UDS (Secreto Único del Dispositivo), un valor integrado físicamente en el silicio durante la fabricación, tal como se especifica en la arquitectura TCG DICE. No se puede exportar ni respaldar. Una vulneración de la clave implica la desactivación del dispositivo, no el reemplazo del certificado.

Implicaciones de la infraestructura de clave pública (PKI):

• No existe un modelo de depósito de claves para las claves vinculadas al hardware.
• La rotación de la llave requiere el reemplazo físico del dispositivo.
• Su CA no puede verificar la clave únicamente mediante un flujo de trabajo CSR estándar; la cadena de derivación DICE proporciona la prueba de vinculación.

2. La validez del certificado debe diseñarse en función de la vida útil del dispositivo, no de los periodos de cumplimiento.

El Foro CA/Browser ha establecido un plazo máximo de 47 días para la duración de los certificados TLS (Propuesta SC-081, vigente desde marzo de 2026). Un acelerador de IA que se comercialice hoy podría seguir en producción en 2045. La especificación de perfiles de certificados TCG DICE aborda este problema directamente.

Los dispositivos que no cuentan con un reloj seguro pueden configurar la parte "No después de" del período de validez del certificado con el valor GeneralizedTime 99991231235959Z , definido por X.509 . Este valor se utiliza para indicar que el certificado no tiene una fecha de vencimiento definida.

Esto no es opcional ni una solución alternativa. Es el comportamiento normativo para los certificados de hardware en dispositivos sin reloj en tiempo real. Su infraestructura de CA debe estar configurada para emitir certificados con este valor. La mayoría de las plataformas de CA empresariales imponen restricciones de período máximo de validez por defecto; necesitará excepciones de configuración explícitas para los perfiles de certificados de hardware.

3. Dos fases de identidad distintas requieren dos jerarquías PKI completamente separadas.

La identidad del hardware opera en dos fases con diferentes puntos de confianza:

Fase 1 – Identidad en tiempo de fabricación (IDevID)	Fase 2 – Identidad en tiempo de despliegue (LDevID)
Estándar: IEEE 802.1AR-2018 + TCG DICE X.509	Estándar: IEEE 802.1AR-2018 + TCG DICE X.509
Emitido por: Autoridad de Certificación del fabricante del dispositivo	Emitido por: Autoridad de certificación del propietario del dispositivo (completamente independiente de la autoridad de certificación del fabricante).
OID de la política: id-tcg-kp-identityInit {id-tcg-kp 6}	OID de la política: id-tcg-kp-identityLoc {id-tcg-kp 7}
Propósito: Demostrar que se trata de hardware original de este fabricante.	Propósito: Identidad operativa dentro del entorno del propietario.
Este es el certificado de nacimiento del dispositivo. No se puede volver a emitir después de su fabricación.	Se emite una vez que la certificación SPDM de la cadena IDevID se realiza correctamente.

Estas dos jerarquías nunca deben compartir una raíz. La CA del fabricante no tiene autoridad sobre el entorno operativo del propietario. Fusionarlas otorga al proveedor de hardware un control continuo sobre las decisiones de PKI de la organización que implementa la infraestructura, lo cual representa un fallo en el modelo de confianza y, en sectores regulados, un problema de cumplimiento normativo.

4. La revocación implica una acción física, no la sustitución del certificado.

Revocar un IDevID no permite volver a emitirlo con una nueva clave. La clave está vinculada al hardware. La revocación implica que el dispositivo se pone en cuarentena o se desactiva. Su infraestructura CRL y OCSP debe diseñarse teniendo en cuenta esta realidad.

• Las entradas CRL de IDevID deberían activar flujos de trabajo de cuarentena de dispositivos, no solo la invalidación del certificado.
• Los acuerdos de nivel de servicio (SLA) de OCSP para las CA de hardware deben ser estrictos; es decir, un dispositivo que no puede validar su cadena de certificados queda inoperativo.
• La frecuencia de publicación de CRL para las CA de hardware puede ser mayor que la de las CA de servidor (de semanal a mensual) porque los eventos de compromiso de claves son raros y están físicamente limitados.

5. La CA emisora ​​puede estar integrada en el firmware del dispositivo.

La especificación TCG DICE define una Autoridad de Certificación Integrada (ECA, por sus siglas en inglés), una CA que reside dentro del firmware del dispositivo y emite certificados a las capas de firmware superiores.

La ECA es una CA real. Tiene un par de claves derivado del DICE CDI (Identificador de Dispositivo Compuesto). Firma certificados. Debe estar certificada por la CA del fabricante durante el proceso de fabricación. Esto significa:

• La CA emisora ​​del fabricante debe estar disponible e integrada en la línea de producción.
• El certificado ECA DEBE contener: keyCertSign en Uso de clave, cA:TRUE en Restricciones básicas con pathLengthConstraint, OID de política id-tcg-kp-eca {id-tcg-kp 12}, y CRLDistributionPoints DEBE estar presente.
• Si descubre que la ECA necesita ser certificada después de que la fabricación haya comenzado, estará rediseñando un plan de flujo de trabajo de producción, por lo que esto debe estar presente desde el primer día.

La jerarquía PKI para la identidad de hardware

Aquí se muestra la jerarquía completa de CA, con los requisitos en cada nivel. Esto se aplica a los proveedores de hardware que desarrollan la infraestructura de clave pública (PKI) del fabricante.

Nivel CA	Algoritmo / HSM	Validez	Uso clave	Temas
Fabricante Root CA	Módulo de seguridad de hardware (HSM) ECDSA P-384 / FIPS 140-3 L3+, aislado de la red.	99991231235959Z (sin reloj) o definido	Solo para California	Fabricante intermedio CA solamente
Fabricante intermedio CA	ECDSA P-384 / FIPS 140-3 L3 HSM, acceso restringido en línea	99991231235959Z (sin reloj) o definido	CA + CRLSign	Certificados IDevID o certificados ECA
ECA (en el dispositivo, DICE)	ECDSA P-256/384 / Derivado de DICE CDI	Coincide con la vida útil de IDevID	Solo keyCertSign (NO DEBE firmar con cRLSign)	Certificados de atestación para capas de firmware
Certificado de hoja IDevID	ECDSA P-256/P-384 / unido al silicio	99991231235959Z (sin reloj) o definido	NO DEBE keyCertSign	Entidad final para la identidad del dispositivo

OIDs de política de TCG: Cada certificado debe llevar el correcto

La especificación TCG DICE define un conjunto de OID de política en el espacio de nombres id-tcg-kp. Cada OID codifica para qué está autorizado un certificado y cómo se vinculó su clave. Un OID incorrecto implica que el certificado no superará la validación en todos los verificadores SPDM y sistemas compatibles con 802.1AR.

Nombre OID	Valor OID	tipo de certificado	La llave debe estar vinculada.
id-tcg-kp-identityInit	{id-tcg-kp 6}	IDevID	En el momento de la fabricación. Certificado por el fabricante CA.
id-tcg-kp-identityLoc	{id-tcg-kp 7}	LDevID	Post-fabricación. Certificado por el propietario local de California.
id-tcg-kp-attestInit	{id-tcg-kp 8}	Atestación (inicial)	En el momento de la fabricación. Señales que evidencian el firmware/configuración del dispositivo.
id-tcg-kp-attestLoc	{id-tcg-kp 9}	Atestación (local)	Post-fabricación. Certificado por un emisor local.
id-tcg-kp-assertInit	{id-tcg-kp 10}	Afirmación (inicial)	En el momento de la fabricación. Los signos hacen referencia a las medidas.
id-tcg-kp-assertLoc	{id-tcg-kp 11}	Afirmación (local)	Post-fabricación. Certificado por un emisor local.
id-tcg-kp-eca	{id-tcg-kp 12}	las exhibiciones de ECA	Fabricación o posfabricación. Autoriza la emisión de certificados por parte de la CA integrada.

Reglas prácticas para la configuración de su CA:

• IDevID DEBE contener id-tcg-kp-identityInit. TAMBIÉN PUEDE contener id-tcg-kp-eca (si el dispositivo es una ECA) e id-tcg-kp-attestInit (si también realiza la firma de atestación).
• LDevID DEBE contener id-tcg-kp-identityLoc. También PUEDE contener id-tcg-kp-eca e id-tcg-kp-attestLoc.
• Los certificados ECA DEBEN contener id-tcg-kp-eca. La extensión CRLDistributionPoints DEBE estar presente.
• Los certificados de atestación DEBEN contener id-tcg-kp-attestInit o id-tcg-kp-attestLoc.

Los seis errores más comunes que cometen los proveedores de hardware en materia de infraestructura de clave pública (PKI).

A continuación, se describen seis errores comunes que los proveedores de hardware pueden cometer al diseñar o implementar controles de identidad y seguridad basados ​​en hardware. Estos puntos no son necesariamente aplicables a todos los proveedores de hardware y pueden variar según la arquitectura del producto, el modelo de implementación, el panorama de amenazas, los requisitos normativos y el caso de uso específico. Deben considerarse como consideraciones generales, no como suposiciones universales.

Se utilizan perfiles de certificados de servidor para certificados de dispositivos. Los perfiles CA/Browser Forum están diseñados para TLS. Estos imponen requisitos de nombre de sujeto, requisitos SAN y periodos de validez que no se aplican a la identidad del hardware. Un IDevID emitido con un perfil CABF no incluirá id-tcg-kp-identityInit, tendrá un periodo de validez corto y será rechazado por los verificadores SPDM que comprueban los OID de TCG.

No se configura la CA con una duración de 99991231235959Z. Las CA empresariales aplican un período máximo de validez. Si su equipo de hardware solicita un IDevID y la CA lo rechaza porque la duración excede los límites de la política, recibirá un certificado mal configurado o un certificado alternativo con una fecha arbitrariamente larga, pero no con el valor especificado.

La fusión de las jerarquías de CA del fabricante y del propietario, al crear una única infraestructura de clave pública (PKI) que emita tanto IDevID como LDevID desde la misma raíz, otorga al proveedor de hardware autoridad sobre la identidad operativa de la organización que implementa el sistema. Esto rompe el modelo de identidad de dos fases definido en IEEE 802.1AR-2018, creando un único punto de fallo para ambas fases.

No planificar la certificación ECA durante la fabricación. Si su dispositivo implementa DICE, la ECA debe estar certificada antes de su envío. Esto significa que la CA intermedia del fabricante debe estar disponible e integrada en el flujo de trabajo de fabricación. Los equipos que descubren este requisito una vez iniciada la fabricación se enfrentan a costosos rediseños de procesos o al envío de dispositivos sin una ECA debidamente certificada.

Ignorando el formato de cadena de certificados SPDM. SPDM GET_CERTIFICATE devuelve una cadena en un formato específico: longitud total de 2 bytes, longitud del hash raíz de 2 bytes, hash del certificado raíz y certificados DER concatenados. Si su PKI emite cadenas DER estándar y su implementación de SPDM las procesa incorrectamente, la verificación CHALLENGE_AUTH fallará.

No se requiere infraestructura CRL/OCSP para las CA de hardware. El perfil de certificado ECA exige la presencia de CRLDistributionPoints. La infraestructura CRL de la CA de hardware debe dimensionarse para una frecuencia de revocación muy baja, pero una frecuencia de validación muy alta. Cada certificación SPDM valida la cadena de certificados, lo que incluye comprobaciones CRL/OCSP.

Cómo puede ayudar la consultoría de cifrado

Encryption Consulting se especializa en arquitectura PKI para identidad basada en hardware. Nuestro trabajo con proveedores de hardware y organizaciones de implementación abarca el tema de este blog: diseño de jerarquías de CA de fabricantes, configuración de perfiles de certificados de hardware, implementación del aprovisionamiento de ECA en flujos de trabajo de fabricación y creación de la PKI del propietario que conecta IDevID con la identidad operativa del agente.

• Diseño de PKI del fabricante: Diseñamos jerarquías de CA alineadas con TCG DICE, IEEE 802.1AR y DMTF SPDM. Esto incluye la planificación de la ceremonia de la CA raíz fuera de línea, la selección y configuración de HSM y las especificaciones del perfil de certificado que su CA necesita para IDevID, ECA y certificados de atestación.
• Integración del flujo de trabajo de fabricación: La certificación de claves ECA requiere que la CA del fabricante esté disponible e integrada durante el proceso de producción. Diseñamos e implementamos la conectividad HSM, la generación de certificados y la verificación de la integración PKI con la fabricación, lo que hace que esto sea viable operativamente.
• Implementación de SPDM y DICE: Conectamos la infraestructura de clave pública (PKI) de hardware con la atestación en tiempo de ejecución, asegurando que la cadena de certificados que emite su PKI pase la validación SPDM GET_CERTIFICATE y CHALLENGE_AUTH. Estudio de caso de una empresa Fortune 100 SPDM es una referencia de producción para este trabajo.
• Administrador de CertSecure Para el agente CLM: Para la gestión de los ciclos de vida de los certificados operativos del agente PKI del propietario a gran escala, CertSecure Manager proporciona descubrimiento, renovación automatizada de EST, automatización de la revocación e infraestructura de registro de auditoría.

Conclusión

La identidad del hardware para los agentes de IA no es una preocupación futura. Los aceleradores de IA ya implementan DICE. El hardware empresarial ya es compatible con SPDM. Los certificados que vinculan estas certificaciones a una infraestructura de clave pública (PKI) utilizable ya cumplen con los estándares X.509 y CMS, ampliamente establecidos. Lo que falta es la arquitectura operativa que los conecte y la voluntad organizacional para exigir la confianza basada en el hardware como requisito fundamental para el despliegue de la IA con agentes.

Los cuatro blogs restantes de esta serie construyen esa arquitectura paso a paso. Al final, tendrás un plan completo para una pila de identidad de agente de IA que comienza en silicio y termina con un registro firmado y auditable de cada acción importante que realicen tus agentes.

Preguntas frecuentes

¿Cuál es la principal conclusión de "La crisis de identidad en los albores de la IA con agentes"?

La mayoría de las implementaciones de IA basadas en agentes dependen de credenciales de software que demuestran que un proceso tiene las credenciales correctas, pero no pueden demostrar que el hardware subyacente sea confiable, que el firmware no haya sido modificado o que el agente se esté ejecutando en la plataforma esperada. La identidad basada en hardware, mediante perfiles de certificados DICE, SPDM y X.509, resuelve esta brecha al anclar la identidad del agente en el silicio, lo que permite detectar criptográficamente las modificaciones del firmware y posibilita que los orquestadores verifiquen el estado del hardware antes de enviar cargas de trabajo. El hardware ya es compatible con estos estándares; la brecha reside en la arquitectura PKI operativa que los conecta.

¿Por qué es importante la infraestructura de clave pública (PKI) de hardware para la IA agente para los equipos de PKI empresariales?

La infraestructura de clave pública (PKI) de hardware difiere estructuralmente de la PKI de servidor en cinco aspectos: las claves están físicamente vinculadas al silicio y no se pueden exportar; la validez del certificado está ligada a la vida útil del dispositivo (99991231235959Z) en lugar de a ventanas de cumplimiento; las jerarquías PKI del fabricante y del propietario nunca deben compartir una raíz; la revocación activa la cuarentena del dispositivo físico en lugar del reemplazo del certificado; y la autoridad de certificación de extremo a extremo (ECA) debe estar certificada en el momento de la fabricación. Una plataforma de CA estándar sin configuración específica de DICE producirá certificados que no superen la atestación SPDM, lo que impedirá que todo el parque de hardware reciba cargas de trabajo de producción.

¿Qué riesgos aumentan si la identidad del hardware de los agentes de IA se gestiona sin un programa estructurado?

Aumentan cuatro categorías de riesgo: suplantación de credenciales de software (sin una identidad basada en hardware, cualquier proceso con las credenciales correctas puede suplantar a un agente de IA, incluido un dispositivo comprometido o falsificado); modificación de firmware no detectada (DICE hace que la modificación del firmware sea detectable criptográficamente; sin ella, no se pueden detectar los ataques a la cadena de suministro); fallo de la certificación SPDM (los certificados que carecen de OID de política TCG fallan en todos los verificadores SPDM); y brechas en la migración post-cuántica (los algoritmos de clave CA de DICE deben migrar a ML-DSA según NIST FIPS 204, finalizado el 13 de agosto de 2024; las jerarquías no catalogadas no se pueden incluir en la planificación de la migración).

¿Qué equipos deberían ser responsables de la identidad del hardware para la IA agente?

Los proveedores de hardware y los equipos de firmware son responsables de la implementación de IDevID en tiempo de fabricación. Los equipos de PKI y certificados son responsables del diseño de la jerarquía de CA y la configuración específica de DICE. Los arquitectos de seguridad son responsables del modelo de gobernanza: integración con IEEE 802.1AR-2018, política de certificación SPDM y puenteo de PKI del propietario desde IDevID del fabricante hasta LDevID del propietario y certificados operativos del agente. Los equipos de cumplimiento son responsables de la evidencia de auditoría de los certificados de identidad de hardware en toda la flota desplegada.

¿Cómo se relaciona la identidad del hardware para la IA agente con la gestión del ciclo de vida de los certificados?

La gestión del ciclo de vida de la identidad del hardware (CLM) se basa en la frecuencia de actualización del firmware, no en la caducidad del calendario: una actualización del firmware genera una nueva derivación de CDI, un nuevo par de claves y una nueva solicitud de certificado. La infraestructura de clave pública (PKI) del propietario emite certificados operativos LDevID y de agente tras la correcta verificación de SPDM, y estos certificados operativos deben gestionarse a escala de flota para aceleradores de IA que se activan y desactivan varias veces al día. CertSecure Manager proporciona la capa CLM a nivel de flota: renovación automatizada mediante EST, automatización de la revocación, detección a nivel de flota y registro de auditoría para las poblaciones de certificados operativos de los agentes.

¿Cómo deberían las organizaciones medir el éxito en la identificación de hardware para la IA automatizada?

Métricas clave: tasa de aprobación de la certificación SPDM (100 por ciento para todos los aceleradores de IA de producción); integridad de la cadena de certificados (todo el hardware implementado tiene una cadena completa y verificable desde el dispositivo hasta la CA raíz del fabricante); cobertura CLM a nivel de flota (todos los certificados operativos del agente en el inventario con correlación de la versión del firmware); y clasificación de preparación post-cuántica (algoritmos clave de CA clasificados según los hitos de obsolescencia de NIST IR 8547 con un cronograma de migración definido).

¿Qué se debe auditar o supervisar periódicamente?

Supervisar continuamente: disponibilidad del respondedor OCSP y del punto de distribución de CRL para todos los certificados ECA (requerido por la especificación TCG DICE; cada certificación SPDM valida la cadena, incluido el estado de revocación); vencimiento del certificado operativo del agente con alertas de renovación; tasas de aprobación/rechazo de la certificación SPDM. Auditar trimestralmente: inventario de certificados a nivel de flota correlacionado con las versiones de firmware implementadas; registros de certificación SPDM para dispositivos que fallan debido a problemas con la cadena de certificados; clasificación del algoritmo de clave CA según NIST FIPS 203/204/205 (finalizado el 13 de agosto de 2024).

¿Cómo afecta la identidad de hardware para la IA agente a los entornos PKI en la nube, híbridos o con múltiples autoridades de certificación?

La capa de CA del fabricante se sitúa por debajo de la jerarquía PKI empresarial. En implementaciones en la nube e híbridas, el puente PKI del propietario debe conectar las credenciales IDevID con raíz del fabricante con la infraestructura de certificados operativos LDevID y de agente operada por el propietario, sin fusionar las dos jerarquías ni otorgar al proveedor de hardware autoridad sobre las decisiones PKI del propietario. Los entornos multinube deben garantizar que la infraestructura de verificación de atestación SPDM de cada entorno de nube confíe en la misma raíz de CA del fabricante. Los certificados operativos de agente para cargas de trabajo de IA que se ejecutan varias veces al día requieren automatización CLM que las herramientas estándar no están diseñadas para proporcionar.

¿Qué errores comunes deben evitar los equipos?

Los seis errores más frecuentes: usar perfiles TLS de CA/Browser Forum para certificados de dispositivos (los OID de política TCG faltantes hacen que todos los verificadores SPDM fallen); no configurar la CA para la validez notAfter 99991231235959Z; fusionar las jerarquías de CA del fabricante y del propietario en una sola raíz; no planificar la certificación ECA en el momento de la fabricación; no enmarcar correctamente la cadena SPDM GET_CERTIFICATE (lo que hace que CHALLENGE_AUTH falle); y no implementar la infraestructura CRL/OCSP para CA de hardware (requerida por el perfil de certificado ECA).

¿Qué aspectos de la gestión de identidades de hardware deben actualizarse trimestralmente?

Trimestralmente: verifique que el inventario de certificados a nivel de flota esté actualizado y correlacionado con las versiones de firmware implementadas; confirme la disponibilidad del respondedor OCSP y del punto de distribución de CRL para todos los certificados ECA; revise los registros de aprobación/rechazo de la atestación SPDM; clasifique los algoritmos de clave CA según los hitos de desuso post-cuántico del NIST (ML-DSA según FIPS 204, finalizado el 13 de agosto de 2024); confirme que el puente PKI del propietario esté configurado correctamente para cualquier hardware recién implementado; revise la cobertura de automatización de renovación de certificados operativos del agente. Para la planificación de la migración de algoritmos de clave CA post-cuánticos, consulte el Centro de Excelencia de PQC.