Основы PKI: как работает проверка подписанных хешей

Когда программа проверяет цифровую подпись документа, она фактически сверяет два объекта: хеш содержимого и криптографическую подпись этого хеша. Но сама по себе математическая проверка ничего не говорит о том, кому принадлежит ключ. Ответ на вопрос «а этому ключу вообще можно доверять?» даёт инфраструктура открытых ключей — PKI (Public Key Infrastructure). В этой статье объясняется, как PKI устроена вокруг проверки подписанных хешей, какие элементы в ней участвуют и что нужно проверить, чтобы результат проверки действительно имел смысл.

Главный принцип простой: подпись подтверждает целостность данных только вместе с подтверждённой принадлежностью ключа. Если владелец ключа не установлен через сертификат и цепочку доверия, корректная криптографическая проверка защищает от случайного искажения файла, но не от подмены отправителя.

Что происходит при подписании и проверке: базовый механизм

Подпись строится не на всём документе, а на его хеше. Хеш-функция превращает данные произвольного размера в строку фиксированной длины — например, 256 бит для SHA-256. Любое изменение содержимого, даже одного байта, меняет хеш, поэтому совпадение хешей означает совпадение данных с практической достоверностью.

Схема выглядит так:

1. Отправитель вычисляет хеш документа.
2. Хеш шифруется (точнее — преобразуется) закрытым ключом отправителя. Результат — подпись.
3. Документ и подпись передаются получателю.
4. Получатель заново вычисляет хеш документа.
5. Получатель расшифровывает подпись открытым ключом отправителя и сравнивает два хеша.
6. Если хеши совпали — данные не изменялись после подписания.

Ключевой момент: на шаге 5 получатель использует открытый ключ, который где-то взял. Откуда он знает, что этот ключ принадлежит именно отправителю, а не злоумышленнику, подсунувшему свой ключ? Именно эту задачу решает PKI.

Роль PKI: связываем ключ с личностью

PKI — это совокупность ролей, политик, процедур и технологий, которые связывают открытые ключи с их владельцами. Центральный элемент — сертификат открытого ключа: электронный документ, в котором открытый ключ привязан к имени владельца (человека, организации, домена или программы) и подписан удостоверяющим центром.

Удостоверяющий центр (CA)

Удостоверяющий центр — организация, которой участники системы доверяют проверять личность заявителей перед выпуском сертификата. CA подписывает каждый выпущенный сертификат своим закрытым ключом. Проверяя эту подпись, любой участник убеждается, что сертификат не подделан и не изменён после выпуска.

Корневые сертификаты крупных удостоверяющих центров предустановлены в операционных системах и браузерах. Это так называемые доверенные корни: их подлинность гарантируется производителем платформы, а не сетью.

Цепочка доверия

Обычно между корневым сертификатом и сертификатом конечного владельца есть промежуточные уровни. Корневой CA подписывает сертификаты промежуточных CA, те — сертификаты пользователей или серверов. Получается цепочка:

• корневой сертификат — самоподписанный, находится в доверенном хранилище;
• промежуточные сертификаты — связывают корень с конечным сертификатом;
• конечный сертификат — содержит открытый ключ владельца, которым подписаны данные.

Проверка подписи документа на практике означает проверку всей цепочки: подпись документа — открытым ключом из конечного сертификата, подпись конечного сертификата — ключом промежуточного CA, и так до корня, который уже считается доверенным локально. Если хотя бы одно звено не сходится или отсутствует, проверка завершается ошибкой.

Сертификат отзыва (CRL) и OCSP

Сертификат может стать недействительным до истечения срока: закрытый ключ скомпрометирован, организация сменила название, сертификат выпущен ошибочно. Для этого PKI поддерживает механизмы отзыва:

• CRL (Certificate Revocation List) — список отозванных серийных номеров, который CA публикует периодически;
• OCSP (Online Certificate Status Protocol) — онлайн-запрос статуса конкретного сертификата, дающий более свежий ответ.

Пропуск проверки отзыва — одна из самых частых причин, когда формально «валидная» подпись оказывается подписью скомпрометированного ключа.

Как проходит полная проверка подписанного хеша

Соберём всё в типичную последовательность, которую выполняет почтовый клиент, средство проверки документов или библиотека верификации кода:

