[Более | Кроме] того, он также не является сколько-нибудь [уважаемым | ценимым] [преподавателем | педагогом]. Его студенты дают его [занятиям | лекциям] [самые низкие | негативные] оценки. Он самый непопулярный [преподаватель | учитель] нашей кафедры, [славящийся | печально известный] своей [привычкой | склонностью] [высмеивать | ставить в неудобное положение] студентов, осмелившихся задавать вопросы на его [лекциях | занятиях].
[Кроме | Помимо] того, [гранты | контракты] проф. Уилсона [почти | практически] не пополняют [фондов | финансовых запасов] нашей кафедры. Если не удастся быстро найти новый источник финансирования, [мы будем вынуждены | нам придется] [закрыть | прекратить] [много | ряд] [важных | специальных] программ, [таких как | среди которых] государственная программа 2025 года. К сожалению, при таких [условиях | обстоятельствах] я не могу [предлагать | рекомендовать] его вам на эту должность.
Затем Элен программирует свой компьютер на подсчет 232 профилей сообщения для каждого варианта обоих писем; вычисления занимают всю ночь. Есть шанс, что один профиль первого письма совпадет с одним из профилей второго письма. В противном случае Элен может добавить еще несколько вариантов слов и выражений в каждое письмо и попытаться еще раз вычислить профили за выходные. Предположим, она нашла совпадение. Назовем положительный отзыв письмом A, а отрицательный — письмом B.
Элен отправляет письмо A по электронной почте Мэрилин на утверждение. Содержание письма B она сохраняет в тайне, никому его не показывая. Естественно, Мэрилин утверждает письмо, вычисляет 64-разрядный профиль сообщения, подписывает профиль и отсылает его декану. Независимо от нее, Элен отправляет декану письмо B (вместо письма A, которое нужно отправить на самом деле).
Получив письмо и подписанный профиль, декан запускает алгоритм вычисления профиля сообщений для письма B, видит, что его профиль совпадает с тем, что ему прислала Мэрилин, и увольняет Тома. Он не догадывается, что Элен удалось создать два письма с одинаковыми профилями сообщений и отправить ему совсем не тот вариант, который читала и подписала Мэрилин. (Вариант с хэппи-эндом: Элен сообщает Дику о своих проделках. Потрясенный, Дик порывает с ней. Элен в ярости бежит сознаваться во всем Мэрилин. Мэрилин звонит декану. Том получает должность.) При использовании алгоритма SHA-2 подобную атаку шифра достаточно сложно выполнить. Даже если компьютер сможет вычислять по 1 трлн профилей в секунду, потребуется более 32 000 лет, чтобы перебрать по 280 вариантов для обоих писем, и это все равно не даст стопроцентной гарантии совпадения. Конечно, если параллельно запустить 1 млн процессоров, то вместо 32 000 лет потребуется 2 недели.
8.8. Управление открытыми ключами
Криптография с использованием открытых ключей позволяет передавать секретные данные, не обладая открытым ключом заранее, а также создавать электронные подписи сообщений без необходимости в привлечении третьей, доверительной стороны. Наконец, подписанные профили сообщений позволяют получателю легко и надежно проверять целостность и аутентичность полученных данных.
Между тем мы обошли один важный вопрос: если Алиса и Боб друг друга не знают, как они обменяются открытыми ключами перед началом общения? Очевидное решение — выложить ключ на веб-сайте. Однако так делать нельзя, и вот почему. Представьте, что Алиса хочет найти открытый ключ Боба на его сайте. Как она это делает? Набирает URL сайта. Браузер ищет DNS-адрес домашней страницы Боба и передает запрос GET (илл. 8.25). К сожалению, Труди в этот
Илл. 8.25. Способ вторжения в систему с открытыми ключами
момент перехватывает запрос и отсылает Алисе фальшивую страницу, например копию страницы Боба, на которой вместо его ключа выложен открытый ключ Труди. После того как Алиса зашифрует свое первое сообщение с помощью ET, Труди расшифрует его, прочтет, зашифрует с помощью открытого ключа Боба и перешлет ничего не подозревающему Бобу. Но гораздо хуже то, что Труди может менять сообщения перед повторным шифрованием и отправкой Бобу. Очевидно, необходим механизм секретного обмена открытыми ключами.
8.8.1. Сертификаты
Конечно, можно попытаться решить эту проблему с помощью центра распространения ключей (Key Distribution Center, KDC), круглосуточно доступного в интернете и предоставляющего открытые ключи по требованию. Однако у этого решения есть множество недостатков; в частности, оно не поддается масштабированию — такой центр очень быстро станет узким местом. А если он не выдержит нагрузки, вся интернет-безопасность в один момент сойдет на нет.
По этой причине возникло новое решение, не требующее постоянного доступа к центру распространения ключей. На самом деле даже не обязательно, чтобы центр вообще работал онлайн. Вместо этого на него возлагается обязанность сертификации открытых ключей, принадлежащих как физическим, так и юридическим лицам. Организация, выполняющая эту задачу, в настоящее время называется центром сертификации (Certification Authority, CA).
В качестве примера рассмотрим такую ситуацию: Боб хочет разрешить Алисе и другим лицам, с которыми он не знаком, устанавливать с ним защищенные соединения. Он приходит в CA со своим открытым ключом, а также паспортом или другим удостоверением личности и просит зарегистрировать ключ. CA выдает ему сертификат (похожий на тот, что показан на илл. 8.26) и подписывает хеш SHA-2 своим закрытым ключом. Затем Боб оплачивает услуги CA и получает документ, содержащий сертификат и его подписанный хеш (который в идеале должен передаваться по надежным каналам).
Настоящим удостоверяю, что открытый ключ
19836A8B03030CF83737E3837837FC3s87092827262643FFA82710382828282A
принадлежит
Роберту Джону Смиту
12345, Юниверсити-авеню
Беркли, Калифорния 94702
Дата рождения: 4 июля 1958 г.
Email: [email protected]
Хеш SHA-2 данного сертификата подписан закрытым ключом CA
Илл. 8.26. Пример сертификата и подписанного хеша
Основная задача сертификата — связать открытый ключ с именем принципала (физического или юридического лица). Сами сертификаты никак не защищаются и не хранятся в тайне. Боб может выложить его на свой сайт и поставить ссылку: «Здесь находится сертификат моего открытого ключа». Перейдя по ссылке, пользователь увидит и сертификат, и блок с подписью (подписанный хеш SHA-2 сертификата).
Теперь снова рассмотрим сценарий, показанный на илл. 8.25. Что может сделать Труди, перехватив запрос страницы Боба, отправленный Алисой? Она может выложить свой сертификат и блок с подписью на подложной странице, однако Алиса сразу догадается, что разговаривает не с Бобом: его имени в этом сертификате просто нет. Труди может изменить домашнюю страницу Боба на лету, заменив его открытый ключ своим собственным. Но Алиса может проверить сертификат алгоритмом SHA-2. Тогда она получит значение хеш-функции, которое не согласуется со значением, вычисленным по открытому ключу CA и блоку подписи. Труди не имеет доступа к закрытому ключу CA и никак не может сгенерировать блок подписи, содержащий хеш модифицированной страницы с открытым ключом Труди. Таким образом, Алиса может не беспокоиться о подлинности ключа Боба. Как мы и обещали, при такой схеме не требуется, чтобы CA постоянно работал онлайн. Тем самым ликвидируется потенциально узкое место системы.
Сертификат используется для связывания открытого ключа не только с принципалом, но и с атрибутом. Например, он может содержать такую информацию: «Данный открытый ключ принадлежит лицу старше 18 лет». Этим можно подтвердить статус принципала или убедиться в том, что ему разрешен доступ к некоторым специфическим данным, на которые накладываются возрастные ограничения. При этом имя владельца может и не раскрываться. Обычно владелец отсылает сертификат на веб-сайт, принципалу или процессу, запрашивающему информацию о возрасте клиента. В ответ генерируется случайное число, шифруемое с помощью открытого ключа (считываемого с сертификата). Если клиент (то есть владелец) сможет расшифровать его и отослать обратно, это будет служить подтверждением тому, что он действительно обладает указанными в сертификате характеристиками. Кроме того, это случайное число может быть использовано в качестве сеансового ключа для будущего соединения.
Сертификат может содержать атрибут еще в одном случае: если речь идет об объектно-ориентированной распределенной системе. Каждый объект обычно имеет несколько методов. Владелец объекта может предоставить каждому клиенту сертификат с битовой картой, где перечислены доступные ему методы. Эта битовая карта привязывается к открытому ключу с помощью подписанного сертификата. Если владелец сертификата докажет, что у него есть соответствующий закрытый ключ, он сможет воспользоваться методами, указанными в битовой карте. Особенность этого подхода состоит в том, что необязательно указывать имя владельца. Это полезно в ситуациях, в которых важна конфиденциальность.
8.8.2. X.509
Если бы все желающие подписать что-либо обращались в CA за сертификатами различных видов, обслуживание разнообразных форматов вскоре стало бы проблемой. Во избежание этого МСЭ разработал и утвердил специальный стандарт сертификатов. Он называется X.509 и широко применяется в интернете. Начиная с 1988 года вышло уже три версии X.509; мы рассмотрим новейшую из них — третью.
На стандарт X.509 сильное влияние оказала система OSI, из которой он позаимствовал худшие ее свойства, в частности принцип кодирования и именования. Удивительно, что IETF согласился с данной концепцией, учитывая, что практически во всех областях, начиная с машинных адресов и заканчивая транспортными протоколами и форматами электронных писем, IETF всегда игнорировал OSI и пытался сделать что-нибудь более толковое. IETF-версия X.509 описана в RFC 5280.
По сути, X.509 — это способ описания сертификатов. Основные поля сертификата перечислены на илл. 8.27. Из описаний, приведенных в правой колонке, должно быть понятно, для чего служит соответствующее поле. За дополнительной информацией обращайтесь к RFC 2459.