H2 的安全问题答案

【问题标题】：A security concern with H2H2 的安全问题
【发布时间】：2014-08-17 13:03:03
【问题描述】：

注意：虽然我提到的是 H2，但这可能适用于任何 DBMS，

我的担忧：

是否可以通过执行以下操作来侵入加密的 H2 数据库？

在某个表中存储一个非常大的清零 BLOB，大小为 100 KB。
检查新的 H2 数据库文件二进制文件并在页面/块边界附近寻找重复模式。页面/块大小可以从 H2 源代码中获得。如此获得的重复模式将是用于加密 H2 数据库的密钥。
一旦密钥暴露出来，黑客只需足够专注，然后进一步挖掘 H2 源并找出其表、列和行的确切结构。换句话说，从此时起，一切都暴露无遗。

我没有亲自研究过 H2 的源代码，也不是密码学专家，但这就是为什么我认为上述方法（或类似上述思路的一些技巧）可能有效：

【问题讨论】：

【解决方案1】：

一个好的加密算法不会受到这种攻击。

明文中的模式（这里是零的 BLOB）将在密文中消散。密钥在密文中不容易作为模式或其他方式可见。在使用分组密码时实现这一点的经典技术是使分组的加密依赖于前一个分组的密文。这里我指的块是密码算法中使用的块，通常是 128 位长度。

例如，您可以将明文块与前一个块加密的结果进行异或，这是来自 Wikipedia 的 CBC 模式模式，它将当前块与加密之前的前一个块的结果进行异或。

如您所见，即使您在每个明文块中输入全零，您最终也会得到一个完全随机的结果。

这些只是示例，H2 中使用的实际混淆机制可能更复杂或更复杂，具体取决于它们使用的算法。

【讨论】：

但即使每个加密块在 CBC 中都不同，但对于整个数据库页面（通常是 > 加密块），我确实希望看到重复的模式。我关心的不是密码算法的可靠性，而是 H2 如何使用它来防止上述类型的攻击。因为 H2 的源代码是公开的，所以任何黑客都可以找出正在使用的混淆机制，因此……值得关注。
使用这样一种方案是可能的并且是可取的，其中包含相同数据的两个数据库页面不会产生相同的密文。例如，当使用像 TrueCrypt 这样的磁盘加密软件时，这一点很明显，其中 512 字节的磁盘扇区通常包含相同的数据，但应该加密为不同的密文。
代码是开源的，理论上是件好事，除了密钥，一切都应该是公开的。我们可以假设攻击者无论如何都可以访问专有代码，因此最好将其公开并进行同行评审。我将尝试挖掘 H2 中使用了什么加密，希望是 AES-XTS 或类似的。但是，实现确实通常是最薄弱的地方。
谢谢。 H2 确实允许在连接 URL 中指定 "CIPHER=AES"。我想知道 H2 如何避免数据序列 2x、3x、4x 的模式重复......加密块大小。另外，如果在同一页面内有重复的模式，安全方面是否可以？例如，跨页面存储时清零的 BLOB 会为不同的页面提供不同的密文，但我担心在同一页面内重复的模式。

【解决方案2】：

H2 中使用的文件加密算法不使用ECB encryption mode。文件加密算法为as documented，不易受到此类攻击。将用于 H2 未来版本的 new storage engine 使用 standardized AES XTS algorithm。

【讨论】：