Шифрование

Data Encryption Standard (DES)

Алгоритм Data Encryption Standard (DES) был разработан компанией IBM в начале 1970-х гг. Национальный институт стандартов и технологий США (NIST) принял на вооружение алгоритм (публикация FIPS 46) для DES в 1977 г. после изучения, модификации и утверждения алгоритма в NSA. Алгоритм подвергался дальнейшей модификации в 1983, 1988, 1993 и 1999 гг.

DES использует ключ длиной 56 бит. Используются 7 бит из байта, восьмой бит каждого байта используется для контроля четности. DES является блочным алгоритмом шифрования, обрабатывающим единовременно один 64-битный блок открытого текста (см. рис. 12.3). В алгоритме DES выполняются 16 циклов шифрования с различным подключом в каждом из циклов. Ключ подвергается действию своего собственного алгоритма для образования 16 подключей (см. рис. 12.4).

На блок-схеме алгоритма DES изображены несколько блоков, в которых происходит перестановка. Рассматриваемый стандарт шифрования предусматривает специальное переупорядочивание битов для каждой перестановки. То же самое относится к алгоритму генерации подключа. Для перестановочной выборки 1 и 2 предусмотрено определенное переупорядочивание битов. На рисунке 12.3 также изображена функция вызова f. В этой функции находятся S-блоки. S-блоки представляют собой блоки табличного поиска (также определенные в стандарте), изменяющие 6-битные выходные данные на 4-битные.

Алгоритм DES может функционировать в четырех режимах.

