pms包管理服务分析-证书校验流程

Apk签名后，apk文件目录下生成了一个名为META-INF目录，里面有三个文件，分别是MANIFEST.MF, CERT.SF和CERT.RSA;

其中MANIFEST.MF中记录的是apk中所有文件的摘要值；CERT.SF中记录的是对MANIFEST.MF的摘要值，包括整个文件的摘要，还有文件中每一项的摘要；而CERT.RSA中记录的是对CERT.SF文件的签名，以及签名的公钥。这个目录下的签名文件是如何解析和校验的呢，我们回到pms的scanPackageLI方法。

[/frameworks/base/services/core/java/com/android/server/pm/PackageManagerService.java]

    /*
     *  Scan a package and return the newly parsed package.
     *  Returns null in case of errors and the error code is stored in mLastScanError
     */
    private PackageParser.Package scanPackageLI(File scanFile, int parseFlags, int scanFlags,
            long currentTime, UserHandle user) throws PackageManagerException {
        if (DEBUG_INSTALL) Slog.d(TAG, "Parsing: " + scanFile);
        …
         // Verify certificates against what was last scanned
        collectCertificatesLI(pp, ps, pkg, scanFile, parseFlags);
        …
}

这里调用了collectCertificatesLI方法，传入pkg以及pkg目录，继续分析该方法：

[/frameworks/base/services/core/java/com/android/server/pm/PackageManagerService.java]

    private void collectCertificatesLI(PackageParser pp, PackageSetting ps, PackageParser.Package pkg, 
File srcFile, int parseFlags) throws PackageManagerException {
        if (ps != null && ps.codePath.equals(srcFile) && ps.timeStamp == srcFile.lastModified()
                && !isCompatSignatureUpdateNeeded(pkg) && !isRecoverSignatureUpdateNeeded(pkg)) {
            long mSigningKeySetId = ps.keySetData.getProperSigningKeySet();
            if (ps.signatures.mSignatures != null && ps.signatures.mSignatures.length != 0
                    && mSigningKeySetId != PackageKeySetData.KEYSET_UNASSIGNED) {
                pkg.mSignatures = ps.signatures.mSignatures;
                KeySetManagerService ksms = mSettings.mKeySetManagerService;
                synchronized (mPackages) {
                    pkg.mSigningKeys = ksms.getPublicKeysFromKeySetLPr(mSigningKeySetId);
                }
                return;
            }
        } 
        try {
            pp.collectCertificates(pkg, parseFlags);
            pp.collectManifestDigest(pkg);
        } catch (PackageParserException e) {
            throw PackageManagerException.from(e);
        }
    }

collectCertificatesLI方法中首先判断当前packages.xml是否存在，如果存在则把之前保存的apk签名信息取出并赋值给pkg。否则调用PackageParser的collertCertficates和collectManifestDigest方法分别解析手机apk的签名信息。

继续分析PackageParser里面的这两个方法：

[/frameworks/base/services/core/java/com/android/server/pm/PackageParser.java]

    public void collectCertificates(Package pkg, int flags) throws PackageParserException {
        pkg.mCertificates = null;
        pkg.mSignatures = null;
        pkg.mSigningKeys = null;
        collectCertificates(pkg, new File(pkg.baseCodePath), flags);
        …
  }

