WAP（Wireless Appication Protocol）：不正アクセスを防止するSSL/TLS（1）

公開仕様のWAP

　移動体通信端末（平たく言えば“ケータイ”）によるインターネットアクセスの周辺事情がここのところ熱い。日本国内では、NTTドコモが独自に開発したiモードと、世界的な業界標準として開発され、日本移動通信（IDO）、セルラー、ツーカーの各社が導入したWAP（Wireless Application Protocol）の2方式が、覇権争いを繰り広げている。

　今のところ、端末数400万台を超えたiモードが先頭を走る。ただし、WAP端末も各社合計で100万台と猛追を仕掛けている。多くのケータイ・インターネットユーザーは、この勝負の行方に大きな興味を持っていることだろう。

　この両者には様々な差異がある。中でも大きな違いは公開仕様かどうかという点だ。NTTドコモ独自方式であるiモードは、現段階では詳しい仕様が公開されていない。一方、WAPの仕様については、WAPフォーラムによってWeb（http://www.wapforum.org/）上で仕様が公開されている。

　言うまでもないが、端末メーカー、通信事業者、サービス開発ベンダーなど、移動体通信に注目する多くの事業者にとって、仕様の公開は極めて大きな意味を持つ。WAP方式のアドバンテージの１つは、まさにこの点にあるといって過言ではないだろう。

　本稿では、現在、公開されているWAP1.2の仕様に基づいて、そのアーキテクチャを概説してゆく。細かい仕様や実装方法には触れないが、WAP方式の構成や技術的なポテンシャルの理解に役立ていただきたい。 WAP1.2の仕様書（PDF版）は、http://www.wapforum.org/what/technical.htmから入手できる。

WAPフォーラム

　WAP仕様の定義や利用推進活動はWAPフォーラムが行っている。WAPフォーラムは、1997年に米国のアンワイヤードプラネット、モトローラ、フィンランドのノキア、スウェーデンのエリクソンの４社で設立した業界団体。現在では200社以上が参加している（http://www.wapforum.org/who/members.htm）。

　参加メンバーには、日本移動通信、セルラー、ツーカーなどの通信事業者、電機メーカー、商社、ソフト／ハードベンダ、など世界中の企業が名を連ねている。ちなみにiモードを主力商品とするNTTドコモもメンバーの1社だ。

　もちろん、参加メンバ全社がWAPサービス／製品を提供しているわけではない。標準仕様策定時によく見られるように、情報収集とかウォッチのために参加する企業もある。そうは言いつつも、影響力のない仕様には参加企業も集まらないのが現実であり、この参加企業数は業界的な影響力を物語っていると考えるのが妥当だろう。

　今後の動向を見ても、WAP vs iモードの単純な対立構造での競争が続くというより、両者の統合が広く進むとの見方が多い。WAPのオープンなフレームワーク、iモードで培った実用技術、それぞれの特長を融合させて、オープンで実用的な業界標準を目指した動きである。W3Cなどで策定されたインターネット標準も取り入れる方向であり、今後は、WAPという仕様ありきではなく、移動体インターネットのための標準化機関としての位置付けが強くなる可能性もあると思われる。

WAP方式の設計趣旨

　ケータイでのインターネット利用を考えるとき、第一には移動体通信ならではの制約をどうクリアするのかが焦点となる。そのあたりをWAP方式では、次のような捉え方をしている。

　まず、移動体通信機器が持つ性質について。これについては、CPUの処理能力が低い、メモリが少ない、電池で駆動しなければならない、入出力デバイスが原始的である、という点を挙げている。これは移動体通信端末の物理サイズに依存する問題で、Internet in my pocketを実現するためには今のところ避けて通れない。

