导读：iOS 签名校验机制是苹果生态安全的基础，日常工作中无论是开发阶段还是测试阶段常常会遇到很多需要通过签名机制解决的问题，了解 iOS 签名机制的原理有助于提高我们解决相关问题的成本和效率。本文首先介绍数字签名和证书的原理，之后会介绍苹果开发者证书的生成安装过程，最后对苹果实现签名校验的流程及流程中涉及的关键信息进行介绍，希望能对大家有所帮助。

全文 9494 字，预计阅读时间 24 分钟。

背景

iOS15 beta 版发布后，QA 同学需要测试新功能在iOS 15 系统下的功能稳定性，但是通过公司流水线打出的企业包无法安装在 iOS 15 系统的设备上，具体报错见下图：

通过在控制台查看安装过程中的具体报错信息，发现具体的IPA 包的签名信息在 iOS 15 系统上已经不再被支持了： The code signature version is no longer supported.详细的控制台报错信息如下图所示：

也就是安装失败和IPA 的代码签名版本有关，为此通过codesign命令查看流水线产出的IPA 的相关签名信息，具体信息见下图，其中CodeDirectory的版本为 v=20400：

CodeDirectory 直译是代码目录，记录的是将 Mach-O 文件分页后每页的哈希值信息，除此之外还包含了资源文件的摘要信息、权限信息等，这些信息按照一定的格式组合在一起，而不同的 signature version 对应这不同的信息种类、组合形式或计算算法。去年从 iOS 14 beta2 开始，苹果系统采用一种更为安全的签名格式，在其上运行使用旧签名格式签名的 APP 时会出警告弹窗。其官方介绍中提到 In a future release, the new format will become mandatory, and the system won’t launch apps with the old signature format.因此怀疑是签名格式在 iOS 15 系统上进行了强制校验，导致安装失败:

在官方文档中提到 If you signed your app on a Mac running macOS 10.14 or later, the app already has the new signature format.换句话说 macOS 系统的版本会影响到签名的格式；  "For any value of v less than 20400, you’ll need to re-sign your app." 

当 CodeDirectory version 的值小于 20400  时可以通过重签名来解决签名失效问题。而 CodeDirectory v=20400 可以安装在 iOS 14 系统上，但是却无法安装在 iOS 15 系统上。为了解决这个问题，采用重签名的思路，在 macOS 11.5.2 及 macOS 12.0 Beta 版系统下分别对流水线 IPA 包重签名后，均可以正常安装在 iOS 15 系统上了。

以上是 iOS 签名校验机制的一个体现，日常开发及测试中，与上述 iOS 签名校验机制相关的事情还有很多比如修改系统时间后使得企业证书过期从而导致启动崩溃等，在这里再和大家一起分享下有关 iOS 证书与签名校验相关的一些信息。

首先我们看几个问题：

• 什么是签名校验机制？

对可执行文件或脚本进行数字签名，用来保证软件在签名后未被损害或者修改的措施；

• 苹果为什么要使用签名校验机制？

Signing your app allows iOS to identify who signed your app and to verify that your app hasn’t been modified since you signed it. 

即确定 APP 来源并防止外部攻击，以实现苹果对其生态的控制；

• 苹果如何实现签名校验？

这是 iOS 签名校验机制的流程示意图，在学习过程中，个人觉得理解清楚非对称加密、数字签名以及数字证书的原理对于理解整个签名机制非常重要，因此在文章的开始会对加密与解密、数字签名以及数字证书做一些说明，然后结合数字签名和证书的原理，对苹果创建开发者证书的流程以及 iOS 签名校验流程包括过程中涉及到一些关键信息进行说明：

1. 加密与解密、数字签名、证书在通信过程中各自的作用

2. 解析苹果开发者证书的生成安装过程

3. 苹果实现签名校验的流程及关键信息

一、加密与解密、数字签名、证书在通信过程中各自的作用

无论是从 AppStore 下载 App 安装到手机上还是在 Debug 阶段通过 Xcode 将 App 安装到测试机上进行真机调试，其实都是一次将 App 包发送到手机沙盒中的一次通信过程，如何保证一次安全有效的通信呢？或者说在一次通信过程中可能面临哪些安全问题呢？

