Курс лекций «Проблемы безопасности в информационных технологиях»



жүктеу 4.51 Mb.
бет14/44
Дата13.09.2017
өлшемі4.51 Mb.
түріКурс лекций
1   ...   10   11   12   13   14   15   16   17   ...   44

Инфраструктура публичных ключей


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

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

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

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

Один из любопытных механизмов аутентификации называется одноразовым паролем (one time password, OTP) — это пароль, действительный только для одного сеанса аутентификации. Действие одноразового пароля также может быть ограничено определённым промежутком времени. Преимущество одноразового пароля по сравнению со статическим состоит в том, что пароль невозможно использовать повторно. Таким образом, злоумышленник, перехвативший данные из успешной сессии аутентификации, не может использовать скопированный пароль для получения доступа к защищаемой информационной системе. Использование одноразовых паролей само по себе не защищает от атак, основанных на активном вмешательстве в канал связи, используемый для аутентификации (например, от атак типа «человек посередине»).

Один подход к использованию OTP, разработанный Лесли Лэмпортом, использует одностороннюю функцию (назовём её f), причём длина y=f(s) совпадает с длиной аргумента s. Система одноразовых паролей начинает работать от некоторого начального числа s, затем генерирует пароли


f(s),f(f(s)),f(f(f(s))), …
столько раз, сколько необходимо. Если ищется бесконечная серия паролей, новое начальное число может быть выбрано после того, как ряд для s оказывается исчерпанным. Каждый пароль распределяется в обратном порядке, начиная с f(f(…f(s))…), заканчивая f(s).

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

При аутентификации «запрос-ответ» (challenge-response) сервер генерирует случайный запрос и отправляет его пользователю. Вместо того чтобы в ответ отправить серверу пароль, пользователь А шифрует запрос при помощи ключа, известного только ему самому и серверу. Сервер выполняет такое же шифрование и сравнивает результат с шифротекстом, полученным от пользователя. Если они совпадают, то аутентификация прошла успешно, в противном случае – неудачно.

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

Аутентификации на базе протокола Kerberos будет рассмотрена в лекциях позже. Это довольно старая и весьма громоздкая технология, разработанная в своё время в MIT для распределённых Unix-систем.

Ещё один вариант аутентификации – с использованием сертификатов открытых ключей. Аутентификацию при помощи сертификатов обеспечивают несколько распространенных протоколов, в частности, наиболее известный и широко распространенный протокол Secure Socket Layer (SSL), который применяется практически в каждом web-браузере. Помимо него применяются протоколы Transport Layer Security (TLS), Internet Key Exchange (IKE), S/MIME, PGP и др. Каждый из них немного по-своему использует сертификаты, но основные принципы одни и те же.

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

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




  • механизмом установления доверия на базе определенной модели доверия;

  • механизмом присваивания субъектам имен, уникальных в данной среде;

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

PKI обеспечивает аутентификацию, но не реализует:




  • авторизацию (хотя может применяться с целью защиты информации, используемой для авторизации);

  • доверие (хотя и способствует установлению отношений доверия, подтверждая принадлежность данного открытого ключа определенному субъекту);

  • именование субъектов (а только связывает известные имена субъектов с их открытыми ключами);

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



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


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

Основные компонентами PKI являются:




  • удостоверяющий центр (УЦ, англ.CA);

  • регистрационный центр (РЦ);

  • репозиторий (хранилище) сертификатов;

  • архив сертификатов;

  • конечные субъекты (пользователи).

Взаимодействие компонентов PKI представлено на рисунке ниже:




Рис.33 Основные компоненты PKI
Фундаментальная предпосылка криптографии с открытыми ключами заключалась в том, что два незнакомых субъекта должны иметь возможность безопасно связываться друг с другом. Например, если пользователь Боб желает отправить конфиденциальное сообщение пользователю Алиса, с которой он ранее не встречался, то для шифрования сообщения он должна иметь возможность связать каким-либо образом пользователя Алиса и её открытый ключ. Для сообщества потенциальных пользователей, объединяющего сотни тысяч или миллионов субъектов, наиболее практичным способом связывания открытых ключей и их владельцев является организация доверенных центров. Этим центрам большая часть сообщества или, возможно, все сообщество доверяет выполнение функций связывания ключей и идентификационных данных (идентичности) пользователей.

