連載 ビジネスWebサービス最新事情（2）
Webサービスのセキュリティ技術を詳解する

Webサービスをビジネスで利用するために、高度なセキュリティやトランザクション処理、複数のWebサービスの連携などを実現するさまざまな仕様が策定されようとしている。本連載では、これらの仕様を理解するための解説を行っていく。（編集局）

日本アイオナテクノロジーズ（株）
藤本 国浩
2003/8/29

■Webサービスセキュリティ関連仕様間の関連

　一般にシステムのセキュリティを考える場合、そこには技術や運用などさまざまな側面が絡み合っており、トランザクションと並んで最も複雑な分野の1つです。従ってWebサービスでのセキュリティ関連仕様も、それぞれの側面に対応する複数の仕様が絡み合って存在します。セキュリティ関連仕様の初回は、主な関連仕様同士の関連性と、それらが基盤としている概念や仕様についての解説を行います。

　今回は、Webサービスにおける主なセキュリティ関連仕様として以下の4つを取り上げます。

• OASIS WS-Security：XML署名とXML暗号をSOAPメッセージ内で使用するための仕様
• W3C XKMS（XML Key Management Specification）：公開鍵基盤（PKI）を使用した公開鍵情報の取得や登録などをWebサービスとして使用可能にするための仕様
• OASIS SAML（Security Assertion Markup Language）：セキュリティ情報（認証、属性、認可）の記述とやりとりに関する標準を規定する仕様
• OASIS XACML（eXtensible Access Control Markup Language）：セキュリティ情報のうち、認可制御ポリシーの記述と認可要求処理サービスに対するインターフェイスに関する標準を規定する仕様

　これら4つの主要な仕様と、そのほかの仕様との関連性を図にすると以下のようになります。

図1　Webサービス関連セキュリティ仕様の相関図 依存：ある仕様が矢印の指す仕様に依存しており、その仕様なしには成立しないことを示します。 使用可能：ある仕様が矢印の指す仕様を組み込んだり、あるいは矢印の指す仕様にマッピングしたりすることで、相互補完的な使用が可能であることを示します。

　上図から分かるように、Webサービスの4つのセキュリティ関連仕様はすべてXML署名およびXML暗号化仕様がベースになっていることが分かります。これ以外の依存関係はWS-SecurityのSOAPへの依存性のみですが、これは仕様自体の目的が「SOAP上でXML署名／暗号化を使う」ことなので当然といえます。

　次に各仕様の「使用可能」関係について、それぞれ具体的に見ていきます。

　まずWS-SecurityからSAMLを使用する場合ですが、WS-Securityはクライアントの認証情報（トークンと呼ばれる）をどのように保持するかについて、さまざまな認証機構を利用可能にしています。仕様ではいくつか具体的なトークンについてその形式（プロファイルと呼ばれる）も定めており、この中にSAMLで記述されたアサーションをトークンとして利用するためのプロファイルが定義されています。

　残りの「使用可能」関係は、矢印が指す仕様を下位プロトコルとしてマッピングすることが可能であることを示します。例えばXKMSのメッセージをSOAPに乗せて運んだり、またXACMLの認可要求処理サービスに対するリクエストメッセージをSAMLの認可アサーション要求として送信したり、ということが可能です。

■セキュリティの基礎概念――暗号、署名、PKI

　ここで各仕様を具体的に説明する前に、それらの基盤となっている概念についておさらいしておきましょう。

共通鍵暗号と公開鍵暗号

　まずはデータを暗号化する方法についてです。これには共通鍵方式と公開鍵方式という大きく分けて2つの方式があります。

　まず共通鍵方式ですが、これはデータの暗号化と復号に同じ鍵を用いる方法です。この方式は原理的に暗号化／復号処理が高速に行えるため、大量のデータを暗号化するのに適しています。しかし暗号化したデータを共有する場合、鍵も共有しなければならないという問題を抱えています。特に共有する相手が離れている場合、鍵をほかに漏れないようにどう交換するかが大きな問題となります。共通鍵暗号方式の代表的なものにはDES、3DES、AES、RC5などがあります。

共通鍵方式名	解　説
DES（Data Encryption Standard）	鍵の長さが56bitの暗号方式。標準になったのは1977年で、米国では政府標準の暗号化手法の1つ
3DES（Triple DES）	DESの暗号化／復号処理を3回実行して暗号化を行う方式。ビジネス用途として比較的広く使用されている
AES（Advanced Encryption Standard）	DESの後継。AESの鍵長は128／192／256bit、ブロック長は128／192／256bitから自由に組み合わせて利用できる
RC5	RC2の改良型で、可変長ブロックサイズ、可変長の鍵サイズ、可変長回数のラウンドを持つブロック暗号化方式

