5

首先，关于我们系统的一些信息，它基本上是建筑行业的电子招标解决方案。

所以：

  • 项目清单
  • 我们的系统有多家公司
  • 每个公司都有多个用户
  • 每个公司可以创建多个拍卖
  • 然后其他公司可以为可用的拍卖提交他们的投标。投标由成百上千个单独的项目组成，我们只需要加密这些记录的“价格”部分。

我们面临的问题是，我们的大客户不希望我们获得投标价格，至少在投标进行时是这样，这是完全可以理解的。现在，我们只是通过对称加密对价格进行加密，所以即使价格在数据库中被有效加密，他们担心的是我们有解密价格的密钥。

因此，我们正在研究某种形式的公钥加密系统。以下是我们对解决方案的初步想法：

  1. 当一家公司注册时，我们使用 OpenSSL 为其创建一个公钥/私钥对，并将其保存在 S3 中或直接保存到数据库中。为了真正有用，我们将强制用户对私钥使用强密码，当然不会将其保存在数据库中。
  2. 当一家公司提交拍卖报价时，我们使用拍卖所有者公司的公钥对价格进行加密，并将其保存到数据库中。
  3. 当拍卖投标期结束并且发行公司想要第一次生成报告时，我们要求他输入他的密码并使用该密码和他公司的私钥来解密价格。
  4. 为了使后续流量更快，我们缓存了解密的数据（并且可能使用简单的对称加密系统对其进行加密）

所以这里是问题（不幸的是，我们不是安全专家，如果这些是愚蠢的问题，很抱歉）：

  • 这是否有任何意义，还是完全荒谬或矫枉过正的解决方案？
  • 我们会使用 OpenSSL、OpenPGP 还是其他解决方案生成密钥？
  • 如果用户想要更改密码或生成新密钥会怎样？除了用新密钥对所有内容进行解密/重新编码之外，别无他法？
  • 这个解决方案会有哪些陷阱？
  • 您可以推荐任何更好的解决方案吗？
4

3 回答 3

5

所以这是我的建议，如果你想使用加密来解决这个问题......

  • 每个用户和每个公司都应该生成OpenPGP（或GnuPG）非对称公钥/私钥对
  • 这些公钥中的每一个都应上传到公钥服务器
  • 公司可以选择“签署”个人用户的公钥，以指定与这些用户的信任关系（如果该关系发生变化，则撤销该签名）
  • 拍卖师或无党派仲裁者还将生成一个密钥对并将该公钥推送到公钥服务器
  • 作为拍卖注册过程的一部分，每个用户都将导入拍卖人的公钥，而拍卖人将导入每个用户的公钥
  • 受信任的第三方（可能是拍卖商之外的SaaS供应商）将提供服务，用户和拍卖商将通过该服务进行通信
  • 出价用户将通过以下方式创建出价
    • 用他们的私钥签署他们的出价
    • 将他们提议的价格加密为两个密钥：他们自己的公钥和拍卖师的公钥
    • 将出价提交给受信任的第三方服务，这将需要对在拍卖到期之前检索出价的任何用户实施禁令
  • 在拍卖结束时，并且只有在拍卖结束后，拍卖师才会检索所有的出价、解密它们并验证签名

几个关键点：

  • 至关重要的是，永远不会在服务中共享或存储任何用户或公司私钥——这是我在您提出的问题中看到的唯一真正的“缺陷”。如果是这种情况，一个用户很有可能指责管理员“欺诈”或“篡改”投标，因为您的服务器管理员最终将有权访问所有用户的私钥，因为您已经自己生成它们。
  • 沿着同样的思路，任何所有通信和“投标”都必须由每个用户使用真正的私钥进行加密“签名”。这就是您如何知道出价来自一个特定用户并且仅来自该用户，并且该出价不可能被篡改。
  • 将投标加密到投标用户和拍卖人的公钥中，确保第三方 SaaS 供应商在拍卖开放期间的停电期间不会对投标本身进行内省。我相信这是解决您所描述的问题的最重要的一点。
  • 请注意，如果按照设计您希望在拍卖结束后公开所有出价，则实际上可能更喜欢将每个出价加密到所有出价用户的环中。如上所述，这将是对我的算法的轻微修改。

为了充分披露和可能进行一些微妙的营销，我碰巧是一家名为Gazzang的公司的架构师和首席技术官，该公司实施了一个名为zTrustee的产品，该产品的运作方式与上述完全一样；-)

