JPH11331147A

JPH11331147A - デ―タネットワ―クでのシンクライアントとサ―バ装置との間の暗号始動処理をなす方法

Info

Publication number: JPH11331147A
Application number: JP11036454A
Authority: JP
Inventors: Hanging Liao; リアオハンチン; Peter F King; エフキングピーター
Original assignee: Individual
Current assignee: Individual
Priority date: 1998-02-19
Filing date: 1999-02-15
Publication date: 1999-11-30
Also published as: KR19990072733A; US6263437B1; EP0938209A2; EP0938209A3; CN1234662A

Abstract

(57)【要約】【課題】データネットワーク上のクライアント装置と
サーバー装置との間で安全な通信チャンネルを確立する
方法を提供する。【解決手段】クライアント装置のクライアントプライ
ベート値を発生し；該クライアント装置の該クライア
ントプライベート値に基づいてクライアント公開値を発
生し；サーバー装置に該クライアント装置から該クライ
アント公開値からなる鍵リクエストメッセージを送り；
該サーバー装置から該鍵リクエストメッセージへのサー
バーの応答を受け；該クライアントプライベート値及び
該サーバー応答に関して、及び鍵合意プロトコルにより
クライアント側の秘密鍵を発生する各段階からなる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はクライアントコンピ
ュータとサーバーコンピュータとの間の安全で信頼性の
高いデータ通信に関し、よし詳細には無線ネットワーク
又はインターネットであるようなデータネットワークで
の二方向対話通信装置とサーバーコンピュータとの間の
暗号始動処理をなす方法及び装置に関し；ここで移動装
置。セルラー電話、ランドライン電話、インターネット
機器の制御装置、のような二方向対話通信装置は一般に
計算能力、メモリ、グラフィック表示能力などの限られ
たコンピューティング資源を有する。

【０００２】

【従来の技術】電子取引（ｃｏｍｍｅｒｃｅ）はインタ
ーネット上で急速に成長している。電子取引は全てがグ
ローバルなインターネットを介してなされる広範囲なビ
ジネス支援サービス、物資、製品、専用化された製品、
専用に作られた用品及びサービス用の通商支援システ
ム；注文及び補給支援システム；設置支援システム；管
理情報及び統計報告システムと共になされるよう設計さ
れた統合的なコンセプトである。しかしながらインター
ネットは広く公開されており、世界にわたり相互接続さ
れたコンピュータ及び電子装置の公共及び国際ネットワ
ークである。インターネットでビジネス取引するために
は会社又は個人はその間で個人的な通信をするために効
率的で信頼性の高い安全な方法を有さなければならな
い。ほとんどがランドラインネットワークのコンピュー
タ装置であるインターネットにわたり行き来する所有者
の情報を保護する目的で多くの努力がなされてきた。

【０００３】現在進行中の努力の一つはクライアントコ
ンピュータとサーバーコンピュータとの間の個人的な通
信セッションを確実にするために暗号技術を用いること
である。暗号技術は通信チャンネル上で盗聴する誰に対
しても情報の内容を公開することなく不確かな通信チャ
ンネルにわたり情報を伝送する方法を提供する。暗号技
術でのエンクリプション処理を用いて、ある集団が承認
されていない第三の集団によるアクセスから伝送中のデ
ータの内容を保護し、一方で意図されている集団は対応
するデクリプション処理を用いてデータを読み取ること
が可能である。エンクリプションは一組のデータをある
読み取り不可能な「暗号化された」形に変換する処理で
ある。その目的は情報の実際の内容を暗号化されたデー
タにアクセスするかも知れない盗聴者のような意図され
ていない受信者から隠すことによりプライバシーを確保
することである。デクリプションはエンクリプションの
逆の処理である。デクリプションはエンクリプトされた
データを実際の内容にアクセスし得るようなある理解可
能な形に変換して戻す処理である。エンクリプション及
びデクリプションの両方は通常「鍵」と称されるある秘
密の情報の使用を必要とする。用いられたエンクリプシ
ョン機構の型に依存して同じ鍵がエンクリプション及び
デクリプションの両方に用いられる一方で、他の機構に
対してはエンクリプションとデクリプションに対して用
いられる鍵が異なる。

【０００４】伝統的な暗号技術は同じ秘密の鍵を知り、
用いるメッセージの送信者と受信者に基づく：送信者は
メッセージをエンクリプトするために秘密の鍵を用い、
受信者はメッセージをデクリプトするために同じ鍵、し
ばしば秘密の鍵と称される、を用いる。故に通信チャン
ネルを安全に保つために送信者と受信者以外のユーザー
は誰も秘密の鍵にアクセスを許容されない。この方法は
秘密鍵又は送信者と受信者との間で対称的なプライベー
ト鍵を伝送するための安全なチャンネルが必要とされ
る。

【０００５】公開鍵暗号として知られているエンクリプ
ションの比較的新しいコンセプトは２つの異なる鍵を用
いる。２つの鍵の公開鍵暗号システムでは各ユーザーが
２つの鍵を有する：公開されている公開鍵と秘密に保た
れているプライベート鍵である。公開鍵を受け取ってい
るユーザーにメッセージをエンクリプトするために送信
者は受取者の公開鍵を用いてメッセージをエンクリプト
する。受取者は自分のプライベート鍵を用いてメッセー
ジをデクリプトする。斯くして安全な通信が安全なチャ
ンネルを通して秘密鍵を伝送する必要なしに可能とな
る。

【０００６】公開鍵暗号法の第一の利点はプライベート
鍵が誰に対しても伝送又は公開される必要が決してない
ことである。これに対して秘密鍵暗号法では秘密鍵又は
それを生成するための情報は転送されなければならない
（手渡し又は安全な通信チャンネルを用いるかのいずれ
かで）。しかしながら暗号に対する公開鍵を用いる知ら
れている一つの欠点はエンクリプションの速度である。
特に他の現在利用可能な公開鍵エンクリプション方法よ
り顕著に速い人気のあるプライベート鍵エンクリプショ
ン方法が存在する。故にエンクリプション速度は限定さ
れたコンピューティング資源のシンクライアント装置を
含む安全な通信セッションで用いられるときにプライベ
ート鍵暗号法対公開鍵暗号法の比較を考えるときに非常
に重要な要因となる。いわゆるシンクライアント（ｔｈ
ｉｎｃｌｉｅｎｔ）装置は移動コンピューティング装
置、セルラー電話、ランドライン電話、又はインターネ
ット機器制御装置のような２方向対話通信装置であると
考えられる。シンクライアント装置は一般にできる限り
小さく、軽く、低消費電力、経済的かつ携帯可能に設計
される。そのようなシンクライアント設計はそのコンピ
ューティング能力が典型的には多分、例えば典型的なデ
スクトップ又は携帯コンピュータの能力の１パーセント
以下であり、そのメモリ容量は通常２５０キロバイト以
下である。加えてシンクライアントとランドラインサー
バーコンピュータとの間の通信は低帯域幅を特徴とする
無線ネットワークをしばしば介しており、その通信時間
に対する料金は高価である。故にプライベート鍵暗号法
は速度の要求に適合するためにシンクライアントとラン
ドラインコンピュータとの間の通信セッションでしばし
ば用いられる。

【０００７】２つの信頼できる通信装置間のプライベー
トエンクリプション鍵の配布は暗号始動（ｉｇｎｉｔｉ
ｏｎ）処理と称される。秘密の方法でのプライベートエ
ンクリプション鍵の相互の配布は暗号始動方法の一つと
して用いられ得るが、一つのランドラインサーバーコン
ピュータと通信する数百或いは数千のシンクライアント
が存在するときにそのコストは顕著に高い。更にこの方
法に関する人間の誤りと信頼性はその実用化の可能性を
困難にしている。故に各シンクライアントそれぞれとラ
ンドラインサーバーコンピュータとの間のプライベート
鍵の自動的な配布を許容する汎用の暗号始動処理への強
いニーズが存在する。

【０００８】鍵取り決め（ａｇｒｅｅｍｅｎｔ）プロト
コールが２つの通信集団の各側で秘密鍵での取り決めを
なすためにそれら２つの集団に対して単独で使用される
がその認証は提供されない。鍵取り決めプロトコールの
使用は取り決めされた鍵がどのような方法でも攻撃され
ない保証はない。そのようなスキームでの認証（ａｕｔ
ｈｅｎｔｉｃａｔｉｏｎ）の欠如はこれらの取り決めさ
れた鍵を長期間安全に維持されるために充分強くなくす
る。これらのスキームを適所で認証を有するように変更
する解決策が存在するが、それは通信装置内に予め装填
されたある秘密の情報を必要とし、故にシンクライアン
ト装置とサーバーコンピュータとの間の交信がより多く
なるという結果を生ずる。付加的な交信はシン装置のコ
ンピューティング性能及びメモリーの顕著な増加を更に
必要とし、サーバーコンピュータから到来した情報の潜
在を増加し、これは一般に望ましくない。故に最小のコ
ンピューティング能力とメモリーを用いる２つの通信装
置間の暗号始動処理をなす暗号始動処理に対する更なる
ニーズが存在する。

【０００９】

【発明が解決しようとする課題】本発明の目的はデータ
ネットワーク上のクライアント装置とサーバー装置との
間で安全な通信チャンネルを確立する方法を提供するこ
とにある。

【００１０】

