XML暗号化の基礎と実践
前編 XML暗号化と正規化と電子署名 (2/6)
2. 電子署名とXML文書の正規化 |
ある取引でトラブルが起こった。発注した企業は注文書となったXML文書に「100個」と書いて送ったが、商品が1000個納品され、1000個分の代金を請求された。一方、注文を受けた企業は「間違いなく1000個受注している」と、受け取ったXML文書を見せた。そこには個数が1000個と記入されており、発注した企業は「いや、100個だ」と、100個と記入された送信済みのXML文書を見せた。さて、どちらを信用するべきだろうか。
■XML文書の電子署名
現実の世界では、こういうときのために発注書を紙の書類として保存しておく。紙の書類は物理媒体であるため、証拠性が高いからである。しかし電子データではそうもいかない。これは最初に紹介したセキュリティ要件である「否認防止」を実現する場面だ。
ある電子データが「ある人(あるいはコンピュータ)によって作られ、その後変更されていない」ことを数学的に証明するテクノロジとしては、電子署名を利用する。電子署名は大まかにいうと次のような仕組みである。
(1)基本はPKIのような暗号化技術を使う。PKIでは、秘密鍵、公開鍵、証明書、証明局などが要素として存在する。 |
(2)署名したい電子データを作ったら、その電子データに対して、ある計算を行う。例えば、その文書のバイト数を数えたり、といった計算だ。実際にはもっと複雑な計算を行うが、これにより、その文書の特徴が小さなバイト数で表せる。これは「ダイジェスト値」などと呼ばれる。 |
(3)ダイジェスト値を秘密鍵で暗号化する。暗号化されたダイジェスト値を「署名値」という。署名値は、秘密鍵を持っているサーバ上でしか算出できない。 |
(4)元の電子データと、署名値、鍵情報(公開鍵を含む証明書)をセットにして相手に送る。このセットが「署名された電子データ」となり、送信者、受信者双方で「証拠」として保存する。 |
(5)受信した瞬間や、後日にデータの内容を証明したいときには、まず現在の電子データからダイジェスト値を求める。 |
(6)次に、署名された電子データの署名値を公開鍵で解読し、最初のダイジェスト値も求める。 |
(7)両方のダイジェスト値が一致すれば、電子データは改ざんされていないと考えられる(元の電子データが異なってもダイジェスト値が偶然同じになることはあるが、その確率は非常に小さい。そのため、元の文書とダイジェスト値が一致すれば、元のデータは改ざんされていないと考えられる)。 |
XMLの電子署名については、W3Cにより「XML-Signature Syntax and Processing」が勧告されている。このほか、電子署名の技術はさまざまなところで使われている。最近ではPDFに電子署名を付けることもできるようになっている。一般的な電子署名技術については、Security&Trustフォーラムの連載「電子署名導入指南」が参考になるだろう。
■XML文書の正規化
XML文書の電子署名は、一般的な電子署名とは多少異なる手順が必要だ。それは、電子署名する前に、「正規化」と呼ばれる処理が入ることである。なぜ正規化が必要なのだろうか。次の2つのXML文書を見てほしい。
<quantity >100</quantity> |
<quantity>100</quantity> |
左右どちらのXML文書も、同じ意味を持つ。左のXML文書のタグには余計な空白が含まれているが、この空白は通常の処理では無視されるだけであり、XML文書が意味する内容には影響しない。そこで左のXML文書を送信したところ、たまたまXML文書を中継するサーバによって、右のようなXML文書に書き換えられて中継された。
ではこの書き換えは、XML文書の「改ざん」だろうか? たぶん違うだろう。一般の電子署名では、たとえ内容が1bitでも書き換えられていれば改ざんになるが、XML文書の場合には、その内容が表す情報が一緒であれば、書式を整えたり変化するのは通常の処理の一環であり、即改ざんということにはならない。こうした例を簡単にまとめてみた。
<quantity >100</quantity> |
<quantity>100</quantity> |
<quantity > 100 </quantity> |
<quantity>
100 </quantity> |
<quantity > |
<quantity>100</quantity> |
<quantity/> |
<quantity></quantity> |
XML文書の書き方にはゆらぎがある。左のXML文書と右のXML文書は、意味的には同じものだ |
XML文書には、このようにタグの書き方に「ゆらぎ」がある。XMLの電子署名処理では、このゆらぎまでも改ざんと見なすことのないような処理が必要である。
そこでXMLの電子署名では、まずXML文書を整形してから署名をすることになっている。この整形をXML文書の「正規化」といい、英語ではXML Canonicalizationという(CanonicalizationのCからnの間に14文字あることから、「XML c14n」と記述されることもある)。正規化により、「よけいな空白は入れない」「タグの途中で改行しない」「空要素は<xxx/>ではなく、<xxx></xxx>と記述する」などといったことを決めている。Canonical XMLはW3Cで2001年3月19日に勧告されている。実は、上の例では右側が正規化した例だ。
■SOAPのセキュリティ拡張
ところで電子署名技術では、XML文書と一緒に署名データや鍵情報を送る必要がある。これらすべてをXMLデータの形式で送るとするならば、どういうデータフォーマットにするのかが問題になる。これには、SOAPで送信する方法が考えられている。それが「SOAP Security Extensions: Digital Signature」(SOAPセキュリティ拡張:電子署名)である。
図3 署名されたXML文書と、証明書、公開鍵をSOAPでまとめて受信者に送る。受信者はそれを保存しておけば、あとでXML文書が改ざんされたかどうかを確認できる |
SOAPセキュリティ拡張では、<SOAP-SEC>というタグがSOAPのヘッダ内のタグとして定義されており、SOAPボディに入れられたXML文書の署名データ、鍵情報などがヘッダに入れられ、送受信される。
2/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」の詳細も紹介する
|
|