id: Гость   вход   регистрация
текущее время 16:59 29/03/2024
создать
просмотр
редакции
ссылки

Пакеты подписей


В PGP используется целое множество подписей. Сертифицирующие подписи создаются на открытых ключах, чтобы подтвердить взаимосвязь между открытым ключом и именем пользователя (User ID, записью сертификата). Частный случай подобных подписей — это автоподпись, которая создаётся на сертификате ключа самим этим ключом. Подписи также могут ставиться на сообщениях и файлах. И, наконец, подпись может не зависеть ни от каких внешних данных: такова, к примеру, аннулирующая подпись.


Схема подписей PGP (49 Кб)
Схема подписей 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, даже полученные от доверенных лиц.