android - HTTPS 连接 - 如何管理密钥对

Question

在 HTTPS 连接中，客户端和服务器交换公共密钥并使用这些密钥使用算法（例如 RSA）（非对称加密）加密它们的消息。有趣的是，对于 Web 上的 HTTPS 连接，在双方确保他们拥有安全通道之后，他们会传输一个密钥，用于发送由另一种算法（对称加密）加密的进一步消息。使用对称加密是因为非对称加密的计算量很大。在他们同意一个单一的秘密加密密钥后，服务器和客户端可以轻松地传输消息（文本、图像、重视频等）。

现在，我的问题是：如何管理用于 https 连接的密钥对？操作系统是管理它们还是浏览器？它们存储在哪里？可以改变它们吗？是否为客户端建立的每个 https 连接生成（新）密钥对？

从逻辑上讲，单个密钥对将为客户提供终生服务。所以每个操作系统都需要为每个算法生成一堆不同长度的密钥。

具体来说，我很好奇它是如何在android中完成的。我正在尝试决定如何在我的应用程序中管理 https 连接，但我没有找到任何允许我使用特定密钥对进行连接的库，这让我想到了所有这些东西。

标签： androidencryptionhttpscryptographyoperating-system

Answer 1

在 HTTPS 连接中，客户端和服务器交换公钥并使用这些密钥使用算法（例如 RSA）（非对称加密）加密它们的消息

这不是真的。密钥对用于建立预主密钥，从中导出对称密钥。这可以通过在 TLS 中使用密钥协议（DH/DHE/ECDH/ECDHE 密码套件）来完成，直到 TLS 1.3（包括 TLS 1.3）。在标准的早期版本中，也可以使用 RSA 加密来加密由客户端生成的秘密，只需使用服务器的密钥对。

有趣的是，对于 Web 上的 HTTPS 连接，在双方确保他们拥有安全通道之后，他们会传输一个密钥，用于发送由另一种算法（对称加密）加密的进一步消息。

不，pre-master secret 用于生成 master secret，然后使用密钥导出函数来导出会话密钥，在 TLS 标准高达 1.3 中通常称为 PRF。

使用对称加密是因为非对称加密的计算量很大。

它还将密文扩展了比非对称加密大得多的数量。认为它仅取决于计算量大是一种误解。否则这是正确的。

在他们同意一个单一的秘密加密密钥后，服务器和客户端可以轻松地传输消息（文本、图像、重视频等）。

不，首先需要对之前的消息进行身份验证。否则，攻击者可以插入信息来攻击该方案。此外，使用两到四个密钥来加密数据帧。如果需要具有身份验证的密码，则使用一个密钥在任一方向创建消息。如果使用未经身份验证的密码，则每个方向都需要另一个密钥，以通过计算 MAC（通常是 HMAC）来提供完整性和真实性。

现在，我的问题是：如何管理用于 https 连接的密钥对？

这取决于密钥对和实现。

操作系统是管理它们还是浏览器？

这也取决于。Firefox 当然管理它自己的密钥和证书。但是 IE 和 Edge 通常使用 SChannel，这是一种在 Windows 中使用 Windows 证书/密钥存储的 TLS 实现。

它们存储在哪里？

临时（临时）密钥对通常保存在内存中。静态密钥对通常保存在永久存储中，甚至可能受到硬件保护。

可以改变它们吗？

不，您可以生成新的，但如果您更改它们，它们将不再有效。

是否为客户端建立的每个 https 连接生成（新）密钥对？

基于 DHE 和 ECDHE 的密码套件中的 E 表示短暂的。对于很少使用的 DH 和 ECDH 方案，一对密钥是静态的，另一对是短暂的。否则密钥对是静态的，答案是否定的。静态密钥对的公钥通常在 X.509证书中。要使用静态密钥对，建立对公钥的信任很重要。

从逻辑上讲，单个密钥对将为客户提供终生服务。所以每个操作系统都需要为每个算法生成一堆不同长度的密钥。

这完全是胡说八道。客户端通常甚至没有密钥对。证书都有一个需要使用的有效期。客户通常甚至没有证书。密钥需要更新。临时密钥对是动态生成的。

具体来说，我很好奇它是如何在android中完成的。我正在尝试决定如何在我的应用程序中管理 https 连接，但我没有找到任何允许我使用特定密钥对进行连接的库，这让我想到了所有这些东西。

你不应该想，因为你上面写的任何东西都是完全错误的（除了那句话，它只是不完整的）。您应该阅读- 对于初学者的 TLS RFC。思考是在你建立了足够的知识基础之后产生的。

如果你现在有任何有趣的想法：把它们写下来，学习，然后检查它们是否值得保留。