XADM:安全套接字层的工作原理

文章翻译 文章翻译
文章编号: 245152 - 查看本文应用于的产品
展开全部 | 关闭全部

本文内容

概要

本文概述安全套接字层 (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?User A, 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 生成的消息进行签名。

交付公钥

用户怎样才能安全地交付公钥?下面是用户 B 的示例身份验证协议:
A->B B->A A->B B->A
hello Hi, I'm User B, User_B's_public_key prove it User A, 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 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}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 的消息。此时,用户 A 已经相信用户 B,因此用户 A 可能会相信被篡改的消息并依据这些消息进行操作。注意,用户 C 不知道机密信息,他能做的就是破坏用密钥加密的数据。用户 C 可能无法生成有效消息,也可能会侥幸生成有效的消息,具体如何取决于协议。

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

属性

文章编号: 245152 - 最后修改: 2004年3月25日 - 修订: 3.0
这篇文章中的信息适用于:
  • Microsoft Exchange Server 4.0 标准版
  • Microsoft Exchange Server 5.0 标准版
  • Microsoft Exchange Server 5.5 标准版
关键字:?
kbinfo KB245152
Microsoft和/或其各供应商对于为任何目的而在本服务器上发布的文件及有关图形所含信息的适用性,不作任何声明。 所有该等文件及有关图形均"依样"提供,而不带任何性质的保证。Microsoft和/或其各供应商特此声明,对所有与该等信息有关的保证和条件不负任何责任,该等保证和条件包括关于适销性、符合特定用途、所有权和非侵权的所有默示保证和条件。在任何情况下,在由于使用或运行本服务器上的信息所引起的或与该等使用或运行有关的诉讼中,Microsoft和/或其各供应商就因丧失使用、数据或利润所导致的任何特别的、间接的、衍生性的损害或任何因使用而丧失所导致的之损害、数据或利润不负任何责任。
不再更新的 KB 内容免责声明
本文介绍那些 Microsoft 不再提供支持的产品。因此本文按“原样”提供,并且不再更新。

提供反馈

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com