[EAT] Entity Attestation Token (EAT) Draft Comments

[Hannes Tschofenig <[e-mail]>]

Hi all,


Within Arm, we have been looking at the role of attestation with respect to a wide set of use cases and evaluating EAT as the means to describe the claims necessary to describe the entities within these use cases. We have some comments on the existing set of claims proposed in https://tools.ietf.org/html/draft-mandyam-eat-00 and would like to introduce further claims of general utility.

The use cases considered include:

 

  *   Attestation for a standalone, self-contained device
  *   Overall attestation for a device or system composed of multiple identifiable components
  *   Attestation for a combination of hardware and the software deployed on that device

 

In the above, even for the combination cases, it is assumed that where an EAT is produced, a single attesting authority can produce the token. If there are different trust or security levels within the components, they can still be combined into a single report, but the report will then be structured to clarify the diverse conditions. Where a device is composed of components which might have multiple attesting authorities, it would be expected that multiple EATs would be created, even if delivered as a package within a further EAT.

 

Proposed claims:

 

'Debug-*-Disabled'

Having 4 separate claims related to debug tracking (debug-*-disabled) could lead to some contradictory declarations, especially as the definitions of those settings appear to be of increasing restriction. We would propose that the 4 are combined into a single 'debug-disabled' claim, with 4 integer values representing the states represented by the current individual claims. It would also then be useful to have a distinct value for ‘Enabled’ to help distinguish that distinct state from the absence of the claim.

 

'Origination' + 'OEM'

Where the device involved may have complex make up, these claims alone are not sufficient to be able to describe all components. Therefore, we propose the addition of the following claims to be used in addition to these. These claims can be used for both software and hardware components. Use of claims within submods and arrays or within embedded EAT claims would capture the necessary hierarchy of the component set. The exact hierarchy will depend upon the scope of the attesting authority with respect to the components within the device. Where possible, it seems desirable to keep the maximum set of claims within a single EAT, but depending on the composition of the device, multiple EATs can contribute different scopes. If there are a subset of claims which have a contained signing or encryption scope, it would be expected that set would be embedded in a (signed, encrypted) EAT. Also note the ‘profile’ proposal below to clarify layout for any use case.



The following set of proposed new claims appear to be of general value to describe an entity.

'manufacturer' - string value capturing manufacturer name or code. Note that this is most similar to one of the existing uses of 'origination' and it is possible that claim might suffice for this claim purpose.

 

'component' - string value capturing the component name or part code (from a given manufacturer). In hierarchical descriptions, this claim may often match or reflect a submod_name and can potentially be omitted.

 

'version' - string value reflecting a release level of a component. It was not felt that multiple levels of version claims would be required as the value of this claim would often contain a relevant internal structure, for example the "major.minor.maintenance.build" format common to many software releases.

 

'securityReleaseLevel' - a string value reflecting the security release (sometimes called epoch) level. Given the nature of some device components, this was felt to be a useful distinct claim in addition to version.



‘session’ – a claim for data such as boot seeds or similar that might be used to do correlated validations across a number of tokens from the same source.

 

'measurement' - a string value reflecting some measurement of the component. For the example of a software component, this would often be a hash of the software, taken at the relevant point of its lifecycle for the nature of the attestation.

 

'measurementState' - a string value which describes the lifecycle state of a component when it was measured. A string is proposed for flexible interpretation, but it could be possible to capture an expected set of states. Examples might be 'delivered', 'installed', 'loaded', 'executing', 'snapshot'.

 

'certifiedBy' - where a component has been through a certification program, this claim would be a string value representing the identity of the authority conducting that certification. Examples could be an authority which formally assesses the seclevel claim or a software signing authority. This claim could potentially be used by a verifier to check with the authority for any alteration claims to that certification or used with the measurement claim to check that a component has an expected measured value.

 

'certifiedByReference' - this claim would be a string value, used in association with 'certifiedBy' to locate the relevant program that the certification authority has applied. An example might be the thumbprint of a signing certificate.

 

We have deliberately kept these proposed additions to a modest set. It is thought that they can enhance the descriptive nature of claims in an EAT for a multitude of use cases. Where a device or system is of complex nature, hierarchical layout of the EAT should be able to reflect any subtle or specific semantic interpretations of claims and their relationships.

 

'development' - this would be an additional (global level) claim added to a report that indicates that the EAT has been generated only for system development purposes and not deployed in production. This claim could allow a validating service to treat such a submission with lower priority or to return greater detail on any errors.

 

 

Profiles

In order to assist the implementors of a verifier for a given EAT set and to assist in keeping the EAT claims to a discrete set, we would also like to propose the publication of EAT 'Profiles'.  These would be separate documents created by a vendor, industry alliance, or an SDO, which describe what claims must be present for a particular use case. The document would contain:

·            which standard claims would be used

·            whether the presence of those claims is required / recommended / optional

·            what the expected submod / array / embedded EAT hierarchy would be in the EAT and any semantic interpretations or claim relationships that a verifier should consider.

·            list any custom claims expected, with their key values, presence recommendations and place in a hierarchy

·            what signing algorithm must be used



If a profile is expected to be in place for a given EAT use case, additional claims may also be present in the EAT, to assist the expected validation process. These claims would be strings  ‘profileName’ and ‘profileVersion’, expected to be resolvable to a known published use case/description. IANA could maintain a profile registry.



 (As a comparison, this profile concept has been applied successfully to JWTs by organizations like the OpenID Foundation.)


Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.