Атака на множественные 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 и пытается подсунуть его Бобу, когда тот ищет ключ Алисы.