Re: [EAT] [Rats] Implicit vs Explicit Attestation (was Re: Scope, Goals & Background for RATS)

"Smith, Ned" <ned.smith@intel.com> Mon, 24 September 2018 23:20 UTC

Return-Path: <ned.smith@intel.com>
X-Original-To: eat@ietfa.amsl.com
Delivered-To: eat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CB813116A; Mon, 24 Sep 2018 16:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T49kfSEA14aL; Mon, 24 Sep 2018 16:20:07 -0700 (PDT)
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C986130E60; Mon, 24 Sep 2018 16:20:07 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Sep 2018 16:20:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.54,299,1534834800"; d="scan'208,217";a="266350991"
Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga006.fm.intel.com with ESMTP; 24 Sep 2018 16:20:04 -0700
Received: from orsmsx112.amr.corp.intel.com (10.22.240.13) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 24 Sep 2018 16:20:04 -0700
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.251]) by ORSMSX112.amr.corp.intel.com ([169.254.3.23]) with mapi id 14.03.0319.002; Mon, 24 Sep 2018 16:20:04 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: "Wheeler, David M" <david.m.wheeler@intel.com>, Laurence Lundblade <lgl@island-resort.com>, "Fuchs, Andreas" <andreas.fuchs@sit.fraunhofer.de>
CC: "rats@ietf.org" <rats@ietf.org>, Denis <denis.ietf@free.fr>, "Birkholz, Henk" <henk.birkholz@sit.fraunhofer.de>, "eat@ietf.org" <eat@ietf.org>
Thread-Topic: [Rats] [EAT] Implicit vs Explicit Attestation (was Re: Scope, Goals & Background for RATS)
Thread-Index: AQHUVFUdyqoLepXrsUm/iJg/N6AIJqUAEY+A
Date: Mon, 24 Sep 2018 23:20:03 +0000
Message-ID: <AA0DA18B-F00B-4C6D-8467-C50CA996DFE7@intel.com>
References: <710df01c-c45f-9d26-b578-e4baa53c6de8@sit.fraunhofer.de> <b3aa7b71-a80a-78fc-aef7-fc9145a3169b@free.fr> <17ba2709-0a0e-859f-2fa2-fd09747273d9@sit.fraunhofer.de> <67234e9e-1543-5ecb-7fd8-3797d529744c@free.fr> <7E4B881E-7AD6-42A1-B2B3-7478DFCCB9FB@island-resort.com> <b941c49a-c860-e15d-b6ce-91739c168eeb@sit.fraunhofer.de> <11B80224-BD02-44BF-B2C9-068377A4BD8B@island-resort.com> <9F48E1A823B03B4790B7E6E69430724D014264CC53@exch2010c.sit.fraunhofer.de> <CC7AA480-4988-414C-B48C-6249F78582A0@island-resort.com> <0627F5240443D2498FAA65332EE46C843B69BE59@CRSMSX102.amr.corp.intel.com>
In-Reply-To: <0627F5240443D2498FAA65332EE46C843B69BE59@CRSMSX102.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.2.180910
x-originating-ip: [10.251.2.63]
Content-Type: multipart/alternative; boundary="_000_AA0DA18BF00B4C6D8467C50CA996DFE7intelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/lb0n9_DMVRiU_6FOlopYKo3MZNA>
Subject: Re: [EAT] [Rats] Implicit vs Explicit Attestation (was Re: Scope, Goals & Background for RATS)
X-BeenThere: eat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <eat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eat>, <mailto:eat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eat/>
List-Post: <mailto:eat@ietf.org>
List-Help: <mailto:eat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eat>, <mailto:eat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Sep 2018 23:20:14 -0000

It is important to understand the semantics of different types of attestation because when we get to defining tokens, the token semantics should correspond to the security state(s) of the computing context (aka Mr. Enclave) and whether or not the claimant (aka Mr. Signer) is authoritatively able to know the claimed security states are actually true.

