名稱解釋
代碼簽名是對可執行文件或腳本進行數字簽名.用來確認軟件的來源並保證在簽名后未被修改或損壞的措施。和數字簽名原理一樣,只不過簽名的數據是代碼而已.
為什么要使用代碼簽名？
在iOS出來之前,以前的主流操作系統軟件隨便從哪里下載都能運行,系統安全存在隱患,盜版軟件,病毒入侵,靜默安裝等等.蘋果希望解決這樣的問題,要保證每一個安裝到 iOS 上的 APP 都是經過蘋果官方允許的,保證方法就是通過代碼簽名。
實現原理
iOS代碼簽名機制
1.基本原理
代碼簽名的技術基礎是數字簽名，也就是非對稱加密算法。如果我們iOS設備安裝APP只通過App Store這一個途徑，代碼簽名的實現就很容易, 在iOS的系統中內置一個公鑰,私鑰由蘋果后台保存,我們傳APP到AppStore時,蘋果后台用私鑰對APP數據進行簽名,iOS系統下載這個APP后,用公鑰驗證這個簽名,若簽名正確,這個APP肯定是由蘋果后台認證的,並且沒有被修改過,也就達到了蘋果的需求:保證安裝的每一個APP都是經過蘋果官方允許的。
2.iOS的雙層簽名機制
實際上iOS應用的安裝除了app store，還有開發者調試和企業安裝兩種形式。對於這兩種安裝方式，他們具有以下需求
1）安裝包不需要上傳到App Store,可以直接安裝到手機上.
2）蘋果為了保證系統的安全性,又必須對安裝的APP有絕對的控制權：a.經過蘋果允許才可以安裝；b.不能被濫用導致非開發APP也能被安裝
於是，iOS采用的方案是雙層代碼簽名。
mac系統中有自身的非對稱加密的一對公私鑰，Xcode即可完成，這里稱為公鑰M和私鑰M；蘋果系統里有固定的一對公私鑰，私鑰在蘋果后台，公鑰在每個iOS系統里，這里稱為公鑰A和私鑰A。
首先，將公鑰M和一些開發者的信息傳到蘋果后台，這個就是申請證書時用到的CSR文件。蘋果后台使用私鑰A對公鑰M進行簽名，得到的數據包包含公鑰M和蘋果的簽名，這個就是發放給開發者的證書。申請證書之后，用戶申請appid和Provisioning Profile描述文件，Provisioning Profile包含了證書、授權設備uuid，以及app的權限，同樣是經過蘋果簽名的。
然后在mac上對app開發編譯完畢后，用本地的私鑰M對這個APP進行簽名，同時把從蘋果服務器得到的Provisioning Profile文件打包進APP里,文件名為embedded.mobileprovision。
在安裝時，iOS系統解壓ipa安裝包，可以得到embedded.mobileprovision文件，取得證書，通過系統內置的公鑰A，去驗證證書的數字簽名是否正確。驗證證書后確保了公鑰 M 是蘋果認證過的，再用公鑰M去驗證APP的簽名，這里就間接驗證了這個APP安裝行為是否經過蘋果官方允許。
Android簽名機制
Android 不同於iOS只能安裝app store上的應用，允許隨意安裝來自第三方的應用，同樣也要求開發者為開發的應用進行簽名，但證書不需要由證書認證中心簽名，使用開發者自制的簽名證書。Android 系統不會安裝或運行沒有正確簽名的應用，此規則適用於任何地方運行的Android系統。因此在真機或模擬器上運行或者調試應用前，必須為其設置好簽名。簽名除了為了保證app的真實性和完整性，還有以下幾個好處：
1.應用程序升級 - 當發布應用的更新時，如果想染給用戶無縫的升級到新版本，需要繼續使用相同的某個或某套證書來簽名更新包，當系統安裝應用的更新時，它會比較現在的版本和新版本的證書，如果證書吻合，包括證書數據和順序都吻合，那么系統允許更新，如果新版本所做的簽名不是匹配的，那么將需要給用起一個不同的包名 - 在這種情況下，用戶相當於安裝了一個完全新的程序。
2.用用程序模塊化 - Android允許相同證書簽名的應用程序運行在相同的進程中，此時系統會將它們作為耽擱應用程序對待，在這種方式中，可以按模塊化的凡事部署應用，用戶可以根據需要獨立的跟新每一個模塊。
3.代碼、數據的授權共享 - Android提供模式匹配的權限控制機制，因此一個應用可以暴露功能給另一個用指定證書簽名的簽名的應用，通過用相同證書簽名多個應用，以及使用模式匹配的權限檢查，應用程序可以以安全的方式共享代碼和數據。
兩種簽名：
1、調試模式下簽名（sdk 為應用自動生成一個簽名證書，調試模式下簽名的應用不能對外發布，因為由構建工具創建的證書是不安全的，應用商店不接受調試證書簽名的apk）。這種模式下密鑰在不同機器上可能都不一樣，如果換了機器進行版本升級將不能覆蓋安裝。
2、發布模式下簽名（需要生成自己的證書）
注：給自己開發的app簽名，就代表着我們自己的版權，之后要進行升級，也必須要使用相同的簽名才可以，簽名代表着自己的身份（即 keystore，是一個包括私人密鑰集合的二進制文件），創建的keystore 多個app可以使用同一簽名。
簽名的原理也是基於非對稱加密算法。給apk簽名有兩種方法，一種是通過命令行，android在公布的源碼包中提供了一個工具—signapk.jar，用於進行應用程序的簽名，簽名命令如下:
java -jar signapk.jar certificate.pem key.pk8 UnsignedApp. apk SignedApp.apk
其中，certificate.pem和key.pk8分別為用於簽名的公鑰證書和私鑰文件;UnsignedApp.apk是未簽名的Android應用程序;SignedApp.apk是簽名后的Android應用程序。通過對應用程序包(apk為zip壓縮文件)解壓縮后的數據對比，可以看出簽名后的apk包中多了一個目錄“/META-INF”，此目錄下包含三個文件:MANIFEST.MF、CERT.SF、CERT.RSA。具體的簽名過程如圖所示，包含5個步驟:
另外一種簽名方式是使用ADT Export Wizard，例如在android應用的開發工具android studio里的Generate Signed APK和Project Structure里可以進行進行配置來生成簽名，配置好后，項目文件里會自動補全相關代碼。
驗證機制
Android 系統使用“PackageInstaller”程序進行應用程序的安裝，並在安裝過程中進行代碼簽名驗證。（1)調用verifySignature() 函數，驗證CERT.RSA文件中的簽名值確實是從CERT.SF簽名得到 ;(2)調用JarVerifier.verify()函數，驗證MANIFEST.MF文件的摘要確實同CERT.SF提取的摘要值一致;(3)對包中除了簽名數據之外的其它文件調用VerifierEntry.verify()函數，驗證文件的摘要值等於MANIFEST.MF中的摘要值。安裝后，應用程序每次啟動時，android系統也會進行簡單的路徑和時間戳的驗證。
Windows代碼簽名機制
微軟公司在windows平台下設計了一種代碼簽名機制，並且在64位操作系統的平台下強制性地對涉及到內核的驅動程序進行簽名驗證。為了避免用戶應用程序訪問或修改關鍵的操作系統數據，windows使用了兩種處理器訪問模式，用戶模式和內核模式。微軟代碼簽名機制的策略為：每次驅動程序系統文件被加載到內存中時，代碼簽名機制會檢測被加載到內核中的驅動程序或系統文件是否已經被簽名，此規則適用於每個運行內核權限的模塊。不僅是普通用戶賬戶，計算機的管理員賬戶也同樣不能加載未簽名的代碼。