книги / Практическая криптография

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

Идея, лежащая в основе применения сервера ключей, очень проста. Мы предполагаем, что каждый пользователь обменивается общим секретным ключом с сервером ключей. Например, пользователь А выбирает ключ К а , который будет известен только ему и серверу ключей. Пользователь Б выби­ рает ключ Кв, который будет известен только ему и серверу ключей. Ана­ логичным образом свои секретные ключи выбирают и остальные участники общения.

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

18.2 Kerberos

Описанная идея легла в основу Kerberos — системы управления ключами, которая широко используется во всем мире [57]. Родоначальником Kerberos стал протокол Нидхэма-Шредера (Needham-Schroeder) [75].

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

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

ЦРК (Key Distribution Center — KDC), не нужно обновлять свое состояние слишком часто. Разумеется, сервер ключей должен помнить все общие клю­ чи, которыми он обменялся с каждым участником. Тем не менее, когда поль­ зователь А просит ЦРК создать ключ для общения между ним и пользова-

«гелем Б, ЦРК выполняет свою функцию и тут же об этом забывает. Он не следит за тем, какие ключи были сгенерированы им для общения пользо­ вателей друг с другом. Это очень удобное свойство, так как оно позволяет без особых трудностей распределить сверх меры загруженный сервер клю­ чей между несколькими компьютерами. Поскольку серверу ключей не нуж­ но обновлять свое состояние, пользователь А может в один момент общаться с одной копией сервера, а в следующий момент — уже с другой его копией.

Оказывается, что криптографические протоколы, которые требуются для работы систем на основе Kerberos, очень сложны. Вначале проектирование подобных протоколов выглядит довольно простым, но даже разработки опыт­ ных криптографов в конце концов оказывались взломанными. Изъяны, кото­ рым удается проникнуть в эти протоколы, крайне тонки и незаметны. Мы не будем рассматривать протоколы такого типа, поскольку считаем их слишком опасными. Даже мы избегаем разрабатывать их “с нуля”. Если вам действи­ тельно нужен подобный протокол, воспользуйтесь последней версией Ker­ beros. Он уже довольно давно применяется на практике и тщательно изучен многими компетентными критиками.

18.3Решения попроще

Иногда использовать Kerberos невозможно. Структуру этого протокола никак не назовешь простой. Кроме того, она накладывает на систему неко­ торые ограничения. Серверы должны запоминать все принятые ими билеты, а каждому участнику общения нужны надежные часы1. В некоторых ситуа­ циях удовлетворить подобные требования невозможно.

Между тем мы можем создать более простое и надежное решение, если не будем слишком заострять внимание на эффективности. Оказывается, что со­ хранение сервером ключей своего состояния может весьма пригодиться для распространения ключей. Современные компьютеры намного мощнее, чем вычислительные машины тех лет, когда создавался Kerberos. Поэтому они не должны испытывать затруднений, сохраняя состояние сервера для десят­ ков тысяч участников. Даже наличие большой системы со 100 000 участников не представляет особых проблем: если на каждого участника потребуется по 1 Кбайт для сохранения состояния на сервере ключей, сохранение всех состо­ яний потребует лишь 100 Мбайт памяти. Разумеется, сервер ключей все же должен быть достаточно быстрым, чтобы генерировать все запрашиваемые ключи, но это не составит проблем для современных быстрых компьютеров.

Мы ограничимся тем, что рассмотрим использование только одного сер­ вера ключей. Существуют методы, с помощью которых состояние сервера

1Билет (ticket) — это сообщение, которое пользователь А отсылает пользователю Б. Это стандартная терминология Kerberos.

ключей может быть распределено между несколькими компьютерами. Вда­ ваться в подробности этих методов мы не будем, так как не собираемся созда­ вать сервер ключей для десятков тысяч участников: это слишком рискованно. Опасность больших серверов ключей состоит в том, что все ключи находятся

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

