125 Кібербезпека / 5 Курс / 5.2_Методи побудови і аналізу криптосистем / Література / пiдручник
.pdf
2. Инфраструктура криптасистем |
109 |
Х9.55 - стандарт США дЛЯ финансовой индустрии;
PKIX - проект стандарта штр на базе стандарта X.509v3, адап тирующий положения этого стандарта для использования в сети
Intemet;
APКI - архитектура дЛЯ ИОК, описанная в документах The Open
Group.
Однако использование идентификационных сертификатов не всегда желательно для пользователей, так как при этом может про исходить доступ к информации, не имеющей отношения к тому слу чаю, по которому необходим данный конкретный факт доступа к сертификату. Возможность однозначно установить личность вла дельца по сертификату может привести к установлению «тотального контроля» над участниками криптосистемы. В связи с этим было предложено использовать другую форму сертификатов.
Атрибутныв сертификаты связывают открытый ключ с одним или более «атрибутов», которые в соответствии со стандартом Меж дународного телекоммуникационного союза Х.501 (эквивалентный стандарт - ISOIIEC 9594-2) определяются как «информация любого типа». Таким образом, один и тот же участник в зависимости от си туации и используемой прикладной программы может предстать в
разных «ипостасях», между которыми невозможно установить одно
значную связь. К примеру, атрибутомможет быть роль пользователя
в информационной системе, например путем указания его должно сти. Тогда можно реализовать модель управления доступа «по ро
лям», т. е. участники системы, занимающие одну и ту же должность,
имеют абсолютно одинаковые права в системе и невозможно уста новить, кто именно из них совершил конкретное действие с приме нением данного конкретного сертификата.
Наиболееразработаннымии широко применяемыми на практике логическими моделями инфраструктуры открытых ключей на осно ве атрибутныхсертификатовявляются:
Х9.57 - стандарт США дЛЯ финансовой индустрии;
SPКI - проект стандарта IEТF дЛЯ использования в сети Intemet.
Удостоверяющийцентр (центр сертификацииоткрытых ключей) - это специально выделенный участник криптосистемы, кото
рому доверяют все остальные участники (ецентр доверия»), чья
110 Запечников С. В. Криптографическиепротоколы и их применение
подпись служит гарантией ПОДЛИНН'ости ключей и который выпол няет следующие функции:
1) сбор сведений об участниках системы, необходимых для сер тификации: имя, почтовый адрес, права доступа, должность, номер кредитной карты и т. п. (зависит от конкретного приложения);
2)генерация и рассылка (либо помещение в общедоступное хранилище) сертификатов открытых ключей;
3)уничтожение сертификатов с истекшим сроком годности;
4)обновление сертификатов;
5)аннулирование сертификатов.
Аннулирование сертификата может потребоваться в случаях,
когда срок санкционированного использования открытого ключа
участника системы прерывается досрочно, ранее, чем это преду
смотрено принятым в системе регламентом, например при ком
прометации секретного ключа участника криптосистемы, соот ветствующего данному открытому ключу, при удалении (выбы тии) владельца ключа из системы, при смене роли пользователя в системе (перемещении пользователя). Аннулирование сертифика та - это чрезвычайное обстоятельство, о котором необходимо оповестить всех участников криптосистемы. Существует два спо соба решения этой задачи.
Проверка статуса сертификата в режиме реального времени. Для этого требуется выполнение специального протокола с удосто веряющим центром, который отвечает на вопрос, не был ли запро шенный сертификат аннулирован.
Периодическое создание и рассылка списков аннулированных
сертификатов (Certificate Revocation List - CRL). Формат CRL оп
ределен в стандарте 1ТU X.509v2 (рис. 2.4).
Второй способ на практике используется чаще. Однако у него есть один существенный недостаток: между двумя последователь ными рассылками списка аннулированных сертификатов всегда су ществует какой-то временной «зазор», т. е. об аннулировании сер тификата какого-либо участника все остальные участники узнают не мгновенно, а только по прошествии некоторого времени. Наличие
такого разрыва создает угрозу несанкционированного использова
ния аннулированного ключа.
2. Инфраструктура критносивтем |
111 |
Идентификатор алгоритма цифРОВОЙ ПОДПИСИ, ИСПОJlliзуемого удосто-
веряюшим центром
имя удостоверяющего центра (дирекгориальное имя по станпарту Х500)
Дата иБремя текущего обновления
Дата и время следующего обновления
I
I
Серийный номер сертификата
Датааннупирования
г-
Дополнительные ПОЛЯ |
t - |
|
|
Поле расширения
Цифроваяподписьудостоверяющегоцентра под всемипредыдущими
полями
Рис. 2.4. Формат списка аннулированных сертификатов по стандарту тзХ509 v2
Удостоверяющий центр рассылает всем участникам системы свой открытый ключ, который нужен им для проверки подписи на сертификатах. Считается, что подменить его невозможно в силу трех причин: массовости рассылки, периодического повтора и об
щедоступности.
В криптосистемах с большим числом участников или с большой интенсивностью потока требований к удостоверяющему центру функции регистрации участников передко возлагают на специально
выделяемый центр регистрации (Registration Authority - RA).
Сертификаты всех участников криптосистемы могут либо хра ниться в специальном общедоступном хранилище, либо рассылаться по сети. На практике преимущественно используется первый спо соб, причем физически хранилище сертификатов чаще всего реали зуется либо с использованием директориального сервиса (директо рия, к которой открыт доступ на чтение всем участникам), либо ве6 сервиса (веб-страница, с которой все участники криптосистемы мо
гут забирать сертификаты).
112 Запечников С. В. Криптографическиепротоколы и ю; применение
Преимущество сертификата в том, что два участника системы,
доверяющие одному и тому же удостоверяющему центру, могут не знать и не хранить открытые ключи никаких других абонентов, а при необходимости обратиться в хранилище сертификатов и полу чить необходимые ключи. Для этого ему достаточно знать только открытый ключ удостоверяющего центра. Это позволяет применять метод сертификации открытых ключей в криптосистемах со сколь угодно большим и даже неопределенным числом участников, где
все участники не покрыты сетью непосредственных контактов меж
ду собой.
Теперь для того, чтобы узнать открытый ключ любого интере сующего его абонента, участнику криптосистемы (обозначим его В) необходимо однократно приобрести аутентичный открытый ключ удостоверяющего центра (что технически реализовать не сложно). Далее для установления связи с абонентом А ему необходимо:
1) приобрести сертификат открытого ключа А одним из следую щих способов: обратившись в хранилище сертификатов, непосред ственно получив его от удостоверяющего центра или от абонента А (зависит от порядка, установленного в системе);
2) выполнить процедуру проверки сертификата, состоящую из следующих действий:
проверки текущей даты и времени и сравнения с периодом дей ствия сертификата; проверки действительности в данный момент времени открытого
ключа самого удостоверяющего центра;
проверки подписи удостоверяющего центра на сертификате от крытого ключа абонента А, используя открытый ключ удостове
ряющего центра;
проверки, не был ли сертификат аннулирован к текущему мо
менту времени.
3) в случае, если все проверки окончились с положительным ре зультатом, принять открытый ключ, извлеченный из сертификата А как аутентичный ключ.
Далее В может использовать открытый ключ абонента А для вы полнения любых необходимых ему криптографических алгоритмов
или протоколов. К примеру, участники А и В, приобретя таким обра-
2. Инфраструктуракриптосистем |
113 |
зом открытые ключи друг друга, могут выработать общий секрет ный ключ для симметричной криптосистемы.
Хотя сертификат является вспомогательным средством для транспортировки и обеспечения подлинности открытого ключа, он, как и сам ключ, имеет свой жизненный цикл. В его жизненном цик ле можно выделить те же стадии и ряд состояний, в которых пребы вает сертификат: создание, рассылка, штатное использование, об новление или аннулирование, уничтожение сертификата.
Недостаток метода сертификации открытых ключей заключается в том, что участникам криптосистемы после проверки сертификата часто все равно необходим доступ в реальном масштабе времени в базу данных с информацией о других участниках криптосистемы (например, для проверки аннулирования сертификата либо для того, чтобы получить какие-то дополнительные данные об этом участни ке, необходимые для работы прикладных программ). Это не всегда удобно, поэтому сейчас наблюдается «откат» к модели иак с удо стоверяющим центром, работающим не в отложенном режиме, а в реальном масштабе времени.
2.1.7. Особенности управления ключами в сложных (многодоменных) информационных системах
Домен безопасности (security domain) - территориально распре
деленный сегмент информационной системы, находящийся под еди
ным административным управлением, в котором проводится опре
деленная, единая политика безопасности. Как правило, управление безопасностью домена осуществляет администратор, которому до веряют все абоненты.
Ключевое понятие для обеспечения безопасности в распреде ленных информационных системах - доверие. В первом приближе
нии доверие следует понимать как гарантии качества ключевого ма
териала одних участников криптосистемы, предоставляемые другим
участникам системы, которые дают возможность организовать меж ду ними безопасный канал обмена данными. Источником отношения доверия является центр доверия (администратор). Поддерживается это отношение посредством выработки общих с центром доверия секретных ключей или паролей для каждого субъекта (в случае сим метричных криптосистем) или посредством обладания аутентичным
114 Запечников С. В. Криптографические протоколы 11их примененив
открытым ключом центра доверия (в случае асимметричных крип тосистем), что позволяет установить безопасный канал связи между субъектами информационной системы и центром доверия или меж ду различными субъектами. Домены могут быть организованы ие рархически и формировать б6льшие домены.
Доверие между двумя доменами. Пусть А, В - два абонента, желающие связаться между собой безопасным образом, причем они принадлежат к разным доменам информационной системы: АЕ DА '
ВЕ Ds ; Тл и ТВ - центры доверия соответствующих доменов
(рис. 2.5).
|
|
Единый Л"~""'. "'"Ч' дсверия |
Домен DB |
||||||||
|
|
|
|
|
|
|
|
|
|
||
,..---------------------- ..-------- |
|
--- ----- |
---------------------_.._-------- -, |
|
|||||||
|
i:[ Центр доверия ТА |
1- |
|
(2) |
~- |
lI |
Центр доверия ТВ [!I |
|
|||
|
|
КАВ |
|
||||||||
|
|
|
|
|
|
|
|
|
|
||
|
~---t-------t------------- |
|
|
------------------~t----------..; |
|||||||
|
|
|
|||||||||
(1) |
(ЗА) |
|
|
|
|
|
|
. (3В) |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Абонент А |
1- |
|
(4) |
, J |
|
Абонент В |
|||
|
|
|
|
|
|||||||
|
I |
|
I~ |
|
~ |
I |
|
|
I |
||
Рис. 2.5. Установление отношения доверия между двумя доменами
Образование безопасного канала связи в симметричной критгто системе подразумевает, что абонентам необходим общий секретный ключ КлВ, известный только А, В и лицам, которым оба они доверя ют. Изначально таких ключей у них нет, да и лиц, которым доверя ют одновременно оба абонента, также может не быть.
Образование безопасного канала связи в асимметричной крипто системе предполагает, что абонентам необходимо установить отно шение доверия к их открытым ключам таким образом, чтобы обра зовался «мост доверия» между А иВ.
Вобоих случаях это возможно только при условии, что между ТА
иТВ уже существует отношение доверия. Оно образуется, например, в момент инсталляции криптосистемы. Если ТА и ТВ уже имеют ме жду собой отношение доверия, его можно использовать для уста
новления отношения доверия между А и В через цепочку (А,ТА),
2. Инфраструктура КРШllllОСllсmе.м |
115 |
(т.1'~J)'(ТВ'В)' если А и В, в свою очередь, доверяют своим центрам доверия. Если ТА и ТВ не имеют прямого отношения доверия, оно мо жет быть установлено с помощью третьего центрадоверия - Те и т. д.
Симметричные криптосистемы. Отношение доверия образуется при выработке гарантированно аутентичных общих секретных клю чей, которое осуществляется следующим образом:
1)А подает запрос в ТА на выработку ключа для связи с В (шаг 1 на рис. 2.5);
2)ТА И ТВ вырабатывают общий сеансовый ключ КАв (шаг 2);
3)ТА И ТВ соответственно передают КАв абонентам А и В, гаран тируя секретность и аутентичность (шаги ЗА и ЗВ);
4)А использует КАВ для прямой связи с В (шаг 4).
С точки зрения абонента А взятые вместе ТА, ТВ и отношение до верия (ТА, Тв) могут рассматриваться как единый, композитный центр доверия, с которым А связывается через ТА и который играет роль центра распределения ключей (центра трансляции ключей), по аналогии с простыми (однодоменными) схемами. Аналогичный взгляд создается и для абонента В, которому единый центр доверия доступен уже в лице центра доверия своего домена Тв.
Асимметричные криптосистемы. Доверие в асимметричных криптосистемах может быть установлено, основываясь на сущест
вующих отношениях доверия, происходящих от источника данных, посредством стандартных криптографических примитивов (цифро вой подписи, хеш-функции с ключом). А может приобрести дове ренный открытый ключ В следующим образом:
1) А запрашивает у ТА доверенный открытый ключ абонента В (шаг 1 на рис. 2.5);
2)ТА приобретает его у ТВ с гарантированной аутентичностью (шаг 2);
3)ТА передает этот открытый ключ А с гарантированной аутен тичностью (шаг ЗА);
4)А использует этот открытый ключ для обеспечения безопас ности прямой связи с В (шаг 4).
В асимметричных криптосистемах чаще всего функции центра доверия Твьшолняет удостоверяющий центр.
116 Запечников С. В. Криптографическиепротоколы и ихприиененив
Модели доверия, включающие несколько центров сертифика ции. Существует много способов организации отношения доверия
между удостоверяющими центрами в асимметричных криптосисте мах с несколькими удостоверяющими центрами. Эти способы назы ваются моделями доверия (или топологиями сертификацищ и логи чески могут отличаться от физической ТОпологии сети (В частности,
коммуникационное звено еще не означает отношения доверия меж
ду связываемыми им узлами). Все они опираются на метод сертифи кации открытых ключей, изученный ранее. Отношение доверия между удостоверяющими центрами определяет; как сертификаты! подписанные одним удостоверяющим центром, могут быть исполь зованы или проверены абонентами, сертифицированными другим
удостоверяющим центром в другом домене.
Кросс-сертификат - сертификат, созданный одним удостове ряющим центром САх, удостоверяющий открытый ключ другого удостоверяющего центра САу. Будем обозначать такой кросс-
сертификат {САу}САх . Запись вида ({САх}САу,{САу}САх) называ
ется парой кросс-сертификатов, один из которых носит название прямого сертификата (jorward-certificate), другой - обратного сер
тификата (reverse-certijicate).
Сертификаты открытых ключей обеспечивают средства ДЛЯ по лучения аутентичных открытых ключей при условии, что прове ряющий имеет доверенный открытый ключ удостоверяющего цен тра, подписавшего сертификат. В случае наличия нескольких удо стоверяющих центров проверяющий может пожелать обладать аутентичным открытым ключом путем цроверки сертификата, под
писанного иным удостоверяющим центром, нежели тот, для которо ГО он владеет доверенным открытым ключом. В этом случае прове ряющий сможет так поступать лишь при условии, что может быть сконструирована цепочка сертификатов, соответствующая непре рывной цепи доверия от открытого ключа удостоверяющего центра, которому проверяющий доверяет, до открытого ключа, доверием к которому он желает обладать.
Цепочки сертификатов соответствуют направленным ребрам в графическом представлении модели доверия. Цель - найти после довательность сертификатов, соответствующую направленному пу ти - пути сертификации, начиная с узла, соответствующего уцосто-
2. Инфраструктура крunmосисmе.м |
117 |
веряющему центру, открытому ключу которого проверяющий дове
ряет априори, и кончая удостоверяющим центром, подписавшим сертификат открытого ключа, который подлежит проверке,
Рассмотрим пример. Пусть А - проверяющий, который желает проверить открытый ключ абонента В (рис. 2.6).
Рис. 2.6. К llрtuиеру отыскания цепочки сертификатов
Очевидно, что путь (СAs,СА4,САз) существует. {CA4}CAs- сер тификат открытого ключа Р4 удостоверяющегоцентра СА4, подпи санный удостоверяющим центром CA s. Цепочка сертификатов ({СА4}cAs, {САз}СА4) вместе с априорным доверием абонента А к
CA s позволяет А проверить подпись {СА4}СЛs для того, чтобы из
влечь доверенную копию ключа Р4 и использовать Р4, чтобы прове рить подпись {САз}СА4, чтобы извлечь доверенную копию Рз и за
тем использовать Рз, чтобы проверить аутентичность сертификата,
содержащего рв,
Если направленный путь в графе неизвестен априори, его нужно найти (построить) некриптографическими методами, что похоже на
решение задачи маршрутизации пакетов данных в сетях.
Рассмотрим теперь часто используемые модели доверия. Строго иерархическая модель доверия (рис. 2.7). Каждый або
нент начинает проверку цепочки сертификатов со своего корневого
узла. Эта модель называется также моделью корневых цепей, так как
118 Запечников С. В. Криптографические протоколы /l их примененив
все цепи доверия начинаются с корня. Эта модель реализует идею централизованного доверия.
Е/4) в}4)
Рис. 2. 7. Строго иерархическая модель доверия
Несколько таких деревьев могут быть скомбинированы в модель доверия, поддерживающую множество деревьев - лес. В этом случае между корнями деревьев заводятся кросс-сертификаты. Например, если подписан сертификат {САу}САх , это дает возможность пользо
вателям из дерева под управлением САх получить доверие к серти фикатам, подписанным САу, через цепи сертификатов, которые на чинаются с САх и тянутся через САу• Такую модель нередко назы вают мостовой моделью доверия, так как кросс-сертификаты между корнями деревьев образуют своего рода «мосты доверия».
В строго иерархической модели все пользователи, по существу, находятся в единственном домене, определенном корнем. Несмотря на тот факт, что, например, CA1 подписывает сертификат ключа
E1(1) , E1(1) доверяет корню CAs непосредственно, но не CA1• Ер) до
веряет СА) только косвенно через корень. Потенциально недостатки этой модели заключаются в следующем:
все доверие в системе зависит от корневого ключа;
цепочки сертификатов требуются даже для двух абонентов, ОТ
носящихся к одному И тому же удостоверяющему центру;