导语：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算法已经被证明可以被破解）；
• 唯一性，原本信息内容一致，那么哈希值也一致；反过来理论上不同内容的原数据可能会碰撞产生相同的哈希值（这也就是上面说到的被破解），但碰撞概率的大小受哈希函数的影响，而且这只是理论上的概率事件可以认为这并不影响信息摘要在iOS签名中的使用。

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

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

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

1.2.2 签名证书

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

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

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

2. iOS签名

2.1 概念要点

• .certSigningRequest 文件。从Mac的钥匙串访问中生成 .certSigningRequest 文件，这个过程会从Mac终端生成一对钥匙对，私钥存储在Mac中，公钥则包含在 .certSigningRequest 中。再将 .certSigningRequest 文件上传到Apple后台即苹果开发者中心，则可以对应生成开发证书或者发布证书（.cer文件）。

• .cer 文件：Apple后台使用Apple私钥对Mac公钥进行签名后生成的证书。
• .p12 文件：Mac本地生成的钥匙对私钥。由于私钥是本地私有的，但你可以使用`.p12`将私钥导出给其他团队成员使用。
• Identifiers。Identifiers 是iOS设备安装应用时用来识别不同App的唯一标识，点击创建App IDs，同时勾选app所包含的权限：APNs、HealthKit、iCloud等。
• entitlements。App使用到的各种权限（APNs、HealthKit、iCloud等），也是需要Apple验证通过后才能生效的，Apple将这些权限开关统一称为Entitlements。当第一次在Xcode中勾选权限时，项目中会自动生成一个.entitlements后缀的文件，里面记录了App所拥有的权限。
• Profiles。.cer 文件只是声明了证书的类型，比如Apple Development、Apple Distribution、APNs推送等等，而至于使用什么证书打包、AppID是什么、打包的App包含了哪些功能、可以在哪些设备上安装，则是通过 Provisioning Profile 描述文件（.mobileprovision后缀）来说明的，苹果后台将所有这些信息组合后再使用Apple私钥进行签名，最后生成Provisioning Profile描述文件：

2.2 AppStore签名

发布App至AppStore之前需要经过苹果后台审核，审核通过苹果后台会用Apple私钥对App数据进行加密签名生成ipa包；用户从AppStore下载App后，使用设备内置的Apple公钥解密验证，验证通过安装成功。由于AppStore分发的过程中上传审核、下载安装的整个过程都处在苹果的生态链内，所以只需要一次验证就能保证安全性。

2.3 其他签名

从AppStore下载安装App只需要一次数字签名就足以保证安全性，但除了这种途径苹果还有其他的安装方式：

• 开发中连接设备到Xcode进行调试安装
• AD-Hoc内部测试安装，需要先获取设备UDID并注册，并且有最多100台设备的限制
• In-House企业内部分发，安装设备数量无限制，但安装后需主动在设置中选择信任证书

那这些安装App的过程中苹果又是怎样保证流程安全性的呢？答案就是 双重签名机制，苹果使用前面讲到的Mac本地钥匙对以及Apple后台钥匙对进行多次数字签名，从而保证整体流程的可控。

1. Mac 钥匙串访问在本地生成一对公私钥钥匙对，下面默认为公钥L、私钥L（L：Local）。

2. Apple已有一对公私钥钥匙对，私钥A在Apple后台，公钥A内置到每一台iOS设备终端（A：Apple）。

3. 上传 公钥L 至Apple后台，使用 私钥A 对 公钥L进行数字签名生成签名证书 .cer ，同时使用 私钥A 对额外信息（使用什么证书打包、AppID、打包的App包含了哪些功能、可以在哪些设备上安装）进行签名生成描述文件 Provisioning Profile，之后将 .cer和Provisioning Profile下载安装到Mac机器上。

4. 编译打包app，选择签名证书 .cer，打包指令会自动找到该证书对应的私钥L（能匹配是因为钥匙对是成对出现的，前提是本地必须已经存在L私钥，也就是p12的安装），然后使用私钥L对app进行签名。

• 这些签名数据包含两部分：Mach-O可执行文件会把签名直接写入这个文件中，其他资源文件则会保存在 _CodeSignature目录下。你可以将打包生成的 .ipa文件另存为 .zip，解压后对 Payload 文件夹中的 .app 文件右键、显示包内容，就可以看到签名数据。
• 另外签名过程中对于App内包含的动态库以及插件（Plugins、Watch、Frameworks文件夹），每一个都会单独进行一次签名，并生成各自的Mach-O可执行文件和_CodeSignature。
• 签名数据指代码内容、App包含的所有资源文件，只要其中有任何改动，都必须重新签名才有效。

5. 打包的过程中会将描述文件 Provisioning Profile 命名为 embedded.mobileprovision放入到打包app中。

6. 安装/启动，iOS设备使用内置的 公钥A 验证 embedded.mobileprovision 是否有效（设备是否在允许安装列表内），同时再次验证里面包含的 .cer 证书签名是否有效（证书过期与否）并取出 公钥L。

7. embedded.mobileprovision 验证通过，就使用 公钥L 解密验证app签名信息：AppID是否对应、权限开关是否跟app里的 entitlements 一致等等。

8. 所有验证通过，安装/启动完成。

以上流程便是开发调试、AD-Hoc、In-House等方式打包安装App的过程，区别只在于第⑤步中 设备IDs 的匹配规则不一致。开发调试只安装当前联调的设备；AD-Hoc允许安装到已在开发者账号下注册过的设备，且每年最多允许100台；In-House无设备数量限制，常用于企业内部App的分发。

3. ipa包重签名

ipa包重签名主要针对的是非App Store的安装包，App Store分发最终是上传ipa文件到苹果后台审核，通过后使用Apple私钥加密，然后才能发布安装，不存在重签入侵的可能。而开发调试、AD-Hoc、In-House等分发途径生成的ipa包不存在苹果后台验证的步骤，这也就意味着你可以对任意的.app、.ipa文件进行重签名。

回顾前面讲到的签名流程，真正对ipa包进行签名的关键步骤（④⑤）是在Mac本地进行的，签名过程中需要满足三个条件：App即软件代码编译生成的产物、p12证书以及Provisioning Profile配置文件。其中App的内容是动态变动的，Apple不会去验证它，实际上也无需验证，因为在开发调试过程中，所开发的App肯定是不停的迭代变化的，如果需要上线App Store那Apple只需在审核阶段对App内容进行把关验证即可，而其他分发渠道它则管不了。p12以及Provisioning Profile则是下载后主动安装的，大部分情况下都是由管理员创建下载好之后，导出分发给团队成员。

3.1 签名指令

iOS签名调用的是 codesign 指令，你也可以直接使用相关指令进行签名，下面是codesign的常用指令：

# MAC终端输入： codesign --help

codesign --help

Usage: codesign -s identity [-fv*] [-o flags] [-r reqs] [-i ident] path ... # sign

       codesign -v [-v*] [-R=

                                                        
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/56190.html