Алгоритмы асимметричного шифрования

Инфраструктура Открытого Ключа

Цифровая подпись обеспечивает аутентификацию отправителя, т.е. служит доказательством того, что сообщение было послано конкретным участником. Такая аутентификация с помощью цифровой подписи является более сильной, чем аутентификация с использованием общего секрета (пароля).

Сначала рассмотрим уязвимости, связанные с открытым ключом, и необходимость создания Инфраструктуры Открытого Ключа (Public Key Infrastructure - PKI). Затем определим ключевые термины, используемые в Инфраструктуре Открытого Ключа.

Одним из требований к алгоритмам цифровой подписи является требование, чтобы было вычислительно невозможно, зная открытый ключ KU, определить закрытый ключ KR. Казалось бы, открытый ключ KU можно распространять по небезопасным сетям и хранить в небезопасных репози-торях. Но при этом следует помнить, что при использовании цифровой подписи необходимо быть уверенным, что субъект, с которым осуществляется взаимодействие с использованием алгоритма открытого ключа, является собственником соответствующего закрытого ключа. В противном случае возможна атака, когда оппонент заменяет открытый ключ законного участника своим открытым ключом, оставив при этом идентификатор законного участника без изменения. Это позволит ему создавать подписи от имени законного участника и читать зашифрованные сообщения, послан-ные законному участнику, используя для этого свой закрытый ключ, соответствующий подмененному открытому ключу. Для предотвращения такой ситуации следует использовать сертификаты, которые являются структу-рами данных, связывающими открытый ключ с субъектом. Для связывания необходимо наличие доверенного сертификационного центра (Certification Authority – СА), который проверяет идентификацию субъекта и подписы-вает его открытый ключ и некоторую дополнительную информацию своим закрытым ключом.

Целью PKI является предоставление доверенного и действительного открытого ключа участника, а также управление всем жизненным циклом сертификата открытого ключа.

Основным понятием Инфраструктуры Открытого Ключа является понятие сертификата.

Сертификат участника, созданный СА, имеет следующие характеристики:

• Любой участник, имеющий открытый ключ СА, может восстановить открытый ключ участника, для которого СА создал сертификат.
• Никто другой, кроме данного сертификационного центра, не может модифицировать сертификат без обнаружения этого проверяющей стороной.

Мы будем рассматривать сертификаты Х.509, хотя существует доста-точно много сертификатов других форматов.

Стандарт Х.509 первоначально являлся частью стандарта Х.500 и описывал основные требования к аутентификации в Каталогах Х.500. Но Х.509 используется не только в контексте сервиса Каталога Х.500. Сертификаты, определяемые данным стандартом, используются практически всеми программными продуктами, относящимися к обеспечению сетевой безопасности.

Стандарты ITU-TX.509 и ISO/IEC 9594-8, которые впервые были опубликованы в 1988 году как часть рекомендаций Х.500 Директории, определили формат сертификата Х.509. Формат сертификата в стандарте 1988 года называется форматом версии 1 (v1). Стандарт Х.500 был пересмотрен в 1993 году, в результате чего было добавлено несколько новых полей в формат сертификата Х.509, который был назван форматом версии 2 (v2).

Опыт реализации первой и второй версий говорит о том, что форматы сертификата v1 и v2 имеют ряд недостатков. Самое важное, что для хранения различной информации требуется больше полей. В результате ISO/IEC, ITU-T и ANSI X9 разработали формат сертификата Х.509 версии 3 (v3). Формат v3 расширяет формат v2, обеспечивая возможность добавления дополнительных полей расширения. Конкретные типы полей расширения могут быть определены в стандартах или определены и зарегистрированы любой организацией или сообществом. В 1996 году стандартизация базового формата v3 была завершена.

Стандарт ISO/IEC, ITU-T и ANSI X9 являются очень общими, чтобы применять их на практике. Для того чтобы разрабатывать интероперабельные реализации, использующие сертификаты Х.509 v3, необходимо четко специфицировать формат сертификата Х.509 v3. Специалисты IETF разработали профиль сертификата X.509 v3 и опубликовали его в RFC 3280.

Основные элементы сертификата представлеы в таблице 1.8.

Часто используется следующая нотация для обозначения сертификата:

- сертификат пользователя А, выданный сертификационным центром СА.

СА подписывает сертификат своим закрытым ключом. Если соответствующий открытый ключ известен проверяющей стороне, то она может проверить, что сертификат, подписанный СА, действителен.

Так как сертификаты не могут быть изменены без обнаружения этого, их можно разместить в общедоступной директории и пересылать по открытым каналам связи без опасения, что кто-то может их изменить.

В любом случае если В имеет сертификат А, В уверен, что сообщение, которое он зашифровывает открытым ключом А, никто не может просмотреть, и что сообщение, подписанное закрытым ключом А, не изменялось.

Таблица 4.1

