Трудно понять, что такое PKI, учитывая, что она используется повсюду, от сертификатов до ключей шифрования. Давайте попробуем разобраться в этом. Источник - LAN

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

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

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

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

«Чем больше бизнес-операций проводится в интерактивном режиме, тем более полезной и значимой будет система позитивной идентификации, например цифровой сертификат», — считает Том Паттерсон, исполнительный директор по вопросам управляемых служб в компании KPMG Consulting.

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

НЕ ТОЛЬКО ШИФРОВАНИЕ

Шифрование — наиболее известная область применения системы с открытыми ключами, но ее можно использовать и для других важных целей. «PKI оказывается весьма полезна в таких приложениях, как аутентификация, обеспечение целостности и фиксация авторства, строгое выполнение обязательств, а также идентификация и поддержка конфиденциальности, — утверждает Кален Кинг, менеджер по маркетингу продуктов PKI компании Baltimore Technologies. — Шифрование, безусловно, необходимо, но оно имеет второстепенное значение».

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

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

Следующий шаг — авторизация, когда определяются особые права в системе для конкретного лица. Например, клиенту по имени Боб разрешено перевести ограниченную сумму денег в течение одного дня.

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

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

КЛЮЧИ, СЕРТИФИКАТЫ И ПОДПИСИ

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

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

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

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

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

Как и в случае с указанными документами, цифровой сертификат предоставляет наделенная особыми правами организация, в данном случае это сертификационный центр (Certificate Authority, CA). При использовании простой архитектуры PKI функции CA по выдаче сертификатов конечным пользователям может выполнять системный администратор. В более сложной среде в качестве CA может выступать крупное предприятие, государственное агентство или независимый консорциум, который действует как доверительный агент в рамках конкретной отрасли.

Цифровые сертификаты, созданные на основе стандарта X.509, содержат массу информации, в том числе серийный номер, который CA присваивает сертификату, дату окончания срока действия сертификата, имя держателя сертификата и его открытый ключ (см. Рисунок 2).

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

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

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

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

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

ЭЛЕМЕНТЫ ГОЛОВОЛОМКИ

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

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

Хранилище содержит текущие сертификаты и список отозванных сертификатов. Это открытая база данных, информация из которой о выданных и отозванных сертификатах пересылается по запросу. Хранилище публикует свои данные в каталоге, созданном либо на базе упрощенного каталога службы протоколов (Lightweight Directory Access Protocol, LDAP), либо на основе каталога X.500 (протокол CCITT для поддержки единой логической структуры файлов и каталогов, размещенных на нескольких физических системах).

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

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

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

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

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

Другой и, возможно, более серьезный минус связан с оперативностью обновления таких списков. Скажем, вы обновляете свой CRL дважды в день, в 10 ч утра и в 4 ч дня. Каковы будут последствия, если сотрудника уволят во время обеденного перерыва? Что касается PKI, то этот человек будет иметь все права, определенные сертификатом, еще в течение 4 ч, т. е. у раздраженного служащего окажется достаточно времени, чтобы в отместку оставить после себя если не пепелище, то некоторые разрушения.

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

Еще одна возможность — интерактивный протокол статуса сертификатов (Online Certificate Status Protocol, OCSP), с помощью которого пользователи могут проверить статус сертификата в режиме реального времени, не ожидая, пока CA выпустит обновленный CRL. Как отметил Марк Диодети, старший менеджер по продуктам RSA Keon и RSA WebPassPort, протокол OCSP был создан как основная технология для проверки сертификатов в режиме реального времени.

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

КЛЮЧИ ОТ ЦАРСТВА

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

«Строжайшая защита выданного личного ключа — критически важный компонент PKI», — напоминает Лайза Притти, исполнительный директор PKI Forum, независимой от производителей организации, которая пропагандирует технологию с открытыми ключами.

Защита ключа зависит от выбранного метода хранения ключа; иными словами, будут ли ключи конечных пользователей храниться на смарт-картах или на настольной системе? Диодети описывает четыре основных метода хранения ключа. Первый предусматривает хранение личного ключа на смарт-карте и считается самым безопасным, поскольку сами смарт-карты защищены от подделки. Наиболее безопасным методом хранения ключей Диодети в настольной системе называет парную аутентификацию с помощью аппаратного ключа и пользовательского PIN. Следующий метод — защита с использованием кодовой фразы, посредством которой личный ключ шифруется в настольной системе. И, наконец, наименее надежный способ состоит в хранении ключа в браузере в виде незашифрованного текста.

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

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

Так какое же решение наиболее подходящее? «На самом деле, это зависит от степени риска и требуемого уровня безопасности, а также от того, какой метод лучше всего подходит для данной среды, — рассуждает Притти. — Многие европейские организации считают, что ключи следует хранить на аппаратных устройствах, поэтому они выбирают смарт-карты. В Соединенных Штатах большинство компаний предпочитает держать ключи в зашифрованном виде в настольной системе».

Имейте в виду, что пользователи, скорее всего, будут иметь не одну пару ключей. Как правило, они используются либо для шифрования, либо для цифровых подписей. Иными словами, у пользователя может быть один набор ключей для шифрования, а другой — для цифровых подписей. Зачем это нужно? Если у вас есть резервная копия личного ключа для цифровых подписей, то значимость этой подписи с точки зрения фиксации авторства снижается, поскольку ключ больше не уникален для конечного пользователя. «Копии ключей, служащих для формирования цифровых подписей, не стоит делать никогда», — убежден Диодети.

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

Еще один вопрос, связанный с ключами, касается возможности применения их в нескольких приложениях. Например, если конечные пользователи работают с разными программами электронной почты, поддерживать несколько пар ключей для каждой из программ будет довольно обременительно. Переносить ключи и сертификаты между приложениями позволяют два интерфейса — Public Key Cryptography Standard (PKCS) #11 и Cryptographic API (CAPI) компании Microsoft.

Как легко предположить, это конкурирующие интерфейсы. PKCS #11 предназначен для программ на базе UNIX, а Microsoft разработала CAPI для своей собственной платформы. «PKCS #11 представляет собой открытый стандарт. Он существует уже достаточно давно и используется очень широко», — сообщает Паттерсон.

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

Так что же следует поддерживать вам? «Если вы работаете исключительно в среде Windows, я бы посоветовал выбрать Crypto-API. При наличии компьютеров разных типов от различных компаний предпочтение следует отдать PKCS #11. Но на самом деле не так уж сложно поддерживать оба интерфейса», — советует Паттерсон.

ФИЗИЧЕСКАЯ ЗАЩИТА

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

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

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

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