1. Вычислить хеш полученных данных выбранным алгоритмом.
2. Расшифровать подпись открытым ключом из сертификата подписанта.
3. Сравнить хеши. Несовпадение означает, что данные изменены — дальнейшие шаги бессмысленны.
4. Проверить срок действия сертификата на момент подписания (для документов важна именно дата подписи, если она зафиксирована меткой времени).
5. Построить цепочку до доверенного корня, проверив подпись каждого сертификата в цепочке.
6. Проверить статус отзыва каждого сертификата цепочки через CRL или OCSP.
7. Проверить назначение ключа: расширения сертификата должны разрешать использование для подписи (например, флаг digitalSignature), а не только для шифрования.
8. При наличии метки времени — убедиться, что она сама подписана доверенным TSA (Time Stamping Authority) и действительна.

Только прохождение всех шагов даёт осмысленный ответ «подпись действительна». Каждый пропущенный шаг открывает конкретный класс атак.

Алгоритмы: что используется для хешей и подписей

На практике чаще всего встречаются следующие сочетания:

Компонент	Типичные варианты	На что влияет выбор
Хеш-функция	SHA-256, SHA-384, SHA-512; устаревшие SHA-1 и MD5	Стойкость к коллизиям: слабый хеш позволяет подобрать поддельный документ с тем же хешем
Асимметричный алгоритм	RSA, ECDSA, EdDSA (Ed25519)	Скорость проверки, размер подписи, требования к длине ключа
Формат подписи	CMS/PKCS#7, XML-DSig, JWS/JOSE, PGP	Совместимость инструментов и способ хранения сертификатов в подписи
Метка времени	TSA-токены по RFC 3161	Сохранение юридической значимости подписи после истечения сертификата

Важно понимать зависимость: стойкость схемы определяется самым слабым звеном. Подпись RSA-4096 поверх MD5 не даёт реальной защиты, потому что атакующему достаточно скомпрометировать хеш. Алгоритмы со временем деградируют: SHA-1 когда-то считался надёжным, а сегодня подписи на нём отвергаются современными системами. Поэтому при разработке или аудите стоит опираться на актуальные рекомендации профильных органов стандартизации вашей юрисдикции, а не на учебные примеры.

Типичные ошибки при проверке подписанных хешей

Проверка только математики

Самая распространённая ошибка — считать успешное сравнение хешей достаточным. Это подтверждает лишь то, что данные подписаны каким-то ключом, чья пара соответствует предъявленному открытому ключу. Без проверки сертификата и цепочки подпись не отвечает на вопрос «кто подписал».

Игнорирование даты подписания

Сертификат действует ограниченный срок. Документ, подписанный год назад действующим сертификатом, остаётся валидным и после истечения его срока — но только если дата подписания зафиксирована меткой времени. Без неё проверяющая система вынуждена сверять срок на текущую дату, и старые документы начинают «отваливаться», хотя ничего подозрительного в них нет.

Отключённая проверка отзыва

Некоторые приложения пропускают CRL/OCSP-проверку ради скорости или при отсутствии сети. В корпоративной среде это осознанный компромисс, который должен быть задокументирован; в остальных случаях молчаливое отключение проверки отзыва лишает схему главного защитного свойства.

Слепое доверие любому корню в хранилище

Доверенное хранилище системы может пополняться вручную. Установленный когда-то «для теста» корневой сертификат превращается в постоянную лазейку: любой ключ, подписанный таким корнем, будет проходить проверку. Регулярный аудит хранилища доверенных корней — обязательная гигиеническая процедура.

Несоответствие назначения ключа

Сертификат с расширением, ограничивающим ключ шифрованием, не должен приниматься для проверки подписей. Библиотеки, которые не проверяют расширения keyUsage и extendedKeyUsage, допускают использование ключей вне их заявленного назначения.

Ограничения и компромиссы PKI

PKI решает проблему доверия, но не бесплатно:

