Цифровые подписи файлов: подтвердите подлинность и происхождение

Цифровая подпись — это криптографическое доказательство того, что конкретный человек или организация создала файл и что файл не изменился с момента создания. Технически вы хешируете файл с помощью SHA-256, затем «подписываете» хеш своим приватным ключом с использованием RSA-PSS, ECDSA или Ed25519. Любой, у кого есть ваш публичный ключ, может проверить подпись — если она верна, значит, именно вы создали файл и он побайтово идентичен тому, что вы подписали. Подписи — это то, что macOS использует для верификации обновлений приложений, что Git использует для авторства коммитов (git commit -S), и что PGP использует для подписанных писем. Они решают задачу, с которой шифрование само по себе не справляется: доказать, кто что отправил.

Подписи против шифрования: разные задачи

Шифрование скрывает содержимое. Подписи доказывают авторство и целостность. Они дополняют друг друга, а не являются альтернативами.

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

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

Как на самом деле работает подписание

Канонический процесс подписания Ed25519:

1. Хешируем сообщение: h = SHA-512(сообщение).
2. Вычисляем детерминированный nonce: r = SHA-512(приватный_ключ_префикс || h).
3. Вычисляем точку подписи: R = r·G (где G — базовая точка кривой).
4. Вычисляем s = r + SHA-512(R || публичный_ключ || h)·приватный_ключ mod ℓ.
5. Подпись — это (R, s), всего 64 байта.

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

