只是想知道这个。它是否需要 PKI 才能工作?
HMAC 密钥是如何交换的?
信息安全
加密
密码学
hmac
2021-09-02 15:54:20
1个回答
HMAC 密钥是对称密钥,即一串字节。“对称性”与以下重要事实有关:相同的密钥既用于在某些消息上生成 HMAC 值,又用于验证消息上的 HMAC 值。从这个意义上说,HMAC不是数字签名算法(但有些人仍然在谈论关于 HMAC 的“签名”,这既错误又令人困惑)。
分发对称密钥是一项复杂的工作,原因有两个:
- 旅行的秘密价值是“不那么秘密”,因为旅行意味着暴露的额外风险。
- 一个秘密只有在没有太多人知道的情况下才能保持秘密。因此,如果n个人必须能够相互进行对称加密,那么您或多或少需要每对用户共享一个秘密;所以整个系统中会有n(n-1)/2 个对称密钥。
为了使事情变得更容易,发明了公钥密码术。它也被称为非对称密码学;当与数字签名一起使用时,用于生成签名的密钥不同于用于验证签名的密钥;它们在数学上相互关联,但是从签名验证密钥重新计算签名生成密钥是不可行的(或者我们希望如此)。因此,我们有能力将后者公开,因此得名。
公钥密码学使密钥分配问题变得更加容易:
- 公钥是公开的,因此传输的机密性不再是问题。
- 每个用户只有一个公钥/私钥对,因此整个系统中的密钥数量要少得多。
现在公钥密码术使密钥分发变得更容易,而不是容易。你仍然必须想出一些东西来让用户确保他们使用正确的公钥。这就是PKI发挥作用的地方:PKI 是一个分发公钥的系统。
那么实际情况如何呢?考虑SSL/TLS,通常与 HTTP 结合使用,从而产生 HTTPS。当 Web 浏览器连接到支持 HTTPS 的网站时:
- 执行初始“握手”过程,服务器向客户端(浏览器)显示他的证书。这是 PKI。该证书包含服务器的公钥,并且是经过签名的,而该签名就是 PKI 的化身。客户端验证一堆签名并最终确信它看到的公钥确实是来自预期服务器的真正公钥。
- 使用服务器的公钥,发生了更多的非对称加密(这次是密钥交换,可能基于非对称加密,而不是签名),最终得到了一个很好的结果:客户端和服务器现在知道一个共享的秘密值,并且没有人监视行将能够重建该值。
- 然后将共享密钥值扩展(使用密钥推导函数)成几个对称密钥,客户端和服务器将使用这些密钥来加密和 MAC 任何他们想要发送给对方的数据。在 SSL/TLS 中,通常的 MAC 算法是 HMAC。
完整的画面是 PKI 用于分发公钥,然后这些公钥与非对称加密一起使用以动态创建共享密钥,然后该共享密钥与 HMAC 等对称算法一起使用。
因此,您不会直接使用 PKI 分发 HMAC 密钥;有一个中间层。
其它你可能感兴趣的问题