漫談iOS程序的證書和簽名機制

時間  2019-12-06
標籤 漫談 ios 程序 證書 簽名 機制 欄目 iOS 简体版
原文   原文鏈接

 

漫談iOS程序的證書和簽名機制 

 

接觸iOS開發半年，曾經也被這個主題坑的摸不着頭腦，也在淘寶上買過企業證書籤名這些服務，有大神都作了一個全自動的發佈打包（不過此大神如今不賣企業證書了），甚是羨慕和崇拜。因而，花了一點時間去研究了一下iOS這套證書和簽名機制，並撰文分享給須要的朋友。因爲本人才疏學淺，多有遺漏或錯誤之處，還請大神多多指教。html

非對稱加密和摘要

非對稱加密的特性和用法

非對稱加密算法多是世界上最重要的算法，它是當今電子商務等領域的基石。簡而言之，非對稱加密就是指加密密鑰和解密密鑰是不一樣的，並且加密密鑰和解密密鑰是成對出現。非對稱加密又叫公鑰加密，也就是說成對的密鑰，其中一個是對外公開的，全部人均可以得到，稱爲公鑰，而與之相對應的稱爲私鑰，只有這對密鑰的生成者才能擁有。公私鑰具備如下重要特性：ios

  • 對於一個私鑰，有且只有一個與之對應的公鑰。生成者負責生成私鑰和公鑰，並保存私鑰，公開公鑰
  • 公鑰是公開的，但不可能經過公鑰反推出私鑰，或者說極難反推，只能窮舉，因此只要密鑰足夠長度，要經過窮舉而獲得私鑰，幾乎是不可能的
  • 經過私鑰加密的密文只能經過公鑰解密，公鑰加密的密文只有經過私鑰解密

因爲上述特性，非對稱加密具備如下的典型用法：git

  • 對信息保密，防止中間人攻擊：將明文經過接收人的公鑰加密，傳輸給接收人，由於只有接收人擁有對應的私鑰，別人不可能擁有或者不可能經過公鑰推算出私鑰，因此傳輸過程當中沒法被中間人截獲。只有擁有私鑰的接收人才能閱讀。此用法一般用於交換對稱密鑰。
  • 身份驗證和防止篡改：權限狗用本身的私鑰加密一段受權明文，並將受權明文和加密後的密文，以及公鑰一併發送出來，接收方只須要經過公鑰將密文解密後與受權明文對比是否一致，就能夠判斷明文在中途是否被篡改過。此方法用於數字簽名。

著名的RSA算法就是非對稱加密算法，RSA以三個發明人的首字母命名。github

非對稱加密算法如此強大可靠，卻有一個弊端，就是加解密比較耗時。所以，在實際使用中，每每與對稱加密和摘要算法結合使用。對稱加密很好理解，此處略過1w字。咱們再來看一下摘要算法。web

摘要算法

另外一個神奇的算法就是摘要算法。摘要算法是指，能夠將任意長度的文本，經過一個算法，獲得一個固定長度的文本。這裏文本不必定只是文本，能夠是字節數據。因此摘要算法試圖將世間萬物，變成一個固定長度的東西。摘要算法具備如下重要特性：算法

  • 只要源文本不一樣，計算獲得的結果，必然不一樣
  • 沒法從結果反推出源（那是固然的，否則就能量不守恆了）

典型的摘要算法，好比大名鼎鼎的MD5和SHA。摘要算法主要用於比對信息源是否一致，由於只要源發生變化，獲得的摘要必然不一樣；並且一般結果要比源短不少，因此稱爲「摘要」。xcode

數字簽名

理解了非對稱加密和摘要算法，來看一下數字簽名。實際上數字簽名就是二者結合。假設，咱們有一段受權文本，須要發佈，爲了防止中途篡改文本內容，保證文本的完整性，以及文本是由指定的權限狗發的。首先，先將文本內容經過摘要算法，獲得摘要，再用權限狗的私鑰對摘要進行加密獲得密文，將源文本、密文、和私鑰對應的公鑰一併發佈便可。那麼如何驗證呢？瀏覽器

