Once an app has been successfully developed, the next step is to publish and share it with others.
However, apps can’t simply be added to a store and shared, they must be first signed. The cryp- tographic signature serves as a verifiable mark placed by the developer of the app. It identifies the app’s author and ensures that the app has not been modified since its initial distribution.
Signing Process
During development, apps are signed with an automatically generated certificate. This certificate is inherently insecure and is for debugging only. Most stores don’t accept this kind of certificate for publishing; therefore, a certificate with more secure features must be created. When an ap- plication is installed on the Android device, the Package Manager ensures that it has been signed with the certificate included in the corresponding APK. If the certificate’s public key matches the key used to sign any other APK on the device, the new APK may share a UID with the pre-existing
APK. This facilitates interactions between applications from a single vendor. Alternatively, spec- ifying security permissions for the Signature protection level is possible; this will restrict access to applications that have been signed with the same key.
APK Signing Schemes
Android supports three application signing schemes. Starting with Android 9 (API level 28), APKs can be verified with APK Signature Scheme v3 (v3 scheme), APK Signature Scheme v2 (v2 scheme) or JAR signing (v1 scheme). For Android 7.0 (API level 24) and above, APKs can be verified with the APK Signature Scheme v2 (v2 scheme) or JAR signing (v1 scheme). For backwards compatibility, an APK can be signed with multiple signature schemes in order to make the app run on both newer and older SDK versions. Older platforms ignore v2 signatures and verify v1 signatures only.
JAR Signing (v1 Scheme)
The original version of app signing implements the signed APK as a standard signed JAR, which must contain all the entries inMETA-INF/MANIFEST.MF. All files must be signed with a common certificate. This scheme does not protect some parts of the APK, such as ZIP metadata. The drawback of this scheme is that the APK verifier needs to process untrusted data structures before applying the signature, and the verifier discards data the data structures don’t cover. Also, the APK verifier must decompress all compressed files, which takes considerable time and memory.
APK Signature Scheme (v2 Scheme)
With the APK signature scheme, the complete APK is hashed and signed, and an APK Signing Block is created and inserted into the APK. During validation, the v2 scheme checks the signatures of the entire APK file. This form of APK verification is faster and offers more comprehensive protection against modification. You can see theAPK signature verification process for v2 Schemebelow.
APK Signature Scheme (v3 Scheme)
The v3 APK Signing Block format is the same as v2. V3 adds information about the supported SDK versions and a proof-of-rotation struct to the APK signing block. In Android 9 (API level 28) and higher, APKs can be verified according to APK Signature Scheme v3, v2 or v1 scheme. Older platforms ignore v3 signatures and try to verify v2 then v1 signature.
The proof-of-rotation attribute in the signed-data of the signing block consists of a singly-linked list, with each node containing a signing certificate used to sign previous versions of the app. To make backward compatibility work, the old signing certificates sign the new set of certificates, thus providing each new key with evidence that it should be as trusted as the older key(s). It is no longer possible to sign APKs independently, because the proof-of-rotation structure must have the old signing certificates signing the new set of certificates, rather than signing them one-by-one.
You can see theAPK signature v3 scheme verification processbelow.
APK Signature Scheme (v4 Scheme)
The APK Signature Scheme v4 was introduced along with Android 11 (API level 30). which requires all devices launched with it to havefs-verity enabled by default. fs-verity is a Linux kernel fea- ture that is primarily used for file authentication (detection of malicious modifications) due to its extremely efficient file hash calculation. Read requests only will succeed if the content verifies against trusted digital certificates that were loaded to the kernel keyring during boot time.
The v4 signature requires a complementary v2 or v3 signature and in contrast to previous signa- ture schemes, the v4 signature is stored in a separate file<apk name>.apk.idsig. Remember to specify it using the --v4-signature-fileflag when verifying a v4-signed APK with apksigner verify.
You can find more detailed information in theAndroid developer documentation.
Creating Your Certificate
Android uses public/private certificates to sign Android apps (.apk files). Certificates are bundles of information; in terms of security, keys are the most important type of this information Public certificates contain users’ public keys, and private certificates contain users’ private keys. Public and private certificates are linked. Certificates are unique and can’t be re-generated. Note that
if a certificate is lost, it cannot be recovered, so updating any apps signed with that certificate becomes impossible. App creators can either reuse an existing private/public key pair that is in an available KeyStore or generate a new pair. In the Android SDK, a new key pair is generated with thekeytoolcommand. The following command creates a RSA key pair with a key length of 2048 bits and an expiry time of 7300 days = 20 years. The generated key pair is stored in the file ‘myKeyStore.jks’, which is in the current directory):
keytool-genkey -aliasmyDomain-keyalgRSA-keysize2048-validity7300-keystoremyKeyStore.jks-storepassmyStrongPassword
Safely storing your secret key and making sure it remains secret during its entire life cycle is of paramount importance. Anyone who gains access to the key will be able to publish updates to your apps with content that you don’t control (thereby adding insecure features or accessing shared content with signature-based permissions). The trust that a user places in an app and its developers is based totally on such certificates; certificate protection and secure management are therefore vital for reputation and customer retention, and secret keys must never be shared with other individuals. Keys are stored in a binary file that can be protected with a password; such files are referred to as KeyStores. KeyStore passwords should be strong and known only to the key creator. For this reason, keys are usually stored on a dedicated build machine that developers have limited access to. An Android certificate must have a validity period that’s longer than that of the associated app (including updated versions of the app). For example, Google Play will require certificates to remain valid until Oct 22nd, 2033 at least.
Signing an Application
The goal of the signing process is to associate the app file (.apk) with the developer’s public key.
To achieve this, the developer calculates a hash of the APK file and encrypts it with their own private key. Third parties can then verify the app’s authenticity (e.g., the fact that the app really comes from the user who claims to be the originator) by decrypting the encrypted hash with the author’s public key and verifying that it matches the actual hash of the APK file.
Many Integrated Development Environments (IDE) integrate the app signing process to make it easier for the user. Be aware that some IDEs store private keys in clear text in configuration files; double-check this in case others are able to access such files and remove the information if necessary. Apps can be signed from the command line with the ‘apksigner’ tool provided by the Android SDK (API level 24 and higher). It is located at[SDK-Path]/build-tools/[version].
For API 24.0.2 and below, you can use ‘jarsigner’, which is part of the Java JDK. Details about the whole process can be found in official Android documentation; however, an example is given below to illustrate the point.
apksigner sign--outmySignedApp.apk--ksmyKeyStore.jks myUnsignedApp.apk
In this example, an unsigned app (‘myUnsignedApp.apk’) will be signed with a private key from the developer KeyStore ‘myKeyStore.jks’ (located in the current directory). The app will become a signed app called ‘mySignedApp.apk’ and will be ready to release to stores.
Zipalign
Thezipaligntool should always be used to align the APK file before distribution. This tool aligns all uncompressed data (such as images, raw files, and 4-byte boundaries) within the APK that helps improve memory management during app runtime.
Zipalign must be used before the APK file is signed with apksigner.
Publishing Process
Distributing apps from anywhere (your own site, any store, etc.) is possible because the Android ecosystem is open. However, Google Play is the most well-known, trusted, and popular store, and Google itself provides it. Amazon Appstore is the trusted default store for Kindle devices. If users want to install third-party apps from a non-trusted source, they must explicitly allow this with their device security settings.
Apps can be installed on an Android device from a variety of sources: locally via USB, via Google’s official app store (Google Play Store) or from alternative stores.
Whereas other vendors may review and approve apps before they are actually published, Google will simply scan for known malware signatures; this minimizes the time between the beginning of the publishing process and public app availability.
Publishing an app is quite straightforward; the main operation is making the signed APK file down- loadable. On Google Play, publishing starts with account creation and is followed by app delivery through a dedicated interface. Details are available atthe official Android documentation.