Nothing Special   »   [go: up one dir, main page]

JP2008166894A - クライアント端末、中継サーバ、通信システム、及び通信方法 - Google Patents

クライアント端末、中継サーバ、通信システム、及び通信方法 Download PDF

Info

Publication number
JP2008166894A
JP2008166894A JP2006350921A JP2006350921A JP2008166894A JP 2008166894 A JP2008166894 A JP 2008166894A JP 2006350921 A JP2006350921 A JP 2006350921A JP 2006350921 A JP2006350921 A JP 2006350921A JP 2008166894 A JP2008166894 A JP 2008166894A
Authority
JP
Japan
Prior art keywords
data
client
encrypted
data communication
communication message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2006350921A
Other languages
English (en)
Other versions
JP4081724B1 (ja
Inventor
Yuichi Ishikawa
雄一 石川
Toshio Koide
俊夫 小出
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2006350921A priority Critical patent/JP4081724B1/ja
Priority to US11/850,899 priority patent/US8583912B2/en
Application granted granted Critical
Publication of JP4081724B1 publication Critical patent/JP4081724B1/ja
Publication of JP2008166894A publication Critical patent/JP2008166894A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60Digital content management, e.g. content distribution
    • H04L2209/601Broadcast encryption

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】秘匿性の高い複数のプライベートネットワーク間の通信を中継する中継サーバの処理負荷を低減する。
【解決手段】本発明による通信システムは、異なるプライベートネットワークに接続される複数のクライアント端末11、21間におけるデータの送受信を、グローバルネットワークに接続される中継サーバ31との間に構築した暗号化セッション利用コネクション13、23を介して実行する。ここで送受信されるデータ通信用メッセージ104は、クライアント端末間で共通のクライアント共有鍵101を用いて暗号化されたデータ202が挿入された暗号化データフィールド107と、中継サーバに通知された情報を含む暗号化セッションヘッダを含む非暗号化データフィールド108とを有する。
【選択図】図1

Description

本発明は、中継サーバを介して通信を行う通信システムに関し、特に異なるプライベートネットワークに接続したクライアント端末間の通信を、グローバルネットワークに接続した中継サーバが中継する通信システムに関する。
近年企業や部門をまたがったコラボレーションが活発化するなど業務形態が多様化しており、異なる企業LANや部門LANに接続している端末同士の通信へのニーズが急速に高まっている。すなわち、異なるプライベートネットワークに接続している端末間における通信に対する要求が高まっている。こうした背景から近年異なるプライベートネットワークに接続する端末同士の通信を可能にする方式が提案されている。従来技術ではグローバルネットワークに設置された中継サーバを介することによって、異なるプライベートネットワークに接続している端末同士の通信を実現している。しかし、プライベートネットワークには通常ファイアウォールが設置されている。このため、異なるプライベートネットワークに接続している端末間の通信は、ファイアウォールによって遮断されることが多い。
通常、ファイアウォールはプライベートネットワークからグローバルネットワークへの特定のTCP(Transmission Control Protocol)通信は許可する設定がなされている。ここでTCP通信とは、例えばWeb閲覧用通信に用いられる宛先ポート80番のTCP通信(すなわちHTTP(Hypertext Transfer Protocol)通信)や宛先ポート443番のTCP通信(すなわちHTTPS(Hypertext Transfer Protocol Layer Security)通信)等である。従来技術では先ず、プライベートネットワーク上の端末からTCPコネクションを中継サーバに対して構築し、端末と中継サーバの間で双方向の通信が行える状態にする。その後、端末は通信相手の端末に渡したいデータを中継サーバとの間に構築したTCPコネクションを利用して送信する。中継サーバは受信したデータを通信相手端末との間に構築したTCPコネクションに対して送信する。
上記のような異プライベートネットワーク間の通信を実現するに当たり、中継サーバは、端末と中継サーバとの間の通信セキュリティを確保しなければならない。中継サーバはグローバルネットワーク上に設置されているため、端末同士の通信もグローバルネットワークを経由することになる。グローバルネットワークはプライベートネットワークとは異なり、常に盗聴などのセキュリティリスクにさらされているため、端末と中継サーバの間の通信を暗号化する必要がある。
従来技術では、端末と中継サーバの間の通信暗号化を実現する技術として主に2つの異なる技術がある。
第1の従来技術では、端末と中継サーバとの間でHTTPSセッションが構築され、端末−中継サーバ間の通信をHTTPSセッション上で行うことで通信の暗号化が行われる。具体的には先ず、端末と中継サーバの間で構築されたTCPコネクションを利用して端末と中継サーバの間でSSL(Security Socket Layer)による共有鍵の交換を行う。端末は通信相手に届けたいデータを中継サーバと交換した共有鍵によって暗号化する。中継サーバは受信した暗号化データを共有鍵によって復号化し、通信相手となる端末との間でHTTPSセッションを構築した際に交換した別の共有鍵を利用して再度暗号化して通信相手となる端末へ転送する。このような第1の従来技術の一例として、SoftEther(登録商標)が挙げられる。
第1の従来技術による中継サーバは、端末から受信したデータの内部に記載された転送先情報を基に転送先を判断する。尚、上記のように端末から受信したデータは何らかの形で暗号化されているため、中継サーバでは受信データ内容を参照するために、データの復号化(更に再暗号化)を行う必要がある。例えばSoftEther(登録商標)では、端末は通信相手に送信したいデータをレイヤ2のヘッダ情報まで含むパケットの形でHTTPSでカプセル化し、予め中継サーバとの間で構築したHTTPSコネクションを利用してカプセル化データを送信する。この際、中継サーバは、受信したデータのデカプセル化を行う。受信データはHTTPSでカプセル化されているため、デカプセル化処理には暗号化されたデータの復号化処理が含まれる。次に、中継サーバは、デカプセル化により取り出したデータ、すなわちレイヤ2のヘッダ情報まで含むパケットのレイヤ2ヘッダを参照し、宛先MACアドレスから転送先の端末を判断する。判断後、中継サーバは、取り出したデータを再度HTTPSでカプセル化し(すなわち復号化されたデータを再度暗号化する)、転送先端末との間で構築したHTTPSコネクションを利用して転送する。
第2の従来技術では、端末−中継サーバ間で構築されたTCPコネクションを利用し、通信を行う端末同士が直接HTTPSセッションを構築する。端末は先ず、宛先ポート番号443番のTCPコネクションを中継サーバとの間で構築する。その後、このTCPコネクションを利用してSSLを利用した共有鍵の交換を通信相手の端末と行う。中継サーバは端末からSSLの共有鍵交換メッセージを受信しても、その内容は吟味せず単に受信したメッセージを通信相手の端末との間で構築したTCPコネクションを利用して転送するだけである。端末は通信相手に届けたいデータを通信相手と交換した共有鍵によって暗号化し、中継サーバとの間で構築したTCPコネクションを利用して送信する。中継サーバは受信したデータの復号化や再暗号化は行わず、そのまま通信相手となる端末との間で構築したTCPコネクションに転送する。このような第2の従来技術の一例として特開2006−50191号公報(特許文献1参照)が挙げられる。又、こうした中継サーバの動作は従来からよく用いられているWeb Proxyサーバと同様の動作である。
第2の従来技術による中継サーバは、端末が中継サーバとの間で確立したTCPコネクションと、通信先の端末とを対応付けた情報に基づいて、コネクションベースで受信データの転送先端末を判断する。このような第2の従来技術の一例として、特開2006−50191号公報(特許文献1参照)、特許第3637863号(特許文献2参照)、特開2003−32236号公報(特許文献3参照)が挙げられる。
第1の従来技術と第2の従来技術との違いは、第1の従来技術による中継サーバは、HTTPSセッションの終端を行う(端末間の通信の復号化や暗号化を行う)のに対して、第2の従来技術による中継サーバは、TCPコネクションの終端のみを行い、HTTPSセッションは終端しない(端末間の通信の復号化や暗号化は行わない)という点である。
第1の従来技術では、中継サーバが転送を行う際に受信データの復号化、再暗号化を行わなければならず、転送を行う度に復号化・暗号化処理の負荷がかかるという課題がある。
第2の従来技術による中継サーバでは、暗号化や符号化処理が省略されるため処理負荷は第1の従来技術に比べて軽減される。しかし、転送データのレイヤ5以上の内容まで吟味してフィルタリングを行う高機能ファイアウォールが設置されたプライベートネットワークからは、中継サーバを介した通信を利用できないという課題がある。プライベートネットワークに高機能ファイアウォールが設置されている場合、端末から中継サーバへ宛先ポート443番のTCPコネクションを構築するまでの通信についてはファイアウォールに遮断されることはないが、中継サーバから端末へ転送される共有鍵交換のためのSSLメッセージがファイアウォールに遮断される可能性がある。
以下、第2の従来技術の問題点を具体的に説明する。SSLメッセージにはSSL Record Headerというフィールドがあり、この部分にメッセージ種別を記載することになっている。メッセージ種別にはHandshake、Change Cipher Spec、Application Data等があり、共有鍵交換のためのメッセージにはメッセージ種別としてHandshake、Change Cipher Specが記載される。SSL Record Header自体は通常暗号化されておらず、ファイアウォールがその内容を吟味することが可能である。つまり、ファイアウォールはSSL Record Headerのメッセージ種別とメッセージの送信方向を見ることにより、SSLセッションがどの方向へ張られようとしているのかを検出することができる。このため、第2の従来技術ではグローバルネットワークの中継サーバからプライベートネットワーク内の端末に対してSSLセッションが張られようとしていることがファイアウォールによって検出される。ファイアウォールは通常グローバルネットワークからプライベートネットワークへのコネクションやセッションの構築を遮断するポリシーで運用されるため、前述のSSLメッセージは遮断される。
特開2006−50191号公報 特許第3637863号公報 特開2003−32236号公報
本発明の目的は、秘匿性の高い複数のプライベートネットワーク間の通信を中継する中継サーバの処理負荷を低減することにある。
本発明の他の目的は、高機能ファイアウォールが設置されたプライベートネットワークを含む複数のプライベートネットワーク間における通信を中継する中継サーバの処理負荷を軽減することにある。
本発明の更に他の目的は、高機能ファイアウォールが設置されたプライベートネットワークを含む複数のプライベートネットワーク間における通信を中継する中継サーバの収容可能端末数を増大することにある。
以下に、[発明を実施するための最良の形態]で使用される番号・符号を括弧付きで用いて、[課題を解決するための手段]を説明する。この番号・符号は、[特許請求の範囲]の記載と[発明を実施するための最良の形態]の記載との対応関係を明らかにするために付加されたものであるが、[特許請求の範囲]に記載されている発明の技術的範囲の解釈に用いてはならない。
本発明による通信システム(1)は、異なるプライベートネットワークに接続される複数のクライアント端末(11、21)間におけるデータの送受信を、グローバルネットワークに接続される中継サーバ(31)を介して実行する。本発明によるクライアント端末(11,21)は、暗号化セッション構築部(111)、共有鍵管理部、データ暗号化部、データ通信用メッセージ作成部(115)、送信部を具備する。暗号化セッション構築部(111)は、中継サーバ(31)との間で送受信する暗号化セッション構築メッセージによって、中継サーバ(31)との間に暗号化セッション利用コネクションを構築し、暗号化セッションヘッダ(203)に含めるヘッダ情報(102)を中継サーバ(31)に通知する。共有鍵管理部(112)は、他のクライアント端末(11、21)と共通のクライアント共有鍵(101)を保持する。データ暗号化部(113)は、クライアント共有鍵(101)を用いてデータの暗号化及び/又はデータのMAC(Message Authentication Code)の計算を行い、クライアント暗号化データ(202)として出力する。データ通信用メッセージ作成部(115)は、クライアント暗号化データ(202)を挿入した暗号化データフィールド(107)と、ヘッダ情報(102)を含む暗号化セッションヘッダ(203)が挿入された非暗号化データフィールド(107)とを含むデータ通信用メッセージ(104)を作成する。送信部は、他のクライアント端末(11、21)宛のデータ通信用メッセージ(104)を、暗号化セッション利用コネクションを利用して中継サーバ(31)に転送する。
中継サーバ(31)は、暗号化セッション構築部(311)、データ通信用メッセージ転送部(312)を具備する。暗号化セッション構築部(311)は、複数のクライアント端末(11、21)のそれぞれとの間で暗号化セッション構築メッセージを送受信することによって、それぞれと個別の暗号化セッション利用コネクションを構築する。又、複数のクライアント端末(11、21)のそれぞれから、暗号化セッションヘッダ(203)に含めるヘッダ情報(102)を取得する。データ通信用メッセージ転送部(312)は、暗号化セッション利用コネクションを利用して、複数のクライアント端末(11、21)のそれぞれとの間においてデータ通信用メッセージ(104)を送受信する。ここで、クライアント端末(11、21)から受信するデータ通信用メッセージ(104)は、クライアント共有鍵(101)によって暗号化されたクライアント暗号化データ(202)が挿入された暗号化データフィールド(107)と、ヘッダ情報(102)を含む暗号化セッションヘッダ(203)が挿入された非暗号化データフィールド(107)とを含む。データ通信用メッセージ転送部(312)は、複数のクライアント端末(11、21)のいずれかから転送されたデータ通信用メッセージ(104)の非暗号化データフィールド(107)に含まれる暗号化セッションヘッダ(203)を、データ通信用メッセージ(104)の転送先となるクライアント端末(11、21)に対応する暗号化セッションヘッダ(203)に変換し、暗号化セッションヘッダ(203)を変換したデータ通信用メッセージ(104)を、転送先のクライアント端末(11、21)に転送する。
本発明では中継サーバ(31)を介して通信を行うクライアント端末(11、21)同士が交換したクライアント共有鍵(101)を利用してメッセージに含めるデータを暗号化する。このため、中継サーバ(31)が端末から受信したデータを復号化したり再暗号化したりしなくても端末間の通信のセキュリティが確保され、従来方式と比べて中継サーバ(31)の負荷を低く抑えることができ、収容可能端末数を従来方式に比べて向上させられる
又、本発明では、暗号化セッションを構築するための暗号化セッション構築メッセージの送受信は、クライアント端末(11、21)と中継サーバ(31)との間で行う。このため、レイヤ5以上の上位レイヤのデータまで吟味してパケット転送のフィルタリングを行う高機能ファイアウォールがプライベートネットワークに設置されていたとしても、そのようなプライベートネットワーク上の端末に対して中継サーバ(31)を介して他のプライベートネットワークの端末から通信を行うことが可能となる。
又、データ通信用メッセージ作成部(115)は、データ通信用メッセージ(104)の宛先である他のクライアント端末(11、21)に割り当てられた端末IDを、宛先端末IDとして非暗号化データフィールド(108)に、中継サーバ(31)が読み取り可能な形式で挿入してデータ通信メッセージを作成することが好ましい。この場合、中継サーバ(31)の暗号化セッション構築部(311)は、複数のクライアント端末(11、21)のそれぞれから通知された端末IDと暗号化セッション利用コネクションとの対応関係をデータ通信用メッセージ転送部(312)に通知することが好ましい。又、中継サーバ(31)のデータ通信用メッセージ転送部(312)は、この対応関係に従い、データ通信用メッセージ(104)の非暗号化データフィールド(108)に含まれる宛先端末IDと同じ端末IDに対応する暗号化セッション利用コネクションを、データ通信用メッセージ(104)の転送に利用することが好ましい。
このように、データ通信用メッセージ(104)の宛先を示す宛先端末IDが非暗号化データフィールド(108)に中継サーバ(31)が読み取れる形で記載される。このため、中継サーバ(31)において暗号化データフィールド(107)全体を復号化する必要がなく、転送先を特定する中継サーバ(31)の処理負荷を軽減することができる。又、宛先端末IDによって転送先を判断するため、クライアント端末(11、21)は、中継サーバ(31)との間の単一の暗号化セッション利用コネクションを利用して任意のクライアント端末(11、21)宛と通信を行うことができる。このため、クライアント端末(11、21)、中継サーバ(31)双方で構築する暗号化セッション利用コネクションの数が従来方式と比較して格段に少なくて済む。
本発明によれば、秘匿性の高い複数のプライベートネットワーク間の通信を中継する中継サーバの処理負荷を低減することができる。
又、高機能ファイアウォールが設置されたプライベートネットワークを含む複数のプライベートネットワーク間における通信を中継する中継サーバの処理負荷を軽減することにある。
更に、高機能ファイアウォールが設置されたプライベートネットワークを含む複数のプライベートネットワーク間における通信を中継する中継サーバの収容可能端末数を増大することができる
以下、添付図面を参照して、本発明による通信システム1の実施の形態を説明する。図面において同一、又は類似の参照符号は、同一、類似、又は等価な構成要素を示している。以下では、互いに異なるプライベートネットワークに接続されたクライアント端末間の通信を、グローバルネットワーク内の中継サーバが中継する通信システムを一例に実施の形を説明する。
1.第1の実施の形態
図1から図9を参照して、本発明による通信システム1の第1の実施の形態を説明する。
(通信システム1の構成)
図1は、実施の形態における通信システム1の構成を示す図である。図1を参照して、通信システム1は、ファイアウォール12、22の設置されたプライベートネットワーク10、20に接続しているクライアント端末11、21と、グローバルネットワーク30に接続している中継サーバ31を具備する。
クライアント端末11、21は、それぞれ異なるプライベートネットワーク10、20に接続し、中継サーバ31を介してデータの送受信を行う通信端末(例示:コンピュータ装置)である。クライアント端末11、21は、それぞれ中継サーバ31との間に暗号化セッションを構築し、暗号化セッションに基づくコネクションを利用して後述するデータ通信用メッセージ104を送受信する。中継サーバ31は、クライアント端末11、21から送信されるデータ通信用メッセージ104の中継処理を行う。ファイアウォール12、22はそれぞれ、プライベートネットワーク10、20からグローバルネットワーク30に対して構築が要求された暗号化セッションを利用する双方向の通信を許可するように設定されている。又、クライアント端末11、21はデータ通信用メッセージ104の送受信を実行する前に、互いに共通の共有鍵(以下、クライアント共有鍵101と称す)を交換している。クライアント端末11、21は、データ通信用メッセージ104にクライアント共有鍵101で暗号化等を施したデータを含めて送受信する。
ここで、暗号化セッションとはセキュリティが確保された仮想的な通信路を指す。暗号化セッションを構築しようとする端末同士(例えばクライアント端末11と中継サーバ31)は、暗号化セッション構築のためのメッセージ(以下、暗号化セッション構築メッセージ100と呼ぶ)を送受信する。暗号化セッション構築メッセージ100の送受信によって、暗号化セッションヘッダ203に含める情報(以下、暗号化セッションヘッダ情報102と称す)が端末同士で交換されるとともに端末間にコネクションが構築される。
暗号化セッションヘッダ203は、暗号化セッションヘッダ情報102として、プロトコルのバージョン番号や、暗号化やMAC(Message Authentication Code)の計算(以下MAC計算と称す)に利用するプロトコル、メッセージの種別(メッセージが暗号化セッション構築メッセージ100なのか、データ通信用メッセージ104なのか)などの情報を含む。尚、暗号化セッションヘッダ203にどのような暗号化セッションヘッダ情報102が含まれるかは暗号化セッションを提供する技術によって異なる。
コネクションとは2つの端末間の通信路のことである。具体的には、コネクションは、端末(クライアント端末11、21や中継サーバ31)のIPアドレスやプロトコル番号、トランスポートプロトコルの種別(TCPやUDP(User Datagram Protocol))やトランスポートプロトコルで使用するポート番号などの情報によって識別される。以下、暗号化セッション構築メッセージ100の送受信により構築されるコネクションを特に暗号化セッション利用コネクションと呼ぶ。本実施の形態では、クライアント端末11と中継サーバ31との間に暗号化セッション利用コネクション13が構築され、クライアント端末21と中継サーバ31との間に暗号化セッション利用コネクション23が構築されるものとする。尚、暗号化セッション利用コネクション13、23がどのような情報で識別可能かは暗号化セッションを提供する技術によって異なる。又、一般的には暗号化セッション構築メッセージ100の送受信に利用するコネクションと暗号化セッション利用コネクションは同一であるが、異なる場合もある。
暗号化セッションを提供する技術としてはSSLやIPSECなどが挙げられる。又、HTTPやSIP(Session Initiation Protocol)など特定のアプリケーションレベルプロトコルにおいてSSLを利用するHTTPSやSIPSも暗号化セッションを提供する技術として挙げられる。
SSLの場合、暗号化セッションヘッダ203としてはSSL Record Headerが利用される。SSL Record HeaderにはContent TypeフィールドやLengthフィールド、SSL Versionフィールドが含まれ、Content Typeフィールドにメッセージ種別が指定される。暗号化セッション構築メッセージ100のContent Typeフィールドには例えばHandshakeやChange Cipher Specなどが指定される。又、データ通信用メッセージ104のContent Typeフィールドには、例えばApplication Dataが指定される。SSLの場合、データ通信用メッセージ104の暗号化データフィールド107は、SSL Record Headerよりも内側の部分である。又、SSLの場合はコネクションとしてTCPコネクションが利用される。この場合、コネクションが構築される端末(ここでは、クライアント端末11、21と中継サーバ31)のIPアドレスとTCPのポート番号で暗号化セッション利用コネクション13、23を識別することができる。
又、IPSEC(IP security protocol)の場合、暗号化セッションヘッダ203としてISAKMP(Internet Security Association & Key Management Protocol)ヘッダやAH(Authentication Header)やESP(encapsulating Security Protocol)ヘッダなど様々なヘッダが利用される。SSLとは異なりメッセージ種別によって付与される暗号化セッションヘッダ203の種類が異なる。又、IPSECの場合、データ通信用メッセージ104の暗号化データフィールド107は、シーケンス番号フィールド(IV(Initial Vector)フィールドを利用する場合はIVフィールド)と、ICV(Integrity Check Value)フィールドで挟まれた部分である。又、IPSECの場合は暗号化セッション利用コネクション13、23のそれぞれをネクションが構築される端末(ここでは、クライアント端末11、21と中継サーバ31)のIPアドレスとプロトコル番号によって識別することができる。
暗号化セッションヘッダ情報102の交換及び暗号化セッション利用コネクション11、12の構築が終わると、クライアント端末(例えばクライアント端末11)は、通信相手のクライアント端末(例えばクライアント端末21)に届けたいデータを送信するためのメッセージ(データ通信用メッセージ104)を作成する。データ通信用メッセージ104は暗号化されたデータを入れるフィールド(以下、暗号化データフィールド107と称す)と暗号化されていないデータを入れるフィールド(以下、非暗号化データフィールド108と称す)に分けられる。データ通信用メッセージ104のうち、どの部分が暗号化データフィールド107で、どの部分が非暗号化データフィールド108であるかは、暗号化セッションを提供する技術によって規定されている。クライアント端末11、12は通信相手の端末に届けたいデータをクライアント共有鍵101によって暗号化やMAC計算行い、これをクライアント暗号化データ202として暗号化データフィールド107に挿入するとともに、非暗号化データフィールド108に暗号化セッションヘッダ203を挿入して、データ通信用メッセージ104を作成する。尚、暗号化セッションヘッダ203の一部は、暗号化されて暗号化データフィールド107に含まれることもある。
又、クライアント端末11、21は、受信したデータ通信用メッセージ104の暗号化データフィールド107に含まれるクライアント暗号化データ202をクライアント共有鍵104で復号化又は/及びMAC計算して元データを取得する。
ファイアウォール12、22はそれぞれ、クライアント端末11、21と中継サーバ31との間で送受信される暗号化セッション構築メッセージ100を監視する。ファイアウォール12、22は、暗号化セッション構築メッセージ100の送受信が完了したことを確認すると、以降、端末間で送受信されるデータ通信用メッセージ104について、暗号化セッション利用コネクション13、23上で送受信されているかと、非暗号化データフィールド107が規定のフォーマットに従っているかを確認する。これらの確認においてエラーとなるデータ通信用メッセージ104はファイアウォール12、22によって遮断される。又、暗号化セッション構築メッセージ100の送受信は、プライベートネットワーク10、20からグローバルネットワーク30に対して開始された場合のみが許可され、そうでない場合は、ファイアウォール12、22によって遮断される。
(クライアント端末の構成)
以下、図2を参照して、本発明によるクライアント端末11の構成の詳細を説明する。クライアント端末11、12は同様の構成であるため、以下では、クライアント端末11についてその構成を説明する。
クライアント端末11は、暗号化セッション構築部111、共有鍵管理部112、データ暗号化部113、データ復号化部114、データ通信用メッセージ作成部115、データ通信用メッセージ解析部116、データ通信用メッセージ送受信部117、アプリケーション118を具備する。
暗号化セッション構築部111は、中継サーバ31に対して暗号化セッションの構築を要求し、暗号化セッション構築メッセージ100を中継サーバ31との間で送受信する。暗号化セッション構築メッセージ100の送受信は、中継サーバ31を介したクライアント端末同士の通信が始まる前に行われる。又、暗号化セッション構築メッセージ100がファイアウォール12により遮断されないようにするため、暗号化セッション構築メッセージ100の送受信は、必ずクライアント端末(の暗号化セッション構築部111)から開始される。すなわち、図4に示すように、暗号化セッションメッセージsm1(sm1’)、sm4(sm4’)は必ずクライアント端末11、21から中継サーバ31に対して送信される。
暗号化セッション構築部111は、暗号化セッション構築手順で規定された暗号化セッション構築メッセージ100の送受信を行う。これにより、中継サーバ31との間において、暗号化セッションヘッダ情報102の交換、及び暗号化セッション利用コネクション13の構築が行われる。ここで、通常の暗号化セッション構築手順では、暗号化セッション構築メッセージを送受信する際、暗号化セッション構築を行う端末間で共通の共有鍵(セッション鍵)が交換されるが、本発明では必須ではない。すなわち、クライアント端末11と中継サーバ31が暗号化セッション構築メッセージ100を送受信する際、クライアント端末11と中継サーバ31との共通のセッション鍵の計算は行わなくても良い。これは、クライアント端末11と中継サーバ31との間で送受信している暗号化セッション構築メッセージ100を経路途中にあるファイアウォール12に見せることによって、暗号化セッション利用コネクション13を利用した双方向通信の遮断を回避することを目的とするためである。但し、後述する理由から、暗号化セッション構築メッセージ100の送受信の際、クライアント端末11と中継サーバ31とで共通のセッション鍵の交換を行っても良い。
暗号化セッション構築部111は、暗号化セッション構築メッセージ100の送受信によって中継サーバ31と交換した暗号化セッションヘッダに含める暗号化セッションヘッダ情報102をデータ通信用メッセージ作成部115に通知するとともに、中継サーバ31と構築した暗号化セッション利用コネクション13に関する情報(以下、コネクション情報103と称す)をデータ通信用メッセージ送受信部117に通知する。
共有鍵管理部112は、中継サーバ31を介して自端末と通信を行うクライアント端末21との間で何らかの手段によって交換した共有鍵(以下、クライアント共有鍵101と称す)を管理する。共有鍵は、暗号化セッションを使用して送信するメッセージの通信内容を暗号化したり、MAC計算を行ったりすることで、盗聴、なりすまし、通信内容の改ざんなどを防止して通信のセキュリティを確保するのに利用される。暗号化とMAC計算には異なる共有鍵が利用されることもある。
データ暗号化部113は、アプリケーション118から渡されたデータを共有鍵管理部112が管理するクライアント共有鍵101によって暗号化したり、渡されたデータのMAC計算を行う。暗号化やMAC計算はいずれか一方のみを行っても良い。又、暗号化はアプリケーション118から渡されたデータの一部に限っても良いし、渡されたデータ全体に対して行っても良い。暗号化やMAC計算を行った後、暗号化されたデータやMACを、クライアント暗号化データ202としてデータ通信用メッセージ作成部115へ渡す。
データ通信用メッセージ作成部115は、データ暗号化部113から渡されたクライアント暗号化データ202と、暗号化セッション構築部111から通知された暗号化セッションヘッダ情報102とを用いてデータ通信用メッセージ104を生成する。詳細には、データ通信用メッセージ作成部115は、クライアント暗号化データ202をデータ通信用メッセージ104の暗号化データフィールド107に挿入する。又、暗号化セッションヘッダ情報102を元にメッセージ種別がデータ通信用メッセージ104であることを示す暗号化セッションヘッダ203を作成し、非暗号化データフィールド108に挿入する。例えば、暗号化セッション構築部111がSSLを利用して暗号化セッション構築メッセージ100の送受信を行った場合は、SSL Record Header222を暗号化セッションヘッダ203として非暗号化データフィールド108に追加し、Content TypeフィールドにApplication Dataを指定する。このようにして作成したデータ通信用メッセージ104はデータ通信用メッセージ送受信部117に渡される。
暗号化データフィールド107に挿入されているデータについてはファイアウォール12にはチェックされることはない。このため、データ通信用メッセージ作成部115は、クライアント暗号化データ202に加えて、任意のデータを暗号化データフィールド107に追加しても良い。例えば、後述するようにクライアント暗号化データ202のデータサイズ値211が含まれたフィールドを追加データとして暗号化データフィールド107に挿入しても良い。尚、暗号化データフィールド107に追加データを挿入する場合は、当該データ通信用メッセージ104を受信した端末において、暗号化データフィールド107のどの部分がクライアント暗号化データ202でどの部分がデータ通信用メッセージ作成部115で追加されたデータであるのかを検出できるようにする必要がある。これらを実現する方法としては、クライアント暗号化データ202、及び追加データの位置を示すフラグフィールドを暗号化データフィールド107に追加する方法や、クライアント暗号化データ202、及び追加データのデータサイズ値211を暗号化データフィールド107に追加する等の方法がある。
データ通信用メッセージ送受信部117は、データ通信用メッセージ作成部115から渡されたデータ通信用メッセージ104を、中継サーバ31に送信する。この際、データ通信用メッセージ送受信部117は、暗号化セッション構築部111から通知されたコネクション情報103に基づき暗号化セッション利用コネクション13を特定し、このコネクションを使ってデータ通信用メッセージ104を中継サーバ31へ送信する。例えば、暗号化セッション構築メッセージ100の送受信にSSLが利用される場合、暗号化セッション構築部111から通知されたTCPコネクションを利用してデータ通信用メッセージ104を中継サーバ31へ送信する。
又、データ通信用メッセージ送受信部117は、中継サーバ31から暗号化セッション利用コネクション13を利用して送信されたデータ通信用メッセージ104を受信する。データ通信用メッセージ送受信部117は、受信したデータ通信用メッセージ104をデータ通信用メッセージ解析部116に渡す。
データ通信用メッセージ解析部116は、データ通信用メッセージ送受信部117から渡されたデータ通信用メッセージ104の暗号化データフィールド107からクライアント暗号化データ202を抽出する。ここで、抽出されるクライアント暗号化データ202は、共有鍵管理部112が保持するクライアント共有鍵101によって復号化及びMAC計算のいずれか又は両方が可能なデータである。すなわち、通信相手のクライアント端末21によって暗号化データフィールドに挿入されたクライアント暗号化データ202である。データ通信用メッセージ解析部116は、抽出したクライアント暗号化データ202をデータ復号化部114に渡す。例えば、受信したデータ通信用メッセージ104の暗号化データフィールド107に、クライアント暗号化データ202のみが挿入されている場合は、暗号化データフィールド107全体をデータ復号化部114に渡す。
データ復号化部114は、データ通信用メッセージ解析部116から渡されたデータを、共有鍵管理部が管理するクライアント共有鍵101を利用して復号化やMAC計算を行った後、アプリケーション118に渡す。
アプリケーション118は自端末上で稼動するプログラムであって、自端末以外の端末とネットワークを介して通信を行う全てのプログラムを示す。例えば、OS(Operating System)のカーネルで稼動するプログラムもアプリケーション118に含まれる。
従来技術では、クライアント端末と中継サーバとの間で通常の暗号化セッションを利用した場合、データ通信用メッセージの暗号化データフィールドにはクライアント端末と中継サーバの間で交換されたセッション鍵によって暗号化やMAC計算が行われたデータのみが挿入される。しかし、本発明によるクライアント端末11は、直接通信する中継サーバ31ではなく通信相手のクライアント端末21と交換したクライアント共有鍵101によって暗号化やMAC計算が行われたクライアント暗号化データ202が暗号化データフィールド107に挿入される。このため、本発明におけるデータ通信用メッセージ104は、暗号化セッションを提供する各種技術(SSLやIPSEC)で本来規定されたデータ通信用メッセージ104のフォーマットに合致していないことになる。しかし、データ通信用メッセージ104についてファイアウォール12がチェックするのは暗号化セッション利用コネクション13上で送受信されているかと、非暗号化データフィールド108が本来規定されたフォーマットに従っているかのみである。データ通信用メッセージ104は、データ通信用メッセージ送受信部117によって暗号化セッション利用コネクション13を利用して送受信されるとともに、データ通信用メッセージ作成部115によって非暗号化データフィールド108に暗号化セッションヘッダ203が挿入されている。このため、クライアント端末11が送信するデータ通信用メッセージ104は、ファイアウォール12から遮断されることなく中継サーバ31へ到達する。
(中継サーバ31の構成)
次に図2を参照して、中継サーバ31の構成の詳細を説明する。中継サーバ31は、暗号化セッション構築部311とデータ通信用メッセージ転送部312とを備える。
暗号化セッション構築部311は、クライアント端末11、12からの暗号化セッション構築の要求を受けて、クライアント端末11、12との間で暗号化セッション構築メッセージ100の送受信を行う。暗号化セッション構築部311は、少なくとも2つ以上のクライアント端末と暗号化セッション構築メッセージ100の送受信を行う。暗号化セッション構築メッセージ100の送受信によって、暗号化セッション構築部311は、クライアント端末11、12のそれぞれと、暗号化セッションヘッダ情報102の交換を行う。暗号化セッション構築部311は、クライアント端末11、12のそれぞれと交換した暗号化セッションヘッダ情報102と、それぞれと構築した暗号化セッション利用コネクション13、23に関するコネクション情報103をデータ通信メッセージ転送部312に通知する。
データ通信用メッセージ転送部312は、暗号化セッション構築部311から通知されたコネクション情報103に基づきクライアント端末毎に構築された暗号化セッション利用コネクションを特定する。又、データ通信用メッセージ転送部212は、受信したデータ通信用メッセージ104を、宛先のクライアント端末に転送する。例えば、データ通信用メッセージ転送部212は、通知されたコネクション情報103に基づき、データ通信用メッセージ104の受信に利用した暗号化セッション利用コネクションとは異なる暗号化セッション利用コネクションに対して当該データ通信用メッセージ104を転送する。
ここでデータ通信用メッセージ転送部312は、転送されたデータ通信用メッセージ104の暗号化データフィールド107のうち、少なくともクライアント共有鍵101によって暗号化やMAC計算されたクライアント暗号化データ202に対しては復号化したりMAC計算を行わない。又、データ通信用メッセージ転送部312は、転送先のクライアント端末11、12に対応する暗号化セッションヘッダ情報102に基づいて、転送するデータ通信用メッセージ104の非暗号化データフィールド108に含まれる暗号化セッションヘッダ203の内容を変更する。但し、受信したデータ通信用メッセージ104に付加された暗号化セッションヘッダ203の内容と、転送先のクライアント端末に対応すると暗号化セッションヘッダ情報102が同じ場合、暗号化セッションヘッダ203の付け替えは行わなくても良い。
従来技術において、端末同士(例えばクライアント端末と中継サーバ)が暗号化セッションを利用して通信を行う場合、一方の端末は、他方の端末から受信したデータ通信用メッセージの暗号化データフィールド107を、暗号化セッション構築時に交換したセッション鍵を使って復号化やMAC計算を行う。これに対して本発明では、中継サーバ31は、クライアント端末11、21から受信したデータ通信用メッセージ104の暗号化データフィールド107のうち、少なくともクライアント暗号化データ202に対する復号化やMAC計算を行わない。
又、本発明では送信元のクライアント端末と転送先のクライアント端末が交換したクライアント共有鍵101によって暗号化やMAC計算が行われたクライアント暗号化データ202が暗号化データフィールド107に挿入される。このため、本発明におけるデータ通信用メッセージ104は、暗号化セッションを提供する各種技術(SSLやIPSEC)で本来規定されたデータ通信用メッセージ104のフォーマットに合致していないことになる。しかし、前述のようにデータ通信用メッセージ104についてファイアウォール12、22がチェックするのは、端末間で事前に構築された暗号化セッション利用コネクション13、23上で送受信されているかと、非暗号化データフィールド108が本来規定されたフォーマットに従っているかのみである。データ通信用メッセージ転送部312によって、データ通信用メッセージ104は、転送先のクライアント端末との間で構築された暗号化セッション利用コネクション上に送信される。又、非暗号化データフィールド108には、転送先のクライアント端末と交換した暗号化セッションヘッダ情報102に基づく暗号化セッションヘッダが挿入される。このため、非暗号化データフィールド108は本来規定されたデータ通信用メッセージ104の規定に合致する。従って、データ通信用メッセージ104は、ファイアウォール12、22から遮断されることなく中継サーバ31から転送先のクライアント端末へ到達する。
(通信システム1の動作)
図3から図9を参照して、本発明による通信システム1におけるデータ転送動作の詳細を説明する。以下では、クライアント端末11からクライアント端末21に対してデータ通信メッセージ104が送信されることを一例に、通信システム1の動作を説明する。
図3は、通信システム1におけるクライアント端末間のデータの転送動作を示すシーケンス図である。図3を参照して、クライアント端末11と、クライアント端末21は事前に、何らかの方法でクライアント共有鍵101を交換する(ステップS1)。クライアント共有鍵101の交換方法は、例えば、フロッピー(登録商標)ディスクやUSBメモリなどの媒体に記録されたクライアント共有鍵101を、手渡しや郵送など物理的な媒体を使用して交換しても良いし、電子メールにクライアント共有鍵101を添付して交換しても良い。更には、クライアント共有鍵101を保管する共有鍵保管サーバ(図示せず)を別途設けておき、そのサーバに対してアクセスすることでクライアント共有鍵101を取得する方法でも良い。但し、この場合、共有鍵保管サーバはパスワードによるアクセス制限などによって、クライアント共有鍵101が認証されていないユーザに配布されることを防ぐ必要がある。
次に、クライアント端末11、21はそれぞれ、中継サーバ31との間で暗号化セッション構築メッセージ100を送受信し、暗号化セッション利用コネクション13、23を構築する(ステップS2)。暗号化セッション構築メッセージ100の送受信は、必ずクライアント端末(の暗号化セッション構築部111)から開始される。すなわち、図4に示すように、暗号化セッションメッセージsm1(sm1’)、sm4(sm4’)は必ずクライアント端末11、21から中継サーバ31に対して送信される。暗号化セッション構築メッセージ100の送受信によって、クライアント端末11、21は、中継サーバ31と個別の暗号化セッションヘッダ情報102を交換する。又、クライアント端末11及び中継サーバ31は、構築した暗号化セッション利用コネクション13に関するコネクション情報103を取得する。同様に、クライアント端末21及び中継サーバ31は、構築した暗号化セッション利用コネクション23に関するコネクション情報103を取得する。
ステップS2において、クライアント端末11、21と中継サーバ31の間で暗号化セッション構築メッセージ100の送受信が完了すると、ファイアウォール12、22からはクライアント端末11、21と中継サーバ31の間で暗号化セッションの構築が完了したと見なされる。これ以降、ファイアウォール12、22のそれぞれは、暗号化セッション利用コネクション13、23上を通るデータ通信用メッセージ104を利用した双方向の通信を許可するようになる。
アプリケーション118から渡されたデータをクライアント端末21に送信するクライアント端末11は、このデータを暗号化してデータ通信用メッセージ104を作成する(ステップS3)。ここでは、クライアント端末11は、送信したいデータをクライアント共有鍵101で暗号化し、暗号化データフィールド107に挿入するとともに、ステップS2で交換した暗号化セッションヘッダ情報102に基づく暗号化セッションヘッダ203を非暗号化データフィールド108に挿入してデータ通信用メッセージ104を作成する。
クライアント端末11は、作成したデータ通信用メッセージ104を暗号化セッション利用コネクション13を介してデータ通信用メッセージ104を中継サーバ31に送信する(ステップS4)。
中継サーバ31は、転送先のクライアント端末21から通知された暗号化セッションヘッダ情報102に基づき、クライアント端末11から受信したデータ通信用メッセージ104の暗号化セッションヘッダ203を付け替える(ステップS5)。ここでは、データ通信用メッセージ104の非暗号化データフィールド108に挿入された暗号化セッションヘッダ203が、転送先の暗号化セッションヘッダ情報102の内容に書き換えられる。但し、受信したデータ通信用メッセージ104に付加された暗号化セッションヘッダ203と転送先のクライアント端末21から取得した暗号化セッションヘッダ情報102を含む暗号化セッションヘッダ203の内容が同一であれば付け替えは行われなくても良い。又、データ中継サーバ31は、受信したデータ通信用メッセージ104の暗号化データフィールド107のうち少なくともクライアント共有鍵101によって暗号化やMAC計算されたクライアント暗号化データ202に対しては復号化したりMAC計算を行わない。
中継サーバ31は、暗号化セッションヘッダ203を付け替えたデータ通信用メッセージ104をクライアント端末21に送信する(ステップS6)。この際、中継サーバ31は、転送先のクライアント端末21に対応するコネクション情報103に基づいて暗号化セッション利用コネクション21を特定し、このコネクションを利用してデータ通信用メッセージ104をクライアント端末21送信する。
クライアント端末21は、暗号化セッション利用コネクション23を介して、中継サーバ31からのデータ通信用メッセージを受信する。クライアント端末21は、受信したデータ通信用メッセージ104の暗号化データフィールド107からクライアント暗号化データ202を抽出し、ステップS1においてクライアント端末11と交換したクライアント共有鍵101によって復号化及びMAC計算のいずれか又は両方を実行する(ステップS7)。ここで復号化されたデータ、又は計算されたMACはクライアント端末21のアプリケーション118に渡される。
以上の動作により、ファイアウォールが設置された異なるプライベートネットワークに接続した2つのクライアント端末の間で、中継サーバを介した双方向の通信が可能になる。
次に、図4を参照して、ステップ2における暗号化セッション利用コネクション13、23の構築動作の一例を説明する。図4は、クライアント端末11、21の暗号化セッション構築部111がSSLによって暗号化セッション構築メッセージ100の送受信を行う際のメッセージシーケンスである。
SSLでは暗号化セッション構築メッセージの送受信にTCPコネクションを利用する。TCPコネクションはコネクション構築処理が必要であるため、暗号化セッション構築部は暗号化セッション構築を要求するメッセージを、送信する前にTCPコネクション構築処理を行う。詳細には、暗号化セッション構築部111は、図4に示す暗号化セッション構築メッセージ100(sm1〜sm3(sm1’〜sm3’))によって、クライアント端末11(21)と中継サーバ31との間にTCPコネクションを構築する。すなわち、クライアント端末11(21)から中継サーバ31への接続ポート通知(SYN):sm1(sm1’)、中継サーバ31からクライアント端末11(21)への通知応答(SYN ACT):sm2(sm2’)、クライアント端末11(21)から中継サーバ31への応答(ACT):sm3(sm3’)によってTCPコネクションが構築される。
次にクライアント端末11(21)は、当該TCPコネクションを利用し、SSLで規定された手順に基づいて中継サーバ31と暗号化セッション構築メッセージ100(sm4〜sm7(sm4’〜sm7’))の送受信が行われる。尚、暗号化セッション構築メッセージ100の送受信に利用するコネクション(ここではTCPコネクション)が必要か否かは、暗号化セッション構築メッセージ100の送受信をどのような技術を用いて行うかで異なる。
詳細には、先ずクライアント端末11(12)の暗号化セッション構築部111は、中継サーバ31に対して暗号化セッション構築を要求する暗号化セッション構築メッセージsm4を送信する。例えば暗号化セッション構築メッセージにSSLを利用する場合、Client Helloメッセージが暗号化セッション構築を要求する暗号化セッション構築メッセージsm4(sm4’)に該当する。又、これにより、中継サーバ31は、コネクションを構築する対象となるクライアント端末11(12)を識別することができる。
クライアント端末11(21)から暗号化セッション構築の要求メッセージsm4(sm4’)が送信された後、中継サーバ31とクライアント端末11(21)との間で暗号化セッション構築メッセージ100(sm5〜sm7(sm5’〜sm7’))の送受信が行われる。ここでは、コネクション対象となるクライアント端末の認証(Server Hello/Certificate/Server Hello Done:sm5(sm5’)、クライアント端末11(21)と中継サーバ31との間におけるセッション鍵の交換(Client Key Exchange):sm6(sm6’)、新たに構築する暗号化セッション利用コネクション13(23)の設定(Change Cipher Spec/Finished):sm6(sm6’)及び(Change Cipher Spec/Finished):sm7(sm7’)が行われる。これにより、クライアント端末11、21のそれぞれと中継サーバ31の間において暗号化セッション利用コネクション13、23が構築される。又、暗号化セッション利用コネクション13、23に関するコネクション情報103と暗号化セッションヘッダ情報102が、クライアント端末11、21のそれぞれと中継サーバ31との間で交換される。尚、クライアント端末11、21と中継サーバ31との間におけるセッション鍵の交換は行われなくても構わない。但し、後述するように、データ通信用メッセージ104内に中継サーバ31のみによって読み取り可能な情報を含ませたい場合は、上述のセッション鍵の交換が行われる。
図5は、ステップS3におけるデータ通信用メッセージ104の作成動作を示すフロー図である。図5を参照して、データ通信用メッセージ104の作成動作の詳細を説明する。
クライアント端末11のデータ暗号化部113は、暗号化セッション構築メッセージ104の送受信が完了すると、アプリケーション118から渡されたデータを、共有鍵管理部112が管理するクライアント共有鍵101によって暗号化、又は/及び渡されたデータのMAC計算を行いクライアント暗号化データ202を作成する(ステップS101)。
クライアント暗号化部113は、作成したクライアント暗号化データ202をデータ通信用メッセージ作成部115に渡す。データ通信用メッセージ作成部115は、図6に示すデータ通信用メッセージ104を作成する。図6を参照して、データ通信用メッセージ104は、暗号化データフィールド107と非暗号化データフィールド108とから構成される。クライアント暗号化データ202は、クライアント暗号化データ202を暗号化データフィールド107に挿入する(ステップS102)。又、データ通信用メッセージ作成部115は、暗号化セッション構築部111から通知された暗号化セッションヘッダ情報102に基づき、メッセージ種別がデータ通信用メッセージであることを示す暗号化セッションヘッダ203を作成し、非暗号化データフィールド108に挿入する(ステップS3)。
ここで、暗号化データフィールド107には任意のデータが挿入されても良い。このため、データ通信用メッセージ作成部115は、中継サーバ31によって読み取り可能なデータ(以下、中継サーバ読み取り可能データ201と称す)を暗号化データフィールド107に挿入する(ステップS104)。ここで挿入される中継サーバ読み取り可能データ201は、平文データ、中継サーバ31との間で交換されたセッション鍵によって暗号化されたデータ、データのMACのいずれか、又はこれらの組み合わせである。
以上のように、データ通信用メッセージ作成部115は、データ通信用メッセージ104を作成する。尚、ステップS102〜S104の順番はこの限りではない。
前述のように、ファイアウォール12、22がデータ通信用メッセージ104に関してチェックするのは、暗号化セッション利用コネクション13、23上で送受信されているかと、非暗号化データフィールド108が本来規定されたフォーマットに従っているかのみである。このため、暗号化データフィールド107については任意のデータを含めることができる。
例えばクライアント端末が通信相手のクライアント端末に対して送信するデータをレイヤ2ヘッダまで含むパケットの形で端末内部でダンプし、その内容を暗号化データフィールドに含めることができる。レイヤ2ヘッダまで含むパケットを端末同士で送受信することで、異なるプライベートネットワークに接続しているクライアント端末同士が、あたかも同一のLANに接続しているかのように通信することが可能となる。
SSLを利用して暗号化セッション構築メッセージの送受信を行った場合に、レイヤ2ヘッダまで含むパケットを暗号化データフィールドに含めたデータ通信用メッセージ104の構成例を図7に示す。SSLを利用した場合、暗号化セッションヘッダ203には、SSLレコードヘッダ222が挿入される。
図7を参照して、データ暗号化部113によってレイヤ2ヘッダまで含むパケットがクライアント共有鍵101で暗号化され、クライアント暗号化データ202として暗号化データフィールド107に挿入される。ここで暗号化されるパケットは、例えばEtherヘッダ212、IPヘッダ213、TCPヘッダ214、HTTPヘッダ215、ペイロード216を含む。又、データ通信用メッセージ作成部115は、このパケットのサイズ値(以下、データサイズ値211と称す)を、中継サーバ読み取り可能データ201として暗号化データフィールド107に含める。これにより、中継サーバ31側でパケット毎の転送処理を行うことが可能となる。
中継サーバ31のデータ通信用メッセージ転送部312は、データサイズ値211を解析することでパケットが暗号化されている状態であっても、どこからどこまでが1つのパケットであるか判別することができる。このため、中継サーバ31は、通信相手となるクライアント端末に対して1パケット毎に転送することが可能となる。従って、受信側のクライアント端末は、パケット再構築処理を行う必要がなくなる。
具体的に、データ通信用メッセージ転送部312は、受信したデータ通信用メッセージ104の暗号化データフィールド104に挿入されたデータサイズ値201を読みとり、データサイズ値201で指定された長さのデータ(ここでは、クライアント暗号化データ202)を暗号化データフィールド107から読み取る。読み取ったデータを新たなデータ通信用メッセージ104の暗号化データフィールド107に入れて、通信相手となるクライアント端末へ転送する。
次に、図8及び図9を参照して、クライアント共有鍵101の交換動作の一例を説明する。上述のステップS1〜S7の動作では、暗号化セッション利用コネクション13、23が構築される前にクライアント共有鍵101の交換が行われた。しかしこれに限らず、暗号化セッション利用コネクション13、23を利用してクライアント端末間でクライアント共有鍵101の交換が行われても良い。この際、既存の標準的な仕組み、例えばSSLやIPSecのIKE(Internet Key exchange)などを利用してクライアント端末同士で直接クライアント共有鍵101の交換を行っても良い。図8は、SSLを利用したクライアント共有鍵101の交換動作を示すメッセージシーケンスである。
図8に示す例では、クライアント端末11、21と中継サーバ31は、ステップS2と同様にSSLによる暗号化セッション構築メッセージ100の送受信を事前に行っているものとする。ここで、クライアント端末11、21は、図9に示すようなデータ通信用メッセージ104を暗号化セッション利用コネクション13、23を介して送受信し、クライアント共有鍵101を交換する。
以下では、クライアント端末11から送信されるデータ通信用メッセージ104について具体的に説明する。先ずクライアント端末11の共有鍵管理部112は、通信相手となるクライアント端末21宛ての暗号化セッション構築メッセージ100を生成してデータ通信用メッセージ作成部115に渡す。データ通信用メッセージ作成部115は、渡された暗号化セッション構築メッセージ100を中継サーバ読み取り可能データ201として暗号化データフィールド107に挿入し、暗号化セッションヘッダ203を非暗号化データフィールド108に挿入してデータ通信用メッセージ104を作成する。ここで挿入される暗号化セッション構築メッセージ100は、中継サーバ31が読み取り可能なSSLメッセージ223及びSSLレコードヘッダ222’が含まれる。このようにして作成されたデータ通信用メッセージ104をデータ通信用メッセージ送受信部117が暗号化セッション利用コネクションを利用して中継サーバ31に送信する。以上の動作は、クライアント端末21でも同じである。
尚、データ通信用メッセージ作成部115は、渡された暗号化セッション構築メッセージ100を平文のまま挿入しても良いし、中継サーバ31と何らかの形で交換した共有鍵(例えばセッション鍵)を利用して暗号化セッション構築メッセージ100に対し暗号化や、MAC計算を施した後に挿入しても良い。暗号化又は/及びMAC計算された暗号化セッション構築メッセージ100を挿入した場合、データ通信用メッセージ作成部115は、暗号化セッション構築メッセージ100が暗号化されていることを示すフラグデータもデータ通信用メッセージ104の暗号化データフィールド107に挿入することが好ましい。これにより、中継サーバ31がデータ通信用メッセージ104を受信した際に、復号化する必要があることを知ることができる。又、上述のように、暗号化データフィールド107に挿入したパケットの大きさを中継サーバ31が検出できるように、データサイズ値211が中継サーバ読み取り可能データ201として暗号化データフィールド107に挿入されていることが好ましい。
上記のように作成されたデータ通信用メッセージ104を利用してクライアント端末11、12間で送受信することで、クライアント共有鍵101を交換することができる。ここで、SSLメッセージ223に含める内容は、クライアント共有鍵101を共有するクライアント端末の識別及び認証(Client Hello:cm1、Server Hello/Certificate/Server Hello Done:cm2、クライアント共有鍵の交換(Client Key Exchange):cm3、使用する暗号化セッション利用コネクション13、23に関する情報の交換(Change Cipher Spec/Finished):cm3、cm4である。
中継サーバ31のデータ通信用メッセージ転送部312は、受信したデータ通信用メッセージをもう一方のクライアント端末へ転送する。尚、SSLメッセージ223が、中継サーバ31が復号化可能な形で暗号化されたりMAC計算されたりしている場合は、復号化及び/又はMAC計算後、平文のままか、再度転送先のクライアント端末との間で何らかの形で交換した共有鍵(例えばセッション鍵)によって暗号化した後、転送先のクライアント端末へ転送する。
上述のデータ通信用メッセージ104を受信したクライアント端末11、21のデータ通信用メッセージ解析部116は、暗号化セッション構築メッセージ(SSLメッセージ223)を抽出して共有鍵管理部112に渡す。
以上のような手順により、既存の標準的な仕組み、例えばSSLやIPSecのIKEなどを利用してクライアント端末同士で直接クライアント共有鍵101の交換を行うことができる。
次に、中継サーバ31及びクライアント端末11、21の認証について説明する。クライアント端末11、21や中継サーバ31の成りすましなどが発生した場合、クライアント端末同士の認証についてはクライアント共有鍵101による送受信データの暗号化及び復号化やMAC計算を行うことにより実現可能である。しかし、より万全なセキュリティを確保するためにはクライアント端末11、21から中継サーバ31を認証したり、中継サーバ31からクライアント端末11、21を認証する必要がある。中継サーバ31におけるクライアント端末11、21の認証、又はクライアント端末11、21における中継サーバ31の認証は、双方とも、クライアント端末11、21のそれぞれと中継サーバ31との間で交換する共有鍵(セッション鍵)によって計算された、データ通信用メッセージ104のMACによって行われることが好ましい。この際、クライアント端末11、21のそれぞれと中継サーバ31との間においてセッション鍵の交換が必要となる。
以下、通信システム1におけるクライアント端末11、21、及び中継サーバ31の認証動作の詳細を説明する。認証に先んじてクライアント端末11、21のそれぞれと中継サーバ31は、それぞれの間で共通のセッション鍵を交換しているものとする。例えば、上述のステップS2における暗号化セッション構築用メッセージ100の送受信により、このセッション鍵の交換が行われる。
クライアント端末11、21のデータ通信用メッセージ作成部115は、上述のステップS3において作成したデータ通信用メッセージ104全体、あるいは、作成したデータ通信用メッセージ104のうち、事前に中継サーバ31と合意した一部分に対して、中継サーバ31と交換したセッション鍵によってMAC計算を行い、MACを暗号化データフィールド107に挿入する。
上述のステップS5において、中継サーバ31のデータ通信用メッセージ転送部312は、受信したデータ通信用メッセージ104全体又は一部に対し上述のセッション鍵でMAC計算する。又、データ通信用メッセージ104に含まれるMACと、自身で計算したMACとを比較し、両者が一致するか否かを確認する。これにより中継サーバ31は、受信したデータ通信用メッセージ104が正規のクライアント端末から送信されたものであることを確認することができ、クライアント端末のなりますましを防ぐことができる。クライアント端末11、21が中継サーバ31の認証を行う場合も、中継サーバ31のデータ通信用メッセージ転送部312が計算したMACをクライアント端末11、21のデータ通信用メッセージ解析部116が確認することで、中継サーバ31のなりすましを防ぐことができる。
本発明では、クライアント端末11、21間で共通のクライアント共有鍵101によって暗号化されたデータ(クライアント暗号化データ202)が、データ通信用メッセージ104の暗号化データフィールド107に挿入されている。このため、中継サーバ31は、データ通信用メッセージ104を中継する際、暗号化データフィールド107内のクライアント暗号化データ202を復号化や再暗号化しなくても、クライアント端末間の通信セキュリティを確保することができる。すなわち、クライアント端末11、21間で送受信されるデータの秘匿性を保持しつつ、中継サーバ31における処理負荷を軽減することができる。
又、本発明では、暗号化セッション構築メッセージ100の送受信は、クライアント端末11、21のそれぞれと中継サーバ31との間で行われ、暗号化セッションの構築を開始するメッセージ(sm1(sm1’)、sm4(sm4’))は必ずクライアント端末から中継サーバに対して送信される。更に、データ通信用メッセージ104の非暗号化データフィールド108には、クライアント端末11、21のそれぞれと中継サーバ31とが交換した暗号化セッションヘッダ情報102に基づく暗号化セッションヘッダ203が挿入されている。このため、ファイアウォール12、22が、レイヤ5以上の上位レイヤのデータまで吟味してパケット転送のフィルタリングを行っても、クライアント端末11、21は中継サーバ31を介して通信することができる。すなわち、本発明によれば高機能のファイアウォールが設置された異なるプライベートネットワーク間の通信が可能となる。
2.第2の実施の形態
図10を参照して、本発明による通信システム1の第2の実施の形態を説明する。本実施の形態は中継サーバを介して1つの端末が複数の端末と通信を行えるようにすることを目的としている。
第2の実施の形態における通信システム1は、図1に示す第1の実施の形態における通信システム1のクライアント端末11、21及び中継サーバ31に替えてクライアント端末11’、21’及び中継サーバ31’を備え、その他の構成は、第1の実施の形態と同じである。第2の実施の形態におけるクライアント端末11’、21’は、図示しない複数のクライアント端末(他のプライベートネットワークに接続されたクライアント端末)と中継サーバ31’を介して通信する。この際、クライアント端末11’、21’は、複数の通信先のクライアント端末に対応する複数の暗号化セッション利用コネクションを中継サーバ31’との間に構築して通信を行う。ここでクライアント端末11’、21’は通信相手毎に異なる暗号化セッション利用コネクションを中継サーバ31’に対して構築する。中継サーバ31’はクライアント端末11’、21’からのデータ通信用メッセージ104の受信に利用した暗号化セッション利用コネクションを基に、転送先の暗号化セッション利用コネクションを判断する。これにより、中継サーバ31’を介して1つのクライアント端末が複数の端末と通信を行えるようになる。
図10を参照して第2の実施の形態におけるクライアント端末11’、21’の構成及び動作について詳細に説明する。クライアント端末11’及び21’の構成は同様であるので、以下では、クライアント端末11’について構成の詳細を説明する。
第2の実施の形態におけるクライアント端末11’は、第1の実施の形態におけるクライアント端末11の構成に加えて、宛先端末解決部119を備える。又、クライアント端末11’は、第1の実施の形態における暗号化セッション構築部111、データ暗号化部113、データ復号化部114、データ通信用メッセージ送受信部117に替えて、暗号化セッション部121、データ暗号化部123、データ復号化部124、データ通信用メッセージ送受信部127を備える。
暗号化セッション構築部121は、第1の実施の形態における暗号化セッション構築部111の処理に加えて以下の処理を行う。暗号化セッション構築部121は、通信相手となるクライアント端末の数分の異なる暗号化セッション利用コネクションを中継サーバ31’と構築する。尚、一度の暗号化セッション構築メッセージ100の送受信で単一の暗号化セッション利用コネクションに関する情報しか交換できない場合は、通信相手となるクライアント端末の数分、暗号化セッション構築メッセージの送受信を繰り返す。例えば暗号化セッション構築メッセージ100の送受信にSSLを利用する場合は、通信相手となるクライアント端末の数だけTCPコネクションを中継サーバ31’に対して構築し、当該TCPコネクション上で暗号化セッション構築メッセージの送受信100を行う。
又、暗号化セッション構築部121は、どの通信相手に対してどの暗号化セッション利用コネクションを利用するかについて中継サーバ31’とルールを共有しておく。暗号化セッション構築部121は、このようなルールをコネクション対応テーブル106として管理する。コネクション対応テーブル106は、クライアント端末11’と中継サーバ31’との間に構築する暗号化セッション利用コネクションと、これを用いてデータを転送する転送先のクライアント端末(例えばクライアント端末21’)とを対応付けた情報である。暗号化セッション構築部121は、中継サーバ31’との間で暗号化セッション利用コネクションを構築する前、又は暗号化セッション構築メッセージ100を送受信する際に、コネクション対応テーブル106を中継サーバ31’に通知する。これにより、暗号化セッション利用コネクションを利用する前にクライアント端末11’と中継サーバ31’とで上記ルールを共有することができる。例えば、クライアント端末Aがクライアント端末B、クライアント端末Cと通信する場合、クライアント端末Aは、中継サーバ31’に対して2本の暗号化セッション利用コネクションX、Yを構築するものとする。又、クライアント端末Aは、クライアント端末Bとの通信に暗号化セッション利用コネクションXを利用し、クライアント端末Cとの通信に暗号化セッション利用コネクションYはを利用するものとする。この場合クライアント端末Aは、通信先のクライアント端末Bと暗号化セッション利用コネクションXとを対応付けたコネクション対応テーブル106と、通信先のクライアント端末Cと暗号化セッション利用コネクションYとを対応付けたコネクション対応テーブル106とを中継サーバ31’に通知する。
宛先端末解決部119は、アプリケーションから渡されたデータを解析して、当該データの宛先となるクライアント端末のアドレス解決を実行し、その結果を宛先端末情報105としてデータ通信用メッセージ送受信部127及びデータ暗号化部123に通知する。
データ暗号化部123は、第1の実施の形態におけるデータ暗号化部113の処理に加えて以下の処理を行う。データ暗号化部123は、宛先端末情報105に対応するクライアント共有鍵101を共有鍵管理部112から取得し、これを利用してアプリケーション118から渡されたデータの暗号化やMAC計算を行いクライアント暗号化データ202を生成する。
データ通信用メッセージ送受信部127は、第1の実施の形態におけるデータ通信用メッセージ送受信部117の処理に加えて以下の処理を行う。データ通信用メッセージ送受信部127は、データ通信用メッセージ送受信部127はデータ通信用メッセージ作成部115からデータ通信用メッセージを渡されると、宛先端末解決部119から宛先端末情報105を取得するとともに、暗号化セッション構築部121からコネクション対応テーブル106を取得する。データ通信用メッセージ送受信部127は、コネクション対応テーブル106に基づいて、宛先端末情報105に対応する暗号化セッション利用コネクションを選択し、選択した暗号化セッション利用コネクションからデータ通信用メッセージ104を送信する。
又、データ通信用メッセージ送受信部127はデータ通信用メッセージ104を受信すると、コネクション対応テーブル106を参照して、受信に利用した暗号化セッション利用コネクションに対応する送信元クライアント端末を特定し、その情報を送信元端末情報109としてデータ復号化部124に通知する。
データ復号化部124は第1の実施の形態におけるデータ復号化部114の処理に加えて以下の処理を行う。データ復号化部124は、データ通信用メッセージ送受信部127から取得した送信元端末情報109に対応するクライアント共有鍵101を共有鍵管理部112から取得する。そして、データ復号化部124は、取得したクライアント共有鍵101を利用してデータ通信用メッセージ解析部116から渡されたクライアント暗号化データ202の復号化やMAC計算行を行う。
尚、共有鍵管理部112が、通信対象となる全てのクライアント端末に対して共通のクライアント共有鍵101のみを管理している場合、宛先端末情報105は、データ暗号部123に通知されなくても良い。この場合、同様に、送信元端末情報109は、データ復号部124に通知されなくても良い。すなわち、クライアント暗号化データ202の生成、又は復号化に使用されるクライアント共有鍵を区別しなくて良い場合は、上記の宛先端末や送信元端末に関する情報の通知は省略される。
次に、図10を参照して第2の実施の形態における中継サーバ31’の構成及び動作の詳細について説明する。中継サーバ31’は、第1の実施の形態における暗号化セッション構築部311、データ通信用メッセージ転送部312に替えて、暗号化セッション構築部321、データ通信用メッセージ転送部322を備える。
暗号化セッション構築部321は、第1の実施の形態における暗号化セッション構築部311の処理に加えて以下の処理を行う。暗号化セッション構築部321は、暗号化セッション利用コネクションを構築したクライアント端末と、当該クライアント端末がどの暗号化セッション利用コネクションをどの通信相手との通信に利用するかについてルールを共有しておく。例えば、暗号化セッション構築部321は、暗号化セッション利用コネクション13、23の構築前、又は構築する際にクライアント端末11’、21’からコネクション対応テーブル106を取得する。暗号化セッション構築部321が保持するコネクション対応テーブル106には、転送元のクライアント端末と、転送元のクライアント端末との間に構築する暗号化セッション利用コネクションと、転送先のクライアント端末と、転送先のクライアント端末との間に構築する暗号化セッション利用コネクションとが対応付けられている。
例えば、クライアント端末Aがクライアント端末B、クライアント端末Cと通信する場合におけるコネクション対応テーブル106について説明する。中継サーバ31’はクライアント端末Aと2本の暗号化セッション利用コネクションX、Yを構築し、クライアント端末Bと暗号化セッション利用コネクションZ、クライアント端末Cと暗号化セッション利用コネクションWを構築するものとする。又、暗号化セッション利用コネクションXは、クライアント端末Aとクライアント端末Bとの通信に、暗号化セッション利用コネクションYはクライアント端末Aとクライアント端末Cとの通信に、それぞれ利用され、暗号化セッション利用コネクションZは、クライアント端末Bとクライアント端末A、暗号化セッション利用コネクションWはクライアント端末Cとクライアント端末Aの通信にそれぞれ利用されるものとする。この場合、クライアント端末Aは、通信先のクライアント端末Bと、暗号化セッションXとを対応付けたコネクション対応テーブル106と、通信先のクライアント端末Cと、暗号化セッションYとを対応付けたコネクション対応テーブル106を中継サーバ31’に通知する。クライアント端末Bは、通信先のクライアント端末Aと、暗号化セッションZとを対応付けたコネクション対応テーブル106を中継サーバ31’に通知する。クライアント端末Cは、通信先のクライアント端末Aと、暗号化セッションWとを対応付けたコネクション対応テーブル106を中継サーバ31’に通知する。中継サーバ31’は、クライアント端末A及びBから通知されたコネクション対応テーブル106に基づき、クライアント端末Aと、暗号化セッション利用コネクションXと、クライアント端末Bと、暗号化セッション利用コネクションZとを対応付けて、新たなコネクション対応テーブル106として管理する。同様に、中継サーバ31’は、クライアント端末A及びCから通知されたコネクション対応テーブル106に基づきクライアント端末Aと、暗号化セッション利用コネクションYと、クライアント端末Cと、暗号化セッション利用コネクションWとを対応付けて、新たなコネクション対応テーブル106として管理する。これらのコネクション対応テーブル106はデータ通信用メッセージ転送部322に通知される。
データ通信用メッセージ転送部322は、第1の実施の形態におけるデータ通信用メッセージ送受信部312の処理に加えて以下の処理を行う。データ通信用メッセージ転送部322は、クライアント端末11’、21’からデータ通信用メッセージ104を受信した際に、データ通信用メッセージ104の受信に利用した暗号化セッション利用コネクションを判別する。次に、データ通信用メッセージ転送部322は、暗号化セッション構築部321から通知されたコネクション対応テーブル106に基づいて、当該暗号化セッション利用コネクションに対応する転送先の暗号化セッション利用コネクションへ、データ通信用メッセージ104を転送する。先ほどの例の場合、暗号化セッション利用コネクションXから受信したデータ通信メッセージ104(すなわちクライアント端末AからB宛のメッセージ)については、暗号化セッション利用コネクションZへ転送する。又、暗号化セッション利用コネクションYから受信したデータ通信用メッセージ104(すなわちクライアント端末Aからクライアント端末C宛のメッセージ)については、暗号化セッション利用コネクションWへ、それぞれ転送する。
以上の構成により、クライアント端末11’、21’は中継サーバ31’を介して複数のクライアント端末と通信を行えるようになる。又、第1の実施の形態と同様に、クライアント共有鍵101で暗号化したクライアント暗号化データ202を暗号化データフィールド107に挿入したデータ通信用メッセージ104が送受信されるため、中継サーバ31’において復号化や再符号化をする必要がない。すなわち、クライアント端末11’(21’)と複数のクライアント端末との間において秘匿性のあるデータの送受信ができるとともに、中継サーバ31’における処理負荷を軽減することができる。又、高機能のファイアウォールが設置された異なるプライベートネットワーク間の通信ができる。
3.第3の実施の形態
次に、図11から図13を参照して本発明による通信システム1の第3の実施の形態について説明する。 中継サーバを介して1つのクライアント端末が複数のクライアント端末と通信を行う場合、従来技術では、クライアント端末毎に別のコネクションが構築され、これを利用してデータの転送が行われている。本実施の形態における通信システム1では、複数のクライアント端末と中継サーバを介して通信する際、中継サーバとの間に構築した1本の暗号化セッション利用コネクションを利用してデータ(データ通信用メッセージ)の転送ができる。
第3の実施の形態における通信システム1は、図1に示す第1の実施の形態における通信システム1のクライアント端末11、21及び中継サーバ31に替えてクライアントサーバ11”、21”及び中継サーバ31”を備え、その他の構成は、第1の実施の形態と同じである。第3の実施の形態におけるクライアントサーバ11”、21”は、図示しない複数のクライアント端末(他のプライベートネットワークに接続されたクライアント端末)と中継サーバ31”を介して通信する。第3の実施の形態では、クライアント端末11”、21”と中継サーバ31”の間で暗号化セッション構築メッセージ100の送受信が完了した後にクライアント端末11”、21”が中継サーバ31”に対して送信するデータ通信用メッセージ104に宛先クライアント端末を識別する情報(以下、宛先端末ID231と称す)を含める。これにより、クライアント端末11”、21”と中継サーバ31”との間に構築される暗号化セッション利用コネクション13、23が単一の場合であっても、クライアント端末11”、21”が中継サーバ31”を介して図示しない他の複数のクライアント端末と通信できる。
本実施の形態では、同じ中継サーバ31”を利用するクライアント端末にはそれぞれ一意な端末IDが割り当てられており、各クライアント端末は自端末に割り当てられた端末ID(送信元端末ID242)と通信相手となるクライアント端末の端末ID(宛先端末ID231)を通信前に何らかの手段によって取得する。
宛先端末ID231の例を以下に挙げる。以下の例では、データの送信元をクライアント端末11”、データの転送先をクライアント端末21”として説明する。
第1の例としては、通信相手となるクライアント端末21”と中継サーバ31”との間で構築された暗号化セッション利用コネクション23のコネクション情報103(暗号化セッション利用コネクション23がTCPコネクションの場合は、中継サーバ31”における送信元ポート番号と宛先IPアドレス、宛先ポート番号の情報など)をクライアント端末11”が何らかの形で取得し、これを宛先端末ID231として利用する方法がある。
第2の例としては、クライアント端末11”、21”に例えばURI(Universal Resource Indicator)のような何らかの一意なIDが割り当てられており、クライアント端末11”は通信を開始する前に予め通信相手の端末IDを取得しておき、取得した端末IDを宛先端末ID231として指定する方法がある。
通信相手の端末ID(宛先端末ID231)を取得する方法としては、例えば、フロッピー(登録商標)ディスクやUSBメモリなどの媒体に記録された端末IDを手渡しや郵送など物理的な媒体を使用して交換しても良いし、電子メールに端末IDを添付して交換しても良い。さらには、複数の端末IDをディレクトリとして(電話帳のような形態で)管理する端末ID管理サーバを別途設けておき、そのサーバに対してアクセスすることで端末IDを取得する方法も考えられる。
図11を参照して第3の実施の形態におけるクライアント端末11”、21”の構成及び動作について詳細に説明する。クライアント端末11”及び21”の構成は同様であるので、以下では、クライアント端末11”について構成の詳細を説明する。
第3の実施の形態におけるクライアント端末11”は、第1の実施の形態におけるクライアント端末11の構成に加えて、宛先端末解決部129を備える。又、クライアント端末11”は、第1の実施の形態における暗号化セッション構築部111、データ暗号化部113、データ復号化部114、データ通信用メッセージ作成部115、データ通信用メッセージ解析部116に替えて、暗号化セッション部131、データ暗号化部133、データ復号化部134、データ通信用メッセージ作成部135、データ通信用メッセージ解析部136を備える。
暗号化セッション構築部131は、第1の実施の形態における暗号化セッション構築部111の処理に加えて以下の処理を行う。暗号化セッション構築部131は、自端末のクライアント端末の端末ID(送信元端末ID242)を中継サーバ31”へ通知する。これにより中継サーバ31”は暗号化セッション利用コネクションがどのクライアント端末と構築されたものであるか判別できる。送信元端末ID242を中継サーバ31”へ通知する方法としては、例えば、中継サーバ31”との暗号化セッション構築メッセージ100の送受信が完了した後に、データ通信用メッセージ104の暗号化データフィールド107へ中継サーバ読み取り可能データ201として挿入し、これを送信する方法がある。
宛先端末解決部129は、アプリケーション118から渡されたデータを解析して、当該データのアドレス解決を行い、転送先のクライアント端末に対応する宛先端末ID231を取得し、これをデータ通信用メッセージ作成部135及びデータ暗号化部133に通知する。
データ暗号化部133は、第1の実施の形態におけるデータ暗号化部113の処理に加えて以下の処理を行う。データ暗号化部133は、宛先端末ID231に対応するクライアント共有鍵101を共有鍵管理部112から取得し、これを利用してアプリケーション118から渡されたデータの暗号化やMAC計算を行いクライアント暗号化データ202を生成する。
データ通信用メッセージ作成部135は、第1の実施の形態におけるデータ通信用メッセージ作成部135の処理に加えて以下の処理を行う。データ通信用メッセージ作成部135は、データ暗号化部133から渡されたクライアント暗号化データ202を暗号化データフィールド107に挿入するとともに、宛先端末解決部129から渡された宛先端末ID231を中継サーバ読み取り可能データ201として暗号化データフィールド107に挿入する。具体的には、宛先端末ID231は平文のまま挿入しても良いし、中継サーバ31”との間で交換した何らかの共有鍵(例えばセッション鍵)によって暗号化したり、MAC計算を行ったりしてから挿入しても良い。
本実施の形態においてクライアント端末11”が中継サーバ31”に対して送信するデータ通信用メッセージ104の例を図12に示す。ここでは、クライアント端末11”と中継サーバ31”の間でSSLによって構築された暗号化セッション利用コネクション13を利用してデータの転送が行われるものとする。図12に示すように、本実施の形態に係るデータ通信用メッセージ104は、暗号化セッションヘッダ203としてSSLレコードヘッダ222、中継サーバ読み取り可能データ201として、宛先端末ID231、クライアント暗号化データ202として任意データ232が挿入されている。
又、図13に示すように、暗号化データフィールド107には、中継サーバ読み取り可能データ201やクライアント暗号化データ202の他に、更に任意の追加データ204を挿入しても良い。このため、データ通信用メッセージ作成部135は、送信元端末ID242を暗号化データフィールド107に挿入したデータ通信用メッセージ104を作成することができる。この場合、送信元端末ID242は、転送先のクライアント端末21”が読み取り可能な形で挿入されることが好ましい。
データ通信用メッセージ解析部136は第1の実施の形態におけるデータ通信用メッセージ解析部116の処理に加えて以下の処理を行う。データ通信用メッセージ解析部136は、受信したデータ通信用メッセージ104の暗号化データフィールド107から送信元端末ID242を抽出し、データ復号化部134に送信する。
データ復号化部134は、第1の実施の形態におけるデータ通信用メッセージ解析部114の処理に加えて以下の処理を行う。データ復号化部134は、送信元端末ID242に対応するクライアント共有鍵101を共有鍵管理部112から取得し、これを用いてクライアント暗号化データ202の復号化やMAC計算を行う。
このように、送信元のクライアント端末を特定するための送信元端末ID242が暗号化データフィールド107に挿入されているため、クライアント端末11”は、通信相手毎に異なるクライアント共有鍵101によって暗号化されたクライアント暗号化データ202でも復号することができる。
次に、図11を参照して第3の実施の形態における中継サーバ31”の構成及び動作の詳細について説明する。中継サーバ31”は、第1の実施の形態における暗号化セッション構築部311、データ通信用メッセージ転送部312に替えて、暗号化セッション構築部331、データ通信用メッセージ転送部332を備える。
暗号化セッション構築部331は、第1の実施の形態における暗号化セッション構築部311の処理に加えて以下の処理を行う。暗号化セッション構築部331には、クライアント端末11”(21”)から転送先のクライアント端末21”(11”)に対応する送信元端末ID242が通知される。暗号化セッション構築部331は、送信元端末ID242に基づき当該クライアント端末11(21”)と構築した暗号化セッション利用コネクション13(23)のコネクション情報103及び暗号化セッションヘッダ情報102と、送信元端末ID242とを対応付けてデータ通信用メッセージ転送部332に通知する。これにより、送信元クライアント端末11”(21”)と、当該クライアント端末と構築した暗号化セッション利用コネクション13(23)とが対応付けられる。
データ通信用メッセージ転送部332は、第1の実施の形態におけるデータ通信用メッセージ転送部312の処理に加えて以下の処理を行う。データ通信用メッセージ転送部332は、受信したデータ通信用メッセージに104含まれる宛先端末ID231を参照し、この端子IDに対応付けられたコネクション情報103から、宛先クライアント端末との間で構築した暗号化セッション利用コネクションを特定する。そして、宛先端末ID231に対応する暗号化セッションヘッダ情報102に基づき暗号化セッションヘッダ203の内容を変更し、当該暗号化セッション利用コネクションを利用して受信したデータ通信用メッセージを転送する。
尚、転送先のクライアント端末において、通信相手によって異なるクライアント共有鍵101を利用してクライアント暗号かデータ202を作成している場合、データ通信用メッセージ転送部332は、図12に示すように、送信元のクライアント端末Kら通知された送信元端末ID242をデータ通信用メッセージ104の暗号化データフィールド107に挿入して転送しても良い。これにより、転送先のクライアント端末は、受信したデータ通信用メッセージのクライアント暗号化データ202の復号化に利用するクライアント共有鍵101を選択することができる。尚、クライアント端末から受信したデータ通信用メッセージ104に、すでに送信元端末ID242が挿入されていれば、データ通信用メッセージ転送部332は送信元端末IDを挿入する必要はない。
以上のように、本実施の形態では、データ通信用メッセージ104の宛先を示す宛先端末ID231が暗号化データフィールドに中継サーバが読み取れる形で記載される。このため従来技術のように、中継サーバが受信したデータ通信用メッセージの転送先を判断するために、受信したデータ通信用メッセージの暗号化データフィールド全体を復号化する必要がない。本実施の形態における中継サーバ31”は、暗号化データフィールド107全体の復号化を行うことなくデータ通信用メッセージ104の転送先を判断できるため、転送時における中継サーバの負荷の負荷を従来技術よりも軽減することができる。
又、本実施の形態による中継サーバ31”は、受信したデータ通信用メッセージ104に記載された宛先端末ID231によって転送先を判断する。このため、クライアント端末11”、21”は、中継サーバ31”との間の単一の暗号化セッション利用コネクションを利用して1つ以上の任意のクライアント端末宛に通信を行うことができる。このため、クライアント端末11”、21”、中継サーバ31”の双方で構築する暗号化セッション利用コネクションの数が従来技術と比較して格段に少なくて済む。このため、クライアント端末11”、21”、中継サーバ31”双方の負荷を従来技術よりも軽減することが可能である。
又、本実施の形態において宛先端末ID231や送信元端末ID242はデータ通信用メッセージ104の暗号化データフィールド107に挿入されるため、ファイアウォール12、22からは通常の暗号化セッションのフォーマットに従ったデータ通信用メッセージに見えるため、ファイアウォール12、21によって通信が遮断される可能性もない。
更に、本実施の形態では、通信を行うクライアント端末の組を識別するセッション識別子(例えばIPSECのSPIなど)ではなく、個別のクライアント端末を識別する端末ID(送信元端末ID242、宛先端末ID231)によってパケットの転送先を判断している。このため、中継サーバ31”が保持しなければならない情報量を大幅に削減することができる。セッション識別子は、2端末間の通信を一意に識別することができる(例えばクライアント端末A−クライアント端末Bの通信のセッション識別子と、クライアント端末A−クライアント端末Cの通信のセッション識別子は別のものとして扱われる)。しかし、セッション識別子によって転送先を特定する方法では、クライアント端末がn台あった場合、セッション識別子を用いると中継サーバは個ものセッション識別子を保持しなければならない。この場合、中継サーバは最大でn個のクライアント端末の中から2つの端末を選ぶ組み合わせ数分のセッション識別子を保持しなければならない。例えばn=1000台の場合は499,500個のセッション識別子が必要)。これに対して本実施の形態では中継サーバはn個の端末IDのみを保持していれば良い。
又、第1の実施の形態と同様に、クライアント共有鍵101で暗号化したクライアント暗号化データ202を暗号化データフィールド107に挿入したデータ通信用メッセージ104が送受信されるため、中継サーバ31’において復号化や再符号化をする必要がない。すなわち、クライアント端末11”(21”)と複数のクライアント端末との間において秘匿性のあるデータの送受信ができるとともに、中継サーバ31”における処理負荷を軽減することができる。又、高機能のファイアウォールが設置された異なるプライベートネットワーク間の通信ができる。
第3の実施の形態の通信システム1で利用した宛先端末ID242を、複数のクライアント端末に対応付けたID、すなわちグループIDとすることで、複数のクライアント端末にデータを送信する同報配信が可能となる。又、この際、同報先及び送信元のクライアント端末で共通のクライアント共有鍵101(以下、グループ鍵と称す)によって、クライアント暗号化データ202が作成されることで、クライアント端末11”、21”における暗号化処理の負荷を軽減することができる。以下、本実施の形態における同報配信及びグループ鍵による暗号化処理について説明する。
クライアント端末11”を一例に、グループ鍵を利用してクライアント暗号化データ202を作成する動作について説明する。
ここで、クライアント端末11”及びデータの転送先の複数のクライアント端末のそれぞれにおけるクライアント共有鍵管理部112は、グループ鍵を何らかの手段で取得している。各クライアント端末がグループ鍵を取得する手段としては、例えば、フロッピー(登録商標)ディスクやUSBメモリなどの媒体に記録されたグループ鍵を手渡しや郵送など物理的な媒体を使用して交換しても良いし、電子メールに共有鍵を添付して交換しても良い。さらには、グループ鍵を保管するグループ鍵保管サーバを別途設けておき、そのサーバに対してアクセスすることでグループ鍵を取得する方法も考えられる。
グループ鍵の使用は同報配信時に限っても良いし、単一の通信相手に送るデータを暗号化する際に使用しても良い。但し、一般にグループ鍵は個別鍵と比べてセキュリティが弱いため、単一の通信相手に送るデータは個別鍵を利用し、同報配信時の送信データはグループ鍵を利用する、という具合に使い分けることが望ましい。
クライアント端末11”がデータ通信用メッセージ104の暗号化データフィールド107にレイヤ2ヘッダまで含むパケットを含めて通信相手となるクライアント端末へ送信した場合、異なるプライベートネットワークに接続しているクライアント端末同士が、あたかも同一のLANに接続しているかのように通信することが可能となる。更に、同一のクライアント端末11”が複数のクライアント端末とこのような通信を行う場合、そのクライアント端末11”は他の複数のクライアント端末と同一のLANに接続しているかのような通信ができる。
このようなケースで、クライアント端末11”がARP(Address Resolution Protocol) RequestパケットやUpnP(Universal Plug and Play)のSSDP(Simple Service Discovery)パケットを送信した場合、これらのパケットの宛先MACアドレスにブロードキャストアドレスが指定されているため、同報配信が発生する。
クライアント端末11”の宛先端末解決部139はアプリケーション118から渡されたパケットのレイヤ2ヘッダの宛先アドレスを見て、それがブロードキャストアドレスやマルチキャストアドレス(すなわち同報配信)であれば、同報配信である旨データ暗号化部133に通知する。この際、宛先端末解決部139は、同報配信の対象となる複数のクライアント端末の端末IDを宛先端末ID242としてデータ通信用メッセージ作成部136に通知する。
データ暗号化部133は宛先端末解決部139から同報配信である旨通知された場合、共有鍵管理部112が管理するグループ鍵を利用して暗号化やMAC計算を行いクライアント暗号化データ202を生成する。
データ通信用メッセージ作成部136は、宛先端末解決部139から複数の宛先端末ID242を渡された場合には同報配信であると判断してデータ通信用メッセージ104のコピーを複数作成し、それぞれの暗号化データフィールド107に、宛先端末ID242を挿入する。
又、上述のデータ通信用メッセージ104を受信した複数のクライアント端末におけるデータ通信用メッセージ解析部137は、中継サーバ31”から受信したデータ通信用メッセージ104が同報配信である場合、データ復号化部134に同報配信である旨を通知する。同報配信である旨通知されたデータ復号化部134は、共有鍵管理部112が管理するグループ鍵を利用して復号化やMAC計算を行う。
複数のクライアント端末に対して同報配信を行う場合、アプリケーション118から渡されたデータの暗号化に個々のクライアント端末と交換したクライアント共有鍵101(以下個別鍵と呼ぶ)を利用すると、同報配信の対象となるクライアント端末の数だけデータの暗号化処理を繰り返し行わなければならない。このため、同報配信の対象となるクライアント端末の数が増えるにしたがって送信元のクライアント端末にかかる負荷が増加し、多数のクライアント端末に対して同報配信を行うことが困難になる。しかし、本実施の形態では、同報配信の対象となる全てのクライアント端末と共通のクライアント共有鍵101(グループ鍵)による1回の暗号化処理によりクライアント暗号化データ202を生成している。このため、多数のクライアント端末への同報配信をする場合でも、複数回の暗号化処理をする必要がなくなり、送信元のクライアント端末における暗号化処理の負荷は軽減される。
次にグループIDを利用する場合について説明する。送信元のクライアント端末11”の宛先端末解決部139は、アプリケーション118から渡されたパケットのレイヤ2ヘッダの宛先アドレスを見て、それがブロードキャストアドレスやマルチキャストアドレス(すなわち同報配信)であれば、グループIDを宛先端末ID242としてデータ通信用メッセージ作成部136に通知する。
中継サーバ31”のデータ通信用メッセージ転送部332は受信したデータ通信用メッセージ104から宛先端末ID242を抽出する。この際、宛先端末ID242がグループIDである場合、データ通信用メッセージ転送部332は、グループIDに対応する個別の端末IDに基づき、グループを構成するクライアント端末の数だけデータ通信用メッセージ104をコピーする。又、データ通信用メッセージ転送部332は、コピーしたメッセージ104を当該端末IDに対応する暗号化セッション利用コネクションへ転送する。
このように本実施の形態では、グループ鍵が宛先端末ID242として挿入されたデータ通信用メッセージ104が中継サーバ31”で中継処理される。又、同報配信するメッセージのコピーを中継サーバ31”ではなくクライアント端末側行なっている。このため、宛先クライアント端末毎の端末IDを宛先端末IDとしてデータ通信用メッセージに含め、中継サーバにおいてメッセージのコピー、及び転送を行なう場合に比べ、中継サーバの負荷を軽減するとともに、データ通信用メッセージ104に占める宛先端末ID242のサイズを小さくすることができる。
又、第1の実施の形態と同様に、クライアント共有鍵101で暗号化したクライアント暗号化データ202を暗号化データフィールド107に挿入したデータ通信用メッセージ104が送受信されるため、中継サーバ31’において復号化や再符号化をする必要がない。すなわち、クライアント端末11”(21”)と複数のクライアント端末との間において秘匿性のあるデータの送受信ができるとともに、中継サーバ31”における処理負荷を軽減することができる。又、高機能のファイアウォールが設置された異なるプライベートネットワーク間の通信ができる。
尚、グループ鍵とグループIDは組み合わせて利用されても良い。
以上、本発明の実施の形態を詳述してきたが、具体的な構成は上記実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。
図1は、本発明による通信システムの実施の形態における構成を示す図である。 図2は、本発明によるクライアント端末及び中継サーバの第1の実施の形態における構成を示すブロック図である。 図3は、本発明による携帯通信端末における動作とプログラムの移動との対応関係を示すタイミングチャートである。 図4は、本発明による携帯通信端末の起動、通常動作、間欠動作の1連の動作におけるプログラムの移動状態を示す概念図である。 図5は、本発明による携帯通信端末の起動時におけるプログラムの移動処理を示すブロック図である。 図6は、本発明による携帯通信端末の通常動作から間欠動作への遷移時におけるプログラムの移動処理を示すブロック図である。 図7は、本発明による携帯通信端末の間欠動作から通常動作への遷移時におけるプログラムの移動処理を示すブロック図である。 図8は、本発明に係る間欠プログラムを細分化した場合のプログラムの移動状態を示す概念図である。 図9は、従来技術による携帯通信端末の構成を示すブロック図である。 図10は、従来技術による携帯通信端末の構成を示すブロック図である。 図11は、従来技術による携帯通信端末の構成を示すブロック図である。 図12は、従来技術による携帯通信端末の構成を示すブロック図である。 図13は、従来技術による携帯通信端末の構成を示すブロック図である。
符号の説明
10、20:プライベートネットワーク
11、11’、11”、21、21’、21”:クライアント端末
111:暗号化セッション構築部
112:共有鍵管理部
113:データ暗号化部
114:データ復号化部
115:データ通信用メッセージ作成部
116:データ通信用メッセージ解析部
117:データ通信用メッセージ送受信部
118:アプリケーション
119:宛先端末解決部
12、22:ファイアウォール
30:グローバルネットワーク
31、31’、31”:中継サーバ
311:暗号化セッション構築部
312:データ通信用メッセージ転送部
100、sm1〜sm7:暗号化セッション構築メッセージ
101:クライアント共有鍵101
102:暗号化セッションヘッダ情報
103:コネクション情報
104、cm1〜cm5:データ通信用メッセージ
105:宛先端末情報
106:コネクション対応テーブル
107:暗号化データフィールド
108:非暗号化データフィールド
201:中継サーバ読み取り可能データ
202:クライアント暗号化データ
203:暗号化セッションヘッダ
204:追加データ
211:データサイズ値
212:Etherヘッダ
213:IPヘッダ
214:TCPヘッダ
215:HTTPヘッダ
216:ペイロード
222、222’:SSLレコードヘッダ
223:SSLメッセージ
231:宛先端末ID
232:任意データ
242:送信元端末ID

Claims (22)

  1. 中継サーバとの間で暗号化セッション構築メッセージを送受信することによって、前記中継サーバとの間に暗号化セッション利用コネクションを構築し、暗号化セッションヘッダに含めるヘッダ情報を前記中継サーバに通知する暗号化セッション構築部と、
    他のクライアント端末と共通のクライアント共有鍵を保持する共有鍵管理部と、
    前記クライアント共有鍵を用いてデータの暗号化及び/又は前記データのMAC(Message Authentication Code)の計算を行い、クライアント暗号化データとして出力するデータ暗号化部と、
    前記クライアント暗号化データを挿入した暗号化データフィールドと、前記ヘッダ情報を含む暗号化セッションヘッダが挿入された非暗号化データフィールドとを含むデータ通信用メッセージを作成するデータ通信用メッセージ作成部と、
    前記他のクライアント端末宛の前記データ通信用メッセージを、前記暗号化セッション利用コネクションを利用して前記中継サーバに転送する送信部と
    を具備するクライアント端末。
  2. 請求項1に記載のクライアント端末において、
    前記共有鍵管理部は、前記他のクライアント端末宛てにクライアント共有鍵の交換を開始するための暗号化セッション構築メッセージを作成し、
    前記データ通信用メッセージ作成部は、前記クライアント共有鍵の交換を開始するための暗号化セッション構築メッセージを前記暗号化データフィールドに挿入して前記データ通信メッセージを作成する
    クライアント端末。
  3. 請求項1又は2に記載のクライアント端末において、
    前記データ通信用メッセージ作成部は、前記暗号化データフィールドに挿入するデータのデータサイズ値を、前記暗号化データフィールドに挿入して前記データ通信メッセージを作成する
    クライアント端末。
  4. 請求項1から3いずれか1項に記載のクライアント端末において、
    前記データ通信用メッセージ作成部は、前記データ通信用メッセージの宛先である他のクライアント端末に割り当てられた端末IDを、宛先端末IDとして前記暗号化データフィールドに、前記中継サーバが読み取り可能な形式で挿入して前記データ通信メッセージを作成する
    クライアント端末。
  5. 請求項4に記載のクライアント端末において、
    自端末の端末IDを送信元IDとして、
    前記データ暗号化部は、前記共有鍵管理部が管理するクライアント共有鍵のうち前記宛先端末IDに対応するクライアント共有鍵を利用してデータの暗号化及び/又はデータのMACの計算を行い、
    前記データ通信用メッセージ作成部は、自端末の端末IDを送信元端末IDとして前記暗号化データフィールドに挿入して前記データ通信メッセージを作成する
    クライアント端末。
  6. 請求項4又は5に記載のクライアント端末において、
    前記共有鍵管理部は、複数のクライアント端末と共通のグループ鍵を保持し、
    前記データ暗号化部は、前記グループ鍵を利用してデータの暗号化及び/又はデータのMACの計算を行い、
    前記データ通信用メッセージ作成部は、前記データ通信用メッセージの宛先である前記複数のクライアント端末に割り当てられた複数の端末IDを、複数の宛先端末IDとして複数のデータ通信メッセージの暗号化データフィールドに挿入し、
    前記転送部は、前記複数のクライアント端末宛の前記複数のデータ通信用メッセージを、前記暗号化セッション利用コネクションを利用して前記中継サーバに転送する
    クライアント端末。
  7. 請求項4又は5に記載のクライアント端末において、
    前記共有鍵管理部は、複数のクライアント端末と共通のグループ鍵を保持し、
    前記データ暗号化部は、前記グループ鍵を利用してデータの暗号化及び/又はデータのMACの計算を行い、
    前記データ通信用メッセージ作成部は、前記データ通信用メッセージの宛先である前記複数のクライアント端末に割り当てられた1つのグループ端末IDを、宛先端末IDとして暗号化データフィールドに挿入したデータ通信メッセージを作成し、
    前記転送部は、前記複数のクライアント端末宛の前記データ通信用メッセージを、前記暗号化セッション利用コネクションを利用して前記中継サーバに転送する
    クライアント端末。
  8. 請求項1から3いずれか1項に記載のクライアント端末において、
    前記暗号化セッション構築部は前記中継サーバとの間に、通信相手となる他のクライアント端末毎に異なる暗号化利用コネクションを複数構築し、
    前記データ通信用メッセージ送信部は、前記他のクライアント端末宛の前記データ通信用メッセージを、前記他のクライアント端末に対応する暗号化セッション利用コネクションを利用して中継サーバへ送信する
    クライアント端末。
  9. 請求項1から8いずれか1項に記載のクライアント端末において、
    前記暗号化セッション構築部は、前記中継サーバと前記暗号化セッション利用コネクションを構築する際、セッション鍵を前記中継サーバと交換し、
    前記データ通信用メッセージ作成部は、前記セッション鍵を用いて暗号化され、且つ/又はMACが計算されたデータを挿入した暗号化データフィールドを含むデータ通信用メッセージを作成する
    クライアント端末。
  10. 請求項1から8いずれか1項に記載のクライアント端末において、
    前記暗号化セッション構築部は、前記中継サーバと前記暗号化セッション利用コネクションを構築する際、セッション鍵を前記中継サーバと交換し、
    前記データ通信用メッセージ作成部は、前記セッション鍵を利用して、データ通信用メッセージに含めるデータのMACを計算し、計算結果を前記暗号化データフィールドに挿入して前記データ通信用メッセージを作成する
    クライアント端末。
  11. 請求項1から10いずれか1項に記載のクライアント端末において、
    他のクライアント端末から、前記中継サーバを介して送信されたデータ通信用メッセージを受信する受信部と、
    前記受信部で受信したデータ通信用メッセージの暗号化データフィールドから、送信元のクライアント端末と共通のクライアント端末鍵を用いて復号化及び/又はMACの計算が可能なデータを抽出するデータ通信用メッセージ解析部と、
    前記データ通信用メッセージ解析部で抽出されたデータの復号化及び/又は抽出されたデータのMACの計算を行うデータ復号化部と
    を更に具備するクライアント端末。
  12. 請求項11に記載のクライアント端末において、
    前記中継サーバから受信したデータ通信用メッセージの暗号化データフィールドに、前記送信元のクライアント端末が送信した暗号化セッション構築メッセージが含まれている場合、前記データ通信用メッセージ解析部は、前記暗号化セッション構築メッセージを前記共有鍵管理部に転送し、
    前記共有鍵管理部は、前記データ通信用メッセージ解析部から転送された暗号化セッション構築メッセージに対応する暗号化セッション構築メッセージに基づき、前記送信元のクライアント端末と共通のクライアント共有鍵を取得する
    クライアント端末。
  13. 請求項12に記載のクライアント端末において、
    前記データ通信用メッセージ解析部は、受信したデータ通信用メッセージの暗号化データフィールドに含まれる送信元端末IDを抽出し、
    前記データ復号化部は、前記共有鍵管理部が管理するクライアント共有鍵のうち、前記データ通信用メッセージ解析部で抽出された送信元端末IDに対応するクライアント共有鍵101を利用して、前記データ通信用メッセージ解析部で抽出されたデータの復号化及び/又は抽出されたデータのMACの計算を行う
    クライアント端末。
  14. 請求項12に記載のクライアント端末において、
    前記データ通信用メッセージ解析部は、受信したデータ通信用メッセージに応じて同報通信であることを前記データ復号化部に通知し、
    同報通信であることを通知された前記データ復号化部は、前記共有鍵管理部が管理するクライアント共有鍵のうち、送信元の複数のクライアントサーバと共通のグループ鍵を利用して、前記データ通信用メッセージ解析部で抽出されたデータの復号化及び/又は抽出されたデータのMACの計算を行う
    クライアント端末。
  15. 請求項11から14いずれか1項に記載のクライアントサーバにおいて、
    前記データ通信用メッセージ解析部は、前記中継サーバから受信したデータ通信用メッセージに含まれるMACと、前記暗号化セッション利用コネクションの構築時に前記中継サーバから取得したセッション鍵を用いて計算した、前記データ通信用メッセージに含まれるデータのMACとを比較して、前記データ通信用メッセージの認証を行う
    クライアント端末。
  16. 複数のクライアント端末の間で行われる通信を中継する中継サーバであって、
    前記複数のクライアント端末のそれぞれとの間で暗号化セッション構築メッセージを送受信することによって、それぞれと個別の暗号化セッション利用コネクションを構築し、前記複数のクライアント端末のそれぞれから、暗号化セッションヘッダに含めるヘッダ情報を取得する暗号化セッション構築部と、
    前記暗号化セッション利用コネクションを利用して、前記複数のクライアント端末のそれぞれとの間においてデータ通信用メッセージを送受信するデータ通信用メッセージ転送部と
    を具備し、
    前記データ通信用メッセージは、前記複数のクライアント端末との間で共有するクライアント共有鍵によって暗号化されたクライアント暗号化データが挿入された暗号化データフィールドと、前記ヘッダ情報を含む暗号化セッションヘッダが挿入された非暗号化データフィールドとを含み、
    前記データ通信用メッセージ転送部は、前記複数のクライアント端末のいずれかから転送されたデータ通信用メッセージの非暗号化データフィールドに含まれる暗号化セッションヘッダを、前記データ通信用メッセージの転送先となるクライアント端末に対応する暗号化セッションヘッダに変換し、暗号化セッションヘッダを変換した前記データ通信用メッセージを、転送先のクライアント端末に転送する
    中継サーバ。
  17. 請求項16に記載の中継サーバにおいて、
    前記暗号化セッション構築部は、前記複数のクライアント端末のそれぞれから通知された端末IDと前記暗号化セッション利用コネクションとの対応関係を前記データ通信用メッセージ転送部に通知し、
    前記データ通信用メッセージ転送部は、前記対応関係に従い、前記データ通信用メッセージの暗号化データフィールドに含まれる宛先端末IDと同じ端末IDに対応する暗号化セッション利用コネクションを、前記データ通信用メッセージの転送に利用する
    中継サーバ。
  18. 請求項16又は17に記載の中継サーバにおいて、
    前記暗号化セッション構築部は、前記暗号化セッション利用コネクションを構築する際、個別のセッション鍵を前記複数のクライアント端末のそれぞれと交換し、
    前記データ通信用メッセージ転送部は、前記クライアント端末から受信したデータ通信用メッセージの暗号化データフィールドの一部に対し、受信したデータ通信用メッセージの送信元クライアント端末と前記暗号化セッション構築部が交換したセッション鍵によって復号化及び/又はMAC(Message Authentication Code)の計算が可能な場合、前記セッション鍵によって復号化及び/又はMACの計算を行い、復号化結果及び/又はMACを前記データ通信用メッセージの前記暗号化データフィールドに挿入して転送先クライアント端末に転送する
    中継サーバ。
  19. 請求項16又は17に記載の中継サーバにおいて、
    前記暗号化セッション構築部は、前記暗号化セッション利用コネクションを構築する際、個別のセッション鍵を前記複数のクライアント端末のそれぞれと交換し、
    前記データ通信用メッセージ転送部は、受信したデータ通信用メッセージに含まれるMACと、前記データ通信用メッセージに含まれるデータに対して、前記データ通信用メッセージの送信元のクライアント端末と交換したセッション鍵を利用して計算したMACとを比較することでメッセージ認証を行う
    中継サーバ。
  20. 請求項1から15のいずれか1項に記載のクライアント端末と、
    請求項16から19いずれか1項に記載の中継サーバと、
    前記クライアント端末に接続されたプライベートネットワークと、
    前記中継サーバに接続されたグローバルネットワークと、
    前記プライベートネットワークと前記グローバルネットワークとの間に設けられ、前記暗号化セッション利用コネクションを監視するファイアウォールと、
    を具備する
    通信システム。
  21. 異なるプライベートネットワークに接続される複数のクライアント端末間におけるデータの送受信を、グローバルネットワークに接続される中継サーバを介して実行する通信方法であって、
    前記複数のクライアント端末は共通のクライアント共有鍵を保持し、
    前記複数のクライアント端末のそれぞれが、前記中継サーバとの間に暗号化セッション利用コネクションを構築するステップと、
    前記クライアント端末が、前記中継サーバに暗号化セッションヘッダに含めるヘッダ情報を通知するステップと、
    前記クライアント端末が、前記クライアント共有鍵を用いてデータを暗号化してクライアント暗号化データを生成するステップと、
    前記クライアント端末が、前記クライアント暗号化データを挿入した暗号化データフィールドと、前記ヘッダ情報を含む暗号化セッションヘッダが挿入された非暗号化データフィールドとを含むデータ通信用メッセージを作成するステップと、
    前記クライアント端末が、前記中継サーバに前記データ通信用メッセージを送信するステップと、
    前記中継サーバが、前記データ通信用メッセージの宛先のクライアント端末に対応するヘッダ情報に基づき、前記暗号化セッションヘッダの内容を変更するステップと、
    前記中継サーバが、前記ヘッダ情報を変更したデータ通信用メッセージを、前記宛先のクライアント端末との間に構築した暗号化セッション利用コネクションを介して送信するステップと、
    を具備する
    通信方法。
  22. 請求項21に記載の通信方法において、
    クライアント端末が、受信したデータ通信用メッセージの暗号化データフィールドに含まれる前記クライアントデータを、前記クライアント共有鍵を用いて復号化し、前記データを取得するステップを更に備える
    通信方法。
JP2006350921A 2006-12-27 2006-12-27 クライアント端末、中継サーバ、通信システム、及び通信方法 Active JP4081724B1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2006350921A JP4081724B1 (ja) 2006-12-27 2006-12-27 クライアント端末、中継サーバ、通信システム、及び通信方法
US11/850,899 US8583912B2 (en) 2006-12-27 2007-09-06 Communication system of client terminals and relay server and communication method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006350921A JP4081724B1 (ja) 2006-12-27 2006-12-27 クライアント端末、中継サーバ、通信システム、及び通信方法

Publications (2)

Publication Number Publication Date
JP4081724B1 JP4081724B1 (ja) 2008-04-30
JP2008166894A true JP2008166894A (ja) 2008-07-17

Family

ID=39381850

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006350921A Active JP4081724B1 (ja) 2006-12-27 2006-12-27 クライアント端末、中継サーバ、通信システム、及び通信方法

Country Status (2)

Country Link
US (1) US8583912B2 (ja)
JP (1) JP4081724B1 (ja)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010045668A (ja) * 2008-08-14 2010-02-25 Nippon Telegr & Teleph Corp <Ntt> 認証メッセージ交換システムおよび認証メッセージ交換方法
WO2010032391A1 (ja) * 2008-09-19 2010-03-25 日本電気株式会社 完全性検証のための通信システム、通信装置、及びそれらを用いた通信方法及びプログラム
JP2013514682A (ja) * 2009-12-18 2013-04-25 西安西▲電▼捷通▲無▼綫▲網▼絡通信股▲分▼有限公司 ノード間秘密保持通信方法およびシステム
JP2015233173A (ja) * 2014-06-09 2015-12-24 Necエンジニアリング株式会社 通信システム、通信装置及び通信方法
JP2018164290A (ja) * 2014-03-19 2018-10-18 ブルーフィン ペイメント システムズ エルエルシーBluefin Payment Systems,Llc 暗号化装置から受信したペイロードを復号可能にするシステム及び方法
US10505906B2 (en) 2014-03-19 2019-12-10 Bluefin Payent Systems Llc Systems and methods for decryption as a service via a configuration of read-only databases
US11070534B2 (en) 2019-05-13 2021-07-20 Bluefin Payment Systems Llc Systems and processes for vaultless tokenization and encryption
US11120418B2 (en) 2017-06-02 2021-09-14 Bluefin Payment Systems Llc Systems and methods for managing a payment terminal via a web browser
US11256798B2 (en) 2014-03-19 2022-02-22 Bluefin Payment Systems Llc Systems and methods for decryption as a service
US11711350B2 (en) 2017-06-02 2023-07-25 Bluefin Payment Systems Llc Systems and processes for vaultless tokenization and encryption

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7899031B2 (en) * 2007-11-20 2011-03-01 Microsoft Corporation Locally terminating an established connection
US8335316B2 (en) * 2008-04-21 2012-12-18 Broadcom Corporation Method and apparatus for data privacy in passive optical networks
US8763107B1 (en) * 2009-08-03 2014-06-24 Omnimetrix, Llc Cross-connected, server-based, IP-connected, point-to-point connectivity
US9059971B2 (en) * 2010-03-10 2015-06-16 Koolspan, Inc. Systems and methods for secure voice communications
US8379855B2 (en) * 2010-06-03 2013-02-19 Nokia Corporation Ciphering in a packet-switched telecommunications system
US9179303B2 (en) 2010-11-17 2015-11-03 Qualcomm Incorporated Methods and apparatus for transmitting and receiving secure and non-secure data
US9684887B2 (en) * 2011-03-31 2017-06-20 Loment, Inc. Priority of outbound messages communicated among end user communication devices
US9106633B2 (en) * 2011-05-26 2015-08-11 First Data Corporation Systems and methods for authenticating mobile device communications
CN102868665B (zh) * 2011-07-05 2016-07-27 华为软件技术有限公司 数据传输的方法及装置
US9071964B2 (en) * 2011-09-16 2015-06-30 Motorola Solutions, Inc. Method and apparatus for authenticating a digital certificate status and authorization credentials
JP5727353B2 (ja) * 2011-11-17 2015-06-03 Kddi株式会社 情報収集システム、通信装置及びプログラム
US9185021B1 (en) * 2012-10-15 2015-11-10 Wal-Mart Stores, Inc. Content based routing architecture system and method
JP6149591B2 (ja) * 2013-08-08 2017-06-21 富士通株式会社 無線中継装置、通信システム、及び、通信方法
US9961055B1 (en) 2014-12-18 2018-05-01 Amazon Technologies, Inc. Inaccessibility of data to server involved in secure communication
US9930067B1 (en) * 2014-12-18 2018-03-27 Amazon Technologies, Inc. Techniques for secure session reestablishment
US9591479B1 (en) 2016-04-14 2017-03-07 Wickr Inc. Secure telecommunications
EP3491775A4 (en) 2016-07-27 2020-02-26 Akamai Technologies, Inc. SHARING OF CRYPTOGRAPHIC MATERIAL BETWEEN ENTITIES WITHOUT CONNECTIVITY OR RELATIONSHIP OF DIRECT TRUST
US10659476B2 (en) * 2016-09-12 2020-05-19 Architecture Technology Corporation Transparent bridge for monitoring crypto-partitioned wide-area network
US10469425B1 (en) * 2016-12-09 2019-11-05 Amazon Technologies, Inc. Secure message service for preventing dissemination of sensitive information to third-parties
CN106817369A (zh) * 2017-01-05 2017-06-09 深圳市证通电子股份有限公司 数据安全交互方法和系统
US10541981B1 (en) 2017-05-17 2020-01-21 Amazon Technologies, Inc. Secure message service for managing third-party dissemination of sensitive information
US10735469B1 (en) 2017-07-01 2020-08-04 Juniper Networks, Inc Apparatus, system, and method for predictively enforcing security policies on unknown flows
JP7203297B2 (ja) * 2017-09-27 2023-01-13 有限会社シモウサ・システムズ エンドツーエンド暗号化通信システム
US10778432B2 (en) 2017-11-08 2020-09-15 Wickr Inc. End-to-end encryption during a secure communication session
US10855440B1 (en) 2017-11-08 2020-12-01 Wickr Inc. Generating new encryption keys during a secure communication session
US11101999B2 (en) 2017-11-08 2021-08-24 Amazon Technologies, Inc. Two-way handshake for key establishment for secure communications
US10541814B2 (en) 2017-11-08 2020-01-21 Wickr Inc. End-to-end encryption during a secure communication session
WO2020105738A1 (ja) * 2018-11-23 2020-05-28 株式会社アクリート メッセージ転送装置、方法及びプログラム
US11089010B2 (en) * 2019-08-14 2021-08-10 Taklane Method for transmitting digital information
US11483294B2 (en) * 2019-08-28 2022-10-25 University Of Maryland, Baltimore County Method for anonymizing network data using differential privacy
US11463366B1 (en) 2020-09-22 2022-10-04 Architecture Technology Corporation Autonomous network optimization using network templates
CN113114644B (zh) * 2021-03-31 2022-03-25 杭州恒生数字设备科技有限公司 一种基于sip架构的多级跨域对称密钥管理系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2357226B (en) * 1999-12-08 2003-07-16 Hewlett Packard Co Security protocol
JP3637863B2 (ja) * 2000-11-01 2005-04-13 日本電気株式会社 仮想ネットワーク及び仮想ネットワーク接続方式
US20020150097A1 (en) * 2001-02-21 2002-10-17 Wei Yen Method and apparatus for secured multicasting
JP4380945B2 (ja) 2001-07-12 2009-12-09 村田機械株式会社 中継サーバ
JP4492248B2 (ja) * 2004-08-04 2010-06-30 富士ゼロックス株式会社 ネットワークシステム、内部サーバ、端末装置、プログラム、およびパケット中継方法
IL167180A (en) * 2005-03-01 2011-02-28 Eci Telecom Ltd Method and device for providing multicast services to multiple customers

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010045668A (ja) * 2008-08-14 2010-02-25 Nippon Telegr & Teleph Corp <Ntt> 認証メッセージ交換システムおよび認証メッセージ交換方法
WO2010032391A1 (ja) * 2008-09-19 2010-03-25 日本電気株式会社 完全性検証のための通信システム、通信装置、及びそれらを用いた通信方法及びプログラム
JP2013514682A (ja) * 2009-12-18 2013-04-25 西安西▲電▼捷通▲無▼綫▲網▼絡通信股▲分▼有限公司 ノード間秘密保持通信方法およびシステム
JP2020123376A (ja) * 2014-03-19 2020-08-13 ブルーフィン ペイメント システムズ エルエルシーBluefin Payment Systems,Llc 暗号化装置のフィンガープリントを作成するシステム及び方法
US10880277B2 (en) 2014-03-19 2020-12-29 Bluefin Payment Systems Llc Managing payload decryption via fingerprints
US10505906B2 (en) 2014-03-19 2019-12-10 Bluefin Payent Systems Llc Systems and methods for decryption as a service via a configuration of read-only databases
US10616188B2 (en) 2014-03-19 2020-04-07 Bluefin Payment Systems Llc Systems and methods for decryption as a service via a message queuing protocol
US10721215B2 (en) 2014-03-19 2020-07-21 Bluefin Payment Systems Llc Systems and methods for decryption as a service
JP7554419B2 (ja) 2014-03-19 2024-09-20 ブルーフィン ペイメント システムズ エルエルシー 暗号化装置のフィンガープリントを作成するシステム及び方法
US10749845B2 (en) 2014-03-19 2020-08-18 Bluefin Payment Systems Llc Systems and methods for decryption as a service via a hardware security module
JP2018164290A (ja) * 2014-03-19 2018-10-18 ブルーフィン ペイメント システムズ エルエルシーBluefin Payment Systems,Llc 暗号化装置から受信したペイロードを復号可能にするシステム及び方法
US11880446B2 (en) 2014-03-19 2024-01-23 Bluefin Payment Systems Llc Systems and methods for decryption as a service
US11256798B2 (en) 2014-03-19 2022-02-22 Bluefin Payment Systems Llc Systems and methods for decryption as a service
JP6989929B2 (ja) 2014-03-19 2022-01-12 ブルーフィン ペイメント システムズ エルエルシー 暗号化装置のフィンガープリントを作成するシステム及び方法
JP2015233173A (ja) * 2014-06-09 2015-12-24 Necエンジニアリング株式会社 通信システム、通信装置及び通信方法
US11120418B2 (en) 2017-06-02 2021-09-14 Bluefin Payment Systems Llc Systems and methods for managing a payment terminal via a web browser
US11711350B2 (en) 2017-06-02 2023-07-25 Bluefin Payment Systems Llc Systems and processes for vaultless tokenization and encryption
US12099982B2 (en) 2017-06-02 2024-09-24 Bluefin Payment Systems, LLC Systems and methods for managing a payment terminal via a web browser
US11070534B2 (en) 2019-05-13 2021-07-20 Bluefin Payment Systems Llc Systems and processes for vaultless tokenization and encryption

Also Published As

Publication number Publication date
US8583912B2 (en) 2013-11-12
JP4081724B1 (ja) 2008-04-30
US20080162929A1 (en) 2008-07-03

Similar Documents

Publication Publication Date Title
JP4081724B1 (ja) クライアント端末、中継サーバ、通信システム、及び通信方法
JP4407452B2 (ja) サーバ、vpnクライアント、vpnシステム、及びソフトウェア
JP4674502B2 (ja) 情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラム
US8364772B1 (en) System, device and method for dynamically securing instant messages
TWI313996B (en) System and method for secure remote access
JP3688830B2 (ja) パケット転送方法及びパケット処理装置
US7774594B2 (en) Method and system for providing strong security in insecure networks
US7827597B2 (en) Secure transport for mobile communication network
EP1635502B1 (en) Session control server and communication system
US20070255784A1 (en) Communication System for Use in Communication Between Communication Equipment by Using Ip Protocol
JP2006121510A (ja) 暗号化通信システム
JP2007184892A (ja) 代理端末、サーバ装置、代理端末の通信経路設定方法及びサーバ装置の通信経路設定方法
JP2007281919A (ja) アクセス制限を行う公衆回線上の通信システムと端末接続装置およびサーバー接続制限装置
JP2005236728A (ja) サーバ装置、要求発行機器、要求受諾機器、通信システム及び通信方法
WO2012014566A1 (ja) 通信システム、通信装置及び通信方法、並びにコンピューター・プログラム
JP4933286B2 (ja) 暗号化パケット通信システム
CN110351308B (zh) 一种虚拟专用网络通信方法和虚拟专用网络设备
JP4707325B2 (ja) 情報処理装置
US20080059788A1 (en) Secure electronic communications pathway
JP2011217268A (ja) メールサーバ、メール通信システム、及びメール送受信方法
JP2010081108A (ja) 通信中継装置、情報処理装置、プログラム、及び通信システム
JP2009071481A (ja) 通信制御システム、端末、及び、プログラム
JP2007281918A (ja) アクセス制限を行う公衆回線上の通信システムと端末接続装置およびサーバー接続制限装置
JP2005064984A (ja) 通信装置、鍵交換システムおよび鍵交換プログラム
JP4757088B2 (ja) 中継装置

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080117

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080130

R150 Certificate of patent or registration of utility model

Ref document number: 4081724

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110222

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110222

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120222

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120222

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130222

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130222

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140222

Year of fee payment: 6