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

354	Глава 20. PKI: жестокая реальность

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

Так, может быть, стоит совсем избавиться от имен в сертификатах? Вообще-то нет. Хотя имена и не будут фигурировать в обычных опера­

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

20.6Системы мандатов

Продолжая развивать описанный принцип доступа на основе разрешений, мы получим полноценную систему мандатов. Это уже не просто инфраструк­ тура, а суперинфраструктура открытого ключа. В подобной системе для выполнения каждого действия пользователю нужно иметь мандат (creden­ tial) в виде подписанного сертификата. Если у пользователя А есть мандат, который разрешает ему открывать конкретный файл для чтения и записи, этот пользователь может передать полностью или частично свои полномочия пользователю Б. Например, пользователь А может подписать сертификат от­ крытого ключа пользователя Б, в котором будет утверждаться нечто напо­ добие: “Ключу РКд разрешено открывать файл X для чтения, так как ему были переданы полномочия ключа РК^”. Если пользователь Б хочет считать файл X , он должен предъявить этот сертификат, а также сертификат, дока­

20.6 Системы мандатов

355

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

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

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

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

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

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

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

вкаком-либо уровне доступа, что подрывает безопасность всей системы. В-третьих, чтобы реализовать систему мандатов, необходимо разработать

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

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

ний.. Он также должен быть разработан с запасом на будущее. После того как система мандатов будет развернута, в каждую программу понадобит­

2Многие клиенты требуют, чтобы система обладала подобным свойством, однако нам это кажется в корне неверным. Ограничение возможности пользователя Б передавать свои полномочия другим лишь вынуждает его запустить какую-нибудь службу прокси, благо­ даря которой другие пользователи смогут применять мандат пользователя Б для доступа к нужным ресурсам. Использование подобных программ подрывает инфраструктуру без­ опасности и должно быть запрещено, но это имеет смысл только тогда, когда у людей нет практических причин передавать свои полномочия и, следовательно, запускать прокси. А такие причины всегда найдутся.

356	Глава 20. PKI: жестокая реальность

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

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

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

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

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

исистемные администраторы, что уж говорить о рядовых пользователях!

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

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

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

20.7 Измененная мечта

357

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

20.7 Измененная мечта

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

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

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

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

Как видите, измененная мечта стала более реалистичной. Она также об­ ладает ббльшими возможностями, большей гибкостью и безопасностью, чем первоначальная. Было бы так приятно считать, что измененная мечта решит все наши проблемы управления ключами! К сожалению, существует пробле­ ма (она описана в следующем разделе), которая никогда не будет решена до конца и всегда будет требовать компромиссов.

358	Глава 20. PKI: жестокая реальность

20.8 Отзыв

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

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

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

•Скорость отзыва. Какое максимально допустимое количество време­ ни может пройти между поступлением команды на отзыв и последним использованием сертификата?

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

•Количество отзывов. Сколько отзывов могут обрабатываться одно­ временно?

Существует два практических решения проблемы отзывов: списки отзыва и быстрое устаревание.

20 .8.1 Список отзыва

Список отзыва сертификатов (certificate revocation list — CRL) представ­ ляет собой базу данных, в которой перечислены отозванные сертификаты.

3Программа PGP использует собственную довольно странную инфраструктуру, кото­ рая по своему назначению напоминает PKI и называется с е т ь ю д о в е р и я (w eb o f trust). На практике данная концепция слишком сложна для понимания пользователей, а потому применяется только в ограниченном масштабе.

20.8 Отзыв

359

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

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

Несмотря на это, у централизованной базы данных отзыва есть и суще­ ственные недостатки. Каждый член PKI должен быть постоянно подключен к центру сертификации, чтобы он мог в любой момент обратиться к списку отзыва сертификатов. Кроме того, при использовании централизованной ба­ зыданных у системы появляется так называемая одна точка сбоя (single point of failure): если база данных окажется недоступной, выполнение каких-либо действий станет невозможным. Некоторые решают эту проблему, позволяя членам PKI продолжать свою работу, даже если база данных отзыва сер­ тификатов окажется недоступной. В этом случае, однако, злоумышленники будут использовать атаки типа “отказ в обслуживании”, чтобы деактивизировать базу данных и вывести из строя систему отзыва.

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

