Методы защиты информации в компьютерных системах и сетях

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

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

В понятие управление ключами входит совокупность методов решения следующих задач:

• генерация ключей;
• распределение ключей;
• хранение ключей;
• замена ключей;
• депонирование ключей;
• уничтожение ключей.

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

3.11.1. Разрядность ключа

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

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

Примечание. На практике в гибридных криптосистемах долговременный ключ для асимметричного алгоритма выбирают более стойким, чем сеансовый ключ для симметричного.

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

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

Если технические возможности противника известны, сложность атаки путем полного перебора по всему ключевому пространству оценить достаточно просто. Например, при разрядности ключа симметричной криптосистемы, равной 64 битам, объем ключевого пространства равен 264. Компьютер, который может перебирать 106 ключей в секунду, потратит на проверку всех возможных ключей более пяти тысяч лет. Современная вычислительная техника позволяет за время около нескольких дней при финансовых затратах около нескольких сотен тысяч долларов находить методом полного перебора 56-разрядные ключи симметричных криптосистем.

Несколько лет назад международной группе исследователей удалось вскрыть шифр RSA с ключом длиной 512 бит. Именно такой ключ используется для защиты Интернет-транзакций, а также в шифрах многих коммерческих банков. Интересно также отметить, что 512 двоичных разрядов - это максимальная длина ключа, которую правительство США разрешает использовать в экспортируемых программных продуктах. Работа по подбору двух простых сомножителей числа, содержащего 155 десятичных цифр, велась в течение семи месяцев с привлечением ресурсов параллельно работающих 292 компьютеров, находящихся в 11 различных географических точках. В это количество входят 160 рабочих станций SGI и Sun, работающих на тактовых частотах 175—400 МГц, восемь компьютеров Origin 2000 SGI, работающих на частоте 250 МГц, 120 ПК с процессорами Pentium II (350—450 МГц) и четыре процессора, работающих на частоте 500 МГц, производства Digital/Compaq. Общие затраты вычислительных ресурсов составили около восьми тысяч MIPS-лет.

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

Согласно принципу Кирхгофа, стойкость криптоалгоритма определяется секретностью ключа. Это означает, что, если для генерации ключей используется криптографически слабый алгоритм, независимо от используемого шифра вся система будет нестойкой. Качественный ключ, предназначенный для использования в рамках симметричной криптосистемы, представляет собой случайный двоичный набор. Если требуется ключ разрядностью n, в процессе его генерации с одинаковой вероятностью должен получаться любой из возможных кодов. Генерация ключей для асимметричных криптосистем - процедура более сложная: так, ключи, применяемые в таких системах, должны обладать определенными математическими свойствами. Например, в случае системы RSA модуль шифрования есть произведение двух больших простых чисел.

Для генерации ключевой информации, предназначенной для использования в рамках симметричной криптосистемы, используются следующие методы (в порядке возрастания качества):

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

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

На рис. 3.36 показана схема генерации сеансовых ключей в стандарте ANSI X9.17, где E - функция зашифрования DES, K - ключ, - секретная синхропосылка, - временная отметка, - сеансовый ключ. Очевидно, что данная схема может применяться совместно с любым другим блочным шифром. Очередной сеансовый ключ формируется в соответствии с уравнением

.

Новое значение определяется следующим образом:

.

Рис. 3.36. Схема генерации ключей в стандарте ANSI X9.17

3.11.3. Хранение ключей

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

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

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

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

Один из способов аутентификации мастер-ключа показан на рис. 3.37.

Рис. 3.37. Схема аутентификации мастер-ключа

Мастер-ключ -

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

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

Рис. 3.38. Схема защиты сеансового ключа

Сеансовый ключ -

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

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

• запоминание пароля PW и в случае необходимости автоматическое получение из него ключа K с использованием хеш-функции h (x) по формуле ;
• запоминание начального заполнения качественного генератора ПСП, формирующего ключ;
• использование пластикового ключа с размещенным на нем ПЗУ (ROM-key) или интеллектуальной карточки.

