需求

對于一些敏感字段，比如手機號碼、身份證、地址、銀行卡號等，我們在存放進數(shù)據(jù)庫前，可能需要對其進行加密。

大部分情況下，我們只需要支持等值查詢。但是如果需要支持模糊查詢，那么整段內(nèi)容整體加密就不具備這個能力。

下面是幾種解決辦法，場景是我們需要根據(jù)手機號碼的前綴進行匹配。

服務(wù)器端解密

因為服務(wù)器肯定是具備解密密文的能力的，因此最簡單的方式就是把整個表的密文字段數(shù)據(jù)拉下來，在服務(wù)器端進行解密，然后再在服務(wù)器端進行匹配。

findRecords(prefix)  {
    records = getAllRecords()
    finds = []
    for (record : records) {
        phone = decrypt(record.phone)
        if (phone.hasPrefix(prefix)) {
            finds.push(record)
        }
    }
    return finds
}

如果數(shù)據(jù)量很小，那么這種做法也許還能夠接受。但是只要數(shù)據(jù)量上去，那么效率就會很低，而且還需要通過網(wǎng)絡(luò)IO把整個表的數(shù)據(jù)傳輸?shù)椒?wù)器端。

數(shù)據(jù)庫端解密

上面的做法需要把整個表的數(shù)據(jù)傳輸?shù)椒?wù)器端，那么我們只需要能夠在數(shù)據(jù)庫進行匹配，就不需要傳輸整個表了。因此我們也可以在數(shù)據(jù)庫實現(xiàn)解密算法，在匹配的時候用解密算法解密密文，就能夠進行模糊匹配了。

findRecords(prefix) {
    return query("select * from table where decrypt(phone) like '?%'", prefix)
}

這個做法也是需要遍歷整個數(shù)據(jù)庫，因此只適合數(shù)據(jù)量比較小的情況下；而且需要把密鑰傳給數(shù)據(jù)庫，增加了密鑰泄露的風險。

字符串分片

上面的做法我們都沒有用到數(shù)據(jù)庫的索引能力，正常情況下，前綴匹配我們是可以使用到索引的，比如where phone like 'prefix%'。如果加密后的密文，也能夠走索引，那么我們就不需要遍歷整個數(shù)據(jù)表了。

比如我們可以根據(jù)4位作為一個檢索條件，將手機號碼拆分位多個分片：比如手機號012345678901，我們可以拆分并對分片進行加密：

這些密文拼接起來的串為：

/egpaR5G9sMQUUWWz+3CLgeHCMZqxNSLx/B37koArx/w9w1Pv8ik2H41s1KORLfPHAvcFFFvi0mwAgIjdSQjcmSwTr/WaYfVySyMJhcZ78RFlA2wFeC6sgdXX7wmo0YcYY/QFfO9qD9XPx/lnJJuTfTfaAWufth7zOBLEy2LmepG5Taw1xR5MHRmlqOac5X6Cmn3kA

然后就可以支持前綴查詢了（最少4位），比如前綴01234，我們可以按照上面的分片方式先分片，再拼接為查詢串：

查詢串：

/egpaR5G9sMQUUWWz+3CLgeHCMZqxNSLx/B37koArx/w

可以看到查詢串為上面的前綴，因此可以進行前綴查詢！

代價

這種方式也是會有一定的代價的：

密文長度較長

比如手機號碼是明文長度是11，但是按照4位分片的密文長度是198

分片長度不能太短

分片太短有安全問題，因此沒辦法支持過短的查詢。

主要是因為切片過短，會很容易被猜出來每一位對應(yīng)的密文。比如0-9的密文切片長度1切分：

只有10種分片類型，如果對應(yīng)的是手機號碼字段，很容易根據(jù)統(tǒng)計每個數(shù)字的概率分布猜出每個數(shù)字對應(yīng)的密文。

可能有多余結(jié)果

可能有兩個不同分片對應(yīng)相同密文，這時候就需要在服務(wù)器再過濾一遍。

參考

密文字段檢索方案

實現(xiàn)

Golang實現(xiàn)基于AES+CBC+PKCS5Padding的可模糊查詢加密