Direct Anonymous Attestation for the Remote Attestation Procedures Architecture
draft-birkholz-rats-daa-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Henk Birkholz , Christopher Newton , Liqun Chen | ||
| Last updated | 2021-04-25 | ||
| Replaced by | draft-ietf-rats-daa | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-birkholz-rats-daa-00
RATS Working Group H. Birkholz
Internet-Draft Fraunhofer SIT
Intended status: Informational C. Newton
Expires: 28 October 2021 L. Chen
University of Surrey
26 April 2021
Direct Anonymous Attestation for the Remote Attestation Procedures
Architecture
draft-birkholz-rats-daa-00
Abstract
This document maps the concept of Direct Anonymous Attestation (DAA)
to the Remote Attestation Procedures (RATS) Architecture. The role
DAA Issuer is introduced and its interactions with existing RATS
roles is specified.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 October 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Birkholz, et al. Expires 28 October 2021 [Page 1]
Internet-Draft DAA for RATS April 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Direct Anonymous Attestation . . . . . . . . . . . . . . . . 3
4. DAA changes to the RATS Architecture . . . . . . . . . . . . 5
5. Additions to Remote Attestation principles . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Remote ATtestation procedureS (RATS, [I-D.ietf-rats-architecture])
describe interactions between well-defined architectural constituents
in support of Relying Parties that require an understanding about the
trustworthiness of a remote peer. The identity of an Attester and
its corresponding Attesting Environments play a vital role in RATS.
A common way to refer to such an identity is the Authentication
Secret ID as defined in the Reference Interaction Models for RATS
[I-D.ietf-rats-reference-interaction-models]. The fact that every
Attesting Environment can be uniquely identified in the context of
the RATS architecture is not suitable for every application of remote
attestation. Additional issues may arise when Personally
identifiable information (PII) -- whether obfuscated or in clear text
-- are included in attestation Evidence or even corresponding
Attestation Results. This document illustrates how Direct Anonymous
Attestation (DAA) can mitigate the issue of uniquely
(re-)identifiable Attesting Environments. To accomplish that goal, a
new RATS role -- the DAA Issuer -- is introduced and its duties as
well as its interactions with other RATS roles are specified.
Birkholz, et al. Expires 28 October 2021 [Page 2]
Internet-Draft DAA for RATS April 2021
2. Terminology
This document uses the following set of terms, roles, and concepts as
defined in [I-D.ietf-rats-architecture]: Attester, Verifier, Relying
Party, Conceptual Message, Evidence, Attestation Result, Attesting
Environment. The role of Endorser, also defined in
[I-D.ietf-rats-architecture], needs to be adapted and details are
given below.
Additionally, this document uses and adapts, as necessary, the
following concepts and information elements as defined in
[I-D.ietf-rats-reference-interaction-models]: Attester Identity,
Authentication Secret, Authentication Secret ID
A PKIX Certificate is an X.509v3 format certificate as specified by
[RFC5280].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Direct Anonymous Attestation
Figure 1 shows the data flows between the different RATS roles
involved in DAA.
Birkholz, et al. Expires 28 October 2021 [Page 3]
Internet-Draft DAA for RATS April 2021
************ ************* ************ *****************
* Endorser * * Reference * * Verifier * * Relying Party *
************ * Value * * Owner * * Owner *
| * Provider * ************ *****************
| ************* | |
| | | |
|Endorsements |Reference |Appraisal |Appraisal
| |Values |Policy |Policy for
| | |for |Attestation
| | |Evidence |Results
V | | |
.-----------------. | | |
| DAA Issuer |---------. | | |
'-----------------' | | | |
^ | Group| | | |
| | Public| | | |
|Credential| Key| | | |
|Request | v v v |
| | .----------------------. |
| | .->| Verifier |--. |
| | | '----------------------' | |
| | | | |
| | |Evidence Attestation| |
| | | Results| |
| | | | |
| |Credential| | |
| | | | |
| v | v v
| .-------------. .---------------.
'--------| Attester | | Relying Party |
'-------------' '---------------'
Figure 1: DAA data flows
DAA [DAA] is a signature scheme that allows the privacy of users that
are associated with an Attester (e.g. its owner) to be maintained.
Essentially, DAA can be seen as a group signature scheme with the
feature that given a DAA signature no-one can find out who the signer
is, i.e., the anonymity is not revocable. To be able to sign
anonymously, an Attester has to obtain a credential from a DAA
Issuer. The DAA Issuer uses a private/public key pair to generate
credentials for a group of Attesters and makes the public key (in the
form of a public key certificate) available to the verifier in order
to enable them to validate the Evidence received.
In order to support these DAA signatures, the DAA Issuer MUST
associate a single key pair with a group of Attesters and use the
same key pair when creating the credentials for all of the Attesters
Birkholz, et al. Expires 28 October 2021 [Page 4]
Internet-Draft DAA for RATS April 2021
in this group. The DAA Issuer's group public key certificate
replaces the individual Attester Identity documents during
authenticity validation as a part of the appraisal of Evidence
conducted by a verifier. This is in contrast to intuition that there
has to be a unique Attester Identity per device.
For DAA, the role of the Endorser is essentially the same, but they
now provide Attester endorsement documents to the DAA Issuer rather
than directly to the verifier. These Attester endorsement documents
enable the Attester to obtain a credential from the DAA Issuer.
4. DAA changes to the RATS Architecture
In order to enable the use of DAA, a new conceptual message, the
Credential Request, is defined and a new role, the DAA Issuer role,
is added to the roles defined in the RATS Architecture.
Credential Request: An Attester sends a Credential Request to the
DAA Issuer to obtain a credential. This request contains
information about the DAA key that the Attester will use to create
evidence and together with Attester endorsement information that
is provided by the Endorser to confirm that the request came from
a valid Attester.
DAA Issuer: A RATS role that offers zero-knowledge proofs based on
public-key certificates used for a group of Attesters (Group
Public Keys) [DAA]. How this group of Attesters is defined is not
specified here, but the group must be large enough for the
necessary anonymity to be assured.
Effectively, these certificates share the semantics of Endorsements,
with the following exceptions:
* Upon receiving a Credential Request from an Attester, the
associated group private key is used by the DAA Issuer to provide
the Attester with a credential that it can use to convince the
Verifier that its Evidence is valid. To keep their anonymity the
Attester randomizes this credential each time that it is used.
Although the DAA Issuer knows the Attester Identity and can
associate this with the credential issued, randomisation ensures
that the Attester's identity cannot be revealed to anyone,
including the Issuer.
* The Verifier can use the DAA Issuer's group public key
certificate, together with the randomized credential from the
Attester, to confirm that the Evidence comes from a valid Attester
without revealing the Attester's identity.
Birkholz, et al. Expires 28 October 2021 [Page 5]
Internet-Draft DAA for RATS April 2021
* A credential is conveyed from a DAA Issuer to an Attester in
combination with the conveyance of the group public key
certificate from DAA Issuer to Verifier.
5. Additions to Remote Attestation principles
In order to ensure an appropriate conveyance of Evidence via
interaction models in general, the following prerequisite considering
Attester Identity MUST be in place to support the implementation of
interaction models.
Attestation Evidence Authenticity: Attestation Evidence MUST be
correct and authentic.
In order to provide proofs of authenticity, Attestation Evidence
SHOULD be cryptographically associated with an identity document
that is a randomised DAA credential.
The following information elements define extensions for
corresponding information elements defined in
[I-D.ietf-rats-reference-interaction-models] and that are vital to
all types of reference interaction models. Varying from solution to
solution, generic information elements can be either included in the
scope of protocol messages (instantiating Conceptual Messages defined
by the RATS architecture) or can be included in additional protocol
parameters of protocols that facilitate the conveyance of RATS
Conceptual Messages. Ultimately, the following information elements
are required by any kind of scalable remote attestation procedure
using DAA with one of RATS's reference interaction models.
Attester Identity ('attesterIdentity'): _mandatory_
In DAA, the Attester's identity is not revealed to the verifier.
The Attester is issued with a credential by the DAA Issuer that is
randomised and then used to anonymously confirm the validity of
their evidence. The evidence is verified using the DAA Issuer's
group public key.
Authentication Secret IDs ('authSecID'): _mandatory_
In DAA, Authentication Secret IDs are represented by the DAA
Issuer's group public key that MUST be used to create DAA
credentials for the corresponding Authentication Secrets used to
protect Evidence.
In DAA, an Authentication Secret ID does not identify a unique
Birkholz, et al. Expires 28 October 2021 [Page 6]
Internet-Draft DAA for RATS April 2021
Attesting Environment but is associated with a group of Attesting
Environments. This is because an Attesting Environment should not
be distinguishable and the DAA credential which represents the
Attesting Environment is randomised each time it used.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
[DAA] Brickell, E., Camenisch, J., and L. Chen, "Direct
Anonymous Attestation", page 132-145, ACM Proceedings of
the 11rd ACM conference on Computer and Communications
Security, 2004.
[I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", Work
in Progress, Internet-Draft, draft-ietf-rats-architecture-
12, 23 April 2021, <https://www.ietf.org/archive/id/draft-
ietf-rats-architecture-12.txt>.
[I-D.ietf-rats-reference-interaction-models]
Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference
Interaction Models for Remote Attestation Procedures",
Work in Progress, Internet-Draft, draft-ietf-rats-
reference-interaction-models-02, 25 April 2021,
<https://www.ietf.org/archive/id/draft-ietf-rats-
reference-interaction-models-02.txt>.
Authors' Addresses
Birkholz, et al. Expires 28 October 2021 [Page 7]
Internet-Draft DAA for RATS April 2021
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@sit.fraunhofer.de
Christopher Newton
University of Surrey
Email: cn0016@surrey.ac.uk
Liqun Chen
University of Surrey
Email: liqun.chen@surrey.ac.uk
Birkholz, et al. Expires 28 October 2021 [Page 8]