驗證方首先查看公鑰是不是權限狗的，而後用公鑰對密文進行解密獲得摘要，將文本用一樣的摘要算法獲得摘要，兩個摘要進行比對，若是相等那麼一切正常。這個過程只要有一步出問題就視爲無效。安全

數字簽名能夠快速驗證文本的完整性和合法性，已普遍應用於各個領域。理解了數字簽名之後，咱們進一步來看什麼是數字證書。併發

數字證書

現實生活的證書

證書顧名思義，就是權限機構的頒發的證實。好比英語6級證書，就是教育部門頒發給經過了6級考覈的我的的證實，證實這我的的英語能力。咱們來看一下這個證書的組成：

  • 被證實人：老王
  • 內容：經過了英語六級
  • 蓋章：教育部門的公章或鋼印

因而老王就能夠用這張證書找工做了，用人單位會經過查看證書的各項內容（尤爲是公章），來驗證證書的合法性和老王的能力。

在現實生活中，常常有假的6級證書，這些假證書最重要的就是有一個假公章。現實生活中使用法律法規來約束私刻假公章的行爲，可是用人單位可能不能十分準確的判斷公章是真是假。而這些問題在數字簽名面前均可以用數學的方法嚴謹的解決。

數字證書：用數字簽名實現的證書

實際上，數字證書就是經過數字簽名實現的數字化的證書。在通常的證書組成部分中，還加入了其餘的信息，好比證書有效期（比如駕駛證初次申領後6年有效），過了有效期，須要從新簽發（駕駛證6年有效後需從新申領）。

跟現實生活中的簽發機構同樣，數字證書的簽發機構也有若干，並有不一樣的用處。好比蘋果公司就能夠簽發跟蘋果公司有關的證書，而跟web訪問有關的證書則是又幾家公認的機構進行簽發。這些簽發機構稱爲CA（Certificate Authority）。

對於被簽發人，一般都是企業或開發者。好比須要搭建基於SSL的網站，那麼須要從幾家國際公認的CA去申請證書；再好比須要開發iOS的應用程序，須要從蘋果公司得到相關的證書。這些申請一般是企業或者開發者我的提交給CA的。固然申請所須要的材料、資質和費用都各不相同，是由這些CA制定的，好比蘋果要求$99或者$299的費用。

之因此要申請證書，固然是爲了被驗證。英語6級證書的驗證方通常是用人單位；web應用相關的SSL證書的驗證方一般是瀏覽器；iOS各類證書的驗證方是iOS設備。咱們之因此必須從CA處申請證書，就是由於CA已經將整個驗證過程規定好了。對於iOS，iOS系統已經將這個驗證過程固化在系統中了，除非越獄，不然沒法繞過。

證書的受權鏈

數字證書可能還包括證書鏈信息。舉個例子：若是你要申請休假1周，須要你的上司審批，你的上司須要他的上司贊成，最終須要大老闆贊成，那麼這一層層的受權，造成了一個受權鏈，大老闆是受權鏈的根(root)，中間這些環節分別是被更接近root的人受權的。

咱們從蘋果MC（Member Center）中得到的證書實際也是一個包含有證書鏈的證書，其中的根是蘋果的CA。咱們得到的證書其實是在告訴iOS設備：咱們的證書是被蘋果CA簽過名的合法的證書。而iOS設備在執行app前，首先要先驗證CA的簽名是否合法，而後再經過證書中咱們的公鑰驗證程序是否的確是咱們發佈的，且中途沒有對程序進行過篡改。

iOS證書申請和簽名打包流程圖

在繼續下去以前，先來看一張圖。

這張圖闡述了，開發iOS應用程序時，從申請證書，到打包的大體過程。接下來我將對圖中的每個環節進行分析。

證書申請