　次は、移動体通信ネットワークの持つ性質だ。固定通信網と比較して、相対的に帯域幅が狭い、遅延が大きい、通信中の安定性が低い、サービスエリア外になると利用できない（圏外）などが挙げられている。例えば、同じ音声伝送媒体で1.5Mbpsの帯域を得ようと思うと、銅より線ならxDSL技術が、移動体通信ならW-CDMAの利用が、それぞれ基準となるだろう。これを技術の普及度で見ると、現段階ではxDSLは既に商用サービスとして提供されているが、W-CDMAは今年の秋くらいからのサービス開始が予定されている。ある時点での利用可能な帯域で比較すれば、やはり固定通信網に軍配があがる。

　一方で、モダンな通信サービスに要求される特性として、WAP方式では次のような項目を強く意識している。相互運用性が高いこと、サービスの拡張性に優れること、移動体通信の特性を十分考慮て効率がよいこと、矛盾が発生せず信頼性が高いこと、通信内容や通信サービスのセキュリティが確保できること、といった点だ。

　これらの条件や要求を合理的にフォローする形として、WAPのアーキテクチャでは次の点を仕様設計時の要求として定義している。これらは、前出の移動体通信の特性を考慮しつつ、モダンな通信サービスを提供するための、必須条件と見てよい。

• 可能な限り既存標準を尊重する
• プロトコルを階層化することで、大規模化やサービス拡張性に対応
• なるべく多くの移動体ネットワークをサポート
• 狭帯域、高遅延という移動体通信独自の特性に対する最適化
• 効率的なシステムを実現し、メモリ、CPU、電力の制約をクリア
• セキュアな通信とサービスの実現
• 柔軟で使いやすいユーザーインタフェースの実現
• 電話機能との統合を図り、ソフトウエアから利用しやすくする
• 通信網オペレーションやサードパーティによるサービス提供の容易化
• マルチベンダ環境への対応
• テレフォニAPIの提供

　なお、実際のWAP方式を策定するにあたっては、アンワイヤードプラネット社（現Phone.com社）が開発した、UP仕様と呼ばれるプロトコルや記述言語がベースになった。アンワイヤードプラネット社はWAPフォーラム設立メンバの1社だ。

WAP方式のネットワーク構成

　iモードの基本思想には、既存標準を重視するスタンスが色濃い。一方、WAPについては、通信効率を特に重視する姿勢が強く、その様子はネットワーク構成にも現れている。

図1　WAP方式のネットワーク構成

　図1はWAP方式のネットワーク構成を模式的に表したものだ。インターネットと移動体ネットワークとは、WAP Proxyと呼ばれるゲートウェイによって接続されている。このマシンは、インターネットのWebサーバーからみると、通常のHTTP Proxyのように見えていて、移動体端末がこのProxyを利用してインターネットにアクセスする、というモデルだ。

　また、WAP Proxyは単純なHTTP Proxyではない。これには大きく3つの働きがある。

• コンテンツ記述言語の変換
  WAP方式ではコンテンツ記述言語としてWMLを採用している。詳しくは後述するが、XMLをベースとするWMLにはHTMLとの互換性がない。そこで、インターネットに存在するWebサーバーにアクセスする際には、WAP Proxyの機能の1つとしてHTMLからWMLへの変換を行っている。なお、Webサーバー上のコンテンツがWAPを意識してWML表記されていれば、この変換は不要である。
• コンテンツ記述言語の表現形式変換
  WMLにはテキスト表現のほかバイナリ表現が定義されている。通信帯域が狭い移動体ネットワーク内では、このうちバイナリ表現でのWMLが使用される。一方、Webサーバー上のコンテンツはテキスト表現が使われるため、WAP Proxyにおいてその変換を行う必要がある。なお、WMLのテキスト表現とバイナリ表現の比較は後で行う。
• ネットワークプロトコルの変換
  ご存知のとおり、インターネットではネットワーク層以上のプロトコルにTCP/IP、HTTPを使用している。一方、WAP方式では次項で説明するような、独自のプロトコルスタックを利用する。これは相対的に狭帯域な移動体ネットワークで、なるべく効率的な通信が行えるよう設計されたもの。この両者の相互変換をWAP Proxyで行う。

