JP2001119394A - 暗号鍵配送方法 - Google Patents
暗号鍵配送方法Info
- Publication number
- JP2001119394A JP2001119394A JP29300799A JP29300799A JP2001119394A JP 2001119394 A JP2001119394 A JP 2001119394A JP 29300799 A JP29300799 A JP 29300799A JP 29300799 A JP29300799 A JP 29300799A JP 2001119394 A JP2001119394 A JP 2001119394A
- Authority
- JP
- Japan
- Prior art keywords
- key
- address
- encryption key
- destination
- terminal
- 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.)
- Withdrawn
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Abstract
(57)【要約】 （修正有）
【課題】 ネットワークを介して端末間で暗号通信する
際の暗号鍵の配送を、装置構成やシステム全体の状態管
理を複雑化せずに、容易に行えるようにする。 【解決手段】 送信側通信端末１０からパス開設要求を
送信側アドレス管理サーバ１２に送信しＳ１、送信側ア
ドレス管理サーバがパス開設要求に公開鍵を付加して宛
先側アドレス管理サーバ１４に送信しＳ２、宛先側アド
レス管理サーバで暗号化に使用する鍵を生成しＳ３、そ
の鍵を確認要求に付加して宛先側通信端末１６に送信す
るＳ４。宛先側通信端末では、確認応答を宛先側アドレ
ス管理サーバに送信しＳ５、宛先側アドレス管理サーバ
で暗号化に使用する鍵を公開鍵によって暗号化しＳ６、
暗号化された鍵をパス開設応答に付加して送信側アドレ
ス管理サーバに送信するＳ７。送信側アドレス管理サー
バは、暗号化された鍵を復号化しＳ８、復元された鍵を
パス開設応答に付加して送信側通信端末に送信するＳ
９。
際の暗号鍵の配送を、装置構成やシステム全体の状態管
理を複雑化せずに、容易に行えるようにする。 【解決手段】 送信側通信端末１０からパス開設要求を
送信側アドレス管理サーバ１２に送信しＳ１、送信側ア
ドレス管理サーバがパス開設要求に公開鍵を付加して宛
先側アドレス管理サーバ１４に送信しＳ２、宛先側アド
レス管理サーバで暗号化に使用する鍵を生成しＳ３、そ
の鍵を確認要求に付加して宛先側通信端末１６に送信す
るＳ４。宛先側通信端末では、確認応答を宛先側アドレ
ス管理サーバに送信しＳ５、宛先側アドレス管理サーバ
で暗号化に使用する鍵を公開鍵によって暗号化しＳ６、
暗号化された鍵をパス開設応答に付加して送信側アドレ
ス管理サーバに送信するＳ７。送信側アドレス管理サー
バは、暗号化された鍵を復号化しＳ８、復元された鍵を
パス開設応答に付加して送信側通信端末に送信するＳ
９。
Description
【０００１】
【発明の属する技術分野】本発明は、暗号鍵配送方法に
係り、さらに詳しくは、ネットワークを介して複数の端
末間で通信を行う際に、通信データを各端末で暗号化し
たり復号化したりするのに必要な暗号鍵の配送を行う暗
号鍵配送方法に関する。
係り、さらに詳しくは、ネットワークを介して複数の端
末間で通信を行う際に、通信データを各端末で暗号化し
たり復号化したりするのに必要な暗号鍵の配送を行う暗
号鍵配送方法に関する。
【０００２】
【従来の技術】従来より、ＡＴＭ（Asynchronous Trans
fer Mode）ネットワーク、Ｘ．２５あるいはフレーム・
リレーに代表されるＮＢＭＡ（Non-Broadcast,Multi-Ac
cess）ネットワークなどでは、インターネット・プロト
コル（Internet Protocol：以下ＩＰ）を使用した通信
を行う際に、ネットワーク層アドレスからデータリンク
層アドレスへ変換するアドレス解決プロトコルとしてＩ
ＥＴＦ（Internet Engineering Task Force ）から発行
されるインターネット関係の公式標準文書ＲＦＣ（Requ
est For Comments）２３３２において、ＮＨＲＰ（Next
Hop ResolutionProtocol）が規格化されている。例え
ば、図５は、グローバルネットワークを介して端末間で
通信を行う場合の従来の手順を説明する図である。図５
に示すように、送信側通信端末２０と送信側アドレス管
理サーバ２２、および、宛先側アドレス管理サーバ２４
と宛先側通信端末２６は、それぞれローカルネットワー
クで接続されていて、送信側アドレス管理サーバ２２と
宛先側アドレス管理サーバ２４同士は、インターネット
のように世界中に張り巡らされたグローバルネットワー
クを介して接続されているものとする。図５の送信側通
信端末２０は、通信を行う前に宛先側通信端末２６のア
ドレス情報を取得する必要がある。まず、送信側通信端
末２０から送信側アドレス管理サーバ２２へパス開設要
求５を送信すると（Ｓ１１）、送信側アドレス管理サー
バ２２は、宛先側アドレス管理サーバ２４宛にパス開設
要求を送信する（Ｓ１２）。宛先側アドレス管理サーバ
２４は、宛先側通信端末２６に対して確認要求を送信す
ると（Ｓ１３）、宛先側通信端末２６が確認応答を返す
ことにより（Ｓ１４）宛先側通信端末２６の存在を確認
することができる。宛先側アドレス管理サーバ２４は、
そこでアドレスの割り当てを行ってアドレス解決を行う
（Ｓ１５）。そして、上述した逆の経路をたどって、宛
先側アドレス管理サーバ２４から送信側アドレス管理サ
ーバ２２へパス開設応答を返し（Ｓ１６）、送信側アド
レス管理サーバ２２は送信側通信端末２０へパス開設応
答が返送される（Ｓ１７）。送信側通信端末２０では、
これに基づいてパスの開設が行われる（Ｓ１８）。従来
は、このような手順によりアドレス解決処理が行われて
いた。また、ネットワークを介して複数の端末間で通信
を行う際に、通信データを安全に伝送したり管理するた
めの情報セキュリティが要求されてきており、その情報
セキュリティの核として暗号技術がある。そこで、暗号
通信を行う場合は、送信側端末と宛先側端末で共通の暗
号鍵を共有する必要があることから（共通鍵暗号方式の
場合）、上述したアドレス解決プロトコルとは別に設計
されたプロトコルによって暗号鍵の配送が行われてい
た。さらに、上記以外にＬＡＮ（ローカルエリアネット
ワーク）などで暗号通信を行う際に必要となる暗号鍵
は、暗号通信に先立って手紙や電話等により予め配送す
るなど、通常のＬＡＮのプロトコルとは別に行われるこ
ともあった。
fer Mode）ネットワーク、Ｘ．２５あるいはフレーム・
リレーに代表されるＮＢＭＡ（Non-Broadcast,Multi-Ac
cess）ネットワークなどでは、インターネット・プロト
コル（Internet Protocol：以下ＩＰ）を使用した通信
を行う際に、ネットワーク層アドレスからデータリンク
層アドレスへ変換するアドレス解決プロトコルとしてＩ
ＥＴＦ（Internet Engineering Task Force ）から発行
されるインターネット関係の公式標準文書ＲＦＣ（Requ
est For Comments）２３３２において、ＮＨＲＰ（Next
Hop ResolutionProtocol）が規格化されている。例え
ば、図５は、グローバルネットワークを介して端末間で
通信を行う場合の従来の手順を説明する図である。図５
に示すように、送信側通信端末２０と送信側アドレス管
理サーバ２２、および、宛先側アドレス管理サーバ２４
と宛先側通信端末２６は、それぞれローカルネットワー
クで接続されていて、送信側アドレス管理サーバ２２と
宛先側アドレス管理サーバ２４同士は、インターネット
のように世界中に張り巡らされたグローバルネットワー
クを介して接続されているものとする。図５の送信側通
信端末２０は、通信を行う前に宛先側通信端末２６のア
ドレス情報を取得する必要がある。まず、送信側通信端
末２０から送信側アドレス管理サーバ２２へパス開設要
求５を送信すると（Ｓ１１）、送信側アドレス管理サー
バ２２は、宛先側アドレス管理サーバ２４宛にパス開設
要求を送信する（Ｓ１２）。宛先側アドレス管理サーバ
２４は、宛先側通信端末２６に対して確認要求を送信す
ると（Ｓ１３）、宛先側通信端末２６が確認応答を返す
ことにより（Ｓ１４）宛先側通信端末２６の存在を確認
することができる。宛先側アドレス管理サーバ２４は、
そこでアドレスの割り当てを行ってアドレス解決を行う
（Ｓ１５）。そして、上述した逆の経路をたどって、宛
先側アドレス管理サーバ２４から送信側アドレス管理サ
ーバ２２へパス開設応答を返し（Ｓ１６）、送信側アド
レス管理サーバ２２は送信側通信端末２０へパス開設応
答が返送される（Ｓ１７）。送信側通信端末２０では、
これに基づいてパスの開設が行われる（Ｓ１８）。従来
は、このような手順によりアドレス解決処理が行われて
いた。また、ネットワークを介して複数の端末間で通信
を行う際に、通信データを安全に伝送したり管理するた
めの情報セキュリティが要求されてきており、その情報
セキュリティの核として暗号技術がある。そこで、暗号
通信を行う場合は、送信側端末と宛先側端末で共通の暗
号鍵を共有する必要があることから（共通鍵暗号方式の
場合）、上述したアドレス解決プロトコルとは別に設計
されたプロトコルによって暗号鍵の配送が行われてい
た。さらに、上記以外にＬＡＮ（ローカルエリアネット
ワーク）などで暗号通信を行う際に必要となる暗号鍵
は、暗号通信に先立って手紙や電話等により予め配送す
るなど、通常のＬＡＮのプロトコルとは別に行われるこ
ともあった。
【０００３】
【発明が解決しようとする課題】しかしながら、このよ
うな従来の暗号鍵配送方法にあっては、暗号通信に用い
る暗号鍵の配送を通常のアドレス解決プロトコルとは別
に設計されたプロトコルを用いて行っていたため、複数
のプロトコルを同時に併用することから、それを実現す
るための装置構成やシステム全体の状態管理が複雑にな
ってしまい、システムの運用上問題となっていた。ま
た、暗号鍵の配送をプロトコル以外の別の方法を用いて
相手方に配送する場合、通常の通信動作とは別に行わな
くてはならないので、手間がかかり、面倒であった。本
発明は、上記課題を解決するためになされたものであっ
て、ネットワークを介して端末間で暗号通信を行う場合
の暗号鍵の配送を、アドレス解決プロトコル上で同一の
データフォーマットを用いて実行することにより、装置
構成やシステム全体の状態管理が複雑化すること無く、
暗号鍵を別に配送するという面倒な手続きも不要な暗号
鍵配送方法を提供することを目的としている。
うな従来の暗号鍵配送方法にあっては、暗号通信に用い
る暗号鍵の配送を通常のアドレス解決プロトコルとは別
に設計されたプロトコルを用いて行っていたため、複数
のプロトコルを同時に併用することから、それを実現す
るための装置構成やシステム全体の状態管理が複雑にな
ってしまい、システムの運用上問題となっていた。ま
た、暗号鍵の配送をプロトコル以外の別の方法を用いて
相手方に配送する場合、通常の通信動作とは別に行わな
くてはならないので、手間がかかり、面倒であった。本
発明は、上記課題を解決するためになされたものであっ
て、ネットワークを介して端末間で暗号通信を行う場合
の暗号鍵の配送を、アドレス解決プロトコル上で同一の
データフォーマットを用いて実行することにより、装置
構成やシステム全体の状態管理が複雑化すること無く、
暗号鍵を別に配送するという面倒な手続きも不要な暗号
鍵配送方法を提供することを目的としている。
【０００４】
【課題を解決するための手段】上記課題を解決するため
に、請求項１に記載の発明は、ネットワークを介して複
数の端末間で通信を行う際に、通信データを各端末で暗
号化／復号化処理するための暗号鍵の配送を行う暗号鍵
配送方法において、前記ネットワーク内でルーティング
を行うアドレス解決プロトコルに前記暗号鍵を組み込ん
で、アドレス解決処理を行うと共に暗号鍵の配送を行う
ものである。これによれば、ネットワーク内でルーティ
ングを行うアドレス解決プロトコルに暗号鍵を組み込ん
で、アドレス解決処理と共に暗号鍵を配送するようにし
たため、暗号通信に必要な暗号鍵を配送する際に別のプ
ロトコルを用意する必要が無くなり、アドレス解決を行
うと同時に暗号鍵の配送が実行されるので、装置構成や
システム全体の状態管理が複雑化することなく、暗号鍵
を別に配送するという面倒な手続き等も不要となる。請
求項２に記載の発明は、請求項１に記載の暗号鍵配送方
法において、前記ネットワークがローカルエリアネット
ワークであって、前記アドレス解決プロトコルにより、
外部から伝送されてきたＩＰパケットの送り先アドレス
から目的の端末のＭＡＣアドレスを求める際に、相手端
末に対してＭＡＣアドレスの問い合わせを行う段階と、
その問い合わせを受けた該当端末が自分のＭＡＣアドレ
スを返答する際に、ＭＡＣアドレスの伝送に用いるプロ
トコルとデータフォーマットを利用して前記端末間に暗
号鍵を配送する段階と、を含むものである。これによれ
ば、ローカルエリアネットワークを介して複数の端末間
で通信を行う際に、アドレス解決プロトコルにより伝送
されてきたＩＰパケットの送り先アドレスに基づいて目
的端末のＭＡＣアドレスを求める場合、全ての端末に対
してＭＡＣアドレスの問い合わせを行い、その問い合わ
せを受けた該当端末が自分のＭＡＣアドレスを返答する
際に、ＭＡＣアドレスの伝送に用いるプロトコルとデー
タフォーマットとを使って共通の暗号鍵を配送するよう
にしたため、１つのアドレス解決プロトコルを実行する
だけで、アドレス解決と同時に暗号鍵を配送することが
可能となり、装置構成やシステム全体の状態管理を複雑
化することなく、面倒な手続き等も不要となる。
に、請求項１に記載の発明は、ネットワークを介して複
数の端末間で通信を行う際に、通信データを各端末で暗
号化／復号化処理するための暗号鍵の配送を行う暗号鍵
配送方法において、前記ネットワーク内でルーティング
を行うアドレス解決プロトコルに前記暗号鍵を組み込ん
で、アドレス解決処理を行うと共に暗号鍵の配送を行う
ものである。これによれば、ネットワーク内でルーティ
ングを行うアドレス解決プロトコルに暗号鍵を組み込ん
で、アドレス解決処理と共に暗号鍵を配送するようにし
たため、暗号通信に必要な暗号鍵を配送する際に別のプ
ロトコルを用意する必要が無くなり、アドレス解決を行
うと同時に暗号鍵の配送が実行されるので、装置構成や
システム全体の状態管理が複雑化することなく、暗号鍵
を別に配送するという面倒な手続き等も不要となる。請
求項２に記載の発明は、請求項１に記載の暗号鍵配送方
法において、前記ネットワークがローカルエリアネット
ワークであって、前記アドレス解決プロトコルにより、
外部から伝送されてきたＩＰパケットの送り先アドレス
から目的の端末のＭＡＣアドレスを求める際に、相手端
末に対してＭＡＣアドレスの問い合わせを行う段階と、
その問い合わせを受けた該当端末が自分のＭＡＣアドレ
スを返答する際に、ＭＡＣアドレスの伝送に用いるプロ
トコルとデータフォーマットを利用して前記端末間に暗
号鍵を配送する段階と、を含むものである。これによれ
ば、ローカルエリアネットワークを介して複数の端末間
で通信を行う際に、アドレス解決プロトコルにより伝送
されてきたＩＰパケットの送り先アドレスに基づいて目
的端末のＭＡＣアドレスを求める場合、全ての端末に対
してＭＡＣアドレスの問い合わせを行い、その問い合わ
せを受けた該当端末が自分のＭＡＣアドレスを返答する
際に、ＭＡＣアドレスの伝送に用いるプロトコルとデー
タフォーマットとを使って共通の暗号鍵を配送するよう
にしたため、１つのアドレス解決プロトコルを実行する
だけで、アドレス解決と同時に暗号鍵を配送することが
可能となり、装置構成やシステム全体の状態管理を複雑
化することなく、面倒な手続き等も不要となる。
【０００５】請求項３に記載の発明は、請求項２に記載
の暗号鍵配送方法において、前記アドレス解決プロトコ
ルにより一度判明したＭＡＣアドレスを、対応するＩＰ
アドレスと、同時に配送した暗号鍵と共にテーブル化
し、それ以降の通信時にアドレス解決を行う際に、送信
先端末のＩＰアドレスが前記テーブルにある場合は、対
応するＭＡＣアドレスと暗号鍵とを読み出して暗号通信
に用いるものである。これによれば、アドレス解決プロ
トコルによって判明したＭＡＣアドレスを、対応するＩ
Ｐアドレスと暗号鍵と共にテーブル化するようにしたた
め、それ以降の通信時にアドレス解決する際に、そのテ
ーブルに送信先端末のＩＰアドレスがある場合は、再度
アドレス解決処理を行う必要が無くなり、対応するＭＡ
Ｃアドレスと暗号鍵とを読み出すだけで、容易かつ迅速
に暗号通信を開始することができる。請求項４に記載の
発明は、グローバルネットワークを介して複数の端末間
で通信を行う際に、通信データを各端末で暗号化／復号
化処理するための暗号鍵の配送を行う暗号鍵配送方法に
おいて、送信側端末から送信側サーバにパス開設要求を
送ると、そのパス開設要求に送信側サーバの公開鍵を付
加して宛先側サーバへ送信する段階と、前記宛先側サー
バは暗号化に使用する鍵を生成し、その鍵を確認要求に
付加して宛先側端末に送信する段階と、前記確認要求を
受信した宛先側端末は確認応答を宛先側サーバに送る
と、暗号化に使用する鍵を宛先側サーバにて前記公開鍵
で暗号化する段階と、前記宛先側サーバはその暗号化さ
れた鍵をパス開設応答に付加して送信側サーバに送り、
その送信側サーバにて暗号化された鍵を復号化する段階
と、送信側サーバは復号化された鍵をパス開設応答に付
加して送信側端末へ送信する段階と、を含むものであ
る。これによれば、グローバルネットワークを介して複
数の端末間で通信を行う際に、送信側端末から送信側サ
ーバにパス開設要求を送り、送信側サーバの公開鍵を付
加して宛先側サーバへ送信し、宛先側サーバで暗号化に
使用する鍵を生成して、その鍵を確認要求に付加して宛
先側端末に送信し、宛先側端末は確認要求を受信すると
確認応答を宛先側サーバに送って、宛先側サーバで暗号
化に使用する鍵を公開鍵で暗号化し、その暗号化された
鍵を宛先側サーバがパス開設応答に付加して送信側サー
バに送って、送信側サーバで暗号化された鍵を復号化
し、その復号化された鍵を送信側サーバがパス開設応答
に付加して送信側端末へ送信するようにする。このた
め、暗号鍵の配送をパス開設要求に対するパス開設応答
に付加して行うことから、１つの通信プロトコルを実行
することにより公開鍵暗号方式の鍵配送も同時に実行さ
れ、装置構成やシステム全体の状態管理を複雑化するこ
となく、面倒な手続き等も不要となる。
の暗号鍵配送方法において、前記アドレス解決プロトコ
ルにより一度判明したＭＡＣアドレスを、対応するＩＰ
アドレスと、同時に配送した暗号鍵と共にテーブル化
し、それ以降の通信時にアドレス解決を行う際に、送信
先端末のＩＰアドレスが前記テーブルにある場合は、対
応するＭＡＣアドレスと暗号鍵とを読み出して暗号通信
に用いるものである。これによれば、アドレス解決プロ
トコルによって判明したＭＡＣアドレスを、対応するＩ
Ｐアドレスと暗号鍵と共にテーブル化するようにしたた
め、それ以降の通信時にアドレス解決する際に、そのテ
ーブルに送信先端末のＩＰアドレスがある場合は、再度
アドレス解決処理を行う必要が無くなり、対応するＭＡ
Ｃアドレスと暗号鍵とを読み出すだけで、容易かつ迅速
に暗号通信を開始することができる。請求項４に記載の
発明は、グローバルネットワークを介して複数の端末間
で通信を行う際に、通信データを各端末で暗号化／復号
化処理するための暗号鍵の配送を行う暗号鍵配送方法に
おいて、送信側端末から送信側サーバにパス開設要求を
送ると、そのパス開設要求に送信側サーバの公開鍵を付
加して宛先側サーバへ送信する段階と、前記宛先側サー
バは暗号化に使用する鍵を生成し、その鍵を確認要求に
付加して宛先側端末に送信する段階と、前記確認要求を
受信した宛先側端末は確認応答を宛先側サーバに送る
と、暗号化に使用する鍵を宛先側サーバにて前記公開鍵
で暗号化する段階と、前記宛先側サーバはその暗号化さ
れた鍵をパス開設応答に付加して送信側サーバに送り、
その送信側サーバにて暗号化された鍵を復号化する段階
と、送信側サーバは復号化された鍵をパス開設応答に付
加して送信側端末へ送信する段階と、を含むものであ
る。これによれば、グローバルネットワークを介して複
数の端末間で通信を行う際に、送信側端末から送信側サ
ーバにパス開設要求を送り、送信側サーバの公開鍵を付
加して宛先側サーバへ送信し、宛先側サーバで暗号化に
使用する鍵を生成して、その鍵を確認要求に付加して宛
先側端末に送信し、宛先側端末は確認要求を受信すると
確認応答を宛先側サーバに送って、宛先側サーバで暗号
化に使用する鍵を公開鍵で暗号化し、その暗号化された
鍵を宛先側サーバがパス開設応答に付加して送信側サー
バに送って、送信側サーバで暗号化された鍵を復号化
し、その復号化された鍵を送信側サーバがパス開設応答
に付加して送信側端末へ送信するようにする。このた
め、暗号鍵の配送をパス開設要求に対するパス開設応答
に付加して行うことから、１つの通信プロトコルを実行
することにより公開鍵暗号方式の鍵配送も同時に実行さ
れ、装置構成やシステム全体の状態管理を複雑化するこ
となく、面倒な手続き等も不要となる。
【０００６】
【発明の実施の形態】以下、本発明の実施の形態を図面
に基づいて詳細に説明する。 （実施の形態１）本実施の形態１では、ローカルエリア
ネットワーク（以下、ＬＡＮ）を用いて端末間で通信す
る際に、共通鍵暗号方式による暗号鍵の配送をＬＡＮの
プロトコルを利用して行うものである。図１は、複数の
端末間を結ぶＬＡＮ１１の一構成例を示す図である。こ
こでは、ノードｎ１に接続された送信側通信端末１３と
ノードｎ２に接続された宛先側通信端末１５との間で暗
号通信が行われる。まず、送信側通信端末１３と宛先側
通信端末１５との間で通信を開始するにあたって、アド
レス解決という処理が実行される。このプロトコルは、
アドレス解決プロトコル（ Address Resolution Protoc
ol：ＡＲＰ）と称され、端末からノードへＩＰ（インタ
ーネット・プロトコル）パケットが伝送されると、その
ＩＰパケットの送り先アドレス（Destination Addres
s）から宛先端末のＭＡＣ（メディア・アクセス・コン
トロール：媒体アクセス制御）アドレスを求める。ＭＡ
Ｃアドレスの求め方は、ＬＡＮ１１のブロードキャスト
機能を利用し、全ての端末に対して問い合わせを行っ
て、該当する端末が自分のＭＡＣアドレスを返答すると
いう手順で行われる。ここでＭＡＣとは、ＯＳＩ参照モ
デルのデータリンク層の下位層を構成するもので、ＭＡ
Ｃアドレスは、イーサーネット（Ethernet）におけるデ
ータリンク層でのアドレスを意味している。このような
ＭＡＣアドレスは、ネットワーク上に接続された端末や
機器同士で通信するのに必要であって、データリンク層
で動作する機器全てに割り振られ、端末や機器がそれぞ
れ固有のアドレスを持っている。
に基づいて詳細に説明する。 （実施の形態１）本実施の形態１では、ローカルエリア
ネットワーク（以下、ＬＡＮ）を用いて端末間で通信す
る際に、共通鍵暗号方式による暗号鍵の配送をＬＡＮの
プロトコルを利用して行うものである。図１は、複数の
端末間を結ぶＬＡＮ１１の一構成例を示す図である。こ
こでは、ノードｎ１に接続された送信側通信端末１３と
ノードｎ２に接続された宛先側通信端末１５との間で暗
号通信が行われる。まず、送信側通信端末１３と宛先側
通信端末１５との間で通信を開始するにあたって、アド
レス解決という処理が実行される。このプロトコルは、
アドレス解決プロトコル（ Address Resolution Protoc
ol：ＡＲＰ）と称され、端末からノードへＩＰ（インタ
ーネット・プロトコル）パケットが伝送されると、その
ＩＰパケットの送り先アドレス（Destination Addres
s）から宛先端末のＭＡＣ（メディア・アクセス・コン
トロール：媒体アクセス制御）アドレスを求める。ＭＡ
Ｃアドレスの求め方は、ＬＡＮ１１のブロードキャスト
機能を利用し、全ての端末に対して問い合わせを行っ
て、該当する端末が自分のＭＡＣアドレスを返答すると
いう手順で行われる。ここでＭＡＣとは、ＯＳＩ参照モ
デルのデータリンク層の下位層を構成するもので、ＭＡ
Ｃアドレスは、イーサーネット（Ethernet）におけるデ
ータリンク層でのアドレスを意味している。このような
ＭＡＣアドレスは、ネットワーク上に接続された端末や
機器同士で通信するのに必要であって、データリンク層
で動作する機器全てに割り振られ、端末や機器がそれぞ
れ固有のアドレスを持っている。
【０００７】このＬＡＮ１１において、ＭＡＣアドレス
の問い合わせ元の機器がノードｎ１で、問い合わせ先の
機器がノードｎ２であって、送信側通信端末１３と宛先
側通信端末１５との間で共通鍵暗号方式による暗号通信
を実現するには、ノードｎ１とノードｎ２との間で暗号
鍵を共有することが必要となる。その暗号鍵の共有を実
現するため、アドレス解決においてＭＡＣアドレスを通
知する際に、それを伝送するプロトコルとデータフォー
マットとを利用して同時にノードｎ２からノードｎ１に
暗号鍵を配送するようにする。その際、暗号鍵を平文の
ままで配送することが危険な場合は、ノードｎ１はＭＡ
Ｃアドレスの問い合わせを行う際に自分の公開鍵もブロ
ードキャストし、該当する端末はその公開鍵を用いて暗
号通信に用いる暗号鍵を暗号化して、ＭＡＣアドレスを
返答するプロトコル上で同一のフォーマットを用いてノ
ードｎ１に配送する（公開鍵暗号方式の場合）。また、
図２は、ノードｎ２のＩＰアドレス、ＭＡＣアドレス、
および配送された暗号鍵をノードｎ１でテーブル化した
例を示す図であり、次回以降のアドレス解決の処理にこ
のテーブルを利用することで、同一の宛先側通信端末と
の間で暗号通信を行う際の暗号鍵の配送処理が省略でき
ることから、より迅速な通信が実現できる。
の問い合わせ元の機器がノードｎ１で、問い合わせ先の
機器がノードｎ２であって、送信側通信端末１３と宛先
側通信端末１５との間で共通鍵暗号方式による暗号通信
を実現するには、ノードｎ１とノードｎ２との間で暗号
鍵を共有することが必要となる。その暗号鍵の共有を実
現するため、アドレス解決においてＭＡＣアドレスを通
知する際に、それを伝送するプロトコルとデータフォー
マットとを利用して同時にノードｎ２からノードｎ１に
暗号鍵を配送するようにする。その際、暗号鍵を平文の
ままで配送することが危険な場合は、ノードｎ１はＭＡ
Ｃアドレスの問い合わせを行う際に自分の公開鍵もブロ
ードキャストし、該当する端末はその公開鍵を用いて暗
号通信に用いる暗号鍵を暗号化して、ＭＡＣアドレスを
返答するプロトコル上で同一のフォーマットを用いてノ
ードｎ１に配送する（公開鍵暗号方式の場合）。また、
図２は、ノードｎ２のＩＰアドレス、ＭＡＣアドレス、
および配送された暗号鍵をノードｎ１でテーブル化した
例を示す図であり、次回以降のアドレス解決の処理にこ
のテーブルを利用することで、同一の宛先側通信端末と
の間で暗号通信を行う際の暗号鍵の配送処理が省略でき
ることから、より迅速な通信が実現できる。
【０００８】次に、動作を説明する。まず、アドレス解
決プロトコル（ＡＲＰ）に基づいて、図１の送信側通信
端末１３からノードｎ１に伝送されてきたＩＰパケット
のＩＰアドレスに対応したＭＡＣアドレスの問い合わせ
が行われる。その際、必要に応じて暗号鍵配送時に暗号
鍵を暗号化するのに利用するノードｎ１の公開鍵をブロ
ードキャストする。そして、ＭＡＣアドレスの問い合わ
せに対して該当する宛先側通信端末１５が接続されたノ
ードｎ２は、自分のＭＡＣアドレスを回答すると同時
に、ノードｎ１との暗号通信に用いる暗号鍵をＭＡＣア
ドレスを回答するプロトコルの同一のデータフォーマッ
ト上で配送するようにする。その際、暗号鍵を暗号化し
てノードｎ１に配送する場合は、ノードｎ１から知らせ
てきた公開鍵を用いて暗号化して配送する。ノードｎ１
は、自分の持っている秘密鍵を用いて暗号化した暗号鍵
を復号化し、暗号通信に用いる暗号鍵を得る。ノードｎ
１では、ノードｎ２よりＭＡＣアドレスと共に送られて
きた暗号鍵を用いて、ＩＰパケットを暗号化してノード
ｎ２へ送信する。これと同様にノードｎ２も同じ暗号鍵
を用いてＩＰパケットを暗号化して、ノードｎ１へ返信
する。このように、本実施の形態１によれば、アドレス
解決と同時にノードｎ１とノードｎ２との間で暗号鍵の
配布が行われ、暗号通信が実施することができる。ま
た、本実施の形態１によれば、上述したアドレス解決に
よって得られたＭＡＣアドレス、および暗号通信に用い
る暗号鍵は、図２に示すように、ＩＰアドレスに対応す
るように、ＩＰアドレス／ＭＡＣアドレス／暗号鍵の関
係を記述する形式でテーブル化することにより、次回以
降にノードｎ１とノードｎ２との間で暗号通信を行う場
合は、ＩＰアドレスに従って図２のテーブルからＭＡＣ
アドレスと暗号鍵を読み出すだけで容易に暗号通信を行
うことができる。
決プロトコル（ＡＲＰ）に基づいて、図１の送信側通信
端末１３からノードｎ１に伝送されてきたＩＰパケット
のＩＰアドレスに対応したＭＡＣアドレスの問い合わせ
が行われる。その際、必要に応じて暗号鍵配送時に暗号
鍵を暗号化するのに利用するノードｎ１の公開鍵をブロ
ードキャストする。そして、ＭＡＣアドレスの問い合わ
せに対して該当する宛先側通信端末１５が接続されたノ
ードｎ２は、自分のＭＡＣアドレスを回答すると同時
に、ノードｎ１との暗号通信に用いる暗号鍵をＭＡＣア
ドレスを回答するプロトコルの同一のデータフォーマッ
ト上で配送するようにする。その際、暗号鍵を暗号化し
てノードｎ１に配送する場合は、ノードｎ１から知らせ
てきた公開鍵を用いて暗号化して配送する。ノードｎ１
は、自分の持っている秘密鍵を用いて暗号化した暗号鍵
を復号化し、暗号通信に用いる暗号鍵を得る。ノードｎ
１では、ノードｎ２よりＭＡＣアドレスと共に送られて
きた暗号鍵を用いて、ＩＰパケットを暗号化してノード
ｎ２へ送信する。これと同様にノードｎ２も同じ暗号鍵
を用いてＩＰパケットを暗号化して、ノードｎ１へ返信
する。このように、本実施の形態１によれば、アドレス
解決と同時にノードｎ１とノードｎ２との間で暗号鍵の
配布が行われ、暗号通信が実施することができる。ま
た、本実施の形態１によれば、上述したアドレス解決に
よって得られたＭＡＣアドレス、および暗号通信に用い
る暗号鍵は、図２に示すように、ＩＰアドレスに対応す
るように、ＩＰアドレス／ＭＡＣアドレス／暗号鍵の関
係を記述する形式でテーブル化することにより、次回以
降にノードｎ１とノードｎ２との間で暗号通信を行う場
合は、ＩＰアドレスに従って図２のテーブルからＭＡＣ
アドレスと暗号鍵を読み出すだけで容易に暗号通信を行
うことができる。
【０００９】（実施の形態２）本実施の形態２では、暗
号化に使用する鍵を送信側および宛先側以外の第３者に
決して知られないようにするため、その鍵をグローバル
ネットワーク領域において公開鍵暗号方式を用いて配送
するようにしたものである。図３は、本実施の形態２に
おける通信手順を説明する図である。図３において、送
信側通信端末１０と送信側アドレス管理サーバ１２、お
よび、宛先側アドレス管理サーバ１４と宛先側通信端末
１６は、それぞれローカルネットワークで接続されてお
り、送信側アドレス管理サーバ１２と宛先側アドレス管
理サーバ１４同士は、インターネットのように世界中に
張り巡らされたグローバルネットワークを介して接続さ
れている。図３には、説明を簡略化するために送信側通
信端末１０と宛先側通信端末１６の２つの通信端末しか
描かれていないが、実際には無数の端末が存在する。次
に、動作を説明する。まず、送信側通信端末１０からパ
ス開設要求を送信側アドレス管理サーバ１２に送信する
と（Ｓ１）、送信側アドレス管理サーバ１２は、そのパ
ス開設要求に公開鍵を付加して宛先側アドレス管理サー
バ１４に送信する（Ｓ２）。そして、宛先側アドレス管
理サーバ１４は、暗号化に使用する鍵を生成して（Ｓ
３）、その鍵を確認要求に付加して宛先側通信端末１６
に送信する（Ｓ４）。宛先側通信端末１６では、受信し
た確認要求に対する確認応答を宛先側アドレス管理サー
バ１４に送信する（Ｓ５）。宛先側アドレス管理サーバ
１４は、上記Ｓ３で生成した暗号化に使用する鍵を送信
側アドレス管理サーバ１２の公開鍵によって暗号化し
（Ｓ６）、その暗号化された鍵をパス開設応答に付加し
て送信側アドレス管理サーバ１２に送信する（Ｓ７）。
送信側アドレス管理サーバ１２は、前述の宛先側アドレ
ス管理サーバ１４で暗号化された鍵を復号化し（Ｓ
８）、その復元された鍵をパス開設応答に付加して送信
側通信端末１０に送信する（Ｓ９）。
号化に使用する鍵を送信側および宛先側以外の第３者に
決して知られないようにするため、その鍵をグローバル
ネットワーク領域において公開鍵暗号方式を用いて配送
するようにしたものである。図３は、本実施の形態２に
おける通信手順を説明する図である。図３において、送
信側通信端末１０と送信側アドレス管理サーバ１２、お
よび、宛先側アドレス管理サーバ１４と宛先側通信端末
１６は、それぞれローカルネットワークで接続されてお
り、送信側アドレス管理サーバ１２と宛先側アドレス管
理サーバ１４同士は、インターネットのように世界中に
張り巡らされたグローバルネットワークを介して接続さ
れている。図３には、説明を簡略化するために送信側通
信端末１０と宛先側通信端末１６の２つの通信端末しか
描かれていないが、実際には無数の端末が存在する。次
に、動作を説明する。まず、送信側通信端末１０からパ
ス開設要求を送信側アドレス管理サーバ１２に送信する
と（Ｓ１）、送信側アドレス管理サーバ１２は、そのパ
ス開設要求に公開鍵を付加して宛先側アドレス管理サー
バ１４に送信する（Ｓ２）。そして、宛先側アドレス管
理サーバ１４は、暗号化に使用する鍵を生成して（Ｓ
３）、その鍵を確認要求に付加して宛先側通信端末１６
に送信する（Ｓ４）。宛先側通信端末１６では、受信し
た確認要求に対する確認応答を宛先側アドレス管理サー
バ１４に送信する（Ｓ５）。宛先側アドレス管理サーバ
１４は、上記Ｓ３で生成した暗号化に使用する鍵を送信
側アドレス管理サーバ１２の公開鍵によって暗号化し
（Ｓ６）、その暗号化された鍵をパス開設応答に付加し
て送信側アドレス管理サーバ１２に送信する（Ｓ７）。
送信側アドレス管理サーバ１２は、前述の宛先側アドレ
ス管理サーバ１４で暗号化された鍵を復号化し（Ｓ
８）、その復元された鍵をパス開設応答に付加して送信
側通信端末１０に送信する（Ｓ９）。
【００１０】図４は、入力ＩＰパケットを出力ＩＰパケ
ットに変換する際のフォーマット変換例を示す図であ
り、（ａ）は入力ＩＰパケットの図、（ｂ）は出力ＩＰ
パケットの図である。ここでは、図４（ａ）の入力ＩＰ
パケットのフレーム長から１２（ＭＡＣアドレスｗｏｒ
ｄｓ数）を減算し、６（挿入するｗｏｒｄｓ数）を加算
することで、図４（ｂ）の出力ＩＰパケットのフレーム
長を得るようにしている。このように、本実施の形態２
によれば、アドレス解決処理と同時に暗号鍵の配送を１
つのアドレス解決プロトコル（ＡＲＰ）で用いて行うよ
うにしたため、これまでの装置構成やシステム全体の状
態管理を変更する必要が無くなり、別の手続きで暗号鍵
を配送するなどの手間も不要となる。なお、本実施の形
態２では、鍵を暗号化する手法として公開鍵暗号方式で
あれば良く、ＲＳＡ、ラビン暗号方式、あるいは楕円暗
号方式など何れも適用することが可能である。また、本
実施の形態２では、通信端末間のｅｎｄ−ｔｏ−ｅｎｄ
の暗号化について説明したが、必ずしもその場合に限ら
れるものではなく、通信端末をルータ（ノード）等に置
き換えることによって、例えば、ルータ−ルータ間のリ
ンク暗号の場合などに適用するようにしても良い。さら
に、本実施の形態２では、実施の形態１の図２で説明し
たのと同様に、配送された暗号鍵を宛先端末に対応させ
てテーブル化しても良く、再度同じ宛先端末と暗号通信
する場合の暗号鍵の配送に関して省力化することができ
る。
ットに変換する際のフォーマット変換例を示す図であ
り、（ａ）は入力ＩＰパケットの図、（ｂ）は出力ＩＰ
パケットの図である。ここでは、図４（ａ）の入力ＩＰ
パケットのフレーム長から１２（ＭＡＣアドレスｗｏｒ
ｄｓ数）を減算し、６（挿入するｗｏｒｄｓ数）を加算
することで、図４（ｂ）の出力ＩＰパケットのフレーム
長を得るようにしている。このように、本実施の形態２
によれば、アドレス解決処理と同時に暗号鍵の配送を１
つのアドレス解決プロトコル（ＡＲＰ）で用いて行うよ
うにしたため、これまでの装置構成やシステム全体の状
態管理を変更する必要が無くなり、別の手続きで暗号鍵
を配送するなどの手間も不要となる。なお、本実施の形
態２では、鍵を暗号化する手法として公開鍵暗号方式で
あれば良く、ＲＳＡ、ラビン暗号方式、あるいは楕円暗
号方式など何れも適用することが可能である。また、本
実施の形態２では、通信端末間のｅｎｄ−ｔｏ−ｅｎｄ
の暗号化について説明したが、必ずしもその場合に限ら
れるものではなく、通信端末をルータ（ノード）等に置
き換えることによって、例えば、ルータ−ルータ間のリ
ンク暗号の場合などに適用するようにしても良い。さら
に、本実施の形態２では、実施の形態１の図２で説明し
たのと同様に、配送された暗号鍵を宛先端末に対応させ
てテーブル化しても良く、再度同じ宛先端末と暗号通信
する場合の暗号鍵の配送に関して省力化することができ
る。
【００１１】
【発明の効果】以上説明したように、請求項１に記載の
発明によれば、暗号通信に必要な暗号鍵を配送する際に
別のプロトコルを用意する必要が無くなって、アドレス
解決を行うと同時に暗号鍵が配送されるので、装置構成
やシステム全体の状態管理が複雑化することなく、暗号
鍵を別に配送するという面倒な手続き等も不要となる。
請求項２に記載の発明によれば、１つのアドレス解決プ
ロトコルを実行するだけで、アドレス解決と同時に暗号
鍵を配送することができるので、装置構成やシステム全
体の状態管理を複雑化することなく、面倒な手続き等も
不要となる。請求項３に記載の発明によれば、アドレス
解決と暗号鍵配送によって判明したＭＡＣアドレスとＩ
Ｐアドレスと暗号鍵とを関連付けてテーブル化するの
で、それ以降同じ送信先端末との間で暗号通信を行う際
に、暗号鍵の配送に係る手間が省け、容易かつ迅速に暗
号通信を開始することができる。請求項４に記載の発明
によれば、暗号鍵の配送をパス開設要求に対するパス開
設応答に付加して行うので、１つのプロトコル制御だけ
で公開鍵暗号方式の鍵配送をも同時に実行することがで
き、装置構成やシステム全体の状態管理を複雑化させる
こと無く、面倒な手続き等も不要となる。
発明によれば、暗号通信に必要な暗号鍵を配送する際に
別のプロトコルを用意する必要が無くなって、アドレス
解決を行うと同時に暗号鍵が配送されるので、装置構成
やシステム全体の状態管理が複雑化することなく、暗号
鍵を別に配送するという面倒な手続き等も不要となる。
請求項２に記載の発明によれば、１つのアドレス解決プ
ロトコルを実行するだけで、アドレス解決と同時に暗号
鍵を配送することができるので、装置構成やシステム全
体の状態管理を複雑化することなく、面倒な手続き等も
不要となる。請求項３に記載の発明によれば、アドレス
解決と暗号鍵配送によって判明したＭＡＣアドレスとＩ
Ｐアドレスと暗号鍵とを関連付けてテーブル化するの
で、それ以降同じ送信先端末との間で暗号通信を行う際
に、暗号鍵の配送に係る手間が省け、容易かつ迅速に暗
号通信を開始することができる。請求項４に記載の発明
によれば、暗号鍵の配送をパス開設要求に対するパス開
設応答に付加して行うので、１つのプロトコル制御だけ
で公開鍵暗号方式の鍵配送をも同時に実行することがで
き、装置構成やシステム全体の状態管理を複雑化させる
こと無く、面倒な手続き等も不要となる。
【図１】複数の端末間を結ぶＬＡＮの一構成例を示す図
である。
である。
【図２】ノードｎ２のＩＰアドレス、ＭＡＣアドレス、
および配送された暗号鍵をノードｎ１でテーブル化した
例を示す図である。
および配送された暗号鍵をノードｎ１でテーブル化した
例を示す図である。
【図３】本実施の形態２における通信手順を説明する図
である。
である。
【図４】入力ＩＰパケットを出力ＩＰパケットに変換す
る際のフォーマット変換例を示す図であり、（ａ）は入
力ＩＰパケットの図、（ｂ）は出力ＩＰパケットの図で
ある。
る際のフォーマット変換例を示す図であり、（ａ）は入
力ＩＰパケットの図、（ｂ）は出力ＩＰパケットの図で
ある。
【図５】グローバルネットワークを介して端末間で通信
を行う場合の従来の手順を説明する図である。
を行う場合の従来の手順を説明する図である。
１０ 送信側通信端末、 １１ ローカルエリアネットワーク（ＬＡＮ）、 １２ 送信側アドレス管理サーバ、 １３ 送信側通信端末、 １４ 宛先側アドレス管理サーバ、 １５ 宛先側通信端末、 １６ 宛先側通信端末。
───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5J104 AA01 AA16 EA01 EA04 EA19 NA02 PA07 5K030 GA15 HA08 HC01 HC14 HD03 HD10 JT02 KA01 KA05 KA07 LD19 5K033 AA08 CB08 DA05 DB12 DB14 DB16 DB19 EA07 EC03 9A001 CC06 CC08 EE03 LL03
Claims (4)
- 【請求項１】 ネットワークを介して複数の端末間で通
信を行う際に、通信データを各端末で暗号化／復号化処
理するための暗号鍵の配送を行う暗号鍵配送方法におい
て、 前記ネットワーク内でルーティングを行うアドレス解決
プロトコルに前記暗号鍵を組み込んで、アドレス解決処
理を行うと共に暗号鍵の配送も行うことを特徴とする暗
号鍵配送方法。 - 【請求項２】 前記ネットワークがローカルエリアネッ
トワークであって、 前記アドレス解決プロトコルにより、外部から伝送され
てきたＩＰパケットの送り先アドレスから目的の端末の
ＭＡＣアドレスを求める際に、相手端末に対してＭＡＣ
アドレスの問い合わせを行う段階と、 その問い合わせを受けた該当端末が自分のＭＡＣアドレ
スを返答する際に、ＭＡＣアドレスの伝送に用いるプロ
トコルとデータフォーマットを利用して前記端末間に暗
号鍵を配送する段階と、 を含むことを特徴とする請求項１に記載の暗号鍵配送方
法。 - 【請求項３】 前記アドレス解決プロトコルにより一度
判明したＭＡＣアドレスを、対応するＩＰアドレスと、
同時に配送した暗号鍵と共にテーブル化し、 それ以降の通信時にアドレス解決を行う際に、送信先端
末のＩＰアドレスが前記テーブルにある場合は、対応す
るＭＡＣアドレスと暗号鍵とを読み出して暗号通信に用
いることを特徴とする請求項２に記載の暗号鍵配送方
法。 - 【請求項４】 グローバルネットワークを介して複数の
端末間で通信を行う際に、通信データを各端末で暗号化
／復号化処理するための暗号鍵の配送を行う暗号鍵配送
方法において、 送信側端末から送信側サーバにパス開設要求を送ると、
そのパス開設要求に送信側サーバの公開鍵を付加して宛
先側サーバへ送信する段階と、 前記宛先側サーバは暗号化に使用する鍵を生成し、その
鍵を確認要求に付加して宛先側端末に送信する段階と、 前記確認要求を受信した宛先側端末は確認応答を宛先側
サーバに送ると、暗号化に使用する鍵を宛先側サーバに
て前記公開鍵で暗号化する段階と、 前記宛先側サーバはその暗号化された鍵をパス開設応答
に付加して送信側サーバに送り、その送信側サーバにて
暗号化された鍵を復号化する段階と、 送信側サーバは復号化された鍵をパス開設応答に付加し
て送信側端末へ送信する段階と、 を含むことを特徴とする暗号鍵配送方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP29300799A JP2001119394A (ja) | 1999-10-14 | 1999-10-14 | 暗号鍵配送方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP29300799A JP2001119394A (ja) | 1999-10-14 | 1999-10-14 | 暗号鍵配送方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2001119394A true JP2001119394A (ja) | 2001-04-27 |
Family
ID=17789280
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP29300799A Withdrawn JP2001119394A (ja) | 1999-10-14 | 1999-10-14 | 暗号鍵配送方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2001119394A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014125572A1 (ja) * | 2013-02-13 | 2014-08-21 | 株式会社日立製作所 | 共通鍵共有システム及びその方法 |
-
1999
- 1999-10-14 JP JP29300799A patent/JP2001119394A/ja not_active Withdrawn
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014125572A1 (ja) * | 2013-02-13 | 2014-08-21 | 株式会社日立製作所 | 共通鍵共有システム及びその方法 |
| JP5836534B2 (ja) * | 2013-02-13 | 2015-12-24 | 株式会社日立製作所 | 共通鍵共有システム及びその方法 |
| JPWO2014125572A1 (ja) * | 2013-02-13 | 2017-02-02 | 株式会社日立製作所 | 共通鍵共有システム及びその方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7587591B2 (en) | Secure transport of multicast traffic | |
| US5548646A (en) | System for signatureless transmission and reception of data packets between computer networks | |
| EP1304830B1 (en) | Virtual private network management | |
| US5604807A (en) | System and scheme of cipher communication | |
| US7774837B2 (en) | Securing network traffic by distributing policies in a hierarchy over secure tunnels | |
| US5588060A (en) | Method and apparatus for a key-management scheme for internet protocols | |
| US7509491B1 (en) | System and method for dynamic secured group communication | |
| FI118619B (fi) | Menetelmä ja järjestelmä tiedon salaamiseksi ja tallentamiseksi | |
| EP1490995B1 (en) | End-to-end protection of media stream encryption keys for voice-over-IP systems | |
| EP0693836A1 (en) | Method and apparatus for a key-management scheme for internet protocols. | |
| US8117273B1 (en) | System, device and method for dynamically securing instant messages | |
| EP1374533B1 (en) | Facilitating legal interception of ip connections | |
| US6725276B1 (en) | Apparatus and method for authenticating messages transmitted across different multicast domains | |
| JP2005536961A (ja) | 公衆ネットワークにおけるデバイスと内部ネットワークにおけるデバイスとの間でデータを送信するための方法、ゲートウェイ及びシステム | |
| US20030037235A1 (en) | System for signatureless transmission and reception of data packets between computer networks | |
| CN102905199A (zh) | 一种组播业务实现方法及其设备 | |
| EP1135888B1 (en) | Apparatus and method for limiting unauthorized access to a network multicast | |
| US20060143701A1 (en) | Techniques for authenticating network protocol control messages while changing authentication secrets | |
| EP1068711A1 (en) | Ip key management mechanism with divergence barrier increasing entropy against computational crypto-analyses | |
| JPH07170280A (ja) | ローカルエリアネットワーク | |
| WO2002039657A1 (en) | A method for secure packet-based communication between two units via an intermedia unit | |
| JP2001119394A (ja) | 暗号鍵配送方法 | |
| EP1615402A2 (en) | Identification and authentication system and method for a secure data exchange | |
| Jadhav et al. | Secure key establishment for bundle security protocol of space DTNs in noninteractive manner | |
| JP2001320359A (ja) | 暗号通信システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20061011 |
|
| A761 | Written withdrawal of application |
Free format text: JAPANESE INTERMEDIATE CODE: A761 Effective date: 20071225 |