РегистрацияПакеты подписей
В PGP используется множество разных подписей. Сертифицирующие подписи создаются на открытых ключах, чтобы подтвердить взаимосвязь между открытым ключом и именем пользователя (User ID, записью сертификата). Частный случай подобных подписей — это автоподпись, которая создаётся на сертификате ключа самим этим ключом. Подписи также могут ставиться на сообщениях и файлах. И, наконец, подпись может не зависеть ни от каких внешних данных: такова, к примеру, аннулирующая подпись.
Схема подписей PGP в исполнении Ральфа Сендерека
Смысл подписи определяется её типом. Вот существующие типы:
| ID | Тип подписи |
|---|---|
| 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 байта хэш-значения] позволяют определить, что сверка подписи производится с ошибочного документа ещё до выполнения вычислительно дорогой операции с открытым ключом. ID ключа помогает найти верный ключ на связке.
RSA
В этом случае подпись содержит одно большое число md mod n. Значение m образуется из хэш-значения, предварённого специальным для хэш-функции префиксом согласно таблице. Результат дополняется, как было описано в разделе "Алгоритмы с открытым ключом". Префиксы опираются на некую формальную схему кодировки, приведённую в [10].
Префиксы хэш-функций.
| 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 уязвимы к атаке с подменой хэш-функции, описанной выше. 1 На текущий момент ни одна из 160-битовых функций хэширования в PGP не считается слабой, но если одна из них вдруг будет взломана, это сделает недействительными все подписи DSA, даже полученные от доверенных лиц.
Version 4
Подпись v4 содержит:
Хэшируются как подписываемые данные, так и всё, начиная с индикатора версии и заканчивая хэшируемыми субпакетами.
Субпакеты v4
Субпакеты подписей были придуманы, чтобы сделать схему подписей более гибкой, позволяя закреплять в подписи множество сочетаний опций и свойств. Заголовок субпакета состоит из указателя длины, такого же, как для пакетов v4 (формат partial body length недопустим), и из следующего за ним однобайтового идентификатора субпакета, имеющего одно из следующих значений:
| ID | Тип субпакета v4 |
|---|---|
| 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 | Частные/пользовательские субпакеты. |
1 Уязвима только подпись DSA v3. Новый формат предусматривает хэширование идентификаторов алгоритма ЭЦП и хэш-функции, делая проведение атаки на откат версии невозможным, — прим. пер.
