idnits 2.17.1 draft-tschofenig-rats-aiss-token-00.txt: -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 April 2022) is 727 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-12 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-15 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS H. Tschofenig 3 Internet-Draft Arm Limited 4 Intended status: Informational A. Kankaanpää 5 Expires: 24 October 2022 N. Bowler 6 Synopsys 7 T. Khandelwal 8 Arm Limited 9 22 April 2022 11 Automatic Integration of Secure Silicon (AISS) Attestation Token 12 draft-tschofenig-rats-aiss-token-00 14 Abstract 16 This specification defines a profile of the Entity Attestation Token 17 (EAT) for use in special System-on-Chip (SoC) designs that are 18 generated automatically utilizing a methodology currently developed 19 in a DARPA funded project. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 24 October 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 53 3. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.3. Implementation ID . . . . . . . . . . . . . . . . . . . . 4 57 3.4. Security Lifecycle . . . . . . . . . . . . . . . . . . . 5 58 3.5. Boot Odometer . . . . . . . . . . . . . . . . . . . . . . 6 59 3.6. Watermark . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.7. Profile Definition . . . . . . . . . . . . . . . . . . . 7 61 4. Token Encoding and Signing . . . . . . . . . . . . . . . . . 7 62 5. Freshness Model . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. Collated CDDL . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Verification . . . . . . . . . . . . . . . . . . . . . . . . 9 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 8.1. Claim Registration . . . . . . . . . . . . . . . . . . . 10 67 8.1.1. Security Lifecycle Claim . . . . . . . . . . . . . . 10 68 8.1.2. Implementation ID Claim . . . . . . . . . . . . . . . 10 69 8.1.3. Watermark Claim . . . . . . . . . . . . . . . . . . . 10 70 8.2. Media Type Registration . . . . . . . . . . . . . . . . . 11 71 8.3. CoAP Content-Formats Registration . . . . . . . . . . . . 12 72 8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 12 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 9.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 14 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 The DARPA-funded project Automated Implementation of Secure Silicon 83 (AISS) is aimed at making scalable on-chip security pervasive. The 84 objective is to develop ways to automate the process of adding 85 security into integrated circuits. 87 If successful, AISS will allow security to be inexpensively 88 incorporated into chip designs with minimal effort and expertise, 89 ultimately making scalable on-chip security ubiquitous. The project 90 seeks to create a novel, automated chip design flow that will allow 91 the security mechanisms to scale consistently with the goals of the 92 design. 94 As a minimal component, the generated chip designs must offer 95 attestation capabilities. 97 This specification describes the minimal claim set offered by an 98 attestation token conforming to the Entity Attestation Token (EAT) 99 specification. This attestation token is, on request, provided to a 100 Verifier. 102 2. Conventions and Definitions 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in 107 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 The following term is used in this document: 112 RoT Root of Trust, the minimal set of software, hardware and data 113 that has to be implicitly trusted in the platform - there is no 114 software or hardware at a deeper level that can verify that the 115 Root of Trust is authentic and unmodified. An example of RoT is 116 an initial bootloader in ROM, which contains cryptographic 117 functions and credentials, running on a specific hardware 118 platform. 120 3. Claims 122 This section describes the claims to be used in an AISS attestation 123 token. 125 CDDL [RFC8610] along with text descriptions is used to define each 126 claim independent of encoding. The following CDDL type(s) are reused 127 by different claims: 129 aiss-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 131 3.1. Nonce 133 The Nonce claim is used to carry the challenge provided by the caller 134 to demonstrate freshness of the generated token. 136 The EAT [I-D.ietf-rats-eat] nonce (claim key 10) is used. The 137 following constraints apply to the nonce-type: 139 * The length MUST be either 32, 48, or 64 bytes. 141 * Only a single nonce value is conveyed. Per [I-D.ietf-rats-eat] 142 the array notation is not used for encoding the nonce value. 144 This claim MUST be present in an AISS attestation token. 146 aiss-nonce = ( 147 nonce-label => aiss-hash-type 148 ) 150 3.2. Instance ID 152 The Instance ID claim represents the unique identifier of the 153 attestation key. 155 The EAT ueid (claim key 256) of type RAND is used. The following 156 constraints apply to the ueid-type: 158 * The length MUST be 17 bytes. 160 * The first byte MUST be 0x01 (RAND) followed by the 16-bytes random 161 value, which may be created by hashing the key identifier or may 162 be the key identifier itself. 164 This claim MUST be present in an AISS attestation token. 166 aiss-instance-id-type = bytes .size 33 168 aiss-instance-id = ( 169 ueid-label => aiss-instance-id-type 170 ) 172 3.3. Implementation ID 174 The Implementation ID claim uniquely identifies the implementation of 175 the immutable RoT. A verification service uses this claim to locate 176 the details of the RoT implementation from a manufacturer. Such 177 details are used by a verification service to determine the security 178 properties or certification status of the RoT implementation. 180 The value and format of the ID is decided by the manufacturer or a 181 particular certification scheme. For example, the ID could take the 182 form of a product serial number, database ID, or other appropriate 183 identifier. 185 This claim MUST be present in an AISS attestation token. 187 Note that this identifies the RoT implementation, not a particular 188 instance. The Instance ID claim, see Section 3.2, uniquely 189 identifies an instance. 191 aiss-implementation-id-type = bytes .size 32 193 aiss-implementation-id = ( 194 aiss-implementation-id-label => aiss-implementation-id-type 195 ) 197 3.4. Security Lifecycle 199 The Security Lifecycle claim represents the current lifecycle state 200 of the RoT. The state is represented by an unsigned integer. 202 The lifecycle states are illustrated in Figure 1. When the device is 203 deployed, a Verifier can only trust reports when the lifecycle state 204 is in "Secured" and "Non-RoT Debug" states. The states "Testing" and 205 "Provisioning" are utilized during manufacturing. A device is in 206 "Decommisioned" state when it is retired. 208 This claim MUST be present in an AISS attestation token. 210 .-------------. .-------------. 211 + Testing |-------> Provisioning | 212 '-------------' '------+------' 213 | .------------------. 214 | | | 215 v v | 216 .---------. | 217 .---------+ Secured +-----------. | 218 | '-+-------' | | 219 | | ^ | | 220 | v | v | 221 | .------------+------. .----------+----. 222 | | Non-RoT Debug | | Recoverable | 223 v '---------+---------' | RoT Debug | 224 .----------------. | '------+--------' 225 | Decommissioned |<-----------+-------------------' 226 '----------------' 228 Figure 1: Lifecycle States. 230 aiss-lifecycle-unknown-type = 0 231 aiss-lifecycle-testing-type = 1 232 aiss-lifecycle-provisioning-type = 2 233 aiss-lifecycle-secured-type = 3 234 aiss-lifecycle-non-rot-debug-type = 4 235 aiss-lifecycle-recoverable-rot-debug-type = 5 236 aiss-lifecycle-decommissioned-type = 6 238 aiss-lifecycle-type = 239 aiss-lifecycle-unknown-type / 240 aiss-lifecycle-testing-type / 241 aiss-lifecycle-provisioning-type / 242 aiss-lifecycle-secured-type / 243 aiss-lifecycle-non-rot-debug-type / 244 aiss-lifecycle-recoverable-rot-debug-type / 245 aiss-lifecycle-decommissioned-type 247 aiss-lifecycle = ( 248 aiss-lifecycle-label => aiss-lifecycle-type 249 ) 251 3.5. Boot Odometer 253 The Boot Odometer claim contains a value that represents the number 254 of times the entity or submod has been booted. 256 The EAT boot-seed-label (claim key TBD) of type unsigned integer is 257 used. 259 This claim MUST be present in an AISS attestation token. 261 aiss-boot-odometer = ( 262 aiss-boot-odometer-label => uint 263 ) 265 3.6. Watermark 267 Watermarking, the process of marking an asset with a known structure, 268 is used to detect intellectual property (IP) theft and overuse. 269 Watermarking in hardware IPs is the mechanism of embedding a unique 270 "code" into IP without altering the original functionality of the 271 design. The ownership of the IP can be later verified when the 272 watermark is extracted. 274 The Watermark claim contains a code extracted from the watermarking 275 hardware identified by an identifier. This identifier is formated as 276 a type 4 UUID [RFC4122]. 278 This claim MUST be present in an AISS attestation token when the 279 attestation token request asked for a watermark to be present. 281 watermark-type = [ 282 id: bstr .size 16, 283 watermark: bytes 284 ] 286 aiss-watermark = ( watermark-label => watermark-type ) 288 3.7. Profile Definition 290 The Profile Definition claim encodes the unique identifier that 291 corresponds to the EAT profile described by this document. This 292 allows a receiver to assign the intended semantics to the rest of the 293 claims found in the token. 295 The EAT profile (claim key 265) is used. The following constraints 296 apply to its type: 298 * The URI encoding MUST be used. 300 * The value MUST be http://aiss/1.0.0. 302 This claim MUST be present in an AISS attestation token. 304 aiss-profile-type = "http://aiss/1.0.0" 306 aiss-profile = ( 307 profile-label => aiss-profile-type 308 ) 310 4. Token Encoding and Signing 312 The AISS attestation token is encoded in CBOR [RFC8949] format. Only 313 definite-length string, arrays, and maps are allowed. 315 Cryptographic protection is accomplished by COSE. The signature 316 structure MUST be COSE_Sign1. Only the use of asymmetric key 317 algorithms is envisioned. 319 The CWT CBOR tag (61) is not used. An application that needs to 320 exchange PSA attestation tokens can wrap the serialised COSE_Sign1 in 321 a dedicated media type, as for example defined in defined in 322 Section 8.2 or the CoAP Content-Format defined in Section 8.3. 324 5. Freshness Model 326 The AISS attestation token supports the freshness models for 327 attestation Evidence based on nonces (Section 10.2 and 10.3 of 328 [I-D.ietf-rats-architecture]) using the nonce claim to convey the 329 nonce supplied by the Verifier. No further assumption on the 330 specific remote attestation protocol is made. 332 6. Collated CDDL 334 aiss-token = { 335 aiss-nonce, 336 aiss-instance-id, 337 aiss-profile, 338 aiss-implementation-id, 339 aiss-lifecycle, 340 aiss-boot-odometer, 341 aiss-watermark, 342 } 344 aiss-lifecycle-label = 2500 345 aiss-implementation-id-label = 2501 346 aiss-watermark-label = 2502 347 aiss-boot-odometer-label = 2503 349 ; from EAT 350 nonce-label = 10 351 ueid-label = 256 352 profile-label = 265 353 aiss-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 354 aiss-nonce = ( 355 nonce-label => aiss-hash-type 356 ) 357 aiss-instance-id-type = bytes .size 33 359 aiss-instance-id = ( 360 ueid-label => aiss-instance-id-type 361 ) 362 aiss-implementation-id-type = bytes .size 32 364 aiss-implementation-id = ( 365 aiss-implementation-id-label => aiss-implementation-id-type 366 ) 367 aiss-lifecycle-unknown-type = 0 368 aiss-lifecycle-testing-type = 1 369 aiss-lifecycle-provisioning-type = 2 370 aiss-lifecycle-secured-type = 3 371 aiss-lifecycle-non-rot-debug-type = 4 372 aiss-lifecycle-recoverable-rot-debug-type = 5 373 aiss-lifecycle-decommissioned-type = 6 375 aiss-lifecycle-type = 376 aiss-lifecycle-unknown-type / 377 aiss-lifecycle-testing-type / 378 aiss-lifecycle-provisioning-type / 379 aiss-lifecycle-secured-type / 380 aiss-lifecycle-non-rot-debug-type / 381 aiss-lifecycle-recoverable-rot-debug-type / 382 aiss-lifecycle-decommissioned-type 384 aiss-lifecycle = ( 385 aiss-lifecycle-label => aiss-lifecycle-type 386 ) 387 aiss-boot-odometer = ( 388 aiss-boot-odometer-label => uint 389 ) 391 watermark-type = [ 392 id: bstr .size 16, 393 watermark: bytes 394 ] 396 aiss-watermark = ( watermark-label => watermark-type ) 398 aiss-profile-type = "http://aiss/1.0.0" 400 aiss-profile = ( 401 profile-label => aiss-profile-type 402 ) 404 7. Verification 406 To verify the token, the primary need is to check correct encoding 407 and signing as detailed in Section 4. In particular, the Instance ID 408 claim is used (together with the kid in the COSE header, if present) 409 to assist in locating the public key used to verify the signature 410 covering the token. The key used for verification is supplied to the 411 Verifier by an authorized Endorser along with the corresponding 412 Attester's Instance ID. 414 In addition, the Verifier will typically operate a policy where 415 values of some of the claims in this profile can be compared to 416 reference values, registered with the Verifier for a given 417 deployment, in order to confirm that the device is endorsed by the 418 manufacturer supply chain. The policy may require that the relevant 419 claims must have a match to a registered reference value. 421 The protocol used to convey Endorsements and Reference Values to the 422 Verifier is not in scope for this document. 424 8. IANA Considerations 426 8.1. Claim Registration 428 This specification requests IANA to register the following claims in 429 the "CBOR Web Token (CWT) Claims" registry [IANA-CWT]. 431 8.1.1. Security Lifecycle Claim 433 * Claim Name: aiss-security-lifecycle 435 * Claim Description: AISS Security Lifecycle 437 * JWT Claim Name: N/A 439 * Claim Key: TBD (requested value: 2500) 441 * Claim Value Type(s): unsigned integer 443 * Change Controller: [[Authors of this RFC]] 445 * Specification Document(s): Section 3.4 of [[this RFC]] 447 8.1.2. Implementation ID Claim 449 * Claim Name: aiss-implementation-id 451 * Claim Description: AISS Implementation ID 453 * JWT Claim Name: N/A 455 * Claim Key: TBD (requested value: 2501) 457 * Claim Value Type(s): byte string 459 * Change Controller: [[Authors of this RFC]] 461 * Specification Document(s): Section 3.3 of [[this RFC]] 463 8.1.3. Watermark Claim 465 * Claim Name: aiss-watermark 467 * Claim Description: AISS Watermark 468 * JWT Claim Name: N/A 470 * Claim Key: TBD (requested value: 2502) 472 * Claim Value Type(s): byte string 474 * Change Controller: [[Authors of this RFC]] 476 * Specification Document(s): Section 3.6 of [[this RFC]] 478 8.2. Media Type Registration 480 IANA is requested to register the "application/aiss-attestation- 481 token" media type [RFC2046] in the "Media Types" registry 482 [IANA-MediaTypes] in the manner described in RFC 6838 [RFC6838], 483 which can be used to indicate that the content is an AISS Attestation 484 Token. 486 * Type name: application 488 * Subtype name: aiss-attestation-token 490 * Required parameters: n/a 492 * Optional parameters: n/a 494 * Encoding considerations: binary 496 * Security considerations: See the Security Considerations section 497 of [[this RFC]] 499 * Interoperability considerations: n/a 501 * Published specification: [[this RFC]] 503 * Applications that use this media type: Attesters and Relying 504 Parties sending AISS attestation tokens over HTTP(S), CoAP(S) and 505 other transports. 507 * Fragment identifier considerations: n/a 509 * Additional information: 511 - Magic number(s): n/a 513 - File extension(s): n/a 515 - Macintosh file type code(s): n/a 517 * Person & email address to contact for further information: Hannes 518 Tschofenig, Hannes.Tschofenig@arm.com 520 * Intended usage: COMMON 522 * Restrictions on usage: none 524 * Author: Hannes Tschofenig, Hannes.Tschofenig@arm.com 526 * Change controller: IESG 528 * Provisional registration? No 530 8.3. CoAP Content-Formats Registration 532 IANA is requested to register the CoAP Content-Format ID for the 533 "application/aiss-attestation-token" media type in the "CoAP Content- 534 Formats" registry [IANA-CoAP-Content-Formats]. 536 8.3.1. Registry Contents 538 * Media Type: application/aiss-attestation-token 540 * Encoding: - 542 * Id: [[To-be-assigned by IANA]] 544 * Reference: [[this RFC]] 546 9. References 548 9.1. Normative References 550 [I-D.ietf-rats-eat] 551 Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity 552 Attestation Token (EAT)", Work in Progress, Internet- 553 Draft, draft-ietf-rats-eat-12, 24 February 2022, 554 . 557 [IANA-CWT] IANA, "CBOR Web Token (CWT) Claims", 2022, 558 . 561 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 562 Extensions (MIME) Part Two: Media Types", RFC 2046, 563 DOI 10.17487/RFC2046, November 1996, 564 . 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, 568 DOI 10.17487/RFC2119, March 1997, 569 . 571 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 572 Unique IDentifier (UUID) URN Namespace", RFC 4122, 573 DOI 10.17487/RFC4122, July 2005, 574 . 576 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 577 Specifications and Registration Procedures", BCP 13, 578 RFC 6838, DOI 10.17487/RFC6838, January 2013, 579 . 581 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 582 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 583 May 2017, . 585 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 586 Definition Language (CDDL): A Notational Convention to 587 Express Concise Binary Object Representation (CBOR) and 588 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 589 June 2019, . 591 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 592 Representation (CBOR)", STD 94, RFC 8949, 593 DOI 10.17487/RFC8949, December 2020, 594 . 596 9.2. Informative References 598 [I-D.ietf-rats-architecture] 599 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 600 W. Pan, "Remote Attestation Procedures Architecture", Work 601 in Progress, Internet-Draft, draft-ietf-rats-architecture- 602 15, 8 February 2022, . 605 [IANA-CoAP-Content-Formats] 606 IANA, "CoAP Content-Formats", 2022, 607 . 609 [IANA-MediaTypes] 610 IANA, "Media Types", 2022, 611 . 613 Appendix A. Example 615 The following example shows an AISS attestation token for an 616 hypothetical system. The attesting device is in a lifecycle state 617 Section 3.4 of SECURED. 619 The claims in this example are: 621 { 622 / instance-id / 255: h'FF0039A1', 623 / nonce / 10: h'AABBCCDD', 624 / lifecycle / 2500: 2, 625 / implementation-id / 2501: h'CCDDEE', 626 / watermark / 2502: h'010203', 627 / boot-odometer / 2503: 5, 628 / profile-id / 256: "aiss/1.0.0", 629 } 631 The resulting COSE object is: 633 18( 634 [ 635 / protected / h'A10126', 636 / unprotected / {}, 637 / payload / h'A718FF44FF0039A10A44AABBCCDD1909C4021901006 638 A616973732F312E302E301909C543CCDDEE1909C643 639 0102031909C705', 640 / signature / h'9744085E05D875E5EAAEC1598D1DD9E14097CCE4E9A 641 484344D08C9D41244713C700CD4F1CD7E86C0C6397A 642 ABECE40E166EBA5AA92DB11170F69B2DD8E681708E' 643 ] 644 ) 646 Acknowledgments 648 We would like to thank Rob Aitken, Mike Borza, Liam Dillon, Dale 649 Donchin, John Goodenough, and Oleg Raikhman for their feedback. 651 Work on this document has in part been supported by the DARPA AISS 652 project (grant agreement HR0011-20-9-0043). 654 Authors' Addresses 656 Hannes Tschofenig 657 Arm Limited 658 Email: Hannes.Tschofenig@arm.com 659 Arto Kankaanpää 660 Synopsys 661 Email: arto.kankaanpaa@synopsys.com 663 Nick Bowler 664 Synopsys 665 Email: nick.bowler@synopsys.com 667 Tushar Khandelwal 668 Arm Limited 669 Email: Tushar.Khandelwal@arm.com