java - 使用Java可搜索的行级加密？

Question

我正在设计一个Java应用程序，该应用程序使用算法将其他来源的数据导入数据库。该应用程序还搜索数据库中的记录。

如何以数据库甚至不知道数据已加密的方式实现行级安全性，而且还允许使用从Java代码调用的查询来搜索数据库？

在将数据插入数据库之前，我可以使用BouncyCaSTLe加密每行数据中的每个字段。但是，如果数据库中的每个行和字段都经过单独加密，那么如何搜索行呢？答案是否像在将搜索参数传递到SQL或JPA SELECT查询之前使用相同的密钥对每个搜索参数进行加密一样简单？还是需要更复杂的方法？

我目前正在使用MySQL，但是如果这对数据库供应商而言是不可知的，那就太好了。

Answer 1

良好加密的最重要属性之一是，将相似的明文加密为截然不同的密文。两个密文的大约一半位将匹配。使用此属性很难(不可能)制定通过LIKE查找子字符串或确定字段值是大于还是小于给定值的任何类型的查询。

还有另一个属性，那就是语义安全。当使用相同的密钥对相同的明文进行加密时，生成的密文应该不同。此属性使攻击者无法获取有关纯文本块的某些元信息，但是由于建议的解决方案的工作方式，必须删除此属性。

让我们以AES作为CBC模式下的基本加密原语为例。它的块大小为16个字节，因此密文将是此的倍数。如果开销太大，则应使用具有三个不同密钥的三重DES(168比特安全性为24字节密钥)。

简单的例子:

所有表单元格都使用相同的密钥加密。现在，您要查询表以获取其中一列具有特定值的行。首先，您将值加密以与相同的密钥匹配，并且由于我们说过没有语义安全性，因此生成的密文将与表中的密文完全匹配。

query("SELECT * FROM table WHERE col = '" + encrypt(x) + "';");

然后，您遍历结果集并解密每个值。警告:为简单起见，未对查询进行参数设置。使用准备好的语句来禁用SQL注入(inject)。

实现非语义安全:

ECB模式是不安全的支柱，我建议使用带有静态IV(也许全为0x00字节: new byte[16];)的CBC模式。还有其他确定性的操作模式，但稍后会介绍更多。

局限性:

没有order by

不直接在SQL中使用值计算

where子句

中没有 <， >， <=或 >=

...(现在想不起来)

使其有趣:

您可以采取一些措施来提高安全性。

如果事先知道永远不会尝试查看两列是否具有相同的值，则可以使用半随机方法，在此方法中，您将为每个表的每一列分配不同的随机初始化 vector (IV)。这样，攻击者就无法尝试将一列中的密文与另一列中的密文进行匹配，以找到相似之处来获取有关明文的一些元数据。

如果减少开销不是那么重要，则可以选择采用确定性的身份验证加密模式(例如SIV)，而不是CCM或GCM(不确定EAX)。它仅具有身份验证标签的开销(AES为16字节)。通过使用它，您始终可以检查密文是否被某人操纵，并且可以检查密文值是否从另一个表单元格中移出，因为您可以简单地将列名用作关联数据。仍然很难检测它是否在没有严重性能下降的情况下在列中移动。

幻想解决限制

Order-Preserving Encryption可用于解决上述第1个限制，但是您会牺牲安全性，因为

Intuitively, it says that certain attackers can learn half the bits of a plaintext given its ciphertext.

资料来源: How does order-preserving encryption work?

如果SQL风格直接在SQL中提供加密功能，则可以避免第二个限制(也许也可以避免其他限制)，但是第二个限制可能太慢而无法大规模使用。

公钥加密

您可能已经注意到，我始终只提到对称加密。不必只使用对称加密，但是例如RSA的问题是密文很大(对于2048位密钥为256字节)，而AES的开销很小。基于ECC的加密的占用空间要好得多(例如ElGamal Encrypt)。

关于公钥加密的另一个好处是，您可以查询所有想要的数据，但是如果没有私钥就无法解密数据。因此，您始终可以将数据放入(使用公钥)，但只能通过私钥取出数据。