客户端和服务器在SSL / TLS中共享四个不同机密的目的是什么？

#1 楼

在TLS（这是SSL的标准名称； TLS 1.2类似于“ SSL版本3.3”）中，客户端和服务器最终以共享机密（“主机密”，一个48字节序列）结束；使用RSA密钥交换时主密钥是从“ premaster密钥”派生的，“ premaster密钥”是客户端使用服务器公钥加密的48字节字符串。然后，将共享的机密“扩展”为六个值：


“客户端写密钥”；
“客户端写IV”；
“客户端写” “ MAC key”；
服务器的三个相似值。

“扩展”使用第5节中描述的PRF； TLS的主要目的是确保数据机密性；它可以被认为是具有可变输出长度的哈希函数。但是，它也旨在维护数据的完整性：如果某人或某物有意或无意地更改了传输中的数据，那么接收者必须能够可靠地检测到它。在许多协议中，检测变更很重要。此外，如果攻击者可以修改数据，则他通常可以进行精确的更改，当更改发送到对等端代替正确的数据时，更改可能会导致反应，从而泄漏有关加密数据的信息。因此，我们不仅要出于完整性的目的检测更改，而且还因为无限制的更改可能会导致违反保密性。

因此，我们需要加密（出于保密性）和完整性控制（以支持机密性，因为完整性本身也需要）。这需要几种算法，通常是对称加密部分使用AES，完整性控制使用HMAC。 HMAC是消息身份验证代码算法，它是一种“带有密钥的哈希函数”（HMAC建立在真正的哈希函数（如SHA-256）上，并以“正确的方式”插入了密钥）。 HMAC值由客户端使用其“客户端写入MAC密钥”计算得出，并附加到记录数据中；服务器将重新计算HMAC值，并查看其是否与发送的值匹配。

加密部分需要一个密钥（以及一个使用CBC模式的对称加密算法的IV，这取决于SSL协议版本，因此有一些微妙之处，因此在此不再赘述）。 MAC还需要一个密钥。通常，完全不建议对两个不同的算法使用相同的密钥：这两个算法之间可能存在不必要的交互作用，这是一个不太可能但并非不可能的事件，尚未进行深入研究。因此，为了安全起见，我们生成了两个密钥，一个用于加密，另一个用于MAC。这两个密钥来自主密钥，但是派生机制就像一个哈希函数，因此，即使您知道加密密钥，也可能无法猜测MAC密钥，反之亦然。

由于TLS具有可以产生任意长度的输出的密钥派生功能（“ PRF”），因此很容易强制要求产生双向加密的加密和MAC密钥（客户端用于加密数据的密钥-服务器用来解密接收到的数据-与服务器用来加密发送给客户端的数据所使用的密钥不同）。使用不同的密钥可以避免攻击者的麻烦，否则攻击者可能会获取客户端发送的加密记录的副本，然后将其反馈给客户端，就像从服务器发送来一样。使用不同的密钥，客户端将拒绝尝试，因为HMAC值将与客户端期望的值不匹配（它将是使用客户端写入MAC密钥而不是使用服务器写入MAC密钥计算的HMAC）。

有较新的对称加密模式，它们以可控的方式对同一密钥进行加密和MAC GCM-和AES-with-GCM可以与TLS一起使用，尽管您可能很难找到兼容的实现（这是相当新的）。

#2 楼

SSL不仅可以加密数据。它还保护它免受未检测到的修改。为此，在加密数据时，它还会生成明文记录的加密校验和（称为消息认证码或“ mac”），并将其包括在加密记录中。现在，为了确保中间人不能修改自己的记录，就无法计算自己的mac，请计算这些mac的使用密钥（最终从主记录派生，就像加密密钥一样）。在解密时，解密器还计算它获得的纯文本的mac（使用其密钥副本），并将其与记录中的mac进行比较；因此，client_write_mac_secret是用于保护客户端发送（写入）和服务器接收的记录的秘密密钥。 server_write_mac_secret是用于保护服务器发送和客户端接收的记录的密钥。

请注意，双方都有两个秘密；客户端使用client_write_mac_secret保护发送给客户端的记录，而服务器使用client_write_mac_secret验证从客户端接收的记录。