表1　代表的な共通鍵暗号方式

　この共通鍵方式の鍵交換問題を解決するのが公開鍵方式です。公開鍵方式は2つの異なる鍵を使い、どちらか片方の鍵で暗号化したデータはもう片方の鍵でのみ復号することができるというものです。この性質を使って、2つの鍵の一方を秘密鍵として保持し、もう片方を公開鍵として公開することで、安全に鍵を共有することが可能になります。また秘密鍵を持っているのは鍵を生成した本人のみであることから、秘密鍵で暗号化されたはずのデータを公開鍵で復号できるかどうかを検証することにより「デジタル署名」が可能になります（公開鍵で復号できなければ他人のデータ）。

　このように非常に便利な公開鍵方式ですが、原理的に暗号化／復号処理が複雑で処理が遅いという欠点があるため、大量なデータの暗号化処理には向いていません。公開鍵暗号方式の代表的なものにはRSA、Diffie-Hellman、ElGamal、ECCなどがあります。

公開鍵方式名	解　説
RSA	最も普及している公開鍵暗号。大きな数字の素因数分解が非常に困難なことを利用している
DH（Diffie-Hellman）	安全でない通信経路上で共通鍵交換を可能にする技術。共通鍵そのものではなく、乱数と共通鍵から生成した公開情報を送受信する
ElGamal	離散対数問題を利用して、平文と乱数と公開鍵から暗号文を作成し、秘密鍵で復号する
ECC	だ円曲線という数式で定義される特殊な加算法に基づいて暗号化／復号を行う。RSAなどに比べて、長さの短い鍵で高い安全性を確保することができる

表2　代表的な公開鍵暗号方式

　以上のように、共通鍵、公開鍵ともにメリットとデメリットがあるため、実際の暗号システムではこれらを組み合わせて使っています。具体的には「データは共通鍵方式で暗号化し、そこで使った共通鍵をさらに公開鍵方式で暗号化して伝達する」という方法です。この方法ならば、暗号化対象データ自体は共通鍵方式で暗号化するため高速に処理できますし、共通鍵は公開鍵方式で暗号化するため安全に交換することが可能です。また公開鍵方式の処理速度の問題についても、共通鍵自体のサイズが小さいため問題になることはありません。

デジタル署名とダイジェスト

　先に公開鍵暗号方式はデジタル署名に応用可能であると述べましたが、これを行う場合にもいくつか解決しなければならない問題があります。

　まず1つ目は、公開鍵暗号方式の処理の遅さという問題です。署名対象データすべてを秘密鍵で暗号化すると、対象データのサイズが大きい場合に処理が非常に遅くなってしまいます。これを解決するために、一般的には「メッセージダイジェスト」と呼ばれる方法を使います。メッセージダイジェストとは、任意長のデータから比較的小さなサイズの固定長データ（ダイジェストまたはハッシュ値）を生成する「一方向ハッシュ関数」という技術を使って対象データを圧縮する仕組みです。この一方向ハッシュ関数は、「元のデータが少しでも異なると生成されたダイジェストは大きく異なる」「生成されたダイジェストから元のデータを推測することは実質的に不可能」という性質を持っており、改ざんが非常に困難な形で安全に圧縮を行うことが可能になります。

　実際のデジタル署名ではこの方法を使い、元のデータから小さなサイズのダイジェストを生成し、そのダイジェストに対して秘密鍵で暗号化を行うことで署名するという方法を取ります。署名を検証するには、暗号化されたダイジェストを公開鍵で復号したものと、署名のときに使われたものと同一のハッシュ関数を使って、署名対象である元のデータから生成されたダイジェストが同一であるかを比較すればよいことになります。メッセージダイジェストの代表的なものには、SHA-1（Secure Hash Algorithm-1）、MD5（Message Digest 5）などがあります。

メッセージダイジェスト	解　説
SHA-1（Secure Hash Algorithm-1）	2の64乗bit以下の原文から160bitの「ハッシュ値」を生成し、原文が改ざんされていないか比較する。IPsecなどにも応用されている
MD5（Message Digest 5）	原文を基に固定長の「ハッシュ値」を生成し、原文が改ざんされていないか比較する。RFC 1321としてIETFで標準化されている

表3　代表的なメッセージダイジェスト

PKI

　以上のような方法で暗号化や署名を使ってセキュリティを確保することが可能になりますが、ここでもさらにいくつかの問題が残ります。