При большом количестве пользователей неразумно подписывать сертификаты всех пользователей у одного СА. Кроме того, если существует единственный СА, который подписывает сертификаты, каждый пользователь должен иметь копию открытого ключа СА, чтобы проверять подписи. Этот открытый ключ должен быть передан каждому пользователю абсолютно безопасным способом (с обеспечением целостности и аутентифика-ции), чтобы пользователь был уверен в подписанных им сертификатах. Таким образом, в случае большого количества пользователей лучше иметь несколько СА, каждый из которых безопасно предоставляет свой открытый ключ некоторому подмножеству пользователей.

Теперь предположим, что А получил сертификат от уполномоченного органа СА₁, и В получил сертификат от уполномоченного органа СА₂. Если А не знает безопасным способом открытый ключ СА₂, то сертификат В, выданный СА₂, для него бесполезен. А может прочитать сертификат В, но не в состоянии проверить подпись. Тем не менее, если два СА могут безопасно обмениваться своими открытыми ключами, возможна следующая процедура для получения А открытого ключа В.

1. А получает сертификат СА₂, подписанный СА₁. Так как А знает открытый ключ СА₁ надежным способом, А может получить открытый ключ СА₂ из данного сертификата и проверить его с помощью подписи СА₁ в сертификате.

2. Затем А получает сертификат В, подписанный СА₂. Так как А теперь имеет открытый ключ СА₂ надежным способом, А может проверить подпись и безопасно получить открытый ключ В.

Для получения открытого ключа В А использует цепочку сертификатов. В приведенной выше нотации эта цепочка выглядит следующим образом:

Аналогично В может получить открытый ключ А с помощью такой же цепочки:

Данная схема не обязательно ограничена цепочкой из двух сертификатов. Для получения цепочки может использоваться путь СА произвольной длины. Цепочка, содержащая N элементов, выглядит следующим образом:

В этом случае каждая пара СА в цепочке (СА_i , СА_i+1 ) должна создать сертификаты друг для друга.

Все эти сертификаты CA необходимо разместить в каталоге, и пользователи должны иметь информацию о том, как они связаны друг с другом, чтобы получить путь к сертификату открытого ключа другого пользователя. Это определяет Инфраструктуру Открытого Ключа, изучению которой и посвящены следующие лекции.

Когда сертификат выпущен, считается, что он будет использоваться в течение всего своего периода действительности. Однако могут произойти события, в результате которых сертификат станет недействительным до завершения своего периода действительности. К таким событиям относится изменение имени, изменение связывания между субъектом и СА (например, сотрудник увольняется из организации) и компрометация или предположение компрометации соответствующего закрытого ключа. При таких обстоятельствах СА должен отменить сертификат.

Х.509 определяет следующий способ отмены сертификата. Предполагается, что каждый СА периодически выпускает подписанную структуру данных, называемую списком отмененных сертификатом (Certificate Revo-cation List – CRL). CRL является помеченным временем списком, который подписан СА или специальным выпускающим CRL и в котором перечис-лены отмененные на текущий момент сертификаты с неистекшим периодом действительности, указанным в сертификате. Данный список становится свободно доступен в открытом репозитории. Каждый отмененный сертификат идентифицируется в CRL своим серийным номером. Когда использующая сертификат система получает сертификат, эта система не только проверяет подпись сертификата и действительность, но также полу-чает свежий CRL и проверяет, не находится ли в этом CRL серийный номер сертификата. Понятие "свежий" может зависеть от локальной политики, но обычно означает самый последний выпущенный CRL. Новый CRL выпускается регулярно (например, каждый час, день или неделю). При получении уведомления об отмене запись добавляется в CRL.

Преимущество данного метода отмены состоит в том, что CRL могут распространяться теми же способами, что и сами сертификаты, а именно через небезопасные серверы и коммуникации.

При этом недостатком данного метода отмены CRL является то, что точность отмены ограничена периодом выпуска CRL. Например, если об отмене сообщено в текущий момент, то об отмене не будут оповещены использующие сертификат системы до тех пор, пока не будет выпущен новый CRL – это может занять час, день или неделю, в зависимости от частоты создания CRL.

Как и формат сертификата Х.509 v3, для того, чтобы обеспечить интероперабельность реализаций различных производителей, необходимо иметь строгий формат Х.509 CRLv2. Существуют также специальные про-токолы и соответствующие им форматы сообщений, поддерживающих on-line оповещения об отмене. On-line методы оповещения об отмене могут применяться в некоторых окружениях как альтернатива CRL. On-line проверка отмены может существенно уменьшить промежуток между отправ-кой сообщения об отмене и получением этой информации проверяющей стороной. После того как СА получает сообщение об отмене, любой запрос к on-line сервису будет корректно отображать действительность сертификата. Однако эти методы навязывают новые требования безопасности: проверяющая сторона должна доверять on-line сервису действительности, в то время как репозиторий не обязательно должен быть доверяемым.

В Инфраструктуре Открытого Ключа используются следующие термины и понятия.

Public Key Infrastructure (PKI)– инфраструктура открытого ключа – это множество аппаратуры, ПО, людей, политик и процедур, необходимых для создания, управления, хранения, распределения и отмены сертифика-тов, основанных на криптографии с открытым ключом.

End Entity (ЕЕ)– конечный участник, для которого выпущен данный сертификат. Важно заметить, что здесь под конечными участниками подразумеваются не только люди и используемые ими приложения, но также и исключительно сами приложения (например, для безопасности уровня IP).

