XML暗号化の基礎と実践
前編 XML暗号化と正規化と電子署名
XML文書を使ってBtoBなどの社内外のコミュニケーションを実現するときに、大きな問題となってくるのがセキュリティだ。途中でXML文書の内容が改ざんされたり、取引内容を第三者に見られる危険性があれば、安心してビジネスにXMLを利用できない。こうした問題に対処するための使用や技術が登場してきた。それが今回紹介するXMLエレメント暗号や、SOAP拡張などだ。
米持幸寿 ・木下直樹日本アイ・ビー・エム
2002/4/2
1. SSLの利用とXML暗号化の違い |
皆さんは「セキュリティ」という言葉を聞いて何を思い浮かべるだろうか。サーバなどを「ハッカーの侵入から守る」のもセキュリティだし、Webブラウザやメールでのやりとりを「他人から盗み読みされたり改ざんされたりしないようにする」のもセキュリティである。サーバをカギのかかった部屋に設置し、監視カメラで監視するのもセキュリティである。
本稿では、XMLでデータ交換を行う場合に特化したセキュリティのテクノロジや、XML関連のセキュリティの標準規格、または規約案について紹介していく。
まずコンピュータのデータにおけるセキュリティとは何か? ということを確認しておこう。こういった話は、Security&Trustフォーラムの方で多くの筆者が書いていることなので詳細は述べないが、以下のことを考えておけばよい。
(1) | 識別 相手がだれか識別する |
(2) | 認証 識別した相手がその本人であることを証明する |
(3) | 許可 ある操作に対して権限を持っているか、判断する |
(4) | 完全性 送信されたデータが受信されたときも変更されていない |
(5) | 機密性 送信しているデータが読み取られていない |
(6) | 監査 後で、取引の証拠が見られる |
(7) | 否認防止 送信者、受信者の双方で、送受信されたデータが正しいことを証明する |
これらの項目は「すべて必ず解決するべき」ものではない。システムが「どの項目のセキュリティ要件を満たすべきか」をよく見極め、それを中心に解決すべきだ。また、それぞれの項目においても「完全」を追求するのは不可能だ。あるレベルで妥協することが必要である。例えば、1000円の入ったお財布は盗まれないようにしたいが、だからといって100万円もする金庫を買って、その中に入れるわけではない。これと同じで、セキュリティの確保はコストがかかることであり、あるシステムにどれくらいの投資が必要か、情報の価値とコストをてんびんにかける必要がある。
■XMLの交換におけるSSLの利用
XML文書によるデータ交換をする場合、そのメディアにはさまざまなものが利用できる。というか、何を使ってもよい。ネットワーク上で交換する場合は、NetBIOSのような旧来の通信プロトコルでもいいし、TCP/IPでもよい。フロッピーに入れて渡したっていい。しかし、実際に最も多く使われるプロトコルは、HTTPかSMTPのいずれかだろう。
HTTPはご存じのとおり、同期型のプロトコルである。多くの場合、クライアントの「要求の送信」と「返答の受信」の組み合わせで処理が行われる。そして、XML文書の交換に使われる場合には、このメッセージもXML文書であることが多い。
図1 HTTPは基本的に同期型のプロトコルだ。内容は平文で送られるため、のぞき見や改ざんに対しては非常に弱い |
HTTPをXML文書の交換に使う場合、そのままではさまざまな危険がある。通信経路上にあるサーバが、さまざまな悪事を容易に行うことができるからだ。例えば、HTTPで送受信されるデータは、平文のため簡単に中身を「のぞき見」することができる。送受信されるパケットを横取りして、中身を「改ざん」することもできる。要求パケットを横取りして中身を読み取り、それに対応する返答パケットを送り返せば、「なりすまし」を行うのも可能だ。インターネットではすべてのサーバが信用できるわけではないので、こういった危険性を予測して防止する必要がある。
ここで挙げた「のぞき見」「改ざん」「なりすまし」を防止するテクノロジとしては、「SSL(Secure Sockets Layer)」が使える。XML文書の交換にSSLを使う場合、サーバ上で普通にSSLの設定を行えばよい。これは普通のWebアプリケーションでSSLを使うのとまったく同じである。SSLを使うXML通信では、以下のセキュリティ要件に対応できる。
識別 | 認証 | 許可 | 完全性 | 機密性 | 監査 | 否認防止 |
○ | ○ | × | ○ | ○ | × | × |
SSLによって実現できるセキュリティ要件 |
当然のことながら、最近話題のWebサービスでもSSLを使った通信が非常に多く行われている。この場合も「識別」「認証」「完全性」「機密性」といったセキュリティ要素に対応することができる。
■SSLでは十分ではない
XMLによるデータ交換は、Webアプリケーションのように「画面に内容を表示して人間と対話する」のではなく、システム間のデータ交換システムである。そのためデータがポイント間で交換されるだけでなく、複数のシステムの間でワークフローのように移動することも考えられる。SOAPのようなプロトコルを使う場合、そのプロトコルを処理するために一度パースしたデータを、再度プロトコル・パケット、つまりSOAPエンベロープに入れて送出し直すかもしれない。そういったとき、中継サーバの存在に対してSSLは有効な手法ではない。なぜなら、その中継サーバ上でデータを読み取れてしまうからだ。
図2 SSLで通信経路上の情報は暗号化できても、中間サーバ上で情報がのぞき見されたり、改ざんされる可能性がある。これを防ぐには、データ自身の暗号化が必要だ |
そのため、BtoBのようなデータ交換システムでは、通信経路だけを暗号化するのではなく、XML文書そのものを暗号化するテクノロジが求められる。しかも、XML文書全体を暗号化するだけでなく一部だけの暗号化が可能ならば、より使い勝手が良くなる。
例えば通信販売のWebサイトへ、XML文書で発注書を送付することを考えてみよう。発注書には、注文内容とともに支払いのためにクレジットカード番号が記載されているとする。
この発注書は、受注した店舗を経て、支払い情報を通達するためにクレジットカード会社にも転送される。しかし、受注した店舗には注文内容だけを知らせれば十分で、クレジットカード番号はセキュリティのためにも読み取れないようになっていることが望ましい。
■XMLエレメント暗号
クレジットカード番号はお店に見せずに、クレジットカード会社だけに見られるようにしたい。このような、XML文書の部分的な暗号化が必要なときには「XMLエレメント暗号」技術が有効になる。XMLエレメント暗号は、「XML Encryption」としてW3Cに提案されている技術で、ツリー構造に見なしたXML文書のある要素以下をすべて暗号化する。上記の例の場合、クレジットカード番号の保存されている要素だけを暗号化すればいい。
もちろん、XMLエレメント暗号を用いてルートタグを暗号化すれば、XML文書全体が暗号化される。このときルートタグは<EncryptedData>というタグで置き換わり、その中身は全部暗号になる。暗号化には特定のサーバの公開鍵を使う。そうすることで、該当するサーバ(というかその秘密鍵を持っているサーバ)上でしか、そのツリー内の情報を解読できなくなる。これがXMLエレメント暗号の簡単な仕組みだ。鍵の情報は、XML電子署名で決められている<KeyInfo>タグで添付することができる。公開鍵、秘密鍵などの仕組みついては、Security&Trustフォーラムの「5分で絶対に分かるPKI」などを参照してほしい。
下記に、W3Cの「XML Encryption Syntax and Processing」に紹介されているXMLエレメント暗号の例を引用する。
<?xml version='1.0'?> |
上記のデータには、個人情報としてクレジットカード番号などが含まれている。この部分を暗号化すると、下記のようになる |
<?xml version='1.0'?> |
暗号化された部分がEncryptedDataタグで囲まれている |
1/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」の詳細も紹介する
|
|