Podpisy cyfrowe plików: udowodnij autentyczność i pochodzenie

Podpis cyfrowy to kryptograficzny dowód, że określona osoba lub podmiot stworzył plik i że nie uległ on zmianie od momentu podpisania. Technicznie: oblicza się skrót pliku algorytmem SHA-256, a następnie „podpisuje" ten skrót kluczem prywatnym przy użyciu RSA-PSS, ECDSA lub Ed25519. Każdy posiadający klucz publiczny może zweryfikować podpis — jeśli weryfikacja się powiedzie, odbiorca wie, że plik pochodzi od nadawcy i jest identyczny bajt po bajcie z tym, co zostało podpisane. Z podpisów korzysta macOS przy weryfikacji aktualizacji aplikacji, Git przy autoryzacji commitów (git commit -S) oraz PGP przy podpisywaniu wiadomości. Podpisy rozwiązują problem, którego samo szyfrowanie nie rozwiązuje: udowodnienie, kto wysłał co.

Podpisy a szyfrowanie: różne zadania

Szyfrowanie chroni treść przed ujawnieniem. Podpisy dowodzą autorstwa i integralności. Są wzajemnym uzupełnieniem, a nie alternatywami.

Samo szyfrowanie: odbiorca zna treść, ale nie wie, kto ją przesłał. Każdy z kluczem publicznym mógłby być nadawcą.
Sam podpis: odbiorca wie, kto wysłał plik i że nie był modyfikowany, ale treść jest widoczna dla przechwytującego.
Podpis i szyfrowanie: pełna autentyczność, integralność i poufność. Domyślny tryb PGP.

Usługi transferu plików skupiają się na szyfrowaniu. Podpisy pojawiają się w kontekstach wysokiego zaufania: dystrybucja oprogramowania, dokumenty prawne, umowy, łańcuchy dowodów kryminalistycznych.

Jak podpisywanie działa w praktyce

Kanoniczny przepływ podpisywania Ed25519:

Oblicz skrót wiadomości: h = SHA-512(wiadomość).
Wyznacz deterministyczny nonce: r = SHA-512(prefiks_klucza_prywatnego || h).
Oblicz punkt podpisu: R = r·G (gdzie G to punkt bazowy krzywej).
Oblicz s = r + SHA-512(R || klucz_publiczny || h)·klucz_prywatny mod ℓ.
Podpis to (R, s) — łącznie 64 bajty.

Weryfikacja używa wyłącznie klucza publicznego, wiadomości i podpisu. Jeśli obliczenia się zgadzają, weryfikator wie, że podpis powstał przy użyciu pasującego klucza prywatnego.

