SSL工作原理

　　密钥加密介绍

　　Rivest-Shamir-Adleman(RSA)公钥加密广泛用户计算机行业中的身份验证和加密。Netscape已获得在起产品中好使用RSA Data Security Inc.的RSA公钥加密的许可，具体用途是身份验证。、

　　公钥加密是一种使用一对不对称密钥进行加密和解密的技术。每对密钥由一个公钥和一个私钥组成。档公钥被广泛分发时，它就变得公开了。私钥从不分发；它始终是保密的。

　　用公钥加密的数据只能用私钥解密。繁殖，用私钥加密的数据只能用公钥解密。正是这种不对称性使得公钥加密非常有用。

　　使用公钥加密进行身份验证

　　身份验证是验证身份以使一个实体可以确认另一个实体的身份的过程。

　　示例：

　　用户A 和用户B使用公钥加密验证用户B的身份。

　　{something}key //表示项目已经用密钥加密法进行了加密或解密

　　//something是对加密项或解密项的描述,key是用来加密或解密该项的密钥

　　示例：

　　用户A想验证用户B的身份

　　用户B有一对密钥：一个公钥和一个私钥。用户B向用户A披露公钥。

　　用户A生成随机消息并将它发送给用户B，如下所示：

　　A->B random_message

　　用户B使用私钥对随机数进行加密，并将加密后的版本返回给用户A：

　　B->A {random_message}User_B's_private_key

　　用户A收到此消息并使用B早先公开的公钥将它解密。

　　用户A将解密后的消息与其最初发送给用户B的消息进行比较；如果这两个消息匹配，则用户A就知道后来的消息来自用户B，因为冒名顶替者应该不会知道用户B的私钥，因此无法正确地对随机消息加密并发送给用户A。

　　注意事项：示例（更加安全性）

　　用户B没有对用户A发送的原始消息进行加密，而是创建了消息摘要并对消息摘要进行加密。消息摘要是从原始随机消息中派生的，具有以下两种属性：

　　摘要很难逆转。冒名顶替用户B的人无法根据摘要确定原始消息。

　　冒名顶替者很难找到一个能够计算出相同摘要值的不同消息。

　　用户B通过使用摘要而得到了保护。用户B计算用户A发送的随机消息的摘要，然后对结果进行加密。用户B将加密的摘要发挥给用户A。通过对用户B的消息进行解密并比较生成的值，用户A可以计算出相同的摘要并验证B的身份。

　　注意事项里介绍的技术称之为“数字签名”

　　生成用于身份验证的数据

　　此技术要求用户B对用户A生成的消息进行签名；对于用户B而言，这与对用户A生成的随机数值进行加密几乎是同样危险的。因此此示例身份验证协议需要再增加一个步骤以保证安全；用户B需要生成以下所示的一些（或所有）数据

　　A->B B->A hello,are you user B?UserA,This is User B {digest[User A , This is User B]}User_B's_private_key

　　当用B使用此协议时，他就会知道发送给用户A的是什么消息，因此就可以放心地对消息进行签名。用户B先发送未加密版本的消息，"User A , This is User B";然后再发送加密版本。用户A很容易验证用户B是否真是用户B，并且用户B不需要对任何不是由用户B生成的消息进行签名。

　　交付公钥

　　A->B B->A A->B B->A

　　hello

　　Hi,I'm User B,

　　User_B's_public_key prove it UserA,

　　This is User B{digest[User A ,This is User B]}User_B's_private_key

　　如果使用此协议，任何人都可以冒名顶替用户B。冒名顶替者需要的只是一个公钥和一个密钥而已。冒名顶替这可以对用户A说谎，并通过提供冒名顶替者自己的公钥，而不是B的公钥来冒名顶替用户B。然后使用冒名顶替者的私钥对内容进行加密，来“证明”冒名顶替者就是用户B,而用户A将看不出冒名顶替者并不是用户B。

　　为了解决这个问题，标准团体发明了成为证书的对象。证书包含下列含义：

　　证书颁发者的名称

　　证书颁发给的实体（也成为接收方）

　　接收方的公钥

　　一些时间戳

　　给证书签名时需要使用证书颁发者的私钥。每个人都知道证书颁发者的公钥（即，证书颁发者也有证书）。证书是将公钥绑定到姓名上的标准方法。

　　如果使用证书技术，每个人都可以检查用户B的证书，以查证书是不是伪造的。如果用户B严密控制着他的私钥，并且他确实获取了证书，则证书技术是安全的。

　　下面是采用此项技术修订后的协议：

　　A->B B->A A->B B->A

　　hello

　　Hi,I'm User B,User_B's_certificate prove

　　it User A,This is User B{digest[User A,This Is User B]}User_B's_private_key

　　当用户A收到用户B的第一个消息时，用户A可以查看证书，查看签名（如前面的示例所示，通过使用摘要和公钥解密），然后检查接收方（即用户B的姓名），看他是否确实是用户B。然后用户A可以相信公钥是用户B的公钥，并可以请求用户B提供身份证明。

