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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обнаружение ошибок при передаче ключей

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

Одним из наиболее широко используемых методов является шифрование ключом некоторой постоянной в е-личины и передача первых 2-4 байт этого шифротекста вместе с ключом. У получателя делается то же самое. Если шифрованные константы совпадают, то ключ был передан без ошибки. Вероятность ошибки находится в диапазоне от 1/216 до 1/232.

Обнаружение ошибок при дешифрировании

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

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

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

Вот для этого способ получше [821]:

(1) Сгенерите вектор идентификации (отличный от используемого в сообщении).

(2) Используйте этот вектор идентификации для генерации большого блока битов: скажем, 512.

(3) Хэшируйте результат.

(4) Используйте те же фиксированные биты хэш-значения, скажем, 32, для контрольной суммы ключа .

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

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

8.5 Использование ключей

Программное шифрование рискованно . Ушли те дни, когда простые микрокомпьютеры работали под упра в-лением единственной программы. Сегодня время Macintosh System 7, Windows NT и UNIX. Невозможно сказать, когда операционная система остановит работающую программу шифрования , запишет все на диск и разрешит выполняться какой-то другой задаче . Когда операционная система, наконец, вернется к шифрованию, чтобы там не шифровалось, картинка может оказаться весьма забавной. Операционная система записала пр о-грамму шифрования на диск, и ключ записан вместе с ней. Ключ, незашифрованный, будет лежать на диске, пока компьютер не напишет что-нибудь в эту же область памяти поверх . Это может случиться через несколько минут, а может через несколько месяцев. Этого может и никогда не случиться, но ключ все же может оказаться на диске в тот момент, когда жесткий диск густо прочесывается вашим противником . В приоритетной, многозадачной среде, для шифрования можно установить достаточно высокий приоритет, чтобы эта операция не пр е-рывалась. Это снизило бы риск. Даже при этом система в целом в лучшем случае ненадежна.

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

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

Контроль использования ключей

В некоторых приложениях может потребоваться контролировать процесс использования сеансового ключа . Некоторым пользователям сеансовые ключи нужны только для шифрования или только для дешифрирования . Сеансовые ключи могут быть разрешены к использованию только на определенной машине или только в опр е-деленное время. По одной из схем управления подобными ограничениями к ключу добавляется вектор контроля (Control Vector, CV), вектор контроля определяет для этого ключа ограничения его использования (см. раздел 24.1) [1025, 1026]. Этот CV хэшируется, а затем для него и главного ключа выполняется операция XOR. Результат используется как ключ шифрования для шифрования сеансового ключа . Полученный сеансовый ключ затем хранится вместе с CV. Для восстановления сеансового ключа нужно хэшировать CV и выполнить для него и главного ключа операцию XOR. Полученный результат используется для дешифрирования шифрованн ого сеансового ключа.

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