That said, it appears there isn’t a well-established definition of ‘implicit attestation’ and we’re in a position of having to describe parts of an elephant.

One more part of the elephant of implicit attestation can exist when a VMM or OS is loaded according to a trusted boot scenario using TPM PCRs to explicitly capture VMM/OS measurements. The VMM/OS then creates keys, loads software and otherwise creates an environment that isn’t measured into PCRs. This environment isn’t directly attested by the TPM quoting key. But nevertheless [By extension, it could only be created by the VMM/OS, however; and so if the environment code can be trusted (via evidence of the attestation), “appropriate security policy decisions can be made regarding the attached data.”]

A further extrapolation of the elephant part: if keys created in the implicitly attested environment are created following a DICE-inspired convention where a hash of the VMM/OS code is used to seed the key gen function, then it can be asserted that the implicitly attested application using that key would not have access to said key unless the hash value again matched. Use of that key also implicitly attests the data it has signed.

If the subtlety of attestation semantics are important and need explicit representation in a CWT or JWT token. Then some sort of token that distinguishes the type of attestation is needed in addition to a token that asserts, for example, a location attribute.  It may be good enough to define attestation claims structure as a collection of tokens. Then if appropriate, the a token identifying the type of attestation can accompany any other tokens needed.

Jumping into solution space for clarity: Inside tokens may be signed (by claimants) and the collection is signed by the attester.

-Ned

On 9/24/18, 3:22 PM, "RATS on behalf of Wheeler, David M" <rats-bounces@ietf.org<mailto:rats-bounces@ietf.org> on behalf of david.m.wheeler@intel.com<mailto:david.m.wheeler@intel.com>> wrote:

One thing I think we should discuss is the claimant versus the attestor. I say this in the context of SGX Attestation.
In SGX, the Quoting Enclave signs the attestation, which is attesting to the code running in the enclave matches the attached hash (Mr.Enclave) and its signature was verified by a particular signing key (Mr.Signer).

The attestation signature cover an included a hash – this hash is of an accompanying structure created by the enclave code.

The attestor in this case is the Quoting Enclave. And the attestation is that the code is actually running inside an SGX enclave.

The accompanying structure could have GPS coordinates, another public key, a blockchain transaction, etc.
But it was created by the enclave code, and NOT DIRECTLY attested by the signature.
By extension, it could only be created by the enclave, however, and so if the enclave code can be trusted (via evidence of the attestation), “appropriate security policy decisions can be made regarding the attached data.”

I believe this is in line with Andreas’ comment on implicit attestation.
The enclave attributes (Mr.Enclave & Mr.Signer, along with other attributes of the system, like microcode version, patches, etc.) are Explicitly attested by the signature.
The other things added by the enclave code are implicitly attested.

I think it is important for EAT to have these two different structures in the token (in some form), because I believe you cannot have an Implicit Attestation without some (perhaps small) Explicit Attestation.
And thus, we should be talking about (within EAT) the concept of Claimant and Attestor.

Thoughts?

-- Dave Wheeler


From: EAT [mailto:eat-bounces@ietf.org] On Behalf Of Laurence Lundblade
Sent: Monday, September 24, 2018 3:06 PM
To: Fuchs, Andreas <andreas.fuchs@sit.fraunhofer.de>
Cc: rats@ietf.org; Denis <denis.ietf@free.fr>fr>; Birkholz, Henk <henk.birkholz@sit.fraunhofer.de>de>; eat@ietf.org
Subject: Re: [EAT] [Rats] Implicit vs Explicit Attestation (was Re: Scope, Goals & Background for RATS)

That’s super clear. Thanks! A few comments:

In EAT, many claims are dynamic and vary over time. For example GPS location can be a claim. The public key of a newly created key pair stored in a (Android) Key Store can be a claim. Obviously these can only be carried using explicit attestation. (Also, by my understanding it is hard to get a TPM to sign such things).

