¿El “lanzamiento tardío” / la “cadena dinámica de confianza” permite la certificación remota?

  

¿La "cadena de confianza dinámica" es compatible con la certificación remota?

Cuando se utiliza un lanzamiento dinámico en un área de la memoria, se usan índices de PCR específicos en el TPM para registrar el estado de ese software. Si estos índices de PCR están incluidos en la solicitud de certificación por parte del retador, entonces ese software se confirmará en la respuesta. Estos índices de PCR son 17-22, como se especifica en Implementación de PCClient de TCG para especificaciones de BIOS , vea la página 30.

  

¿Proporciona una forma de certificar el código del módulo confiable que se lanzó de esta manera, a un tercero?

La implementación de Intel de la compatibilidad con TXT en Linux, tboot, se ha perdido un detalle que, con suerte, se solucionará pronto. tboot no expone el registro de eventos, que mostraría qué software se extendió a los TPM PCR como parte del lanzamiento de TXT. Este es un requisito para que un participante remoto pueda atestiguar contra los PCR de lanzamiento dinámicos, por lo que en este momento, el soporte no está completamente allí. Técnicamente, puede encontrar el registro de eventos, pero no está disponible en un formato estándar TCG, por lo que todas las herramientas informáticas de confianza comunes que se usarían para analizarlo no funcionarán en ATM.

Sí.

Puede ver ambas funciones como realmente dos cosas separadas, es decir, DRTM (Dynamic Root of Trust for Measurement) es solo otra manera de extender los valores de PCR (17-22) (como SRTM), mientras que la certificación remota tomará cualquier PCR desea utilizar (como la operación de sellado). No hay dependencia o vínculo real entre esas funcionalidades.

Si desea obtener más detalles sobre los aspectos internos de DRTM y la certificación remota, le recomiendo que lea los documentos del proyecto de Flicker. Flicker usa DRTM para demostrar a un tercero que se ejecutó un D-MLE particular (Entorno de lanzamiento de medida dinámico). Historia corta: enlace , Historia larga: enlace .

p.s. Parece que hay un error en la larga historia donde dicen que SRK (Storage Root Key) es creado por el fabricante, mientras que en realidad es creado por el propietario de la plataforma cuando el take ownership . Con suerte, no usaron el SRK para demostrar que es un TPM real / físico. Solo la EK (Clave de aprobación) puede demostrar que un TPM es genuino.

No estoy seguro de cómo podría hacerlo sin tener algún tipo de clave precompartida con el servicio remoto o una clave privada establecida de manera confiable que tenga el TPM. Creo que el problema sería que el tercero no tendría forma de saber que era el TPM el que ejecutaba el código en lugar de una variante modificada modificada para ejecutarse en un espacio no protegido. Si el TPM tuviera una clave privada de confianza del tercero, sería posible que el tercero emitiera un desafío al TPM al cual el TPM solo podría responder dentro de un proceso firmado y de confianza y que cumpliría el objetivo de certificación remota. , pero no veo cómo se establecería esa clave privada de confianza.

Tenga en cuenta que estoy respondiendo puramente de la descripción del sistema de cifrado provisto y mi conocimiento general de los TPM. No tengo ningún conocimiento específico adicional sobre lo que Trusted Execution soporta, pero pensé que el objetivo principal de eso era con fines de protección de código y DRM en lugar de atestación remota, aunque sin duda sería una buena extensión para ello.

Encontré un documento con más detalles del CERT. documento CERT sobre la capacidad del TPM .