SSL的产生过程

数字签名

　　认证是一个验证身份的过程，目的是使一个实体能够确信对方是他所声称的实体。下面的例子包括 Alice 和 Bob ，并且向我们演示了如何使用公用密钥密码系统来轻易的验证身份。下面的 {something}key 表示 something 已经用密钥 key 加密或解密。

　　假设 Alice 要认证 Bob ， Bob 有一个密钥对，即一个公钥和一个私钥， Bob 透露给 Alice 他的公钥（至于他是怎么做的将在以后讨论）。然后 Alice 产生一段随机的消息，然后把它发给 Bob 。

　　 A-->B random--message

　　 Bob 用自己的私钥来加密这段消息，然后把加密后的消息返回给 Alice 。

　　 B-->A {random--message}bobs--private--key

　　 Alice 接到了这段消息，然后用 Bob 以前发过来的公钥来解密。她把解密后的消息和原始的消息做比较，如果匹配的话，她就知道自己正在和 Bob 通信。一个入侵者应该不知道 Bob 的私钥，因此就不能正确的加密那段 Alice 要检查的随机消息。

　　除非你确切的知道你在加密什么，否则用你的私钥加密一些东西，然后发给别人永远不是一件好事 （比如说？） 。这是因为加密后的数据可能会背叛你（记住，只有你能加密，因为只有你才有密钥）。

　　所以，我们不加密 Alice 发送的原始消息，取而代之的是，由 Bob 构造一个消息摘要，然后加密它。消息摘要是从随机消息中以某种方式提取出来的，并且具有以下特点：

摘要很难逆转，任何假冒 Bob 的人不能从摘要得到原始消息
　　假冒者无法找到具有相同摘要的不同消息

　　通过使用摘要， Bob 能够保护自己。他首先计算出 Alice 发给他的随机消息的摘要并加密，然后把加密后的摘要返回给 Alice ， Alice 可以计算出相同的摘要，通过解密 Bob 的消息然后对比一下就可以认证 Bob 的身份。

刚才描述的技术称为 数字签名 。 Bob 为 Alice 产生的消息签名，这样做其实和加密 Alice 产生的随机消息一样危险。因此我们的认证协议需要一次以上的变形。部分（或者全部）的数据需要由 Bob 产生。

　　 A-->B hello,are you bob?

　　 B-->A Alice,This Is bob{digest[Alice,This Is Bob]}bobs-private-key

　　当 Bob 使用这个协议的时候，他知道自己发给 Alice 的是什么消息，并且不介意签名。他首先发送没有加密的消息 “Alice,This Is Bob 。 ” 然后发送加密的摘要。 Alice 能够轻易的判断 Bob 是 Bob ，并且 Bob 没有签任何他不愿意签的东西。

数字证书

　　 Bob 如何以一种可信赖的方式分发他的公钥呢？我们假设认证协议是这个样子的：

　　 A-->B hello

　　 B-->A Hi, I'm Bob, bobs-public-key

　　 A-->B prove it

　　 B-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key

　　如果使用这个协议的话，任何人都可以是 Bob 。你需要的只是一个公钥和私钥，你跟 Alice 慌称你是 Bob ，接着你用自己的公钥代替 Bob 的公钥，然后你通过用你的私钥加密的东西来证明，这样 Alice 就不能分辨出你不是 Bob 。

　　为了解决这个问题，标准化组织发明了一个叫做证书的东西，一个证书包括下面的一些内容：

证书发行者的名字 （ B 的上级）
　　证书发送给的团体 （ B ）
　　主题 （ B 的名字） 的公钥
　　一些时间戳

　　证书是由证书发行者的私钥签名的，每个人都知道证书发行者的公钥（即证书发行者有一个证书，等等）。 证书是一种把公钥绑定到名字的标准方式 。

　　通过使用证书这种技术，每个人都可以通过检查 Bob 的证书来判断 Bob 是不是伪造的。假设 Bob 严格的控制着他的私钥，并且的确是 Bob 得到了他的证书，那么一切都好。下面是补偿协议：

　　 A-->B hello

　　 B-->A Hi, I'm Bob, bobs-certificate

　　 A-->B prove it

　　 B-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key

　　当 Alice 收到 Bob 的第一条消息，她可以检查证书，核实签名，核实主题（ Bob 的名字）来判断那是不是真的 Bob 。这样她就相信公钥是 Bob 的公钥，然后要求 Bob 证明他的身份。 Bob 会计算消息的摘要，签名之后发给 Alice ， Alice 可以用从证书得到的公钥检查 Bob 的消息摘要，从而判断 Bob 的身份。

一个坏家伙 - 我们不妨叫他 Mallet - 可以做下面的事情：

　　 A-->M hello

　　 M-->A Hi, I'm Bob, bobs-certificate

　　 A-->M prove it

　　 M-->A ????

　　但是 Mallet 在最后的消息中不能满足 Alice 。 Mallet 没有 Bob 的私钥，所以他无法构造一条使 Alice 相信来自 Bob 的消息。

交换数据 or 对后续数据进行加密的对称密钥

　　一旦 Alice 认证了 Bob ，她就可以做另外一件事 - 她能发给一条只有 Bob 才能解码的消息：

　　 A-->B {secret}bobs-public-key

　　发现这个秘密的唯一方法就是用 Bob 的私钥来解密上面的消息，交换秘密是公用密钥密码系统的另一种强大的用法。即使 Alice 和 Bob 之间的通信被监视，除了 Bob ，也没有人能够得到秘密。

