深入浅出iOS签名机制(provision,certificater,p12)

1.前言

苹果的为了管控app权限，搞出了一套复杂的签名原理。很多概念工作了四五年的人也未必能弄清，最近决定花时间研究一下，从概念上一步步递推，不仅知其然，更要知其所以然。

2.为何要这么复杂的权限管理

在Windows盗版软件满天飞的时代，随便下载一个软件，就可以在机器上运行，虽然对于用户来说很爽，但也有很多隐患，比如各种病毒，比如软件的质量得不到保证。而苹果爸爸显然不希望跑在自己手机上的软件app自己的控制。权限管理就是在这种情况下诞生的。

3. 具体策略

3.1 最简单的非对称加密

苹果自己有一对公钥和私钥，我们称它为A。私钥存储在苹果服务器，公钥存储在每台Device上。 那么对于从appSotre下载的app, 苹果都会用私钥A对其进行签名，在device上运行时，苹果系统会首先会用公钥A来解密，从而dump出内容包，最后运行app。

如果这么简单就能搞定，那么也不会出现那么多复杂的Per,Certificater, provision之类的概念。因为苹果不但要支持appStore下载，还要支持开发者在将app上传到appStore之前，在自己的device上build测试。那么这个时候无法用私钥A对app进行签名，device要怎么认证呢。

3.2 开发者认证的流程

苹果的流程是这样的：

1. 开发者本地生成一对公钥和私钥L. 私钥存在keyChain中，公钥上传到苹果服务端，苹果会生成一个Certificater文件，这是用苹果私钥A进行过数字签名的文件，包含了开发者id,开发者公钥L等信息。
2. 具体开发者在开发一个App时，有需要生成一个开发者provision，privison包含了荣（1）用户的公钥证书Cetificater (2)能够运行的DeviceID列表 （3）App可使用权限，苹果同样用私钥A进行数字签名，并返回给开发者。
3. 开发者在完成 App开发并打包时首先会用私钥L对app进行签名，并会同Provision文件打进最终bundle（名字为embedded.mobileprovision）， device在运行时先通过公钥A将Provision解密，得到其中的证书（再次解密得到公钥L）,设备ID列表，权限文件（Provision由于是苹果私钥签名的，所以无法更改），然后用公钥L解码app内容，并通过设备列表ID和权限信息来判断app能否在当前device上运行。

那么开发者换一台机器怎么办，那么就把私钥导出吧，.p12文件就是为密钥导出而生的。有了私钥就可以轻松的再生成Certificater文件了。

企业证书签名也是一样的，只不过Device数量变多了。

3.3 一些绕过的机制

比如说以前各种app助手的重签名机制。
develop和distiton的provision。
待续