一、密码学知识

签名：为了验证身份的
信封：为了传输信息的
证书：承载公钥和发布者信息的

1、数字签名

       一种电子签名，身份校验，完整性校验。
       一对非对称密钥，计算哈希，私钥签名。
       发送者发送原文+签名值。

2、数字证书

       存在的问题接收方存储的发送方的公钥伪造问题。
       证书中心CA(证书颁发机构)，为公钥作证，证书中心用自己的私钥，对请求者的公钥和一些相关信息一起加密，生成数字证书，发送者签名的同时附上数字证书，接受者用CA的公钥解开证书，对比公钥。
       数字证书，证明某一实体身份和公钥的合法性以及实体与公钥的匹配关系。证书是公钥的载体，证书上的公钥与唯一实体身份绑定。
       证书格式及证书内容遵循X.509标准，序列号、用户公钥、用户实体信息、×××机构的信息、签证机构的签名、证书有效期等。
       证书信任链，根证书，中间证书，子叶证书
       根证书的颁发者被称为 Root Certificate Authority（Root CA）。某一认证领域内的根证书是 Root CA 自行颁发给自己的证书，安装证书意味着对这个 CA 认证中心的信任。事实上，根证书都是随软件一起安装的，如：操作系统安装时会内置一份可信的根证书列表。

3、数字信封

真实性，私密性
使用接受方的非对称公钥对临时的加密对称密钥加密，只能接收方的私钥解密。

二、签名打包

       钥匙串中从证书颁发机构请求证书这个过程生成一个非对称密钥，certificateSigningRequest.certSigningRequest本质包含开发者信息和公钥，私钥则始终保存在开发者的Mac中，然后在开发者后台网站（类似根证书的角色）上传CSR,由CA进行签名并生成开发者证书，开发者证书包含开发者信息，公钥，以及开发者后台的私钥签名。Xcode导入证书后，从keychain中找到匹配的私钥对APP签名。
       Provisioning Profile指定了AppID,Certificates,Devices。
       签名、Provisioning Profile、应用程序都会被打包到ipa中。

三、验签运行

在真机上运行测试包和正式包时，系统对两者的验证有所不同。测试包在设备上进行了完整的签名验证；正式包则把验证过程交给了 App Store，App Store 验证通过后重新进行一次签名，设备下载正式包后进行的验证过程则简化很多。

1、测试包：

当在设备上安装运行时，会对 App 进行验证。
首先，设备系统会对 App 中的 bundle ID、entitlements、certificate 与 Provisioning Profile 中的 App ID、entitlements、certificates 进行匹配验证，否则无法启动 App。
其次，设备系统使用本地内置的 CA 公钥对 Provisioning Profile 中匹配的 certificate 进行签名验证，从而确认匹配到的证书的合法性。
然后，设备系统使用 Provisioning Profile 中的匹配的，且经过 CA 验证过的 certificate（即打包应用程序的开发者的证书）中取出公钥，对 App 进行签名验证，否则无法启动 App。
最后，设备系统会将设备的 Device ID 与 Provisioning Profile 中的 Devices 的 Device ID 进行匹配，否则无法启动 App。

2、正式包

假如你有一台越狱的设备，查看任意一个从 App Store 上下载的 App，你会发现里面没有 embedded.mobileprovision 文件，因为 App Store 已经完成了对 App 的验证（类似于上述测试包的验证过程）。当 App 通过验证后，Apple Store 会对 App 进行重新签名。重新签名的内容将不再包含 Provisioning Profile，最终的 ipa 文件也不包含它。当设备从 App Store 下载 App 时，会直接使用设备上的 CA 公钥对 pa进行签名验证。
与上述测试包的签名验证相比，正式包的签名验证简化了很多，因为有一部分验证工作已经由 App Store 完成了。