JP3644579B2 - セキュリティ強化方法及び装置 - Google Patents
セキュリティ強化方法及び装置 Download PDFInfo
- Publication number
- JP3644579B2 JP3644579B2 JP30800798A JP30800798A JP3644579B2 JP 3644579 B2 JP3644579 B2 JP 3644579B2 JP 30800798 A JP30800798 A JP 30800798A JP 30800798 A JP30800798 A JP 30800798A JP 3644579 B2 JP3644579 B2 JP 3644579B2
- Authority
- JP
- Japan
- Prior art keywords
- key
- encryption key
- communication device
- encryption
- communication
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/60—Digital content management, e.g. content distribution
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、イントラネットやインターネットなどのコンピュータネットワーク上で行われる通信のセキュリティを高める技術に関し、なかでもチャットシステムにおける会話内容のセキュリティを高める技術に関する。
本発明において、チャットシステムとは、チャットサーバと複数のチャットクライアントとから構成され、複数の利用者が互いに同一のチャネルを共有して同時に会話可能なシステムをいう。チャネルとは、論理的にユーザをグルーピングした仮想空間であり、チャネル内での発言がチャネルを共有する利用者全員にブロードキャストされる仮想空間である。ニックネームとは、チャットシステム上でユーザを識別するための名前である。チャネルオペレータ属性とは、チャネル内のユーザ管理及びモード管理を行う権限である。ボットとは、チャネルに参加して様々なサービスを提供するソフトウェアロボットを言う。
【０００２】
【従来の技術】
従来、チャットサーバとチャットクライアントとからなるチャットシステムにおいて、チャットクライアント間の会話内容のセキュリティを高めるために、会話内容を共通鍵で暗号化することが提案されている。この共通鍵の生成方法として、例えばチャットサーバがチャネル暗号鍵を生成し、複数のチャットクライアントに配布する方法が提供されている。
【０００３】
また、チャットクライアントとしてサーバに接続するボットを準備しておき、このボットにチャネル暗号鍵を生成及び配布させ、また生成したチャネル暗号鍵を管理させる方法も提案されている。さらに、チャットクライアントにあらかじめチャネル暗号鍵を組み込んでおくことも考えられる。
【０００４】
【発明が解決しようとする課題】
前記チャットサーバがチャネル暗号鍵を生成してチャットクライアントに配布する方法では、クライアントとサーバとの間の通信路上では会話内容の秘匿が行われる。しかし、サーバがチャネル暗号鍵を知っているので、サーバ上で会話の解読が可能であるという問題がある。
【０００５】
一方、ボットを用いてチャネル鍵を管理する方法を用いると、チャットサーバに会話内容が漏洩することはないものの、ボット上で会話内容の解読が可能である。また、サーバと別個独立したボットを運用することになり、運用上面倒である。チャットクライアントにチャネル暗号鍵を組み込む構成は、単純ではあるものの鍵を変更できないため、鍵を解読される可能性が高くなるおそれがある。
【０００６】
本発明は、チャネル暗号鍵を用いて会話の暗号化／復号化を行う場合に、チャネル暗号鍵を管理する負担を軽減し、チャネル鍵の解読を困難にするセキュリティ強化方法及び装置を提供することを目的とする。
【０００７】
【課題を解決するための手段】
前記の課題を解決するために、本願第１発明は、互いに同一のネットワークを共有して同時に双方向通信が可能な通信装置に用いられ、以下のステップを含むセキュリティ強化方法を提供する。
・前記通信装置の処理手段が、前記共有されたネットワーク内の通信内容を暗号化及び復号化するための暗号鍵を記憶手段に保持する記憶ステップ、
・前記処理手段が、通信内容を前記通信装置から取得し、前記暗号鍵を用いて暗号化する暗号化ステップ、
・前記処理手段が、通信内容を前記通信装置から取得し、前記暗号鍵を用いて復号化する復号化ステップ、
・前記通信装置が前記いずれかのネットワークに参加している場合に、前記処理手段が、少なくとも前記ネットワークを共有する他の通信装置リストを含む所定の利用者情報を前記通信装置から取得し、他のセキュリティ強化装置に暗号鍵の配布を許可する鍵配布属性を前記取得した利用者情報に基づいて設定し、取得した利用者情報及び設定した鍵配布属性を前記記憶手段に格納する利用者管理ステップ、
・前記処理手段が、前記設定した鍵配布属性に基づいて前記暗号鍵を取得するか否かを判断し、前記判断の結果に基づいて前記他の通信装置リストからいずれかの通信装置を選択して前記暗号鍵を要求し、前記要求に応じて前記他の通信端末から送信される暗号鍵を前記記憶手段に格納する鍵取得ステップ、
・前記処理手段が、前記設定した鍵配布属性に基づいて前記暗号鍵を生成するか否かを判断し、前記判断の結果に基づいて前記暗号鍵を生成し、他の前記通信装置から前記暗号鍵の要求があった場合、前記記憶手段からいずれかの暗号鍵を読み出して前記他の通信端末に配布可能な鍵配布ステップ。
【０００８】
チャットシステムを例に取り説明する。例えば、チャットクライアントは、利用者情報としてニックネーム、ユーザＩＤ、チャネルオペレータか否か等を取得可能である。そこで、鍵配布属性を、例えばチャネルオペレータ属性に連動させ、チャネルオペレータであれば鍵配布属性ありに設定する。チャネル開設者により最初のチャネル暗号鍵を生成する。次にチャネルに参加してきたユーザは、チャネル開設者に対してチャネル暗号鍵を要求する。チャネル開設者は、前記要求に応じてチャネル暗号鍵を付与する。このように、ユーザ端末間でチャネル暗号鍵を配布し、サーバやボット上でのチャネル暗号鍵の解読を防止する。
【０００９】
本願第２発明は、他の通信装置と互いに同一のネットワークを共有して同時に双方向通信が可能な通信装置とともに用いられ、記憶手段と、暗号化手段と、復号化手段と、利用者管理手段と、鍵取得手段と、鍵配布手段とを備えるセキュリティ強化装置を提供する。
記憶手段は、前記共有されたネットワーク内の通信内容を暗号化及び復号化するための暗号鍵を保持する。暗号化手段は、通信内容を前記通信装置から取得し、前記暗号鍵を用いて暗号化する。復号化手段は、通信内容を前記通信装置から取得し、前記暗号鍵を用いて復号化する。
【００１０】
利用者管理手段は、前記通信装置が前記いずれかのネットワークに参加している場合に、少なくとも前記ネットワークを共有する他の通信装置リストを含む所定の利用者情報を前記通信装置から取得し、他のセキュリティ強化装置に暗号鍵の配布を許可する鍵配布属性を、前記取得した利用者情報に基づいて設定し、取得した利用者情報及び設定した鍵配布属性を前記記憶手段に格納する。鍵取得手段は、前記設定した鍵配布属性に基づいて前記暗号鍵を取得するか否かを判断し、前記判断の結果に基づいて前記他の通信装置リストからいずれかの通信装置を選択して前記暗号鍵を要求し、前記要求に応じて前記他の通信端末から送信される暗号鍵を前記記憶手段に格納する。鍵配布手段は、前記設定した鍵配布属性に基づいて前記暗号鍵を生成するか否かを判断し、前記判断の結果に基づいて前記暗号鍵を生成し、他の前記通信装置から前記暗号鍵の要求があった場合、前記記憶手段からいずれかの暗号鍵を読み出して前記他の通信端末に配布可能である。
【００１１】
セキュリティ強化装置をチャットクライアントと共に用いる場合を例に取る。利用者管理手段は、チャネルに入るとそのチャネルに参加しているニックネームリストを含む利用者情報を、チャットクライアントを介して取得する。例えば、チャットクライアントは、利用者情報としてニックネーム、ユーザＩＤ、チャネルオペレータか否か等を取得可能である。そこで、鍵配布属性を、例えばチャネルオペレータ属性に連動させ、チャネルオペレータであれば鍵配布属性ありに設定する。次に、鍵取得手段は、ニックネームリストから鍵配布属性を有するいずれかの他の利用者を選択し、その利用者端末にチャネル暗号鍵を要求する。この要求を受け取った他の利用者端末では、鍵配布手段が、記憶手段からチャネル暗号鍵を取り出し、要求元の利用者端末に送信する。要求元の利用者端末は、鍵取得手段によりチャネル暗号鍵を受け取って記憶手段に格納する。暗号化手段及び復号化手段は、前記のようにして記憶手段に格納されたチャネル暗号鍵を用い、以降の会話内容を暗号化及び復号化する。
【００１２】
本願第３発明は、前記第２発明において、前記通信装置が、前記セキュリティ強化装置との連携手段を有している。さらに、連携手段は、前記暗号鍵の要求、前記要求に応じて送信される暗号鍵、前記利用者情報に関する情報及び所定の条件に合致する場合は通信内容の受け渡しを、通信装置とセキュリティ強化装置との間で行うセキュリティ強化装置を提供する。
【００１３】
例えば、受信した通信内容が暗号化されている場合、連携手段は、暗号化されている通信内容をセキュリティ強化装置に送出する。復号化された通信内容は連携手段を介してセキュリティ装置から通信装置に送出され、通常の会話内容と同様に表示される。逆に、通信内容を暗号化する場合、連携手段は入力された通信内容をセキュリティ強化装置に送出する。暗号化された通信内容は連携手段を介してセキュリティ強化装置から通信装置に送出され、通信装置により通常の会話内容と同様の扱いで送信される。
【００１４】
本願第４発明は、前記第２発明において、前記利用者管理手段が、所定の条件に基づいて、他の通信装置を選択し、前記暗号鍵の配布を許可する鍵配布属性を前記他の通信装置に付与するセキュリティ強化装置を提供する。さらに利用者管理手段は、鍵配布属性の設定及び設定対象の通信装置を前記通信装置から取得し、前記記憶手段に格納する。
【００１５】
たとえば、利用者管理手段は、そのチャットクライアントがチャネル開設者である場合に、他の利用者端末を選択する。選択方法は、チャネルに参加しているチャットクライアントからランダムに一定数選択したり、所定の参加順位までのチャットクライアントを選択するなどが挙げられる。他の利用者端末に鍵配布属性を付与可能にするために、具体的にはチャットシステムのプロトコルに新たに拡張プロトコルを設け、鍵配布属性を利用者情報として設定可能にすると良い。また、チャネルオペレータの設定と同様に、設定コマンドに基づいて鍵配布属性を付与可能にしても良い。
【００１６】
本願第５発明は、前記第２発明において、利用者管理手段が、他の通信装置の選択と、前記暗号鍵の配布を許可する鍵配布属性の前記他の通信装置への付与及び解除の指示とを受け付け、かつ鍵配布属性の設定及び設定対象の通信装置を前記通信装置から取得し、前記記憶手段に格納するセキュリティ強化装置を提供する。
【００１７】
利用者による鍵配布属性の設定及び解除を受け付け、個々の利用者端末にかかる鍵配布負担を利用者自身により調節可能にする。
本願第６発明は、前記第２発明において、鍵取得手段が所定の条件に基づいて前記暗号鍵の要求先を選択するセキュリティ強化装置を提供する。
すなわち、鍵取得手段は、乱数を発生させたり、鍵配布属性を有する通信装置から選択する等、所定の条件に基づいてチャネル暗号鍵の要求先を選択する。
【００１８】
本願第７発明は、前記第２発明において鍵取得手段が、所定の条件に基づいて前記暗号鍵の要求先を選択して前記暗号鍵を要求し、所定時間内に前記要求先から暗号鍵が送信されない場合、他の通信装置を選択して再度要求を行うセキュリティ強化装置を提供する。
要求先から一定時間内に暗号鍵が送信されてこない場合、鍵取得手段は要求先に何らかのトラブルがあったとして要求先の通信装置を選択し直す。選択基準は、ランダム、鍵配布属性のある通信装置など所定の条件を満たすものを選択する。
【００１９】
本願第８発明は、前記第２発明において、鍵取得手段が、前記通信内容が暗号化されている場合に前記暗号鍵の取得要求を行うセキュリティ強化装置を提供する。
例えば、チャットシステムにおいて、チャネル内の通信内容の全てを暗号化する暗号化モードを設定可能にしておく。鍵取得手段は、参加したチャネルのモードをチャットクライアントから取得し、暗号化モードがオンである場合は暗号鍵の取得要求を行う。
【００２０】
本願第９発明は、前記第２発明において、前記復号化手段が、前記通信装置から受け取る通信内容を復号不可能と判断した場合、前記暗号鍵の要求を行うことを決定し、前記鍵取得手段が、前記復号化手段の決定に従い、前記暗号鍵の取得要求を行うセキュリティ強化装置を提供する。
会話単位で暗号化を設定可能にすることも考えられる。例えば、ＧＵＩ(Graphic User Interface)によりコマンドボタンを表示し、このコマンドボタンのオンオフにより会話毎に暗号化の設定やその解除を行う。暗号化が設定されている場合、暗号化手段は、暗号化された会話内容の先頭部分に、会話の暗号化を示す暗号化フラグを記述する。通信装置は、会話内容に送信コマンドを付加し、ネットワークに送出する。復号化手段は、暗号化された会話内容を受け取ったが暗号鍵がない場合や、保持されている暗号鍵では復号化できない場合、暗号鍵を要求する旨の判断をする。鍵取得手段は、復号化手段の判断に従い、暗号鍵の取得要求を行う。
【００２１】
本願第１０発明は、前記第２発明において、前記記憶手段が複数の暗号鍵と暗号鍵を特定する鍵識別情報とを対応付けて記憶し、前記暗号化手段が、前記通信内容の暗号化に用いられた暗号鍵を示す鍵識別情報と通信内容とを、前記通信装置を介してネットワークに送出可能であり、前記復号化手段が、前記鍵識別情報で特定される暗号鍵は前記記憶手段に保持されているか否かを判断し、前記鍵取得手段が、前記判断結果に従い、前記鍵識別情報を通知して前記暗号鍵の取得要求を行うセキュリティ強化装置を提供する。
【００２２】
会話毎に暗号化の設定及び解除が行われる場合に、復号化手段がその会話の暗号化に用いられたチャネル暗号鍵を有していないと判断すれば、鍵取得手段はその判断に従ってチャネル暗号鍵の取得要求を行う。その際には、鍵識別番号を通知することにより、どの暗号鍵を要求しているかを特定する。鍵識別番号としては、チャネル生成時からのシリアル番号や、チャネル暗号鍵にハッシュ関数等の一方向関数をかけたものなどが挙げられる。
【００２３】
本願第１１発明は、前記第２発明において、前記鍵取得手段が、利用者の公開鍵暗号系の公開鍵を前記暗号鍵の要求とともに通知し、前記要求に応じて送信される暗号鍵を利用者の秘密鍵を用いて復号化し、前記鍵配布手段が、前記要求元の公開鍵暗号系の公開鍵を用いて暗号化した前記暗号鍵を配布するセキュリティ強化装置を提供する。
【００２４】
暗号鍵を要求する要求元の鍵取得手段は、利用者の公開鍵を通知して要求を行う。要求を受け取った通信装置の鍵配布手段は、公開鍵を用いて暗号鍵を暗号化し、送り返す。要求元では、鍵取得手段が利用者の秘密鍵を用いて復号化し、暗号鍵を取得する。
本願第１２発明は、前記第２発明において、前記鍵配布手段が、他の前記通信装置から前記暗号鍵の要求があった場合、前記要求を検証し、検証結果に基づいて前記記憶手段からいずれかの暗号鍵を読み出し、前記他の通信端末に配布可能であるセキュリティ強化装置を提供する。
【００２５】
チャネル暗号鍵の要求を受け取った他の利用者端末では、まず鍵配布手段が要求を検証する。正当な要求者であれば、鍵配布手段は、記憶手段からチャネル暗号鍵を取り出して要求元の利用者端末に送信する。前述の要求元公開鍵を用いる例では、鍵配布手段は、要求元の公開鍵が正当な公開鍵か否かを検証することが好ましい。例えば、認証局の電子署名がある公開鍵や、ＩＲＣサーバの電子署名が施された公開鍵、暗号鍵の要求を受けたユーザの電子署名がある公開鍵などを、正当な公開鍵と見なすことが挙げられる。
【００２６】
本願第１３発明は、前記第２発明において、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備えるセキュリティ強化装置を提供する。
すなわち、適当なタイミングで暗号鍵を更新することにより、暗号鍵の解読を防止してセキュリティを高める。適当なタイミングとは、例えば所定の時間間隔、所定の会話数または会話量を超過したとき、ネットワークの参加利用者数が所定数を超えたときや下回ったとき、話題が変化したとき、最後の会話から所定時間経過したとき、利用者が暗号鍵の変更を指示したときなど様々なタイミングが考えられる。また、前記タイミングが生じても、会話が続行している最中は変更した鍵の配布を待機し、会話がとぎれたタイミングで鍵を再配布することも考えられる。
【００２７】
本願第１４発明は、前記第２発明において、所定のタイミングで前記暗号鍵を更新し、前記更新した暗号鍵を直前の暗号鍵を用いて暗号化して他の通信装置に配布する鍵変更手段をさらに備えるセキュリティ強化装置を提供する。
前記更新された暗号鍵をその更新前の暗号鍵を用いて暗号化することにより、更新された暗号鍵を配布する際の解読のおそれを防止する。
【００２８】
本願第１５発明は、前記第２発明において、前記鍵変更手段が、前記各通信装置内に保持される秘密情報、時間情報及びネットワークに固有の情報のいずれかまたは全ての組合せに基づいて前記暗号鍵を生成するセキュリティ強化装置を提供する。
例えば、通信装置内に記憶されている基板番号やプログラムの格納アドレス、暗号鍵を更新する時間、チャネル名及びチャネルパスワードに基づいて、新たな暗号鍵を生成することが考えられる。
【００２９】
本願第１６発明は、前記第２発明において、前記鍵変更手段が、前記各通信装置内に保持される秘密情報、時間情報及びネットワークに固有の情報のいずれかの組合せまたは全てを、一方向関数で暗号化して前記暗号鍵を生成するセキュリティ強化装置を提供する。
例えば、通信装置内に記憶されている基板番号やプログラムの格納アドレス、暗号鍵を生成する時間、チャネル名及びチャネルパスワードを、ハッシュ関数で暗号化して暗号鍵とする。
【００３０】
本願第１７発明は、前記第２発明において、前記利用者管理手段が、前記暗号鍵の更新及び配布を許可する鍵変更属性を、前記取得した利用者情報に基づいて設定して前記記憶手段に格納し、前記鍵変更属性の有無に基づいて、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備えるセキュリティ強化装置を提供する。
【００３１】
前記鍵配布属性と同様、鍵変更属性をチャネルオペレータ属性に連動させて設定したり、チャネルに最後まで参加している利用者に設定してもよい。また、新たに拡張プロトコルを設けてチャットシステム上で鍵変更属性を設定可能にし、鍵変更属性を利用者情報として取得するようにしても良い。さらに、チャネルオペレータからの設定コマンドに基づいて鍵変更属性を設定することも可能である。
【００３２】
本願第１８発明は、前記第２発明において、前記利用者管理手段が、利用者が前記暗号鍵の更新及び配布を許可する鍵変更属性を有する場合に、所定の条件に基づいて他の通信装置を選択し、前記選択した通信装置に前記鍵変更属性を設定可能である。かつ、利用者管理手段は、鍵変更属性の設定及び設定対象の通信装置を前記通信装置から取得して前記記憶手段に格納する。さらに、前記鍵変更属性の有無に基づいて、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備えるセキュリティ強化装置である。
【００３３】
鍵変更属性を有する利用者は、他の利用者に対して鍵変更属性を付与可能にしても良い。他の利用者の選択方法は、ランダムに一定数の通信装置を選択したり、チャネルへの参加順序に応じて一定数の通信装置を選択したり、任意の通信装置を通信装置リストから選択したり、様々である。鍵変更属性の設定は、例えばチャットシステム上で新たなコマンドを設定することにより可能になる。この設定に応じて、チャネルに参加しているユーザ端末は、ユーザ情報の書き換えをそれぞれ行う。
【００３４】
本願第１９発明は、前記第２発明において、前記利用者管理手段が、前記暗号鍵の更新及び配布を許可する鍵変更属性及び優先順位を、前記取得した利用者情報に基づいて設定して前記記憶手段に格納し、前記利用者情報の変化に従って前記優先順位の書き換えを行う。さらに、鍵変更属性及び優先順位に基づいて、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備えるセキュリティ強化装置である。
【００３５】
例えば、チャネルオペレータ属性に基づいて鍵変更属性を、チャネルへの参加順序に基づいて優先順位を設定する。第２位以降の利用者管理手段は、第１位の通信装置がネットワークから退出した場合や、前回の暗号鍵の更新から所定時間が経過して第１位の通信装置に何らかのトラブルがあったと判断する場合、利用者情報に基づいて自動的に優先順位をひとつづつ繰り上げる。新たな鍵の生成は、第１位のユーザが、所定のタイミングで行う。
【００３６】
本願第２０発明は、前記第２発明において、前記利用者管理手段が、利用者が前記暗号鍵の更新及び配布を許可する鍵変更属性を有する場合に、所定の条件に基づいて他の通信装置を選択し、前記他の通信装置に前記鍵変更属性と優先順位とを設定可能である。かつ、利用者管理手段は、鍵変更属性と優先順位との設定及び設定対象の通信装置を前記通信装置から取得して前記記憶手段に格納し、前記利用者情報の変化に従って前記優先順位の書き換えを行う。さらに、このセキュリティ強化装置は、前記鍵変更属性及び優先順位に基づいて、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備えている。
【００３７】
例えば、チャネル暗号鍵の変更及び配布は、第１位の通信装置が行う。第２位以下の通信装置は、第１位の通信装置が配布する新たなチャネル暗号鍵を取得する。第２位以降の利用者管理手段は、第１位の通信装置がネットワークから退出した場合や、前回の暗号鍵の更新から所定時間が経過して第１位の通信装置に何らかのトラブルがあったと判断する場合、利用者情報に基づいて自動的に優先順位をひとつづつ繰り上げる。新たに第１位となった通信装置は、自ら暗号鍵の変更及び配布を行う。
【００３８】
本願第２１発明は、互いに同一のネットワークを共有して同時に双方向通信が可能な複数の通信装置から構成され、前記各通信装置が、記憶手段と、暗号化手段と、復号化手段と、利用者管理手段と、鍵取得手段と、鍵配布手段とを備えるセキュリティ強化システムを提供する。
記憶手段は、前記共有されたネットワーク内の通信内容を暗号化及び復号化するための暗号鍵を保持する。
【００３９】
暗号化手段は、通信内容を前記暗号鍵を用いて暗号化する。復号化手段は、通信内容を前記暗号鍵を用いて復号化する。利用者管理手段は、前記いずれかのネットワークに参加している場合に、少なくとも前記ネットワークを共有する他の通信装置リストを含む所定の利用者情報を取得し、他のセキュリティ強化装置に暗号鍵の配布を許可する鍵配布属性を、前記取得した利用者情報に基づいて設定し、取得した利用者情報及び設定した鍵配布属性を前記記憶手段に格納する。
【００４０】
鍵取得手段は、前記設定した鍵配布属性に基づいて前記暗号鍵を取得するか否かを判断し、前記判断の結果に基づいて前記他の通信装置リストからいずれかの通信装置を選択して前記暗号鍵を要求し、前記要求に応じて前記他の通信端末から送信される暗号鍵を前記記憶手段に格納する。鍵配布手段は、前記設定した鍵配布属性に基づいて前記暗号鍵を生成するか否かを判断し、前記判断の結果に基づいて前記暗号鍵を生成し、他の前記通信装置から前記暗号鍵の要求があった場合、前記記憶手段からいずれかの暗号鍵を読み出して前記他の通信端末に配布可能である。
【００４１】
前記第２発明と同様の作用効果を有する。
本願第２２発明は、互いに同一のネットワークを共有して同時に双方向通信が可能な通信装置に用いられる、セキュリティ強化プログラムを記録したコンピュータ読み取り可能な記録媒体であって、下記Ａ〜Ｆ段階を実行させるためのセキュリティ強化プログラムを記録した、コンピュータ読み取り可能な記録媒体を提供する。
・前記通信装置の処理手段が、前記共有されたネットワーク内の通信内容を暗号化及び復号化するための暗号鍵を記憶手段に保持する記憶段階、
・前記処理手段が、通信内容を前記通信装置から取得し、前記暗号鍵を用いて暗号化する暗号化段階、
・前記処理手段が、通信内容を前記通信装置から取得し、前記暗号鍵を用いて復号化する復号化段階、
・前記通信装置が前記いずれかのネットワークに参加している場合に、前記処理手段が、少なくとも前記ネットワークを共有する他の通信装置リストを含む所定の利用者情報を前記通信装置から取得し、他のセキュリティ強化装置に暗号鍵の配布を許可する鍵配布属性を前記取得した利用者情報に基づいて設定し、取得した利用者情報及び設定した鍵配布属性を前記記憶手段に格納する利用者管理段階、
・前記処理手段が、前記設定した鍵配布属性に基づいて前記暗号鍵を取得するか否かを判断し、前記判断の結果に基づいて前記他の通信装置リストからいずれかの通信装置を選択して前記暗号鍵を要求し、前記要求に応じて前記他の通信端末から送信される暗号鍵を前記記憶手段に格納する鍵取得段階、
・前記処理手段が、前記設定した鍵配布属性に基づいて前記暗号鍵を生成するか否かを判断し、前記判断の結果に基づいて前記暗号鍵を生成し、他の前記通信装置から前記暗号鍵の要求があった場合、前記記憶手段からいずれかの暗号鍵を読み出して前記他の通信端末に配布可能な鍵配布段階。
【００４２】
前記第２発明と同様の作用効果を有する。
【００４３】
【発明の実施の形態】
次に、本発明のセキュリティ強化装置について、実施形態例を挙げて具体的に説明する。以下の実施形態例においては、チャットシステムにおける会話内容のセキュリティを高めるために、本発明のセキュリティ強化装置をチャットクライアントとともに用いる場合を例に取り、説明する。
【００４４】
＜第１実施形態例＞
図１に、チャットクライアントと共に用いられるセキュリティ強化装置の機能構成図を示す。図１において、複数のユーザ端末Ａ，Ｂ，Ｃ，Ｄ，Ｅ…は、チャットクライアントが動作可能であり、チャットサーバとコンピュータネットワークを介して接続されている。セキュリティ強化装置１は、チャットクライアントとともに、各ユーザ端末に設けられている。
【００４５】
セキュリティ強化装置１は、記憶部２、ユーザ管理部３、鍵取得部４、鍵配布部５、鍵変更部６、鍵生成部７及び暗号化／復号化部８を有している。チャットクライアント１０には、セキュリティ強化装置１に応じ、ユーザＤＢ９、連携部１１及び振り分け部１２が設けられている。本実施形態例においては、セキュリティ強化装置１及びチャットクライアント１０を有する複数のユーザ端末Ａ〜Ｅ間において、会話を暗号化／復号化するためのチャネル暗号鍵を生成し、配布する。
【００４６】
［セキュリティ強化装置］
記憶部２は、ユーザ自身の公開鍵系秘密鍵及び公開鍵を記憶している。また、記憶部２は、チャットクライアントが参加しているチャネルにおける会話を暗号化／復号化するためのチャネル暗号鍵を、鍵取得部４から受け取り、保持する。さらに、記憶部２は、チャネル暗号鍵を特定する暗号鍵ＩＤを鍵取得部４から受け取り、チャネル暗号鍵と暗号鍵ＩＤとを対応付けて暗号鍵リストに保持する。記憶部２に保持されるチャネル暗号鍵は、１つとは限らず複数でも良い。複数のチャネル暗号鍵が保持される場合には、記憶部２に保持するチャネル暗号鍵の最大数を予め設定またはユーザにより設定可能にしておくと良い。
【００４７】
ユーザ管理部３は、チャットクライアントがチャットサーバから取得するユーザ情報を参照し、参照したユーザ情報に基づいて、鍵配布属性及び鍵変更属性を設定する。図２に、鍵配布属性及び鍵変更属性を含めたユーザ情報の一例を示す。ここで、鍵配布属性とは、チャネル暗号鍵を他のユーザ端末に配布することが許可されていることを示す。また、鍵変更属性とは、チャネル暗号鍵を新たに更新し、他のユーザ端末に配布することが許可されていることを示す。
【００４８】
通常、チャットクライアントは、チャネルに参加することにより所定のユーザ情報をサーバから取得可能である。取得可能なユーザ情報としては、(1)ニックネーム、(2)ユーザの実際の氏名であるReal Name、(3)ネットワーク上でユーザを特定するためのユーザＩＤ、(4)チャットクライアントが動作している利用者端末を特定するクライアント名、(5)利用者端末が接続しているサーバを特定するサーバ名、(6)各ユーザが接続しているチャネルのリスト、(7)最終発言からの経過時間、(8)チャネルオペレータ属性の有無(0/1)などが挙げられる。このうち、少なくともニックネームは、チャネル内のユーザを特定するために必要な情報である。
【００４９】
図２に示したユーザ情報の例では、チャットクライアントは、前記(1)〜(8)のユーザ情報をチャットサーバから取得してユーザＤＢに書き込む。ユーザ管理部３は、チャットクライアントが取得したユーザ情報の中のチャネルオペレータ属性に基づいて鍵配布属性及び鍵変更属性を設定し、ユーザＤＢ９に書き込んでいる。チャネルオペレータ属性が"１"であれば、鍵配布属性及び鍵変更属性もそれぞれ"１"に設定される。また、ユーザ管理部３は、ユーザ情報の変化、例えば新たなチャネルオペレータの設定やユーザの退出を、後述するチャットクライアントの連携部１１を介して通知され、変化に応じてユーザ情報を更新する。
【００５０】
鍵配布属性や鍵変更属性の設定方法は、他にも考えられる。属性の他の設定方法として、ユーザ管理部３により所定の条件に基づいてユーザを選択し、選択したユーザに属性を設定する方法があげられる。鍵配布属性の付与対象の選択方法としては、例えば、乱数を発生させることによりランダムに一定数のユーザを選択したり、チャネルへの所定の参加順位までのユーザを手動であるいは自動的に選択したり、ユーザによる他のユーザの指定を受け付けることにより選択することが挙げられる。
【００５１】
鍵変更属性の付与対象の選択方法としては、例えば、チャネルの開設者を選択したり、チャネルに最後まで参加していたユーザを選択したりすることが挙げられる。また、鍵変更属性を有するユーザにより、例えば、チャネルへの参加順序に応じて一定数のユーザを選択したり、ランダムに一定数のユーザを選択したり、ユーザの手動による他のユーザの指定を受け付けて選択することが挙げられる。
【００５２】
これら選択したユーザに対し、属性を設定する方法の一つとして、属性配布コマンドを新たに設けることが考えられる。例えば、鍵配布属性の設定コマンドを"MODE #CH1 +d userA"、鍵変更属性の設定コマンドを"MODE #CH1 +x userA"とする。但し、ここで#CH1は任意のチャネル名、userAは任意のチャネル内ユーザのニックネームとする。ユーザ管理部３により、選択されたユーザ及び配布する属性を指定して前記コマンドをチャットクライアントに送出することにより、チャネルに参加している全ユーザ端末に前記コマンドが通知される。他のユーザ端末では、チャットクライアントを介してコマンドを受け取ったユーザ管理部３が、コマンドを解釈してユーザ情報の書き換えを行う。
【００５３】
複数のユーザが鍵変更属性を有する場合、ユーザ管理部３によりチャネル暗号鍵を変更する優先順位を併せて設定することが好ましい。例えば、チャネルオペレータ属性に連動させて鍵変更属性を設定する場合は、チャネル開設者の優先順位を第１位とし、他のユーザの優先順位はチャネルに参加した順に設定する。また、鍵変更属性を有するユーザが一人であり、そのユーザから他のユーザに鍵変更属性を付与する場合は、最初に鍵変更属性を有していたユーザの優先順位を第１位とする。そして、ユーザ管理部３により選択されるユーザに対し、チャネルへの参加順序に応じて、ランダムに、または手動による指定を受け付け、優先順位を設定する。
【００５４】
前記優先順位を設定するために、前記属性設定コマンドにより属性と共に優先順位の設定も可能にしておくことが好ましい。例えば、鍵変更属性の設定コマンドにおいて、拡張子"+x"のあとに優先順位を示す自然数"n"を記述することにより、優先順位を設定することが考えられる。例えば、"userA"に第２位の鍵変更属性を設定するコマンドは、"MODE #CH1 +x2 userA"となる。鍵変更属性と共に設定される優先順位は、チャネル内の全てのユーザ端末に通知される。従って、各ユーザ端末のユーザ管理部３は、ユーザ情報の変化、例えばいずれかのユーザが退出することにより鍵変更属性の優先順位に変更が生じると、生じた変化に応じて優先順位を書き換えることが出来る。
【００５５】
鍵取得部４は、所定の条件に基づいて、他のユーザの選択及び選択したユーザへのチャネル暗号鍵の要求を行う。また、要求に応じて送信されてくるチャネル暗号鍵を記憶部２に格納する。チャネル暗号鍵の要求先の選択方法は特に限定されない。例えば、乱数を発生させることによりランダムに一意のユーザを選択したり、鍵配布属性を有するユーザからチャネルに参加した順に選択することが挙げられる。選択したユーザ端末が多忙であったり、通信路が混雑しているなど、何らかの事情により選択したユーザ端末から一定時間経過しても応答がない場合、鍵取得部４は、他のユーザ端末を選択し、再びチャネル暗号鍵の要求を行う。
【００５６】
チャネル暗号鍵の要求は、所定の情報及びユーザ証明書を送信することにより行う。所定の情報とは、チャネル名と、ニックネームなどの要求元ユーザを特定する情報とを最低限含んでいる。ユーザ証明書は、ユーザに関する情報、すなわち証明書本体と、要求元ユーザの公開鍵と、証明者である認証局の電子署名とから構成されている。証明者としては、認証局が一般的ではあるが、他にユーザ端末が接続するサーバや、鍵を要求する先のユーザなどでも良い。
【００５７】
前記チャネル暗号鍵の要求を行うタイミングは、鍵取得部４が通信の暗号化を確認したときである。具体的には、そのチャネル内の通信が全て暗号化されている暗号化モードを確認したとき、または暗号化された会話を受信したときである。前者の場合、チャネル内の全会話を暗号化する暗号化モードの設定コマンドを予め準備しておく。例えば、"MODE #CH1 +c"などのように、"MODE"コマンドの拡張子を用いたコマンドを準備する。通常、チャットクライアントがチャネルに参加すると、そのチャネルに設定されているモードが通知される。鍵取得部４は、このモードをチャットクライアントの連携部１１から取得し、暗号化モードであればチャネル暗号鍵の要求を行う。
【００５８】
後者の場合、会話毎にその会話が暗号化されているか否かを示す暗号化フラグを、各会話と共に送信することが考えられる。通常のチャットシステムにおいては、会話を送信する送信コマンドと会話内容とからなる会話メッセージが作成される。本実施形態例においては、さらに暗号化のオン／オフを示す暗号化フラグ（０／１）を会話内容の先頭部分に記述して会話メッセージを作成する。
【００５９】
また、暗号化フラグに代えて暗号鍵ＩＤを用いることも考えられる。暗号化フラグを会話内容に記述することは、後述するように暗号化／復号化部８が行う。鍵取得部４は、暗号化／復号化部８がチャットクライアントから受け取る会話内容を復号化できない場合、後述する暗号化／復号化部８の指示に従ってチャネル暗号鍵の要求を行う。暗号化／復号化部８が復号化を行えない場合については後述する。
【００６０】
鍵取得部４は、要求元ユーザの公開鍵で暗号化されたチャネル暗号鍵を受信し、これをユーザの秘密鍵で復号化してチャネル暗号鍵を取得する。また、暗号化されたチャネル暗号鍵と共に暗号鍵ＩＤを受信し、取得したチャネル暗号鍵と暗号鍵ＩＤとを記憶部２の暗号鍵リストに格納する。
さらに、鍵取得部４は、ユーザ端末に鍵変更属性がない場合か、鍵変更属性を有していても優先順位が第１位でない場合には、他のユーザ端末から送信される新たなチャネル暗号鍵を取得する。取得した新たなチャネル暗号鍵は直前のチャネル暗号鍵を用いて暗号化されているので、鍵取得部４は、直前のチャネル暗号鍵を記憶部２から取り出し、送信されてきたチャネル暗号鍵を復号化する。また、前記と同様に、復号化したチャネル暗号鍵から暗号鍵ＩＤを求め、チャネル暗号鍵と対応付けて暗号鍵リストに格納する。さらに、鍵取得部４は、チャネル暗号鍵が更新される所定のタイミングを経過しても新たなチャネル暗号鍵を受信しない場合、ユーザ管理部３に対して優先順位の変更の指示を通知する。この通知を受け、ユーザ管理部３により鍵変更属性の優先順位の繰り上げが行われる。チャネル暗号鍵の更新については後述する。
【００６１】
鍵配布部５は、他のユーザ端末から送信されるチャネル暗号鍵の要求を検証する。要求の検証には、チャネル暗号鍵の要求とともに要求元から送信されるユーザ証明書を用いる。検証の結果、要求元が正当なユーザであることを判断すると、最新のチャネル暗号鍵を暗号鍵リストから取り出し、ユーザ証明書に含まれる要求元の公開鍵で暗号化する。鍵配布部５は、前記取り出したチャネル暗号鍵にハッシュ関数などの一方向関数をかけて暗号鍵ＩＤを求め、暗号化したチャネル暗号鍵と暗号鍵ＩＤとを要求元に送信する。暗号鍵ＩＤはチャネル暗号鍵を一義的に特定できればよいので、シリアル番号やチャネル暗号鍵を生成した日付及び時刻などを暗号鍵ＩＤとして用いても良い。また、鍵配布部５は、要求とともに暗号鍵ＩＤが送信された場合は、暗号鍵ＩＤにより指定されるチャネル暗号鍵を送信する。
【００６２】
鍵変更部６は、適当なタイミングでチャネル暗号鍵を新たに生成し、生成したチャネル暗号鍵を他のユーザ端末に送信する。新たにチャネル暗号鍵を生成するタイミングとしては、例えば一定時間経過毎に生成することが挙げられる。また、チャットクライアントにおける会話数や会話のデータ量を監視することにより、ある一定会話数毎に、あるいは一定会話量毎に生成してもよい。さらに、ユーザ情報を監視して、チャネル内ユーザ数が所定数、例えば１になったとき、チャネルのトピックが変化したとき、最後の会話から所定時間経過したとき、ユーザがチャネル暗号鍵の変更を指示する任意の時など、様々なタイミングが考えられる。鍵変更部６は、生成したチャネル暗号鍵をすぐに送信しても良いが、会話が断続的に続いているような状態では送信を見合わせ、会話がとぎれたときに送信を行うようにすると好ましい。
【００６３】
新たなチャネル暗号鍵の生成は、例えばユーザ端末内に保持されている秘密情報、時間情報、チャネル固有情報などの情報を組み合わせ、ハッシュ関数などの一方向関数をかけることにより生成するとよい。ユーザ端末内に保持されている秘密情報とは、端末内の基板の製造番号や、ある特定のプログラムのアドレスなど、第３者が容易に想到しにくい情報が好ましく、さらに時間的に静的情報ではなく変化する情報であればさらに好ましい。
【００６４】
時間情報としては、前記チャネル暗号鍵の生成タイミングにおける時刻データを、時刻データ取得プログラムルーチンを用いて取得する。時刻データ取得プログラムルーチンは、ユーザ端末の内部時計を利用しており、通常ユーザ端末上で動作するオペレーティングシステムにより提供されている。時刻データとしては、時刻データ取得プログラムルーチンが出力する1970年1月1日からの通算秒が一般に用いられる。チャネル固有情報としては、例えばチャネル名やチャネルに設定されているパスワードなどが挙げられる。
【００６５】
生成した新たなチャネル暗号鍵は、そのまま送信するよりも、暗号化して送信する方がセキュリティの観点から好ましい。例えば、１つ前のチャネル暗号鍵を用いて新たなチャネル暗号鍵を暗号化して送信すると、受信側も復号可能である上に盗聴を防止しやすいと考えられる。
前記チャネル暗号鍵の生成及び配布は、ユーザ情報の鍵変更属性に基づいて行うことが好ましい。すなわち、ユーザ情報の鍵変更属性が付与されている場合のみ、前記チャネル暗号鍵を生成し、配布する。鍵変更属性は、前述のように各ユーザ端末においてユーザ管理部３により設定される。鍵変更属性とともに優先順位が設定されている場合は、例えば次のようにしてチャネル暗号鍵の更新を行う。
【００６６】
優先順位が第１位のユーザにおいては、鍵変更部６は前述のように所定のタイミングで新たなチャネル暗号鍵を生成し、他のユーザ端末に送信する。優先順位が第２位以降のユーザにおいては、所定時間経過しても新たなチャネル暗号鍵が送信されてこない場合、第１位のユーザ端末が何らかの事情でチャネル暗号鍵を送信できなかったものと判断する。この判断は、前述のように鍵取得部４で行う。そして、ユーザ管理部３により順次優先順位の繰り上げが行われた結果新たに第１位となったユーザが、チャネル暗号鍵の生成及び配布を行う。
【００６７】
鍵生成部７は、チャットクライアントがチャネル開設者である場合、最初のチャネル暗号鍵を生成する。生成方法は、前記チャネル暗号鍵の更新と同様に、ユーザ端末内の秘密情報、時間情報、チャネル固有情報などの情報を組み合わせ、ハッシュ関数をかけて生成するとよい。時間情報としては、例えばチャネルを開設した時刻のデータを用いるなどが考えられる。また、鍵生成部７は、生成したチャネル暗号鍵にハッシュ関数をかけるなどして前述の鍵配布部５と同様に暗号鍵ＩＤを作成し、チャネル暗号鍵と暗号鍵ＩＤとを対応付けて記憶部２に格納する。
【００６８】
暗号化／復号化部８は、後述するチャットクライアントの振り分け部１２から暗号化された会話内容が送出されることに従い、記憶部２に保持されているチャネル暗号鍵を取り出し、会話内容の復号化を行う。復号化に用いるチャネル暗号鍵には通常は最新のチャネル暗号鍵を用いるが、会話内容の先頭に暗号鍵ＩＤが記述されている場合、暗号鍵ＩＤにより特定されるチャネル暗号鍵を用いて復号化を行う。
【００６９】
また、暗号化／復号化部８は、復号化を行うことができない場合、鍵取得部４に対し鍵要求を行うことを指示する。復号化を行うことができない場合とは、(1)記憶部２にチャネル暗号鍵が保持されていない場合または(2)通知された暗号鍵ＩＤに対応するチャネル暗号鍵が記憶部２に保持されていない場合である。復号化した会話内容は、再びチャットクライアントに送出され、通常のメッセージを受信した場合と同様に画面上に表示される。
【００７０】
さらに、暗号化／復号化部８は、振り分け部１２から会話内容を受け取ると、最新のチャネル暗号鍵を用いて暗号化する。ついで、暗号化した会話内容の先頭部分に暗号化フラグまたは暗号鍵ＩＤを記述し、再びチャットクライアントに送出する。チャットクライアントでは、通常の会話内容と同様に、セキュリティ強化装置１から送出されたデータに送信コマンドを付加し、送信する。
【００７１】
［チャットクライアント］
図１に示すように、本実施形態例におけるチャットクライアント１０には、連携部１１と振り分け部１２とがセキュリティ強化装置１に応じて設けられている。連携部１１は、チャットクライアントが送受信するコマンドを解釈し、セキュリティ強化装置１の各構成要素に処理を振り分ける。具体的には、連携部１１は、ユーザ情報が変化するコマンドを解釈すると、ユーザ情報の変化及びその内容をユーザ管理部３にユーザ管理部３に通知する。前記コマンドとしては、例えばユーザの退出を示すコマンド"PART"、参加を示すコマンド"JOIN"、チャネルオペレータの特権を授与するコマンド"MODE #CH1 +o"、鍵配布属性の設定コマンド"MODE #CH1 +d userA"、鍵変更属性及び優先順位の設定コマンド"MODE #CH1 +xn userA"等が挙げられる。また、逆に、ユーザ管理部３からの鍵配布属性の設定コマンド"MODE #CH1 +d userA"、鍵変更属性及び優先順位の設定コマンド"MODE #CH1 +xn userA"等を受け付け、処理する。
【００７２】
連携部１１は、チャネル暗号鍵の授与を示すコマンドや暗号化モードの設定コマンドを解釈すると、鍵取得部４に対し通知する。また、鍵取得部４からチャネル暗号鍵の取得を要求するコマンドを受け付け、処理する。
連携部１１は、チャネル暗号鍵の要求を示すコマンドを解釈すると、鍵配布部５に対し要求を通知する。また、鍵配布部５からの要求に対してチャネル暗号鍵の授与コマンドを受け付け、処理する。
【００７３】
振り分け部１２は、送信されてきた会話メッセージの先頭部分が暗号化フラグ"１"または暗号鍵ＩＤである場合、復号化の指示を暗号化／復号化部８に通知する。具体的には、暗号化フラグまたは暗号鍵ＩＤと暗号化された会話内容とを暗号化／復号化部８に送出する。
また、振り分け部１２は、利用者からの暗号化の指示及び解除を受け付け、暗号化が指示されている場合には、入力された会話内容を暗号化／復号化部８に送出する。暗号化の指示及び解除は、例えばＧＵＩ(Graphic User Interface)を利用してコマンドボタンを画面上に表示させ、コマンドボタンのオン／オフによりなされるようにすることが出来る。さらに、振り分け部１２は、暗号化／復号化部８により暗号化され、暗号化フラグまたは暗号鍵ＩＤを含む会話内容を、通常の会話内容と同様に処理する。すなわち、暗号化された会話内容は、チャットクライアントにより通常の会話内容と同様に、送信コマンドを付加され、通常のチャットシステムにおける発言として送信される。
【００７４】
［処理の流れ］
次に、セキュリティ強化装置１が行う主な処理の流れを説明する。図３は、セキュリティ強化装置１が行うメインルーチンの処理の流れを示すフローチャートである。図４〜６は、メインルーチンにおいて行われる処理の詳細を示している。図４は、他のユーザ端末から鍵を取得するための鍵取得処理の流れを示すフローチャート、図５は、他のユーザ端末に鍵を配布する鍵配布処理の流れを示すフローチャート、図６は、他のユーザからの鍵の要求を検証する要求検証処理の流れを示すフローチャートである。また、図７は、メインルーチンと独立に行われ、所定の条件に従ってチャネル暗号鍵を変更する場合の鍵変更処理の流れを示すフローチャートである。
【００７５】
（１）メインルーチン
ユーザ端末においてチャットクライアントがチャネルに参加またはチャネルを開設することにより、図３のメインルーチンの処理が開始される。説明を容易にするため、鍵配布属性及び鍵変更属性をチャネルオペレータに連動させて設定する場合を例に取り、説明する。
【００７６】
ステップＳ１では、ユーザ管理部３が、ユーザ情報のチャネルオペレータに連動させて、鍵配布属性及び鍵変更属性を設定する。
ステップＳ２では、ユーザ管理部３は、ユーザがチャネルの開設者か否かを判断する。チャネル内のユーザが１人だけ、すなわちチャネルに参加しているチャットクライアントが自己のチャットクライアントだけであれば、そのユーザはチャネル開設者であるのでステップＳ３に移行する。チャネルの開設者ではなく複数のユーザがチャネル内にいれば、チャネル暗号鍵を取得するためにステップＳ４に移行する。
【００７７】
ステップＳ３では、チャネル開設者のユーザ端末において、鍵生成部７がチャネル暗号鍵を生成する。さらに、生成したチャネル暗号鍵に暗号鍵ＩＤを付し、記憶部２の暗号鍵リストに格納し、ステップＳ５に移行する。
ステップＳ４では、チャネル開設者ではないユーザが、後述する鍵取得サブルーチンにより他のユーザ端末に対してチャネル暗号鍵の要求を行い、チャネル暗号鍵を取得する。
【００７８】
ステップＳ５では、後述する鍵配布サブルーチンにより、鍵配布属性を有するユーザが他のユーザ端末にチャネル暗号鍵を配布する。
ステップＳ６では、当該チャットクライアントがチャネルから退出するか否かを判断し、退出するのであれば処理を終了する。退出しないのであれば、再びステップＳ５に戻り、他のユーザからの要求に応じてチャネル暗号鍵を配布する。
【００７９】
なお、図示していないが、ユーザ管理部３は、メインルーチンとは独立にチャットクライアントからのユーザ情報の変更の通知を受け付け、通知に従って鍵配布属性及び鍵変更属性をを更新している。
（２）鍵取得処理
次に、前記メインルーチンのステップＳ４で行う鍵取得処理について、図４を参照しながら説明する。
【００８０】
まず、ステップＳ１１では、鍵取得部４が、暗号化モードの設定になっているかどうかを判断する。暗号化モードであれば、会話内容は全て暗号化されており、チャネル暗号鍵を取得する必要があるので、後述するステップＳ１３に移行する。暗号化モードでなければステップＳ１２に移行する。
ステップＳ１２では、鍵取得部４は、暗号化／復号化部８から鍵の取得を指示されているか否かを判断する。チャネル暗号鍵を取得していない状態で暗号化フラグが"１"のまたは暗号鍵ＩＤを含む会話メッセージを受信した場合、暗号化／復号化部８は鍵取得部４に対して鍵の取得を指示するからである。ステップＳ１２では、暗号化／復号化部８からの指示を待機し、指示があるとステップＳ１３に移行する。
【００８１】
ステップＳ１３では、鍵取得部４が、他のユーザを選択するための乱数を発生させる。
ステップＳ１４では、鍵取得部４が、発生させた乱数に基づいて、鍵配布属性を有する他のユーザの中からいずれかのユーザを選択する。
ステップＳ１５では、鍵取得部４が、記憶部２からユーザの公開鍵を取り出し、チャネル名及びニックネームにユーザの公開鍵を含むユーザ証明書を添付し、チャネル暗号鍵の要求を送信する。前述のように、鍵取得部４は、暗号鍵ＩＤを含む会話メッセージの受信に応じてチャネル暗号鍵を要求する場合には、暗号鍵ＩＤを指定して要求を送信する。逆に、暗号化モードの通知または暗号化フラグが“１”の会話メッセージの受信に応じて要求を行う場合には、暗号鍵ＩＤを指定せずに要求を送信する。
【００８２】
ステップＳ１６では、鍵取得部４が、チャネル暗号鍵及び暗号鍵ＩＤを受信したか否か判断し、まだであればステップＳ１７に移行する。受信していればステップＳ１８に移行する。
ステップＳ１７では、鍵取得部４が、所定時間Ｔが経過しているか否かを判断し、まだであればステップＳ１６に戻ってチャネル暗号鍵の受信を待機する。所定時間Ｔが経過していれば、鍵取得部４は、選択したユーザが何らかの理由によりチャネル暗号鍵を送信できないものと判断し、他のユーザ端末を再度選択すべくステップＳ１３に戻る。
【００８３】
ステップＳ１８では、鍵取得部４が、受信した暗号鍵をユーザの公開鍵を用いて復号化してチャネル暗号鍵を得、チャネル暗号鍵と共に受信した暗号鍵ＩＤとともに暗号鍵リストに格納し、処理を終了する。
（３）鍵配布処理
次に、前記メインルーチンのステップＳ５で行う鍵配布処理について、図５を参照しながら説明する。
【００８４】
まず、ステップＳ２１では、鍵配布部５が、ユーザ情報を参照し、自己のユーザ端末に鍵配布属性があるか否かを判断する。鍵配布属性がなければ処理を終了し、あればステップＳ２２に移行する。
ステップＳ２２では、鍵配布部５が、他のユーザ端末からのチャネル暗号鍵の要求を受け取ったか否かを判断する。受け取っていればステップＳ２３に移行し、受け取っていなければ、要求を受け取るまで待機する。
【００８５】
ステップＳ２３では、鍵配布部５が、後述する要求検証サブルーチンを実行し、要求の送信元が正当なユーザか否かを検証して検証結果を得る。
ステップＳ２４では、鍵配布部５が、検証結果に基づき要求元ユーザが正当なユーザか否かを判断し、正当でなければステップＳ２５に移行する。正当なユーザであれば、ステップＳ２６に移行する。
【００８６】
ステップＳ２５では、鍵配布部５が、正当でないユーザに対して例えばチャネル暗号鍵を配布できない旨のメッセージを送信するなどの適当な処理を行う。
ステップＳ２６では、要求元が正当なユーザであったので、鍵配布部５は、チャネル暗号鍵の要求とともに送られて来ているユーザ証明書から要求元ユーザの公開鍵を取り出す。
【００８７】
ステップＳ２７では、鍵配布部５が、最新のチャネル暗号鍵を暗号鍵リストから取り出す。要求と共に暗号鍵ＩＤが送信されてきている場合は、暗号鍵ＩＤにより特定されるチャネル暗号鍵を取り出す。また、取り出したチャネル暗号鍵にハッシュ関数をかけて暗号鍵ＩＤを求める。
ステップＳ２８では、鍵配布部５が、前記チャネル暗号鍵を要求元ユーザの公開鍵で暗号化する。
【００８８】
ステップＳ２９では、鍵配布部５が、暗号化されたチャネル暗号鍵及び暗号鍵ＩＤを、チャットクライアントを介して要求元ユーザ端末に送信し、メインルーチンに戻る。
（４）要求検証処理サブルーチン
次に、前記鍵配布サブルーチンのステップＳ２３で行う要求検証処理について、図６を参照しながら説明する。
【００８９】
ステップＳ３１では、鍵配布部５が、チャネル暗号鍵の要求とともに送信されてきたユーザ証明書を取り出す。
ステップＳ３２では、鍵配布部５が、ユーザ証明書の中の認証局の電子署名を取り出す。
ステップＳ３３では、鍵配布部５が、前記取り出した電子署名を、通常ユーザ端末が有する認証局データベースのなかから検索する。
【００９０】
ステップＳ３４では、鍵配布部５が、前記検索の結果に基づいて電子署名が認証局ＤＢに登録されているか否かを判断し、登録されていなければステップＳ３９１に移行する。登録されていればステップＳ３５に移行する。
ステップＳ３５では、鍵配布部５が認証局の公開鍵を認証局ＤＢから取得する。
【００９１】
ステップＳ３６では、鍵配布部５が、前記電子署名を認証局の公開鍵で復号化し、ユーザ証明書のメッセージダイジェスト（ＭＤ）を求める。
ステップＳ３７では、鍵配布部５が、前記ユーザ証明書のうち、前記電子署名の対象となっている部分を取り出し、通常用いられるアルゴリズムを用いてメッセージダイジェスト（ＭＤ'）を計算する。通常用いられるアルゴリズムとしては、例えばＭＤ５やＳＨＡなどが挙げられる。
【００９２】
ステップＳ３８では、鍵配布部５が、２つのメッセージダイジェストを比較し、両者が一致していればステップＳ３９に移行する。一致しなければステップＳ３９１に移行する。
ステップＳ３９では、鍵配布部５が「要求元ユーザは正当である」旨を検証結果とする。
【００９３】
ステップＳ３９１では、鍵配布部５が、要求元ユーザを不当なユーザとして扱い、例えば要求元ユーザに不当である旨の通知を送出する。
（５）鍵変更処理
次に、前記メインルーチンと平行して独立に行われる鍵変更処理について、図７を参照しつつ説明する。
【００９４】
まず、ステップＳ４１では、鍵変更部６が、当該ユーザ端末に鍵変更属性があるか否かを、ユーザ情報を参照して判断する。鍵変更属性がないと判断すると、後述するステップＳ５０に移行する。鍵変更属性があると判断すると、ステップＳ４２に以降する。
ステップＳ４２では、鍵変更部６が、当該ユーザ端末に鍵変更属性とともに付与されている優先順位が第１位か否かを判断する。第１位であればステップＳ４３に移行し、第２位以降であれば後述するステップＳ５０に移行する。
【００９５】
ステップＳ４３では、鍵変更部６が所定のトリガの発生を待機し、所定のトリガが発生すると、ステップＳ４４に移行する。今、説明を分かりやすくするために、チャネル内ユーザが１人になったときまたは所定時間毎に、チャネル暗号鍵を変更するものとする。具体的には、チャネル内ユーザが最後の１人になった場合、またはチャネル内に複数のユーザがいても前回の変更から所定時間が経過している場合に、ステップＳ４４に移行する。
【００９６】
ステップＳ４４では、鍵変更部６が、予め決めておいた規則により暗号鍵を生成する。例えば、ユーザ端末において本プログラムが格納されているアドレス、前記トリガが発生した時刻、チャネル名及びチャネルのパスワードの組合わせにハッシュ関数をかけたものを新たなチャネル暗号鍵とする。また、新たなチャネル暗号鍵にハッシュ関数をかけて暗号鍵ＩＤを求める。
【００９７】
ステップＳ４５では、鍵変更部６が、直前のチャネル暗号鍵を暗号鍵リストから取得する。
ステップＳ４６では、鍵変更部６が、生成した新たな暗号鍵を直前のチャネル暗号鍵で暗号化する。
ステップＳ４７では、鍵変更部６が、暗号化した新たなチャネル暗号鍵の送信を行うか否かを、現在の会話状況に基づいて判断する。例えば、最後の発言から所定時間経過していれば、会話がとぎれていると判断してステップＳ４８に移行する。所定時間経過していなければ、会話が断続的に続いていると判断し、再度ステップＳ４７を繰り返して会話がとぎれるのを待機する。
【００９８】
ステップＳ４８では、鍵変更部６が、暗号化された新たなチャネル暗号鍵及び暗号鍵ＩＤを、チャットクライアントを介して他のユーザ端末に送信する。
ステップＳ４９では、当該ユーザ端末のチャットクライアントがチャネルから退出したか否かを判断し、退出していれば処理を終了する。退出していなければ、再びステップＳ４２に戻り、前記処理を繰り返す。
【００９９】
ステップＳ４１で鍵変更属性がないと判断された場合、または、ステップＳ４２で鍵変更属性の優先順位が第２位以下であると判断された場合、ステップＳ５０に移行して新たなチャネル暗号鍵の取得を行う。
ステップＳ５０では、鍵取得部４が、前回のチャネル暗号鍵の変更から所定時間経過するのを待機し、所定時間が経過するとステップＳ５１に移行する。本実施形態例においては、鍵取得部４は、ユーザ端末内の内部時計を参照することにより、前回のチャネル暗号鍵の変更からの経過時間を監視する。
【０１００】
ステップＳ５１では、鍵取得部４が新たなチャネル暗号鍵を取得したか否かを判断し、まだ取得していなければ鍵取得部４はユーザ管理部３に対して優先順位の繰り上げを通知し、ステップＳ５２に移行する。取得していれば後述するステップＳに移行する。
ステップＳ５２では、前記通知を受けたユーザ管理部３が、鍵変更属性の優先順位が第２位以降のユーザの優先順位を順次繰り上げ、ユーザ情報の書き換えを行う。これにより、書き換え前は第２位以降であったユーザ全ての優先順位が変化する。
【０１０１】
ステップＳ５３では、優先順位の書き換えにより優先順位が第１位になったか否かを鍵変更部６により判断し、第１位であればステップＳ４３に移行して前記チャネル暗号鍵の変更を行う。優先順位が第２位以降であれば、前記ステップＳ５０に移行し、新たなチャネル暗号鍵の取得を行う。
ステップＳ５４では、他のユーザ端末から送信された新たなチャネル暗号鍵を取得したので、鍵取得部４が、暗号化されたチャネル暗号鍵を直前のチャネル暗号鍵を用いて復号化し、新たなチャネル暗号鍵を得る。
【０１０２】
ステップＳ５５では、取得部が、得られたチャネル暗号鍵と暗号鍵ＩＤとを対応付けて暗号鍵リストに格納する。
ステップＳ５６では、当該ユーザ端末のチャットクライアントがチャネルから退出したか否かを判断し、退出していれば処理を終了する。退出していなければ、再びステップＳ４１に戻り、前記処理を繰り返す。
【０１０３】
＜第２実施形態例＞
チャットクライアント間で１対１の会話を行う場合は、会話の開始元の鍵取得部４が、相手先に対して自分の公開鍵を付加してセッション鍵要求を出す。
要求を受けた相手先では、鍵生成部７がセッション鍵を生成し、要求元の公開鍵でセッション鍵を暗号化して要求元に送る。セッション鍵は、前記第１実施形態例と同様、会話の開始元や相手先の固有情報、時刻、クライアントに内蔵される秘密情報の組合せに対し、ハッシュ関数をかけて生成すると良い。
【０１０４】
さらに、前記第１実施形態例と同様、新規セッション鍵は直前のセッション鍵を用いて暗号化して相手先に送ることが好ましい。また送信の際には、新規セッション鍵を相手先の公開鍵で暗号化して送信することが好ましいのも第１実施形態例と同様である。
要求元の鍵取得部４は、ユーザの秘密鍵でセッション鍵を復号化し、記憶部２に格納する。以降、相互にセッション鍵によってメッセージを暗号化して会話を行う。
【０１０５】
セッション鍵の変更のタイミングや条件は、前記第１実施形態例と同様である。すなわち、所定時間が経過したとき、所定会話数を超過したとき、所定会話量を超過したときなどにセッション鍵を変更する。また、セッション鍵の変更は、会話の開始元が行っても、また会話の相手先が行ってもよい。セッション鍵の変更を、前回メッセージを送信した方が行ったり、前回メッセージを受信した方が行ったりしてもよい。
【０１０６】
なお、会話開始の要求を受けた鍵配布部５が、要求に付加されている公開鍵の正当性をチェックし、不当な場合は要求を受け付けないことはいうまでもない。公開鍵は、通常利用者端末に内蔵されている認証局の電子署名が施された公開鍵や、接続中のサーバの電子署名が施された公開鍵や、自らが電子署名した公開鍵を正当として認めることが考えられる。
【０１０７】
＜第３実施形態例＞
前記の第１実施形態例においては、セキュリティ強化装置１に設けたユーザ管理部３により鍵配布属性及び鍵変更属性を設けたが、他の方法も可能である。例えば、チャネルオペレータ属性などと同様に、鍵配布属性及び鍵変更属性をチャットシステム上のユーザ属性として設ける。各チャットクライアントは、ニックネームやチャネルオペレータ属性などと同様に、鍵配布属性及び鍵変更属性をユーザ情報の一部としてチャットサーバから取得し、ユーザＤＢに格納する。セキュリティ強化装置は、ユーザＤＢ内のユーザ情報を参照し、前述の処理を行う。
【０１０８】
＜第４実施形態例＞
前記の第１実施形態例においては、チャネル暗号鍵を変更するタイミングを鍵取得部４により監視しているが、他の形態も考えられる。例えば、鍵生成部７、鍵配布部５及び鍵変更部６は、チャネル暗号鍵と共にチャネル暗号鍵が次に変更される時刻を送信する。各ユーザ端末は、チャネル暗号鍵と共にチャネル暗号鍵の有効期限を持つことになる。各ユーザ端末の鍵取得部４は、チャネル暗号鍵の有効期限をチャネル暗号鍵の変更タイミングとする。チャネル暗号鍵と共にチャネル暗号鍵の有効期限を示す時刻を送信することにより、チャネル暗号鍵の変更を所定時間毎に行うことはもちろん、任意のタイミングで行うことが出来る。
【０１０９】
もっとも、各ユーザ端末において内部時計にずれがある場合も考えられる。そこで、チャネル暗号鍵の有効期限を示す情報として、時刻に代えて相対時間及び起点時刻を用いることが考えられる。起点時刻としては、チャネル暗号鍵が生成された時刻を用い、相対時間としては、生成時刻を起点とした場合に次にチャネル鍵が変更されるまでの時間を用いる。
【０１１０】
また前述のように、時間に基づくのではなく他の変化が生じた場合、例えばチャネル内ユーザが一人になった場合にチャネル暗号鍵の変更を行うこともあり得る。このような設定では、変化の頻度が少なすぎ、チャネル暗号鍵が長時間変更されない場合も考えられる。このような場合を防止する方法として、例えば次のような方法が挙げられる。
【０１１１】
通常、鍵の生成に用いられるアルゴリズムは、鍵に有効期限を持たせている。そこで、鍵生成部７、鍵配布部５及び鍵変更部６により、チャネル暗号鍵と共にその有効期限を各ユーザ端末に送信する。鍵取得部４は、チャネル暗号鍵の有効期限まで所定の変化が生じなかった場合、有効期限をチャネル暗号鍵の変更タイミングとする。
【０１１２】
【発明の効果】
チャットクライアント間でチャネル暗号鍵を分散管理し、クライアント間で公開鍵暗号を利用して鍵の配布を行い、チャネル暗号鍵を共有する。
サーバに無関係に、クライアント間でチャネル暗号鍵を生成し、配布するので、サーバにメッセージ内容が漏洩することなく、チャネル内の会話のセキュリティを高めることが出来る。また、クライアント間で、メッセージの暗号化／復号化が行われるため、クライアント側に負荷が分散され、サーバの負荷を軽減することが出来る。
【図面の簡単な説明】
【図１】第１実施形態例に係るセキュリティ強化装置の機能ブロック図。
【図２】ユーザ情報の一例を示す説明図。
【図３】第１実施形態例に係るセキュリティ強化装置が行う主な処理の流れを示すフローチャート。
【図４】鍵取得処理の流れを示すフローチャート。
【図５】鍵配布処理の流れを示すフローチャート。
【図６】要求検証処理の流れを示すフローチャート。
【図７】鍵変更処理の流れを示すフローチャート。
【発明の属する技術分野】
本発明は、イントラネットやインターネットなどのコンピュータネットワーク上で行われる通信のセキュリティを高める技術に関し、なかでもチャットシステムにおける会話内容のセキュリティを高める技術に関する。
本発明において、チャットシステムとは、チャットサーバと複数のチャットクライアントとから構成され、複数の利用者が互いに同一のチャネルを共有して同時に会話可能なシステムをいう。チャネルとは、論理的にユーザをグルーピングした仮想空間であり、チャネル内での発言がチャネルを共有する利用者全員にブロードキャストされる仮想空間である。ニックネームとは、チャットシステム上でユーザを識別するための名前である。チャネルオペレータ属性とは、チャネル内のユーザ管理及びモード管理を行う権限である。ボットとは、チャネルに参加して様々なサービスを提供するソフトウェアロボットを言う。
【０００２】
【従来の技術】
従来、チャットサーバとチャットクライアントとからなるチャットシステムにおいて、チャットクライアント間の会話内容のセキュリティを高めるために、会話内容を共通鍵で暗号化することが提案されている。この共通鍵の生成方法として、例えばチャットサーバがチャネル暗号鍵を生成し、複数のチャットクライアントに配布する方法が提供されている。
【０００３】
また、チャットクライアントとしてサーバに接続するボットを準備しておき、このボットにチャネル暗号鍵を生成及び配布させ、また生成したチャネル暗号鍵を管理させる方法も提案されている。さらに、チャットクライアントにあらかじめチャネル暗号鍵を組み込んでおくことも考えられる。
【０００４】
【発明が解決しようとする課題】
前記チャットサーバがチャネル暗号鍵を生成してチャットクライアントに配布する方法では、クライアントとサーバとの間の通信路上では会話内容の秘匿が行われる。しかし、サーバがチャネル暗号鍵を知っているので、サーバ上で会話の解読が可能であるという問題がある。
【０００５】
一方、ボットを用いてチャネル鍵を管理する方法を用いると、チャットサーバに会話内容が漏洩することはないものの、ボット上で会話内容の解読が可能である。また、サーバと別個独立したボットを運用することになり、運用上面倒である。チャットクライアントにチャネル暗号鍵を組み込む構成は、単純ではあるものの鍵を変更できないため、鍵を解読される可能性が高くなるおそれがある。
【０００６】
本発明は、チャネル暗号鍵を用いて会話の暗号化／復号化を行う場合に、チャネル暗号鍵を管理する負担を軽減し、チャネル鍵の解読を困難にするセキュリティ強化方法及び装置を提供することを目的とする。
【０００７】
【課題を解決するための手段】
前記の課題を解決するために、本願第１発明は、互いに同一のネットワークを共有して同時に双方向通信が可能な通信装置に用いられ、以下のステップを含むセキュリティ強化方法を提供する。
・前記通信装置の処理手段が、前記共有されたネットワーク内の通信内容を暗号化及び復号化するための暗号鍵を記憶手段に保持する記憶ステップ、
・前記処理手段が、通信内容を前記通信装置から取得し、前記暗号鍵を用いて暗号化する暗号化ステップ、
・前記処理手段が、通信内容を前記通信装置から取得し、前記暗号鍵を用いて復号化する復号化ステップ、
・前記通信装置が前記いずれかのネットワークに参加している場合に、前記処理手段が、少なくとも前記ネットワークを共有する他の通信装置リストを含む所定の利用者情報を前記通信装置から取得し、他のセキュリティ強化装置に暗号鍵の配布を許可する鍵配布属性を前記取得した利用者情報に基づいて設定し、取得した利用者情報及び設定した鍵配布属性を前記記憶手段に格納する利用者管理ステップ、
・前記処理手段が、前記設定した鍵配布属性に基づいて前記暗号鍵を取得するか否かを判断し、前記判断の結果に基づいて前記他の通信装置リストからいずれかの通信装置を選択して前記暗号鍵を要求し、前記要求に応じて前記他の通信端末から送信される暗号鍵を前記記憶手段に格納する鍵取得ステップ、
・前記処理手段が、前記設定した鍵配布属性に基づいて前記暗号鍵を生成するか否かを判断し、前記判断の結果に基づいて前記暗号鍵を生成し、他の前記通信装置から前記暗号鍵の要求があった場合、前記記憶手段からいずれかの暗号鍵を読み出して前記他の通信端末に配布可能な鍵配布ステップ。
【０００８】
チャットシステムを例に取り説明する。例えば、チャットクライアントは、利用者情報としてニックネーム、ユーザＩＤ、チャネルオペレータか否か等を取得可能である。そこで、鍵配布属性を、例えばチャネルオペレータ属性に連動させ、チャネルオペレータであれば鍵配布属性ありに設定する。チャネル開設者により最初のチャネル暗号鍵を生成する。次にチャネルに参加してきたユーザは、チャネル開設者に対してチャネル暗号鍵を要求する。チャネル開設者は、前記要求に応じてチャネル暗号鍵を付与する。このように、ユーザ端末間でチャネル暗号鍵を配布し、サーバやボット上でのチャネル暗号鍵の解読を防止する。
【０００９】
本願第２発明は、他の通信装置と互いに同一のネットワークを共有して同時に双方向通信が可能な通信装置とともに用いられ、記憶手段と、暗号化手段と、復号化手段と、利用者管理手段と、鍵取得手段と、鍵配布手段とを備えるセキュリティ強化装置を提供する。
記憶手段は、前記共有されたネットワーク内の通信内容を暗号化及び復号化するための暗号鍵を保持する。暗号化手段は、通信内容を前記通信装置から取得し、前記暗号鍵を用いて暗号化する。復号化手段は、通信内容を前記通信装置から取得し、前記暗号鍵を用いて復号化する。
【００１０】
利用者管理手段は、前記通信装置が前記いずれかのネットワークに参加している場合に、少なくとも前記ネットワークを共有する他の通信装置リストを含む所定の利用者情報を前記通信装置から取得し、他のセキュリティ強化装置に暗号鍵の配布を許可する鍵配布属性を、前記取得した利用者情報に基づいて設定し、取得した利用者情報及び設定した鍵配布属性を前記記憶手段に格納する。鍵取得手段は、前記設定した鍵配布属性に基づいて前記暗号鍵を取得するか否かを判断し、前記判断の結果に基づいて前記他の通信装置リストからいずれかの通信装置を選択して前記暗号鍵を要求し、前記要求に応じて前記他の通信端末から送信される暗号鍵を前記記憶手段に格納する。鍵配布手段は、前記設定した鍵配布属性に基づいて前記暗号鍵を生成するか否かを判断し、前記判断の結果に基づいて前記暗号鍵を生成し、他の前記通信装置から前記暗号鍵の要求があった場合、前記記憶手段からいずれかの暗号鍵を読み出して前記他の通信端末に配布可能である。
【００１１】
セキュリティ強化装置をチャットクライアントと共に用いる場合を例に取る。利用者管理手段は、チャネルに入るとそのチャネルに参加しているニックネームリストを含む利用者情報を、チャットクライアントを介して取得する。例えば、チャットクライアントは、利用者情報としてニックネーム、ユーザＩＤ、チャネルオペレータか否か等を取得可能である。そこで、鍵配布属性を、例えばチャネルオペレータ属性に連動させ、チャネルオペレータであれば鍵配布属性ありに設定する。次に、鍵取得手段は、ニックネームリストから鍵配布属性を有するいずれかの他の利用者を選択し、その利用者端末にチャネル暗号鍵を要求する。この要求を受け取った他の利用者端末では、鍵配布手段が、記憶手段からチャネル暗号鍵を取り出し、要求元の利用者端末に送信する。要求元の利用者端末は、鍵取得手段によりチャネル暗号鍵を受け取って記憶手段に格納する。暗号化手段及び復号化手段は、前記のようにして記憶手段に格納されたチャネル暗号鍵を用い、以降の会話内容を暗号化及び復号化する。
【００１２】
本願第３発明は、前記第２発明において、前記通信装置が、前記セキュリティ強化装置との連携手段を有している。さらに、連携手段は、前記暗号鍵の要求、前記要求に応じて送信される暗号鍵、前記利用者情報に関する情報及び所定の条件に合致する場合は通信内容の受け渡しを、通信装置とセキュリティ強化装置との間で行うセキュリティ強化装置を提供する。
【００１３】
例えば、受信した通信内容が暗号化されている場合、連携手段は、暗号化されている通信内容をセキュリティ強化装置に送出する。復号化された通信内容は連携手段を介してセキュリティ装置から通信装置に送出され、通常の会話内容と同様に表示される。逆に、通信内容を暗号化する場合、連携手段は入力された通信内容をセキュリティ強化装置に送出する。暗号化された通信内容は連携手段を介してセキュリティ強化装置から通信装置に送出され、通信装置により通常の会話内容と同様の扱いで送信される。
【００１４】
本願第４発明は、前記第２発明において、前記利用者管理手段が、所定の条件に基づいて、他の通信装置を選択し、前記暗号鍵の配布を許可する鍵配布属性を前記他の通信装置に付与するセキュリティ強化装置を提供する。さらに利用者管理手段は、鍵配布属性の設定及び設定対象の通信装置を前記通信装置から取得し、前記記憶手段に格納する。
【００１５】
たとえば、利用者管理手段は、そのチャットクライアントがチャネル開設者である場合に、他の利用者端末を選択する。選択方法は、チャネルに参加しているチャットクライアントからランダムに一定数選択したり、所定の参加順位までのチャットクライアントを選択するなどが挙げられる。他の利用者端末に鍵配布属性を付与可能にするために、具体的にはチャットシステムのプロトコルに新たに拡張プロトコルを設け、鍵配布属性を利用者情報として設定可能にすると良い。また、チャネルオペレータの設定と同様に、設定コマンドに基づいて鍵配布属性を付与可能にしても良い。
【００１６】
本願第５発明は、前記第２発明において、利用者管理手段が、他の通信装置の選択と、前記暗号鍵の配布を許可する鍵配布属性の前記他の通信装置への付与及び解除の指示とを受け付け、かつ鍵配布属性の設定及び設定対象の通信装置を前記通信装置から取得し、前記記憶手段に格納するセキュリティ強化装置を提供する。
【００１７】
利用者による鍵配布属性の設定及び解除を受け付け、個々の利用者端末にかかる鍵配布負担を利用者自身により調節可能にする。
本願第６発明は、前記第２発明において、鍵取得手段が所定の条件に基づいて前記暗号鍵の要求先を選択するセキュリティ強化装置を提供する。
すなわち、鍵取得手段は、乱数を発生させたり、鍵配布属性を有する通信装置から選択する等、所定の条件に基づいてチャネル暗号鍵の要求先を選択する。
【００１８】
本願第７発明は、前記第２発明において鍵取得手段が、所定の条件に基づいて前記暗号鍵の要求先を選択して前記暗号鍵を要求し、所定時間内に前記要求先から暗号鍵が送信されない場合、他の通信装置を選択して再度要求を行うセキュリティ強化装置を提供する。
要求先から一定時間内に暗号鍵が送信されてこない場合、鍵取得手段は要求先に何らかのトラブルがあったとして要求先の通信装置を選択し直す。選択基準は、ランダム、鍵配布属性のある通信装置など所定の条件を満たすものを選択する。
【００１９】
本願第８発明は、前記第２発明において、鍵取得手段が、前記通信内容が暗号化されている場合に前記暗号鍵の取得要求を行うセキュリティ強化装置を提供する。
例えば、チャットシステムにおいて、チャネル内の通信内容の全てを暗号化する暗号化モードを設定可能にしておく。鍵取得手段は、参加したチャネルのモードをチャットクライアントから取得し、暗号化モードがオンである場合は暗号鍵の取得要求を行う。
【００２０】
本願第９発明は、前記第２発明において、前記復号化手段が、前記通信装置から受け取る通信内容を復号不可能と判断した場合、前記暗号鍵の要求を行うことを決定し、前記鍵取得手段が、前記復号化手段の決定に従い、前記暗号鍵の取得要求を行うセキュリティ強化装置を提供する。
会話単位で暗号化を設定可能にすることも考えられる。例えば、ＧＵＩ(Graphic User Interface)によりコマンドボタンを表示し、このコマンドボタンのオンオフにより会話毎に暗号化の設定やその解除を行う。暗号化が設定されている場合、暗号化手段は、暗号化された会話内容の先頭部分に、会話の暗号化を示す暗号化フラグを記述する。通信装置は、会話内容に送信コマンドを付加し、ネットワークに送出する。復号化手段は、暗号化された会話内容を受け取ったが暗号鍵がない場合や、保持されている暗号鍵では復号化できない場合、暗号鍵を要求する旨の判断をする。鍵取得手段は、復号化手段の判断に従い、暗号鍵の取得要求を行う。
【００２１】
本願第１０発明は、前記第２発明において、前記記憶手段が複数の暗号鍵と暗号鍵を特定する鍵識別情報とを対応付けて記憶し、前記暗号化手段が、前記通信内容の暗号化に用いられた暗号鍵を示す鍵識別情報と通信内容とを、前記通信装置を介してネットワークに送出可能であり、前記復号化手段が、前記鍵識別情報で特定される暗号鍵は前記記憶手段に保持されているか否かを判断し、前記鍵取得手段が、前記判断結果に従い、前記鍵識別情報を通知して前記暗号鍵の取得要求を行うセキュリティ強化装置を提供する。
【００２２】
会話毎に暗号化の設定及び解除が行われる場合に、復号化手段がその会話の暗号化に用いられたチャネル暗号鍵を有していないと判断すれば、鍵取得手段はその判断に従ってチャネル暗号鍵の取得要求を行う。その際には、鍵識別番号を通知することにより、どの暗号鍵を要求しているかを特定する。鍵識別番号としては、チャネル生成時からのシリアル番号や、チャネル暗号鍵にハッシュ関数等の一方向関数をかけたものなどが挙げられる。
【００２３】
本願第１１発明は、前記第２発明において、前記鍵取得手段が、利用者の公開鍵暗号系の公開鍵を前記暗号鍵の要求とともに通知し、前記要求に応じて送信される暗号鍵を利用者の秘密鍵を用いて復号化し、前記鍵配布手段が、前記要求元の公開鍵暗号系の公開鍵を用いて暗号化した前記暗号鍵を配布するセキュリティ強化装置を提供する。
【００２４】
暗号鍵を要求する要求元の鍵取得手段は、利用者の公開鍵を通知して要求を行う。要求を受け取った通信装置の鍵配布手段は、公開鍵を用いて暗号鍵を暗号化し、送り返す。要求元では、鍵取得手段が利用者の秘密鍵を用いて復号化し、暗号鍵を取得する。
本願第１２発明は、前記第２発明において、前記鍵配布手段が、他の前記通信装置から前記暗号鍵の要求があった場合、前記要求を検証し、検証結果に基づいて前記記憶手段からいずれかの暗号鍵を読み出し、前記他の通信端末に配布可能であるセキュリティ強化装置を提供する。
【００２５】
チャネル暗号鍵の要求を受け取った他の利用者端末では、まず鍵配布手段が要求を検証する。正当な要求者であれば、鍵配布手段は、記憶手段からチャネル暗号鍵を取り出して要求元の利用者端末に送信する。前述の要求元公開鍵を用いる例では、鍵配布手段は、要求元の公開鍵が正当な公開鍵か否かを検証することが好ましい。例えば、認証局の電子署名がある公開鍵や、ＩＲＣサーバの電子署名が施された公開鍵、暗号鍵の要求を受けたユーザの電子署名がある公開鍵などを、正当な公開鍵と見なすことが挙げられる。
【００２６】
本願第１３発明は、前記第２発明において、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備えるセキュリティ強化装置を提供する。
すなわち、適当なタイミングで暗号鍵を更新することにより、暗号鍵の解読を防止してセキュリティを高める。適当なタイミングとは、例えば所定の時間間隔、所定の会話数または会話量を超過したとき、ネットワークの参加利用者数が所定数を超えたときや下回ったとき、話題が変化したとき、最後の会話から所定時間経過したとき、利用者が暗号鍵の変更を指示したときなど様々なタイミングが考えられる。また、前記タイミングが生じても、会話が続行している最中は変更した鍵の配布を待機し、会話がとぎれたタイミングで鍵を再配布することも考えられる。
【００２７】
本願第１４発明は、前記第２発明において、所定のタイミングで前記暗号鍵を更新し、前記更新した暗号鍵を直前の暗号鍵を用いて暗号化して他の通信装置に配布する鍵変更手段をさらに備えるセキュリティ強化装置を提供する。
前記更新された暗号鍵をその更新前の暗号鍵を用いて暗号化することにより、更新された暗号鍵を配布する際の解読のおそれを防止する。
【００２８】
本願第１５発明は、前記第２発明において、前記鍵変更手段が、前記各通信装置内に保持される秘密情報、時間情報及びネットワークに固有の情報のいずれかまたは全ての組合せに基づいて前記暗号鍵を生成するセキュリティ強化装置を提供する。
例えば、通信装置内に記憶されている基板番号やプログラムの格納アドレス、暗号鍵を更新する時間、チャネル名及びチャネルパスワードに基づいて、新たな暗号鍵を生成することが考えられる。
【００２９】
本願第１６発明は、前記第２発明において、前記鍵変更手段が、前記各通信装置内に保持される秘密情報、時間情報及びネットワークに固有の情報のいずれかの組合せまたは全てを、一方向関数で暗号化して前記暗号鍵を生成するセキュリティ強化装置を提供する。
例えば、通信装置内に記憶されている基板番号やプログラムの格納アドレス、暗号鍵を生成する時間、チャネル名及びチャネルパスワードを、ハッシュ関数で暗号化して暗号鍵とする。
【００３０】
本願第１７発明は、前記第２発明において、前記利用者管理手段が、前記暗号鍵の更新及び配布を許可する鍵変更属性を、前記取得した利用者情報に基づいて設定して前記記憶手段に格納し、前記鍵変更属性の有無に基づいて、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備えるセキュリティ強化装置を提供する。
【００３１】
前記鍵配布属性と同様、鍵変更属性をチャネルオペレータ属性に連動させて設定したり、チャネルに最後まで参加している利用者に設定してもよい。また、新たに拡張プロトコルを設けてチャットシステム上で鍵変更属性を設定可能にし、鍵変更属性を利用者情報として取得するようにしても良い。さらに、チャネルオペレータからの設定コマンドに基づいて鍵変更属性を設定することも可能である。
【００３２】
本願第１８発明は、前記第２発明において、前記利用者管理手段が、利用者が前記暗号鍵の更新及び配布を許可する鍵変更属性を有する場合に、所定の条件に基づいて他の通信装置を選択し、前記選択した通信装置に前記鍵変更属性を設定可能である。かつ、利用者管理手段は、鍵変更属性の設定及び設定対象の通信装置を前記通信装置から取得して前記記憶手段に格納する。さらに、前記鍵変更属性の有無に基づいて、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備えるセキュリティ強化装置である。
【００３３】
鍵変更属性を有する利用者は、他の利用者に対して鍵変更属性を付与可能にしても良い。他の利用者の選択方法は、ランダムに一定数の通信装置を選択したり、チャネルへの参加順序に応じて一定数の通信装置を選択したり、任意の通信装置を通信装置リストから選択したり、様々である。鍵変更属性の設定は、例えばチャットシステム上で新たなコマンドを設定することにより可能になる。この設定に応じて、チャネルに参加しているユーザ端末は、ユーザ情報の書き換えをそれぞれ行う。
【００３４】
本願第１９発明は、前記第２発明において、前記利用者管理手段が、前記暗号鍵の更新及び配布を許可する鍵変更属性及び優先順位を、前記取得した利用者情報に基づいて設定して前記記憶手段に格納し、前記利用者情報の変化に従って前記優先順位の書き換えを行う。さらに、鍵変更属性及び優先順位に基づいて、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備えるセキュリティ強化装置である。
【００３５】
例えば、チャネルオペレータ属性に基づいて鍵変更属性を、チャネルへの参加順序に基づいて優先順位を設定する。第２位以降の利用者管理手段は、第１位の通信装置がネットワークから退出した場合や、前回の暗号鍵の更新から所定時間が経過して第１位の通信装置に何らかのトラブルがあったと判断する場合、利用者情報に基づいて自動的に優先順位をひとつづつ繰り上げる。新たな鍵の生成は、第１位のユーザが、所定のタイミングで行う。
【００３６】
本願第２０発明は、前記第２発明において、前記利用者管理手段が、利用者が前記暗号鍵の更新及び配布を許可する鍵変更属性を有する場合に、所定の条件に基づいて他の通信装置を選択し、前記他の通信装置に前記鍵変更属性と優先順位とを設定可能である。かつ、利用者管理手段は、鍵変更属性と優先順位との設定及び設定対象の通信装置を前記通信装置から取得して前記記憶手段に格納し、前記利用者情報の変化に従って前記優先順位の書き換えを行う。さらに、このセキュリティ強化装置は、前記鍵変更属性及び優先順位に基づいて、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備えている。
【００３７】
例えば、チャネル暗号鍵の変更及び配布は、第１位の通信装置が行う。第２位以下の通信装置は、第１位の通信装置が配布する新たなチャネル暗号鍵を取得する。第２位以降の利用者管理手段は、第１位の通信装置がネットワークから退出した場合や、前回の暗号鍵の更新から所定時間が経過して第１位の通信装置に何らかのトラブルがあったと判断する場合、利用者情報に基づいて自動的に優先順位をひとつづつ繰り上げる。新たに第１位となった通信装置は、自ら暗号鍵の変更及び配布を行う。
【００３８】
本願第２１発明は、互いに同一のネットワークを共有して同時に双方向通信が可能な複数の通信装置から構成され、前記各通信装置が、記憶手段と、暗号化手段と、復号化手段と、利用者管理手段と、鍵取得手段と、鍵配布手段とを備えるセキュリティ強化システムを提供する。
記憶手段は、前記共有されたネットワーク内の通信内容を暗号化及び復号化するための暗号鍵を保持する。
【００３９】
暗号化手段は、通信内容を前記暗号鍵を用いて暗号化する。復号化手段は、通信内容を前記暗号鍵を用いて復号化する。利用者管理手段は、前記いずれかのネットワークに参加している場合に、少なくとも前記ネットワークを共有する他の通信装置リストを含む所定の利用者情報を取得し、他のセキュリティ強化装置に暗号鍵の配布を許可する鍵配布属性を、前記取得した利用者情報に基づいて設定し、取得した利用者情報及び設定した鍵配布属性を前記記憶手段に格納する。
【００４０】
鍵取得手段は、前記設定した鍵配布属性に基づいて前記暗号鍵を取得するか否かを判断し、前記判断の結果に基づいて前記他の通信装置リストからいずれかの通信装置を選択して前記暗号鍵を要求し、前記要求に応じて前記他の通信端末から送信される暗号鍵を前記記憶手段に格納する。鍵配布手段は、前記設定した鍵配布属性に基づいて前記暗号鍵を生成するか否かを判断し、前記判断の結果に基づいて前記暗号鍵を生成し、他の前記通信装置から前記暗号鍵の要求があった場合、前記記憶手段からいずれかの暗号鍵を読み出して前記他の通信端末に配布可能である。
【００４１】
前記第２発明と同様の作用効果を有する。
本願第２２発明は、互いに同一のネットワークを共有して同時に双方向通信が可能な通信装置に用いられる、セキュリティ強化プログラムを記録したコンピュータ読み取り可能な記録媒体であって、下記Ａ〜Ｆ段階を実行させるためのセキュリティ強化プログラムを記録した、コンピュータ読み取り可能な記録媒体を提供する。
・前記通信装置の処理手段が、前記共有されたネットワーク内の通信内容を暗号化及び復号化するための暗号鍵を記憶手段に保持する記憶段階、
・前記処理手段が、通信内容を前記通信装置から取得し、前記暗号鍵を用いて暗号化する暗号化段階、
・前記処理手段が、通信内容を前記通信装置から取得し、前記暗号鍵を用いて復号化する復号化段階、
・前記通信装置が前記いずれかのネットワークに参加している場合に、前記処理手段が、少なくとも前記ネットワークを共有する他の通信装置リストを含む所定の利用者情報を前記通信装置から取得し、他のセキュリティ強化装置に暗号鍵の配布を許可する鍵配布属性を前記取得した利用者情報に基づいて設定し、取得した利用者情報及び設定した鍵配布属性を前記記憶手段に格納する利用者管理段階、
・前記処理手段が、前記設定した鍵配布属性に基づいて前記暗号鍵を取得するか否かを判断し、前記判断の結果に基づいて前記他の通信装置リストからいずれかの通信装置を選択して前記暗号鍵を要求し、前記要求に応じて前記他の通信端末から送信される暗号鍵を前記記憶手段に格納する鍵取得段階、
・前記処理手段が、前記設定した鍵配布属性に基づいて前記暗号鍵を生成するか否かを判断し、前記判断の結果に基づいて前記暗号鍵を生成し、他の前記通信装置から前記暗号鍵の要求があった場合、前記記憶手段からいずれかの暗号鍵を読み出して前記他の通信端末に配布可能な鍵配布段階。
【００４２】
前記第２発明と同様の作用効果を有する。
【００４３】
【発明の実施の形態】
次に、本発明のセキュリティ強化装置について、実施形態例を挙げて具体的に説明する。以下の実施形態例においては、チャットシステムにおける会話内容のセキュリティを高めるために、本発明のセキュリティ強化装置をチャットクライアントとともに用いる場合を例に取り、説明する。
【００４４】
＜第１実施形態例＞
図１に、チャットクライアントと共に用いられるセキュリティ強化装置の機能構成図を示す。図１において、複数のユーザ端末Ａ，Ｂ，Ｃ，Ｄ，Ｅ…は、チャットクライアントが動作可能であり、チャットサーバとコンピュータネットワークを介して接続されている。セキュリティ強化装置１は、チャットクライアントとともに、各ユーザ端末に設けられている。
【００４５】
セキュリティ強化装置１は、記憶部２、ユーザ管理部３、鍵取得部４、鍵配布部５、鍵変更部６、鍵生成部７及び暗号化／復号化部８を有している。チャットクライアント１０には、セキュリティ強化装置１に応じ、ユーザＤＢ９、連携部１１及び振り分け部１２が設けられている。本実施形態例においては、セキュリティ強化装置１及びチャットクライアント１０を有する複数のユーザ端末Ａ〜Ｅ間において、会話を暗号化／復号化するためのチャネル暗号鍵を生成し、配布する。
【００４６】
［セキュリティ強化装置］
記憶部２は、ユーザ自身の公開鍵系秘密鍵及び公開鍵を記憶している。また、記憶部２は、チャットクライアントが参加しているチャネルにおける会話を暗号化／復号化するためのチャネル暗号鍵を、鍵取得部４から受け取り、保持する。さらに、記憶部２は、チャネル暗号鍵を特定する暗号鍵ＩＤを鍵取得部４から受け取り、チャネル暗号鍵と暗号鍵ＩＤとを対応付けて暗号鍵リストに保持する。記憶部２に保持されるチャネル暗号鍵は、１つとは限らず複数でも良い。複数のチャネル暗号鍵が保持される場合には、記憶部２に保持するチャネル暗号鍵の最大数を予め設定またはユーザにより設定可能にしておくと良い。
【００４７】
ユーザ管理部３は、チャットクライアントがチャットサーバから取得するユーザ情報を参照し、参照したユーザ情報に基づいて、鍵配布属性及び鍵変更属性を設定する。図２に、鍵配布属性及び鍵変更属性を含めたユーザ情報の一例を示す。ここで、鍵配布属性とは、チャネル暗号鍵を他のユーザ端末に配布することが許可されていることを示す。また、鍵変更属性とは、チャネル暗号鍵を新たに更新し、他のユーザ端末に配布することが許可されていることを示す。
【００４８】
通常、チャットクライアントは、チャネルに参加することにより所定のユーザ情報をサーバから取得可能である。取得可能なユーザ情報としては、(1)ニックネーム、(2)ユーザの実際の氏名であるReal Name、(3)ネットワーク上でユーザを特定するためのユーザＩＤ、(4)チャットクライアントが動作している利用者端末を特定するクライアント名、(5)利用者端末が接続しているサーバを特定するサーバ名、(6)各ユーザが接続しているチャネルのリスト、(7)最終発言からの経過時間、(8)チャネルオペレータ属性の有無(0/1)などが挙げられる。このうち、少なくともニックネームは、チャネル内のユーザを特定するために必要な情報である。
【００４９】
図２に示したユーザ情報の例では、チャットクライアントは、前記(1)〜(8)のユーザ情報をチャットサーバから取得してユーザＤＢに書き込む。ユーザ管理部３は、チャットクライアントが取得したユーザ情報の中のチャネルオペレータ属性に基づいて鍵配布属性及び鍵変更属性を設定し、ユーザＤＢ９に書き込んでいる。チャネルオペレータ属性が"１"であれば、鍵配布属性及び鍵変更属性もそれぞれ"１"に設定される。また、ユーザ管理部３は、ユーザ情報の変化、例えば新たなチャネルオペレータの設定やユーザの退出を、後述するチャットクライアントの連携部１１を介して通知され、変化に応じてユーザ情報を更新する。
【００５０】
鍵配布属性や鍵変更属性の設定方法は、他にも考えられる。属性の他の設定方法として、ユーザ管理部３により所定の条件に基づいてユーザを選択し、選択したユーザに属性を設定する方法があげられる。鍵配布属性の付与対象の選択方法としては、例えば、乱数を発生させることによりランダムに一定数のユーザを選択したり、チャネルへの所定の参加順位までのユーザを手動であるいは自動的に選択したり、ユーザによる他のユーザの指定を受け付けることにより選択することが挙げられる。
【００５１】
鍵変更属性の付与対象の選択方法としては、例えば、チャネルの開設者を選択したり、チャネルに最後まで参加していたユーザを選択したりすることが挙げられる。また、鍵変更属性を有するユーザにより、例えば、チャネルへの参加順序に応じて一定数のユーザを選択したり、ランダムに一定数のユーザを選択したり、ユーザの手動による他のユーザの指定を受け付けて選択することが挙げられる。
【００５２】
これら選択したユーザに対し、属性を設定する方法の一つとして、属性配布コマンドを新たに設けることが考えられる。例えば、鍵配布属性の設定コマンドを"MODE #CH1 +d userA"、鍵変更属性の設定コマンドを"MODE #CH1 +x userA"とする。但し、ここで#CH1は任意のチャネル名、userAは任意のチャネル内ユーザのニックネームとする。ユーザ管理部３により、選択されたユーザ及び配布する属性を指定して前記コマンドをチャットクライアントに送出することにより、チャネルに参加している全ユーザ端末に前記コマンドが通知される。他のユーザ端末では、チャットクライアントを介してコマンドを受け取ったユーザ管理部３が、コマンドを解釈してユーザ情報の書き換えを行う。
【００５３】
複数のユーザが鍵変更属性を有する場合、ユーザ管理部３によりチャネル暗号鍵を変更する優先順位を併せて設定することが好ましい。例えば、チャネルオペレータ属性に連動させて鍵変更属性を設定する場合は、チャネル開設者の優先順位を第１位とし、他のユーザの優先順位はチャネルに参加した順に設定する。また、鍵変更属性を有するユーザが一人であり、そのユーザから他のユーザに鍵変更属性を付与する場合は、最初に鍵変更属性を有していたユーザの優先順位を第１位とする。そして、ユーザ管理部３により選択されるユーザに対し、チャネルへの参加順序に応じて、ランダムに、または手動による指定を受け付け、優先順位を設定する。
【００５４】
前記優先順位を設定するために、前記属性設定コマンドにより属性と共に優先順位の設定も可能にしておくことが好ましい。例えば、鍵変更属性の設定コマンドにおいて、拡張子"+x"のあとに優先順位を示す自然数"n"を記述することにより、優先順位を設定することが考えられる。例えば、"userA"に第２位の鍵変更属性を設定するコマンドは、"MODE #CH1 +x2 userA"となる。鍵変更属性と共に設定される優先順位は、チャネル内の全てのユーザ端末に通知される。従って、各ユーザ端末のユーザ管理部３は、ユーザ情報の変化、例えばいずれかのユーザが退出することにより鍵変更属性の優先順位に変更が生じると、生じた変化に応じて優先順位を書き換えることが出来る。
【００５５】
鍵取得部４は、所定の条件に基づいて、他のユーザの選択及び選択したユーザへのチャネル暗号鍵の要求を行う。また、要求に応じて送信されてくるチャネル暗号鍵を記憶部２に格納する。チャネル暗号鍵の要求先の選択方法は特に限定されない。例えば、乱数を発生させることによりランダムに一意のユーザを選択したり、鍵配布属性を有するユーザからチャネルに参加した順に選択することが挙げられる。選択したユーザ端末が多忙であったり、通信路が混雑しているなど、何らかの事情により選択したユーザ端末から一定時間経過しても応答がない場合、鍵取得部４は、他のユーザ端末を選択し、再びチャネル暗号鍵の要求を行う。
【００５６】
チャネル暗号鍵の要求は、所定の情報及びユーザ証明書を送信することにより行う。所定の情報とは、チャネル名と、ニックネームなどの要求元ユーザを特定する情報とを最低限含んでいる。ユーザ証明書は、ユーザに関する情報、すなわち証明書本体と、要求元ユーザの公開鍵と、証明者である認証局の電子署名とから構成されている。証明者としては、認証局が一般的ではあるが、他にユーザ端末が接続するサーバや、鍵を要求する先のユーザなどでも良い。
【００５７】
前記チャネル暗号鍵の要求を行うタイミングは、鍵取得部４が通信の暗号化を確認したときである。具体的には、そのチャネル内の通信が全て暗号化されている暗号化モードを確認したとき、または暗号化された会話を受信したときである。前者の場合、チャネル内の全会話を暗号化する暗号化モードの設定コマンドを予め準備しておく。例えば、"MODE #CH1 +c"などのように、"MODE"コマンドの拡張子を用いたコマンドを準備する。通常、チャットクライアントがチャネルに参加すると、そのチャネルに設定されているモードが通知される。鍵取得部４は、このモードをチャットクライアントの連携部１１から取得し、暗号化モードであればチャネル暗号鍵の要求を行う。
【００５８】
後者の場合、会話毎にその会話が暗号化されているか否かを示す暗号化フラグを、各会話と共に送信することが考えられる。通常のチャットシステムにおいては、会話を送信する送信コマンドと会話内容とからなる会話メッセージが作成される。本実施形態例においては、さらに暗号化のオン／オフを示す暗号化フラグ（０／１）を会話内容の先頭部分に記述して会話メッセージを作成する。
【００５９】
また、暗号化フラグに代えて暗号鍵ＩＤを用いることも考えられる。暗号化フラグを会話内容に記述することは、後述するように暗号化／復号化部８が行う。鍵取得部４は、暗号化／復号化部８がチャットクライアントから受け取る会話内容を復号化できない場合、後述する暗号化／復号化部８の指示に従ってチャネル暗号鍵の要求を行う。暗号化／復号化部８が復号化を行えない場合については後述する。
【００６０】
鍵取得部４は、要求元ユーザの公開鍵で暗号化されたチャネル暗号鍵を受信し、これをユーザの秘密鍵で復号化してチャネル暗号鍵を取得する。また、暗号化されたチャネル暗号鍵と共に暗号鍵ＩＤを受信し、取得したチャネル暗号鍵と暗号鍵ＩＤとを記憶部２の暗号鍵リストに格納する。
さらに、鍵取得部４は、ユーザ端末に鍵変更属性がない場合か、鍵変更属性を有していても優先順位が第１位でない場合には、他のユーザ端末から送信される新たなチャネル暗号鍵を取得する。取得した新たなチャネル暗号鍵は直前のチャネル暗号鍵を用いて暗号化されているので、鍵取得部４は、直前のチャネル暗号鍵を記憶部２から取り出し、送信されてきたチャネル暗号鍵を復号化する。また、前記と同様に、復号化したチャネル暗号鍵から暗号鍵ＩＤを求め、チャネル暗号鍵と対応付けて暗号鍵リストに格納する。さらに、鍵取得部４は、チャネル暗号鍵が更新される所定のタイミングを経過しても新たなチャネル暗号鍵を受信しない場合、ユーザ管理部３に対して優先順位の変更の指示を通知する。この通知を受け、ユーザ管理部３により鍵変更属性の優先順位の繰り上げが行われる。チャネル暗号鍵の更新については後述する。
【００６１】
鍵配布部５は、他のユーザ端末から送信されるチャネル暗号鍵の要求を検証する。要求の検証には、チャネル暗号鍵の要求とともに要求元から送信されるユーザ証明書を用いる。検証の結果、要求元が正当なユーザであることを判断すると、最新のチャネル暗号鍵を暗号鍵リストから取り出し、ユーザ証明書に含まれる要求元の公開鍵で暗号化する。鍵配布部５は、前記取り出したチャネル暗号鍵にハッシュ関数などの一方向関数をかけて暗号鍵ＩＤを求め、暗号化したチャネル暗号鍵と暗号鍵ＩＤとを要求元に送信する。暗号鍵ＩＤはチャネル暗号鍵を一義的に特定できればよいので、シリアル番号やチャネル暗号鍵を生成した日付及び時刻などを暗号鍵ＩＤとして用いても良い。また、鍵配布部５は、要求とともに暗号鍵ＩＤが送信された場合は、暗号鍵ＩＤにより指定されるチャネル暗号鍵を送信する。
【００６２】
鍵変更部６は、適当なタイミングでチャネル暗号鍵を新たに生成し、生成したチャネル暗号鍵を他のユーザ端末に送信する。新たにチャネル暗号鍵を生成するタイミングとしては、例えば一定時間経過毎に生成することが挙げられる。また、チャットクライアントにおける会話数や会話のデータ量を監視することにより、ある一定会話数毎に、あるいは一定会話量毎に生成してもよい。さらに、ユーザ情報を監視して、チャネル内ユーザ数が所定数、例えば１になったとき、チャネルのトピックが変化したとき、最後の会話から所定時間経過したとき、ユーザがチャネル暗号鍵の変更を指示する任意の時など、様々なタイミングが考えられる。鍵変更部６は、生成したチャネル暗号鍵をすぐに送信しても良いが、会話が断続的に続いているような状態では送信を見合わせ、会話がとぎれたときに送信を行うようにすると好ましい。
【００６３】
新たなチャネル暗号鍵の生成は、例えばユーザ端末内に保持されている秘密情報、時間情報、チャネル固有情報などの情報を組み合わせ、ハッシュ関数などの一方向関数をかけることにより生成するとよい。ユーザ端末内に保持されている秘密情報とは、端末内の基板の製造番号や、ある特定のプログラムのアドレスなど、第３者が容易に想到しにくい情報が好ましく、さらに時間的に静的情報ではなく変化する情報であればさらに好ましい。
【００６４】
時間情報としては、前記チャネル暗号鍵の生成タイミングにおける時刻データを、時刻データ取得プログラムルーチンを用いて取得する。時刻データ取得プログラムルーチンは、ユーザ端末の内部時計を利用しており、通常ユーザ端末上で動作するオペレーティングシステムにより提供されている。時刻データとしては、時刻データ取得プログラムルーチンが出力する1970年1月1日からの通算秒が一般に用いられる。チャネル固有情報としては、例えばチャネル名やチャネルに設定されているパスワードなどが挙げられる。
【００６５】
生成した新たなチャネル暗号鍵は、そのまま送信するよりも、暗号化して送信する方がセキュリティの観点から好ましい。例えば、１つ前のチャネル暗号鍵を用いて新たなチャネル暗号鍵を暗号化して送信すると、受信側も復号可能である上に盗聴を防止しやすいと考えられる。
前記チャネル暗号鍵の生成及び配布は、ユーザ情報の鍵変更属性に基づいて行うことが好ましい。すなわち、ユーザ情報の鍵変更属性が付与されている場合のみ、前記チャネル暗号鍵を生成し、配布する。鍵変更属性は、前述のように各ユーザ端末においてユーザ管理部３により設定される。鍵変更属性とともに優先順位が設定されている場合は、例えば次のようにしてチャネル暗号鍵の更新を行う。
【００６６】
優先順位が第１位のユーザにおいては、鍵変更部６は前述のように所定のタイミングで新たなチャネル暗号鍵を生成し、他のユーザ端末に送信する。優先順位が第２位以降のユーザにおいては、所定時間経過しても新たなチャネル暗号鍵が送信されてこない場合、第１位のユーザ端末が何らかの事情でチャネル暗号鍵を送信できなかったものと判断する。この判断は、前述のように鍵取得部４で行う。そして、ユーザ管理部３により順次優先順位の繰り上げが行われた結果新たに第１位となったユーザが、チャネル暗号鍵の生成及び配布を行う。
【００６７】
鍵生成部７は、チャットクライアントがチャネル開設者である場合、最初のチャネル暗号鍵を生成する。生成方法は、前記チャネル暗号鍵の更新と同様に、ユーザ端末内の秘密情報、時間情報、チャネル固有情報などの情報を組み合わせ、ハッシュ関数をかけて生成するとよい。時間情報としては、例えばチャネルを開設した時刻のデータを用いるなどが考えられる。また、鍵生成部７は、生成したチャネル暗号鍵にハッシュ関数をかけるなどして前述の鍵配布部５と同様に暗号鍵ＩＤを作成し、チャネル暗号鍵と暗号鍵ＩＤとを対応付けて記憶部２に格納する。
【００６８】
暗号化／復号化部８は、後述するチャットクライアントの振り分け部１２から暗号化された会話内容が送出されることに従い、記憶部２に保持されているチャネル暗号鍵を取り出し、会話内容の復号化を行う。復号化に用いるチャネル暗号鍵には通常は最新のチャネル暗号鍵を用いるが、会話内容の先頭に暗号鍵ＩＤが記述されている場合、暗号鍵ＩＤにより特定されるチャネル暗号鍵を用いて復号化を行う。
【００６９】
また、暗号化／復号化部８は、復号化を行うことができない場合、鍵取得部４に対し鍵要求を行うことを指示する。復号化を行うことができない場合とは、(1)記憶部２にチャネル暗号鍵が保持されていない場合または(2)通知された暗号鍵ＩＤに対応するチャネル暗号鍵が記憶部２に保持されていない場合である。復号化した会話内容は、再びチャットクライアントに送出され、通常のメッセージを受信した場合と同様に画面上に表示される。
【００７０】
さらに、暗号化／復号化部８は、振り分け部１２から会話内容を受け取ると、最新のチャネル暗号鍵を用いて暗号化する。ついで、暗号化した会話内容の先頭部分に暗号化フラグまたは暗号鍵ＩＤを記述し、再びチャットクライアントに送出する。チャットクライアントでは、通常の会話内容と同様に、セキュリティ強化装置１から送出されたデータに送信コマンドを付加し、送信する。
【００７１】
［チャットクライアント］
図１に示すように、本実施形態例におけるチャットクライアント１０には、連携部１１と振り分け部１２とがセキュリティ強化装置１に応じて設けられている。連携部１１は、チャットクライアントが送受信するコマンドを解釈し、セキュリティ強化装置１の各構成要素に処理を振り分ける。具体的には、連携部１１は、ユーザ情報が変化するコマンドを解釈すると、ユーザ情報の変化及びその内容をユーザ管理部３にユーザ管理部３に通知する。前記コマンドとしては、例えばユーザの退出を示すコマンド"PART"、参加を示すコマンド"JOIN"、チャネルオペレータの特権を授与するコマンド"MODE #CH1 +o"、鍵配布属性の設定コマンド"MODE #CH1 +d userA"、鍵変更属性及び優先順位の設定コマンド"MODE #CH1 +xn userA"等が挙げられる。また、逆に、ユーザ管理部３からの鍵配布属性の設定コマンド"MODE #CH1 +d userA"、鍵変更属性及び優先順位の設定コマンド"MODE #CH1 +xn userA"等を受け付け、処理する。
【００７２】
連携部１１は、チャネル暗号鍵の授与を示すコマンドや暗号化モードの設定コマンドを解釈すると、鍵取得部４に対し通知する。また、鍵取得部４からチャネル暗号鍵の取得を要求するコマンドを受け付け、処理する。
連携部１１は、チャネル暗号鍵の要求を示すコマンドを解釈すると、鍵配布部５に対し要求を通知する。また、鍵配布部５からの要求に対してチャネル暗号鍵の授与コマンドを受け付け、処理する。
【００７３】
振り分け部１２は、送信されてきた会話メッセージの先頭部分が暗号化フラグ"１"または暗号鍵ＩＤである場合、復号化の指示を暗号化／復号化部８に通知する。具体的には、暗号化フラグまたは暗号鍵ＩＤと暗号化された会話内容とを暗号化／復号化部８に送出する。
また、振り分け部１２は、利用者からの暗号化の指示及び解除を受け付け、暗号化が指示されている場合には、入力された会話内容を暗号化／復号化部８に送出する。暗号化の指示及び解除は、例えばＧＵＩ(Graphic User Interface)を利用してコマンドボタンを画面上に表示させ、コマンドボタンのオン／オフによりなされるようにすることが出来る。さらに、振り分け部１２は、暗号化／復号化部８により暗号化され、暗号化フラグまたは暗号鍵ＩＤを含む会話内容を、通常の会話内容と同様に処理する。すなわち、暗号化された会話内容は、チャットクライアントにより通常の会話内容と同様に、送信コマンドを付加され、通常のチャットシステムにおける発言として送信される。
【００７４】
［処理の流れ］
次に、セキュリティ強化装置１が行う主な処理の流れを説明する。図３は、セキュリティ強化装置１が行うメインルーチンの処理の流れを示すフローチャートである。図４〜６は、メインルーチンにおいて行われる処理の詳細を示している。図４は、他のユーザ端末から鍵を取得するための鍵取得処理の流れを示すフローチャート、図５は、他のユーザ端末に鍵を配布する鍵配布処理の流れを示すフローチャート、図６は、他のユーザからの鍵の要求を検証する要求検証処理の流れを示すフローチャートである。また、図７は、メインルーチンと独立に行われ、所定の条件に従ってチャネル暗号鍵を変更する場合の鍵変更処理の流れを示すフローチャートである。
【００７５】
（１）メインルーチン
ユーザ端末においてチャットクライアントがチャネルに参加またはチャネルを開設することにより、図３のメインルーチンの処理が開始される。説明を容易にするため、鍵配布属性及び鍵変更属性をチャネルオペレータに連動させて設定する場合を例に取り、説明する。
【００７６】
ステップＳ１では、ユーザ管理部３が、ユーザ情報のチャネルオペレータに連動させて、鍵配布属性及び鍵変更属性を設定する。
ステップＳ２では、ユーザ管理部３は、ユーザがチャネルの開設者か否かを判断する。チャネル内のユーザが１人だけ、すなわちチャネルに参加しているチャットクライアントが自己のチャットクライアントだけであれば、そのユーザはチャネル開設者であるのでステップＳ３に移行する。チャネルの開設者ではなく複数のユーザがチャネル内にいれば、チャネル暗号鍵を取得するためにステップＳ４に移行する。
【００７７】
ステップＳ３では、チャネル開設者のユーザ端末において、鍵生成部７がチャネル暗号鍵を生成する。さらに、生成したチャネル暗号鍵に暗号鍵ＩＤを付し、記憶部２の暗号鍵リストに格納し、ステップＳ５に移行する。
ステップＳ４では、チャネル開設者ではないユーザが、後述する鍵取得サブルーチンにより他のユーザ端末に対してチャネル暗号鍵の要求を行い、チャネル暗号鍵を取得する。
【００７８】
ステップＳ５では、後述する鍵配布サブルーチンにより、鍵配布属性を有するユーザが他のユーザ端末にチャネル暗号鍵を配布する。
ステップＳ６では、当該チャットクライアントがチャネルから退出するか否かを判断し、退出するのであれば処理を終了する。退出しないのであれば、再びステップＳ５に戻り、他のユーザからの要求に応じてチャネル暗号鍵を配布する。
【００７９】
なお、図示していないが、ユーザ管理部３は、メインルーチンとは独立にチャットクライアントからのユーザ情報の変更の通知を受け付け、通知に従って鍵配布属性及び鍵変更属性をを更新している。
（２）鍵取得処理
次に、前記メインルーチンのステップＳ４で行う鍵取得処理について、図４を参照しながら説明する。
【００８０】
まず、ステップＳ１１では、鍵取得部４が、暗号化モードの設定になっているかどうかを判断する。暗号化モードであれば、会話内容は全て暗号化されており、チャネル暗号鍵を取得する必要があるので、後述するステップＳ１３に移行する。暗号化モードでなければステップＳ１２に移行する。
ステップＳ１２では、鍵取得部４は、暗号化／復号化部８から鍵の取得を指示されているか否かを判断する。チャネル暗号鍵を取得していない状態で暗号化フラグが"１"のまたは暗号鍵ＩＤを含む会話メッセージを受信した場合、暗号化／復号化部８は鍵取得部４に対して鍵の取得を指示するからである。ステップＳ１２では、暗号化／復号化部８からの指示を待機し、指示があるとステップＳ１３に移行する。
【００８１】
ステップＳ１３では、鍵取得部４が、他のユーザを選択するための乱数を発生させる。
ステップＳ１４では、鍵取得部４が、発生させた乱数に基づいて、鍵配布属性を有する他のユーザの中からいずれかのユーザを選択する。
ステップＳ１５では、鍵取得部４が、記憶部２からユーザの公開鍵を取り出し、チャネル名及びニックネームにユーザの公開鍵を含むユーザ証明書を添付し、チャネル暗号鍵の要求を送信する。前述のように、鍵取得部４は、暗号鍵ＩＤを含む会話メッセージの受信に応じてチャネル暗号鍵を要求する場合には、暗号鍵ＩＤを指定して要求を送信する。逆に、暗号化モードの通知または暗号化フラグが“１”の会話メッセージの受信に応じて要求を行う場合には、暗号鍵ＩＤを指定せずに要求を送信する。
【００８２】
ステップＳ１６では、鍵取得部４が、チャネル暗号鍵及び暗号鍵ＩＤを受信したか否か判断し、まだであればステップＳ１７に移行する。受信していればステップＳ１８に移行する。
ステップＳ１７では、鍵取得部４が、所定時間Ｔが経過しているか否かを判断し、まだであればステップＳ１６に戻ってチャネル暗号鍵の受信を待機する。所定時間Ｔが経過していれば、鍵取得部４は、選択したユーザが何らかの理由によりチャネル暗号鍵を送信できないものと判断し、他のユーザ端末を再度選択すべくステップＳ１３に戻る。
【００８３】
ステップＳ１８では、鍵取得部４が、受信した暗号鍵をユーザの公開鍵を用いて復号化してチャネル暗号鍵を得、チャネル暗号鍵と共に受信した暗号鍵ＩＤとともに暗号鍵リストに格納し、処理を終了する。
（３）鍵配布処理
次に、前記メインルーチンのステップＳ５で行う鍵配布処理について、図５を参照しながら説明する。
【００８４】
まず、ステップＳ２１では、鍵配布部５が、ユーザ情報を参照し、自己のユーザ端末に鍵配布属性があるか否かを判断する。鍵配布属性がなければ処理を終了し、あればステップＳ２２に移行する。
ステップＳ２２では、鍵配布部５が、他のユーザ端末からのチャネル暗号鍵の要求を受け取ったか否かを判断する。受け取っていればステップＳ２３に移行し、受け取っていなければ、要求を受け取るまで待機する。
【００８５】
ステップＳ２３では、鍵配布部５が、後述する要求検証サブルーチンを実行し、要求の送信元が正当なユーザか否かを検証して検証結果を得る。
ステップＳ２４では、鍵配布部５が、検証結果に基づき要求元ユーザが正当なユーザか否かを判断し、正当でなければステップＳ２５に移行する。正当なユーザであれば、ステップＳ２６に移行する。
【００８６】
ステップＳ２５では、鍵配布部５が、正当でないユーザに対して例えばチャネル暗号鍵を配布できない旨のメッセージを送信するなどの適当な処理を行う。
ステップＳ２６では、要求元が正当なユーザであったので、鍵配布部５は、チャネル暗号鍵の要求とともに送られて来ているユーザ証明書から要求元ユーザの公開鍵を取り出す。
【００８７】
ステップＳ２７では、鍵配布部５が、最新のチャネル暗号鍵を暗号鍵リストから取り出す。要求と共に暗号鍵ＩＤが送信されてきている場合は、暗号鍵ＩＤにより特定されるチャネル暗号鍵を取り出す。また、取り出したチャネル暗号鍵にハッシュ関数をかけて暗号鍵ＩＤを求める。
ステップＳ２８では、鍵配布部５が、前記チャネル暗号鍵を要求元ユーザの公開鍵で暗号化する。
【００８８】
ステップＳ２９では、鍵配布部５が、暗号化されたチャネル暗号鍵及び暗号鍵ＩＤを、チャットクライアントを介して要求元ユーザ端末に送信し、メインルーチンに戻る。
（４）要求検証処理サブルーチン
次に、前記鍵配布サブルーチンのステップＳ２３で行う要求検証処理について、図６を参照しながら説明する。
【００８９】
ステップＳ３１では、鍵配布部５が、チャネル暗号鍵の要求とともに送信されてきたユーザ証明書を取り出す。
ステップＳ３２では、鍵配布部５が、ユーザ証明書の中の認証局の電子署名を取り出す。
ステップＳ３３では、鍵配布部５が、前記取り出した電子署名を、通常ユーザ端末が有する認証局データベースのなかから検索する。
【００９０】
ステップＳ３４では、鍵配布部５が、前記検索の結果に基づいて電子署名が認証局ＤＢに登録されているか否かを判断し、登録されていなければステップＳ３９１に移行する。登録されていればステップＳ３５に移行する。
ステップＳ３５では、鍵配布部５が認証局の公開鍵を認証局ＤＢから取得する。
【００９１】
ステップＳ３６では、鍵配布部５が、前記電子署名を認証局の公開鍵で復号化し、ユーザ証明書のメッセージダイジェスト（ＭＤ）を求める。
ステップＳ３７では、鍵配布部５が、前記ユーザ証明書のうち、前記電子署名の対象となっている部分を取り出し、通常用いられるアルゴリズムを用いてメッセージダイジェスト（ＭＤ'）を計算する。通常用いられるアルゴリズムとしては、例えばＭＤ５やＳＨＡなどが挙げられる。
【００９２】
ステップＳ３８では、鍵配布部５が、２つのメッセージダイジェストを比較し、両者が一致していればステップＳ３９に移行する。一致しなければステップＳ３９１に移行する。
ステップＳ３９では、鍵配布部５が「要求元ユーザは正当である」旨を検証結果とする。
【００９３】
ステップＳ３９１では、鍵配布部５が、要求元ユーザを不当なユーザとして扱い、例えば要求元ユーザに不当である旨の通知を送出する。
（５）鍵変更処理
次に、前記メインルーチンと平行して独立に行われる鍵変更処理について、図７を参照しつつ説明する。
【００９４】
まず、ステップＳ４１では、鍵変更部６が、当該ユーザ端末に鍵変更属性があるか否かを、ユーザ情報を参照して判断する。鍵変更属性がないと判断すると、後述するステップＳ５０に移行する。鍵変更属性があると判断すると、ステップＳ４２に以降する。
ステップＳ４２では、鍵変更部６が、当該ユーザ端末に鍵変更属性とともに付与されている優先順位が第１位か否かを判断する。第１位であればステップＳ４３に移行し、第２位以降であれば後述するステップＳ５０に移行する。
【００９５】
ステップＳ４３では、鍵変更部６が所定のトリガの発生を待機し、所定のトリガが発生すると、ステップＳ４４に移行する。今、説明を分かりやすくするために、チャネル内ユーザが１人になったときまたは所定時間毎に、チャネル暗号鍵を変更するものとする。具体的には、チャネル内ユーザが最後の１人になった場合、またはチャネル内に複数のユーザがいても前回の変更から所定時間が経過している場合に、ステップＳ４４に移行する。
【００９６】
ステップＳ４４では、鍵変更部６が、予め決めておいた規則により暗号鍵を生成する。例えば、ユーザ端末において本プログラムが格納されているアドレス、前記トリガが発生した時刻、チャネル名及びチャネルのパスワードの組合わせにハッシュ関数をかけたものを新たなチャネル暗号鍵とする。また、新たなチャネル暗号鍵にハッシュ関数をかけて暗号鍵ＩＤを求める。
【００９７】
ステップＳ４５では、鍵変更部６が、直前のチャネル暗号鍵を暗号鍵リストから取得する。
ステップＳ４６では、鍵変更部６が、生成した新たな暗号鍵を直前のチャネル暗号鍵で暗号化する。
ステップＳ４７では、鍵変更部６が、暗号化した新たなチャネル暗号鍵の送信を行うか否かを、現在の会話状況に基づいて判断する。例えば、最後の発言から所定時間経過していれば、会話がとぎれていると判断してステップＳ４８に移行する。所定時間経過していなければ、会話が断続的に続いていると判断し、再度ステップＳ４７を繰り返して会話がとぎれるのを待機する。
【００９８】
ステップＳ４８では、鍵変更部６が、暗号化された新たなチャネル暗号鍵及び暗号鍵ＩＤを、チャットクライアントを介して他のユーザ端末に送信する。
ステップＳ４９では、当該ユーザ端末のチャットクライアントがチャネルから退出したか否かを判断し、退出していれば処理を終了する。退出していなければ、再びステップＳ４２に戻り、前記処理を繰り返す。
【００９９】
ステップＳ４１で鍵変更属性がないと判断された場合、または、ステップＳ４２で鍵変更属性の優先順位が第２位以下であると判断された場合、ステップＳ５０に移行して新たなチャネル暗号鍵の取得を行う。
ステップＳ５０では、鍵取得部４が、前回のチャネル暗号鍵の変更から所定時間経過するのを待機し、所定時間が経過するとステップＳ５１に移行する。本実施形態例においては、鍵取得部４は、ユーザ端末内の内部時計を参照することにより、前回のチャネル暗号鍵の変更からの経過時間を監視する。
【０１００】
ステップＳ５１では、鍵取得部４が新たなチャネル暗号鍵を取得したか否かを判断し、まだ取得していなければ鍵取得部４はユーザ管理部３に対して優先順位の繰り上げを通知し、ステップＳ５２に移行する。取得していれば後述するステップＳに移行する。
ステップＳ５２では、前記通知を受けたユーザ管理部３が、鍵変更属性の優先順位が第２位以降のユーザの優先順位を順次繰り上げ、ユーザ情報の書き換えを行う。これにより、書き換え前は第２位以降であったユーザ全ての優先順位が変化する。
【０１０１】
ステップＳ５３では、優先順位の書き換えにより優先順位が第１位になったか否かを鍵変更部６により判断し、第１位であればステップＳ４３に移行して前記チャネル暗号鍵の変更を行う。優先順位が第２位以降であれば、前記ステップＳ５０に移行し、新たなチャネル暗号鍵の取得を行う。
ステップＳ５４では、他のユーザ端末から送信された新たなチャネル暗号鍵を取得したので、鍵取得部４が、暗号化されたチャネル暗号鍵を直前のチャネル暗号鍵を用いて復号化し、新たなチャネル暗号鍵を得る。
【０１０２】
ステップＳ５５では、取得部が、得られたチャネル暗号鍵と暗号鍵ＩＤとを対応付けて暗号鍵リストに格納する。
ステップＳ５６では、当該ユーザ端末のチャットクライアントがチャネルから退出したか否かを判断し、退出していれば処理を終了する。退出していなければ、再びステップＳ４１に戻り、前記処理を繰り返す。
【０１０３】
＜第２実施形態例＞
チャットクライアント間で１対１の会話を行う場合は、会話の開始元の鍵取得部４が、相手先に対して自分の公開鍵を付加してセッション鍵要求を出す。
要求を受けた相手先では、鍵生成部７がセッション鍵を生成し、要求元の公開鍵でセッション鍵を暗号化して要求元に送る。セッション鍵は、前記第１実施形態例と同様、会話の開始元や相手先の固有情報、時刻、クライアントに内蔵される秘密情報の組合せに対し、ハッシュ関数をかけて生成すると良い。
【０１０４】
さらに、前記第１実施形態例と同様、新規セッション鍵は直前のセッション鍵を用いて暗号化して相手先に送ることが好ましい。また送信の際には、新規セッション鍵を相手先の公開鍵で暗号化して送信することが好ましいのも第１実施形態例と同様である。
要求元の鍵取得部４は、ユーザの秘密鍵でセッション鍵を復号化し、記憶部２に格納する。以降、相互にセッション鍵によってメッセージを暗号化して会話を行う。
【０１０５】
セッション鍵の変更のタイミングや条件は、前記第１実施形態例と同様である。すなわち、所定時間が経過したとき、所定会話数を超過したとき、所定会話量を超過したときなどにセッション鍵を変更する。また、セッション鍵の変更は、会話の開始元が行っても、また会話の相手先が行ってもよい。セッション鍵の変更を、前回メッセージを送信した方が行ったり、前回メッセージを受信した方が行ったりしてもよい。
【０１０６】
なお、会話開始の要求を受けた鍵配布部５が、要求に付加されている公開鍵の正当性をチェックし、不当な場合は要求を受け付けないことはいうまでもない。公開鍵は、通常利用者端末に内蔵されている認証局の電子署名が施された公開鍵や、接続中のサーバの電子署名が施された公開鍵や、自らが電子署名した公開鍵を正当として認めることが考えられる。
【０１０７】
＜第３実施形態例＞
前記の第１実施形態例においては、セキュリティ強化装置１に設けたユーザ管理部３により鍵配布属性及び鍵変更属性を設けたが、他の方法も可能である。例えば、チャネルオペレータ属性などと同様に、鍵配布属性及び鍵変更属性をチャットシステム上のユーザ属性として設ける。各チャットクライアントは、ニックネームやチャネルオペレータ属性などと同様に、鍵配布属性及び鍵変更属性をユーザ情報の一部としてチャットサーバから取得し、ユーザＤＢに格納する。セキュリティ強化装置は、ユーザＤＢ内のユーザ情報を参照し、前述の処理を行う。
【０１０８】
＜第４実施形態例＞
前記の第１実施形態例においては、チャネル暗号鍵を変更するタイミングを鍵取得部４により監視しているが、他の形態も考えられる。例えば、鍵生成部７、鍵配布部５及び鍵変更部６は、チャネル暗号鍵と共にチャネル暗号鍵が次に変更される時刻を送信する。各ユーザ端末は、チャネル暗号鍵と共にチャネル暗号鍵の有効期限を持つことになる。各ユーザ端末の鍵取得部４は、チャネル暗号鍵の有効期限をチャネル暗号鍵の変更タイミングとする。チャネル暗号鍵と共にチャネル暗号鍵の有効期限を示す時刻を送信することにより、チャネル暗号鍵の変更を所定時間毎に行うことはもちろん、任意のタイミングで行うことが出来る。
【０１０９】
もっとも、各ユーザ端末において内部時計にずれがある場合も考えられる。そこで、チャネル暗号鍵の有効期限を示す情報として、時刻に代えて相対時間及び起点時刻を用いることが考えられる。起点時刻としては、チャネル暗号鍵が生成された時刻を用い、相対時間としては、生成時刻を起点とした場合に次にチャネル鍵が変更されるまでの時間を用いる。
【０１１０】
また前述のように、時間に基づくのではなく他の変化が生じた場合、例えばチャネル内ユーザが一人になった場合にチャネル暗号鍵の変更を行うこともあり得る。このような設定では、変化の頻度が少なすぎ、チャネル暗号鍵が長時間変更されない場合も考えられる。このような場合を防止する方法として、例えば次のような方法が挙げられる。
【０１１１】
通常、鍵の生成に用いられるアルゴリズムは、鍵に有効期限を持たせている。そこで、鍵生成部７、鍵配布部５及び鍵変更部６により、チャネル暗号鍵と共にその有効期限を各ユーザ端末に送信する。鍵取得部４は、チャネル暗号鍵の有効期限まで所定の変化が生じなかった場合、有効期限をチャネル暗号鍵の変更タイミングとする。
【０１１２】
【発明の効果】
チャットクライアント間でチャネル暗号鍵を分散管理し、クライアント間で公開鍵暗号を利用して鍵の配布を行い、チャネル暗号鍵を共有する。
サーバに無関係に、クライアント間でチャネル暗号鍵を生成し、配布するので、サーバにメッセージ内容が漏洩することなく、チャネル内の会話のセキュリティを高めることが出来る。また、クライアント間で、メッセージの暗号化／復号化が行われるため、クライアント側に負荷が分散され、サーバの負荷を軽減することが出来る。
【図面の簡単な説明】
【図１】第１実施形態例に係るセキュリティ強化装置の機能ブロック図。
【図２】ユーザ情報の一例を示す説明図。
【図３】第１実施形態例に係るセキュリティ強化装置が行う主な処理の流れを示すフローチャート。
【図４】鍵取得処理の流れを示すフローチャート。
【図５】鍵配布処理の流れを示すフローチャート。
【図６】要求検証処理の流れを示すフローチャート。
【図７】鍵変更処理の流れを示すフローチャート。
Claims (22)
- 互いに同一のネットワークを共有して同時に双方向通信が可能な通信装置に用いられ、
前記通信装置の処理手段が、前記共有されたネットワーク内の通信内容を暗号化及び復号化するための暗号鍵を記憶手段に保持する記憶ステップと、
前記処理手段が、通信内容を前記通信装置から取得し、前記暗号鍵を用いて暗号化する暗号化ステップと、
前記処理手段が、通信内容を前記通信装置から取得し、前記暗号鍵を用いて復号化する復号化ステップと、
前記通信装置が前記いずれかのネットワークに参加している場合に、前記処理手段が、少なくとも前記ネットワークを共有する他の通信装置リストを含む所定の利用者情報を前記通信装置から取得し、他のセキュリティ強化装置に暗号鍵の配布を許可する鍵配布属性を前記取得した利用者情報に基づいて設定し、取得した利用者情報及び設定した鍵配布属性を前記記憶手段に格納する利用者管理ステップと、
前記処理手段が、前記設定した鍵配布属性に基づいて前記暗号鍵を取得するか否かを判断し、前記判断の結果に基づいて前記他の通信装置リストからいずれかの通信装置を選択して前記暗号鍵を要求し、前記要求に応じて前記他の通信端末から送信される暗号鍵を前記記憶手段に格納する鍵取得ステップと、
前記処理手段が、前記設定した鍵配布属性に基づいて前記暗号鍵を生成するか否かを判断し、前記判断の結果に基づいて前記暗号鍵を生成し、他の前記通信装置から前記暗号鍵の要求があった場合、前記記憶手段からいずれかの暗号鍵を読み出して前記他の通信端末に配布可能な鍵配布ステップと、
を含むセキュリティ強化方法。 - 他の通信装置と互いに同一のネットワークを共有して同時に双方向通信が可能な通信装置とともに用いられ、
前記共有されたネットワーク内の通信内容を暗号化及び復号化するための暗号鍵を保持する記憶手段と、
通信内容を前記通信装置から取得し、前記暗号鍵を用いて暗号化する暗号化手段と、
通信内容を前記通信装置から取得し、前記暗号鍵を用いて復号化する復号化手段と、
前記通信装置が前記いずれかのネットワークに参加している場合に、少なくとも前記ネットワークを共有する他の通信装置リストを含む所定の利用者情報を前記通信装置から取得し、他のセキュリティ強化装置に暗号鍵の配布を許可する鍵配布属性を、前記取得した利用者情報に基づいて設定し、取得した利用者情報及び設定した鍵配布属性を前記記憶手段に格納する利用者管理手段と、
前記設定した鍵配布属性に基づいて前記暗号鍵を取得するか否かを判断し、前記判断の結果に基づいて前記他の通信装置リストからいずれかの通信装置を選択して前記暗号鍵を要求し、前記要求に応じて前記他の通信端末から送信される暗号鍵を前記記憶手段に格納する鍵取得手段と、
前記設定した鍵配布属性に基づいて前記暗号鍵を生成するか否かを判断し、前記判断の結果に基づいて前記暗号鍵を生成し、他の前記通信装置から前記暗号鍵の要求があった場合、前記記憶手段からいずれかの暗号鍵を読み出して前記他の通信端末に配布可能な鍵配布手段と、
を備えるセキュリティ強化装置。 - 前記通信装置は、前記セキュリティ強化装置との連携手段を有し、
前記連携手段は、前記暗号鍵の要求、前記要求に応じて送信される暗号鍵、前記利用者情報に関する情報及び所定の条件に合致する場合は通信内容の受け渡しを、前記通信装置とセキュリティ強化装置との間で行う、請求項２に記載のセキュリティ強化装置。 - 前記利用者管理手段は、所定の条件に基づいて、他の通信装置を選択し、前記暗号鍵の配布を許可する鍵配布属性を前記他の通信装置に付与し、かつ鍵配布属性の設定及び設定対象の通信装置を前記通信装置から取得し、前記記憶手段に格納する、請求項２に記載のセキュリティ強化装置。
- 前記利用者管理手段は、他の通信装置の選択と、前記暗号鍵の配布を許可する鍵配布属性の前記他の通信装置への付与及び解除の指示とを受け付け、かつ鍵配布属性の設定及び設定対象の通信装置を前記通信装置から取得し、前記記憶手段に格納する、請求項２に記載のセキュリティ強化装置。
- 前記鍵取得手段は、所定の条件に基づいて前記暗号鍵の要求先を選択する、請求項２に記載のセキュリティ強化装置。
- 前記鍵取得手段は、所定の条件に基づいて前記暗号鍵の要求先を選択して前記暗号鍵を要求し、所定時間内に前記要求先から暗号鍵が送信されない場合、他の通信装置を選択して再度要求を行う、請求項２に記載のセキュリティ強化装置。
- 前記鍵取得手段は、前記通信内容が暗号化されている場合に前記暗号鍵の取得要求を行う、請求項２に記載のセキュリティ強化装置。
- 前記復号化手段は、前記通信装置から受け取る通信内容を復号不可能と判断した場合、前記暗号鍵の要求を行うことを決定し、
前記鍵取得手段は、前記復号化手段の決定に従い、前記暗号鍵の取得要求を行う、請求項２に記載のセキュリティ強化装置。 - 前記記憶手段は、複数の暗号鍵と暗号鍵を特定する鍵識別情報とを対応付けて記憶し、
前記暗号化手段は、前記通信内容の暗号化に用いられた暗号鍵を示す鍵識別情報と通信内容とを、前記通信装置を介してネットワークに送出可能であり、
前記復号化手段は、前記鍵識別情報で特定される暗号鍵が前記記憶手段に保持されているか否かを判断し、
前記鍵取得手段は、前記判断結果に従い、前記鍵識別情報を通知して前記暗号鍵の取得要求を行う、請求項２に記載のセキュリティ強化装置。 - 前記鍵取得手段は、利用者の公開鍵暗号系の公開鍵を前記暗号鍵の要求とともに通知し、前記要求に応じて送信される暗号鍵を利用者の秘密鍵を用いて復号化し、
前記鍵配布手段は、前記要求元の公開鍵暗号系の公開鍵を用いて暗号化した前記暗号鍵を配布する、
請求項２に記載のセキュリティ強化装置。 - 前記鍵配布手段は、他の前記通信装置から前記暗号鍵の要求があった場合、前記要求を検証し、検証結果に基づいて前記記憶手段からいずれかの暗号鍵を読み出し、前記他の通信端末に配布可能である、請求項２に記載のセキュリティ強化装置。
- 所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備える、請求項２に記載のセキュリティ強化装置。
- 所定のタイミングで前記暗号鍵を更新し、前記更新した暗号鍵を直前の暗号鍵を用いて暗号化して他の通信装置に配布する鍵変更手段をさらに備える、請求項２に記載のセキュリティ強化装置。
- 前記鍵変更手段は、前記各通信装置内に保持される秘密情報、時間情報及びネットワークに固有の情報のいずれかまたは全ての組合せに基づいて前記暗号鍵を生成する、請求項２に記載のセキュリティ強化装置。
- 前記鍵変更手段は、前記各通信装置内に保持される秘密情報、時間情報及びネットワークに固有の情報のいずれかの組合せまたは全てを、一方向関数で暗号化して前記暗号鍵を生成する、請求項２に記載のセキュリティ強化装置。
- 前記利用者管理手段は、前記暗号鍵の更新及び配布を許可する鍵変更属性を、前記取得した利用者情報に基づいて設定して前記記憶手段に格納し、
前記鍵変更属性の有無に基づいて、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備える、請求項２に記載のセキュリティ強化装置。 - 前記利用者管理手段は、
利用者が前記暗号鍵の更新及び配布を許可する鍵変更属性を有する場合に、所定の条件に基づいて他の通信装置を選択し、前記選択した通信装置に前記鍵変更属性を設定可能であり、
かつ鍵変更属性の設定及び設定対象の通信装置を前記通信装置から取得して前記記憶手段に格納し、
前記鍵変更属性の有無に基づいて、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備える、
請求項２に記載のセキュリティ強化装置。 - 前記利用者管理手段は、前記暗号鍵の更新及び配布を許可する鍵変更属性及び優先順位を、前記取得した利用者情報に基づいて設定して前記記憶手段に格納し、前記利用者情報の変化に従って前記優先順位の書き換えを行い、
前記鍵変更属性及び優先順位に基づいて、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備える、請求項２に記載のセキュリティ強化装置。 - 前記利用者管理手段は、
利用者が前記暗号鍵の更新及び配布を許可する鍵変更属性を有する場合に、所定の条件に基づいて他の通信装置を選択し、前記他の通信装置に前記鍵変更属性と優先順位とを設定可能であり、
かつ鍵変更属性と優先順位との設定及び設定対象の通信装置を前記通信装置から取得して前記記憶手段に格納し、前記利用者情報の変化に従って前記優先順位の書き換えを行い、
前記鍵変更属性及び優先順位に基づいて、所定のタイミングで前記暗号鍵を更新し、他の通信装置に配布する鍵変更手段をさらに備える、
請求項２に記載のセキュリティ強化装置。 - 互いに同一のネットワークを共有して同時に双方向通信が可能な複数の通信装置から構成され、
前記各通信装置は、
前記共有されたネットワーク内の通信内容を暗号化及び復号化するための暗号鍵を保持する記憶手段と、
通信内容を前記暗号鍵を用いて暗号化する暗号化手段と、
通信内容を前記暗号鍵を用いて復号化する復号化手段と、
前記いずれかのネットワークに参加している場合に、少なくとも前記ネットワークを共有する他の通信装置リストを含む所定の利用者情報を取得し、他のセキュリティ強化装置に暗号鍵の配布を許可する鍵配布属性を、前記取得した利用者情報に基づいて設定し、取得した利用者情報及び設定した鍵配布属性を前記記憶手段に格納する利用者管理手段と、
前記設定した鍵配布属性に基づいて前記暗号鍵を取得するか否かを判断し、前記判断の結果に基づいて前記他の通信装置リストからいずれかの通信装置を選択して前記暗号鍵を要求し、前記要求に応じて前記他の通信端末から送信される暗号鍵を前記記憶手段に格納する鍵取得手段と、
前記設定した鍵配布属性に基づいて前記暗号鍵を生成するか否かを判断し、前記判断の結果に基づいて前記暗号鍵を生成し、他の前記通信装置から前記暗号鍵の要求があった場合、前記記憶手段からいずれかの暗号鍵を読み出して前記他の通信端末に配布可能な鍵配布手段と、
を備えるセキュリティ強化システム。 - 互いに同一のネットワークを共有して同時に双方向通信が可能な通信装置に用いられる、セキュリティ強化プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記通信装置の処理手段が、前記共有されたネットワーク内の通信内容を暗号化及び復号化するための暗号鍵を記憶手段に保持する記憶段階と、
前記処理手段が、通信内容を前記通信装置から取得し、前記暗号鍵を用いて暗号化する暗号化段階と、
前記処理手段が、通信内容を前記通信装置から取得し、前記暗号鍵を用いて復号化する復号化段階と、
前記通信装置が前記いずれかのネットワークに参加している場合に、前記処理手段が、少なくとも前記ネットワークを共有する他の通信装置リストを含む所定の利用者情報を前記通信装置から取得し、他のセキュリティ強化装置に暗号鍵の配布を許可する鍵配布属性を前記取得した利用者情報に基づいて設定し、取得した利用者情報及び設定した鍵配布属性を前記記憶手段に格納する利用者管理段階と、
前記処理手段が、前記設定した鍵配布属性に基づいて前記暗号鍵を取得するか否かを判断し、前記判断の結果に基づいて前記他の通信装置リストからいずれかの通信装置を選択して前記暗号鍵を要求し、前記要求に応じて前記他の通信端末から送信される暗号鍵を前記記憶手段に格納する鍵取得段階と、
前記処理手段が、前記設定した鍵配布属性に基づいて前記暗号鍵を生成するか否かを判断し、前記判断の結果に基づいて前記暗号鍵を生成し、他の前記通信装置から前記暗号鍵の要求があった場合、前記記憶手段からいずれかの暗号鍵を読み出して前記他の通信端末に配布可能な鍵配布段階と、
を実行させるための、セキュリティ強化プログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP30800798A JP3644579B2 (ja) | 1998-10-29 | 1998-10-29 | セキュリティ強化方法及び装置 |
| US09/414,502 US6711264B1 (en) | 1998-10-29 | 1999-10-08 | Security improvement method and security system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP30800798A JP3644579B2 (ja) | 1998-10-29 | 1998-10-29 | セキュリティ強化方法及び装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000134193A JP2000134193A (ja) | 2000-05-12 |
| JP3644579B2 true JP3644579B2 (ja) | 2005-04-27 |
Family
ID=17975777
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP30800798A Expired - Fee Related JP3644579B2 (ja) | 1998-10-29 | 1998-10-29 | セキュリティ強化方法及び装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6711264B1 (ja) |
| JP (1) | JP3644579B2 (ja) |
Families Citing this family (104)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6272223B1 (en) | 1997-10-28 | 2001-08-07 | Rolf Carlson | System for supplying screened random numbers for use in recreational gaming in a casino or over the internet |
| US7690043B2 (en) | 1994-12-19 | 2010-03-30 | Legal Igaming, Inc. | System and method for connecting gaming devices to a network for remote play |
| US7260834B1 (en) * | 1999-10-26 | 2007-08-21 | Legal Igaming, Inc. | Cryptography and certificate authorities in gaming machines |
| JP2000244655A (ja) * | 1999-02-18 | 2000-09-08 | Fujitsu Ltd | 秘匿サービス機能を有するネットワークシステム |
| JP3570311B2 (ja) * | 1999-10-07 | 2004-09-29 | 日本電気株式会社 | 無線ｌａｎの暗号鍵更新システム及びその更新方法 |
| US7765581B1 (en) | 1999-12-10 | 2010-07-27 | Oracle America, Inc. | System and method for enabling scalable security in a virtual private network |
| US7089211B1 (en) * | 2000-01-12 | 2006-08-08 | Cisco Technology, Inc. | Directory enabled secure multicast group communications |
| US6839437B1 (en) * | 2000-01-31 | 2005-01-04 | International Business Machines Corporation | Method and apparatus for managing keys for cryptographic operations |
| US7493486B1 (en) * | 2000-06-09 | 2009-02-17 | Verizon Laboratories, Inc. | Method and apparatus for supporting cryptographic-related activities in a public key infrastructure |
| US7159008B1 (en) * | 2000-06-30 | 2007-01-02 | Immersion Corporation | Chat interface with haptic feedback functionality |
| US20020143869A1 (en) * | 2001-01-03 | 2002-10-03 | Hal Cohen | Method and apparatus for making random introductions electronically |
| US7308477B1 (en) * | 2001-01-10 | 2007-12-11 | Cisco Technology, Inc. | Unified messaging system configured for transport of encrypted messages |
| US20020114453A1 (en) * | 2001-02-21 | 2002-08-22 | Bartholet Thomas G. | System and method for secure cryptographic data transport and storage |
| US7301968B2 (en) * | 2001-03-02 | 2007-11-27 | Pmc-Sierra Israel Ltd. | Communication protocol for passive optical network topologies |
| GB0107215D0 (en) * | 2001-03-22 | 2001-05-16 | Wraptech Ltd | Distribution system amd method of operation thereof |
| US8121296B2 (en) | 2001-03-28 | 2012-02-21 | Qualcomm Incorporated | Method and apparatus for security in a data processing system |
| US8077679B2 (en) | 2001-03-28 | 2011-12-13 | Qualcomm Incorporated | Method and apparatus for providing protocol options in a wireless communication system |
| US20020154635A1 (en) * | 2001-04-23 | 2002-10-24 | Sun Microsystems, Inc. | System and method for extending private networks onto public infrastructure using supernets |
| JP2003015993A (ja) * | 2001-06-28 | 2003-01-17 | Sony Corp | 情報処理装置および情報処理方法、記録媒体、並びにプログラム |
| US7185362B2 (en) * | 2001-08-20 | 2007-02-27 | Qualcomm, Incorporated | Method and apparatus for security in a data processing system |
| JP5008233B2 (ja) * | 2001-08-24 | 2012-08-22 | 京セラ株式会社 | 携帯電話装置 |
| US20030046534A1 (en) * | 2001-08-31 | 2003-03-06 | Alldredge Robert L. | Method and apparatus for secured electronic commerce |
| US7352868B2 (en) | 2001-10-09 | 2008-04-01 | Philip Hawkes | Method and apparatus for security in a data processing system |
| US7649829B2 (en) | 2001-10-12 | 2010-01-19 | Qualcomm Incorporated | Method and system for reduction of decoding complexity in a communication system |
| JP2004007567A (ja) * | 2002-04-17 | 2004-01-08 | Toshiba Corp | 通信装置、通信方法及び通信プログラム |
| US7590844B1 (en) * | 2002-04-26 | 2009-09-15 | Mcafee, Inc. | Decryption system and method for network analyzers and security programs |
| US20030206637A1 (en) * | 2002-05-03 | 2003-11-06 | Germano Caronni | Mechanism and method to achieve group-wise perfect backward secrecy |
| US20030223586A1 (en) * | 2002-05-30 | 2003-12-04 | Edward Green | Method and system for secure communications over a communications network |
| DE60208909T2 (de) * | 2002-06-26 | 2006-09-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Verfahren zur steuerung einer netzwerkeinheit und einer mobilstation |
| US9865126B2 (en) | 2002-10-09 | 2018-01-09 | Zynga Inc. | System and method for connecting gaming devices to a network for remote play |
| US20060155981A1 (en) * | 2002-12-25 | 2006-07-13 | Mizutanai Mika, Kamimaki Hideki, Ebina Akihiro | Network device, network system and group management method |
| US7599655B2 (en) | 2003-01-02 | 2009-10-06 | Qualcomm Incorporated | Method and apparatus for broadcast services in a communication system |
| US7835520B2 (en) * | 2003-02-20 | 2010-11-16 | Zoran Corporation | Unique identifier per chip for digital audio/video data encryption/decryption in personal video recorders |
| JP2004302667A (ja) * | 2003-03-28 | 2004-10-28 | Fujitsu Ltd | チャットログ記録方法、およびチャットログ記録プログラム |
| US8027844B2 (en) * | 2003-05-12 | 2011-09-27 | Pitney Bowes Inc. | System and method for processing mail |
| JP4557506B2 (ja) * | 2003-05-28 | 2010-10-06 | シャープ株式会社 | 情報処理装置 |
| US8098818B2 (en) | 2003-07-07 | 2012-01-17 | Qualcomm Incorporated | Secure registration for a multicast-broadcast-multimedia system (MBMS) |
| US8718279B2 (en) | 2003-07-08 | 2014-05-06 | Qualcomm Incorporated | Apparatus and method for a secure broadcast system |
| US8724803B2 (en) | 2003-09-02 | 2014-05-13 | Qualcomm Incorporated | Method and apparatus for providing authenticated challenges for broadcast-multicast communications in a communication system |
| US7900250B1 (en) * | 2003-09-12 | 2011-03-01 | Nortel Networks Limited | Method of providing secure groups using a combination of group and pair-wise keying |
| JP2005136870A (ja) * | 2003-10-31 | 2005-05-26 | Toshiba Corp | 電子機器および暗号鍵更新制御方法 |
| US20060210080A1 (en) * | 2003-11-17 | 2006-09-21 | Koninklijke Philips Electronics N.V. | Key synchronization in a visual cryptographic system |
| US7644278B2 (en) * | 2003-12-31 | 2010-01-05 | International Business Machines Corporation | Method for securely creating an endorsement certificate in an insecure environment |
| US8495361B2 (en) * | 2003-12-31 | 2013-07-23 | International Business Machines Corporation | Securely creating an endorsement certificate in an insecure environment |
| CN1906885A (zh) * | 2004-04-28 | 2007-01-31 | 松下电器产业株式会社 | 通信系统、通用密钥控制装置及一般通信装置 |
| JP4645084B2 (ja) * | 2004-07-13 | 2011-03-09 | 富士ゼロックス株式会社 | データ管理システム、データ管理方法及びそのためのプログラム |
| WO2006022006A1 (ja) | 2004-08-26 | 2006-03-02 | Fujitsu Limited | コンテンツ管理プログラム、方法及び装置 |
| JP2006092242A (ja) * | 2004-09-24 | 2006-04-06 | Fuji Xerox Co Ltd | 遠隔会議システム、拠点サーバ、管理サーバ、遠隔会議管理方法及びプログラム |
| EP3468175A1 (en) * | 2004-10-15 | 2019-04-10 | OpenTV, Inc. | Speeding up channel change |
| US20070234395A1 (en) * | 2004-10-15 | 2007-10-04 | Vincent Dureau | Speeding up channel change |
| KR100677152B1 (ko) * | 2004-11-17 | 2007-02-02 | 삼성전자주식회사 | 사용자 바인딩을 이용한 홈 네트워크에서의 콘텐츠 전송방법 |
| US7899189B2 (en) * | 2004-12-09 | 2011-03-01 | International Business Machines Corporation | Apparatus, system, and method for transparent end-to-end security of storage data in a client-server environment |
| US8316416B2 (en) | 2005-04-04 | 2012-11-20 | Research In Motion Limited | Securely using a display to exchange information |
| US9143323B2 (en) * | 2005-04-04 | 2015-09-22 | Blackberry Limited | Securing a link between two devices |
| US7693280B2 (en) * | 2005-04-22 | 2010-04-06 | Microsoft Corporation | Rights management system for streamed multimedia content |
| US7684566B2 (en) | 2005-05-27 | 2010-03-23 | Microsoft Corporation | Encryption scheme for streamed multimedia content protected by rights management system |
| JP4350682B2 (ja) * | 2005-06-15 | 2009-10-21 | キヤノン株式会社 | 監視装置 |
| US8321690B2 (en) | 2005-08-11 | 2012-11-27 | Microsoft Corporation | Protecting digital media of various content types |
| WO2007059378A2 (en) * | 2005-11-10 | 2007-05-24 | Motorola Inc. | A method for managing security keys utilized by media devices in a local area network |
| US7694147B2 (en) * | 2006-01-03 | 2010-04-06 | International Business Machines Corporation | Hashing method and system |
| JP4877932B2 (ja) * | 2006-03-30 | 2012-02-15 | 富士通テレコムネットワークス株式会社 | 暗号化通信システム及び暗号鍵更新方法 |
| US8670566B2 (en) * | 2006-05-12 | 2014-03-11 | Blackberry Limited | System and method for exchanging encryption keys between a mobile device and a peripheral output device |
| US20080132222A1 (en) * | 2006-11-30 | 2008-06-05 | Brady Colin P | Wireless communication using a picocell station having its own phone number |
| JP5164372B2 (ja) * | 2006-12-15 | 2013-03-21 | 株式会社エルイーテック | 遊技機制御用チップ及びそのｒｏｍライタ |
| AU2008255030B2 (en) | 2007-05-15 | 2014-02-20 | Schneider Electric It Corporation | Methods and systems for managing facility power and cooling |
| US8315652B2 (en) * | 2007-05-18 | 2012-11-20 | Immersion Corporation | Haptically enabled messaging |
| GB2451505A (en) * | 2007-08-01 | 2009-02-04 | Iti Scotland Ltd | Key distribution in a network using key shares in a secret sharing scheme |
| JP5139028B2 (ja) * | 2007-10-24 | 2013-02-06 | エイチジーエスティーネザーランドビーブイ | コンテンツデータ管理システム及び方法 |
| US9003186B2 (en) * | 2008-07-24 | 2015-04-07 | Zscaler, Inc. | HTTP authentication and authorization management |
| US8806201B2 (en) * | 2008-07-24 | 2014-08-12 | Zscaler, Inc. | HTTP authentication and authorization management |
| US8656462B2 (en) * | 2008-07-24 | 2014-02-18 | Zscaler, Inc. | HTTP authentication and authorization management |
| US9379895B2 (en) | 2008-07-24 | 2016-06-28 | Zscaler, Inc. | HTTP authentication and authorization management |
| JP5077186B2 (ja) * | 2008-10-17 | 2012-11-21 | 富士通株式会社 | 通信装置、通信方法及び通信プログラム |
| US9203873B2 (en) | 2008-12-17 | 2015-12-01 | Telefonaktiebolaget L M Ericsson (Publ) | Method of and a network server and mobile user equipment for providing chat/VoIP services in a mobile telecommunications network |
| JP2011004385A (ja) * | 2009-03-16 | 2011-01-06 | Ricoh Co Ltd | 情報処理装置、相互認証方法、相互認証プログラム、情報処理システム、情報処理方法、情報処理プログラム及び記録媒体 |
| US9444620B1 (en) * | 2010-06-24 | 2016-09-13 | F5 Networks, Inc. | Methods for binding a session identifier to machine-specific identifiers and systems thereof |
| US8913746B2 (en) * | 2010-12-22 | 2014-12-16 | Schneider Electric It Corporation | Wireless communication system and method |
| EP2795489A4 (en) | 2011-12-22 | 2016-06-01 | Schneider Electric It Corp | ANALYSIS OF THE IMPACT OF TRANSITION EVENTS ON THE TEMPERATURE IN A DATA CENTER |
| US9830410B2 (en) | 2011-12-22 | 2017-11-28 | Schneider Electric It Corporation | System and method for prediction of temperature values in an electronics system |
| WO2013126266A1 (en) * | 2012-02-23 | 2013-08-29 | Mastercard International Incorporated | Selectively providing cash-based e-commerce transactions |
| US20140366091A1 (en) * | 2013-06-07 | 2014-12-11 | Amx, Llc | Customized information setup, access and sharing during a live conference |
| JP2014161043A (ja) * | 2014-04-01 | 2014-09-04 | Thomson Licensing | マルチメディア・アクセス・デバイスの登録システム及び方法 |
| KR102428374B1 (ko) * | 2014-04-25 | 2022-08-03 | 삼성전자주식회사 | 소셜 네트워크 서비스의 제공 방법 및 그를 위한 서버 |
| US9781123B2 (en) | 2014-04-25 | 2017-10-03 | Samsung Electronics Co., Ltd. | Methods of providing social network service and server performing the same |
| JP6368531B2 (ja) * | 2014-04-28 | 2018-08-01 | 達広 白井 | 暗号処理装置、暗号処理システム、および暗号処理方法 |
| JP2015216413A (ja) * | 2014-05-07 | 2015-12-03 | 日本電気株式会社 | 端末、サーバ、暗号通信システムおよび暗号通信方法 |
| KR101594846B1 (ko) * | 2014-12-03 | 2016-02-22 | 조선대학교산학협력단 | 가변 암호화 기반의 네트워크 보안 장치 및 그 동작 방법 |
| US11063758B1 (en) | 2016-11-01 | 2021-07-13 | F5 Networks, Inc. | Methods for facilitating cipher selection and devices thereof |
| US10833870B2 (en) | 2017-01-06 | 2020-11-10 | Microsoft Technology Licensing, Llc | Cryptographic operations in an isolated collection |
| WO2019026776A1 (ja) * | 2017-08-02 | 2019-02-07 | 日本電信電話株式会社 | 暗号化通信装置、暗号化通信システム、暗号化通信方法、およびプログラム |
| US11068511B2 (en) * | 2018-03-27 | 2021-07-20 | International Business Machines Corporation | Aggregate relationship graph |
| JP2020030527A (ja) * | 2018-08-21 | 2020-02-27 | キオクシア株式会社 | 記憶装置及びプログラム |
| US10439825B1 (en) * | 2018-11-13 | 2019-10-08 | INTEGRITY Security Services, Inc. | Providing quality of service for certificate management systems |
| US11133932B2 (en) * | 2018-12-20 | 2021-09-28 | Sony Interactive Entertainment LLC | Secure data channel in a networked gaming system |
| EP3909275A1 (en) * | 2019-01-11 | 2021-11-17 | NEC Corporation | A method and a device for enabling key re-usage in a communication network |
| US11595204B2 (en) * | 2019-06-04 | 2023-02-28 | EMC IP Holding Company LLC | Adaptive re-keying in a storage system |
| WO2020255575A1 (ja) * | 2019-06-19 | 2020-12-24 | ソニー株式会社 | 暗号鍵生成装置、暗号鍵生成方法 |
| US11343098B2 (en) * | 2019-07-22 | 2022-05-24 | Whitestar Communications, Inc. | Systems and methods of securing digital conversations for its life cycle at source, during transit and at destination |
| CN111147444B (zh) * | 2019-11-20 | 2021-08-06 | 维沃移动通信有限公司 | 一种交互方法及电子设备 |
| US12088571B2 (en) * | 2020-09-04 | 2024-09-10 | CACI, Inc.—Federal | System and methods of determining and managing probes in a multi-hop network |
| EP4416892A1 (en) * | 2021-10-12 | 2024-08-21 | Telefonaktiebolaget LM Ericsson (publ) | Prioritized rekeying of security associations |
| CN114302178A (zh) * | 2021-12-27 | 2022-04-08 | 上海哔哩哔哩科技有限公司 | 形象模型文件传输方法及装置 |
| US12307234B2 (en) | 2022-10-11 | 2025-05-20 | Ford Global Technologies, Llc | Transmission of authentication keys |
| US12418795B2 (en) | 2022-11-01 | 2025-09-16 | Ford Global Technologies, Llc | Transmission of authentication keys |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4965804A (en) * | 1989-02-03 | 1990-10-23 | Racal Data Communications Inc. | Key management for encrypted packet based networks |
| US5434920A (en) * | 1991-12-09 | 1995-07-18 | At&T Corp. | Secure telecommunications |
| JPH0637750A (ja) * | 1992-07-20 | 1994-02-10 | Hitachi Ltd | 情報転送方式 |
| JPH06237249A (ja) * | 1992-12-18 | 1994-08-23 | Kawasaki Steel Corp | ネットワーク管理のセキュリティシステム |
| JPH06303231A (ja) * | 1993-04-14 | 1994-10-28 | Panpukin House:Kk | 鍵配送装置 |
| JPH0774743A (ja) * | 1993-08-31 | 1995-03-17 | Oki Electric Ind Co Ltd | 多地点間接続方法 |
| US5513261A (en) * | 1993-12-29 | 1996-04-30 | At&T Corp. | Key management scheme for use with electronic cards |
| US5452358A (en) * | 1994-02-08 | 1995-09-19 | Apple Computer, Inc. | Method and apparatus for improving the security of an electronic codebook encryption scheme utilizing a data dependent encryption function |
| JPH0954741A (ja) * | 1995-08-11 | 1997-02-25 | Toshiba Corp | ネットワークシステム及びそのセッション管理方法 |
| JPH09321748A (ja) | 1996-05-27 | 1997-12-12 | Trans Kosumosu Kk | 共有暗号鍵による通信システム、同システム用サーバ装置、同システム用クライアント装置、及び通信システムにおける暗号鍵の共有方法 |
| JPH1051438A (ja) * | 1996-07-30 | 1998-02-20 | Matsushita Electric Works Ltd | 暗号通信システム |
| JP3471558B2 (ja) * | 1997-04-11 | 2003-12-02 | 日本電気株式会社 | 計算機を利用した会議システム |
| US6105131A (en) * | 1997-06-13 | 2000-08-15 | International Business Machines Corporation | Secure server and method of operation for a distributed information system |
| US6263437B1 (en) * | 1998-02-19 | 2001-07-17 | Openware Systems Inc | Method and apparatus for conducting crypto-ignition processes between thin client devices and server devices over data networks |
| US6157722A (en) * | 1998-03-23 | 2000-12-05 | Interlok Technologies, Llc | Encryption key management system and method |
| US6445794B1 (en) * | 1998-06-24 | 2002-09-03 | Benyamin Ron | System and method for synchronizing one time pad encryption keys for secure communication and access control |
| US6385730B2 (en) * | 1998-09-03 | 2002-05-07 | Fiware, Inc. | System and method for restricting unauthorized access to a database |
| US6189100B1 (en) * | 1998-06-30 | 2001-02-13 | Microsoft Corporation | Ensuring the integrity of remote boot client data |
| US6151677A (en) * | 1998-10-06 | 2000-11-21 | L-3 Communications Corporation | Programmable telecommunications security module for key encryption adaptable for tokenless use |
-
1998
- 1998-10-29 JP JP30800798A patent/JP3644579B2/ja not_active Expired - Fee Related
-
1999
- 1999-10-08 US US09/414,502 patent/US6711264B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000134193A (ja) | 2000-05-12 |
| US6711264B1 (en) | 2004-03-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3644579B2 (ja) | セキュリティ強化方法及び装置 | |
| KR100821435B1 (ko) | 암호 통신 시스템, 통신 상태 관리 서버, 암호 통신 방법및 통신 상태 관리 방법 | |
| US6260142B1 (en) | Access and storage of secure group communication cryptographic keys | |
| US7076654B2 (en) | Multicast system, authentication server terminal, multicast receiver terminal controlling method, and storage medium | |
| US6651166B1 (en) | Sender driven certification enrollment system | |
| US6742116B1 (en) | Security method, security software and security system for electronic communications | |
| US8925059B2 (en) | Dynamic trust connection | |
| KR100610317B1 (ko) | 홈 네트워크를 구성하는 기기들에 대한 인증 장치 및 방법 | |
| US7957320B2 (en) | Method for changing a group key in a group of network elements in a network system | |
| US20020154782A1 (en) | System and method for key distribution to maintain secure communication | |
| US7965846B2 (en) | Client distributed system and inter-client RTP encrypting method | |
| GB2436668A (en) | Corporate LAN with key server that stores copies of user's private keys to allow network manager to check for viruses/spam in encrypted emails | |
| US20080028204A1 (en) | Client server distributed system, client apparatus, server apparatus, and message encryption method used therefor | |
| TW200423631A (en) | Network connection system | |
| CN111683072A (zh) | 一种远程验证方法和远程验证系统 | |
| JP2001251297A (ja) | 情報処理装置、該情報処理装置を具備する暗号通信システム及び暗号通信方法 | |
| US20030007645A1 (en) | Method and system for allowing a sender to send an encrypted message to a recipient from any data terminal | |
| US8453247B2 (en) | Apparatus, system and method for providing security service in home network | |
| KR101241864B1 (ko) | 사용자 중심의 아이덴터티 관리 시스템 및 그 방법 | |
| US11265298B2 (en) | Method for end-to-end transmission of a piece of encrypted digital information, application of this method and object implementing this method | |
| JP2003244123A (ja) | 共通鍵管理システム、共通鍵管理サーバ、共通鍵管理方法、及び共通鍵管理プログラム | |
| CN118041635A (zh) | 数据加密方法、装置、设备、存储介质及计算机产品 | |
| JP2004242210A (ja) | マルチキャスト配信システム及びその方法並びにデータ中継装置、クライアント装置、認証・鍵管理装置 | |
| JP2001111606A (ja) | 通信制御装置及び記録媒体 | |
| JP2003069561A (ja) | 利用者認証システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040903 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040928 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041129 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050125 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050127 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080210 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090210 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090210 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100210 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110210 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110210 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120210 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130210 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130210 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140210 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |