数据库加密字段的模糊搜索_如何搜索安全加密的数据库字段

数据库加密字段的模糊搜索

This post was originally published on the ParagonIE blog and reposted here with their permission.

该帖子最初发布在ParagonIE博客上，并在获得其许可的情况下在此处重新发布。

---

---

We [ParagonIE] get asked the same question a lot (or some remix of it).

我们[ParagonIE]经常被问到相同的问题(或对其进行一些混音)。

This question shows up from time to time in open source encryption libraries’ bug trackers. This was one of the “weird problems” covered in my talk at B-Sides Orlando (titled Building Defensible Solutions to Weird Problems), and we’ve previously dedicated a small section to it in one of our white papers.

这个问题会不时出现在开源加密库的错误跟踪器中 。 这是我在奥兰多B站的演讲中 提到的“怪异问题”之一(标题为“ 为怪异问题构建防御解决方案” )，我们以前在其中一份白皮书中专门针对了其中一小部分。

You know how to search database fields, but the question is, How do we securely encrypt database fields but still use these fields in search queries?

您知道如何搜索数据库字段 ，但问题是， 我们如何安全地加密数据库字段，但仍在搜索查询中使用这些字段？

Our secure solution is rather straightforward, but the path between most teams asking that question and discovering our straightforward solution is fraught with peril: bad designs, academic research projects, misleading marketing, and poor threat modeling.

我们的安全解决方案相当简单，但是大多数团队在提出问题和发现我们的简单解决方案之间的道路充满着危险：不良的设计，学术研究项目，误导性的营销以及不良的威胁建模 。

If you’re in a hurry, feel free to skip ahead to the solution.

如果您很着急，请随时跳过此解决方案 。

迈向可搜索的加密 (Towards Searchable Encryption)

Let’s start with a simple scenario (which might be particularly relevant for a lot of local government or health care applications):

让我们从一个简单的场景开始(这可能与许多地方政府或医疗保健应用特别相关)：

• You are building a new system that needs to collect social security numbers (SSNs) from its users.
  您正在构建一个新系统，该系统需要从其用户那里收集社会保险号(SSN)。
• Regulations and common sense both dictate that users’ SSNs should be encrypted at rest.
  法规和常识都规定用户的SSN应该在静止状态下进行加密。
• Staff members will need to be able to look up users’ accounts, given their SSN.
  给定用户的SSN，工作人员将需要能够查找用户的帐户。

Let’s first explore the flaws with the obvious answers to this problem.

首先，让我们用明显的答案来解决这些缺陷。

不安全(或其他不良建议)的答案 (Insecure (or otherwise ill-advised) Answers)

非随机加密 (Non-randomized Encryption)

The most obvious answer to most teams (particularly teams that don’t have security or cryptography experts) would be to do something like this:

对于大多数团队(特别是没有安全性或加密专家的团队)，最明显的答案是这样做：

<?php
class InsecureExampleOne
{
    protected $db;
    protected $key;

    public function __construct(\PDO $db, string $key = '')
    {
        $this->db = $db;
        $this->key = $key;
    }

    public function searchByValue(string $query): array
    {
        $stmt = $this->db->prepare('SELECT * FROM table WHERE column = ?');
        $stmt->execute([
            $this->insecureEncryptDoNotUse($query)
        ]);
        return $stmt->fetchAll(\PDO::FETCH_ASSOC);
    }

    protected function insecureEncryptDoNotUse(string $plaintext): string
    {
        return \bin2hex(
            \openssl_encrypt(
                $plaintext,
                'aes-128-ecb',
                $this->key,
                OPENSSL_RAW_DATA | OPENSSL_ZERO_PADDING
            )
        );
    }
}

In the above snippet, the same plaintext always produces the same ciphertext when encrypted with the same key. But more concerning with ECB mode is that every 16-byte chunk is encrypted separately, which can have some extremely unfortunate consequences.

在以上代码段中，当使用相同的密钥加密时，相同的明文始终会产生相同的密文。 但是，与ECB模式有关的更多问题是，每个16字节的块分别进行了加密 ，这可能会带来一些非常不幸的后果 。

Formally, these constructions are not semantically secure: If you encrypt a large message, you will see blocks repeat in the ciphertext.