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&mdash;that is, if the
233      <code>attestationSecurity</code> value is set to Software&mdash;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