1680

Приложение А

Далее я продемонстрирую, как шифровать и дешифровать большой объект. Для этого используется простой оператор UPDATE. Обратите внимание, что на этот раз применяется ключ шифрования длиной 24 байта. Мы будем использовать подпрограмму DES3ENCRYPT, поскольку установили необязательный параметр which => ThreeKeyMode. В результате будет выполнено шифрование тройным алгоритмом DES с тройным ключом:

tkyte@DEV817> update demo

2 set theClob = crypt pkg.encryptLob(theClob,

3 MagicKeyIsLongerEvenMore)

4 where id = 1;

1 row updated.

tkyte@DEV817>selectdbms lob.getlength(theclob)lob len,

2 utl raw.cast to raw(crypt pkg.md51ob(theclob)) md5 checksum

3 from demo;

LOB LEN MD5 CHECKSUM

50624 FCBD33DA233 6C83 685B1A62956CA2D16

Длина объекта увеличилась с 50601 до 50624 байт, и рассчитанная по алгоритму MD5 контрольная сумма отличается от прежней - т.е. данные изменены. Если вспомнить представленное ранее описание алгоритма, мы взяли первые 32000 байт объекта типа CLOB, добавили в начале 8 байт при кодировании строки и зашифровали результат. Затем мы выбрали оставшиеся 18601 байт данных и дополнили их до 18608 байт (чтобы длина была кратна 8), и добавили еще 8 байт для сохранения исходной длины. Это и дало в результате увеличение длины до 50624 байт.

Теперь рассмотрим, как выбрать из базы данных зашифрованный объект типа CLOB:

tkyte@DEV817> select dbms lob.substr (

2 crypt pkg.decryptLob(theClob), 100, 1) data

3 from demo

4 where id = 1;

DATA

set define off

create or replace package htp as /* STRUCTURE tags */ procedure htmlOpen; procedure

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

Проблемы

Данные, зашифрованные средствами пакета DBMS OBFUSCATION TOOLKIT в

системе с обратным порядком байтов ( little endian system) не могут быть дешифрова-

Пакет DBMS OBFUSCATION TOOLKIT 1681

ны с помощью того же ключа в системе с прямым порядком байтов (Ъig endian system). Речь идет о порядке байтов в многобайтовом числе. На Intel-платформах (NT, многие дистрибутивы Linux и Solaris x86) принят обратный порядок байтов. Системы на базе процессоров Sparc и Risc обычно имеют прямой порядок байтов. Данные, зашифрованные на Windows NT с помощью ключа 12345678 , нельзя расшифровать на Sparc Solaris с помощью этого же ключа. Следующий пример демонстрирует проблему (и способ ее избежать). На платформе Windows NT выполним:

tkyte@TKYTE816> create table anothert (encrypted data varchar2(2 5)) ;

Table created.

tkyte@TKYTE816> insert into anothert values

2 (crypt pkg.encryptString( helloworld, 12345678));

1 row created.

tkyte@TKYTE816> select crypt pkg.decryptstring(encrypted data)

from anothert;

CRYPT PKG.DECRYPTSTRING(ENCRYPTED DATA)

hello world

tkyte@TKYTE816> host exp userid=tom/kyte tables=anothert

Соответствующий файл EXPDAT.DMP передан по FTP на машину Sparc Solaris и загружены находящиеся в нем данные. При попытке выбрать данные я получил:

opsStkyte@DEV816> select

2 crypt pkg.decryptstring(encrypted data, 12345678)

3 from t;

crypt pkg.decryptstring(encrypted data, 12345678)

ERROR at line 2:

ORA-06502: PL/SQL: numeric or value error: character to number convers ORA-06512: at OPS$TKYTE.CRYPT PKG , line 84 ORA-06512 : at OPS$TKYTE.CRYPT PKG , line 215 ORA-06512: at line 1

ops$tkyte@DEV816> select

2 crypt pkg.decryptstring(encrypted data, 43218765)

3 from t;

CRYPT PKG.DECRYPTSTRING(ENCRYPTED DATA,43218765)

hello world

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

Оказывается, 8 байтовый (или 16-, или 24-байтовый ключ) внутренне хранится как набор 4-байтовых цел1х чисел. Мы должны изменить порядок байтов в каждой 4-байтовой группе символов ключа, чтобы расшифровать данные в системе с другим поряд-

1682

ПриложениеА

ком байтов. Поэтому, если использовался ключ 12345678 на платформе Windows NT (Intel), я должен использовать ключ 43218765 на Sparc Solaris. Задаем первые 4 байта в обратном порядке, затем задаем в обратном порядке следующее 4 байта (и так далее - для ключей большего размера).

Это важно помнить при переносе данных, например, с NT на Sparc Solaris и при запросе данных из удаленной базы. Вы должны быть готовы физически переупорядочить байты, чтобы успешно дешифровать данные. Эта проблема была решена в версиях, начиная с Oracle 8.1.7.1, так что теперь переставлять байты уже не нужно.

Управление ключами

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

Зашифрованные данные защищены настолько, насколько защищен ключ, использовавшийся для шифрования. Тут все дело в ключе. Если ключ известен, данные с таким же успехом можно вовсе не шифровать (при наличии ключа данные можно расшифровать оператором SELECT).

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

Генерация и хранение ключей в клиентском приложении

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

При использовании этого метода, связанного с передачей ключей по сети, необходимо добавить еще один уровень шифрования - шифрование потока данных протокола Net8. Связываемые переменные и строковые литералы по умолчанию передаются в явном виде. В этом случае, поскольку защита ключей принципиально важна, придется использовать технологии типа ASO (Advanced Security Option - расширенная защита).