ホーム > 特許ランキング > アルカテル−ルーセント
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6505710
(24)【登録日】2019年4月5日
(45)【発行日】2019年4月24日
(54)【発明の名称】ＴＬＳプロトコル拡張
(51)【国際特許分類】
H04L 9/16 20060101AFI20190415BHJP
H04L 9/32 20060101ALI20190415BHJP
G09C 1/00 20060101ALI20190415BHJP
【ＦＩ】
H04L9/00 643
H04L9/00 675A
G09C1/00 640D
【請求項の数】7
【全頁数】11
(21)【出願番号】特願2016-539493(P2016-539493)
(86)(22)【出願日】2014年9月2日
(65)【公表番号】特表2016-532398(P2016-532398A)
(43)【公表日】2016年10月13日
(86)【国際出願番号】EP2014068564
(87)【国際公開番号】WO2015032732
(87)【国際公開日】20150312
【審査請求日】2016年4月22日
(31)【優先権主張番号】13306230.7
(32)【優先日】2013年9月9日
(33)【優先権主張国】EP
【前置審査】
(73)【特許権者】
【識別番号】391030332
【氏名又は名称】アルカテル−ルーセント
(74)【代理人】
【識別番号】110001173
【氏名又は名称】特許業務法人川口國際特許事務所
(72)【発明者】
【氏名】ロシュ，セバスチャン
(72)【発明者】
【氏名】ドゥグツンダ，マルセル
【審査官】
和平 悠希
(56)【参考文献】
【文献】
米国特許出願公開第２００７／００２２４７５（ＵＳ，Ａ１）
【文献】
WILLIAMS M, et al，Mobile DTLS draft-barrett-mobile-dtls-00，IETF Internet Draft，２００９年 ３月 ４日
【文献】
RESCORLA E, et al.，Datagram Transport Layer Security，IETF Proposed Standard，２００６年 ４月，pp.15-19，IETF RFC 4347，ＵＲＬ，https://tools.ietf.org/html/rfc4347
【文献】
DIERKS T, et al.，The Transport layer Security (TLS) Protocol Version 1.2，IETF Proposed Standard，[online]，２００８年 ８月，pp.39-42，IETF RFC 5246，ＵＲＬ，https://tools.ietf.org/html/rfc5246
【文献】
M WILLIAMS; J BARRETT，MOBILE DTLS; DRAFT-BARRETT-MOBILE-DTLS-00.TXT，IETF STANDARD-WORKING-DRAFT，スイス，２００９年 ３月 ４日
【文献】
E.Rescorla et al，Datagram Transport Layer Security，２００６年 ４月，pp.15-19，ＵＲＬ，https://tools.ietf.org/html/rfc4347
【文献】
T.Dierks et al，The Transport Layer Security (TLS) Protocol Version 1.2，２００８年 ８月，pp.39-42，ＵＲＬ，https://tools.ietf.org/html/rfc5246
(58)【調査した分野】（Int.Cl.，ＤＢ名）
Ｈ０４Ｌ ９／１６
Ｇ０９Ｃ １／００
Ｈ０４Ｌ ９／３２
(57)【特許請求の範囲】
【請求項1】
通信装置（ＣＤ）とアプリケーションサーバ（ＡＳ）間のハンドシェイク通信を拡張するための方法であって、
少なくとも２つのメッセージ（ＭｅｓＣ）を、通信装置（ＣＤ）から受信するステップ（Ｓ１）であって、各メッセージ（ＭｅｓＣ）が、ハンドシェイクインデックス（ＩｎｄＨ）を備え、かつアプリケーションサーバ（ＡＳ）が、通信装置（ＣＤ）と、暗号パラメータの組についてネゴシエートするように、ハンドシェイクセッションをトリガする、受信するステップ（Ｓ１）と、
受信された少なくとも２つのメッセージ（ＭｅｓＣ）の各ハンドシェイクインデックス（ＩｎｄＨ）に対して、関連したハンドシェイクインデックス（ＩｎｄＨ）に応じた対応する接続状態インデックス（ＩｎｄＣ）とともに、ネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータを格納するステップ（Ｓ２）であって、前記対応する接続状態インデックス（ＩｎｄＣ）は、プロトコルメッセージフィールドに含まれる単一バイトである、ステップと、
通信装置の１つだけのポートとのセキュア接続を確立するために、送信されるデータの機密度に応じて、最も低い接続状態インデックス（ＩｎｄＣ）とともに格納されたネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータをアクティブ化するステップ（Ｓ３）と
のアプリケーションサーバ（ＡＳ）におけるステップを含み、
アプリケーションサーバが、接続状態を通信装置から受信し、受信された接続状態に対応して対応する接続状態インデックス（ＩｎｄＣ）とともに格納されたネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータをアクティブ化することによって、受信された接続状態に対応するセキュリティコンテキストを切り替える、方法。
少なくとも２つのメッセージ（ＭｅｓＣ）を、通信装置（ＣＤ）から受信するステップ（Ｓ１）であって、各メッセージ（ＭｅｓＣ）が、ハンドシェイクインデックス（ＩｎｄＨ）を備え、かつアプリケーションサーバ（ＡＳ）が、通信装置（ＣＤ）と、暗号パラメータの組についてネゴシエートするように、ハンドシェイクセッションをトリガする、受信するステップ（Ｓ１）と、
受信された少なくとも２つのメッセージ（ＭｅｓＣ）の各ハンドシェイクインデックス（ＩｎｄＨ）に対して、関連したハンドシェイクインデックス（ＩｎｄＨ）に応じた対応する接続状態インデックス（ＩｎｄＣ）とともに、ネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータを格納するステップ（Ｓ２）であって、前記対応する接続状態インデックス（ＩｎｄＣ）は、プロトコルメッセージフィールドに含まれる単一バイトである、ステップと、
通信装置の１つだけのポートとのセキュア接続を確立するために、送信されるデータの機密度に応じて、最も低い接続状態インデックス（ＩｎｄＣ）とともに格納されたネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータをアクティブ化するステップ（Ｓ３）と
のアプリケーションサーバ（ＡＳ）におけるステップを含み、
アプリケーションサーバが、接続状態を通信装置から受信し、受信された接続状態に対応して対応する接続状態インデックス（ＩｎｄＣ）とともに格納されたネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータをアクティブ化することによって、受信された接続状態に対応するセキュリティコンテキストを切り替える、方法。
【請求項2】
少なくとも２つのメッセージが“ＣｌｉｅｎｔＨｅｌｌｏ”メッセージである、請求項１に記載の方法。
【請求項3】
暗号パラメータの組が、圧縮型、暗号化型、およびメッセージ認証コード（ＭＡＣ）アルゴリズムを含む、請求項１または２に記載の方法。
【請求項4】
ハンドシェイクインデックスのそれぞれが、１バイトで符号化された数である、請求項１から３のいずれか一項に記載の方法。
【請求項5】
不当なハンドシェイクインデックスを有するメッセージを受信した場合、アプリケーションサーバが、ハンドシェイクネゴシエーションをアボートする、請求項１から４のいずれか一項に記載の方法。
【請求項6】
通信装置（ＣＤ）とサーバ（ＡＳ）間のハンドシェイク通信を拡張するためのサーバ（ＡＳ）であって、
少なくとも２つのメッセージ（ＭｅｓＣ）を、通信装置（ＣＤ）から受信するための手段（ＳＳＭ）であって、各メッセージ（ＭｅｓＣ）が、ハンドシェイクインデックス（ＩｎｄＨ）を備え、かつサーバ（ＡＳ）が、通信装置（ＣＤ）と、暗号パラメータの組についてネゴシエートするように、ハンドシェイクセッションをトリガする、受信するための手段（ＳＳＭ）と、
受信された少なくとも２つのメッセージ（ＭｅｓＣ）の各ハンドシェイクインデックス（ＩｎｄＨ）に対して、対応する接続状態インデックスとともに、ネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータを格納するための手段（ＳＳＭ）であって、前記対応する接続状態インデックスは、プロトコルメッセージフィールドに含まれる単一バイトである、手段と、
通信装置の１つだけのポートとのセキュア接続を確立するために、送信されるデータの機密度に応じて、最も低い接続状態インデックスとともに格納されたネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータをアクティブ化するための手段（ＳＳＭ）と、
接続状態を通信装置から受信し、受信された接続状態に対応して対応する接続状態インデックスとともに格納されたネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータをアクティブ化することによって、受信された接続状態に対応するセキュリティコンテキストを切り替える手段と
を備える、サーバ（ＡＳ）。
少なくとも２つのメッセージ（ＭｅｓＣ）を、通信装置（ＣＤ）から受信するための手段（ＳＳＭ）であって、各メッセージ（ＭｅｓＣ）が、ハンドシェイクインデックス（ＩｎｄＨ）を備え、かつサーバ（ＡＳ）が、通信装置（ＣＤ）と、暗号パラメータの組についてネゴシエートするように、ハンドシェイクセッションをトリガする、受信するための手段（ＳＳＭ）と、
受信された少なくとも２つのメッセージ（ＭｅｓＣ）の各ハンドシェイクインデックス（ＩｎｄＨ）に対して、対応する接続状態インデックスとともに、ネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータを格納するための手段（ＳＳＭ）であって、前記対応する接続状態インデックスは、プロトコルメッセージフィールドに含まれる単一バイトである、手段と、
通信装置の１つだけのポートとのセキュア接続を確立するために、送信されるデータの機密度に応じて、最も低い接続状態インデックスとともに格納されたネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータをアクティブ化するための手段（ＳＳＭ）と、
接続状態を通信装置から受信し、受信された接続状態に対応して対応する接続状態インデックスとともに格納されたネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータをアクティブ化することによって、受信された接続状態に対応するセキュリティコンテキストを切り替える手段と
を備える、サーバ（ＡＳ）。
【請求項7】
通信装置（ＣＤ）とサーバ（ＡＳ）間のハンドシェイク通信を拡張するためのサーバ（ＡＳ）内で実行されることが可能なコンピュータプログラムであって、前記プログラムが、プログラムが、前記装置にロードされ、その中で実行される場合に、
少なくとも２つのメッセージ（ＭｅｓＣ）を、通信装置（ＣＤ）から受信するステップ（Ｓ１）であって、各メッセージ（ＭｅｓＣ）が、ハンドシェイクインデックス（ＩｎｄＨ）を備え、かつサーバ（ＡＳ）が、通信装置（ＣＤ）と、暗号パラメータの組についてネゴシエートするように、ハンドシェイクセッションをトリガする、受信するステップ（Ｓ１）と、
受信された少なくとも２つのメッセージ（ＭｅｓＣ）の各ハンドシェイクインデックス（ＩｎｄＨ）に対して、関連したハンドシェイクインデックス（ＩｎｄＨ）に応じた対応する接続状態インデックス（ＩｎｄＣ）とともに、ネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータを格納するステップ（Ｓ２）であって、前記対応する接続状態インデックス（ＩｎｄＣ）は、プロトコルメッセージフィールドに含まれる単一バイトである、ステップと、
通信装置の１つだけのポートとのセキュア接続を確立するために、送信されるデータの機密度に応じて、最も低い接続状態インデックス（ＩｎｄＣ）とともに格納されたネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータをアクティブ化するステップ（Ｓ３）と、
接続状態を通信装置から受信し、受信された接続状態に対応して対応する接続状態インデックス（ＩｎｄＣ）とともに格納されたネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータをアクティブ化することによって、受信された接続状態に対応するセキュリティコンテキストを切り替えるステップと
を遂行する命令を備える、コンピュータプログラム。
少なくとも２つのメッセージ（ＭｅｓＣ）を、通信装置（ＣＤ）から受信するステップ（Ｓ１）であって、各メッセージ（ＭｅｓＣ）が、ハンドシェイクインデックス（ＩｎｄＨ）を備え、かつサーバ（ＡＳ）が、通信装置（ＣＤ）と、暗号パラメータの組についてネゴシエートするように、ハンドシェイクセッションをトリガする、受信するステップ（Ｓ１）と、
受信された少なくとも２つのメッセージ（ＭｅｓＣ）の各ハンドシェイクインデックス（ＩｎｄＨ）に対して、関連したハンドシェイクインデックス（ＩｎｄＨ）に応じた対応する接続状態インデックス（ＩｎｄＣ）とともに、ネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータを格納するステップ（Ｓ２）であって、前記対応する接続状態インデックス（ＩｎｄＣ）は、プロトコルメッセージフィールドに含まれる単一バイトである、ステップと、
通信装置の１つだけのポートとのセキュア接続を確立するために、送信されるデータの機密度に応じて、最も低い接続状態インデックス（ＩｎｄＣ）とともに格納されたネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータをアクティブ化するステップ（Ｓ３）と、
接続状態を通信装置から受信し、受信された接続状態に対応して対応する接続状態インデックス（ＩｎｄＣ）とともに格納されたネゴシエートされた暗号パラメータの組のうちの１つ以上の暗号パラメータをアクティブ化することによって、受信された接続状態に対応するセキュリティコンテキストを切り替えるステップと
を遂行する命令を備える、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、トランスポート層セキュリティ（ＴＬＳ：Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）プロトコルなどのチャネルセキュリティプロトコルに関する。
【背景技術】
【0002】
ＴＬＳは、２つの通信ホスト、通常はクライアントとサーバとの間にセキュアチャネルを提供するために、ＩＰネットワーク上で広く配備されるプロトコルである。実際に、ＴＬＳは、クライアント／サーバベースアプリケーション（ウェブ閲覧、電子メール、ボイスオーバーＩＰ、テレビ電話、テレビ会議、インターネットファクス送信、またはインスタントメッセージングなど）が通信できるようにすると同時に、盗聴、メッセージの偽造や改ざんを防ぐ。
【0003】
ＴＬＳは、２つの通信エンティティ間の認証およびセキュリティパラメータネゴシエーション用のハンドシェイクプロトコルと、ハンドシェイクプロトコルを介して合意されたパラメータを使用した、これら２つの通信エンティティ間のデータ転送のためのレコードプロトコルとを含む。
【0004】
ＴＬＳセッションの確立のために、ＲＦＣ２２４６で定義されるハンドシェイクプロトコルは、ピアが、レコード層（暗号化アルゴリズムや暗号化鍵など）用のセキュリティパラメータに合意すること、ピア自身を認証すること、ネゴシエートされたセキュリティパラメータをインスタンス化すること、およびエラー状態を互いに報告すること、を可能にする。
【0005】
ＴＬＳセッション内で暗号パラメータを変更することはできない。いったんハンドシェイクが行われると、パラメータは、セッションの間ずっと残っているようになる。種々のパラメータを使う唯一の方法は、別のＴＬＳセッションを開くか、または同時に非セキュア接続を使用することである。
【0006】
第２のＴＬＳセッションが開く時に第１のＴＬＳセッションが閉じていない場合、クライアント上で別のポートを使用する必要がある。
【0007】
いくつかの部分のみが強力な暗号化を必要とする、単一ファイルまたはデータストリームが送信される場合、２つの接続を同時に開く必要がある。その場合、クライアントとサーバは、正しい順番でデータを配信するために、同期化問題に対処しなければならない。
【0008】
現在のＴＬＳプロトコルの欠点と限界を克服することが求められる。
【発明の概要】
【課題を解決するための手段】
【0009】
本概要は、本発明の主題に関する概念を紹介するために提供される。本概要は、請求項に記載された主題の本質的特徴を特定することを目的とせず、また請求項に記載された主題の範囲を決定または制限するのに使用することを目的としない。
【0010】
一実施形態によれば、通信装置とアプリケーションサーバ間のハンドシェイク通信を拡張するための方法が提供され、方法は：少なくとも２つのメッセージを、通信装置から受信するステップであって、各メッセージが、ハンドシェイクインデックスを備え、かつアプリケーションサーバが、通信装置と暗号パラメータの組についてネゴシエートするように、ハンドシェイクセッションをトリガする、受信するステップと、
それぞれの受信されたメッセージに対して、ハンドシェイクインデックスに応じて、接続状態インデックスに対応する、ネゴシエートされた暗号パラメータの組を格納するステップと、
通信装置とのセキュア接続を確立するために、格納された暗号パラメータの組のうちの１つをアクティブ化するステップと
のアプリケーションサーバにおけるステップを含む。
【0011】
本発明は、セッション中に、ファイル転送で、または持続的接続中に、送信されたデータの機密度に応じて、種々の暗号パラメータを選択するための解決策を有益に提供する。
【0012】
本発明は、１つだけのＴＬＳセッションと、クライアント側の１つだけのポートとを使用する。
【0013】
本発明は、セッション中何時でも、同じＴＬＳセッション（再ネゴシエーションなしの）において送信されたデータに対して、セキュリティレベルを適合させることを可能にする。
【0014】
本発明は、機密性の低いデータに対して無駄なプロセッサ消費を減らす一方で、最も機密性の高いデータに対して最大の機密度を与える。
【0015】
本発明は、ＰＢＸのような組込みサーバが、この解決策を使用しない場合よりも多くのクライアントを受け入れることを可能にする。
【0016】
本発明は、セキュリティを強化しなければならない場合、またはより多くのクライアントに対応しなければいけない場合、どのデータがどのセキュリティレベルで送信されるべきかを正確に選択することによって、ハードウェアコンポーネントのアップグレードを回避できる。
【0017】
一実施形態において、メッセージは“ＣｌｉｅｎｔＨｅｌｌｏ”メッセージである。
【0018】
一実施形態において、暗号パラメータの組は、圧縮型、暗号化型、およびメッセージ認証コードアルゴリズムを含む。
【0019】
一実施形態において、ハンドシェイクインデックスは、１バイトで符号化された数である。
【0020】
一実施形態において、アプリケーションサーバは、最も低い接続状態インデックスに対応して格納された暗号パラメータの組をアクティブ化する。
【0021】
一実施形態において、アプリケーションサーバは、接続状態を受信し、受信された接続に対応して格納された暗号パラメータの組をアクティブ化することによって、受信された接続状態に対応するセキュリティコンテキストを切り替える。
【0022】
一実施形態において、不当なハンドシェイクインデックスを有するメッセージを受信した場合、アプリケーションサーバは、ハンドシェイクネゴシエーションをアボートする。
【0023】
本発明はまた、通信装置とサーバ間のハンドシェイク通信を拡張するためのサーバに関し、サーバは：少なくとも２つのメッセージを、通信装置から受信するための手段であって、各メッセージが、ハンドシェイクインデックスを備え、かつサーバが、通信装置と暗号パラメータの組についてネゴシエートするように、ハンドシェイクセッションをトリガする、受信するための手段と、
それぞれの受信されたメッセージに対して、接続状態に対応する、ネゴシエートされた暗号パラメータの組を格納するための手段と、
通信装置とのセキュア接続を確立するために、格納された暗号パラメータの組のうちの１つをアクティブ化する手段と
を備える。
【0024】
本発明はまた、サーバ内で実行できるコンピュータプログラムに関し、前記プログラムは、プログラムが前記サーバ内で実行される場合、本発明による方法に従ったステップを遂行する命令を含む。
【0025】
本発明およびその利点は、以下の説明を、添付図面を参照して考察することによって、よりよく理解されるものとする。
【図面の簡単な説明】
【0026】
【図1】ＴＬＳハンドシェイクの拡張のための本発明の一実施形態による、通信システムの概略ブロック図である。
【図2】本発明の一実施形態による、ＴＬＳハンドシェイクの拡張のための方法のアルゴリズムである。
【発明を実施するための形態】
【0027】
同じ参照番号は、全ての図面において同じ要素、または同じタイプの要素を示す。
【0028】
図１に関して、本発明による通信システムは、通信ネットワークＴＮ（ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ ｎｅｔｗｏｒｋ）と、通信ネットワークを通してそれら間で通信可能な通信装置ＣＤ（ｃｏｍｍｕｎｉｃａｔｉｏｎ ｄｅｖｉｃｅ）およびアプリケーションサーバＡＳ（ａｐｐｌｉｃａｔｉｏｎ ｓｅｒｖｅｒ）とを備える。
【0029】
通信ネットワークＴＮは、有線もしくは無線ネットワーク、または有線もしくは無線ネットワークの組合せであってもよい。
【0030】
通信ネットワークＴＮは、パケットネットワーク、例えば、インターネットまたはイントラネットなどのＩＰ（“インターネットプロトコル”）高速ネットワークとすることができ、または会社固有のプライベートネットワークとすることもできる。
【0031】
序説として、本発明の理解に役立ついくつかの用語および概念が以下に定義される。
【0032】
通信装置ＣＤおよびアプリケーションサーバＡＳは、クライアント−サーバ関係にあり、通信装置ＣＤは、クライアントとして、アプリケーションサーバと相互作用できる。
【0033】
例えば、通信装置ＣＤは、携帯電話、固定電話、コンピュータ、および他の様々な通信用ユーザ機器とすることができる。
【0034】
通信装置ＣＤは、ＴＬＳプロトコルに従って、アプリケーションサーバＡＳにおいて実行される別のアプリケーションと相互作用できるアプリケーションを実行する。
【0035】
非制限的実施例として、アプリケーションは、ウェブブラウザ、メッセージングクライアント、ロッギングアプリケーション、またはリモートデスクトップクライアントとすることができる。
【0036】
通信装置ＣＤは、サーバとのハンドシェイク手順を操作する機能性を有するアプリケーションを実行するクライアントセキュリティモジュールＣＳＭ（ｃｌｉｅｎｔ ｓｅｃｕｒｉｔｙ ｍｏｄｕｌｅ）を備える。クライアントセキュリティモジュールＣＳＭは、特にアプリケーションサーバとの接続用のポートを管理する。
【0037】
アプリケーションサーバＡＳは、通信装置ＣＤにおいて実行されるクライアントアプリケーションと、サーバとして相互作用することのできるいずれかのアプリケーションを実行するウェブサーバとすることができる。サーバセキュリティモジュールＳＳＭ（ｓｅｒｖｅｒ ｓｅｃｕｒｉｔｙ ｍｏｄｕｌｅ）は、特に通信装置との接続用のポートを管理する。
【0038】
アプリケーションサーバＡＳは、クライアントとのハンドシェイク手順を操作する機能性を有するアプリケーションを実行するサーバセキュリティモジュールＳＳＭを備える。
【0039】
通信装置およびアプリケーションサーバが、ＴＬＳセッションの確立を決定した時点で、それらは、ハンドシェイク手順を使用して、接続についてネゴシエートする。
【0040】
アプリケーションサーバＡＳとのハンドシェイクセッションを開始するために、通信装置ＣＤは、“ｍｕｌｔｉｐｌｅ＿ｈａｎｄｓｈａｋｅ”で示される専用フィールドにおいて、ハンドシェイクインデックスを備える“ＣｌｉｅｎｔＨｅｌｌｏ”メッセージを送信するように構成される。
【0041】
ハンドシェイクインデックスは、１バイトで符号化された、０から２５５までの数である（標準固有ハンドシェイクの場合は０）。
【0042】
アプリケーションサーバが、このハンドシェイクインデックスを受信する場合、最初のハンドシェイクが行われると、別のハンドシェイクインデックスを有する別のＣｌｉｅｎｔＨｅｌｌｏメッセージが受信されるかもしれないことが分かる。
【0043】
一実施形態において、ハンドシェイクインデックスが、第１のＣｌｉｅｎｔＨｅｌｌｏメッセージで使用されない場合、ハンドシェイクインデックスは、その後も使用されない。また、ハンドシェイクインデックスが、第１のＣｌｉｅｎｔＨｅｌｌｏメッセージで使用された場合、ハンドシェイクインデックスは、同じセッションでの続く全てのＣｌｉｅｎｔＨｅｌｌｏメッセージで使用される。これは、クライアントとサーバ間の交換が、標準モードまたは“複数ハンドシェイク”モードのいずれかであることを意味する。インデックス付きハンドシェイクが成功する度に、サーバとクライアントにおいて、インデックス付き接続状態が生成される。
【0044】
このため、ＴＬＳハンドシェイクプロトコルは、新しい値：【数1】
【0045】
一実地形態において、拡張の構造体は、以下の通りである：【数2】
【0046】
全てのハンドシェイクが行われると（１から最大２５５までであるが、事実上２が概して最大になるであろう）、アプリケーションサーバは、最も低いインデックスを有する接続状態をアクティブ化する。値０は、“標準モード”と同じである。
【0047】
その後、対応するハンドシェイクにおいてネゴシエートされたパラメータがアクティブ化される（圧縮、暗号化、およびＭＡＣアルゴリズム）。
【0048】
一実施形態において、エラー値は、ｅｎｕｍ ＡｌｅｒｔＤｅｓｃｒｉｐｔｉｏｎ中の【数3】
【0049】
複数ハンドシェイク拡張なしで、メッセージ“ＣｌｉｅｎｔＨｅｌｌｏ”を送信するクライアントに対しては、標準固有ハンドシェイクが適用される。
【0050】
通信装置が、不当なハンドシェイクインデックス（すでに使用されたインデックス、第１のハンドシェイクが拡張なしで送信されていた間に送信された拡張）を有するメッセージ“ＣｌｉｅｎｔＨｅｌｌｏ”を送信する場合、アプリケーションサーバは、複数の方法：致命的レベルの“ｉｌｌｅｇａｌ＿ｈａｎｄｓｈａｋｅ＿ｉｎｄｅｘ”を送信することによってネゴシエーションをアボートする、またはデフォルトポリシーとのネゴシエーションを続ける、で対応することができ、またこの場合、警告レベルの“ｉｌｌｅｇａｌ＿ｈａｎｄｓｈａｋｅ＿ｉｎｄｅｘ”によってクライアントに警告するか、またはしないかを選択することができる。
【0051】
一実施形態において、レコード層コンテンツタイプは、以下のように定義される：【数4】
【0052】
このようなレコードがアプリケーションサーバによって受信される場合、サーバセキュリティモジュールＳＳＭは、セキュリティコンテキストを、望ましい接続状態に切り替え、クライアントによって送信されたものと全く同じ肯定応答メッセージを送信し、またデータ交換は、新しいセキュリティパラメータで継続できる。悪い接続状態インデックスの場合、エラーが戻され、接続状態は変わらない。この場合、送信元は接続を閉じるか、継続するかを選ぶ。
【0053】
図２に関して、本発明の一実施形態による、通信装置とアプリケーションサーバ間のハンドシェイク通信を拡張するための方法は、通信システム内で実行されるステップＳ１からＳ３を含む。
【0054】
ステップＳ１において、通信装置ＣＤのクライアントセキュリティモジュールＣＳＭは、アプリケーションサーバＡＳとのハンドシェイクセッションをトリガする。通信装置ＣＤは、ハンドシェイクインデックスＩｎｄＨを備える第１の“ＣｌｉｅｎｔＨｅｌｌｏ”メッセージＭｅｓＣを、アプリケーションサーバＡＳに送信する。インデックスは、１バイトで符号化された０から２５５とすることができ、“ＣｌｉｅｎｔＨｅｌｌｏ”メッセージの専用フィールド“ｍｕｌｔｉｐｌｅ＿ｈａｎｄｓｈａｋｅ”に提供することができる。
【0055】
メッセージＭｅｓＣはまた、少なくともクライアントの識別子を含む。
【0056】
アプリケーションサーバのサーバセキュリティモジュールＳＳＭは、アプリケーションサーバの識別子といっしょに、“ＳｅｒｖｅｒＨｅｌｌｏ”メッセージを通信装置ＣＤに送信することによって、応答する。
【0057】
その後、アプリケーションサーバおよび通信装置は、暗号パラメータの組についてネゴシエートし、ハンドシェイクセッションを終了する。
【0058】
第１の“ＣｌｉｅｎｔＨｅｌｌｏ”メッセージＭｅｓＣは、ハンドシェイクインデックスＩｎｄＨを含むので、アプリケーションサーバＡＳは、続いて通信装置から受信される全ての“ＣｌｉｅｎｔＨｅｌｌｏ”メッセージもハンドシェイクインデックスを含むことを知る。
【0059】
ステップ２において、ハンドシェイクセッションが終了すると、アプリケーションサーバＡＳのクライアントセキュリティモジュールＣＳＭと、通信装置ＣＤのサービスセキュリティモジュールＳＳＭのそれぞれは、インデックス付き接続状態を生成し、ハンドシェイクセッション中にネゴシエートされた暗号パラメータの組に対応する接続状態インデックスＩｎｄＣを格納する。接続状態インデックスＩｎｄＣは、ハンドシェイクインデックスＩｎｄＨと同じ値であり得る。
【0060】
ステップＳ１およびＳ２は、ハンドシェイクセッションが通信装置によってトリガされる度に繰り返すことができる。
【0061】
アプリケーションサーバＡＳおよび通信装置ＣＤは、各ハンドシェイクセッション用のインデックス付き接続状態を格納する。各ハンドシェイクセッションでは、接続状態インデックスＩｎｄＣは、メッセージＭｅｓＣで受信されたハンドシェイクインデックスＩｎｄＨに左右される。
【0062】
ステップＳ３において、全てのハンドハンドシェイクが行われると、アプリケーションサーバＡＳのサービスセキュリティモジュールＳＳＭは、最も低い接続状態インデックスＩｎｄＣを有する接続状態をアクティブ化する。値“０”は、“標準モード”と定義することができる。
【0063】
アプリケーションサーバＡＳのサービスセキュリティモジュールＳＳＭは、最も低い接続状態インデックスＩｎｄＣに対応して格納された、ネゴシエートされた暗号パラメータの組を識別する。サービスセキュリティモジュールＳＳＭは、識別された暗号パラメータの組をアクティブ化する。例えば、暗号パラメータは、圧縮型、暗号化型、メッセージ認証コード（ＭＡＣ）アルゴリズムを含む。
【0064】
アプリケーションサーバＡＳは、通信装置とのセキュア接続を確立し、セキュア接続は、暗号パラメータの組によって、暗号化、復号される。
【0065】
一例示的実施例では、クライアントは、ハンドシェイク１で暗号化用の２５６ビットＡＥＳプロトコルと、ハンドシェイク２で暗号化用の１２８ビットＡＥＳプロトコルと、についてネゴシエートする。機密性の高いデータは、接続状態１（ＡＥＳ２５６）を使って送信され、“通常の”データは、接続状態２を使用して送信される。このように、機密性の高いデータの量が少ない場合、クライアントおよびサーバは、必要な時に依然として非常にセキュアに通信することができ、同時に、セキュリティがあまり重要ではない場合は、固有接続でプロセッサリソースを節約することができる。
【0066】
別の実施例は、以下の２つのＣｉｐｈｅｒＳｕｉｔｅ：すなわち、機密データ用のＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ２５６と、その他のデータ用のＴＬＳ＿ＮＵＬＬ＿ＷＩＴＨ＿ＮＵＬＬ＿ＮＵＬＬと、についてネゴシエートするクライアントであり、このことは、非機密データが、非セキュアに、また追加のプロセッサリソースもなく送信されることを意味する。この解決策は、処理能力が小さく、機密データ量が少ないクライアントに高いセキュリティを提供するのに非常に役立つであろう。
【0067】
提案された拡張は、セキュアな交換を確実にすることが必要な組込み電話システム（プロセッサリソースが制限された）に特に適している：クライアントが、２つのインデックス付きハンドシェイクを使用して、暗号パラメータの２つの組についてネゴシエートする場合、クライアントは、必要とされるセキュリティに応じて、一方の接続状態を使用するか、または他方を使用するか、選択することができる。この拡張はまた、そのストリームのいくつかの部分のみが非常にセキュアであることを必要とし、他の部分は機密性が低い、音声または映像のデータストリームを多くのクライアントに配信する大きなサーバが使用することができる。
【0068】
本発明は、処理リソースの節約と同時に、交換するデータのいくつかに対して高いレベルのセキュリティの確保を必要とする場合のある組込みシステムにおいて、非常に興味深いものである。
【0069】
本発明はまた、ストリームのくつかの部分がセキュアにされる必要がある場合のデータストリームサーバにとって、または常時接続（キープアライブ接続）を使用する、もしくは機密部分が少ない大型ファイルを交換する、あらゆるクライアント／サーバソリューションにとって興味深いものである。
【0070】
今後、暗号鍵のサイズは、セキュア送信を常に維持するために、処理パワーの増大と並行して大きくなるだろう。この解決策では、交換されたデータの一部のみが最も高いセキュリティレベルであることを必要とする場合、組込みシステムでの処理パワーは、この流れに同じ速さで従うことは必ずしも必要ではない：関心の低い共通データは、それがセキュアにされる必要がなければ、よりセキュアにはされないであろう。
【0071】
本明細書に記載された発明は、ハンドシェイク通信の拡張のための方法およびサーバに関する。本発明の一実施例によれば、本発明のステップは、アプリケーションサーバなどのサーバに組み入れられたコンピュータプログラムの命令によって決定される。プログラムは、前記プログラムが、サーバ内にロードされ、そこで実行される場合、方法のステップを遂行するプログラム命令を備える。
【0072】
その結果、本発明は、コンピュータプログラム、具体的には本発明を実行するのに適した情報媒体上またはその中のコンピュータプログラムにも適用する。このプログラムは、いずれのプログラミング言語を使用してもよく、またソースコード、オブジェクトコード、または部分的にコンパイルされた形、もしくは本発明による方法を実行するのに望ましい他のいずれかの形、などのソースコードとオブジェクトコードとの間の中間コードの形であってもよい。