JP2005284915A - 情報検索装置および方法、ならびに情報検索システムおよびその制御方法 - Google Patents
情報検索装置および方法、ならびに情報検索システムおよびその制御方法 Download PDFInfo
- Publication number
- JP2005284915A JP2005284915A JP2004100398A JP2004100398A JP2005284915A JP 2005284915 A JP2005284915 A JP 2005284915A JP 2004100398 A JP2004100398 A JP 2004100398A JP 2004100398 A JP2004100398 A JP 2004100398A JP 2005284915 A JP2005284915 A JP 2005284915A
- Authority
- JP
- Japan
- Prior art keywords
- document data
- search
- server
- encrypted
- key
- 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.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】 コンピュータに保存される情報の機密性を確保しつつ高速な情報検索が可能な情報検索システムおよび方法を提供する。
【解決手段】 マークアップ言語で書かれた文書データは、その所定部分が所定の鍵を用いて暗号化され(802)、データベース(804)に登録される。検索文字列が入力されると、その検索文字列が上記所定の鍵を用いて暗号化され(807)、この暗号化された検索文字列を含む文書データが、データベース(804)から検索される(803)。
【選択図】 図8
【解決手段】 マークアップ言語で書かれた文書データは、その所定部分が所定の鍵を用いて暗号化され(802)、データベース(804)に登録される。検索文字列が入力されると、その検索文字列が上記所定の鍵を用いて暗号化され(807)、この暗号化された検索文字列を含む文書データが、データベース(804)から検索される(803)。
【選択図】 図8
Description
本発明は、情報検索の技術に関し、特に、暗号化された情報の検索を行う技術に関する。
デジタルコンテンツの暗号化方式として、図14に示すように、送信者と受信者で同一の暗号鍵を秘密に共有する共通鍵暗号方式(秘密鍵暗号方式、対称暗号方式、慣用暗号方式とも呼ばれる)がある。共通鍵暗号方式は適当な長さの文字列(ブロック)ごとに同じ鍵で暗号化するブロック暗号と文字列またはビットごとに鍵を変えていくストリーム暗号に分けることができる。ブロック暗号としてはDES(Data Encryption Standard)やAES(Advanced Encryption Standard)などが良く知られている。ストリーム暗号には多表を用いるビジネル暗号や1回限りの使い捨ての鍵を用いるバーナム暗号等が知られている。画像データ全体の暗号化による著作権保護は上記の共通鍵暗号方式のうちのいずれかを用いることにより容易に実現できる。共通鍵暗号方式によれば、送信者と受信者で暗号鍵を共有し、送信者が暗号化した画像データを受信者がその鍵を用いて復号すればよい。
また、公開鍵暗号方式もよく利用されている。公開鍵暗号方式は平文を暗号化するときと復号するときとで異なる鍵を使う暗号アルゴリズムである。この方式では、暗号化用の鍵を公開し、復号用の鍵を自分だけが秘密に保持する。そのため、暗号化用の鍵を公開鍵、復号用の鍵を秘密鍵と呼ぶ。図15を用いて説明すると、受信者Bは公開鍵と秘密鍵の鍵ペアを持ち、公開鍵は送信者のAに渡す。AはBの公開鍵で平文を暗号化してBに送信する。BはAから受信した暗号文を自分の秘密に保存した秘密鍵で復号する。公開鍵暗号アルゴリズムには整数の素因数分解の困難性(素因数分解問題)を利用したRSA、離散対数の困難性(離散対数問題)を利用したDSA、DHなどがある。
一方、これら鍵暗号方式を用いた暗号化は、例えば、文書データや画像データなどが解読されないために使われている。そして、これら鍵暗号方式を用いて暗号化された文書データや画像データを解読するには、共通鍵暗号方式なら、暗号化された際に使われた共通鍵で復号し、また、公開鍵暗号方式なら、暗号化された際に使われた公開鍵と対になる秘密鍵で復号する。(例えば、特許文献1参照。)
従来の情報セキュリティ技術では、コンピュータに保存されている情報が暗号化されている場合、それらの暗号化されている情報は復号化されない限り検索することができない。このため、暗号化されている情報が大規模になるほど、復号化および検索の処理時間がかかるという問題がある。
そこで、本発明は、コンピュータに保存される情報の機密性を確保しつつ高速な情報検索を可能にすることを目的とする。
本発明の一側面によれば、例えば、マークアップ言語によって書かれた文書データの所定部分が所定の鍵を用いて暗号化され、この所定部分が暗号化された文書データがデータベースとして保持される。そして、入力された検索文字列が前記所定の鍵を用いて暗号化され、その後、暗号化された検索文字列を含む文書データが前記データベースから検索される。
本発明によれば、コンピュータに保存される情報の機密性を確保しつつ高速な情報検索が可能になる。
以下、図面を参照して本発明の好適な実施形態について詳細に説明する。
(実施形態1)
まず、本実施形態における情報検索対象のデータの形式としては、XML(Extensible Markup Language)文書を考える。XMLは、拡張可能なマークアップ言語で、1986年ISOで標化されたSGML(Standard Generalized Markup Language)をインターネットで活用しやすくするために、1998年2月にその基本仕様XML1.0がW3Cにて策定された。Webページ作成言語であるHTML(HyperText Markup Language)はタグが固定であり、表示に特化した構造となっているため、アプリケーションからそのタグ情報を基にプログラム処理したいという要求に対応できないという問題がある。これに対して、XMLでは利用者が自由にタグを定義でき、文書中の文字列に意味付けができる言語構造を持っており、プログラムで自在にXMLデータを情報処理できるというメリットがある。さらに、SGMLの持つ複雑な印刷系のオプションなどを省略して言語仕様を規定しており、理解しやすさ、使いやすさを向上させている点にもメリットがある。
まず、本実施形態における情報検索対象のデータの形式としては、XML(Extensible Markup Language)文書を考える。XMLは、拡張可能なマークアップ言語で、1986年ISOで標化されたSGML(Standard Generalized Markup Language)をインターネットで活用しやすくするために、1998年2月にその基本仕様XML1.0がW3Cにて策定された。Webページ作成言語であるHTML(HyperText Markup Language)はタグが固定であり、表示に特化した構造となっているため、アプリケーションからそのタグ情報を基にプログラム処理したいという要求に対応できないという問題がある。これに対して、XMLでは利用者が自由にタグを定義でき、文書中の文字列に意味付けができる言語構造を持っており、プログラムで自在にXMLデータを情報処理できるというメリットがある。さらに、SGMLの持つ複雑な印刷系のオプションなどを省略して言語仕様を規定しており、理解しやすさ、使いやすさを向上させている点にもメリットがある。
図1は、XML文書の簡単な例である。これは、鈴木太郎という人が市場調査というテーマで作成した市場調査報告書である。ここでは、報告書を細かい情報単位で分け、その前後に情報の意味を表すタグをつけて、XML文書を作成した。この文書のキーワードになるのは「複写機」である。
この図1を例を用いて、XML文書を規定するために使用する用語を定義する。
(1)空要素タグ&開始タグ&終了タグ:
XML文書中で、要素の内容を持たない空の要素を示すタグを「空要素タグ」と呼ぶ。図1中、「<client Id=“1”/>」の部分が空要素タグである。
XML文書中で、要素の内容を持たない空の要素を示すタグを「空要素タグ」と呼ぶ。図1中、「<client Id=“1”/>」の部分が空要素タグである。
XML文書中で、空要素ではない要素の始まりを示すタグを、「開始タグ」と呼ぶ。図1中、「<data>」、「<Title>」、「<KeyWord>」などの部分が開始タグである。
XML文書中で、空要素ではない要素の終わりを示すタグを、「終了タグ」と呼ぶ。 図1中、「</data>」、「</Title>」、「</KeyWord>」などの部分が終了タグである。
(2)要素:
「<Title>市場調査</Title>」や「<FamilyName>鈴木</FamilyName>」などのように開始タグから終了タグまでの部分を「要素」と呼ぶ。
「<Title>市場調査</Title>」や「<FamilyName>鈴木</FamilyName>」などのように開始タグから終了タグまでの部分を「要素」と呼ぶ。
(3)要素の内容:
「市場調査」または「鈴木」のように開始タグと終了タグで囲まれた中身を「要素の内容」と呼ぶ。
「市場調査」または「鈴木」のように開始タグと終了タグで囲まれた中身を「要素の内容」と呼ぶ。
(4)XML文書:
XMLによって作成された文書やデータを「XML文書」を呼ぶ。
XMLによって作成された文書やデータを「XML文書」を呼ぶ。
(5)子要素:
ある要素の中に直接含まれる要素を「子要素」という。例えば、Title要素はdata要素の子要素である。
ある要素の中に直接含まれる要素を「子要素」という。例えば、Title要素はdata要素の子要素である。
入力データを転送、保存する場合、機密性を確保するために暗号化を行う必要がある。ここでは、XML暗号化を用いてデータの暗号化を行う。XML暗号化の特徴として、XML要素、XML要素の内容、任意の電子データ全体(XML文書も含む)を暗号化の対象とすることができる。XML暗号化では、復号側が復号に必要な全ての情報、暗号化アルゴリズム、鍵の情報、暗号化されたデータなどすべての情報をEncryptedData要素の中に格納する。図2はXML暗号文書の構成例を示したものである。図中、“?”は0回または1回、“*”は0回以上出現することを意味する。
EncryptedData要素の子要素としては、
EncryptionMethod要素、
KeyInfo要素、
CipherData要素、
EncryptionProperties要素、
の4つがある。これらのうち、CipherDataのみ省略不可能である。
EncryptionMethod要素、
KeyInfo要素、
CipherData要素、
EncryptionProperties要素、
の4つがある。これらのうち、CipherDataのみ省略不可能である。
EncryptionMethod要素にはType属性に暗号アルゴリズムの情報、KeyInfo要素には暗号化に使用した鍵に関する情報を格納する。
暗号化されたデータはBase64エンコードされて、CipherData要素の子要素CipherValue要素に格納するか、または、CipherReference要素のURI属性で指定した場所に格納する。
EncryptionProperties要素にはEncryptedData要素の生成に関する追加情報(日付/タイムスタンプなど)を格納する。XML暗号化を用いて、キーワードになる「複写機」など、選択した部分や要素のみの暗号化が可能である。また、一つの文書で部分暗号化を行う場合、それぞれ暗号化に使う鍵を異ならせることもできる。
例えば、図1のdata要素のすべての子要素の内容(「鈴木」、「太郎」、「複写機」など)をそれぞれ、図2のXML暗号化構文を利用して暗号化した結果は図4のようになる。具体的には、図1の「鈴木」はEncryptedData要素に置き換えられ、暗号化されたデータ「A3sa98z3」はCipherData要素のCipherValue要素に格納される。なお、空要素タグ<client Id=“1”/>は図1のXML文書がID番号1を持つクライアントにより生成されていることを意味する。
ここで、用いる暗号方式としてTriple DESを考える。Triple DESはDESの安全性を高めるための暗号方式である。
DESの基本的な動作は、(1)データを64ビット長のブロックに分割する、(2)各ブロックを56ビット長の鍵で暗号化する、の2つであるが、ブロックと鍵の使い方によってECB、CBC、OFB、CFBの4つのモードがある。
DESの基本型と言えるモードがECB(Electronic Code Block)である。上で述べた基本動作がそのまま行われる。つまり、データをブロックに分割した後、各ブロックを秘密鍵で暗号化し、それらのブロックを元の順番でつなぎ合わせる。
CBC(Cipher Block Chaining)は、暗号化された前ブロックと、まだ暗号化されていない現在のブロックとのXOR(排他的論理和)をとり、これを秘密鍵で暗号化するモードである。“Chaining(連鎖)”という言葉が使われているように、各ブロックの暗号化が「連鎖的」に進められる。
一方、CFB(Cipher Feedback)は、前ブロックの暗号化結果の1部(mビット)が次ブロックのmビットとXORをとる値としてフィードバックされるモードである。したがってCBCとCFBでは、ブロック内で発生したビット・エラーが、以降のブロックの暗号化に影響を与えることになる。
OFB(Output Feedback)は、ある初期値を第1ブロックとして暗号文を生成し、その暗号文(の1部)を次の暗号文の入力として用いると同時にその1部(mビット)を乱数として対応するmビットのデータとXOR をとるモードである。この仕組みによりブロック内のビット・エラーが、ほかのブロックを暗号化する際に影響を及ぼさない。“Output Feedback(出力フィードバック)”という名前は、前ブロックで生成された暗号文出力を次ブロックで使用する暗号文出力を生成させるためのパラメータとして、フィードバックさせることに由来している。
上記各モードにおいて、mビットを適切に選択することにより、任意のビット長毎の暗号化を実現できる。
Triple DESは、DESのアルゴリズムを複数回適用することで暗号強度を強化した暗号方式である。TipleDESは2つの異なる共通鍵を用いて「1つ目の鍵で暗号化」→「2つ目の鍵で復号化」→「1つ目の鍵で暗号化」を行うE-D-E方式と、3つの異なる共通鍵を用いるE-E-Dがある。
図3は、本実施形態に係る情報検索システムの構成を示すブロック図である。本発明の情報検索装置は単体の情報処理装置によって実現が可能であるが、ここではネットワークを介して相互に接続されるクライアント・サーバ型の情報検索システムを示す。
本実施形態の情報検索システムは、図示の如く、サーバ50にインターネット40を介して複数のクライアント10,20,30が接続されている。同図には3つのクライアントが接続されているが、クライアントの数は問題ではない。すなわち、クライアントは1つだけでもよいし、4つ以上接続された形態であってもよい。また、インターネット40はネットワークの一形態であって、LAN等の別の形態のネットワークであってもよい。
サーバおよびクライアントはそれぞれ、一般のパーソナルコンピュータで実現できるものであり、そのハードウェア構成は基本的に同様のものである。したがって、ここでは代表的にクライアント10のハードウェア構成についてのみ説明することにする。なお、以下に示すハードウェア構成はパーソナルコンピュータとして概ね標準的なものであるが、本発明を実現するためにこれらの構成をすべて備える必要があるというものではない。
クライアント10において、文書データの入力作業はマウス313やキーボード314を用いて行うことができ、あるいは、インターネット40を介して外部から文書データを取得することも可能である。作成された文書データは、例えばハードディスク304に記憶される。なお、ユーザからの各種指示等は、マウス313およびキーボード314からの入力操作により行われる。クライアント10の各構成要素はバス307によって接続され、相互に種々のデータの受け渡しが可能である。CPU302は主記憶装置303にロードされたプログラムを実行し、各構成要素の動作を制御する。主記憶装置303は、CPU302において行われる処理のために、一時的にプログラムや処理対象のXML文書を格納しておくメモリ(RAM)である。ハードディスク装置(HDD)304は、主記憶装置303等に転送されるプログラムやXML文書をあらかじめ格納したり、処理後の結果データを保存することのできる装置である。315はインターネット40に接続するためのインタフェース(I/F)、308はXML文書等を印刷するプリンタ316と接続ためのプリンタI/Fである。CDドライブ309は、外部記憶媒体の一つであるCD(CD−R/CD−RW)に記憶されたデータを読み込んだり、あるいは書き出すことができる装置である。FDD311は、CDドライブ309と同様にFDからの読み込みや、FDへの書き出しをすることができる装置である。DVDドライブ310は、FDD311と同様に、DVDからの読み込みや、DVDへの書き出しをすることができる装置である。なお、CD、FD、DVD等に文書編集用のプログラムが記憶されている場合には、これらプログラムをHDD304上にインストールし、必要に応じて主記憶装置303に転送されるようになっている。312は、マウス313やキーボード314からの入力指示を受け付けるために、これらと接続されるI/Fである。また、モニタ306は、文書の暗号化過程や文書検索結果を表示することのできる表示装置である。さらに、ビデオコントローラ305は、表示データをモニタ306に送信するための装置である。
図8は、本実施形態における情報検索システムの機能構成を示す図である。
図示のように、クライアント側で生成されたXML文書やテキストファイルはサーバ50に転送され、タグ生成部806および文書暗号化部802の処理を経て、データベース804に保存される。このデータベース804への保存処理の詳細は、後ほど図5および図10を用いて説明する。
各クライアントは、任意の検索文字列を含む文書を、サーバ50のデータベース804から検索するよう要求することができる。クライアントで入力された検索文字列がサーバ50に転送されると、サーバ50はこれに応じ、検索文字列暗号化部807および検索処理部803の処理を実行して、データベース804から検索された文書を取り出す。取り出した文書は復号処理部808での復号処理を経て検索要求を出したクライアントに出力される。この検索処理の詳細は、のちほど図7を用いて説明する。
なお、文書暗号化部802、検索文字列暗号化部807、および復号処理部808で利用する共通鍵は鍵管理部809から獲得する。
各クライアントでは、上記したとおり、文書データの入力作業はマウス313やキーボード314を用いて行うことができ、あるいは、インターネット40を介して外部から文書データを取得することも可能である。マウス313やキーボード314を用いて例えばXML文書を作成する際には、図6に示すようなグラフィカルユーザインタフェースによってその作成を支援することが好ましい。作成された文書データはインターネット40を介してサーバ805に転送される。
次に、図5のフローチャートを用いて、クライアントで生成された文書データをサーバ50のデータベース804に保存する処理を説明する。このフローチャートに対応するプログラムは例えば、サーバ50におけるHDDに記憶されており、主記憶装置にロードされてCPUによって実行されるものである。
クライアントより転送されてきた文書データを受け取ると(ステップ501)、その文書をXML文書に変換する(ステップ502)。このステップ502のXML文書への変換処理については図10のフローチャートを用いて説明する。
まず、入力したデータがXML文書かどうかを判断し(ステップ1002)、XML文書ではない場合には、タグ生成部806により、図1に示したような所定のタグをつけてXML文書を生成する(ステップ1003)ことが好ましい(ただし、この処理は本発明に必須のものではない。)。次に、入力されたXML文書またはステップ1003で生成されたXML文書の要素を順番に読み取り(ステップ1004)、暗号化対象の要素かどうかを判断する(ステップ1005)。暗号化対象の要素には特定の属性を付ける(ステップ1006)。例えば、図9に示すように、FamilyName要素、LastName要素、およびKeyWord要素にそれぞれ“EncObject”という属性名をつけることで、暗号化部分を明記することができる。EncObject属性値は暗号化に使う情報、例えば暗号鍵の名前を規定しても良い。全ての要素の検出が終わるまで、ステップ1004〜1006の処理を繰り返す(ステップ1007)。
なお、上記ステップ1006では、暗号化対象を決定するために暗号化対象になる要素に特定の属性をつけるようにしたが、他にも暗号対象の上位に特定の要素を付けることによっても暗号化対象を決定することができる。さらに、名前空間を与えることにより、正確に暗号化対象を探すことができる。
説明を図5のフローチャートに戻す。XML文書への変換を終えると、XML文書データの暗号化に使う共通鍵を鍵管理部809より獲得する(ステップ503)。続いて、XML文書から要素を順番に取り(ステップ504)、特定の属性がついている要素を検出する(ステップ505)。例えば、ステップ1006によって付与された属性EncObjectを検出する。特定の属性(EncObject)がついている要素に対しては、文書暗号化部802により、検出された要素の内容を共通鍵で、それぞれXML部分暗号化を実行する(ステップ506)。この部分暗号化は前述したXML暗号化を用いて実現する。なお、暗号方式はTripleDES方式などを用いる。
次に、上記特定の属性(EncObject)を取り除く(ステップ507)。これは同一形式のXML文書でデータを生成するためである。そして、当該要素がXML文書の末尾かを判断し(ステップ508)、最後の要素の場合には、以上の処理によって暗号化されたXML文書をデータベース804に格納し(ステップ509)、この処理を終了する。一方、まだ終了要素ではない場合にはステップ504に戻って処理を繰り返す。
次に、図7のフローチャートを用いて、サーバ50における文字列検索処理を説明する。この検索処理の検索対象は、上記した図5のフローに従いデータベース804に登録された部分暗号化されたXML文書である。
まず、クライアントから検索文字列を受信すると(ステップ702)、共通鍵を鍵管理部809より獲得する(ステップ703)。この共通鍵はデータベース804への登録処理における暗号化(ステップ506)で使用された鍵である。検索文字列は、検索文字列暗号化部807により、この獲得した鍵を用いて暗号化される(ステップ704)。そして、検索処理部803により、データベース804に保存されている全ての要素内容を検索する(ステップ707)。
ここで、要素型などの補助情報を持っている場合には(ステップ705)、その情報を検索条件として付加し(ステップ706)、これにより高速な検索を行なうことも可能である。
検索された部分暗号化文書は、復号処理部808により、ステップ703で獲得した共通鍵を用いて復号され(ステップ708)、検索要求元のクライアントに転送される(ステップ709)。
以上説明した実施形態1によれば、各文書は、その文書の特徴的な情報を含むであろう所定の部分が所定の鍵によって暗号化されたうえでデータベースに保存されるので、文書の機密性は確保される。そして、データベースの検索要求があった場合、その検索文字列が上記所定の鍵により暗号化され、この暗号化された検索文字列がデータベースから検索される。このため、従来のように検索処理のためにデータベース内の文書をすべて復号する必要がなくなり、検索を高速化することができる。
(実施形態2)
上述の実施形態1では、クライアント側で生成された文書データがそのままサーバに転送され、サーバにおいて文書データの暗号化が行われていた。この場合には、クライアントからサーバに転送する過程における文書データのセキュリティが保証されないという問題がある。そこで、本実施形態では、文書データの暗号化をクライアント側で行い、その後にサーバに転送するようにする。これにより、文書データの安全な転送およびデータベースの保存が確保される。
上述の実施形態1では、クライアント側で生成された文書データがそのままサーバに転送され、サーバにおいて文書データの暗号化が行われていた。この場合には、クライアントからサーバに転送する過程における文書データのセキュリティが保証されないという問題がある。そこで、本実施形態では、文書データの暗号化をクライアント側で行い、その後にサーバに転送するようにする。これにより、文書データの安全な転送およびデータベースの保存が確保される。
図11は、本実施形態における情報検索システムの機能構成を示す図である。図示のように、クライアント1101がタグ生成部1107および文書暗号化部1108を有する構成である。各クライアントは必要に応じて各処理部を備えており、例えば、クライアント1102はさらに、検索文字列暗号化部や復号処理部も備えている。一方、クライアント1103は、検索文字列暗号化部や復号処理部を備えているが、タグ生成部や文書暗号化部は備えていない。サーバ1104は、図8に示したサーバ50とは対照的に、タグ生成部、文書暗号化部、検索文字列暗号化部、復号処理部を備えていない。
また、実施形態1におけるサーバは鍵管理部を有していたが、本実施形態では各クライアントの鍵を一元管理する鍵管理サーバ1112を別途設けるシステム構成とした。鍵管理サーバは、クライアントIDとクライアントの共通鍵をあらかじめ登録してこれらを管理する。したがって、クライアントはこの鍵管理サーバ1112から共通鍵を取得して文書データの暗号化、検索文字列の暗号化、復号処理を行うことになる。同様に、サーバ1104における検索処理部1106も鍵管理サーバ1112から共通鍵を取得して検索処理を行うことになる。
次に、図12のフローチャートを用いて、クライアントによる文書データのサーバへの転送に係る処理を説明する。この処理は、実施形態1におけるサーバ50の処理(図5)と類似のものである。なお、このフローチャートに対応するプログラムは例えば、クライアント側のHDDに記憶されており、主記憶装置にロードされてCPUによって実行されるものである。
クライアントにおいて、文書データを作成またはネットワーク等を介して受信すると(ステップ1201)、その文書をXML文書に変換する(ステップ1202)。このステップ1202のXML文書への変換処理については実施形態1のステップ502(図10のフローチャート)と同様に行うことができる。
XML文書への変換を終えると、XML文書データの暗号化に使う共通鍵を鍵管理サーバ1112より獲得する(ステップ1203)。続いて、XML文書から要素を順番に取り(ステップ1204)、特定の属性がついている要素を検出する(ステップ1205)。例えば、ステップ1006によって付与された属性EncObjectを検出する。特定の属性(EncObject)がついている要素に対しては、文書暗号化部1108により、検出された要素の内容を共通鍵で、それぞれXML部分暗号化を実行する(ステップ1206)。この部分暗号化は前述したXML暗号化を用いて実現する。なお、暗号方式はTripleDES方式などを用いる。
次に、上記特定の属性(EncObject)を取り除く(ステップ1207)。これは同一形式のXML文書でデータを生成するためである。そして、当該要素がXML文書の末尾かを判断し(ステップ1208)、最後の要素の場合には、以上の処理によって暗号化されたXML文書をサーバ1104に転送し(ステップ1209)、この処理を終了する。一方、まだ終了要素ではない場合にはステップ1204に戻って処理を繰り返す。
サーバ1104は、以上の処理によって部分暗号化されたXML文書が転送されてくると、保存部1105の処理により、これをそのままデータベース1109に保存(登録)する。
次に、本実施形態における検索処理について説明する。ここでは、クライアント1103がサーバ1104に対して検索要求を出す場合を想定する。
クライアント1103は、ユーザにより入力された検索文字列を、自身が有する検索文字列暗号化部1110の処理により暗号化し、それを鍵管理サーバ1112に転送する。鍵管理サーバ1112は、暗号化された検索文字列を復号し、各クライアントの鍵で暗号化したうえでサーバ1104に転送する。サーバ1104は、検索処理部1106の処理により暗号化された検索文字列を含む文書をデータベース1109から検索し、検索によりヒットした部分暗号化文書を鍵管理サーバ1112に転送する。鍵管理サーバ1112は、これに応じて部分暗号化文書を復号し、クライアント1103の鍵で暗号化して、これをクライアント1103に転送する。図13および図30のフローチャートを用いて、以上の処理をより詳しく説明する。図13は、クライアント1103における処理、図30は鍵管理サーバ1112における処理を示している。
図13に示したクライアント1103における処理は、図7に示したサーバ50における処理と一部と類似している。まず、検索文字列を入力すると(ステップ1301)、共通鍵を鍵管理サーバ1112より獲得する(ステップ1302)。この共通鍵はデータベース1109への登録処理における暗号化(ステップ1206)で使用された鍵である。検索文字列は、検索文字列暗号化部1110により、この獲得した鍵を用いて暗号化される(ステップ1303)。そして、この暗号化された検索文字列を、クライアント1103のID(ネットワークID)とともに鍵管理サーバ1112に転送する(ステップ1306)ここで、要素型などの補助情報を持っている場合には(ステップ1304)、その情報を検索条件として付加し(ステップ1305)、これにより高速な検索を行わせることも可能である。
次に、図30の鍵管理サーバ1112における処理を説明する。鍵管理サーバ1112は、クライアントより暗号化された検索文字列を受信すると(ステップ3001)、同時に送信されてきたクライアントのIDを用いて、登録されているクライアントの共通鍵を獲得し(ステップ3002)、その共通鍵を用いて暗号化された検索文字列を復号する(ステップ3003)。次に、各クライアントの共通鍵を獲得し(ステップ3004)、それらの共通鍵を用いて、復号した検索文字列を暗号化する(ステップ3005)。そして、各クライアントの共通鍵別に暗号化された複数の検索文字列をサーバ1104に転送する(ステップ3006)。
図20は、上記ステップ3006に応じて行われるサーバ1104における検索処理を示すフローチャートである。サーバ(1104)は、上記ステップ3006によって転送されてきた複数の暗号化された検索文字列を受信し(ステップ2001)、これらの暗号化された検索文字列を含む文書をデータベース1109から検索する(ステップ2002)。そして、この検索でヒットした部分暗号化文書を鍵管理サーバ1112に転送する(ステップ2003)。
図31は、上記ステップ2003に応じて行われる鍵管理サーバ1112における制御処理を示すフローチャートである。鍵管理サーバ1112は、上記ステップ2003によって転送されてきた部分暗号化文書を受信すると(ステップ3101)、部分暗号化文書のclient要素のID属性により、どのクライアントの共通鍵で暗号化されているか判断し、登録されているそのクライアントの共通鍵を獲得し(ステップ3102)、その共通鍵を用いて部分暗号化文書を復号する(ステップ3103)。次に、送信先クライアント(検索要求元のクライアント)の共通鍵を獲得し(ステップ3104)、その共通鍵を用いて、復号した文書を暗号化する(ステップ3105)。そして、この暗号化された部分暗号化文書をクライアントに転送する(ステップ3106)。
図21は、クライアント1103の復号処理部1111による復号処理を示すフローチャートである。クライアント1103は、検索された部分暗号化文書を受信すると(ステップ2101)、自分の共通鍵を獲得して(ステップ2102)、部分暗号化文書を復号する(ステップ2103)。
なお、以上の検索処理の例では、サーバ1104は検索された部分暗号化文書を鍵管理サーバ1112に送り(図20)、鍵管理サーバ1112がそれをクライアントに転送するようにしたが(図31)、サーバ1104が直接クライアントに検索された部分暗号化文書を転送するようにしてもよい。この場合には、ステップ2102における鍵の獲得は鍵管理サーバ1112への問い合わせ処理となる。
(実施形態3)
上述の実施形態2では、各クライアントの鍵を一元管理する鍵管理サーバ1112を別途設けるシステム構成とした。しかしこの場合には、鍵の管理を鍵管理サーバに依存することになり鍵の管理が複雑になるという欠点がある。本実施形態では各クライアントとサーバとでそれぞれ違う鍵で暗号化して送信することによりデータの安全性を高める。
上述の実施形態2では、各クライアントの鍵を一元管理する鍵管理サーバ1112を別途設けるシステム構成とした。しかしこの場合には、鍵の管理を鍵管理サーバに依存することになり鍵の管理が複雑になるという欠点がある。本実施形態では各クライアントとサーバとでそれぞれ違う鍵で暗号化して送信することによりデータの安全性を高める。
図19は、本実施形態における情報検索システムの機能構成を示す図である。実施形態2に係る図11と対照すると分かるように、本システムは鍵管理サーバを設けないかわりに、クライアントおよびサーバが鍵生成管理部を有する構成である。各クライアント1901および1902とサーバ1903はそれぞれ、公開鍵と秘密鍵の鍵ペアを持つ。クライアントの公開鍵はサーバ1903の鍵生成管理部1912に保存される。また、サーバ1903の公開鍵は各クライアントの鍵生成管理部1913および1914に保存される。
図16は、クライアント1901で生成した文書データがサーバ1903のデータベース1909に登録されるまでの暗号化過程を表したものである。以下ではこの図16と、図22および図23のフローチャートを用いて、クライアント1901とサーバ1903の動作をそれぞれ説明する。
図22は、本実施形態におけるクライアント1901による文書データのサーバ1903への転送に係る処理を示すフローチャートである。
クライアント1901において、文書データを作成またはネットワーク等を介して受信すると(ステップ2201)、その文書をXML文書に変換する(ステップ2202)。このステップ2202のXML文書への変換処理については実施形態1のステップ502(図10のフローチャート)と同様に行うことができる。
XML文書への変換を終えると、XML文書データの暗号化に使う共通鍵を獲得する(ステップ2203)。本実施形態で使用する共通鍵は毎回ランダムに生成される共通鍵(Ran_Key1、図16参照)であり、これは鍵生成管理部1913で生成される。
続いて、XML文書から要素を順番に取り(ステップ2204)、特定の属性がついている要素を検出する(ステップ2205)。例えば、実施形態1,2と同様に、ステップ1006によって付与された属性EncObjectを検出する。特定の属性(EncObject)がついている要素に対しては、文書暗号化部1908により、検出された要素の内容を共通鍵で、それぞれXML部分暗号化を実行する(ステップ2206)。この部分暗号化は前述したXML暗号化を用いて実現する。なお、暗号方式はTripleDES方式などを用いる。
次に、上記特定の属性(EncObject)を取り除く(ステップ2207)。これは同一形式のXML文書でデータを生成するためである。そして、当該要素がXML文書の末尾かを判断する(ステップ2208)。最後の要素であった場合には、鍵生成管理部1913によりサーバ1903の公開鍵を獲得し(ステップ2209)、そのサーバの公開鍵を用いてRan_Key1をXML暗号化する(ステップ2210)。そして、以上の処理によって暗号化されたXML文書をサーバ1903に転送し(ステップ2211)、この処理を終了する。一方、まだ終了要素ではない場合にはステップ1204に戻って処理を繰り返す。なお、Ran_Key1の暗号化情報は、部分暗号化文書の中に埋め込んでサーバに転送しても良いし、独自でサーバに転送しても良い。あるいは、Ran_Key1については暗号化せずにそのままサーバに転送してもよい。
図23は、サーバ1903の、上記ステップ2211によりクライアントから転送されてきた部分暗号化文書のデータベースへの登録処理を示すフローチャートである。
サーバ1903は、Ran_Key1の暗号化情報を受信すると(ステップ2301)、サーバの秘密鍵を鍵生成管理部1912より獲得し(ステップ2302)、そのサーバの秘密鍵を用いて、Ran_Key1の暗号化情報を復号する(ステップ2303)。次に、復号されたRan_Key1を用いて部分暗号化文書を復号する(ステップ2304)。さらに、サーバの共通鍵(Ser_Key)を鍵生成管理部1912より獲得し(ステップ2305)、そのサーバの共通鍵(Ser_Key)を用いて、復号した部分を暗号化し(ステップ2306)、これをデータベース1909に保存する(ステップ2307)。
図17は、クライアント1902から検索文字列を入力して、サーバ1903が検索を行うまでの暗号化過程を表したものである。以下ではこの図17と、図24および図25のフローチャートを用いて、クライアント1902とサーバ1903の動作をそれぞれ説明する。
図24は、本実施形態の検索処理に係るクライアント1902での処理内容を示すフローチャートである。この処理は実施形態2で説明した図13の処理と類似の処理である。ただし、実施形態2では、クライアント固有の共通鍵を用いて暗号化するのに対し、本実施形態で使用する共通鍵は毎回ランダムに生成される共通鍵(Ran_Key2)である(ステップ2402,2403)。また、Ran_Key2は鍵生成管理部1914に保存されているサーバの公開鍵で暗号化する(ステップ2406,2407)。なお、Ran_Key2の暗号化情報は部分暗号化文書の中に埋め込んでサーバに転送しても良いし、独立にサーバに転送されても良い。あるいは、Ran_Key2は暗号化せずにそのままサーバに転送してもよい。
図25は、サーバ1903による検索処理を示すフローチャートである。
サーバ1903はまず、Ran_Key2の暗号化情報と暗号化された検索文字列を受信する(ステップ2501)。次に、サーバの秘密鍵を鍵生成管理部1912より獲得し(ステップ2502)、そのサーバの秘密鍵を用いてRan_Key2を復号する(ステップ2503)。続いて、そのRan_Key2を用いて、暗号化された検索文字列を復号する(ステップ2504)。さらに、サーバの共通鍵(Ser_Key)を鍵生成管理部1912より獲得し(ステップ2505)、そのサーバの共通鍵(Ser_Key)を用いて、復号した検索文字列を暗号化する(ステップ2506)。そして、この暗号化された検索文字列を含む文書をデータベースから検索する(ステップ2507)。
図18は、上記ステップ2507によりサーバ1903で検索された部分暗号化文書をクライアント1902で復号する際の復号過程を表したものである。以下ではこの図18と、図26および図27のフローチャートを用いて、サーバ1903およびクライアント1902の動作をそれぞれ説明する。
図26は、サーバ1903による検索した部分暗号化文書に対する処理を示すフローチャートである。
サーバ1903はまず、サーバの共通鍵(Ser_Key)を鍵生成管理部1912より獲得し(ステップ2602)、そのサーバの共通鍵(Ser_Key)を用いて、検索された部分暗号化文書の暗号化された部分を復号する(ステップ2603)。次に、復号した部分を、ランダムに生成された鍵(Ran_Key3)を鍵生成管理部1912より獲得し(ステップ2604)、その鍵(Ran_Key3)を用いて、復号した文書を暗号化する(ステップ2605)。次に、クライアント1902の公開鍵を鍵生成管理部1912より獲得し(ステップ2606)、そのクライアント1902の公開鍵を用いて、ステップ2604で獲得した鍵(Ran_Key3)を暗号化する(ステップ2607)。そして、ステップ2605で暗号化された部分暗号化文書およびステップ2607で暗号化されたRan_Key3の暗号化情報を、クライアント1902に転送する(ステップ2608)。
なお、Ran_Key3を生成せず、上記した検索処理で利用したRan_Key2を用いて復号した部分を暗号化しても良い。また、安全性は低くなるが、検索された部分暗号化文書を、クライアント1902の公開鍵で暗号化されたSer_Keyの暗号化情報と共にクライアント1902に転送しても良い。
図27は、クライアント1902による復号処理を示すフローチャートである。
ランダムに生成された鍵Ran_Key3の暗号化情報および部分暗号化文書をサーバ1903より受信すると(ステップ2701)、クライアント1902の秘密鍵を鍵生成管理部1914より獲得し(ステップ2702)、そのクライアント1902の秘密鍵を用いて、受信した暗号化情報を復号する(ステップ2703)。これにより、ランダムに生成された鍵Ran_Key3が復号される。続いて、復号したRan_Key3を用いて、受信した部分暗号化文書を復号する(ステップ2704)。
(実施形態4)
上述の実施形態3では、サーバが送信された部分暗号化文書を復号して、サーバの共通鍵で暗号化したが、この場合にはデータの処理時間が長くなるという欠点がある。そこで本実施形態では、サーバが暗号化して送信された部分暗号化文書をそのまま保存し、クライアント毎の鍵をサーバ内に管理して、検索文字列をその鍵で暗号化する。
上述の実施形態3では、サーバが送信された部分暗号化文書を復号して、サーバの共通鍵で暗号化したが、この場合にはデータの処理時間が長くなるという欠点がある。そこで本実施形態では、サーバが暗号化して送信された部分暗号化文書をそのまま保存し、クライアント毎の鍵をサーバ内に管理して、検索文字列をその鍵で暗号化する。
図28は、本実施形態における情報検索システムの機能構成を示す図である。サーバ2803は、保存処理部2804により、クライアント2801から転送された部分暗号化文書をデータベース2805にそのまま保存する。この点は、実施形態3に係る図19では、部分暗号化文書が復号処理部1904および暗号化処理部1905の処理を介してデータベース1909に保存される点と対照的である。サーバ2803は、検索文字列によって部分暗号化文書を検索し、クライアント2802に転送する。
図32は、本実施形態におけるクライアント2801による文書データのサーバ2803への転送に係る処理を示すフローチャートである。これは実施形態3に係る図22とほぼ共通の処理である。ただし、実施形態3ではランダムで生成した鍵で文書データを暗号化したが(ステップ2203,2206)、本実施形態ではクライアント2801の共通鍵で暗号化する(ステップ3203,3206)。クライアント2801のID情報は文書データ中のclient要素のId属性に保存する。なお、クライアント2801の共通鍵は鍵管理部2810に保存されている。
図36は、サーバ2803による受信データの保存処理を示すフローチャートである。サーバ2803は、部分暗号化文書を受信すると(ステップ3601)、上記のとおり、そのままデータベース2805に保存する(ステップ3602)。次に、上記ステップ3210で暗号化されたうえで転送されてきたクライアント2801の共通鍵を、サーバ2803の秘密鍵で復号し(ステップ3603)、これを鍵管理部2807に保存する(ステップ3604)。
図33は、本実施形態の検索処理に係るクライアント2802での処理内容を示すフローチャートである。この処理は実施形態3で説明した図24の処理と類似の処理である。ただし、実施形態3(図24)では、クライアントは検索文字列をランダムに生成された鍵で暗号化する(ステップ2402,2403)のに対し、本実施形態では、クライアント2802は入力された検索文字列をクライアント2802の共通鍵で暗号化する(ステップ3302,3303)。
図29は、サーバ2803による検索処理を示すフローチャートである。この処理は実施形態3で説明した図25の処理と類似の処理である。ただし、実施形態3(図25)ではいったん復号された検索文字列をサーバの共通鍵で暗号化した(ステップ2505,2506)のに対し、本実施形態ではいったん復号した検索文字列を各クライアントの共通鍵で暗号化する(ステップ2905,2906)。なお、各クライアントの共通鍵は鍵管理部2807に保存されている。
図34は、サーバ2803による検索した部分暗号化文書に対する処理を示すフローチャートである。この処理は実施形態3で説明した図26の処理と類似の処理である。ただし、実施形態3(図26)では検索された部分暗号化文書を復号する際にはサーバの共通鍵で復号したが(ステップ2602,2603)、本実施形態では、クライアントの共通鍵で復号する(ステップ3402,3403)。なお、クライアントの共通鍵は鍵管理部2807に保存されている。また、本実施形態では、検索された部分暗号化文書のclient要素を用いて、どのクライアントの共通鍵を利用するかを識別する。
図35は、クライアント2803による復号処理を示すフローチャートである。この処理は実施形態3で説明した図27の処理と類似の処理である。ただし、本実施形態では、クライアントの共通鍵を用いて部分暗号化文書を復号することになる(ステップ3502,3503)。
(他の実施形態)
上述の各実施形態では、暗号方式としてTriple DESを用いた例を説明したが、本発明ではTripleDESに限らずAESやMISTY,Camelliaなどその他の共通鍵暗号化を用いることでできるのは明らかである。この場合、本発明の暗号化・復号手法の強度は用いた暗号方式に応じた安全性を持つ。
上述の各実施形態では、暗号方式としてTriple DESを用いた例を説明したが、本発明ではTripleDESに限らずAESやMISTY,Camelliaなどその他の共通鍵暗号化を用いることでできるのは明らかである。この場合、本発明の暗号化・復号手法の強度は用いた暗号方式に応じた安全性を持つ。
また、暗号化モードもCFBやOFBに限らず任意長のデータを暗号化できる手法であるかぎり、本発明は特定の暗号化モードに限定されるものではない。
また、実施形態2と実施形態3では、検索文字列をクライアントからサーバに転送する際、安全性のため暗号化して転送したが、必要がなければ暗号化せずにそのまま転送しても良い。また、閉じたシステムにおいて、いつも決まった部分のみ暗号化するような場合には、暗号化する部分を特定しなくても良いであろう。
以上、本発明の実施形態を詳述したが、本発明は、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータがその供給されたプログラムコードを読み出して実行することによっても達成される。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。
従って、本発明の機能処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体およびそのプログラムを格納した記憶媒体も本発明を構成することになる。つまり、本発明の特許請求の範囲には、本発明の機能処理を実現するためのコンピュータプログラム自体、およびそのプログラムを格納した記憶媒体も含まれる。
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、OSに供給するスクリプトデータ等、プログラムの形態を問わない。
プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、MO、CD−ROM、CD−R、CD−RW、磁気テープ、不揮発性のメモリカード、ROM、DVD(DVD−ROM、DVD−R)などがある。
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、そのホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるWWWサーバも、本発明のクレームに含まれるものである。
また、本発明のプログラムを暗号化してCD−ROM等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているOSなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
さらに、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。
Claims (16)
- 文書データをデータベースとして保持するサーバと、このサーバと通信可能に接続されたクライアントとを含み、このクライアントからの検索要求に応じて前記サーバがデータベースに対する情報検索を行う情報検索システムであって、
前記サーバは、
マークアップ言語によって書かれた文書データの所定部分を所定の鍵を用いて暗号化する第1の暗号化手段と、
前記第1の暗号化手段により前記所定部分が暗号化された文書データを前記データベースに登録する登録手段と、
検索文字列を前記所定の鍵を用いて暗号化する第2の暗号化手段と、
前記第2の暗号化手段により暗号化された検索文字列を含む文書データを前記データベースから検索する検索手段と、
を有することを特徴とする情報検索システム。 - 前記所定部分は、前記マークアップ言語のタグによって特定されることを特徴とする請求項1に記載の情報検索システム。
- 前記第1の暗号化手段は、入力した文書データが前記マークアップ言語で記述されたものでない場合、前記文書データを前記マークアップ言語の文書データに変換する変換手段を含むことを特徴とする請求項1または2に記載の情報検索システム。
- 前記第1の暗号化手段は、前記所定部分の暗号化を実行した後に前記所定部分を特定する前記タグを前記文書データから削除する編集手段を含むことを特徴とする請求項2に記載の情報検索システム。
- 前記検索手段によって検索された文書データを復号する復号手段を更に有することを特徴とする請求項1から4までのいずれかに記載の情報検索システム。
- 文書データをデータベースとして保持するサーバと、このサーバと通信可能に接続されたクライアントとを含み、このクライアントからの検索要求に応じて前記サーバがデータベースに対する情報検索を行う情報検索システムであって、
前記クライアントは、
マークアップ言語によって書かれた文書データの所定部分を所定の鍵を用いて暗号化する第1の暗号化手段と、
検索文字列を前記所定の鍵を用いて暗号化する第2の暗号化手段と、
を有し、
前記サーバは、
前記第1の暗号化手段により前記所定部分が暗号化された文書データを前記データベースに登録する登録手段と、
前記第2の暗号化手段により暗号化された検索文字列を含む文書データを前記データベースから検索する検索手段と、
を有することを特徴とする情報検索システム。 - 文書データをデータベースとして保持するサーバと、このサーバと通信可能に接続されたクライアントとを含み、このクライアントからの検索要求に応じて前記サーバがデータベースに対する情報検索を行う情報検索システムであって、
前記クライアントは、
マークアップ言語によって書かれた文書データの所定部分を第1の鍵を用いて暗号化する第1の暗号化手段と、
前記第1の暗号化手段により前記所定部分が暗号化された文書データを前記サーバに送信する送信手段と、
を有し、
前記サーバは、
前記クライアントから受信した前記所定部分が暗号化された文書データを、前記第1の鍵を用いて復号する復号手段と、
前記復号手段により復号された文書データの前記所定部分を第2の鍵を用いて暗号化する第2の暗号化手段と、
前記第2の暗号化手段により前記所定部分が暗号化された文書データを前記データベースに登録する登録手段と、
検索文字列を前記第2の鍵を用いて暗号化する第3の暗号化手段と、
前記第3の暗号化手段により暗号化された検索文字列を含む文書データを前記データベースから検索する検索手段と、
を有することを特徴とする情報検索システム。 - 文書データをデータベースとして保持するサーバと、このサーバと通信可能に接続されたクライアントとを含み、このクライアントからの検索要求に応じて前記サーバがデータベースに対する情報検索を行う情報検索システムであって、
前記クライアントは、
マークアップ言語によって書かれた文書データの所定部分をそのクライアントに依存した第1の鍵を用いて暗号化する第1の暗号化手段と、
前記第1の暗号化手段により前記所定部分が暗号化された文書データと前記第1の鍵とを前記サーバに送信する送信手段と、
を有し、
前記サーバは、
前記クライアントから受信した前記所定部分が暗号化された文書データと前記第1の鍵とを前記データベースに登録する登録手段と、
検索文字列を前記第2の鍵を用いて暗号化する第2の暗号化手段と、
前記第2の暗号化手段により暗号化された検索文字列を含む文書データを前記データベースから検索する検索手段と、
を有することを特徴とする情報検索システム。 - マークアップ言語によって書かれた文書データの所定部分を所定の鍵を用いて暗号化する第1の暗号化手段と、
前記第1の暗号化手段により前記所定部分が暗号化された文書データを記憶する記憶手段と、
検索文字列を前記所定の鍵を用いて暗号化する第2の暗号化手段と、
前記第2の暗号化手段により暗号化された検索文字列を含む文書データを、前記記憶手段から検索する検索手段と、
を有することを特徴とする情報検索装置。 - マークアップ言語によって書かれた文書データが所定部分を所定の鍵を用いて暗号化し、その所定部分が暗号化された文書データをメモリに記憶しておき、このメモリに記憶されている文書データに対し情報検索を行う情報検索方法であって、
検索文字列を前記所定の鍵を用いて暗号化するステップと、
暗号化された前記検索文字列を含む文書データを、前記メモリから検索するステップと、
を有することを特徴とする情報検索方法。 - マークアップ言語によって書かれた文書データが所定部分を所定の鍵を用いて暗号化し、その所定部分が暗号化された文書データをメモリに記憶しておき、このメモリに記憶されている文書データに対し情報検索を行う情報検索方法をコンピュータに実行させるためのプログラムであって、
検索文字列を前記所定の鍵を用いて暗号化するためのコードと、
暗号化された前記検索文字列を含む文書データを、前記メモリから検索するためのコードと、
を含むことを特徴とするプログラム。 - 請求項11に記載のプログラムを格納したコンピュータ読み取り可能な記憶媒体。
- 文書データをデータベースとして保持し、クライアントからの検索要求に応じてこのデータベースに対する情報検索を行う情報検索システムにおけるサーバであって、
マークアップ言語によって書かれた文書データの所定部分を所定の鍵を用いて暗号化する第1の暗号化手段と、
前記第1の暗号化手段により前記所定部分が暗号化された文書データを前記データベースに登録する登録手段と、
検索文字列を前記所定の鍵を用いて暗号化する第2の暗号化手段と、
前記第2の暗号化手段により暗号化された検索文字列を含む文書データを前記データベースから検索する検索手段と、
を有することを特徴とするサーバ。 - マークアップ言語によって書かれた文書データの所定部分を所定の鍵を用いて暗号化し、その所定部分を暗号化した文書データをデータベースとして保持し、クライアントからの検索要求に応じてこのデータベースに対する情報検索を行う情報検索システムにおけるサーバの制御方法であって、
検索文字列を前記所定の鍵を用いて暗号化するステップと、
暗号化された前記検索文字列を含む文書データを前記データベースから検索するステップと、
を有することを特徴とするサーバの制御方法。 - マークアップ言語によって書かれた文書データの所定部分を所定の鍵を用いて暗号化し、その所定部分を暗号化した文書データをデータベースとして保持し、クライアントからの検索要求に応じてこのデータベースに対する情報検索を行う情報検索方法をサーバに実行させるためのプログラムであって、
検索文字列を前記所定の鍵を用いて暗号化するためのコードと、
暗号化された検索文字列を含む文書データを前記データベースから検索するためのコードと、
を含むことを特徴とするプログラム。 - 請求項15に記載のプログラムを格納したコンピュータ読み取り可能な記憶媒体。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004100398A JP2005284915A (ja) | 2004-03-30 | 2004-03-30 | 情報検索装置および方法、ならびに情報検索システムおよびその制御方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004100398A JP2005284915A (ja) | 2004-03-30 | 2004-03-30 | 情報検索装置および方法、ならびに情報検索システムおよびその制御方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2005284915A true JP2005284915A (ja) | 2005-10-13 |
JP2005284915A5 JP2005284915A5 (ja) | 2007-03-22 |
Family
ID=35183205
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004100398A Pending JP2005284915A (ja) | 2004-03-30 | 2004-03-30 | 情報検索装置および方法、ならびに情報検索システムおよびその制御方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2005284915A (ja) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007124520A (ja) * | 2005-10-31 | 2007-05-17 | Ntt Data Corp | データ検索システム、情報処理装置、データ検索方法、及び、プログラム。 |
JP2008501175A (ja) * | 2004-05-28 | 2008-01-17 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | プロテクトされた構造化されたデータのクエリ方法及び装置 |
JP2008226098A (ja) * | 2007-03-15 | 2008-09-25 | Brother Ind Ltd | 印刷ジョブ管理装置およびコンピュータプログラム |
JP2010518531A (ja) * | 2007-02-14 | 2010-05-27 | プロヴィラ インコーポレイテッド | 非対称署名生成を使用するドキュメント照合エンジン |
JP2010186163A (ja) * | 2009-01-23 | 2010-08-26 | Nec (China) Co Ltd | 暗号化転置インデックステーブルに対するk−匿名性更新のための方法および装置 |
WO2012004880A1 (ja) * | 2010-07-08 | 2012-01-12 | 三菱電機株式会社 | キーワード変換装置、キーワード変換プログラム、記録媒体及びキーワード変換方法 |
JP2013516642A (ja) * | 2009-12-31 | 2013-05-13 | バウルティブ リミテッド | ネットワークを介して送信されるデータの暗号化および復号化システム、装置、および方法 |
WO2013111284A1 (ja) * | 2012-01-25 | 2013-08-01 | 三菱電機株式会社 | データ検索装置、データ検索方法、データ検索プログラム、データ登録装置、データ登録方法、データ登録プログラムおよび情報処理装置 |
US20140373176A1 (en) * | 2013-06-18 | 2014-12-18 | International Business Machines Corporation | Providing access control for public and private document fields |
US9002976B2 (en) | 2008-09-15 | 2015-04-07 | Vaultive Ltd | System, apparatus and method for encryption and decryption of data transmitted over a network |
US10235539B2 (en) | 2013-02-25 | 2019-03-19 | Mitsubishi Electric Corporation | Server device, recording medium, and concealed search system |
US10313371B2 (en) | 2010-05-21 | 2019-06-04 | Cyberark Software Ltd. | System and method for controlling and monitoring access to data processing applications |
-
2004
- 2004-03-30 JP JP2004100398A patent/JP2005284915A/ja active Pending
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008501175A (ja) * | 2004-05-28 | 2008-01-17 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | プロテクトされた構造化されたデータのクエリ方法及び装置 |
JP2007124520A (ja) * | 2005-10-31 | 2007-05-17 | Ntt Data Corp | データ検索システム、情報処理装置、データ検索方法、及び、プログラム。 |
JP2010518531A (ja) * | 2007-02-14 | 2010-05-27 | プロヴィラ インコーポレイテッド | 非対称署名生成を使用するドキュメント照合エンジン |
JP2008226098A (ja) * | 2007-03-15 | 2008-09-25 | Brother Ind Ltd | 印刷ジョブ管理装置およびコンピュータプログラム |
US9002976B2 (en) | 2008-09-15 | 2015-04-07 | Vaultive Ltd | System, apparatus and method for encryption and decryption of data transmitted over a network |
US9444793B2 (en) | 2008-09-15 | 2016-09-13 | Vaultive Ltd. | System, apparatus and method for encryption and decryption of data transmitted over a network |
US9338139B2 (en) | 2008-09-15 | 2016-05-10 | Vaultive Ltd. | System, apparatus and method for encryption and decryption of data transmitted over a network |
JP2010186163A (ja) * | 2009-01-23 | 2010-08-26 | Nec (China) Co Ltd | 暗号化転置インデックステーブルに対するk−匿名性更新のための方法および装置 |
JP2013516642A (ja) * | 2009-12-31 | 2013-05-13 | バウルティブ リミテッド | ネットワークを介して送信されるデータの暗号化および復号化システム、装置、および方法 |
US10313371B2 (en) | 2010-05-21 | 2019-06-04 | Cyberark Software Ltd. | System and method for controlling and monitoring access to data processing applications |
JP5425307B2 (ja) * | 2010-07-08 | 2014-02-26 | 三菱電機株式会社 | キーワード変換装置、キーワード変換プログラム、記録媒体及びキーワード変換方法 |
WO2012004880A1 (ja) * | 2010-07-08 | 2012-01-12 | 三菱電機株式会社 | キーワード変換装置、キーワード変換プログラム、記録媒体及びキーワード変換方法 |
JP5606642B2 (ja) * | 2012-01-25 | 2014-10-15 | 三菱電機株式会社 | データ検索装置、データ検索方法、データ検索プログラム、データ登録装置、データ登録方法、データ登録プログラムおよび情報処理装置 |
US9391965B2 (en) | 2012-01-25 | 2016-07-12 | Mitsubishi Electric Corporation | Data search device, data search method, data search program, data registration device, data registration method, data registration program, and information processing device |
WO2013111284A1 (ja) * | 2012-01-25 | 2013-08-01 | 三菱電機株式会社 | データ検索装置、データ検索方法、データ検索プログラム、データ登録装置、データ登録方法、データ登録プログラムおよび情報処理装置 |
USRE48146E1 (en) | 2012-01-25 | 2020-08-04 | Mitsubishi Electric Corporation | Data search device, data search method, computer readable medium storing data search program, data registration device, data registration method, computer readable medium storing data registration program, and information processing device |
US10235539B2 (en) | 2013-02-25 | 2019-03-19 | Mitsubishi Electric Corporation | Server device, recording medium, and concealed search system |
US20140373176A1 (en) * | 2013-06-18 | 2014-12-18 | International Business Machines Corporation | Providing access control for public and private document fields |
US9069986B2 (en) * | 2013-06-18 | 2015-06-30 | International Business Machines Corporation | Providing access control for public and private document fields |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR100753932B1 (ko) | 컨텐츠 암호화 방법, 이를 이용한 네트워크를 통한 컨텐츠제공 시스템 및 그 방법 | |
US9461817B2 (en) | Method and system for encrypting JavaScript object notation (JSON) messages | |
EP1920354B1 (en) | Remotely accessing protected files via streaming | |
US8744076B2 (en) | Method and apparatus for encrypting data to facilitate resource savings and tamper detection | |
US20120290837A1 (en) | Method and system for secured management of online XML document services through structure-preserving asymmetric encryption | |
JP2002278970A (ja) | 文書管理システム | |
JP5231522B2 (ja) | コンテンツ配信システム、コンテンツ配信装置、端末装置、コンテンツ配信プログラムおよびコンテンツ配信方法 | |
JP2005284915A (ja) | 情報検索装置および方法、ならびに情報検索システムおよびその制御方法 | |
JP2004096754A (ja) | 一方向関数を使用する階層的暗号化装置及び方法 | |
JP2005516278A (ja) | 情報を秘密保護して送信および分配し、中間情報記憶媒体において送信された情報の物理的な例示を行う方法およびシステム | |
JP4226534B2 (ja) | コンテンツ多段暗号化システムおよびコンテンツ多段暗号化プログラム | |
US8195959B2 (en) | Encrypting a credential store with a lockbox | |
JP5573272B2 (ja) | デジタルコンテンツの配信プログラム,再生プログラム,配信装置及び再生装置 | |
JP2004072151A (ja) | ファイル暗号化機能を有する端末装置 | |
JP2008177752A (ja) | 鍵管理装置、端末装置、コンテンツ管理装置およびコンピュータプログラム | |
JP2006244420A (ja) | 識別情報生成管理装置およびシステムならびにプログラム | |
JP2018180408A (ja) | 暗号処理方法、暗号処理システム、暗号化装置、復号装置、プログラム | |
JP2004234538A (ja) | 暗号化データ共有システム | |
US20020184490A1 (en) | Anti-piracy network storage device | |
JP2005346310A (ja) | 情報処理装置および方法ならびに情報処理システム | |
JP4220671B2 (ja) | 暗号化データ通信方法並びにそのための暗号化データ生成システム及び記録媒体 | |
JP2009104327A (ja) | ファイル管理システム及びファイル管理プログラム | |
JP2005328238A (ja) | コンテンツ提供システムおよびその方法 | |
WO2021044465A1 (ja) | 暗号化装置、復号装置、コンピュータプログラム、暗号化方法、復号方法及びデータ構造 | |
Santos et al. | Secure Javascript Object Notation (SecJSON) Enabling granular confidentiality and integrity of JSON documents |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070130 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070130 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20091019 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20100301 |