Subject: [Rats] Out-of-band key material set up in architecture document

From: Laurence Lundblade <[email-masked]>
Date: Tue, 5 Nov 2019 12:17:12 -0800

An issue I have with both the current architecture documents is that they do not discuss the need for some out of band key material set up to make verification work.

The manufacturer of the device must put some private key into each device so that the device can sign attestation evidence. Most likely the manufacturer also creates the verifying key material, but they may or may not be the verifier.  If they are not the verifier, somehow the verifier of attestation evidence must have corresponding key material to verify the signature.

This paragraph could be a start of the text. I think this is a critical part of the architecture because attestation doesn’t work without it. 

I do NOT want to specify any details for how this happens in the architecture doc. It needs to stay at a high level. It stays at a high level in other places. For example it discusses claims, but doesn’t defined individual claims.

I think there’s a large parallel with HTTPS. HTTPS wouldn’t work without some out-of-band distribution of certs/keys for verification.

Just like with HTTPS, there are a lot of different business models, protocols and end-end systems that this out-of-band set can be done. Here’s a few that are real today and publicly described:

- Intel EPID (no X.509, the ECDAA algorithm, a service run exclusively by Intel for Intel chips for fee)
- Android Attestation (buckets of keys distributed to phone makers, X.509, a verification service run exclusively by Google)
- FIDO Metadata service (a 3rd party doing X.509 certificate distribution for many FIDO vendors)

I also know of some that are not publicly described that do not use X.509, some even using symmetric key material.

I think business models will drive architecture in some cases. I also think the cost of putting keys into chips and devices is a another driver. A third driver is big IoT back-end service providers like Amazon and Google.

I mention all these only illustrate the variety and thus the futility of trying to come up with one standard way.

However, I think to help the world get their heads around how attestation works; leaving this out of the architecture would be leaving a critical part out.

LL

---

From: Dave Thaler <[email-masked]>
Date: Tue, 5 Nov 2019 23:40:58 +0000

Inline below…

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Tuesday, November 5, 2019 12:17 PM
To: [email-masked]
Subject: [Rats] Out-of-band key material set up in architecture document

I agree that a private key is needed in each device for attestation to work (at least using any techniques
I’m aware of). Saying “the manufacturer must put it there”, is however I think too narrow, as it implies the
manufacturer actually knows the key. In some arguably more secure designs, the device itself creates the
key pair and the manufacturer per se never knows the private key, only the public key, so it would be
confusing to say the manufacturer “put” it there, or that the “manufacturer creates” the key material.

As you say below, we want the arch doc to stay at a high level and not over-specify details like whether the
manufacturer creates a key and installs it on a device, vs the device creating a key pair and the manufacturer
extracting the public (but not private) key from the device.   In my view, those are both fine to mention as
helpful examples, but not to constrain it to one case or the other.

Furthermore, the RATS charter does not constrain attestation to only *hardware* based roots of trust.
There are some cases where it may be in a hypervisor or bios or firmware or whatever, and only attest
things above that, with obviously a weaker level of security than hardware-rooted attestation.   But any
protocol mechanisms should still work (mainly because it’s almost impossible to rule them out except via
a security policy that says which keys to trust), even if it’s not the primary focus we care most about.  The
point here being that in such a case it may not be the “manufacturer”, but may be another entity.  That’s
actually true in some cases even for hardware-based roots of trust.

As for your comment “somehow the verifier of attestation evidence must have corresponding key material
to verify the signature”, that’s true.  My text has a section on Trust Model that covers this at a high level,
without explaining the key material (and I get your point that it should), saying:

Ø  The Verifier trusts (or more specifically, the Verifier's security

Ø  policy is written in a way that configures the Verifier to trust) a

Ø  manufacturer, or the manufacturer's hardware, so as to be able to

Ø  evaluate the health of that manufacturer's devices.  In solutions

Ø  with weaker security, a Verifier might be configured to implicitly

Ø  trust firmware or even software (e.g., a hypervisor).

In order to trust something in a protocol sense, we require the ability to cryptographically verify
that trust using key material.   I agree with your point that that should be stated explicitly.

Thanks for raising this,
Dave

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 6 Nov 2019 08:58:20 -0800

> On Nov 5, 2019, at 3:40 PM, Dave Thaler <[email-masked]> wrote:
> 
> Inline below…
>  
> From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Laurence Lundblade
> To: [email-masked] <mailto:[email-masked]>

We could say “establish the signing key”? Certainly don’t want to exclude those more secure designs.

> ...

Yes, the “manufacturer” could be a SW vendor or even the author of a dumb Android app. We need a much broader term or description.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 6 Nov 2019 18:14:06 +0100

Hi Dave,
hi list,

the scope of the architecture was discussed a lot. It is okay to provide 
a bigger picture here, as the "phasing approach" will allow to talk 
about the attestation provisioning flows later on. Ben accompanied that 
decision process and I think he might be able to restate that :)

I think we are all in wild agreement here wrt to:

> "the manufacturer must put it there”, is however I think too narrow

