JP2008028869A

JP2008028869A - 通信代理システムおよび通信代理装置

Info

Publication number: JP2008028869A
Application number: JP2006201232A
Authority: JP
Inventors: Masaya Teraoka; 正也寺岡; Masanori Nishitani; 昌紀西谷
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2006-07-24
Filing date: 2006-07-24
Publication date: 2008-02-07

Abstract

【課題】データ通信においてセキュリティを確保しつつ伝送効率を向上させる。
【解決手段】クライアント端末３００からサーバ装置４００へ秘匿すべきデータが送信されるとき、クライアント代理装置１００とサーバ代理装置２００は秘匿データを中継する。クライアント代理装置１００は、クライアント端末３００の送信処理を代理し、サーバ代理装置２００はサーバ装置４００の受信処理を代理する。クライアント代理装置１００は、クライアント端末３００から暗号化された送信用のデータを取得し、いったん復号した後に圧縮し、更に暗号化してサーバ装置４００に宛てて送信する。サーバ代理装置２００は、クライアント代理装置１００からそのデータを受信し、復号した上で展開し、サーバ装置４００に転送する。サーバ代理装置２００は、サーバ装置４００が発行する公開鍵証明書を自己のルート証明書により認証し、認証結果をクライアント代理装置１００に通知する。
【選択図】図４

Description

この発明は、データ通信技術、特に、データ通信の伝送効率とセキュリティを向上させるための技術、に関する。

近年、コンピュータの普及とネットワーク技術の進展にともない、ネットワークを介した電子情報の交換が盛んになっている。これにより、従来においては紙ベースで行われていた事務処理の多くが、ネットワークベースの処理に置き換えられつつある。このような状況において、通信経路上のデータの盗取や改竄、送受信者のなりすましを防ぐための技術が重要性を増している。

電子情報の交換はＦＴＴＨ（Fiber To The Home）などの有線通信回線上だけでなく、無線ＬＡＮ（Local Area Network）などの無線通信回線上においても行われる。携帯電話やカーナビゲーションシステムなどの移動通信端末の高機能化により、いつでもどこでも手軽に通信できる環境が整いつつある。無線通信回線においては、セキュリティ対策が特に重要である。
特開２００６−１００９７３号公報

また、無線通信回線では、移動通信端末と接続先の基地局（base station）との距離、基地局に接続されている移動通信端末の数、移動通信端末が接続先の基地局を切り換えるときのハンドオーバー（hand-over）などの影響により、パケット損失、ひいては、パケット再送処理が発生しやすい。パケット損失を抑制し、データの伝送効率を向上させる対策も必要である。

本発明者は、送信するデータのサイズを圧縮すれば、パケット損失の発生回数そのものを抑制できることに着目した。データサイズの圧縮は、通信ネットワーク全体のトラフィックを低下させる。パケット従量制の場合であれば、料金面でもメリットがある。しかし、一般的な圧縮技術の場合、同じパターンが繰り返し現れるタイプのデータであれば高い圧縮率を実現できるが、暗号化されたデータにはこのような繰り返しのパターンが現れにくくなり、圧縮率が下がってしまう。

本発明は本発明者の上記課題認識に基づいて完成された発明であり、その主たる目的は、セキュリティ確保とデータサイズ圧縮を両立させることにより、好適なデータ通信を実現するための技術、を提供することにある。

本発明のある態様は、第２のデータ処理装置により発行される公開鍵に基づいて第１のデータ処理装置から第２のデータ処理装置へ暗号化されたデータを送信するシステムに追加される通信代理システムである。このシステムは、第１のデータ処理装置の送信処理を代理する第１通信代理装置と第２のデータ処理装置の受信処理を代理する第２通信代理装置を備える。
第１通信代理装置は、送信側である第１のデータ処理装置から暗号化されたデータを取得し、いったん復号した後に圧縮し、更に暗号化して第２のデータ処理装置に宛てて送信する。
第２通信代理装置は、第１通信代理装置からその暗号化されたデータを受信し、復号した上で展開し、受信側である第２のデータ処理装置に転送する。このとき、第２通信代理装置は、第２のデータ処理装置が発行した公開鍵証明書を取得して認証する機能を備える。

本発明の別の態様も、第２のデータ処理装置により発行される公開鍵に基づいて第１のデータ処理装置から第２のデータ処理装置へ暗号化されたデータを送信するシステムに追加される通信代理システムである。このシステムは、第１のデータ処理装置の送信処理を代理する第１通信代理装置と第２のデータ処理装置の受信処理を代理する第２通信代理装置を備える。
第１通信代理装置は、送信側である第１のデータ処理装置から暗号化されたデータを取得し、いったん復号した後に圧縮し、更に暗号化して第２のデータ処理装置に宛てて送信する。第１通信代理装置は、第２のデータ処理装置が発行した公開鍵証明書を取得して認証する機能を備える。
第２通信代理装置は、第１通信代理装置からその暗号化されたデータを受信し、復号した上で展開し、受信側である第２のデータ処理装置に転送する。

既存の暗号通信システムにこのような通信代理システムを追加することで、効率的なデータ圧縮と暗号化という２つの目的を達成できる。

なお、以上の構成要素の任意の組合せ、本発明を方法、装置、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。

本発明によれば、通信セキュリティ確保しつつ、効率的なデータ圧縮を実現する上で効果がある。

本実施例においては、ＳＳＬ（Secure Socket Layer）をベースとしてクライアント端末３００からサーバ装置４００にデータを送信するクライアント・サーバシステムを対象として説明する。ＳＳＬは、公開鍵暗号方式に基づく通信プロトコルである。

公開鍵暗号方式は、暗号化用の鍵と復号用の鍵が異なる点に特徴がある。公開鍵暗号方式には、ＲＳＡ（Rivest Shamir Adleman）暗号や、ラビン（Rabin）暗号、エルガマル（Elgamal）暗号など、さまざまな実用方式がある。これらのいずれにおいても、公開鍵および秘密鍵という一対の鍵によって暗号化処理と復号処理が実現される。公開鍵暗号方式において、公開鍵で暗号化したデータは秘密鍵でしか復号できない。また、秘密鍵で暗号化したデータは公開鍵でしか復号できない。すなわち、公開鍵で暗号化したデータは、同じ公開鍵でも復号できず、秘密鍵で暗号化したデータも秘密鍵では復号できない。このような公開鍵暗号方式の非対称性を利用したＳＳＬは、電子商取引等のさまざまな場面で使用されている。

図１は、一般的なＳＳＬの仕組みを説明するためのシーケンス図である。
同図では、クライアント端末３００からサーバ装置４００に対して、秘匿すべきデータ（以下、単に「秘匿データ」とよぶ）を送信するとして説明する。まず、クライアント端末３００はサーバ装置４００に接続要求コマンドを送信する（Ｓ１０）。接続要求コマンドは、クライアント端末３００が秘匿データを送信する前に送信すべきとして通信プロトコルに定義されているコマンドであればよい。たとえば、接続要求コマンドは、セッション開始時に送信するＳＹＮパケット（Synchronize Packet）であってもよい。

サーバ装置４００は、接続要求コマンドを受信すると公開鍵と秘密鍵を対生成する（Ｓ１２）。以下、サーバ装置４００が生成する公開鍵のことを「公開鍵Ｓ」、秘密鍵のことを「秘密鍵Ｓ」とよぶ。サーバ装置４００は、公開鍵Ｓのデータを含む公開鍵証明書をクライアント端末３００に送信する（Ｓ１４）。公開鍵証明書は、Ｘ．５０９規格に基づく形式にて生成される。公開鍵証明書には、公開鍵以外にも、公開鍵を認証した認証局、公開鍵の有効期間、発行元であるサーバ装置４００のＩＤなどが含まれる。

クライアント端末３００は、公開鍵証明書を受信すると共通鍵を生成する（Ｓ１６）。以下、クライアント端末３００が生成する共通鍵のことを「共通鍵Ｃ」ともよぶ。ただし、クライアント端末３００は、許容可能な認証局があらかじめ登録されているルート証明書（root certificate）を参照して、公開鍵Ｓの認証局が登録されていることを条件として共通鍵Ｃを生成する。クライアント端末３００は、共通鍵Ｃを公開鍵Ｓにより暗号化する（Ｓ１８）。暗号化された共通鍵Ｃは、サーバ装置４００に送信される（Ｓ２０）。以下、暗号化されていることを示すために「＜＞」という記号を利用して説明する。たとえば、Ｓ２０にて送信される暗号化された共通鍵Ｃのことを＜共通鍵Ｃ＞と表す。サーバ装置４００は、この＜共通鍵Ｃ＞を取得する。

サーバ装置４００は、＜共通鍵Ｃ＞を秘密鍵Ｓで復号し、共通鍵Ｃを取り出す（Ｓ２２）。こうして、クライアント端末３００とサーバ装置４００は共通鍵Ｃを秘密裏に共有する。次に、クライアント端末３００は、送信対象となる秘匿データを共通鍵Ｃにより暗号化する（Ｓ２４）。クライアント端末３００は、この暗号化された＜秘匿データ＞をサーバ装置４００に送信する（Ｓ２６）。サーバ装置４００は、＜秘匿データ＞を共通鍵Ｃで復号し、秘匿データを取り出す（Ｓ２８）。こうして、クライアント端末３００からサーバ装置４００に対して秘匿データが秘密裏に送信される。以上が、一般的なＳＳＬ通信の概略である。

