Platform Configuration Registers Open Config Standard based proto definitions for External Vendors#11
Conversation
…o Definitions for External Vendors
…initions for External Vendors
proto/pcr.proto
Outdated
| } | ||
| message PcrValues { | ||
| int32 pcr_index = 1; // Refers to the PCR index value | ||
| repeated BootStage boot_stage = 2; // Refers to a quick reference name to define PCR measurement content associated with the pcr index. eg - UEFI Boot Manager Code=pcr_4 |
There was a problem hiding this comment.
i am not clear how this is meant to be used?
There was a problem hiding this comment.
This is only for informational purpose.
There was a problem hiding this comment.
The idea, @marcushines, was to link a PCR to a boot stage. Currently, each business unit of each vendor assigns PCRs as they wish, so it is not possible to know which PCR correlates to the software image, for example. So, we must maintain maps. We'd like to stop doing that.
I'm not sure that this enum is complete, but it is a starting point.
There was a problem hiding this comment.
so what gaurentees the pcr's are comparable by that definition?
like how do we know all vendors support a common set and for any individual PCR they are calculated the same way?
There was a problem hiding this comment.
The list came from the TCG docs. Maybe more values are needed? I do not know; hopefully there will be input from vendors and people who know more about TPMs than Morrow and I.
I thought that, excepting the hash type, there was only 1 way to calculate the value, though there might be multiple constituents. Please explain.
proto/pcr.proto
Outdated
|
|
||
| // Get RPC Messages | ||
| message GetRequest { | ||
| string image_version = 1; // Refers to the the version of the software/firmware |
There was a problem hiding this comment.
Is image_version referring to a software_version retrieved from FetchSoftwareVersions? Should there be another string field under GetRequest to refer to a bootloader_version?
There was a problem hiding this comment.
I agree with that first comment; fields image_version and hardware_model need a lot more guidance about their contents, where it comes from, etc. Otherwise, vendors will find many options. I expect we'd want them to be equal (from) another thing so we can readily match it to things we have.
The other thing is possibly:
image_version: the software image filename? For example, c7200-p-mz.121-27b.bin. You have an image from a vendor. how do you retrieve the PCR(s) for that image? What do you place in the request? We do not want to spend time manipulating strings to find the matches. This needs to be defined.
hardware_model: the same as openconfig.ovgs.v1.GetSerialResponse.model - I hope! Be consistent! Which I expect to be the same thing that snmp, netconf, gnmi, and cli return for the model.
Regarding the second comment; I do not think that the kernel and boot loader should be combined. That might be relevant to one vendor, but not another. Each software image has its own PCR, they should be collected separately.
There was a problem hiding this comment.
i would say this should be same version that is reported in OS version in OC
/system/state/software-version/
There was a problem hiding this comment.
/system/state/software-version
description:
Operating system version of the currently active controller of the device. It is required that this value matches the value of the state/software-version leaf in the component of type OPERATING_SYSTEM.
That might be insufficient; an example from XR:
7.3.2
That would not differentiate a kernel from a boot image, for example. And, there are several variants of IOS XR 7.3.2, afaik; for example k9 and not k9 variants.
mihirpitale-googler
left a comment
mihirpitale-googler
left a comment
There was a problem hiding this comment.
adding bootloaderversion repeated pcr values and creating struct
mihirpitale-googler
left a comment
mihirpitale-googler
left a comment
There was a problem hiding this comment.
adding comments above attributes
5 participants
Description
The current lack of a unified standard for vendors to provide Platform Configuration Register (PCR) values—characterized by less secure delivery methods like Excel or JSON and disparate data formats—severely hampers the scalability and reliability of Google’s Attestation service for network infrastructure.
This fragmentation necessitates manual data entry and creates significant operational toil, ultimately slowing down the integrity verification process for network devices. To resolve this, we propose a standardized OpenConfig schema and protobuf-based framework that mandates vendors to deliver PCR values in a consistent, hex-standardized format via secure endpoints with every software release. By automating the ingestion of these measurements, the solution ensures a more reliable and efficient way to verify device trustworthiness across the network.