接着调用collectCertificates的一个重载版本：

    private static void collectCertificates(Package pkg, File apkFile, int flags)
            throws PackageParserException {
        final String apkPath = apkFile.getAbsolutePath();
        StrictJarFile jarFile = null;
        try {
            jarFile = new StrictJarFile(apkPath);
            …

方法的开头，首先创建了一个StrictJarFile（代码位于libcore\luni\src\main\java\java\util\jar\StrictJarFile.java，编译后存在于core.jar文件中）对象，先来看看其构造函数中的内容：

[libcore/luni/src/main/java/java/util/jar/StrictJarFile.java]

    public StrictJarFile(String fileName) throws IOException {
        …
        try {
            HashMap<String, byte[]> metaEntries = getMetaEntries();
            this.manifest = new Manifest(metaEntries.get(JarFile.MANIFEST_NAME), true);
            this.verifier = new JarVerifier(fileName, manifest, metaEntries);
        isSigned = verifier.readCertificates() && verifier.isSignedJar();
    …
}

这里构造了几个重要的对象。首先，获得了META-INF目录下所有文件名及其字节流。然后是构造了一个manifest对象，主要是用来处理对META-INF目录下MANIFEST.MF文件的操作。接着，构造了一个JarVeirifer（代码位于libcore\luni\src\main\java \java\util\jar\JarVerifier.java文件中，编译后存在于core.jar文件中）对象，这个对象主要实现了对Jar文件的验证工作，非常关键，后面的分析中会逐步提到。在构造函数的最后，调用了JarVeirifer.readCertificates函数：

[libcore/luni/src/main/java /java/util/jar/JarVerifier.java]

synchronized boolean readCertificates() {  
    if (metaEntries.isEmpty()) {  
        return false;  
    }  
  
    Iterator<String> it = metaEntries.keySet().iterator();  
    while (it.hasNext()) {  
        String key = it.next();  
        if (key.endsWith(".DSA") || key.endsWith(".RSA") || key.endsWith(".EC")) {  
            verifyCertificate(key);  
            it.remove();  
        }  
    }  
    return true;  
}

代码遍历所有META-INF目录下的文件，找到以.DSA、.RSA或者.EC结尾的文件，以这些名字结尾的文件都是所谓的签名证书文件。在本例中对应的是META-INF目录下的CERT.RSA签名文件。然后调用JarVeirifer.verifyCertificate函数：

[libcore/luni/src/main/java /java/util/jar/JarVerifier.java]

private void verifyCertificate(String certFile) {  
    String signatureFile = certFile.substring(0, certFile.lastIndexOf('.')) + ".SF";  
    byte[] sfBytes = metaEntries.get(signatureFile);  
    if (sfBytes == null) {  
        return;  
    }  
    ……  
    byte[] sBlockBytes = metaEntries.get(certFile);  
    try {  
       Certificate[] signerCertChain = JarUtils.verifySignature( new ByteArrayInputStream(sfBytes),  
                    new ByteArrayInputStream(sBlockBytes));  
        if (signerCertChain != null) {  
            certificates.put(signatureFile, signerCertChain);  
        }  
    } 
    ……

函数开头，首先找到与证书文件同名，但是以.SF结尾的签名文件，本例中即为META-INF目录下的CERT.SF文件。然后分别获得签名文件CERT.SF和证书文件CERT.RSA的字节流，调用JarUtils（代码位于libcore\luni\src\main\java\org\apache\harmony\security\utils\JarUtils.java文件中，编译后存在于core.jar文件中）的verifySignature函数，验证CERT.RSA文件中包含的对CERT.SF文件的签名是否正确。如果验证失败，则会抛出GeneralSecurityException异常；而如果验证成功，则会返回签名的证书链。回到JarVeirifer.verifyCertificate函数，如果JarUtils.verifySignature验证失败抛出异常，被捕获后会接着向上抛出SecurityException异常；

如果签名验证成功的话，会将证书链保存在certifcates属性变量中。而JarVerifier自己的isSignedJar函数，就是判断一下这个certificates属性变量是否为空。

boolean isSignedJar() {  
    return certificates.size() > 0;  
}

如果不为空就代表这个Jar是签过名的，如果为空则代表其没有签过名。

继续分析JarVeirifer.verifyCertificate函数：

 ……  
Attributes attributes = new Attributes();  
HashMap<String, Attributes> entries = new HashMap<String, Attributes>();  
try {  
    ManifestReader im = new ManifestReader(sfBytes, attributes);  
    im.readEntries(entries, null);  
} catch (IOException e) {  
    return;  
}    
if (attributes.get(Attributes.Name.SIGNATURE_VERSION) == null) {  
    return;  
}    
boolean createdBySigntool = false;  
String createdBy = attributes.getValue("Created-By");  
if (createdBy != null) {  
    createdBySigntool = createdBy.indexOf("signtool") != -1;  
}  
……

函数接下来读取了签名文件，也就是META-INF目录下CERT.SF文件中的内容。CERT.SF文件内容大致如下：

首先判断了是否有“Signature-Version”属性，如果没有的话，直接返回。再下来判断apk是否是由签名工具签的名，判断条件就是在“Created-By”属性值内有没有“signtool”字符串。本例中，签名版本是“1.0”，并且不是用其它签名工具签的名。如果不是用其它工具签名的话，接下来还会验证主属性中是否有“SHA1-Digest-Manifest-Main-Attributes”属性的值，这个属性值记录的是对META-INF目录下MANIFEST.MF文件内，头属性块的hash值。

……  
byte[] manifestBytes = metaEntries.get(JarFile.MANIFEST_NAME);  
if (manifestBytes == null) {  
    return;  
}  
……  
if (mainAttributesEnd > 0 && !createdBySigntool) {  
    String digestAttribute = "-Digest-Manifest-Main-Attributes";  
    if (!verify(attributes, digestAttribute, manifestBytes, 0, mainAttributesEnd, false, true)) {  
        throw failedVerification(jarName, signatureFile);  
    }  
}  
……

接着调用了JarVerifier.verify对该摘要值进行验证：

private boolean verify(Attributes attributes, String entry, byte[] data,  
            int start, int end, boolean ignoreSecondEndline, boolean ignorable) {  
    for (int i = 0; i < DIGEST_ALGORITHMS.length; i++) {  
        String algorithm = DIGEST_ALGORITHMS[i];  
        String hash = attributes.getValue(algorithm + entry);  
        if (hash == null) {  
            continue;  
        }    
        MessageDigest md;  
        try {  
            md = MessageDigest.getInstance(algorithm);  
        } catch (NoSuchAlgorithmException e) {  
            continue;  
        }  
        if (ignoreSecondEndline && data[end - 1] == '\n' && data[end - 2] == '\n') {  
            md.update(data, start, end - 1 - start);  
        } else { 
            md.update(data, start, end - start);  
        }  
        byte[] b = md.digest();  
        byte[] hashBytes = hash.getBytes(StandardCharsets.ISO_8859_1);  
        return MessageDigest.isEqual(b, Base64.decode(hashBytes));  
    }  
    return ignorable;  
}

JarVerifier.verify函数很简单，由于不知道到底是用什么算法算出的散列值，所以其会遍历所有的可能算法。这些算法都预先定义在DIGEST_ALGORITHMS这个JarVerifier内的静态字符串数组变量中：

private static final String[] DIGEST_ALGORITHMS = new String[] {  
    "SHA-512",  
    "SHA-384",  
    "SHA-256",  
    "SHA1",  
};

可以看出，一共支持四种算法，本例中用到的是SHA1摘要算法。变量attributes表示的是一个属性块，而变量entry是要在attributes属性块中查找的属性名的一部分，它会与摘要算法的名称拼接成正真的属性名。接着会将在属性块中，对应属性名的属性值取出来，与data数据块中start到end之间的数据，用同样算法算出的摘要值进行比较，如果一致就返回“true”，不一致则返回“false”。

    ……  
    String digestAttribute = createdBySigntool ? "-Digest" : "-Digest-Manifest";  
    if (!verify(attributes, digestAttribute, manifestBytes, 0, manifestBytes.length, false, false)) {  
        Iterator<Map.Entry<String, Attributes>> it = entries.entrySet().iterator();  
        while (it.hasNext()) {  
            Map.Entry<String, Attributes> entry = it.next();  
            Manifest.Chunk chunk = manifest.getChunk(entry.getKey());  
            if (chunk == null) {  
                return;  
            }  
            if (!verify(entry.getValue(), "-Digest", manifestBytes,  
                    chunk.start, chunk.end, createdBySigntool, false)) {  
                throw invalidDigest(signatureFile, entry.getKey(), jarName);  
            }  
        }  
    }  
    metaEntries.put(signatureFile, null);  
    signatures.put(signatureFile, entries);  
}

JarVeirifer.verifyCertificate剩下的代码就很简单了，会比较MANIFEST.MF文件的整体摘要值和每一个属性块的摘要值，与CERT.SF文件中记录的是否一致。如果都验证通过的话，会将该签名文件的信息加到metaEntries和signatures属性变量中去。所以，在StrictJarFile构造的过程中就已经完成了两步验证：一是通过在CERT.RSA文件中记录的签名信息，验证了CERT.SF没有被篡改过；二是通过CERT.SF文件中记录的摘要值，验证了MANIFEST.MF没有被修改过。

回到PackageParser的collectCertificates方法中：

[/frameworks/base/services/core/java/com/android/server/pm/PackageParser.java]

……  
final ZipEntry manifestEntry = jarFile.findEntry(ANDROID_MANIFEST_FILENAME);  
if (manifestEntry == null) {  
   throw new PackageParserException(INSTALL_PARSE_FAILED_BAD_MANIFEST,"Package " + apkPath + " has no manifest");  
}    
final List<ZipEntry> toVerify = new ArrayList<>();  
toVerify.add(manifestEntry);    
if ((flags & PARSE_IS_SYSTEM) == 0) {  
    final Iterator<ZipEntry> i = jarFile.iterator();  
    while (i.hasNext()) {  
        final ZipEntry entry = i.next();    
        if (entry.isDirectory()) continue;  
        if (entry.getName().startsWith("META-INF/")) continue;  
        if (entry.getName().equals(ANDROID_MANIFEST_FILENAME)) continue;    
        toVerify.add(entry);  
    }  
}  
……

接下来的代码主要是用来确定，到底哪些文件需要进行验证。AndroidManifest.xml无论如何都要验证。如果不是系统，也就是普通的应用程序安装，必须要验证除去位于META-INF目录下所有文件之外的所有剩下的文件。

……  
for (ZipEntry entry : toVerify) {  
    final Certificate[][] entryCerts = loadCertificates(jarFile, entry);  
    if (ArrayUtils.isEmpty(entryCerts)) {  
        throw new PackageParserException(INSTALL_PARSE_FAILED_NO_CERTIFICATES,  
                    "Package " + apkPath + " has no certificates at entry " + entry.getName());  
    }  
    final Signature[] entrySignatures = convertToSignatures(entryCerts);  
    ……

接着是逐项验证前面罗列出的apk中的各个文件。对每个文件，都接着调用了PackageParser.loadCertificates函数：

private static Certificate[][] loadCertificates(StrictJarFile jarFile, ZipEntry entry) throws ackageParserException{
    InputStream is = null;  
    try {  
        is = jarFile.getInputStream(entry);  
        readFullyIgnoringContents(is);  
        return jarFile.getCertificateChains(entry);  
     …

方法内对apk内的文件创建了一个输入流，并且通过函数PackageParser.readFullyIgnoringContents全读了一遍，而且通过函数名可以看出，具体读出什么内容并不重要。我们先来看看StrictJarFile.getInputStream函数：

public InputStream getInputStream(ZipEntry ze) {  
    final InputStream is = getZipInputStream(ze);    
    if (isSigned) {  
        JarVerifier.VerifierEntry entry = verifier.initEntry(ze.getName());  
        if (entry == null) {  
            return is;  
        }    
        return new JarFile.JarFileInputStream(is, ze.getSize(), entry);  
    }    
    return is;  
}

重点要关注两个函数调用，一是JarVerifier.initEntry，二是JarFile.JarFileInputStream。

initEntry函数主要的用途就是构造一个JarVerifer.VerifierEntry对象：要构造这个对象，必须事先准备好参数。第一个参数很简单，就是要验证的文件名，直接将name传进来就好了。第二个参数是计算摘要的对象，可以通过MessageDigest.getInstance获得，不过要先告知到底要用哪个摘要算法，同样也是通过查看MANIFEST.MF文件中对应名字的属性值来决定的。本例中的MANIFEST.MF文件格式大致如下：

所以可以知道所用的摘要算法是SHA1。第三个参数是对应文件的摘要值，这是通过读取MANIFEST.MF文件获得的。第四个参数是证书链，即对该apk文件签名的所有证书链信息。为什么是二维数组呢？这是因为Android允许用多个证书对apk进行签名，但是它们的证书文件名必须不同。最后一个参数是已经验证过的文件列表，VerifierEntry在完成了对指定文件的摘要验证之后会将该文件的信息加到其中。

通过digest就可以算出apk内指定文件的真实摘要值。而记录在MANIFEST.MF文件中对应该文件的摘要值，也在构造JarVerifier.VerifierEntry时传递给了hash变量。不过这个hash值是经过Base64编码的。所以在比较之前，必须通过Base64解码。如果不一致的话，会抛出SecurityException异常：

至此，最后一步验证，即apk内所有文件的摘要值要和在MANIFEST.MF文件中记录的一致，也已经完成了。这还没完，PackageParser.collectCertificates还要接着验证apk文件中的每个文件对应的签名要和第一个文件一致：

……  
if (pkg.mCertificates == null) {  
    pkg.mCertificates = entryCerts;  
    pkg.mSignatures = entrySignatures;  
    pkg.mSigningKeys = new ArraySet<PublicKey>();  
    for (int i=0; i < entryCerts.length; i++) {  
        pkg.mSigningKeys.add(entryCerts[i][0].getPublicKey());  
    }  
} 
……

最后将证书信息以Certificates, mSignatures, SigningKeys的形式保存到pkg中，并最终写入packages.xml供下次开机使用。

到这里，apk安装时的签名验证过程都已经分析完了，来总结一下：

1. 所有有关apk文件的签名验证工作都是在JarVerifier里面做的，一共分成三步；

2. JarVeirifer.verifyCertificate主要做了两步。首先，使用证书文件（在META-INF目录下，以.DSA、.RSA或者.EC结尾的文件）检验签名文件（在META-INF目录下，和证书文件同名，但扩展名为.SF的文件）是没有被修改过的。然后，使用签名文件，检验MANIFEST.MF文件中的内容也没有被篡改过；

3. JarVerifier.VerifierEntry.verify做了最后一步验证，即保证apk文件中包含的所有文件，对应的摘要值与MANIFEST.MF文件中记录的一致。

pms包管理服务分析-证书校验流程

猜你喜欢