• Централизация риска. Компрометация корневого или промежуточного CA ставит под угрозу все выданные им сертификаты. История отрасли знает случаи массового отзыва доверия к отдельным центрам.
• Зависимость от доступности сервисов. OCSP-респондеры и точки распространения CRL могут быть недоступны; политика обработки таких сбоев (fail-open или fail-closed) — отдельное решение с последствиями в обе стороны.
• Сложность управления жизненным циклом. Выпуск, ротация, отзыв и продление сертификатов требуют процессов; забытый сертификат с истекающим сроком — классическая причина простоев.
• Юридический слой. Криптографическая валидность и юридическая значимость подписи — разные вещи; вторая зависит от законодательства конкретной страны и статуса удостоверяющего центра.

Для замкнутых систем иногда применяются альтернативы: заранее распределённые ключи без CA (модель trust-on-first-use, пиннинг конкретных ключей), децентрализованные реестры или внутренний корпоративный CA. Они уместны, когда множество участников невелико и контролируется одной организацией, но плохо масштабируются на открытые экосистемы.

Практические сценарии: что проверить в вашем случае

Вы проверяете входящие подписанные документы

Используйте стандартные средства проверки (встроенные в ОС, офисные пакеты или специализированные криптопровайдеры), а не собственные скрипты поверх сырой криптографии. Убедитесь, что инструмент показывает не только «подпись верна», но и сведения о сертификате: владельца, издателя, срок действия, статус отзыва. Если приложение сообщает только результат сверки хешей — оно закрывает лишь часть задачи.

Вы разрабатываете систему, проверяющую подписи

Опирайтесь на проверенные библиотеки и протоколы (CMS, JOSE, XML-DSig) вместо самостоятельной реализации. Обязательный минимум проверок: цепочка до доверенного корня, сроки, отзыв, назначение ключа, актуальность алгоритмов. Заранее определите политику при недоступности OCSP/CRL и задокументируйте её. Логируйте причину отказа в проверке — «невалидно» без причины невозможно диагностировать.

Вы настраиваете проверку подписей обновлений ПО

Здесь часто применяется модель с фиксированным набором доверенных ключей издателя вместо общей PKI: обновления подписываются ключом разработчика, а проверяющий компонент сверяет подпись с зашитым публичным ключом. Это проще и жёстче, но требует надёжной процедуры ротации ключа: потеря закрытого ключа издателя парализует доставку обновлений.

Частые вопросы

Чем отличается проверка хеша от проверки подписи?

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

Можно ли доверять подписи, если сертификат просрочен?

Да, если дата подписания зафиксирована меткой времени и попадает в срок действия сертификата, а сертификат не был отозван на момент подписания. Без метки времени большинство систем отклонит такую подпись, поскольку момент подписания недоказуем.

Почему проверка падает с ошибкой «цепочка не построена»?

Чаще всего промежуточный сертификат не приложен к подписи и не установлен локально. Решение — установить недостающие промежуточные сертификаты или потребовать от подписанта включать полную цепочку в подпись.

Нужна ли PKI внутри одной компании?

Часто да, но в упрощённом виде: внутренний корпоративный CA с собственным корнем, распространяемым на рабочие станции политиками. Это дешевле и управляемее, чем покупка публичных сертификатов для внутренних сервисов, хотя требует собственных процессов выпуска и отзыва.

С чего начать

Главный ориентир: подписанный хеш доказывает целостность данных, а PKI превращает это доказательство в доказательство авторства. Оценивая любую систему проверки подписей, пройдите по чек-листу:

• строится ли полная цепочка до доверенного корня;
• проверяется ли срок действия относительно даты подписания, а не текущей даты;
• работает ли проверка отзыва и какая политика при её сбое;
• проверяются ли назначения ключа и допустимость алгоритмов;
• понятен ли источник доверенных корней и контролируется ли он.

Следующий практический шаг — взять один реальный подписанный объект в вашей среде (документ, пакет обновления, письмо) и посмотреть, какие именно проверки выполняет ваш инструмент и какие результаты он показывает по каждому пункту. Пробелы в этом списке и есть ваши зоны риска.

Материал носит информационный характер и описывает общие принципы работы инфраструктуры открытых ключей. Требования к электронным подписям, признаваемым удостоверяющим центрам и юридической значимости подписи различаются по странам и меняются со временем; при внедрении решений с юридическими или финансовыми последствиями сверяйтесь с актуальными нормативными актами и консультируйтесь со специалистами по информационной безопасности.