Subject: Re: [Rats] Dealing with Attestation Roots

From: Anders Rundgren <[email-masked]>
Date: Tue, 21 Apr 2020 14:58:45 +0200

Any takers out there?
I could consider writing an I-D.
/Anders

On 2020-02-27 18:51, Anders Rundgren wrote:
> Hi List,
> In the https://cyberphone.github.io/openbankingwallet project the idea was to use attestations.  The most recent version of the Android app indeed supports this as well.
> 
> In an ideal world the root would be provided by Google.  However, since we don't live in an ideal world there are vendors out there who do not follow that "recipe".
> 
> For W3C's PaymentRequest API a simpler solution is used which do not match attestations but is better than nothing.  This scheme builds on publishing a manifest associated with the app.  Here is my particular manifest:  https://mobilepki.org/w3cpay/method
> 
> But I still would like to use attestations and also not being tied to browsers.
> 
> What about making attestations optionally contain a URL to the root like https://huawei.com/teeroot ?
> Since the number of vendors in finite and the Web-PKI is in a fairly good shape these days, this could serve as a workaround for those who don't have any number of cycles to spend on installing arbitrary tee root certificates.  That is, a verifier's "trust registry" would simply hold host names like "huawei.com", "sony.com", "samsung.com", etc.
> 
> If there is a better method, I'm all ears!
> 
> thanx,
> Anders
>

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 22 Apr 2020 07:38:26 -0700

Hi Anders,

> On Feb 27, 2020, at 9:51 AM, Anders Rundgren <[email-masked]> wrote:
> 
> Hi List,
> In an ideal world the root would be provided by Google.  However, since we don't live in an ideal world there are vendors out there who do not follow that "recipe”.

Are you referring to Android N Key Attestation that is implemented in the key store?

> What about making attestations optionally contain a URL to the root like https://huawei.com/teeroot ?

I don’t know what https://huawei.com/teeroot  is. I can’t get anything from this URL.

I’m guessing you are after an X.509 root certificate, one that is used for Android-style attestation. Is that right?

LL

> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 22 Apr 2020 16:54:57 +0200

> Hi Anders,

Hi Laurence,
Thank you for responding!

> Are you referring to Android N Key Attestation that is implemented in the key store?

This is indeed one possible usage.
https://developer.android.com/training/articles/security-key-attestation

> I don’t know what https://huawei.com/teeroot  is. I can’t get anything from this URL.

That's correct, I don't even know where to find Huawei's attestation root which is how I came to this idea :)

> I’m guessing you are after an X.509 root certificate, one that is used for Android-style attestation. Is that right?

Right.  Is using an X.509 root certificate an unusual way of dealing with attestation verification?

Anders

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 23 Apr 2020 12:20:57 -0700

Hi Anders,

I think using an X.509 hierarchy with EAT is a fine thing to do, but no one’s done it yet. The two EAT implementations I know of, use other means to find the verification key. One by key ID, another by a combination of claims inside the attestation.

Android’s solution is not standard, it is just used by Android AFAIK.

I think it would be fine to write a draft that says how to use X.509 with EAT. It would involve https://tools.ietf.org/html/draft-ietf-cose-x509-06 and maybe the URL you’ve suggested for finding the root. Would even be interested in adding this functionality to ctoken <https://github.com/laurencelundblade/ctoken>. 

Technically speaking, this is all about endorsements and relates to recent email threads on that subject here.

LL

> On Apr 22, 2020, at 7:54 AM, Anders Rundgren <[email-masked]> wrote:
>

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 24 Apr 2020 05:31:57 +0200

> Hi Anders,
Hi Laurence;

> I think using an X.509 hierarchy with EAT is a fine thing to do, but no one’s done it yet. 

I see it more like a workaround in the absence of a standard.  Using CWTs is a better solution.

The two EAT implementations I know of, use other means to find the verification key. One by key ID, another by a combination of claims inside the attestation.

Somewhere there must be a trust anchor or a trusted public key, right? How do you locate it expressed in practical terms?  This is the only thing the "Web PKI + Vendor URL" proposal was meant to addresses.  For those who have doubts about automated retrieval of trust anchors based on vendor-specific host names, the scheme can also aid manual installation of such.

The proposal is neutral with respect to key hierarchy.  A flat or multi-level (as in Android) scheme would be dealt with in the same way.

Anders

>> On Apr 22, 2020, at 7:54 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>> On Feb 27, 2020, at 9:51 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>> Hi List,

---

From: Eliot Lear <[email-masked]>
Date: Fri, 24 Apr 2020 09:16:04 +0200

Hiya

> On 24 Apr 2020, at 05:31, Anders Rundgren <[email-masked]> wrote:
> 
> Somewhere there must be a trust anchor or a trusted public key, right? How do you locate it expressed in practical terms?  

Yeah, “combination of claims inside the attestation”?  Isn’t that a self-assertion?

Eliot

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 26 Apr 2020 12:25:55 -0700

> On Apr 23, 2020, at 8:31 PM, Anders Rundgren <[email-masked]> wrote:
> 

Android uses X.509 both for the attestation token and to chain up from a root to a verification key. Agreed that the X.509 for the attestation token is not preferred as a standard. I wasn’t suggesting that. I was suggesting that X.509 is used WITH CWT/EAT to chain up from a root to a verification key per https://tools.ietf.org/html/draft-ietf-cose-x509-06 <https://tools.ietf.org/html/draft-ietf-cose-x509-06>. I think I’m agreeing with you.

> The proposal is neutral with respect to key hierarchy.  A flat or multi-level (as in Android) scheme would be dealt with in the same way.

Yes, I generally I agree with you on all this.

Though I think there are other ways than an X.509 root certificate and a URL for it to find a verification key. 

I think we should have an IETF RATS draft that says how to use X.509 roots and hierarchies plus a URI with EAT/CWT.

LL

>> I think it would be fine to write a draft that says how to use X.509 with EAT. It would involve https://tools.ietf.org/html/draft-ietf-cose-x509-06 <https://tools.ietf.org/html/draft-ietf-cose-x509-06> and maybe the URL you’ve suggested for finding the root. Would even be interested in adding this functionality to ctoken <https://github.com/laurencelundblade/ctoken <https://github.com/laurencelundblade/ctoken>>.
>>> On Apr 22, 2020, at 7:54 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>>>> On Feb 27, 2020, at 9:51 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>> 
>>>>> Hi List,
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 26 Apr 2020 12:35:28 -0700

> On Apr 24, 2020, at 12:16 AM, Eliot Lear <lear=[email-masked]> wrote:
> 
> Hiya
> 
>> On 24 Apr 2020, at 05:31, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>> 

By “claims inside the attestation” I don’t mean self-assertion. You use the claims inside the attestation to find the key. For example you use OEM ID to find the OEM of the device, then you use the UEID to find the specific key. Yes, you are using claims that are unverified to find the key, but that is OK. If you get the wrong key, nothing works anyway. COSE’s key id is unprotected.

Personally, I prefer to use the COSE kid or https://tools.ietf.org/html/draft-ietf-cose-x509-06 <https://tools.ietf.org/html/draft-ietf-cose-x509-06> because it keeps the SW stack cleaner, but there’s nothing insecure about using claims inside the attestation to look up the verification key. 

LL