【課題を解決するための手段】上記目的は、クライアン
ト装置のクライアントプライベート値を発生し；該クラ
イアント装置の該クライアントプライベート値に基づい
てクライアント公開値を発生し；サーバー装置に該クラ
イアント装置から該クライアント公開値からなる鍵リク
エストメッセージを送り；該サーバー装置から該鍵リク
エストメッセージへのサーバーの応答を受け；該クライ
アントプライベート値及び該サーバー応答に関して、及
び鍵合意プロトコルによりクライアント側の秘密鍵を発
生する各段階からなる方法により達成される。

【００１１】

【発明の実施の形態】本発明のこれら及びその他の特
徴、利点は以下に図面と請求項を参照した詳細な説明に
よってよりよく理解される。表記及び述語以下の本発明の詳細な説明において、多くの具体的詳細
が、本発明を完全に理解するために述べられる。しかし
ながら本発明がこれらの具体的な詳細なしに実施されう
ることは当業者にとって明らかである。次に良く知られ
た方法、手順、部品、回路は理解を容易にするために詳
細には説明しない。

【００１２】以下の本発明の詳細な説明はほとんど手
順、段階、論理ブロック、処理、ネットワークに接続し
たデータ処理デバイスに似ている他の記号表現に関して
行われる。これらの処理の説明及び表現は当業者が他の
当業者にその仕事の内容を最も効率的に伝達するために
使用する手段である。本発明はデータネットワーク上の
サーバー装置を有する対話的通信装置間の暗号始動処理
をなす方法及び装置を提供する。以下に詳細に記載され
るアーキテクチャーに沿った方法は所望の結果を導く処
理又は段階の自己完結的なシーケンスである。これらの
段階又は処理は物理的な量の物理的な操作を必要とする
ものである。必要と言うわけではないが通常これらの量
は記憶され、転送され、結合され、比較され、表示され
うる電気信号の形、さもなければコンピュータシステム
又は電気的コンピューティング装置で取り扱われるよう
な形を取る。通常の使用の理由に対してこれらの信号
を、ビット、値、要素、シンボル、操作、メッセージ、
こう、数、又は同様なものと称することは原理的にある
場合には便利であることが明らかである。これらの類似
の用語の全ては適切な物理的な量に関連し、これらの量
に適用される単に便利なラベルである。特に言及するこ
となしに以下の記述から明らかであるように本発明を通
して「処理」又は「コンピューティング」又は「照合」
又は「表示」等々のような用語を用いることはコンピュ
ーティング装置又は他の電子装置内の物理的な量として
表された他の同様に表されたデータにコンピューティン
グ装置のレジスタ及びメモリ内の物理的な量として表さ
れたデータを操作し、変換するコンピューティング装置
の動作及び処理に関する。ディフィ・ヘルマン鍵取り決めプロトコールへの導入ディフィ・ヘルマン（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）
鍵取り決めプロトコルはまた指数関数鍵取り決めと称さ
れ、二人のユーザーにいかなる事前の秘密もなしに安全
でない媒体上で秘密鍵を交換することを許容する。この
プロトコルは２つのシステムパラメータｐ，ｇを有す
る。ｐ，ｇの両方ともシステム内の全てのユーザーに公
開され、彼らにより用いられ得る。パラメータｐは最初
の数であり、パラメータｇ（通常ジェネレータと称され
る）はｐ以下の整数であり、これは最初のｐを法とし
て、それ自身をある回数乗算したときに１からｐ−１ま
での全ての要素（ｅｌｅｍｅｎｔ）を発生することが可
能である。集団Ａトランスデューサ集団Ｂがディフィ
・ヘルマン鍵取り決めプロトコルを用いて秘密鍵を共有
することに合意しようとしている場合を考える。彼らは
以下のように進める。第一に集団Ａはランダムプライベ
ート値ａを発生し、集団Ｂはランダムプライベート値ｂ
を発生する。次に彼らはパラメータｐ，ｇと彼らのプラ
イベート値を用いて彼らの公開値を得る。集団Ａの公開
値はｇ^aｍｏｄｐであり、集団Ｂの公開値はｇ^bｍｏ
ｄｐである。次に彼らは彼らの公開値を交換する。最
終的に集団Ａはｋ_ab＝（ｇ^b）^aｍｏｄｐを計算し、
集団Ｈはｋ_ba＝（ｇ^a）^bｍｏｄｐを計算する。ｋ_ab＝
ｋ^ba＝ｋである故に集団Ａと集団Ｂはここで秘密鍵ｋを
共有している。このプロトコルはその安全性に対する離
散的な対数問題に依存する。それは共有された秘密鍵素
数ｐが充分大きいときに与えられた２つの公開値ｇ ^aｍ
ｏｄｐとｇ^bｍｏｄｐからｋ＝ｇ^ab ｍｏｄｐを
計算することが実行不可能であることを仮定している。

【００１３】ディフィ・ヘルマン鍵交換は媒介者（ｍｉ
ｄｄｌｅｍａｎ）攻撃に弱い。この攻撃で、対向する集
団Ｘは集団Ａの公開値を横取りし彼自身の公開値を集団
Ｂに送る。集団Ｂが彼の公開値を送信したときに集団Ｘ
はそれを彼自身の数と交換し、それを集団Ａに送る。斯
くして集団Ｘと集団Ａとは共有された鍵で一致し、集団
Ｘと集団Ｂとは他の共有された鍵で一致する。この交換
の後に集団Ｘは集団Ａ又は集団Ｂにより送られたいかな
るメッセージも簡単にデクリプトし、それを適当な鍵で
エンクリプトして正しい集団に送信する前にそれらを読
み、変更することが可能である。この弱点はディフィ・
ヘルマン鍵交換は参与者を信用できないからである。

【００１４】媒介者の攻撃を克服するために認証された
ディフィ・ヘルマン鍵取り決めが導入された。イミュニ
ティは２つの集団がデジタル署名の使用により相互に信
頼化することを許容することにより達成される。基本的
な構想は以下の通りである。交換プロトコルの前に２つ
の集団ＡとＢはそれぞれ公開／プライベート鍵の対及び
公開鍵に対する証明を有する。交換プロトコル中に集団
Ａはそのプライベート鍵を用いてあるメッセージ上の署
名を計算し、集団Ｂにその署名とその公開鍵証明と共に
公開値ｇ^aｍｏｄｐを送る。集団Ｂはまたそのプライ
ベート鍵を用いてあるメッセージ上の署名を計算し、集
団Ａにその署名とその公開鍵証明と共に公開値ｇ^aｍｏ
ｄｐを送る。集団Ｘがなお集団ＡとＢの間のメッセー
ジを横取りしても、それは集団Ａのプライベート鍵と集
団Ｂのプライベート鍵がなければ署名を偽造できない。
故に強化されたプロトコルは媒介者の攻撃を退けうる。好ましい実施例本発明の原理によれば２つの通信集団に同一の秘密鍵を
供給するための暗号始動処理はデータネットワークにわ
たるシンクライアントとサーバーコンピュータとの間で
なされる。シンクライアント装置は通常制限されたコン
ピューティング能力と制限された作業メモリを有する。
サーバーコンピュータは複数のそのようなシンクライア
ント装置と通信する。両方の側の秘密鍵の安全を確実に
し、ネットワークのトラフィックを減少するために公開
値の一対のみがデータネットワークのシンクライアント
装置とサーバーコンピュータとの間で交換される。各側
はディフィ・ヘルマン鍵取り決めプロトコルのような一
般に用いられる鍵取り決めプロトコルにより受信された
対向する側の公開値に沿ってそれ自身の秘密鍵を自己発
生されたプライベート値から発生する。発生された秘密
鍵が両側で同一であることを確実にするために確認処理
の後に発生されたクライアント側の秘密鍵及び２つの発
生された秘密鍵から発生された署名の手動による確認に
よりエンクリプトされたメッセージを交換することが続
く。秘密鍵はエンクリプトされたメッセージが他の秘密
鍵によりうまくデクリプトされたときに同一であること
が証明され、署名が確かめられたときに安全である。ネ
ットワークトラフィックを減少するために確認処理はサ
ーバーコンピュータとの安全かつ信頼できる通信セッシ
ョンを確立するためのシン装置からのセッションリクエ
ストでピギーバック方式でなされる。本発明は顕著なコ
ンピューティング性能及び作業用のメモリを必要とせ
ず、シンクライアントそれぞれとサーバーコンピュータ
との間の秘密鍵の自動的な配布を可能にする。