サーバ装置４００からクライアント端末３００にデータを送信する場合にも、Ｓ１０からＳ２２までの処理内容は同じである。サーバ装置４００は共通鍵Ｃにより秘匿データを暗号化してクライアント端末３００に送信する。一般的なＳＳＬ通信では、公開鍵暗号方式によって秘密裏に共通鍵Ｃを共有し、共通鍵Ｃにより秘匿データの暗号化と復号が行われる。通常、共通鍵暗号方式よりも公開鍵暗号方式の方が処理負荷が大きくなるため、公開鍵Ｓは共通鍵Ｃを安全に送り届けるためだけに使われる。クライアント端末３００やサーバ装置４００の処理能力によっては、共通鍵Ｃではなく、公開鍵Ｓによって秘匿データを暗号化するとしてもよい。以下、本実施例においては、秘匿データは公開鍵Ｓではなく共通鍵Ｃにより暗号化されるものとして説明する。

ところで、秘匿データのサイズが大きいほど、伝送に要する時間は長くなり、Ｓ２６におけるパケット送信回数も多くなる。パケット送信回数が多くなると、秘匿データの送信中にパケット損失が発生しやすくなる。無線通信の場合は特に発生しやすい。また、パケット従量制の場合には、秘匿データのサイズが大きいほどユーザに金銭的なコストを強いる結果となる。本実施例においては、秘匿データのサイズを圧縮してパケット送信回数を減少させることにより、伝送時間や伝送コストを改善するというアプローチを採用している。秘匿データのサイズを圧縮するために、クライアント端末３００とサーバ装置４００の間に、クライアント代理装置１００とサーバ代理装置２００を追加する。

図２は、本実施例における通信代理システム３１０のハードウェア構成図である。
クライアント端末３００は、通信ネットワーク３５０を介してサーバ装置４００ａ〜４００ｃにアクセスする。クライアント端末３００は、ノートＰＣ、携帯電話、ＰＨＳ（Personal Handyphone System）、カーナビゲーション端末などの移動通信端末であるが、少なくともＳＳＬに対応した秘匿データ送信機能を備える装置であればよい。サーバ装置４００は、クライアント端末３００からの接続要求を受けてさまざまなサービスを提供する装置である。サーバ装置４００も、ＳＳＬに対応した秘匿データ受信機能を備える装置であればよい。通信ネットワーク３５０は、無線通信ネットワークを含む通信ネットワークである。クライアント端末３００は最寄りの基地局と接続し、通信ネットワーク３５０を介してサーバ装置４００と通信する。

本実施例においては、このようなＳＳＬ対応の通信システムに対して、クライアント代理装置１００とサーバ代理装置２００が通信代理システム３１０として追加される。クライアント代理装置１００は、クライアント端末３００の秘匿データ送信処理を代理する装置であり、クライアント端末３００と通信ネットワーク３５０のインタフェースとなる。したがって、クライアント端末３００はクライアント代理装置１００を介して通信ネットワーク３５０と接続する。クライアント代理装置１００は、クライアント端末３００にインストールされるソフトウェアモジュールであってもよい。クライアント代理装置１００の機能は基地局の機能の一部として実現されてもよいし、ハードウェア的にクライアント端末３００や基地局とは別個の装置であってもよい。本実施例においては、クライアント代理装置１００はクライアント端末３００に代わって通信ネットワーク３５０に接続する単体の装置であるとして説明する。

サーバ代理装置２００は、サーバ装置４００の秘匿データ受信処理を代理する装置であり、サーバ装置４００と通信ネットワーク３５０のインタフェースとなる。したがって、各サーバ装置４００はサーバ代理装置２００を介して通信ネットワーク３５０と接続する。サーバ代理装置２００は、サーバ装置４００にインストールされるソフトウェアモジュールであってもよい。サーバ代理装置２００の機能は、複数のサーバ装置４００をまとめるプロキシサーバ（proxy server）やファイアウォール（firewall）の機能の一部として実現されてもよい。サーバ代理装置２００とサーバ装置４００を接続する通信回線は、イントラネットのような通信ノードを限定した回線であってもよいし、インターネットのような広域回線、あるいは、それらの組み合わせであってもよい。本実施例においては、サーバ代理装置２００はサーバ装置４００に代わって通信ネットワーク３５０に接続する単体の装置であるとして説明する。

クライアント代理装置１００がクライアント端末３００を代理し、サーバ代理装置２００がサーバ装置４００を代理するのは、クライアント端末３００からサーバ装置４００に対して秘匿データを送信するという前提で説明しているためである。したがって、サーバ装置４００からクライアント端末３００に秘匿データを送信する場合には、クライアント代理装置１００はサーバ装置４００を代理し、サーバ代理装置２００はクライアント端末３００を代理することになる。秘匿データを双方向に送信し合う通信システムの場合には、クライアント代理装置１００とサーバ代理装置２００の双方の機能を備えた通信代理装置をクライアント端末３００側とサーバ装置４００側の両方に設置すればよい。

なお、クライアントとサーバの関係は固定的な関係である必要はない。ノード間で適宜、送信側と受信側が入れ替わるような通信システムであっても、通信代理システム３１０を適用可能であることはいうまでもない。Ｐ２Ｐ（Peer to Peer）のようにノード間で相互に直接通信するシステムでも当然に適用できる。

秘匿データの送信について想定されるパターンは以下の３通りである。
Ａ．クライアント・サーバの関係が固定的なシステムにおいて、クライアント端末３００からサーバ装置４００に秘匿データを送信するパターン。いわゆるアップストリーム送信である。
Ｂ．クライアント・サーバの関係が固定的なシステムにおいて、サーバ装置４００からクライアント端末３００に秘匿データを送信するパターン。いわゆるダウンストリーム送信である。
Ｃ．Ｐ２Ｐのようにデータ送信主体とデータ受信主体がノード間で適宜入れ替わるシステムにおいて、送信ノードから受信ノードに対して秘匿データを送信するパターン。

本明細書においては、上記Ａのパターンを前提として説明した上で、上記Ｂのパターンについても付言する。
上記Ｃのパターンについては、上記Ａのパターンと同様である。送信ノードの送信処理は以下に詳述するクライアント代理装置１００の送信機能によって代理される。受信ノードの受信処理は以下に詳述するサーバ代理装置２００の受信機能によって代理される。上記Ｃのパターンのように秘匿データを双方向に送信し合う通信システムの場合には、クライアント代理装置１００とサーバ代理装置２００の双方の機能を備えた通信代理装置を各ノードごとに設置すればよい。送信ノードとなるときにはこの通信代理装置により送信処理が代理される。受信ノードとなるときには通信代理装置により受信処理を代理される。

図３は、通信代理システム３１０によるデータ圧縮処理を図１のＳＳＬ通信処理に追加した場合のシーケンス図である。ここではＡのパターンを前提としている。
同図では、図１のＳＳＬ通信処理に対して単純にデータの圧縮・展開処理を追加した場合のシーケンスを示している。本実施例における実際の通信処理過程は図４以降に関連して説明する予定であるが、その特徴を明確にするために、まず、図３に沿って基本的な処理の流れとその問題点について説明する。

クライアント端末３００が接続要求コマンドをサーバ装置４００に送信すると、クライアント代理装置１００は、接続要求コマンドを中継してサーバ装置４００に転送する（Ｓ１０）。サーバ代理装置２００も、接続要求コマンドをサーバ装置４００に代わって受信したあと、サーバ装置４００に転送する。公開鍵証明書の送信（Ｓ１４）や、＜共通鍵Ｃ＞の送信（Ｓ２０）においても、クライアント代理装置１００とサーバ代理装置２００がデータの中継を行うが、Ｓ１０からＳ２２までの基本的な処理の流れは、図１に関連して説明した内容と同様である。そのため、Ｓ２４における秘匿データの暗号化処理から説明する。

クライアント端末３００は、秘匿データを共通鍵Ｃで暗号化し（Ｓ２４）、＜秘匿データ＞をサーバ装置４００に宛てて送信する（Ｓ２６）。クライアント代理装置１００は、＜秘匿データ＞を受信し、所定のデータ圧縮方法にて圧縮する（Ｓ２９）。圧縮方法としては、ＪＰＥＧ（Joint Photographic Experts Group）やＺＩＰなど、秘匿データのタイプに応じて既知の圧縮技術を応用すればよい。クライアント代理装置１００は、圧縮後の＜秘匿データ＞をサーバ装置４００に宛てて送信する（Ｓ３０）。以下、圧縮されていることを示すために「［］」という記号を利用して説明する。たとえば、Ｓ２９にて圧縮された＜秘匿データ＞のことを［＜秘匿データ＞］と表す。ここまでの処理をまとめると、
秘匿データ→暗号化（Ｓ２４）→＜秘匿データ＞→圧縮（Ｓ２９）→［＜秘匿データ＞］
となる。［＜秘匿データ＞］はサーバ代理装置２００により受信され、サーバ代理装置２００により展開（extract）される（Ｓ３２）。サーバ代理装置２００は展開後の＜秘匿データ＞をサーバ装置４００に転送する（Ｓ３４）。サーバ装置４００は、図１に示したのと同様、＜秘匿データ＞を共通鍵Ｃにより復号する（Ｓ２８）。まとめると、
［＜秘匿データ＞］→展開（Ｓ３２）→＜秘匿データ＞→復号（Ｓ２８）→秘匿データ
である。

