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 终于可以放心的进行通信了。这种机制保证了接受方可以得知接受到的信息是否是发送方发出的原始信息。