В некоторых приложениях может потребоваться контролировать процесс использования сеансового ключа . Некоторым пользователям сеансовые ключи нужны только для шифрования или только для дешифрирования . Сеансовые ключи могут быть разрешены к использованию только на определенной машине или только в опр е-деленное время. По одной из схем управления подобными ограничениями к ключу добавляется вектор контроля(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. - "Наш девиз - Мы тебе не скажем." Как примерный служащий корпорации она в соответствии с инструкциями по безопасности шифрует все свои данные . К несчастью, она, проигнорировав инструкции по переходу улицы, попала под грузовик . Что делать президенту компании Бобу?
Если Алиса не оставила копии своего ключа, ему придется несладко. Весь смысл шифрования файлов - в невозможности восстановить их без ключа. Если Алиса не была дурой и не использовала плохих шифровальных программ, то ее файлы пропали навсегда.
У Боба есть несколько способов избежать этого. Простейший иногда называют условным вручением клю-
чей(см. раздел 4.14). Он требует, чтобы все сотрудники записали свои ключи на бумажках отдали их начальнику службы безопасности компании, который запрет их где-нибудь в сейф (или зашифрует их главным ключом). Теперь, чтобы не случилось с Алисой, Боб узнает ее ключ у начальника службы безопасности. Еще одну копию Боб также должен хранить в своем сейфе, в противном случае, если начальник службы безопасн о-сти попадет под другой грузовик, Бобу снова не повезет.
Проблема такой системы управления ключами в том, что Боб должен верить, что его начальник службы безопасности не воспользуется чужими ключами. Что еще серьезнее, все сотрудники должны верить, что начальник службы безопасности не воспользуется их ключами . Существенно лучшим решением является использование протокола совместного использования секрета (см. раздел 3.7).
Когда Алиса генерирует ключ, она одновременно делит ключ не несколько частей и затем посылает все ча с-ти - зашифрованные, конечно - различным должностным лицам компании . Ни одна из этих частей сама по себе не является ключом, но все эти части можно собрать вместе и восстановить ключ . Теперь Алиса защищена от злоумышленников, а Боб - от потери всех данных Алисы после ее попадания под грузовик . Или, она может просто хранить разные части, зашифрованные открытыми ключами соответствующих должностных лиц компании, на своем жестком диске. Таким образом, никто не участвует в управлении ключами, пока это не станет необх о-димым.
Другая схема резервирования [188] использует для временного условного вручения ключей интеллектуальные карточки (см. раздел 24.13). Алиса может поместить ключ, которым закрыт ее жесткий диск, на интелле к-туальную карточку и выдать ее Бобу, пока она в отъезде. Боб может использовать карточку для доступа к жесткому диску Алисы, но, так как ключ хранится на карточке, Боб не сможет его узнать . Кроме того, такая система контролируема с обеих сторон: Боб может проверить, что ключ открывает диск Алисы, а когда Алиса вернется, она сможет проверить, использовал ли Боб раз этот ключ, и если да, то сколько раз .
В подобной схеме не нужна передача данных. Для безопасного телефона ключ должен существовать только в течение разговора и не дольше. Для хранилищ данных, как было показано, условное вручение ключей может быть неплохой идеей. Я теряю ключи примерно раз в пять лет, а моя память получше, чем у многих . Если бы 200 миллионов человек пользовались криптографией, подобная частота привела бы к потере 40 миллионов ключей ежегодно. Я храню копии ключей от моего дома у соседа, потому что я могу потерять свои ключи . Если бы ключи от дома были подобны криптографическим ключам, то, потеряв их, я никогда не смог бы попасть внутрь и вступить в свои права владения. Также, как я храню где-то в другом месте копии своих данных, мне имеет смысл хранить и резервные копии моих ключей шифрования .
8.9 Скомпрометированные ключи
Все протоколы, методы и алгоритмы этой книги безопасны только, если ключ (закрытый ключ в системе с открытыми ключами) остается в тайне. Если ключ Алисы украден, потерян, напечатан в газете или скомпром е-тирован иным способом, то все ее безопасность исчезнет.
Если скомпрометированный ключ использовался для симметричной криптосистемы, Алисе придется изм е-нить свой ключ и надеяться, что случившийся ущерб минимален . Если это закрытый ключ, ее проблемы намного больше, так как ее открытый ключ может храниться на многих серверах в сети. И если Ева получит доступ к закрытому ключу Алисы, она сможет выдать себя за нее в этой сети : читать шифрованную почту, подписывать корреспонденцию и контракты, и так далее. Ева действительно сможет стать Алисой.
Жизненно необходимо, чтобы известие о компрометации закрытого ключа быстро распространилось бы по сети. Нужно немедленно известить все базы данных открытых ключей о случившейся компрометации, чтобы ничего не подозревающий человек не зашифровал сообщение скомпрометированным ключом .
Хорошо, если Алиса знает, когда был скомпрометирован ее ключ . Если ключ распределяет KDC, то Алиса должна сообщить ему о компрометации своего ключа. Если KDC не используется, то ей следует известить всех корреспондентов, которые могут получать от нее сообщения. Кто-то должен опубликовать тот факт, что любое сообщение, полученное после потери ключа Алисой, является подозрительным, и что никто не должен посылать сообщения Алисе, используя соответствующий открытый ключ. Рекомендуется, чтобы программное обеспечение использовало какие-нибудь метки времени, тогда пользователи смогут определить, какие сообщения зако н-ны, а какие подозрительны.
Если Алиса не знает точно, когда ее ключ был скомпрометирован, то дело хуже . Алиса может захотеть отказаться от контракта, так как он подписан вместо нее человеком, укравшим у нее ключ . Если система дает такую возможность, то кто угодно сможет отказаться от контракта, утверждая, что его ключ был скомпрометирован перед подписанием. Вопрос должен быть решен арбитром.
Это серьезная проблема показывает, как опасно для Алисы связывать свою личность с единственным кл ю-чом. Лучше, чтобы у Алисы были различные ключи для различных приложений - точно также, как она держит в
своем кармане физические ключи для различных замков . Другие решения этой проблемы включают биометрические измерения, ограничения возможностей использования ключа, задержки времени и вторая подпись .
Эти процедуры и рекомендации наверняка не оптимальны, но это лучшее, что мы можем посоветовать . Мораль - защищайте ключи, и сильнее всего защищайте закрытые ключи .
8.10 Время жизни ключей
Ни один ключ шифрования нельзя использовать бесконечно . Время его действия должно истекать автоматически, подробно паспортам и лицензиям. Вот несколько причин этого:
— Чем дольше используется ключ, тем больше вероятность его компрометации . Люди записывают ключи и теряют их. Происходят несчастные случаи. Если вы используете ключ в течение года, то вероятность его компрометации гораздо выше, чем если бы вы использовали его только один день .
— Чем дольше используется ключ, тем больше потери при компрометации ключа . Если ключ используется только для шифрования одного финансового документа на файл-сервере , то потеря ключа означает компрометацию только этого документа. Если тот же самый ключ используется для шифрования всей фина н-совой информации на файл-сервере, то его потеря гораздо более разрушительна.
— Чем дольше используется ключ, тем больше соблазн приложить необходимые усилия для его вскрытия -даже грубой силой. Вскрытие ключа, используемого в течение дня для связи между двумя воинскими подразделениями, позволит читать сообщения, которыми обмениваются подразделения, и создавать по д-дельные. Вскрытие ключа, используемого в течение года всей военной командной структурой, позволило бы взломщику в течение года читать все сообщения, циркулирующие в этой системе по всему миру, и подделывать их. В нашем мире закончившейся холодный войны какой ключ выбрали бы для вскрытия вы?
— Обычно намного легче проводить криптоанализ, имея много шифротекстов, шифрованных одним и тем же ключом.
Для любого криптографического приложения необходима стратегия, определяющая допустимое время жи з-ни ключа. У различных ключей могут быть различные времена жизни . Для систем с установлением соединения, таких как телефон, имеет смысл использовать ключ только в течение телефонного разговора, а для нового ра з-говора - использовать новый ключ.
Для систем, использующих специализированные каналы связи, все не так очевидно . У ключей должно быть относительно короткое время жизни, в зависимости от значимости данных и количества данных, зашифрова н-ных в течение заданного периода. Ключ для канала связи со скоростью передачи 1 Гигабит в секунду возможно придется менять гораздо чаще, чем для модемного канала 9600 бит/с. Если существует эффективный метод передачи новых ключей, сеансовые ключи должны меняться хотя бы ежедневно .
Ключи шифрования ключей так часто менять не нужно. Они используются редко (приблизительно раз в день) для обмена ключами. При этом шифротекста для криптоаналитика образуется немного, а у соответству тощего открытого текста нет определенной формы. Однако, если ключ шифрования ключей скомпрометирован, потенциальные потери чрезвычайны: вся информация, зашифрованная ключами, зашифрованными ключом шифрования ключей. В некоторых приложениях ключи шифрования ключей заменяются только раз в месяц или даже раз в год. Вам придется как-то уравновесить опасность, связанную с использованием одного и того же ключа, и опасность, связанную с передачей нового ключа.
Ключи шифрования, используемые при шифровании файлов данных для длительного хранения, нельзя м е-нять часто. Файлы могут храниться на диске зашифрованными месяцами или годами, прежде чем они кому-нибудь снова понадобятся. Ежедневное дешифрирование и повторное шифрование новым ключом никак не п о-высит безопасность, просто криптоаналитик получит больше материала для работы. Решением может послужить шифрование каждого файла уникальным ключом и последующее шифрование ключей файлов ключом шифрования ключей. Ключ шифрования ключей должен быть либо запомнен, либо сохранен в безопасном ме с-те, может быть где-нибудь в сейфе. Конечно же, потеря этого ключа означает потерю всех индивидуальных файловых ключей.
Время жизни закрытых ключей для приложений криптографии с открытыми ключами зависит от прилож е-ния. Закрытые ключи для цифровых подписей и идентификации могут использоваться годами (даже в течение человеческой жизни). Закрытые ключи для протоколов бросания монеты могут быть уничтожены сразу же п о-сле завершения протокола. Даже если считается, что время безопасности ключа примерно равно человеческой жизни, благоразумнее менять ключ каждую пару лет. Во многих четях закрытые ключи используются только два года, затем пользователь должен получить новый закрытый ключ . Старый ключ, тем не менее, должен храниться в секрете на случай, когда пользователю будет нужно подтвердить подпись, сделанную во время дейс т-вия старого ключа. Но для подписания новых документов должен использоваться новый ключ. Такая схема п о-
зволит уменьшить количество документов, которое криптоаналитик сможет использовать для вскрытия
8.11 Разрушение ключей
Принимая во внимание, что ключи должны регулярно меняться, старые ключи необходимо уничтожать. Старые ключи имеют определенное значение, даже если они никогда больше не используются. С их помощью враг сможет прочитать старые сообщения, зашифрованные этими ключами [65].
Ключи должны уничтожаться надежно (см. раздел 10.9). Если ключ записан на бумажке, бумажку нужно разрезать и сжечь. Пользуйтесь качественными уничтожителями бумаги, рынок заполнен дефектными устро й-ствами. Алгоритмы, описанные в этой книге, надежно противостоят вскрытию грубой силой, стоящему милли о-ны долларов и требующему миллионов лет. Если враг сможет раскрыть ваш ключ, добыв плохо измельченные документы из вашего мусорника и наняв сотню безработных в какой-нибудь отсталой стране за 10 центов в час склеивать вместе кусочки разрезанных страниц, он выгодно вложит пару десятков тысяч долларов .
Если ключ - это микросхема EEPROM, то ключ необходимо переписать несколько раз. Если ключ - это микросхема EPROM или PROM, то она должна быть стерта в порошок и развеяна во все стороны. Если ключ хранится на диске компьютера, действительные биты соответствующего участка памяти должны быть переписаны несколько раз (см. раздел 10.9) или диск должен быть уничтожен.
Возможная проблема состоит в том, что в компьютере ключи могут быть легко скопированы и сохранены во множестве мест. Любой компьютер, реализующий какую-либо схему управления памятью, постоянно выгруж а-ет программы из памяти и загружает их обратно, усугубляя проблему. Способа гарантировать надежное уничтожение ключа в компьютере не существует, особенно когда процесс уничтожения контролируется операцио н-ной системой компьютера. Самым озабоченным необходимо использовать специальную программу, которая на физическом уровне искала бы на диске копию ключа даже в неиспользуемых блоках и затем стирала бы соо т-ветствующие блоки. Не забывайте также стирать все временных файлов .
8.12 Управление открытыми ключами
Криптография с открытыми ключами упрощает управление ключами, но у нее есть свои собственные пр о-блемы. У каждого абонента, независимо от числа людей в сети, есть только один открытый ключ . Если Алиса захочет отправить Бобу сообщение, ей придется где-то найти открытый ключ Боба. Она может действовать несколькими способами:
— Получить ключ от Боба.
— Получить его из централизованной базы данных.
— Получить его из своей личной базы данных.
В разделе 2.5 обсуждаются возможные способы вскрытия криптографии с открытыми ключами , основанных на подмене ключа Боба ключом Мэллори. Используется следующий сценарий: пусть Алиса хочет послать сообщение Бобу. Она обращается к базе данных открытых ключей и получает открытый ключ Боба . Но подлый Мэллори подменяет ключ Боба своим собственным. (Если Алиса запрашивает ключ непосредственно у Боба, Мэллори для успешной подмены придется перехватить ключ Боба при передаче .) Алиса шифрует сообщение ключом Мэллори и отправляет его Бобу. Мэллори перехватывает сообщение, расшифровывает и читает его . Затем шифрует открытым ключом Боба и отправляет по назначению. Ни Боб, ни Алиса ни о чем не догадыв а-ются.