このような処理方法によれば、Ｓ３０において送信される［＜秘匿データ＞］のサイズを図１のＳ２６において送信される＜秘匿データ＞よりも小さくできる。また、通信セキュリティも確保できる。一般的には、秘匿データ中に繰り返しパターンが多く現れるほど圧縮率が高くなる。しかし、秘匿データを暗号化すると、この繰り返しパターンの出現頻度が小さくなり圧縮率が下がってしまう。そのため、伝送効率をいっそう向上させるためには、Ｓ２９における圧縮率を高めるための工夫が必要がある。

図４は、本実施例におけるデータ圧縮処理過程を示すシーケンス図である。
図４に示す処理の前提となる処理は、図３のＳ１０からＳ２２までの処理内容と同様である。図４では、Ｓ２４における秘匿データの暗号化処理から説明する。まず、クライアント端末３００は、共通鍵Ｃにより秘匿データを暗号化する（Ｓ２４）。クライアント端末３００は、＜秘匿データ＞をサーバ装置４００に宛てて送信する（Ｓ２６）。クライアント代理装置１００は、この＜秘匿データ＞を取得し、共通鍵Ｃにより復号する（Ｓ３６）。このため、クライアント代理装置１００は、共通鍵Ｃをあらかじめクライアント端末３００から受け取っておく必要がある。クライアント代理装置１００がクライアント端末３００にインストールされるソフトウェアモジュールとして実現される場合、クライアント代理装置１００はクライアント端末３００がＳ１６で共通鍵Ｃを生成したときに共通鍵Ｃが公開鍵Ｓで暗号化される前に受け取ればよい。あるいは、クライアント代理装置１００とクライアント端末３００はあらかじめ静的に生成されている共通鍵Ｃを暗黙的に共有しておいてもよい。本実施例におけるクライアント端末３００とクライアント代理装置１００の間での共通鍵Ｃの共有方法については、図７に関連して後に詳述する。

クライアント代理装置１００は、復号された秘匿データを圧縮する（Ｓ３８）。復号後の圧縮であるため、図３のＳ２９の圧縮よりも高い圧縮率を実現しやすい。クライアント代理装置１００は、所定の共通鍵により、圧縮後の［秘匿データ］を暗号化する（Ｓ４０）。この共通鍵のことを以降においては「共通鍵Ｐ」とよぶことにする。共通鍵Ｐは、あらかじめクライアント代理装置１００とサーバ代理装置２００の間で暗黙的に共有しておいてもよいし、クライアント代理装置１００とサーバ代理装置２００の間でＳＳＬの仕組みによって共有してもよい。クライアント代理装置１００は、圧縮後に共通鍵Ｐにて暗号化された＜［秘匿データ］＞をサーバ装置４００に送信する（Ｓ４２）。

送信側の処理をまとめると、
秘匿データ→暗号化（Ｓ２４）→＜秘匿データ＞→復号（Ｓ３６）→秘匿データ→圧縮（Ｓ３８）→［秘匿データ］→暗号化（Ｓ４０）→＜［秘匿データ］＞
となる。

サーバ代理装置２００は、＜［秘匿データ］＞を受信すると、共通鍵Ｐにより復号し（Ｓ４４）、展開する（Ｓ４６）。サーバ代理装置２００は、所定の共通鍵により、展開後の秘匿データを暗号化する（Ｓ４８）。この共通鍵のことを以降においては「共通鍵Ｑ」とよぶことにする。サーバ代理装置２００は、共通鍵Ｑにより暗号化した＜秘匿データ＞をサーバ装置４００に転送する（Ｓ５０）。サーバ装置４００は、共通鍵Ｑにより＜秘匿データ＞を復号することにより、秘匿データを取得する（Ｓ５２）。サーバ装置４００は、共通鍵Ｑをあらかじめサーバ代理装置２００から受け取っておく必要がある。サーバ代理装置２００がサーバ装置４００にインストールされるソフトウェアモジュールとして実現される場合、サーバ装置４００はサーバ代理装置２００が共通鍵Ｑを生成したときにそのまま受け取ればよい。あるいは、サーバ代理装置２００とサーバ装置４００はあらかじめ共通鍵Ｑを暗黙的に共有しておいてもよい。本実施例におけるサーバ代理装置２００とサーバ装置４００の間での共通鍵Ｑの共有方法については、図７に関連して後に詳述する。

受信側の処理をまとめると、
＜［秘匿データ］＞→復号（Ｓ４４）→［秘匿データ］→展開（Ｓ４６）→秘匿データ→暗号化（Ｓ４８）→＜秘匿データ＞→復号（Ｓ５２）→秘匿データ
となる。

なお、クライアント端末３００の生成した共通鍵Ｃと、秘匿データの暗号化に使用される共通鍵Ｐは同じであってもよい。たとえば、クライアント代理装置１００は、ＳＳＬの仕組みによって、共通鍵Ｃをサーバ代理装置２００に秘密裏に渡すことにより、クライアント端末３００、クライアント代理装置１００、サーバ代理装置２００の間で共通鍵Ｃを共有してもよい。同様に、サーバ代理装置２００とサーバ装置４００の間で使用する共通鍵Ｑと共通鍵Ｐは同じであってもよい。すなわち、共通鍵Ｃ、Ｐ、Ｑは必ずしも別々である必要はない。

また、Ｓ４８以降において、サーバ代理装置２００からサーバ装置４００までの通信セキュリティが確保できる場合には、サーバ代理装置２００は秘匿データを暗号化することなくそのままサーバ装置４００に転送してもよい。
本実施例における通信処理過程の基本的な原理は同図に示した通りである。以下、クライアント代理装置１００とサーバ代理装置２００の具体的な構成について説明した後、特に共通鍵Ｃ、Ｑの共有方法やサーバ装置４００が発行する公開鍵証明書（後述）の認証を中心として、より詳細に通信代理システム３１０の処理内容を説明する。

図５は、クライアント代理装置１００の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。後の図６に示すサーバ代理装置２００についても同様である。
ここでは、主として各ブロックの発揮すべき機能について説明し、それらの具体的な作用については、図７以降に関連して説明する。

クライアント代理装置１００は、ユーザインタフェース処理部１１０、代理インタフェース処理部１２０、ネットワークインタフェース処理部１３０、データ処理部１４０および鍵データ保持部１８０を含む。

ユーザインタフェース処理部１１０は、ユーザからの入力処理やユーザに対する情報表示のようなユーザインタフェース全般に関する処理を担当する。代理インタフェース処理部１２０は、クライアント端末３００とのインタフェース全般に関する処理を担当する。ネットワークインタフェース処理部１３０は、通信ネットワーク３５０を介して、サーバ代理装置２００やサーバ装置４００との通信を担当する。データ処理部１４０は、ユーザインタフェース処理部１１０や代理インタフェース処理部１２０、ネットワークインタフェース処理部１３０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部１４０は、ユーザインタフェース処理部１１０、代理インタフェース処理部１２０、ネットワークインタフェース処理部１３０および鍵データ保持部１８０の間のインタフェースの役割も果たす。鍵データ保持部１８０は、共通鍵や公開鍵・秘密鍵等の各種鍵のデータを格納する。

代理インタフェース処理部１２０は、送信データ取得部１２２、共通鍵取得部１２４および公開鍵発行部１２６を含む。
送信データ取得部１２２は、図４のＳ２６においてクライアント端末３００から送信対象となる＜秘匿データ＞を取得する。既に説明したようにこの＜秘匿データ＞は共通鍵Ｃにより暗号化されている。公開鍵発行部１２６は、クライアント端末３００に対して独自の公開鍵を発行する。クライアント代理装置１００がクライアント端末３００に対して独自に発行する公開鍵（以下、「公開鍵Ｐ」とよぶ）については後に詳述する。なお、公開鍵Ｐと対生成される秘密鍵のことを「秘密鍵Ｐ」とよぶことにする。共通鍵取得部１２４は、クライアント端末３００から公開鍵Ｐによって暗号化された＜共通鍵Ｃ＞を取得する。

ネットワークインタフェース処理部１３０は、データ送信部１３２を含む。データ送信部１３２は、図４のＳ４２に関連して説明したように、＜［秘匿データ］＞をサーバ装置４００に宛てて送信する。

データ処理部１４０は、圧縮処理部１５０と鍵処理部１６０を含む。
圧縮処理部１５０は、秘匿データの圧縮処理を行う。圧縮処理部１５０は、送信データ復号部１５２、送信データ圧縮部１５４および送信データ暗号化部１５６を含む。送信データ復号部１５２は、図４のＳ３６において共通鍵Ｃにより＜秘匿データ＞を復号する。送信データ圧縮部１５４は、図４のＳ３８において復号後の秘匿データを圧縮する。送信データ暗号化部１５６は、図４のＳ４０において圧縮後の［秘匿データ］を共通鍵Ｐにより暗号化する。