RSA-PSS (PKCS#1 v2.2) i ECDSA działają podobnie, lecz na innej matematyce. Ed25519 jest preferowany w nowych systemach, ponieważ jest deterministyczny (brak losowego nonce per podpis) i szybszy.

Trzy główne algorytmy podpisywania

| Algorytm | Rozmiar klucza | Rozmiar podpisu | Szybkość | Uwagi | |-----------|----------------|-----------------|----------|-------| | RSA-PSS-2048 | 256 bajtów | 256 bajtów | ~1000 podpisów/s | Szeroko wspierany, wolna generacja klucza | | ECDSA P-256 | 32 bajty | 64 bajty | ~30 000 podpisów/s | Krzywa NIST, wymaga bezpiecznego RNG na podpis | | Ed25519 | 32 bajty | 64 bajty | ~50 000 podpisów/s | Deterministyczny, współczesny standard |

Wszystkie trzy są zatwierdzone w NIST FIPS 186-5 (2023). Ed25519 to wybór dla nowych protokołów: WireGuard, SSH (domyślny od OpenSSH 8.0), Signal, podpisywanie commitów w Git oraz podpisywanie pakietów Cargo w Rust.

Podpisywanie kodu: przypadek użycia wart miliardy

Dystrybucja oprogramowania opiera się na podpisach. Bez nich użytkownicy nie mogą odróżnić oryginalnego instalatora od złośliwego oprogramowania:

Apple Developer ID + Notaryzacja. Wszystkie aplikacje na macOS muszą być podpisane i notaryzowane od Cataliny (2019). Używa RSA-2048 lub ECDSA P-256.
Microsoft Authenticode. Pliki wykonywalne Windows podpisane certyfikatami RSA-3072 lub ECDSA P-384.
Android APK v2/v3. Podpisy Ed25519 nad zawartością APK.
Debian apt, Red Hat dnf, npm, PyPI, Homebrew. Wszystkie używają oddzielonych podpisów (zwykle GPG Ed25519 lub RSA) nad manifestami pakietów.

Słynny incydent: w 2020 roku aktualizacja SolarWinds Orion została podpisana legalnym certyfikatem firmy po tym, jak atakujący skompromitowali system budowania. Podpis był prawidłowy — potwierdzał jedynie, że kod pochodzi ze skompromitowanego źródła. Podpisy gwarantują tożsamość podpisującego, nie jego osąd.

PGP i oddzielone podpisy plików

GnuPG (gpg) pozostaje standardem dla podpisów plików poza korporacyjną infrastrukturą PKI. Oddzielony podpis zachowuje plik bez zmian, umieszczając podpis w osobnym pliku .sig:

gpg --detach-sign --armor dokument.pdf
# Tworzy dokument.pdf.sig

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

Słabością PGP jest dystrybucja kluczy: skąd weryfikator wie, że klucz podpisujący rzeczywiście należy do Alice? Opcje obejmują serwery kluczy, sieć zaufania, keybase.io lub weryfikację pozakanałową (odcisk klucza opublikowany na wizytówce).

Nowoczesne alternatywy: Sigstore (używany przez Kubernetes, npm) realizuje podpisywanie bez klucza za pomocą tokenów tożsamości OIDC, a logi transparentności zastępują sieć zaufania. minisign autorstwa Franka Denisa oferuje proste podpisywanie Ed25519 bez złożoności PGP.

Agregacja podpisów oparta na skrótach

W przypadku kolekcji plików podpisywanie każdego z osobna jest nieefektywne. Lepsze podejście: obliczanie skrótu każdego pliku, budowanie drzewa Merkle'a i podpisanie korzenia. Zalety:

Jeden podpis obejmuje wiele plików.
Pojedyncze pliki można zweryfikować względem korzenia za pomocą log(n) skrótów siostrzanych.
Stosowane przez logi transparentności certyfikatów, Git i coraz częściej przez narzędzia łańcucha dostaw oprogramowania, takie jak in-toto.

Wydanie 10 000 plików podpisane w ten sposób daje jeden podpis plus 32-bajtowy skrót korzenia, weryfikowalny względem dowolnego podzbioru plików.

Znaczniki czasu: dowód momentu podpisania

Podpis dowodzi, kto podpisał, ale nie kiedy. Atakujący, który ukradnie klucz prywatny, może antydatować podpisy. Zaufane Organy Znaczników Czasu (TSA) rozwiązują ten problem, podpisując znacznik czasu nad podpisem i zakotwiczając go w konkretnym momencie.

Standardy:

RFC 3161 — używany przez Microsoft Authenticode i podpisy Adobe PDF.
RFC 5544 (CMS ze znacznikami czasu).
Roughtime — nowszy protokół Google do weryfikacji czasu z niskim opóźnieniem.

Podpisywanie dokumentów prawnych (DocuSign, Adobe Sign, kwalifikowane podpisy eIDAS UE) polega na znacznikach czasu RFC 3161 od zaufanych organów w celu ustalenia, kiedy umowa została podpisana.

Podpisy w transferze plików

Większość konsumenckich usług transferu nie udostępnia podpisów bezpośrednio — tag uwierzytelniania AES-GCM dowodzi integralności w ramach transferu, a TLS dowodzi tożsamości serwera, ale nie ma wbudowanego mechanizmu potwierdzania tożsamości nadawcy.

W przypadku transferów wysokiego zaufania podpisywanie odbywa się przed przesłaniem:

Nadawca podpisuje plik algorytmem Ed25519 lub PGP, tworząc plik.ext i plik.ext.sig.
Oba pliki są przesyłane do dowolnej usługi transferu (HexaTransfer, SwissTransfer, WeTransfer).
Odbiorca pobiera oba, weryfikuje podpis za pomocą klucza publicznego nadawcy.

Oddziela to autentyczność od mechanizmu transferu — usługa transferu mogłaby zostać skompromitowana bez naruszenia ważności podpisu, o ile klucz prywatny nadawcy pozostaje tajny, a odbiorca posiada prawidłowy klucz publiczny.

Kwalifikowane podpisy eIDAS UE

Rozporządzenie eIDAS (UE 910/2014, znowelizowane w 2024 jako eIDAS 2.0) definiuje trzy poziomy podpisów:

Podpis elektroniczny — podstawowy, obejmuje zeskanowane podpisy odręczne.
Zaawansowany podpis elektroniczny (AES/AdES) — powiązany z podpisującym, wykrywa manipulacje. Podpisy PGP kwalifikują się.
Kwalifikowany podpis elektroniczny (QES) — AdES plus kwalifikowany certyfikat od dostawcy usług zaufania, przechowywany na Kwalifikowanym Urządzeniu do Składania Podpisu (karta inteligentna lub HSM).

QES ma taką samą moc prawną jak podpis odręczny we wszystkich państwach członkowskich UE. Dostawcy to m.in. DocuSign EU, Adobe Sign EU, Namirial i DTrust.

Kiedy podpisy są zbyteczne

Nie każdy plik wymaga podpisu. Można z niego zrezygnować, gdy:

Odbiorca ufa kanałowi transferu od końca do końca (Signal, pendrive wręczony osobiście).
Treść nie jest krytyczna pod względem bezpieczeństwa (zdjęcia ze spotkania, przepisy, robocze wersje dokumentów).
Integralność zapewniana przez AES-GCM lub TLS jest wystarczająca.

Podpisów warto używać, gdy:

Liczą się kwestie prawne lub umowne (umowy, dowody sądowe, dokumentacja medyczna).
W grę wchodzi zaufanie w łańcuchu dostaw (wydania oprogramowania, aktualizacje firmware).
Plik będzie przekazywany przez niezaufane pośredniki.
Potrzebny jest trwały ślad audytu, który przeżyje oryginalny transfer.

Zastosowanie w praktyce

Prosty przepływ pracy: wygeneruj klucz Ed25519 przez ssh-keygen -t ed25519 -f ~/.ssh/klucz_podpisujacy, podpisz plik przez openssl pkeyutl -sign -inkey klucz_podpisujacy -in plik -out plik.sig, udostępnij swój klucz publiczny pozakanałowo i wyślij plik przez dowolną bezpieczną usługę transferu. Odbiorcy weryfikują przez openssl pkeyutl -verify.

Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.