EAT is more focused on standardizing bits-on-the-wire and their meaning rather than the device architecture implementing it and particularly the way the keys are securely stored and managed. For example, EAT is mostly mum about TPM vs DICE. I’ve been using IEEE DeviceID as an example of a scheme built on an X.509 hierarchy as viewed from the wire. Perhaps that is somewhat incorrect since it is oriented to a particular device key storage architecture. When EAT uses X.509, the bits-on-the-wire shouldn’t really reflect if the keys were stored in a DICE, TPM, TrustZone or an eSE.

I’m curious if RATS is interested involving device side architectures, or is just interested in bits-on-the wire?  Maybe IETF should just do bits-on-the-wire, leaving the device architectures to TCG and IEEE?

LL







On Sep 24, 2018, at 1:37 AM, Fuchs, Andreas <andreas.fuchs@sit.fraunhofer.de<mailto:andreas.fuchs@sit.fraunhofer.de>> wrote:

Hi Laurence,

the distinction between explicite and implicite (in the TC(G) community) is a different one:

- Explicite Attestation is where an Attestation Claim (or statement of properties) is represented as a data structure and signed (e.g. by the TPM). Thus the verifier will verify that the signature originates from the device's shielded reporting component (e.g. a TPM) and will consume the Claims / properties.

- Implicite Attestation is where only a nonce is signed (by the TPM or in DICE). The verifier however knows (e.g. by a Certificate) that the private key for this signature can only be used if certain Attestation Claims (certain properties) are fulfilled. In case of a TPM-based implicite attestation this may be certain PCRs (those that the explicite attestation just signs and transfers) have a certain value. In case of DICE the key for implicite attestation is derived from the currently running software, thus knowledge of the key (and thus usage) is restricted to the trusted software configuration of the device.

I hope this makes the division into implicite vs explicite a little better understandable from a taxonomic view.

Regarding IEEE Device ID: This is first and foremost a authentication method. If however the DeviceID was extended such that the access to its private key was restricted e.g. by a TPM to a certain software configuration and this was described in an extension of the DevID certificate, then this would be implicite attestation.

Let me know if this makes sense to you or let's discuss this a little further.

Best regards,
Andreas


________________________________
From: RATS [rats-bounces@ietf.org<mailto:rats-bounces@ietf.org>] on behalf of Laurence Lundblade [lgl@island-resort.com<mailto:lgl@island-resort.com>]
Sent: Monday, September 24, 2018 02:05
To: Birkholz, Henk
Cc: rats@ietf.org<mailto:rats@ietf.org>; Denis; eat@ietf.org<mailto:eat@ietf.org>
Subject: Re: [Rats] [EAT] Implicit vs Explicit Attestation (was Re: Scope, Goals & Background for RATS)
From the TCG paper<https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf>  it looks to me that implicit refers to use of a deterministic process for creating an attestation key and device ID from a seed (the UDS) rather than explicitly putting an attestation private key and X.509 certificate (e.g., IEEE Device ID) in each device. That is a fine thing to do. No objection to that.

By inference, then I’d guess that IEEE Device ID is an example of explicit attestation.

From an attestation taxonomic view, I don’t think we can divide into implicit vs explicit.  There are many more variants such as EPID, other variants of ECDAA, other ways to set pub key crypto and IDs, attestation based on symmetric keys and so on. I haven’t read enough TCG documents to know for sure, but I doubt that the TCG taxonomy is sufficient to cover all of them.

EAT’s approach to this is to just say that tokens are signed using the COSE format (and probably JOSE too) and to focus on the definition of claims with the idea that the claims can be used with lots of different ways of signing and attestation key set up. This seems like clear achievable work.

I think it is OK to work on standardization of the attestation key and signing set up. We will probably need several such efforts as one size definitely won’t fit all.

So I propose we replace the internal / external intro sentence and bullets with this:

There are many ways to provision / store / derive / establish the key material used by the Attester to digitally sign claims that are transmitted to the Verifier. These might include EPID, some variant of ECDAA, IEEE DeviceID, TC Implicit Identity Based Device Attestation, other public key based schemes and schemes using symmetric keys. They might also include a privacy proxy or privacy CA.