　　这项技术加强了因特网的安全性，它把这个密码当作另一个密钥 （对称性密码系统算法的密钥（如 DES ， RC4 ， IDEA ）） 。 Alice 知道这个秘密，因为这是自己在发送给 Bob 之前产生的。 Bob 知道这个秘密，因为 Bob 有私钥，能够解密 Alice 的消息。因为他们都知道这个秘密，所以他们就可以初始化一个对称的密码算法然后开始传输用它加密的消息。下面是订正的协议：

　　 A-->B hello

　　 B-->A Hi, I'm Bob, bobs-certificate

　　 A-->B prove it

　　 B-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key

　　 A-->B ok bob, here is a secret {secret} bobs-public-key 这里的 secret 可以等效为 secret-key

　　 B-->A {some message}secret-key

　　 secret-key 的计算取决于协议的定义，但是它可以简化成一个 secret 的副本。

摘要防篡改

　　 Mallet 的袋子里有很多诡计。虽然 Mallet 不能发现 Alice 和 Bob 交换的秘密，但是他可以干预并且破坏他们的对话。举例来说，如果 Mallet 位于 Alice 和 Bob ，他可以选择让大多数的消息返回以及向前继续传输没有改变，但是破坏了特定位的消息（这对他来说很容易，因为他知道 Alice 和 Bob 之间通信的协议）。

　　 A-->M hello

　　 M-->B hello

　　 B-->M Hi, I'm Bob, bobs-certificate

　　 M-->A Hi, I'm Bob, bobs-certificate

　　 A-->M prove it

　　 M-->B prove it

　　 B-->M Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key

　　 M-->A Alice, This Is bob{ digest[Alice, This Is Bob] } bobs-private-key

　　 A-->M ok bob, here is a secret {secret} bobs-public-key

　　 M-->B ok bob, here is a secret {secret} bobs-public-key

　　 B-->M {some message}secret-key

　　 M-->A Garble[ {some message}secret-key ]

　　 Mallet 一直让数据没有改变的通过，直到 Alice 和 Bob 分享一个秘密。然后 Mallet 通过改变 Bob 发送给 Alice 的消息来进入这个方式中。这时候 Alice 是相信 Bob 的，因此她就可能相信这个改变的消息，然后按照它来做。注意 Mallet 并不知道这个秘密 - 他能做的所有事就是破坏用这个秘密的密钥加密的数据。他可能不能利用这个协议制造出一条有效的消息，但是下一次，他可能幸运一点。

　　为了防止这种破坏， Alice 和 Bob 在他们的协议中引入了一种消息认证码（ MAC ）。 MAC 是根据秘密的密钥和传输的数据计算出来的，上面描述的摘要算法的属性正好可以用于构造抵抗 Mallet 的 MAC 功能。

　　 MAC := Digest[ some message, secret ] 这里的 secret 可以等效为 secret-key

 

　　因为 Mallet 不知道这个秘密的密钥，所以他无法计算出这个摘要的正确数值。即使 Mallet 随机的改变消息，如果摘要数据很大的话，他成功的可能性也很小。举例来说，通过使用 MD5 （ RSA 公司发明的一种很好的密码摘要算法）， Alice 和 Bob 能和他们的消息一起发送 128 位的 MAC 值。 Mallet 猜中这个正确的 MAC 值的几率是 18,446,744,073,709,551,616 分之 1- 也就是从来也不会猜出来。

　　下面是样本协议，又订正了一次：
　　 A-->B hello

　　 B-->A Hi, I'm Bob, bobs-certificate  数字证书

　　 A-->B prove it

　　 B-->A {digest[Alice, This Is Bob] } bobs-private-key  数字签名（非对称加密）

A-->B ok bob, here is a secret {secret} bobs-public-key 这里的 secret 可以等效为 secret-key

B-->A {some message,MAC}secret-key  摘要（摘要算法，对称加密）

　　 Mallet 现在有麻烦了， Mallet 可以改变任何的消息，但是 MAC 的计算将揭露他的欺诈行为。 Alice 和 Bob 能发现伪造的 MAC 值并停止会话， Mallet 就不能伪造 Bob 的消息了。

最后的，但是同样重要的是要防范 Mallet 鹦鹉学舌。如果 Mallet 记录了会话的过程，他虽然可能不知道会话的内容，但是他可以重放这些会话。实际上， Mallet 能在 Alice 和 Bob 之间做一些真正龌龊的事。解决的办法就是从会话的双方 引入随机因素 。

 

【总结】

数据的安全传输是以数字认证和签名作为前提的，只有完成了数字认证和签名才能确定 B 的真实性。

在这个前提下，

如果要保密的数据量大（不考虑传输过程中的篡改），则应先使用对称加密，然后将对称加密的密钥用 B’s public key 加密传输

如果要保密的数据量小，倒是可以直接用 B’s public key 加密传输，但问题是现实情况下（一个 BS 应用） A 往往没有自己的公钥私钥，虽然 A 传给 B 的数据可以保密，但是 B 传给 A 的数据没有办法保密。所以，合理的解决方案还是由 A 随机生成一个“对称密钥”，这样 A 和 B 都可以用它加密通讯的数据。

如果数据只要保证不被篡改，而不用保密，则考虑先对数据做个摘要，然后 用 B’s public key 对摘要进行加密传输

如果既考虑保密有考虑防篡改，则先根据“原文及对称密钥”对原文进行摘要，然后用对称密钥对原文和摘要一起加密，最后用 B’s public key 对这个对称密钥加密传输。