XML署名

XML署名（XMLDSig、XML-DSig、XML-Sigとも呼ばれる）は、デジタル署名のためのXML構文を定義するもので、 W3C勧告「XML署名構文と処理」で定義されています。機能的にはPKCS #7と多くの共通点がありますが、より拡張性が高く、XML文書への署名に特化しています。SOAP 、SAMLなどの様々なWeb技術で使用されています。

XML署名は、あらゆる種類のデータ（リソース）に署名するために使用できます。通常はXMLドキュメントですが、URL経由でアクセスできるものであれば何でも署名できます。XMLドキュメントの外側にあるリソースに署名するために使用されるXML署名は、分離署名と呼ばれます。ドキュメントの一部に署名するために使用される場合は、エンベロープ署名と呼ばれます。^{[ 1 ]}署名されたデータが署名自体に含まれている場合は、エンベロープ署名と呼ばれます。^{[ 2 ]}

XML署名は、名前空間Signature内の要素で構成されますhttp://www.w3.org/2000/09/xmldsig#。基本的な構造は以下のとおりです。

<Signature> <SignedInfo> <CanonicalizationMethod /> <SignatureMethod /> <Reference> <Transforms /> <DigestMethod /> <DigestValue /> </Reference> <Reference />など </SignedInfo> <SignatureValue /> <KeyInfo /> <Object /> </Signature>

• このSignedInfo要素は、署名付きデータを含むか、または参照し、使用されるアルゴリズムを指定します。
  • および要素SignatureMethodは要素CanonicalizationMethodによって使用されSignatureValue、SignedInfo改ざんから保護するために に含まれています。
  • 1つ以上のReference要素は、URI参照によって署名対象のリソースと、署名前にリソースに適用される変換を指定します。
    • Transforms署名前にリソースに適用された変換が含まれています。変換は、ドキュメントツリーの定義済みサブセットを選択する XPath 式です。^{[ 3 ]}
    • DigestMethodハッシュを適用する前に、ハッシュアルゴリズムを指定します。
    • DigestValue要素属性で定義された変換済みリソースにハッシュアルゴリズムを適用した結果をBase64エンコードしたものが含まれますReference。
• このSignatureValue要素には、要素で指定されたパラメータを使用して生成された署名である、要素のBase64エンコードされた署名結果が含まれています。これは、要素で指定されたアルゴリズムを適用した後のものです。SignatureMethodSignedInfoCanonicalizationMethod
• KeyInfoオプションとして、署名者は署名を検証する鍵を受信者に提供できます。鍵は通常、1つ以上のX.509デジタル証明書の形式で提供されます。鍵が存在しない場合、依拠当事者はコンテキストから鍵を特定する必要がありますKeyInfo。
• この要素（オプション）には、これがエンベロープ署名Objectである場合、署名済みデータが含まれます。

XML署名を検証する際には、コア検証と呼ばれる手順が実行されます。

1. 参照検証:各Referenceダイジェストは、対応するリソースを取得し、必要な変換を適用した後、指定されたダイジェストメソッドを適用することによって検証されます。結果は記録されたダイジェストと比較されDigestValue、一致しない場合は検証が失敗します。
2. 署名検証:要素SignedInfoは で指定された正規化方法を使用してシリアル化されCanonicalizationMethod、キーデータはKeyInfoまたは他の手段を使用して取得され、署名は で指定された方法を使用して検証されますSignatureMethod。

この手順により、リソースが本当に申し立てられた当事者によって署名されたかどうかが検証されます。ただし、正規化および変換方法の拡張性のため、検証側は、実際に署名またはダイジェストされたものが元のデータに存在していたものと本当に一致していること、つまり、そこで使用されているアルゴリズムが署名されたデータの意味を変更しないことを信頼できることを確認する必要があります。

署名された文書の構造は改ざんされて「署名ラッピング」攻撃につながる可能性があるため、検証プロセスでは XML 文書の構造も対象とする必要があります。署名要素と署名要素は、メソッドではなく絶対XPath式を使用して選択する必要がありますgetElementByName。^{[ 4 ]}

