​
表弟最近负责公司的iOS打包工作,但是总是出现各种问题.
上次看见他,头已经和西瓜一样大了.
表弟是伯父家的独苗,实在不忍心看他这样子.
为了保住这一支血脉,这一次,我们针对AppStore发布的应用,来了解一下App打包签名的完整流程.

看完这篇文章,你可以掌握以下知识点:
a. 整体掌握iOS App打包上架的流程
b. 对打包中需要的资料有清楚的了解
c. 在整个流程中,苹果是如何保证用户安装的App是经过授权的

0. 打包整体流程

App完整的打包上架,经过4道工序:
a. 账号管理者申请证书
b. 开发者打包
c. 账号管理者上架应用
d. 用户下载安装

有的公司账号管理者和开发者是同一个人,但也有的不是,所以这里分开了这两种角色.
为了更好地理解本文,希望读者对数字签名有一定了解,如果还不是那么了解数字签名,请参考文末给出的有关数字签名文章.

1. 账号管理者申请发布证书

1.1 申请CSR文件

账号管理者在创建CSR文件的同时,会在创建CSR文件的Mac电脑上同时创建本地公钥PublicKeyOfLocal(PkL)和本地私钥SecretKeyOfLocal(SkL),并保存在管理者电脑的KeyChain中;

而生成的CSR文件,包含了本地公钥PkL的所有信息;

注意在整个流程中,一共牵涉到两对密钥:

• 账号管理者创建的公钥PkL和私钥SkL,这一对是在管理者申请CSR文件的时候创建的;

• 苹果公司的公钥PublicKeyOfApple(PkA)和私钥SecretKeyOfApple(SkA).这一对是早就部署好的.苹果私钥SkA存在于苹果后台,苹果公钥PkA存在于所有的iOS设备.

1.2 上传CSR文件

账号管理者上传CSR文件到苹果服务器后台.

苹果后台把CSR文件中的本地公钥PkL提取出来,并用苹果私钥SkA对其签名,得到一个PkL及其签名的数据包,这个数据包就是发布证书;

1.3 制作ProvisionProfile描述文件

账号管理者选择AppId,证书和设备Id之后,在后台生成描述文件.

描述文件就像一个账本,记载了App使用了哪些功能,关联了哪个发布证书,可以安装到哪些设备上等信息.

在后续打包的时候,编译器会对程序的AppId,使用的功能以及使用的证书与描述文件上记录的信息进行比较,只有全部一致,才能进行打包;

而在安装的时候,iOS设备,又会将本机的设备id和描述文件中记录的信息进行比较,只有一致,才能安装;

1.4 下载发布证书和描述文件并提供给开发者

账号管理者电脑上存在本地私钥SkL,证书中包含本地公钥PkL
所以这两个文件在KeyChain中会匹配成一对;
账号管理者需要将本地私钥SkL,证书,描述文件给开发者,这样开发者才能打包;
而证书和私钥导出来的方式,就是一个p12文件.
导出的时候,管理者设置了一个密码,需要将该密码一起给开发者,开发者才能提取其中的私钥和证书;
所以,账号管理者,需要给开发者3个资源:
a. 描述文件
b. 包含私钥和证书的p12文件
c. p12文件的密码

2 开发者打包App

2.1 准备4个资源

开发者将App源代码打包成ipa文件,需要准备以下4个资源:
a. App源码,由开发者编写得到;
b. 描述文件,由账号管理者提供给开发者;
c. 本地私钥SkL
d. 发布证书,发布证书和本地私钥SkL由账号管理者提供p12文件得到;

2.2 验证资源有效性

打包时,App需要有一个BundleId,指定发布证书和描述文件,编译器会根据描述文件对各个要素进行验证:

a. 描述文件和发布证书均在有效期内;
b. 实际使用的发布证书是描述文件中指定的证书
c. App的id和使用权限与描述文件中记载的一致;
d. 打包的机器上存在指定证书相匹配的本地私钥SkL;

2.3 签名打包

各个要素验证没有问题后,开始打包
a. 使用本地密钥SkL对App源码进行签名
b. 整合App,App签名,描述文件,发布证书,得到最终ipa包供用户下载

3 账号管理者上架App

开发者将ipa包给账号管理者,账号管理者上传到苹果后台发布.
这一步主要就是文件和信息的上传,具体的流程不在本文讨论的内容范围之内;
账号管理者上传App之后,等待苹果审核委员会对App的内容进行审核,审核通过之后,就可以在AppStore上下载;

4 用户下载和安装App

现在终于到了用户从AppStore上下载完App,准备安装了.App的安装又经历了以下流程:

4.1验证公钥PkL

前文提到过苹果公司有一对密钥对.
私钥SkA存在于苹果后台,在生成发布证书时,用来对本地公钥PkL加密;

公钥PkA,存在于所有的iOS设备,用于在安装应用时,验证证书中的公钥PkL是没有被篡改的;

公钥验证签名的流程可以参考文末给出的有关 数字签名 的文章.

4.2 验证源代码

用经过验证的公钥PkL去验证App源代码是没有被篡改的;

4.3 iOS设备安装程序

经过双重验证后,最终可以确认App是经过苹果验证没有篡改的,并且程序所使用的功能,安装App的设备id都和描述文件中的信息一致.​

5 总结

5.1 iOS App打包上架的流程

a. 账号管理者申请证书
b. 开发者打包
c. 账号管理者上架应用
d. 用户下载安装

5.2 打包中需要的资料

a. App源码,由开发者编写得到;
b. 描述文件,由账号管理者提供给开发者;
c. 本地私钥SkL
d. 发布证书,发布证书和本地私钥SkL由账号管理者提供p12文件得到,同时需要密码;

5.3 苹果是如何保证用户安装的App是经过授权的

苹果的双重验证,主要是防止用户安装的App不是开发者打包的App;

我们假设开发者实际打包的内容是App,App签名数据是SignApp;本地公钥是PkL,本地公钥签名是SignPkL;

用户实际安装的应用是App1,签名为SignApp1,本地公钥是PkL1,本地公钥签名为SignPkL1;

第一轮验证PkL时:
如果PkL!=PkL1,SignPkL==SignPkL1,那么设备用PkA验证会失败,无法安装;
如果PkL!=PkL1,SignPkL!=SignPkL1,那么除非SignPkL1是用SkA签名PkL1得到的,否则必然会失败;而SkA在苹果后台,无法获取到;

第二轮验证App时:
如果App!=App1,SignApp==SignApp1,那么,设备用PkL去验证SignApp1的时候,必然会失败,无法安装;
如果App!=App1,并且SignApp!=SignApp1,除非SignApp1是用SkL签名的,否则用PkL验证也会失败,而SkL是存在于管理者和开发者电脑上的,篡改者也无法获取到;

所以,经过这样的双重验证,保证了用户安装的App都是经过苹果授权的.