A 向 B 发送的明文，可以被中间路由直接查看，泄密了 --- 被窃听

好事者 C 修改了 A 向 B 请求内容，使得 A 发起了错误请求 --- 被篡改

好事者 C 拦截并模拟 A 向 B 发起请求，让 B 误以为是 A 发起的 --- 被欺骗

A 向 B 发起了请求，但是 A 就是不承认发起了此次请求 --- 被否认

1.1 防止被窃听 - 加密与解密

通信过程中是不好避免被第三方拦截的，但是我们可以做到即便被截获，窃听者仍然无法破译有效的信息，这个过程可以通过加密来实现。

目前加密算法主要有两大类，对称加密和非对称加密：

对称加密的特点是加密和解密使用的同一个秘钥，其特点是速度快，常用算法有： DES 、3DES 、AES ；

非对称加密的密钥分为公钥和私钥，其最重要的特性是使用公钥加密的信息，只能使用私钥解密，而使用私钥加密的信息，只能使用公钥进行解密，最常用的算法有 RSA ；

但是对称加密的密钥管理繁琐且密钥传输存在一定的安全隐患，而非对称加密算法速度比较慢，尤其是对于加密数据较大的信息时耗时更加明显。因此在实际使用过程中，最常使用的是混合加密方式：

发送方：1.对信息(明文)采用 DES 密钥加密；2.使用 RSA 加密前面的 DES 密钥信息；然后将 1 和 2 步产生的信息进行整合后传递。

接收方：接收到信息后：1.用 RSA 解密 DES 密钥信息；2.再用 RSA 解密获取到的密钥信息解密密文信息；最终就可以得到我们要的信息(明文)。

1.2 防止否认 - 数字签名

因为公钥是对外公开的，A 可以使用公钥加密信息计算摘要，B 也可以使用公钥加密信息计算摘要，也就是所有拥有公钥的人都可能成为信息发送者，这就导致 A 发送消息后可以否认。前面我们有提到非对称加密的特性：使用公钥加密的信息，只能使用私钥解密，而使用私钥加密的信息，只能使用公钥进行解密。公钥是对外公开的，但是私钥仅存在于密钥对生成者自己手里，所以当在发送消息时使用发送者的私钥加密信息，在接收端使用发送者的公钥来解密信息，那么接收端就可以精确确认消息发送者了，也就解决了消息发送者否认发送的问题。使用发送者的私钥对摘要进行加密，就形成了签名，即数字签名。

我们来看下数字签名是如何起作用的：

总结下数字签名的作用，主要有三点：1.可以确认消息的完整性；2.可以识别消息是否被篡改；3.可以防止消息发送者否认；

但是我们不能忽视一点：数字签名生效的前提：用于加密的公钥必须属于真正的接受者，用于解密的公钥必须属于真正的发送者。如果公钥被伪造了或者说好事者冒充发送者去发送消息，单纯依赖数字签名是无法解决的；我们一起来看下公钥被伪造时会发生什么：

由上图可以看到，如果公钥在传输过程中被伪造了，那么后续相关的通信过程都是建立一个伪造的密钥对间进行，从而导致这个通信过程不再安全。因此在验证签名之前，首先得先验证公钥的合法性。

但是如何保证公钥的合法性呢？

根据上面的相关介绍，为了保证公钥信息不被篡改和欺骗，那么最好的方式就是对公钥进行数字签名，但问题又来了，如何保证此次数字签名验证过程中公钥的合法性呢？再来一次数字签名吗？这就陷入了一个鸡生蛋蛋生鸡的过程了，为了打破这个死循环，人们创造了证书中心和数字证书。

1.3 保证公钥的合法性 - 数字证书

循环进行数字签名的原因是因为公钥有可能被伪造，为此人们将一些具有公信力的组织或者政府部门作为证书中心，由证书中心使用自己的私钥来对公钥进行数字签名。通俗理解证书中心就是那些能够认定“公钥确实属于此人”并且能够生成数字签名的权威个人或者组织，简称 CA。而由 CA 对公钥等信息施加数字签名后就生成了证书。

