<a href="http://jaq.alibaba.com/community/art/show?articleid=457">android安全開發之通用簽名風險</a>
1 通用簽名風險簡介
阿裡聚安全漏洞掃描器有一項檢測服務是檢測app的通用簽名風險。android系統要求安裝的應用必須用數字證書進行簽名後才能安裝，并且簽名證書的私鑰由應用開發者儲存。簽名證書的生成也由開發者自己生成。在應用安裝時會校驗包名（package name）和簽名，如果系統中已經存在了一個相同的包名和簽名的應用，将會用新安裝的應用替換舊的；如果包名相同但是簽名不同，則會安裝失敗。
為什麼需要數字簽名？
數字簽名是防止要保護的内容被篡改，用非對稱加密算法。先對要保護的内容進行消息摘要，用私鑰對消息摘要進行加密，生成數字簽名，将數字簽名和要保護的内容一起分發出去。 内容接收者用公鑰對數字簽名解密得到發送者給的消息摘要a，内容接收者對接收到的内容進行用相同的消息摘要算法處理得到消息摘要b，對比a和b是否相同，來判定傳送的内容是否被篡改。 正常的apk檔案是個zip壓縮檔案，除了應用的可執行檔案、資源檔案，還包括這些可執行檔案、資源檔案的摘要資訊，數字證書的公鑰資訊等。并且通過這些簽名資訊可以确定app和其開發者的關系。
進行簽名需要的工具有哪些？
對apk進行簽名需要用到簽名證書和簽名工具。android系統要求對app進行簽名的數字證書可以由開發者自己生成。簽名工具有jarsigner和signapk。jarsigner是java本身自帶的一個工具，他也可以對jar進行簽名的；而signapk是專門為了android應用程式apk進行簽名的工具。二者的差別是：jarsigner工具簽名時使用的是keystore簽名檔案，signapk工具簽名時使用的是pk8，x509.pem檔案。
簽名後的檔案都有哪些？
應用簽名完後在應用的meta-inf目錄下會有三個檔案：
cert.rsa、cert.sf和manifest.mf。
manifest.mf中儲存了所有其他檔案的sha1摘要并base64編碼後的值。
cert.sf檔案是對manifest.mf檔案中的每項中的每行加上“\r\n”後，再次sha1摘要并base64編碼後的值（這是為了防止通過篡改檔案和其在manifest.mf中對應的sha1摘要值來篡改apk，要對manifest的内容再進行一次數字摘要）。
cert.rsa檔案：包含了簽名證書的公鑰資訊和釋出機構資訊。
什麼是通用簽名？
搭建好android開發環境後（使用eclipse或android studio），對apk簽名的預設密鑰存在debug.keystore檔案中。在linux和mac上debug.keystore檔案位置是在~/.android路徑下，在windows目錄下檔案位置是c:\user\使用者名.android路徑下。
除了debug.keystore外，在aosp釋出的android源碼中，還有以下幾個證書是公開的，任何人都可以擷取，在源碼的build/target/product/security目錄中：
這幾個證書的作用：
testkey
generic default key for packages that do not otherwise specify a key.
platform
test key for packages that are part of the core platform.
shared
test key for things that are shared in the home/contacts process.
media
test key for packages that are part of the media/download system.
verity
test key for verifiedboot system imagein android lollipop. sign boot.img,sign verity metadata in system.img.
通用簽名風險：
（1）如果攻擊者的應用包名與目标應用相同，又使用了相同的密鑰對應用進行簽名，攻擊者的應用就可以替換掉目标應用；
（2）另外目标應用的自定義權限android:protectionlevel為“signature”或者“signatureorsystem”時，保護就形同虛設；
（3）如果裝置使用的是第三方rom，而第三方rom的系統也是用aosp預設的簽名，那麼使用如果使用系統級簽名檔案簽名過的應用，權限就得到了提升。
對于普通開發者如果自己的簽名證書洩露也可能發生(1)、(2)條所提到的風險。
使用通用簽名的公開案例非常少，不過我們阿裡聚安全漏洞掃描器還是發現了一些應用使用了通用簽名，掃描結果資料庫中查到曾經有819個app使用了aosp的簽名證書（排查了幾個app的最新版，但都已經用了新的簽名；也不排除應用被惡意攻擊者反編譯重打包後使用通用簽名證書簽名）。 另外還有不少私有簽名證書洩露、濫用的（使用通用簽名證書其實就相當于洩露了簽名證書）情況。
以烏雲公開的wooyun-2014-67027為例，有安全研究人員發現有一個數字證書簽名被很多銀行的手機用戶端所使用。與此同時還發現了幾款個人開發者類應用也使用了此證書簽名。而這種數字簽名被濫用的行為存在極大的安全隐患。
解壓應用安裝包，可用keytool檢視應用的簽名證書資訊：
keytool -printcert -v -file meta-inf/cert.rsa
經挖掘和分析，研究人員發現目前共有23款不同銀行手機銀行用戶端使用該簽名：
在應用市場内，目前共發現6款個人開發的應用同時使用該數字證書簽名：
事情發生的原因是銀行的外包開發管理不嚴，不同銀行的app居然用同樣的數字證書簽名，并且開發者還将證書用于了個人app的開發中。如果簽名證書被惡意攻擊者擷取，可以編寫安裝是能直接替換掉這些銀行用戶端的惡意app。
還可以使用aosp通用簽名提升應用權限：
本人直接編譯aosp源碼得到的rom，使用aosp的預設證書，在設定->關于手機，版本号中可檢視到：
對于普通的用預設debug.keystore證書簽名的app，如果在androidmanfiest.xml的manifest節點加入android:shareduserid=”android.uid.system”這個屬性，安裝時會提示錯誤：
如果對app-debug.apk使用aosp提供的platform.x509.pem和platform.pk8重新簽名，則可以安裝成功：
檢視應用的程序屬性，已是system使用者組。
目前有不少的第三方rom使用的aosp提供的預設簽名（見參考[4]的論文中所提）。
（1）上線前用阿裡聚安全的漏洞掃描器進行一下檢查。
阿裡聚安全的漏洞掃描器目前已能檢查出通用簽名風險，未來可能增加檢測證書是否洩漏風險。還可以發現其他安全風險。
（2） 生成自己專有的簽名證書，證書分類使用。
使用keytool工具生成.keystore的數字證書：
keytool -genkey -v -keystore my-release-key.keystore
-alias alias_name -keyalg rsa -keysize 2048 -validity 10000
使用jarsigner工具對打包好的apk進行簽名：
jarsigner -verbose -sigalg sha1withrsa -digestalg sha1
-keystore my-release-key.keystore my_application.apk alias_name
使用openssl生成pk8和x509.pm的證書，參考如下：
使用signapk工具和pk8、x509.pm證書對打包好的app簽名：
java -jar signapk.jar platform.x509.pem platform.pk8 input.apk output.apk
或者gradle打包配置設定：
（3）做好安全教育訓練，規範開發流程，證書之類的統一管理。
（4）個人開發者在往開源平台上傳代碼時，注意不要将簽名證書的私鑰上傳。
搜了下github，有不少開發者将其release版的keysotre上傳了，并且在gradle檔案上寫上了keystore的通路密碼。如下：
[4] min zheng，droidray: a security evaluation system for customized android firmwares
本文來自合作夥伴“阿裡聚安全”，發表于2016年08月08日 09:15.