iOS 打包签名，你真的懂吗？_ios打包时的keyid

iOS签名类型有Development、AD-Hoc、In-House与App Store，而打包过程中又涉及到各种证书、Provision Profile、entitlements、CertificateSigningRequest、p12、AppID…各种概念一大堆，本文将从打包签名的原理说起，并梳理完全签名的整体流程，最后讲解重签名的实现以及签名机制中有哪些需要注意防护的要点。

为了保证App的分发平台是可控的，以及保证所有安装到iOS设备上的App都是经过苹果官方允许的，苹果建立了iOS签名打包机制。要了解iOS签名机制的实现，我们首先从签名机制的原理说起。

1. 签名原理

1.1 不对称加密

网络数据的传输可以使用对称加密以及不对称加密的方式进行安全防护，对称加密是指数据发送者（A）和接收者（B）双方进行加解密的密钥是一致的，但这样会增加密钥自身分发的不安全性：比如要如何保证密钥在传递过程中不被泄露。

而不对称加密则由A、B持有一对公私钥进行加解密，公私钥钥匙是成对出现的。对于一个私钥，有且只有一个与其对应的公钥，私钥保密、公钥公开，但是不能通过公钥推导出私钥，使用私钥加密的文件可用公钥解密，反过来公钥加密的文件也只能用私钥进行解密。加密过程如下：

1. 发送方（A）首先生成一对公私钥钥匙对，私钥自己保管，公钥则任意分发出去（每台iOS设备终端其实已经包含Apple的公钥）。

2. 发送数据时，发送方使用私钥对原数据加密成密文传输（加密打包ipa）；

3. 接收方（B）收到密文后，使用之前已经获取到的公钥进行解密得到数据内容（iOS设备验证安装ipa）。

1.2 数据签名

这里主要解决了两个问题，一个是加密数据大小的问题，另一个是如何验证公钥的有效性。

1.2.1 信息摘要

前面已经讲到，iOS打包安装的过程中会对ipa包进行加解密验证。然而ipa安装包大小动辄就有十几M，大的有好几G，那如果对这么大的数据量进行加解密，肯定效率是非常低的。而信息摘要则是解决了加密数据过大的问题，其原理是对信息内容通过一个很难被逆向推导的公式计算得到一段哈希数值，它具有以下特点：

• 计算得到的哈希值大小固定，不受原本信息内容大小的影响；
• 不可逆，根据哈希值无法推断得到原本信息（实际上MD5以及SHA-1算法已经被证明可以被破解）；
• 唯一性，原本信息内容一致，那么哈希值也一致；原数据不同，也不会存在重复的哈希结果。

使用信息摘要技术在数据加密传输时，发送方先对文件内容使用哈希算法进行信息摘要计算，再对摘要内容进行加密，之后将文件内容以及摘要内容（已加密）发送出去。

接收方收到数据后，先解密得到摘要内容，再依据相同的哈希算法对文件内容进行信息摘要计算，最后匹配接收到的哈希值与计算得到的哈希值是否一致，如果一致那就说明传输过程是安全的。

这样也就避免了对整体原数据加解密的计算过程，从而提高了验证效率。

1.2.2 签名证书

不对称加密中的公钥是公开的，谁都可以得到，这样也就存在了不安全性。比如主动攻击者C冒充数据发送者A，将自己伪装后的公钥分发给数据接收者B，从而达到监听A、B之间通信的目的，又或者是对A、B之间的通信数据进行注入攻击。

那为了保证获取公钥的安全性，这里引入CA认证（Certificate Authority）。CA是证明公钥合法性的权威机构（Apple就属于CA认证机构），它为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。用户使用CA的公钥对数字证书上的签名进行验证，如果验证通过，也就认为证书内包含的公钥是有效的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-63D02qZy-1591770044343)(https://upload-images.jianshu.io/upload_images/18569867-2baae17ec6e73b39.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]

CA认证确保了用户公钥使用过程中的安全性，iOS打包需要向苹果开发者中心上传.certSigningRequest文件，然后配置得到各种.cer证书，这些流程中便包括了开发者向Apple CA认证中心注册公钥的过程。