Это старая редакция страницы Библиотека / Статьи / Анализ Надежности P G P / Формат Файлов P G P / Пакеты Подписей за 28/11/2007 19:57.
Пакеты подписей
В PGP используется множество разных подписей. Сертифицирующие подписи создаются на открытых ключах, чтобы подтвердить взаимосвязь между открытым ключом и именем пользователя (User ID, записью сертификата). Частный случай подобных подписей — это автоподпись, которая создаётся на сертификате ключа самим этим ключом. Подписи также могут ставиться на сообщениях и файлах. И, наконец, подпись может не зависеть ни от каких внешних данных: такова, к примеру, аннулирующая подпись.
Схема подписей PGP в исполнении Ральфа Сендерека
Смысл подписи определяется её типом. Вот существующие типы:
- 00 — Подпись на двоичном объекте (signature on a binary document): подписант утверждает, что обладает файлом, создал или видел его, либо что файл не был изменён.
- 01 — Подпись на текстовом документе (signature on a text document). Отличие этого типа от предыдущего в том, что в данном случае перед вычислением подписи производится конвертация окончаний строк в [возврат каретки][перенос строки] и из конца строк удаляются пробелы. Это очень полезно, поскольку подпись остаётся действительной, даже если переслать документ на компьютер с другой ОС, имеющей иные правила переноса строк.
- 02 — Самостоятельная подпись (standalone signature): она покрывает только собственные субпакеты. Это необходимо для подписей v4, которые могут содержать множество дополнительной информации.
- 10 — Общая сертификация открытого ключа и имени пользователя (generic certification). Она не определяет, насколько доскональную проверку проводил поручитель перед подписанием ключа.
- 11,12,13 — Обозначают, соответственно, личную (persona), небрежную (casual) и позитивную (positive) проверку ключа и записи сертификата. Они дают некоторые сведения об усилиях поручителя, затраченных на проверку: "личная" означает, что поручитель не проводил вообще никакой проверки, "небрежная" означает, что была проведена некоторая поверхностная проверка, а "позитивная" означает тщательную детальную проверку. Тем не менее, всё это очень туманно. Если верить стандарту OpenPGP, эта туманность есть не ошибка, а цель системы, но я не вижу смысла в такой детализации без конкретизации её смысла. Все сертифицирующие подписи программы PGP на данный момент имеют тип 10.
- 18 — Подпись привязки подключа (subkey binding signature). Говорит о том, что данный подключ относится к подписавшему его главному ключу. Она вычисляется на самом подключе, а не на каких-либо записях сертификата.
- 1F — Подпись на ключе (signature on a key). В отличие от типов 10-13, вычисляется непосредственно на ключе, не затрагивая записи сертификата. Подпись может содержать субпакеты, предоставляющие информацию о самом ключе. Чтобы она была расценена достоверной, подпись должна быть сгенерирована самим целевым ключом. Другие пользователи смогут использовать её, чтобы с помощью субпакетов делать определённые оценки о ключе.
- 20 — Подпись аннулирования ключа (key revocation signature). Вычисляется на подлежащем аннулированию открытом ключе. Она может быть издана как самим этим ключом, так и другим ключом, определённым как ключ аннулирования ("уполномоченным отменителем").
- 30 — Подпись отзыва сертифицирующей подписи (certification revocation signature). Такая подпись способна аннулировать (отзывать) подтверждающие подписи типов 10-13. Она может быть издана либо ключом, издавшим изначальную подтверждающую подпись, либо "уполномоченным отменителем" того же ключа.
- 40 — Подпись метки времени (timestamp signature): заверяет только отражённое в ней время.
Когда подпись вычисляется на данных, содержащих сам ключ подписи, она называется автоподписью (self-signature). Автоподпись может относиться к типам 10,11,12,13,18 и 1F. Автоподписи важны, поскольку гарантируют, что заверяемая ими связь (между записью сертификата и ключом в случаях 10,11,12,13 либо между ключом и подключом для 18) создана самим владельцем ключа.
Version 3
Подпись v3 содержит:
Метка времени кодируется в четырёх байтах и отражает число секунд с 1 января 1970 года (начало эпохи UNIX). Тип подписи указан в приведённом выше списке. Идентификаторы алгоритма с открытым ключом и хэш-функции представлены одним байтом каждый и берутся из таблицы констант №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, даже полученные от доверенных лиц.
Version 4
Подпись v4 содержит:
Хэшируются как подписываемые данные, так и всё, начиная с индикатора версии и заканчивая хэшируемыми субпакетами.
Субпакеты v4
Субпакеты подписей были придуманы, чтобы сделать схему подписей более гибкой, позволяя закреплять в подписи множество сочетаний опций и свойств. Заголовок субпакета состоит из указателя длины, такого же, как для пакетов v4 (формат partial body length недопустим), и из следующего за ним однобайтового идентификатора субпакета, имеющего одно из следующих значений:
- 2 — Метка времени подписи (signature creation time), 4 байта. Должна находиться в блоке хэшируемых субпакетов.
- 3 — Срок действия подписи (signature expiration time), 4 байта. Если отсутствует или равен нулю, подпись не ограничена по времени.
- 4 — Экспортируемое заверение (exportable certification), 1 байт. 0 — не экспортируется, 1 — экспортируется. Такой субпакет можно обнаружить в сертифицирующих подписях на ключах пользователей; он определяет, должна ли подпись экспортироваться со связки вместе с самим ключом.
- 5 — Глубина доверия (trust signature), 1 байт. Указывает количество уровней распространения доверия от данного ключа: 0 — обычный достоверный ключ, доверие не распространяется, 1 — доверенный поручитель, все заверенные им ключи автоматически достоверны, 2 — мета-поручитель и т.д...
- 6 — Ограничитель доверия, регулярное выражение, оканчивающееся на нуль-байт 00. Это регулярное выражение определяет, к ключам с какими именами может применяться расширенная передача доверия (субпакетом 5). Формат регулярного выражения полностью описан в [3].
- 7 — Отзываемая подпись (revocable), 1 байт. 0 означает, что подпись неотзываемая, 1 — отзываемая. Если отсутствует, то подпись отзываемая.
- 9 — Срок действия ключа (key expiration time), 4 байта. Число секунд, через которое ключ прекратит действие. Если равно 0, ключ не ограничен по времени. Такой субпакет присутствует только в автоподписях.
- 10 — Метка для обратной совместимости (placeholder for backward compatibility). Не представляю, что это значит, но подозреваю, что это можно опустить.
- 11 — Предпочтительные симметричные алгоритмы (preferred symmetric algorithms). Размещается только в автоподписи и содержит последовательность идентификаторов шифров в порядке убывания предпочтения.
- 12 — Аннулирующий ключ, или "доверенный отменитель" (revocation key). Состоит из класса (1 байт), идентификатора PK-алгоритма (1 байт) и отпечатка ключа (20 байт). Наличие субпакета означает, что ключ с указанным отпечатком может аннулировать данный ключ. Эти сведения полезно добавить на случай, если вы забудете парольную фразу, поскольку в таком случае не сможете самостоятельно аннулировать ключ. Байт класса должен иметь установленный старший бит. Если второй бит тоже установлен, то данные сведения считаются чувствительными и не должны экспортироваться без явной необходимости. Этот субпакет размещается в автоподписи и должен находиться в хэшируемом блоке.
- 16 — Идентификатор ключа подписи (issuer key ID), 8 байт.
- 20 — Нотация подписи (notation data). Содержит: 4 байта однобитовых флагов (если установлен первый бит — нотация человекочитаемая), 2-байтовый указатель длины имени нотации N, 2-байтовый указатель длины значения нотации V, N-байтовое имя нотации, V-байтовое значение нотации. Может быть использована, чтобы оставить на подписи любые желаемые пояснения и комментарии.
- 21 — Предпочтительные алгоритмы хэширования (preferred hash algorithms). Размещается в автоподписи и содержит последовательность идентификаторов хэш-функций в порядке убывания предпочтения.
- 22 — Предпочтительные алгоритмы сжатия (preferred compression algorithms).
- 23 — Параметры для сервера ключей (key server preferences). Присутствует только в автоподписи и содержит произвольное число байт однобитовых флагов, определяющих, как серверы ключей должны обрабатывать ключ. Пока только первый бит имеет значение: если он установлен, это означает "не изменять", т.е. только владелец ключа может изменять его на сервере. Надеюсь, они добавят в будущем другие полезные флаги, потому как на данный момент я не вижу смысла в этом субпакете.
- 24 — Предпочтительный сервер ключей (preferred key server). Одна строка с URL предпочтительного сервера. Заметьте, что каждая запись сертификата может иметь собственный предпочтительный сервер.
- 25 — Первичная запись сертификата (primary user ID). Один байт, обозначающий данную запись как первичную.
- 26 — URL политик (policy URL). Строка с URL документа, описывающего политики/регламент, согласно которым была издана подпись.
- 27 — Флаги ключа (key flags). Последовательность однобитовых флагов. В настоящее время определены такие: бит 7 — ключ может применяться для сертификации других, бит 6 — ключ может подписывать данные, бит 5 — ключ может шифровать коммуникации (передаваемые данные), бит 4 — ключ может шифровать хранилища данных (хранимые данные), бит 3 — закрытая часть ключа была разделена по схеме разделения секрета, бит 1 — закрытой частью ключа обладает более одного владельца. Дополнительные флаги могут быть добавлены в будущем. Отсутствующие флаги должны быть установлены в 0. Часть этих флагов имеет смысл только на автоподписи, другие меняют смысл в зависимости от того, на какой подписи находятся.
- 28 — Имя подписанта (signer’s user id). С помощью этого субпакета можно указать, от какого имени (имени сертификата ключа) была поставлена подпись; это, например, позволяет отличить деловые подписи от личных.
- 29 — Причина аннулирования (reason for revocation). Содержит код аннулирования (1 байт) и строку с описанием причины для аннулирования. Код аннулирования может иметь значения: 00 — причина не указана, 01 — ключ был заменён, 02 — ключ скомпрометирован, 03 — ключ более не используется, 20 — запись сертификата более не действительна. Значение 20 применимо только к сертифицирующим подписям, 01,02 и 03 — только к подписям на ключе, а 00 — к тем и другим.
- 100-110 — Частные/пользовательские субпакеты.