Генерация ключей в министерстве обороны США

Министерство обороны США для генерации случайных ключей рекомендует использовать DES в режиме OFB (см. раздел 9.8) [1144]. Создавайте ключи DES, используя системные вектора прерывания, регистры со­стояния системы и системные счетчики. Создавайте вектор инициализации, используя системные часы, идент и-фикатор системы, с также дату и время. Для открытого текста используйте 64-битовые величины, созданные кем-то другим, например, 8 символов, введенных системным администратором. Используйте в качестве своего ключа результат.

8.2 Нелинейные пространства ключей

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

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

Получившееся пространство ключей называется нелинейным, потому что ключи не являются одинаково сильными. (Противоположным является линейное, или плоское, пространство ключей.) Простым способом д о-биться этого можно, создавая ключ, состоящий из двух частей: непосредственно ключа и некоторой фиксир о-ванной строки, шифрованной этим ключом. Модуль расшифровывает строку, используя ключ. Если результ а-том оказывается фиксированная строка, то ключ используется как обычно, если нет, то используется другой, слабый алгоритм. Если алгоритм имеет 128-битовый ключ и 64-битовый размер блока, то длина полного ключа - 192 бита. Таким образом, у алгоритма 2¹²⁸ эффективных ключа, но вероятность случайно выбрать правильный составляет один шанс из 2⁶⁴.

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

Это работает только, если используется секретный алгоритм, который враг не может перепроектировать, или если различие в силе ключей достаточно тонко, чтобы враг не смог о нем догадаться. NSA проделывало это с секретными алгоритмами в своих модулях Overtake (см. раздел 25.1). Делали ли они то же самое с Skipjack (см. раздел 13.12)? Неизвестно.

8.3 Передача ключей

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

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

Стандарт Х9.17 [55] определяет два типа ключей: ключи шифрования ключей и ключи данных. Ключа­ми шифрования ключей при распределении шифруются другие ключи. Ключи данных шифруют сами сообщ е-ния. Ключи шифрования ключей должны распределяться вручную, (хотя они могут быть в безопасности в з а-щищенном от взлома устройстве, таком как кредитная карточка), но достаточно редко. Ключи данных распр е-деляются гораздо чаще. Подробности можно найти в [75]. Эта идей двухсвязных ключей часто используется при распределении ключей.

Другим решением проблемы распределения является разбиение ключа на несколько различных частей (см. раздел 3.6) и передача их по различным каналам. Одна часть может быть послана телефоном, другая - почтой, третья - службой ночной доставки, четвертая - почтовым голубем, и так далее, (см. 6-й). Так противник может собрать все части, кроме одной, и все равно ничего не узнает про ключ. Этот метод будет работать во всех ел у-чаях, кроме крайних. В разделе 3.6 обсуждаются схемы разбиения ключа на несколько частей. Алиса могла бы даже применить схему совместно используемого секрета, (см. раздел 3.7), что даст возможность Бобу восст а-навливать ключ, если некоторые из частей потеряны при перед аче.

ОТПРАВИТЕЛЬ Делит ключ на части

ПОЛУЧАТЕЛЬ Восстанавливает ключ

Телефон Почтовый голубь

Ki

Кг

Кз

к₄

к₅

к2

к5

Рис. 8-2. Распределение ключей по параллельным каналам.

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

Распределение ключей в больших сетях

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

обменяться ключами, общее число обменов ключами в сети из п человек равно п(п -1)/2.

В сети с шестью пользователями потребуется 15 обменов ключами. В сети из 1000 пользователей понадо­бится уже около 500000 обменов ключами. В этих случаях работа сети гораздо более эффективна при использ о-вании центрального сервера (или серверов) ключей.

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

8.4 Проверка ключей

Как Боб узнает, получив ключ, что ключ передан Алисой, а не кем-то другим, кто выдает себя за Алису? Все просто, если Алиса передает ему ключ при личной встрече. Если Алиса посылает свой ключ через доверенного курьера, то курьеру должен доверять и Боб. Если ключ зашифрован ключом шифрования ключей, то Боб должен доверять тому, что этот ключ шифрования ключей есть только у Алисы. Если для подписи ключа Алиса испол ь-зует протокол электронной подписи, Боб при проверке подписи должен доверять базе данных открытых кл ю-чей,. (Ему также придется считать, что Алиса сохранила свой ключ в безопасности.) Если Центр распределения ключей (Key Distribution Center, KDC) подписывает открытый ключ Алисы, Боб должен считать, что его копия открытого ключа KDC не была подменена.

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

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

Эта точка зрения наивна. Теоретически все правильно, но действительность гораздо сложнее. Криптография с открытыми ключами, используемая вместе с электронными подписями и надежными KDC, сильно усложняет подмену одним ключом другого. Боб никогда не может быть абсолютно уверен, что Мэллори не контролирует его реальность полностью, но Боб может знать наверняка, что такая подмена реальности потребует гораздо больше ресурсов, чем сможет заполучить реальный Мэллори.

Боб мог бы также проверять ключ Алисы по телефону, получив возможность услышать ее голос. Распозн а-вание голоса действительно является хорошей схемой идентификации личности. Если речь идет об открытом ключе, он может безопасно его повторить его даже при угрозе подслушивания. Если это секретный ключ, он может использовать для проверки ключа одностороннюю хэш-функцию. Оба TSD PGP (см. раздел 24.12.) и АТ$Т (см. Раздел 24.18) используют этот способ пр оверки ключей.

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