Криптография 2е издание Протоколы, алгоритмы и исходные тексты на языке С
 Скачать 3.25 Mb.
|
|
7.5 Каков должны быть длина ключа? На этот вопрос нет единого ответа, ответ этот зависит от ситуации . Чтобы понять, какая степень безопасно- сти вам нужна, вы должны задать себе несколько вопросов . Сколько стоит ваша информация? Как долго она должна безопасно храниться? Каковы ресурсы ваших врагов? Список клиентов может стоить $1000. Финансовая информация при неожиданном разводе могла бы стоить $10000. Реклама и данные маркетинга для большой корпорации могли бы стоить 1 миллион долларов . Главный ключ для системы электронных наличных может стоить миллиарды . В мире торговли предметами потребления секреты должны только сохраняться в течение нескольких минут. В газетном бизнесе сегодняшние секреты - это завтрашние заголовки. Информация о разработке какого-то пр о- дукта, возможно, должна будет храниться в секрете в течение года или двух Изделия(программы) могла бы была бы должна остаться секретом в течение года или два. Данные переписи США в соответствии с законом должны храниться в секрете в течение 100 лет. Список гостей, приглашенных на вечер-сюрприз в честь дня рождения вашей сестры, интересен только в а- шим любопытным родственникам. Торговые секреты корпорации представляют интерес для конкурирующих компаний. Военные секреты интересны вражеским военным. В этих терминах даже можно определить требования к безопасности Можно . Например: Длина ключа должна быть такой, чтобы взломщик, готовый потратить 100 миллионов долларов, мог взломать систему в течение года с вероятностью не более, чем 1/2 32 , даже с учетом скорости технического прогресса 30 процентов в год. В -3-й, частично взятой из [150], приведены оценки требований к безопасности для различной информ ации: Будущую вычислительную мощь оценить нелегко, но вот разумное эмпирическое правило : эффективность вычислительных средств удваивается каждые 18 месяцев и возрастает на порядок каждые 5 лет . Следовательно, через 50 лет самые быстрые компьютеры будут в 10 миллиардов быстрее, чем сегодня ! Кроме того, не забывай- те, что эти числа относятся только к универсальным компьютерам, кто знает, какие специализированные ус т- ройства для вскрытия криптосистем будут разработаны в следующие 50 лет ? Предполагая, что криптографический алгоритм будет использоваться в ближайшие 30 лет, вы можете пре д- ставить себе, насколько он должен быть безопасен . Алгоритм, созданный сегодня, возможно не станет широко использоваться до 2000 года, и все еще будет использоваться в 2025 для шифрования сообщений, которые должны оставаться в секрете до 2075 года и позже. Табл. 7-10. Требования к безопасности различной информации Типы трафика Время жизни Минимальная дли- на ключа (в битах) Тактическая военная информация минуты/часы 56-64 Объявления о продуктах, слиянии компаний, процен т- ных ставках дни/недели 64 Долговременны бизнес-планы годы 64 Торговые секреты (например, рецепт кока-колы) десятилетия 112 Секреты водородной бомбы >40 лет 128 Личности шпионов >50 лет 128 Личные дела >50 лет 128 Дипломатические конфликты >65 лет 128 Данные переписи США 100 лет по меньшей мере 128 7.6 Caveat emptor 1 Вся эта глава - просто много чепухи. This entire chapter is a whole lot of nonsense. Смешно говорить даже о самом понятии предсказания вычислительной мощи на 10, а тем более на 50 лет вперед . Эти расчеты приведе- ны только для ориентировки, ни для чего больше . Экстраполируя прошлое, мы получаем будущее, которое, возможно, будет иметь мало общего с грядущей реальностью . Будьте консерваторами. Если ваши ключи длиннее, чем вам кажется необходимым, то меньшее количество технологических сюрпризов сможет повредить вам. 1 Да будет осмотрителен покупатель (латин.) Глава 8 Управление ключами У Алисы и Боба есть безопасная система связи. Они играют в мысленный покер, одновременно подписыв а- ют контракты и даже меняют цифровые наличные. Их протоколы безопасны. Их алгоритмы -самые лучшие. К несчастью, они покупают свои ключи от "Keys-R-Us" Евы, чей лозунг - "Вы можете доверять нам: Безопасность - среднее имя человека, которого туристический агент нашей бывшей тещи встретил в "Kwik-E-Mart". Ева не нужно вскрывать алгоритмы. Ей не нужно полагаться на тонкие дефекты протоколов. Она может и с- пользовать их ключи для чтения всех сообщений Алисы и Боба, не прикладывая никаких криптоаналитических усилий. В реальном мире управление ключами представляет собой самую трудную часть криптографии. Проектир о- вать безопасные криптографические алгоритмы и протоколы не просто, но Вы можете положиться на большой объем академических исследований. Сохранить секрет ключей намного труднее. Криптоаналитики часто вскрывают и симметричные криптосистемы, и криптосистемы с открытыми ключ а- ми через распределение ключей. Зачем Еве беспокоиться об проблеме вскрытия криптографического алгоритма целиком, если она может восстановить ключ из-за неаккуратного хранения ключа? Зачем ей тратить 10 ми л- лионов долларов на создание машина для криптоанализа, если она может подкупить клерка за 1000 долларов? Миллион долларов за клерка связи на хорошем месте в дипломатическом посольстве может быть выгодной сделкой. Уолкеры годами продавали Советам ключи шифрования ВМС США. Руководитель контрразведки ЦРУ стоил меньше 2 миллионов долларов, включая жену. Это намного дешевле, чем строить огромные маш и- ны вскрытия и нанимать блестящих криптоаналитиков. Ева может выкрасть ключи. Она может арестовать или похищать кого-то, кто знает ключи. Она может совращать кого-то и получать ключи таким образом. (Морские пехотинцы, охранявшие посольство США в Москве не устояли перед подобной атакой.) Намного проще нах о- дить дефекты в людях, чем в криптосист емах. Алиса и Боб должны защищать и свой ключ, и в той степени шифруемые им данные. Если ключ не изменять регулярно, то количество данных может быть огромно. К сожалению, многие коммерческие продукты просто объявляют "Мы используем DES" и забывают обо всем остальном. Результаты не слишком впечатляют. Например, программа DiskLock для Macintosh (версия 2.l), продававшаяся в большинстве магазинов пр о- граммного обеспечения, претендует на безопасное шифрование DES. Она шифрует файлы, используя DES. Ре а- лизация DES алгоритма правильна. Однако, DiskLock сохраняет ключ DES вместе с зашифрованным файлом. Если вы знаете, где искать ключ, и хотеть прочитать файл, шифрованный DiskLock с помощью DES, восстан о- вите ключ из шифрованного файла и затем расшифровывать файл. Не имеет значение, что программа использ у- ет шифрование DES - реализация абсолютно небезопасна. Дальнейшую информацию относительно управления ключами можно найти в [457, 98, 1273, 1225, 775, 357]. В следующих разделах обсуждаются некоторые из вопросов и решений. 8.1 Генерация ключей The security of an algorithm rests in the key. If you're using a cryptographically weak process to generate keys, then your whole system is weak. Eve need not cryptanalyze your encryption algorithm; she can cryptanalyze your key generation algorithm. Безопасность алгоритма сосредоточена в ключе. Если вы используете криптографически слабый процесс для генерации ключей, то ваша система в целом слаба. Еве не нужно криптоанализировать ваш алгоритм шифров а- ния, она может криптоанализировать ваш алгоритм генерации ключей. Уменьшенные пространства ключей DES использует 56-битовый ключ с битами. Любая правильно заданная 56-битовая строка может быть кл ю- чом, существует 2 56 (10 16 ) возможных ключей. Norton Discreet for MS-DOS (версии 8.0 и более ранние) разре- шает пользоваться только ключам ASCII, делая старший бит каждого байта нолем. Программа также преобр а- зует символы нижнего регистра в верхний регистр (так что пятый бит каждого байта всегда противоположен шестому бита) и игнорирует бит младшего разряда каждого байта, что приводит к пространству в 2 40 возмож- ных ключей. Эти ущербные процедуры генерации ключей сделали свою реализацию DES в десять тысяч раз проще для вскрытия. 7-й содержит число возможных ключей для различных ограничений на входные строки. В 6-й приведено время, требуемое для исчерпывающего перебора всех возможных ключей при миллионе попыток в секу нду. Могут быть использованы для вскрытия грубой силой любые специализированные аппаратные и параллел ь- ные реализации. При проверке миллиона ключей в секунду (одной машиной или несколькими параллельно) физически возможно расколоть ключи из символов нижнего регистра и ключи из цифр и символов нижнего регистра длиной до 8 байтов, алфавитно-цифровые ключи - длиной до 7 байтов, ключи из печатаемых символов и ASCII-символов - длиной до 6 байтов, в ключи из 8-битовых ASCII-символов - длиной до 5 байтов. Табл. 8-1. Количество возможных ключей в различных пространствах ключей 4 байта 5 байтов 6 байтов 7 байтов 8 байтов Строчные буквы (26) 460000 1.2*10 7 3.1*10 8 8.0*10 9 2.1*10 11 Строчные буквы и цифры (36) 1700000 6.0*10 7 2.2*10 9 7.8*10 10 2.8*10 12 Алфавитные и цифровые символы (62) 1.5*10 7 9.2*10 8 5.7*10 10 3.5*10 12 2.2*10 14 Печатаемые символы (95) 8.1*10 7 7.7*10 9 7.4*10 11 7.0*10 13 6.6*10 15 Символы ASCII (128) 2.7*10 8 3.4*10 10 4.4*10 12 5.6*10 14 7.2*10 16 8-битовые ASCII символы (256) 4.3*10 9 1.1*10 12 2.8*10 14 7.2*10 16 1.8*10 19 Табл. 8-2. Время исчерпывающего поиска различных пространства ключей (при одном миллионе проверок в се- кунду) 4 байта 5 байтов 6 байтов 7 байтов 8 байтов Строчные буквы (26) 0.5 секунды 12 секунд 5 минут 2.2 часа 2.4 дня Строчные буквы и цифры (36) 1.7 секунды 1 минута 36 минут 22 часа 33 дня Алфавитные и цифровые символы (62) 15 секунд 15 минут 16 часов 41 день 6.9 года Печатаемые символы (95) 1.4 минуты 2.1 часа 8.5 дня 2.2 года 210 лет Символы ASCII (128) 4.5 минуты 9.5 часа 51 день 18 лет 2300 лет 8-битовые ASCII символы (256) 1.2 часа 13 дней 8.9 года 2300 лет 580000 лет И помните, вычислительная мощь удваивается каждые 18 месяцев. Если вы хотите, чтобы ваши ключи были устойчивы к вскрытию грубой силой в течение 10 лет, вы должны соответствующим образом планировать и с- пользование ключей. Обедненный выбор ключей Когда люди сами выбирают ключи, они выбирают ущербные ключи. Они с большей вероятностью выберут "Barney", чем "*9 (hH/A". Это не всегда происходит из-за плохой практики, просто "Barney" легче запомнить чем "*9 (hH/A". Самый безопасный алгоритм в мире не сильно поможет, если пользователи по привычке выб и- рают имена своих жен (мужей) для ключей или пишут свои ключи на небольших листочках в бумажниках. И н- теллектуальное вскрытие грубой силой не перебирает все возможные ключи в числовом порядке, но пробует сначала очевидные ключи. Это называется вскрытием со словарем, потому что нападющий использует словарь общих ключей. Дэн и- ел Кляйн (Daniel Klein) смог расколоть 40 процентов паролей на среднем компьютере, используя этот способ вскрытия [847, 848]. Нет, он не перебирал один пароль за другим, пытаясь войти в систему. Он скопировал з а- шифрованный файл паролей и предпринял вскрытие автономно. Вот, что он пробовал: 1. В качестве возможного пароля имя пользователя, инициалы, имя бюджета и другую связанную с ч е- ловеком информацию. В целом, на основе такой информации пробовалось до 130 различных паролей. Вот некоторые из паролей, проверявшихся для имени бюджета klone и пользователя "Daniel V. Klein": klone, klone0, klonel, klonel23, dvk, dvkdvk, dklein, Dklein, leinad, nielk, dvklein, danielk, DvkkvD, DANIEL-KLEIN, (klone), KleinD, и так далее. 2. Слова из различных баз данных. Использовались списки мужских и женских имен (всего около 16000), названия мест (включая изменения, поэтому рассматривались и "spain", " Spanish", и "Spaniard"), имена известных людей, мультфильмы и мультипликационные герои, заголовки, герои и места из фильмов и научной фантастики, мифические существа (добытые из Bullfinch's Mythology и словарей мифических животных), спорт (включая названия команд, прозвища и специальные терм и- ны), числа (записанные как цифрами - '2001", так и буквами " twelve''), строки символов и чисел ("a", "aa", "aaa", "aaaa" и т.д.), китайские слоги (из Piny in Romanization of Chinese, международного стан- дарта письма по китайски на англоязычной клавиатуре), Библия короля Джеймса; биологические те р- мины, разговорные и вульгарные выражения (типа "fuckyou", "ibmsux" и "deadhead"), стандарты кл а- виатуры (типа "qwerty", "asdf" и "zxcvbn"), сокращения (типа "roygbiv" - первые буквы названий цв е- тов радуги по английски - и "ooottafagvah" - мнемоническая схема для запоминания 12 черепных не р- вов), имена компьютеров (полученные из /etc/hosts), герои, пьесы и места действия у Шекспира, с а- мые распространенные слова языка Идиш, названия астероидов, совокупность слов из различных те х- нических статей, опубликованных ранее Кляйном. Итого, для пользователя рассматривалось более чем 60000 отдельных слов (с отбрасыванием дубликатов в различных словарях). 3. Вариации слов из пункта 2. Это включало перевод первого символа в верхний регистр или его замену управляющим символом, перевод всего слова в верхний регистр, инверсию регистра слова (с и без вышеупомянутого изменения регистра первой буквы), замену буквы "o" на цифру "0" (так, чтобы сл о- во "scholar" было также проверено как "sch0lar"), замену буквы "l" на цифру "1" (так, чтобы слово "scholar" было бы также проверено как "scho1ar") и выполнение аналогичных манипуляций с буквой "z" и цифрой "2", а также с буквой "s" и цифрой "5". Другая проверка состояла из перевода слова во множественное число (независимо от того, было ли слово существительным) с учетом необходимых правил, чтобы "dress" заменилось на "dresses", "house" - на "houses", а "daisy" - на "daisies". Хотя Кляйн не жестко придерживался правил преобразования ко множественному числу, поэтому "datum" стала "datums" (а не "data"), "sphynx" - "sphynxs" (а не "sphynges"). Аналогично, для преобразования слов добавлялись суфиксы "-ed", "-er" и "-ing", подобно "phase" в "phased," "phaser" и "phasing". Эти дополнительные проверки добавили еще 1000000 слов к списку возможных паролей, которые пров е- рялись для каждого пользователя. 4. Различные варианты преобразования к верхнему регистру слов пункта 2, не рассматривавшихся в пункте 3. Сюда вошло преобразование к верхнему регистру одиночных символов (так, чтобы "michael" был также проверен как "mIchael", "miChael", "micHael", "michAel", и т.д.), преобразование к верхнему регистру пары символов ("MIchael", "MiChael", "MicHael", ..., "mIChael", "mIcHael", и т.д.), преобразование к верхнему регистру трех символов, и т.д. Изменения одиночного символа доб а- вили к проверяемым примерно еще 400000 слов, а изменения пары символов - 1500000 слов. Измен е- ния трех символов добавляли по крайней мере еще 3000000 слов для каждого пользователя, если для завершения тестирования хватало времени. Проверка изменения четырех, пяти и шести символов была признана непрактичной, так как для их проверки не хватало вычислительных мощностей. 5. 5. Иностранные слова для иностранных пользователей. Специфический тест, который был выполнен, проверял пароли из китайского языка для пользователей с китайскими именами. Для китайских сл о- гов использовался стандарт Pinyin Romanization, слоги объединялись вместе в одно-, двух- и тре х- сложные слова. Так как не было выполнено предварительной проверки слов на значимость, использ о- вался исчерпывающий перебор. Так как в системе Pinyin существует 298 китайских слогов, то имеется 158404 слов с двумя слогами, и немного больше 16000000 слов с тремя слогами. Подобный способ вскрытия мог бы быть легко использован и для английского языка, с учетом правил образования пр о- износимых ничего не значащих слов. 6. Пары слов. Объем такого исчерпывающего теста колеблется. Чтобы упростить тест, из /usr/dict/words использовались только слова длиной три или четыре символа. Даже при этом, число пар слов сост а- вило приблизительно десять миллионов. Вскрытие со словарем намного мощнее, когда оно используется против файла ключей, а не против одного ключа. Одиночный пользователь может быть достаточно разумен и выбрать хорошие ключи. Если из тысячи людей каждый выбирает собственный ключ как пароль компьютерной системы, то велика вероятность того, что по крайней мере один человек выберет ключ, имеющийся в словаре взломщика. Случайные ключи Хорошими ключами являются строки случайных битов, созданные некоторым автоматическим процессом. Если длина ключа составляет 64 бита, то все возможные 64-битовые ключи должны быть равновероятны. Ген е- рируйте биты ключей, пользуясь либо надежным источником случайных чисел (см. раздел 17.14), либо крипт о- графически безопасным генератором псевдослучайных битов (см. главы 16 и 17.) Если такие автоматические процессы недоступны, бросайте монетку или кости. Это важно, но не увлекайтесь обсуждением того, является ли шум из звуковых источников более случайным, чем шум из радиоактивного распада. Ни один из этих источников случайного шума не совершенен, но все они, скорее всего, будут достаточно хороши. Для генерации ключей важно использовать хороший генератор случа й- ных чисел, но гораздо важнее использовать хорошие алгоритмы шифрования и процедуры управления ключ а- ми. Если вы беспокоитесь о случайности ваших ключей, используйте описанную ниже методику перемалывания ключа. Некоторые алгоритмы шифрования имеют слабые ключи - специфические ключи, менее безопасные чем другие ключи. Я советую проверять слабость ключа ключей и, обнаружив ее, генерировать новый. У DES тол ь- ко 16 слабых ключей в пространстве 2 56 , так что вероятность получить один из этих ключей невероятно мала. Заявлялось, что криптоаналитик не будет знать о том, что используется слабый ключ, и, следовательно, не см о- жет получить никакой выгоды из их случайного использования. Также заявлялось, что информацию криптоан а- литику дает совсем не использование слабых ключей. Однако, проверка немногих слабых ключей настолько проста, что кажется глупым пренебречь ею. Генерация ключей для систем криптографии с открытыми ключами тяжелее, потому что часто ключи дол ж- ны обладать определенными математическими свойствами (возможно, они должны быть простыми числами, квадратичным остатком, и т.д.). Методы генерации больших случайных простых чисел рассматриваются в ра з- деле 11.5. Важно помнить, что с точки зрения управления ключами случайные стартовые последовательности для таких генераторов должны быть действительно случайны. Генерация случайного ключа возможна не всегда. Иногда вам нужно помнить ваш ключ. (Интересно, скол ь- ко времени вам понадобится, чтобы запомнить 25e8 56f2 e8ba c820?). Если вам надо генерировать простой для запоминания ключ, замаскируйте его. Идеалом является то, что легко запомнить, но трудно угадать. Вот н е- сколько предложений: — Пары слов, разделенные символом пунктуации, например, " turtle*moose" или "zorch!splat" — Строки букв, являющиеся акронимами длинных фраз, например, "Mein Luftkissenfahrzeug ist voller Aale!" служит для запоминания ключа "MLivA!" Ключевые фразы Лучшим решением является использование вместо слова целой фразы и преобразование этой фразы в ключ . Такие фразы называются ключевыми фразами. Методика с названием перемалывание ключа преобразует легко запоминающиеся фразы в случайные ключи . Для преобразования текстовой строки произвольной длины в строку псевдослучайных бит используте однонаправленную хэш-функцию . Например, легко запоминающаяся текстовая строка: Myname is Ozymandias, king ofkings. Look on myworks, yemighty, and despair. 1 может "перемолоться" в такой 64-битовый ключ: e6cl 4398 5ae9 0a9b Конечно, может быть нелегко ввести в компьютер целую фразу, если вводимые символы не отображаются на экране. Разумные предложения по решению этой проблемы будут оценены . Если фраза достаточно длинна, то полученный ключ будет случаен . Вопрос о точном смысле выражения "достаточно длинна" остается открытым. Теория информации утверждает, что информационная значимость стандартного английского языка составляет около 1.3 бита на символ (см. раздел 11.1). Для 64-битового ключа достаточной будет ключевая фраза, состоящая примерно из 49 символов, или 10 обычных английских слов. В качестве эмпирического правила используйте пять слов для каждых 4 байтов ключа. Это предложение работает с запасом, ведь в нем не учитываются регистр, пробелы и знаки пунктуации . Этот метод также можно использовать для генерации закрытых ключей в криптографических системах с о т- крытыми ключами: текстовая строка преобразуется в случайную стартовую последовательность, а эта послед о- вательность может быть использована в детерминированной системе, генерирующей пары открытый ключ/закрытый ключ. Выбирая ключевую фразу, используйте что-нибудь уникальное и легко запоминающееся. Не выбирайте фра- зы из книг - пример с "Ozymandias" в этом смысле плох. Легко доступны и могут быть использованы для вскрытия со словарем и собрание сочинений Шекспира, и диалоги из Звездных войн. Выберите что-нибудь ту- манное и личное. Не забудьте о пунктуации и преобразовании регистра, если возможно включите числа и неа л- фавитные символы. Плохой или искаженный английский, или даже любой иностранный язык, делает ключевую фразу более устойчивой к вскрытию со словарем . Одним из предложений является использование фразы, кото- рая является "потрясающей ерундой", чем-то таким, что вы вряд ли запомните и вряд ли запишете . Несмотря на все написанное здесь маскировка не заменяет истинную случайность. Лучшими являются сл у- чайные ключи, которые так тяжело запомнить . 1 Я Озимандиас, царь царей. Вы, сильные мира сего, смотрите на мои труды и трепещите. Стандарт генерации ключей X9.17 Стандарт ANSI X9.17 определяет способ Генерации ключей (см. 7th) [55]. Он не создает легко запоминаю- щиеся ключи, и больше подходит для генерации сеансовых ключей или псевдослучайных чисел в системе . Для генерации ключей используется криптографический алгоритм DES, но он может быть легко заменен любым другим алгоритмом. Шифровать Шифровать R i V i+1 V i T i Шифровать Рис. 8-1. Генерация ключей ANSI X9.17 Пусть E K (X) - это X, зашифрованный DES ключом K, специальным ключом, предусмотренным для генер а- ции секретных ключей. V 0 - это секретная 64-битовая стартовая последовательность. T - это метка времени. Для генерации случайного ключа R i вычислим: R i = E K (E K (T i ) ? V i ) Для генерации V i+1 , вычислим: V i+1 = E K (E K (T i ) ? R i ) Для превращения R i в ключ DES, просто удалите каждый восьмой бит. Если вам нужен 64-битовый ключ, используйте ключ без изменения. Если вам нужен 128-битовый ключ, создайте пару ключей и объедините их . Генерация ключей в министерстве обороны США Министерство обороны США для генерации случайных ключей рекомендует использовать DES в режиме OFB (см. раздел 9.8) [1144]. Создавайте ключи DES, используя системные вектора прерывания, регистры с о- стояния системы и системные счетчики. Создавайте вектор инициализации, используя системные часы, идент и- фикатор системы, с также дату и время. Для открытого текста используйте 64-битовые величины, созданные кем-то другим, например, 8 символов, введенных системным администратором . Используйте в качестве своего ключа результат. 8.2 Нелинейные пространства ключей Вообразите, что вы - это военная криптографическая организация, создающая криптографический модуль для ваших войск. Вы хотите использовать безопасный алгоритм, но что будет, если аппаратура попадет во вр а- жеские руки? Ведь вы не хотите, чтобы ваши приборы использовались для защиты вражеских секретов. Если вы можете поместить ваш алгоритм в защищенный модуль, то вот, что вы можете сделать. Потребуйте, чтобы модуль правильно работал только с ключами специальной и секретной формы, а со всеми другими кл ю- чами для шифрования использовался сильно ослабленный алгоритм. Можно сделать так, чтобы вероятность того, что кто-то, не знающий этой специальной формы, случайно наткнется на правильный ключ, была исч е- зающе малой. Получившееся пространство ключей называется нелинейным, потому что ключи не являются одинаково сильными. (Противоположным является линейное, или плоское, пространство ключей.) Простым способом д о- биться этого можно, создавая ключ, состоящий из двух частей: непосредственно ключа и некоторой фиксир о- ванной строки, шифрованной этим ключом. Модуль расшифровывает строку, используя ключ. Если результ а- том оказывается фиксированная строка, то ключ используется как обычно, если нет, то используется другой, слабый алгоритм. Если алгоритм имеет 128-битовый ключ и 64-битовый размер блока, то длина полного ключа - 192 бита. Таким образом, у алгоритма 2 128 эффективных ключа, но вероятность случайно выбрать правильный составляет один шанс из 2 64 Вы можете сделать еще хитрее. Можно разработать такой алгоритм, что некоторые ключи будут сильнее других. У алгоритма не будет слабых ключей - ключей, которые с очевидностью являются недостаточно защ и- щенными - и тем не менее у него будет нелинейное пространство ключей. Это работает только, если используется секретный алгоритм, который враг не может перепроектировать, или если различие в силе ключей достаточно тонко, чтобы враг не смог о нем догадаться. NSA проделывало это с секретными алгоритмами в своих модулях Overtake (см. раздел 25.1). Делали ли они то же самое с Skipjack (см. раздел 13.12)? Неизвестно. 8.3 Передача ключей Алиса и Боб собираются для безопасной связи использовать симметричный криптографический алгоритм, им нужен общий ключ. Алиса генерирует ключ, используя генератор случайных ключей. Теперь она должна безопасно передать его Бобу. Если Алиса сможет где-то встретить Боба (какие-нибудь задворки, комната без окон или одна из лун Юпитера), то она сможет передать ему копию ключа. В противном случае, у них есть пр о- блема. Криптография с открытыми ключами решает проблему легко и с минимумом предварительных соглаш е- ний, но эти методы не всегда доступны (см. раздел 3.1). Некоторые системы используют альтернативные кан а- лы, считающиеся безопасными. Алиса могла бы посылать Бобу ключ с доверенным посыльным. Она могла бы послать ключ заказной почтой или ночной службой доставки. Она могла бы устанавливать другой канал связи с Бобом и надеяться, что его то никто не подслушивает. Алиса могла бы послать Бобу симметричный ключ по их каналу связи - тот, который они собираются ши ф- ровать. Но глупо передавать ключ шифрования канала по этому же каналу в открытом виде, кто-то, подслуш и- вающий канал, наверняка сможет расшифр овывать все сообщения. Стандарт X9.17 [55] определяет два типа ключей: ключи шифрования ключей и ключи данных. Ключа- ми шифрования ключей при распределении шифруются другие ключи. Ключи данных шифруют сами сообщ е- ния. Ключи шифрования ключей должны распределяться вручную, (хотя они могут быть в безопасности в з а- щищенном от взлома устройстве, таком как кредитная карточка), но достаточно редко. Ключи данных распр е- деляются гораздо чаще. Подробности можно найти в [75]. Эта идей двухсвязных ключей часто используется при распределении ключей. Другим решением проблемы распределения является разбиение ключа на несколько различных частей (см. раздел 3.6) и передача их по различным каналам. Одна часть может быть послана телефоном, другая - почтой, третья - службой ночной доставки, четвертая - почтовым голубем, и так далее, (см. 6-й). Так противник может собрать все части, кроме одной, и все равно ничего не узнает про ключ. Этот метод будет работать во всех сл у- чаях, кроме крайних. В разделе 3.6 обсуждаются схемы разбиения ключа на несколько частей. Алиса могла бы даже применить схему совместно используемого секрета, (см. раздел 3.7), что даст возможность Бобу восст а- навливать ключ, если некоторые из частей потеряны при перед аче. k 5 k 4 k 3 k 2 k 1 Почтовый голубь Телефон Федеральная экспресс-почта Заказная почта Курьер ПОЛУЧАТЕЛЬ Восстанавливает ключ ОТПРАВИТЕЛЬ Делит ключ на части k 5 k 4 k 3 k 2 k 1 k 5 k 2 Рис. 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/2 16 до 1/2 32 Обнаружение ошибок при дешифрировании Иногда получатель хочет проверить, является ли его конкретный ключ правильным ключом симметричного дешифрирования. Если открытый текст сообщения представляет собой что-то похожее на 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. - "Наш девиз - Мы тебе не скажем." Как примерный служащий корпорации она в соответствии с инструкциями по безопасности шифрует все свои данные . К несча- стью, она, проигнорировав инструкции по переходу улицы, попала под грузовик . Что делать президенту компа- нии Бобу? Если Алиса не оставила копии своего ключа, ему придется несладко. Весь смысл шифрования файлов - в не- возможности восстановить их без ключа. Если Алиса не была дурой и не использовала плохих шифровальных программ, то ее файлы пропали навсегда. У Боба есть несколько способов избежать этого . Простейший иногда называют условным вручением клю- чей (см. раздел 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 обсуждаются возможные способы вскрытия криптографии с открытыми ключами , основанных на подмене ключа Боба ключом Мэллори . Используется следующий сценарий: пусть Алиса хочет послать с о- общение Бобу. Она обращается к базе данных открытых ключей и получает открытый ключ Боба . Но подлый Мэллори подменяет ключ Боба своим собственным . (Если Алиса запрашивает ключ непосредственно у Боба, Мэллори для успешной подмены придется перехватить ключ Боба при передаче .) Алиса шифрует сообщение ключом Мэллори и отправляет его Бобу. Мэллори перехватывает сообщение, расшифровывает и читает его . Затем шифрует открытым ключом Боба и отправляет по назначению. Ни Боб, ни Алиса ни о чем не догадыв а- ются. Заверенные открытые ключи Заверенным открытым ключом, или сертификатом, является чей-то открытый ключ, подписанный засл у- живающим доверия лицом. Заверенные ключи используются, чтобы помешать попыткам подмены ключа [879]. Заверенный ключ Боба в базе данных открытых ключей состоит не только из открытого ключа Боба . Он содер- жит информацию о Бобе - его имя, адрес, и т.д. - и подписан кем-то, кому Алиса доверяет - Трентом (обычно известным как орган сертификации, certification authority, или CA). Подписав и ключ, и сведения о Бобе, Трент заверяет, что информация о Бобе правильна, и открытый ключ принадлежит ему . Алиса проверяет под- пись Трента и затем использует открытый ключ, убедившись в том, что он принадлежит Бобу и никому другому. Заверенные ключи играют важную роль во многих протоколах с открытыми ключами, например, PEM [825] (см. раздел 24.10) и X.509 [304] (см. раздел 24.9). В таких системах возникает сложная проблема, не имеющая прямого отношения к криптографии . Каков смысл процедуры заверения? Или, иначе говоря, кто для кого имеет полномочия выдавать сертификаты ? Кто угодно может заверит своей подписью чей угодно открытый ключ, но должен же быть какой-то способ отфиль т- ровать ненадежные сертификаты: например, открытые ключи сотрудников компании, заверенные CA другой компании. Обычно создается цепочка передачи доверия : один надежный орган заверяет открытые ключи дов е- |