Basic concepts
Signature: Write a "fingerprint" in the APK. After the fingerprint is written, any modification in the APK will cause the fingerprint to be invalid. The Android system will fail the signature verification when installing the APK, thus ensuring security.
Digest algorithm: Use a simple seemingly random irreversible fixed-length string to represent the uniqueness of a file. Common digest algorithms include MD5 (128 bits) and SHA-1 algorithm (160/192/256 bits).
Public key cryptography: also called asymmetric algorithm, its characteristic is that the public key is public and the private key is confidential. Common ones are: RSA.
Let’s discuss RSA:
Signature scheme in Android
V1: Based on jarsigner (JDK’s own tool, using keystore file for signing) or apksigner ( Specifically provided by Android, using pk8, x509.pem for signature). keystore and pk8/x509.pem can be converted to each other.
Signature principle: First, the keystore file contains an MD5 and a SHA1 digest. This is also the summary data that many open platforms require us to upload.
After signing the APK, three files, CERT.RSA, CERT.SF, and MANIFEST.MF, will be produced in the META-INF folder.
In the apk, the signature information of the apk is stored in the /META-INF folder, which generally contains at least three files, [CERT].RSA, [CERT].SF and MANIFEIST.MF files. These three files are the signature information for the apk.
MANIFEST.MF contains signature values ??for all files in the apk except the /META-INF folder. The signature method is SHA1() (or other hash method) first and then base64(). The storage format is: Name plus [SHA1]-Digest.
[CERT].SF is the overall signature of the MANIFEST.MF file and the signature of each entry in it. Generally, if a tool signature is used, one more item is included. It is the signature of the MANIFEST.MF header information, which has been mentioned in the previous source code analysis.
[CERT].RSA contains a signature of [CERT].SF with the private key and a digital certificate containing the public key information.
? Is there a possibility of signature forgery:
If the files in the apk are modified (including additions, deletions and modifications), then: the digest value of the file calculated during verification is the same as the MANIFEST.MF file The entries in do not match and fail.
Modify the file + MANIFEST.MF in the apk, then: the summary of the modified entry in MANIFEST.MF does not match the entry corresponding to [CERT].SF, and it fails.
Modify the file +MANIFEST.MF+[CERT].SF in the apk, then: the calculated [CERT].SF signature does not match the signature value recorded in [CERT].RSA, and it fails.
Modify the file +MANIFEST.MF+[CERT].SF+[CERT].RSA in the apk, then: since the certificate cannot be forged, [CERT].RSA cannot be forged.
V2: New in 7.0
The signed package will be divided into four parts
1. Contents of ZIP entries (from offset 0 until the start of APK Signing Block)
2. APK Signing Block
3. ZIP Central Directory
4. ZIP End of Central Directory
The signature information of the new application signature scheme will be stored in Block 2 (APK Signing Block), while Block 1 (Contents of ZIP entries), Block 3 (ZIP Central Directory), and Block 4 (ZIP End of Central Directory ) is protected, and any modifications to blocks 1, 3, and 4 after signing cannot escape the inspection of the new application signature scheme.
V3: New in 9.0
The format is generally similar to v2. In the signature block (Apk Signature Block v2) inserted in v2, a new block (Attr block) is added .
In this new block, our previous signature information and new signature information will be recorded, and the key wheel scheme will be used to replace and upgrade the signature. This means that as long as the old signing certificate is in hand, we can use it to change the signature in the new APK file.
The new block (attr) added to v3 signature stores all signature information, which is stored in the form of a linked list in smaller Level blocks.
Each node contains a signing certificate used to sign previous versions of the application. The oldest signing certificate corresponds to the root node. The system will let the certificate in each node sign the next certificate in the list. , thereby providing each new key with evidence that it should be as trustworthy as the old key.
This process is somewhat similar to the certification process of the CA certificate. The old signature of the installed App ensures that the new signature covering the installed APK is correct and the trust is passed on.
Note: The signature method only supports upgrades and not downgrades. If a V2 package is installed, it cannot overwrite the package replaced by V1.
Reference
Android App signature (certificate) verification process source code analysis
New generation open source Android channel package generation tool Walle
Android Signature mechanism v1, v2, v3