Merge "docs: Migrated "key attestation" page to a new location (for N OTA)." into nyc-dev

  to: /studio/intro/index.html?utm_medium=android-studio

- from: /r/studio-ui/menu-start.html

  to: /training/index.html?utm_medium=android-studio

# N Preview redirects

- from: /preview/features/key-attestation.html

  to: /training/articles/security-key-attestation.html

    path_attributes:

    - name: description

      value: How to use the SafetyNet service to analyze a device where your app is running and get information about its compatibility with your app.

  - title: Verifying Hardware-backed Key Pairs with Key Attestation

    path: /training/articles/security-key-attestation.html

    path_attributes:

    - name: description

      value: How to retrieve and verify the properties of a device's hardware-backed key pair.

  - title: Enhancing Security with Device Management Policies

    path: /work/device-management-policy.html

    path_attributes:

page.title=Key Attestation

page.metaDescription=New support in Android N for verifying security properties of hardware-backed keys.

page.keywords="android N", "security", "TEE", "hardware-backed", "keystore", "certificate", "key attestation"

page.metaDescription=A tool for verifying security properties of hardware-backed key pairs.

page.keywords="security", "TEE", "hardware-backed", "keystore", "certificate", "key attestation"

@jd:body

<div id="qv-wrapper">

  <div id="qv">

<div id="tb-wrapper">

  <div id="tb">

    <h2>In this document</h2>

      <ol>

        <li><a href="#verifying">Retrieving and Verifying a Hardware-backed Key Pair</a></li>

</p>

<p class="note">

  <strong>Note: </strong>Only a small number of devices running Android N

  support hardware-level key attestation; all other devices running Android N

  use software-level key attestation instead. Before you verify the properties

  of a device's hardware-backed keys in a production-level environment, you

  should make sure that the device supports hardware-level key attestation. To

  do so, you should check that the attestation certificate chain contains a root

  certificate that is signed by the Google attestation root key and that the

  <code>attestationSecurityLevel</code> element within the <a

  <strong>Note: </strong>Only a small number of devices running Android 7.0 (API

  level 24) support hardware-level key attestation; all other devices running

  Android 7.0 use software-level key attestation instead. Before you verify the

  properties of a device's hardware-backed keys in a production-level

  environment, you should make sure that the device supports hardware-level key

  attestation. To do so, you should check that the attestation certificate chain

  contains a root certificate that is signed by the Google attestation root key

  and that the <code>attestationSecurityLevel</code> element within the <a

  href="#certificate_schema_keydescription">key description</a> data structure

  is set to the TrustedEnvironment security level.

</p>

</p>

<p>

  The root certificate within this chain is signed using an attestation key,

  which the device manufacturer injects into the device’s hardware-backed

  keystore at the factory.

  If the device supports hardware-level key attestation, the root certificate

  within this chain is signed using an attestation root key, which the device

  manufacturer injects into the device’s hardware-backed keystore at the

  factory.

</p>

<p class="note">

  <strong>Note:</strong> On devices that ship with Android N and Google Play

  services, the root certificate is issued by Google. You should verify that

  this root certificate appears within Google’s list of root certificates.

  <strong>Note:</strong> On devices that ship with hardware-level key

  attestation, Android 7.0 (API level 24), and Google Play services, the root

  certificate is signed by the Google attestation root key. You should verify

  that this root certificate appears within Google’s list of root certificates.

</p>

<p>

  </dd>

  <dt>

    <code>attestationSecurity</code>

    <code>attestationSecurityLevel</code>

  </dt>

  <dd>

    <p class="caution">

      <strong>Warning:</strong> Although it is possible to attest keys that are

      stored in the Android system—that is, if the

      <code>attestationSecurity</code> value is set to Software&mdash;you

      stored in the Android system—that is, if the value of

      <code>attestationSecurityLevel</code> is set to Software&mdash;you

      cannot trust these attestations if the Android system becomes compromised.

    </p>

  </dd>

  </dd>

  <dt>

    <code>keymasterSecurity</code>

    <code>keymasterSecurityLevel</code>

  </dt>

  <dd>

<p>

  Each field name corresponds to a similarly-named Keymaster tag. For example,

  the <code>keySize</code> field in an authorization list corresponds to the

  <code>KM_TAG_KEY_SIZE</code> Keymaster tag.

  <a href="https://source.android.com/security/keystore/implementer-ref.html#km_tag_key_size">

  <code>KM_TAG_KEY_SIZE</code></a> Keymaster tag.

</p>

<p>

  <dd>

    The month and year associated with the security patch that is currently

    installed on the device, specified as a six-digit integer. For example, the

    June 2016 patch is represented as 201606.

    August 2016 patch is represented as 201608.

  </dd>

</dl>