我们都知道，iOS 有非常严格的签名机制，来限制App的安装方式，iOS 用户（不越狱）只能通过（开发者证书，AppStore）安装应用，iOS 的签名机制与 https 的有写类似，理解了 https 就能理解 iOS 的签名机制
基础
先做一些知识储备
加解密
- 对称加密：AES，DES，3DES（其中DES，3DES已经不推荐使用了）
- 非对称加密：RSA（使用公钥加密私钥解密，或者私钥解密公钥加密）
对称加密：解决明文传输的问题
非对称加密：解决对称加密带来的密钥配送问题，即使密钥被窃听数据也不会被解密
由于非对称加密的效率比对称加密的效率要慢很多，所以通常使用混合密码解决（主流的安全协议都使用这种方式，如https）
- 使用非对称加密交换密钥
- 然后使用对称加密传输数据
上面还是存在1个问题
- 如何确保收到的数据是原始的数据，而不是被篡改的数据
- 使用了非对称加密，可以保证数据不会被解密，但是由于公钥可以被监听用于加密数据，中间人可以伪造公钥对数据掉包
数据验证
数据验证通常使用单向散列函数生成数据指纹，用于唯一标识数据，常见的算法有
- MD5
- SHA-1
- SHA-2
- SHA-3
数字签名
数字签名就是数据指纹的一个应用，用于验证数据的完整性（是否被篡改）
上面我们知道了非对称加密，可以用私钥加密，公钥解密，在数据传输工程中
由于验证操作并不敏感，通常发送者可以使用私钥签名数据指纹，然后接受者使用公钥解密
由于私钥只有发送者拥有，所以能确定数据指纹一定是发送者发送的
证书
由于上面数据传输用到的公钥是公开传输的，所以数据可能被掉包，我们需要确保拿到的公钥就是真正的发送者发过来的，而不是中间人伪造的，这个时候就需要证书机构（Certificate Authority，CA）参与公钥的交换，以保证传输过程的公钥的正确
由于 CA 的公钥是公开的，所以 CA 的公钥可以认为不会被伪造，所以可以认为发送方和接收方的通信是安全的
因为任何人都可以充当 CA 的角色，这里所说的 CA 是指权威（可信任）的机构
权威证书机构这里有两点可以确定的
- 发送者和接收者都有有 CA 的公钥，可以验证 CA 发送的数据，这就确保了 CA 的通信过程是安全的
- 接收方（公钥） -> CA -> 发送方
- 发送方利用接收方的公钥就能安全的发送（公钥）数据给接收方了，这个过程公钥交换也是安全的
HTTPS
在 https通信过程中，证书会从服务端发给客户端，而不是从 CA 发送给客户端
服务器会先向 CA 发送公钥和申请信息（资格，身份信息），CA 把服务器公钥和颁发信息（颁发机构，证书有效期等）打包并用私钥签名给服务器，然后走下面流程
苹果证书
苹果的证书的认证就类似于上面说到的 https，我们知道，苹果的开发证书有下面几个文件
*.certSigningRequest: Mac用Mac公钥生成*.certSigningRequest文件*.cer: Apple使用Apple私钥签名Mac公钥，生成cer文件*.mobileprovision: Apple 使用Apple 私钥签名应用信息(bundleId、entitlement、deviceId)和Mac公钥，生成mobileprovision文件*.p12: 包含Mac公钥和Mac私钥，确保多台设备的密钥对是一样的
上面是开发时候的证书处理流程，如果是
AppStore下载的包，则没有mobileprovision文件，经过苹果审核的App，能确保下载来源只需要，不需要再进行多余的验证操作，只需要验证App 是使用Apple私钥签名的就行
上面流程可以看出来，Mac公钥并没有直接传给iOS设备，而是通过苹果的签名的证书来，这里的苹果就相当于 CA 的角色，整个流程的密钥都是安全的，修改这个流程中的任何数据都会导致无法验证通过，理解了 https 的安全加密就能很好的理解苹果的签名