1page.title=Key Attestation 2page.metaDescription=New support in Android N for verifying security properties of hardware-backed keys. 3page.keywords="android N", "security", "TEE", "hardware-backed", "keystore", "certificate", "key attestation" 4 5@jd:body 6 7<div id="qv-wrapper"> 8 <div id="qv"> 9 <h2>In this document</h2> 10 <ol> 11 <li><a href="#verifying">Retrieving and Verifying a Hardware-backed Key Pair</a></li> 12 <li><a href="#certificate_schema">Certificate Extension Data Schema</a></li> 13 </ol> 14 </div> 15</div> 16 17<p> 18 Key Attestation gives you more confidence that the keys you use in your app 19 are stored in a device's hardware-backed keystore. The following sections 20 describe how to verify the properties of hardware-backed keys and how to 21 interpret the schema of the attestation certificate's extension data. 22</p> 23 24<h2 id="verifying"> 25 Retrieving and Verifying a Hardware-backed Key Pair 26</h2> 27 28<p> 29 During key attestation, you specify the alias of a key pair. The attestation 30 tool, in return, provides a certificate chain, which you can use to verify 31 the properties of that key pair. 32</p> 33 34<p> 35 The root certificate within this chain is signed using an attestation key, 36 which the device manufacturer injects into the device’s hardware-backed 37 keystore at the factory. 38</p> 39 40<p class="note"> 41 <strong>Note:</strong> On devices that ship with Android N and Google Play 42 services, the root certificate is issued by Google. You should verify that 43 this root certificate appears within Google’s list of root certificates. 44</p> 45 46<p> 47 To implement key attestation, complete the following steps: 48</p> 49 50<ol> 51 <li> 52 Use a {@link java.security.KeyStore KeyStore} object's 53 {@link java.security.KeyStore#getCertificateChain getCertificateChain()} 54 method to get a reference to the chain of X.509 certificates associated with 55 the hardware-backed keystore. 56 </li> 57 58 <li> 59 <p> 60 Check each certificate’s validity using a 61 {@link java.security.cert.CRL CRL} object's 62 {@link java.security.cert.CRL#isRevoked isRevoked()} method. 63 </p> 64 65 <p class="caution"> 66 <strong>Caution:</strong> Although you can complete this process within 67 your app directly, it’s safer to check the certificates’ revocation lists 68 on a separate server that you trust. 69 </p> 70 </li> 71 72 <li> 73 <p> 74 Create an <code>Attestation</code> object, passing in the first element of 75 the certificate chain as an argument:</p> 76 77<pre> 78// "certificates" contains the certificate chain associated with a specific key 79// pair in the device's hardware-backed keystore. 80X509Certificate attestationCert = (X509Certificate) certificates[0]; 81Attestation hardwareKeyAttestation = new Attestation(attestationCert); 82</pre> 83 84 <p> 85 An attestation object extracts the extension data within this certificate 86 and stores this information in a more accessible format. For more details 87 about the schema of the extension data, see <a href= 88 "#certificate_schema">Certificate Extension Data Schema</a>. 89 </p> 90 </li> 91 92 <li> 93 <p> 94 Use the accessor methods within the <code>Attestation</code> class to 95 retrieve the extension data from the certificate. These methods use the 96 same names and structure hierarchy as in the certificate extension data 97 schema. 98 </p> 99 100 <p> 101 For example, to view the verified boot key for the device’s TEE, use the 102 following method sequence: 103 </p> 104 105<pre> 106// "hardwareKeyAttestation" contains the first element of the attestation 107// certificate chain. 108AuthorizationList teeAuthList = hardwareKeyAttestation.getTeeEnforced(); 109RootOfTrust teeRootOfTrust = teeAuthList.getRootOfTrust(); 110byte[] teeVerifiedBootKey = teeRootOfTrust.getVerifiedBootKey(); 111</pre> 112 113 </li> 114 115 <li> 116 <p> 117 Compare the extension data from the <code>Attestation</code> object with 118 the set of values that you expect the hardware-backed key to contain. 119 </p> 120 121 <p class="caution"> 122 <strong>Caution:</strong> Although you can complete this process within 123 your app directly, it’s safer to check the certificate’s extension data 124 on a separate server that you trust. 125 </p> 126 </li> 127</ol> 128 129<h2 id="certificate_schema"> 130 Certificate Extension Data Schema 131</h2> 132 133<p> 134 Key attestation verifies the extension data that appears in the first 135 certificate within the chain in a device’s hardware-backed keystore. The 136 certificate stores the information according to the following ASN.1 schema: 137</p> 138 139<pre class="no-pretty-print"> 140KeyDescription ::= SEQUENCE { 141 attestationVersion INTEGER, 142 attestationSecurityLevel SecurityLevel, 143 keymasterVersion INTEGER, 144 keymasterSecurityLevel SecurityLevel, 145 attestationChallenge OCTET_STRING, 146 <var>reserved OCTET_STRING</var>, 147 softwareEnforced AuthorizationList, 148 teeEnforced AuthorizationList, 149} 150 151SecurityLevel ::= ENUMERATED { 152 Software (0), 153 TrustedEnvironment (1), 154} 155 156AuthorizationList ::= SEQUENCE { 157 purpose [1] EXPLICIT SET OF INTEGER OPTIONAL, 158 algorithm [2] EXPLICIT INTEGER OPTIONAL, 159 keySize [3] EXPLICIT INTEGER OPTIONAL, 160 digest [5] EXPLICIT SET OF INTEGER OPTIONAL, 161 padding [6] EXPLICIT SET OF INTEGER OPTIONAL, 162 ecCurve [10] EXPLICIT INTEGER OPTIONAL, 163 rsaPublicExponent [200] EXPLICIT INTEGER OPTIONAL, 164 activeDateTime [400] EXPLICIT INTEGER OPTIONAL, 165 originationExpireDateTime [401] EXPLICIT INTEGER OPTIONAL, 166 usageExpireDateTime [402] EXPLICIT INTEGER OPTIONAL, 167 noAuthRequired [503] EXPLICIT NULL OPTIONAL, 168 userAuthType [504] EXPLICIT INTEGER OPTIONAL, 169 authTimeout [505] EXPLICIT INTEGER OPTIONAL, 170 allowWhileOnBody [506] EXPLICIT NULL OPTIONAL, 171 allApplications [600] EXPLICIT NULL OPTIONAL, 172 applicationId [601] EXPLICIT OCTET_STRING OPTIONAL, 173 creationDateTime [701] EXPLICIT INTEGER OPTIONAL, 174 origin [702] EXPLICIT INTEGER OPTIONAL, 175 rollbackResistant [703] EXPLICIT NULL OPTIONAL, 176 rootOfTrust [704] EXPLICIT RootOfTrust OPTIONAL, 177 osVersion [705] EXPLICIT INTEGER OPTIONAL, 178 osPatchLevel [706] EXPLICIT INTEGER OPTIONAL, 179 attestationChallenge [708] EXPLICIT INTEGER OPTIONAL, 180 attestationApplicationId [709] EXPLICIT OCTET_STRING OPTIONAL, 181} 182 183RootOfTrust ::= SEQUENCE { 184 verifiedBootKey OCTET_STRING, 185 deviceLocked BOOLEAN, 186 verifiedBootState VerifiedBootState, 187} 188 189VerifiedBootState ::= ENUMERATED { 190 Verified (0), 191 SelfSigned (1), 192 Unverified (2), 193 Failed (3), 194} 195</pre> 196 197<p> 198 The following list presents a description of each element within the schema: 199</p> 200 201<h3 id="certificate_schema_keydescription"> 202 KeyDescription 203</h3> 204 205<p> 206 This sequence of values presents general information about the key pair being 207 verified through key attestation and provides easy access to additional 208 details. 209</p> 210 211<dl> 212 <dt> 213 <code>attestationVersion</code> 214 </dt> 215 216 <dd> 217 The version of the key attestation feature. Should be set to 1. 218 </dd> 219 220 <dt> 221 <code>attestationSecurity</code> 222 </dt> 223 224 <dd> 225 <p> 226 The <a href="#certificate_schema_securitylevel">security 227 level</a> of the attestation. 228 </p> 229 230 <p class="note"> 231 <strong>Note:</strong> Although it is possible to attest keys that are 232 stored in the Android system—that is, if the 233 <code>attestationSecurity</code> value is set to Software—you 234 cannot trust these attestations if the Android system becomes compromised. 235 </p> 236 </dd> 237 238 <dt> 239 <code>keymasterVersion</code> 240 </dt> 241 242 <dd> 243 The version of the Keymaster hardware abstraction layer (HAL). Use 0 to 244 represent version 0.2 or 0.3, 1 to represent version 1.0, and 2 to represent 245 version 2.0. 246 </dd> 247 248 <dt> 249 <code>keymasterSecurity</code> 250 </dt> 251 252 <dd> 253 The <a href="#certificate_schema_securitylevel">security 254 level</a> of the Keymaster implementation. 255 </dd> 256 257 <dt> 258 <code>attestationChallenge</code> 259 </dt> 260 261 <dd> 262 The challenge string associated with a key pair that is verified using key 263 attestation. 264 </dd> 265 266 <dt> 267 <code><var>reserved</var></code> 268 </dt> 269 270 <dd> 271 Only system apps use this value. In all other apps, this value is empty. 272 </dd> 273 274 <dt> 275 <code>softwareEnforced</code> 276 </dt> 277 278 <dd> 279 Optional. The Keymaster <a href= 280 "#certificate_schema_authorizationlist">authorization 281 list</a> that is enforced by the Android system, not by the device’s TEE. 282 </dd> 283 284 <dt> 285 <code>teeEnforced</code> 286 </dt> 287 288 <dd> 289 Optional. The Keymaster <a href= 290 "#certificate_schema_authorizationlist">authorization 291 list</a> that is enforced by the device’s TEE. 292 </dd> 293</dl> 294 295<h3 id="certificate_schema_securitylevel"> 296 SecurityLevel 297</h3> 298 299<p> 300 This data structure indicates the extent to which a software feature, such as 301 a key pair, is protected based on its location within the device. 302</p> 303 304<p> 305 Because the data structure is an enumeration, it takes on exactly one of the 306 following values: 307</p> 308 309<dl> 310 <dt> 311 Software 312 </dt> 313 314 <dd> 315 The logic for creating and managing the feature is implemented in the 316 Android system. For the purposes of creating and storing key pairs, this 317 location is less secure than the TEE but is more secure than your app's 318 process space. 319 </dd> 320 321 <dt> 322 TrustedEnvironment 323 </dt> 324 325 <dd> 326 The logic for creating and managing the feature is implemented in secure 327 hardware, such as a TEE. For the purposes of creating and storing key pairs, 328 this location is more secure because secure hardware is highly resistant to 329 remote compromise. 330 </dd> 331</dl> 332 333<h3 id="certificate_schema_authorizationlist"> 334 AuthorizationList 335</h3> 336 337<p> 338 This data structure contains the key pair’s properties themselves, as defined 339 in the Keymaster hardware abstraction layer (HAL). You compare these values 340 to the device’s current state or to a set of expected values to verify that a 341 key pair is still valid for use in your app. 342</p> 343 344<p> 345 Each field name corresponds to a similarly-named Keymaster tag. For example, 346 the <code>keySize</code> field in an authorization list corresponds to the 347 <code>KM_TAG_KEY_SIZE</code> Keymaster tag. 348</p> 349 350<p> 351 Each field in the following list is optional: 352</p> 353 354<dl> 355 <dt> 356 <code>purpose</code> 357 </dt> 358 359 <dd> 360 Corresponds to the <code><a href= 361 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_purpose"> 362 KM_TAG_PURPOSE</a></code> Keymaster tag, which uses a tag ID value of 1. 363 </dd> 364 365 <dt> 366 <code>algorithm</code> 367 </dt> 368 369 <dd> 370 <p> 371 Corresponds to the <code><a href= 372 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_algorithm"> 373 KM_TAG_ALGORITHM</a></code> Keymaster tag, which uses a tag ID value of 374 2. 375 </p> 376 377 <p> 378 When an <code>AuthorizationList</code> object is associated with key 379 attestation, this value is always <code>KM_ALGORITHM_RSA</code> or 380 <code>KM_ALGORITHM_EC</code>. 381 </p> 382 </dd> 383 384 <dt> 385 <code>keySize</code> 386 </dt> 387 388 <dd> 389 Corresponds to the <code><a href= 390 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_key_size"> 391 KM_TAG_KEY_SIZE</a></code> Keymaster tag, which uses a tag ID value of 3. 392 </dd> 393 394 <dt> 395 <code>digest</code> 396 </dt> 397 398 <dd> 399 Corresponds to the <code><a href= 400 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_digest"> 401 KM_TAG_DIGEST</a></code> Keymaster tag, which uses a tag ID value of 5. 402 </dd> 403 404 <dt> 405 <code>padding</code> 406 </dt> 407 408 <dd> 409 Corresponds to the <code><a href= 410 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_padding"> 411 KM_TAG_PADDING</a></code> Keymaster tag, which uses a tag ID value of 6. 412 </dd> 413 414 <dt> 415 <code>ecCurve</code> 416 </dt> 417 418 <dd> 419 <p> 420 Corresponds to the <code>KM_TAG_EC_CURVE</code> Keymaster tag, which uses 421 a tag ID value of 10. 422 </p> 423 424 <p> 425 The set of parameters used to generate an elliptic curve (EC) key pair, 426 which uses ECDSA for signing and verification, within the Android system 427 keystore. 428 </p> 429 </dd> 430 431 <dt> 432 <code>rsaPublicExponent</code> 433 </dt> 434 435 <dd> 436 Corresponds to the <code><a href= 437 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_rsa_public_exponent"> 438 KM_TAG_RSA_PUBLIC_EXPONENT</a></code> Keymaster tag, which uses a tag ID 439 value of 200. 440 </dd> 441 442 <dt> 443 <code>activeDateTime</code> 444 </dt> 445 446 <dd> 447 Corresponds to the <code><a href= 448 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_active_datetime"> 449 KM_TAG_ACTIVE_DATETIME</a></code> Keymaster tag, which uses a tag ID value 450 of 400. 451 </dd> 452 453 <dt> 454 <code>originationExpireDateTime</code> 455 </dt> 456 457 <dd> 458 Corresponds to the <code><a href= 459 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_origination_expire_datetime"> 460 KM_TAG_ORIGINATION_EXPIRE_DATETIME</a></code> Keymaster tag, which uses a 461 tag ID value of 401. 462 </dd> 463 464 <dt> 465 <code>usageExpireDateTime</code> 466 </dt> 467 468 <dd> 469 Corresponds to the <code><a href= 470 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_usage_expire_datetime"> 471 KM_TAG_USAGE_EXPIRE_DATETIME</a></code> Keymaster tag, which uses a tag ID 472 value of 402. 473 </dd> 474 475 <dt> 476 <code>noAuthRequired</code> 477 </dt> 478 479 <dd> 480 <p> 481 Corresponds to the <code><a href= 482 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_no_auth_required"> 483 KM_TAG_NO_AUTH_REQUIRED</a></code> Keymaster tag, which uses a tag ID 484 value of 503. 485 </p> 486 487 <p> 488 When an <code>AuthorizationList</code> object is associated with key 489 attestation, this value is always true. 490 </p> 491 </dd> 492 493 <dt> 494 <code>userAuthType</code> 495 </dt> 496 497 <dd> 498 Corresponds to the <code><a href= 499 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_user_auth_type"> 500 KM_TAG_USER_AUTH_TYPE</a></code> Keymaster tag, which uses a tag ID value 501 of 504. 502 </dd> 503 504 <dt> 505 <code>authTimeout</code> 506 </dt> 507 508 <dd> 509 Corresponds to the <code><a href= 510 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_auth_timeout"> 511 KM_TAG_AUTH_TIMEOUT</a></code> Keymaster tag, which uses a tag ID value of 512 505. 513 </dd> 514 515 <dt> 516 <code>allowWhileOnBody</code> 517 </dt> 518 519 <dd> 520 <p> 521 Corresponds to the <code>KM_TAG_ALLOW_WHILE_ON_BODY</code> Keymaster tag, 522 which uses a tag ID value of 506. 523 </p> 524 525 <p> 526 Allows the key to be used after its authentication timeout period if the 527 user is still wearing the device on their body. Note that a secure 528 on-body sensor determines whether the device is being worn on the user’s 529 body. 530 </p> 531 532 <p> 533 When an <code>AuthorizationList</code> object is associated with key 534 attestation, this value is always true. 535 </p> 536 </dd> 537 538 <dt> 539 <code>allApplications</code> 540 </dt> 541 542 <dd> 543 <p> 544 Corresponds to the <code>KM_TAG_ALL_APPLICATIONS</code> Keymaster tag, 545 which uses a tag ID value of 600. 546 </p> 547 548 <p> 549 Indicates whether all apps on a device can access the key pair. 550 </p> 551 552 <p> 553 When an <code>AuthorizationList</code> object is associated with key 554 attestation, this value is always true. 555 </p> 556 </dd> 557 558 <dt> 559 <code>applicationId</code> 560 </dt> 561 562 <dd> 563 Corresponds to the <code><a href= 564 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_application_id"> 565 KM_TAG_APPLICATION_ID</a></code> Keymaster tag, which uses a tag ID value 566 of 601. 567 </dd> 568 569 <dt> 570 <code>creationDateTime</code> 571 </dt> 572 573 <dd> 574 Corresponds to the <code><a href= 575 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_creation_datetime"> 576 KM_TAG_CREATION_DATETIME</a></code> Keymaster tag, which uses a tag ID 577 value of 701. 578 </dd> 579 580 <dt> 581 <code>origin</code> 582 </dt> 583 584 <dd> 585 <p> 586 Corresponds to the <code><a href= 587 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_origin"> 588 KM_TAG_ORIGIN</a></code> Keymaster tag, which uses a tag ID value of 702. 589 </p> 590 591 <p> 592 When an <code>AuthorizationList</code> object is associated with key 593 attestation, this value is usually set to 594 <code>KM_ORIGIN_GENERATED</code>. If the attestation uses Keymaster 595 version 0.2 or 0.3, however, the origin may be set to 596 <code>KM_ORIGIN_UNKNOWN</code> instead. 597 </p> 598 </dd> 599 600 <dt> 601 <code>rollbackResistant</code> 602 </dt> 603 604 <dd> 605 Corresponds to the <code><a href= 606 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_rollback_resistant"> 607 KM_TAG_ROLLBACK_RESISTANT</a></code> Keymaster tag, which uses a tag ID 608 value of 703. 609 </dd> 610 611 <dt> 612 <code>rootOfTrust</code> 613 </dt> 614 615 <dd> 616 <p> 617 Corresponds to the <code><a href= 618 "https://source.android.com/security/keystore/implementer-ref.html#km_tag_root_of_trust"> 619 KM_TAG_ROOT_OF_TRUST</a></code> Keymaster tag, which uses a tag ID value 620 of 704. 621 </p> 622 623 <p> 624 For more details, see the section describing the <code><a href= 625 "#certificate_schema_rootoftrust">RootOfTrust</a></code> 626 data structure. 627 </p> 628 </dd> 629 630 <dt> 631 <code>osVersion</code> 632 </dt> 633 634 <dd> 635 <p> 636 Corresponds to the <code>KM_TAG_OS_VERSION</code> Keymaster tag, which 637 uses a tag ID value of 705. 638 </p> 639 640 <p> 641 The version of the Android operating system associated with the 642 Keymaster, specified as a six-digit integer. For example, version 6.0.1 643 is represented as 060001. 644 </p> 645 646 <p> 647 Only Keymaster version 1.0 or higher includes this value in the 648 authorization list. 649 </p> 650 </dd> 651 652 <dt> 653 <code>osPatchLevel</code> 654 </dt> 655 656 <dd> 657 <p> 658 Corresponds to the <code>KM_TAG_PATCHLEVEL</code> Keymaster tag, which 659 uses a tag ID value of 706. 660 </p> 661 662 <p> 663 The month and year associated with the security patch that is being used 664 within the Keymaster, specified as a six-digit integer. For example, the 665 June 2016 patch is represented as 201606. 666 </p> 667 668 <p> 669 Only Keymaster version 1.0 or higher includes this value in the 670 authorization list. 671 </p> 672 </dd> 673 674 <dt> 675 <code>attestationChallenge</code> 676 </dt> 677 678 <dd> 679 <p> 680 Corresponds to the <code>KM_TAG_ATTESTATION_CHALLENGE</code> Keymaster 681 tag, which uses a tag ID value of 708. 682 </p> 683 684 <p> 685 The challenge string associated with the key pair that is defined in the 686 Keymaster. 687 </p> 688 </dd> 689 690 <dt> 691 <code>attestationApplicationId</code> 692 </dt> 693 694 <dd> 695 <p> 696 Corresponds to the <code>KM_TAG_ATTESTATION_APPLICATION_ID</code> 697 Keymaster tag, which uses a tag ID value of 709. 698 </p> 699 700 <p> 701 The unique ID of the attestation certificate that signed the key pair 702 that is in the Keymaster. 703 </p> 704 </dd> 705</dl> 706 707<h3 id="certificate_schema_rootoftrust"> 708 RootOfTrust 709</h3> 710 711<p> 712 This collection of values defines key information about the device’s status. 713</p> 714 715<p> 716 Each field in the following list is required: 717</p> 718 719<dl> 720 <dt> 721 <code>verifiedBootKey</code> 722 </dt> 723 724 <dd> 725 <p> 726 A secure hash of the key that verifies the system image. It is recommended 727 that you use the SHA-256 algorithm for this hash. 728 </p> 729 </dd> 730 731 <dt> 732 <code>deviceLocked</code> 733 </dt> 734 735 <dd> 736 True if the device’s bootloader is locked, which enables Verified Boot 737 checking and prevents an unsigned device image from being flashed onto the 738 device. For more information about this feature, see the <a class= 739 "external-link" href= 740 "https://source.android.com/security/verifiedboot/verified-boot.html">Verifying 741 Boot</a> documentation. 742 </dd> 743 744 <dt> 745 <code>verifiedBootState</code> 746 </dt> 747 748 <dd> 749 The <a href="#certificate_schema_verifiedbootstate">boot 750 state</a> of the device, according to the Verified Boot feature. 751 </dd> 752 753 <dt> 754 <code>osVersion</code> 755 </dt> 756 757 <dd> 758 The current version of the Android operating system on the device, 759 specified as a six-digit integer. For example, version 6.0.1 is represented 760 as 060001. 761 </dd> 762 763 <dt> 764 <code>patchMonthYear</code> 765 </dt> 766 767 <dd> 768 The month and year associated with the security patch that is currently 769 installed on the device, specified as a six-digit integer. For example, the 770 June 2016 patch is represented as 201606. 771 </dd> 772</dl> 773 774<h3 id="certificate_schema_verifiedbootstate"> 775 VerifiedBootState 776</h3> 777 778<p> 779 This data structure provides the device’s current boot state, which 780 represents the level of protection provided to the user and to apps after the 781 device finishes booting. For more information about this feature, see the 782 <a class="external-link" href= 783 "https://source.android.com/security/verifiedboot/verified-boot.html#boot_state"> 784 Boot State</a> section within the Verifying Boot documentation. 785</p> 786 787<p> 788 This data structure is an enumeration, so it takes on exactly one of the 789 following values: 790</p> 791 792<dl> 793 <dt> 794 Verified 795 </dt> 796 797 <dd> 798 <p> 799 Indicates a full chain of trust, which includes the bootloader, the boot 800 partition, and all verified partitions. 801 </p> 802 803 <p> 804 When the device is in this boot state, the <code>verifiedBootKey</code> is 805 the hash of the device-embedded certificate, which the device manufacturer 806 adds to the device's ROM at the factory. 807 </p> 808 </dd> 809 810 <dt> 811 SelfSigned 812 </dt> 813 814 <dd> 815 <p> 816 Indicates that the device-embedded certificate has verified the device’s 817 boot partition and that the signature is valid. 818 </p> 819 820 <p> 821 When the device is in this boot state, the <code>verifiedBootKey</code> is 822 the hash of a user-installed certificate, which signs a boot partition 823 that the user adds to the device in place of the original, 824 manufacturer-provided boot partition. 825 </p> 826 </dd> 827 828 <dt> 829 Unverified 830 </dt> 831 832 <dd> 833 Indicates that the user can modify the device freely. Therefore, the user is 834 responsible for verifying the device’s integrity. 835 </dd> 836 837 <dt> 838 Failed 839 </dt> 840 841 <dd> 842 Indicates that the device has failed verification. The attestation 843 certificate should never use this value for <code>VerifiedBootState</code>. 844 </dd> 845</dl> 846