ЗАЩИТА   ГОСУДАРСТВЕННЫХ  И  ПРОМЫШЛЕННЫХ  СЕКРЕТОВ  Национальная
инфраструктура для криптографии с открытым ключом. Как отмечаетсм
в  журнале  IЕЕЕ  Соmmuniсаtiоn Маgazinе, криптография с открытым
ключом  требует,  чтобы  каждый пользователь имел секретный ключ,
известный  только  ему,  и  общедоступный открытый ключ. При этом
возникает  вопрос:  как может пользователь А, получивший открытый
ключ   пользователя   В,  быть  уверенным  в  его  подлинности  и
принадлежности  именно  пользователю  В? Этот вопрос имеет важное
значение,  так  как  от целостности и подлинности открытого ключа
зависят  выполняемые  криптосистемой  с  открытым  ключом функции
шифрования   и   применение   цифровой   подписи.  При  небольшом
количестве  пользователей  системы проблема целостности открытого
ключа  и  его принадлежности решается путем просто ручного обмена
открытыми ключами и ввода их в постоянную память на компакт-диске
или другим способом. Однако, если система должна использоваться в
национальном  или  международном  масштабе для проведения деловых
операций,   возникает  необходимость  получения  открытых  ключей
электронным   слособом   с   высокой  степенью  подтверждения  их
целостности  и принадлежности определенным пользователям. Один из
вариантов  решения этой проблемы основан на использовании техники
цифровой подписи. Администрация сети Intеrnеt и МККТТ разработали
концепцию  сертификации  открытых ключей для упрощения способа их
распространения  с обеспечением высокой степени целостности. Суть
этой  концепции  состоит в подтверждении принадлежности открытого
ключа   определенному  пользователю  цифровой  подписью  третьей,
нейтральной  и  пользующейся доверием стороны. Схема сертификации
открытых ключей может использоваться рекурсивно для генерирования
последовательности цифровых подписей. В общем случае она работает
следующим  образом.  Отправитель  сообщения передает его со своей
цифровой подписью получателю; если получатель имеет открытый ключ
отправителя,  он  может проверить его подпись. Если же получатель
не  имеет  открытого  ключа  отправителя,  он  может получить его
сертификат от третьей стороны (например, от определенного сервера
сети).  Получатель  может  проверить  сертификат  открытого ключа
отправителя,  зная  открытый  ключ сервера, выдавшего сертификат.
Если  получатель  не  имеет  этого  ключа, он получает сертификат
сервера. Получатель может повторять этот процесс до тех пор, пока
он  не  получит  открытый  ключ  третьей  стороны  и признает его
достоверным.  Действуя  в  обратном  порядке,  получатель  может,
пользуясь  открытым  ключом  в сертификате отправителя, проверить
его   цифровую  подпись  под  полученным  сообщением.  Сертификат
открытого ключа присваивается отдельным пользователям системы или
представителям организаций. В процессе эксплуатации системы может
возникнуть   необходимость   отмены   действующего   сертификата,
например, в случае компрометации открытого ключа, организационных
изменений  у  пользователей  и  т. д. В этих случаях пользователь
должен  обратиться  в  службу,  выдавшую  сертификат,  с просьбой
объявить его недействительным и заменить другим. Для этого должен
быть  предусмотрен  соответствующий  механизм. Администрация сети
Intеrnеt  и  МККТT  приняли  в  качестве  такого механизма список
сертификатов   СRL(Сеrtifiсаtе   Rеvоcаtiоn   List),   признанных
недействительными.  Это  подтверждается  цифровой падписью службы
или  организации,  выдавшей данный сертификат. Рекомендация МККТТ
Х.509    по   электронной   почте   повышенной   безопасности   с
использованием  сети  Intеrnеt  и  стандарт  Х9.30  Американского
национального  института  стандартов  АNSI  по  безопасности  для
финансового  сообщества предлагают несколько отличающиеся форматы
сертификата   открытого   ключа.  Этот  формат  должен  содержать
следующие  основные  элементы:  - порядковый номер сертификата; -
имя   держателя  сертификата  (кому  принадлежит  соответствующий
открытый   ключ);  -  идентификатор  алгоритма  цифровой  подписи
держателя  сертификата (например, алгоритмов RSА, DSS, ЕI Саmаl'а
и  др.); - открытый ключ держателя сертификата и его параметры; -
период   действия   сертификата;   -   служба   или   организация
(доверительная  сторона),  выдавшая  сертификат;  - идентификатор
алгоритма   цифровой   подписи  службы,  выдавшей  сертификат;  -
открытый  ключ  службы,  выдавшей  сертификат, и его параметры; -
цифровая   подпись   службы,   выдавшей   сертификат.   В  список
недействительных  сертификатов  включаются  следующие сведения: -
держатель  списка; - дата начала этого списка; - дата составления
нового списка; - записи недействительных сертификатов (порядковые
номера  сертификатов  и даты прекращения их действия); - алгоритм
цифровой  подписи  службы,  выдавшей  сертификат; - открытый ключ
службы,  выдавшей сертификат, и его параметры; - цифровая подпись
службы,   выдавшей   сертификат.  Сертификат,  действие  которого
приостановлено,   навсегда  остается  в  списке.  Он  может  быть
исключен  из  списка  только  по  истечении  срока  его действия.
Степень   доверия  получателя  сообщения  к  содержащейся  в  нем
цифровой  подписи  зависит  от того, какие требоваиия учитывались
при  формировании  сертификата.  К таким требованиям относятся: -
размеры  простых  чисел,  используемых  для  генерации  ключей; -
качество программного обеспечения для генерации ключей (например,
программ  выбора простых чисел, генерации случайных чисел и др.);
-  квалификация,  требуемая  для получения сертификата (т. е. кто
может  попучить сертификат); - идентификация и аутентификация при
регистрации   сертификата;   -   периодичность   выпуска   списка
недействительных  сертификатов;  -  обеспечение  безопасности при
генерации   и   регистрации   сертификатов;   -   частота  замены
сертификатов   (аналогично  частоте  смены  паролей).  Назначение
инфраструктуры   криптосистем   с   открытым   ключом  состоит  в
облегчении   генерации   и  распределения  сертификатов  открытых
ключей.  Если  речь  идет  об  инфраструктуре  национального  или
международного   масштаба,   то   в   нее  могут  входить  многие
организации,  выдающие  сертификаты  отдельным пользователям. Они
называются     уполномоченными     организациями.     Архитектура
инфраструктуры   определяет   место   и  роль  этих  организаций.
Инфраструктура  должна  быть  достаточно  гибкой  и эффективной с
точки  зрения  конечного  пользователя и допускать расширения для
обслуживания  большого количества новых пользователей. Она должна
быть  построена так, чтобы свести к минимуму количество операций,
выполняемых   пользователем   для   получения   открытого   ключа
отправителя  сообщения,  так  как  эти  операции требуют большого
объема   вычислений.  Модель  инфраструктуры  для  сети  Intеrnеt
включает   четыре   уровня  уполномоченных  организаций.  Верхний
уровень  -  зто  общенациональный  узел,  являющийся центром всей
инфраструктуры.     Этот    центр,    названный    уполномоченной
организацией,  одобряющей  общую  политику  РАА (Роliсу Аррrоving
Authоritу),    утверждает   политику   применения   сертификатов,
разработанную  организациями  низших  уровней. Роль РАА состоит в
определении обоснованности создания новых узлов на низших уровнях
с  учечом их особенностей, количества обслуживаемых пользователей
и  принятой ими политики распределения и применения сертификатов.
РАА    обеспечивает   также   согласованность   политики   выдачи
сертификвтов   открытых  ключей  и  соответствие  ее  требованиям
пользователей.   РАА  выдает  сертификаты  организациям  и  узлам
второго   уровня.   На   этом   уровне  находятся  уполномоченные
организации,  утверждающие  политику  введения  сертификатов  для
следующего   уровня.   Эти   организации,   получившие   название
РСА(Роliсу Сеrtifiсаtiоn Аuthоritу), выдают сертификаты для узлов
третьего   уровня.  Эти  узлы,  или  уполномоченные  организации,
выдаюшие  сертификаты (СА - Сеrtifiсаtiоn Аuthоrity), обслуживают
пользователей,   охваченных   инфраструктурой   с   центром  РАА.
Пользователи  находятся на четвертом уровне инфраструктуры. Между
третьим и четвертым уровнями может быть промежуточный уровень ОRА
(Оrgаnizatiоn   Rеgistrаtiоn   Аuthоritу),   выполняющий  функции
аутентификации  пользователей  и  определения их принадлежности к
организациям,  обслуживаемым данной инфраструктурой. Этот уровень
не   выдает   сертификатов.   Возможны   два   варианта  иерархии
международной  инфраструктуры.  По  одному  варианту национальные
центры (РАА) могут взаимодействовать друг с другом и обмениваться
сертификатами.  По  второму  варианту  национальные  центры (РАА)
подчиняются   международному   центру,   управляемому  агентством
обьединившихся  наций.  Международный  центр  выдает  сертификаты
национальным  центрам.  Взаимодействие национальных центров может
также  достигаться  на  основе  двусторонних  соглашений с учетом
международного    положения.    Узлами    РСА   в   международной
инфраструктуре  могут  быть правительственные агентства и большие
корпорации,    а   узлы   СА   могут   формироваться   различными
организациями,   подчиненными   РСА.   В   связи   с   непрерывно
возрастающим  применением  электронных средств обмена информацией
все   большее   количество   организаний   (больших   и   малых),
правительственных   учреждений   разных  уровней  и  частных  лиц
осознает  необходимость  ведения  такого  обмена  в засекреченной
форме.   Для   этого   они   должны  обращаться  к  доверенным  и
уполномоченным  организвциям, выдающим сертификаты. Свою помощь в
этом  вопросе  предлагают  почтовая  служба  USPS  (United Status
Роstаl  Sеrviсе),  банки,  фирмы-изготовители кредитных карточек,
службы  связи. Предлагаемые ими услуги упрощают обмен информацией
и   взаимодействие  в  национальном  и  международном  масштабах.
Пользователям  предоставляется  возможность  выбора  предлагаемых
услуг  и  принятой  политики  выдачи  сертификатов уполномоченной
организации,  в системе которой он намерен работать. Пользователю
системы  обмена сообщениями с сертификацией открытых ключей важно
знать,   каких  это  потребует  от  него  дополнительных  затрат.
Основные   затраты   связаны   с   хранением   секретного   кпюча
пользователя и обращениями к списку недействительных сертификатов
открытых  ключей  СRL.  По одному из вариантов пользователь может
хранить свой секретный ключ на сравнительно дешевом гибком диске.
Однако  при  этом  он  должен полностью доверять рабочей станции,
имеющей доступ к этому ключу для формирования цифровой подписи. В
другом варианте секретный ключ может храниться в интеллектуальной
карточке  пользователя, генерирующей его цифровую подпись. В этом
варианте в затраты пользователя входят стоимость интеллектуальной
карточки  и карточного интерфейса. Более значительными могут быть
затраты,  связанные  с дополнением уже существуюшего оборудования
польэователя    считывателем    карточек.    В    рассматриваемой
инфраструктуре  получателю сообщения может потребоваться проверка
до  трех  сертификатов  (отправителя, СА и РСА) для подтверждения
подлинности  сообщения.  Пользователь  может сократить затраты на
необходимые  для  этого  сеансы  связи, применив метод хранения к
хэш-памяти наиболее часто используемые сертификаты и СRL. Затраты
на  проверку  сертификатов  и  обращения  к СRL составят основную
часть оперативных затрат в инфраструктуре РКI. Они будут зависеть
от  размеров  списка  СRL  и частоты его замены. Одна из наиболее
сложных  проблем, связанных с иерархией инфраструктуры, состоит в
том,   что   раскрытие  ключа  РАА  может  скомпрометировать  всю
инфраструктуру.  Финансовые мотивы могут побудить злоумышленников
или   организации   подкупить   обслуживающий  персонал  РАА  или
попытаться  раскрыть ключ РАА методом перебора всех возможных его
значений.  В связи с этим требуется дальнейшее изучение следующих
вопросов:  -  размер  ключа РАА; - частота смены ключа; - правила
пользования  этим ключом многими лицами; - оперативная реализация
частой  смены  ключа. Для реализации смены ключа необходимо иметь
средства   оповещения   об  этом.  Один  из  способов  состоит  в
использовании   предшествующего   ключа   РАА   для  сертификации
следующего  ключа.  Пусть,  например,  принимается,  что ключ РАА
действует  в  течение года. В первом полугодии ключ РАА считается
действительным  и  оперативным. В течение следующих шести месяцев
этот  ключ  может  быть  использован  для сертификации следующего
ключа  РАА.  Таким  образом,  пользователи  всегда могут получить
действующий  ключ  после регистрации. По окончании срока действия
ключа РАА они могут использовать текущий ключ для проверки нового
сертификата    РАА   и   извлечения   нового   открытого   ключа.
Инфраструктура РКI предусматривает создание ряда служб для выдачи
и проверки сертификатов и СRL. Пользователи должны сами решать, в
какой  мере  они  будут  использовать  эти службы. Например, если
пользователь  применяет  хэш-память для хранения сертификатов, он
должен  решить,  когда он будет (если будет) обновлять содержимое
этой  памяти  в  зависимости  от  замены  списка СRL. Детальность
проверки достоверности сообщения получателем зависит от характера
и  значимости транзакций. При малозначащих транзакциях получатель
сообщения может использовать сертификат отправителя, хранящийся в
его  хэш-памяти.  В  других случаях он может проверить сертификат
отправителя  по  последнему списку СRL. Может также потребоваться
проверка  сертификатов  не  только  отправителя, но и всех узлов,
участвующих    в    передаче    сообшения.   Инфраструктура   РКI
предоставляет    пользователям   возможность   проведения   таких
проверок. Архитектура различных инфраструктур РКI может строиться
в  соответствии  с  различными  стандартами и для разных форматов
сертификатов  и  списков  СRL. Эти различия могут сделать процесс
верификации   сертификатов  неоправданно  сложным  для  конечного
пользователя.  До  настоящего  времени  сделано  очень  мало  для
практического   внедрения  инфраструктуры  РКI.  Так,  фирма  RSА
предлагает  услуги  своей  службы  сертификации  открытых ключей.
Фирма  BBN  разработала  коммерчески доступный продукт Sаfеkеуреr
для  безопасного формирования сертификатов открытых ключей. Но ни
одна  из  фирм  не  предприняла  шагов в направлении разработки и
реализации  общенациональной  инфраструктуры.  Практический опыт,
касающийся   правовой   стороны,   ответственности,   доверия   и
управления   национальной   инфраструктурой,может  быть  накоплен
только   в  процессе  реального  применения  инфраструктуры,  При
создании   национальной   инфраструктуры  РКI  возникает  вопрос,
требующий  разрешения  в  самом начале. Это вопрос о национальной
уполномоченной  организации  РАА,  определяющей  общую  политику.
Ясно, что ей не может быть отдельная общественная организация или
частная  компания.  В  США  в  нее  должны  входить представители
криптографических  служб, политики и зксперты по проблемам РКI от
правительства  и  промышленности.  Это  могут  быть представители
Национального института стандартов и технологий (NISТ), Агентства
национальной  безопасности, административно-бюджетного управления
(ОМВ), главного контрольно-финансового управления (GАО), почтовой
службы   USРS,   фирмы   RSА,   компании   Intеrnеt  и  др.  IЕЕЕ
Соmmuniсation Маgаzinе.- 1994 .- 32, М 9 .Р. 70-74.
 

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