于 2012-12-07T21:30:37.897 回答
4

需要明确的是：我有一种预感，您的客户可能不愿意牺牲让您的系统管理某些密码学所带来的所有便利；您可能应该提出几个选项以及它们的弱点与便利性。

一般要点

首先，您从一个明确的威胁模型开始，涵盖您能想到的所有可能的攻击。即使您选择不解决某些攻击（处理所有事情是不现实的），您也会找出更明显的攻击，并且至少有一套基本的步骤来处理其他攻击。

回复：这有意义吗？

我认为一般前提虽然对您的客户来说有点矫枉过正，但从安全角度来看是有道理的。您的客户需要一个加密安全的系统；很公平。

但是，关于您提出的解决方案的一些要点：

  • 通过允许客户通过网络传递他们的密码，攻击者（您的客户似乎认为可能是您）只需要在密码中间人就可以访问定价数据。

    • SSL 有助于缓解这种情况，但是沿线某处的错误日志行很可能会意外暴露客户端的密码。

客户确保您无权访问定价数据的唯一真正加密安全的方法（如我所见）是让他们对其进行加密，并且您的系统只是充当加密数据的代理。实际上，这使您成为加密数据包和公钥的代理，但您的系统永远不会看到私钥。

问题是：客户是否愿意管理自己的密钥，或者这对他们来说是否过于繁重？您至少可以自动化其中的大部分内容（客户端应用程序/网站将处理在本地存储私钥，并且还负责收集其他相关方的公钥以解密他们的加密投标）

回复：我们会使用 OpenSSL、OpenPGP 或其他解决方案生成密钥吗？

真的没那么重要；这些选项中的每一个仅定义公钥/私钥和任何元数据的容器格式。使用最适合您的语言/平台的任何一种。

主要决策点应该是在哪个加密算法和密钥强度：RSA-2048？RSA-4096？椭圆曲线？别的东西？

特定于 Ruby：您可能只想使用OpenSSL库，因为它是标准库的一部分。但是重申我上面的观点：如果您的服务器甚至从未看到私钥，那就更好了（如果客户端可以在更好的安全性和便利性之间进行权衡）

Re: 如果用户想要更改密码或生成新密钥会怎样？

更改密码是微不足道的：私钥本身只是使用某种对称算法加密。更改密码涉及解密现有密钥，并使用新密钥重新加密。如果客户丢失密码，则无法恢复。

生成新密钥可能更安全，但需要您更加努力（加密的有效负载需要识别它们匹配的密钥，并且客户端一次可以有多个活动密钥）。不过，这是一件好事；定期轮换密钥是一种常见的做法，即使它们没有受到损害。

于 2012-12-06T18:22:44.137 回答
3

当一家公司注册时，我们使用 OpenSSL 为其创建一个公钥/私钥对，并将其保存在 S3 中或直接保存到数据库中。为了真正有用，我们将强制用户对私钥使用强密码，当然不会将其保存在数据库中。

我对这一步有点怀疑。如果您（开发公司）生成用于加密的公钥和私钥，则意味着您有 50% 的能力可以破解加密。唯一可以保护您的客户的是密码，您可能可以暴力破解（我不是建议您这样做，但您有能力这样做）

如果您将使用 PKI（或您所描述的），您需要确保不会在您的系统上创建密钥。客户应该在他们的系统上创建对，然后向您提供他们的公钥，您将使用它来加密价格。然后，客户端将能够使用他们唯一控制的私钥进行解密

这个解决方案会有哪些陷阱？

陷阱是您正在制定一个复杂的解决方案。特别是如果您遵循我上面的建议，那么您信任客户不会“丢失”私钥（和/或密码），否则他们将无法解密价格。此外，如果密钥从他们那里泄露，很难证明你的应用程序是“无辜的”

我们会使用 OpenSSL、OpenPGP 还是其他解决方案生成密钥？

为了防止客户丢失密钥的陷阱，您可能需要研究 PGP（商业版本肯定会这样做）以及 ADK（附加解密密钥）和“拆分密钥”的概念。这个想法是，除了使用客户的公钥加密之外，您还使用“公司”密钥进行加密，该密钥只​​能在 x 人中的 y 人聚集在一起时使用（例如，10 人可以拥有部分密钥如果他们中的 6 个聚集在一起，他们可以重建密钥）。这些零件可以在您的公司、客户、他们的律师等之间共享

于 2012-12-07T09:35:23.640 回答