Oracle高级安全性

核心提示： 图3：Diffie-Hellman公共钥匙键交换 钥匙键生成的传输顺序通过图3所示客户端/服务器端方框中的小数字来确定，如下所示： 1. 客户端根据所支持的计算方法的清单传输一个连接请求，Oracle高级安全性(5)，2. 服务器端根据第一符合的计算方法和客户端的钥匙键大小决定将采用的计算

图3：Diffie-Hellman公共钥匙键交换

钥匙键生成的传输顺序通过图3所示客户端/服务器端方框中的小数字来确定，如下所示：

1. 客户端根据所支持的计算方法的清单传输一个连接请求。

2. 服务器端根据第一符合的计算方法和客户端的钥匙键大小决定将采用的计算方法。

3. 服务器利用服务器端的随机数s计算值gs 。mod p

4. 服务器向客户端传输值g，p，gs mod p，即将采用的计算方法，以及初始向量IV。

5. 客户端利用随机数c 计算gc ，mod p 该值将被传递到服务器。

6. 现在双方都已经获得了值g，p，gs mod p，和gc ，mod p因此可以计算mod p。

7. 客户端和服务器端都对gcs mod p应用一个函数以生成话路钥匙键。该函数根据所选择的计算方法的不同而不同。选择Triple DES与选择RC4将导致不同的计算方法。

8. 话路钥匙键在客户端和服务器端被建立起来。

钥匙键交换的最终结果是主话路钥匙键。主话路钥匙键可被用于加密所有的网络通信。但是，该钥匙键容易受到网络中人的攻击，从而威胁到系统的安全性。

网络中人的攻击

如果有人正在监听网络通讯，他/她不可能捕获话路钥匙键，因为它不会通过导线来传送。

但是，在钥匙键交换设计中存在一个缺陷，即易受到“网络中人”的攻击的薄弱环节。在网络中的人唯一可以得到的信息是交换的元素：g，p，gs mod p，和gc mod p。如果拥有Diffie-Hellman计算方法，他/她就能利用这些值去生成两个钥匙键，一个用于客户端另一个用于服务器端。尽管这两个钥匙键可能不同，但第三方仍然可以伪装成好似客户端之于服务器端或服务器端之于客户端。第三方可以侵入通讯中，并愚弄客户端和服务器端以获得需要继续交流的信息。