Android簽名機制


    為了說明APK簽名比對對軟體安全的有效性，我們有必要了解一下Android APK的簽名機制。為了更易於大家理解，我們從Auto-Sign工具的一條批處理命令說起。
    我們瞭解到，要簽名一個沒有簽名過的APK，可以使用一個叫作Auto-sign的工具。Auto-sign工具實際執行的是一個叫做Sign.bat的批處理命令。用文字編輯器開啟這個批處理檔案，我們可以發現，實現簽名功能的命令主要是這一行命令：
    java -jar signapk.jar testkey.x509.pem testkey.pk8 update.apk update_signed.apk


    這條命令的意義是：通過signapk.jar這個可執行jar包，以“testkey.x509.pem”這個公鑰檔案和“testkey.pk8”這個私鑰檔案對“update.apk”進行簽名，簽名後的檔案儲存為“update_signed.apk”。
    對於此處所使用的私鑰和公鑰的生成方式，這裡就不做進一步介紹了。這方面的資料大家可以找到很多。我們這裡要講的是signapk.jar到底做了什麼。
    signapk.jar是Android原始碼包中的一個簽名工具。由於Android是個開源專案，所以，很高興地，我們可以直接找到signapk.jar的原始碼！路徑為/build/tools/signapk/SignApk.java。
對比一個沒有簽名的APK和一個簽名好的APK，我們會發現，簽名好的APK包中多了一個叫做META-INF的資料夾。裡面有三個檔案，分別名為MANIFEST.MF、CERT.SF和CERT.RSA。signapk.jar就是生成了這幾個檔案（其他檔案沒有任何改變。因此我們可以很容易去掉原有簽名信息）。
    通過閱讀signapk原始碼，我們可以理清簽名APK包的整個過程。


1、 生成MANIFEST.MF檔案：
程式遍歷update.apk包中的所有檔案(entry)，對非資料夾非簽名檔案的檔案，逐個生成SHA1的數字簽名信息，再用Base64進行編碼。具體程式碼見這個方法：
    private static Manifest addDigestsToManifest(JarFile jar)

關鍵程式碼如下：

for (JarEntry entry : byName.values()) {
	String name = entry.getName();
	if (!entry.isDirectory() && !name.equals(JarFile.MANIFEST_NAME) && !name.equals(CERT_SF_NAME)
			&& !name.equals(CERT_RSA_NAME) && (stripPattern == null || !stripPattern.matcher(name).matches())) {
		InputStream data = jar.getInputStream(entry);
		while ((num = data.read(buffer)) > 0) {
			md.update(buffer, 0, num);
		}
		Attributes attr = null;
		if (input != null)
			attr = input.getAttributes(name);
		attr = attr != null ? new Attributes(attr) : new Attributes();
		attr.putValue("SHA1-Digest", base64.encode(md.digest()));
		output.getEntries().put(name, attr);
	}
}
 

    之後將生成的簽名寫入MANIFEST.MF檔案。關鍵程式碼如下：

Manifest manifest = addDigestsToManifest(inputJar);
je = new JarEntry(JarFile.MANIFEST_NAME);
je.setTime(timestamp);
outputJar.putNextEntry(je);
manifest.write(outputJar);

    這裡簡單介紹下SHA1數字簽名。簡單地說，它就是一種安全雜湊演算法，類似於MD5演算法。它把任意長度的輸入，通過雜湊演算法變成固定長度的輸出（這裡我們稱作“摘要資訊”）。你不能僅通過這個摘要資訊復原原來的資訊。另外，它保證不同資訊的摘要資訊彼此不同。因此，如果你改變了apk包中的檔案，那麼在apk安裝校驗時，改變後的檔案摘要資訊與MANIFEST.MF的檢驗資訊不同，於是程式就不能成功安裝。


2、 生成CERT.SF檔案：
對前一步生成的Manifest，使用SHA1-RSA演算法，用私鑰進行簽名。關鍵程式碼如下：

Signature signature = Signature.getInstance("SHA1withRSA");
signature.initSign(privateKey);
je = new JarEntry(CERT_SF_NAME);
je.setTime(timestamp);
outputJar.putNextEntry(je);
writeSignatureFile(manifest, new SignatureOutputStream(outputJar, signature));
 

    RSA是一種非對稱加密演算法。用私鑰通過RSA演算法對摘要資訊進行加密。在安裝時只能使用公鑰才能解密它。解密之後，將它與未加密的摘要資訊進行對比，如果相符，則表明內容沒有被異常修改。


3、 生成CERT.RSA檔案：
生成MANIFEST.MF沒有使用金鑰資訊，生成CERT.SF檔案使用了私鑰檔案。那麼我們可以很容易猜測到，CERT.RSA檔案的生成肯定和公鑰相關。
CERT.RSA檔案中儲存了公鑰、所採用的加密演算法等資訊。核心程式碼如下：

je = new JarEntry(CERT_RSA_NAME);
je.setTime(timestamp);
outputJar.putNextEntry(je);
writeSignatureBlock(signature, publicKey, outputJar);

    其中writeSignatureBlock的程式碼如下：

private static void writeSignatureBlock(Signature signature, X509Certificate publicKey, OutputStream out)
throws IOException, GeneralSecurityException {
SignerInfo signerInfo = new SignerInfo(new X500Name(publicKey.getIssuerX500Principal().getName()),
publicKey.getSerialNumber(), AlgorithmId.get("SHA1"), AlgorithmId.get("RSA"), signature.sign());

PKCS7 pkcs7 = new PKCS7(new AlgorithmId[] { AlgorithmId.get("SHA1") },
new ContentInfo(ContentInfo.DATA_OID, null), new X509Certificate[] { publicKey },
new SignerInfo[] { signerInfo });

pkcs7.encodeSignedData(out);
}

    好了，分析完APK包的簽名流程，我們可以清楚地意識到：