【００１５】ここで図面を参照するに同一の符号が同一
の部分を参照するよう図面を通して用いられる。図１は
本発明が実施されるデータネットワーク１００の概略が
示される。データネットワーク１００は一般に無線ネッ
トワークと称されるエアネット１０２と、一般にランド
ラインネットワークと称されるランドネット１０４から
なる。それぞれの中でデータ伝送のための通信媒体とし
て動作する。エアネット１０２はデータ伝送が空間を媒
介しており、キャリアネットワークと称される。何故な
らば各エアネットは例えばＡＴ＆Ｔ及びＧＴＥのような
キャリアにより制御され操作されるからである。各キャ
リアはエアネット１０２に対してＣＤＰＤ、ＣＤＭＡ，
ＧＳＭ，ＴＤＭＡのようなそれ自身の通信スキームを有
する。ここで相互交換可能に使用されるランドネット１
０４はグローバルインターネット、インターネット又は
他の個人的なネットワークである。１０６を参照するに
これはアンテナ１０８を介してエアネット１０２と通信
可能な移動装置、セルラー電話、ランドライン電話、又
はインターネット機器制御器である移動装置である。エ
アネット１０２は複数の２方向通信装置と同時に通信で
き、図１にはその一つの代表例が示されているのみであ
る。同様にインターネット１０４と複数のデスクトップ
ＰＣ１１０及び複数のサーバーコンピュータ１１２が接
続され、図１にはそのひとつのみが代表として示される
のみである。図示されているＰＣ１１０はＮＥＣ社から
販売されているパーソナルコンピュータＳＰＬ３００で
ある。ＰＣ１１０はハイパーテキストトランスポートプ
ロトコル（ＨＴＴＰ）を用いてインターネット１０４上
の情報にアクセスするためにネットスケープナビゲータ
ー又はマイクロソフトインターネットエクスプローラの
ようなハイパーテキスト記述言語（ＨＴＭＬ）ウェブブ
ラウザを実行する。例えばＰＣ１１０はサンマイクロシ
ステム社から販売されているワークステーションである
ウェブサーバー１１２に記憶されたＨＴＭＬ情報にアク
セスする。ＰＣ１１０がウェブサーバーになるようにそ
の中のアクセス可能な情報を記憶することは当業者に明
らかである。

【００１６】インターネット１０４とエアネット１０２
との間にその間でデータ通信をなすためにリンクサーバ
ー又はプロキシ（ｐｒｏｘｙ）サーバーコンピュータ１
１４が存在する。プロキシサーバーコンピュータ１１４
はまたリンクサーバー又はゲートウエイサーバーコンピ
ュータと称され、マッピング又は転送機能をなすワーク
ステーション又はパーソナルコンピュータである。例え
ばプロキシサーバーコンピュータ１１４は移動装置１０
６がサーバー１１２又はＰＣ１１０それぞれのいずれか
一つと通信するために一のプロトコルから他へと情報を
マップする。

【００１７】インターネット１０４で用いられる一の通
信プロトコルは良く知られているハイパーテキストトラ
ンスファープロトコル（ＨＴＴＰ）又はＨＴＴＰＳ、Ｈ
ＴＴＰの安全化されたバージョンである。ＨＴＴＰはハ
イパーテキスト記述言語（ＨＴＭＬ）情報を搬送するた
めの接続をなすよう良く知られているトランスポート制
御プロトコル（ＴＣＰ）を用いる。プロキシサーバー１
１４内の例えばＨＴＭＬウェブブラウザはウェブサーバ
ー１１２に記憶されたＨＴＭＬ情報にアクセスする。図
１の実施例ではエアネット１０２を介する移動装置１０
６とプロキシサーバー１１４との間の通信プロトコルは
ハンドヘルドデバイストランスポートプロトコル（ＨＤ
ＴＰ）又は安全なアップリンクゲートウエイプロトコル
（ＳＵＧＰ）であり、これは好ましくはユーザーデータ
グラムプロトコル（ＵＤＰ）で走ることが好ましい。Ｈ
ＤＴＰは移動装置１０６内の小さなウェブブラウザのプ
ロキシサーバー１１４への接続を制御する。図１の実施
例で移動装置１０６のブラウザはハンドヘルドデバイス
記述言語（ＨＤＭＬ）ブラウザである。ハンドヘルドデ
バイス記述言語（ＨＤＭＬ）はタグに基づくドキュメン
ト言語であり情報が表示装置上に如何に表示され得るか
を特定するコマンド又はステートメントの組からなり、
ＨＴＭＬと類似である。ＨＤＭＬは情報が移動装置１０
６の小さなスクリーン上に如何に表示されるかを「カー
ド」で特定するよう設計された特別の記述言語である。
通常は多数のカードが移動装置１０６とプロキシサーバ
ー１１４との間で交換されうるＨＤＭＬ情報の最小ユニ
ットであるデッキにグループ化される。ＨＤＭＬカード
及びデッキについてのこれ以上の記述は以下に適切に記
載される。「ＨＤＴＰ仕様」とタイトルされたＨＤＴＰ
の仕様及び「ＨＤＭＬ２．０言語リファレンス」とタイ
トルされたＨＤＭＬはその全体をここに参考として引用
する。

【００１８】ＨＤＴＰはＨＴＴＰと類似であるが、その
オーバーヘッドを被らないセッションレベルのプロトコ
ルであり、顕著に少ないコンピューティング能力及びメ
モリを有するシン装置で使用されるよう高度に最適化さ
れている。更に当業者に明らかなようにユーザーデータ
グラムプロトコル（ＵＤＰ）は情報が交換される前にク
ライアント装置とサーバ装置との間で確立される接続を
必要とせず、これはクライアントとサーバとの間のセッ
ションの形成中に多数のパケットを交換する必要を除去
する。交信中に非常に少数のパケットを交換することは
ランドライン装置と効率的に対話するために非常に制限
されたコンピューティング性能とメモリを有する移動装
置に対する望ましい特徴の一つである。

【００１９】図２を参照するに本発明を実施するために
図１で用いられる典型的なＧＳＭデジタル移動電話１２
０のブロック図を示す。移動電話１２０のハードウエア
部品のそれぞれは当業者に知られており、ここでは詳細
に説明しない。スクリーン１１６とキーパッド１１８を
用いて電話１２０のユーザーはデータネットワークのサ
ーバー（図２には示されない）と対話的に通信可能であ
る。本発明の一実施例によれば本発明のコンパイルさ
れ、リンクされた処理はクライアントモジュール１２４
と支援モジュール１２６としてＲＯＭ１２２に記憶され
る。キーパッド１１８を用いた所定のキーシーケンスの
作動で物理層（ｌａｙｅｒ）プロセッサ又はマイクロ制
御器１２８はＲＯＭ１２２内のクライアントモジュール
１２４を用いたサーバー装置（図示せず）に対して通信
セッションリクエストを開始する。通信セッションを確
立して、電話１２０は典型的にサーバー装置から単一の
ＨＤＭＬデッキ（ｄｅｃｋ）を受けそのデッキをＲＡＭ
１３４内にキャッシュとして記憶する。ＨＤＭＬデッキ
又はデッキはシンクライアント装置とサーバー装置との
間で交換可能な最小単位のＨＤＭＬ情報である。各デッ
キはＵＲＬのような唯一のアドレス識別子を有し、一以
上のカードを含む。カードは表示スクリーン１１６上の
スクリーン表示を発生するよう要求された情報を含む。
故にデッキはスクリーン表示の群にすぎない。カードデ
ッキ内のカードの数は移動装置及びエアーネットワーク
内の資源の効率的な使用をなすように選択される。表示
ドライバ１３０はＲＡＭ１３４内のデッキから情報を受
け、翻訳する。スクリーン１１６がそれによる情報を表
示するようにする。キーパッドドライバ１３２はキーパ
ッド１１８内のどのボタン又はキーが押されたかを示す
信号を受け、その信号をマイクロ制御器１２８により理
解される表現に変換し、それは次に例えばどの選択が電
話のキーパッド１１８を通してなされたかに依存して必
要な場合にはデッキ内のそれぞれのカードを動作するこ
とにより、又は新たなデッキに対するサーバーに対する
新たなリンクにより応答する。

【００２０】図３を参照するに本発明のアーキテクチャ
ーが示される。エアネット１０２に結合された複数の移
動装置を代表する３つが３０２、３０４、３０６により
示され、同様に３１０、３１２、３１４によりランドネ
ット１０４と結合された複数のランドライン装置の３つ
が示される。リンクサーバー装置３７０はエアネット１
０２をランドネット１０４に結合し、故にいずれの移動
装置もエアネットを経由し、リンクサーバー３７０を通
してランドネット１０４を介してランドライン装置と通
信可能である。移動装置は図２に示したものの一つであ
ることは当業者には明らかである。本発明の記載を実施
するために移動装置３０２とリンクサーバー３７０の内
部ブロック図はそれぞれ示される。他のプロセッサ及び
ハードウエアは当業者に良く知られており、ここでは詳
細に説明しない。３０２のような移動装置のそれぞれ
は装置ＩＤ３１６を割り当てられる。装置ＩＤ３１６は
装置の電話番号又は２０４．１６３．１６５．１３２：
０１９０５のようなＩＰアドレス及びポート番号の組合
せであり、ここで２０４．１６３．１６５．１３２はＩ
Ｐアドレスであり０１９０５はポート番号である。装置
ＩＤ３１６はリンクサーバー３７０内のキャリアにより
移動装置３０２に対する加入者アカウント３２０を作動
させる手続の一部分として承認された加入者ＩＤ３１８
に更に関連づけられる。加入者ＩＤ３１８は例えばＡＴ
＆Ｔ無線サービスによる８６１２３４５６７−１０９０
０＿ｐｎ．ｍｏｂｉｌｅ．ａｔｔ．ｎｅｔのような形を
取りこれは移動装置３０２に対して唯一の識別番号であ
る。換言すれば移動装置３０２、３０４、３０６のそれ
ぞれはリンクサーバー装置３７０でのそれぞれのユーザ
ーアカウントに対応する唯一の装置ＩＤを有する。以下
の説明は移動装置３０２及び関連するアカウント３２０
に重点を置き、この説明はリンクサーバー３７０と同時
の通信で複数の移動装置に等しく適用されうる。

