客户端加密,但云服务在死亡的情况下仍然可以解密数据?这可能吗?

信息安全 加密 隐私 客户
2021-09-06 19:25:55

我一直担心这个密码管理器,PasswordBox,它最近似乎正在收集相当多的蒸汽。

他们似乎已经筹集了风险投资资金,并提供免费的密码管理和存储工具。他们的团队似乎没有丰富的加密经验。

真正让我担心的是他们的安全页面提到:

您的所有敏感数据都在您的计算机上通过只有您知道的主密码进行加密和解密。此主密码不会存储在我们的服务器上,因此您的安全数据 > 除您之外的任何人都无法检索。

同时,他们的功能页面提到,他们可以在用户去世后向亲人提供密码访问权限(前提是他们有死亡证明)。详细流程在这里

用于加密密码数据的密钥如何仅存储在客户端上,并且仍然允许第三方服务在发生死亡时解密数据的能力。为什么会有人相信这些家伙?

4个回答

更新:

PasswordBox 回复了我关于该主题的询问。就个人而言,我无法真正弄清楚他们在说什么。这可能是理解的问题。下面是他们回复的截图

在此处输入图像描述


这是一个非常有趣的问题。PasswordBox 似乎声称他们永远无法访问您的密码。根据他们的常见问题页面:

PasswordBox 服务器永远不会看到您的解密数据

PasswordBox 永远不会看到或存储您的主密码,因此我们永远无法访问您的数据

唯一剩下的可能性(我能想到的)是密钥的一半可能存储在客户端中,另一半存储在他们的服务器上。所以他们真的无法访问您的数据,当您请求访问亲人的帐户时,他们有办法将一半的密钥从他们的服务器发送到客户端(在死者的计算机或移动设备上),因此解密的数据仅在客户本身。

请注意,当我说“一半密钥”时,是因为我缺乏密码学知识。可能存在某种方式,两方可以共享密钥的两个部分,而实际上需要两个部分来访问密钥。

更新:感谢@DeerHunter 的评论,看来确实有这样的方案,叫做Shamir 的秘密分享方案。我刚刚下载了实现并玩了一下。对我来说(再次,非常浅薄的密码学知识)似乎它可能是您问题中提出的问题的一个很好的候选者。你可以自己试试

SSSS-split(shares, threshold, secret)
SSSS-split(2, 2, "YOUR_KEY")

Shares = 2(一份给你,一份服务)
Threshold = 2(至少需要两份才能恢复秘密,这里是指所有的部分)

注意:所有答案(包括这个)都只是猜测。我们仍然不知道发生了什么,因为 PasswordBox 没有分享太多技术细节。Lucas 和我已经向 PasswordBox 发送了电子邮件,我们正在等待答复。一旦我们收到回复,答案将相应更新。

请注意“此主密码未存储在我们的服务器上,因此除您之外的任何人都无法检索您的安全数据”这句话。实际上,一个并不一定意味着另一个,具体取决于细节。

考虑以下系统:通过散列您的主密码在客户端软件上生成对称密钥,希望具有相当强的东西,例如足够数量的 PBKDF2 轮次。此密钥将用于对称加密您的数据,使用 AES-128 或 AES-256 之类的东西,具体取决于它们可以从您的密码生成多长时间的密钥。然后使用存储服务提供给您的客户端的公钥对该密钥进行非对称加密(RSA、ECC),并与您的加密数据一起传输给他们。该对的私钥在物理上保护在一个 HSM 中,该 HSM 被锁定在钢筋混凝土后面的保险库中,经过认证的访问控制层和流程规则,以确保任何人都无法单独获得它。

要正常解密您的数据,您的主密码必须在客户端软件中重新散列以获得对称密钥。如果您的密码因为您已经进入坟墓而无法使用,您的近亲必须向公司代表出示您的死亡证明,然后他们将您的帐户信息的数据转储和存储的数据从他们的服务器检索到便携式设备。他们将其带入可访问 HSM 保险库的安全房间,取出 H​​SM,将其插入计算机,并通过它运行加密的对称密钥,然后使用非对称解密的密钥对称解密您的数据并将其提供给你的家人。

因此,您的主密码永远不会存储在他们的服务器上,正如他们所说的那样。同样,解密您的密钥所需的密钥在技术上也不存储在他们的服务器上;它保持离线状态,以确保需要对设备进行物理访问。因此,通常,您是唯一可以访问您的数据的人。但是,如果您去世,通过审核过程,您的家人可以让存储公司检索您的数据。

评论编辑:这只是一种可能性,正如评论所推断的那样,可能是对公司实际内部流程的假设比实际存在的更多。OP 询问了一个系统是否有可能具有客户端加密,同时允许服务器端数据恢复并仍然保护用户的秘密密码。这是一种可能性,我既不断言也不否认 PasswordBox 正在使用类似的东西。

提供的流程明显缺乏技术细节。它提供了人事流程,但不提供技术流程。很难说,看到它,这意味着什么。

我最初阅读常见问题解答的想法是,密码是人类可以记住的东西,但“主密码”是由密码和加盐过程构建的一个难以理解的数字。这用于在传输之前加密客户端数据。

我假设:

  • 受益人可以获得原始密码(不是主密码)的副本,然后使用原始所有者的机器,受益人可以解锁主密码以获得客户端访问权限。

  • 它们完全不一致,并且有一种方法可以从服务器解密客户端数据。

我要在这里补充一点——我在为普通人提供的“安全”服务中经常看到这一点。要么努力将其归结为普通消费者感到安全,要么使信息在技术上毫无意义,或者他们只是不放对他们的设计有足够的思考。无论哪种方式,一个相当精通的技术人员都无法得到直接的答案,这让我很抓狂。

请注意,密码和加密密钥之间可能存在差异!

第一条语句说,如果没有您的密码,他们就无法解密您的资料。考虑到第二个陈述,我相信他们可能正在使用自己的主密钥/密码加密加密密钥或所有文件(重复)。这意味着他们可以解密你的东西并且没有保密性。

如果他们可以解密它,这意味着他们可以通过某种方式获取您的(加密的)密钥(而不是您的密码),或者他们有一个主密钥。无论如何,他们在存储密钥时确实有办法访问您的数据(如果有人死了,他们必须解密数据)。

也可能是你需要在他死后提供他的钥匙(如果你能找到的话)。或者另一种可能的情况是加密密钥本身是用母亲的密码加密的。当母亲要求分配继承人时,儿子需要提供一个密码,该密码也将加密母亲的解密密钥。现在解密/加密密钥存储在他们的服务器上,但密钥本身是用密码加密的(所以从技术上讲,他们无法获得密钥)。

现在,我个人更希望文件在本地(完全)加密,然后发送到服务,而不是保存我的解密密钥的服务,用我的密码加密。因为他们仍然可以访问解密密钥(尽管它是加密的)。我的意思是什么会阻止他们实现一个存储用他们的密码加密的密钥副本的功能?