Следует помнить, что в первых двух случаях объем ключевого пространства зависит не только от длины пароля или ключевой фразы, но и от ограничения на вид используемых символов. В таблице 3.3 приведено количество возможных ключей при использовании 8-символьной ключевой фразы и время полного перебора при скорости перебора 10⁶ ключей в секунду в зависимости от ограничений на используемые символы. Также следует помнить о возможности проведения противником так называемой атаки со словарем, включающем в себя наиболее вероятные ключевые слова. Пароли и символьные строки начального заполнения генератора ПСП следует выбирать случайным образом, а не только на основе критерия простоты запоминания.

Таблица 3.3. Количество возможных ключей и время их полного перебора при различных ограничениях на используемые символы

Символы ключа	Число символов	Число возможных ключей	Время полного перебора
Заглавные буквы	32		13 дней
Заглавные буквы и цифры	42		112 дней
Все 8-разрядные коды	256		600 000 лет

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

3.11.4. Распределение ключей

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

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

увеличить изображение
Рис. 3.39. Возможные варианты построения схемы распределения ключей: а - прямой обмен между пользователями в сети (схема типа «точка-точка»); б - схемы с использованием центра распределения ключей (ЦРК); в - схемы с использованием центра трансляции ключей (ЦТК); А, В, С - участники информационного обмена; К - ключ

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

Примерами первого подхода является схема Kerberos, второго - схема Диффи—Хеллмана, рассмотренные ранее.

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

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

,

подменил своим открытым ключом открытый ключ абонента А. В результате у противника появляются следующие возможности:

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

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

,

где

-

секретный ключ центра С.

В самом общем случае функциями центра доверия могут являться:

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

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

Рис. 3.40. Процедура модификации ключей

3.11.5. Время жизни ключей

Любой ключ должен использоваться в течение ограниченного отрезка времени, длительность которого зависит от:

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

При определении времени жизни ключа учитываются следующие соображения:

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

3.12. Стандарт Х.509

Стандарт Х.509 ITU появился в 1988 г. Позже в нем были исправлены некоторые недостатки в защите. Вторая версия была опубликована в 1993 г. Сейчас действует третья версия.

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

Документ Х.509 определяет каркас схемы предоставления услуг аутентификации каталогом Х.500 своим пользователям. Этот каталог может хранить сертификаты открытых ключей. Каждый сертификат содержит открытый ключ пользователя и подписывается секретным ключом центра сертификации. Кроме того, Х.509 определяет возможные протоколы аутентификации, построенные на использовании сертификатов открытых ключей.

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

Структура сертификатов и протоколов аутентификации, определяемая в Х.509, может использоваться в самых различных ситуациях. Например, формат сертификата Х.509 принят в протоколах S/MIME, IPSec, SSL/TLS и SET.

3.12.1. Сертификаты

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

На рис. 3.41 показан формат сертификата Х.509.

увеличить изображение
Рис. 3.41. Формат сертификата Х.509

Как видно из рис. 3.41, формат включает достаточное большое количество элементов.

1. Версия формата сертификата. По умолчанию выбирается версия 1. Если указан уникальный идентификатор инициатора (Initiator Unique Identifier) или уникальный идентификатор субъекта (Subject Unique Identifier), то значение версии должно быть равно 2. Если имеется одно или несколько расширений, должна быть указана версия 3.
2. Порядковый номер. Целое число, уникальное для данного ЦС, однозначно связанное с данным сертификатом.
3. Идентификатор алгоритма подписи вместе со всеми необходимыми параметрами.
4. Имя (по стандарту Х.500) ЦС, создавшего и подписавшего сертификат.
5. Срок действия - даты начала и окончания действия сертификата.
6. Имя субъекта. Имя пользователя, открытый ключ которого удостоверяет сертификат.
7. Информация об открытом ключе субъекта: собственно открытый ключ субъекта и идентификатор алгоритма, с которым должен использоваться этот ключ.
8. Уникальный идентификатор ЦС, выдавшего сертификат. Необязательный элемент. Используется, когда имя Х.500 применяется для разных ЦС.
9. Уникальный идентификатор субъекта. Необязательный элемент, используемый для однозначной идентификации субъекта, когда имя Х.500 применяется для разных субъектов.
10. Расширения. Одно или несколько полей, добавленные в версию 3.
11. Подпись. Ставится на всех остальных полях сертификата.

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

Для определения сертификата стандарт использует следующую формулу:

,

т.е. удостоверение центра сертификации Y открытого ключа абонента X.

3.12.2. Получение сертификата