　　通过设计消息摘要，然后用经过签名的的摘要版本相应用户A，用户B就可以执行签名示例中概括介绍的过程。用户A可以通过使用证书中的公钥并检查结果，来验证用户B的消息摘要。

　　想要干扰安全通信的人（此示例中为用户C）可创建下列方案来常识进行干扰

　　A->C C-A A->C C->A

　　hello,

　　Hi,I'm User B,User＿B's_certificateprove

　　it???

　　但是，用户C无法在最终消息中满足用户A的要求。用户C没有用户B的私钥，因此他无法创建一条消息使用户A相信该消息来自用户B。

　　交换机密信息

　　用户A验证完用户B的身份后，他可以向用户B发送只有用户B可以解码的消息，如下所示：

　　A->B {secret}User_B's_public_key

　　这里，确定secret的唯一方法是用用户B的私密对上述消息进行解密。交换机密信息是又一种使用公钥加密方法的有效方式。即使用户A和用户B之间的通信收到监视，但除了用户B以外，任何其他人都无法确定机密信息的内容。

　　通过对机密信息用作另一个密钥，此技术增强了Internet的安全性；但是，这种情况下，此密钥是对称加密算算（例如数据加密标准(DES)、RC4或IDEA）的密钥。用户A知道机密信息，因为是用户A生成了机密信息并将其发送给了用户B。用户B也直到机密信息，因为用户B有私钥，因而可以对用户A的消息进行解密。由于用户A和用户B都直到此机密信息，所以他们可以启动对称密码算法，然后发送给对称密码算法加密的消息。下面采用此技术修订后的协议：

　　A->B B->A A->B B->A A->B

　　hello

　　Hi,I'm User B,User_B's_certificate

　　prove it User A,This is User B{digest[User A,This is User B]}User_B's_private_key

　　ok User B,here is a secret{secret}User_B's_public_key

　　{some_message}secret_key

　　用户计算secret_key的方法因定义的协议而异，但是secret_key可能仅仅是机密信息的一个副本

　　安全干扰

　　即使使用了上述技术，想要干扰安全通信的人（用户C）仍然有可能得逞。虽然用户C无法发现用户A和用户B交换机的机密信息，但是用户C可以通过重新排列机密信息的内容（或使内容发生错乱）来干扰他们的会话。比如，如果用户C正处于用户A和用户B之间，他就可以使大部分信息毫无变化的来回传递，并篡改某些消息（他很容易做到这一点，因为他知道用户A和用户B通信时使用的协议）：

　　A->C C-> B B->C C->A A->C C->B B->C C->A A->C C->B B->C C->A

　　hello

　　hello

　　Hi,I'm User B , User_B's_certificate

　　Hi,I'm User B,User_B's_certificate

　　prove it

　　prove it

　　User A,This is User B{digest[User A,This is User B]}User_B's_private_key

　　User A,This is User B{digest[User A,This is User B]}User_B's_private key

　　ok User B here is a secret{secret}User_B's_public key

　　ok User B here is a secret{secret}User_B's_public_key

　　{some_message}secret_key

　　Garble[{some_message}secret_key]

　　在用户A和用户B共享机密信息之前，用户C移植传递未经修改的数据。然后用户C篡改用户B发送给用户的消息。此时用户A已经相信B，因此用户A可能会相信被篡改的消息并依据这些消息进行操作。注意，用户C不知道机密信息，他能做的就是破坏用密钥加密的数据。用户C可能无法生成有效消息，也可能会侥幸生成有效的消息，具体如何取决于协议。

　　为了阻止这种破坏行为，用户A和用户B可以在他们的协议中引入消息身份验证代码。消息身份验证代码是通过使用机密信息和传输的某些数据计算出来的一组数据。上面介绍的摘要算法正好具有那些用于构造消息身份验证代码功能（可以防御用户C）的特性：

　　message_authentication_cod:=digest[some_message,secret]

　　由于用户C不知道机密信息，所以他无法计算正确的摘要值。即使用户C任意篡改消息，如果有大量的摘要数据，用计C成功的可能性也很小。例如，通过使用MD5(RSA开发的一种很好的加密摘要算法)，用户A和用户B可以在消息中发送128位消息身份雁阵个代码值。用户C猜中正确的消息身份雁阵个代码的可能性大约是1：18,446,744,073,709,551,616.实际上，用户C根本不可能猜中正确的消息身份验证代码。

　　以下是采用此技术在此修订的示例协议：

　　A->B B->A A->B B->A

　　hello

　　Hi,I'm User B,User_B's_certificate

　　prove it

　　User A,This is User B{digest[User A,This is User B]}User_B's_private_key

　　ok,User B,here is a secret{secret}User_B's_public_key{some_message,message_authentication_code}secret_key

　　用户C可以尝试篡改消息，但消息身份验证代码计算过程会现实此消息不是来自用户B。用户A或用户B可以发现不正确的消息身份验证代码值并停止通信。这样，用户C就无法再冒名顶替用户B。