The standardization of claims is to be largely independent of these different ways. Any such way of setting up this key material must be able to secure claims expressed in CBOR or JSON directly or indirectly (e.g., a hash of the claims).

The WG may choose to standardize some of the ways to provision / store / derive / establish the key material.

I know the last sentence is a bit wishy washy for a charter. Personally, I was interested in punting that work until EAT is done and there is more operational experience and practice. If there’s a few specific scheme we want to go after, maybe we do that. One or two might be TCG/TPM oriented. Another that works for Android Key Store and FIDO attestation.

LL






On Sep 21, 2018, at 8:44 AM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>> wrote:

Hello Laurence,

please find replies and comments in-line (and sorry for replying in the wrong order...).


On 09/20/2018 11:29 PM, Laurence Lundblade wrote:


Forking the discussion here to focus on implicit/explicit attestation. That seems to be a new term invented in this WG Charter as I haven’t seen it elsewhere. I’m not sure what it means yet. It seems to have something to do with how the loop is closed in the Attestation Model below. In particular the role of the Entity Manufacturer.

The term "explicit attestation" wrt to remote attestation is actually "new" in a sense that "implicit attestation" got a sharper focus and is now used in open documents. In consequence, specializing "explicit" attestation next to implicit attestation (wrt to remote attestation) was the smallest and most intuitive semantic step - terminology-wise.

Google'ing for (implicit) attestation protocols, I found these TCG documents.
The first one uses "implicit attestation" for "strong Device Identity" (same approach as the EAT). The second one is 7 years older and (to my surprise, actually), defines both Attestation and - in fact- Attestation Evidence. I have to admit that we have not taken these definition into account, but will in the next iteration. There does not seem to be a conflict. Also, the semantic equivalent to RIMM seems to be Template Reference Manifest in the second document.
> https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation-v1-rev93.pdf> https://www.trustedcomputinggroup.org/wp-content/uploads/IFM_PTS_v1_0_r28.pdf




The obvious way to do this (kind of like TLS certs, but flipped):
- The Entity Manufacturer puts a private key + X.509 certificate in each Entity (device) it makes
- This Entity (device) X.509 certificate is signed by the Entity Manufactures Root Key
- The Entity uses its private key to sign some Claims
- The Entity sends the signed claims and its X.509 cert to the Relying Party
- The Relying Party gets the Entity Manufacturers Root Cert in a one time operation and saves it
- The Relying Party chains the device X.509 per to the Entity Root Cert
- The Relying Party uses the public key in the device X.509 to verify the signature on the Claims

This is, in essence, _the_ reference work-flow of implicit attestation, I think. Please note that here the signatures are verified (which is the implicitness) in contrast to appraising the signed (temper-evident, amongst other characteristics) claim sets via reference values (which an Verifier is capable to do wrt explicit attestation).



One of my guesses for what implicit attestation is — The RP (Relying Party) does not get any root keys or such from the Entity Manufacturer or a CA or a trusted third party. They verify the signature solely based on what is in the signed token they received. The RP probably did send a nonce and the Entity signed it, so there is proof-of-posession of the Entity's key, but that key and device could be any device so little is proved. The RP can remember the Entity’s key and expect it to be the same next time to give it some value. This is called self-attestation of surrogate attestation in FIDO. It not considered very secure. The loop is not closed.

I assume that the key remembered by the Relying Party is a public key - inside the x.509? Very likely it is not the private key you did the proof-of-possession for. In any case, please see above wrt implicit attestation.

I am not sure what to make of "verify the signature solely based
on what is in the signed token they received" - I assume that is different from verifying the signature, as the RP did not get anything from the corresponding CA?

I am also assuming that the "RP can expect the same key again" via the accompanying x.509 and therefore can infer characteristics on how the claims should be composed (again)?