　まず公開鍵の配布方法について、自分の公開鍵をどうやって公開するのか、また相手の公開鍵をどうやって入手するのかという問題があります。固定した相手同士のやりとりであれば特に問題になりませんが、やりとりする相手が多い場合や、やりとりのパターンが複雑な場合、いちいち公開鍵を相手に要求していたのではらちが明きません。また入手した公開鍵が本当に相手のものなのかを検証する手段も必要です。これができないと他人の公開鍵を使ったなりすましや、署名したことを身に覚えがないと否認することが可能になってしまうからです。

　これらの問題を解決するためのシステムが公開鍵基盤（Public Key Infrastructure：PKI）です。PKIは公開鍵の登録や取得、取得した公開鍵が本人のものであるかどうかの検証や認可などの機能を提供し、公開鍵暗号をさまざまなシステムから使用するためのインフラとしての役割を果たします。

■XML署名とXML暗号化

　さて先に説明した暗号化や署名などのセキュリティ方式をWebサービスで使うためには、WebサービスがXMLをベースとした仕組みである以上、まずそれらがXML上で使用できなくてはなりません。このための標準仕様が、W3Cが策定しているXML署名（XML Signature）とXML暗号化（XML Encryption）の2つの仕様です。先に述べたように、Webサービスにおけるセキュリティに関する4つの主な仕様（WS-Security、XKMS、SAML、XACML）は、すべてこの2つの仕様を基礎として構成されているため、Webサービスにおけるセキュリティに関する仕様を理解するにはまずこの2つの仕様を理解しておく必要があります。

XML署名

　XML署名仕様では、XMLの一部あるいは全体、XMLから参照可能な任意のWebリソースに対して署名を行う方法を定めています。またこの署名は複数の対象に対して同時に行うことや、署名した結果に対してさらに別の署名行うことも可能であり、署名の結果もXMLの要素として表されます。署名で使われる方法（アルゴリズム）に対しても、必須アルゴリズムと鍵構造が規定されているため、異なる実装間での相互運用性が保証されています。

　ここでXMLデータに対して署名を行う場合、1つ大きな問題があります。署名はデータ自体に対してではなくそのダイジェストに対して行うと先に述べました。そしてそのダイジェストは、元のデータが少しでも異なると大きく異なるという性質を持っています。ところがXMLは空白や改行の有無、エンコーディングの種類など、表記上かなりの自由度が許されています。従って意味的に同じXMLデータでもダイジェストがまったく異なるという可能性が常にあります。そうなるとダイジェストが同一かどうかで検証を行う署名は使えなくなってしまいます。

　この問題を解決するのがXML正規化（XML Canonicalization）と排他的XML正規化（Exclusive XML Canonicalization）の2つの仕様です。これらの仕様は、意味的に同一のXML文書は文字列としても同一となるようにするための変換方法を規定しています（排他的正規化は正規化での名前空間の扱いのあいまいさをカバーするための仕様です）。これを用いることによって、署名対象のXMLの内容が同一であれば、そのダイジェストも常に同一であることを保証できるようになります。

XML暗号化

　XML暗号化仕様では、XMLの一部あるいは全体、XMLから参照可能な任意のWebリソースに対して暗号化を行う方法を定めています。暗号化結果に対してさらに暗号化を行うことも可能です。暗号化の結果もXMLの要素として表され、暗号化アルゴリズムや鍵情報なども、結果と同じXML文書に含めることができます。暗号化で使われる方法（アルゴリズム）に対しても、必須アルゴリズムと鍵構造が規定されているため、異なる実装間での相互運用性が保証されています。

　XML暗号化仕様では、鍵情報の記述などに関して、XML署名仕様をそのまま採用しています。また必須アルゴリズムに共通鍵方式と公開鍵方式の両方を採用しているので、暗号方式の項で述べたように2つを併用して処理効率を上げることも可能です。

◆

　今回は、Webサービスにおける主要なセキュリティ関連仕様を概観してみました。次回はOASIS WS-SecurityとXKMSについて解説します。（次回に続く）

■関連記事

　・XML暗号化の基礎と実践　前編　XML暗号化と正規化と電子署名
　・XML暗号化の基礎と実践　後編　XML暗号化と電子署名の実践
　・SOAPのセキュリティはどうなっている？
　・【連載】Webサービスのセキュリティ

■バックナンバー

　1 .複雑化するWebサービスの仕様群を整理する
　2. Webサービスのキュリティ技術を詳解する
　3. OASIS WS-SecurityとXKMSの構造を知る
　4. OASIS SAMLとXACMLの構造を知る
　5. Webサービスを連携させるコレオグラフィ
　6. 混迷するWebサービス・トランザクション制御
　7. BtoB基盤となるWebサービス・トランザクション（最終回）

ビジネスWebサービス最新事情

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）