1、 生成MANIFEST.MF文件:
程序遍历update.apk包中的所有文件(entry),对非文件夹非签名文件的文件,逐个生成SHA1的数字签名信息,再用Base64进行编码。具体代码见这个方法:
private static Manifest addDigestsToManifest(JarFile jar)
关键代码如下:
1 for (JarEntry entry: byName.values()) { 2 String name = entry.getName(); 3 if (!entry.isDirectory() && !name.equals(JarFile.MANIFEST_NAME) && 4 !name.equals(CERT_SF_NAME) && !name.equals(CERT_RSA_NAME) && 5 (stripPattern == null ||!stripPattern.matcher(name).matches())) 6 { 7 InputStream data = jar.getInputStream(entry); 8 while ((num = data.read(buffer)) > 0) { 9 md.update(buffer, 0, num); 10 } 11 Attributes attr = null; 12 if (input != null) attr = input.getAttributes(name); 13 attr = attr != null ? new Attributes(attr) : new Attributes(); 14 attr.putValue("SHA1-Digest", base64.encode(md.digest())); 15 output.getEntries().put(name, attr); 16 } 17 }
之后将生成的签名写入MANIFEST.MF文件。关键代码如下:
1 Manifest manifest = addDigestsToManifest(inputJar); 2 je = new JarEntry(JarFile.MANIFEST_NAME); 3 je.setTime(timestamp); 4 outputJar.putNextEntry(je); 5 manifest.write(outputJar);
这里简单介绍下SHA1数字签名。简单地说, 它就是一种安全哈希算法,类似于MD5算法。它把任意长度的输入,通过散列算法变成固定长度的输出(这里我们称作“摘要信息”)。你不能仅通过这个摘要信息复原原来的信息。另外,它保证不同信息的摘要信息彼此不同。因此,如果你改变了apk包中的文件,那么在apk安装校验时,改变后的文件摘要信息与MANIFEST.MF的检验信息不同,于是程序就不能成功安装。
2、 生成CERT.SF文件:
对前一步生成的Manifest,使用SHA1-RSA算法,用私钥进行签名。关键代码如下:
1 Signature signature = Signature.getInstance("SHA1withRSA"); 2 signature.initSign(privateKey); 3 je = new JarEntry(CERT_SF_NAME); 4 je.setTime(timestamp); 5 outputJar.putNextEntry(je); 6 writeSignatureFile(manifest, 7 new SignatureOutputStream(outputJar, signature));
RSA是一种非对称加密算法。用私钥通过RSA算法对摘要信息进行加密,在安装时只能使用公钥才能解密它。解密之后,将它与未加密的摘要信息进行对比,如果相符,则表明内容没有被异常修改。
3、 生成CERT.RSA文件:
生成MANIFEST.MF没有使用密钥信息,生成CERT.SF文件使用了私钥文件。那么我们可以很容易猜测到,CERT.RSA文件的生成肯定和公钥相关。
CERT.RSA文件中保存了公钥、所采用的加密算法等信息。核心代码如下:
1 je = new JarEntry(CERT_RSA_NAME); 2 je.setTime(timestamp); 3 outputJar.putNextEntry(je); 4 writeSignatureBlock(signature, publicKey, outputJar);
其中writeSignatureBlock的代码如下:
1 private static void writeSignatureBlock( 2 Signature signature, X509Certificate publicKey, OutputStream out) 3 throws IOException, GeneralSecurityException { 4 SignerInfo signerInfo = new SignerInfo( 5 new X500Name(publicKey.getIssuerX500Principal().getName()), 6 publicKey.getSerialNumber(), 7 AlgorithmId.get("SHA1"), 8 AlgorithmId.get("RSA"), 9 signature.sign()); 10 11 PKCS7 pkcs7 = new PKCS7( 12 new AlgorithmId[] { AlgorithmId.get("SHA1") }, 13 new ContentInfo(ContentInfo.DATA_OID, null), 14 new X509Certificate[] { publicKey }, 15 new SignerInfo[] { signerInfo }); 16 17 pkcs7.encodeSignedData(out); 18 }
好了,分析完APK包的签名流程,我们可以清楚地意识到:
1、 Android签名机制其实是对APK包完整性和发布机构唯一性的一种校验机制。
2、 Android签名机制不能阻止APK包被修改,但修改后的再签名无法与原先的签名保持一致。(拥有私钥的情况除外)。
3、 APK包加密的公钥就打包在APK包内,且不同的私钥对应不同的公钥。换句话言之,不同的私钥签名的APK公钥也必不相同。所以我们可以根据公钥的对比,来判断私钥是否一致。
好了,通过Android签名机制的分析,我们从理论上证明了通过APK公钥的比对能判断一个APK的发布机构。并且这个发布机构是很难伪装的,我们暂时可以认为是不可伪装的。
有了理论基础后,我们就可以开始实践了。那么如何获取到APK文件的公钥信息呢?因为Android系统安装程序肯定会获取APK信息进行比对,所以我们可以通过Android源码获得一些思路和帮助。
源码中有一个隐藏的类用于APK包的解析。这个类叫PackageParser,路径为frameworks\base\core\java\android\content\pm\PackageParser.java。当我们需要获取APK包的相关信息时,可以直接使用这个类,下面代码就是一个例子函数:
1 private PackageInfo parsePackage(String archiveFilePath, int flags){ 2 3 PackageParser packageParser = new PackageParser(archiveFilePath); 4 DisplayMetrics metrics = new DisplayMetrics(); 5 metrics.setToDefaults(); 6 final File sourceFile = new File(archiveFilePath); 7 PackageParser.Package pkg = packageParser.parsePackage( 8 sourceFile, archiveFilePath, metrics, 0); 9 if (pkg == null) { 10 return null; 11 } 12 13 packageParser.collectCertificates(pkg, 0); 14 15 return PackageParser.generatePackageInfo(pkg, null, flags, 0, 0); 16 }
其中参数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的对应关系。它们的关系如下面代码所示:
1 pkg.mSignatures = new Signature[certs.length]; 2 for (int i=0; i<N; i++) { 3 pkg.mSignatures[i] = new Signature( 4 certs[i].getEncoded()); 5 }
也就是说signature = new Signature(certificate.getEncoded()); certificate证书中包含了公钥和证书的其他基本信息。公钥不同,证书肯定互不相同。我们可以通过certificate的getPublicKey方法获取公钥信息。所以比对签名证书本质上就是比对公钥信息。
OK,获取到APK签名证书之后,就剩下比对了。这个简单,功能函数如下所示:
1 private boolean IsSignaturesSame(Signature[] s1, Signature[] s2) { 2 if (s1 == null) { 3 return false; 4 } 5 if (s2 == null) { 6 return false; 7 } 8 HashSet<Signature> set1 = new HashSet<Signature>(); 9 for (Signature sig : s1) { 10 set1.add(sig); 11 } 12 HashSet<Signature> set2 = new HashSet<Signature>(); 13 for (Signature sig : s2) { 14 set2.add(sig); 15 } 16 // Make sure s2 contains all signatures in s1. 17 if (set1.equals(set2)) { 18 return true; 19 } 20 return false; 21 }
APK签名比对的应用场景
经过以上的论述,想必大家已经明白签名比对的原理和我的实现方式了。那么什么时候什么情况适合使用签名对比来保障Android APK的软件安全呢?
个人认为主要有以下三种场景:
1、 程序自检测。在程序运行时,自我进行签名比对。比对样本可以存放在APK包内,也可存放于云端。缺点是程序被破解时,自检测功能同样可能遭到破坏,使其失效。
2、 可信赖的第三方检测。由可信赖的第三方程序负责APK的软件安全问题。对比样本由第三方收集,放在云端。这种方式适用于杀毒安全软件或者 APP Market之类的软件下载市场。缺点是需要联网检测,在无网络情况下无法实现功能。(不可能把大量的签名数据放在移动设备本地)。
3、 系统限定安装。这就涉及到改Android系统了。限定仅能安装某些证书的APK。软件发布商需要向系统发布上申请证书。如果发现问题,能追踪到是哪个软件发布商的责任。适用于系统提供商或者终端产品生产商。缺点是过于封闭,不利于系统的开放性。
以上三种场景,虽然各有缺点,但缺点并不是不能克服的。例如,我们可以考虑程序自检测的功能用native method的方法实现等等。软件安全是一个复杂的课题,往往需要多种技术联合使用,才能更好的保障软件不被恶意破坏。
Android源码
转载请注明出处:http://www.blogjava.net/zh-weir/archive/2011/07/19/354663.html