iOS 中的代码签名（一）—— 数字签名基本概念

在继续深刻了解以前，首先要了解一些关于数字签名的基本概念，关于这些基本概念，阮一峰的这篇博客已经作了很是好的解释，能够先移步一看。

若是用 A 来表示文章中的鲍勃，B 来表示苏珊，Z 来表示道格，那么文章最后的所描述的状况能够用下图来表示：

在阮一峰的文章中，貌似到这里就已经结束了，Z 是不管如何都没法窃取和修改 A、B 之间发送的信息了。然而实际状况并无这么简单，在有了 CA 的状况下，Z 依旧能够去窃取 A、B 之间的信息。

若是 Z 得到了 CA 的私钥，那么 Z 就能够用 CA 的公钥首先将信息解密，而后换成本身的信息，而后再用 CA 的私钥从新加密，这样一来，B 依旧获得了错误的信息。

因此为了防止这种状况发生，通常的 CA 都会想进各类办法去保证本身的私钥的安全，由于一旦 CA 的私钥泄露，CA 就彻底没有信任度可言。对于通常的 Z 来讲，这种方式的成本比较大，因此他们会想另一种方式：假装成 CA。

若是 Z 假装成了 CA，那么他就分别给 A、B 本身的证书，让 A、B 错误的信任了本身，觉得本身是万无一失的。

那么这种状况下，保证 A、B 之间信息传递安全的重点就在于，如何保证 A、B 和 CA 之间的信息传递是安全的不会被篡改的。仔细想一想，保证 A、B 之间的信息安全其实和保证 CA 与 A、B 之间的信息安全是同样的，所以，CA 和 A、B 之间的通讯依旧使用了 A、B 之间的飞遁陈加密方式。

这个时候，有意思的事情就来了：CA 为了保证和 A、B 之间信息传递安全，必须找一个另一个 CA 来确保本身和 A、B 之间信息传递的安全，而另一个 CA 单靠本身也没法保证和 A、B 之间信息传递的安全，他也必须再找一个 CA 来保证安全。这样子就产生了一个问题：在当前这套机制中，除非找到一个能够独立确保信息传递的安全的 CA，这套机制才能完美无缺，不然这种依赖关系就会一直传递下去。

在上面这个过程当中，各个 CA 产生了一种链式的依赖关系，一样 CA 所签发的证书也产生了一种链式的依赖关系，一个证书必须被其余的 CA 签发的证书的信任后（所谓信任就是指经过其余 CA 的证书确保了获取当前 CA 证书的过程是安全的），才是可信的。这种链式的信任关系就叫作证书的信任链。

为了保证这套机制可以完美无缺，一种特殊的 CA 的产生了—— Root CA ，A、B 在出生的时候就会带着 Root CA 的证书，这样就确保了和 Root CA 之间的通讯是绝对安全的；在信任了 RootCA 的证书（通常被称做根证书）以后，RootCA 信任的 CA 也能够安全的和 A、B 进行通讯了。在这之后，A、B 终于能够放心的进行通讯了。这种机制保证了接受方能够得知接受到的信息是不是发送方发出的原始信息。