id: Гость   вход   регистрация
текущее время 15:19 29/03/2024
Автор темы: Гость, тема открыта 31/10/2005 20:46 Печать
http://www.pgpru.com/Форум/Криптография/ЗашифрованнаяБазаДанных
создать
просмотр
ссылки

Зашифрованная база данных


Всем привет.


Интересует вопрос шифрования баз данных.


Предположим что у нас есть Web-приложение хостируемое у провайдера (untrusted third party). База данных администрируется DBA провайдера. Хостинг сервера администрируются также админами провайдера.


База данных условно состоит из одной таблицы с полями { key, value }. Количество пользователей ограничено (скажем, меньше 10).


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


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


Хочеться чего-то более серьезного. Скажем уникальный ключ на каждую запись. Но как тогда осуществлять поиск? Полный перебор всех записей неприемлем.


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


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


Понимаю что вопрос сформулировал достаточно расплывчато.
Буду очень благодарен если кто-нибудь подталкнет в нужном направлении. Описаны ли подобные проблемы в литературе?


Спасибо.


 
Комментарии
— SATtva (31/10/2005 21:23)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Предположим что у нас есть Web-приложение хостируемое у провайдера (untrusted third party).

Описаны ли подобные проблемы в литературе?

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

Всё, что потребуется провайдеру, — это записать реквизиты доступа. Если предполагаете шифровать их по SSL, не забывайте, что провайдер будет иметь доступ и к закрытому ключу сервера.
— Гость (31/10/2005 21:36)   <#>
Все те же условия, что и в системах DRM

О. Пошел учить мат-часть. Спасибо.

Продолжительная защита системы от компрометации невозможна, если она находится в ненадёжной среде.

Хмм.

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

В принципе хочется примерно того же самого, только используя базу данных. Сообщений очень много. Боб хочет искать среди них нужное...
— SATtva (01/11/2005 01:04)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Алиса зашифровывает сообщение публичным ключом Боба и отправляет его Бобу.

Неудачный пример. Боб расшифровывает сообщение на своём доверенном компьютере или на рабочем компьютере, где царь и бог — сисадмин? Во втором случае защищённость системы коммуникации наших героев ждёт туманное будущее.

Чтобы поставить знак тождества между Вашим примером и проектом системы из Вашего первого постинга, база должна крутиться на доверенном сервере. Узкое место всей схемы в том, что какой бы механизм защиты Вы ни выбрали, недоверенная сторона (провайдер) всегда будет иметь доступ к секрету сервера, будь это закрытый ключ асимметричной пары (который пров просто считает с сервера) или тайный симметричный ключ, общий для всех пользователей (даже если такой не хранится на сервере постоянно, его можно прослушать, поскольку пров будет иметь доступ и к SSL-сертификату сервера).
— Гость (01/11/2005 09:33)   <#>
Прошу прощения — вероятно действительно неудачный пример, я слишком плохо сформулировал задачу.

Рассмотрим более конкретный пример. Alice — финансовый аналитик. Bob и Charlie — ее клиенты, подписанные на разные категории ценных бумаг (однако множества могут пересекаться).

База данных — одна таблица { ticker, rating, recommendation, analyst_opinion }. Alice пополняет базу, а Bob и Charlie хотят делать запросы вида 1) ticker = 'MSFT' 2) rating = 'AAA' and recommendation = 'BUY'.

Alice, Bob и Charlie используют толстые клиенты с полной возможностью криптографии.

Потенциальные враги — developer, sysadmin, DBA. Риски утечки информации. Риски того, что DBA изменит для какой-то бумаги recommendation с 'BUY' на 'SELL', но с этим понятно что делать. Исходные коды — более чем доступны потенциальному врагу. Риски внедрения back door рассматривать не будем — предполагаем хороший аудит архитектуры и реализации.

Ну с analyst_opinion понятно что делать — шифруется публичными ключами Bob и/или Charlie.

А вот с ticker, rating, recommendation — проблемы. По ним осуществляется поиск. И в тоже время комбинация этих трех полей содержит достаточно много конфидициальной информации. Вариант с перебором всех записей базы неприемлем.

Вариант с использованием hash функции для ticker, rating, recommendation сразу отпадает — в силу того что количество тикеров конечное число, легко вычислить hash для каждого тикера.

Использовать один симметричный ключ как-то не очень хочеться. Он должен где-то храниться... И если Charlie вступит в сговор с developer/sysadmin/DBA, то он сможет получить доступ к информации ему не предназначенной. А хочеться чтоб даже в этом случае он смог получить из базы только то что ему предназначено.
— SATtva (01/11/2005 10:31)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Вариант с использованием hash функции для ticker, rating, recommendation сразу отпадает — в силу того что количество тикеров конечное число, легко вычислить hash для каждого тикера.