鍵処理部１６０は、共通鍵や公開鍵・秘密鍵の生成・取得に関する処理を行う。鍵処理部１６０は、公開鍵生成部１６２、共通鍵復号部１６４、接続要求検出部１６６、認証局登録部１６８および公開鍵認証部１７０を含む。
公開鍵生成部１６２は、クライアント代理装置１００独自の公開鍵Ｐを生成する。このとき、公開鍵Ｐに対応する秘密鍵Ｐも生成される。共通鍵復号部１６４は、クライアント端末３００から受け取った＜共通鍵Ｃ＞を秘密鍵Ｐにより復号する。接続要求検出部１６６は、クライアント端末３００による接続要求コマンドの送信を検出する。認証局登録部１６８は、公開鍵Ｐの認証局をクライアント端末３００のルート証明書に登録する。具体的な処理内容については図７に関連して詳述する。公開鍵認証部１７０は、サーバ装置４００の公開鍵Ｓを認証する。具体的な処理内容については図９に関連して詳述する。

図６は、サーバ代理装置２００の機能ブロック図である。
サーバ代理装置２００は、ユーザインタフェース処理部２１０、代理インタフェース処理部２２０、ネットワークインタフェース処理部２３０、データ処理部２４０および鍵データ保持部２８０を含む。

ユーザインタフェース処理部２１０は、ユーザからの入力処理やユーザに対する情報表示のようなユーザインタフェース全般に関する処理を担当する。代理インタフェース処理部２２０は、サーバ装置４００とのインタフェース全般に関する処理を担当する。ネットワークインタフェース処理部２３０は、通信ネットワーク３５０を介して、クライアント代理装置１００やクライアント端末３００と通信する。データ処理部２４０は、ユーザインタフェース処理部２１０や代理インタフェース処理部２２０、ネットワークインタフェース処理部２３０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部２４０は、ユーザインタフェース処理部２１０、代理インタフェース処理部２２０、ネットワークインタフェース処理部２３０および鍵データ保持部２８０の間のインタフェースの役割も果たす。鍵データ保持部２８０は、共通鍵や公開鍵・秘密鍵等の各種鍵のデータを格納する。

代理インタフェース処理部２２０は、データ転送部２２２、公開鍵取得部２２４および共通鍵発行部２２６を含む。
データ転送部２２２は、図４のＳ５０において共通鍵Ｑにより暗号化された＜秘匿データ＞をサーバ装置４００に転送する。公開鍵取得部２２４は、サーバ装置４００が発行する公開鍵証明書を取得することにより公開鍵Ｓを取得する。公開鍵Ｓの取得に関しては次の図７に関連して詳述する。共通鍵発行部２２６は、サーバ装置４００に対して独自の共通鍵Ｑを発行する。共通鍵Ｑの発行についても図７に関連して詳述する。
ネットワークインタフェース処理部２３０は、データ受信部２３２を含む。データ受信部２３２は、図４のＳ４２において、クライアント代理装置１００のデータ送信部１３２から共通鍵Ｐにより暗号化された＜［秘匿データ］＞を受信する。

データ処理部２４０は、展開処理部２５０と鍵処理部２６０を含む。
展開処理部２５０は、秘匿データの展開処理を行う。展開処理部２５０は、受信データ復号部２５２、受信データ展開部２５４および受信データ暗号化部２５６を含む。受信データ復号部２５２は、図４のＳ４４において＜［秘匿データ］＞を共通鍵Ｐにより復号する。受信データ展開部２５４は、図４のＳ４６において［秘匿データ］を展開する。受信データ暗号化部２５６は、図４のＳ４８において展開後の秘匿データを共通鍵Ｑにより暗号化する。この＜秘匿データ＞が、データ転送部２２２によって送出される。

鍵処理部２６０は、共通鍵や公開鍵・秘密鍵の生成・取得に関する処理を行う。鍵処理部２６０は、共通鍵生成部２６２、共通鍵暗号化部２６４および公開鍵認証部２６６を含む。
共通鍵生成部２６２は共通鍵Ｑを生成する。共通鍵暗号化部２６４は、共通鍵Ｑを公開鍵Ｓにより暗号化する。公開鍵認証部２６６は、サーバ装置４００の公開鍵Ｓを認証する。認証処理の具体的な内容については図８に関連して詳述する。

図７は、本実施例における鍵共有のための処理過程を示すシーケンス図である。
本実施例においては、通常のＳＳＬ通信と異なり、秘匿データの圧縮・展開のために通信代理システム３１０が介在している。通常のＳＳＬ通信であれば、サーバ装置４００が公開鍵Ｓをクライアント端末３００に送信すると、クライアント端末３００は公開鍵Ｓにより共通鍵Ｃを暗号化してサーバ装置４００に送信する。その上で、秘匿データを共通鍵Ｃにより暗号化してサーバ装置４００に送信することになる。
しかし、効率的なデータ圧縮のために、クライアント代理装置１００は共通鍵Ｃにより暗号化された＜秘匿データ＞をいったん復号する必要がある。そのためには、クライアント代理装置１００が共通鍵Ｃを取得しなければならない。クライアント端末３００とクライアント代理装置１００が一体として形成される場合であれば、クライアント代理装置１００はクライアント端末３００から直接共通鍵Ｃを受け取ってもよい。しかし、クライアント代理装置１００が、暗号化前の共通鍵Ｃを取得するには、クライアント端末３００の処理プロセスに介入する必要が生じる。一方、クライアント代理装置１００が暗号化後の＜共通鍵Ｃ＞を取得する場合には、クライアント端末３００の処理プロセスに介入する必要はない。ただし、暗号化後の＜共通鍵Ｃ＞を復号するにはサーバ装置４００しか持っていない秘密鍵Ｓが必要となる。
本実施例においては、クライアント代理装置１００が独自の公開鍵Ｐを生成することによりこのような課題に対処している。同図は、図４に示した処理を実現するための前処理として、クライアント端末３００、クライアント代理装置１００、サーバ代理装置２００およびサーバ装置４００の間で、鍵を共有するために実行される処理を示す。

クライアント端末３００が接続要求コマンドをサーバ装置４００に送信すると（Ｓ１０）、サーバ装置４００は、公開鍵Ｓと秘密鍵Ｓを対生成する（Ｓ１２）。接続要求コマンドは、クライアント代理装置１００とサーバ代理装置２００によって中継される。このとき、クライアント代理装置１００の接続要求検出部１６６は接続要求コマンドの送信を検出する。クライアント代理装置１００の公開鍵生成部１６２は、接続要求コマンドの検出を契機として、公開鍵Ｐと秘密鍵Ｐを独自に対生成する（Ｓ１３）。

サーバ装置４００は、通常のＳＳＬプロトコルにしたがって、公開鍵Ｓの公開鍵証明書を送信する（Ｓ１４）。サーバ代理装置２００の公開鍵取得部２２４は、この公開鍵証明書を横取りし、公開鍵Ｓを取得する。サーバ装置４００の公開鍵証明書はクライアント端末３００に送信されなくなるが、代わりにクライアント代理装置１００が公開鍵Ｐの公開鍵証明書をクライアント端末３００に送信する（Ｓ１５）。クライアント端末３００は、公開鍵証明書を予定通り取得するが、この公開鍵証明書は実際にはサーバ装置４００の公開鍵証明書ではない。

ＳＳＬプロトコルにおいて、サーバ装置４００は、自己の発行した公開鍵証明書が実際にはクライアント端末３００によって取得されていないことを認識する必要はない。また、クライアント端末３００も、実際にはサーバ装置４００ではなくクライアント代理装置１００の公開鍵証明書を取得していることを認識する必要はない。したがって、クライアント端末３００とサーバ装置４００にとってはあくまでもＳＳＬプロトコルの枠組みから外れることなく処理を継続できる。

クライアント端末３００は、クライアント代理装置１００から公開鍵証明書を取得すると、共通鍵Ｃを生成する（Ｓ１６）。クライアント端末３００は、共通鍵Ｃを公開鍵Ｐにより暗号化し（Ｓ１８）、サーバ装置４００に宛てて送信する（Ｓ２０）。クライアント代理装置１００は、この＜共通鍵Ｃ＞を横取りし、サーバ装置４００には送信しない。クライアント代理装置１００の共通鍵復号部１６４は、＜共通鍵Ｃ＞を秘密鍵Ｐにより復号する（Ｓ２３）。こうして、クライアント端末３００とクライアント代理装置１００の間で共通鍵Ｃが秘密裏に共有される。

一方、サーバ代理装置２００の共通鍵生成部２６２は、サーバ装置４００から公開鍵証明書を取得すると、共通鍵Ｑを生成する（Ｓ１７）。サーバ代理装置２００の共通鍵暗号化部２６４は、この共通鍵Ｑを公開鍵Ｓにより暗号化する（Ｓ１９）。そして、データ転送部２２２は、＜共通鍵Ｑ＞をサーバ装置４００に送信する（Ｓ２１）。サーバ装置４００は、＜共通鍵Ｑ＞を秘密鍵Ｓにより復号する（Ｓ２２）。こうして、サーバ代理装置２００とサーバ装置４００の間で共通鍵Ｑが秘密裏に共有される。