【００２１】装置ＩＤ３１６によりインデックス化され
た加入者アカウント３２０は加入者番号３１８、ユーザ
ー情報３２２、鍵状態３２１、署名３２５のような加入
者情報からなるデータ構造である。ユーザー情報（ｉｎ
ｆｏ）３２２はアカウント構造、ユーザー名、ＵＲＬ、
装置バージョン、日付などの他のアカウント関連情報を
含む。鍵状態３１は共有された秘密鍵の状態を示す。署
名３２５はＲＣ５のような対称なエンクリプションアル
ゴリズムを用いることにより共有された秘密鍵から生じ
た結果である。アカウントが新たに確立されたときに鍵
状態３２１は「交換」に設定され、署名は署名３２５で
利用可能ではない。鍵状態及び署名のより詳細は以下に
説明される。アカウントのＵＲＬは例えばｗｗｗ．ａｔ
ｔ．ｃｏｍ／Ｐｏｃｋｅｔｎｅｔのような形を取り、こ
れはエアネット１０２がＡＴ＆Ｔ無線サービスにより作
動されていることを示す。リンクサーバー３７０が多数
の移動装置にサービスを提供するときに好ましくはデー
タベースサービス３２８に保持されるそのようなアカウ
ントが同数存在し、そのアカウントのそれぞれは移動装
置の一つにそれぞれに割り当てられる。データベース
サーバー３２８は本発明では必要ないものである。アカ
ウントを記憶する手段を提供するデータベースサーバー
３２８はリンクサーバー３７０内の別のコンピュータ又
はメモリ記憶でありうる。リンクサーバー３７０はラン
ドライン装置の一つであり、ランドライン装置のいずれ
もリンクサーバー３７０として機能し、装置内で用いら
れるアプリケーションに依存してクライアント装置又は
サーバー装置のいずれかである。以下の説明での可能な
曖昧さを最小にするために移動装置は以下ではクライア
ント装置又はシンクライアント装置と称し、リンクサー
バー３７０は単にサーバー装置と称する。

【００２２】上記のようにコンパイル及びリンクされた
本発明の処理（プロセス）はクライアント装置３０２の
クライアントモジュール３３２としてメモリに記憶され
る。同様に本発明の対応するコンパイルされリンクされ
た処理はサーバー装置３７０のサーバーモジュール３２
０としてメモリにロードされる。クライアント装置３０
２とサーバー装置３７０との間の通信はクライアントモ
ジュール３３２とサーバーモジュール３２０との間で一
対のユーザーデータグラムプロトコル（ＵＤＰ）インタ
ーフェイス３３６、３２４を介してなされる。クライア
ント装置３０２のユーザーが例えば特定のストック上に
価格情報をフェッチするためにサーバー装置３７０と対
話するために所定のキーを押すときに、クライアントモ
ジュール３３２はＵＤＰインターフェイス３３６にＨＤ
ＭＬデッキの形で対応するリクエストを送り、これは更
にそのリクエストをサーバー装置３７０内の対向する部
分のＵＤＰインターフェイス３２４に転送する。リクエ
ストはリンクサーバー３７０がストック価格情報のホス
トでない場合にはリンクサーバー３７０により処理され
インターネット上の他のサーバー装置３１０、３１２に
更に接続される。そうでなければストック価格情報が３
４０でのＨＤＭＬデッキの一以上のカード内に偶然パケ
ット化されている。ＨＤＭＬデッキはサーバーモジュー
ル３２０によりＵＤＰインターフェイス３３６、３２４
を通してクライアント３０２に送り返される。受信され
たＨＤＭＬデッキで好ましくＲＡＭ内にキャッシュされ
て、クライアントモジュールはクライアント装置３０２
の表示スクリーン上にカードを表示する。クライアント
装置３０２とリンクサーバー装置３７０との間の交換さ
れる情報が秘密にされるひつようのある場合にはエンク
リプション／デクリプション技術を用いる安全な通信が
いかなる秘密情報が交換される前に双方で確立されなけ
ればならない。

【００２３】図４を参照するに暗号始動処理がクライア
ント装置３０２とリンクサーバー装置３７０との間でな
されたときにそれぞれのＵＤＰインターフェイスの対を
通したクライアントモジュール３３２とサーバーモジュ
ール３２０との間の例示的な対話が示される。クライア
ント装置３０２がそのユーザーによりリンクサーバー装
置４７０と対話するように指示されたときにクライアン
トモジュール３３２はクライアント装置３０２とリンク
サーバー装置３７０との間の通信セッションを形成する
ためにサーバーモジュール３２０にセッションリクエス
ト信号４０２（ＳＲ４０２）を送る。ＳＲ４０２の信号
成分はクライアント装置３０２の状態に依存し、一般的
にそれからなる。

【００２４】セッションＩＤ−クライアント装置３０２
からリンクサーバー装置４７０への全てのリクエストを
識別する識別子；セッションの形成をリクエストする場
合には、セッションＩＤは常に０に割り当てられる；暗
号−通信プロトコルで利用可能な多数のエンクリプショ
ンスキームが存在する中でクライアントが現在用いてい
るエンクリプションの選択を表す２バイトの数；バージ
ョン−ＰＤＵのような通信プロトコルのアンダーレイフ
ォーマットを決定するために用いられるＨＤＴＰプロト
コルバージョンを表す一バイトの数；型（タイプ）−ど
の装置がクライアントかを表す固定された５バイトの数
（例えば２ＰＣＳＩはクライアントがＰＣＳＩ電話バー
ジョン２であることを意味する）；装置ＩＤ−装置識別
子又はクライアント識別子を表す２５５バイトまでの変
数；ヘッダ−セッション全体に適応され、それに続くサ
ービスリクエスト又はセッションに特有のパラメータに
自動的に適用され、（故にヘッダーは一般に現在のセッ
ションまでサーバーでキャッシュ化される）トークン／
値の対からなる３２７６７バイトまで；Ｃ−ノンス（ｎ
ｏｎｃｅ）−クライアントがそれに続くサーバーの認証
（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）のために用いられる
通常２バイトの繰り返し不可能な（ｎｏｎ−ｒｅｐｅａ
ｔａｂｌｅ）数で表されるクライアントノンス。

【００２５】変更されたＣ−ノンス−サーバーがそれに
続くクライアントのノンスの認証をなすために用いられ
る変更されたクライアントノンスのバージョン。より詳
細にはＳＲ４０２の暗号は特定のエンクリプションアル
ゴリズムに対する識別子と関連するそのパラメータを含
み、即ち暗号の第一のバイトはエンクリプションアルゴ
リズムと鍵の大きさ（例えば米国に対して１２８ビット
又は外国に対して４０ビット）とそれのセキュリティア
タッチメントの内容を表し、暗号の第二のバイトは第一
のバイトに関する付加的なパラメータを示す。例えば第
一のバイトの値１はエンクリプションアルゴリズムがブ
ロック暗号ＲＣ５であり、その鍵の大きさは１２８バイ
トであり、それの２バイトチェックサムがメッセージ認
証コード（ＭＡＣ）として用いられ、故にブロック暗号
に対する初期化ベクトル（ＩＶ）はネットワークにわた
り送信されず、必要な場合にはパディング（ｐａｄｄｉ
ｎｇ）バイトが付加される。ブロック暗号及び種々の利
用可能なエンクリプションアルゴリズムについての情報
は現在の暗号に関するほとんどの本に記載され、又は１
９９５年８月のＭ．Ｊ．Ｂ．Ｒｏｂｓｈａｗ，”Ｂｌｏ
ｃｋＣｉｐｈｅｒｓ”、技術レポートＴＲ−６０１、バ
ージョン２．０，ＲＳＡ研究所、９４０６５−１０３
１，カリフォルニア州Ｒｅｄｗｏｏｄ市Ｍａｒｉｎｅ
Ｐａｒｋｗａｙ１００を参照。暗号の識別子を所望で
あれば安全でないセッションを識別するために唯一の値
に割り当てることが可能である。Ｃ−ノンスは最初に繰
り返し不可能な数であり、クライアントでランダムに発
生されその変更されたバージョンである変更されたＣ−
ノンスは動作的な関係を通してＣ−ノンスから発生され
る。例えば変更されたＣ−ノンスは以下兄説明する排他
的ＯＲ関係（

【００２６】

【数１】

【００２７】を用いて形成される。

【００２８】

【数２】

【００２９】Ｃ−ノンス及び変更されたＣ−ノンスの両
方はクライアント装置３０２により所有される秘密エン
クリプション鍵を用いる暗号によりエンクリプトされ
る。変更されたＣ−ノンスの目的はＣ−ノンスとその変
更されたＣ−ノンスとの関係を調べることによりＣ−ノ
ンスが正確にデクリプトされ、承認されたことを確実に
する手段でＳＲを受けるサーバーを提供することにあ
る。サーバー装置３７０がクライアント装置３０２の一
つと同一である許容された秘密鍵を有する場合にはエン
クリプトされたＣ−ノンス及び変更されたＣ−ノンスは
許容された秘密鍵によりデクリプトされなければなら
ず、それらの間の関係は同じままである。換言するとＳ
Ｒメッセージ４０２は以下のように表される：ＳＲ＝｛セッションＩＤ、暗号、バージョン、型、装置
ＩＤ、ヘッダー、Ｅｎｃｒｙ［Ｃ−ノンス、変更された
Ｃ−ノンス］｝；ここでＥｎｃｒｙ［］はブラケット内のパラメータまた
は内容がこれによりエンクリプトされることを示す。

