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

[Laurence Lundblade <[e-mail]>]

> 
> On Jun 7, 2022, at 11:09 PM, Henk Birkholz <[e-mail]> wrote:
> 
> Hi Laurence,
> 
> okay just fore representative purposes, I am doing this once now. Please don't be mad with me :-)
> 
> What are attestations?

Hi Henk, here’s a hierarchy of levels of attestation depth:

1) Device Identity
The RP knows who made the device and maybe a few basic characteristics such as the model and version. This involves only two parties, the Attester Manufacturer and the Relying Party. The RP gets the public key for verification from the Attester Manufacturer. The RP is mostly on their own to decide if the device is trustworthy.

2) Device Identity and Configuration
Now the RP gets configuration information such as whether debug is enabled, SW versions and maybe even measurements. It’s still just a two-party set up with the Attester Manufacturer and Relying Party. The Relying Party is getting the reference values from the Attester Manufacturer and verifying against Evidence themselves. The Relying Party decides if they go ahead with the transaction if the SW or configuration is out of date.

3) Device Identity and Configuration Verified by the Attester Manufacturer
Now the Attester Manufacturer is running a Verification service. The RP gets Attestation Results that may be a summary and may include a recommendation from the Attester Manufacturer as to whether to trust the device. There are still only two parties involved. I would call this self-assessment, same as 1) and 2) because there is no separate organization cross-checking what the Attester Manufacturer is evaluating about the device.

4) Device Identity and Configuration Verified by a 3rd Party
Now the Verification is being run by a 3rd party that is neither the RP or the Attester Manufacturer. The RP gets Attestation Results from a trusted 3rd party. This is where attestation is clearly not self-assessment, because there are three separate parties involved and the Attester Manufacturer can’t just do what they want.

5) Device Identity and Configuration Verified by a 3rd Party plus Certification
This is the ultimate system with four parties. The 4th party is the certification issuer. This might be FIPS, GlobalPlatform, FIDO or Common Criteria based programs. Certification is above and beyond checking SW versions, measurements and vulnerabilities databases provided by the 3rd party. Certification gives deep review and threat analysis of the architecture and implementation of the Attester. 

I think there are a few other variations that make sense, but they don’t fall neatly into this monotonically increasing hierarchy so I haven’t written them out. In particular, there might be certification, but no independent 3rd party running a RATS verification.

I think all of these are attestation. The minimum for attestation is a device cryptographically proving its identity with the verification key being obtained from some place other than the device.

I am interested in how a definition of “believable” (a very subjective word) aligns with this hierarchy.

LL


An alternate definition of attestation could be: “an IETF process where Henk and Laurence have long discussions that are often annoying and occasionally entertaining." :-) :-)


> 
> On 06.06.22 21:44, Laurence Lundblade wrote:
>> I’m using this thread to comment on the general issue of claims in endorsements vs attestations even though some of that discussion is in the other thread.
>> It’s right that attestations should not be signed by the same key as endorsements:
>> - The type of exposure to attack of the two signing keys are very different
>> - They have very different deployment, operational and life-cycle characteristics
>> I don’t know what the Endorsement standard will look like, but agree that going for a unified Endorsment/Attesation design now is a leap we’re not ready for. But, I don’t think we need that to progress the issue at hand.
>> That said, I stand by my comment (quoted far below) that data items can get from the Endorser/AttesterManufacturer to the Verifier either through 1) an Endorsement protocol/token or 2) by being embedded in the Attester at time of manufacture as a static claim.
>> Restating as three paths:
>>    1a) Signed Endorsement transmitted B2B perhaps secured by TLS
>>    1b) Independently signed Endorsement embedded in the Attester that
>>    the Attester conveys to the Verifier along with the Evidence
>>    2) A static claim in Evidence
>> I don’t think we’re ready to design an Endorsement token/protocol here and now so no further discussion on 1a) or 1b).
>> Think about these static Attestation claims set by the Attester Manufacturer:
>>    OEMID: Set once at manufacturer time and never changes; it is the
>>    same for large numbers of devices
>>    UEID: Set once at manufacturing and never changes; it is different
>>    for each device
>>    HW Version and Mode: Set once at manufacturing time and never
>>    changes; large groups have the same ID
>> We’re fine with these being set and sent as claims. They don’t have to be in an Endorsement, right? Some of them could be in an Endorsement, but there is nothing wrong with them in Evidence.
>> Of course if they are sent in Evidence, then there has to be an Endorsement that tells the Verifier they can believe these claims in Evidence and the signature on Evidence has to be verified.
>> To me security-level (the static statement of designed security level; see here <https://mailarchive.ietf.org/arch/browse/rats/?qdr=d <https://mailarchive.ietf.org/arch/browse/rats/?qdr=d>>) is pretty much the same as the above claims in the way it is conveyed securely.
>> What ever the outcome for security-level is, I think getting to common understanding of how claims are secured relative to Endorsements is critical to Rats.
>> LL
>>> Begin forwarded message:
>>> 
>>> *From: *"Eric Voit \(evoit\)" <evoit=[e-mail] <mailto:evoit=[e-mail]> <mailto:evoit=[e-mail] <mailto:evoit=[e-mail]>>>
>>> *Subject: **Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat> <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat>>)*
>>> *Date: *June 6, 2022 at 11:05:43 AM PDT
>>> *To: *Giridhar Mandyam <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>, "[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>>> 
>>> I am not suggesting any changes to the charter.   I am trying to help
>>> articulate an Endorsed security-level claim capable of transiting an
>>> Attester.  And that it is possible to verify this transit has happened
>>> without modification.   To me this falls under the RATS charter item [6]
>>> which says: "Standardize interoperable data formats to securely declare and
>>> convey endorsements and reference values."
>>> 
>>> I believe endorsements need to signed with a private key not found in the
>>> Attester.  And I believe any endorsements transiting the Attester need to be
>>> passed through to the Verifier and/or Relying Party with this signature
>>> intact.
>>> 
>>> This is why I proposed requirements (1) & (2) below.  These requirements can
>>> be met using a single properly constructed x5chain or an x5bag.
>>> 
>>> Eric
>>> On Jun 6, 2022, at 9:44 AM, Henk Birkholz <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>> 
>>> Hi Laurence,
>>> 
>>> On 04.06.22 23:16, Laurence Lundblade wrote:
>>>> 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.
>>> 
>>> Well, actually I'd say that is a subset of what Endorsements are about. The few components in a Attester that you cannot produce Evidence about need Endorsements instead.
>>> 
>>> If an Attester does not know that is painted green, then that is a Claim about the Attester that has to come from the outside, has to be endorsed trusted third party (and here we go traditional... manufacturer, owner, etc.), because the Attester would never know that (only in weird cases, that is not the point) on its own devices.
>>> 
>>> On 05.06.22 21:34, Michael Richardson wrote:
>>>> So, it is*NEVER*  useful as Evidence.  EVER.
>>> 
>>> As the Attester can at the very best "cache" or "carry" an Endorsement put there during manufacturing, I think I have to agree with Michael here. Please note, in order to be useful and believable, the Endorsement is not signed by the Attester, but the Endorser! With key material not available to the Attester.
>>> 
>>> Viele Grüße,
>>> 
>>> Henk
>>> On Jun 4, 2022, at 2:16 PM, Laurence Lundblade <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[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] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>