влюбой удобный момент. Текущие средства безопасности не очень хорошо защищают компьютеры от сетевых атак, а размещение всех ключей в одном и том же месте равносильно подготовке к убийству. В системах меньшего размера общая “сумма” ключей, которые хранятся на сервере, относительно невелика, поэтому вероятность угрозы снижается2. В следующих нескольких главах мы рассмотрим инфраструктуру управления ключами, которая хо­ рошо подходит для крупных систем. В свою очередь, для описания сервера ключей ограничимся сравнительно небольшими системами — до нескольких тысяч участников.

18.3.1Безопасное соединение

Попробуем кратко описать наше простое решение. Прежде всего предпо­ ложим, что пользователь А и сервер ключей совместно применяют общий ключ К а - Вместо того чтобы использовать этот ключ непосредственно для обмена данными, они запускают с его помощью протокол согласования клю­ чей наподобие описанного в главе 15, “Протокол согласования ключей”. (Если К а — это пароль, вам следовало бы использовать один из протоколов, пред­ назначенных для обработки паролей с низкой степенью энтропии (см. раз­ дел 15.12). К сожалению, это влечет за собой все проблемы, связанные с их лицензированием.) Протокол согласования ключей генерирует для сервера ключей и пользователя А новый ключ К'А. Все другие участники общения запускают этот же протокол между собой и сервером ключей, в результате чего каждый из них получает по новому ключу для обмена данными с сер­ вером ключей.

Пользователь А и сервер ключей применяют ключ К'А для создания без­ опасного канала общения (см. главу 8, “Безопасный канал общения”). Исполь­ зуя последний, пользователь А и сервер ключей могут безопасно взаимодей­ ствовать друг с другом. Безопасный канал общения обеспечивает и конфи­ денциальность, и аутентификацию, и даже защиту от атак воспроизведения. Весь последующий обмен данными между пользователем А и сервером клю­ чей происходит по безопасному каналу общения. Аналогичные каналы для взаимодействия с сервером создают и другие участники.

2Вообще-то нам не нравится оставлять в системе хоть какую-нибудь вероятность угрозы, но в управлении ключами всегда приходится выбирать компромиссное решение.

18.3.2Создание ключа

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

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

спользователем Б напрямую.

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

18.3.3Обновление ключа

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

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

18.3.4 Другие свойства

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

Использование протокола согласования ключей для установки безопасно­ го канала общения имеет еще одно преимущество — обеспечивает прямую безопасность. Даже если ключ К а пользователя А будет взломан, это не повлияет на предыдущие ключи безопасного канала общения К'А, а значит, все прежние сообщения, которыми пользователь А обменивался с другими участниками, останутся в безопасности.

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

18.4Что выбрать

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

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

Глава 19

PKI: красивая мечта

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

19.1Краткий обзор инфраструктуры открытого ключа

Инфраструктура открытого ключа (Public-Key Infrastructure — PKI)

представляет собой систему, с помощью которой можно определять, кому принадлежит тот или иной открытый ключ. Рассмотрим ее классическое опи­ сание.

Существует некий центральный орган, который называется центром сер­ тификации или ЦС (Certificate Authority — СА). Центр сертификации обла­ дает парой “открытый ключ-закрытый ключ” (например, парой ключей RSA) и публикует свой открытый ключ. Будем исходить из предположения, что от­ крытый ключ центра сертификации известен всем. Поскольку данный ключ остается неизменным на протяжении длительных периодов времени, достичь этого будет несложно.

Чтобы присоединиться к инфраструктуре открытого ключа, пользова­ тель А генерирует собственную пару “открытый ключ-закрытый ключ”. За­ крытый ключ он сохраняет в секрете, а открытый ключ РКд передает центру сертификации со следующим пояснением: “Привет, я пользователь А, и у ме­

ня есть открытый ключ РКд”. Центр сертификации проверяет, действительно ли пользователь А является тем, за кого себя выдает, а затем подписывает цифровое утверждение примерно следующего содержания: “Ключ РКа при­ надлежит пользователю А”. Это подписанное утверждение называется сер­ тификатом (certificate). Оно удостоверяет, что данный ключ принадлежит пользователю А.

Теперь, если пользователь А захочет пообщаться с пользователем Б, он может отослать ему свой открытый ключ и сертификат. У пользователя Б есть открытый ключ центра сертификации, с помощью которого он может проверить цифровую подпись последнего. Если пользователь Б доверяет цен­ тру сертификации, он может довериться и тому, что ключ РКд действительно принадлежит пользователю А.

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

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