Такие доверенные центры в терминологии PKI называются удостоверяющими (УЦ, Certification authority, CA). CA – сторона (отдел, организация), чья честность неоспорима, а открытый ключ широко известен. Задача центра сертификации — подтверждать подлинность публичных ключей с помощью сертификатов электронной подписи.

Асимметричный шифр позволяет шифровать одним ключом, а расшифровывать другим. Таким образом, один ключ («закрытый», «секретный») хранится у принимающей стороны, а второй («открытый») можно получить при сеансе прямой связи, по почте, найти на «электронной доске объявлений», и т. д. Но такая система связи остаётся уязвимой для злоумышленника, который представляется Алисой, но отдаёт свой открытый ключ, а не её.

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

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

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

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

Удостоверяющий центр известен субъектам PKI по двум атрибутам: названию и открытому ключу. CA включает свое имя в каждый выпущенный им сертификат и в список аннулированных сертификатов (САС, англ. CRLCertificate Revocation List) и подписывает их при помощи собственного секретного ключа. Пользователи могут легко идентифицировать сертификаты по имени CA и убедиться в их подлинности, используя его открытый ключ.



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

CA может работать с несколькими регистрационными центрами, в этом случае он поддерживает список аккредитованных регистрационных центров, то есть тех, которые признаны надёжными. CA выдает сертификат РЦ и отличает его по имени и открытому ключу. РЦ выступает как объект, подчиненный УЦ, и должен адекватно защищать свой секретный ключ. Проверяя подпись РЦ на сообщении или документе, CA полагается на надежность предоставленной РЦ информации.

РЦ объединяет комплекс программного и аппаратного обеспечения и людей, работающих на нем. В функции РЦ может входить генерация и архивирование ключей, уведомление об аннулировании сертификатов, публикация сертификатов и CRL в каталоге LDAP и др. Но РЦ не имеет полномочий выпускать сертификаты и списки аннулированных сертификатов. Иногда CA сам выполняет функции РЦ.

Репозиторий – специальный объект инфраструктуры открытых ключей, по сути база данных, в которой хранится реестр сертификатов (термин «реестр сертификатов ключей подписей» введен в практику Законом РФ «Об электронной цифровой подписи»). Репозиторий предоставляет информацию о статусе сертификатов, обеспечивает хранение и распространение сертификатов и CRL, управляет внесениями изменений в сертификаты. К репозиторию предъявляются следующие требования:


  • простота и стандартность доступа;

  • регулярность обновления информации;

  • встроенная защищенность;

  • простота управления;

  • совместимость с другими хранилищами (необязательное требование).

Репозиторий часто размещается на сервере каталогов, организованном в соответствии с международным стандартом X.500 и его подмножеством. Подавляющее большинство серверов каталогов и прикладное программное обеспечение пользователей поддерживают упрощенный протокол доступа к каталогам LDAP (Lightweight Directory Access Protocol).

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

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

Сертификаты открытых ключей X.509


Формат сертификата открытого ключа определен в рекомендациях Международного Союза по телекоммуникациям ITU (X.509) и документе RFC3280 Certificate & CRL Profile организации инженерной поддержки Интернета Internet Engineering Task Force (IETF). В настоящее время основным принятым форматом является формат версии 3, позволяющий задавать дополнения, с помощью которых реализуется определенная политика безопасности в системе. Несмотря на то, что документ RFC3820 адресован Интернет-сообществу, формат сертификата открытого ключа предоставляет гибкий механизм передачи разнообразной информации и применяется в корпоративных PKI.

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





Рис.35 Структура сертификата
В сертификате версии 3 имеется десять основных полей: шесть обязательных и четыре опциональных. Большая часть информации, указываемой в сертификате, не является обязательной, а содержание обязательных полей сертификата может варьироваться. К обязательным полям относятся:


  • серийный номер сертификата Certificate Serial Number;

  • идентификатор алгоритма подписи Signature Algorithm Identifier;

  • имя издателя Issuer Name;

  • период действия Validity (Not Before/After);

  • открытый ключ субъекта Subject Public Key Information;

  • имя субъекта сертификата Subject Name.

Издатель сертификатов присваивает каждому выпускаемому сертификату серийный номер Certificate Serial Number, который должен быть уникален (в пределах издателя). Комбинация имени издателя и серийного номера однозначно идентифицирует каждый сертификат.