We do not have to be prescriptive about any things here anyways, but to 
be descriptive or illustrative is very helpful.

In this quite prominent scenario:

> In some arguably more secure designs, the device itself creates the key pair and the manufacturer per se never knows the private key, only the public key,

the manufacturer provisioned something that made this happen (and 
therefore took measures to render the public key meaningful).

Viele Grüße,

Henk

On 06.11.19 17:58, Laurence Lundblade wrote:
> 
> 
>> On Nov 5, 2019, at 3:40 PM, Dave Thaler <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Inline below…
>> *From:*RATS <[email-masked] <mailto:[email-masked]>>*On 
>> Behalf Of*Laurence Lundblade
>> *Sent:*Tuesday, November 5, 2019 12:17 PM
>> *To:[email-masked] <mailto:[email-masked]>
>> *Subject:*[Rats] Out-of-band key material set up in architecture document
>> An issue I have with both the current architecture documents is that 
>> they do not discuss the need for some out of band key material set up 
>> to make verification work.
>>
>>     The manufacturer of the device must put some private key into each
>>     device so that the device can sign attestation evidence. Most
>>     likely the manufacturer also creates the verifying key material,
>>     but they may or may not be the verifier.  If they are not the
>>     verifier, somehow the verifier of attestation evidence must have
>>     corresponding key material to verify the signature.
>>
>> This paragraph could be a start of the text. I think this is a 
>> critical part of the architecture because attestation doesn’t work 
>> without it.
>> Furthermore, the RATS charter does not constrain attestation to only 
>> **hardware** based roots of trust.
> Yes, the “manufacturer” could be a SW vendor or even the author of a 
> dumb Android app. We need a much broader term or description.
> 
> LL
> 
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Guy Fedorkow <[email-masked]>
Date: Wed, 6 Nov 2019 18:53:03 +0000

Hi Dave,
  I agree that some kind of key is essential to attestation.  
  I don't want to make a statement of RATS architecture, but the RIV draft calls for the use of a manufacturer-installed DevID credential.  In the TPM world, the key corresponding to the DevID would be generated inside the TPM, so no one would have access to it (assuming you trust your TPM vendor!).
  /guy

Juniper Business Use Only

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Henk Birkholz
Sent: Wednesday, November 6, 2019 12:14 PM
To: Laurence Lundblade <[email-masked]>; Dave Thaler <[email-masked]>
Cc: [email-masked]; Benjamin Kaduk <[email-masked]>
Subject: Re: [Rats] Out-of-band key material set up in architecture document

Hi Dave,
hi list,

the scope of the architecture was discussed a lot. It is okay to provide a bigger picture here, as the "phasing approach" will allow to talk about the attestation provisioning flows later on. Ben accompanied that decision process and I think he might be able to restate that :)

> "the manufacturer must put it there”, is however I think too narrow

We do not have to be prescriptive about any things here anyways, but to be descriptive or illustrative is very helpful.

In this quite prominent scenario:

> In some arguably more secure designs, the device itself creates the 
> key pair and the manufacturer per se never knows the private key, only 
> the public key,

the manufacturer provisioned something that made this happen (and therefore took measures to render the public key meaningful).

Viele Grüße,

Henk

On 06.11.19 17:58, Laurence Lundblade wrote:
>> *Sent:*Tuesday, November 5, 2019 12:17 PM *To:[email-masked] 
>> <mailto:[email-masked]> *Subject:*[Rats] Out-of-band key material set 
>> up in architecture document An issue I have with both the current 
>> architecture documents is that they do not discuss the need for some 
>> out of band key material set up to make verification work.
>>
>> I agree that a private key is needed in each device for attestation 
>> to work (at least using any techniques I’m aware of). Saying “the 
>> manufacturer must put it there”, is however I think too narrow, as it 
>> implies the manufacturer actually knows the key. In some arguably 
>> more secure designs, the device itself creates the key pair and the 
>> manufacturer per se never knows the private key, only the public key, 
>> so it would be confusing to say the manufacturer “put” it there, or 
>> that the “manufacturer creates” the key material.
> 
>> There are some cases where it may be in a hypervisor or bios or 
>> firmware or whatever, and only attest things above that, with 
>> obviously a weaker level of security than hardware-rooted 
>> attestation.   But any protocol mechanisms should still work (mainly 
>> because it’s almost impossible to rule them out except via a security 
>> policy that says which keys to trust), even if it’s not the primary 
>> focus we care most about.  The point here being that in such a case 
>> it may not be the “manufacturer”, but may be another entity.  That’s 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/rats
> __;!8WoA6RjC81c!S7VupAZvpNNzm2WeDBek0LrW0vg400DQtY0GLzx8gtgBlX_gBhek44
> nCPoX8OEZiLLs$
> 

_______________________________________________
RATS mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/rats__;!8WoA6RjC81c!S7VupAZvpNNzm2WeDBek0LrW0vg400DQtY0GLzx8gtgBlX_gBhek44nCPoX8OEZiLLs$