JPH10190649A - 双方向データストリーム伝送装置 - Google Patents

Abstract

(57)【要約】 【課題】ＳＴＲＥＡＭＳ型プロトコル・スタックを通過
するデータに対する暗号化および復号を実行する場合、
暗号および復号のためユーザ空間とカーネル空間の間で
データを何度も往復させる必要性をなくす。 【解決手段】ＳＴＲＥＡＭＳ型モジュールのプロトコル
・スタックへの追加、暗号化機構との間でのデータのや
りとりを制御するＳＴＲＥＡＭＳ型暗号化マルチプレク
サの提供、動的関数登録手段を使用してストリーム・ヘ
ッドへの暗号関数の登録、およびプロトコル・スタック
を通過するデータを暗号機構に送るようにＳＴＲＥＡＭ
Ｓ型モジュールの修正などを含む種々の代替的解決手段
を提供することによって、カーネル空間とユーザ空間の
間で第１の方向に流れるデータを暗号化し、第２の方向
へ流れるデータを復号する。 暗号化機構はソフトウェ
アまたはハードウェアいずれの形態でも実施できる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータ・シ
ステム内およびコンピュータ・システム間のデータ通信
に関するもので、特にデータ暗号化を行うように修正さ
れるプロトコル・スタックを使用するコンピュータ・シ
ステム内およびコンピュータ・システム間のデータ通信
に関するものである。

【０００２】

【従来の技術】暗号は、コンピュータ分野においてます
ます重要性を増している。インターネットのような無保
護のネットワーク上に送られる情報量は増加し続けてい
る。加えて、無保護のネットワークが、金融上のトラン
ザクション処理を行うためのみならず、その他種々のタ
イプの秘密を要する個人データを伝送するため使用され
つつある。

【０００３】無保護のネットワーク上で伝送されるデー
タが意図された受け取り人以外のだれによっても横取り
されないことを保証する上で暗号は役立つ。従来技術に
おいては、暗号機能は、暗号化されたデータを生成する
アプリケーションによって通常制御されてきた。アプリ
ケーションは、暗号アルゴリズムを含むか、さもなけれ
ばコンピュータのオペレーティング・システムによって
提供される関数ライブラリに記憶されるアルゴリズムを
使用する。このアプローチはいくつかの制約を持つ。第
１に、暗号アルゴリズムがアプリケーションに含められ
るとすれば、その更新は簡単ではない。第２に、関数ラ
イブラリ(典型的には安全保護されたソケット・ライブ
ラリ)に記憶された暗号アルゴリズムの使用は、ユーザ
空間およびカーネル空間の両方においてデータが何度も
コピーされ処理されなければならないため、非効率であ
る。最後に、アプリケーションが暗号をサポートしなけ
れば、アプリケーションのデータを暗号化することは非
常に困難である。

【０００４】

【発明が解決しようとする課題】このように、アプリケ
ーションに基づく暗号化から、接続(または入出力)に基
づく暗号化へ暗号パラダイムをシフトさせることが、コ
ンピュータ・ネットワーク技術において必要とされてい
る。

【０００５】

【課題を解決するための手段】本発明は、プロトコル・
スタックを通過するデータに対して暗号機能を実行する
方法および装置を提供する。本発明の第１の局面におい
て、ソフトウェアに基づく暗号アルゴリズムを含むモジ
ュールまたはドライバを使用する構成によってまたは、
ハードウェアに基づく暗号機構に接続されるドライバを
使用する構成によって、データが暗号化されまた復号さ
れる。

【０００６】本発明の第２の局面において、プロトコル
・スタック・マルチプレクサが暗号化モジュールまたは
ドライバへデータを渡す。この形態においても上記ハー
ドウェア型構成およびソフトウェア型構成がサポートさ
れる。いくつかの上記ハードウェア型暗号機構が使用可
能でありかつ上記マルチプレクサが使用可能な暗号機能
を選択するスケジューリング・アルゴリズムを実施する
ように構成される場合、特にこの形態は有益である。

【０００７】本発明の第３の局面において、動的関数登
録を使用してストリーム・ヘッドに暗号化関数が登録さ
れる。暗号化関数は、ソフトウェア型暗号化を実施する
ことができるし、あるいはまたハードウェア型暗号機構
にインターフェースするドライバとしての役目を果たす
こともできる。この形態の１つの構成において、データ
がユーザ空間からカーネル空間へコピーされる際にその
データは暗号化され、カーネル空間からユーザ空間へコ
ピーされる際データは復号される。

【０００８】本発明の第４の局面において、暗号プロセ
スを制御する動的取り替え可能関数を含むドライバまた
はモジュールによって、データは暗号化されまた復号さ
れる。この形態においても上記ハードウェア型構成およ
びソフトウェア型構成はサポートされる。

【０００９】このように、発明の課題を解決するため本
発明が提供する手段には、コンピュータ・システム内に
配置され、デバイスとユーザ・プロセスの間で双方向デ
ータストリームを伝送する装置が含まれる。該装置は、
上記デバイスに接続され、上記双方向データストリーム
を上記デバイスへ伝送するデバイス・ドライバ、上記デ
バイスと上記ユーザ・プロセスの間に配置され上記ユー
ザ・プロセスと上記デバイス・ドライバの間で上記双方
向データストリームを伝送するストリーム・ヘッド、お
よび上記双方向性データストリームの形態で伝送される
データに関して暗号化関数を実行する暗号化機構を備え
る。

【００１０】

【発明の実施の形態】図１は、従来技術のコンピュータ
・システム１０を示す図である。コンピュータ・システ
ム１０は、ユーザ空間１１とカーネル空間２０を含む。
ユーザ空間１１は、ユーザ・アプリケーション１２、ソ
ケット１４および安全保護ソケット１６を含む。カーネ
ル空間２０は、暗号化機構１８、ストリーム・ヘッド２
２、伝送制御プロトコル(ＴＣＰ)レーヤ２４、インター
ネット・プロトコル(ＩＰ)レーヤ２６およびデータ・リ
ンク・プロバイダ・インターフェース(ＤＬＰＩ)レーヤ
２８を含む。暗号化機構１８は、ハードウェアに基づく
暗号アルゴリズム(以下単にハードウェア型暗号アルゴ
リズムと呼ぶ)あるいはソフトウェアに基づく暗号アル
ゴリズム(以下単にフトウェア型暗号アルゴリズムと呼
ぶ)のいずれを使用しても実施することができる。スト
リーム・ヘッド２２、ＴＣＰレーヤ２４、ＩＰレーヤ２
６およびＤＬＰＩレーヤ２８が、ＳＴＲＥＡＭＳ型プロ
トコル・スタックを実現する。ＳＴＲＥＡＭＳフレーム
ワークの詳細は、S.Rago著"UNlX System V Network Pro
gramming"(Addison Wesley professional computing se
ries(1993))の９５ページから始まる第３章および４２
５ページから始まる第９章ないし第１１章に記載されて
いる。

【００１１】本明細書において、「暗号」または「暗号
化」という用語は「暗号化」のみならず「復号」をも含
む。従って、「暗号キー」は復号に必要なキーをも含
む。同様に、ハードウェア型暗号化機構は、データを復
号する機能をも持つ。当然ではあるが、文脈的に見て
「暗号化」が「復号」を含まないこともあり、そのよう
な文脈は当業者にとって明白である。

【００１２】図１に示されるように、ユーザ・アプリケ
ーション１２はネットワークを経由して暗号化されたデ
ータを送受信するように構成されている。暗号化された
データを送るためには、安全保護ソケット１６を経由し
て暗号化機構１８に未暗号化データを送ることによって
アプリケーション１２は先ずデータを暗号化しなければ
ならない。典型的には、この動作は、ユーザ・アプリケ
ーション１２がsend()コマンドのようなシステム・コー
ルを呼び出すことによって達成される。安全保護ソケッ
ト１６に関連づけられた安全保護ソケット・ライブラリ
が、暗号化されるべきデータを暗号化機構１８に提供す
る(実施形態依存型)書込みコマンドにそのsend()コマン
ドを対応づける。データが暗号化された後、ユーザ・ア
プリケーション１２は、暗号化されたデータを取り戻す
recv()コマンドのようなシステム・コールを呼び出す。
recv()コマンドは、暗号化機構１８から暗号化されたデ
ータを取り戻す(実施形態依存型)読取りコマンドに対応
づけされ、次に、暗号化されたデータがユーザ・アプリ
ケーション１２に渡される。その後、ユーザ・アプリケ
ーション１２は、(別のsend()コマンドのような)システ
ム・コールを呼び出すことによってソケット１４を経由
してストリーム・ヘッド２２へ暗号化されたデータを送
ることによって、暗号化されたデータをネットワーク上
に送る。暗号化されたデータは、ストリーム・ヘッド２
２から、ＴＣＰレーヤ２４、ＩＰレーヤ２６およびＤＬ
ＰＩレーヤ２８へと流れる。ＤＬＰＩレーヤ２８は、メ
モリと物理的ネットワーク・ハードウェアの間のＤＭＡ
動作を始動させて、物理的ネットワーク上へ暗号化され
たデータを送り出す。

【００１３】send()またはrecv()コマンド、あるいは実
施形態依存型の読取りまたは書き込みコマンドが呼び出
されるたび毎にデータはユーザ空間１１とカーネル空間
２０の間を移動されなければならない。これらのデータ
移動は、Unixのcopyin()またはcopyout()関数のいずれ
かを呼び出すコマンドによって達成される。copyin()関
数はデータをユーザ空間からカーネル空間へ移動し、co
pyout()関数はデータをカーネル空間からユーザ空間へ
移動させる。

【００１４】暗号化されたデータを読むためにはプロセ
スは逆にされる。すなわち、ＤＬＰＩレーヤ２８が、物
理的ネットワーク・ハードウェアとメモリの間のＤＭＡ
動作を始動し、暗号化されたデータがＩＰレーヤ２６、
ＴＣＰレーヤ２４およびストリーム・ヘッド２２に流れ
る。ユーザ・アプリケーション１２は、recv()コマンド
のようなシステム・コールを呼び出すことによってソケ
ット１４経由でストリーム・ヘッド２２から暗号化され
たデータを受け取る。次に、ユーザ・アプリケーション
１２は、send()コマンドのような別のシステム・コール
を呼び出すことによって安全保護ソケット１６を経由し
て暗号化機構１８へ暗号化されたデータを送ることによ
って暗号化されたデータを復号し、もう１つ別のrecv()
コマンドのような最終的システム・コールを呼び出すこ
とによって安全保護ソケット１６を経由して暗号化機構
１８から復号されたデータを受け取る。

【００１５】図１で示される暗号プロセスは機能的では
あるが、いくつかの欠点がある。第１に、処理性能は最
適でない。データは、安全保護ソケット１６および暗号
化機構１８との間で出し入れされ、更に、ソケット１
４、ストリーム・ヘッド２２および諸レーヤ２４，２
６，２８の間を転送される。このようなデータの移動
は、典型的には、ユーザ空間とカーネル空間の間でデー
タを繰り返しコピーすることを必要とする。それに加え
て、システム資源は、各アプリケーション・インスタン
スのために複数のソケット、バッファおよび他の資源を
保持するため占有されなければならず、これらのタスク
すべてが管理されるのにともなってＣＰＵ使用度が増加
する。

