IEEE   Communication   Magazine,   1985,   v.23,   N9,   pp.41-46
D.M.Balenson.  Automated Distribution of Cryptographic Keys Using
the    Financial    Institution    Key    Management    Standard.
Автоматизированное   распределение   криптографических  ключей  с
использованием   стандарта   управления  ключами  для  финансовых
учреждений   Существующие  и  потенциальные  угрозы  безопасности
вычислительных  сетей вызывают необходимость защиты целостности и
секретности  данных  в  сети.  Криптография  является эффективным
средством,  обеспечивающим  высокий  уровень  защиты передаваемых
данных.   В  1977  г.  Национальным  бюро  стандартов  (НБС)  был
опубликован    стандарт   DES   для   использования   Федеральным
правительством в целях защиты ценных и уязвимых, но не секретных,
данных.  Впоследствии  стандарт  был  принят  ANSI  как DEA. Было
разработано  несколько  быстродействующих DES-устройств, и теперь
многие   общественные   и   частные   учреждения   плагаются   на
криптооборудование  на  базе  DES  для  обеспечения  безопасности
передачи  данных.  После  опубликования  DES  НБС  было  поручено
разработать  дополнительные стандарты на базе DES и, в частности,
стандарты  для  внедрения  криптографии  в  вычислитеьные сети. К
последним  результатам  относится  стандарт  ANSI  по  управлению
ключами  для  финансовых  учреждений  (оптовые  сделки)  (Х9.17).
Стандарт   разработан   совместно   банковской   промышленностью,
федеральным  правительством  и частной промышленностью и отвечает
возросшим   требованиям  к  безопасности  со  стороны  финансовых
учреждений, которые в совокупности переводят триллионы долларов в
денежных   средствах   и  ценных  бумагах  электронным  способом.
Используя   совместно   стандарты   ANSI   X3.92   (DEA)  и  Х9.9
(аутентификация  сообщений),  обеспечивается  защита  сообщений и
другой   уязвимой   информации,   гарантирующая   их  точность  и
секретность.   Стандарт   был   принят   Казначейством   США  для
использования   во  всех  системах,  которые  создают,  передают,
транслируют,   принимают  или  обрабатывают  данные  электронного
перевода  денежных средств (ЭПДС). В статье освещены важные черты
стандарта   управления   ключами,  включая  требования  к  такому
управлению,  внутреннюю  структуру,  криптографические  методы  и
протоколы   для  автоматизированного  распределения  криптоключей
безопасным   способом   по   вычислительной   сети.  Безопасность
вычислительной  сети  на  основе  криптографии  Цель классической
криптографии  -  преобразовать исходные данные (открытый текст) в
непонятный  вид  (шифртекст)  перед  передачей  по  сети. Правила
преобразования,  называют шифрованием, а восстановление открытого
текста    из   шифртекста   -   дешифрованием;   они   выражаются
криптоалгоритмом.  DES  определяет  криптоалгоритм (де)шифрования
64-битных  блоков  данных  под управлением уникального 56-битного
ключа.  Если ключ выбирается случайно из множества приблизительно
70 квадрильонов возможных 56-битных ключей и держится в тайне, то
незаконный  получатель, не имеющий ключа, не дешифрует шифртекст,
в  то  время  как законный получатель легко это делает при помощи
секретного ключа. Аутентификация данных - это другой криптометод,
основанный  на шифровании в целях обеспечения целостности данных,
передаваемых   по   вычислительной   сети.   Код  аутентификацуии
сообщения  (КАС)  рассчитывается  создателем  данных  при  помощи
секретного  ключа, разделяемого с предполагаемым получателем. КАС
является криптофункцией каждого бита данных и передагтся вместе с
ними. Получатель данных, используя тот же ключ, рссчитывает КАС и
сравнивает его с полученным в сообщении. Совпадение КАС говорит о
том,  что  вероятность  изменения данных при передаче очень мала.
При  несовпадении КАС данные были изменены, возможно не более, чм
на  1  бит,  или  несовпадают  ключи.  Криптосистема,  сочетающая
шифрование    и    аутентификацию,    может    использоваться   в
вычислительной   сети   для   защиты  целостности  и  секретности
передаваемых  данных.  Но  поскольку криптоалгоритм DES известен,
уровень   защиты   зависит   от  предоставляемого  уровня  защиты
используемых ключей. Безопасное управление этими ключами является
критическим элементом криптосистемы, поскольку даже очень сложная
система  неэффективна  при  слабом  управлении  ключами. Основная
задача   управления  ключами  -  обеспечить  ключами,  когда  они
необходимы   для   шифрования   и   аутентификации,   и  защитить
секретность  и  целостность  ключей.  Управление ключами включает
генерацию,    распределение,   хранение,   ввод,   использование,
уничтожение  и  архивирование  криптоключей. До недавнего времени
распределение ключей осуществлялось только вручную, что приводило
к  задержкам  по  времени, ошибкам и дорого стоило. Автоматизация
распределения    ключей    в    больших    вычислительных   сетях
характеризуется    быстротой,    прозрачностью,   эффективностью,
гибкостью,   дешевизной   и   улучшенной   безопасностью.  Ручное
распределение  ключей  по-прежнему  требуется,  но  число  ключей
значительно  сокращено.  Криптометоды,  используемые  для  защиты
передаваемых  по  сети  данных, могут использоваться и для защиты
секретности и целостности передаваемых по сети ключей. Шифрование
передаваемых ключей защитит их от раскрытия. Ключи аутентификации
обнаружат  любые  изменения  ключей, включая ошибки передачи. При
использовании  системы  нумерации ключей аутентификация обнаружит
подмену,  уничтожение,  повторение  старых  или вставку фальшивых
ключей.  Стандарт  управления  ключами  для финансовых учреждений
Общие   требования  к  управлению  ключами  Стандарт  ANSI  X9.17
описывает   стандартный   уровень   защиты  ключевого  материала,
включающего   криптографические   ключи  и  другую  сопутствующую
информацию,   необходимую   для   управления   ключами,  а  также
устройство   управления   ключами   (УУК),  представляющее  собой
физическую   оболочку   (например,   устройство  или  помещение),
содержащую     криптоэлементы    -    аппаратные,    программные,
программно-аппаратные   средства,   ключи   и   т.п.  Минимальные
требования,  определяемые  стандартом,  следующие:  * Контроль за
ключевым  материалом  в течение всего существования ключей. Ключи
должны  генерипроваться  случайным  образом. Для защиты ключевого
материала  от  непреднамеренного  или  незаконного  раскрытия они
должны быть физически защищены или зашифрованы. При невозможности
физической  защиты ключевой материал должен быть криптографически
аутентифицирован   совместно  со  счгтчиком  с  целью  защиты  от
непреднамеренной  или  незаконной  подмены, вставки, повторения и
уничтожения.  *  Безопасное  распределение ключей, обеспечивающее
возможность    взаимодействия    связующихся    сторон    и    их
криптооборудования.    Для   поддержки   различных   потребностей
финансовых   учреждений   стандарт   определяет   и   ручные,   и
автоматизированные   способы   обмена   ключами.   *  Обеспечение
целостности  ключей  и УУК. Должно обеспечиваться всеохватывающее
управление   ключами   с  процедурными  проверками.  Ключи,  УУК,
процедурные    проверки    должны   постоянно   тестироваться   и
контролироваться.   *  Восстановление  в  случае  сбоя,  то  есть
способность    сохранить   уровень   защиты   при   компрометации
целостности  ключей  или процесса управления ключами. Архитектура
автоматизированного  управления ключами Стандарт Х9.17 основан на
иерархически  структурированном множестве криптоключей, созданном
для  автоматизированного  распределения  ключей по вычислительной
сети.  Иерархию  образуют  три  класса  ключей:  - распределяемые
вручную   ключи   шифрования   ключей   (ККМ);   -  автоматически
распределяемые  ключи  шифрования  ключей  (КК);  - автоматически
распределяемые  ключи  шифрования  данных  (KD). Ключи шифрования
ключей  (ККМ  и КК), которые могут быть одним ключом или ключевой
парой,  шифруют  другие  ключи для распределения. Поскольку ключи
шифрования  ключей  обычно  имеют больший криптопериод, чем ключи
данных, для повышенной защиты могут использоваться ключевые пары,
представляющие   собой   два  ключа,  используемые  для  кратного
шифрования.  Ключи данных (KD), которые должны быть одним ключом,
аутентифицируют сообщения, используемые при распределении ключей,
а   также  шифруют  или  аутентифицируют  данные.  вручную  (*)КК
----------------------------------------------зддддддддддддд
[авт. (*)КК] зддддддддддддд   ----------------------------  
    Сторона    А        авт.   KD      Сторона   В         