　インターネット標準を重視するiモードでは、移動体ネットワーク内でもTCP/IPやHTTPベースのプロトコルを利用している。そのため、インターネットとのゲートウェイが持つ機能は軽くて済む。一方、WAP方式では移動体ネットワーク内での通信をなるべく軽くするため、ゲートウェイには多くの機能を持たせなければならない。そのため、ゲートウェイがネットワーク上の重要な位置を占めることになる。

　このような機能配分になった背景には次のような点が挙げられる。マルチベンダを意識しなければならないWAPには、なるべく端末機能を単純化して製品を作りやすくし、相互運用性を高める必要があった。また端末の仕様を実質的に単一化できるNTTドコモでは、端末に高機能化を求めることができ、特にインターネットとの接続性を重視した、ということだろう。ネットワーク構成には、その方式の持つ背景が強く現れるものだ。

WAPプロトコルスタック

　移動体ネットワーク内でのWAPプロトコルスタックは図2のように定義されている。最下位のベアラサービスは、携帯電話の各方式（日本ではPDC、CdmaOne、PHSなど）が提供するビット透過な通信サービスを指す。そのため、この部分は実装する移動体ネットワークによって異なる。WAP方式として定義されているのは、ベアラサービスの上にある、WDPからWAEまでの部分である。

図2　WAPのプロトコルスタック

　ベアラサービスは、回線交換、パケット交換、ショートメッセージなど、幅広い形態がサポートされている。また、ベアラサービスでPPP／IP／UDPを提供している場合、WDPの代わりにそちらのスタックを使ってもよい。ベアラサービスの持つセキュリティレベルや、上位のサービス内容によって、WTLSを省略することも可能となっている。 各レイヤの機能を簡単に説明する。

• WDP（Wireless Datagram Protocol）
  ベアラサービスに使用する通信網の違いを吸収し、上位層に対して、統一された形でデータグラムサービスを提供する。この層での再送やエラー訂正などは行われないので、基本的にはリライアブルではないデータグラムサービスとなる。もっとも、使用するベアラサービスがリライアブルなら、結果としてWDPで提供するサービスもリライアブルとなる。
  現実には、使用するベアラサービスごとに、WDP over CDMAのように個別のWDPが実装されている。この他にも、WDP over PDCやWDP over PHSの実装がドキュメント上には存在している。
• WTLS（Wireless Transport Layer Security）
  正式名称でいうところのTLS（Transport Layer Security）、一般的にはまだSSL（Secure Socket Layer）と呼ばれている暗号化技術がベースとなっている。この層では、通信内容の暗号化、ユーザー認証、DoS（Denial of Service）の検出など、セキュリティのための機能を提供する。上位のアプリケーションが暗号化を必要としない場合や、下位のベアラサービスによって暗号化が提供されている場合には、この層を利用しなくてもよい。
  暗号化アルゴリズムとしては、RC5、DES、3DES、IDEA、ダイジェストアルゴリズムとしてはSHA、MD5などが定義されている。
• WTP（Wireless Transaction Protocol）
  軽量なトランザクション指向のプロトコルで、リライアブルな通信を行うための仕組みを提供する。TCP/IPネットワークでのTCP相当と考えると分かりやすい。
  通信はメッセージオリエンテッドで行われ、明示的なコネクションセットアップを必要としない。また、3つの通信クラスが用意されていて、リライアブルな一方向のリクエスト、リライアブルなリクエストとレスポンス、リライアブルでない一方向のリクエストのいずれかを利用する。これらはいずれも通信プログラムを軽量化するための施策である。
  なお、上位レイヤのサービスは、リライアブルな通信が必要ならWTPを、そうでない場合にはWDPやその代替となるUDPを利用することができる。
