【问题标题】:How to fully encrypt data in Ruby using Private Key encryption?如何使用私钥加密完全加密 Ruby 中的数据?
【发布时间】:2012-11-24 20:09:21
【问题描述】:

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

所以:

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

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

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

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

以下是问题(不幸的是,我们不是安全专家,如果这些问题很愚蠢,请见谅):

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

【问题讨论】:

    标签: ruby security encryption private-key public-key


    【解决方案1】:

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

    一般要点

    首先,您从明确的threat model 开始,涵盖您能想到的所有可能的攻击。即使您选择不解决某些攻击(处理所有问题是不现实的),您也会找出更明显的攻击,并且至少有一套基本的步骤来处理其他攻击。

    Re:这有意义吗?

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

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

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

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

    唯一真正让客户确保您无权访问定价数据的加密安全方式(如我所见)是让他们加密它,您的系统只是充当加密数据的代理。这实际上使您成为加密数据包和公钥的代理,但您的系统不应该看到私钥。

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

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

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

    主要的决定点应该是在哪个加密算法和密钥强度:RSA-2048? RSA-4096?椭圆曲线?还有什么?

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

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

    更改密码很简单:私钥本身只是使用某种对称算法加密。更改密码涉及解密现有密钥,并使用新密钥重新加密。如果客户端丢失密码,则无法恢复。

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

    【讨论】:

    • 感谢您提供非常详细的回答。您面临的问题是,我们 99% 的客户并不真正关心这些东西,但如果我们不加强安全性,那 1% 的客户实际上确实有能力扼杀我们平台的流量。所以你是对的,我们 99% 的客户永远不会想要牺牲系统的易用性,并且无论如何都不知道一组密钥是什么,更不用说如何生成它们了....
    • 那么我的问题是你会用什么其他方式来做呢?
    • 我想我仍然会坚持我在“回复:这有什么意义吗?”的最后一段的第二段中列出的替代方案。很大程度上:私钥应该存储在客户端的机器上,投标在客户端的机器上加密,您的服务器仅充当分发渠道。然后如何最好地管理客户端应用程序中的密钥以减少摩擦成为一个设计问题
    • 不幸的是,这不是一个可行的解决方案,恕我直言,原因有两个:首先(这可以克服),我们 99% 的客户不知道如何在本地机器上管理密钥或加密内容(是的,我们可以使用 JS 或其他东西,但这只会增加阻力)。然而,最重要的是,投标只能在拍卖开始日期之前保密,届时我们的报告系统必须检查数据并生成定制的复杂报告。这是我们的客户完全可以接受的。
    • AFAIK 您应该能够使密钥管理对您的客户完全透明;需要注意的是,他们需要 some 实用程序来在给定的应用程序副本之间传输密钥。但在他们看来,这是一个相对标准的备份/恢复流程。
    【解决方案2】:

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

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

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

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

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

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

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

    【讨论】:

    • 感谢 Dimitrious,所有有效积分。然后我的问题是,你会推荐我们看什么其他解决方案?
    【解决方案3】:

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

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

    几个关键点:

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

    为了全面披露和可能进行一些微妙的营销,我碰巧是一家名为 Gazzang 的公司的架构师和 CTO,该公司实施了一个名为 zTrustee 的产品,该产品的运作方式与上述完全一样;-)

    【讨论】:

    • 如何向投标人保证拍卖师不会与第三方服务串通以在到期前释放加密对象? :)
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-04-11
    • 2022-12-12
    • 1970-01-01
    • 2016-08-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多