Как искать в зашифрованных полях базы данных

Если шифрование является подходящим элементом управления безопасностью для реализации, это означает, что криптографические ключи, используемые для шифрования / дешифрования данных, не доступны для программного обеспечения базы данных. В большинстве случаев имеет смысл хранить сервер приложений и сервер баз данных на отдельном оборудовании.

Реализация буквального поиска зашифрованных данных

Возможный вариант использования: хранение номеров социального страхования, но возможность их запрашивать.

Чтобы хранить зашифрованную информацию и все еще использовать открытый текст в запросах SELECT, мы будем следовать стратегии, которую мы называем слепой индексацией . Общая идея заключается в том, чтобы хранить хеш-код с ключом (например, HMAC) открытого текста в отдельном столбце. Важно, чтобы слепой индексный ключ отличался от ключа шифрования и был неизвестен серверу базы данных.

Для очень конфиденциальной информации вместо простого HMAC вам понадобится использовать алгоритм растяжения ключа (PBKDF2-SHA256, scrypt, Argon2) с ключом, действующим как статическая соль, чтобы замедлить попытки перечисления. В любом случае нас не беспокоят атаки «грубой силы» в автономном режиме, если только злоумышленник не сможет получить ключ (который не должен храниться в базе данных).

Поэтому, если ваша схема таблицы выглядит следующим образом (в варианте PostgreSQL):

 CREATE TABLE humans (

    humanid BIGSERIAL PRIMARY KEY,
    first_name TEXT,
    last_name TEXT,
    ssn TEXT, /* encrypted */
    ssn_bidx TEXT /* blind index */
);
CREATE INDEX ON humans (ssn_bidx);

Вы должны хранить зашифрованное значение в humans.ssn Слепой индекс незашифрованного SSN попадет в humans.ssn_bidx Наивная реализация может выглядеть так:

 <?php
/* This is not production-quality code.
 * It's optimized for readability and understanding, not security.
 */

function encryptSSN(string $ssn, string $key): string
{
    $nonce = random_bytes(24);
    $ciphertext = sodium_crypto_secretbox($ssn, $nonce, $key);
    return bin2hex($nonce . $ciphertext);
}

function decryptSSN(string $ciphertext, string $key): string
{
    $decoded = hex2bin($ciphertext);
    $nonce = mb_substr($decoded, 0, 24, '8bit');
    $cipher = mb_substr($decoded, 24, null, '8bit');
    return sodium_crypto_secretbox_open($cipher, $nonce, $key);
}

function getSSNBlindIndex(string $ssn, string $indexKey): string
{
    return bin2hex(
        sodium_crypto_pwhash(
            32,
            $ssn,
            $indexKey,
            SODIUM_CRYPTO_PWHASH_OPSLIMIT_MODERATE,
            SODIUM_CRYPTO_PWHASH_MEMLIMIT_MODERATE
        )
    );
}

function findHumanBySSN(PDO $db, string $ssn, string $indexKey): array
{
    $index = getSSNBlindIndex($ssn, $indexKey);
    $stmt = $db->prepare('SELECT * FROM humans WHERE ssn_bidx = ?');
    $stmt->execute([$index]);
    return $stmt->fetchAll(PDO::FETCH_ASSOC);
}

Более подробное подтверждение концепции включено в дополнительный материал для моей презентации B-Sides Orlando 2017 . Он выпущен под лицензией Creative Commons CC0, которая для большинства людей означает то же самое, что и «общественное достояние».

Анализ безопасности и ограничения

В зависимости от вашей конкретной модели угроз, это решение оставляет два вопроса, на которые необходимо ответить, прежде чем его можно будет принять:

1. Это безопасно для использования, или это утечка данных, как сито?
2. Каковы ограничения на его полезность? (Этот вид уже ответил.)

Учитывая приведенный выше пример, предполагая, что ваш ключ шифрования и ваш слепой индексный ключ разделены, оба ключа хранятся на веб-сервере, и у сервера базы данных нет никакого способа получить эти ключи, тогда любой злоумышленник, который только скомпрометирует сервер базы данных ( но не веб-сервер) сможет узнать, только если несколько строк имеют номер социального страхования, но не то, что является общим SSN. Эта утечка повторяющихся записей необходима для того, чтобы индексация была возможной, что, в свою очередь, позволяет выполнять быстрые запросы SELECT из предоставленного пользователем значения.

Кроме того, если злоумышленник способен как наблюдать / изменять открытые тексты как обычный пользователь приложения, так и наблюдать слепые индексы, хранящиеся в базе данных, он может использовать это в атаке с выбранным открытым текстом , где он повторяет каждое возможное значение как пользователь а затем коррелируйте с результирующим значением слепого индекса. Это более практично в сценарии HMAC, чем, например, в сценарии Argon2. Для значений высокой энтропии или низкой чувствительности (не SSN) физика грубой силы может быть на нашей стороне.

Гораздо более практичной атакой для такого преступника будет замена значений из одной строки в другую, а затем обычный доступ к приложению, что откроет открытый текст, если не был использован отдельный ключ для строки (например, hash_hmac('sha256', $rowID, $masterKey, true) Лучшей защитой здесь является использование режима AEAD (передача первичного ключа в качестве дополнительных связанных данных), чтобы шифротексты были привязаны к определенной строке базы данных. (Это не помешает злоумышленникам удалить данные, что является гораздо более сложной задачей .)

По сравнению с объемом информации, просочившейся из других решений, модели угроз большинства приложений должны посчитать это приемлемым компромиссом. Пока вы используете аутентифицированное шифрование для шифрования и либо HMAC (для слепой индексации нечувствительных данных), либо алгоритм хеширования паролей (для слепой индексации конфиденциальных данных), легко рассуждать о безопасности вашего приложения.

Однако у него есть одно очень серьезное ограничение: оно работает только для точных совпадений. Если две строки различаются бессмысленным образом, но всегда выдают разные криптографические хеш-значения, то поиск одной из них никогда не приведет к другой. Если вам нужно выполнить более сложные запросы, но при этом не использовать ключи дешифрования и значения в виде открытого текста в руках сервера базы данных, нам нужно проявить изобретательность.

 CREATE TABLE humans (
    humanid BIGSERIAL PRIMARY KEY,
    first_name TEXT, /* encrypted */
    last_name TEXT, /* encrypted */
    ssn TEXT, /* encrypted */
);
CREATE TABLE humans_filters (
    filterid BIGSERIAL PRIMARY KEY,
    humanid BIGINT REFERENCES humans (humanid),
    filter_label TEXT,
    filter_value TEXT
);
/* Creates an index on the pair. If your SQL expert overrules this, feel free to omit it. */
CREATE INDEX ON humans_filters (filter_label, filter_value);