開發iOS程序，必然要進行的工做就是成爲開發者，並申請相關的證書，不然你的程序只能在模擬器上運行，沒法在真機上調試，更不要說上架了。那麼在申請證書以前須要：

  1. 支付$99或$299成爲蘋果開發者，並每一年續費。這一步是蘋果的強制規定，至關於霸王條款，沒錢玩尼瑪！你們都知道$99針對我的和小企業，$299針對大企業，這麼分沒錯，不過你須要知道的是，兩種金額的本質區別在於你能夠得到的證書類型不一樣，$99固然比$299的少一些。
  2. 安裝蘋果開發者根證書，此證書其實是咱們從蘋果MC中申請的全部證書的「根證書」，安裝這個證書意味着咱們的開發工具對此CA的信任，從而能夠用此CA簽發的其餘證書進行簽名和打包。通常而言，若是安裝了Xcode，那麼這個證書是自動安裝在Key Chain中了。證書以下圖

而後，咱們就開始按照不少圖文並茂的教程開始申請證書，各類操做。這裏因爲是講原理，不展開這部分。咱們來看每一步到底意味着什麼。

什麼是CertificateSigningRequest.certSigningRequest

咱們須要生成一個CertificateSigningRequest.certSigningRequest文件來提交到MC中，從而獲取某種證書。那麼這個文件究竟是什麼呢?從上面的流程圖中你們能夠看到，這個文件包含兩部份內容(Certificate signing request)：

  1. 申請者信息，此信息是用申請者的私鑰加密的
  2. 申請者公鑰，此信息是申請者使用的私鑰對應的公鑰
  3. 摘要算法和公鑰加密算法

咱們能夠用openssl來解析文件中的內容一窺究竟：

openssl asn1parse -i -in CertificateSigningRequest.certSigningRequest
  
        0:d=0  hl=4 l= 649 cons: SEQUENCE          
        4:d=1  hl=4 l= 369 cons:  SEQUENCE          
        8:d=2  hl=2 l=   1 prim:   INTEGER           :00
       11:d=2  hl=2 l=  68 cons:   SEQUENCE          
       13:d=3  hl=2 l=  36 cons:    SET               
       15:d=4  hl=2 l=  34 cons:     SEQUENCE          
       17:d=5  hl=2 l=   9 prim:      OBJECT            :emailAddress
       28:d=5  hl=2 l=  21 prim:      IA5STRING         :zhoupingtkbjb@163.com
       51:d=3  hl=2 l=  15 cons:    SET               
       53:d=4  hl=2 l=  13 cons:     SEQUENCE          
       55:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
       60:d=5  hl=2 l=   6 prim:      UTF8STRING        :Parker
       68:d=3  hl=2 l=  11 cons:    SET               
       70:d=4  hl=2 l=   9 cons:     SEQUENCE          
       72:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
       77:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :CN
       81:d=2  hl=4 l= 290 cons:   SEQUENCE          
       85:d=3  hl=2 l=  13 cons:    SEQUENCE          
       87:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
       98:d=4  hl=2 l=   0 prim:     NULL              
      100:d=3  hl=4 l= 271 prim:    BIT STRING        
      375:d=2  hl=2 l=   0 cons:   cont [ 0 ]        
      377:d=1  hl=2 l=  13 cons:  SEQUENCE          
      379:d=2  hl=2 l=   9 prim:   OBJECT            :sha1WithRSAEncryption
      390:d=2  hl=2 l=   0 prim:   NULL              
      392:d=1  hl=4 l= 257 prim:  BIT STRING

能夠看到文件包含了個人信息，並標明使用了sha1摘要算法和RSA公鑰加密算法。蘋果的MC在拿到這個後，將這個信息記錄下來，並簽發出相關的證書。這裏，蘋果實際無需驗證個人信息，由於若是我不交錢就沒辦法上傳這個文件，也就得不到證書。

從MC中申請到的證書到底是什麼

蘋果取出CertificateSigningRequest.certSigningRequest中的公鑰，根本無論個人其餘信息，而後將個人MC帳號信息和我提交的公鑰封裝在證書中，並進行數字簽名。以開發證書爲例，咱們用openssl來看一下證書的內容：

