id: Гость   вход   регистрация
текущее время 06:57 19/03/2024
Владелец: SATtva (создано 27/11/2007 17:05), редакция от 05/12/2007 18:19 (автор: SATtva) Печать
Категории: криптография, софт, pgp, openpgp, спецификации, сайт проекта, статьи, эцп, стандарты
создать
просмотр
редакции
ссылки

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


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


Схема подписей PGP (49 Кб)
Схема подписей 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). Один байт, обозначающий данную запись как первичную.
26URL политик (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. Новый формат предусматривает хэширование идентификаторов алгоритма ЭЦП и хэш-функции, делая проведение атаки на откат версии невозможным, — прим. пер.


 
Комментариев нет [показать комментарии/форму]
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3