The syntax of a certificate lineage or new signature sequence is as follows:
Learn more about how to use apksigner to rotate keys.
Android 9 supports APK key rotation, which allows applications to change their signature keys during APK update. In order to achieve rotation, APK must indicate the trust level between the old and new signature keys. In order to support key rotation, we update the APK signature scheme from v2 to v3 to allow the use of old and new keys. V3 adds information about supported SDK versions and rotation proof structures to the APK signature block.
In order to maintain backward compatibility with v 1 APK format, v2 and v3 APK signatures are stored in the "APK signature block" immediately before the ZIP central directory.
V3 APK signature block has the same format as v2. The V3 signature of APK is stored as an ID-value pair, where id is 0xf05368c0.
The format of "APK signature block" is as follows (all numerical fields are arranged in order of small end):
When parsing APK, we should first find the starting position of ZIP Central Directory by finding the record of "ZIP Central Directory End" at the end of the file, and then read the starting offset of "Central Directory" from this record. Through the magic value, you can quickly determine that the "central directory" may be preceded by "APK signature block" Then, through the value of the block size, the starting position of the block in the file can be effectively found.
The design of v3 scheme is very similar to that of v2 scheme, which adopts the same conventional format and supports the same signature algorithm ID, key size and EC curve.
However, the v3 scheme adds information about supported SDK versions and rotation proof structures.
"APK signature scheme v2 block" is stored in "APK signature block", and its ID is 0xf05368c0.
"v3 block of APK signature scheme" adopts the format of v2:
The rotating certificate structure allows applications to sign certificates in turn without communicating these certificates with other applications. To do this, the application signature needs to contain two new data blocks:
The rotation proof attribute in the signature data section contains a single linked list, in which each node contains a signing certificate used to sign the previous version of the application. This attribute is intended to contain conceptual rotation proof and self-trust old certificate data structure. The single linked list is sorted by version, and the oldest signature certificate corresponds to the root node. When constructing the rotating proof data structure, the system will make the certificate in each node sign the next certificate in the list, thus providing evidence for each new key, proving that it should be as trustworthy as the old key.
When building the self-trusted old certificate data structure, the system will add labels to each node to indicate its membership and attributes in the group. For example, there may be a flag indicating that the signing certificate on a given node is trustworthy and can obtain Android signing rights. This flag allows other applications signed by the old certificate to still be granted the signing permission defined by the application signed by the new signing certificate. Because the entire rotation proof attribute is located in the signature data part of the v3 signer field, the key used to sign the included APK will protect this attribute.
This format excludes the case of multiple signature keys and the case of aggregating different ancestral signature certificates into one certificate (multiple starting nodes point to a common receiver).
The rotation certificate is stored in "v3 block of APK signature scheme" with the ID of 0x3ba06f8c. Its format is:
At present, Android regards APK signed with multiple certificates as having different signing identities from the included certificates. Therefore, the rotation proof attribute in the signature data part constitutes a directed acyclic graph, which is best regarded as a single linked list, in which each group of signers in a given version represents a node. This brings additional complexity to the rotating proof structure (the following multi-signer version). Sorting has become a particularly prominent problem. More importantly, APK can no longer sign separately, because the rotating certificate structure must let the old signing certificates sign the new certificate set, instead of signing them one by one.
For example, if you want APK signed by two new keys B and C to be signed by key A, it can't let the signer of B only contain the signature of A or B, because this is a different signature identity from B and C ... This means that the signers must coordinate before establishing such a structure.
Rotation proof properties of multiple signers
V3 scheme can't handle the situation that two different keys are rotated to the same signature key of the same application. This is different from the acquisition situation, in which the acquisition company wants to transfer the acquired application to use its signing key to enjoy rights. Acquisition is regarded as a supported use case because new applications will be distinguished by their package names and can contain their own rotation proof structures. The unsupported use case is that the same application has two different paths to the same certificate, which breaks many assumptions made in the key rotation design.
In Android 9 and later versions, APK can be verified according to APK signature schemes v3, v2 or v 1. The old platform will ignore the v3 signature and try to verify the v2 signature, and then try to verify the v 1 signature.