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

[Dave Thaler <[e-mail]>]

Inline below…

From: RATS <[e-mail]> On Behalf Of Laurence Lundblade
Sent: Tuesday, November 5, 2019 12:17 PM
To: [e-mail]
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.

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

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