A, sequence

Signing an APK is an important step before releasing an App to the market, and most of the time, this is hidden in the packaging process, unnoticed by us.

Signatures, in addition to proving App ownership, can also help the Android market and devices verify the correctness of APK

Android signatures are self-proven and do not CA authenticate certificates. That is, we can use the tool to generate a signature certificate, as long as it is a correct signature, the system will recognize, and allow installation.

When you generate a signature, you can specify an expiration date, which by default is 25 years, and Google Play has a mandatory rule that an App’s signature must be valid after the 2033-10-22 date. Therefore, as long as the validity period is not modified by hand, there will be no problem at this moment, after all, no App has existed for 25 years.

Some problems are not immediate, but they are real. For an App on the shelf, the most important thing is the user. When the signature is invalid, we have to change the signature. At this time, because the signature verification fails, the old user cannot cover the installation. The only option for these historical users is to uninstall and reinstall.

The good news is that it’s not just you and me, the sky is falling for tall people, so don’t worry, Google is already working on this problem.

The solution is Android 9.0’s new support for APK V3 signatures.

2. New signature scheme V3

2.1 Android Signature Scheme

Android’s signature scheme, developed to date, did not happen overnight. Android already supports three application signature schemes:

  • V1 scheme: Based on JAR signature.
  • V2 solution: APK signature scheme V2, introduced in Android 7.0.
  • V3 solution: APK signature scheme V3, introduced in Android 9.0.

V1 to V2 is subversive, in order to solve the security problem of JAR signature scheme, but to V3 scheme, in fact, there is no big adjustment in the structure, can be understood as the upgrade version of V2 signature scheme, some data also called it V2+ scheme.

Because the upgrade of this signature scheme is backward compatible, the process is transparent to the developer as long as it is used properly.

V1 to V2 upgrade, the biggest impact on developers, is the channel signing issue. In the current environment, we want to make different installation packages for different channels and markets, and carry the unique logo of the channel, which is commonly known as the channel package. Fortunately, all major manufacturers have their own open source signature channel schemes, such as Walle (Meituan) and VasDolly (Tencent) are very excellent schemes. To understand, you can first look at the previous article: “Android signature and multi-channel packaging principle”.

2.2 History of Signatures

Let’s start with the history of Android signatures.

In the 1980s, Phil Katz created the ZIP format, which combined files and tuples into a single file for easy transfer and archiving, as a solution to problems such as compression, validation, and redundancy.

In the 1990s, Sum used ZIP as the basis for the JAR format, which is essentially a ZIP archive. The meta-INF directory contains metadata and signature data.

After the emergence of Android, the Java JAR distribution method is also followed, APK is based on the JAR format, and more standardized structures are added to Dalvik bytecode classes.dex and resources. At the time, Android’s APK relied entirely on the JAR signature scheme, commonly known as V1 (JAR scheme), to ensure the correctness of applications.

V1 signature scheme does not protect all files in APK. Some exceptions, such as ZIP metadata, will not invalidate signatures even if they are modified. At the same time, V1 scheme separately calculates the data summary for the original files protected inside APK, so it needs to decompress and then verify during verification, which will cost more time and consume more memory during installation. For example, the channel signing method in V1 scheme takes advantage of this feature and writes the channel information to the meta-INF file, which does not break the V1 signature.

Over the years, a new signature approach was added to Android 7.0, known as the V2 scheme. V2 signature provides more powerful validation of APK files, which no longer checks individual files within a package, but the entire APK. It inserts an additional signature block into the ZIP file, overwriting the rest of the ZIP file.

In this additional Signature Block (Apk Signature Block V2), other parts of the current Apk are signed.

V2 will be more secure than V1 from a security point of view. The V2 signature validates the entire packaged APK file, so “any” changes to its APK file will break the signature. Note that any quoted signature block for a V2 signature is actually a K-V structure into which simple data can be inserted without breaking the V2 signature. This is the multi-channel scheme idea for the V2 scheme.

The introduction of the V2 scheme also ensures backward compatibility. The old JAR signature scheme still works on older devices (Android 7.0 or below). On newer devices, V2 signatures are checked, and V1 signatures are checked if not.

The V2 solution addresses security issues and the efficiency of installation verification, but it does not address the aforementioned signature change problem.

2.3 Android V3 Solution

Android 9.0 introduced a new Signature method, which is roughly similar to V2. In the Apk Signature Block V2, a new fast (Attr Block) was added.

In this new block, we will record our previous signature information and the new signature information, in the key wheel scheme, to do the signature replacement and upgrade. This means that as long as we have the old signing certificate, we can use it to change the signature in the new APK file.

V3 Signature New Block (ATTR) stores all signature information in the form of a linked list of smaller Level blocks.

Each node contains the signing certificate used to sign the previous version of the application. The oldest signing certificate corresponds to the root node. The system will have the certificate in each node sign the next certificate in the list, providing evidence for each new key that it should be as trusted as the old key.

This process is somewhat similar to the certification process for CA certificates, with the old signature of the installed App, ensuring that the new signature overrides the installed APK is correct, passing on trust.

2.4 V3 Signature Verification Procedure

Android’s signature scheme, no matter how updated, is designed to ensure downward compatibility.

After the introduction of V3 scheme, in Android 9.0 and later, APK signature scheme can be verified by V3 → V2 → V1. Older platforms ignore V3 signatures and try V2 signatures before validating V1 signatures.

The whole verification process is shown as follows:

It is important to note that in the case of an overwritten installation, signature verification only supports upgrades, not downgrades. In other words, if an Apk with V1 signature is installed on the device, the Apk with V2 signature can be used to override the installation. Otherwise, the installation is not allowed.

Summary moment

Android signature replacement issue, Google has been considering, 9.0 new V3 signature solution is to solve the signature replacement. All of this must have been prepared in advance.

We don’t need to worry too much about signature expiration, we just need to follow The pace of Google.

In Android 9.0, there is a solution to the signature expiration issue. In addition:

  1. V1 signature follows JAR signature mode and independently verifies files in the APK compressed package.
  2. V2 signature authenticates APK files by writing signature information into signature blocks, enhancing security and authentication efficiency.
  3. V3 signature adds a new block (ATTR) to the signature block, consisting of a smaller Level block that stores multiple certificates in a linked list.
  4. In the V3 scenario, the oldest certificate is the root node of the new block linked list, which is used to sign the new certificate and ensure that it is valid.

V3 is not officially available. Apksigner in Build Tools 28.0.3 does not support V3’s APK signature scheme. If you want to experiment, you can compile your own source code.

Based on the information available, I am concerned about the multichannel packaged support scheme, and the old V2 supported multichannel scheme should remain valid (or with minor changes) after the upgrade to V3.

Look forward to the specific effect after the online.

If you have any thoughts or questions about V3 signature, please feel free to discuss them in the comments section. If this article has helped you, please leave a comment, retweet, or like it.

reference:

Android APK signature scheme V3

Android Doc: Application signature

Android P V3 signature is new


Public number background reply growth “growth”, will get the learning materials I prepared, can also reply “add group”, learning progress together; You can also reply to “questions” and ask me questions.