Сертификат пользователя, формируемый ЦС, имеет следующие свойства:

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

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

Предположим, что абонент А получил сертификат от уполномоченного ЦС Z, а абонент В - от уполномоченного ЦС W. Если А не знает открытого ключа центра W, то сертификат абонента В окажется бесполезным, так как А не сможет проверить подпись W на сертификате. Однако если центры Z и W по какой-то защищенной схеме обменялись своими открытыми ключами, то следующая процедура дает возможность А получить открытый ключ абонента В:

• абонент А получает из каталога сертификат W, подписанный Z. Поскольку А знает открытый ключ Z, из полученного сертификата А может извлечь открытый ключ W и проверить его подлинность, проверим подпись Z;
• абонент А обращается к каталогу и получает сертификат В, подписанный центром W. Поскольку теперь А знает открытый ключ W, он может проверить подпись W на сертификате В и получить таким образом заверенный открытый ключ В.

В рассмотренном случае А использовал цепочку сертификатов

,

чтобы получить открытый ключ В. Точно так же В может получить открытый ключ А по обратной цепочке

.

На рис. 3.42 показан пример иерархии ЦС.

Рис. 3.42. Пример иерархии ЦС

В данном случае А может построить следующий сертификационный маршрут к В:

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

Если предположить, что ЦС X и Z взаимно сертифицировали друг друга, сертификационные маршруты от А к В и от В к А укорачиваются и принимают соответственно вид:

3.12.3. Отзыв сертификата

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

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

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

Каждый список отозванных сертификатов (CRL, Certificate Revocation List), размещаемый в каталоге, подписывается центром сертификации и включает в себя имя ЦС, дату создания списка, дату выхода следующей версии CRL и отдельные записи по каждому из отозванных сертификатов. Каждая такая запись включает в себя порядковый номер сертификата и дату его отзыва. Учитывая, что для отдельно взятого ЦС порядковый номер уникален, для распознавания сертификата его указания достаточно.

Получив сертификат в сообщении, пользователь обязан выяснить, не был ли этот сертификат отозван. Формат списка, необходимый при отзыве сертификата, приведен на рис. 3.43.

Рис. 3.43. Формат списка отозванных сертификатов

3.12.4. Процедуры аутентификации

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

Одношаговая аутентификация предполагает передачу одного сообщения от А к В, которое устанавливает следующее:

• аутентичность А;
• аутентичность сообщения, иначе говоря, то, что сообщение было создано А;
• что сообщение предназначено В;
• целостность сообщения;
• оригинальность сообщения, иначе говоря, что оно не посылается второй раз.

Двухшаговая аутентификация предполагает передачу двух сообщений (от А к В и обратно) и помимо пяти вышеперечисленных фактов гарантирует следующее:

• аутентичность В;
• аутентичность ответа В;
• что ответ предназначен А;
• целостность ответа;
• оригинальность ответа.

3.12.5. Версия 3 стандарта Х.509

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

Можно выделить три категории расширений:

• информация о ключах и политике сертификации;
• субъект сертификации и атрибуты ЦС;
• ограничения маршрута сертификации.

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

Область включает в себя следующие поля.

1. Идентификатор ключа ЦС. Позволяет различать разные ключи одного ЦС. Используется при обновлении пары ключей ЦС.
2. Идентификатор ключа субъекта. Позволяет пользователю иметь несколько ключей (и соответственно несколько сертификатов) для различных целей (например, для подписи и для шифрования). Полезно при обновлении пар ключей субъекта.
3. Ограничения на использование сертифицированного открытого ключа. Возможные варианты: электронная подпись, невозможность отказа от авторства, шифрование ключей, шифрование данных, соглашения о ключах, проверка подписи ЦС в сертификатах, проверка подписи ЦС в CRL.
4. Срок использования секретного ключа. Поле необходимо, учитывая, что во многих случаях срок действия секретного ключа меньше срока действия соответствующего открытого ключа, например в случае ключей соответственно для формирования и проверки подписи.
5. Политика сертификации. Поле предполагает наличие списка политик, распознаваемых данным сертификатом, а также дополнительную уточняющую информацию.
6. Отображение политик. Используется только в сертификатах ЦС, выданных другими ЦС. Позволяет ЦС выяснить, является одна или несколько таких политик эквивалентными другой политике, используемой в домене ЦС, выступающего в качестве субъекта сертификации.

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

