Атака на множественные UserID

Данный метод атаки был выявлен Сьювертом ван Оттерлоо в июле 2001 года. Проблема основана на неоднозначности, создаваемой ключами с несколькими именами пользователя (userID). Атака эксплуатирует ряд незначительных багов в графическом интерфейсе PGP 5.0 и более новых версий. Патч, устраняющий уязвимость, был выпущен 4 сентября 2001 года.

В разделе "Сеть доверия" мы обсуждали достоверность ключей. На тот момент мы исходили из того, что каждый ключ имеет только одно имя пользователя. Для PGP это неверно: ключи здесь могут иметь более одной записи сертификата. В таком случае с определением достоверности возникает проблема. Мы больше не можем говорить о достоверности ключа в целом: каждая запись сертификата может иметь независимое от других значение достоверности. Таким образом, следует отдельно рассматривать достоверность каждой из комбинаций ключа-имени, но не ключа, как такового. Зачастую такие детали можно опустить. Предположим, сертификат ключа несёт два имени пользователя: "Alice <alice@home.com>" и "Alice <alice@hotmail.com>". Если Алиса, создавшая ключ, обладает обоими из указанных адресов, то можно заключить, что ключ достоверен. Если же, напротив, создатель ключа не владеет ни одним из адресов и его даже не зовут Алисой, тогда ключ очевидно недостоверен.

Дело приобретает интересный оборот, если владелец ключа обладает лишь одним из указанных адресов и только иногда называет себя Алисой. Теперь одна связка "ключ-имя пользователя" достоверна, а другая — нет. В этом случае ключ не является полностью достоверным, но он также и не совсем недостоверный. Говорить о достоверности ключа здесь неразумно.

PGP не использует концепцию достоверности ключа, как таковую, и стандарт OpenPGP тоже не подразумевает её. Все подписи присваивают достоверность только одной записи сертификата. Зато пользовательский интерфейс пытается представить дело несколько проще, чем есть на самом деле: там есть зелёный/серый индикатор, обозначающий "достоверность ключа", а также шкала в окне свойств ключа, отображающая значение достоверности. Эти два элемента используют разные эвристики, чтобы сообщить достоверность пользователю программы:

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

Как оказалось, PGP сочетает эти два метода очень неудачным образом, позволяя злоумышленнику ввести пользователей в заблуждение. Чтобы воспользоваться этой неоднозначностью, нужен ключ с двумя записями сертификата. Ниже приведён рецепт по изготовлению такого ключа. Он описывает действия Евы, ¹ которая хочет одурачить Боба. Ей потребуется некоторое [невольное] участие Кэрол. Кэрол — близкая подруга Боба, и её ключ на связке Боба обозначен как доверенный. Это простая процедура, её можно исполнить, не вдаваясь в подробности формата OpenPGP-файлов. Предлагаемые имена файлов служат лишь напоминанием об их назначении и содержимом. Атака работает на всех новых версиях PGP: пятых, шестых и седьмых.

1. Ева генерирует ключ с именем Алисы, email-адресом Алисы или адресом, который кажется принадлежащим Алисе.
2. Ева добавляет собственное имя и email-адрес к ключу в качестве второй записи сертификата.
3. Ева экспортирует ключевую пару (вместе с закрытым ключом), сохраняя её в произвольном каталоге в файле temp1.asc.
4. Ева удаляет запись сертификата с именем Алисы и снова экспортирует ключ (без закрытого ключа), теперь содержащий только имя Евы, в файл tocarol.asc. Затем Ева удаляет этот ключ со связки.
5. Ева лично идёт к Кэрол, имея при себе файл tocarol.asc со своим открытым ключом. Кэрол удостоверяется, что ключ действительно принадлежит Еве, поэтому она подписывает его (экспортируемой подписью) и возвращает ключ с подписью обратно Еве (в файле fromcarol.asc), чтобы та могла убеждать других людей, что ключ на самом деле её. Издавая сертифицирующую подпись, Кэрол не заявляет, что доверяет Еве, а только то, что ключ действительно принадлежит ей.
6. Вначале Ева импортирует на свою связку файл temp1.asc. Затем она импортирует fromcarol.asc. Теперь она снова имеет свой ключ с двумя именами. Первым именем было имя Алисы, поэтому имя Алисы отображается как первичное имя ключа в окне связки PGP. Второе имя, имя Евы, заверено подписью Кэрол.
7. Ева экспортирует открытый ключ в файл alice.asc и пытается подсунуть его Бобу, когда тот ищет ключ Алисы.

