Хеширование используется не только в криптографии, но и во многих других областях, например в веб-программировании и антивирусных средствах.
Веб-приложения не запоминают состояние: они не сохраняют соединение с сервером базы данных открытым на протяжении транзакции. Другими словами, для них не существует понятия «сеанс», и поэтому нет возможности блокирования данных в том виде, в каком она существует в традиционных приложениях. Так что простого способа определения того, что данные на веб-странице изменились, не существует. Но если сохранить вместе с данными хеш-значение, то потом можно вычислить его заново и сравнить с сохраненным значением. Если два значения не совпадут, это будет означать, что данные были изменены.
Хеширование также полезно при определении надежности данных. Представим себе вирус, который изменяет важные документы, хранящиеся в базе данных. Триггеру это не отловить. Однако если документ содержит хеш-значение, то, сравнив вычисленное значение с сохраненным, вы сможете определить, было ли искажено содержание документа и можно ли ему теперь доверять.
Рассмотренный ранее метод хеширования весьма полезен, но имеет некоторые недостатки:
• Проверить подлинность переданных данных с помощью хеш-функции может кто угодно. Это может оказаться недопустимым для некоторых систем повышенной безопасности, предполагающих, что аутентичность сообщения или данных проверяет только определенный получатель.
Узнав алгоритм хеширования, злоумышленник может вычислить правильное хеш-значение и подменить им реальное, скрыв тем самым изменение данных.
По причине, указанной в предыдущем пункте, хранение хеш-значения вместе с данными не представляется безопасным. Каждый, кто имеет привилегию на изменение таблицы, сможет изменить и хеш-значение. Аналогично некто может сгенерировать хеш-значение и изменить данные «в пути». Поэтому хеш-значение не должно сопровождать данные, а обязательно должно передаваться отдельно, что усложняет систему.
Справиться с этими недостатками помогает усовершенствованная реализация хеширования, в которой эксклюзивность механизма хеширования на стороне получателя удостоверяется паролем или ключом. Такое специальное хеш-значение называется кодом аутентификации сообщения (MAC - Message Authentication Code). Отправитель вычисляет MAC для данных, используя предопределенный ключ, который также известен получателю, но не отправляется вместе с данными. Отправитель отсылает получателю MAC вместе с данными, не разделяя их. После получения данных получатель также вычисляет значение MAC (используя тот же ключ) и сравнивает его со значением, пришедшим вместе с данными. Схематически данный механизм изображен на рис. 4.9.
Как и хеширование, MAC следует стандартным алгоритмам MD5 и SHA-1. При этом, как и в функции HASH, используемый алгоритм ука-
Можно также построить собственные вычисления MAC на основе на шей функции хеширования.
зывается в параметре typ. Требуется выбрать значение DBMS_CRYP TO. HMAC_MD5 или DBMS_CRYPTO.HMAC_SH1. В следующем примере значени MAC для входной строки вычисляется при помощи алгоритма SHA-1
Протестируем эту функцию, попробовав получить значение MAC для данных «Test Data» и ключа «Key».
Для вычисления контрольной суммы требуется ключ, что делает данный метод более надежным, чем просто хеширование. Например, в банковских приложениях важна целостность таких данных, как номер социального страхования (Social Security number - SSN) клиента, владеющего счетом. Предположим, что таблица счетов ACCOUNTS выглядит следующим образом:
Предположим теперь, что когда-нибудь впоследствии какой-то злоумышленник изменит поле SSN. Если бы поле SSN_MAC содержало хеш- значение столбца SSN, то злоумышленник мог бы самостоятельно вычислить хеш-значение и записать новое значение в этот столбец. Тогда при последующем вычислении хеш-значения для столбца SSN и его сравнении с сохраненным значением SSN_MAC значения бы совпали, и изменение данных выявить бы не удалось! Если столбец содержит не хеш-значение, а MAC-значение для столбца, то вычисление нового значения потребует знания ключа («A Jolly Good Rancher»). Не зная его, злоумышленник не сможет сгенерировать значение, равное MAC- значению, и изменение данных будет очевидным.
Подведем итог. Применим полученные знания о шифровании и хешировании, построив реальную действующую систему шифрования.
При создании счета вычисляется значение MAC для поля SSN: используется предопределенный ключ, например «A Jolly Good Rancher». Столбец SSN_MAC обновляется следующим образом:
В некоторых случаях требуется сравнение зашифрованных данных с входящими данными. Например, многие CRM-приложения (Customer Relationship Management - управление взаимоотношениями с клиентами) используют для уникальной идентификации клиентов такие атрибуты, как номера кредитных карт, номера паспортов и другие. Медицинским приложениям может потребоваться просмотр истории болезни для предложения плана лечения. Страховым компаниям может понадобиться просмотр диагнозов пациента для подтверждения справедливости жалоб. Все эти данные хранятся в зашифрованном виде, поэтому простое сравнение входящих данных с сохраненными данными невозможно.
Существуют два способа обработки подобных ситуаций:
Зашифровать поступившие данные и сравнить их с сохраненными зашифрованными данными
Реализуется только в случае, если известен ключ шифрования. Если при шифровании был использован подход «один ключ для базы данных» (таблицы или схемы), то вы точно знаете, какой ключ следует применить для шифрования значений. Если был использован подход «новый ключ для каждой строки», то вам нужно знать, какой ключ следует применить для шифрования значения в каждой конкретной строке. Так что вы не сможете использовать данный способ.
Еще одним проблемным местом при использовании данного способа являются индексы. Если для данного зашифрованного столбца создан индекс, то этот индекс будет полезен при наличии предиката равенства (например, ssn = encrypt ('123-45-6789')). Запрос найдет в индексе зашифрованное значение строки «123-45-6789», а затем получит остальные значения данной строки таблицы. Если задано условие равенства, то в индексе производится поиск точного значения. Однако, если задать предикат подобия (например, ssn like '123-%'), индекс окажется бесполезным. Структура «b-tree» индекса устроена так, что рядом оказываются значения, у которых совпадают начальные символы. Индекс полезен для операции подобия, если значения заданы открытым текстом. В этом случае записи индекса для «123-45-6789» и «123-67-8945» оказались бы недалеко друг от друга. Но после шифрования такие значения могут превратиться в нечто подобное:
Как видите, начальные символы зашифрованных значений сильно отличаются друг от друга, поэтому они попадут в разные части индекса. В результате поиск по индексу для определения местоположения в таблице окажется медленнее полного просмотра таблицы.
Расшифровать зашифрованные данные в каждой строке и сравнить их с соответствующими открытыми данными
Для тех, кто использует отдельный ключ для каждой строки, этот способ является единственно возможным. Но каждая операция дешифрования потребляет несколько драгоценных циклов ЦПУ и может повлиять на общую производительность базы данных.
Как же спроектировать систему так, чтобы сравнение с зашифрованными столбцами было наиболее эффективным? Фокус в том, чтобы выполнять сравнение не с зашифрованным значением, а с хеш-значе
нием. Создание хеш-значения занимает значительно меньше времени, чем шифрование, и потребляет меньше циклов ЦПУ. Поскольку в результате хеширования некоторых данных всегда будет получено одно и то же хеш-значение, можно сохранить хеш-значение для конфиденциальных данных, создать хеш-значение для проверяемых на совпадение данных и сравнить его с сохраненным хеш-значением.
Предлагается следующая структура системы. Предположим, что у нас есть таблица CUSTOMERS, в которой хранятся номера кредитных карт, требующие шифрования. Вместо того чтобы сохранять в таблице CUSTOMERS номер кредитной карты, мы создадим две дополнительных таблицы (таблицы и связи между ними представлены на рис. 4.10).
Таблица CUSTOMERS
CUST_ID (первичный ключ)
CC (хеш-значение кредитной карты, но не сам реальный номер карты) Таблица CC_MASTER
CC_HASH (первичный ключ)
ENC_CC# (зашифрованное значение номера кредитной карты) Таблица CC_KEYS
CC_HASH (первичный ключ)
ENC_KEY (ключ шифрования, используемый для шифрования данного номера кредитной карты)
Незашифрованный номер кредитной карты нигде не хранится. Можно написать триггер, запускаемый перед вставкой (INSERT) или изменением (UPDATE) строки, который будет реализовывать такой псевдокод.
Тем самым мы обеспечим отсутствие незашифрованного значения номера кредитной карты в базе данных. Приложения будут продолжать вставлять значения открытым текстом, но триггер будет заменять их хеш-значениями. Далее приводится возможный код такого триггера:
Поясним ключевые моменты:
Строки
|
Описание
|
|
10
|
Сначала вычисляю хеш-значение для полученного открытым текстом от пользователя номера кредитной карты.
|
|
13-
|
16
|
Проверяю, существует ли такое значение в таблице CC_MASTER.
|
21
|
Если совпадающее хеш-значение не найдено, это означает, что речь идет о новой кредитной карте. Для ее шифрования необходимо сначала сгенерировать ключ.
|
|
22
|
Использую этот ключ для шифрования открытого значения номера карты.
|
|
24-
|
-28
|
Вставляю зашифрованный номер кредитной карты в таблицу
CC_MASTER.
|
30-
|
34
|
Сохраняю ключ в таблице CC_KEYS.
|
41
|
Заменяю открытый номер кредитной карты соответствующим хеш-значением и сохраняю его.
|
|
Триггер заменяет открытое значение хеш-значением, поэтому изменение приложения не требуется. Программы, сравнивающие номера кредитных карт, будут искать совпадение с хеш-значением, а не с открытым или зашифрованным значениями. Используя такой триггер и представленные в главе функции, вы сможете создать собственную эффективную систему шифрования.
В этой главе мы познакомились с шифрованием, управлением ключами, хешированием и некоторыми смежными вопросами. Давайте подведем некоторые итоги. Шифрование данных - это маскировка данных, выполняемая для того, чтобы скрыть их реальное значение. Для шифрования требуются входные данные, ключ шифрования и алгоритм шифрования. Существуют два базовых метода шифрования: асимметричное шифрование (шифрование с открытым ключом) - для шифрования и дешифрования используются разные ключи, и симметричное шифрование - для шифрования и дешифрования используется один и тот же ключ. Первый метод обычно используется при передаче данных и требует тщательной настройки, в то время как второй способ достаточно прост в применении.
Наиболее важным и сложным аспектом создания инфраструктуры шифрования является создание надежной и безопасной системы управления ключами, а не использование самих программных интерфейсов приложений. Для хранения ключей можно использовать раз-
нообразные возможности: можно хранить их в базе данных, в файловой системе или комбинировать эти типы хранилищ. Вы можете использовать один ключ для всей базы данных, отдельный ключ для каждой строки таблицы или какой-то промежуточный вариант. Можно использовать два разных ключа: обычный ключ, сохраненный в одном месте, и мастер-ключ, сохраненный в другом месте. Для шифрования данных будет использован не сохраненный ключ, а результат побитовой операции XOR для мастер-ключа и сохраненного ключа. Даже если один из этих ключей будет рассекречен, дешифровать данные удастся только после получения второго ключа.
В некоторых случаях нет необходимости в сокрытии данных, требуется лишь уверенность в том, что они не были изменены. Для этого существует криптографическое хеширование. Хеш-функция всегда возвращает одно и то же значение для заданного входного значения. То есть изменение вычисленного хеш-значения по отношению к исходному хеш-значению означает изменение исходных данных. Одна из разновидностей хеширования, MAC (код аутентификации сообщения), также использует ключ.
Oracle 10^ Release 2 вводит новую возможность прозрачного шифрования - Transparent Database Encryption (TDE), обеспечивающую прозрачное шифрование и дешифрование данных перед их сохранением в полях данных. При использовании средств TDE конфиденциальные данные в файлах данных, архивных журнальных файлах и резервных копиях баз данных хранятся в зашифрованном виде, следовательно, кража таких файлов не приводит к рассекречиванию данных. Однако имейте в виду, что TDE не является полноценной системой шифрования, поскольку требует контроля над пользователями. Если вы хотите управлять доступом к дешифрованным значениям, то вам необходимо будет создать собственную инфраструктуру.
| < Предыдущая | Следующая > |
|---|