openssl x509 -inform der -in ios_development.cer -noout -text

    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number:
                65:97:cd:73:6f:19:37:c2
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: C=US, O=Apple Inc., OU=Apple Worldwide Developer Relations, CN=Apple Worldwide Developer Relations Certification Authority
            Validity
                Not Before: Jul 29 07:36:28 2015 GMT
                Not After : Jul 28 07:36:28 2016 GMT
            Subject: UID=8VPWB57FDW, CN=iPhone Developer: Liang Ding (2U967A2YJ6), OU=7XPNRZE9TC, O=Liang Ding, C=US
            Subject Public Key Info:
                Public Key Algorithm: rsaEncryption
                RSA Public Key: (2048 bit)
                    Modulus (2048 bit):
                        00:ab:43:a4:57:32:57:30:81:89:eb:b4:5c:b6:88:
                        7f:4f:59:3a:9e:f6:14:50:2c:5c:14:6d:01:58:bd:
                        d7:2b:a6:66:71:f7:d9:da:58:a2:e8:4c:d5:a9:87:
                        20:5b:b7:4c:58:29:3c:b3:48:de:7f:ad:3f:98:cc:
                        9d:b3:07:2f:93:4a:3a:e5:32:e2:fc:59:30:1e:ee:
                        65:11:c3:88:ea:7a:54:d8:60:56:d1:fa:69:06:40:
                        dd:72:1d:7f:d9:14:85:bf:7a:b0:a3:34:a0:ac:c1:
                        dc:a9:48:3c:9c:43:c8:e4:fd:02:eb:fe:d2:a7:ce:
                        2e:e4:9a:51:20:0b:5b:e5:5a:d4:04:9e:a4:52:8d:
                        c2:1e:1f:50:80:fb:ea:c1:e4:bb:b4:ec:35:fd:96:
                        6a:86:0a:62:fa:d2:5a:8b:34:1b:f2:c5:c8:c9:2c:
                        85:d1:4d:8c:cb:91:be:db:92:f0:88:37:7a:6d:8d:
                        ef:c6:e1:47:5c:e5:ca:e2:5a:47:14:5d:2f:5b:2e:
                        d4:df:61:d9:99:e2:3e:6b:24:b2:aa:36:b3:af:e6:
                        a8:a8:28:a7:8a:73:aa:68:a9:71:ac:81:a8:20:98:
                        bb:3e:76:e2:09:19:41:45:d7:9a:68:1b:7c:1d:f5:
                        b2:0b:36:ac:f0:4b:fc:0a:f1:3c:de:96:a0:10:14:
                        aa:79
                    Exponent: 65537 (0x10001)
            X509v3 extensions:
                Authority Information Access: 
                    OCSP - URI:http://ocsp.apple.com/ocsp03-wwdr01
    
                X509v3 Subject Key Identifier: 
                    C7:AB:35:54:A3:7B:96:2A:67:55:B8:2F:B6:82:4B:B8:F0:49:0F:EB
                X509v3 Basic Constraints: critical
                    CA:FALSE
                X509v3 Authority Key Identifier: 
                    keyid:88:27:17:09:A9:B6:18:60:8B:EC:EB:BA:F6:47:59:C5:52:54:A3:B7
    
                X509v3 Certificate Policies: 
                    Policy: 1.2.840.113635.100.5.1
                      User Notice:
                        Explicit Text: Reliance on this certificate by any party assumes acceptance of the then applicable standard terms and conditions of use, certificate policy and certification practice statements.
                      CPS: http://www.apple.com/certificateauthority/
    
                X509v3 Key Usage: critical
                    Digital Signature
                X509v3 Extended Key Usage: critical
                    Code Signing
                1.2.840.113635.100.6.1.2: critical
                    ..
        Signature Algorithm: sha256WithRSAEncryption
            80:99:47:27:ae:e5:1e:89:1e:c2:ec:52:d7:c8:8b:df:86:25:
            a9:cb:b2:f2:01:6c:5e:a0:55:6c:ad:1d:bd:3b:1c:ce:b4:53:
            4d:03:d0:98:f6:f7:0e:24:2b:c5:cb:5e:71:88:bd:53:46:a8:
            c7:e0:d9:f4:81:47:98:a5:91:5c:04:f6:df:b9:c2:06:64:a4:
            73:3d:0b:78:0d:8b:11:29:d3:3a:ea:88:b7:97:a9:2a:e0:74:
            a9:0b:1f:91:0f:47:78:be:90:46:21:10:16:a5:4b:0d:a6:33:
            7e:0c:18:95:ba:7c:8e:b5:ed:86:5f:73:1b:cb:9e:ae:c8:96:
            9d:4f:12:0a:9b:43:cc:58:ca:f3:d5:f0:6e:19:a6:e9:bf:9d:
            95:34:39:4d:86:34:46:7e:11:e7:7c:9f:7b:1d:b1:9c:7d:1b:
            39:85:5f:77:b0:89:d4:bb:55:c3:a9:24:af:54:a6:42:47:bf:
            7c:d3:b0:6f:af:6a:2e:c6:00:07:1c:de:6b:aa:5b:a6:23:2b:
            fb:cd:2b:eb:04:fb:19:3e:1d:9d:ca:ae:d4:20:f1:4d:63:10:
            44:80:d1:cf:fd:82:51:d2:cd:77:cb:46:1e:bd:63:df:4f:82:
            c7:5d:b3:61:45:03:6b:84:35:17:4b:c6:16:f0:47:1f:7b:26:
            62:e3:d1:1b

