上架Appstore背后的故事

前言

眾說周知，iOS系統(tǒng)對第三方APP擁有很強力的控制權(quán)，有別于安卓系統(tǒng)上可以從任意地方下載，蘋果保證了每一個安裝在iOS系統(tǒng)中的APP都是經(jīng)過官方認(rèn)證的。那么在這表層現(xiàn)象的背后，引發(fā)我們的思考，蘋果是如何保證認(rèn)證。

準(zhǔn)備知識：非對稱加密

一、理論

首先說到非對稱加密，大家都熟知一個算法，RSA（又三位數(shù)學(xué)家名字首字母構(gòu)成），這個算法中包含很多數(shù)學(xué)公式和理論證明，這里就不做深究。我們來簡單地理解下非對稱加密的思想。

先來看看對稱加密的過程，對稱加密的雙方都保持相同的加密密鑰和解密密鑰，數(shù)據(jù)經(jīng)過加密密鑰加密之后再網(wǎng)絡(luò)中傳輸，對稱加密最大的問題就是解密秘鑰的如何安全傳輸。

再來看看非對稱加密，非對稱加密有兩個密鑰，公鑰和私鑰，公鑰公開，私鑰私有。

二、非對稱加密的例子

加密：

A想要傳輸信息給B，那么B首先生成公鑰和私鑰，公鑰發(fā)送給A，私鑰保留，A收到B的公鑰之后，將信息利用公鑰加密，然后傳輸給B，B通過私鑰解密。

防止篡改：

B想要給A發(fā)送一個證明，那么B首先生成公鑰和私鑰，利用私鑰加密證明生成加密文件，然后將證明和加密文件以及公鑰一同發(fā)送給A，A收到之后，利用公鑰將加密文件解密，然后對比證明，如果相同，則可以認(rèn)為證明沒有被篡改過。

蘋果的數(shù)字簽名

蘋果生成了一對密鑰，公鑰安裝在每臺iOS設(shè)備上，私鑰保存在蘋果后臺服務(wù)器中，當(dāng)APP上架到Appstore的時候，蘋果后臺用私鑰對App進行簽名（加密），當(dāng)用戶使用iOS設(shè)備下載App時，利用設(shè)備中的公鑰驗證簽名，如果簽名正確，那么可以認(rèn)為該App是被官方認(rèn)證的，同時也沒有被修改過。

上面的邏輯很通俗易懂，當(dāng)然，這只是最簡單的邏輯?？紤]到很多實際情況，蘋果制定了更為復(fù)雜的簽名機制。

實際情況

開發(fā)者可以直接把開發(fā)中的應(yīng)用安裝進手機進行調(diào)試

更復(fù)雜的簽名機制

一、簽名

首先在Mac機器中生成一對公鑰和私鑰，這里標(biāo)記為公鑰M，私鑰M（M：Mac）

同樣蘋果仍然持有一對密鑰，公鑰放在iOS設(shè)備上，私鑰放在后臺服務(wù)器，這里標(biāo)記為公鑰A，私鑰A（A：Apple）

簽名：

1.將公鑰M上傳到后臺服務(wù)器，通過私鑰A進行簽名，然后返回簽名和公鑰M，將其稱為證書

2.用私鑰M對App簽名

將以上兩者內(nèi)容打包，安裝在手機上

二、驗證

首先利用設(shè)備中的公鑰A對證書中的簽名進行驗證，確保公鑰M是是認(rèn)證過的

然后利用公鑰鑰M對App簽名進行驗證，確保App是認(rèn)證過的

更完善的策略設(shè)計

以上是簽名的大致過程，但是蘋果還加了兩個限制：

1.只有在后臺注冊過的設(shè)備才能安裝

2.簽名機制應(yīng)該針對具體的某一App

完善的簽名機制

做一些小調(diào)整

在簽名過程中，原來只講私鑰M上傳后臺服務(wù)器，現(xiàn)在需要將設(shè)備的IDs和AppID以及Entitlements（權(quán)限開關(guān)）也傳入到后臺服務(wù)器

先利用私鑰A簽名得到證書，然后將證書和添加的信息打包后再用私鑰簽名（由一次簽名變成兩次簽名，驗證也從一次變成兩次）

在驗證過程中，添加了兩項驗證：

1.用設(shè)備IDs驗證iOS設(shè)備是否屬于注冊的設(shè)備范圍

2.用AppID驗證App的ID是否對應(yīng)

概念與實際操作對應(yīng)

一、簽名

在keychain中選擇“從證書頒發(fā)機構(gòu)請求證書”，可以在本地生成一對公鑰私鑰，私鑰保存在電腦中，公鑰為生成的CertificateSigningRequest

iOS系統(tǒng)中保存一個公鑰，蘋果后臺保存一個私鑰

簽名：

1.將CertificateSigningRequest上傳到服務(wù)器進行證書的申請，然后在網(wǎng)頁上設(shè)置設(shè)備的IDs、AppID和Entitlements，配置完成后即可下載Provisioning Profile文件（該文件中包含證書、設(shè)備IDs、AppID、Entitlements）

2.Xcode通過Provisioning Profile中的本地公鑰可以找到對應(yīng)的私鑰（如果其他機器想要編譯這個APP，則需要將私鑰導(dǎo)出，為.p12文件），并簽名該App，接著把Provisioning Profile文件命名為embedded.mobileprovision一同打包

二、驗證

1.先用公鑰驗證證書和附加信息的包的簽名，然后再驗證證書的簽名

2.利用公鑰驗證App簽名

3.利用附加信息驗證