Зашифрованный запрос к базе данных

Question

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

Я не очень разбираюсь в криптографии, но если я не достаточно ясен, я попытаюсь отредактировать / прокомментировать, чтобы уточнить любые вопросы.

Попытка быть краткой, среда выглядит примерно так:

• Приложение, в котором внешний интерфейс для доступа к ключам шифрования / дешифрования и внутренний интерфейс просто используется для хранения и запросов.

• Имея базу данных, к которой у вас нет доступа для пары полей, например, скажем, «адрес», как обычно text / varchar.

• У вас нет доступа к ключу для расшифровки информации, и вся информация поступает в базу данных уже в зашифрованном виде.

Основная проблема заключается в следующем: как последовательно выполнять запросы к базе данных, невозможно выполнять такие вещи, как "где адрес, например,"% F§YU / ´ ~ # JKSks23% '". (Если есть кто-нибудь, кто чувствует ответ на этот вопрос, не стесняйтесь стрелять).

Но нормально ли это делать where address='±!NNsj3~^º-:'? Или это также полностью поглотит базу данных?

Еще одним ограничением, которое может применяться, является то, что интерфейс не имеет достаточной вычислительной мощности, поэтому уже шифрование / дешифрование информации начинает расширять ее до предела. (Сказать это просто, чтобы избежать ответов типа «Экспорт объединения таблиц во внешний интерфейс и запрос его там».)

Может ли кто-нибудь указать мне направление, чтобы продолжать думать об этом?

---

Что ж, спасибо за столь быстрые ответы в 4 часа утра, в первый раз я действительно впечатлен этим сообществом. (А может я просто для другого часового пояса)

Просто введите некоторую информацию:

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

Возможное решение для частичного совпадения:

• Пароль + пара открытых полей пользователя на самом деле являются ключом для шифрования. Для аутентификации идея состоит в том, чтобы зашифровать статическое значение и сравнить его в базе данных.
• Создание нового набора таблиц, в которых информация хранится в разобранном виде, что означает что-то вроде: «4-я улица» станет 2 зашифрованными строками (одна для «4-й», другая для «Улицы»). Это уже позволило бы полу-частичное сопоставление, поскольку поиск уже мог быть выполнен по отдельным таблицам.

Новый вопрос:

• Возможно, это снова поглотит сервер базы данных, или кто-то считает это жизнеспособным решением проблемы частичного сопоставления?

Post Scriptum: Я принял ответ от Cade Roux только для того, чтобы дать возможность для дальнейшего обсуждения и, в частности, возможного ответа на новый вопрос.

Answer 1

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

В более типичном приложении ключи, в конечном счете, будут доступны кому-то в цепочке - возможно, веб-серверу.

Для трафика конечного пользователя SSL защищает этот канал. Некоторые сетевые коммутаторы могут защитить его между веб-сервером и базой данных, и хранение зашифрованных данных в базе данных прекрасно, но вы не собираетесь запрашивать такие зашифрованные данные.

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

Answer 2

почему бы не зашифровать диск, содержащий таблицы базы данных, зашифровать соединения с базой данных и не позволить базе данных работать нормально?

[я не очень понимаю контекст / ограничения, которые требуют этого уровня паранойи]

РЕДАКТИРОВАТЬ: "законные ограничения", а? Надеюсь, ты не причастен ни к чему незаконному, я бы не хотел быть непреднамеренным аксессуаром ...; -)

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

Answer 3

Несколько месяцев назад я столкнулся с той же проблемой: вся база данных (за исключением индексов) зашифрована и возникла проблема частичных совпадений.

Я искал в Интернете поиски решения, но, похоже, с этим ничего не поделаешь, кроме «обходного пути».

Решение, которое я, наконец, принял:

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

2. Выполните частичное сопоставление с этой временной таблицей и получите идентификаторы.

3. Запрос реальной таблицы для этих идентификаторов и возврат результата.

4. Удалите временную таблицу.

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

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

Answer 4

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

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

Запросы к зашифрованным данным? Если вы используете хороший алгоритм шифрования, я не могу представить, как это сделать.

Answer 5

Вы хотите использовать хеширование md5. По сути, он берет вашу строку и превращает ее в хеш, который невозможно воспроизвести. Затем вы можете использовать его для проверки на предмет позже. Например:

$salt = "123-=asd";
$address = "3412 g ave";

$sql = "INSERT INTO addresses (address) VALUES ('" . md5($salt . $address) . "')";
mysql_query($sql);

Затем, чтобы подтвердить адрес в будущем:

$salt = "123-=asd";
$address = "3412 g ave";

$sql = "SELECT address FROM addresses WHERE address = '" . md5($salt . $address) . "'";
$res = mysql_query($sql);
if (mysql_fetch_row($res))
    // exists
else
    // does not

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

http://en.wikipedia.org/wiki/MD5