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

344	Глава 19. PKI: красивая мечта

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

19.3.2 Срок действия

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

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

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

Самым распространенным форматом сертификатов является Х.509 v3, который содержит просто немыслимое количество всякого мусора. Если вы не боитесь сойти с ума, почитайте справочник Питера Гутманна (Peter Guttmann) [39]. Если ваша система не должна обладать возможностью взаимо­ действия с другими системами, забудьте об Х.509 v3 раз и навсегда. Если же вам все-таки придется использовать Х.509 v3 — примите наши искренние соболезнования.

19.3.3 Отдельный центр регистрации

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

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

19.4 Заключение

345

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

Одно из наиболее неудачных решений — добавить к криптографическому протоколу третьего участника. В этом случае в спецификациях проекта бу­ дет фигурировать центр сертификации и еще один участник, который может называться, скажем, центром регистрации или ЦР (Registration Authority — RAJ. ЦС и ЦР будут рассматриваться как две совершенно отдельные сущно­ сти, в результате чего к системе добавится еще по крайней мере 100 страниц документации. Это плохо уже само по себе. Кроме того, нам понадобится описать взаимодействие между ЦР и ЦС. Мы даже встречали протоколы с тремя участниками, в которых ЦР авторизует ЦС, чтобы последний мог выдать сертификат. Это не просто безумие, но и хороший пример того, как требования пользователей могут навязать неудобоваримое техническое ре­ шение. Требования пользователей задают только внешнее поведение систе­ мы. Компании нужно обладать отдельными наборами функций для отдела кадров и IT-департамента, но это не значит, что программное обеспечение должно содержать для них отдельный код. Во многих ситуациях, в том чис­ ле и в данной, оба отдела могут с успехом использовать бблыпую часть одной и той же функциональности, а следовательно, бблыную часть одного и то­ го же кода. Использование одного и того же набора функций сертификации упрощает структуру системы, делает ее менее дорогостоящей, а также более мощной и гибкой, чем структура, основанная непосредственно на требова­ ниях пользователей, которые включают в себя и ЦС и ЦР. Двухуровневая схема сертификации позволяет отделу кадров и IT-департаменту совмест­ но использовать бблыную часть кода и протоколов. Разница будет касаться в основном пользовательского интерфейса, что совсем несложно реализовать. Применение подобной схемы, может, и приведет к появлению нескольких со­ тен дополнительных строк кода, но никак не нескольких сотен дополнитель­ ных страниц спецификации, для описания которых программе потребуются десятки тысяч строк кода.

19.4Заключение

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

346	Глава 19. PKI: красивая мечта

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

Глава 20

PKI: жестокая реальность

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

20.1Имена

Начнем с относительно простой проблемы — понятия имени. Инфраструк­ тура открытого ключа привязывает открытый ключ пользователя к его име­ ни. А что же такое имя?

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

Вданной главе речь идет не об официальных именах, которые указаны

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

348	Глава 20. PKI: жестокая реальность
	Когда деревня разрастается до размеров небольшого городка, число лю­

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

Когда небольшой городок превращается в настоящий мегаполис, ситуация изменяется еще сильнее. Оказывается, что на самом деле вы знакомы лишь с крохотным подмножеством жителей своего города. Что еще хуже, имена окончательно перестают быть уникальными. Вам будет очень сложно найти конкретного человека, зная о нем только то, что его зовут Джон Смит — ведь людей с таким именем в городе могут быть сотни! Значение имени начинает зависеть от контекста. Девушка по имени Алиса может быть знакома с тремя Джонами, но когда на работе она говорит о “Джоне”, всем понятно, что речь идет о том самом Джоне из отдела продаж. Позднее, говоря о “Джоне” уже в домашней обстановке, она может иметь в виду сына соседей. Связь между именем и конкретным человеком становится еще более туманной.

Теперь возьмем Internet. Вскоре число пользователей всемирной сети до­ стигнет миллиарда. Что значит имя “Джон Смит” в Internet? Практически ничего: людей с такими именем и фамилией слишком много. Поэтому для идентификации людей вместо традиционных имен используются адреса элек­ тронной почты. Теперь вы общаетесь не с Джоном Смитом, а с j smith5330 yahoo.com. Это имя, конечно же, уникально, но для вас оно не привязано к конкретной личности, т.е. к человеку, которого вы наглядно знаете. Да­ же если вы узнаете его адрес и номер телефона, он все равно останется для вас неким абстрактным человеком, живущим где-то на другом конце мира. Вы никогда не встретите его лично, если только не сделаете этого специ­ ально. Неудивительно, что многие пользователи Internet зачастую пытаются представить себя совсем другими людьми с другими именами, возрастом, увлечением и привычками. И естественно, у каждого человека может быть масса имен. Многие пользователи в конце концов обрастают горами адресов электронной почты. (У нас их, например, никак не меньше десятка.) Крайне

20.1 Имена

349

сложно определить, ссылаются ли два адреса электронной почты на одного

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

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

укаждого гражданина было одно официальное имя, которое фигурирует

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

ифамилией; поэтому на практике имя часто расширяют такими данными, как адрес, номер водительских прав и дата рождения. Это, однако, все еще не гарантирует уникальность идентификатора конкретного человека1. Кроме того, в течение жизни человека некоторые из этих идентификаторов могут измениться. Люди меняют адреса, номера водительских прав, имена и даже пол. Пожалуй, единственное, что не изменяется, — это дата рождения, но не следует забывать, что многие намеренно ее искажают.

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

и“подгоняют” иностранные имена под похожие, “правильные” имена на своем языке.

Во избежание путаницы во многих странах жителям присваивают уни­ кальные номера наподобие номеров социального страхования (Social Security number — SSN) в США или номеров SoFi в Нидерландах. Главное назна­ чение этого номера состоит в присвоении каждому человеку уникального

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

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

Номера водительских прав действительно уникальны, но права есть не у всех.

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

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

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

20.2Полномочный орган

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

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

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

20.3 Доверие	351

дом. Имя Фред Смит вполне подходит для идентификации этого человека среди служащих компании.

20.3Доверие

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

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

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

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

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

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

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

20.4Непрямая авторизация

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

Для разрешения данной проблемы большинством систем используются так называемые списки контроля доступа (access control list — ACL). Спи­ сок контроля доступа — это всего лишь база данных, в которой указано, кому из пользователей системы какие действия разрешено выполнять. Ино­ гда содержимое списка контроля доступа сортируется по имени пользовате­ ля (например, пользователю по имени Боб разрешено выполнять следующее: открывать файлы в каталоге /usr/bob, использовать офисный принтер, осу­ ществлять доступ к файловому серверу), но в большинстве случаев список контроля доступа индексируется по действию (например, вносить деньги на данный счет может только Боб либо Бетти). Зачастую для упрощения спис­ ков контроля доступа пользователей объединяют в группы, однако базовая функциональность при этом не изменяется.

Итак, теперь у нас есть три объекта: ключ, имя и разрешение на выпол­ нение какого-нибудь действия. Система при этом должна знать, какой ключ какое действие авторизует, другими словами, есть ли у заданного ключа раз­ решение на выполнение определенного действия. Классическая инфраструк­ тура открытого ключа решает эту проблему, привязывая ключи к именам и используя список контроля доступа, чтобы привязать имена к разрешени­ ям. Это непрямой метод авторизации, который к тому же создает больше потенциальных объектов для нападения [27].

Первый объект нападения — это сертификат типа “имя-ключ”, выдан­ ный инфраструктурой открытого ключа. Второй объект нападения — база

20.5 Прямая авторизация

353

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

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

20.5Прямая авторизация

Намного эффективнее привязать разрешения непосредственно к ключу, используя для этого инфраструктуру открытого ключа. Сертификат боль­ ше не будет привязывать ключ к имени; вместо этого он связывает ключ с набором разрешений [27].

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

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