As the current (wordy) charter text illustrates proof-of-possession is the basis for implicit attestation and in that regard I think we are actually in alignment here.



Another one of my guesses — The RP does get key material with which to perform verification, but it is not directly from the Entity Manufacturer. Instead there is some CA or trusted 3rd party in the loop. This is a realistic scenario. The loop is closed so it is secure.

This is a work-flow that I would very much like to flesh out, homogenize and include more... explicitly :)



I see this as a topic for technical discussion, not something for definite in the charter.

Well, apparently we are under the impression of... yes and no. In order to get goals/deliverables and scope right we have to agree on what term has which technical meanings, implications and dependencies. Assuming that background and terminology could be pruned from the charter at some point of consensus and then be... and that is my problem here... maintained without changing their meaning (and therefore not implicitly changing the charter).
Carsten highlighted the problems with that approach, so while these definitions may go down to a technical level, they are essential to the meaning of the charter. It is a bit of a hen & egg problem, I am afraid, due to the terminology document (evolving into an architecture document) being in flux.

Viele Grüße,

Henk



LL


On Sep 18, 2018, at 8:56 AM, Denis <denis.ietf@free.fr<mailto:denis.ietf@free.fr> <mailto:denis.ietf@free.fr>> wrote:

Hi Henk,

I fear that we don't understand each other.



Hi Denis,

there are a lot of topics addressed by your reply. First of all, thank you for the the feedback!

We attempted to create a document that is as inclusive as possible - within reason. Hence, it is also solution agnostic.

As Andreas just said, Proof-of-Possession of a secret key is intended to be captured by Implicit Attestation. In other words:
if you are able to use that secret key to sign something, it implies (that is the "implicitness" here) that "that device has some well known properties".

No. If you are able to use a secret key to sign something, it does not mean that you are using a device.
If a device is able to sign something, it does not necessarily mean that what is signed really comes from the device, unless "that device has some well known properties".



The definition of implicit attestation might require some improvement, I assume (and I don't mean by adding even more words).

I am a bit confused by the use of "attestation certificate", "private key" and "origin of data exchange" in your reply.

If "certificate" in your proposal:



"shared attestation certificates" to designate attestation certificates that are specific to a batch of devices from the same model (like in FIDO),
"individual attestation certificates" to designate attestation certificates that are specific to each device.

means identity document, the concepts of "Singular Identity", "Shared Identity", and "Group Identity" are already subsumed in the IETF by the definition of "Identity" in RFC4949.
Maybe that fact is a little bit too hidden at the end of the Background section that refers to "cryptographic identities". Highlighting that more up front and referencing RFC4949
explicitly could address that issue.

It does not mean anything from the above list. My arguments have nothing to do with "Identity". Typically, an Attestation Certificate it is an X509 certificate, as in FIDO.




Correspondingly, the same secret key can be enrolled on multiple devices, but that is not the same thing as enrolling the same (group/shared) identity document on multiple devices.

The private key of a device is never enrolled but is placed in the device by the manufacturer of the device (or the entity that personalizes it before making it available to an end-user);




The smallest identity document I can think of would be a signed public key. More commonly today, it would be an ASN.1-based identity document, I assume.

My arguments are fully unrelated to "identity documents".



Jumping a bit to the end:

Local Attestation is described in the Background section and is referred to again in the Scope section as out-of-scope.

This is fine.



That said, as Local Attestation can be a prerequisite for Remote Attestation and it also might require some provisioning (via network protocols) in order to work,
provisioning protocols that enable local attestation are currently considered in-scope.

The fact that the definition of Attestation Evidence is difficult to understand could be the biggest issue here, I think. Especially, because it is the basis for
the definition of Remote Attestation, as you highlighted. I will come back to this topic as soon as I have a few more free cycles :)

Viele Grüße,

Henk
...

_______________________________________________
EAT mailing list
EAT@ietf.org<mailto:EAT@ietf.org>
https://www.ietf.org/mailman/listinfo/eat