以上の処理を経て、クライアント端末３００とクライアント代理装置１００の間で共通鍵Ｃ、サーバ代理装置２００とサーバ装置４００の間で共通鍵Ｑがそれぞれ共有されたあと、図４に示した処理に移行する。サーバ装置４００の公開鍵証明書をクライアント端末３００に送信しない代わりに、クライアント代理装置１００が独自の公開鍵証明書をクライアント端末３００に送信している。また、クライアント端末３００の＜共通鍵Ｃ＞をサーバ装置４００に送信しない代わりに、サーバ代理装置２００が＜共通鍵Ｑ＞をサーバ装置４００に送信している。そのため、通信代理システム３１０が追加されたとしても、クライアント端末３００とサーバ装置４００は、ＳＳＬプロトコルから外れることなくそれぞれの処理を実行できる。

また、クライアント端末３００からクライアント代理装置１００までの通信経路、サーバ代理装置２００からサーバ装置４００までの通信経路においても、共通鍵や秘匿データが暗号化された状態で送信されている。そのため、データ送信のセキュリティをいっそう堅牢にできる。更に、図１に示したような標準的なＳＳＬのプロセスと異なり、公開鍵証明書や＜共通鍵Ｃ＞のデータは実際には通信ネットワーク３５０を通過しない。通信ネットワーク３５０を介したデータ転送プロセスの一部省略により、全体としての伝送効率をいっそう向上させるメリットもある。

クライアント代理装置１００は、接続要求コマンドが検出されるごとに公開鍵Ｐと秘密鍵Ｐを生成してもよいが、最初に接続要求コマンドが検出されたときだけ公開鍵Ｐと秘密鍵Ｐを生成するとしてもよい。これにより、Ｓ１３やＳ１５の処理にともなう処理負荷を軽減できる。あるいは、公開鍵Ｐと秘密鍵Ｐは、いったん生成されると所定の有効期間、たとえば、３０秒間だけ有効であり、この有効期間が経過した後、再度、接続要求コマンドが検出されたときには、新たに公開鍵Ｐ・秘密鍵Ｐを生成するとしてもよい。有効期間が短いほど、クライアント端末３００とクライアント代理装置１００の間における通信セキュリティが向上する。有効期間が長いほど、Ｓ１３およびＳ１５の処理にともなう処理負荷が軽減され、伝送効率が向上する。クライアント端末３００とクライアント代理装置１００の処理能力・使用状況、クライアント端末３００とクライアント代理装置１００間の通信環境等、さまざまな条件に基づいて、公開鍵Ｐ・秘密鍵Ｐの生成タイミングを設定すればよい。

クライアント代理装置１００が発行する公開鍵証明書も、サーバ装置４００が発行する公開鍵証明書と同様、Ｘ．５０９形式にて記述される。この公開鍵証明書には、公開鍵Ｐのほかに、公開鍵Ｐの認証局や公開鍵Ｐの有効期間などの情報が含まれる。図７に示した一連の処理が有効に機能するためには、クライアント端末３００がクライアント代理装置１００から受け取った公開鍵Ｐを正当な公開鍵として受け入れる必要がある。そこで、クライアント代理装置１００の認証局登録部１６８は、あらかじめクライアント端末３００のルート証明書に、自己の発行する公開鍵Ｐの認証局を登録しておく。たとえば、クライアント代理装置１００の設置時において、認証局登録部１６８はクライアント端末３００のルート証明書に、公開鍵Ｐの認証局を登録する。このような登録処理により、クライアント端末３００はクライアント代理装置１００が発行する公開鍵Ｐを受け入れ、ＳＳＬプロトコルに基づく処理をスムーズに継続できる。

ここで、上記Ｂのパターン、すなわち、サーバ装置４００からクライアント端末３００に対して秘匿データを送信する場合について付言しておく。Ｂのパターンでも同様に、クライアント端末３００がサーバ装置４００に接続要求コマンドを送信すると、図７のＳ１２からＳ２２までの処理が実行される。クライアント端末３００とクライアント代理装置１００の間における共通鍵Ｃの共有方法と、サーバ代理装置２００とクライアント代理装置１００の間における共通鍵Ｑの共有方法は、秘匿データがダウンストリームのときであっても変わらない。したがって、図８に示した共通鍵を共有するまでのプロセスは、上記Ａのパターンと上記Ｂのパターンでは基本的に同じである。

ここで、クライアント端末３００がサーバ装置４００に対して秘匿データのダウンロードを要求すると、図４に関連して説明した処理が開始される。ただし、Ｂのパターンにおいては、図４に示した各処理は以下のように変形される。
Ｓ２４：サーバ装置４００が共通鍵Ｑにより秘匿データを暗号化する。
Ｓ２６：サーバ装置４００が共通鍵Ｑにより暗号化した＜秘匿データ＞をサーバ代理装置２００に送信する。
Ｓ３６：サーバ代理装置２００は、共通鍵Ｑにより＜秘匿データ＞を復号する。
Ｓ３８：サーバ代理装置２００は、復号された秘匿データを圧縮する。
Ｓ４０：サーバ代理装置２００は、圧縮された［秘匿データ］を共通鍵Ｐにより暗号化する。
Ｓ４２：サーバ代理装置２００は、＜［秘匿データ］＞をクライアント代理装置１００に送信する。
Ｓ４４：クライアント代理装置１００は、＜［秘匿データ］＞を共通鍵Ｐにより復号する。
Ｓ４６：クライアント代理装置１００は、［秘匿データ］を展開する。
Ｓ４８：クライアント代理装置１００は、秘匿データを共通鍵Ｃにより暗号化する。
Ｓ５０：クライアント代理装置１００は、暗号化された＜秘匿データ＞をクライアント端末３００に送信する。
Ｓ５２：クライアント端末３００は、共通鍵Ｃにより＜秘匿データ＞を復号する。
こうして、サーバ装置４００からクライアント端末３００への秘匿データの送信が実現される。このようなダウンストリーム送信を可能とするためには、サーバ代理装置２００が図５のクライアント代理装置１００の送信機能を備える必要がある。具体的には、サーバ代理装置２００は、クライアント代理装置１００の送信データ取得部１２２、圧縮処理部１５０およびデータ送信部１３２を更に備える。また、クライアント代理装置１００も、図６のサーバ代理装置２００の受信機能を備える必要がある。具体的には、クライアント代理装置１００は、サーバ代理装置２００のデータ受信部２３２、展開処理部２５０およびデータ転送部２２２を更に備えることになる。

図８は、サーバ装置４００が発行する公開鍵証明書をサーバ代理装置２００が認証する処理過程を示すシーケンス図である。
企業のような組織内においては、複数のサーバ装置４００を同じセキュリティポリシにて運用したい場合がある。たとえば、組織内の各サーバ装置４００が発行する公開鍵証明書の認証局としては、認証局Ａ〜Ｆまでの６種類に限って認めるという運用をしたいとする。新たなサーバ装置４００が追加されたとき、そのサーバ装置４００が発行する公開鍵証明書の認証局が上記Ａ〜Ｆのいずれかに該当しているかを自動的にチェックできれば便利である。同図は、複数のサーバ装置４００の受信処理を代理するサーバ代理装置２００にて、このような認証処理を行うときのシーケンス図である。

クライアント端末３００が接続要求コマンドをサーバ装置４００に送信し（Ｓ１０）、サーバ装置４００が公開鍵Ｓ・秘密鍵Ｓを生成すると（Ｓ１２）、サーバ装置４００は、公開鍵Ｓの公開鍵証明書をクライアント端末３００に宛てて送信する（Ｓ１４）。この公開鍵証明書には、公開鍵Ｓの認証局名が含まれる。サーバ代理装置２００の公開鍵取得部２２４は公開鍵証明書を取得し、公開鍵認証部２６６はあらかじめ保持している自己のルート証明書を参照し、公開鍵Ｓの認証局がＡ〜Ｆのいずれかに該当するか判定する（Ｓ５４）。認証結果はクライアント代理装置１００に通知される（Ｓ５６）。

認証に成功すると（Ｓ５８のＹ）、クライアント代理装置１００の公開鍵生成部１６２は、公開鍵Ｐ・秘密鍵Ｐを対生成する（Ｓ１３）。クライアント代理装置１００の公開鍵発行部１２６は公開鍵Ｐを含む公開鍵証明書をクライアント端末３００に送信する（Ｓ１５）。以降の処理は、図７に関連して説明した通りである。

一方、認証に失敗すると（Ｓ５８のＮ）、クライアント代理装置１００のユーザインタフェース処理部１１０は認証失敗を示す警告画面を表示する（Ｓ６０）。ユーザは、この警告画面表示中において、自己の責任で公開鍵Ｓを許容するか否かを選択する（Ｓ６２）。許容する場合には（Ｓ６２のＹ）、処理はＳ１３に移行する。許容しない場合には（Ｓ６２のＮ）、クライアント代理装置１００から公開鍵証明書は発行されることなく処理が終了する。Ｓ６２にて許容された場合には、ネットワークインタフェース処理部１３０は許容の旨をサーバ代理装置２００に通知してもよい。そして、サーバ代理装置２００の公開鍵認証部２６６は、Ｓ６２にて許容された認証局を新たに自己のルート証明書に登録してもよい。このような処理方法によれば、クライアント代理装置１００からサーバ代理装置２００のルート証明書を変更できる。