【００１６】もう一つの欠点は、暗号化プロセスがユー
ザ空間１１から制御されるということである。悪意のあ
る攻撃に対して、ユーザ空間におけるデータおよび活動
はカーネル空間における場合より弱く、従って、ユーザ
空間から制御される暗号化プロセスは、カーネル空間か
ら制御される暗号化プロセスに比較して、そのような攻
撃を受けやすい。この脆弱さは、(University of Calif
ornia-Berkelyの)EricBrewer, Paul Gauthier, Ian Gol
dbergおよびDavid Wagnerの諸氏によって実証されてい
る。Brewer氏らは、安全保護セッション・レーヤ・プロ
トコルの重視および暗号化キーの十分な無作為性が、末
端間のセキュリティのより基本的な傷を隠蔽したと主張
する。具体的には、プロトコルが安全でなければならな
いだけではなく、ユーザ・コードもまた各エンド・ポイ
ントで安全でなければならない。Brewer氏らは、彼らの
論点を証明するため、ネットワーク上を伝送されている
間にプログラムのバイナリ・コードを変えることができ
る方法を示した。彼らは、その方法を使用してネットス
ケープのナビゲータ・ブラウザの合法的コピーを彼らだ
けが知っている固定的キーを使用したバージョンに変更
した。これは目に見えない形のセキュリティ侵害であ
る。従って、たとえユーザが特定のアプリケーションの
供給業者を信頼することができるとしても、無保護のネ
ットワーク上で伝送されるとすれば、そのコード自体は
信頼できない。

【００１７】最後に、図１で示された暗号プロセスに関
連するもう１つの欠点は、ユーザ・アプリケーション１
２が暗号化を始動しなければならないことである。アプ
リケーション１２が、暗号をサポートするように設計さ
れなかった過去の遺産のアプリケーションであるとすれ
ば、アプリケーション１２がネットワーク上に送り出す
データを暗号化すことはできない。また、たとえユーザ
・アプリケーション１２が暗号をサポートするように設
計されていたとしても、例えば一層大きい暗号キーまた
は異なる形式を使用する可能性のある新しい暗号アルゴ
リズムをサポートできるほどそれは柔軟でないかもしれ
ない。

【００１８】本発明は、暗号機能をプロトコル・スタッ
クに移動することによって図１で示された暗号プロセス
に関連した諸問題を解決する。プロトコル・スタックに
暗号機能を含むことによってデータのコピーおよび移動
は最小にされる。加えて、暗号化および復号がカーネル
空間で実行されるので、暗号プロセスは、悪意がある攻
撃または「嗅ぎまわり」に対してさほど弱くない。本発
明を使用することによって、データはアプリケーション
ではなくカーネルによって与えられるキーを使用して暗
号化されることができる。これは、暗号化されたデータ
伝送を行う際のユーザ・アプリケーションの役割を減少
させ、それによってセキュリティが増加する結果とな
る。更に、ユーザ・アプリケーションは暗号化をサポー
トする必要はない。本発明は、プロトコル・スタックを
通過するいかなる情報をも暗号化し復号するように構成
することができる。

【００１９】本発明は、ハードウェア型暗号アルゴリズ
ムまたはソフトウェア型暗号アルゴリズムのいずれを使
用する暗号化をもサポートする。暗号化技術の現在の状
態においては、いくつかの理由のため、ハードウェア型
暗号アルゴリズムがソフトウェア型暗号アルゴリズムよ
り好ましい。第１に、組み込まれたハードウェアの処理
速度は速い。現在市販されている暗号化ハードウェア
は、毎秒１メガバイト以上のデータ率でデータを暗号化
する能力を持つ。第２に、暗号化機構が専用ハードウェ
アに装填されているので、ＣＰＵは他の処理を並列的に
実行するために利用できる。第３に、多くのハードウェ
ア型暗号化装置が標準的ＳＣＳＩ装置として動作するの
で、ハードウェアは、非保護のオペレーティング・シス
テムにおいてまた多数のプラットホームにおいて使用で
きる。第４に、物理的ハードウェアは変更や妨害が比較
的難しい。物理的装置は水銀破壊装置を備えることもで
きる。最後に、暗号技術の更新は比較的簡単である。例
えば、暗号化技術や暗号化キーはＰＣＭＣＩＡカードで
提供することができ、そのカードは暗号化技術を更新す
る時簡単に交換することができる。

【００２０】当然のことながら、ハードウェア暗号化機
構にも種々の欠点があり、それら欠点はソフトウェア暗
号化によって今や解決される傾向にある。第１に、暗号
化プロトコルの数が増大していて、現在のハードウェア
暗号化実施形態は、最高４つの暗号化プロトコルをサポ
ートするだけである。ソフトウェアはいかなる数のプロ
トコルをもサポートするることができ、使用現場で導入
または更新できる。第２に、ホストＣＰＵ能力は組み込
まれたプロセッサ能力より一層迅速になる傾向があり、
並列処理およびスケーリング技術は向上し続けている。
最終的にソフトウェア型暗号化技術が、ハードウェア型
暗号化技術に優る性能を示すかもしれない。第３に、ハ
ードウェアは、データが入出力経路を通して移動される
かＤＭＡ動作によってアクセスされることを必要とする
が、一方、ソフトウェアは、ＤＭＡ動作またはハードウ
ェア割り込み処理を必要とすることなく同じメモリ位置
内でデータを暗号化することができる。加えて、メモリ
・バンド幅は典型的には多くの入出力バンド幅より数倍
も大きい。第４に、ソフトウェアは、複数の文脈切り替
えを必要とせず、従ってＣＰＵキャッシュを汚染しな
い。最後に、ソフトウェアは、なにかセキュリティ問題
が発見されれば、迅速にパッチを当てることができる。

【００２１】本発明は、ハードウェアおよびソフトウェ
ア両者の暗号化をサポートすることによって最大限の柔
軟性を提供する。本発明に従うＳＴＲＥＡＭＳ型プロト
コル・スタックが、スタックを通過するすべてのデータ
のハードウェア型暗号化および復号を実行するように構
成されると仮定する。ハードウェア型暗号化においてセ
キュリティ問題が発見されると、ソフトウェア型暗号化
アルゴリズムは、アプリケーションまたはユーザへ影響
を及ぼすことなくハードウェア型アルゴリズムと交換す
ることができる。セキュリティ問題が解決され、ハード
ウェアが利用できるようになると、ハードウェア暗号化
は暫定的ソフトウェア暗号化ルーチンと簡単に取り替え
ることができる。

【００２２】到来データを暗号化し送出データを復号す
ることもまた本発明の範囲内にあり、そのような結果を
達成するため本明細書に記述される技術を適応させる方
法を当業者は容易に認めることであろう。しかしなが
ら、このような形態でデータを暗号化することは非常に
少数のアプリケーションに限定され、送出データを暗号
化し到来データを復号する方がより典型的であることが
予想される。従って、本発明の実施形態は、送出データ
を暗号化し到来データを復号するＳＴＲＥＡＭＳ型ＴＣ
Ｐ／ＩＰスタックを参照して記述される。本明細書で記
述される技術はいかなるタイプのプロトコル・スタック
にも適用できる点に注意する必要がある。

【００２３】図２は、本発明の実施形態を示すコンピュ
ータ・システム１００の図である。コンピュータ・シス
テム１００は、ユーザ空間１０２およびカーネル空間１
０４を含む。ユーザ空間１０２は、ユーザ・アプリケー
ション１０６およびソケット１０８を含む。カーネル空
間１０４は、ストリーム・ヘッド１１０、暗号化機構モ
ジュール１１２、ＴＣＰレーヤ１１４、ＩＰレーヤ１１
６およびＤＬＰＩレーヤ１１８を含む。

【００２４】図２において、ユーザ・アプリケーション
１０６がＴＣＰ／ＩＰ接続を経由してデータを書き出す
ことを望む時、アプリケーション１０６は、send()コマ
ンドのようなシステム・コールを呼び出すことによって
データをソケット１０８に送り出す。システム・コール
は、データをユーザ空間１０２からカーネル空間１０４
に移動させるcopyin()関数を呼び出す。暗号化機構モジ
ュール１１２がデータを暗号化し、ＴＣＰレーヤ１１４
およびＩＰレーヤ１１６がＴＣＰ／ＩＰプロトコルに従
って処理を実行し、ＤＬＰＩレーヤ１１８が物理的ネッ
トワーク・ハードウェアにデータを提供するＤＭＡ動作
を始動する。図２に示される実施形態は、標準的ＳＴＲ
ＥＡＭＳ型モジュールを使用して、暗号化技術をＳＴＲ
ＥＡＭＳ型プロトコル・スタックに追加する。図２にお
いて、暗号化機構モジュール１１２は、図に示される位
置以外に、ＴＣＰレーヤ１１４とＩＰレーヤ１１６の間
またはＩＰレーヤ１１６とＤＬＰＩレーヤ１１８の間の
ようなその他の種々の位置に置くことも可能である。

【００２５】暗号化機構モジュール１１２は、当業界に
おいてよく知られているソフトウェア型アルゴリズムま
たはハードウェア型アルゴリズムを使用してデータを暗
号化する。加えて、ユーザ・アプリケーション１０６
は、暗号化機構モジュール１１２をスタックに入れたり
暗号化機構モジュール１１２をスタックから引き出すこ
とによって暗号化機能の付加および削除の選択をおこな
うことができる。これは、暗号化機構モジュール１１２
が図２に示されるようにストリーム・ヘッド１１０の次
の最初のモジュールである場合特にうまく動作する。

【００２６】加えて、コンピュータ１００は、ＳＴＲＥ
ＡＭＳのautopush(自動スタック入れ)機能を使用してい
かなるＴＣＰ／ＩＰスタックにも暗号機能を追加できる
ように構成することができる。autopush機構は、あらか
じめ定義されたタイプのスタックがオープンされる時は
いつでもモジュールがオペレーティング・システムによ
って自動的にスタックに入れられることを可能にするも
のである。例えば、適切に構成されたautopush機構を備
えていれば、ユーザ・アプリケーションがＴＣＰ／ＩＰ
スタックをオープンする時は必ず暗号化モジュールもＴ
ＣＰレーヤ１１４の後の位置においてスタックに入れら
れる。