RSA-PSS (PKCS#1 v2.2) и ECDSA работают аналогично, но с другой математикой. Ed25519 предпочтителен для новых систем: он детерминирован (случайный nonce на подпись не нужен) и быстрее.

Три распространённых алгоритма подписи

| Алгоритм | Размер ключа | Размер подписи | Скорость | Примечания | |----------|-------------|----------------|----------|-----------| | RSA-PSS-2048 | 256 байт | 256 байт | ~1000 подп./с | Широко поддерживается, медленная генерация ключа | | ECDSA P-256 | 32 байта | 64 байта | ~30 000 подп./с | Кривая NIST, требует безопасного генератора случайных чисел для каждой подписи | | Ed25519 | 32 байта | 64 байта | ~50 000 подп./с | Детерминирован, современный стандарт |

Все три одобрены в FIPS 186-5 NIST (2023). Ed25519 — выбор для новых протоколов: WireGuard, SSH (по умолчанию с OpenSSH 8.0), Signal, подписание коммитов Git и подписание пакетов Rust Cargo.

Подписание кода: применение с многомиллиардными ставками

Распространение ПО опирается на подписи. Без них пользователи не могут отличить настоящий установщик от вредоносного ПО:

• Apple Developer ID + Notarization. Все приложения macOS должны быть подписаны и нотаризированы с версии Catalina (2019). Используются RSA-2048 или ECDSA P-256.
• Microsoft Authenticode. Windows-исполняемые файлы подписываются сертификатами RSA-3072 или ECDSA P-384.
• Android APK v2/v3. Подписи Ed25519 над содержимым APK.
• Debian apt, Red Hat dnf, npm, PyPI, Homebrew. Все используют отделённые подписи (обычно GPG Ed25519 или RSA) над манифестами пакетов.

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

PGP и отделённые подписи для файлов

GnuPG (gpg) по-прежнему остаётся основным инструментом для подписей файлов вне корпоративной PKI. Отделённая подпись оставляет файл неизменным и помещает подпись в отдельный файл .sig:

gpg --detach-sign --armor document.pdf
# Создаёт document.pdf.sig

gpg --verify document.pdf.sig document.pdf
# gpg: Good signature from "Alice <alice@example.com>"

Слабость PGP — распределение ключей: как верификатор знает, что ключ подписания действительно принадлежит Алисе? Варианты: серверы ключей, сеть доверия, keybase.io или внеполосная верификация (опубликованный отпечаток на визитной карточке).

Современные альтернативы: Sigstore (используется Kubernetes, npm) выполняет подписание без ключей с использованием токенов OIDC и журналов прозрачности вместо сети доверия. minisign Фрэнка Дениса предлагает простое подписание Ed25519 без сложности PGP.

Агрегирование подписей на основе хеш-функций

Для коллекций файлов подписывать каждый отдельно неэффективно. Лучше: хешировать каждый файл, построить дерево Меркла, подписать корень. Преимущества:

• Одна подпись охватывает множество файлов.
• Отдельные файлы могут быть верифицированы относительно корня с помощью log(n) соседних хешей.
• Используется журналами прозрачности сертификатов, Git и всё чаще инструментами цепочки поставок ПО, такими как in-toto.

Релиз из 10 000 файлов, подписанный таким образом, производит одну подпись плюс 32-байтный корневой хеш, верифицируемый для любого подмножества файлов.

Временны́е метки: доказательство момента

Подпись доказывает «кто», но не «когда». Злоумышленник, укравший ваш приватный ключ, может задним числом датировать подписи. Доверенные центры временны́х меток (TSA) решают эту задачу, подписывая временну́ю метку поверх вашей подписи и привязывая её к конкретному моменту.

Стандарты:

• RFC 3161 — временны́е метки для Microsoft Authenticode, подписей Adobe PDF.
• RFC 5544 (CMS с временны́ми метками).
• Roughtime — новый протокол Google для верифицированного времени с низкой задержкой.

Подписание юридических документов (DocuSign, Adobe Sign, квалифицированные подписи EU eIDAS) опирается на временны́е метки RFC 3161 от доверенных органов для установления момента подписания контракта.

Подписи при передаче файлов

Большинство потребительских сервисов передачи файлов не предоставляют подписи напрямую — тег аутентификации AES-GCM доказывает целостность в ходе передачи, TLS доказывает личность сервера, но встроенного способа доказать личность отправителя нет.

Для передач с высоким уровнем доверия подписание происходит до загрузки:

1. Отправитель подписывает файл с помощью Ed25519 или PGP, получая file.ext и file.ext.sig.
2. Оба файла загружаются в любой сервис передачи (HexaTransfer, SwissTransfer, WeTransfer).
3. Получатель скачивает оба, верифицирует подпись с помощью публичного ключа отправителя.

Это отделяет подлинность от механизма передачи — сервис передачи может быть скомпрометирован без нарушения действительности подписи, пока приватный ключ отправителя остаётся в тайне и у получателя есть правильный публичный ключ.

Квалифицированные подписи EU eIDAS

Регламент ЕС об eIDAS (EU 910/2014, пересмотренный в 2024 году как eIDAS 2.0) определяет три уровня подписей:

• Электронная подпись — базовая, включает сканированные рукописные подписи.
• Усиленная электронная подпись (AES/AdES) — привязана к подписанту, обнаруживает фальсификации. Подписи PGP соответствуют этому уровню.
• Квалифицированная электронная подпись (QES) — AdES плюс квалифицированный сертификат от Поставщика доверительных услуг, хранимый на Квалифицированном устройстве создания подписи (смарт-карта или HSM).

QES имеет ту же юридическую силу, что и рукописная подпись, во всех государствах-членах ЕС. Провайдеры: DocuSign EU, Adobe Sign EU, Namirial, DTrust. Американские аналоги по ESIGN Act и UETA менее формально структурированы, но функционально сопоставимы.

Когда подписи излишни

Не каждый файл нуждается в подписи. Пропустите этот шаг, когда:

• Получатель полностью доверяет каналу передачи (Signal, USB при личной встрече).
• Содержимое не критично с точки зрения безопасности (фото со встреч, рецепты, черновые документы).
• Достаточно только целостности, обеспечиваемой AES-GCM или TLS.

Добавляйте подписи, когда:

• Важна юридическая или договорная сила (контракты, судебные доказательства, медицинские записи).
• В процессе задействовано доверие к цепочке поставок (выпуски ПО, обновления прошивки).
• Файл будет передаваться через ненадёжных посредников.
• Необходима долговечная цепочка аудита, переживающая исходную передачу.

Применение на практике

Для простого рабочего процесса: сгенерируйте ключ Ed25519 с помощью ssh-keygen -t ed25519 -f ~/.ssh/signing_key, подпишите файл с помощью openssl pkeyutl -sign -inkey signing_key -in file -out file.sig, передайте ваш публичный ключ по отдельному каналу и отправьте файл через любой защищённый сервис передачи. Получатели верифицируют с помощью openssl pkeyutl -verify.

Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.