サーバ代理装置２００において各クライアント端末３００の認証ポリシを適用すれば、複数のサーバ装置４００がそれぞれ発行する公開鍵証明書についての各クライアント端末３００の認証ポリシを一元的に管理できる。Ｓ５４の認証処理では、公開鍵証明書に記載されている公開鍵Ｓの有効期間と現在日時を比較して、公開鍵Ｓが有効期間内にあるかも判定する。また、公開鍵証明書に記載されているサーバ装置４００のＩＤと、公開鍵証明書の実際の送信元が一致しているか判定する。このように、Ｓ５４の認証処理は、公開鍵証明書に含まれる公開鍵のさまざまな属性と、属性について許容可能な所定条件を比較することにより認証する。

図９は、サーバ装置４００が発行する公開鍵証明書をクライアント代理装置１００が認証する処理過程を示すシーケンス図である。
図８とは異なり、クライアント端末３００ごとに認証ポリシを個別に管理したい場合もある。同図は、クライアント端末３００の送信処理を代理するクライアント代理装置１００にて、このような認証処理を行う場合のシーケンス図である。

クライアント端末３００が接続要求コマンドをサーバ装置４００に送信し（Ｓ１０）、サーバ装置４００が公開鍵Ｓ・秘密鍵Ｓを生成すると（Ｓ１２）、サーバ装置４００は、公開鍵Ｓの公開鍵証明書をクライアント端末３００に宛てて送信する（Ｓ１４）。サーバ代理装置２００の公開鍵取得部２２４は公開鍵証明書を取得するが、同図に示す処理の場合、サーバ代理装置２００のネットワークインタフェース処理部２３０は、この公開鍵証明書をクライアント代理装置１００にも転送する（Ｓ７０）。クライアント代理装置１００の公開鍵認証部１７０は、自己のルート証明書に登録されている認証局のいずれかに、公開鍵Ｓの認証局が該当しているかを判定する（Ｓ７２）。なお、このとき参照するルート証明書はクライアント端末３００のルート証明書と同一であってもよい。クライアント代理装置１００のルート証明書とクライアント端末３００のルート証明書が同一であれば、クライアント端末３００の認証ポリシをそのままクライアント代理装置１００にて適用できる。

認証に成功した場合には（Ｓ７４のＹ）、クライアント代理装置１００の公開鍵生成部１６２は、公開鍵Ｐ・秘密鍵Ｐを対生成する（Ｓ１３）。公開鍵発行部１２６は公開鍵Ｐを含む公開鍵証明書をクライアント端末３００に送信する（Ｓ１５）。以降の処理は、図７に関連して説明した通りである。

一方、認証に失敗した場合には（Ｓ７４のＮ）、クライアント代理装置１００のユーザインタフェース処理部１１０は認証失敗を示す警告画面を表示する（Ｓ７６）。クライアント代理装置１００のユーザは、この警告画面表示中において、自己の責任で許容するか、許容しないかを選択する（Ｓ７８）。許容する場合には（Ｓ７８のＹ）、処理はＳ１３に移行する。許容しない場合には（Ｓ７８のＮ）、クライアント代理装置１００から公開鍵証明書は発行されることなく処理が終了する。

このような処理方法によれば、クライアント端末３００ごとの認証ポリシをクライアント代理装置１００にて適用できる。Ｓ７２の認証処理においても、公開鍵Ｓの有効期間やサーバ装置４００のＩＤについての判定がなされる。図８に示した受信側の認証処理と図９に示した送信側の認証処理はいずれか一方を適用するとしてもよいし、受信側でも送信側でも認証処理を行うことにより２重の認証処理を実行するとしてもよい。

以上、本実施例における通信代理システム３１０について説明した。
本実施例に示したように、クライアント端末３００とクライアント代理装置１００が暗号に関する規則について合意しておくことにより、クライアント代理装置１００による＜秘匿データ＞の復号・圧縮・再度暗号化という一連のプロセスを実現できる。このような処理により、通信ネットワーク３５０を通過する秘匿データの圧縮率を高め、かつ、通信セキュリティを確保するという２つの目的を達成している。また、クライアント代理装置１００とサーバ代理装置２００、サーバ代理装置２００とサーバ装置４００の間でそれぞれ暗号規則について合意しておくことにより、サーバ代理装置２００による＜［秘匿データ］＞の復号・展開・再暗号化という一連のプロセスを実現できる。特に、サーバ代理装置２００とサーバ装置４００が暗号規則について合意することによって、サーバ代理装置２００からサーバ装置４００までの通信セキュリティも確保できる。

サーバ代理装置２００は、サーバ装置４００が生成した公開鍵Ｓを横取りし、＜共通鍵Ｃ＞の代わりに＜共通鍵Ｑ＞をサーバ装置４００に渡している。また、共通鍵Ｃにより暗号化された＜秘匿データ＞ではなく、共通鍵Ｑにより暗号化された＜秘匿データ＞を渡している。このため、サーバ装置４００の処理はＳＳＬプロトコルの枠組みから外れなくて済む。
クライアント代理装置１００は、公開鍵Ｓの代わりに独自の公開鍵Ｐをクライアント端末３００に発行している。このため、クライアント端末３００の処理もＳＳＬプロトコルの枠組みから外れなくて済む。
このように、既存のＳＳＬ対応通信システムに対して、通信代理システム３１０を導入しても、クライアント端末３００やサーバ装置４００の処理プロセスに特段の変更が生じない。そのため、本実施例の通信代理システム３１０は既存のＳＳＬ対応通信システムに導入しやすいというメリットがある。ＳＳＬは既に広く普及している通信プロトコルである。本実施例に示した通信代理システム３１０を導入することにより既存のＳＳＬ通信システムの伝送効率を向上させることができる。
なお、通信ネットワーク３５０は、有線通信ネットワークであってもよいが、パケット損失が生じやすい無線通信ネットワークを含む場合には、本実施例に示した通信方法は特に有効である。

クライアント端末３００が、ＳＳＬの仕組みにしたがって共通鍵Ｃで暗号化した＜秘匿データ＞を送信するとき、クライアント代理装置１００はその＜秘匿データ＞を横取りし、復号・圧縮・暗号化という一連の処理を施した上で、サーバ装置４００に送信する。クライアント端末３００にとって、クライアント代理装置１００の有無に関わらず、サーバ装置４００を宛先として＜秘匿データ＞を送信することにはかわりがない。そのため、クライアント代理装置１００を導入しても、クライアント端末３００の設定を変更する必要がない。サーバ装置４００からクライアント端末３００に宛てて＜秘匿データ＞を送信するときのサーバ代理装置２００についても同様である。
クライアント代理装置１００は、クライアント端末３００にインストールされるソフトウェアモジュールであってもよい。この場合、クライアント代理装置１００はクライアント端末３００の機能の一部として形成されることになる。（以下、ソフトウェアモジュールであることを明確化するときには、「クライアント代理モジュール」とよぶことにする）。クライアント端末３００で実行されるアプリケーションソフトウェアが共通鍵Ｃで暗号化した＜秘匿データ＞をクライアント代理モジュールが横取りし、復号・圧縮・暗号化という一連の処理を施した上で、サーバ装置４００に送信してもよい。クライアント代理モジュールの有無に関わらず、送信主体であるアプリケーションソフトウェアにとって、サーバ装置４００を宛先として＜秘匿データ＞を送信することにはかわりがない。サーバ代理装置２００がソフトウェアモジュールとして形成され、サーバ装置４００からクライアント端末３００に宛てて＜秘匿データ＞を送信する場合についても同様である。
クライアント端末３００は、サーバ装置４００ではなくクライアント代理装置１００を直接の宛先としてデータを送信してもよい。たとえば、クライアント端末３００は宛先となるサーバ装置４００のＩＤを含む＜秘匿データ＞をクライアント代理装置１００に送信し、クライアント代理装置１００がそのサーバＩＤによりアドレス解決をした上で、該当するサーバ装置４００に＜秘匿データ＞を送信してもよい。このような処理方法によれば、クライアント端末３００とクライアント代理装置１００間において宛先そのものを秘匿できる。Ｂのパターンのダウンストリーム送信についても同様である。

クライアント代理装置１００は、公開鍵Ｐの認証局をクライアント端末３００のルート証明書に登録する。これにより、クライアント代理装置１００はサーバ装置４００が発行した公開鍵Ｐを自動的に認証するため、図７のＳ１６以降の処理をスムーズに進めることができる。本実施例においては、クライアント端末３００からの接続要求コマンドが検出されるごとに、公開鍵Ｐ・秘密鍵Ｐが対生成される。そのため、クライアント代理装置１００とクライアント端末３００の間の通信セキュリティがいっそう堅牢となっている。

サーバ代理装置２００は、サーバ装置４００が発行した公開鍵Ｓの認証機能を備えてもよい。サーバ代理装置２００において各クライアント代理装置１００の認証ポリシを適用すれば、複数のサーバ装置４００がそれぞれ発行する公開鍵証明書をクライアント代理装置１００の認証ポリシに基づいて一元的に認証できる。また、公開鍵Ｓが認証または許容されなければ、クライアント代理装置１００は公開鍵Ｐを発行しない。そのため、サーバ代理装置２００の認証ポリシに適合しないサーバ装置４００への秘匿データの送信を効果的に抑制できる。