Если Боб импортирует этот ключ в PGP и попробует сверить подпись, поставленную этим ключом, он увидит нечто странное. Обратите внимание на скриншот.

Как можно видеть в окне PGPlog (наверху слева), подпись была якобы сгенерирована Алисой и расценена достоверной. Что здесь происходит, так это то, что поле имени использует метод 1 и отображает первичное имя ключа. Зато индикатор достоверности в этом окне следует методу 2, вынося заключение по наиболее достоверной записи сертификата: по второй. Итак, Боб введён в заблуждение и наивно полагает, что файл был получен им от Алисы. Мы успешно подделали подпись!

Другие окна тоже показывают интересные вещи. Окно PGPkeys (внизу слева) отображает ровно то, что ему и следует: первое имя пользователя недостоверно, второе — достоверно, и, если имя Алисы установлено первичным именем ключа, то ключ в целом — тоже недостоверен. Окно свойств, однако, сбито с толку и/или само сбивает с толку. Оно показывает имя Алисы, но свойства — Евы, считая ключ достоверным и даже позволяя переместить ползунок доверия. Если Боб повысит доверие из-за того, что доверяет Алисе, первичная запись сертификата тут же станет достоверной (ведь она заверена теперь уже доверяемым ключом, собственно, этим же ключом), и Боб сможет начать шифровать свои секретные послания Алисе ключом Евы, а Ева сможет читать всё, что Боб отправляет Алисе! Обычно PGP не позволяет устанавливать доверие недостоверным ключам, но здесь он позволяет. Таким образом, и шкала достоверности, и ползунок доверия здесь неверны. (Либо окно свойств ключа должно показывать в заголовке другое имя. Именно смешение двух эвристических методов создаёт проблему.)

Опытные или внимательные пользователи PGP с лёгкостью раскусят атаку. Это ещё и весьма дерзкая атака: Ева вынуждена идентифицировать себя перед Кэрол, поэтому в случае провала её имя станет известно Бобу немедленно. По этим причинам едва ли кто-то решится провести эту аферу вживую. Тем не менее, если кто-то рискнёт, он или она имеет разумный шанс на успех. И если уж злоумышленнику удалось обдурить Боба, тот может подписать ключ и передать его своим друзьям. ² Достаточно одного разрыва в Сети доверия, чтобы ключ распространился и заразил всю систему (опять же, маловероятно, что такое действительно произойдёт, но и не совсем невероятно, если случится). Я считаю, эта атака имеет очень хорошее соотношение "цены/качества": взломщику совсем не требуются вычислительные ресурсы, только немного своего везения и беспечности пользователей.

Назад | Дальше

¹ Алиса, Боб, Кэрол, Ева (и другие) — это обычные персонажи в описаниях криптографических протоколов. Как правило, Ева (Eve, от eavesdropper (англ.) – перехватчик) выполняет пассивную роль, только прослушивая коммуникации. Задачи, которые в данной работе возложил на неё автор, чаще выполняет Мэллори, — прим. пер.

² Однако, это именно то, чего Бобу делать совершенно не следует. Он может по своему усмотрению устанавливать доверие (trust) ключу, но заверять своей подписью (т.е. указывать на достоверность, или подлинность, ключа — validity) должен лишь после личной встречи с Евой/Алисой. Если же он регулярно совершает такую глупость, его друзьям было бы полезно пересмотреть степень доверия (trust) к его сертифицирующим подписям, — прим. пер.