Рабочая группа сети S. Bellovin
Запрос комментариев: 4107 Columbia University
BCP: 107 R. Housley
Категория: Лучшая современная практика Vigil Security
Июнь 2005
Руководство по управлению криптографическими ключами
Статус данного меморандума
Этот документ определяет Лучшую современную практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение этого меморандума не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (2005).
Аннотация
Часто возникает вопрос, требует ли данная система безопасности
некоторой формы автоматизированного управления ключами или достаточно
ручного управления ключами. Этот меморандум содержит руководство для
принятия таких решений. Когда в протоколе используются симметричные
криптографические механизмы, предполагается, что автоматизированное
управление ключами обычно, но не всегда необходимо. Если предлагается
ручное управление ключами, бремя доказательства того, что
автоматизированное управление ключами не требуется, ложится на
предлагающего.
1. Введение
Часто возникает вопрос, требует ли данная система безопасности
некоторой формы автоматизированного управления ключами или достаточно
ручного управления ключами.
На этот вопрос нет единственного ответа; обстоятельства различаются.
В общем случае следует (SHOULD) использовать автоматизированное
управление ключами. Иногда полагаться на ручное управление ключами
разумно; мы предлагаем некоторое руководство для вынесения такого
суждения.
С другой стороны, опора на ручное управление ключами имеет
существенные недостатки, и мы излагаем соображения безопасности,
обосновывающие предпочтение автоматизированного управления ключами.
Однако существуют ситуации, в которых ручное управление ключами
приемлемо.
1.1. Терминология
Ключевые слова ДОЛЖЕН (MUST), НЕ ДОЛЖЕН (MUST NOT), ДОЛЖЕН (REQUIRED),
ДОЛЖЕН (SHALL), НЕ ДОЛЖЕН (SHALL NOT), СЛЕДУЕТ (SHOULD), НЕ СЛЕДУЕТ
(SHOULD NOT), СЛЕДУЕТ (RECOMMENDED), МОЖЕТ (MAY) и НЕОБЯЗАТЕЛЬНО
(OPTIONAL) при их появлении в этом документе подлежат толкованию,
описанному в RFC 2119 [B].
2. Руководство
Это руководство предназначено для использования рабочими группами
IETF и авторами протоколов, определяющими, следует ли предписывать
автоматизированное управление ключами и приемлемо ли ручное управление
ключами. Требуется осведомлённое суждение.
Термин «управление ключами» относится к установлению криптографического
ключевого материала для использования с криптографическим алгоритмом
с целью предоставления служб безопасности протокола, особенно
целостности, аутентификации и конфиденциальности. Автоматизированное
управление ключами выводит один или несколько краткосрочных сеансовых
ключей. Функция вывода ключей может использовать долгосрочные ключи
для включения аутентификации в этот процесс. Способ распределения этого
долгосрочного ключа между сторонами взаимодействия и тип используемого
ключа (предварительно распределённое симметричное секретное значение,
открытый ключ RSA, открытый ключ DSA и другие) выходят за рамки данного
документа. Однако это является частью общего решения по управлению
ключами. Для распространения таких значений используется ручное
управление ключами. Ручное управление ключами также может
использоваться для распространения долгосрочных сеансовых ключей.
Автоматизированное и ручное управление ключами предоставляют весьма
разные возможности. В частности, протокол, связанный с методом
автоматизированного управления ключами, подтвердит активность стороны
взаимодействия, защитит от воспроизведения, аутентифицирует источник
краткосрочного сеансового ключа, свяжет информацию о состоянии
протокола с краткосрочным сеансовым ключом и обеспечит создание нового
краткосрочного сеансового ключа. Кроме того, протокол
автоматизированного управления ключами может улучшить взаимодействие,
включая механизмы согласования криптографических алгоритмов. Эти ценные
возможности невозможно или чрезвычайно обременительно реализовать с
помощью ручного управления ключами.
Для некоторых симметричных криптографических алгоритмов реализации
должны предотвращать чрезмерное использование данного ключа. Реализация
таких алгоритмов может использовать автоматизированное управление
ключами, когда пределы использования почти исчерпаны, чтобы установить
заменяющие ключи до достижения пределов, тем самым сохраняя безопасную
связь.
Примеры систем автоматизированного управления ключами включают IPsec
IKE и Kerberos. S/MIME и TLS также включают функции автоматизированного
управления ключами.
Схемы управления ключами не следует разрабатывать любителям; рабочим
группам почти наверняка неуместно разрабатывать собственные схемы. Если
выразить это конкретно, самый первый протокол управления ключами в
открытой литературе был опубликован в 1978 году [NS]. Ошибка и её
исправление были опубликованы в 1981 году [DS], а исправление было
взломано в 1994 году [AN]. В 1995 году [L] в исходной версии 1978 года
была обнаружена новая ошибка в области, не затронутой проблемой
1981/1994 годов. Все эти ошибки были очевидны после их описания, — но
никто не заметил их раньше. Обратите внимание, что исходный протокол
(переведённый на использование сертификатов, которые в то время ещё не
были изобретены) состоял всего из трёх сообщений.
Программное обеспечение управления ключами не всегда велико или
раздуто. Даже IKEv1 [HC] можно реализовать менее чем в 200 Kbytes
объектного кода, а TLS [DA] — в половине этого объёма. Обратите
внимание, что эта оценка для TLS также включает другую функциональность.
Сеансовый ключ используется для защиты полезной нагрузки. Характер
полезной нагрузки зависит от уровня, на котором применяется
симметричная криптография.
В общем случае для установления сеансовых ключей следует (SHOULD)
использовать автоматизированное управление ключами. В разделе
соображений безопасности предложения, использующего ручное управление
ключами, требуется веское обоснование.
2.1. Автоматизированное управление ключами
Автоматизированное управление ключами должно (MUST) использоваться,
если выполняется любое из следующих условий:
Стороне придётся управлять n^2 статическими ключами, где n может
стать большим.
Используется любой потоковый шифр (например, RC4 [TK], AES-CTR
[NIST] или AES-CCM [WHF]).
Вектор инициализации (IV) может быть использован повторно, особенно
неявный IV. Обратите внимание, что случайные или псевдослучайные
явные IV не являются проблемой, если только вероятность повторения
не высока.
Большие объёмы данных могут нуждаться в шифровании за короткое
время, вызывая частую смену краткосрочного сеансового ключа.
Долгосрочные сеансовые ключи используются более чем двумя сторонами.
Многоадресная рассылка является необходимым исключением, но для
предотвращения этого в будущем формируются стандарты управления
ключами многоадресной рассылки. Совместное использование
долгосрочных сеансовых ключей в общем случае следует не поощрять.
Вероятная эксплуатационная среда такова, что смена персонала (или
устройств) происходит часто, вызывая частую смену краткосрочного
сеансового ключа.
2.2. Ручное управление ключами
Ручное управление ключами может быть разумным подходом в любой из
следующих ситуаций:
Среда имеет очень ограниченную доступную полосу пропускания или
очень высокое время кругового обхода. Системы с открытым ключом
обычно требуют длинных сообщений и большого объёма вычислений;
альтернативы на симметричных ключах, такие как Kerberos, часто
требуют нескольких круговых обходов и взаимодействия с третьими
сторонами.
Защищаемая информация имеет низкую ценность.
Общий объём трафика за весь срок существования долгосрочного
сеансового ключа будет очень мал.
Масштаб каждого развёртывания весьма ограничен.
Обратите внимание, что к утверждениям о таких вещах часто следует
относиться скептически. Бремя демонстрации того, что ручное управление
ключами уместно, ложится на сторонников — и это довольно высокий барьер.
Системам, использующим ручное управление ключами, необходимы положения
для смены ключей. Должен (MUST) существовать некоторый способ указать,
какой ключ используется, чтобы избежать проблем при переходе. В проектах
следует (SHOULD) набросать правдоподобные механизмы для развёртывания
новых ключей и замены старых, которые могли быть скомпрометированы.
При хорошем исполнении такие механизмы впоследствии могут быть
использованы схемой управления ключами, добавляемой как дополнение.
Неясность относительно сторон, участвующих в аутентификации, не
является веской причиной избегать управления ключами. Напротив, она
обычно указывает на более глубокую проблему с базовой моделью
безопасности.
2.3. Размер ключа и случайные значения
Руководство по размеру криптографического ключа для открытых ключей,
используемых для обмена симметричными ключами, можно найти в BCP 86
[OH].
Когда используется ручное управление ключами, долгосрочные совместно
используемые секретные значения следует (SHOULD) иметь длину не менее
128 бит.
Руководство по генерации случайных чисел можно найти в BCP 106 [ESC].
Когда используется ручное управление ключами, долгосрочные совместно
используемые секреты должны (MUST) быть непредсказуемыми «случайными»
значениями, обеспечивая, что ожидаемая вероятность нахождения значения
противником после перебора половины пространства поиска ключа будет не
более 50%.
3. Соображения безопасности
Этот документ содержит руководство для рабочих групп и разработчиков
протоколов. Безопасность Интернета повышается при использовании
автоматизированного управления ключами.
Включение автоматизированного управления ключами не означает, что
интерфейс для ручного управления ключами запрещён. Фактически ручное
управление ключами очень полезно для отладки. Поэтому реализации
следует предоставлять интерфейс ручного управления ключами для таких
целей, даже если он не определён протоколом.
4. Ссылки
Этот раздел содержит нормативные и информационные ссылки.
4.1. Нормативные ссылки
[B] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ESC] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[OH] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
April 2004
4.2. Информационные ссылки
[AN] M. Abadi and R. Needham, "Prudent Engineering Practice for
Cryptographic Protocols", Proc. IEEE Computer Society
Symposium on Research in Security and Privacy, May 1994.
[DA] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[DS] D. Denning and G. Sacco. "Timestamps in key distributed
protocols", Communication of the ACM, 24(8):533--535, 1981.
[HC] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[L] G. Lowe. "An attack on the Needham-Schroeder public key
authentication protocol", Information Processing Letters,
56(3):131--136, November 1995.
[NIST] National Institute of Standards and Technology.
"Recommendation for Block Cipher Modes of Operation -- Methods
and Techniques," NIST Special Publication SP 800-38A, December
2001.
[NS] R. Needham and M. Schroeder. "Using encryption for
authentication in large networks of computers", Communications
of the ACM, 21(12), December 1978.
[TK] Thayer, R. and K. Kaukonen. "A Stream Cipher Encryption
Algorithm", Work in Progress.
[WHF] Whiting, D., Housley, R., and N. Ferguson , "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003.
Адреса авторов
Steven M. Bellovin
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, M.C. 0401
New York, NY 10027-7003
Phone: +1 212-939-7149
EMail: bellovin@acm.org
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
Phone: +1 703-435-1775
EMail: housley@vigilsec.com
Полное заявление об авторских правах
Copyright (C) The Internet Society (2005).
Этот документ подпадает под действие прав, лицензий и ограничений,
содержащихся в BCP 78, и, за исключением установленного в нём, авторы
сохраняют все свои права.
Этот документ и содержащаяся в нём информация предоставляются по
принципу «КАК ЕСТЬ», И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА
ПРЕДСТАВЛЯЕТ ИЛИ КОТОРОЙ СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ), INTERNET
SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНО
ВЫРАЖЕННЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО,
ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ
НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, ЛИБО ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ
ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Интеллектуальная собственность
IETF не занимает позиции относительно действительности или объёма
каких-либо прав интеллектуальной собственности или иных прав, которые
могут заявляться как относящиеся к реализации или использованию
технологии, описанной в этом документе, либо относительно того, может
ли быть доступна какая-либо лицензия на основании таких прав; также
она не заявляет, что предпринимала какие-либо независимые усилия по
выявлению любых таких прав. Информацию о процедурах, касающихся прав в
документах RFC, можно найти в BCP 78 и BCP 79.
Копии раскрытий IPR, сделанных Секретариату IETF, и любых заверений о лицензиях, которые будут предоставлены, либо результат попытки получить общую лицензию или разрешение на использование таких прав собственности разработчиками или пользователями данной спецификации можно получить в онлайновом репозитории IPR IETF по адресу
http://www.ietf.org/ipr.
IETF приглашает любую заинтересованную сторону довести до сведения IETF любые авторские права, патенты или заявки на патенты либо иные права собственности, которые могут распространяться на технологию, которая может потребоваться для реализации данного стандарта. Просьба направлять эту информацию в IETF по адресу ietf-
ipr@ietf.org.
Благодарность
Финансирование функции RFC Editor в настоящее время предоставляется
Internet Society.