XML署名の作成は、通常のデジタル署名の作成よりもはるかに複雑です。なぜなら、特定のXMLドキュメント（XML開発者の間では「情報セット」と呼ばれることが多い）には、複数の有効なシリアル化表現が存在する可能性があるからです。たとえば、XML要素内の空白は構文的に意味を持たないため、 はと構文的に同一です。<Elem ><Elem>

デジタル署名はデータの完全性を保証するため、1バイトの違いでも署名が変わってしまいます。さらに、XML文書がコンピュータ間で転送される場合、行末文字がCRからLF、CR LFなどに変更される可能性があります。XML文書を解析・検証するプログラムは、属性定義と要素定義の間に余分なスペースを追加したり、相対URL（絶対URLではなく）を使用したり、名前空間定義の順序を変更したりするなど、後でXML文書を異なる方法でレンダリングする可能性があります。特に、XML署名がリモート文書を参照する場合、誤ったリモートサーバーによって時間とともにレンダリング方法が異なる可能性があるため、正規XMLは非常に重要です。

これらの問題を回避し、論理的に同一のXML文書が同一のデジタル署名を生成することを保証するために、XML文書に署名する際にはXML正規化変換（C14nと略されることが多い）が使用されます（署名にはSignedInfo正規化が必須です）。これらのアルゴリズムは、意味的に同一の文書が完全に同一のシリアル化表現を生成することを保証します。

もう一つの問題は、デフォルトの正規化アルゴリズムが名前空間宣言を処理する方法に起因するものです。署名付きXMLドキュメントを別のドキュメントに埋め込む必要がある場合、元の正規化アルゴリズムでは、ドキュメントを単独で処理した場合と同じ結果が得られません。そのため、周囲のXMLとは独立してXML名前空間宣言をシリアル化する、いわゆる排他的正規化が作成されました。

XML署名は、 Pretty Good PrivacyやCryptographic Message Syntaxといった他のデジタル署名形式よりも柔軟性に優れています。なぜなら、バイナリデータではなくXML情報セット上で動作するため、データのサブセットを操作できるからです（バイナリデータでも、例えばバイナリデータのブロックをbase64 ASCIIでエンコードするなど、非標準的な方法で操作できます）。また、署名と署名済み情報を様々な方法で結合し、変換を実行できます。もう一つの重要な概念は正規化です。これは、空白や改行コードといった無意味な違いを排除し、「本質」のみに署名するというものです。

XMLセキュリティのアーキテクチャ全般に対する批判^{[ 5 ]}、特にXML正規化の複雑さ、固有の処理要件、およびパフォーマンス特性の悪さから、XMLデータの署名と暗号化のフロントエンドとしてのXML正規化の適合性に対する批判^{[ 6 ] [ 7 ] [ 8 ]}がある。その主張は、XML正規化を実行すると、トランザクション処理やパフォーマンスに敏感なSOAアプリケーションでは克服できないほどの過剰なレイテンシが発生するというものである。

これらの問題は、 XMLセキュリティワーキンググループで取り組まれています。^{[ 9 ] [ 10 ]}

適切なポリシーと実装がない場合^{[ 4 ]、} SOAPおよびWS-SecurityでのXML Dsigの使用は、 XML署名ラッピング^{[ 12 ]}などの脆弱性につながる可能性があります^{[ 11 ] 。}

XML署名の応用例：

• オランダの監査人によるXBRL年次報告書の電子署名。王立勅許会計士協会が承認したPKIoverheid X.509証明書が必要です。電子署名は法的拘束力があります。SBR保証基準^{[ 13 ]}は、オランダ標準ビジネス報告プログラムの一部です。

• 正規XML
• XML暗号化
• XAdESは、高度な電子署名で使用するためのXML-DSigの拡張機能です。
• 暗号メッセージ構文

• XML署名の構文と処理
• 正規XML
• 追加のXMLセキュリティ統一リソース識別子（URI）
• 排他的XML正規化
• XMLSignatures Java バインディングは、 XMLBeans および JAXB 用にWayback Machineに 2009 年 4 月 11 日にアーカイブされました。
• 署名の作成手順を段階的に示した例。