【００２７】また、暗号化機構モジュール１１２をＤＬ
ＰＩレーヤ１１８のすぐ上の位置に置き、単一ＤＬＰＩ
レーヤ・インスタンスを通過するすべてのデータを暗号
化するように構成することもできる。しかしながら、そ
のような構成は、ＤＬＰＩレーヤで暗号化するスタック
とそうではないスタックとを区別するなんらかのメカニ
ズムを必要とする。１つのメカニズムとして、単一のハ
ードウェア・デバイス・インスタンスに関して種々のデ
バイス・ファイル名を使用し、暗号化をサポートするプ
ロトコル・スタックにある１つにファイル名を関連付
け、暗号化をサポートしないプロトコル・スタックに別
のファイル名を関連付ける。暗号化に関連付けられたフ
ァイル名を参照するストリームがオープンされる時は必
ず自動的に暗号化機構モジュール１１２をＤＬＰＩレー
ヤ１１８にプッシュし暗号化機構モジュール１１２をＩ
Ｐレーヤに１１６にリンクするようにオペレーティング
・システムを構成することができるので、上記のメカニ
ズムはautopush機構を用いてうまく動作する。加えて、
暗号化を行わないスタックに関連付けられたファイル名
を参照するストリームがオープンされる時は暗号化機構
モジュール１１２をＤＬＰＩレーヤ１１８にプッシュし
ないようにutopush機構を構成することもできる。

【００２８】また、ＤＬＰＩレーヤにおいて復号するス
タックと復号しないスタックを区別する別のメカニズム
を使用することによって、ifconfig関数を用いてネット
ワーク接続を構成する時暗号化が必要であるか否かを指
定することができる。Unixオペレーティング・システム
においては、ifconfig関数呼び出しは、ネットワーク・
インターフェースにアドレスを割り当てるためあるいは
ネットワーク・インターフェース・パラメータを構成す
るため使用することができる。ifconfig関数呼び出し
は、コンピュータ・システムに現在あるインターフェー
スの各々のネットワーク・アドレスを定義するため起動
時に使用されなければならず、また、その他の時点で特
定のアドレスやその他の動作パラメータを再定義するた
めに使用することができる。従って、本発明は、他のネ
ットワーク・インターフェース・パラメータとともに暗
号化パラメータを定義する能力を持つ修正ificonfig関
数呼び出しを含む。

【００２９】図３は、本発明の別の１つの実施形態を示
すコンピュータ・システム１２０の図である。コンピュ
ータ・システム１２０はユーザ空間１２２およびカーネ
ル空間１２４を含む。ユーザ空間１２２はユーザ・アプ
リケーション１２６およびソケット１２８を含む。カー
ネル空間１２４は、ストリーム・ヘッド１３０、暗号化
マルチプレクサ１３２、ＴＣＰレーヤ１３４、ＩＰレー
ヤ１３６、ＤＬＰＩレーヤ１３８および暗号化機構ドラ
イバ１４０を含む。ユーザ・アプリケーション１２６、
ソケット１２８、ストリーム・ヘッド１３０、ＴＣＰレ
ーヤ１３４、ＩＰレーヤ１３６およびＤＬＰＩレーヤ１
３８は、図２において対応する名前を持つコンポーネン
トと同様に動作する。しかしながら、図２のように暗号
化モジュールをその他のスタック・モジュールと同列に
配置するのではなく、暗号化マルチプレクサ１３２が暗
号化機構ドライバ１４０との間でデータを転送するよう
に構成する。

【００３０】ＳＴＲＥＡＭＳ型マルチプレクサ・モジュ
ールは、データを宛先に送り分けるために使用される標
準的ＳＴＲＥＡＭＳコンポーネントである。例えば、マ
ルチプレクサ・モジュールは、複数のユーザとおそらく
複数の伝送媒体の間で複数メッセージを多重送信するた
めネットワーキング・プロトコルによって使用される。
同様に、暗号マルチプレクサ１３２によって、単一のハ
ードウェア型暗号化機構が複数のＳＴＲＥＡＭＳスタッ
ク・インスタンスによって同時に共用されることが可能
とされる。代替的には、暗号マルチプレクサ１３２は、
単純なスケジューリング・アルゴリズムを使用すること
によって、複数のハードウェア型暗号化機構から、１つ
の使用可能ハードウェア型暗号化機構を選択するように
構成することもできる。

【００３１】従来技術において、安全保護ソケットライ
ブラリ(すなわちSecured Socket Library略してＳＳＬ)
仕様v.3.0は、ユーザ・アプリケーションとの間でメッ
セージを受け渡しする暗号パッケージが、使用される暗
号キーおよび暗号化される接続などを含め暗号復号処理
形態を構成できるようにするプロトコルを定義してい
る。最大限の互換性を提供しプログラミング・コストを
最小にするため、本発明はこのプロトコルを活用して、
暗号キーを保存し暗号化および復号を指示する図３の暗
号化マルチプレクサ１３２を使用する。図２で示された
実施形態では、暗号化機構モジュール１１２が暗号キー
を保存し暗号化および復号を指示した。

【００３２】図２および図３で示される両方の実施形態
ともソフトウェア型暗号化またはハードウェア型暗号化
いずれをも使用するように構成できるが、図２の実施形
態はソフトウェア型暗号化に関する使用の方がより適し
ていて、一方図３の実施形態はハードウェア型暗号化に
関する使用の方がより適している。以下の記述は、暗号
マルチプレクサ１３２および暗号化機構ドライバ１４０
をハードウエァ型暗号化機構と動作できるように適応さ
せる方法を説明するが、同様の技術を使用して、図２の
暗号化機構モジュール１１２をハードウエァ型暗号化機
構と動作できるようにに適応させることができる点は同
業者に認められるであろう。

【００３３】暗号化されるべきデータを指し示すデータ
・メッセージがマルチプレクサ１３２に到着すると、マ
ルチプレクサ１３２はメッセージを検査し適切な暗号キ
ーを調べる。特定のアプリケーションから出されるすべ
てのデータが特定のキーを使用するような形態で暗号キ
ーがアプリケーション・インスタンスに結合されている
かもしれないし、あるいは、特定のＩＰアドレスに送ら
れるすべてのデータが特定のキーを使用して暗号化され
るような形態で暗号キーがＩＰアドレスに結合されてい
る場合もある。暗号化キーを取得した後、暗号化マルチ
プレクサ１３２は、"処理中"カウンタを自動的に増分す
るために使用されるスピンロック(spinlock)を取得す
る。この"処理中"カウンタは、ＴＣＰ／ＩＰスタックが
仕掛かり中の暗号処理を持ち、このカウンタが仕掛かり
中の暗号要求がないことを示す値のゼロに等しくなるま
で当該ストリームをクローズすることはできないこを標
示する。"処理中"カウンタは、暗号マルチプレクサ１３
２のインスタンスの各々と関連づけられるプライベート
・データ構造の一部として定義される。このカウンタは
を検査することによって、システム・パニックにつなが
る可能性のあるクローズ競合状態が防止される。

【００３４】暗号マルチプレクサ１３２は、次に、スタ
ック(この場合ＴＣＰレーヤ１３４)における次のモジュ
ールの書込み待ち行列を目標として持つコールバック機
能(通常はＳＴＲＥＡＭＳ putnext()関数)を含むデータ
構造を設定する。データ構造は、また、暗号化されるべ
きデータを保持するメモリ・ブロックへのポインタを含
む。次に、マルチプレクサは暗号化要求を逐次化する同
期待ち行列を取得する。暗号マルチプレクサ１３２が、
別の暗号化動作が進行中のため同期待ち行列を取得する
ことができない場合は、マルチプレクサはハードウェア
の待機待ち行列スピンロックを取得して将来の処理に備
えて待機待ち行列にトランザクションを入れる。次に、
暗号マルチプレクサ１３２は、スタックを通過するその
他のメッセージの処理へ戻る。

【００３５】同期待ち行列が取得されると、ハードウェ
ア型暗号化プロセスはソフトウェア割り込みサービスを
使用して始動される。このソフトウェア割り込みサービ
スは、ユーザ・アプリケーション１２６と並列して実行
することによってユーザ・アプリケーション１２６の実
行に影響を与えることなくハードウェア型暗号化機構が
暗号処理を実行することを可能にする。データを暗号化
した後、ハードウェア型暗号化機構は割込みサービスル
ーチン(すなわちinterrupt service routine略してＩＳ
Ｒ)を呼び出す。ＩＳＲはコールバック関数を起動し、
コールバック関数がＴＣＰレーヤ１３４の書込み待ち行
列へ暗号化されたデータを送り、"処理中"フラグをフラ
グのスピンロックを取得することによって消去する。暗
号ハードウェアがメモリ・ブロックに記憶されているデ
ータに対して直接暗号化を実行したので、不必要なメモ
リ管理もデータの移動も行わずに暗号化はその場で行わ
れた。

【００３６】到来データに関してもプロセスは基本的に
同様であるが、相違するのは、暗号マルチプレクサ１３
２によって設定されたデータ構造に含められるコールバ
ック機能が目標としてストリーム・ヘッド１３０の読み
取り待ち行列を持つ点である。 図２および図３が、標
準ＳＴＲＥＡＭＳモジュールおよびドライバを使用して
ＳＴＲＥＡＭＳ型プロトコル・スタックに暗号機能がど
のように付加されるかを例示しているが、米国特許出願
第08/593,313号および同第08/545,561号に記載されてい
る技術を適用して、ＳＴＲＥＡＭＳ型プロトコル・スタ
ックにおける暗号機能を提供するよりすぐれたメカニズ
ムを提供することもできる。

【００３７】従来技術のＳＴＲＥＡＭＳ型プロトコル・
スタックにおいては、ストリームはＬＩＦＯ(すなわち
後入れ先出し)スタックにモジュールを入れる(すなわち
プッシュ)することによって構築される。(図１のＴＣＰ
レーヤ２４のような)モジュールがスタックにプッシュ
されると、モジュールは、スタックに以前にプッシュさ
れている(ＩＰレーヤ２６のような)モジュールまたはド
ライバの読み取りおよび書き込み待ち行列にリンクさ
れ、スタックにプッシュされているモジュールの読み取
りおよび書き込み待ち行列は(ストリーム・ヘッド２２
のような)ストリーム・ヘッドにリンクされる。スタッ
クの底部には、(ＤＬＰＩレーヤ２８)のようなドライバ
があって、データを物理的ハードウェアにリンクするか
あるいは処理関数などを実行する。ストリーム・ヘッド
はスタックの先頭にあって、ユーザ空間およびカーネル
空間の間でデータをコピーする。ストリーム・ヘッド
は、また、ユーザ・アプリケーションの観点からストリ
ームに対する入り口の役目を果たす。ドライバおよびス
トリーム・ヘッド間のモジュールは種々の処理機能を実
行する。

【００３８】従来技術においては、ストリームの機能性
の変更は、ストリームを引き離し再構築することを必要
とした。ドライバに隣接するモジュールの機能性を変更
する必要がある場合、ドライバより上のあらゆるモジュ
ールはスタックから引き離されなければならず、(新し
い機能性を含む)モジュールの更新されたバージョンが
スタックにプッシュされなければならず、変更されたモ
ジュールより上流に以前から存在していたすべてのモジ
ュールはスタックに再度プッシュされなければならなか
った。このプロセスは遅くプロセッサは忙殺され、再構
成の間スタックは利用できない。