• WSP（Wireless Session Protocol）
  もっともアプリケーションに近い機能を提供するレイヤ。現在の定義はブラウザアプリケーション向けのものになっていて、WSP/Bと表記されることもある。ブラウジングに代表されるコネクション型通信のほかにも、データプッシュのようなコネクションレス型の通信も提供する。具体的には、HTTP/1.1相当機能、long-livedセッションの管理、セッションマイグレーションに伴うサスペンドとリジュームなどのほか、データプッシュやプロトコル機能のネゴシエーションなどを備えている。
• WAE（Wireless Application Envrionment）
  アプリケーションの実行環境に相当する。WMLユーザーエージェント（WMLブラウザ）といった具体的なプログラムのほか、WMLやURLなどフォーマットの定義、テレフォニ機能を利用するためのサービス（WTA）なども含んでいる。
  なお、これら各レイヤで提供するサービスは、直接接する上位レイヤが使用するほかに、レイヤを飛ばして直接アクセスすることも可能だ。たとえばWSPはWTPを利用するほか、WDP（またはUDP）を利用してもよい。

WMLについて

　アプリケーションの実行環境がWAEにおいて定義されているのは前出のとおりである。図3はWAEの定義を図示したものだ。この中にWMLやWMLScriptの定義が含まれている。

図3　WAEの定義

　なかでもWMLはWAPアプリケーションを作成する際にコアとなる要素だ。WMLはXMLをベースに定義されたマークアップ言語で、モバイル環境での利用にも考慮がなされている。たとえばWMLには、CardとDeckと呼ばれる概念がある。Cardは移動体端末に表示される1画面に相当するもの、またDeckは一度のダウンロード単位を表すもので、その中には複数のCardを含んでいる。

　ダウンロードされた一群のCardは端末でキャッシュされる。そのため1つのDeckに含まれるCard間の移動では、ネットワークへのアクセスが発生しない。その結果、端末においてページ間の移動が高速化されるほか、アクセスが集中しがちなProxyの負荷低減や、ネットワークトラフィックの削減効果も期待できるというわけだ。

　WMLのようなマークアップ言語に、ダウンロード単位の概念を含むことの是非は別として、こういった効率化の仕組みが用意されているのはWAP方式ならではだろう。

　同じようにWMLのバイナリ表現も効率化に大きく寄与している。Webサーバー上にあるコンテンツは、テキスト表現のWMLで記述されているが、WAP Proxyを経由して以降、移動体ネットワーク内ではバイナリ表現が用いられている。

　図4はWMLのバイナリ表現の例だ。Card定義に必要なデータサイズは、テキスト表現で30バイト。これをバイナリ表現にすると9バイトで済んでしまう。文字列部分はインライン文字列の識別子と文字列で表記されサイズ削減の効果は少ないが、エレメントやそのアトリビュートは1バイトで表現されるので、全体としてコンテンツサイズは小さくすることができる。

　同様な変換はWMLScriptに対しても行われる。WMLScriptはJavaScriptに相当するスクリプティング言語で、JavaScriptによく似た文法を採用している。サーバー上に配置されたWMLScriptは、WMLをバイナリ表現に変換するのと同時期に、バイトコードと呼ばれるバイナリ表記に変換される。端末に実装されたWMLScriptインタプリタは、そのバイトコードを実行することになる（図5）。

図5　WMLのテキスト表現がバイナリ表現に変換される仕組み

効率重視のWAP

　ここまでWAP方式を見ていて感じとれるのは、ありとあらゆるところに効率を重視する姿勢がにじみ出ている点である。ネットワークや端末の負荷を減らして、幅広いインフラで利用可能にする、そのスタンスは首尾一貫している。もっとも、効率を重視するあまり、WAP Proxyの負担が大きくなったり、WMLとHTMLの互換性がないなどデメリットも生まれている。今後は、こういった部分の改善が進み、さらにiモードなど外部技術との融合が進むことになるだろう。