Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

ООП в Python

ВВЕДЕНИЕ

шифр сертификат интернет

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

Какие же проблемы могут возникнуть у вас при попытке передать какие-либо данные в зашифрованном виде? Если вы выбираете какой-либо симметричный алгоритм шифрования (например, DES или ГОСТ 28147-89), то один и тот же ключ используется и для зашифрования и расшифрования данных. Т.е. ваш оппонент должен иметь ключ, используемый для шифрования. Передать этот ключ по обычным каналам связи в открытом виде не представляется возможным - любой получивший доступ к этому ключу сможет расшифровать ваши данные. Одним из решений этой проблемы является использование фельдъегерской службы, но это очень дорого и не всегда применимо на практике.

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

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

При небольшом числе участников защищенного обмена, к тому же проживающих в одном городе, эта проблема решается элементарно - достаточно встретиться вместе и обменяться на дискете открытыми ключами. Но что делать, если участники находятся в разных городах (а зачастую и странах) и таких участников слишком много - сотни тысяч и даже миллионы? И вот тут на сцену выходит PKI (Public Key Infrastructure).

1. ИНФРАСТРУКТУРА PKI

PKI - инфраструктура открытых ключей - вводит два новых элемента - эмитент (CA, Certificate (CA, Certificate Authority) или "удостоверяющий центр" в терминах Закона об ЭЦП (иногда используется термин "центр сертификации") и сертификат. Именно на эмитента возложена задача выпуска сертификатов, т.е. электронных документов, которые связывает открытый ключ с конкретным субъектом, таким как компьютер или пользователь. Такие эмитенты известны во всем мире. Среди них компании VeriSign и Thawte Consulting. Кстати, последняя компания уже выдает такие сертификаты российским компаниям. Например, Internet-магазин "оЗон" или страховая компания "Ренессанс-Страхование", осуществляющая страхование через Internet, уже имеют сертификаты, выпущенные Thawte. Сертификат, который содержит информацию о владельце открытого ключа, подписан ЭЦП удостоверяющего центра. Таким образом, нет необходимости проверять подлинность каждого открытого ключа - достаточно проверить подлинность ЭЦП центра сертификации. Кстати, это очень важный момент. При отсутствии доверия к центру сертификатов вся инфраструктура PKI не имеет смысла.

С технической точки зрения удостоверяющим центром может стать абсолютно любая компания и даже конкретный пользователь, т.к. компания Microsoft и здесь явила свое присутствие, включив в состав своей операционной системы пакет Microsoft Certificate Services, позволяющий организовать небольшой центр сертификации. Существуют и другие решения, которые ориентированы на создание полномасштабных удостоверяющих центров в рамках крупной корпорации и даже страны. Например, в России известна компания Baltimore Technologies с ее семейством UniCERT.

В основе PKI лежит использование криптографической системы с открытым ключом и несколько основных принципов:

1. закрытый ключ известен только его владельцу;

2. удостоверяющий центр создает сертификат открытого ключа, таким образом удостоверяя этот ключ;

3. никто не доверяет друг другу, но все доверяют удостоверяющему центру;

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

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

1.1 История

Начало асимметричным шифрам было положено в работе "Новые направления в современной криптографии" Уитфилда Диффи и Мартина Хеллмана, опубликованной в 1976 году. Находясь под влиянием работы Ральфа Меркле (англ. Ralph Merkle) о распространении открытого ключа, они предложили метод получения секретных ключей, используя открытый канал. Этот метод экспоненциального обмена ключей, который стал известен как обмен ключами Диффи - Хеллмана, был первым опубликованным практичным методом для установления разделения секретного ключа между заверенными пользователями канала. В 2002 году Хеллман предложил называть данный алгоритм "Диффи - Хеллмана - Меркле", признавая вклад Меркле в изобретение криптографии с открытым ключом. Эта же схема была разработана Малькольмом Вильямсоном в 1970-х, но держалась в секрете до 1997 г. Метод Меркле по распространению открытого ключа был изобретён в 1974 и опубликован в 1978 году, его также называют загадкой Меркле.

В 1977 г. учёными Рональдом Ривестом, Ади Шамиром и Леонардом Адлеманом из Массачусетского технологического института был разработан алгоритм шифрования, основанный на проблеме о разложении на множители. Система была названа по первым буквам их фамилий (RSA - Rivest, Shamir, Adleman). Эта же система была изобретена в 1973 г. Клиффордом Коксом (англ. Clifford Cocks), работавшим в центре правительственной связи (GCHQ), но эта работа хранилась лишь во внутренних документах центра, поэтому о её существовании было неизвестно до 1977 года. RSA стал первым алгоритмом, пригодным и для шифрования, и для цифровой подписи.

1.2 Объекты PKI

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

· Основные компоненты PKI

· * Удостоверяющий центр (УЦ) является основной структурой, формирующей цифровые сертификаты подчиненных центров сертификации и конечных пользователей. УЦ является главным управляющим компонентом PKI:

· он является доверенной третьей стороной (trusted third party) это сервер, который осуществляет управление сертификатами.

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

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

· Репозиторий -- хранилище, содержащее сертификаты и списки отозванных сертификатов (СОС) и служащее для распространения этих объектов среди пользователей. В Федеральном Законе РФ № 63 «Об электронной подписи» он называется реестр сертификатов ключей подписей.

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

· Центр запросов -- необязательный компонент системы, где конечные пользователи могут запросить или отозвать сертификат.

· Конечные пользователи -- пользователи, приложения или системы, являющиеся владельцами сертификата и использующие инфраструктуру управления открытыми ключами.

1.3 Основные задачи

Основные задачи системы информационной безопасности, которые решает инфраструктура управления открытыми ключами:

· обеспечение конфиденциальности информации;

· обеспечение целостности информации;

· обеспечение аутентификации пользователей и ресурсов, к которым обращаются пользователи;

· обеспечение возможности подтверждения совершенных пользователями действий с информацией (неотказуемость, или апеллируемость -- англ. non-repudiation).

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

1.4 Основная идея

Задачей PKI является определение политики выпуска цифровых сертификатов, выдача их и аннулирование, хранение информации, необходимой для последующей проверки правильности сертификатов. В число приложений, поддерживающих PKI, входят: защищённая электронная почта, протоколы платежей, электронные чеки, электронный обмен информацией, защита данных в сетях с протоколом IP, электронные формы и документы с электронной цифровой подписью (ЭП).

Деятельность инфраструктуры управления открытыми ключами осуществляется на основе регламента системы. Инфраструктура открытых ключей основывается на использовании принципов криптографической системы с открытым ключом. Инфраструктура управления открытыми ключами состоит из центра сертификации(удостоверяющего центра -- УЦ), конечных пользователей и опциональных компонентов: центра регистрации и сетевого справочника.

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

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

Удостоверяющий центр также публикует и списки отозванных сертификатов (Certificate Revocation List/CRL), которые могут использовать клиенты инфраструктуры открытого ключа, когда решают вопрос о доверии сертификату пользователя и/или компьютера.

Ключевая пара -- это набор, состоящий из двух ключей: секретного ключа (private key) и открытого ключа (public key). Эти ключи создаются вместе, являются комплементарными по отношению друг к другу (то, что зашифровано с помощью открытого ключа можно расшифровать, только имея секретный ключ, а подпись, сделанную с помощью секретного ключа, можно проверить, используя открытый ключ).

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

Пользователь делает запрос на сертификат, после чего, после процедуры идентификации пользователя, центр выдаёт ему сертификат со своей подписью. Эта подпись свидетельствует о том, что данный сертификат выдан именно этим центром выдачи сертификатов и никем другим.

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

1.5 Некоторые основные моменты

Разберём подробнее следующие моменты:

* В чём заключается работа УЦ

* Как происходит выдача сертификата, обмен открытыми ключами и как понять, что открытый ключ, который мы имеем, не фальшивый

* Какие бывают PKI.

УЦ и его работа

Основная работа удостоверяющего центра заключается в идентификации пользователей и их запросов на сертификаты, в выдаче пользователям сертификатов, в проверке подлинности сертификатов, в проверке по сертификату, не выдаёт ли пользователь сертификата себя за другого, в аннулировании или отзыве сертификатов, в ведении списка отозванных сертификатов.

Процесс работы с сертификатами

Для того чтобы получить сертификат, нужно найти какой-либо УЦ в интернете (альтернативным решением является использование ПО PGP или ему подобных), после чего выписать сертификат и установить его себе в систему. Обычно этот процесс происходит автоматически. После установки сертификата его можно будет увидеть у себя в хранилище личных сертификатов. Для того чтобы просмотреть его свойства, достаточно просто открыть его. (Для операционных систем семейства Windows: Пуск -> Выполнить -> certmgr.msc -> OK). В свойствах можно увидеть время действия сертификата, кем он был выдан, кому был выдан, его уникальный номер и прочие свойства. После получения сертификатов двумя или более пользователями от одного УЦ, происходит организация простейшей по архитектуре PKI. PKI -- с одиночным УЦ.

Пользователи, сохранив сертификаты в файл обмениваются ими (таким образом происходит обмен открытыми ключами) и начинают защищённую переписку. Проверка подлинности полученного открытого ключа проводится по электронному отпечатку этого ключа. В простейшем случае достаточно позвонить коллеге выславшему открытый ключ и сверить с ним электронный отпечаток ключа. Если он совпал -- можно смело начинать защищённую переписку, если нет -- обменяться ключами ещё раз. Какие же бывают PKI по архитектуре, кроме как одиночные УЦ?

1.6 Архитектуры PKI

В основном выделяют 5 видов архитектур PKI, это:

1. простая PKI (одиночный УЦ)

2. иерархическая PKI

3. сетевая PKI

4. кросс-сертифицированные корпоративные PKI

5. архитектура мостового УЦ

В основном PKI делятся на разные архитектуры по следующим признакам:

· количество УЦ (а также количество УЦ, которые доверяют друг-другу)

· сложность проверки пути сертификации

· последствия выдачи злоумышленника себя за УЦ

Рассмотрим более подробно каждую из архитектур PKI в отдельности.

1. Простая PKI

Как уже говорилось выше, самая простая из архитектур, это архитектура

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

2. Иерархическая PKI

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

3. Сетевая PKI

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

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

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

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

4. Архитектура кросс-сертифицированной корпоративной PKI

Данный вид архитектуры можно рассматривать как смешанный вид иерархической и сетевой архитектур. Есть несколько фирм, у каждой из которых организована какая-то своя PKI, но они хотят общаться между собой, в результате чего возникает их общая межфирменная PKI.В архитектуре кросс-сертифицированной корпоративной PKI самая сложная система цепочки сертификации.

5. Архитектура мостового УЦ

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

1.7 Внедрение PKI

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

· Этап 1. Анализ требований к системе.

· Этап 2. Определение архитектуры.

· Этап 3. Определение регламента.

Этап 4. Обзор системы безопасности. Анализ и минимизация рисков.

* Этап 5. Интеграция.

* Этап 6. Развертывание.

* Этап 7. Эксплуатация.

Примеры использования PKI

Электронная подпись (ЭП)

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

Шифрование сообщений

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

Авторизация

Сертификаты могут использоваться для подтверждения личности пользователя и задания полномочий, которыми он наделён. В числе полномочий субъекта сертификата может быть, например, право просматривать информацию или разрешение вносить изменения в материал, представленный на web-сервере.

2. СЕРТИФИКАЦИЯ АДРЕСНЫХ ИНТЕРНЕТ-РЕСУРСОВ

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

Архитектура Интернета накладывает определенные требования на то, как должны распределяться АИР между участниками. Протокол IP требует уникальности - каждая сеть должна использовать уникальное адресное пространство, а каждое устройство этой сети - уникальный адрес. Система маршрутизации накладывает требование агрегированности - насколько возможно, распределение адресов должно отражать топологию связности сетей для уменьшения числа глобальных маршрутов. Наконец для обеспечения общедоступности адресных ресурсов, учитывая их ограниченное количество, был введен принцип сохранения - распределение этих ресурсов строго по потребностям.

Лучше всего данным требованиям удовлетворяет иерархическая регионально-топологическая система распределения, образованная в середине 90-х и существующая по сегодняшний день. Пять Региональных Интернет Регистратур (РИР) - AfriNIC, APNIC, ARIN, LACNIC и RIPE NCC распределяют АИР сервис-провайдерам, выполняющим также роль Локальных Интернет-Регистратур (ЛИР). ЛИРы, в свою очередь, распределяют их далее своим клиентам - менее крупным сетям и конечным пользователям.

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

Сегодняшняя публичные регистрационные данные включают региональные регистрационные базы, поддерживаемые РИРами (whois.afrinic.net, whois.arin.net, whois.apnic.net, whois.lacnic.net, whois.ripe.net) и многочисленные регистратуры маршрутизации (наиболее крупные - RADB и RIPE IRR). Качество информации, доступной из этих источников, очень сильно варьируется. Чем меньше объекты регистрации (сети, маршруты и т.д), чем ближе они к конечному пользователю, тем меньше доверия к этим данным. Другой проблемой является то, что достоверность данных неочевидна для «третьих лиц». Зачастую проверка достоверности превращается в детективное расследование с привлечением различных источников.

Одним из перспективных направлений улучшения доступности и достоверности регистрационных данных является применения технологий, основанных на инфраструктуре открытых ключей - PKI (Public Key Infrastructure). PKI является иерархической системой доступа к открытым (public) цифровым ключам субъектов, основанной на выпуске цифровых сертификатов, связывающих открытый ключ субъекта с определенными атрибутами субъекта - например, принадлежащее ему доменное имя. Этот цифровой документ скреплен цифровой подписью организации выдавшей сертификат. Более подробно структура сертификата X.509 описана в стандарте IETF RFC 3280.

В свою очередь, владелец сертификата может выдать подчиненный сертификат, скрепленный своей подписью и так далее. Во главе этой иерархии находится сертификат, также называемый«точкой доверия» (Trust Anchor). Этот сертификат не имеет “родительского” сертификата и подписан собственным ключем. Однако если пользователь уверен в достоверности этого сертификата, подлинность всех остальных сертификатов иерархии может быть легко установлена.

Примером этой технологии является использование SSL сертификатов для защищенного доступа к вэб-сайтам с помощью протокола https.

Поскольку распределение АИР является иерархическим, структура PKI может полностью соответствовать структуре распределения интернет-ресурсов. Однако отличия PKI для АИР, получившей название RPKI (Resource PKI), от стандартной PKI существенны, мы остановимся на них подробно в этой статье.

Начнем с основного компонента RPKI - сертификата интернет-ресурса.

2.1 Сертификат

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

СР является сертификатом стандарта X.509 и содержит так называемые критические расширения для документации АИР, стандартизованные в RFC 3779. Субъект может подтвердить свои права на использование указанных ИР путем демонстрации владения закрытым (private) ключом, соответствующим публичному ключу, указанному в сертификате. Обычно это носит характер подписания данным закрытым ключом какого-либо документа. Получатель этого документа, в свою очередь, может удостоверить соответствие этой подписи с публичным ключом, указанным в сертификате, и как следствие достоверность документа и его ассоциацию с субъектом и его интернет-ресурсами.

Другими словами, владелец закрытого ключа, ассоциированного с СР, может продемонстрировать свои права на использование АИР, указанных в сертификате.

Цифровые сертификаты являются компонентом иерархической инфраструктуры открытых ключей - PKI (Public Key Infrastructure). Также предполагается, что структура PKI соответствует структуре распределения АИР. Сертификаты этой системы являются СР, а вся система в целом получила название RPKI (Resource PKI). Необходимо отметить, что данная система не является системой сертификации аутентичности пользователей (в отличие от большинства традиционных PKI).

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

Перечислим основные достоинства использования сертификации:

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

· Проверка достоверности сертификата основана на криптотехнологии.

· Прозрачная иерархическая система удостоверения прав, конгруэнтная текущей системе распределения АИР.

· Четкие параметры качества данных - сроки действия, удостоверение подлинности прав

2.2 Поддержка глобальной уникальности распределения АИР

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

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

Однако предстоящее опустошение свободного пула адресов IPv4 и, как следствие, возможный процесс перераспределения существующих ресурсов, накладывает новые требования на систему регистрации АИР.

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

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

В то же время нельзя исключить возможность перераспределения АИР незаконным путем, посредством одностороннего присвоения и использования АИР и возможного изменения регистрационных данных в публичных базах данных whois (address space hijacking).

Можно сказать, что сегодняшняя система публичной регистрации АИР не соответствует будущим требованиям, предъявляемым к системе вследствие предполагаемой большей мобильности АИР и необходимости защиты прав использования.

В этом смысле сертификация АИР предоставляет более надежный и технологичный метод публичной регистрации.

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

Функцию связи субъекта СР с реальной организацией выполняет УЦС. Решение о публикации этой информации, например на вэб-сайте или в базе данных whois, остается за УЦС.

2.3 Поддержка безопасности системы глобальной маршрутизации

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

Безопасность и надежность системы маршрутизации во многом зависит от возможности правильного ответа на вопросы:

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

· является ли автономная система-отправитель сообщения BGP, правомочным источником (origin) префикса?

· соответствует ли атрибут AS_PATH, полученный в сообщении BGP, действительному пути, который прошло данное сообщение в сети Интернет?

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

Одной из причин такой ситуации является трудоемкость получения четких ответов на поставленные вопросы и сложность автоматизации этого процесса. Это, в первую очередь, связано с отсутствием достоверного способа документирования использования адресного пространства. Как уже упоминалось, существующие базы данных whois Региональных Интернет Регистратур содержат неполную и сильно различающуюся по качеству информацию; еще хуже состояние дел в Интернет-регистратурах маршрутизации (Internet Routing Registry, IRR). Эта проблема усугубляется отсутствием надежного способа определения достоверности данных, полученных из этих баз данных.

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

1. Генерация трафика с использованием подложных адресов в качестве источника трафика. Данная технология используется в атаках отказа в обслуживании DoS (Denial of Service). Например, в случае использования протокола DNS, атакуемые компьютеры играют роль отражателей и усилителей трафика, который затем поражает компьютеры, якобы являющиеся источником запросов.

2. Притягивание трафика, является одним из видов атаки DoS. Ярким примером явилось анонсирование компанией Pakistan Telecom адресного пространства серверов YouTube, с последующим игнорированием входящего трафика, что привело к невозможности доступа к сервису YouTube.

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

4. Краткосрочная незаконная деятельность с использованием присвоенного адресного пространства. Примером может служить анонсирование временной сети для атаки DoS или рассылки спама.

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

2.4 Установление пиринга

В настоящее время установление пиринга и предоставление услуг передачи данных сети во многих случаях не предусматривает дополнительных проверок достоверности прав использования АИР. В случаях, когда сетевой оператор все же осуществляет такие проверки, они зачастую носят характер детективной работы с привлечением нескольких баз данных (например whois, IRR), точность данных которых небезупречна.

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

2.5 Поддержка текущей практики фильтрации маршрутов

К сожалению на сегодняшний день фильтрация маршрутов не является широко распространенной практикой среди сетевых операторов. Одной из причин тому - опять же отсутствие надежных достоверных и технологичных данных о принадлежности АИР определенным сетям и, как следствие, трудности принятия решения относительно допустимости того или иного маршрута.

Настоящая практика в основном предусматривает «локальную» фильтрацию - использование сетевыми операторами IRR, в которой сети-клиенты обязаны зарегистрировать т.н. объекты маршрутов (объекты “route: ”), описывающие адресное пространство, которое анонсирует автономная система. Коллекция объектов «route:» всех автономных систем - клиентов оператора, составляет его фильтр маршрутов. Следует отметить, что хотя данный метод может быть автоматизирован, надежность IRR с точки зрения достоверности данных невысока.

Идея использования сертификатов RPKI для поддержки эффективного построения фильтров является весьма привлекательной. Во-первых, сертификаты свободны от многих недостатков упомянутых баз данных и предоставляют ряд преимуществ. Например, возможность криптографического установление достоверности данных сертификата, или документа, созданного на основе сертификата, вне контекста какой-либо базы данных. Во-вторых, криптографический характер сертификатов позволяет эффективно использовать его производные - данные, подписанные сертифицированным ключом. Этими данными, так называемыми вторичными объектами, могут быть документы ROA (Route Origination Authorisation), которые позволяют удостоверить правомерность анонсирования автономной системой определенных префиксов.

2.6 Безопасность на уровне протокола BGP

Полным решением указанных проблем безопасности является определение достоверности анонсируемых маршрутов на уровне протокола BGP. Основная идея заключается в том, что на всем пути маршрута граничные маршрутизаторы связанных автономных систем «подписывают» соответствующие участки пути. В результате каждый анонсированный маршрут может быть достоверно проверен как на предмет адресного пространства и автономной системы, его анонсирующей, но также и на то, что полученный маршрут действительно был передан через автономные системы, которые в нем указаны (атрибут AS_PATH).

Данный подход получил некоторое развитие в архитектуре sBGP и soBGP, работа над которыми началась несколько лет назад. Однако в последнее время стало очевидно, что дороговизна применения (например, требуемая компьютерная мощность) и сложность внедрения (последовательное внедрение технологии не приносит ожидаемых улучшений до достижения значительной критической массы) данных технологий несоразмерны с теми преимуществами, которые они обещают (например, величина и вероятность рисков, которым они противодействуют). В силу этого работы в этом направлении не получили достаточного развития и вряд ли можно рассчитывать на практическое внедрение безопасности на уровне протокола BGP в обозримом будущем.

2.7 Основные принципы RPKI

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

Для эффективного применения данной технологии необходимо удовлетворить два основных условия:

· обеспечить эффективную систему распространения открытых ключей и

· обеспечить достоверную идентификацию открытого ключа с его владельцем

Данная задача успешно решается с помощью иерархической системы PKI. Основным элементом этой системы являются сертификаты. Сертификат выдается удостоверяющими центрами сертификации, УЦС, - органами, отвечающими за установление связи между субъектом сертификата и его открытым ключом. По существу, сертификат является цифровым документом, который содержит некоторый идентификатор субъекта и его открытый ключ, подписанным органом, выдавшим сертификат. Посредством сертификатов, УЦС могут сертифицировать УЦС следующего уровня и так далее, образуя, таким образом, древовидную иерархическую структуру. Эта структура является также «структурой доверия». Если вы доверяете УЦС, сертифицировавшему другой УЦС, вы также доверяете и этой организации, и т.д. То есть, третьим лицам достаточно доверять УЦС в корне данной структуры, чтобы установить достоверность любого сертификата и, таким образом, достоверно идентифицировать связь какого-либо открытого ключа с его владельцем.

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

Система RPKI основана на сертификатах стандарта X.509, содержащими критические расширения для документации АИР, стандартизованные в RFC3779. Данное расширение содержит список всех АИР (адресов IPv4 и IPv6, а также номера АС) полученных субъектом сертификата. Важно отметить, что задачей СР не является идентификация субъекта, в отличие от стандартной системы PKI. СР удостоверяет, что УЦС распределил определенные ресурсы субъекту сертификата, и данные ресурсы

перечислены в расширении сертификата. УЦС удостоверяет, что любой документ, подписанный секретным ключом, соответствующим открытому ключу сертификата, подписан законным обладателем прав использования ИР, перечисленных в сертификате. Данная концепция схематично представлена на рис. 1.

Рис.3.7.1 X.509 Сертификат Ресурсов с расширениями

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

При этом почтовый адрес отправителя не имеет значения и не влияет на достоверность описанной проверки.

2.8 Cтруктура RPKI

Любая система PKI имеет иерархическую структуру с корневым сертификатом во главе. Поскольку для корневого сертификата не существует родительского УЦС, данный сертификат представляет собой самоподписанный корневой ключ. Организация, которой принадлежит корневой СР, является т.н. «точкой доверия» (Trust Anchor). Важно отметить, что как и в любой системе PKI вопрос доверия данной PKI остается за третьими лицами - пользователями системы.

Хотя в случае RPKI очевидным кандидатом на роль точки доверия является IANA, можно предположить, что некоторая организация создаст СР, охватывающий все ИР (все адресное пространство IPv4, IPv6 и АС). Эта организация теперь может предоставлять СР любым участниками системы распределения ИР, при этом выданные сертификаты будут формально отвечать требованиям удостоверения подлинности в соответствии с RFC 3779. Единственным условием успешного использования этих сертификатов является выбор данной организации пользователями СР в качестве точки доверия. Очевидным недостатком такой системы является отсутствие надежных регистрационных данных у такого УЦС, что делает процесс сертификации менее надежным.

Более реалистичным является предположение, что процесс внедрения RPKI начнется с создания нескольких точек доверия, включающих РИР, и последующим созданием единого корневого СР.

Для этого потребуют решения вопросы контроля, управления и сопровождения корневого СР, которые затрагивают глобальное Интернет-сообщество и во многом носят нетехнический характер. Эти аспекты выходят за рамки данной статьи. Для иллюстрации работы RPKI остановимся на «идеальной» с технической точки зрения структуре.

В этом случае корневой СР в качестве списка АИР охватывает все адресное пространство IPv4, IPv6 и автономных систем. С помощью этого сертификата могут быть сгенерированы сертификаты РИР в соответствии с фактически распределенным адресным пространством.

В свою очередь РИР могут сертифицировать АИР, которые они распределяют Локальным Регистратурам (Local Internet Registry - LIR) или конечным пользователям, которые получают АИР непосредственно от RIR. Локальные Регистратуры могут осуществлять последующее распределение, и соответствующую сертификацию. Наконец конечные пользователи - сети, фактически использующие адресное пространство, также должны иметь возможность генерирования временных сертификатов для подписания вторичных объектов RPKI - ROA, BOA, и т.д. Дело в том, что срок жизни этих объектов обычно короче, чем право на использования АИР, а их аннулирование реализуется путем аннулирования сертификатов, использованных при создании соответствующих объектов. Во избежание аннулирования всех вторичных объектов и последующего их воссоздания, для каждого объекта генерируется свой СР. Таким образом аннулирование вторичных объектов может быть осуществлено независимо.

Важным последствием такого подхода является требование, что все участники RPKI являются органами выдачи сертификатов, УЦС, со всеми вытекающими последствиями: необходимостью соответствующей защищенной инфраструктуры, процессов управления ключами и т.п. Общая схема RPKI проиллюстрирована на рис. 2.



Рис. 3.8.1 Общая структура RPKI

Как и в случае традиционной PKI, в состав RPKI входят следующие компоненты:

· Служба выдачи сертификатов (Certificate Authority, CA). Основной функцией CA является генерация и публикация сертификатов и списков ануллированных сертификатов. Эта функция по существу не меняется в RPKI, за исключением того, что СР содержат расширения документирующие распределенные АИР.

· Служба регистрации (Registration Authority, RA) отвечает за проверку подлинности связи между субъектом сертификата и его ключом. В случае RPKI также удостоверяется, что субъект сертификата имеет права на использование АИР, перечисленных в расширении. По существу, эта функция неотличима от функции регистрационных услуг, выполняемых сегодня РИР. Отметим, что хотя предполагается, что УЦС удостоверяет субъекта СР, данное условие не является необходимым, и информация о субъекте в СР может не быть неявной (например, субъект может быть представлен цифровым идентификатором, имеющим значение только во внутренней структуре УЦС).

Эти две службы являются частью УЦС.

· Репозитории - открытые базы данных, в которых публикуются выданные сертификаты, списки аннулированных сертификатов и, в случае RPKI, вторичные объекты.

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

· Разрешение на создание маршрута (Route Origin Authorisation, ROA). Одним из наиболее проработанных вторичных объектов является ROA. Использование ROA предполагается в контексте безопасности маршрутизации. Как следует из названия, ROA является разрешением, данным сетью - владельцем прав использования АИР на анонсирование данных ресурсов Автономной Системой, указанной в ROA. В соответствии со спецификацией ROA содержит номер авторизованной АС и список IP префиксов, которые эта АС имеет разрешение анонсировать. К этому "заявлению" прилагается сертификат, описывающий соответствующие АИР, и весь объект подписан с использованием ключа, указанного в сертификате. Также отметим, что наличие ROA не означает «согласие» авторизованной АС и что указанные префиксы непременно будут анонсированы данной Автономной Системой.

2.9 Использование RPKI третьими лицами (relying party)

Одной из задач создания RPKI является предоставление третьим лицам возможности независимой проверки достоверности сертификатов и вторичных объектов системы (например, ROA). Единственным условием является доверие третьих лиц корневому УЦС. Третьими лицами являются пользователи системы RPKI, задачей которых является проверка достоверности данных относительно АИР, их статуса и подлинности связи ресурсов с заявленным владельцем прав на использование.

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

Следующим шагом является создание т.н. «цепи доверия». Происходит это следующим образом. Как и в стандартном PKI каждый СР содержит ссылку на СР УЦС, выдавшего данный сертификат. Таким образом, можно убедиться, что сертификат действительно подписан УЦС и данные сертификата не были модифицированы. Поднявшись на ступеньку выше, таким же образом можно проверить подлинность сертификата УЦС, УЦС более высокого уровня, и т.д. вплоть до корневого УЦС, который является доверенным центром для третьих лиц. Если все проверки цепочки прошли без ошибок, можно с уверенностью сказать, что исходный сертификат является достоверным и немодифицированным. Этот процесс представлен на рис.3.

Рис. 3.9.1 Построение цепи доверия для проверки подлинности вторичных объектов и СР

2.10 Реализация системы Сертификации Региональными Интернет Регистратурами

РИР начали заниматься вопросами сертификации АИР с 2006 года. Пионером в этом отношении являлся APNIC, который предложил основные принципы построения системы RPKI. В 2007 году к работе активно подключился ARIN и совместная группа RESCERT, в состав которой также входили специалисты других РИР, разработала основные компоненты системы.

RIPE NCC начал работу над сертификацией почти одновременно с APNIC. В отличие от APNIC первоначально основная деятельность была направлена на выработку общей позиции относительно целей сертификации АИР, а также на вовлечение сообщества в процесс выработки требований к системе RPKI. В ноябре 2006 была создана рабочая группа.