【００３０】サーバーモジュール３２０はＳＲが受信さ
れたときにＥｎｃｒｙ［Ｃ−ノンス、変更されたＣ−ノ
ンス］をデクリプトしようとする。デクリプション処理
から、サーバー装置３７０は双方で秘密鍵の状態を決定
しうる。「許容（Ｖａｌｉｄ）」、「確認（Ｖｅｒｉｆ
ｙ）」、「交換（Ｅｘｃｈａｎｇｅ）」、「強制（Ｆｏ
ｒｃｅ）」の４つの可能な秘密鍵状態が存在する。

【００３１】ＳＲ４０２のエンクリプトされたメッセー
ジのデクリプションの成功から得られた「許容」鍵状態
は双方の秘密鍵の対が同一であり、故にクライアント装
置３０２又はサーバー装置３７０の各々が共有された秘
密鍵（ＳＳＫ）を有し、新たな暗号始動プロセスが必要
ないことを意味する。「確認」状態は新たな暗号始動プ
ロセスにより発生されたＳＳＫが確認されず、それは次
に確認処理（プロセス）をなされなければならないこと
を意味する。「交換」鍵状態は暗号始動処理がクライア
ント装置３０２によりリクエストでいつでも許可され、
これはクライアント装置３０２のユーザーアカウントが
新たに確立されたときの通常の場合である。「強制」鍵
状態は暗号始動処理がいかなる新たなセッションが発生
しない前になされなければならないことを示す。ＳＲ４
０２でエンクリプトされたメッセージのデクリプション
が完全に失敗した結果が得られたときに「強制」状態に
入来される。

【００３２】クライアント装置３０２が新たに作動さ
れ、パワーオンされたときに鍵ー状態は自動的にデフォ
ルトで「交換」に設定される。鍵リクエスト４０６は暗
号始動処理が開始されるようサーバー装置３７０に送ら
れる。ＳＲ内のＣ−ノンス及び変更されたＣ−ノンスは
エンクリプトされず、これはサーバーモジュール３２０
がＥｎｃｒｙ［Ｃ−ノンス、変更されたＣ−ノンス］を
デクリプトしようと試みるときにエラーを引き起こす。
サーバーはクライアント３３２に通信セッションが暗号
始動処理を最初になすことなく確立されないことを示す
エラーと共に応答リクエスト４０４を送る。

【００３３】暗号始動処理は鍵状態が交換又は強制のい
ずれかの場合にクライアント装置３０２によりサーバー
装置３７０にキーリクエスト４０６を送ることにより常
に開始される。そうでなければサーバー装置３７０が始
動し、クライアント装置３０２が暗号始動処理と共の処
理されることに合意する場合にはプロセスがまた開始さ
れうる。これは現在のＳＳＫが期限切れになったときに
発生する。ＳＳＫは多くの理由で限られた寿命を有す
る。最も重要な理由は暗号解読と称されることに対する
保護である。ＳＫＫ鍵が用いられる各々の時にそれは多
数の暗号文を発生する。繰り返し鍵を使用することは攻
撃者に鍵の値の暗号解読を成功するために充分な暗号文
（及び可能な元のテキスト）の貯蔵を作り上げることを
許容する。サーバーが初期化した暗号始動プロセスの他
の例は双方の側の２つのＳＳＫの間のミスマッチを含
む。クライアント装置の暗号始動処理はサーバーモジュ
ール３２０からクライアントモジュール３２２へ送られ
たセッションリクエスト応答（ＳＲＲ）４０４により開
始される。ＳＲＲ４０４は双方の側のＳＳＫのミスマッ
チ又は期限切れによる鍵エラーメッセージからなる。

【００３４】クライアント装置３０２がかぎリクエスト
４０６を出す前にクライアントモジュール３３２は乱数
からクライアントプライベート値と称されるプライベー
ト値を発生する。乱数発生器は通常乱数のシードを受け
入れる。標準のＣライブラリで利用可能な例えばｒａｎ
ｄ（）のような使用可能な多くの乱数発生器が存在する
ことは当業者には明らかである。更にまたノイズ信号を
アンテナなしで検出する、ハードコーデッドインソー
ス、又はクライアント装置の製造業者により供給された
ような乱数シードを得る方法が多数存在する。乱数シー
ドで、クライアントのプライベート値がそのコアエンジ
ンとして一方向ハッシュ（ｈａｓｈ）関数である乱数発
生器により発生される。反対方向（逆方向）より一方向
（前方向）でなすことは顕著に容易である一方向手段は
発生された乱数から乱数シードを得る見込みをなくす
る。ハッシュ関数の一例はある値自体をある回数乗算
し、次にモジュロ（ｍｏｄｕｌｏ）操作をなすことであ
る。クライアントプライベート値は通常１６バイト長の
バイナリ数の形を取る。クライアントプライベート値は
そのように発生され、全ての可能な乱数を試行すること
に基づくクライアントプライベート値の統計的な複写は
見込みがない。故に発生されたクライアントプライベー
ト値はディフィ・ヘルマン鍵合意プロトコルのような鍵
合意プロトコルによるクライアント公開値と称される公
開値を発生するための入力として用いられる。クライア
ント公開値はしばしば米国内での通信用には９６バイト
バイナリ数であり、米国外での通信用には６４バイトバ
イナリ数である。本発明の一実施例によればＬＩＢＤＨ
と称されるライブラリはクライアント公開値を発生させ
るために用いられる。ＬＩＢＤＨはＢＳＡＦＥと称され
る製品の一部分でありこれは９４０６５−１０３１，カ
リフォルニア州Ｒｅｄｗｏｏｄ市ＭａｒｉｎｅＰａ
ｒｋｗａｙ１００で営業しているＲＳＡ研究所から販
売されている汎用で低レベルの暗号ツールキットであ
る。このエンジンはディフィ・ヘルマン鍵合意プロトコ
ルと暗号及びハッシュ関数からなる。クライアントプラ
イベート値はクライアント装置３０２内で得られ、クラ
イアント公開値はサーバー装置３７０に転送される。次
にクライアントモジュールはサーバー装置３７０に鍵リ
クエスト信号４０６を送る。鍵リクエスト４０６はクラ
イアント装置４０３の装置ＩＤ３１６と発生されたクラ
イアント公開値とを有する。

【００３５】サーバー装置３７０内の暗合始動処理はク
ライアント装置３０２からの鍵リクエスト４０６を受け
たときに開始する。上記のようにクライアント装置３０
２からの鍵リクエスト４０６はサーバー装置３７０から
送られたエラーメッセージ又はクライアント装置のユー
ザーによる手動のリクエストから得られる。クライアン
ト装置３０２から鍵リクエストを受けるとサーバー装置
３７０はサーバープライベート値と称されるプライベー
ト値を発生することにより装置ＩＤ３２６に基づいて一
連の認証プロセスをなした後に暗号始動処理と共に進
む。クライアントプライベート及び公開値と同様に、サ
ーバープライベート値はサーバー装置３７０内のノイズ
の多いダイオード又はトラフィック事象のようなノイズ
源から発生されうる乱数から発生される。プライベート
値はまた１６バイト長のバイナリ数である。入力として
サーバープライベート値で、公開値又はサーバー公開値
はまた９６又は６４バイトバイナリ数であり、ＬＩＢＤ
Ｈライブラリを用いてそれから発生される。

【００３６】上記のようにディフィ・ヘルマン鍵合意プ
ロトコルは秘密鍵を発生するために２つの数を必要とす
る。サーバーモジュール３２０はＬＩＢＤＨライブラリ
を用いて発生されるディフィ・ヘルマン鍵合意プロトコ
ルに基づくサーバー側の秘密鍵を発生するために自己発
生されたサーバープライベート値に沿って受信された鍵
リクエスト信号４０６内でクライアント公開値を用い
る。クライアント側の秘密鍵を発生するためにクライア
ント装置３０２を助けるためにサーバー３７０はサーバ
ー公開値からなる鍵応答信号４０８を送る。同様に受信
されたサーバー信号及び自己発生されたクライアントプ
ライベート値に基づきクライアントモジュール３３２は
ＬＩＢＤＨで発生される同じ鍵合意プロトコルに基づき
クライアント側の秘密鍵を発生する。上記のようにクラ
イアント側の秘密鍵は通常の環境下で共有された秘密鍵
（ＳＳＫ）と称されるサーバー側の秘密鍵と同じでなけ
ればならない。秘密鍵が同一であり、公開値が媒介者の
攻撃により公開データネットワーク内で送信中に変更さ
れていないことを確実にするために以下のように二段階
確認処理がなされる。

【００３７】第一段階はクライアントモジュール３３２
によりサーバー装置３７０に新たなＳＲ４１０を送る。
ＳＲ４１０内のＣ−ノンス及び変更されたＣ−ノンスの
部分はクライアント側の新たな秘密鍵によりここでエン
クリプトされる。新たなＳＲ４１０を受けると、サーバ
ーモジュール３２０は新たに発生されたサーバー側の秘
密鍵を用いてＥｎｃｒｙ［Ｃ−ノンス、変更されたＣ−
ノンス］をデクリプトするように試みる。デクリプショ
ンが成功した場合には、即ち双方の側の秘密鍵が同一で
ある場合には、公開値がデータネットワーク内で交換さ
れるときに媒介者の攻撃がないと仮定される。秘密鍵は
許可された共有された秘密鍵（ＳＳＫ）であると見なさ
れ、サーバーの永続的な記憶に付される。ＳＳＫは第二
の段階として定義される更なる確認に曝される。デクリ
プションが失敗した場合には双方の側の秘密鍵はどうい
つでなく、これはそれらがエアネット１０２のようなデ
ータネットワークにわたり送信されたときに公開鍵の可
能なデータ破損から生じる。新たな暗号始動処理がクラ
イアント装置３０２へのエラーメッセージを含む他のリ
クエスト応答４０４を送ることにより再開され、これは
暗号始動処理が失敗し、他の新たな暗号始動処理が再開
されたことを示す。