Некоторые системы просто рассылают полные копии базы данных отзыва сертификатов всем своим устройствам. Подобный принцип применялся во­ енными силами США при шифровании телефонных разговоров с помощью оборудования STU-III (Secure Telephone Unit, Third Generation — безопасный телефонный аппарат третьего поколения). Точно так же поступают н банки, когда рассылают по магазинам маленькие книжечки с номерами украденных кредитных карт. Реализовать такую схему отзыва сравнительно несложно. Каждое устройство системы может периодически (скажем, раз в полчаса) загружать с Web-сервера обновленную версию списка отзыва сертификатов. Разумеется, это несколько снизит скорость отзыва. К сожалению, данное ре­ шение накладывает ограничения на размер базы данных отзыва сертифика­ тов. Мало кто может позволить себе, чтобы на каждое устройство системы постоянно копировался список, состоящий из сотен тысяч сертификатов. Нам попадались системы, в которых размер списка отзыва был ограничен 50 эле­ ментами. Думаем, способ нападения на такую систему понятен и школьнику.

360	Глава 20. PKI: жестокая реальность

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

20 .8.2 Быстрое устаревание

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

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

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

20.8.3 Отзыв обязателен

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

20.9 Где может пригодиться инфраструктура открытого ключа

361

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

20.9Где может пригодиться инфраструктура открытого ключа

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

Ничего не вышло.

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

Но, если мы все время подключены к ЦС, нам вовсе не нужна большая и сложная инфраструктура открытого ключа. Желательной безопасности можно достичь гораздо проще, с помощью централизованного сервера клю­ чей наподобие описанного в главе 18, “Серверы ключей”.

Рассмотрим преимущества инфраструктуры открытого ключа по сравне­ нию с использованием сервера ключей.

•Сервер ключей требует, чтобы каждый участник общения был все время

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

362	Глава 20. PKI: жестокая реальность

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

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

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

•Теоретически инфраструктура открытого ключа должна гарантировать соблюдение пользователями своих обязательств. Оно состоит в следую­ щем: если пользователь А подписал сообщение своим ключом, он не мо­ жет впоследствии отрицать факт подписывания этого сообщения. Сер­ вер ключей подобным свойством не обладает. Главный сервер имеет до­ ступ к ключу, который применяется пользователем А, а потому может легко отправить поддельное сообщение, подписанное якобы пользова­ телем А. На практике, однако, принцип соблюдения обязательств не срабатывает, потому что люди не в состоянии обеспечить достаточную надежность хранения своих секретных ключей. Если пользователь А захочет отрицать факт подписывания сообщения, он может просто за­ явить, что его компьютер подвергся нападению вируса, который и украл закрытый ключ.

•Самым важным ключом PKI является ключ корневого центра серти­ фикации. Его не обязательно хранить на компьютере, подключенном

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

20.10 Что выбрать

363

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

20.10Что выбрать

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

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

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

Тем, кто разрабатывает большую систему, мы бы посоветовали внима­ тельно приглядеться к инфраструктуре открытого ключа, но все же сравнить ее с решением на основе сервера ключей. Подумайте, стоят ли преимущества инфраструктуры открытого ключа ее дороговизны и сложности. Особенно трудно придется тем, кому действительно необходимо ограничить полномо­ чия подчиненных центров сертификации с помощью системы мандатов. Для описания ограничений вам понадобится некоторая логическая структура (lo­ gical framework). Универсальной логической структуры для выполнения за­ дач такого рода не существует, а следовательно, проектирование данной ча­ сти системы будет полностью определяться требованиями ваших заказчиков. Это, вероятно, также означает, что вы не сможете воспользоваться готовыми инфраструктурами открытого ключа от других производителей, поскольку подобные продукты вряд ли будут содержать язык описания ограничений.