1. 程式人生 > >iOS批量自動打包和部署(I)

iOS批量自動打包和部署(I)

如果你遇到這樣的一項需求:專案的程式碼沒有變動,只是icon和介面改動,然後要打成很多的包,發往AppleStore。就像喜馬拉雅的各種小版本那樣,像牛皮鮮一樣汙染在AppleStore之上。那麼問題來了,成十上百的包,僅僅只是icon的圖示變了,程式碼都一樣,難道要人工在那打成十上百次嗎?答案當然是否定的,不想著把工作變簡單的程式設計師不是好程式設計師。

帶著上面的問題,腦子裡孕育了這個系列的文章。希望通過這個系列的文章,能加深一下對加密,蘋果的證書,自動打包,程式碼簽名,重新簽名等的瞭解,文章出現任何錯誤,歡迎指正。

本篇主要涉及對一些基本概念的理解,後續的文章將會有Demo和最終的指令碼,如果想直接用指令碼,請稍後。

對稱加密(symmetric cryptography)和非對稱加密(asymmetric cryptography)

先從對稱加密和非對稱加密講起。

  • 對稱加密:加密和解密用的是同一個祕鑰
  • 非對稱加密:加密和解密是不同的鑰匙

客戶端(Client)和伺服器(Server)進行通訊,Client和Server約定好相同的一把祕鑰,Client傳送的明文通過這把祕鑰進行加密,Server在收到這段加密後的密文後通過事先約定好的那邊祕鑰進行解密得到明文。理論上只要保證祕鑰不被洩露就可以保證安全,但是實際上這種方式很不安全,如果祕鑰被破解,又恰好伺服器只用了這一個祕鑰(這可能是最糟糕的情況),那麼伺服器和其他的客戶端之間的通訊基本上就是完全暴露了。這個例子說的是對稱加密。

對稱加密

還有一種情況,比上面的想法更加出色一點。每個端都生成一個“私鑰-公鑰”對,私鑰是自己保管,公鑰可以隨便分享,用公鑰可以解開私鑰,用私鑰可以解開公鑰。例如服務端生成了一個“私鑰-公鑰”對,自己保留了一份私鑰,把公鑰給客戶端,客戶端對傳送的訊息通過公鑰進行加密,服務端在收到這個公鑰後用自己的私鑰進行解密還原得到明文。

非對稱加密

常見的對稱加密有:DES,AES等 常見的非對稱加密有:SSL,HTTPS,TLS,RSA。 祕鑰長度越長破解的難度越大。我在iOS持久化資料時用過AES,其他的沒有用過。非對稱加密中RSA是很有名,被應用的很廣泛的數字證書。

數字簽名和數字證書

看下面的一個場景:

A生成了一對“私鑰-公鑰”,然後把公鑰給了B,B用公鑰加密一段訊息,發給A,A收到訊息後用私鑰解密,接著A用私鑰加密一段文字給B,B收到後用公鑰解密檢視明文。如此反覆。

上面是一個非對稱加密聊天的具體場景,雖然經典,但是還是有一些問題。

1.A在收到B的資訊的時候不能保證B發的資訊是最原始的,即傳輸的內容有可能被篡改
2.黑客C獲取了B的公鑰,然後偽裝成BA進行通訊

上面的情況都是可能出現的,現在這樣,A為了保證資料不被改動,先對資料用hash函式生成一個摘要(digest),然後用私鑰對這個摘要進行加密,生成了“數字簽名”(signature),B在收到這個訊息時先用公鑰對摘要進行解密得到摘要並且對資料內容也進行一次hash,比較這次的hash是否與之前解密得到的摘要一致,如果一致,說明資料沒有被改動。我們把對內容資料進行hash後再加密生成的一段內容稱為“數字簽名”。

黑客C進行偽裝交流的可能性也是有的,為了解決這個辦法,A去找了一個權威的“證書中心”(certificate authority,簡稱CA),為公鑰做驗證。CA用自己的私鑰對A的公鑰和一些相關資訊一起加密,生成了“數字證書”(Digital Certificate)。這樣A在進行訊息傳遞時也附帶上數字證書,B在收到訊息時用CA的公鑰解開數字證書拿到真實的公鑰,通過這樣的方式驗證身份。

在Mac上的鑰匙串訪問app是專門用來管理證書的。iOS開發者在申請iOS開發證書時,需要通過keychain生成CSR檔案(Certificate Signing Request),提交給蘋果的Apple Worldwide Developer Relations Certification Authority(WWDR)證書認證中心進行簽名,最後從蘋果官網下載並安裝使用。這個過程中還會產生一個私鑰,證書和私鑰在keychain中得位置如圖:(以下這段摘自這篇文章,因為我發現這個圖非常形象)
http://img.objccn.io/issue-17/iphone-developer-keychain.png

iOS系統原本就持有WWDR的公鑰,系統首先會對證書內容通過指定的雜湊演算法計算得到一個資訊摘要;然後使用WWDR的公鑰對證書中包含的數字簽名解密,從而得到經過WWDR的私鑰加密過的資訊摘要;最後對比兩個資訊摘要,如果內容相同就說明該證書可信。整個過程如圖所示:
https://img-blog.csdn.net/20130603170924312

在驗證了證書是可信的以後,iOS系統就可以獲取到證書中包含的開發者的公鑰,並使用該公鑰來判斷程式碼簽名的可用性了。

每個iOS的開發者都必需有蘋果的證書和祕鑰,因為在打完包的最後一個流程就是進行簽名,沒有這些就無法提交appstore。

objc.io上面有篇《Inside Code Signing》(中文翻譯篇:程式碼簽名探析)上詳細的講述了一個已簽名應用的組成和一些其他知識,是一篇很不錯的學習文章,下篇blog也會在講打包之前穿插這個程式碼簽名探析裡面的知識要點。