【００３９】動的関数置き換え機能(すなわちdynamic f
unction replacement)は、モジュールが代替実行経路を
持つことを可能にする。コマンドを出すことによって、
実行中に、種々の機能を切り換えてＳＴＲＥＡＭＳ型プ
ロトコル・スタックから出し入れすることができる。動
的機能置き換えは、スタックを通過するデータの暗号化
および復号を選択的に実行する能力をＴＣＰ／ＩＰスタ
ックに与える理想的なメカニズムである。それに加え
て、ＴＣＰ／ＩＰスタックは複数の暗号プロトコルに関
して構成することができ、これらのプロトコルは必要に
応じて動的に変更することができる。

【００４０】対照的に、動的関数登録(すなわちdynamic
function registration)は、いろいろな関数がストリ
ーム・ヘッドに登録されることを可能にする。ストリー
ム・ヘッドには、登録された関数の実行を指示する機能
をもつコントローラが備えられる。動的関数登録に関す
る１つの特徴的アプリケーションは、３２ビットから６
４ビットへの変換である。３２ビットのアプリケーショ
ンが６４ビットのオペレーティング・システムのストリ
ーム・ヘッドにデータを書き込む場合、データが６４ビ
ット形式に変換される必要があることを認識し、ＳＴＲ
ＥＡＭＳ型スタックにおけるモジュールに変換の実行を
指示するようにストリーム・ヘッドを構成することがで
きる。用語が示す通り、暗号化関数を登録したり、プロ
トコル・スタックを流れるデータに対してそれら関数の
実行を制御するため、動的関数登録を使用することがで
きる。関数の登録は、ユーザ・プロセスあるいはＳＴＲ
ＥＡＭＳ型モジュールまたはドライバによって始動され
る。

【００４１】動的関数登録によって機能性のストリーム
・ヘッドへの追加またはそこからの削除が可能にされ
る。対照的に、動的関数置き換えは、ストリーム・ヘッ
ドへの種々の実行経路およびそこからの種々の実行経路
を入れ替えることによって、ストリームにおけるいかな
るモジュールまたはドライバへも機能性を追加するこを
可能にしあるいはそこから削除することを可能にする。

【００４２】本発明の１つの実施形態は、図１のストリ
ーム・ヘッド２２においてデータを暗号化し復号する。
暗号機能がストリーム・ヘッドにおいて付加されるの
で、動的関数登録を使用して、ストリームを流れるデー
タの暗号化および復号が制御される。別の実施形態は、
ストリーム・スタックとは異なるＴＣＰ／ＩＰスタック
の別の点で(例えば図１のＴＣＰレーヤ２４とＩＰレー
ヤ２６の間で)データを暗号化し復号する。暗号化機能
がモジュールまたはドライバに付加されるので、モジュ
ールまたはドライバを暗号機能を提供するように構成す
るか、または動的関数置き換えを使用してモジュールま
たはドライバの実行経路に暗号化関数を選択的に挿入す
ることができる。

【００４３】以下に記述するハードウェア型実施形態お
よびソフトウェア型実施形態の各々は、当業者が既知の
ＵＤＰ／ＩＰスタックまたはその他のプロトコル・スタ
ックに応用できるように容易に適応することができる。

【００４４】図４は、本発明に従ってＳＴＲＥＡＭＳ型
プロトコル・スタックを通過するデータを暗号化し復号
するように適応されたコンピュータ・システム３０の図
である。コンピュータ・システム３０はユーザ空間３２
およびカーネル空間３４を含む。ユーザ空間３２はユー
ザ・アプリケーション３６およびソケット３８を含む。
カーネル空間３４は、ストリーム・ヘッド４０、暗号化
技術４２、ＴＣＰレーヤ４４、ＩＰレーヤ４６およびＤ
ＬＰＩレーヤ４８を含む。ストリーム・ヘッド４０はレ
ジスタ５０およびコントローラ５２を含み、ＴＣＰレー
ヤ４４は関数ポインタ５４を含む。

【００４５】暗号化技術４２は実際にＳＴＲＥＡＭＳモ
ジュールまたはドライバではない。むしろ、暗号化技術
４２は、ストリーム・ヘッド４０において登録される関
数によってアクセスされるハードウェア型またはソフト
ウェア型暗号化機構である。ソフトウェア型暗号化機構
の場合、ストリーム・ヘッドに登録される関数に暗号コ
ードが含められる。ハードウェア型暗号化機構の場合、
ストリーム・ヘッドに登録される関数は、物理的暗号ハ
ードウェアとインターフェースする暗号化ドライバと通
信する機能を持つ関数である。

【００４６】ストリーム・ヘッドにおいてＳＴＲＥＡＭ
Ｓ型プロトコル・スタックへ暗号機能を提供するため、
動的関数登録を使用して、暗号化技術４２によって実施
される暗号アルゴリズムの実行が制御される。動的関数
登録は、以下の表１のパブリック・データ構造をストリ
ーム・ヘッド・ライブラリ・ファイル<stream.h>に追加
することによって、ストリーム・ヘッドを定義した標準
Ｃライブラリを変更する。

【００４７】

【表１】 struct sth_func_reg { int (*sth_copyin)(); /* 書込側copyin */ int sth_copyin_threshold; /* sth_copyin()へ渡されるアーギュメント */ int (*sth_32_to_64)(); /* 書込側３２対６４ビット変換関数 */ int(*sth_write_opt)(); /* 書込側オプション関数 */ int(*sth_read_opt)(); /* 読取側オプション関数 */ int(*sth_ioctl_opt)() /* ioctlオプション関数 */ int(*sth_64_to_32)(); /* 読取側６４対３２ビット変換関数 */ }

【００４８】本発明は、以下を加えることによって上記
パブリック・データ構造を修正する。 int (*str_copyout)(); /* 読取側copyout */ パブリック構造へのアクセスを可能にするため以下の表
２のプライベート・データ構造がそのストリーム・ヘッ
ド宜言自体に加えられた。

【００４９】

【表２】 struct sth_s { ... struct sth_func_reg sth_f_reg; int32 sth_in_Progress; ... }

【００５０】従来技術のＳＴＲＥＡＭＳ型プロトコル・
スタックにおいては、ストリーム・ヘッドは、カーネル
空間およびユーザ空間の間のインターフェースを提供す
るもので、非常に単純な構造である。動的関数登録によ
ってストリーム・ヘッドを変えたことによって、ストリ
ーム・ヘッドがいろいろな関数へのポインタを記憶し、
ストリーム・ヘッドによって処理されるデータに対して
それら関数を実行することが可能となった。上述のよう
に定義されたsth_f_reg構造は、諸関数へのポインタが
記憶される場所を与える。ストリーム・ヘッドのsth_f_
reg構造が、ある関数へのポインタを含むとすれば、デ
ータがストリーム・ヘッドによって処理される時その関
数が実行される。

【００５１】copyinおよびcopyout関数を例外として、s
th_f_reg構造に定義される関数エントリのすべてはオプ
ションの関数を実行する。言い換えると、sth_f_reg構
造における対応するエントリが関数ポインタを含まなけ
れば、その関数は実行されない。対照的に、copyinおよ
びcopyout関数は代替関数である。copyinに対するエン
トリが存在しなければ、デフォルトのUnix copyinルー
チンが呼び出されて、ユーザ空間およびカーネル空間の
間でデータをコピーする。同様に、copyoutに対するエ
ントリが存在しなければ、デフォルトのUnix copyoutル
ーチンが呼び出されて、ユーザ空間およびカーネル空間
の間でデータをコピーする。

【００５２】書き込み側の暗号化は、暗号化技術４２の
実施形態に応じて、代替関数sth_copyinまたはオプショ
ン関数sth_write_optのいずれかによって実施される。
同様に、読み取り側の暗号化は、代替関数sth_copyout
またはオプション関数sth_read_optのいずれかによって
実施される。

【００５３】代替関数sth_copyinおよびsth_copyoutは
ソフトウェア型暗号化に非常に適していて、この場合、
暗号化技術４２は、暗号アルゴリズムをsth_copyinおよ
びsth_copyoutに組み込むことによって実施される。こ
れら関数を使用して、データは、ユーザ空間３２からカ
ーネル空間３４へコピーされる際に暗号化され、カーネ
ル空間３４からユーザ空間３２へコピーされる際に復号
され、それによってデータを取り扱わねばならない回数
が最小限にとどめられる。チェックサム機能性がcopyin
関数に継続的に含まれるとすれば、sth_copyin_thresho
ldは、米国特許出願第08/593,313号に開示されている通
り、ＴＣＰ ＭＴＵサイズを継続的に反映する。

【００５４】オプション関数sth_read_optおよびsth_wr
ite_optは、ソフトウェア型暗号暗号アルゴリズム、ハ
ードウェア型暗号暗号アルゴリズムいずれとでも使用す
ることができ、いくつかの利点を提供する。第１に、st
h_write_optは、カプセル化されたデータに関して呼び
出すことができる。カプセル化されたデータを形成する
１つの方法は、esballoc()システム・コールを呼び出す
ことである。esballoc()システム・コールは、ＳＴＲＥ
ＡＭＳプログラミング技法において既知の通り、カーネ
ル空間において任意の大きさのメモリを取り出し、b_da
tapおよびb_rptrポインタを介してこのメモリをポイン
トするmblkヘッダを割り当てる。例えば、バッファ・キ
ャッシュに記憶されているデータを暗号化してネットワ
ーク上にデータを伝送することを望む場合、esballoc()
システム・コールは、キャッシュにおけるデータに関し
て呼び出される。カプセル化されているメモリがカーネ
ル空間に既に存在しているので、copyin関数は必要とさ
れない。従って、copyin/encrypt組み合わせ関数をその
データに対して実行することができないが、sth_write_
optがカーネルに既に存在するデータを暗号化すること
ができる。

【００５５】第２の利点は、sth_write_optおよびd sth
_read_optは、mblk連鎖全体が使用可能な時呼び出さ
れ、連鎖がどのように暗号化されるべきかを指示するた
め個々のmblkタイプを暗号アルゴリズムが利用すること
ができることである。対照的に、sth_copyinは、すべて
のデータがカーネル空間３４にコピーされ暗号化される
までmblk連鎖全体に対するアクセスは行わない。例え
ば、１つまたは複数のM_DATAメッセージが後に続く１つ
のM_PROTOメッセージを含むmblk連鎖を考察する。この
場合、M_PROTOメッセージはデータがどのように暗号化
されるかを記述するデータ構造を含んでいる。そのよう
なデータ構造は、暗号化技術識別子、パブリック暗号キ
ー、識別サーバー識別子および暗号化プロセスを制御す
るためのその他の情報を含むことができる。この方法を
使用して、暗号化技術をメッセージ単位、または任意の
間隔で変えることが可能で、それによって暗号の類型化
を避けることができる。

