security - 确保第三方存储数据的完整性和有效性

Question

我正在处理不受信任的外部存储，需要确保存储提供商不会保留查询中的任何记录。

示例:

我有两个受信任的实体 TA 和 TB，这些实体应该能够更改存储在云/不可信存储中的数据，但没有其他人可以更改。所以我的解决方案我为 TA 和 TB 配备了公钥，并且我有一个数据结构，可以与具有版本的表进行比较

 Ver | Data | Signature       | Signee
  4  |  ... | (AAAAAAAAA)_TA  | TA
  3  |  ... | (ZZZZZZZZZ)_TB  | TB
  2  |  ... | (YYYYYYYYY)_TA  | TA
  1  |  ... | (XXXXXXXXX)_TA  | TA

因此，当我从存储提供商检索这样的表时，我可以轻松验证签名并检查签名是否正确，是否允许签名者更改表格。

但是，我还想检查记录的完整性。假设 TA 上传版本 4，但 TB 只知道版本 3 之前的所有记录。现在，当 TB 查询时，存储提供商可能会完全扣留版本 4。

由于 TA 和 TB 之间没有直接的旁路，因此无法交换当前版本。有没有办法避免这个问题？

我正在考虑定期插入虚拟记录，以便至少有一定的时间确定性。然而，这种方法缺乏可扩展性，并且会导致大量的存储和签名开销。我正在寻找的实际系统属性是什么(很难找到您不知道其名称的东西的研究)？

Answer 1

如果没有虚拟记录，这个问题就无法完全解决:

我们将当前版本为版本 3 时的状态称为“状态 3”，将当前版本为版本 4 时的状态称为“状态 4”。无论您如何签署这些状态 - 只要攻击者告诉您“状态 3 是当前状态”(向您显示状态 3 期间的整个数据库)，您就无法知道这是否属实或状态是否正确同时存在 4 个。

因此，您将必须定期签署“无更改”更新。您将无法避免签名开销，但您不必存储所有这些。您创建一个单独的“lastupdate”表:

 Signer | Last | Timestamp | Signature
  TA    |  4   | 2013-1... | (TA;4;2013-1...)_TA
  TB    |  3   | 2013-1... | (TB;3;2013-1...)_TB

意思是“签名者TA确认截至2013年1月...，我发送的最后一个版本是4”。如果存储提供商无法向您显示来自所有签名者的当前确认，表明他们没有发布更新版本，则您必须假设他隐藏了某些内容(或某些损坏的内容) - 无论哪种方式，数据都不是最新的)。任何新签署的声明都会替换该签名者的旧声明，因为它们现在无关紧要。

现在，如果您不只拥有一个版本化“事物”，而是拥有大量版本化“事物”，则不必为每个“事物”拥有一个这样的虚拟日志。例如，您可以计算签名者所有最新行的哈希(或哈希树)(例如“事物 A，版本 3。事物 B，版本 7。事物 C，版本 2。”)，然后只需将hash 或lastupdate 表中的哈希树的根。

如果您确实想要避免额外的签名，并且某些内容一直在更新，您可以在您签署的版本记录的签名中包含哈希值和时间戳 - 最新的签名记录这样就足以证明新鲜度，如果它太旧，您仍然可以使用“lastupdate”表。恕我直言，这不值得这么复杂。