要約
- 署名属性がない場合、純粋なML-DSAはコンテンツのオクテットを直接署名する。相互運用のため
digestAlgorithmにはSHA-512を記すが、検証者はその値を無視する。 - 署名属性がある場合は、コンテンツのダイジェストが保護対象に入り、受信側の再計算と比較が必要になる。ここではダイジェストの強度が構成全体の上限になり得る。
- 監査証跡では、CMSの分岐、厳密な署名対象、パラメータセットOID、ダイジェスト比較、アルゴリズム保護、鍵と外部μの境界、権限、実行結果を別々に残すべきだ。
運用画面に「SHA-512」「ML-DSA-65」「検証成功」と並んでいても、表示は誤りとは限らない。ただし、その三行からSHA-512が内容をハッシュしたこと、秘密鍵がHSMから出なかったこと、証明書の主体に承認権限があったことまでは導けない。
2025年10月にIETFのProposed Standardとして公開されたRFC 9882は、FIPS 204のML-DSA-44、ML-DSA-65、ML-DSA-87をCryptographic Message Syntaxで用いる規約を定める。各パラメータセットには固有の署名アルゴリズムOIDがあり、そのAlgorithmIdentifierにパラメータを付けてはならない。対象は純粋なML-DSAであり、CMSにおけるHashML-DSAは規定しない。旧称Dilithiumとの互換性もない。
検証の意味を決めるのは、まずsignedAttrsの有無である。
署名属性がなければ、ML-DSAに渡すのはencapContentInfo eContentのOCTET STRING値を構成するオクテットである。タグと長さは含めない。純粋なML-DSAがメッセージを直接処理するため、この経路のSignerInfo.digestAlgorithmは署名計算に意味を持たない。
それでも送信側はSHA-512を指定しなければならない。異なる実装間の不整合を減らすためだ。一方、受信側は欄の内容を無視しなければならない。したがって、この値が示すのは互換性ルールへの準拠であって、外部でSHA-512を実行した履歴ではない。正しく読み取ったフィールドを、誤った因果関係に変えないことが重要になる。
署名属性があれば、署名入力そのものが変わる。対象はSignedAttrs値の完全なDER符号化で、タグと長さを含み、完成したメッセージ内のIMPLICIT [0]タグではなくEXPLICIT SET OFタグを用いる。最低限、content-type属性とmessage-digest属性が必要だ。後者にはコンテンツのハッシュが入り、受信者は再計算して一致を確認する。この経路ではダイジェスト選択に実効的な意味があり、弱い方式は構成全体の安全性を制限し得る。SHA-512のサポートは必須、SHAKE256は推奨で、SHAKE256のパラメータも付けない。
この分岐を記録せずに「署名有効」とだけ残すと、どのバイトを検証したかも、digestAlgorithmが何を意味したかも、内容のハッシュを比較したかも説明できない。結果は正しくても、判断過程の証拠にはならない。
アルゴリズム識別も独立した確認項目だ。検証側はML-DSAパラメータセットのOIDを読み、本来ないはずのパラメータを拒否する。RFC 6211のCMSAlgorithmProtectionは関連するアルゴリズム識別子を署名属性に入れる。RFC 9882は置換攻撃を避けるため、この属性を含めるよう勧告する。数学的な署名が通ったことだけで、その存在や整合性を推定してはならない。
秘密鍵の保護はさらに別の層にある。ML-DSA秘密鍵が漏えいすれば偽造が可能になる。FIPS 204の既定のhedged署名は新しい乱数と秘密鍵内の事前計算されたランダムデータを組み合わせるが、決定論的署名も許す。RFC 9882は、サイドチャネルや故障攻撃が懸念される環境で決定論的方式を使わないよう求める。CMSオブジェクトだけでは実際の選択を証明できない。
HSMも証拠境界を消さない。署名属性を使えば、装置に送るのは大きな本文ではなく小さなDER属性集合で済む。また純粋なML-DSAでは、別の暗号モジュールでメッセージ代表μを計算し、署名側へ渡す構成も可能だ。「HSMが署名した」という事実だけでは、HSMが原文を見たこともμを算出したことも分からない。入力インターフェースと保存済み原文との結び付きが必要になる。
防御可能な記録は、受信したCMSの厳密な保存から始まる。属性の有無を解析し、署名対象バイトを再構成し、OIDとパラメータ不在を確認する。属性があれば内容ダイジェストを再計算・比較し、アルゴリズム保護と署名を検証する。その後に、判明している乱数方針とμの計算境界、証明書経路、主体の同一性、アプリケーション上の権限、最終動作を個別に判断する。
情報源
- https://www.rfc-editor.org/rfc/rfc9882.html
- https://www.rfc-editor.org/rfc/rfc5652.html
- https://www.rfc-editor.org/rfc/rfc6211.html
- https://www.rfc-editor.org/rfc/rfc9881.html
- https://csrc.nist.gov/pubs/fips/204/final
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

