XML署名

XML署名 (もしくはXML Signature、XMLDsig、XML-DSig、XML-Sigとも呼ばれる)は、デジタル署名のためのXML構文を規定するW3C勧告である。機能的には、PKCS#7と共通の部分が多くあるが、より拡張を備え、XMLドキュメントに対する署名に適応している。これは様々なSOAP、SAMLなどといった様々なウェブ技術で使われている。

XML署名は任意のタイプの–リソース–、典型的にはXMLドキュメントに対して署名を行うために用いられる。XML署名を含むXMLドキュメントの外のリソースに対して署名を行うのに用いられるXML署名をdetached署名と呼び、署名を含むドキュメントのある部分に署名するために用いられるXML署名をenveloped署名と呼び、署名されるデータが署名の中にある場合には、enveloping署名と呼んでいる。

構造

XML署名は、名前空間 http://www.w3.org/2000/09/xmldsig# のSignature要素で構成される。その基本構造は次のようになる:

Signature
  SignedInfo
    SignatureMethod
    CanonicalizationMethod
    Reference
       Transforms
       DigestMethod
       DigestValue
    Reference ...
  SignatureValue
  KeyInfo
  Object

• SignedInfo要素は何に対して署名するか、およびどのアルゴリズムであるかを指定する。SignatureMethod および CanonicalizationMethod要素はSignatureValue要素により使用され、改竄(かいざん)から保護するためにSignedInfoに含まれる。
  Reference要素のリストは、URIの参照を用いて署名されるしソースを指定する。この要素は、ハッシュを適用する前にリソースに対し適用する全ての変換(transform)、(DigestMethodにおいて)ダイジェスト(ハッシュ)アルゴリズム、およびリソースに対して適用した結果(これはDigestValueにおいてBase64エンコードされている)を指定する。

• SignatureValueは、署名のBase64エンコードされた値である。この値は、SignedInfo要素をCanonicalizationMethod要素で指定されたアルゴリズムによりシリアル化した後の(SignatureMethodの指定により生成される)署名である。(正規化に関する詳細は下記を参照のこと)

• KeyInfoは、署名の受信者に対し署名を検証するのに必要となる鍵を取得できるようにするオプション要素である。一般的には一連のX.509証明書を入れることができる。KeyInfo要素が存在しない場合、受信者はデータの内容から鍵を特定することが求められる。

• Objectは、enveloping署名の場合に署名対象データを保持するのに使われるオプションの要素である。

検証とセキュリティ考察

XML署名を検証する際に、コア検証(Core Validation)と呼ばれる手続きは以下のようになる。

1. リファレンス検証(Reference Validation): 個々のReferenceのダイジェスト値は関連するリソースを取得し、指定された全ての変換(transform)を適用し、指定されたダイジェストアルゴリズムを適用することにより検証される。結果は登録されたDigestValueと比較する。一致しない場合、検証失敗となる。
2. 署名検証(Signature Validation): SignedInfo要素はCanonicalizationMethodで指定された正規化方式でシリアル化され、KeyInfoや他の方法を用いて鍵データを取得し、SignatureMethodで指定された方式を用いて署名を検証する。

この手続き、主張する組織により本当にリソースが署名されたものかどうか立証する。しかしながら、正規化(canonicalication)と変換(transformation)方法の拡張性により、検証側の組織では実際に何に対して署名されたり、ハッシュ計算されたのか、言い換えれば、そこで使われたアルゴリズムが署名されたデータの意味を変更しないことを信頼できるかもまた確認しなければならない。

XML正規化 (XML Canonicalization)

XML署名の生成は、通常のデジタル署名の生成よりも少し複雑である。何故なら、与えられたXMLドキュメント(XML開発者の間では一般に"Infoset"と呼ぶ)は、一つ以上の正式なシリアル化された表現が存在するかもしれないからである。例えば、XML要素の中の空白は文法的に区別されないので、<Elem > は文法的には <Elem> と同じである。

デジタル署名はシリアル化されたXMLドキュメントに対し暗号ハッシュ関数(一般的にはSHA1)を実行した結果に対して、暗号化に非対称鍵アルゴリズム(一般的にはRSA)を用いることにより生成されるので、1バイトの違いによりデジタル署名は大きく変化する。

このような問題を回避し、論理的に同一であるXMLドキュメントが同一の署名値を生成することを保証するために、XMLドキュメントを署名する際には、ほぼ常にXML正規化変換(しばしば省略してC14nと呼ばれる)が実行される。(SignedInfoにを署名する際には正規化は必須である。)これらのアルゴリズムは、論理的に同一のドキュメントが、全く同一のシリアル化された表現を生成することを保証している。

デフォルトの正規化アルゴリズムが名前空間を扱う方式のために、また別の大きな問題がある。しばしば、署名されるXMLドキュメントは他のドキュメントを組み込む必要がある。この場合、オリジナルの正規化アルゴリズムではドキュメント単体で扱う時と同じ結果にはならない。このような理由により排他的正規化(Exclusive Canonicalizationと呼ばれる周囲のXMLに依存せずXML名前空間の定義をシリアル化する方式が開発された。

批評

XMLデータへの署名や暗号化のための前処理としてXML正規化を利用ことについて、その複雑さ、固有の処理要件、低いパフォーマンス特性による批判がある。XML正規化を行うと、過度の待ち時間が発生し、単純にトランザクションや、パフォーマンスの影響が大きいSOAアプリケーションでは、解決することが難しいという議論がある。

関連項目

• XAdES, XML Advanced Electronic Signature - 欧州電子署名き係る指針で定めた高度電子署名で利用できるXML署名の拡張

外部リンク

• Performance of Web Services Security
• W3C workshop presentation on XML security
• Performance Comparison of Security Mechanisms for Grid Services
• Why XML canonicalization is bad for Web Services Security
• XML-Signature Syntax and Processing (W3C)
• Canonical XML
• Exclusive XML Canonicalization
• Why XML Security is Broken
• XMLSignatures Java binding for XMLBeans and JAXB.