【００３８】第二の段階は両方の秘密鍵から得られた署
名を検査することである。秘密鍵は１６バイトのバイナ
リ数である。最初の８バイトはＲＣＡエンジンでブロッ
ク暗号ＲＣ５であるような相互に合意された暗号により
エンクリプション鍵として第二の８バイトによりエンク
リプトされ、エンクリプトされた結果は秘密鍵の署名と
称される。この署名は例えばＦＥ６３ＡＢＣＤ４７ＦＡ
３ＤＡ３のような形を取る。公開値が変更されなかった
場合には双方の秘密鍵は同一であり、故に署名も同一で
ある。署名の使用はクライアント側とサーバー側との間
の直接の確認のための手段を提供する。例えばクライア
ント装置のユーザーはクライアント秘密鍵とサーバー秘
密鍵から得られたそれぞれの２つの署名の間の適合が存
在するかどうかを確認するためにサービス装置の操作者
を呼ぶ。署名が同一である場合にはそれは媒介者の攻撃
がなく、そうでなければ暗号始動プロセスが誤ったと考
えられる。

【００３９】エアトラフィックを減少するために段階１
の確認プロセスは形成される新たなセッションでピギー
バックされる。換言すると、確認プロセスはサーバー装
置３７０に新たなセッションを送ることによりクライア
ント装置３０２により開始される。確認が成功した場
合、即ち双方のエンクリプション鍵が同一である場合
に、新たなセッションはセッション応答４１２と完了メ
ッセージ４１４を通してクライアント装置３０２とサー
バー装置３７０との間の一連の認証と共に続く。安全
な、認証された通信セッションは斯くして確立される。

【００４０】付録されたマイクロフィッシュにリストさ
れたコードは本発明の一実施例である。ソースファイル
セッションＴｘｎ．ｃ及びｎｅｔｓｕｇｐ．ｃにはサー
バー装置３７０とクライアント装置３２０それぞれの暗
号始動プロセスの全ての詳細な段階と過程が記載されて
いる。ｎｅｔｓｕｇｐ．ｃ内のＫｅｙＥｘｃｈＩｎｉｔ
（）という関数は関数ＫｅｙＥｘｃｈａｎｇｅＤｏＰｈ
ａｓｅＯｎｅ（）を開始することにより暗号始動処理に
対する初期化をなし、これはまずＤＨＩｎｉｔ（）関数
を通して鍵交換プロトコルをなすためにメモリ領域をア
ローケイトする。乱数はＤｅｖＧｅｔＲａｎｄｏｍ（）
関数から得られ、クライアントプライベート値としてＤ
ＨＰｈａｓｅ（）ｎｅ（）で用いられる。ＤＨＰｈａｓ
ｅ（）ｎｅ（）はクライアント装置３３２に対するクラ
イアント公開値を発生する。ｎｅｔＳｅｔｕｐＫｅｙＥ
ｘｃｈ（）関数では公開値はＳｕｇｐＫｅｙＲｑｓｔＳ
ｅｔＫｅｙＤａｔａ（）関数を通してＫｅｙＲｅｑｒｅ
ｓｔＰＤＵ関数に入来される。構成されたＫｅｙＲｅｑ
ｕｅｓｔＰＤＵは次にｎｅｔＤｏＴｘｎ（）関数内のＤ
ｅｖＳｅｎｄＰＤＵ（）を通してサーバーに送られる。

【００４１】暗号始動処理はＫｅｙＲｅｑｕｅｓｔＰＤ
Ｕがクライアント装置３０２からサーバーモジュール３
２０により受信されたときにＳｅｓｓｉｏｎＴｘｎ，ｃ
の関数ＴｓｅｓｓｉｏｎＴｘｎ：：Ｉｇｎｉｔｉｏｎで
開始される。サーバー装置３０２は処理を開始するため
にＣＩｇｎｉｔｉｏｎ関数ににより設定され、データベ
ース３２８の外から対応する記録３２１を引き出すため
にプロトセッション（ｐｒｏｔｏ−ｓｅｓｓｉｏｎ）を
形成する。サーバー装置３７０は次にクライアント装置
３０２は一時的にレジスタされ、又はディセーブルされ
たかどうか、及び暗号始動が許可されたかどうかを確認
する。これらの条件のいずれの一つも満足されない場合
には暗号始動処理はアボートされ、エラーコードがサー
バー装置３７０からクライアント装置３０２へ送られ
る。

【００４２】これら全ての条件が満足されたときに、サ
ーバーモジュール３２０はクライアント装置３０２に対
してＴｋｅｙＡｇｒｅｅ，ｋｅｙａｇｒｅｅのインスタ
ンスオブジェクトを形成し、これはＫｅｙＲｅｑｕｅｓ
ｔＰＤＵを送る。サーバーモジュール３２０はＩｎｉｔ
（），ＰｕｂｋｅｙＧｅｎ（），ＧｅｔＳＳｋｅ
ｙ（），ＩｓＷｅａｋＫｅｙ（）のようなオペレーショ
ンでｋｅｙａｇｒｅｅオブジェクト上で作動する。Ｉｎ
ｉｔ（）オペレーションは鍵合意プロトコルに対する計
算を初期化する；ＰｕｂｋｅｙＧｅｎ（）は鍵合意プロ
トコル及び乱数発生器を通して公開値及びプライベート
値を発生する；ＰｕｂｋｙｅＧｅｎ（）はまず乱数エン
ジンとリンクされ、それからサーバープライベート値が
発生される；ＧｅｔＳＳｋｅｙ（）はクライアント装置
３０２からのＫｅｙＲｅｑｕｅｓｔＰＤＵのクライアン
ト公開値とそれ自身のプライベート値の入力でサーバー
側の秘密鍵を計算する。ＩｓＷｅａｋＫｅｙ（）は発生
されたサーバー側の秘密鍵がエンクリプション鍵として
安全に使用されたかどうかをチェックする。そうでない
場合には上記のプロセスは良好なサーバー側の秘密鍵が
見いだされるまで繰り返される。関数ＣｍａｘＫｅｙＴ
ｒｉｅｓはサーバーモジュールがあきらめ、続いてクラ
イアントにエラーメッセージを送る前に反復を制御す
る。エラーメッセージの受信でクライアント装置３０２
は良好なサーバーがあの秘密鍵がＣｍａｘＫｅｙＴｒｉ
ｅｓでサーバーが満足するよう発生されるまで全体のプ
ロセスを繰り返すよう他のＫｅｙＲｅｑｕｅｓｔＰＤＵ
を送る。

【００４３】次にサーバー装置３７０はクライアント装
置３０２がｍ＿ｒＡｉｒｌｉｎｋ−＞Ｄｅｌｉｖｅ
ｒ（）関数を用いることにより暗号始動処理を完了する
ようＫｅｙＲｅｐｌｙＰＤＵのクライアント装置３０２
にサーバー公開値を供給する。サーバー装置３７０がｍ
＿ｐＮｅｗＣｉｐｈｅｒにサーバー側の秘密鍵をセーブ
し、クライアント装置３０２がサーバー側の秘密鍵をＳ
ＳＫに引き渡す確認プロセスを開始するのを待ち、次に
それはクライアント装置３０２からの新たなセッション
形成リクエストを通して永続的なデータベースにロード
される。

【００４４】ｎｅｔｓｕｇｐ．ｃ即ちクライアント側
で、ＫｅｙＲｅｐｌｙＰＤＵは関数ＮｅｔＤａｔａＡｒ
ｒｉｖｅｄ（）を通して受信され、ｎｅｔＨａｎｄｌｅ
ＫｅｙＲｐｌｙ（）関数に渡される。サーバーからのＫ
ｅｙＲｅｐｌｙ内のサーバー公開値は抽出され、クライ
アント側の秘密鍵を形成するためにＫｅｙＥｘｃｈＤＰ
ｈａｓｅＴｗｏ（）関数に入来される。クライアント側
の秘密鍵の形成が成功した後に、クライアントモジュー
ル３３２はそれをその永続的な記録にセーブし、Ｃｌｅ
ａｒＮｅｅｄｓ（ｋＫｅｙＥｘｈｈ）関数を呼ぶことに
より暗号始動リクエストに対するその必要をクリアす
る。クライアント装置３０２とサーバー装置３７０内で
それそれ発生された両方の秘密鍵を確認するためにクラ
イアント装置３０２はＳｅｓｓｉｏｎＲｅｑｕｅｓｔＰ
ＤＵ内のＣ−ノンス、変更されたＣ−ノンスをエンクリ
プトするために新たに発生されたクライアント側の秘密
鍵を用いることにより新たなセッションを形成するため
に新たなセッションリクエストを形成し、これはｎｅｔ
ＳｅｔｕｐＳｅｓｓ（）関数で見られる。Ｓｅｓｓｉｏ
ｎＲｅｑｕｅｓｔＰＤＵはクライアント装置３０２から
サーバー装置３７０に送られる。

