src/help/studio_help/src/topics/c_keys-keystores.dita

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "../dtd/concept.dtd">
<concept id="c_keys-keystores" xml:lang="en-us">
  <title>Keys and Keystores</title>
  <shortdesc>Keys are used to sign Android packages. Keys live within keystore files.</shortdesc>
  <prolog>
    <metadata>
      <keywords>
        <!--<indexterm></indexterm>-->
      </keywords>
    </metadata>
  </prolog>
  <conbody>
    <section>
      <p>Android relies upon "public key cryptography" to ensure the integrity of all Android packages (APKs). Public
        Key Cryptography is a cryptographic system that uses a pair of keys—one public and one private—where one key
        encrypts a message or signs an app while the other decrypts the encrypted message or verifies the app's
        signature. The two keys are strings of binary digits; for purposes of Android app signing, Google recommends
        that your keys be at least 2048 bits in length. Because of the way that the signing algorithm works, the private
        key must be kept private while the public key can be freely distributed. Note that for message encryption, you
        encrypt the message with the public key and decrypt it with the private key. For app signing, the reverse is
        true: you sign the app with the private key, and verify the signature using the public key. </p>
    </section>
<section><title>Certificates</title>A certificate is an electronic document that uses a digital signature to connect a
      public key to an identity (of a person or corporation, typically). The identity is a set of information such as
      the name of a person or an organization, their address, and so forth. Certificates used to sign Android
      applications follow the X.509 standard; that standard defines the set of identity fields used within the
      certificate. Android uses the certificate both to identify the author of an app and to establish a trust
      relationship between apps that have both been signed using the same certificate. In addition to the public key and
      identity information, certificates also have a "validity period": a period of time during which the certificate is
      valid. Beyond this validity period, the certificate is considered invalid. Android developers apply their own
      certificates; unlike on some platforms, Google doesn't apply a certificate of its own to apps submitted to Google
      Play. <p>Certificates can be issued by a trusted source—a "Certificate Authority" or CA—or they can be
        user-generated. This latter form is often referred to as "self-signed". When used to sign an Android app, the
        certificate need not be issued by a CA. In fact, self-signed certificates are not only allowed but are typically
        what developers use to sign Android apps. As with your key pairs, you can use keytool to generate, display,
        import, and export digital certificates. </p><p>X.509 certificates are kept in files; install one by moving the
        file to the device and pointing the app that needs it to the certificate file. </p><note>The Signing and Keys view presents a streamlined interface for
      working with keystores and "keys." In reality, you are creating and manipulating certificates, but to minimize the
      confusion for developers not comfortable with keys, certificates, and signing, the term "key" is used by the tools
      within this view to represent both certificates and the public/private key pairs associated with them.</note></section>    <section>
      <title>Keystores</title>
    <p>A keystore is a repository (usually, an encrypted file) containing private keys and
      security certificates. You can use a command-line tool called keytool to manipulate the keystore, or you can use
      the tools provided in MOTODEV Studio's Signing and Keys view. These tools employ keytool on your behalf; you don't
      have to invoke the command-line tools to generate keys and certificates, to manipulate keystores, or to sign your
      apps.</p>
    </section>
    <section>
      <title>Why Are Apps Signed?</title>
      <p>Android requires that all apps—development builds and release builds alike—installed on an Android device be
        signed. There are a few reasons for this: <ul>
          <li>To provide some degree of assurance that an app is unaltered</li>
          <li>To securely tie an app to its updates</li>
          <li>To allow close ties between separate apps signed using the same certificate </li>
        </ul>For Android apps, there are additional benefits to code signing: <ul>
          <li>Application signing is the first step to placing an application into its own application sandbox. The
            signing certificate helps to define which user ID is associated with a given application. Apps signed with
            different certificates run under different user IDs, and cannot directly access each other's data.
            Application signing thus ensures that one application can only interact with another through a well-defined
            IPC mechanism.</li>
          <li>Two apps signed with the same certificate can be run in the same process. An APK has the option to specify
            in its manifest that it will share its UID with other similarly signed APKs. If the certificate (or, more
            accurately, the public key in the certificate) used to sign one app matches the one used to sign another app
            on the same device, those apps will be run in the same process and will have access to each other's
            data.</li>
          <li>Apps can declare security permissions at the Signature protection level, allowing some access by apps
            signed with the same key while maintaining distinct UIDs and application sandboxes.</li>
        </ul> The requirement that all apps be signed extends to apps under development, as well as to the release
        versions of your apps. Both at app installation, and again when the app is run, the device checks the app for a
        signature. This check cannot be bypassed by "side-loading" apps or downloading apps from other than Google Play.
        Therefore, all apps must be signed. Fortunately for developers the tools automatically generate and apply a
        debug certificate to development builds; you need only get involved when you create release versions of your
        apps. When you are ready to release an app, you sign it with a suitable private key. Note that you cannot
        publish an app that has been signed with a debug key. </p>
      <p>You can publish, but users can't install, an app that is signed using a certificate that has expired. Android
        will, however, allow you to run an app that has already been installed even if the certificate has since
        expired. Related to this is the fact that app updates must be signed using the same certificate as the app to
        which they apply. Thus when creating a certificate to use for app signing make sure that it has a sufficiently
        long validity period—Google recommends a minimum of 25 years—to last for not only the projected lifetime of the
        app itself, but also any updates you may issue. This is a very important point, because after the certificate
        expires, users can no longer install the app and can no longer install any updates. </p>
    </section>
  </conbody>
</concept>