На первый взгляд звучит довольно просто.

19.2Примеры инфраструктуры открытого ключа

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

19.2.1Всеобщая инфраструктура открытого клю ча

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

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

19.2.2Доступ к виртуальным частным сетям

В качестве более реального примера можно привести компанию, у которой есть виртуальная частная сеть (virtual private network — VPN). С ее помо­ щью сотрудники компании могут осуществлять доступ к корпоративной сети прямо го дома или, скажем, го гостиничного номера во время путешествия. Точки доступа VPN должны уметь распознавать людей, которым разрешено получать доступ к сети, и предоставлять им соответствующий уровень до­ ступа. В этом случае IT-департамент компании выступает в качестве центра сертификации. Он предоставляет каждому сотруднику сертификат, благода­ ря которому точка доступа VPN сможет распознать этого сотрудника.

19.2.3Электронные платежи

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

19.2.4Нефтеперегонный завод

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

и развернуть инфраструктуру открытого ключа для всех датчиков, чтобы

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

19.2.5 Ассоциация кредитных карт

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

19.3Дополнительные детали

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

19.3.1Многоуровневые сертификаты

Довольно часто центр сертификации разбивается на несколько частей. Например, ассоциации кредитных карт было бы крайне утомительно самой сертифицировать каждый банк. Сертификацией отдельных банков занима­ ются ее региональные отделения. Это приводит к появлению двухуровне­ вой структуры сертификатов. Главный ЦС выдает сертификат на открытый ключ регионального отделения. Этот сертификат утверждает нечто наподо­ бие “Ключ РКх принадлежит региональному отделению X и может приме­ няться для сертификации других ключей”. После этого региональное отделе­ ние может сертифицировать ключи отдельных банков. Сертификат откры­ того ключа банка состоит из двух подписанных сообщений: сообщения глав­ ного ЦС, которое авторизует ключ регионального отделения, и сертификата, выданного региональным ЦС ключу банка. Такая структура называется це­ почкой сертификатов (certificate chain) и может быть расширена на любое количество уровней.

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

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

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

Следует быть крайне осторожным, выстраивая цепочки сертификатов на­ подобие описанной выше. Они усложняют систему, а сложность — это всегда плохо. Вот лишь один пример из недалекого прошлого. Защищенные Webузлы в Internet используют систему PKI, чтобы обозреватели пользователей могли идентифицировать эти узлы. На практике эта система оказалась не очень защищенной. Если бы все дело было только в пользователях, которые не утруждают себя проверкой имени посещаемого Web-узла! К сожалению, около года назад критическая ошибка была обнаружена и в библиотеке, кото­ рая удостоверяет правильность сертификатов всех операционных систем Mi­ crosoft. Каждый элемент цепочки сертификатов содержит флажок, который показывает, является ли сертифицируемый ключ ключом центра сертифи­ кации. Ключам центров сертификации разрешено сертифицировать другие ключи. Ключи остальных субъектов этого делать не могут. Это очень важ­ ное различие. К сожалению, упомянутая библиотека не проверяла данный флажок. Как следствие, злоумышленник мог приобрести сертификат, ска­ жем, для домена nastyattacker.com и воспользоваться им, чтобы самому заверить подделанный ключ узла amazon.com. Обозреватель Microsoft Inter­ net Explorer использовал ту самую библиотеку, в которой была обнаружена ошибка. Он мог принять сертификат фальшивого ключа Amazon, выданный узлом nastyattacker.com, и отобразить поддельный Web-узел под видом на­ стоящего узла Amazon. Подумать только: глобальную систему безопасности, на разработку которой было затрачено столько средств и усилий, удалось обмануть с помощью малюсенькой ошибки в одной-единственной библиоте­ ке! Как только о наличии ошибки стало известно широкой общественности, Microsoft выпустила исправление библиотеки (специалистам компании пона­ добилось несколько попыток, чтобы устранить эту проблему). Тем не менее это хороший пример того, как одна маленькая ошибка может разрушить без­