クライアント代理装置１００は、サーバ装置４００が発行した公開鍵Ｓの認証機能を備えてもよい。これにより、各クライアント代理装置１００は、ユーザごとに認証ポリシを管理できる。また、クライアント代理装置１００は、クライアント端末３００とルート証明書を共用することにより、クライアント端末３００の認証ポリシをそのまま適用できる。

なお、共通鍵でなく、公開鍵により秘匿データを暗号化する場合の処理プロセスについても付言しておく。
図７の処理においては、Ｓ１０、Ｓ１２、Ｓ１３、Ｓ１４、Ｓ１５の処理のみが実行対象となる。これにより、クライアント端末３００が公開鍵Ｐ、クライアント代理装置１００が秘密鍵Ｐ、サーバ代理装置２００が公開鍵Ｓ、サーバ装置４００が秘密鍵Ｓを保持する。
次に、図４の処理は以下のように変更される。クライアント端末３００は公開鍵Ｐで秘匿データを暗号化し（Ｓ２４）、＜秘匿データ＞をクライアント代理装置１００に送信する（Ｓ２６）。クライアント代理装置１００は秘密鍵Ｐで＜秘匿データ＞を復号し（Ｓ３６）、圧縮し（Ｓ３８）、共通鍵Ｐで暗号化し（Ｓ４０）、サーバ代理装置２００に送信する（Ｓ４２）。サーバ代理装置２００は、共通鍵Ｐで＜［秘匿データ］＞を復号し（Ｓ４４）、展開し（Ｓ４６）、公開鍵Ｓで暗号化し（Ｓ４８）、送信する（Ｓ５０）。サーバ装置４００は、この＜秘匿データ＞を秘密鍵Ｓで復号する。
このような処理方法に対しても、本実施例に示した圧縮処理と同様の処理内容を適用可能である。

以上、本発明を実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

請求項に記載の第１のデータ処理装置は、本実施例においてはクライアント端末３００に相当し、第２のデータ処理装置はサーバ装置４００に相当する。請求項に記載の第１通信代理装置は、本実施例のＡのパターンにおいてはクライアント代理装置１００に相当し、第２通信代理装置はサーバ代理装置２００に相当する。なお、Ｂのパターンにおいては、第１通信代理装置はサーバ代理装置２００に相当し、第２通信代理装置はクライアント代理装置１００に相当する。
請求項に記載の第１の暗号規則とは、クライアント端末３００とクライアント代理装置１００の間で秘密裏に共有される共通鍵Ｃとその暗号方式に相当し、第２の暗号規則とは、クライアント代理装置１００とサーバ代理装置２００の間で秘密裏に共有される共通鍵Ｐとその暗号方式に相当する。請求項に記載の属性とは、本実施例においては公開鍵の認証局名や公開鍵の有効期間等、公開鍵認証書に記載される公開鍵につい設定される属性全般を示し、請求項に記載の定義データは、本実施例においてはルート証明書に相当する。
このほかにも、請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。

一般的なＳＳＬの仕組みを説明するためのシーケンス図である。本実施例における通信代理システムのハードウェア構成図である。通信代理システムによるデータ圧縮処理を図１のＳＳＬ通信処理に追加した場合のシーケンス図である。本実施例におけるデータ圧縮処理過程を示すシーケンス図である。クライアント代理装置の機能ブロック図である。サーバ代理装置の機能ブロック図である。本実施例における鍵共有のための処理過程を示すシーケンス図である。サーバ装置が発行する公開鍵証明書をサーバ代理装置が認証する処理過程を示すシーケンス図である。サーバ装置が発行する公開鍵証明書をクライアント代理装置が認証する処理過程を示すシーケンス図である。

符号の説明

１００クライアント代理装置、１１０ユーザインタフェース処理部、１２０代理インタフェース処理部、１２２送信データ取得部、１２４共通鍵取得部、１２６公開鍵発行部、１３０ネットワークインタフェース処理部、１３２データ送信部、１４０データ処理部、１５０圧縮処理部、１５２送信データ復号部、１５４送信データ圧縮部、１５６送信データ暗号化部、１６０鍵処理部、１６２公開鍵生成部、１６４共通鍵復号部、１６６接続要求検出部、１６８認証局登録部、１７０公開鍵認証部、１８０鍵データ保持部、２００サーバ代理装置、２１０ユーザインタフェース処理部、２２０代理インタフェース処理部、２２２データ転送部、２２４公開鍵取得部、２２６共通鍵発行部、２３０ネットワークインタフェース処理部、２３２データ受信部、２４０データ処理部、２５０展開処理部、２５２受信データ復号部、２５４受信データ展開部、２５６受信データ暗号化部、２６０鍵処理部、２６２共通鍵生成部、２６４共通鍵暗号化部、２６６公開鍵認証部、２８０鍵データ保持部、３００クライアント端末、３１０通信代理システム、３５０通信ネットワーク、４００サーバ装置。

Claims