Область включает в себя следующие поля.

1. Альтернативное имя субъекта. Содержит одно или несколько альтернативных имен в любой из множества допустимых форм. Необходимо для приложений, которые могут поддерживать свои собственные форматы имен (например, электронной почты).
2. Альтернативное имя ЦС. Содержит одно или несколько альтернативных имен в любой из множества допустимых форм.
3. Атрибуты каталога субъекта. Содержит значения любых атрибутов каталога Х.500, необходимых субъекту данного сертификата.
4. Ограничения маршрута сертификации. В сертификатах, выдаваемых ЦС другим ЦС, могут указываться ограничения на типы выдаваемых сертификатов, ограничения на дальнейшие действия в цепочке сертификатов.

Область включает в себя следующие поля.

1. Основные ограничения. Указывает на то, может ли субъект выступать в качестве ЦС. Если да, то могут быть заданы ограничения на длину маршрута сертификации.
2. Ограничения имен. Указывает рамки, в которых должны находиться имена субъектов в последующих сертификатах маршрута.
3. Ограничения политик. Задает ограничения, которые может требовать явно указанная политика сертификации.

3.13. Вероятностное шифрование

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

Схема одного из возможных вариантов вероятностного блочного шифрования в режиме ECB показана на рис. 3.44, где на вход функции зашифрования E поступает "расширенный" блок  полученный в результате конкатенации блока открытого текста и двоичного набора той же разрядности с выхода генератора ПСП.

Рис. 3.44. Пример вероятностного шифрования. E и D - функции за- и расшифрования симметричной или асимметричной криптосистемы

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

Можно выделить следующие достоинства вероятностного шифра:

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

Недостаток у рассматриваемой схемы лишь один - шифротекст всегда длиннее соответствующего ему открытого текста.

3.14. Причины ненадежности криптосистем

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

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

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

• человеческий фактор;
• особенности реализации.

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

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

Получают распространение атаки типа отказ в обслуживании (denial of service), провоцирующие пользователя отключать "заедающую" систему защиты при решении неотложных задач.

Можно выделить следующие причины ненадежности криптосистем, связанные с особенностями их реализации:

• применение нестойких криптоалгоритмов;
• неправильное применение криптоалгоритмов;
• ошибки в реализации криптоалгоритмов.

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

Многие качественные криптографические средства подпадают под действие экспортных ограничений, искусственно снижающих качество этих средств. Например, в США запрещен экспорт криптоалгоритмов с длиной ключа более 56 бит. Все программные средства, произведенные в США и легально экспортируемые за рубеж, обеспечивают ослабленную криптографическую защиту. Аналогичная ситуация имеет место и в Европе. Так, например, существуют две версии алгоритма поточного шифрования А5 (стандарт GSM) - надежная А5/1 и существенно менее стойкая А5/2 для поставок в развивающиеся страны.

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

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

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

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

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

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

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

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

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

РПВ могут выполнять одно или несколько из перечисленных действий, опасных для системы защиты:

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

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

• средства, препятствующие внедрению, и средства выявления РПВ до использования программных продуктов по назначению;
• средства, обеспечивающие оперативное обнаружение РПВ в процессе реального функционирования ПО, изначально свободного от них;
• средства удаления РПВ;
• средства определения факта наличия или отсутствия РПВ в добавляемом в систему ПО.

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

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

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

1. Поиск по таблицам - неуязвим для временных атак.
2. Фиксированные сдвиги - неуязвимы для временных атак.
3. Булевы операции - неуязвимы для временных атак.
4. Сложение/вычитание - трудно защитить от временных атак.
5. Умножение/деление - наиболее уязвимые для временных атак операции.

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

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

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

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

К моменту выхода этого курса в большинстве существующих систем обеспечения безопасности произойдет замена криптоалгоритмов с секретным и открытым ключом на лучшие на сегодняшний день - соответственно AES и ECCS, которые были описаны в данной главе. Поэтому в последующих главах везде, где будет идти речь об алгоритмах блочного шифрования DES, Triple DES (3DES) и других, следует учитывать скорее всего уже свершившийся переход к AES; везде, где речь идет об алгоритме открытого шифрования RSA, следует учитывать скорее всего уже свершившийся переход к ECCS.