Certificate Authority (CA)– сертификационный или удостоверяющий центр – это уполномоченный орган, который создает и подписывает сертификаты открытого ключа. Дополнительно СА может создавать пары закрытый/открытый ключ для конечного участника. Важно заметить, что СА отвечает за сертификаты открытого ключа в течение всего времени их жизни, а не только в момент выпуска.

Public Key Certificate (PKC)– сертификат открытого ключа или просто сертификат – это структура данных, содержащая открытый ключ конечного участника и другую информацию, которая подписана закрытым ключом СА, выпустившим данный сертификат.

Registration Authority (RA)– регистрационный центр - необязательный участник, ответственный за выполнение некоторых административных задач, необходимых для регистрации конечных участников. Такими задачами могут быть: подтверждение идентификации конечного участника; проверка значений, которые будут указаны в создаваемом сертификате; проверка, знает ли конечный участник закрытый ключ, соответствующий открытому ключу, указанному в сертификате. Заметим, что RA сам также является конечным участником.

Причины, по которым могут создаваться RA, разделяют на технические и организационные. К техническим относятся следующие причины:

• Если используется аппаратный токен, то не все конечные участники имеют необходимое оборудование для его инициализации; оборудование RA может включать необходимую функциональность, что также может быть вопросом политики.
• Не все конечные участники могут иметь возможность опубликовать свои сертификаты; для этого может использоваться RA.
• RA может иметь возможность выпускать подписанные запро-ы отмены от имени конечного участника, тогда как конечный участник не всегда имеет возможность сделать это (например, если пара ключей потеряна).

Организационные причины для использования RA следующие:

• Может оказаться более эффективным сконцентрировать некоторую функциональность в оборудовании RA, чем иметь данную функциональность для всех конечных участников (особенно если используется специальное оборудование для инициализации токена).
• Наличие RА может уменьшить число необходимых СA.
• RA могут быть оптимальнее размещены с целью идентификации людей и присваивании им "электронных" имен, особенно если СА физически удален от конечного участника.
• Во многих случаях уже существуют определенные административные структуры, которые могут играть роль RA.

Выпускающий CRL- необязательный компонент, которому СА делегирует функции опубликования списков отмененных сертификатов.

Certificate Policy (CP)– политика сертификата - поименованное множество правил, которое определяет применимость сертификата открытого ключа для конкретного сообщества или класса приложений с общими требованиями безопасности. Например, конкретная политика сертификата может указывать применимость сертификата открытого ключа для аутентификации транзакций данных при торговле товарами в данном ценовом диапазоне.

Certificate Practice Statement (CPS)– утверждение об используемой практике, в соответствии с которой сотрудники сертификационного центра выпускают сертификаты открытого ключа.

Relying Party (RP)– проверяющая сторона - пользователь или агент (например, клиент или сервер), который использует сертификат для надежного получения открытого ключа субъекта и, быть может, некоторой дополнительной информации.

Root CA – СА, которому непосредственно доверяет конечный участник; это означает безопасное получение открытого ключа корневого СА, требующее некоторых внешних по отношению к PKI шагов. Этот термин не означает, что корневой СА обязательно должен быть вершиной иерархии. Заметим, что термин "доверенный якорь" имеет то же значение, что и корневой СА в данном случае.

Репозиторий - система или набор распределенных систем, которые хранят сертификаты и CRL и предназначены для распределения этих сертификатов и CRL между конечными участниками.

Пользователи систем, основанных на открытом ключе, должны быть уверены, что когда они используют открытый ключ, субъект, с которым они связываются, является собственником соответствующего закрытого ключа. Эта уверенность достигается благодаря использованию сертификата открытого ключа, которые являются структурами данных, связывающих значения открытого ключа с субъектами. Связывание обеспечивается наличием доверенного СА, который проверяет идентификацию субъекта и подписывает каждый сертификат.

Сертификат имеет ограниченное время жизни, которое указывается в подписанном содержимом. Так как подпись и своевременность могут быть независимо проверены клиентом, использующим сертификат, сертификаты могут распространяться по небезопасным коммуникациям и серверным системам и кэшироваться в небезопасном хранилище в системах, исполь-зующих сертификаты.

Сертификаты используются для проверки действительности подписанных данных. Имеется определенная специфика, относящаяся к используемому алгоритму, но общий процесс выглядит следующим образом (заме-тим, что не существует особенностей, относящихся к порядку, в котором должны выполняться перечисленные проверки; разработчики свободны в выборе наиболее эффективного способа для своих систем).

• Проверяющая сторона при получении подписанных данных должна убедиться, что предоставленная идентификация пользователя соответствует идентификации, содержащейся в сертификате.
• Проверяющая сторона смотрит, не отменен ли в полученной цепочке сертификатов какой-либо PKC (например, посредством получения соответствующего текущего CRL или on-line запроса статуса сертификата) и все ли сертификаты были дей-ствительны в момент подписывания данных.
• Если все эти проверки проходят, получатель может считать, что данные были подписаны указанной подписывающей стороной. Процесс для ключей, используемых для шифрования, аналогичен.