Инфраструктура открытых ключей. Ssl

Вид материала

Лекция

Подобный материал:

• Мы обсудили формально большую часть протокола ssl, 95.85kb.
• Программа выступлений на секциях конференции: Н. А. Богульская, 90.95kb.
• Пошаговое руководство по организации удаленного доступа по протоколу sstp, 918.09kb.
• Поиск в Google Ключевые слова, 123.18kb.
• Шифрование почты, 689.07kb.
• Инструкция по обеспечению безопасности движения поездов при производстве работ по техническому, 752.1kb.
• Инфраструктуры открытых ключей, 2432.22kb.
• Уважаемые организации – клиенты системы «СБиС++ Электронная отчетность», 31.48kb.
• Памятка для клиента по обеспечению безопасности при работе в Системе дбо, 30.25kb.
• Это было одно из тех безобидных маленьких привидений, которые появляются ночью и никому, 491.6kb.

Лекция №2

24.02.2009

Гурьев


Инфраструктура открытых ключей. SSL.

Список документов, посвященных PKI очень сильно разросся за последние 7 лет.

Какой это посвящено задаче?

Мы знаем, что существуют открытые ключи, криптографические алгоритмы, связанные с этими ключами и у всех систем, основанных на открытых ключах, существует уязвимость подмены открытого ключа. Для того, что бы с этой уязвимостью бороться, придумали такую вещь. Пара (ID, KM) (id того кому ключ принадлежит и сам ключ) подписывается некоей третьей стороной. Для того, что бы сформировать подпись, тоже нужен открытый ключ, и ему тоже нужно верить. Ключ, при помощи которого сформирована эта подпись, тоже можно подписать, и формируется структура, кот называется сертификационный путь. Эти пути могут идти от одного центра ко многим ключам, подлинность которого необходимо обеспечить. И за счет этого приема, удается свести к минимуму число ключей, которые нужно распределить ручным способом. Пример протокола, в котором это уже сделано - DNSSec (расширения DNS с точки зрения безопасности). Еще эта идея эксплуатируется в протоколе PGP. Помимо этого есть стандарт X.509, который реализует эту идею не только в рамках одного протокола.

История.

Исходно было технология X.500 (X.500-X.599) – это служба каталогов.

Реализация Novel NDS, MS Active Directory, LDAP (RFC 1777-1779)

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

X.509 v1 1988 год

X.509 v2 1993 год

X.509 v2 2000 год

Говорим о v2. В этом стандарте была одна неприятность. Он очень сильно был завязан на систему адресации, принятой в этом пакете стандартов – Distinguished Names. Такое имя, состоит из отдельных компонентов, упорядоченных по большинству. Читается справа налево.

P=guriev,OU=cs,C=Moscow,CN=Ru

Жесткой структуры нет, секции могут повторяться несколько раз, есть только описание префиксов. Однако это системное именование не гарантирует уникальности имен. Поэтому, иногда нужны дополнительные идентификаторы. Но самое неприятное, что идентификаторы такого вида в Интернет не применяются. Хотя есть такие расширения, которые позволяли в качестве альтернативного имени html-адрес.

Так случилось, что именно этот стандарт положили в основу в систему открытых ключей Интернет. Но так как в таким виде он неприменим, то был разработан целый пакет уточняющих документов о том, как этот стандарт адаптировать к Интернету. PKIX – Public Key Infrastructure for Internet.

X.509 v3 интегрировала многие документы RFC.

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

Такова история.


Ключевое понятие – CN. Если рассматривать его в первом приближении, то это комбинация 4х значений.

SubjectID идентификатор того, кому ключ принадлежит

IssuerID идентификатор, того кто этот ключ выпустил

Key собственно ключ, подлинность которого удостоверяется

SIGN подпись, которую формирует УЦ, при помощи своего закрытого ключа (а проверяется при помощи открытого ключа)

Такой документ обозначает, что ключ Key действительно принадлежит SubjectID

Это в самом общем виде иллюстрация основной идеи.

В X.509 v2 сертификат открытого ключа был сертифицирован более подробно.

Version Версия стандарта X.509

