ポスト量子署名が静かに登場：.NET の Word ドキュメント向け ML-DSA

💡 完全に動作するサンプルはGitHubで入手可能です: sign-word-with-ml-dsa-certificates-dotnet

従来の方法はプロジェクト計画だった

ドキュメント署名をポスト量子化するために何が必要か尋ねると、ロードマップが得られます: アルゴリズムの評価、ライブラリの選択、署名コード上に抽象化レイヤーを書く、デュアル署名期間を計画、四半期の予算を立てる。

そのほとんどは組織側、すなわち証明書の調達、ポリシー、バリデータのサポートに対して今でも当てはまります。コード側はロードマップが示すよりも小さく済むことが判明しており、誰かが四半期分の予算を組む前に知っておく価値があります。

ML-DSA 署名は .NET 用の GroupDocs.Signature 機能で、FIPS 204 に基づく証明書を使用して Word ドキュメントに署名します。これは NIST のポスト量子署名標準です。26.9 で導入され、呼び出し側コードから見ると別の PFX ファイルです。

より良い方法がある

コード変更全体は次のとおりです:

using var signature = new Signature(sourcePath);

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

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

これは RSA 証明書で使用するのと同じ呼び出しです。アルゴリズムは証明書のプロパティであるため、オプションで選択する必要も抽象化レイヤーも不要で、移行期間用の別ルートも現れません。DigitalSignOptions に ML-DSA の PFX を指定すれば、出力は ML-DSA 署名になります。

複数の証明書が関与している場合は、結果から証明書を取り出して確認すると便利です:

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

意見ではなく数値でレベルを選択

ML-DSA には 3 つのパラメータセットがあり、NIST のセキュリティカテゴリ 2、3、5 に対応します。強度が上がるほどキーと署名が大きくなり、合理的な判断方法は自分のドキュメントを 3 回署名して比較することです:

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

サンプルはレベルごとに 1 つずつ署名済みコピーを書き出し、サイズを記録します。したがってトレードオフは仕様書の表ではなく測定結果です。単一の契約書では差は目立ちませんが、数百万件の署名ドキュメントを保管するアーカイブでは、最高レベルに標準化する前に容量面で検討すべき重要な質問になります。

ポリシーで指定がない限り、ML-DSA-65 が妥当なデフォルトです。CNSA 2.0 のようなプロファイルは明示的に ML-DSA-87 を指定し、サイズがマージンより重要な場合にのみ ML-DSA-44 が意味を持ちます。

検証には公開証明書のみが必要

配布の流れは RSA と変わらず、これは 2 つ目の朗報です:

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

VerificationResult result = signature.Verify(options);

受信者が必要なのは署名者の .cer だけで他には何も要りません。署名がコンテンツと一致し、証明書がシリアル番号とサムプリントで一致したときにのみ結果は有効となります。そのため、別の当事者が署名したドキュメントはチェックに失敗します—サンプルは正しい証明書と他人の証明書でそれぞれ検証を実行してこのことを示しています。

サイドバイサイド: 期待と実際

最後の行が計画を制約する要素であり、この記事の率直な部分へとつながります。

まだ機能しないもの

2 つの制限があり、どちらも約束する前に知っておく価値があります。

26.9 のフォーマット対応は Word のみです—DOCX、DOC、ODT など Word 系列全体が対象です。PDF、スプレッドシート、プレゼンテーションは ML-DSA で署名できません。PDF ファーストのパイプラインにとっては、このリリースは移行というよりもプロトタイピングと測定向けです。

もう一つはバリデータのサポートです。ML-DSA 用の標準 XML‑DSig 識別子がまだ存在しないため、Microsoft Word は暗号的に正しく API でも正しく検証できても署名を有効と報告しないことがあります。これは欠陥ではなく標準のギャップであり、検証はファイルを開いてバナーを見るレビュアーではなく、コード側で行う必要があることを意味します。

また、対策不要のプラットフォーム詳細として、.NET は Linux 上の .NET 8 を含むすべての環境で ML-DSA キーを読み取れません。読み取れない場合、GroupDocs.Signature は Word エンジン経由で証明書を取得するため、同じビルドが開発者のラップトップでも Linux コンテナでも条件分岐コードなしで動作します。

これらの制限を考慮して、今やる価値はありますか？

はい、コードとは無関係の 2 つの理由があります。証明書の調達は遅く、公共 CA はまだ ML-DSA 発行を展開中です。そのため、組織側の作業は早めに始めるほど利益があります。また「今日ポスト量子署名を生成できるか？」という質問はコンプライアンスチームが問うようになってきており、計画ではなく署名済みドキュメントで答えられることは、数時間の作業に見合う価値があります。

サンプルが実際に証明すること

4 つのメソッドを順に実行し、終了コードを結果に結び付けます。ML-DSA-65 で契約書に署名し、使用された証明書のサブジェクトを出力します。同じ契約書を 3 つのレベルすべてで署名し、得られたサイズを表示します。署名済みファイルを 2 回検証します—1 回は署名者の公開証明書で成功を期待し、もう 1 回は別の署名者の証明書で失敗を期待します。その後、出力に含まれるデジタル署名を一覧表示します。

2 回目の検証がコピーすべきポイントです。これまで有効入力しか示されていないルーチンでは、無効な入力を拒否するかどうかは何も分かりません。署名に関してはそれが全ての問題です。

実務例: 30年契約

長期保存アーカイブは理論的な話でなくなる場所です。今日署名され、30 年間保存される契約書は、その期間に暗号技術がどう変化しても検証可能でなければなりません。「今収集し、後で復号する」という脅威モデルが文書化されているのは、まさにこの種の資料に対するものです。

そのようなアーカイブに対して実務的に取るべき今日のアクションはデュアルトラックです: ML-DSA がまだカバーしていないフォーマットは RSA を維持し、Word 出力は ML-DSA-65 または 87 で署名し、ドキュメントごとに使用したアルゴリズムを記録しておけば、将来の監査でファイルを開かずに区別できます。

サンプルをコピーする前に修正すべきこと

リポジトリには自己署名の ML-DSA 証明書が同梱されているため、デモはすぐに実行できます。つまり documents/ に 4 つの PFX ファイルとハードコードされたパスワードが置かれています。このサンプル内だけで有効な使い捨てテスト証明書としては問題ありません。

しかし、これは自分のリポジトリに持ち込むべきパターンではありません。代わりに実行時にテスト証明書を生成するか、GroupDocs の certificate‑validity サンプルが行っているように扱うか、あるいはバージョン管理から完全に除外してください。コミットされたキーは取り消しが面倒で、デモが終了した後も残り続ける傾向があります。

結論

ポスト量子移行でコストがかかるのは証明書、ポリシー、バリデータです。コード自体は、少なくとも .NET の Word ドキュメントに関しては別の PFX と同じ DigitalSignOptions 呼び出しです。サンプルをクローンし、自分の契約書のいずれかを指すようにすれば、数分で署名済みファイルが 3 つ、検証結果が 2 つ、サイズ比較が得られます—これは見積もりよりもはるかに実践的な移行計画の基礎となります。

追加リソース

• GitHub の完全な .NET サンプルプロジェクト
• ステップバイステップのユースケースガイド
• デジタル署名でドキュメントに署名
• ドキュメント内のデジタル署名を検証
• GroupDocs.Signature for .NET のドキュメント
• Free Support Forum