XML暗号化の基礎と実践
後編 XML暗号化と電子署名の実践（6/6）
| 6. XML電子署名と検証 |
■正しく署名されたか検証する
では、今度は署名されたXML文書を検証してみよう。同様に、検証するためのバッチファイルを準備して稼働させる。
set xss4j_home=D:\_work\xss4j |
リスト8 署名されたXML文書を検証するためのバッチファイル（改行個所には↓マークを付加した） |
実行結果は、下記のようにコンソールに表示されると同時にウィンドウとしても表示される。
C:\_userdata\Project\xss4j>java
-Djava.ext.dirs=;D:\IBMJava13\jre\lib\ext;D:\_work\xerces-1_2_3;D:\_work\xalan-j_2_3_1\bin;D:\_work\xss4j
dsig.VerifyGUI 0<signature.xml |
リスト9 電子署名の検証結果画面 |
|
| 画面1 署名検証が正しく行われた結果が示された |
「Core Validity: OK」と表示されており、電子署名が問題ないことを示している。
■データ改ざんを発見できるか？
電子署名されたXML文書は、改ざんを検知することができる。署名された文書は改ざんが許されていないためだ。そこで、改ざんが本当に検知できるかどうかを実験してみる。次の2つの方法で、データに手を加えてみよう。まず、データ部分を書き換えてみよう。署名付き文書「signature.xml」をコピーして、以下のように書き換えてみる。
<?xml version="1.0" encoding="Shift_JIS"
?> |
| リスト10 result.xml このXML文書を下記のように書き換えてみる |
<name> |
| リスト11 result.xml 書き換えたXML文書 |
「yonemochi」が「yonemochi-kun」などに書き換えられており、これを検証すれば当然のことながら「NG」が出る。内容が改ざんされているからだ。
今度は次のように書き換えてみる。firstタグとlastタグの後ろに空白を入れた。これは、このXML文書をテキストとしてみたら改ざんだが、タグの後ろの空白は無視され、XML文書としてはまったく同じ意味を示す。そのため、この改変は改ざんされたと見なされない。このため、署名検査は「OK」となる。
<name> |
| リスト12 result.xml firstタグとlastタグの後ろに空白を入れてみる |
■XMLの正規化
前述した、XML文書の改ざんについては、XML文書の「正規化」処理が関連している。XML文書の電子署名の処理では、下記に示すように必ず正規化が行われているのだ。
| 署名処理 |
| 1． XML文書の正規化 |
| ↓ |
| 2． ツリーのダイジェスト値の計算 |
| ↓ |
| 3． ダイジェスト値の暗号化 |
| 検証処理 |
| 1． XML文書の正規化 |
| ↓ |
| 2． ツリーのダイジェスト値の計算 |
| ↓ |
| 3． 暗号化されたデータの復号 |
| ↓ |
| 4． 計算した値と復号した値の比較 |
正規化は、XML文書の電子署名において非常に重要な処理だ。そこで今度は、XSS4Jの正規化ライブラリで、正規化処理を実際に行ってみよう。
ちょっとわざとらしいが、以下のXML文書を準備する。
<?xml version="1.0> |
| リスト13 正規化を行うため、わざと書式を崩したXML文書 |
これを正規化してみよう。正規化を実行するための「C14nSAX」で処理してみる。
set xss4j_home=D:\_work\xss4j |
| リスト14 正規化を実行するプログラムを呼び出すバッチファイル |
すると以下のような結果が得られる。
<persons> |
| リスト15 正規化されたXML文書。タグの中の空白の扱いや改行など、細かいところがいくつも変更されている |
正規化後、（1）の<person>エレメント以下とまったく同じ形になるのは、（3）と（5）である。つまり、（1）（3）（5）の3つは、正規化前はそれぞれ正規化後とは違う表現で記述されていたのだが、正規化前、後のいずれも、XML文書としては同じ内容を示していることになる。
（2）はデータの前後に改行が含まれているが、これはテキスト・エレメントに含まれるデータとして扱われる。（4）では<name>エレメントと<address>エレメントの間に改行のテキスト・エレメントが含まれていない、と判断されているのがお分かりいただけるだろうか。
こうしたタグの整理などが、正規化と呼ばれる処理である。正規化後に同じXML文書になるのであれば2つは本質的に同一であり、両者の間に改ざんされた形跡はない、と判断できるのだ。
以上、ざっくりとXMLの暗号化、電子署名について実際の方法を紹介してきた。アルファ・ワークスにはこれ以外にも、XKMS/PKIを試すことができる「IBM WebServices Toolkit（WSTK）」なども提供されている。ぜひこうしたツールで実際にXMLの高度な暗号化機能を試してみていただきたい。
 |
6/6 |
| Index | |
| XML暗号化の基礎と実践 | |
| 前編〜XML暗号化と正規化と電子署名 | |
| 1. SSLの利用とXML暗号化の違い | |
| 2. 電子署名とXML文書の正規化 | |
| 3. XML文書のアクセスポリシーとシングル・サインオン | |
| 後編〜XML暗号化と電子署名の実践 | |
| 4. XMLセキュリティ・スイートを使う | |
| 5. XML文書に電子署名をしてみる | |
 |
6. 署名された文書の改ざんを検証 |
- QAフレームワーク：仕様ガイドラインが勧告に昇格 （2005/10/21）
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か （2005/10/12）
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ （2005/9/13）
文字符号化方式（UTF-8、シフトJISなど）を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様（XKMS 2.0）が勧告に昇格 （2005/8/16）
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
 |
|
|
|
|
