非對稱加密和摘要
非對稱加密的特性和用法
非對稱加密算法可能是世界上最重要的算法，它是當今電子商務等領域的基石跨细。簡而言之鹦倚，非對稱加密就是指加密密鑰和解密密鑰是不同的，而且加密密鑰和解密密鑰是成對出現(xiàn)冀惭。非對稱加密又叫公鑰加密震叙，也就是說成對的密鑰，其中一個是對外公開的散休，所有人都可以獲得媒楼，稱為公鑰，而與之相對應的稱為私鑰戚丸，只有這對密鑰的生成者才能擁有划址。公私鑰具有以下重要特性：
- 對于一個私鑰，有且只有一個與之對應的公鑰限府。生成者負責生成私鑰和公鑰夺颤，并保存私鑰，公開公鑰
- 公鑰是公開的胁勺，但不可能通過公鑰反推出私鑰世澜，或者說極難反推，只能窮舉署穗，所以只要密鑰足夠長度寥裂，要通過窮舉而得到私鑰，幾乎是不可能的
- 通過私鑰加密的密文只能通過公鑰解密案疲，公鑰加密的密文只有通過私鑰解密
由于上述特性封恰，非對稱加密具有以下的典型用法：
- 對信息保密，防止中間人攻擊：將明文通過接收人的公鑰加密褐啡，傳輸給接收人诺舔，因為只有接收人擁有對應的私鑰，別人不可能擁有或者不可能通過公鑰推算出私鑰，所以傳輸過程中無法被中間人截獲混萝。只有擁有私鑰的接收人才能閱讀。此用法通常用于交換 對稱密鑰
- 身份驗證和防止篡改：權限狗用自己的私鑰加密一段授權明文萍恕，并將授權明文和加密后的密文逸嘀，以及公鑰一并發(fā)送出來，接收方只需要通過公鑰將密文解密后與授權明文對比是否一致允粤，就可以判斷明文在中途是否被篡改過崭倘。此方法用于 數(shù)字簽名
著名的RSA算法就是非對稱加密算法，RSA以三個發(fā)明人的首字母命名类垫。
非對稱加密算法如此強大可靠司光，卻有一個弊端，就是加解密比較耗時悉患。因此残家，在實際使用中，往往與對稱加密和摘要算法結(jié)合使用售躁。對稱加密很好理解坞淮，此處略過1w字。我們再來看一下摘要算法陪捷。
摘要算法
另一個神奇的算法就是摘要算法回窘。摘要算法是指，可以將任意長度的文本市袖，通過一個算法啡直，得到一個固定長度的文本。這里文本不一定只是文本苍碟，可以是字節(jié)數(shù)據(jù)酒觅。所以摘要算法試圖將世間萬物，變成一個固定長度的東西微峰。摘要算法具有以下重要特性：
- 只要源文本不同阐滩，計算得到的結(jié)果，必然不同
- 無法從結(jié)果反推出源（那是當然的县忌，不然就能量不守恒了）
典型的摘要算法掂榔，比如大名鼎鼎的MD5和SHA。摘要算法主要用于比對信息源是否一致症杏，因為只要源發(fā)生變化装获，得到的摘要必然不同；而且通常結(jié)果要比源短很多厉颤，所以稱為“摘要”
數(shù)字簽名
理解了非對稱加密和摘要算法穴豫，來看一下數(shù)字簽名。實際上數(shù)字簽名就是兩者結(jié)合。假設精肃，我們有一段授權文本秤涩，需要發(fā)布，為了防止中途篡改文本內(nèi)容司抱，保證文本的完整性筐眷，以及文本是由指定的權限狗發(fā)的。首先习柠，先將文本內(nèi)容通過摘要算法匀谣，得到摘要，再用權限狗的私鑰對摘要進行加密得到密文资溃，將源文本武翎、密文、和私鑰對應的公鑰一并發(fā)布即可溶锭。那么如何驗證呢宝恶？
驗證方首先查看公鑰是否是權限狗的，然后用公鑰對密文進行解密得到摘要趴捅，將文本用同樣的摘要算法得到摘要卑惜，兩個摘要進行比對，如果相等那么一切正常驻售。這個過程只要有一步出問題就視為無效露久。
圖示1
數(shù)字簽名可以快速驗證文本的完整性和合法性，已廣泛應用于各個領域。理解了數(shù)字簽名以后，我們進一步來看什么是數(shù)字證書前塔。
數(shù)字證書
現(xiàn)實生活的證書
證書顧名思義身辨，就是權限機構(gòu)的頒發(fā)的證明。比如英語6級證書，就是教育部門頒發(fā)給通過了6級考核的個人的證明，證明這個人的英語能力。我們來看一下這個證書的組成：
- 被證明人：老王
- 內(nèi)容：通過了英語六級
- 蓋章：教育部門的公章或鋼印
于是老王就可以用這張證書找工作了臊泰，用人單位會通過查看證書的各項內(nèi)容（尤其是公章），來驗證證書的合法性和老王的能力蚜枢。
在現(xiàn)實生活中缸逃，經(jīng)常有假的6級證書，這些假證書最重要的就是有一個假公章〕С椋現(xiàn)實生活中使用法律法規(guī)來約束私刻假公章的行為需频，但是用人單位可能不能十分準確的判斷公章是真是假。而這些問題在數(shù)字簽名面前都可以用數(shù)學的方法嚴謹?shù)慕鉀Q筷凤。
數(shù)字證書：用數(shù)字簽名實現(xiàn)的證書
實際上昭殉，數(shù)字證書就是通過數(shù)字簽名實現(xiàn)的數(shù)字化的證書。在一般的證書組成部分中，還加入了其他的信息挪丢，比如證書有效期（好比駕駛證初次申領后6年有效）蹂风，過了有效期，需要重新簽發(fā)（駕駛證6年有效后需重新申領）乾蓬。
跟現(xiàn)實生活中的簽發(fā)機構(gòu)一樣惠啄，數(shù)字證書的簽發(fā)機構(gòu)也有若干，并有不同的用處巢块。比如蘋果公司就可以簽發(fā)跟蘋果公司有關的證書，而跟web訪問有關的證書則是又幾家公認的機構(gòu)進行簽發(fā)巧号。這些簽發(fā)機構(gòu)稱為CA（Certificate Authority）族奢。
對于被簽發(fā)人，通常都是企業(yè)或開發(fā)者丹鸿。比如需要搭建基于SSL的網(wǎng)站越走，那么需要從幾家國際公認的CA去申請證書；再比如需要開發(fā)iOS的應用程序靠欢，需要從蘋果公司獲得相關的證書廊敌。這些申請通常是企業(yè)或者開發(fā)者個人提交給CA的。當然申請所需要的材料门怪、資質(zhì)和費用都各不相同骡澈，是由這些CA制定的，比如蘋果要求$99或者$299的費用掷空。
之所以要申請證書肋殴，當然是為了被驗證。英語6級證書的驗證方一般是用人單位坦弟；web應用相關的SSL證書的驗證方通常是瀏覽器护锤；iOS各種證書的驗證方是iOS設備。我們之所以必須從CA處申請證書酿傍，就是因為CA已經(jīng)將整個驗證過程規(guī)定好了烙懦。對于iOS，iOS系統(tǒng)已經(jīng)將這個驗證過程固化在系統(tǒng)中了赤炒，除非越獄氯析，否則無法繞過!
證書的授權鏈
數(shù)字證書可能還包括證書鏈信息。舉個例子：如果你要申請休假1周莺褒，需要你的上司審批魄鸦，你的上司需要他的上司同意，最終需要大老板同意癣朗，那么這一層層的授權拾因，形成了一個授權鏈，大老板是授權鏈的根(root)，中間這些環(huán)節(jié)分別是被更接近root的人授權的绢记。
我們從蘋果MC（Member Center）中獲得的證書實際也是一個包含有證書鏈的證書扁达，其中的根是蘋果的CA。我們獲得的證書實際上是在告訴iOS設備：我們的證書是被蘋果CA簽過名的合法的證書蠢熄。而iOS設備在執(zhí)行app前跪解，首先要先驗證CA的簽名是否合法，然后再通過證書中我們的公鑰驗證程序是否的確是我們發(fā)布的签孔，且中途沒有對程序進行過篡改叉讥。
iOS證書申請和簽名打包流程圖
證書申請
開發(fā)iOS程序，必然要進行的工作就是成為開發(fā)者饥追，并申請相關的證書图仓，否則你的程序只能在模擬器上運行，無法在真機上調(diào)試但绕，更不要說上架了救崔。那么在申請證書之前需要：
支付$99或$299成為蘋果開發(fā)者，并每年續(xù)費捏顺。這一步是蘋果的強制規(guī)定六孵，相當于霸王條款，沒錢玩尼瑪幅骄！大家都知道$99針對個人和小企業(yè)劫窒，$299針對大企業(yè)，這么分沒錯拆座，不過你需要知道的是烛亦，兩種金額的本質(zhì)區(qū)別在于你可以獲得的證書類型不同，$99當然比$299的少一些懂拾。
安裝蘋果開發(fā)者根證書煤禽，此證書實際上是我們從蘋果MC中申請的所有證書的“根證書”，安裝這個證書意味著我們的開發(fā)工具對此CA的信任岖赋，從而可以用此CA簽發(fā)的其他證書進行簽名和打包檬果。一般而言，如果安裝了Xcode唐断，那么這個證書是自動安裝在Key Chain中了选脊。證書如下圖
然后，我們就開始按照很多圖文并茂的教程開始申請證書脸甘，各種操作恳啥。這里由于是講原理，不展開這部分丹诀。我們來看每一步到底意味著什么钝的。
什么是CertificateSigningRequest.certSigningRequest
我們需要生成一個CertificateSigningRequest.certSigningRequest
從上面的流程圖中大家可以看到翁垂，這個文件包含兩部分內(nèi)容(Certificate signing request)：
- 申請者信息，此信息是用申請者的私鑰加密的
- 申請者公鑰硝桩，此信息是申請者使用的私鑰對應的公鑰
- 摘要算法和公鑰加密算法
我們可以用openssl來解析文件中的內(nèi)容一窺究竟:
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在拿到這個后碗脊，將這個信息記錄下來啼肩，并簽發(fā)出相關的證書。這里衙伶，蘋果實際無需驗證我的信息祈坠，因為如果我不交錢就沒辦法上傳這個文件，也就得不到證書矢劲。
從MC中申請到的證書究竟是什么
蘋果取出CertificateSigningRequest.certSigningRequest中的公鑰赦拘，根本不管我的其他信息，然后將我的MC賬號信息和我提交的公鑰封裝在證書中卧须，并進行數(shù)字簽名另绩。以開發(fā)證書為例儒陨，我們用openssl來看一下證書的內(nèi)容：
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域即為證書的實際內(nèi)容花嘶，與Data域平級的Signature Algorithm實際就是蘋果的CA的公鑰，而摘要的簽名應該沒有顯示出來蹦漠。Data域下一級的內(nèi)容就是我的蘋果賬號信息椭员，其中最為重要的是我的公鑰，這個公鑰與我本機的私鑰是對應的笛园。當我們雙擊安裝完證書后隘击，KeyChain會自動將這對密鑰關聯(lián)起來，所以在KeyChain中可以看到類似的效果：
后續(xù)在程序上真機的過程中研铆，會使用這個私鑰埋同，對代碼進行簽名，而公鑰會附帶在mobileprovision文件中棵红，打包進app凶赁。
注意這里，公鑰是附帶在mobileprovision中的逆甜，并不是直接隨代碼打包的虱肄，所以，筆者認為交煞，本質(zhì)上在電腦上安裝證書是沒有實際用處的咏窿，因為mobileprovision是MC為我們生成的。之所以需要安裝證書素征，是因為簽名程序codesign或者Xcode集嵌，只能讓我們選擇“用哪個證書簽名”萝挤，因為我們所選的證書還是會對應到私鑰，真正用于簽名的是私鑰纸淮。mobileprovision和代碼簽名在后面詳細說明平斩。
所以，就算你有證書咽块，但是如果沒有對應的私鑰是沒有用的绘面。那么有人要問了，既然私鑰只有某臺電腦生成的侈沪，那么團隊開發(fā)怎么展開呢揭璃？
團隊開發(fā)
于是，大家會去搜索“iOS證書共享”之類的關鍵字亭罪，給出的解決方案就是“私鑰導出”瘦馍。沒錯，既然問題的關鍵是私鑰应役，我們共享私鑰不就行了情组，將最初申請證書的機器的私鑰導出成.p12文件，并讓其他機器導入箩祥，同時其他機器也應該安裝下載下來的證書院崇。
當然還有一種方案，就是每臺機器都各自去申請各自的證書袍祖。然而這樣做可能到后面比較混亂底瓣。
由于iOS證書有多種類型，用于不同的用處蕉陋，所以我們可能后續(xù)還會去MC上申請別的證書捐凭。所以強烈建議CertificateSigningRequest.certSigningRequest需要保留，因為如果再次生成CertificateSigningRequest.certSigningRequest文件凳鬓，可能就是對應另一個私鑰了茁肠！還需要在共享一次私鑰，會比較麻煩缩举。
iOS證書類型
當我們在MC的申請證書界面點擊新建證書時垦梆，需要選擇一種證書。每種證書有不同的用處蚁孔，就好比你要生孩子奶赔，那么得有準生證；你要駕駛機動車杠氢，需要駕駛證站刑；你要出國，需要護照...那么在iOS開發(fā)中涉及的證書究竟有什么區(qū)別呢鼻百？本質(zhì)上他們的區(qū)別只是用途绞旅，從證書結(jié)構(gòu)上講都是同一個摆尝，只要你不改變申請用的CertificateSigningRequest.certSigningRequest文件，這些證書中包含的公鑰和對應的私鑰都是同一個因悲。接下來羅列幾個常用的證書類型：
- iOS App Development堕汞。開發(fā)、真機調(diào)試用
- Apple Push Notification service SSL (Sandbox)晃琳。開發(fā)階段使用蘋果的推送服務
- App Store and Ad Hoc讯检。上架和AdHoc方式發(fā)布時用
- Apple Push Notification service SSL (Production)。上架后使用蘋果推送服務
- In-House卫旱。企業(yè)版發(fā)布人灼，需$299才能擁有，還需鄧氏編碼
其他不常用的就不列舉了顾翼。關于AdHoc方式投放，在后面的mobileprovision中再說。
iOS授權和描述文件
但是光有證書并不夠解決蘋果的“后顧之憂”适贸，證書能夠證明app的所屬以及app的完整性灸芳，保證app本身是安全的。但是拜姿，卻不能細化到app所使用的某些服務是被蘋果認可的烙样，比如APN推送服務。而且證書無法限制調(diào)試版的app的裝機規(guī)模砾隅。于是误阻，蘋果想出了“花式作死”的mobileprovision债蜜。你可以使用如下命令查看一個mobileprovision：
security cms -D -i embedded.mobileprovision
mobileprovision
文件包含：
- AppId晴埂。每個app必須在MC中創(chuàng)建一個對應的AppId。規(guī)則不累述了寻定。
- 使用哪些證書儒洛。上面說了，不同類型的證書就代表了不同的發(fā)布方式狼速，還包括一些功能的能否使用（比如APN）
- 功能授權列表
- 可安裝的設備列表琅锻。對于AdHoc方式發(fā)布的app或者真機調(diào)試時，會有一個列表向胡，這個列表里面是iOS設備的UDID恼蓬，每臺iOS設備出廠的UDID都不同，所以可以用來標識設備僵芹〈τ玻可通過iTunes連接設備，或者http://fir.im/udid這里獲取
- 蘋果的簽名拇派！
注意5荷辕，這里的簽名是蘋果簽的凿跳，跟我們的私鑰沒有關系。也就是說mobileprovision文件是蘋果簽名的疮方，我們除了從MC中獲取控嗜，別無他法。也不能再獲取后隨意篡改（比如添加別的設備）骡显。因此上面的1-4就被蘋果牢牢的控制在手里疆栏，所有的規(guī)則都必須由蘋果來制定和約束。
AdHoc發(fā)布和真機調(diào)試
AdHoc允許將測試版app發(fā)布給有限的設備安裝惫谤，而無需通過appstore的審核承边。這里的關鍵是如何控制哪些設備可以裝。答案就是mobileprovision文件石挂，記得你在生成mobileprovision文件的時候需要選設備的UDID吧博助，所以這些設備需要事先添加到MC的Devices里面。對于開發(fā)時候的真機調(diào)試痹愚，原理差不多富岳。都是通過mobileprovision的條目4來做到的。而蘋果對于調(diào)試和測試用機的數(shù)量限制為100臺拯腮！
iOS代碼簽名
很多人研究到上面也就停止了窖式，然而生命不息，作死不止动壤。上面很多次提到代碼簽名萝喘，那么究竟代碼是如何簽名的。這對于可能需要做自動簽名發(fā)布的企業(yè)或團隊是必須了解的琼懊。另外阁簸，你可能還需要去閱讀iReSign的源碼。
相關的程序和命令
一般我們會用Xcode自帶的archive功能來打包ipa和簽名哼丈，實際上xcode只不過是調(diào)用了一些外部程序完成了工作启妹，如果我們有朝一日需要自己實現(xiàn)自動化的簽名流程，就需要了解究竟相關的程序和命令有哪些醉旦。
用下面命令饶米，列出系統(tǒng)中可用于簽名的有效證書：
/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的結(jié)構(gòu)跟app其實差不多羹饰，所以簽名命令類似伊滋。這個命令會自動找到證書相關的私鑰碳却。-f表示對于已經(jīng)簽名的app強制重簽。
最后用下面命令校驗簽名是否合法：
/usr/bin/codesign -v xxx.app
如果沒有任何輸出說明沒有問題笑旺。
使用zip命令重新打包成ipa包
/usr/bin/zip -qry destination source
對app重新簽名的流程
如果要設計一個自動化的重簽程序昼浦，大致需要這么個流程：
- 首先解壓ipa
- 如果mobileprovision需要替換，替換
- 如果存在Frameworks子目錄筒主，則對.app文件夾下的所有Frameworks進行簽名关噪，在 Frameworks文件夾下的.dylib或.framework
- 對xxx.app簽名
- 重新打包
iOS設備如何驗證app是否合法
關鍵的幾個點：
- 解壓ipa
- 取出embedded.mobileprovision，通過簽名校驗是否被篡改過 a. 其中有幾個證書的 公鑰乌妙，其中開發(fā)證書和發(fā)布證書用于校驗簽名 b. BundleId c. 授權列表
- 校驗所有文件的簽名使兔，包括Frameworks
- 比對Info.plist里面的BundleId是否符合embedded.mobileprovision文件中的
總結(jié)
非對稱密鑰算法是基石，本文比較詳細的闡述了非對稱加密算法和摘要算法藤韵，并逐漸引出數(shù)字簽名和數(shù)字證書虐沥。理解非對稱密鑰算法是關鍵。
蘋果通過證書來授權開發(fā)者開發(fā)iOS應用泽艘，不同的證書具有不同的用處欲险，建議申請時使用相同的請求文件（即保證私鑰統(tǒng)一）∑ヤ蹋可以通過共享私鑰的方式讓團隊使用相同的私鑰和證書天试，已方便開發(fā)。為了保證app的安全性然低，app中所有的文件都會被簽名喜每，這樣，簽過名的app除非重新簽名雳攘，否則無法改動其中的任何東西带兜。
mobileprovision是一個配置文件，由蘋果簽名并發(fā)布給開發(fā)者来农。配置文件是一組信息的集合鞋真，這組信息決定了某一個應用是否能夠在某一個特定的設備上運行崇堰。配置文件可以用于讓應用在你的開發(fā)設備上可以被運行和調(diào)試沃于，也可以用于內(nèi)部測試 (ad-hoc) 或者企業(yè)級應用的發(fā)布。有了配置文件海诲，蘋果對開發(fā)者的約束就十分穩(wěn)固了繁莹。
所以，證書（及其對應的私鑰）和配置文件是簽名和打包的兩個必要文件特幔。必須深刻理解咨演，才能在日常的錯誤中找到解決辦法。
更多內(nèi)容可參考這幾篇：
Inside Code Signing
代碼簽名探析