【００４５】ＳｅｓｓｉｏｎＴｘｎ．Ｃで、Ｓｅｓｓｉ
ｏｎＲｅｑｕｅｓｔＰＤＵがサーバー装置３７０により
受信されたときにサーバーモジュール３２０はリクエス
トを処理するためにＴＳｅｓｓｉｏｎＴｘｎ：：Ｓｔａ
ｒｔ（）を呼ぶ。暗号始動処理に関連する限り、新たに
発生されたサーバー側の秘密鍵を用いることによるＳｅ
ｓｓｉｏｎＲｅｑｕｅｓｔＰＤＵの到来でのデクリプシ
ョンの成功はサーバー側の秘密鍵をＳＳＫに引き渡し、
それは次にその永続的なデータベースにロードされる。
同じ関数で、サーバーモジュール３２０はｍ＿ｐＮｅｗ
Ｃｉｐｈｅｒが存在するかどうかをチェックすることに
よりペンディングの暗号始動プロセスが存在するかどう
かをチェックする。そうである場合にはそれはＳｅｓｓ
ｉｏｎＲｅｑｕｅｓｔＰＤＵをデクリプトするために用
いられる。デクリプションが成功した場合にはサーバー
は関数ｍ＿ｒＳｅｓｓｉｏｎ−＞ｍ＿ｐＳｕｂｓｃｒｉ
ｂｅｒ−＞Ｓｅｔ（）とｍ＿ｒＳｅｓｓｉｏｎ−＞ｍ＿
ｐＳｕｂｓｃｒｉｂｅｒ−＞ＥｘｃｈａｎｇｅＣｏｍｐ
ｌｅｔｅ（）を用いることにより共有された秘密鍵とし
てサーバー側の秘密鍵をセーブする。署名はまたなさ
れ、ｍ＿ｐＮｅｗＣｉｐｈｅｒ−＞ＭａｋｅＳｉｇｎａ
ｔｕｒｅ（）関数を用いることによりその点でセーブさ
れる。これはサーバー３７０で暗号始動処理を完了す
る。

【００４６】図５、６を参照するにクライアント装置３
０２とサーバー装置３７０それぞれの暗号始動処理（Ｃ
ＩＰ）のデータフローチャートが示される。図５、６の
両方は図３、４と関連して理解されなければならない。
上記のように暗号始動処理は幾つかの方法で開始されそ
のひとつは新たな暗号始動処理がサーバー装置３７０と
クライアント装置３０２との間でなされるように相互に
リクエストすることにより処理を開始する。第二の方法
は例えばＳＲ４０２をデクリプトすることの完全な失敗
又は双方のＳＳＫのミスマッチ又は期限切れによりサー
バー装置３７０により送られたセッションリクエスト応
答４０４のエラーメッセージからである。

【００４７】クライアント装置は図５の５０２で暗号始
動処理（ＣＩＰ）を開始する。段階５０４でクライアン
トモジュールはクライアント公開値を発生することの前
にクライアントプライベート値を発生し、その処理は上
記で説明された。クライアント公開値が利用可能になっ
たときにクライアントモジュールは段階５０６でサーバ
ーモジュールに鍵リクエスト信号４０６を送る。クライ
アント装置は段階５０８でサーバー装置から鍵応答４０
８に対する待ちを開始する。鍵応答４０８を待つ間に、
クライアント装置は意図されたサーバー装置から所望の
鍵応答４０８以外の信号を受ける。受信された信号が所
望の鍵応答４０８得ない場合には、それらは段階５１０
で破棄される。クライアント装置が無期限に待つことを
防ぐために、時間制限が例えば６０秒のように待ちに対
して設定される。時間制限内で所望の鍵応答４０８が受
信されなければならず、さもなければエラーメッセージ
がそのユーザーに現在の暗号始動は段階５１４でアボー
トされたことを伝えるために段階５１２でクライアント
装置の表示スクリーンに表示される。

【００４８】図６を参照するに段階５５２でクライアン
ト装置からの鍵リクエスト信号４０６を受けて、サーバ
ーモジュールはサーバーで形成されるクライアント装置
によりリクエストされたセッションを識別するためにセ
ッションＩＤと称されるセッション識別子と共にクライ
アント装置に対して段階５５４でプロトセッションを形
成する。サーバープロトセッションはセッションテーブ
ルでプロト状態としてマークされたセッションエントリ
であり、これはセッションが認証されず、クライアント
といかなる交信もなし得ないことを示す。プロトセッシ
ョンはサーバーのＲＡＭ内に保持され、サーバー装置が
他のクライアント装置と通信にある場合には一以上のプ
ロトセッションが存在しうる。プロトセッションが特定
のクライアント装置に対して既に存在する場合にそれは
浅い利用される。受信されたＳＲの情報はプロトセッシ
ョンにセーブされる。サーバーモジュールが認証された
クライアント装置と通信することを確実にするために、
サーバー装置は一連の確認をなす。５５６でサーバー装
置はまず受信されたＳＲ４０２の装置ＩＤをアカウント
で割り当てられた装置ＩＤと比較することにより許容さ
れるかどうかを検査する。受信された装置ＩＤが許容さ
れる場合にはサーバーモジュールは更にクライアント装
置が５５８でイネーブルされたかどうか検査する。ある
場合にはクライアント装置が許容された（ｖａｌｉｄ）
装置ＩＤを有するがクライアント装置はある理由でディ
セーブルされる。クライアント装置がサーバー装置に認
識され、認証されるときにサーバーモジュールは暗号始
動処理がユーザーアカウントの鍵状態を検査することに
よりイネーブルされるかどうか検査する。上記のように
鍵状態はユーザーアカウントが新たに確立されたときに
は「交換」に設定される。暗号始動処理を許容する状態
は「交換」及び「強制」であり、これは現在の暗号始動
処理がイネーブルであると考えられ、さもなければそれ
はイネーブルではない。

【００４９】段階５５６、５５８、５６０での確認のい
ずれの一つが失敗した場合にはサーバーモジュールはク
ライアントに企てたＣＩＰがアボートされたことを知ら
せるために装置エラーを５６２で送る。サーバーは形成
されたプロトセッションをこの特定のセッションに対し
て段階５８６で除去し、段階５９０でＣＩＰをアボート
する。

【００５０】段階５５６、５５８、５６０での全ての確
認が成功したときに、サーバーモジュールはサーバープ
ライベート値及びサーバー公開値を形成する段階に進
み、その過程は上記で説明した。受信されたクライアン
ト公開値及びサーバー自己形成プライベート値で、サー
バーモジュールは段階５６４の共通鍵合意プロトコルに
よりサーバー側の秘密鍵を発生する。安全性の理由によ
り段階５２６で発生されたサーバー側の秘密鍵は段階５
６６の鍵検査処理を通される。鍵検査処理は形成された
秘密鍵は充分なランダムパターンを有し、暗号解析によ
り容易には再構成されない。容易に統計的に検出される
パターンのあるものは０１０１０１０１０１．．．０１
のような周期的に０と１を有する鍵であり、これは承認
されていない複製を容易になされる。ＳＳＫは弱いと考
えられ、破棄され、再生されなければならない。段階５
６８で形成された秘密鍵が再生されなければならない回
数をモニタするカウンタが存在する。カウンタが例えば
１０回のようなある数以上の場合にサーバー装置はあき
らめ、故にクライアントにＣＩＰの全体を再び開始する
ようにリクエストするために段階５７８でクライアント
にエラーメッセージを送る。発生された秘密又は再発生
された秘密鍵は段階５６６で鍵検査プロセスを通過する
場合に、段階５６０でサーバーは鍵応答信号をサーバー
公開値と共にクライアントモジュールに送り、クライア
ントモジュールにクライアント側の秘密鍵を発生させ
る。クライアント装置と同様に、サーバーモジュールも
段階５７でクライアント装置からの応答の待機を開始す
る。いかなる所望でない信号も段階５７４で破棄され
る。サーバーモジュールが非常に長く待たされる場合に
は最初に形成されたプロトセッションが段階５８６で除
去され、現在の暗号始動処理が段階５９０でアボートさ
れる。

【００５１】図５を参照するにクライアントモジュール
は段階５０８でキー応答信号を待っている。クライアン
トモジュールはサーバー装置からの鍵応答信号を受けて
クライアント側の秘密鍵を段階５１６で形成する。故に
クライアントモジュールはサーバーの弱いＳＳＫに対す
るテストに頼る。クライアントモジュールは段階５１６
で共通に用いられる鍵合意プロトコルによるクライアン
ト側の秘密鍵の形成のためにサーバー公開値とクライア
ント自己発生プライベート値を用いて類似の鍵形成プロ
セスを開始する。クライアント装置の遠近感から発生さ
れたクライアント側の秘密鍵は許容されていると仮定さ
れ、クライアントモジュールはそれの永続的メモリ又は
ＲＡＭにそれをロードすることにより発生されたクライ
アント側の秘密鍵をＳＳＫに引き渡す。次にクライアン
トはクライアント形成ＳＳＫによりＥｎｃｒｙ［Ｃ−ノ
ンス、変更されたＣ−ノンス］で新たなセッションリク
エスト４１０を開始する。