В "Прикладной криптографии" (раздел 3.8. Криптографическая защита баз данных) Шнайер приводит аналогичные опасения.

Я представляю только два подхода к защите БД:

1. Размещение базы на шифрованном разделе. Имеет смысл только в подконтрольной доверенной среде на случай форсмажора.
2. Шифрование полей базы (с поиском по шифрованным или хэшированным индексам и подобные схемы). Система не обяза быть подконтрольной, но среда всё равно должна быть доверенной.

Проблема Вашего случая в том, что в любом случае недоверенной стороне остаётся простор для манёвра. Например, как будет осуществляться взаимодействие клиентов с базой? Трафик можно тем или иным образом шифровать, но у оппонента всегда будет доступ к секрету сервера и, следавательно, сохранится возможность трафик расшифровать.

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

Если же требуется и защита данных на канале связи, при этом предполагается тесная интеграция клиентский приложений с СУБД, может быть решением стало бы расшифрование переданных полей именно у клиентов? (Т.е. мы не задействуем протоколов защиты транспорта, вроде SSL, вообще.)

Вопрос индексации и поиска остаётся. Можно было бы хэшировать поля не в чистом виде, а "подсаливать" их некой случайной строкой. В то же время, как согласовать её с клиентами без риска перехвата?. Более того, это не решает проблему разграничения доступа для защиты от инсайдерских атак. Вообще со всех сторон Вашу базу враги обложили. :)

Надо подумать ещё. Какие идеи есть у коллег?
— Гость (01/11/2005 12:29)   <#>
В "Прикладной криптографии" (раздел 3.8. Криптографическая защита баз данных)

Спасибо за ссылку! Сейчас же закажу на Bolero.

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

Да, защита от манипуляций легко реализуется цифровой подписью. Здесь все очевидно.

Основная угроза — это инсайдеры. Защита информации от утечки.

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

Можно было бы хэшировать поля не в чистом виде, а "подсаливать" их некой случайной строкой.

Это в данном случае аналогично шифрованию с симметричным ключом — общий секрет который дает доступ ко содержимому базы.


— unknown (04/11/2005 15:45)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
К сожалению, работа с базами данных это все еще не решенная криптографическая задача (так же как и зашифрованными дисками – слишком много потенциальных дырок и возможностей утечки информации заложено во все протоколы, много открытий будет в будущем).

Можете ознакомиться с работой http://eprint.iacr.org/2004/170
хотя бы для общего представления всей сложности проблемы.

Для выявления "инсайдера" надо будет еще прикрутить к этому делу протоколы класса "traitor tracing", но это все тоже очень сложные задачи. Честно признаюсь, не могу дать никакого простого практического совета. Это предмет для специальной разработки. Неудивительно же. что большинство баз данных так плохо защищено?
— Гость (04/11/2005 22:30)   <#>
Общая задача шифрованной базы данных действиельно нерешенная, но кое-какие решение похожих задач существуют. Например стоит взглянуть на Just1Key компании Hush Communications:
Там вы отдаете на хранение ваши пароли от сайтов.
Ключем в их базе данных является H1(u, p), то есть общий хэш логического ключа (в даннонм случае это URL сайта) и пароля пользователя. Содержание базы данных зашифрованно симметричным ключем H2(u, p), где H2 — тоже хеш функция, но независимая от H1. Из H2 в принципе можно исключить u.

Ваша задача несколько сложнее, так как пишут и читают базу данных разные пользователи. Из этого следует, что без ассимметричной криптографии не обойтись. Вместо пароли p, надо пользоваться согласованным секретом (при помощи, скажем, Diffie-Hellman) того, кто записывает и того, кто имеет право читать. (в этом случае можно даже обойтись без цифровой подписи — MDC достаточно для проверки подлинности, так как ни ключа шифрования ни ключа базы данных противник не знает)

Скорее всего стоит просто продублировать записи в базе данных для всех пользователей, которые имеют к данной записи доступ. Их ведь не так много, верно? Так же стоит продублировать базу данных в обе стороны запроса (ticker -> rating, recommendation, opinion) и (rating, recommendation -> ticker, opinion)

То есть у провайдера хостинга вы держете базу данных пар (key, value), где запрос всегда происходит на key. Для него (провайдера) ни то, ни другое ничего не говорит.

В конкретной реализации конечно можно избежать полного дублирования, но это уже детали реализации. У меня, кстати, есть некоторые наработки для похожей системы (был у меня такой заказ раньше). Если вам нужна программная реализация, у меня уже много готового, проверянного кода, и в достаточно короткий срок могу свою систему подогнать под вашу конкретную задачу (небесплатно, конечно). Или же могу вам послать свой код с документацией (по-английски), и подгоняйте сами (это бесплатно — исходники открытые, никаких секретов).
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3