обменяться ключами, общее число обменов ключами в сети из 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.

8.6 Обновление ключей

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

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

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

8.7 Хранение ключей

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

Примером такой системы является IPS [881]. Пользователи могут либо вводить 64-битовый ключ непосре д-ственно, либо ввести ключ как более длинную символьную строку . В последнем случае система генерирует 64-битовый ключ по строке символов, используя технику перемалывания ключа .

Другим решением является хранить ключ в виде карточки с магнитной полоской, пластикового ключа с встроенной микросхемой ROM (называемого ROM-ключ) или интеллектуальной карточки [556, 557, 455]. Пользователь может ввести свой ключ в систему, вставив физический носитель в считывающее устройство, встроенное в его шифрователь или подключенное к компьютерному терминалу. Хотя пользователь может использовать ключ, он не знает его и не может его скомпрометировать . Он может использовать его только тем способом и только для тех целей, которые определены вектором контроля.

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

Эта техника становится более безопасной при разбиении ключа на две половины, одна из которых хранится в терминале, а вторая - в ROM-ключе. Так работает безопасный телефон STU-III правительства США. Потеря ROM-ключа не компрометирует криптографический ключ - замените этот ключ и все снова станет нормально . То же происходит и при потере терминала. Следовательно, компрометация ROM-ключа или системы не компрометирует криптографический ключ key - врагу нужно заполучить обе части.

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

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

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

8.8 Резервные ключи

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

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

У Боба есть несколько способов избежать этого. Простейший иногда называют условным вручением клю-