----------------------------    юддддддддддддды юддддддддддддды
Рис.1.  Ключевые  связи  при  прямом  распределении  вручную  *КК
зддддддддддддддд   вручную   *КК   ------------     ключевой  
-------------  центр    юддддддддддддддды зддддддддддддд [авт.
(*)КК]  зддддддддддддд      ----------------------------   
Сторона    А        авт.    KD        Сторона    В          
----------------------------    юддддддддддддды юддддддддддддды
Рис.2.  Ключевые  связи  при распределении с центром ККМ образуют
основу   для   ключевой   взаимосвязи  между  двумя  связующимися
сторонами.  Для  автоматизированного  обмена  ключами по сети обе
стороны должны либо разделять один ККМ или ККМ-пару (рис.1), либо
каждый  должен разделять ККМ-пару с третьей доверенной стороной -
ключевым  центром (рис.2). Эти ключи генерируются и рассылаются в
физически  защищгнном виде и вручную вводятся в УУК обеих сторон.
После того, как ККМ разделен между двумя сторонами или с ключевым
центром,  его  можно  использовать  для шифрования дополнительных
ключей  для  автоматизированного  распределения по сети. Стандарт
требует,  как  минимум,  двухуровневой архитектуры, в которой ККМ
шифрует    KD   для   распределения.   Может   использоваться   и
тргхуровневая    архитектура,   в   которой   ККМ   шифрует   для
распределения  КК,  а  КК  шифрует  для распределения KD. В обоих
случаях  могут автоматически обмениваться векторами инициализации
(IV),  которые  требуются  для некоторых операций шифрования. При
необходимости  IV  шифруются  при  помощи  KD.  Генерация  ключей
Способы,  используемые  для  генерации  новых  ключей и IV должны
держаться   в   тайне.   Если   эти  способы  связаны  с  ручными
процедурами, то они выполняются в защищгнных местах и под двойным
контролем  (т.е.  два  независимых источника). Автоматизированные
процедуры должны быть физически и логически защищены. Новые ключи
и IV должны генерироваться случайным образом, а при использовании
детерминированного  алгоритма должны быть псевдослучайными. Любой
возможный  ключ  или  IV должен генерироваться равновероятно и не
иметь  явной  связи  с  предшествующими  и  последующими ключами.
Уровень    защиты    процесса    генерации   ключей   не   должна
компрометировать   криптографическую   защиту,   достигаемую  при
шифровании  и  аутентификации данных на этих ключах. Шифрование и
дешифрование  ключей  и  IV Стандарт рекомендует использовать для
(де)шифрования  ключей  и IV при автоматизированном распределении
алгоритм  DEA.  Единичные  ключи  шифрования (ККМ и КК) шифруют и
дешифруют  другие  единичные  ключи, используя режим "электронной
кодовой  книги"  (ECB)  DEA.  Единичные ключи не используются для
(де)шифрования ключевых пар. Ключевые пары шифрования ключей (ККМ
и  КК) могут использоваться для (де)шифрования единичных ключей и
других ключевых пар, используя режим ECB для кратного шифрования.
При  кратном  шифровании  ключа  ключевой  парой, во-первых, ключ
шифруется  первым ключом пары, затем результат дешифруется вторым
ключом  пары,  и  в итоге результат снова шифруется первым ключом
пары.  При  кратном дешифровании ключа ключевой парой сперва ключ
ключ  дешифруется  первым  ключом  пары,  затем  шифруется вторым
ключом  пары и в конце снова дешифруется первым ключом пары. Даже
если УУК сконструировано для работы с ключевыми парами, оно может
выполнить шифрование, используя единичный ключ в качестве первого
и  второго  ключей  пары.  Если  IV  шифруются, то (де)шифрование
проводится  на  KD в ECB-режиме DEA. Ключевые счгтчики и смещение
ключа  Стандарт  требует  использования  ключевых  счгтчиков  для
контроля   за   автоматизированным   распределением  ключей.  При
подсчгте  передаваемых по сети сообщений для распределения ключей
можно  выявить  повторение  ранее переданных сообщений. Когда две
стороны  напрямую обмениваются ключами, используются два счгтчика
-  счгтчик  передачи  и  счгтчик  пригма,  чтобы была возможность
одновременного  обмена  ключами  в  обоих  направлениях. Счгтчики
хранятся  вместе  с  ключами шифрования ключей. Каждый раз, когда
передагтся    сообщение,    содержащее    зашифрованные    ключи,
соответствующий  счгтчик  включается  в сообщение. При нормальных
условиях  счгтчик передачи отправителя должен быть равен счгтчику
пригма  получателя,  и  сообщение принимается. Затем оба счгтчика
получают   приращение  для  следующего  сообщения.  Если  счгтчик
передачи,  включгнный  в  сообщение,  меньше  счгтчика  пригма на
пригмной  стороне,  сообщение  считается повторным и отвергается.
При  получении неверного счгтчика стороны обмениваются счгтчиками
для  ресинхронизации  последующих  сообщений.  Стандарт  требует,
чтобы  все  ключи,  шифруемые  для  распределения,  были защищены
смещением  ключа.  Смещение ключа комбинирует (сложение по модулю
2)  счгтчик  передачи  соответствующего  ключа шифрования ключа с
этим  ключом  до  того,  как  на этом ключе произойдгт шифрование
ключа.  Для  дешифрования  зашифрованных  ключей получатель также
должен  сместить  ключ  шифрования  ключа  тем  же счгтчиком. Это
предотвращает повторную передачу ранее переданных ключей, которые
по  ряду  причин  могли  быть раскрыты, так как ключ передагтся с
новым счгтчиком. Заверение ключа Другой защитной чертой стандарта
является  поддержка  заверения  ключа.  Заверение  ключа сходно с
действиями   нотариуса,  который  сперва  требует,  чтобы  клиент
идентифицировал  себя,  а затем заверяет его подпись на документе
нотариальной печатью. При автоматизированном распределении ключей
электронное    заверение    "опечатывает"   зашифрованные   ключи
идентичностями  отправителя  и предполагаемого получателя. Печать
формируется   путгм   комбинирования  ключа  шифрования  ключа  с
идентичностями    обеих    сторон.    Затем    печать   смещается
соответствующим  счгтчиком,  образуя  ключ  заверения,  который и
шифрует  ключи. После того, как ключи опечатаны, или заверены, их
можно  дешифровать  только  при  помощи  того же ключа заверения.
Таким  образом,  ключ  заверения подобен нотариусу, работающему в
интересах  отправителя  и  получателя при распределении ключей по
сети.  Стандарт  требует,  чтобы все ключи, генерируемые ключевым
центром  для  двух  сторон,  были  заверены  идентичностями  этих
сторон.   Безопасностьпри   этом   возрастает,   поскольку  ключи
заверения  не  могут  быть  дешифрованы  и  использованы  другими
сторонами.  Протоколы  автоматизированного  распределения  ключей
Криптографические    служебные    сообщения    и   аутентификация
Криптографические  служебные  сообщения  (CSM)  служат для обмена
между  сторонами  при  установлении  новых  ключей  и  выводе  из
действия   существующих   ключей.  Это  сообщения  фиксированного
формата,  которые  передаются  в  открытом виде и могут содержать
зашифрованные  ключи,  IV  и  другой  ключевой  материал, включая
идентичности сторон, идентичности ключей и счгтчики. Для гарантии
целостности   CSM  при  передаче  по  сети  содержимое  сообщения
аутентифицируется  в  соответствии с Х9.9 и включает КАС, который
проверяется получателем. Некоторые CSM должны аутентифицироваться
при помощи KD, который они устанавливают или выводят из действия.
Поскольку  эти  KD  будут  зашифрованы  и,  следовательно,  будут
рсшифровываться  на  секретном  ключе шифрования ключа, известном
только   отправителю   и   получателю,   идентичность   законного
отправителя    может    быть    проверена   получателем.   Прямое
распределение  (от  точки  к  точке) Стандарт определяет три типа
распределения  ключей:  прямое,  при  помощи центра распределения
ключей  (ЦРК)  или  центра  перевода  ключей  (ЦПК).  При  прямом
распределении  (это  минимальное  требование  стандарта) стороны,
разделяющие  ключ шифрования ключа - единичный или ключевая пара,
напрямую  обмениваются  дополнительными  KD,  IV  и, возможно, КК
между собой (рис.1). По крайней мере, одна из сторон должна иметь
возможность  генерировать  или  приобретать новые ключи и IV. Для
прямого  распределения  имеется  5 типов CSM. Если одна из сторон
желает  установить  ключи  с  другой  стороной,  но  не  может их
генерировать  или  приобретать, то можно запрпосить новые ключи у
другой стороны при помощи "Запроса на начало обслуживания" (RSI),
котрый включает поле для указания типа требуемых ключей. Ключевое
служебное  сообщение  (KSM) позволяет одной стороне послать новые
ключи  другой  стороне либо произвольно, либо по запросу RSI. KSM
должно  содержать, по крайней мере, один KD и может содержать КК,
второй  KD и IV. Если получатель KSM успешно аутентифицирует KSM,
и счгтчик верен, то отправителю KSM посылается ответное служебное
сообщение  (RSM).  Поскольку КАС, используемый для аутентификации
RSM,  будет  функцией  полученных  в  KSM ключей, отправитель KSM
может  убедиться  в правильном пригме ключей. Если получатель KSM
не  может  аутентифицировать  это  сообщение,  произошла ошибка в
счгтчике  или другая ошибка, он возвращает служебное сообщение об
ошибке (ESM). ESM содержит код типа ошибки, а при ошибке счгтчика
-  ожидаемое  показание  счгтчика. Отправитель KSM может передать
KSM произвольное количество раз, пока не добьгтся его правильного
пригма.   Если   другая   сторона  пожелает  прекратить  ключевую
взаимосвязь  или  вывести  из  действия  определгнные  ключи,  то
посылается  служебное  сообщение  разъединения  (DSM), включающее
идентичности  выводимых из действия ключей. Как и в случае с KSM,
получатель DSM возвращает RSM или ESM при успешном или неуспешном
пригме  DSM.  При  прямом  распределении  каждая  сторона  должна
обмениваться  вручную,  по крайней мере, одним ККМ с любой другой
стороной,  с  которой  она  желает  обмениваться  дополнительными
ключами,  IV и зашифрованными или аутентифицированными данными. В
больших  сетях  число распределяемых вручную и хранимых ККМ будет
весьма  большим.  Однако, поскольку ключи шифрования ключей могут
быть  ключевыми  парами  для  повышенной  защиты  и  обычно имеют
больший,   чем   KD,   криптопериод,   частота  их  распределения
снижается.   Ключевые   центры   ЦРК   и   ЦПК   позволяют  вести
централизованный  контроль  управления  ключами  в вычислительной
сети.  Они  позволяют двум сторонам, которые не разделяют ККМ или
не  способны генерировать и приобретать новые ключи, обмениваться
ключами  при  помощи  взаимно  доверяемой  третьей  стороны,  или
ключевого  центра  (рис.2).  Стороны  должны разделять ККМ-пару с
этим  центром,  который  может  управляться  владельцем  сети или
некоторой   доверенной  стороной.  Если  одна  из  сторон  желает
установить  ключи  с  другой  стороной,  но  ни одна из сторон не
способна  генерировать или приобретать ключи, они могут запросить
ключи  у  ЦРК  при помощи RSI. ЦРК генерирует необходимые ключи и
посылает  их  в  ответном  сообщении  на запрос (RTR) отправителю
запроса.  Последний  отправляет  их  стороне, с которой требуется
разделить   ключи   (конечному   получателю).  RTR  содержит  два
одинаковых  набора  ключей.  Один набор заверяется и шифруется на
ключевой  паре  шифрования  ключа,  разделяемой с отправителем, а
другой  набор - на паре, разделяемой с конечным получателем. Если
одна  из сторон желает установить ключи с другой стороной, но при
этом хочет сама генерировать ключи, то можно зашифровать ключи на
ключе  шифрования  ключа, разделяемом с ЦПК, и послать их в ЦПК в
запросном   служебном   сообщении  (RFS).  ЦПК  дешифрует  ключи,
заверяет  и перешифровывает их на ключевой паре шифрования ключа,
разделяемой  с  конечным  получателем  и возвращает их инициатору
запроса в RTR. Запрашивающая сторона посылает зашифрованные ключи
конечному получателю. При работе с ЦРК и ЦПК в случае обнаружения
получателем  ключей ошибки в центр посылается служебное сообщение
об  исправлении  ошибки (ERS), чтобы процесс мог повториться. Все
ключи,   которыми  обмениваются  центр  и  сторона,  должны  быть
заверены, чтобы ими не могла воспользоваться сторона, отличная от
законного   получателя.   Ключевые  центры  обеспечивают  большую
гибкость   и   эффективность   автоматизированного  распределения
ключей.  Отпадает  необходимость  в  том,  чтобы  каждая  сторона
разделяла  ККМ  с  каждой  другой стороной в сети. Каждая сторона
должна  лишь  разделять  ККМ  с  ключевым центром. Таким образом,
значительно  сокращается число распределяемых вручную ККМ. Обычно
стоимость  использования  ключевого  центра  превышает  стоимость
прямого  обмена  ключами.  Для  уменьшения  стоимости две стороны
могут   сперва   обменяться   КК   при  помощи  центра,  а  затем
использовать  протоколы прямого распределения для обмена KD и IV.
Заключение  Методы,  предложенные  в  Х9.17,  обеспечивают единый
процесс   автоматизированного   распределения   ключей   в  сетях
несовместимых вычислительных систем и криптоустройств. Эти методы
будут   развиваться   с  ростом  использования  сетей.  Готовится
дополнение  к  стандарту  касательно составных ключевых центров в
сетях.  НБС  сыграло  важную  роль в подготовке стандартов Х9.9 и
Х9.17  и  обеспечивает  поддержку банков, Казначейства и торговли
при   внедрении   стандарта.   На   основе   стандартов   в   НБС
разрабатывается  УУК, которое будет испытано на экспериментальной
ЛВС  для  демонстрации  возможности внедрения высококачественных,
недорогих  функций  управления ключами, особенно ключевого центра
на  микрокомпьютерной  технологии.  Литература 1. ANSI X3.92-1981
DEA  2.  ANSI  X3.106-1982  Режимы  работы  DEA 3. ANSI X9.9-1982
Аутентификация  сообщений  4.  ANSI X9.17-1985 Управление ключами
(оптовы   сделки)   5.   Branstad   D.K.   Security  of  computer
communications/IEEE  Comm.  Society  Mag., pp.33-40, Nov. 1978 6.
Dept.  of  Treasury,  Criteria  for  testing & evaluating message
Authentication  technology, EFTC Task Force, Jan. 28, 1985 7. Fed
Standard    1027,   GSA,   Общие   требования   к   оборудованию,
использующему  DES,  Apr  14,  1982  8.  NBS,  DES  9.  Smid M.E.
Integrating  the  DES  into  computer networks/IEEE Tr. on Comm.,
v.29, N65, p.762-772, 1981
 

Оставит комментарий