我们一起看下数字证书是如何起作用的：

消息接收者首先生成密钥对，并将公钥_B 及邮箱等信息在 CA 认证机构中进行注册，认证机构 CA 用自己的私钥_CA 对公钥_B 进行数字签名，并生成证书；消息发送者 A 向认证机构 CA 请求证书，并通过认证机构 CA 的公钥_CA 验证数字签名，以验证公钥_B 的合法性。

对此，我们对公钥、私钥、数字签名、数字证书的概念及作用有了一个大概的回顾。下面我们从数字签名及数字证书的生成流程角度来看下 iOS 开发者证书的生成与安装过程。

二、苹果开发者证书的生成与安装

-1.生成证书请求：钥匙串访问 -> 证书助理 -> 从证书颁发机构请求证书 （可以理解为 Mac 端创建非对称加密密钥对公钥 M 和 私钥 M 的过程，使用私钥 M 来签署生成 CSR 文件，CSR 文件中包含开发者的信息和公钥 M ，私钥 M 则存储在 Mac 端本地）

-2.登录开发者平台，将第一步生成的 CertificateSigningRequest.certSigningRequest 上传至 Developer 生成证书。（CertificateSigningRequest.certSigningRequest 可以理解为 Mac 生成的公钥，上传至开发者平台可以为将公钥 M 在证书认证机构 CA 进行注册，并利用苹果开发者中心的公钥 A 对 Mac 设备的公钥进行签名，生成开发者证书）

- 3.Mac 将证书下载到本地，双击安装（在安装过程中，钥匙串 keychain 会将第一步生成的私钥 M 与第二步生成的 Cer 证书关联在一起：

三、苹果实现签名校验的流程及关键信息

苹果签名校验机制的作用是要保证每一个安装到 iOS 设备上的 App 都是经过苹果官方授权的。为了实现上述效果，苹果采取的方案是双重签名，其大概流程可以参见下图：

> 1.首先在 Mac 端生成一对密钥对（公钥 M 和私钥 M），苹果也会生成一对秘钥对（公钥 A 和私钥 A），其中公钥 A 预置在 iOS 设备上，私钥 A 放在苹果服务器中；

> 2.开发者通过开发者后台将公钥 M 上传至苹果服务器，苹果服务器使用私钥 A 对公钥 M 进行签名生成证书，开发者下载该证书并安装在 Mac 中。安装过程中会将证书与私钥 M 进行关联。

> 3.在开发过程中，会使用私钥 M 对 APP 进行签名，同时会将证书也打包进 APP 中。

> 4.在安装过程中，iOS 系统首先会使用预置的公钥 A 对证书进行验证，得到公钥 M（验证成功，即说明证书是经过苹果私钥签名过的，根据前面的讲解我们知道这样就说明是经过苹果认证的了），然后使用公钥 M 对签名进行验证，验证成功后才能将 APP 安装在设备中。

那是不是只要拥有一个经过苹果认证的开发者证书，就可以将任意 App 安装在任意测试机上呢？显然这是苹果生态所不允许的。那苹果是通过什么方式实现设备限制的呢？而且，在团队开发中，也并不是所有人都去生成开发者证书，那又是通过什么方式实现团队授权的呢？以及在苹果开发者中心中配置的 BundleID 、Capabilities 、Devices 等信息在签名机制中又扮演着什么样的作用呢？

3.1 关于 P12 - 团队协作开发

在上面的签名过程中，我们看到开发者在对 App 进行签名过程中，主要用到两个信息：私钥 M 和证书，因此只需要将这两个信息提供给团队中的其它成员。在证书安装过程我们了解中，钥匙串会将证书与 Mac 生成的私钥 M 进行关联并存储为钥匙串中的一项，钥匙串支持将其导出为 p12  文件，然后我们将 p12 文件提供给团队成员安装就可以了。

3.2 关于 Entitlements - 权限管控

Xcode 在编译打包时会自动执行/usr/bin/codesign 命令进行代码签名，以下是签名的详细信息：

在签名时通过--sign 指定了证书信息，那么--entitlements 配置的是什么信息呢？

entitlements 链接：