Data域即爲證書的實際內容，與Data域平級的Signature Algorithm實際就是蘋果的CA的公鑰，而摘要的簽名應該沒有顯示出來。Data域下一級的內容就是個人蘋果帳號信息，其中最爲重要的是個人公鑰，這個公鑰與我本機的私鑰是對應的。當咱們雙擊安裝完證書後，KeyChain會自動將這對密鑰關聯起來，因此在KeyChain中能夠看到相似的效果：

後續在程序上真機的過程當中，會使用這個私鑰，對代碼進行簽名，而公鑰會附帶在mobileprovision文件中，打包進app。

注意這裏，公鑰是附帶在mobileprovision中的，並非直接隨代碼打包的，因此，筆者認爲，本質上在電腦上安裝證書是沒有實際用處的，由於mobileprovision是MC爲咱們生成的。之因此須要安裝證書，是由於簽名程序codesign或者Xcode，只能讓咱們選擇「用哪一個證書籤名」，由於咱們所選的證書仍是會對應到私鑰，真正用於簽名的是私鑰。mobileprovision和代碼簽名在後面詳細說明。

因此，就算你有證書，可是若是沒有對應的私鑰是沒有用的。那麼有人要問了，既然私鑰只有某臺電腦生成的，那麼團隊開發怎麼展開呢？

團隊開發

因而，你們會去搜索「iOS證書共享」之類的關鍵字，給出的解決方案就是「私鑰導出」。沒錯，既然問題的關鍵是私鑰，咱們共享私鑰不就好了，將最初申請證書的機器的私鑰導出成.p12文件，並讓其餘機器導入，同時其餘機器也應該安裝下載下來的證書。

固然還有一種方案，就是每臺機器都各自去申請各自的證書。然而這樣作可能到後面比較混亂。

因爲iOS證書有多種類型，用於不一樣的用處，因此咱們可能後續還會去MC上申請別的證書。因此強烈建議CertificateSigningRequest.certSigningRequest須要保留，由於若是再次生成CertificateSigningRequest.certSigningRequest文件，可能就是對應另外一個私鑰了！還須要在共享一次私鑰，會比較麻煩。

iOS證書類型

