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

【问题标题】：Ensuring Data completeness and validity on third party storage确保第三方存储数据的完整性和有效性
【发布时间】：2013-12-23 23:42:13
【问题描述】：

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

例子：

我有两个受信任的实体 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 之间没有直接的侧通道，因此无法交换当前版本。有没有办法绕过这个？

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

【问题讨论】：

标签： security encryption cloud public-key-encryption verification

【解决方案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”表。恕我直言，这不值得复杂。

【讨论】：

我猜这是朝着正确的方向发展。你介意在最后一段详细说明一下吗，因为这对我来说有点不清楚。
基本上，不要仅使用时间戳和“最后一个版本”创建单独的签名，而是将时间戳和最后一个版本放入您正在签名的其他内容中。正如我所说，我认为这是一个坏主意 - 如果你真的只有两个聚会，而且它不在移动设备上，只需每 10 秒创建一个签名并使用“lastupdate”表。

【解决方案2】：

如果问题与记录完整性有关，我建议使用 MAC（消息验证码）。在这种情况下，您应该使用对称密钥加密，它比加密签名（非对称）效率更高。

我想到了两个方向：

您可以将问题归结为记录完整性。如果您有要验证的特定重要数据，您可以在存储中创建特定表，以保存每个受信任实体更新每个重要变量的时间。重要数据可以是：记录数（总、新、根据某些类别）、最新版本等。当有人做出影响重要数据的更改时，他会更新空间表中的相关记录，并在记录上签名——该记录还包含上次更新的日期。现在，为了防止不受信任的存储返回旧记录或类似的东西，每个受信任方必须每隔一段时间（例如 - 一天）至少更新一次记录 - 记录可能不会改变（只有日期记录），标志会改变（现在标志是以后的日期）。当实体读取信息时，他可以验证数据是真实的，并且最多在一天前（在示例中）是真实的。如果返回记录的日期早于一天，则不应考虑。您可以根据需要更改定期更新的频率。对于此选项，您也可以使用 MAC 代替签名（以提高效率）。
您可以尝试另一种策略：您无法验证每个更新的完整性，但如果它试图撒谎，您可以尝试捕获不受信任的存储！您可以通过安排更新和查询来做到这一点。

最后一件事 - 你写道：

由于 TA 和 TB 之间没有直接的侧信道，所以没有办法交换当前版本。有没有办法绕过这个？

我相信你的意思是沟通渠道。侧信道是另一回事。如果是我，我会创建这样的沟通渠道来解决问题。顺便说一句，与我描述的第一个选项类似，您可以创建这样一个频道：

创建一个来自不同实体的消息表，他们在其中宣布他们所做的重要更改，并在更改日期上签名：

实体 |变化 |日期 |签名（或 MAC）

就像在第一个选项中一样，每个实体都必须每隔某个预定义的时间段添加一次这样的消息 - 并且您在实体之间拥有可信的通信渠道。

【讨论】：