Postkvantové podepisování přichází tiše: ML-DSA pro Word dokumenty v .NET

💡 Kompletní funkční příklad dostupný na GitHubu:
sign-word-with-ml-dsa-certificates-dotnet

Starý způsob byl projektový plán

Zeptejte se, co je potřeba k tomu, aby podepisování dokumentů bylo post‑kvantové, a dostanete plán: vyhodnotit algoritmy, vybrat knihovnu, napsat abstrakční vrstvu nad kódem podepisování, naplánovat období dvojího podepisování, vyčlenit čtvrtletí rozpočtu.

Většina toho je stále pravda pro organizační část – získávání certifikátů, politika, podpora validátorů. Kódová část se ukázala být menší, než naznačuje plán, a to je dobré vědět, než si kdokoli vyčlení čtvrtletí rozpočtu.

ML‑DSA podepisování je schopnost GroupDocs.Signature pro .NET, která podepisuje Word dokumenty certifikáty založenými na FIPS 204, standardu NIST pro post‑kvantové podpisy. Objevila se ve verzi 26.9 a z pohledu volajícího kódu jde o jiný PFX soubor.

Existuje lepší způsob

Zde je celý změněný kód:

using var signature = new Signature(sourcePath);

var options = new DigitalSignOptions(pfxPath)
{
    Password = certificatePassword
};

SignResult result = signature.Sign(outputPath, options);

Jedná se o stejný volání, které se používá pro RSA certifikát. Algoritmus je vlastností certifikátu, takže není potřeba žádná volba jej vybírající, není potřeba abstrakční vrstva a neobjevuje se žádná druhá cesta kódu pro přechodové období. Stačí nasměrovat DigitalSignOptions na ML‑DSA PFX a výstup bude ML‑DSA podpis.

Čtení certifikátu zpět z výsledku stojí za to, pokud je v provozu více certifikátů:

var created = result.Succeeded.OfType<DigitalSignature>().FirstOrDefault();
return created?.Certificate?.Subject ?? "(no certificate returned)";

Výběr úrovně, s čísly místo názorů

ML‑DSA existuje ve třech sadách parametrů, které odpovídají bezpečnostním kategoriím NIST 2, 3 a 5. Silnější znamená větší – jak klíč, tak podpis – a rozumný způsob, jak se rozhodnout, je podepsat vlastní dokument třikrát a podívat se:

var levels = new Dictionary<string, string>
{
    ["ML-DSA-44"] = MlDsa44Pfx,
    ["ML-DSA-65"] = MlDsa65Pfx,
    ["ML-DSA-87"] = MlDsa87Pfx
};

Ukázka zapíše jednu podepsanou kopii pro každou úroveň a zaznamená její velikost, takže kompromis je měření, nikoli tabulka ze specifikace. Pro jeden kontrakt je rozdíl nepozorovatelný; pro archiv několika milionů podepsaných dokumentů je to otázka kapacity, kterou je dobré si ujasnit před standardizací na nejvyšší úroveň.

ML‑DSA‑65 je rozumná výchozí hodnota, pokud žádná politika neurčuje jinak. Profily jako CNSA 2.0 explicitně uvádějí ML‑DSA‑87 a ML‑DSA‑44 má smysl jen tehdy, když je velikost důležitější než rezerva.

Ověření potřebuje jen veřejný certifikát

Distribuční příběh se nezměnil oproti RSA, což je druhá dobrá zpráva:

var options = new DigitalVerifyOptions(certificatePath);
if (password != null)
{
    options.Password = password;
}

VerificationResult result = signature.Verify(options);

Příjemce potřebuje jen .cer podepisujícího a nic víc. Výsledek je platný jen tehdy, když podpis odpovídá obsahu a certifikát se shoduje podle sériového čísla a otisku, takže dokument podepsaný jinou stranou selže – což ukázka dokazuje tím, že ověření spustí dvakrát, jednou se správným certifikátem a podruhé s cizím.

Vedle sebe: Očekávané vs. Skutečné

Poslední řádek je ten, který omezuje plánování, a vede k upřímné části tohoto článku.

Co zatím nefunguje

Dva limity, oba stojí za to znát, než něco slíbíte.

Pokrytí formátů je ve verzi 26.9 jen Word – DOCX, DOC, ODT a další členové rodiny Word. PDF, tabulky a prezentace nelze podepsat pomocí ML‑DSA. Pro pipeline zaměřenou na PDF je toto vydání spíše pro prototypování a měření než pro migraci.