【００５６】暗号化技術４２がハードウェア型暗号化機
構を使用する場合、ハードウェア型暗号化機構を駆動す
る能力を持つドライバが、sth_write_optおよびsth_rea
d_opt関数としてストリーム・ヘッド４０に登録され
る。図３に示される実施形態におけるように、ハードウ
ェア型暗号化機構は、クローズ競合状態を監視されなけ
ればならない。しかし、上述の通り、図３において、ク
ローズ競合状態は、暗号化マルチプレクサ１３２内で変
更され検査される"処理中"カウンタによって検出され
る。従って、暗号化マルチプレクサ１３２に関連するcl
ose()ルーチンは、"処理中"カウンタへのアクセスを持
つ。状況は、図４に示される実施形態においてはいくぶ
ん異なる。ストリーム・ヘッド４０がデータを暗号化し
復号するドライバを制御しているので、sth_in_progres
sカウンタは、ストリーム・ヘッド４０のプライベート
・データ構造の一部として定義され、sth_in_progress
カウンタがゼロにならない限りストリームをクローズす
ることはできない。従って、スタック内の種々のモジュ
ールおよびドライバのclose()関数が"処理中"カウンタ
にアクセスすることを可能にし、レジスタ関数がカウン
タを増分および減分することことを可能にするように、
ＳＴＲＥＡＭＳカーネル・インターフェースは要求され
る。そのようなインターフェースの種々の形態は種々の
Unixバージョンに含められている。伝送非依存ＳＴＲＥ
ＡＭＳカーネル・インターフェースはヒューレット・パ
ッカード社版Unixリリース10.10以後にも含まれている
が、リリーズ10.30によって開発者に公式に提供される
予定である。

【００５７】暗号化が実行されているレベルに隣接する
すべてのモジュールおよびドライバのclose()ルーチン
は、それぞれのモジュールまたはドライバのクローズを
許容するまえに"処理中"カウンタを検査するように変更
されなければならない。close()ルーチンは、当業者に
周知の方法でモジュールのコードを変更することによっ
て、あるいは米国特許出願第08/545,561号に開示されて
いる技法を使用して代替実行経路を定義することによっ
て、変更することができる。

【００５８】下記(表３の)プログラム・コードは、ハー
ドウェア型暗号化機構をサポートするようにclose()ル
ーチンをどのように変更するかを示す。close()ルーチ
ンは以下のコードを含むように修正されなければならな
い。

【００５９】

