I think this represents a good answer.
APK Signature Scheme v2 verification
APK Signing Block
and verify that:
APK Signing Block
contain the same value.ZIP Central Directory
is immediately followed by ZIP End of Central Directory
record.ZIP End of Central Directory
is not followed by more data.APK Signature Scheme v2 Block
inside the APK Signing Block
. If the v2 Block if present, proceed to step 3. Otherwise, fall back to verifying the APK using v1 scheme.APK Signature Scheme v2 Block
:
SubjectPublicKeyInfo
of the first certificate of certificates is identical to public key.Note: APK must not be verified using the v1 scheme if a failure occurs in step 3 or 4.
JAR-signed APK verification (v1 scheme)
The JAR-signed APK is a standard signed JAR, which must contain exactly the entries listed in META-INF/MANIFEST.MF
and where all entries must be signed by the same set of signers. Its integrity is verified as follows:
META-INF/<signer>.SF
and META-INF/<signer>.(RSA|DSA|EC)
JAR entry.<signer>.(RSA|DSA|EC)
is a PKCS #7 CMS ContentInfo
with SignedData structure whose signature is verified over the <signer>.SF
file.<signer>.SF
file contains a whole-file digest of the META-INF/MANIFEST.MF
and digests of each section of META-INF/MANIFEST.MF
. The whole-file digest of the MANIFEST.MF
is verified. If that fails, the digest of each MANIFEST.MF
section is verified instead.META-INF/MANIFEST.MF
contains, for each integrity-protected JAR entry, a correspondingly named section containing the digest of the entry’s uncompressed contents. All these digests are verified.MANIFEST.MF
and are not part of JAR signature.
The protection chain is thus <signer>.(RSA|DSA|EC)
? <signer>.SF
? MANIFEST.MF
? contents of each integrity-protected JAR entry.