Re: [Rats] Function of an endorsement relative to evidence

["Smith, Ned" <[e-mail]>]

> The fundamental purpose of an Endorsement is to tell the Verifier that they can believe what they get in Evidence. 

The RATS Architecture defines Endorsement according to [1] and Reference Values according to [2]. The statement above seems misleading since Evidence is believed based on how it matches with Reference Values. Endorsements describe the intrinsic properties that are not surmisable by an Attesting Environment.

For security-level claim asserted as Evidence to make sense, the claims collection capability of the Attesting Environment must be able to assess the security-level of the Target Environment. According to [3], the Attesting Environment relationship to the Target Environment is already anticipated to be reliable. Hence, security-level claims must apply to the *type* of Target Environment being assessed. The primary question is whether or not such an assessment mechanism has been built into an Attesting Environment (or reasonably can be). 

The security-level criteria are 'unrestricted', 'restricted' (as defined by the FIDO spec), and 'hardware'. The 'unrestricted' level reasonably applies if the Attesting Environment can't surmise the hardening properties of the TE. It is likely to apply to at least some portion of the Attester if the entire Attester is attested. The Reference Value is likely to be 'unrestricted' given the reported value is supposed to be the weakest link security level. 

The FIDO spec 'restricted' list names various TEE technologies including TrustZone, SGX, TEEs with a GP protection profile (though certification to the profile doesn't appear to be a requirement?), virtualization technology, Windows10 virtualization technology (unclear if this means SW only or SW + HW), security co-processors, TPMs and Secure Elements. The other category is 'hardware' which EAT references TPM and Secure Elements. This seems like a problem since TPM and SE are in both the 'restricted' and the 'hardware' categories. Additionally, environments such as SGX, TrustZone, and some virtual environments are implemented using hardware, so it is unclear why these should not be categorized as 'hardware'. 

The TCG defines a TPM as an interface. This means a TPM could be implemented in software, firmware or hardware. Aside from the apparent contradiction that the FIDO restricted environments list includes TPM and Secure Elements, it isn't obvious how an Attesting Environment can be certain the hardening properties of the Target Environment with any confidence greater than 'unrestricted'. The EAT spec indicates that the weakest link determines the actual security level. Hence, if any part of the Attester is 'unrestricted' then the claim in Evidence should be set to unrestricted. Following this guidance, it seems a large majority of Attesters should report unrestricted in Evidence. 

Given EAT claims may also be supplied as Endorsements. The manufacturer might be better able to assess the properties of the Target Environments based on the manufacturing processes / people familiar with the environment. Hence, it is possible, for a given Target Environment, the security-level claim asserted as Endorsements will disagree with security-level claims asserted as Evidence.

This creates a scenario where the Endorsements security-level may be different from that of Reference Values/Evidence. The Verifier must decide how to proceed given apparent contradictory information. 

Possibly, given the FIDO context, the apparent contradictory conditions can be explained? But if so, would it make sense for FIDO to do so in the context of that group defining a security-level claim? 

-Ned

[1]"An Endorsement is a secure statement that some entity (e.g., a
   manufacturer) vouches for the integrity of the device's various
   capabilities such as claims collection, signing, launching code,
   transitioning to other environments, storing secrets, and more."

[2]"Reference Values used in appraisal procedures come from a Reference
   Value Provider and are then used by the Verifier to compare to
   Evidence."

[3]"An arbitrary execution environment may not, by default, be capable of
   Claims collection for a given Target Environment.  Execution
   environments that are designed specifically to be capable of Claims
   collection are referred to in this document as Attesting
   Environments."

On 6/4/22, 2:16 PM, "RATS on behalf of Laurence Lundblade" <[e-mail] on behalf of [e-mail]> wrote:

    This is a step back for framing for the security-level discussion.

    The fundamental purpose of an Endorsement is to tell the Verifier that they can believe what they get in Evidence. There may be some varying degree here from claim to claim and device to device, but the basic  principle always holds.

    Assuming for the sake or argument here that the Attester Manufacturer and Endorser are the same, it goes like this. The Endorser/AttesterManufacturer only puts private keys into devices that it knows are built correctly. They won’t lie. They’ll protect their keys. They produce correct claims. This really is the fundamental work of the Endorser/AttesterManufacturer above all else.

     For example, maker of a device with a TPM selects a good TPM and also carefully writes the boot code that does the measurement. They make sure that the devices that the TPM is soldered into always has the good boot code. Then they publish the public keys supplied with the TPM to the Verifier so it knows it can trust the measurements.

    In the TPM world, you can’t really have the Attester send much more than PCRs in Evidence, but in the non-TPM world, lots of stuff can go into Evidence.

    Tell me if you disagree with this!


    By all that, Evidence can be a parallel channel for the Endorser/AttesterManufacturer to convey claims to the Verifier.

    The Endorsement can mean “believe all the Evidence from this Attester”. (It might always not be all the Evidence, but it will always be some of the Evidence).

    By this it is entirely reasonable for security-level to be transmitted either as an Endorsement or in Evidence.


    I think there is also room for security-level in Evidence in composite device attestation. One Attester may have a good way to evaluate the security-level of a subsystem, perhaps a subsystem that varies from device to device.

    LL

    _______________________________________________
    RATS mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/rats