【表３】 do { spinlock(sth->sth_in_progress_flag_lock) ; if (sth->sth_in_progress) { /* 仕掛かり中の暗号処理がある */ get_sleep_10ck((int) &sth->sth_in_progress_sleep_addr); spinunlock(sth->sth_in_progress_flag_lock); error = sleep(&sth->sleep(&sth->sth_in_progress_sleep_addr); if (error) error=EINTR; } } while (error == 0);

【００６０】上記のループによって、close()ルーチン
はシステム・パニックまたはデッドロックを引き起こす
ことなく休止することができる。スレッドは、暗号化ハ
ードウェアをサポートするために使用されている現在時
スレッドが以下の動作(表４)を行うまで存在することは
できない。

【００６１】

【表４】 spinlock(sth->sth_in_progress_flag_lock) ; sth->sth_in_progress++; spinunlock(sth->sth_in_progress_flag_lock) ; /* 処理を実行 */ /* フラグをリセットして休止中のすべてのスレッドを起動させる */ spinlock(sth->sth_in_progress_flag_lock); sth->sth_in_progress--; spinunlock(sth->sth_in_progress_flag_lock) ; wake up(&sth->sth_in_progress_sleep_addr) ;

【００６２】sth_write_optおよびsth_read_optがスト
リーム・ヘッド４０のレジスタ５０に登録されると、コ
ントローラ５２がsth_write_optを実行して送出データ
を暗号化し、sth_read_optを実行して到来データを復号
する。暗号化技術４２がハードウェア型暗号化機構とし
て実施され、ユーザ・アプリケーションがソケット３８
を経由してデータを書き込む時、sth_write_optがまず
スピンロック(spinlock)にアクセスして"処理中"カウン
タを増分する。上述のように、このフラグはＳＴＲＥＡ
ＭＳカーネル・インターフェースを使用してセットされ
なければならず、close()動作はカウンタがゼロでなけ
れば待機しなければならない。

【００６３】次に、ハードウェア型暗号化機構のハード
ウェア同期待ち行列が、sth_write_optによって取得さ
れなければならない。サービスしなければならないので
同期待ち行列を待つことができない(図３の)暗号化マル
チプレクサ１３２と相違して、sth_write_optはハード
ウェアが利用できるようになるまで休止する。sth_writ
e_optが同期待ち行列を取得すると、sth_write_optはmb
lkデータ・アドレスをハードウェア型暗号化機構に渡
し、ハードウェア暗号化ルーチンを呼び出す。その後の
ある時点でハードウェア型暗号化機構は暗号化されたデ
ータを戻し、sth_write_optが"処理中"カウンタを減分
し、ルーチンは終了する。次に、ＳＴＲＥＡＭＳフレー
ムワークがＴＣＰレーヤ４４へmblkデータ・アドレスを
渡し、処理は続行する。

【００６４】暗号化技術４２がハードウェア型暗号化機
構として実施され、ユーザ・アプリケーションがソケッ
ト３８を経由してデータを読み取る時、sth_read_optが
まずスピンロック(spinlock)にアクセスして"処理中"カ
ウンタを増分する。次に、ハードウェア型暗号化機構の
ハードウェア同期待ち行列が、sth_read_optによって取
得されなければならない。sth_read_optが同期待ち行列
を取得すると、sth_read_optはmblkデータ・アドレスを
ハードウェア型暗号化機構に渡し、ハードウェア暗号化
ルーチンを呼び出す。その後のある時点でハードウェア
型暗号化機構は復号されたデータを戻し、sth_read_opt
が"処理中"カウンタを減分し、ルーチンは終了する。次
に、ＳＴＲＥＡＭＳフレームワークはユーザ空間１２２
へのデータの移動を完了し、それによってユーザ・アプ
リケーション１２６によって要求された読取り動作が完
了する。

【００６５】モジュールまたはドライバがstr_func_ins
tallと呼ばれる関数を実行することによってストリーム
・ヘッドに関数を登録することができ、それによって、
モジュールまたはドライバによって識別された関数の関
数ポインタをsth_f_regデータ構造のエントリに送るこ
とができることが、米国特許出願第08/593,313号に記載
されている。例えば、図４において、ＴＣＰレーヤ４４
は、str_func_installを呼び出すことによって１つの暗
号化関数を登録し、関数ポインタ・テーブル５４に記憶
されている関数ポインタをsth_f_regデータ構造におけ
る適切なエントリへ伝送する。この場合伝送される関数
ポインタはストリーム・ヘッドにおけるレジスタ５０に
よって表されている。

【００６６】本発明は、２つのＳＴＲＥＡＭＳのioctl
コマンドを追加する。これらコマンドは、ユーザ・アプ
リケーション３６が暗号化を構成することを可能にし、
また、その他の動的関数登録アプリケーションにおいて
も役立つものである。ioctlコマンドI_GET_FUNC_REG
は、アプリケーション３６によってプロトコル・スタッ
クにおけるドライバおよびモジュールの各々へストリー
ム・ヘッド４０を経由して転送される。スタックにおけ
るドライバおよびモジュールの各々は、可能な関数の各
々に関する名前およびユニークな識別子を含む関数登録
リストを戻し、それによって、ユーザ・アプリケーショ
ン３６は登録することができるすべての関数の存在を通
知される。この情報を使用して、ユーザ・アプリケーシ
ョン３６は、第２のioctlコマンドI_SET_FUNC_REGを発
することができる。このコマンドによって、米国特許出
願第08/593,313号に記載されているようにモジュールま
たはドライバがstr_func_install関数を実行するかまた
はM_SETOPTSメッセージを送出することによって関数を
登録することができるのと同じ方法でユーザ・アプリケ
ーション３６が関数を登録することを可能にする。

【００６７】別の１つの構成においては、上述のioctl
を使用する安全保護機能を持つスレッドが実行される。
このスレッドは、アプリケーションまたは環境に基づい
て適切な暗号化機能を自動的に登録することができる。
この構成は、暗号化をサポートするように設計されてい
ないアプリケーションについて使用される時特に有益で
ある。また、安全保護機能を有するスレッドは、ユーザ
・ログイン、アプリケーション、宛先ＩＰアドレスまた
はその他の特性に基づく暗号化方法および暗号キーを提
供する認証サーバと連携動作するように構成することも
できる。そのようなスレッドは、ケルベロス(Kerberos)
認証システムのような周知の認証サーバと連携動作する
ように構成することもできる。

【００６８】関数登録の一層洗練された方法は、メッセ
ージを選別し関数を登録しメッセージに基づいた暗号化
を構成するようにＴＣＰレーヤ４４を修正することを必
要とする。ＴＣＰレーヤ４４の修正は、周知の方法でモ
ジュール・コードを修正することによって、または、米
国特許出願第08/545,561号に従って置き換え関数を定義
することによって、実行できる。例えば、ＴＰＩのT_CO
NN_REQおよびT_BIND_REQメッセージのようなメッセージ
を調べる置き換えＴＣＰモジュール書込み関数putを定
義することができる。例えば、ＴＰＩ T_CONN_REQメッ
セージは、特定のＩＰアドレスへの接続を確立するため
に使用される。置き換えput関数は、ＩＰアドレスを検
査し、ＩＰアドレスが安全保護された遠隔のものか否か
を(暗号化サーバへのアクセスまたはその他の手段によ
って)判断するように構築することができる。安全保護
されたものであれば暗号化は不要である。そうでない場
合は、置き換えputルーチンは適切な暗号関数を登録す
ることができる。更に、置き換えputルーチンは、暗号
化キーを供給するか、暗号サーバのような別のソースか
らキーを取得することができる。

【００６９】置き換えputルーチンはＴＰＩのT_BIND_RE
Qメッセージを調べるように構築することもできる。Ｔ
ＰＩのT_BIND_REQメッセージは、指定されたプロトコル
・スタックおよびポートにアプリケーションを結合する
ために使用される。上述と同様な方法で、置き換えput
機能は、どのレベルの暗号化が必要とされるかを決定
し、暗号キーを決定し、ストリーム・ヘッドに暗号化関
数を登録することができる。そのような置き換えput関
数は、暗号化を使用するように元々設計されなかったア
プリケーションに関連して使用される場合特に有益であ
る。

【００７０】以上の記述はＴＣＰ／ＩＰスタックに関す
るものではあるが、同様の技法を他のプロトコル・スタ
ックにも使用できる点は留意されるべきであろう。更
に、ＵＤＰ／ＩＰスタックのような特定タイプのプロト
コル・スタックに関してはより簡単な技法を使用するこ
とが可能である。大部分の実施形態において、ＵＤＰは
無接続データグラム・プロトコルである。図４におい
て、ＴＣＰ／ＩＰプロトコル・スタックは、ＴＣＰレー
ヤ４４をＵＤＰレーヤと置き換えることによってＵＤＰ
／ＩＰプロトコル・スタックに変換することができる。
ＵＤＰメッセージは、M_DATAメッセージが後に続くT_UN
ITDATA_REQメッセージを含むM_PROTOメッセージから成
る。T_UNITDATA_REQメッセージがＩＰアドレスを含むの
で、登録された関数は、メッセージ単位に必要に応じて
暗号化を単純に実行することができる。

【００７１】図５は、本発明のもう１つ別の実施形態に
従ってデータを暗号化および復号するコンピュータ・シ
ステム１５０を示している。コンピュータ・システム１
５０は、ユーザ空間１５２およびカーネル空間１５４を
含む。ユーザ空間１５２は、ユーザ・アプリケーション
１５６およびソケット１５８を含み、カーネル空間１５
４は、ストリーム・ヘッド１６０、ＴＣＰレーヤ１６
２、ＩＰレーヤ１６４、ＤＬＰＩレーヤｌ６６および暗
号化技術１６８を含む。

【００７２】図５において、ＩＰレーヤ１６４およびＤ
ＬＰＩレーヤ１６６のputルーチンは、データを暗号化
技術１６８との間でやりとりするように修正されてい
る。しかしながら、暗号化技術１６８は、ＴＣＰ／ＩＰ
スタック内の別の位置に配置することも可能である。当
業者に周知の技術を使用してputルーチンを修正するこ
とができるし、あるいは、置き換えputルーチンを、米
国特許出願第08/545,561号に開示されている動的関数置
き換えを使用してモジュール実行経路に挿入することも
できる。ソフトウェア型暗号アルゴリズムが使用される
場合、アルゴリズムを直接置き換えputルーチンに含め
ることもできる。

【００７３】図６は、ＩＰレーヤ１６４、ＤＬＰＩレー
ヤ１６６および暗号化ドライバ１６８の詳細な図であ
る。図６は、ハードウェア型暗号化機構を使用してデー
タを暗号化するように構成される実施形態を示す。図６
において、ＤＬＰＩレーヤ１６６の書込み側putルーチ
ンが、出力データを暗号化ドライバ１６８に送る置き換
えputルーチンと置き換えられている。暗号化された
後、データは暗号化ドライバ１６８によってＤＬＰＩレ
ーヤ１６６の書込み待ち行列に置かれる。ＩＰレーヤ１
６４の読取り側putルーチンも、到来データを暗号化ド
ライバ１６８に送る置き換えputルーチンと置き換えら
れている。復号された後、データはＩＰレーヤ１６４の
読取り待ち行列に置かれる。

【００７４】ハードウェア型暗号化をプロトコル・スタ
ックに付加することに伴なう問題は、上述の実施形態に
関連したものと同様である。従って、暗号化ドライバ１
６８は、"処理中"カウンタ、同期待ち行列および処理さ
れているメモリ・ブロックのmblkアドレスを記憶するレ
ジスタを含む。

【００７５】動的関数置き換えを使用して暗号化をコン
ピュータ・システム１５０に付加するためには、ＩＰレ
ーヤ１６４およびＤＬＰＩレーヤ１６６に関する置き換
えputおよびcloseルーチンが定義されなければならな
い。動的関数置き換えは、標準的Unix System V Releas
e 4.2 (SVR4.2) Device Driver ReferenceのＳＴＲＥＡ
ＭＳデータ構造を使用する。動的関数置き換えを実施す
るため修正されるデータ構造は、streamtabおよびqinit
構造である。各モジュールまたはドライバは、qinit構
造へのポインタを含むstreamtab構造を定義する。

【００７６】qinit構造は、読取り、書込み、書込みマ
ルチプレクサおよびＳＴＲＥＡＭＳフレームワークによ
って作成されるマルチプレクサ待ち行列に関するもので
ある。qinit構造は、open、close、put、service、およ
び、モジュールまたはドライバのような待ち行列の所有
者に代わってＳＴＲＥＡＭＳフレームワークによって呼
び出される管理上の関数に関する関数アドレスを含む。

【００７７】qinit構造内で定義される関数は、実際に
はモジュールまたはドライバ開発者によって書かれ、ス
トリームを行き来するメッセージのような現在時アプリ
ケーション実行経路に基づいてフレームワークによって
自動的に実行される。ＳＴＲＥＡＭＳフレームワーク
が、これらのデータ構造のすべての位置を知っていて、
アプリケーション、モジュールまたはドライバから独立
してそれらにアクセスするかもしれないので、動的関数
置き換えは、これらの構造アドレスを、新しい関数アド
レスを定義する代替的streamtabsおよびqinit構造に対
応づけし直す。以下の表５は、基本的ＳＴＲＥＡＭＳフ
レームワーク・データ構造である。

【００７８】

【表５】 /* STREAMS待ち行列初期化構造 */ struct qinit { int (*qi_putp)(); /* 待ち行列putプロシジャ */ int (*qi_srvp)(); /*待ち行列serviceプロシジャ */ int (*qi_qopen)(); /*待ち行列openプロシジャ */ int (*qiqclose)(); /*待ち行列closeプロシジャ */ int (*qi_qadmin)(); /*待ち行列administrativeプロシジャ */ struct module_info*qi_minfo; struct module_stat*qi_mstat: }; /* ＳＴＲＥＡＭＳドライバおよびモジュール宣言構造 */ struct streamtab { struct qinit * st_rdinit; /* 読み取り待ち行列定義 */ struct qinit * st_wrinit; /* 書き込み待ち行列定義 */ struct qinit * st_muxrinit; /* マルチプレクサ・ドライバに関してのみ */ struct qinit * st_muxwinit; /* 同上 */ }

【００７９】これらのデータ構造内の基礎的フィールド
は、デバイス・ドライバ・インターフェースと一般に呼
ばれるSVR4.2 Device Driver Referenceによって標準化
されている。

【００８０】ＩＰモジュールが以下(表６)の標準的置き
換え構造を持つとする。

【００８１】

【表６】 /* 標準読取側qinit構造 */ struct qinit IP_rinit = { IP_rput,IP_rsrv,IP_open,IP_close,NULL,&IP_minfo,NULL} /* 標準書込側qinit構造 */ struct qinit IP_winit = { IP_wput,IP_wsrv,IP_open,IP_close,NULL,&IP_minfo,NULL} /* 置き換え読取側qinit構造 */ struct qinit IP_rinit_encrypt = { IP_rput_encrypt,IP_rsrv_encrypt,IP_open, IP_close_encrypt,NULL,&IP_minfo,NULL } /* 置き換え書込側qinit構造 */ struct qinit IP_winit_encrypt = { IP_wput_encrypt,IP_wsrv_encrypt,IP_open, IP_close_encrypt,NULL,&IP_info,NULL } /* 標準streamtab */ struct streamtab IP = {&IP_rinit,&IP_winit}; /* 置き換え(暗号化)streamtab */ struct streamtab IP_encrypt ={&IP_rinit_encrypt,&IP_rinit_encrypt};

【００８２】動的関数置き換えは、ＳＴＲＥＡＭＳモジ
ュールおよびドライバに関して代替streamtabsを構成す
るstr_alt_install()ルーチンを定義する。代替streamt
absは、ＳＴＲＥＡＭＳioctl呼び出しを使用してストリ
ームの実行経路との間で動的にスワップされることがで
きる。str_alt_install()ルーチンは、以下(表７)の呼
び出しによって呼び出される。

【００８３】

【表７】 str_alt_install (name, flags, n, streamtabs) 但し char *name; /* モジュールまたはドライバの名 */ unsigned int flags; /* STR_IS_MODULE/DEVICE */ int n; /* 代替streamtabsの数 */ struct streamtab *streamtabs[] ; /* streamtabsへのポインタ・アレイ */

【００８４】ユーザ・アプリケーション１５６にとって
利用できるＳＴＲＥＡＭＳioctlコマンドは、I_ALTSTRT
AB_ACTIVEおよび I_ALTSTRTAB_FUTUREである。I_ALTSTR
TAB_ACTIVEはモジュール・インスタンスの活動的stream
tabを選択し、一方、I_ALTSTRTAB_FUTUREは、そのモジ
ュール・タイプの将来のインスタンスがオープンされる
時、モジュール・タイプに関する活動streamtabを選択
する。

【００８５】ＩＰレーヤ１６４に関して定義される置き
換え関数に加えて、ＤＬＰＩレーヤ１６６に関する置き
換え関数も同様の方法で定義されなければならない。置
き換え関数が一旦定義されると、ユーザ・アプリケーシ
ョン１５６は、「暗号化」streamtabsを起動することに
よって暗号化機能を使用可能にし、「デフォルト」stre
amtabsを起動することによって暗号化機能を除去する。
別の構成においては、暗号モジュールがＳＴＲＥＡＭＳ
型プロトコル・スタックにプッシュされる。この場合、
暗号モジュールは、データを通過させる働きをし暗号化
が必要でない時活動的である通常の機能を持ち、暗号化
が必要な時使用される暗号置き換え関数を持つ。

【００８６】Secured Socket Library(SSL)仕様v.3 .O
のような従来技術暗号パッケージはいくつかの目的にか
なう。そのようなパッケージは、使用されるべき暗号化
技術を決定し、使用されるべきパブリックおよびプライ
ベート暗号キーを決定し、暗号化技術との間でデータを
やり取りする。本発明はこれらの特徴を内包しいくつか
の新しい利点を提供する。例えば、ネットワーク通信お
よび暗号化技術の両方に使用される単一の共通インター
フェースが使用され、それによってユーザ・アプリケー
ションは単純化される。暗号パッケージは、暗号化技術
との間でのデータ移動を調整する責任をもはや有してい
ない。これは今やＳＴＲＥＡＭＳフレームワークによっ
て取り扱われる。

【００８７】加えて、本発明は、処理性能およびスルー
プットを向上させる。データは、ユーザ空間およびカー
ネル空間の間の保護領域をただ１度だけ通過するだけで
よく、それによって、必要とされる文脈切り替えの数が
減少する。本発明は、また、従来技術の暗号パッケージ
と比較してシステム資源利用度を減少させる。ＳＳＬ
は、複数のソケット、バッファ、ファイル・テーブル・
エントリ等々を必要とする。対照的に、暗号をサポート
するため既存のプロトコル・スタックを使用できるの
で、暗号化技術との間でデータをやり取りするために付
加される資源だけが、本発明を実施するために必要とさ
れるすべてである。

【００８８】本発明は、また、より基礎的なシステム・
レベルで暗号機能を提供する。本発明を使用して、コン
ピュータ・システムは統一的システム・レベル暗号戦略
を実施するように構成することができる。例えば、ＴＣ
Ｐ／ＩＰを通過するすべてのデータは、ＴＣＰ／ＩＰス
タックを使用する可能性のあるいかなるユーザ・アプリ
ケーションからも独立して、暗号化されることができ
る。これによって、暗号化の制御を複数のアプリケーシ
ョン開発者から取り除き単一のシステム開発者に与える
ことができるので、セキュリティが改善される。また、
暗号化および復号がカーネル空間で行われるので、シス
テムはより安全で、ユーザ・アプリケーションによる攻
撃の可能性は少なくなる。最後に、Unixの標準ＳＴＲＥ
ＡＭＳインターフェースが使用されるので、ユーザ・ア
プリケーションとの継ぎ目のない統合と更新を維持しな
がら、暗号パッケージの継続的改良および更新を実施す
ことができる。

【００８９】以上本発明を特定の好ましい実施形態を参
照して記述したが、本発明の理念および有効範囲を逸脱
することなく本発明の形態および細部を変更することが
できる点は当業者に認められるであろう。

【００９０】本発明には、例として次のような実施様態
が含まれる。 （１）コンピュータ・システム内に配置され、デバイス
とユーザ・プロセスの間で双方向データストリームを伝
送する装置であって、上記デバイスに接続され、上記双
方向データストリームを上記デバイスへ伝送するデバイ
ス・ドライバと、上記デバイスと上記ユーザ・プロセス
の間に配置され、上記ユーザ・プロセスと上記デバイス
・ドライバの間で上記双方向データストリームを伝送す
るストリーム・ヘッドと、上記双方向性データストリー
ムの形態で伝送されるデータに関して暗号化関数を実行
する暗号化機構と、を備える双方向データストリーム伝
送装置。 （２）上記ストリーム・ヘッドが上記暗号化機構を制御
する関数コントローラを含む、上記（１）に記載の双方
向データストリーム伝送装置。 （３）上記暗号化機構が、関数ポインタによって識別さ
れる暗号化関数を備え、上記ストリーム・ヘッドが上記
暗号化関数を識別する関数ポインタを受け取るように構
成される活動関数レジスタを含み、上記暗号化関数コン
トローラが、上記活動関数レジスタに記憶される関数ポ
インタによって識別される上記暗号化関数の実行を制御
する、上記（２）に記載の双方向データストリーム伝送
装置。 （４）上記デバイス・ドライバが、暗号化関数を識別す
る上記関数ポインタを記憶する使用可能関数レジスタを
含む、上記（３）に記載の双方向データストリーム伝送
装置。

【００９１】（５）上記使用可能関数レジスタに記憶さ
れる上記関数ポインタを上記ストリーム・ヘッドの上記
活動関数レジスタへ伝送する動作を上記デバイス・ドラ
イバが始動する、上記（４）に記載の双方向データスト
リーム伝送装置。 （６）該デバイス・ドライバの上記使用可能関数レジス
タに記憶される上記関数ポインタを上記ユーザ・プロセ
スに対して確認するように指示するコマンドを上記デバ
イス・ドライバが上記ユーザ・プロセスから受け取るよ
うに構成される、上記（５）に記載の双方向データスト
リーム伝送装置。 （７）上記ストリーム・ヘッドが、上記関数ポインタを
確認するコマンドをユーザ・プロセスから受け取り、上
記関数ポインタを上記ストリーム・ヘッドの上記活動関
数レジスタに記憶させるように構成される、上記（３）
に記載の双方向データ・ストリーム伝送装置。 （８）上記コンピュータ・システムが、上記使用可能暗
号化関数を上記ユーザ・プロセスに対して確認するスレ
ッドを実行するように構成される、上記（３）に記載の
双方向データストリーム伝送装置。 （９）上記使用可能暗号化関数から選択される暗号化関
数を上記スレッドに対して確認するように上記ユーザ・
プロセスが構成され、上記ストリーム・ヘッドの活動関
数レジスタの中から選択される暗号化関数を識別する関
数ポインタを記憶するように上記スレッドが構成され
る、上記（８）に記載の双方向データストリーム伝送装
置。

【００９２】（１０）上記ユーザ・プロセスが上記ユー
ザ空間に存在し、上記デバイス・ドライバがカーネル空
間に存在し、上記暗号化機構が暗号化とcopyinの組み合
わせ関数を備え、データが上記ユーザ空間と上記カーネ
ル空間の間でコピーされる時上記組み合わせ関数を実行
することによって、上記関数コントローラが上記双方向
データストリームの暗号化を制御する、上記（２）に記
載の双方向データストリーム伝送装置。 （１１）上記デバイス・ドライバがカーネル空間に存在
し、上記双方向性データストリームが上記カーネル空間
に存在するデータ・ブロックを含み、上記暗号化機構が
カーネル空間に存在するデータ・ブロックに対して上記
暗号化関数を実行する、上記（２）に記載の双方向デー
タストリーム伝送装置。 （１２）カーネル空間に存在するデータ・ブロックが１
つのM_PROTOメッセージおよび少くとも１つのM_DATAメ
ッセージによって識別される、上記（１１）に記載の双
方向データストリーム伝送装置。 （１３）上記データ・ブロックに含まれるデータを暗号
化する時上記暗号化機構によって使用されるべき暗号ア
ルゴリズムを上記M_PROTOメッセージが識別する、上記
（１２）に記載の双方向データストリーム伝送装置。 （１４）上記データ・ブロックに含まれるデータに対し
て上記暗号化関数を実行する時上記暗号化機構によって
使用されるべき暗号キーを上記M_PROTOメッセージが識
別する、上記（１２）に記載の双方向データストリーム
伝送装置。 （１５）M_PROTOメッセージが認証サーバを識別し、上
記データ・ブロックに含まれるデータに対して上記暗号
化関数を実行する時上記暗号化機構によって使用される
べき暗号キーを上記認証サーバが識別する、上記（１
２）に記載の双方向データ・ストリーム伝送装置。

【００９３】（１６）上記暗号化機構がソフトウェア関
数を含み、上記デバイス・ドライバと上記ストリーム・
ヘッドの間に接続され両者の間で双方向データストリー
ムを伝送しその双方向データストリームを上記暗号化機
構へ送るモジュールを更に備える、上記（１）に記載の
双方向データ・ストリーム伝送装置。 （１７）上記暗号化機構がハードウェア暗号デバイスを
含み、上記ハードウェア暗号デバイスに接続され、上記
双方向データストリームに対する暗号化関数を実行する
ため上記ハードウェア暗号デバイスを制御する暗号化ド
ライバと、上記デバイス・ドライバと上記ストリーム・
ヘッドの間に配置され、上記暗号化ドライバに接続さ
れ、上記デバイス・ドライバと上記ストリーム・ヘッド
の間で上記双方向データストリームを伝送し、その双方
向データストリームを上記暗号化機構へ送るモジュール
と、を更に備える上記（１）に記載の双方向データスト
リーム伝送装置。 （１８）上記双方向性データストリームが複数のメモリ
・ブロックに細分化され、基準カウントが開始値に初期
化され、上記基準カウントは上記複数のメモリ・ブロッ
クの第１のメモリ・ブロックが上記暗号化ドライバに送
られる時増分され、上記基準カウントは上記複数のメモ
リ・ブロックの第２のメモリ・ブロックが上記暗号化ド
ライバから送られる時減分され、上記基準カウントが上
記開始値と等しくならない限り上記モジュールがクロー
ズされない、上記（１７）に記載の双方向データストリ
ーム伝送装置。

【００９４】（１９）双方向データストリームが未暗号
化部分および既暗号化部分を持ち、入出力デバイスがカ
ーネル空間に存在するデバイス・ドライバに接続され、
ユーザ・プロセスがカーネル空間とユーザ空間の間のイ
ンターフェースを提供するストリーム・ヘッドに接続さ
れるように構成されたコンピュータ・システムにおい
て、上記双方向データストリームが上記ユーザ・プロセ
スと上記入出力デバイスの間を通過する際に該双方向デ
ータストリームに対し暗号関数を実行する方法であっ
て、上記ユーザ空間と上記カーネル空間の間で上記双方
向データストリームの上記未暗号化部分を通信するステ
ップと、上記双方向データストリームの上記未暗号化部
分と上記双方向データストリームの上記既暗号化部分の
間でデータを移動させる暗号化関数を実行するステップ
と、上記双方向データストリームの上記既暗号化部分を
上記デバイス・ドライバに通信するステップと、上記双
方向データストリームの上記既暗号化部分を上記デバイ
ス・ドライバから上記入出力デバイスに通信するステッ
プと、を含む暗号関数実行方法。 （２０）上記双方向データストリームの上記未暗号化部
分と上記双方向データストリームの上記既暗号化部分の
間でデータを移動させる暗号化関数を実行する上記ステ
ップが、上記ストリーム・ヘッドの活動関数レジスタに
記憶されている関数ポインタに基づいて活動暗号化関数
を識別するサブステップと、上記双方向データストリー
ムの上記未暗号化部分と上記双方向データストリームの
上記既暗号化部分の間でデータを移動するため上記活動
暗号化関数を実行するサブステップと、を含む上記（１
９）に記載の暗号関数実行方法。

【００９５】（２１）上記デバイス・ドライバの使用可
能関数レジスタに記憶される関数ポインタに基づいて使
用可能暗号化関数を識別するステップと、上記デバイス
・ドライバの使用可能関数レジスタに上記デバイス・ド
ライバの使用可能関数レジスタに記憶される関数ポイン
タを伝送して使用可能暗号化関数を活動暗号化関数にす
るステップと、を更に含む、上記（２０）に記載の暗号
関数実行方法。 （２２）使用可能関数を識別する関数ポインタを上記ユ
ーザ・プロセスから上記ストリーム・ヘッドの活動関数
レジスタへ伝送して、使用可能暗号化関数を活動暗号化
関数にするステップと、を更に含む、記（２０）に記載
の暗号関数実行方法。 （２３）ユーザ・プロセスに対して使用可能暗号化関数
を識別するスレッドを実行するステップと、使用可能暗
号化関数から１つの暗号化関数を選択するステップと、
選択された暗号化関数を識別する関数ポインタを上記ス
トリーム・ヘッドの活動関数レジスタに送り、上記選択
された暗号化関数を活動暗号化関数にするステップと、
を更に含む、上記（２０）に記載の暗号関数実行方法。 （２４）上記ユーザ空間と上記カーネル空間の間で上記
双方向データストリームの上記未暗号化部分を通信する
ステップおよび上記双方向データストリームの上記未暗
号化部分と上記双方向データストリームの上記既暗号化
部分の間でデータを移動させる暗号化関数を実行するス
テップが、ともに、ユーザ空間から双方向データストリ
ームの未暗号化部分を読み取り、該未暗号化部分を暗号
化して上記双方向データストリームの上記既暗号化部分
に移動させ、上記双方向データストリームの上記未暗号
化部分を上記カーネル空間に記憶する暗号化／copyin組
み合わせ関数を実行するサブステップを含む、上記（１
９）に記載の暗号関数実行方法。

【００９６】（２５）上記双方向データストリームの未
暗号化部分がカーネル空間に存在する未暗号化データ・
ブロックを含み、上記未暗号化データ・ブロックは、１
つのM_PROTOメッセージおよび少くとも１つのM_DATAメ
ッセージによって識別され、上記双方向データストリー
ムの上記未暗号化部分と上記双方向データストリームの
上記既暗号化部分の間でデータを移動させる暗号化関数
を実行するステップが、上記双方向データストリームの
上記既暗号化部分の一部分である未暗号化データ・ブロ
ックを暗号化データ・ブロックへ暗号化するサブステッ
プを含む、上記（１９）に記載の暗号関数実行方法。 （２６）M_PROTOメッセージに基づいて上記未暗号化デ
ータ・ブロックを暗号化するために使用されるべき暗号
化アルゴリズムを識別するステップを更に含む、上記
（２５）に記載の暗号関数実行方法。 （２７）M_PROTOメッセージに基づいて上記未暗号化デ
ータ・ブロックを暗号化するために使用されるべき暗号
キーを識別するステップを更に含む、上記（２５）に記
載の暗号関数実行方法。 （２８）上記M_PROTOメッセージに基づいて認証サーバ
を識別し、該認証サーバに基づいて上記未暗号化データ
・ブロックを暗号化するために使用されるべき暗号キー
を識別するステップを更に含む、上記（２５）に記載の
暗号関数実行方法。

【００９７】（２９）入出力デバイスがカーネル空間に
存在するデバイス・ドライバに接続され、ユーザ・プロ
セスが上記カーネル空間とユーザ空間の間のインターフ
ェースを提供するストリーム・ヘッドに接続されるよう
に構成されたコンピュータ・システムにおいて、データ
ストリームが上記ユーザ・プロセスと上記入出力デバイ
スの間を通過する際未暗号化データストリームを既暗号
化ストリームへと暗号化する方法であって、上記ユーザ
空間から未暗号化データストリームを読み取るステップ
と、上記未暗号化データストリームを既暗号化データス
トリームへ暗号化するステップと、上記既暗号化データ
ストリームを上記カーネル空間へ記憶するステップと、
上記既暗号化データストリームをデバイス・ドライバに
送るステップと、上記既暗号化データストリームを上記
デバイス・ドライバから上記入出力デバイスへ送るステ
ップと、を含む方法。

【００９８】（３０）入出力デバイスがカーネル空間に
存在するデバイス・ドライバに接続され、ユーザ・プロ
セスが上記カーネル空間とユーザ空間の間のインターフ
ェースを提供するストリーム・ヘッドに接続され、モジ
ュールが上記ストリーム・ヘッドと上記ユーザ空間の間
のインターフェースを提供するように構成されたコンピ
ュータ・システムにおいて、データストリームが上記ユ
ーザ・プロセスと上記入出力デバイスの間を通過する際
未暗号化データストリームを既暗号化ストリームへと暗
号化する方法であって、未暗号化データストリームをユ
ーザ空間におけるユーザ・プロセスからカーネル空間に
おけるストリーム・ヘッドへ送信するステップと、上記
未暗号化データストリームを上記ストリーム・ヘッドか
ら上記モジュールへ送信するステップと、上記未暗号化
データストリームを暗号化関数へ渡すステップと、上記
暗号化関数から暗号化されたデータストリームを受け取
るステップと、既暗号化データストリームを上記デバイ
ス・ドライバに送信するステップと、上記既暗号化デー
タストリームを上記デバイス・ドライバから上記入出力
デバイスに送信するステップと、を含む方法。 （３１）上記未暗号化データストリームが複数の未暗号
化メモリ・ブロックに細分化され、上記既暗号化データ
ストリームが、対応する複数の既暗号化データ・ブロッ
クに細分化されるように構成され、基準カウントを開始
値に初期化するステップと、上記複数の未暗号化メモリ
・ブロックの１つの未暗号化メモリ・ブロックが上記暗
号化関数に渡される時上記基準カウントを増分するステ
ップと、上記複数の既暗号化メモリ・ブロックの１つの
既暗号化メモリ・ブロックが上記暗号化関数から受け取
られる時上記基準カウントを減分するステップと、上記
基準カウントが上記開始値と等しくならない限り上記モ
ジュールのクローズ動作を禁止するステップと、を含む
上記（３０）に記載の方法。 （３２）コンピュータ・システム内のプロトコル・スタ
ックに暗号化関数を付加する方法であって、上記暗号化
関数を識別するステップと、上記暗号化関数が上記プロ
トコル・スタックを第１の方向で通過するデータを暗号
化し、上記プロトコル・スタックを第２の方向で通過す
るデータを復号することを可能にするため、上記暗号化
関数をストリーム・ヘッドに登録するステップと、を含
む方法。

【００９９】（３３）コンピュータ・システムにおいて
ユーザ・プロセス、モジュールおよびデバイス・ドライ
バの間の双方向性データ経路を提供するデータ構造であ
って、上記デバイス・ドライバはシステム・カーネルに
常駐して該カーネルとデバイの間のデータを転送する該
デバイスを制御し、ユーザ・プロセスによって書き込ま
れるデータは上記デバイス・ドライバからデバイス方向
へ流れ、上記ドライバによって受け取られるデータはユ
ーザ・プロセスによって受け取られるようにデバイスか
らデバイス・ドライバ方向へ流れるように構成され、通
常関数と、暗号化関数と、上記通常関数を上記暗号化関
数と置き換える手段と、を備えるデータ構造。 （３４）上記通常関数がデータ受け渡し関数である、上
記（３３）に記載のデータ構造。

【０１００】（３５）双方向データストリームがデバイ
スとユーザ・プロセスの間を流れる際該双方向データス
トリームを暗号化し復号する機能を持つコンピュータ読
取可能プログラム・コードを保持するプログラム記憶媒
体であって、上記デバイスに接続されるデバイス・ドラ
イバが上記双方向データストリームを上記デバイスに転
送するようにさせるコンピュータ読取可能プログラム・
コードの第１のセグメントと、上記デバイスと上記ユー
ザ・プロセスの間に接続されるストリーム・ヘッドが上
記双方向データストリームを上記ユーザ・プロセスと上
記デバイス・ドライバの間で転送するようにさせるコン
ピュータ読取可能プログラム・コードの第２のセグメン
トと、暗号化機構が、第１の方向で上記双方向データス
トリームを通過するデータを暗号化し、第２の方向で上
記双方向データストリームを通過するデータを復号する
ようようにさせるコンピュータ読取可能プログラム・コ
ードの第３のセグメントと、を含むプログラム記憶媒
体。

【０１０１】（３６）未暗号化部分および既暗号化部分
を持つ双方向データストリームに対して暗号化関数を実
行するためコンピュータによって実行される命令プログ
ラムを含むコンピュータ読取可能記憶媒体であって、上
記データストリームがユーザ・プロセスと入出力デバイ
スの間を流れ、上記入出力デバイスがカーネル空間に存
在するデバイス・ドライバに接続され、上記ユーザ・プ
ロセスが上記カーネル空間およびユーザ空間の間のイン
ターフェースを提供するストリーム・ヘッドに接続され
るように構成されていて、上記命令プログラムが、上記
双方向データストリームの未暗号化部分を上記ユーザ空
間から上記カーネル空間へ伝送するステップ、暗号化関
数を実行して、上記双方向データストリームの未暗号化
部分から上記双方向データストリームの既暗号化部分へ
データを移動させるステップ、上記双方向データストリ
ームの既暗号化部分を上記入出力デバイスへ伝送するス
テップ、および上記双方向データストリームの既暗号化
部分を上記入出力デバイスから伝送するステップを含
む、コンピュータ読取可能記憶媒体。

【０１０２】

【発明の効果】本発明に従って、プロトコル・スタック
に暗号機能を含むことによってデータのコピーおよび移
動が最小限にとどめられる。また、暗号化および復号が
カーネル空間で実行されるので、ユーザ空間で制御する
従来技術に比較して、悪意ある攻撃に対する暗号プロセ
スの保護が強化される。更に、本発明を使用することに
よって、データはアプリケーションではなくカーネルに
よって与えられるキーを使用して暗号化される。これ
は、暗号化されたデータ伝送を行う際のユーザ・アプリ
ケーションの役割を減少させ、それによってセキュリテ
ィが増加する結果となる。更にまた、本発明はプロトコ
ル・スタックを通過するいかなる情報をも暗号化し復号
するように構成することができるので、ユーザ・アプリ
ケーションが暗号化をサポートする必要はない。

【図面の簡単な説明】

【図１】従来技術のプロトコル・スタックおよび従来技
術の安全保護ソケット・レイヤ暗号パッケージを有する
従来技術のコンピュータ・システムのブロック図であ
る。

【図２】ＳＴＲＥＡＭＳ型モジュールおよびドライバを
使用してデータの暗号化および復号を制御する本発明に
従ったコンピュータ・システムの１つの実施形態を示す
ブロック図である。

【図３】ＳＴＲＥＡＭＳ型暗号化マルチプレクサを使用
して暗号化モジュールまたは暗号化ドライバへデータを
送信する本発明に従ったコンピュータ・システムの１つ
の実施形態を示すブロック図である。

【図４】ストリーム・ヘッドに登録された機能によって
暗号化技術が制御されるコンピュータ・システムのブロ
ック図である。

【図５】暗号化技術がプロトコル・スタックのレイヤと
レイヤの間に挿入される本発明に従ったコンピュータ・
システムの１つの実施形態を示すブロック図である。

【図６】図５に示されたコンピュータ・システムのＩＰ
レーヤとＤＬＰＩレーヤの間に挿入された暗号化ドライ
バを示すブロック図である。

【符号の説明】

１０、３０、１００、１２０、１５０ コンピュータ
・システム １１、３２、１０２、１２２、１５２ ユーザ空間 １２、３６、１０６、１２６、１５６ ユーザ・アプ
リケーション １４、３８、１０８、１２８、１５８ ソケット １６ 安全保護ソケ
ット １８、１１２ 暗号化機構
(モジュール) ２０、３４、１０４、１２４、１５４ カーネル空間 ２２、４０、１１０、１３０、１６０ ストリーム・
ヘッド ２４、４４、１１４、１３４、１６２ ＴＣＰ ２６、４６、１１６、１３６、１６４ ＩＰ ２８、４８、１１８、１３８、１６６ ＤＬＰＩ ４２、１６８ 暗号化技術 ５０ レジスタ ５２ コントローラ ５４ 関数ポインタ １３２ 暗号化マルチプレクサ １４０ 暗号化ドライバ

Claims (1)

【特許請求の範囲】
1. 【請求項１】コンピュータ・システム内に配置され、デ
   バイスとユーザ・プロセスの間で双方向データストリー
   ムを伝送する装置であって、 上記デバイスに接続され、上記双方向データストリーム
   を上記デバイスへ伝送するデバイス・ドライバと、 上記デバイスと上記ユーザ・プロセスの間に配置され、
   上記ユーザ・プロセスと上記デバイス・ドライバの間で
   上記双方向データストリームを伝送するストリーム・ヘ
   ッドと、 上記双方向性データストリームの形態で伝送されるデー
   タに関して暗号化関数を実行する暗号化機構と、 を備える双方向データストリーム伝送装置。