名稱解釋
代碼簽名是對可執行檔案或腳本進行數字簽名.用來確認軟體的來源并保證在簽名后未被修改或損壞的措施，和數字簽名原理一樣,只不過簽名的資料是代碼而已.
為什么要使用代碼簽名？
在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使用了兩種處理器訪問模式，用戶模式和內核模式，微軟代碼簽名機制的策略為：每次驅動程式系統檔案被加載到記憶體中時，代碼簽名機制會檢測被加載到內核中的驅動程式或系統檔案是否已經被簽名，此規則適用于每個運行內核權限的模塊，不僅是普通用戶賬戶，計算機的管理員賬戶也同樣不能加載未簽名的代碼，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/30918.html
標籤：其他
上一篇：day02-IP地址詳解