1、 Android簽名機制其實是對APK包完整性和釋出機構唯一性的一種校驗機制。
2、 Android簽名機制不能阻止APK包被修改，但修改後的再簽名無法與原先的簽名保持一致。（擁有私鑰的情況除外）。
3、 APK包加密的公鑰就打包在APK包內，且不同的私鑰對應不同的公鑰。換句話言之，不同的私鑰簽名的APK公鑰也必不相同。所以我們可以根據公鑰的對比，來判斷私鑰是否一致。


APK簽名比對的實現方式


    好了，通過Android簽名機制的分析，我們從理論上證明了通過APK公鑰的比對能判斷一個APK的釋出機構。並且這個釋出機構是很難偽裝的，我們暫時可以認為是不可偽裝的。
    有了理論基礎後，我們就可以開始實踐了。那麼如何獲取到APK檔案的公鑰資訊呢？因為Android系統安裝程式肯定會獲取APK資訊進行比對，所以我們可以通過Android原始碼獲得一些思路和幫助。
    原始碼中有一個隱藏的類用於APK包的解析。這個類叫PackageParser，路徑為frameworks\base\core\java\android\content\pm\PackageParser.java。當我們需要獲取APK包的相關資訊時，可以直接使用這個類，下面程式碼就是一個例子函式：

private PackageInfo parsePackage(String archiveFilePath, int flags) {
	PackageParser packageParser = new PackageParser(archiveFilePath);
	DisplayMetrics metrics = new DisplayMetrics();
	metrics.setToDefaults();
	final File sourceFile = new File(archiveFilePath);
	PackageParser.Package pkg = packageParser.parsePackage(sourceFile, archiveFilePath, metrics, 0);
	if (pkg == null) {
		return null;
	}
	packageParser.collectCertificates(pkg, 0);
	return PackageParser.generatePackageInfo(pkg, null, flags, 0, 0);
}

    其中引數archiveFilePath指定APK檔案路徑；flags需設定PackageManager.GET_SIGNATURES位，以保證返回證書籤名資訊。
    具體如何通過PackageParser獲取簽名信息在此處不做詳述，具體程式碼請參考PackageParser中的public boolean collectCertificates(Package pkg, int flags)和private Certificate[] loadCertificates(JarFile jarFile, JarEntry je, byte[] readBuffer)方法。至於如何在Android應用開發中使用隱藏的類及方法，可以參看我的這篇文章：《Android應用開發中如何使用隱藏API》。
    緊接著，我們就可以通過packageInfo.signatures來訪問到APK的簽名信息。還需要說明的是 Android中Signature和Java中Certificate的對應關係。它們的關係如下面程式碼所示：

pkg.mSignatures = new Signature[certs.length];
for (int i=0; i<N; i++) {
    pkg.mSignatures[i] = new Signature(
    certs[i].getEncoded());
}

    也就是說signature = new Signature(certificate.getEncoded()); certificate證書中包含了公鑰和證書的其他基本資訊。公鑰不同，證書肯定互不相同。我們可以通過certificate的getPublicKey方法獲取公鑰資訊。所以比對簽名證書本質上就是比對公鑰資訊。
    OK，獲取到APK簽名證書之後，就剩下比對了。這個簡單，功能函式如下所示:

private boolean IsSignaturesSame(Signature[] s1, Signature[] s2) {
	if (s1 == null) {
		return false;
	}
	if (s2 == null) {
		return false;
	}
	HashSet<Signature> set1 = new HashSet<Signature>();
	for (Signature sig : s1) {
		set1.add(sig);
	}
	HashSet<Signature> set2 = new HashSet<Signature>();
	for (Signature sig : s2) {
		set2.add(sig);
	}
	// Make sure s2 contains all signatures in s1.
	if (set1.equals(set2)) {
		return true;
	}
	return false;
}

APK簽名比對的應用場景
    經過以上的論述，想必大家已經明白簽名比對的原理和我的實現方式了。那麼什麼時候什麼情況適合使用簽名對比來保障Android APK的軟體安全呢？
    個人認為主要有以下三種場景：
1、 程式自檢測。在程式執行時，自我進行簽名比對。比對樣本可以存放在APK包內，也可存放於雲端。缺點是程式被破解時，自檢測功能同樣可能遭到破壞，使其失效。
2、 可信賴的第三方檢測。由可信賴的第三方程式負責APK的軟體安全問題。對比樣本由第三方收集，放在雲端。這種方式適用於防毒安全軟體或者APP Market之類的軟體下載市場。缺點是需要聯網檢測，在無網路情況下無法實現功能。（不可能把大量的簽名資料放在移動裝置本地）。
3、 系統限定安裝。這就涉及到改Android系統了。限定僅能安裝某些證書的APK。軟體釋出商需要向系統釋出上申請證書。如果發現問題，能追蹤到是哪個軟體釋出商的責任。適用於系統提供商或者終端產品生產商。缺點是過於封閉，不利於系統的開放性。
以上三種場景，雖然各有缺點，但缺點並不是不能克服的。例如，我們可以考慮程式自檢測的功能用native method的方法實現等等。軟體安全是一個複雜的課題，往往需要多種技術聯合使用，才能更好的保障軟體不被惡意破壞。