(https://developer.apple.com/library/archive/technotes/tn2415/_index.html)

An Entitlement can be thought of as the string written into an app's signature that allows a specific capability or opts the app into a specific service. The operating system (OS) checks these strings before allowing an app access to certain features. For example, an app must have the iCloud entitlement before it is allowed to access iCloud APIs at runtime.

简单来说 entitlements 其实就是 iOS 沙盒环境的配置文件，苹果通过 entitlements 文件来管控一个 App 所能使用的服务和权限。Sandbox（沙盒）是 iOS 安全体系中很重要的一环，沙盒不仅仅使 App 间相互独立，同时也对每个 App 可操作的行为进行了管控，比如可以使用哪些敏感的系统能力（Push、Sign in with apple 等）等。Xcode 会默认生成一个包含有 Team ID 信息和 App ID 信息的权限声明，如果在 Xcode  Signing&Capabilities 中开启了相关权限，那么会显式的生成一个后缀名为.entitlements 的配置文件，里面包含了相关权限信息的说明。在--entitlements 选项后面的文件是在.entitlements 的配置文件基础上增加了默认配置后的信息。在 Xcode 签名时，会将该权限信息文件嵌入到二进制代码中，作为被签名内容的一部分，由代码签名保证其不会被篡改。　　

可通过 security cms -D -i /path/to/iOSTest.mobileprovision 来检查本地的 Provisioning Profile 是否包含所需要的权限。

3.3 关于 Provisioning profile

Provisioning profile act as a link between the device and the developer account. During development, you choose which devices can run your app and which app services your app can access. A provisioning profile is downloaded from your developer account and embedded in the app bundle, and the entire bundle is code-signed.  

Provisioning Profile 是一个由苹果证书中心加密签名的一个 plist 文件，包含有与之绑定的 App ID、设备的 UUID 列表、过期时间、TeamID、entilements 等信息以及用于对应用程序进行签名的证书，是苹果用来解决对设备授权以及管控 APP 敏感权限的解决方案。其在证书中心的配置页面如下：

在证书中心配置完 App ID、Unique Device Identifiers 以及 capabilities 等信息后，苹果证书中心会将这些信息与证书一起使用苹果的私钥进行签名，最后将签名信息与配置信息、证书、签名信息一起组成一个 Provisioning Profile 文件。开发者将其下载并安装，默认情况下 Xcode 会自动帮助开发者进行管理。以下是 Xcode 中安装的 Provisioning Profile 信息：

在 Mac 编译完一个 App 后，会将 Provisioning Profile 文件也打包进 App 中，并将文件命名为 embedded.mobileprovision。在 App 安装到 iOS 设备上时，iOS 设备会通过预置的公钥信息来验证 embedded.mobileprovision 的签名合法性，进而验证证书中的签名是否正确。

确保了 embedded.mobileprovision 里的数据都是苹果授权以后，就可以使用其中的信息来校验本次安装的合法性，使用公钥 A 验证 Mach-O 的签名信息、验证证书的签名及有效期、验证设备 ID 是否在设备列表中、Provisioning Profile 中的 App ID 是否与 BundleID 是否匹配等等；

值得注意的一点是：设备列表只在 Development 证书下生效，因为 Enterprise 、Distribution 证书本身就是要求可以任意安装，所以不受设备列表的限制；过期时间只对 Development、Enterprise 证书生效，Distribution 证书下不受限制，这也是当 Development、Enterprise 证书过期后会导致应用无法安装或无法启动，而从 App Store 下载的应用不会有时间限制。

当然在开发者中心可以随时对 Provisioning Profile 进行修改，更新不会对已有 Provisioning Profile 产生影响。

3.4 关于可执行文件与资源的签名

在编译生成 App 的过程中，Xcode 会通过钥匙串找到与配置证书配对的私钥 M 对二进制文件进行签名，并将签名信息嵌入到可执行二进制文件中，用于在安装时确认 Mach-O 文件是否有被修改。可通过 MackOView 验证：

但是 App 中不仅仅包含二进制文件，还包含一系列诸如图片、音视频文件等预置资源，因此通过单一的对二进制文件进行签名不足以保证整个 App 文件的完整性和有效性。在 iOS 中，应用程序使用遵循 shallow application bundles 结构的目录来存储必要资源和数据信息，大致为：

TestProject.app |用户可见应用程序

Info.plist |文件，其中包含有关软件包的信息
TestProject |可执行二进制
Assets.car |图标，显示为用户可见应用程序
Framework |任何可执行文件使用的框架或动态库
AFNetworking.framework |iOS 软件中常见框架示例

以下是一个非常简单的 IPA 包的包结构：

可以看到为了保证可执行文件及其在运行期间所依赖的数据和资源不被篡改，在实际生成的 APP 包中，会新生成一个_CodeSignature 目录，在该目录下包含一个名为 CodeResources 文件，该文件为 plist 类型的文件，里面包含了 App 下除可执行文件外其它文件的信息，key 通常为文件名，value 通常为其摘要信息。里面会有 files 和 files2 两项，其中 files 保存的是每个文件的 sha1 的值，files2 同时保存了 sha1 和 sha256，主要原因是 sha1 存在不安全性。_CodeSignature/CodeResources 文件的主要作用是记录签名后每个文件的哈希值，以在安装时用来确保对应的文件没有被篡改过。

3.5 签名及校验流程

> 1.首先在 Mac 端生成一对密钥对（公钥 M 和私钥 M），苹果系统本身也会生成一对密钥对（公钥 A 和私钥 A），其中公钥 A 预置在 iOS 设备上，私钥 A 放在苹果服务器中；

> 2.开发者将公钥 M 整合在 csr 文件中通过开发者后台上传至苹果服务器，苹果服务器使用私钥 A 对公钥 M 进行数字签名生成证书；同时使用私钥 A 将证书、AppID、entilements、设备 UDIDs 等信息加密生成 Provisioning Profile 文件；对应的开发者下载证书和 Provisioning Profile 文件并安装在 Mac 中。安装过程中会将证书与私钥 M 进行关联，Xcode 默认会对 Provisioning Profile 文件进行管理。

> 3.在开发过程中，会使用私钥 M 对 App 进行签名，同时会将 Provisioning Profile 文件也打包进 App 中即 embedded.mobileprovision 文件。

> 4.当将 iOS 设备与 Xcode 连接并通过身份验证后，Xcode 会将 App 数据传输到 iOS 设备中，iOS 设备此时并不会创建真正的沙盒环境来运行 App ，而是会在一个临时沙盒环境中来存放陆续收到的数据，一旦全部接收完，iOS 系统首先会使用预置的公钥 A 对 embedded.mobileprovision 文件的签名进行验证，已确认 App 来源是否合法；来源合法性验证通过后，便可使用公钥 M 去验证里面证书的签名信息、验证该设备 ID 是否在对应 UUID 列表中、以及 APP 中的权限开关配置是否和 embedded.mobileprovision 文件中配置的 entilements 信息相吻合等；同时会读取_CodeSignature/CodeResources 中的信息对资源文件进行校验。只有全部经过验证后，才会为 App 创建真正的沙盒环境进行安装。在启动 APP 时，系统也会执行相应的启动校验，以防止安装后进行的修改。

参考文献：

1.https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format

2.https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html

3.https://pewpewthespells.com/blog/migrating_code_signing.html

4.http://blog.cnbang.net/tech/3386/

5.https://developer.apple.com/library/archive/recipes/ProvisioningPortal_Recipes/DownloadingaProvisioningProfile/DownloadingaProvisioningProfile.html

6.https://developer.apple.com/library/archive/technotes/tn2415/_index.html

7.https://developer.apple.com/library/archive/qa/qa1814/_index.html#//apple_ref/doc/uid/DTS40014030

8.https://getupdraft.com/blog/ios-code-signing-development-and-distribution-prov

9.https://abhimuralidharan.medium.com/what-is-a-provisioning-profile-in-ios-77987a7c54c2

推荐阅读：

｜信息流推荐系统智能交付解决方案探索

｜图谱相关技术在风控反作弊中的应用和探索

｜好看视频Android重构——围绕于播放器的重构实践

​---------- END ----------

百度 Geek 说

百度官方技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢迎各位同学关注