SerialNumber уникальный для данного выпускающего номер сертификата

SIGN идентификатор алгоритма подписи

Issuer идентификатор УЦ

Validity пара дат: от и до какого времени сертификат действителен

Subject ID владельца ключа

SubjectPublicKeyInfo это два подполя AlgID (идентификатор алгоритма для которого этот ключ) и сам ключ

IssuerUniqueID Уникальный ID выпускающего

SubjectUniqueID Уникальный ID владельца

Последние два поля необязательны, но должны быть уникальны. SubjectID и IssuerID не гарантируют уникальность.


X.509 v3

Добавилось единственное поле Extensions переменной длины, которое состоит из нескольких полей. В них вся информация для Интернета.

Заметим, что полей как в заголовке протоколе TCP или IP там нет.

Система основана на подходе ASN.1 – это способ представления элементов данных, и метаязык описания структур данных.

И каждому полю соответствует некое определение типа в этом ASN.1 и это может быть какой-нибудь элементарный тип типа целое, или составной типа как в Validity и Extensions (последовательность разных типов).


ссылка скрыта

Итак, Extensions.

Наиболее важные (с точки зрения использования протокола)

SubjectAltName – альтернативное имя владельца

IssuerAltName – альтернативное имя УЦ.

Это два подтипа одного и того же типа, которое допускает в качестве подтипов доменное имя, IP-адрес, email адрес, URL.


KeyUsage – цель использования ключа. Если это поле присутствует, то этот ключ предназначен не для любых целей, а для каких-то конкретных. Так может быть

KeyUsage ::= BIT STRING {

digitalSignature (0),подпись

nonRepudiation (1),неотказуемость

keyEncipherment (2),шифрование ключей

dataEncipherment (3),шифрование данных

keyAgreement (4),согласование ключей

keyCertSign (5),подпись сертификата

cRLSign (6),

encipherOnly (7),

decipherOnly (8) }


DistributionPoint – адрес в Интернете, где исходно опубликован данный сертификат. Адреса могут принимать разную форму (URL)


CRLDistributionPoints – аналогичный адрес, где можно найти список отзывов данного УЦ. Тоже URL. Таким образом, можно в самом сертификате опубликовать ссылку о том, где он опубликован, и проверить, не отозван ли он.


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


С УЦ связаны два других понятия.

Репозиторий сертификатов - то куда поступают выпущенные сертификаты, общедоступная БД

Список отзывов (Certificate Relocation List, CRL) бывают причины, по которым сертификат становится недействительным. Сертификат – структура, которая ни к чему не привязана. Кто угодно её может скопировать, хранить у себя сколь угодно долго, раз она уже выпущена. Поэтому публикуется специальное объявление, что такой-то сертификат недействителен. Такой список хранится в CRL. Списки отзывов тоже подписываются УЦ.


Взаимодействие между УЦ.

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

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

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

Это определение было еще в X.509 v2.

Там вводилось и другое определение – двунаправленный сертификационный путь. Это два сертификационных пути – туда и обратно.

Узкое место – корневой ключ.

А нельзя ли сделать так, что бы каждый клиент получал только ключ центра сертификации, с которым он взаимодействует? Можно если вдоль линии этой иерархии не только младший будет подписывать этот ключ, но и младший, и так до самого верха в две стороны. И если нам нужно проверить сторону B, то мы где-то берем такой двунаправленный путь. Фактически подпись в две стороны – это два способа обеспечения такой иерархии.

Не совсем легко, когда у нас несколько таких деревьев.

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

Но если в одной иерархии сравнительно просто найти сертификационный центр, то при такой сертификации определить, кто с кем связан таким образом уже значительно сложнее.


Операции с сертификатами и сертификационными путями.

1. Выпуск сертификата
   
2. Публикация сертификата, то есть размещение где-то
   
3. Отзыв сертификата, то есть публикация в CRL.
   

Операции с сертификационными путями.

1. Проверка сертификационного пути. Если путь у нас уже есть, то нужно убедиться, что сертификационному ключу можно доверять
   
2. Поиск сертификационного пути.