Podpora validátorů je druhá. Zatím neexistuje standardní XML‑DSig identifikátor pro ML‑DSA, takže Microsoft Word nemusí označit podpis jako platný, i když je kryptograficky správný a API jej ověří. Jedná se o mezeru ve standardech, nikoli o chybu, a znamená to, že ověření musí probíhat ve vašem kódu, nikoli v recenzentovi otevírajícím soubor a kontrolujícím banner.

Existuje také detail platformy, který nevyžaduje žádnou akci: .NET nemůže všude číst ML‑DSA klíče, včetně Linuxu na .NET 8. Tam, kde to neumí, GroupDocs.Signature načte certifikát přes Word engine, takže stejná sestava běží na vývojářském notebooku i v Linux kontejneru bez podmíněného kódu.

Stojí to za to udělat nyní, vzhledem k těmto limitům?

Ano, ze dvou důvodů, které nesouvisejí s kódem. Získávání certifikátů je pomalé – veřejné CA stále zavádějí vydávání ML‑DSA – takže organizační práce těží z brzkého zahájení. A otázka „můžeme dnes vytvořit post‑kvantový podpis?“ je otázkou, kterou začínají klást týmy pro soulad; být schopen odpovědět podepsaným dokumentem místo plánu stojí odpoledne práce.

Co ukazuje ukázka ve skutečnosti

Čtyři metody, spuštěné v pořadí, s návratovým kódem svázaným s výsledkem. Podepisuje kontrakt pomocí ML‑DSA‑65 a vypisuje předmět použitého certifikátu. Podepisuje stejný kontrakt na všech třech úrovních a vypisuje výsledné velikosti. Ověřuje podepsaný soubor dvakrát – jednou s veřejným certifikátem podepisujícího (očekává úspěch) a podruhé s certifikátem jiného podepisujícího (očekává selhání). Pak vypíše digitální podpisy nalezené ve výstupu.

Druhé ověření je to, co stojí za zkopírování. Rutina, která byla doposud ukázána jen s platným vstupem, nic neříká o tom, zda by odmítla neplatný, a pro podpisy je to podstatná otázka.

Praktický příklad: Třicetiletý kontrakt

Archivy s dlouhodobým uchováváním jsou místem, kde už to není teoretické. Kontrakt podepsaný dnes a uchovávaný třicet let musí zůstat ověřitelný bez ohledu na to, co se v té době stane s kryptografií, a „sklízet nyní, dešifrovat později“ je zdokumentovaný model hrozby právě pro takový materiál.

Pro takový archiv je praktický krok dnes dvojí: zachovat RSA pro formáty, které ML‑DSA zatím nepokrývá, začít podepisovat výstup Wordu pomocí ML‑DSA‑65 nebo 87 a zaznamenávat, který algoritmus byl použit u každého dokumentu, aby budoucí audit mohl rozlišit bez otevírání souborů.

Jedna věc, kterou je potřeba v ukázce opravit před jejím zkopírováním

Repozitář obsahuje samopodepsané ML‑DSA certifikáty, takže demonstrace funguje hned po rozbalení – to znamená čtyři PFX soubory a pevně zakódované heslo v documents/. Pro jednorázový testovací certifikát platný jen v rámci této ukázky to stačí.

Není to však vzor, který byste měli přenést do svého repozitáře. Generujte testovací certifikáty za běhu, podobně jako ukázka GroupDocs „certificate‑validity“, nebo je držte mimo verzovací systém. Zapsaný klíč je obtížné odvolat a má tendenci přežít demo, pro které byl vytvořen.

Závěr

Nejdražší část migrace na post‑kvantové je certifikáty, politika a validátory. Kód, alespoň pro Word dokumenty v .NET, je jen jiný PFX a stejné volání DigitalSignOptions. Naklonujte ukázku, nasměrujte ji na jeden ze svých kontraktů a během několika minut získáte tři podepsané soubory, dva výsledky ověření a srovnání velikostí – což je lepší základ pro migrační plán než odhad.

Další zdroje

• Kompletní .NET ukázkový projekt na GitHubu
• Průvodce krok za krokem – případové použití
• Podepsat dokument digitálním podpisem
• Ověřit digitální podpisy v dokumentu
• Dokumentace GroupDocs.Signature pro .NET
• Free support forum