第２のデータ処理装置により発行される公開鍵に基づいて第１のデータ処理装置から前記第２のデータ処理装置へ暗号化されたデータを送信するシステムに追加され、前記第１のデータ処理装置の送信処理を代理する第１通信代理装置と前記第２のデータ処理装置の受信処理を代理する第２通信代理装置を備えるシステムであって、
前記第１通信代理装置は、
当該第１通信代理装置と前記第１のデータ処理装置との間で取り決められている第１の暗号規則により暗号化されたデータを前記第１のデータ処理装置から取得する送信データ取得部と、
前記取得されたデータを前記第１の暗号規則により復号する送信データ復号部と、
前記復号されたデータを所定の圧縮方式によって圧縮するデータ圧縮部と、
当該第１通信代理装置と前記第２通信代理装置との間で取り決められている第２の暗号規則により、前記圧縮されたデータを暗号化する送信データ暗号化部と、
前記暗号化されたデータを前記第２通信代理装置に送信するデータ送信部と、を含み、
前記第２通信代理装置は、
前記第１通信代理装置から前記第２の暗号規則により暗号化されたデータを受信するデータ受信部と、
前記受信されたデータを前記第２の暗号規則により復号する受信データ復号部と、
前記復号されたデータを前記圧縮方式に対応した展開方式により展開するデータ展開部と、
前記展開されたデータを前記第２のデータ処理装置に転送するデータ転送部と、
前記第２のデータ処理装置が発行した公開鍵証明書を取得する公開鍵取得部と、
許容可能な公開鍵の属性が記述された所定の定義データと前記公開鍵証明書に記述されている公開鍵の属性を参照して、前記公開鍵証明書に含まれる公開鍵を認証する公開鍵認証部と、
を含むことを特徴とする通信代理システム。
前記第１通信代理装置は、
前記第２のデータ処理装置の公開鍵の代わりに当該第１通信代理装置の公開鍵を前記第１のデータ処理装置に発行する公開鍵発行部と、
前記第１のデータ処理装置から当該第１通信代理装置の公開鍵によって暗号化された共通鍵を取得する共通鍵取得部と、
前記暗号化された共通鍵を当該第１通信代理装置の秘密鍵により復号する共通鍵復号部と、を更に含み、
前記送信データ取得部は、前記共通鍵により暗号化されたデータを前記第１のデータ処理装置から取得し、
前記送信データ復号部は、前記取得されたデータを前記共通鍵により復号することを特徴とする請求項１に記載の通信代理システム。
前記第２通信代理装置の前記公開鍵認証部は、前記第２のデータ処理装置が発行した前記公開鍵証明書の認証結果を前記第１通信代理装置に通知し、
前記第１通信代理装置の前記公開鍵発行部は、前記公開鍵証明書が認証されたことを条件として、当該第１通信代理装置の公開鍵を発行することを特徴とする請求項２に記載の通信代理システム。
第２のデータ処理装置により発行される公開鍵に基づいて前記第２のデータ処理装置から第１のデータ処理装置へ暗号化されたデータを送信するシステムに追加され、前記第１のデータ処理装置の受信処理を代理する第１通信代理装置と前記第２のデータ処理装置の送信処理を代理する第２通信代理装置を備えるシステムであって、
前記第２通信代理装置は、
当該第２通信代理装置と前記第２のデータ処理装置との間で取り決められている第１の暗号規則により暗号化されたデータを前記第２のデータ処理装置から取得する送信データ取得部と、
前記取得されたデータを前記第２の暗号規則により復号する送信データ復号部と、
前記復号されたデータを所定の圧縮方式によって圧縮するデータ圧縮部と、
当該第２通信代理装置と前記第１通信代理装置との間で取り決められている第２の暗号規則により、前記圧縮されたデータを暗号化する送信データ暗号化部と、
前記暗号化されたデータを前記第１通信代理装置に送信するデータ送信部と、を含み、
前記第１通信代理装置は、
前記第２通信代理装置から前記第２の暗号規則により暗号化されたデータを受信するデータ受信部と、
前記受信されたデータを前記第２の暗号規則により復号する受信データ復号部と、
前記復号されたデータを前記圧縮方式に対応した展開方式により展開するデータ展開部と、
前記展開されたデータを前記第１のデータ処理装置に転送するデータ転送部と、を含み、
前記第２通信代理装置は、
前記第２のデータ処理装置が発行した公開鍵証明書を取得する公開鍵取得部と、
許容可能な公開鍵の属性が記述された所定の定義データと前記公開鍵証明書に記述されている公開鍵の属性を参照して、前記公開鍵証明書に含まれる公開鍵を認証する公開鍵認証部と、
を含むことを特徴とする通信代理システム。
第２のデータ処理装置により発行される公開鍵に基づいて第１のデータ処理装置から前記第２のデータ処理装置へ暗号化されたデータを送信するシステムに追加され、前記第２のデータ処理装置の受信処理を代理する装置であって、
所定の圧縮方式にて圧縮された後、所定の暗号規則により暗号化されたデータであって、前記第１のデータ処理装置から前記第２のデータ処理装置に対して送信されるデータを受信するデータ受信部と、
前記受信されたデータを前記所定の暗号規則により復号する受信データ復号部と、
前記復号されたデータを前記圧縮方式に対応した展開方式により展開するデータ展開部と、
前記展開されたデータを前記第２のデータ処理装置に転送するデータ転送部と、
前記第２のデータ処理装置が発行した公開鍵証明書を取得する公開鍵取得部と、
許容可能な公開鍵の属性が記述された所定の定義データと前記公開鍵証明書に記述されている公開鍵の属性を参照して、前記公開鍵証明書に含まれる公開鍵を認証する公開鍵認証部と、
を含むことを特徴とする通信代理装置。
第２のデータ処理装置により発行される公開鍵に基づいて第１のデータ処理装置から前記第２のデータ処理装置へ暗号化されたデータを送信するシステムにおいて、前記第１のデータ処理装置から前記第２のデータ処理装置に送信されたデータを受信するコンピュータプログラムであって、
所定の圧縮方式にて圧縮された後、所定の暗号規則により暗号化されたデータであって、前記第１のデータ処理装置から前記第２のデータ処理装置に対して送信されるデータを受信する機能と、
前記受信されたデータを前記所定の暗号規則により復号する機能と、
前記復号されたデータを前記圧縮方式に対応した展開方式により展開する機能と、
前記展開されたデータを前記第２のデータ処理装置に転送する機能と、
前記第２のデータ処理装置が発行した公開鍵証明書を取得する機能と、
許容可能な公開鍵の属性が記述された所定の定義データと前記公開鍵証明書に記述されている公開鍵の属性を参照して、前記公開鍵証明書に含まれる公開鍵を認証する機能と、
をコンピュータに発揮させることを特徴とする通信代理プログラム。
第２のデータ処理装置により発行される公開鍵に基づいて第１のデータ処理装置から前記第２のデータ処理装置へ暗号化されたデータを送信するシステムに追加され、前記第１のデータ処理装置の送信処理を代理する第１通信代理装置と前記第２のデータ処理装置の受信処理を代理する第２通信代理装置を備えるシステムであって、
前記第１通信代理装置は、
当該第１通信代理装置と前記第１のデータ処理装置との間で取り決められている第１の暗号規則により暗号化されたデータを前記第１のデータ処理装置から取得する送信データ取得部と、
前記取得されたデータを前記第１の暗号規則により復号する送信データ復号部と、
前記復号されたデータを所定の圧縮方式によって圧縮するデータ圧縮部と、
当該第１通信代理装置と前記第２通信代理装置の間で取り決められている第２の暗号規則により、前記圧縮されたデータを暗号化する送信データ暗号化部と、
前記暗号化されたデータを前記第２通信代理装置に送信するデータ送信部と、
前記第２のデータ処理装置が発行した公開鍵証明書を受信する公開鍵取得部と、
許容可能な公開鍵の属性が記述された所定の定義データと前記公開鍵証明書に記述されている公開鍵の属性を参照して、前記公開鍵証明書に含まれる公開鍵を認証する公開鍵認証部と、を含み、
前記第２通信代理装置は、
前記第１通信代理装置から前記第２の暗号規則により暗号化されたデータを受信するデータ受信部と、
前記受信されたデータを前記第２の暗号規則により復号する受信データ復号部と、
前記復号されたデータを前記圧縮方式に対応した展開方式により展開するデータ展開部と、
前記展開されたデータを前記第２のデータ処理装置に転送するデータ転送部と、
を含むことを特徴とする通信代理システム。
前記第１通信代理装置は、
前記第２のデータ処理装置の公開鍵の代わりに当該第１通信代理装置の公開鍵を前記第１のデータ処理装置に発行する公開鍵発行部と、
前記第１のデータ処理装置から当該第１通信代理装置の公開鍵によって暗号化された共通鍵を取得する共通鍵取得部と、
前記暗号化された共通鍵を当該第１通信代理装置の秘密鍵により復号する共通鍵復号部と、を更に含み、
前記送信データ取得部は、前記共通鍵により暗号化されたデータを前記第１のデータ処理装置から取得し、
前記公開鍵発行部は、前記第２のデータ処理装置が発行した前記公開鍵証明書が前記公開鍵認証部により認証されたことを条件として、当該第１通信代理装置の公開鍵を発行することを特徴とする請求項７に記載の通信代理システム。
前記第１通信代理装置の前記公開鍵認証部は、前記第１のデータ処理装置に保持されるデータであって、前記第２のデータ処理装置により許容可能な公開鍵の属性が記述された所定の定義データを参照して、前記公開鍵証明書に含まれる公開鍵を認証することを特徴とする請求項７または請求項８に記載の通信代理システム。
第２のデータ処理装置により発行される公開鍵に基づいて前記第２のデータ処理装置から第１のデータ処理装置へ暗号化されたデータを送信するシステムに追加され、前記第１のデータ処理装置の受信処理を代理する第１通信代理装置と前記第２のデータ処理装置の送信処理を代理する第２通信代理装置を備えるシステムであって、
前記第２通信代理装置は、
当該第２通信代理装置と前記第２のデータ処理装置との間で取り決められている第１の暗号規則により暗号化されたデータを前記第２のデータ処理装置から取得する送信データ取得部と、
前記取得されたデータを前記第１の暗号規則により復号する送信データ復号部と、
前記復号されたデータを所定の圧縮方式によって圧縮するデータ圧縮部と、
当該第２通信代理装置と前記第１通信代理装置の間で取り決められている第２の暗号規則により、前記圧縮されたデータを暗号化する送信データ暗号化部と、
前記暗号化されたデータを前記第１通信代理装置に送信するデータ送信部と、を含み、
前記第１通信代理装置は、
前記第２通信代理装置から前記第２の暗号規則により暗号化されたデータを受信するデータ受信部と、
前記受信されたデータを前記第２の暗号規則により復号する受信データ復号部と、
前記復号されたデータを前記圧縮方式に対応した展開方式により展開するデータ展開部と、
前記展開されたデータを前記第２のデータ処理装置に転送するデータ転送部と、
前記第２のデータ処理装置が発行した公開鍵証明書を受信する公開鍵取得部と、
許容可能な公開鍵の属性が記述された所定の定義データと前記公開鍵証明書に記述されている公開鍵の属性を参照して、前記公開鍵証明書に含まれる公開鍵を認証する公開鍵認証部と、
を含むことを特徴とする通信代理システム。
第２のデータ処理装置により発行される公開鍵に基づいて第１のデータ処理装置から前記第２のデータ処理装置へ暗号化されたデータを送信するシステムに追加され、前記第１のデータ処理装置の送信処理を代理する装置であって、
第１の暗号規則により暗号化されたデータを前記第１のデータ処理装置から取得する送信データ取得部と、
前記取得されたデータを前記第１の暗号規則により復号する送信データ復号部と、
前記復号されたデータを所定の圧縮方式によって圧縮するデータ圧縮部と、
前記第２のデータ処理装置側にて復号可能な第２の暗号規則により、前記圧縮されたデータを暗号化する送信データ暗号化部と、
前記暗号化されたデータを前記第２のデータ処理装置に送信するデータ送信部と、
前記第２のデータ処理装置が発行した公開鍵証明書を受信する公開鍵取得部と、
許容可能な公開鍵の属性が記述された所定の定義データと前記公開鍵証明書に記述されている公開鍵の属性を参照して、前記公開鍵証明書に含まれる公開鍵を認証する公開鍵認証部と、
を含むことを特徴とする通信代理装置。
第２のデータ処理装置により発行される公開鍵に基づいて第１のデータ処理装置から前記第２のデータ処理装置へ暗号化されたデータを送信するシステムにおいて、前記第１のデータ処理装置の送信処理を代理するコンピュータプログラムであって、
第１の暗号規則により暗号化されたデータを前記第１のデータ処理装置から取得する機能と、
前記取得されたデータを前記第１の暗号規則により復号する機能と、
前記復号されたデータを所定の圧縮方式によって圧縮する機能と、
前記第２のデータ処理装置側にて復号可能な第２の暗号規則により、前記圧縮されたデータを暗号化する機能と、
前記暗号化されたデータを前記第２のデータ処理装置に送信する機能と、
前記第２のデータ処理装置が発行した公開鍵証明書を受信する機能と、
許容可能な公開鍵の属性が記述された所定の定義データと前記公開鍵証明書に記述されている公開鍵の属性を参照して、前記公開鍵証明書に含まれる公開鍵を認証する機能と、
をコンピュータに発揮させることを特徴とする通信代理プログラム。