當咱們在MC的申請證書界面點擊新建證書時，須要選擇一種證書。每種證書有不一樣的用處，就比如你要生孩子，那麼得有準生證；你要駕駛機動車，須要駕駛證；你要出國，須要護照…那麼在iOS開發中涉及的證書究竟有什麼區別呢？本質上他們的區別只是用途，從證書結構上講都是同一個，只要你不改變申請用的CertificateSigningRequest.certSigningRequest文件，這些證書中包含的公鑰和對應的私鑰都是同一個。接下來羅列幾個經常使用的證書類型：

  1. iOS App Development。開發、真機調試用
  2. Apple Push Notification service SSL (Sandbox)。開發階段使用蘋果的推送服務
  3. App Store and Ad Hoc。上架和AdHoc方式發佈時用
  4. Apple Push Notification service SSL (Production)。上架後使用蘋果推送服務
  5. In-House。企業版發佈，需$299才能擁有，還需鄧氏編碼

其餘不經常使用的就不列舉了。關於AdHoc方式，在後面的mobileprovision中再說。

iOS受權和描述文件

可是光有證書並不夠解決蘋果的「後顧之憂」，證書可以證實app的所屬以及app的完整性，保證app自己是安全的。可是，卻不能細化到app所使用的某些服務是被蘋果承認的，好比APN推送服務。並且證書沒法限制調試版的app的裝機規模。因而，蘋果想出了「花式做死」的mobileprovision。你可使用以下命令查看一個mobileprovision：

security cms -D -i embedded.mobileprovision

mobileprovision文件包含：

  1. AppId。每一個app必須在MC中建立一個對應的AppId。規則不累述了。
  2. 使用哪些證書。上面說了，不一樣類型的證書就表明了不一樣的發佈方式，還包括一些功能的可否使用（好比APN）
  3. 功能受權列表
  4. 可安裝的設備列表。對於AdHoc方式發佈的app或者真機調試時，會有一個列表，這個列表裏面是iOS設備的UDID，每臺iOS設備出廠的UDID都不一樣，因此能夠用來標識設備。可經過iTunes鏈接設備，或者http://fir.im/udid這裏獲取
  5. 蘋果的簽名！

注意5，這裏的簽名是蘋果籤的，跟咱們的私鑰沒有關係。也就是說mobileprovision文件是蘋果簽名的，咱們除了從MC中獲取，別無他法。也不能再獲取後隨意篡改（好比添加別的設備）。所以上面的1-4就被蘋果緊緊的控制在手裏，全部的規則都必須由蘋果來制定和約束。

AdHoc發佈和真機調試

AdHoc容許將測試版app發佈給有限的設備安裝，而無需經過appstore的審覈。這裏的關鍵是如何控制哪些設備能夠裝。答案就是mobileprovision文件，記得你在生成mobileprovision文件的時候須要選設備的UDID吧，因此這些設備須要事先添加到MC的Devices裏面。對於開發時候的真機調試，原理差很少。都是經過mobileprovision的條目4來作到的。而蘋果對於調試和測試用機的數量限制爲100臺！

iOS代碼簽名

不少人研究到上面也就中止了，然而生命不息，做死不止。上面不少次提到代碼簽名，那麼究竟代碼是如何簽名的。這對於可能須要作自動簽名發佈的企業或團隊是必須瞭解的。另外，你可能還須要去閱讀iReSign的源碼。

ipa的組成

iOS程序最終都會以.ipa文件導出，先來了解一下ipa文件的結構：

事實上，ipa文件只是一個zip包，可使用以下命令解壓：

/usr/bin/unzip -q xxx.ipa -d <destination>

解壓後，獲得上圖的Payload目錄，下面是個子目錄，其中的內容以下：

  1. 資源文件，例如圖片、html、等等。
  2. _CodeSignature/CodeResources。這是一個plist文件，可用文本查看，其中的內容就是是程序包中（不包括Frameworks）全部文件的簽名。注意這裏是全部文件。意味着你的程序一旦簽名，就不能更改其中任何的東西，包括資源文件和可執行文件自己。iOS系統會檢查這些簽名。
  3. 可執行文件。此文件跟資源文件同樣須要簽名。
  4. 一個mobileprovision文件.打包的時候使用的，從MC上生成的。
  5. Frameworks。程序引用的非系統自帶的Frameworks，每一個Frameworks其實就是一個app，其中的結構應該和app差很少，也包含簽名信息CodeResources文件

