2.3. Шифровка

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

Шифровка– преобразование читаемого текста в нечитаемый текст при помощи некоторого алгоритма; применяется для защиты уязвимых данных.

Сначала рассмотрим простую схему шифровки, затем – более сложный и более надежный метод.

Метод простой подстановки

Предположим, необходимо зашифровать сообщение (простой текст).

Идет снег.

Простой текст  текст, который можно прочесть.

Текст-шифр  текст, который прочесть невозможно.

Метод простой подстановки состоит в замене каждой буквы алфавита на следующую за ней в алфавите. Считается, что пробел идет после буквы «я» и перед буквой «а». Тогда «идет снег» превращается в текст – шифр:

йежуатожд

Метод поалфавитной подстановки

Предположим, мы хотим зашифровать то же самое сообщение, но теперь у нас есть ключ шифра, например, «защита». Тогда:

1. Ключ пишется под текстом и повторяется столько раз, чтобы полностью «закрыть» текст:

идет снег

защитазащ.

2. Будем считать, что пробел занимает тридцать третье и последнее место в алфавите. Для каждого символа сложим номер в алфавите символа текста и соответствующего символа ключа, разделим на 33 и сохраним остаток. Заменим символ текста на символ, имеющий вычисленный номер. В нашем примере под пробелом (33) стоит т (19), таким образом (33+19)= 52, остаток от деления на 33 равен 19.

На 19 месте в алфавите стоит буква т, поэтому вместо пробела в зашифрованном тексте будет т.

2.4. Секретность данных

БД, позволяющая получать агрегированную информацию о больших подмножествах некоторого множества объектов, называется статистической. Примерами могу служить БД переписи населения, налоговых деклараций либо пациентов госпиталя. Кроме обычных проблем предотвращения несанкционированного доступа к БД или ее модификации, в статистической БД существуют проблемы, связанные с тем, что допускаются запросы в виде: «Напечатать средний доход всех жителей Томска», но в тоже время запрещается доступ к данным о доходах, конкретного человека, например Иванова.

Не так просто запретить запросы, которые требуют информации, относящейся к единственной записи. Например, Петров может запросить средний доход для множества {Петров, Иванов}, из которого, зная свой собственный доход, он может вычислить доход Иванова. Не решает проблему также и требование, чтобы информация запрашивалась относительно множества, состоящего из m человек. Действительно, в этом случае Петров мог бы взять множество S из m-1 или более человек, доходы которых ему не нужно узнавать, и запросить средний доход этих людей вместе с Ивановым. Затем он получил бы средний доход для множества, включающего его самого и людей из множества S. Зная свой собственный доход, он смого бы теперь легко определить доход Иванова на основе двух ответов системы. Поэтому необходимо ввести огранечения на запросы, сильно пересекающиеся друг с другом и таким образом можно если не предотвратить раскрытие индивидуальных данных, но сделать это достаточно трудным делом.

Будем считать для простоты, что статистическая БД содержит единственный файл записей. Каждая запись состоит из нескольких полей. Пусть v = (v,v,…v) – вектор значений некоторого неключевого поля этих записей. Тогдалинейным запросомназывается линейная сумма, где- произвольные действительные числа.

Важным случаем линейных запросов является сумма по множеству S, где

а также средние, где

где p - число записей в S.

Способность компрометировать БД (т.е. вычислять значения отдельного ) будет зависеть от допустимого числа ненулевых, а не от их точных значений.

Существует теорема: Пусть допускаются линейные запросы, продуцирующие по меньшей мере m элементов (т.е. обрабатывают m записей), и никакие два запроса не могут иметь более k общих элементов (т.е. k общих записей). Предположим, что p элементов уже известны (т.е. для p записей конкретные значения поля известны), тогда для вычитания некоторого еще неизвестного элемента (значения поля в интересующей нас записи) необходимо сделать не менее 1+ (m-1-p)k запросов.

Ограничения на структуру запроса.

Пусть ключ записи состоит из x полей и предполагается, что в запросе можно задать не более y полей ключа (т.е. выполняется поиск по частичному соответствию ключа). Тогда, если y < k, никакая функция, использующая только операции сложения, вычитания, умножения и деления, не позволит определить значение данного конкретной записи.