端到端加密模型

Question

我有一个体系结构，它需要一个特定的数据子集才能得到更严格的保护和加密。我认为符合工程范围的主要参数如下：

• 数据应在传输过程中加密
• 数据应在静止时加密。
• API服务器不应该处理这种类型的未加密数据
• 开发人员/sysadmin/db管理员在真空中不应该有足够的信息来破坏加密数据
• 数据只能由具有访问这些资源的权限的经过身份验证的最终用户解密。

Architecture

• iOS/Android 上的移动应用程序
  • 用户会话在每次登录/令牌过期后都有一个新的RSA密钥对

• API (安全vis )
  • API服务器拥有自己的私钥，用于将数据加密到数据库

• 数据库服务器

初始模型

我粗略地设想了一个我认为非常适合这个系统的东西，我想看看它是如何经得起一些受过教育的批评。初步设计如下：

Authentication

• 用户登录到移动应用程序(客户端)。
• 成功身份验证后，客户端生成一个RSA密钥对。
• 在生成密钥对之后，私钥被安全地存储在本地设备上，并且公钥被发送到api以存储在最终用户会话中。

创建共享加密资源组

• 登录用户发送api请求(通过客户端)来创建资源组POST /resource-group。
• API接收POST请求并创建资源组，在创建过程中为组分配自己的RSA密钥对，将私钥用服务器密钥加密以用于数据库存储，然后用客户端公钥加密并返回给客户端。

在组

中创建共享加密资源

• 登录用户发送api请求(通过客户端)以在资源组内创建新资源，该资源具有用资源组密钥POST resource { groupId, dataEncryptedWithResourceGroupKey }加密的数据。
• API接收资源并使用服务器密钥重新加密敏感数据，然后存储在DB中。

从组

检索共享加密资源

• 登录用户发送和api请求(通过客户端)从他们可以访问的资源组获取资源。GET resource [...resourceIds]
• API接收GET请求并从数据库获取资源(S)。API使用服务器密钥对敏感数据进行解密，导致敏感数据现在只能用资源组密钥加密(用户在此时拥有和/或在必要时可以请求)。
• API用最终用户公钥加密敏感数据，并将资源发送给最终用户，最终用户使用他们的私钥解密敏感数据，然后是资源组密钥。

特定问题/未知数

1. 我的初始模型没有考虑暂时访问。(例如如果用户A昨天访问了资源组1并以某种方式存储了私钥，那么明天就不再有访问该资源组的权限了)这是一个有效的关注点吗？有什么好的常见模式来解决这个问题吗？
2. 这种模式对MITM攻击是否足够安全？如果不是，你认为哪些向量被破坏了？
3. 什么位大小的RSA密钥将是一个很好的选择，以平衡安全性和性能。(我没有存储任何金融/身份数据，量子计算的问题也不有趣)
4. 任何其他批评都是受欢迎的。这怎么可能是最好的版本本身呢？

Answer 1

第一件事:这不是E2E。服务器持有资源组的私钥，因此可以解密/日志/更改任何内容。开发人员或数据库管理员可以危及所有数据。

要成为真正的E2E，应该要求用户接收带外的公钥。从您的应用程序接收它们意味着服务器可以为每个用户发出一个键盘，并解密、记录、重新加密和转发所有消息。每个用户都必须能够共享他们的公钥(比如Android上的共享功能)，这样他们就不会依赖服务器了。

在此之后，用户应该创建资源，使用对称密钥在本地加密，用所有预期收件人的公钥加密密钥，并将资源加上加密的对称密钥发送到服务器。接收方将下载这两个文件，用其私钥解密对称密钥并读取数据。服务器不能清除任何私钥或对称密钥，因为这会破坏E2E。

用户也必须存储朋友的公钥，服务器不应该提供这些密钥。如果用户提供它们，则服务器处于模拟位置。公钥必须从波段接收并导入到您的应用程序中。

MITM取决于您的应用程序是否正确地检查TLS证书，以及如果服务器不向客户端提供任何密钥。如果服务器和客户端都检查TLS证书，攻击者就不可能截获和更改数据。但是，如果客户端允许使用无效的证书，并且仍然建立连接，则它将易受攻击。如果服务器从未提供任何公钥，则不可能模拟任何客户端。

暂时访问并不容易实现。如果您使用我编写的更改，昨天资源组中允许的任何用户仍然可以访问昨天发送的数据，但不能访问下一个数据。用户投递到资源组将不会在新消息上使用已删除用户的密钥，并且用户将无法解密任何内容。在成员身份之前发送的消息也是如此:他的密钥不是用来加密对称密钥的，除非另一个用户转发消息，否则他无法读取这些密钥。

对于AES密钥(而不是RSA)，在可预见的将来，192位就足够了。在接下来的十年左右，128位比特已经足够了，但是现在拥有192位并没有什么坏处。对于RSA，2048位被认为是一个高安全性的密钥.

无法确定“最佳版本”。安全性和可用性始终是一种权衡。增加可用性会降低安全性，反之亦然。