Были раскрыты несколько атак, требующих меньше вычислительных мощностей, нежели исчерпывающий поиск (дифференциальный и линейный криптоанализ; для получения более детальных сведений по этим атакам посетите сайт (http://www.rsasecurity.com/rsalabs/faq/). Однако эти атаки требуют большого объема выборочного открытого текста и, следовательно, практически не осуществимы в реальном мире. Сегодня особенно заметным слабым местом шифров стал 56-битный ключ. 56 бит ключа обеспечивают потенциальное число ключей, равное 2⁵⁵. В сегодняшних компьютерных системах все пространство ключей может быть изучено за небольшой промежуток времени. В 1997 г. организация Electronic Frontier Foundation (EFF) анонсировала компьютерную систему, которая сможет найти ключ DES за четыре дня. Создание этой системы стоило 250 000 долларов. С помощью современного оборудования можно определить ключ DES посредством атаки "грубой силы" за 35 минут. Этого времени слишком мало, чтобы защитить информацию, которая должна сохраняться в секрете. В переработанной публикации FIPS (46-2 и текущая 46-3) в NIST признали этот факт, сказав, что простой DES можно использовать только в устаревших системах.

Тройной DES

В 1992 году исследования показали, что DES можно использовать трижды для обеспечения более мощного шифрования. Так родилась концепция тройного алгоритма DES (TDES). На рисунке 12.5 показана схема работы алгоритма TDES. Обратите внимание, что вторая операция в действительности представляет собой дешифрование. Используемый при этом ключ обеспечивает большую мощность тройного DES в сравнении с обычным DES.

Тройной DES используется либо с двумя, либо с тремя ключами. При использовании двух ключей ключ K3 идентичен K1. TDES является относительно быстрым алгоритмом, так как его можно реализовать аппаратно. Его функционирование занимает в три раза больше времени, чем у DES, так как имеют место три операции шифрования DES. В большинстве приложений рекомендуется использовать TDES вместо простого DES.

Примечание

TDES подвергался двум атакам. Тем не менее, объем данных, требуемый для проведения атак (как и в случае с атаками на DES), делал проведение атак на этот алгоритм практически неосуществимым в реальных ситуациях.

Шифрование паролей

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

У каждого пользователя есть свой пароль. Алгоритм использует первые восемь символов пароля. Если пароль длиннее восьми символов, он усекается. Если пароль короче восьми символов, он дополняется. Пароль преобразуется в 56-битное число с помощью первых 7 бит каждого символа. После этого система выбирает 12.битное число на базе системного времени. Этот элемент называется "крупинкой соли" или расширением. Расширение и пароль используются в качестве входных данных в функции шифрования паролей (см. рис. 12.6).

Расширение используется для изменения одной из таблиц перестановки в алгоритме DES (перестановка E) любым из 4096 различных способов, в зависимости от числа единиц в двенадцати битах. Начальный открытый текст содержит 56 нулевых битов, а ключом являются 56 бит, полученных из пароля. Алгоритм выполняется 25 раз, причем входные данные каждого этапа являются выходом предыдущего этапа.

Конечные выходные данные преобразуются в 11 символов, а расширение преобразуется в 2 символа и помещается перед конечными данными выхода.

Главной уязвимостью этой системы является то, что она основана на выборе пароля. Так как большинство пользователей компьютеров используют пароли, состоящие из символов нижнего регистра, мы имеем общее число возможных комбинаций, равное 2⁶⁸. Это значительно больше, чем 2⁵⁵ возможных ключей DES, поэтому взлом такого шифра посредством "грубой силы" займет гораздо меньше времени и вычислительных ресурсов для раскрытия паролей в системе Unix.

Примечание

Большая часть систем Unix теперь обеспечивает возможность использования теневых файлов паролей. Если зашифрованные пароли легко взламываются с помощью грубой силы, то посредством сокрытия зашифрованных паролей можно несколько повысить уровень безопасности системы. Как и в случае с остальными системами, если корневой пароль является слабым, или если в корне системы присутствует "дыра", то правильность выбора паролей пользователями уже не играет какой-либо роли.

Расширенный стандарт шифрования Rijndael

Взамен DES NIST анонсировал в 1997 г. появление алгоритма-конкурента стандарту DES с названием AES. В конце 2000 г. NIST объявили о том, что два криптографа из Бельгии (Joan Daemen и Vincent Rijmen) выиграли конкурс, представив алгоритм Rijndael. Этот алгоритм был выбран с учетом его мощности, применимости в высокоскоростных сетях, а также возможности аппаратной реализации.

Rijndael представляет собой блочный шифр, использующий ключи и блоки длиной 128, 192 или 256 бит. На сегодняшний день такая длина ключей обеспечивает практическую неосуществимость атак с применением грубой силы. Алгоритм состоит из 10-14 циклов, в зависимости от размеров блока открытого текста и размера ключа. На рисунке 12.7 показано, какие вычисления производятся в каждом цикле.

Так как этот стандарт был одобрен, Rijndael начал появляться во многих системах. Данный алгоритм можно считать достойной альтернативой алгоритму TDES.

Другие алгоритмы шифрования с секретным ключом

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

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

Внимание!

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

Шифрование с открытым ключом

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

В чем заключается шифрование с открытым ключом?

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

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

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

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

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

Алгоритм обмена ключами Диффи-Хеллмана

Уитфилд Диффи (Whitfield Diffie) и Мартин Хеллман (Martin Hellman) разработали свою систему шифрования с открытым ключом в 1976 г. Система Диффи-Хеллмана (Diffie-Hellman) разрабатывалась для решения проблемы распространения ключей при использовании систем шифрования с секретными ключами. Идея заключалась в том, чтобы применять безопасный метод согласования секретного ключа без передачи ключа каким-либо другим способом. Следовательно, необходимо было найти безопасный способ получения секретного ключа с помощью того же метода связи, для которого разрабатывалась защита. Алгоритм Диффи-Хеллмана нельзя использовать для шифрования или дешифрования информации.

Алгоритм Диффи-Хеллмана работает следующим образом.

Примечание

В приведенных выше уравнениях "mod" означает остаток. Например, 12 mod 10 = 2. Два - это остаток от деления 12 на 10.

Если злоумышленник прослушивает трафик, передаваемый по кабелю, то ему будут известны a, b, I и J. Тем не менее, остаются в секрете i и j. Уровень безопасности системы зависит от сложности нахождения i при известном I = ai mod b. Эта задача называется задачей дискретного логарифмирования и считается очень сложной (т. е. с помощью современного вычислительного оборудования ее решить практически невозможно), если числа очень велики. Следовательно, a и b необходимо выбирать очень тщательно. Например, оба числа b и (b - 1)/2 должны быть простыми и иметь длину не менее 512 бит. Рекомендуемая длина чисел составляет 1024 бит.

Алгоритм обмена ключами Диффи-Хеллмана используется во многих системах безопасности для реализации обмена ключами, используемыми для дополнительного трафика. Недостатком системы Диффи-Хеллмана является то, что она может быть уязвима для атаки посредником (см. рис. 12.9). Если атакующий сумеет разместить свой компьютер между двумя абонентами P1 и P2, подключить его к каналу связи и осуществлять перехват всей передаваемой информации, то он сможет выполнять обмен данными с P2, выдавая себя за P1, и с P1 под видом P2. Таким образом, обмен ключами будет происходить между P1 и злоумышленником и между P2 и злоумышленником. Тем не менее, осуществление такой атаки требует большого объема ресурсов, и в реальном мире такие атаки происходят редко.

Алгоритм RSA

В 1978 г. Рон Ривест, Ади Шамир и Лен Адельман разработали алгоритм шифрования Rivest-Shamir-Adleman (RSA) с открытым ключом. В отличие от алгоритма Диффи-Хеллмана RSA может использоваться для шифрования и дешифрования. Также, в отличие от алгоритма Диффи-Хеллмана, безопасность алгоритма RSA базируется на факторизации больших чисел. Задачу факторизации больших чисел принято считать очень сложной, если числа очень велики (1024 бит или больше).

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

Шифрованный текст = (открытый текст)e mod n
Открытый текст = (шифрованный текст)d mod n
Секретный ключ = {d, n}
Открытый ключ = {e, n}

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

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

Шифрованный текст = (открытый текст)d mod n
Открытый текст = (шифрованный текст)e mod n
Секретный ключ = {d, n}
Открытый ключ = {e, n}

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

Генерация ключей RSA

При генерировании ключей RSA необходимо соблюдать тщательность. Чтобы сгенерировать ключевую пару RSA, выполните следующие шаги:

Примечание

Число n должно содержать порядка 200 знаков или больше. Тогда оба числа p и q должны иметь длину, по крайней мере, 100 знаков. Ключи для использования на практике должны иметь длину 1024 бит. В случае с секретной информацией рекомендуется использовать ключи длиной 2048 бит и более.

Реальный пример работы RSA

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

Для выполнения непосредственно шифрования и дешифрования используем исходные формулы.

Шифрованный текст = (открытый текст)e mod n
Открытый текст = (шифрованный текст)d mod n

Предположим, что нужно отправить сообщение "9". С помощью формулы шифрования получаем следующее:

Шифрованный текст = (9)7 mod 143 = 48.

При получении зашифрованной информации она подвергается обработке алгоритмом дешифрования:

Открытый текст = (48)103 mod 143 = 9.

Другие алгоритмы с открытым ключом

Существуют некоторые алгоритмы с открытым ключом, имеющие такие же свойства, как RSA и алгоритм Диффи-Хеллмана. В данном параграфе мы вкратце рассмотрим три наиболее распространенных алгоритма.

Алгоритм Эль-Гамаля

Эль-Гамаль (Taher Elgamal) разработал вариант системы Диффи-Хеллмана. Он усовершенствовал алгоритм Диффи-Хеллмана и получил один алгоритм для шифрования и один для обеспечения аутентификации. Алгоритм Эль-Гамаля не был запатентован (в отличие от RSA) и, таким образом, стал более дешевой альтернативой, так как не требовалась уплата лицензионных взносов. Так как этот алгоритм базировался на системе Диффи-Хеллмана, безопасность информации при его использовании обеспечивается сложностью решения задачи дискретного логарифмирования.

Алгоритм цифровой подписи

Алгоритм Digital Signature Algorithm (DSA) был разработан правительством США как стандартный алгоритм для цифровых подписей (для получения дополнительной информации по цифровым подписям обратитесь к следующему параграфу). Данный алгоритм базируется на системе Эль-Гамаля, но позволяет осуществлять только аутентификацию. Конфиденциальность этим алгоритмом не обеспечивается.

Шифрование с использованием эллиптических кривых

Эллиптические кривые были предложены для использования в системах шифрования в 1985 г. Системы шифрования с использованием эллиптических кривых (ECC) базируются на другой сложной математической задаче, нежели факторизация или дискретное логарифмирование. Данная задача заключается в следующем: имея две точки A и B на эллиптической кривой, такие что A = kB, очень трудно определить целое число k. Существует ряд преимуществ использования ECC перед алгоритмом RSA или Диффи-Хеллмана. Самым большим преимуществом является то, что ключи имеют меньшую длину (по причине сложности задачи), в результате чего вычисления производятся быстрее с сохранением уровня безопасности. Например, безопасность, обеспечиваемая 1024-битным ключом RSA может быть обеспечена 160-битным ключом ECC. Может пройти немало времени, прежде чем ECC будут полностью приняты к использованию, так как в этой области еще необходимо провести ряд исследований, и на существующие ECC зарегистрировано несколько патентов.

Вопросы для самопроверки

Цифровые подписи

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

Что такое цифровая подпись?

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

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

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

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

Безопасность и полезность цифровых подписей зависит от двух важнейших элементов:

Примечание

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

Безопасные хеш-функции

Для использования цифровых подписей необходимы безопасные хеш-функции. Хеш-функция может называться безопасной, если:

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

Безопасные хеш-функции должны обеспечивать создание контрольной суммы длиной, по крайней мере, в 128 бит. Двумя наиболее распространенными безопасными хеш-функциями являются MD5, генерирующая 128-битную контрольную сумму, и SHA, которая производит контрольную сумму длиной 160 бит. Существует множество других хеш-функций, однако большая их часть признана небезопасными. В MD5 были обнаружены уязвимости, которые могут использоваться при проведении вычислительной атаки. Эта атака позволит создать дополнительный фрагмент информации, что приведет к образованию той же контрольной суммы. Функция SHA была разработана правительством США и в настоящее время считается безопасной. В большей части программного обеспечения по информационной безопасности рассмотренные функции MD5 и SHA доступны для использования.

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

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

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

Создание ключей

Очевидно, что ключи должны создаваться с особой тщательностью. Некоторые ключи обеспечивают недостаточную производительность при работе с определенными алгоритмами. Например, ключ, состоящий из одних "нулей", при использовании в DES не обеспечивает высокий уровень защищенности информации. Аналогично, при создании ключей для использования в RSA, необходимо соблюдать внимательность при выборе p и q из набора простых чисел.

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

Некоторые ключи выбираются из случайных чисел. К сожалению, существует очень немного генераторов истинно случайных чисел. Большинство из них генерируют псевдослучайные последовательности (т. е. в наборах чисел прослеживаются схемы, которые через то или иное время повторяются). Если генератор случайных чисел не является истинным, то существует возможность предсказания следующего числа. Если ключи базируются на выходных данных генератора случайных чисел, и злоумышленник может предсказать выходные данные, то существует вероятность того, что он сможет выявить ключ.

Также может быть необходимым выбрать правильную длину ключа. В некоторых алгоритмах используются ключи фиксированной длины (например, в алгоритме DES используется ключ длиной 56 бит). Другие алгоритмы могут использовать ключи переменной длины. Чем длиннее ключ, тем выше уровень обеспечиваемой безопасности. Например, 1024-битный ключ RSA более надежен, чем 512.битный ключ RSA. Тем не менее, таким образом нельзя сопоставлять надежность ключа RSA с надежностью ключа DES. В таблице 12.2 представлены относительные степени надежности ключей для различных алгоритмов шифрования.

Чтобы получить представление о том, насколько надежны ключи на практике, вспомните машину EFF. В 1997 г. она стоила 250 000 долларов и обеспечивала раскрытие ключа DES за 4,5 дня. В других случаях 40-битный ключ RC5 был раскрыт с помощью атаки "грубой силы" за 3,5 часа с использованием 250 компьютеров в UC Berkley. В Швейцарском Федеральном институте технологий посредством "грубой силы" раскрыт 48-битный ключ RC5 за 312 часов с использованием 3500 компьютеров. На данный момент рекомендуется использовать, как минимум, 80-битные ключи при шифровании секретной информации, а также минимум 1024-битные ключи в RSA и алгоритме Диффи-Хеллмана. 160-битные ключи ECC также считаются безопасными.

Внимание!

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

Распространение ключей

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

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

Тем не менее, существует частичное решение этой проблемы, заключающееся в использовании алгоритма обмена ключами Диффи-Хеллмана для распространения множества сеансовых ключей (ключи с коротким сроком действия, используемые для одного сеанса или небольшого объема трафика). Этот подход может снизить необходимость дальних поездок.

Любой ключ, используемый в течение продолжительного периода времени, требует обеспечения основательных мер предосторожности. Нельзя использовать алгоритм обмена ключами Диффи-Хеллмана для передачи пар ключей RSA. В случае с парами ключей RSA один ключ должен содержаться в секрете, а другой может находиться в открытом состоянии. Открытый ключ должен публиковаться так, чтобы предотвратить его подмену (см. раздел ниже "Сертификация ключей"). Если пары ключей генерируются центральным бюро сертификатов, секретный ключ должен безопасно передаваться владельцу ключевой пары. Если пара ключей генерируется владельцем, открытый ключ должен передаваться в центральное бюро сертификатов с обеспечением мер безопасности.

Примечание

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

Сертификация ключей

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

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

Внимание!

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

Защита ключей

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

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

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

Аннулирование ключей

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

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

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

Доверие в информационной системе

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

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

Иерархия

Иерархическая модель доверия наиболее проста для восприятия. Говоря простым языком, в данном случае вы доверяете человеку, который находится выше в иерархической цепи, так как от него было получено соответствующее указание о необходимости доверия. На рисунке 12.12 изображена схема этой модели. Как видно из рисунка, пользователи User1 и User2 располагаются под CA1. Следовательно, если CA1 говорит, что сертификат открытого ключа принадлежит пользователю User1, пользователь User2 будет верить этому. На практике User2 передает пользователю User1 свой сертификат открытого ключа, подписанный CA1. Пользователь User1 проверяет подпись CA1 с использованием открытого ключа CA1. Так как CA1 находится в иерархии выше, чем User1, то User1 доверяет CA1 и, следовательно, доверяет сертификату пользователя User2.

Мы рассмотрели довольно простой случай. Если пользователю User1 нужно проверить информацию от пользователя User3, все несколько усложняется. CA1 не знает о пользователе User3, в отличие от CA2. Тем не менее, пользователь User1 не доверяет CA2, так как это бюро сертификатов напрямую не принадлежит цепочке пользователя User1. Следующий уровень вверх по цепочке - CA4. Пользователь User1 может верифицировать информацию от пользователя User3 посредством проверки с помощью CA4 следующим образом.

Как видите, все довольно быстро усложняется. Представьте себе, какой объем операций по верификации необходимо было бы производить, если бы пользователю User1 нужно было верифицировать данные, поступившие от пользователя User4. Две цепочки не пересекаются вплоть до CA9! Так реализована сертификация в X.509. Иерархия устанавливается таким образом, чтобы между любыми двумя нижними объектами могла быть создана цепочка сертификатов.

С теоретической точки зрения все выглядит неплохо. Однако на практике все иначе. Одной из причин, по которой данная технология не функционировала, заключается в том, что не существовало реальных CA корневого уровня. CA корневого уровня - это наивысшая точка в иерархии. В одно время было принято считать, что в каждой стране должно быть свое бюро сертификатов корневого уровня. Также предполагалось, что компании, выпускающие кредитные карты, должны стать корневыми CA, или что каждая организация должна иметь свое собственное CA. На практике почти ничего не было реализовано. Возникал еще один вопрос, который представлял собой потенциальную проблему: сколько CA должны сертифицировать каждого конечного пользователя? Если конечный пользователь живет в стране А, обладает кредитной картой компании B и работает в организации C, должны ли все три объекта подписывать один и тот же сертификат?

Установка CA

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

Вопрос к эксперту

Вопрос. Существуют ли CA общего пользования?

) и Thawte (http://www.thawte.com/) являются наиболее яркими примерами таких CA. Организация может создать пару открытого ключа, например для веб-сервера, и отправить открытый ключ в CA. CA создает сертификат и предоставляет его организации. CA получает прибыль от предоставления этой услуги. Использование таких сертификатов можно наблюдать при посещении многих защищенных сайтов в интернете. Так как открытые ключи CA известны большей части веб-браузеров, сертификат веб-сайта верифицируется с помощью открытого ключа CA.

Примечание

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

Как видно из списка, приведенного выше, при разработке CA возникает целый ряд вопросов. Если организация достаточно крупная или имеет большое число объектов нижних уровней (т. е. пользователей), администрирование сертификатов пользователей будет отнюдь не простой задачей. Перед подписыванием сертификата нужно будет проверить личность каждого пользователя. Срок действия сертификатов будет периодически истекать, и, следовательно, будет возникать потребность в издании новых сертификатов. Некоторые сертификаты придется аннулировать.

Аннулирование сертификатов

Аннулирование сертификатов может оказаться самой трудной проблемой, связанной с CA. Как уже упоминалось ранее, каждый объект, который использует сертификат, должен уведомляться об аннулировании сертификата. Это уведомление должно осуществляться своевременно. Так как природа системы с открытым ключом не позволяет CA знать о каждом пользователе, который может использовать данный сертификат, CA должно полагаться на тех, кто будет использовать сертификат, для проверки того, что сертификат не был аннулирован. При этом потребуется, чтобы каждый объект проверял CA перед использованием сертификата.

Если организация использует только одно CA, все не так сложно, однако при этом CA должно быть постоянно доступным. Если иерархия CA имеет большие размеры (как на рис. 12.12), то проблема приобретает комплексный характер. Пользователь User1 может сообщить CA о том, что его сертификат аннулирован, и CA1 может обнародовать эту информацию, но как эта информация дойдет до пользователя User4 от CA6?

Сеть

Сеть с доверием представляет собой альтернативную модель доверия. Эта концепция была впервые использована в технологии Pretty Good Privacy (PGP). Она заключается в том, что каждый пользователь сертифицирует свой сертификат и передает его известным ассоциированным объектам. Эти объекты могут подписать сертификат другого пользователя, так как он известен (см. рис. 12.13).

В данной модели не существует центрального бюро сертификатов. Если пользователю User1 требуется верифицировать информацию, поступающую от пользователя User2, он запрашивает сертификат пользователя User2. Так как пользователь User1 знает пользователя User2, то доверяет сертификату и даже может его подписать.

Теперь рассмотрим ситуацию, в которой User1 получает информацию от User3. Пользователь User3 не известен пользователю User1, но у пользователя User3 есть сертификат, подписанный пользователем User2. Таким образом, рассматриваемая модель распространяется на всю компьютерную сеть. Единственным решением, которое должно приниматься в процессе работы, является число переходов, которому доверяет пользователь. Как правило, это число равно 3 или 4. Кроме того, может возникнуть ситуация, в которой для установления доверия другому пользователю есть два пути. Например, User2 может использовать два пути установления доверия с пользователем User5: один через пользователя User3 и другой через пользователя User4. Так как оба пользователя User3 и User4 сертифицируют пользователя User5, пользователь User2 может быть уверен в сертификате пользователя User5.

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

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

Разработка системы шифрования

Этот проект предназначен для того, чтобы продемонстрировать использование шифрования в информационной системе для обеспечения аутентификации, конфиденциальности и целостности. В данном проекте подразумевается применение как систем шифрования с секретным ключом (AES), так и систем с открытым ключом (RSA или Диффи-Хеллмана).

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

Шаг за шагом

Выводы

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

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

Контрольные вопросы