Это старая редакция страницы Библиотека / Статьи / Анализ Надежности P G P / Формат Файлов P G P / Пакеты Подписей за 27/11/2007 19:56.
Пакеты подписей
В PGP используется целое множество подписей. Сертифицирующие подписи создаются на открытых ключах, чтобы подтвердить взаимосвязь между открытым ключом и именем пользователя (User ID, записью сертификата). Частный случай подобных подписей — это автоподпись, которая создаётся на сертификате ключа самим этим ключом. Подписи также могут ставиться на сообщениях и файлах. И, наконец, подпись может не зависеть ни от каких внешних данных: такова, к примеру, аннулирующая подпись.
Схема подписей PGP в исполнении Ральфа Сендерека
Смысл подписи определяется её типом. Вот существующие типы:
- 00 — Подпись на двоичном объекте: подписант утверждает, что обладает файлом, создал или видел его, либо что файл не был изменён.
- 01 — Подпись на текстовом документе. Отличие этого типа от предыдущего в том, что в данном случае перед вычислением подписи производится конвертация окончаний строк в [возврат каретки][перенос строки] и из конца строк удаляются пробелы. Это очень полезно, поскольку подпись остаётся действительной, даже если переслать документ на компьютер с другой ОС, имеющей иные правила переноса строк.
- 02 — Самостоятельная подпись: она покрывает только собственные субпакеты. Это необходимо для подписей v4, которые могут содержать множество дополнительной информации.
- 10 — Общая сертификация открытого ключа и имени пользователя (generic certification). Она не определяет, насколько доскональную проверку проводил поручитель перед подписанием ключа.
- 11,12,13 — Обозначают, соответственно, личную (persona), небрежную (casual) и позитивную (positive) проверку ключа и записи сертификата. Они дают некоторые сведения об усилиях поручителя, затраченных на проверку: "личная" означает, что поручитель не проводил вообще никакой проверки, "небрежная" означает, что была проведена некоторая поверхностная проверка, а "позитивная" означает тщательную детальную проверку. Тем не менее, всё это очень туманно. Если верить стандарту OpenPGP, эта туманность есть не ошибка, а цель системы, но я не вижу смысла в такой детализации без конкретизации её смысла. Все сертифицирующие подписи программы PGP на данный момент имеют тип 10.
- 18 — Подпись привязки подключа. Говорит о том, что данный подключ относится к подписавшему его главному ключу. Она вычисляется на самом подключе, а не на каких-либо записях сертификата.
- 1F — Подпись на ключе. (В отличие от типов 10-13, вычисляется непосредственно на ключе, не затрагивая записи сертификата.) Подпись может содержать субпакеты, предоставляющие информацию о самом ключе. Чтобы она была расценена достоверной, подпись должна быть сгенерирована самим целевым ключом. Другие пользователи смогут использовать её, чтобы с помощью субпакетов делать определённые оценки о ключе.
- 20 — Подпись аннулирования ключа. Вычисляется на подлежащем аннулированию открытом ключе. Она может быть издана как самим этим ключом, так и другим ключом, определённым как ключ аннулирования ("уполномоченным отменителем").
- 30 — Подпись отзыва сертифицирующей подписи. Такая подпись способна аннулировать (отзывать) подтверждающие подписи типов 10-13. Она может быть издана либо ключом, издавшим изначальную подтверждающую подпись, либо "уполномоченным отменителем" того же ключа.
- 40 — Подпись метки времени: заверяет только отражённое в ней время.
Когда подпись вычисляется на данных, содержащих сам ключ подписи, она называется автоподписью. Автоподпись может относиться к типам 10,11,12,13,18 и 1F. Автоподписи важны, поскольку гарантируют, что заверяемая ими связь (между записью сертификата и ключом в случаях 10,11,12,13 либо между ключом и подключом для 18) создана самим владельцем ключа.
Version 3
Подпись v3 содержит:
Метка времени кодируется в четырёх байтах и отражает число секунд с 1 января 1970 года (начало эпохи UNIX). Тип подписи указан в приведённом выше списке. ID ключа обозначается 8 байтами. Идентификаторы алгоритма с открытым ключом и хэш-функции представлены одним байтом каждый и берутся из таблицы констант №2[создать]. Входом для хэш-функции являются подписываемые данные, а также тип подписи и метка времени. [Первые 2 байта хэш-значения] позволяют определить, что сверка подписи производится с ошибочного документа ещё до выполнения вычислительно дорогой операции с открытым ключом. ID ключа помогает найти верный ключ на связке.
RSA
В этом случае подпись содержит одно большое число md mod n. Значение m образуется из хэш-значения, предварённого специальным для хэш-функции префиксом согласно таблице 4.1. Результат дополняется, как было изложено в разделе "Алгоритмы с открытым ключом". Префиксы опираются на некую формальную схему кодировки, описанную в [10].
Таблица 4.1. Префиксы хэш-функций.
MD2 | 30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 02 05 00 04 10 |
MD5 | 30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10 |
RIPEMD-160 | 30 21 30 09 06 05 2b 24 03 02 01 05 00 04 14 |
SHA-1 | 03 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 |
Зачем использовать префиксы?
Причина для наличия алгоритмо-зависимого префикса в схеме кодировки RSA в том, чтобы не допустить перенос подписи с одного документа на другой путём замены хэш-функции. Предположим, что мы имеем две функции хэширования, одну стойкую, а другую — слабую. Для подписания документов вы всегда используете стойкую функцию. Однако, я беру одну из ваших подписей, заменяю в ней идентификатор алгоритма хэширования на слабый, а потом подбираю зловредный документ с идентичным хэшем (это не окажется трудным благодаря взлому хэш-функции). Но это окажется невозможно, если ваша подпись будет содержать сведения о том, какую из хэш-функций использовать: чтобы провести такую атаку на классическую подпись RSA мне потребуется взломать RSA.
DSA
Для подписи DSA используются два больших числа: r и s. Входом для алгоритма цифровой подписи является выход от алгоритма хэширования со 160-битовым значением. Дальнейшей обработки не происходит. Это значит, что подписи DSA уязвимы к атаке с подменой хэш-функции, описанной выше. На текущий момент ни одна из 160-битовых функций хэширования в PGP считается слабой, но если одна из них окажется взломана, это инвалидирует все подписи DSA, даже полученные от доверенных лиц.