【００５２】図６を参照するにサーバーが段階５７２で
新たなセッションリクエスト４１０を受けるときにサー
バーはプロトセッションテーブルでプロトセッションエ
ントリを探し、段階５７６で新たなセッションリクエス
ト４１０での装置ＩＤを用いて一連の確認処理をなす。
サーバーモジュールが新たなセッションリクエスト４１
０が認識され承認されたクライアント装置から到来する
ことを確実にするためにそれはＥｎｃｒｙ［Ｃ−ノン
ス、変更されたＣ−ノンス］が現在のサーバー側の秘密
鍵によりうまくデクリプトされるかどうかをチェック
し、うまくゆく場合にはそれはサーバー側の秘密鍵がク
ライアント装置のＳＳＫであることを示す。サーバーモ
ジュールはそれを段階５８２でサーバー装置の永続的メ
モリ内にローディングすることによりサーバー側の秘密
鍵をクライアント装置のＳＳＫに引き渡す（ｃｏｍｍｉ
ｔｔｉｎｇ）。さもなければそれはＥｎｃｒｙ［Ｃ−ノ
ンス、変更されたＣ−ノンス］が古いＳＳＫによりうま
くデクリプトされるかどうかをチェックし、それはクラ
イアント装置が現在の暗号始動処理で失敗したことを示
す。次に現在の暗号始動処理が段階５９０で静かにアボ
ートされ（クライアントにエラーメッセージを送らず
に）、新たなセッションが古いＳＳＫで形成される。故
にこのプロセスは現在の暗号始動処理が失敗した場合に
存在する古いＳＳＫを保存する。

【００５３】形成されたＳＳＫを確認する手段を提供す
るために２つのＳＳＫからの２つの署名が段階５９２で
確認される。これはクライアント装置のユーザーとサー
バー装置のオペレーターとの間の口頭の確認によりなさ
れる。上記のようにクライアント側の署名はクライアン
ト側の秘密鍵が形成されたときに形成される。同様にサ
ーバー側の署名はサーバー側の秘密鍵が形成されたとき
に形成される。２つの署名が一致しない場合には現在の
暗号始動処理は失敗し、安全な通信セッションが確立し
ない。確認が成功した場合には現在の暗号始動処理は段
階５９４で成功する。口頭の確認は本は対の必要な部分
ではなく、ＳＳＫから生じた署名を比較することにより
ＳＳＫを確認する手段を例示するための一実施例で用い
られているだけである。

【００５４】本発明は特定のある度合いの充分な詳細に
より記載されてきた。実施例のこの開示は例示のみのた
めになされたものであり、配置及び段階、部品の組合せ
の無数の変更は本発明の請求項の精神及び範囲を離れる
ことなく実施されうることは当業者には明らかである。
故に本発明の範囲は実施例ではなく請求項によってのみ
決定される。

【図面の簡単な説明】

【図１】本発明が実施可能な移動データネットワークの
概略を示す。

【図２】本発明のリンクされ、コンパイルされた処理を
含む移動装置の典型的な例を示す。

【図３】本発明のアーキテクチャーを示す。

【図４】暗号始動処理がクライアント装置とサーバー装
置との間で作動されたときに一対の各ＵＤＰインターフ
ェイスを通してサーバーモジュールとクライアントモジ
ュールとの間の交信を示す。

【図５】暗号始動処理がクライアント装置とサーバー装
置との間での動作を示すフローチャートである。

【図６】暗号始動処理がクライアント装置とサーバー装
置との間での動作を示すフローチャートである。

【符号の説明】

１００データネットワーク１０２エアネット１０４ランドネット１１０デスクトップＰＣ１１２サーバーコンピュータ１１４プロキシサーバーコンピュータ１０６移動装置１１６スクリーン１１８キーパッド１２０電話１２４クライアントモジュール１２６支援モジュール１２２ＲＯＭ１３４ＲＡＭ１３０表示ドライバ１３２キーパッドドライバ１２８マイクロ制御器３０２、３０４、３０６移動装置３１０、３１２、３１４ランドライン装置３７０リンクサーバー３１６装置ＩＤ３２８データベースサービス３３２クライアントモジュール３２０サーバーモジュール３０２クライアント装置３３６、３２４ＵＤＰインターフェイス

───────────────────────────────────────────────────── フロントページの続き (72)発明者ハンチンリアオアメリカ合衆国，カリフォルニア州 94583 サン・レイモンヴィスタ・ポイント・サークル 1025 (72)発明者ピーターエフキングアメリカ合衆国，カリフォルニア州 94019 ハーフ・ムーン・ベイプリシデオ・アヴェニュ 121

Claims

【特許請求の範囲】

【請求項１】クライアント装置のクライアントプライベ
ート値を発生し；該クライアント装置の該クライアント
プライベート値に基づいてクライアント公開値を発生
し；サーバー装置に該クライアント装置から該クライア
ント公開値からなる鍵リクエストメッセージを送り；該
サーバー装置から該鍵リクエストメッセージへのサーバ
ーの応答を受け；該クライアントプライベート値及び該
サーバー応答に関して、及び鍵合意プロトコルによりク
ライアント側の秘密鍵を発生する各段階からなるデータ
ネットワーク上のクライアント装置とサーバー装置との
間で安全な通信チャンネルを確立する方法。
【請求項２】該サーバ応答はサーバー公開値からな
り、該サーバー公開値は該クライアント装置から受信さ
れた該鍵リクエストメッセージで該クライアント公開値
に関して該サーバーで発生される請求項１記載の方法。
【請求項３】該クライアント側の秘密鍵とサーバー側の
秘密鍵が適合していることを確認する確認処理をなす段
階を更に含み、該サーバー側の秘密鍵はサーバープライ
ベート値及び該鍵リクエストメッセージの該クライアン
ト公開値に関して、及び該鍵合意プロトコルにより該サ
ーバー装置で発生された請求項２記載の方法。
【請求項４】該確認をなす処理は該クライアント側の
秘密鍵によりメッセージをエンクリプトし；該データネ
ットワーク上の該サーバー装置に該エンクリプトされた
メッセージを送る各段階を更に含む請求項３記載の方
法。
【請求項５】該確認をなす処理は該クライアント側の
秘密鍵からのクライアント署名が該サーバー側の秘密鍵
からのサーバー署名に適合することを確認し；該クライ
アント署名及び該サーバー署名が適合している場合に該
クライアント側の秘密鍵及び該サーバー側の秘密鍵を一
対の共通の秘密鍵に引き渡す各段階を更に含む請求項４
記載の方法。
【請求項６】該確認をなす処理は該サーバー装置と通
信セッションを確立するために該クライアント装置によ
りセッションリクエストを開始し；エンクリプトされた
メッセージが該サーバー側の秘密鍵によりうまくデクリ
プトされた後で該サーバー装置からセッション応答を受
ける各段階を更に含み、該セッションリクエストは該ク
ライアント装置の装置ＩＤと、相互に受容された暗号に
よる該クライアント側の秘密鍵によりエンクリプトされ
たメッセージとからなる請求項３記載の方法。
【請求項７】クライアント装置から鍵リクエストメッセ
ージを受け；該クライアント装置に対するサーバー装置
のプロトセッションを形成し；受信されたクライアント
公開値と鍵合意プロトコルによるサーバープライベート
値からサーバー側の秘密鍵を発生し；鍵リクエストメッ
セージに応答して該クライアント装置へサーバー応答を
送り；該サーバー側の秘密鍵が該クライアント装置で発
生されたクライアント側の秘密鍵に適合することを確認
する確認プロセスをなす各段階からなり、該鍵リクエス
トメッセージは該クライアント装置を識別する識別子と
該クライアント装置で発生されたクライアント公開値と
からなり、該サーバー応答はサーバー公開値からなり、
サーバー公開値とサーバープライベート値の両方は該サ
ーバー装置で提供されるデータネットワーク上のクライ
アント装置とサーバー装置との間で安全な通信チャンネ
ルを確立する方法。
【請求項８】該識別子は該クライアント装置の装置識
別をなし、該方法は該装置識別が該サーバー装置にアク
セス可能なアカウントに関して許容されるかどうかを決
定し；暗号始動処理が該アカウントの鍵状態を検査する
ことによりイネーブルされたかどうかを決定する各段階
を更に含む請求項７記載の方法。
【請求項９】該サーバー側の秘密鍵の強度を確認し；該
サーバー側の秘密鍵が弱いと判断された場合に該サーバ
ー側の秘密鍵を再形成する各段階を更に含む請求項８記
載の方法。
【請求項１０】該確認をなす処理は該クライアント側
の秘密鍵からのクライアント署名が該サーバー側の秘密
鍵からのサーバー署名に適合することを確認し；該クラ
イアント署名及び該サーバー署名が適合している場合に
該クライアント側の秘密鍵及び該サーバー側の秘密鍵を
一対の共通の秘密鍵に引き渡す各段階を更に含む請求項
７記載の方法。
【請求項１１】該クライアント側の秘密鍵及び該サー
バー側の秘密鍵を一対の共通の秘密鍵に引き渡す段階は
該サーバー側の秘密鍵を用いて該サーバー装置により該
クライアント装置からエンクリプトされたメッセージを
デクリプションし；該エンクリプトされたメッセージが
該サーバー装置によりうまくデクリプトされたときに該
サーバー側の秘密鍵を該プロトセッションにローディン
グする各段階を更に含み、該エンクリプトされたメッセ
ージは相互に受容された暗号による該クライアント側の
秘密鍵によりエンクリプトされた請求項１０記載の方
法。