相關的程序和命令

通常咱們會用Xcode自帶的archive功能來打包ipa和簽名，實際上xcode只不過是調用了一些外部程序完成了工做，若是咱們有朝一日須要本身實現自動化的簽名流程，就須要瞭解究竟相關的程序和命令有哪些。

用下面命令，列出系統中可用於簽名的有效證書：

/usr/bin/security find-identity -v -p codesigning

1) E056929276F94152F3FDF0EA84BD2B06396F2DDD "iPhone Developer: Liang Ding (2U967A2YJ6)"
2) 7C608F653A989E95E1A4D303EC4E6625D95EEB42 "iPhone Distribution: Liang Ding (7XPNRZE9TC)"
  2 valid identities found

能夠看到這個命令列出了一個字符串標示的證書名稱，如：iPhone Developer: Liang Ding (2U967A2YJ6)。這個名稱後面會用到的。

使用以下命令對xxx.app目錄簽名，codesign程序會自動將其中的文件都簽名，（Frameworks不會自動籤）：

/user/bin/codesign -fs "iPhone Developer: Liang Ding (2U967A2YJ6)" --no-strict Payload/xxx.app

對於每一個Framework，也須要使用這個命令簽名，上面說了Framework的結構跟app其實差很少，因此簽名命令相似。這個命令會自動找到證書相關的私鑰。-f表示對於已經簽名的app強制重籤。

最後用下面命令校驗簽名是否合法：

/usr/bin/codesign -v xxx.app

若是沒有任何輸出說明沒有問題。

使用zip命令從新打包成ipa包

/usr/bin/zip -qry destination source

對app從新簽名的流程

若是要設計一個自動化的重籤程序，大體須要這麼個流程：

  1. 首先解壓ipa
  2. 若是mobileprovision須要替換，替換
  3. 若是存在Frameworks子目錄，則對.app文件夾下的全部Frameworks進行簽名，在Frameworks文件夾下的.dylib或.framework
  4. 對xxx.app簽名
  5. 從新打包

iOS設備如何驗證app是否合法

關鍵的幾個點：

  1. 解壓ipa
  2. 取出embedded.mobileprovision，經過簽名校驗是否被篡改過 a. 其中有幾個證書的公鑰，其中開發證書和發佈證書用於校驗簽名 b. BundleId c. 受權列表
  3. 校驗全部文件的簽名，包括Frameworks
  4. 比對Info.plist裏面的BundleId是否符合embedded.mobileprovision文件中的

總結

非對稱密鑰算法是基石，本文比較詳細的闡述了非對稱加密算法和摘要算法，並逐漸引出數字簽名和數字證書。理解非對稱密鑰算法是關鍵。

蘋果經過證書來受權開發者開發iOS應用，不一樣的證書具備不一樣的用處，建議申請時使用相同的請求文件（即保證私鑰統一）。能夠經過共享私鑰的方式讓團隊使用相同的私鑰和證書，已方便開發。爲了保證app的安全性，app中全部的文件都會被簽名，這樣，簽過名的app除非從新簽名，不然沒法改動其中的任何東西。

mobileprovision是一個配置文件，由蘋果簽名併發布給開發者。配置文件是一組信息的集合，這組信息決定了某一個應用是否可以在某一個特定的設備上運行。配置文件能夠用於讓應用在你的開發設備上能夠被運行和調試，也能夠用於內部測試 (ad-hoc) 或者企業級應用的發佈。有了配置文件，蘋果對開發者的約束就十分穩固了。

因此，證書（及其對應的私鑰）和配置文件是簽名和打包的兩個必要文件。必須深入理解，才能在平常的錯誤中找到解決辦法。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程