What if the App signature expires or is leaked?
Before the app is released to the market, an important step is to sign the APK. Most of the time, this operation is hidden in the packaging process, not noticed by us.
The role of the signature, in addition to proving the ownership of the app, can also help the Android market and device verify the correctness of the APK.
The Android signature is self-certifying and does not CA certificate the certificate.
That is, we can use the tool to generate a self-signed signature certificate, as long as it is a correct signature, the system will recognize it and allow installation.
When generating a signature, you can specify a valid time, which defaults to 25 years, and Google Play also has a mandatory rule that the App signature on the shelf must be valid after the 2033-10-22 date.
So as long as it is not the owing to modify this expiration date, there will be no problem at this moment. After all, there is no App for 25 years.
Some problems are not in front of us, but they are real.
For a shelfd app, 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 cannot pass, the old user cannot overwrite the installation.
The only option for these historical users is to reinstall after uninstalling.
Fortunately, this is not only your problem, but the sky is falling, so don’t worry, Google has already started to solve
The solution is the new Android 9.0 support for APK V3 signing.
Second, the new signature scheme V3
2.1 Android signature scheme
Android’s signature scheme, which has evolved to the present, is not a one-time move.
Android now supports three application signing schemes:
- V1 scheme: based on JAR signature.
- V2 program: APK signature scheme V2, introduced in Android 7.0.
- V3 program: APK signature scheme V3, introduced in Android 9.0.
V1 to V2 are disruptive. In order to solve the security problem of the JAR signature scheme, and to the V3 scheme, there is not much adjustment in the structure. It can be understood as an upgraded version of the V2 signature scheme. Some materials also call it It is a V2+ solution.
Because this upgrade of the signature scheme is backward compatible, this process is transparent to the developer as long as it is used properly.
The biggest impact on developers from the V1 to V2 solution is the channel signing issue.
In the current environment, we want to make different installation channels for different channels and markets, and unique identifiers for carrying channels. This is what we call the channel package.
Fortunately, all major manufacturers have open sourced their own channel solutions, such as: Walle (Mei Tuan), VasDolly (Tencent) are very good programs, you can first look at the previous article: ”
Android signature and multi-channel Packing principle
2.2 History of Signatures
Start with the history of Android signatures.
In the 1980s, Phil Katz created the ZIP format, which combines files and some meta-arrays in a single file for easy transfer and archiving. This format was developed to address issues such as compression, parity, and redundancy. solution.
In the 1990s, Sum used ZIP as the basis for the JAR format, and JAR was essentially a ZIP archive.
Among them, the META-INF directory contains some information such as metadata and signature data.
After Android appeared, it also used the Java JAR publishing method to build the APK on the JAR format. Based on this, add more standardized structures to Dalvik bytecode classes.dex and resources resources.arsc.
At that time, Android’s APK relied entirely on JAR’s signature scheme to ensure the correctness of the application. This is what we call the V1 scheme (JAR scheme).
In the V1 signature scheme, all files in the APK are not protected, and there are some exceptions that will not invalidate the signature even if it is modified, for example: ZIP metadata.
At the same time, the V1 scheme separately calculates the data of the original file that is protected inside the APK, so in the verification, it needs to be decompressed and then verified, which leads to more time and more memory in the installation.
For example, the way the V1 program wins the channel is to take advantage of this feature and write the channel information into the META-INF file, which does not destroy the V1 signature.
Years later, a new signature method was added to Android 7.0, which is what we call the V2 solution.
V2 signatures provide more powerful APK file validation, instead of checking individual files within a package, it checks the entire APK.
It inserts an extra signature block in the ZIP file, overwriting the rest of the ZIP file.
In this extra signature block (Apk Signature Block V2), the rest of the current APK is signed.
From a security perspective, V2 is more secure than V1, and V2 signatures verify the entire packaged APK file, so making any “any” changes to its APK file will break the signature.
Note that any of the quoted blocks here, the V2 signed signature block is actually a KV structure, you can insert some simple data into it without destroying the V2 signature. This is the multi-channel solution idea under the V2 scheme.
While introducing the V2 solution, backward compatibility is also guaranteed. The old JAR signature scheme still works in the old device (below Android 7.0), and on the newer device, it also determines whether to use the V2 signature, otherwise Still will check the V1 signature.
The V2 solution addresses security issues and efficiency issues during installation verification, but it does not address the previously mentioned re-signing issue.
2.3 Android V3 solution
A new signature scheme was introduced in Android 9.0. Its format is roughly similar to V2. In the V2 inserted signature block (Apk Signature Block V2), a new fast (Attr block) is added.
In this new block, our previous signature information and new signature information will be recorded, and the key rotation scheme will be used to replace and upgrade the signature.
This means that as long as the old signature certificate is in hand, we can change the signature in the new APK file.
The new block (attr) added by V3 signature stores all the signature information, which is stored in a linked list by smaller Level blocks.
Each of the nodes contains a signature certificate for signing the application of the previous version. The oldest signature certificate corresponds to the root node, and the system will have the certificate in each node sign the next certificate in the list, thus each new secret. The key provides evidence that it should be as trustworthy as the old key.
This process is somewhat similar to the certification process for a CA certificate, the old signature of an installed app, ensuring that the new signature of the installed APK is overwritten and the trust is passed on.
2.4 V3 signature verification process
Android’s signature scheme, no matter how you upgrade, is to ensure backward compatibility.
After the introduction of the V3 scheme, in Android 9.0 and higher, you can try to verify the APK according to the APK signature scheme, V3 → V2 → V1.
Older platforms ignore V3 signatures and try V2 signatures, and finally verify V1 signatures.
The entire verification process is as follows:
It should be noted that for overlay installation, signature verification only supports upgrades and does not support downgrade.
That is to say, an Apk signed with V1 is installed on the device, and the V2-signed Apk can be used for overwriting installation, and vice versa.
Third, summing up the moment
The issue of Android signature replacement, Google has already considered, 9.0 new V3 signature scheme is to solve the signature replacement.
These are definitely all prepared in advance.
The problem of signature expiration does not need to be too worried. We just need to follow Google’s pace.
Finally, conclude that the problem of signature expiration, the newly supported V3 signature on Android 9.0, has been solved.
- The V1 signature follows the JAR’s signature and separately validates the files in the APK archive.
- The V2 signature is for the verification of the APK file, and the signature information is written into the signature block, which enhances the security and verification efficiency.
- The V3 signature adds a new block (attr) to the signature block. The smaller level block stores multiple certificates in the form of a linked list.
- In the V3 scenario, the oldest certificate is the root node of the new block list, which signs the new certificate to ensure that the new certificate is valid.
The V3 solution has not yet been officially opened. Apksigner in the latest version of Build Tools version 28.0.3 does not yet support V3’s APK signature scheme.
If you want to try it, you can compile it yourself by source code.
From the existing information, I am more concerned about the multi-channel package support program, after upgrading to V3, the old V2 support multi-channel solution should still be effective (or a small change).