快速了解iOS签名机制

接收者的公钥是公开的，任何人都可以向接受者发消息，会衍生以下问题

• 消息被篡改
• 伪装发送者
• 发送者否认发送消息

如何解决？数字签名

注意：公钥和私钥是成对的，它们互相解密，加解密可以反过来；可以被公开的那个叫 公钥 。

数字签名是验证消息的合法性和确定发送人（一个私钥对应一个发送者，拿该发送者的公钥来验证即可）。

以上有个缺点就是如果明文消息很大，那么对于签名的加解密过程以及最终的比对都是灾难性的资源消耗。

如何解决数字签名的明文消息过大问题？ 单向散列函数

• 根据任意长度的消息，计算出固定长度的散列值
• 计算速度快，能快速计算出散列值
• 消息不同，散列值也不同
• 具备单向性，不会逆向出明文 基于以上特点，改进一下：

单向散列函数包含：MD4，MD5，SHA1等，有关散列函数更多内容请查看哈希函数

使用 混合密码 加密明文，结合 数字签名 以后的流程如下

这样看起来是不是比较完美了，事实上还存在 公钥 （签名用）被伪造的风险。伪造者自己生成 密钥对 再拿到接受者的 公钥 就可以给接收者发假消息了。

PS：我们回头看一下签名的加密设计方式、私钥加密，公钥解密。如果跟普通的加密用法一样：私钥解密、公钥假面，行不行？答案是否定的，因为谁都能拿到公钥，用公钥加密就无法确认发送者的身份了。

如何防止数字证书的公钥被伪造？证书

• 什么是证书？ 权威机构 通过对证书申请者提交认证的公钥施加数字签名并加上申请者的一些个人信息如邮箱，而生成证书。 CA就是这样的一个权威机构，也存在一些提供认证服务盈利的企业。

为了方便比对我们在混合密码结合数字证书的流程图中只加上 混合密码公钥的证书认证，如下图

那么iOS的签名机制是这样的么？

不是的，只是用到的原理类似，iOS签名机制没这么复杂，因为只是签名没有加密。 还是来直接看图吧：

事实上，在签名当中还需要带有 一些额外的信息，比如：

• 确定唯一app的信息(appi)
• 该app权限相关信息，如keychain可访问组信息
• 非发布环境的 限制的可安装设备列表信息

至于为什么需要这些信息，这里不做过多解释，创建过证书的同学应该很熟悉。这些信息都放在了 mobileprovision 文件当中了。 那么为何不直接放到证书当中去呢？毕竟多一个文件需要再次签名。 我们知道，一个证书是可以供同一开发者多个app使用的，如果把app相关的信息直接放到证书里面，对于多个app 就需要 创建多个证书，达不到证书公用的目的。 最终完整的签名流程如下