What if the App signature expires or leaks? Don’t worry, Google has come up with a solution!

Time:2019-8-13

I. Preface

Before releasing App to the market, an important step is to sign the APK. Most of the time, this operation is hidden in the packaging process and not noticed by us.

In addition to proving the ownership of App, signatures can also help the Android market and devices verify the correctness of APK.

Android signatures are self-certified and do not have CA certificates. That is to say, we can use the tool to generate signature certificates by ourselves. As long as it is a correct signature, the system will recognize and allow installation.

When generating a signature, you can specify a valid time, which defaults to 25 years, and Google Play also has a hard rule that the validity of the App signature on the shelf must be after 2033-10-22. So as long as it is not due to modify the validity period, at this moment, there will be no problem, after all, no App has existed for 25 years.

Some problems are not in front of us, but they are real. For an app on the shelf, the most important thing is the user, and when the signature is invalid, we can only be forced to change the signature. At this time, because the signature verification can not pass, the old user can not cover the installation. The only option for these historical users is to reinstall after uninstallation.

Fortunately, it’s not just about you and me. There’s a tall head in the sky, so don’t worry, Google is already working on a solution.thisIt’s a problem.

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

II. New Signature Scheme V3

2.1 Android Signature Scheme

Android’s signature scheme has not been achieved overnight. Android now supports three application signature schemes:

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

V1 to V2 are subversive. In order to solve the security problem of JAR signature scheme, V3 scheme has not been adjusted too much. It can be understood as an upgraded version of V2 signature scheme. Some data also call it V2 + scheme.

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

The upgrade from V1 to V2 has the greatest impact on developers, which is the issue of channel signing. In the current environment, we want to make the installation packages of different channels and markets different, carrying the only identification of channels, which is commonly known as channel packages. Fortunately, every major manufacturer has opened its own signature channel scheme, such as Walle (American League) and Vas Dolly (Tencent) are excellent schemes. If you want to know, you can read the previous article: Android Signature and Multi-channel Packaging Principles.

2.2 Signature History

Let’s start with the history of Android signatures.

In the 1980s, Phil Katz created the ZIP format, which combines files and some arrays in one file for easy transmission and archiving. This format is a solution to the problems of compression, verification and redundancy.

Sum used ZIP as the basis of JAR format in the 1990s, and JAR is essentially a ZIP archive. Among them, the META-INF directory contains some metadata and signature data.

After the advent of Android, Java JAR was also used to publish APK based on JAR format. On this basis, more standardized structures were added to files such as Dalvik bytecode classes. DEX and resource resources. arsc. At that time, Android’s APK relied entirely on JAR’s signature scheme to ensure the correctness of the application, which is commonly known as the V1 scheme (JAR scheme).

In V1 signature scheme, all files in APK will not be protected, and there will be some exceptions, even if modified, it will not lead to signature invalidation, such as ZIP metadata. At the same time, V1 scheme calculates the data summary separately for the original files protected in APK, so it needs to decompress before validation, which will lead to more time and memory consumption in installation. For example, the way of signing channel in V1 scheme is to use this feature to write channel information into META-INF file, which will not destroy V1 signature.

Years later, a new signature method was added to Android 7.0, which is commonly known as the V2 scheme. V2 signatures provide more powerful APK file validation, which no longer checks individual files in the package, but checks the entire APK. It inserts an additional signature block into the ZIP file to cover the rest of the ZIP file.

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

V2 is safer than V1 in terms of security. V2 signature is to verify the entire packaged APK file, so any change to its APK file will destroy the signature. Notice that any signature block with quotation marks here is actually a K-V structure, which can insert some simple data into it without destroying the V2 signature. This is the idea of multi-channel scheme under V2 scheme.

While introducing V2 scheme, backward compatibility is guaranteed. The old JAR signature scheme still works in the old device (Android 7.0 or below), and on the newer device, it will judge whether to use V2 signature or not, or it will still check V1 signature.

The V2 scheme solves the security problem and the efficiency of verification during installation, but it does not solve the problem of signature exchange mentioned above.

2.3 Android V3 solution

Android 9.0 introduces a new signature method, which is similar in format to V2. A new fast (Attr block) is added to the Apk Signature Block V2 inserted in V2.

In this new block, we will record our previous signature information and new signature information to replace and upgrade signatures with the key wheel scheme. This means that as long as the old signature certificate is in hand, we can change the signature through it in the new APK file.

The new attr of V3 signature stores all signature information, which is stored by smaller Level blocks in the form of linked lists.

Each node contains a signature certificate for the previous version of the application signature. The oldest signature certificate corresponds to the root node. The system will make the certificate in each node sign for the next Certificate in the list, thus providing evidence for each new key to prove that it should be as trustworthy as the old one.

This process is somewhat similar to the CA certification process. The old signature of the installed App ensures that the new signature covering the installed APK is correct and the trust is passed on.

Verification process of 2.4 V3 signature

Android’s signature scheme, however upgraded, is to ensure downward compatibility.

After introducing V3 scheme, in Android 9.0 and higher versions, we can try to verify APK according to APK signature scheme, V3 V2 V1 in turn. Older platforms ignore V3 signatures and try V2 signatures before verifying V1 signatures.

The whole validation process is as follows:

It is important to note that signature verification only supports upgrades, not downgrades, in case of overwriting installation. That is to say, an APK with V1 signature is installed on the device, which can be overwritten by the APK with V2 signature, and vice versa.

Summary moment

The problem of Android signature replacement has been considered by Google. The new V3 signature scheme in 9.0 is designed to solve the problem of signature replacement. All of these must be prepared in advance.

There’s no need to worry about signature expiration. We just need to follow Google’s lead.

Finally, we conclude that the problem of signature expiration, the newly supported V3 signature on Android 9.0, has been solved. In addition:

  1. The V1 signature follows the JAR signature mode and verifies the files in the APK compression package separately.
  2. V2 signature is aimed at the verification of APK file. It writes signature information into signature block, which enhances security and verification efficiency.
  3. V3 signature adds a new block (attr) to the signature block, which is composed of smaller level blocks and stores multiple certificates in the form of linked lists.
  4. In V3 scheme, the oldest certificate is the root node of the new block list, which can sign the new certificate and ensure the validity of the new certificate.

The V3 scheme has not yet been officially opened. In the latest version of Build Tools version 28.0.3, the APksigner does not support the V3 APK signature scheme. You can compile your own source code if you want to try something fresh.

From the existing data, I am more concerned about the multi-channel packaging support program, after upgrading to V3, the old V2 support multi-channel program should still be effective (or a small change).

Looking forward to the specific effect of online.

If you have any ideas or questions about V3 signature, please discuss them in the message area. If this article is helpful to you, welcome.Messages, forwards, compliments

reference:

Android APK signature scheme V3

Android Doc: Application Signature

New features of Android P V3 signature


The Public’s Backstage Response to GrowthGrow upI will be able to get the materials I have prepared and reply to them.Additive groupLearn together and make progress; you can also reply.Put questions toAsk me questions.

Recommended Today

Implementation of PHP Facades

Example <?php class RealRoute{ public function get(){ Echo’Get me’; } } class Facade{ public static $resolvedInstance; public static $app; public static function __callStatic($method,$args){ $instance = static::getFacadeRoot(); if(!$instance){ throw new RuntimeException(‘A facade root has not been set.’); } return $instance->$method(…$args); } // Get the Facade root object public static function getFacadeRoot() { return static::resolveFacadeInstance(static::getFacadeAccessor()); } protected […]