В поле Signature Аlgorithm Identifier указывается идентификатор алгоритма ЭЦП, который использовался издателем сертификата для подписи сертификата, например ГОСТ Р 34.10-94:


Рис.36 Пример сертификата формата X.509
Можно выделить три класса сертификатов открытых ключей:


  • сертификаты конечных субъектов;

  • сертификаты удостоверяющих центров;

  • самоподписанные сертификаты (selfsigned).

Внутри каждого класса существует несколько типов сертификатов, они представлены на рисунке ниже:




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

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

Самоподписанные (самоизданные) сертификаты образуют специальный тип сертификатов УЦ, в которых издатель сертификата является одновременно субъектом сертификата. Эти сертификаты используются в PKI для установления пунктов доверия, распространения нового открытого ключа подписи CA и изменения политик применения сертификатов.

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

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




Рис.38 Применение пользователем нескольких пар ключей
Если субъект PKI имеет много пар ключей, то должен иметь и много сертификатов, поскольку формат сертификата стандарта X.509 не позволяет ему указывать в поле Subject Public Key Info (информация об открытом ключе субъекта) несколько ключей. Это, однако, не исключает возможности появления определенного открытого ключа в нескольких сертификатах, которые одновременно являются валидными.

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

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


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


  • аннулирования сертификата при увольнении служащего, владеющего этим сертификатом;

  • аннулирования сертификата при утере служащим своего секретного ключа или пароля доступа к секретному ключу;

  • приостановления действия сертификата, выпущенного для служащего, который в данный момент времени увольняется или находится под следствием;

  • возобновления сертификата служащего при отказе от увольнения или после прояснения обстоятельств судебного дела и т.п.

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

Несколько примеров: пусть секретный ключ используется для подписания деловых контрактов. Так как срок действия секретного ключа – 10 лет и ключ был создан в начале 2000 года, то он должен храниться до начала 2010 года. На рисунке ниже символом Х в середине 2001 года помечен момент подписания контракта, который будет действовать до середины 2026 года. Цифровая подпись этого документа остается действительной по истечении срока действия секретного ключа, который использовался для создания этой подписи, поэтому открытый ключ должен храниться дольше секретного, так как он будет использоваться для верификации цифровой подписи и после окончания действия секретного ключа. Действительно, вполне вероятно, что другой электронный документ будет подписан в конце 2009 года непосредственно перед тем, как истечет срок действия секретного ключа, следовательно, открытый ключ должен храниться, по крайней мере, до 2035 года, потому что он может потребоваться для верификации цифровой подписи спустя 25 лет после подписания документа.


Рис.40 Сценарий использования секретного ключа для подписания деловых контрактов
В период 2010-2035 годов секретный ключ не может быть скомпрометирован, так как он либо уничтожается, либо защищённо хранится в архиве, таким образом, нет необходимости устанавливать более длительный срок хранения сертификата открытого ключа.

Ещё один пример: компрометация секретного ключа подписи. На рисунке ниже момент компрометации помечен символом Х в начале 2002 года. После обнаружения компрометации секретного ключа CA вносит сертификат соответствующего открытого ключа в список аннулированных сертификатов.

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


Рис.41 Сценарий компрометации секретного ключа подписи
Политика PKI должна определять, может ли надежность документа, подписанного до компрометации секретного ключа, подтверждаться в результате верификации подписи при помощи старого открытого ключа, или же для этой цели должен быть создан новый сертификат. В процессе развертывания PKI и выработки политики должны быть проанализированы все возможные сценарии управления жизненным циклом сертификатов и ключей и оценены последствия компрометации ключей.

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

Поэтому на сегодня общепринятым стало сочетание симметричной и ассиметричной криптографии. Алгоритмами с открытым ключом генерируется, шифруется, передаётся относительно компактный блок данных, обычно – ключ для симметричного алгоритма. Например, так устроена шифрующая подсистема в ОС Windows EFS: ключ (FEK) для симметричного шифрования собственно файлов защищается (шифруется) ассиметричным алгоритмом (RSA). Ещё один пример: протокол SSH, используемый для удалённого управления и туннелирования. Сеансовыми ключами для работы с симметричными алгоритмами (AES, 3DES,…) клиенты обмениваются, используя алгоритмы ассиметричные – DH, RSA.




Достарыңызбен бөлісу:
1   ...   10   11   12   13   14   15   16   17   ...   44


©kzref.org 2019
әкімшілігінің қараңыз

    Басты бет