図面 (/)

技術 検索処理方法、データ生成方法及び情報処理装置

出願人 富士通株式会社
発明者 野田敏達
出願日 2012年11月13日 (8年0ヶ月経過) 出願番号 2012-249500
公開日 2014年5月29日 (6年5ヶ月経過) 公開番号 2014-098990
状態 特許登録済
技術分野 検索装置 暗号化・復号化装置及び秘密通信
主要キーワード 偽データ データ登録装置 グループ生成 クエリ生成 グループ構成 検索結果数 検索頻度 検索クエリー
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2014年5月29日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

解決手段

本方法は、データ格納部に格納された複数のデータブロックに含まれるインデックスの複数の値をグループ化し、複数のデータブロックの各々について、当該データブロックに含まれるインデックスの値が属するグループ識別するデータを特定し、複数のデータブロックの各々について、当該データブロックについて特定された上記データと当該データブロックの暗号化データとを含む検索用データを生成する処理を含む。

概要

背景

検索のためのインデックス値秘匿化してデータベース登録し、当該データベースに対する検索時にもキーワードを秘匿したまま検索するという要求が存在する。このため、例えば、検索のためのインデックス値を、鍵付ハッシュ関数で暗号化してデータベースに登録して検索に用いる方法がある。

例えば図1のようなデータを考える。一番右の「詳細」の列以外の5列は検索用インデックスだとする。図1のまま登録するとデータベースの管理者からデータを秘匿できないので、暗号化して登録する。

そこで、例えば図2のように暗号化することが考えられる。Hk()は鍵付ハッシュ関数で、例えばHMAC(Keyed-Hashing for Message Authentication code)などである。Ek()は可逆暗号化関数で、たとえばAES(Advanced Encryption Standard)などである。

図2を見ても、鍵Kを知らないデータベースの管理者等からは平文(すなわち元データ)を一般的には知ることはできない。一方、鍵Kを知っている利用者は検索用インデックス値を使って検索をすることができる。例えば、「姓=佐」の行を知りたい場合は、「姓=Hk(佐藤)」を指定した検索クエリーを用いれば、データベースから検索結果(1行目、... など)を得ることができる。

しかしながら、攻撃者(データベースの管理者など)が平文の出現頻度を知っている場合には、攻撃者は検索用インデックス値の平文を推測できてしまうという問題がある。

例えば、「姓」の平文として、「佐藤」が最頻出であることを攻撃者が知っているとする。そこで、図3に模式的に示すように、図2の「姓」列の出現頻度についてヒストグラムを生成すると、「姓」列の値「HK(佐藤)」が最頻出であると分かれば、攻撃者は、その値の平文は「佐藤」であると容易に推測できる。

また、平文をいくつかの別の平文に変換し、秘匿化文(例えばハッシュ値)の頻度を均一にすることで、頻度情報からの平文推測を防ぐ技術がある。例えば、「姓」の頻度情報として、図4左に示すように、「佐藤」は「山田」の2.5倍頻出するものとする。そうすると、図4右に模式的に示すように、例えば「佐藤」を「佐藤1」乃至「佐藤5」の5種類の値のいずれかにランダムに変換し、「山田」を「山田1」と「山田2」の2種類の値のどちらかにランダムに変換する。そうすると、「佐藤」と「山田」についての変換後のインデックス値の出現頻度は均一化される。そして、図5に示すように、変換後のインデックス値の鍵付ハッシュ値の頻度も均一化されるため、データベースの管理者は暗号文の出現頻度から平文を推測することができない。この例では、少なくとも「佐藤」と「山田」のいずれであるかは分からない。

しかし、この従来技術には、検索結果の頻度から平文を推測されることへの対策がない。例えば、上で述べた例において、利用者が「姓=佐藤」の行を抽出する状況を考える。「佐藤」から「佐藤1」乃至「佐藤5」への変換はランダムであるので、それら個々の値を独立に検索する理由はない。すなわち、「姓=佐藤」の行を知りたい場合、「姓=Hk(佐藤1)」乃至「姓=HK(佐藤5)」の5種類の検索クエリーを短時間内に発行することになる。

その検索結果の行数の総和は、元々「姓=佐藤」だった行数に一致する。よって、データベースの管理人等が、図6に模式的に示すように、検索クエリーとその結果を何度も観測していると、「姓」に対する検索クエリーについて、短時間内の検索結果に含まれる行番号のうち他の検索結果でも必ず共起する行番号の集合を抽出し、図7に示すようにヒストグラムを生成してみる。そうすると、含まれる行の数が最も多い集合が、「姓」が平文「佐藤」の行の集合であることが推定できる。また、含まれる行の数が最も多い集合の行数×約0.4が行数となっている集合についても、「姓」が平文「山田」の行の集合であることを推測できる。このような検索結果における共起をも考慮に入れないと、検索用インデックス値を推測されてしまう。

なお、別の従来技術として、検索クエリーに偽データを含めることで検索クエリーの秘匿性を確保する技術がある。しかし、この従来技術は、あくまで検索クエリーの秘匿性を確保するためのものであり、検索結果における頻度から平文を推測されることへの対策にはならない。

たとえば、前述の例で、「姓=佐藤」の行を知りたい場合、この従来技術では「姓=HK(佐藤1)」乃至「姓=HK(佐藤5)」の5種類に加え「姓=ランダム値」の検索クエリーを短時間内に発行し、「姓=HK(佐藤1)」乃至「姓=HK(佐藤5)」の5種類の検索結果の行を抽出する。しかし、ランダム値が鍵付ハッシュ値に一致することはほぼ無いので、やはり、データベースの管理者等が検索結果を観測すれば、上と同じ方法で、「姓」が平文「佐藤」の行の集合を推定することができる。また、たとえランダム値が「HK(山田1)」などに一致することがあっても、別のランダム値を使った検索結果との共通行集合を求めることで、やはりその共通行集合に含まれる行の「姓」が平文「佐藤」であることを推測できる。

例えば、7行のレコードが登録されていて、「佐藤」に相当する行は {1, 3, 4, 6, 7}行目だとする。短時間内のある検索結果は {1, 2, 3, 4, 6, 7} 行目であり、他のある検索結果は {1, 3, 4, 5, 6, 7}行目であるかもしれない。しかし、どの検索結果を見ても、1行目が含まれているときは常に {1, 3, 4, 6, 7} 行目が含まれているため、その集合に含まれる{1, 3, 4, 6, 7} 行は、頻度が最多の「佐藤」であると推測できてしまう。

概要

データベースのインデックス値を秘匿する。本方法は、データ格納部に格納された複数のデータブロックに含まれるインデックスの複数の値をグループ化し、複数のデータブロックの各々について、当該データブロックに含まれるインデックスの値が属するグループ識別するデータを特定し、複数のデータブロックの各々について、当該データブロックについて特定された上記データと当該データブロックの暗号化データとを含む検索用データを生成する処理を含む。

目的

特開2010−267227号公報




伊藤隆, 服部 充洋,田 規,井 祐介, 太田 和夫.頻度分析耐性を持つ高速秘匿検索方式.電子情報通信学会技術研究報告. ISEC,情報セキュリティ, Vol. 110, Num. 443, pp. 1-6, 2011.






従って、本技術の目的は、一側面によれば、データベースのインデックス値を秘匿するための技術を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

データ格納部に格納された複数のデータブロックに含まれるインデックスの複数の値をグループ化し、前記複数のデータブロックの各々について、当該データブロックに含まれるインデックスの値が属するグループ識別するデータを特定し、前記複数のデータブロックの各々について、当該データブロックについて特定された前記データと当該データブロックの暗号化データとを含む検索用データを生成する処理を含み、コンピュータにより実行されるデータ生成方法

請求項2

前記グループを識別するデータが、グループの識別子又はグループに含まれるインデックスのハッシュ値である請求項1記載のデータ生成方法。

請求項3

前記グループ化する処理が、所属するインデックスの値を含むデータブロックの数のばらつきが最小又は所定の許容範囲内であるように、前記インデックスの値をグループ化する処理を含む請求項1又は2記載のデータ生成方法。

請求項4

前記グループ化する処理が、前記インデックスの複数の値のうち最も多く出現する値の出現回数に応じてグループ数を決定する処理を含む請求項1乃至3のいずれか1つ記載のデータ生成方法。

請求項5

前記グループ化する処理が、前記インデックスの複数の値のうち最も多く出現する値の出現回数とグループ数との積が前記複数のデータブロックの数を超えないように前記グループ数を決定する処理を含む請求項1乃至3のいずれか1つ記載のデータ生成方法。

請求項6

第1のコンピュータが、インデックスの値を含む検索条件受け付け、インデックスの値が属するグループを特定するためのデータを格納するデータ格納部から、前記検索条件に含まれる前記インデックスの値が属するグループを特定し、前記グループを識別するデータを含む検索要求を生成して、所属するグループを識別するデータと対応する暗号化データブロックとを各々含む複数の検索用データブロックを保持する第2のコンピュータに対して送信し、前記第2のコンピュータから、前記検索要求に応じた1又は複数の暗号化データブロックを受信し、前記検索要求に応じた1又は複数の暗号化データブロックを復号することで1又は複数の平文データブロックを生成し、前記1又は複数の平文データブロックから、前記検索条件を満たす平文データブロックを抽出する処理を実行する検索方法

請求項7

前記グループを識別するデータが、前記グループの識別子又は前記グループに属するインデックスのハッシュ値である請求項6記載の検索方法。

請求項8

データ格納部に格納された複数のデータブロックに含まれるインデックスの複数の値をグループ化し、前記複数のデータブロックの各々について、当該データブロックに含まれるインデックスの値が属するグループを識別するデータを特定し、前記複数のデータブロックの各々について、当該データブロックについて特定された前記データと当該データブロックの暗号化データとを含む検索用データを生成する処理を、コンピュータに実行させるためのデータ生成プログラム

請求項9

第1のコンピュータに、インデックスの値を含む検索条件を受け付け、インデックスの値が属するグループを特定するためのデータを格納するデータ格納部から、前記検索条件に含まれる前記インデックスの値が属するグループを特定し、前記グループを識別するデータを含む検索要求を生成して、所属するグループを識別するデータと対応する暗号化データブロックとを各々含む複数の検索用データブロックを保持する第2のコンピュータに対して送信し、前記第2のコンピュータから、前記検索要求に応じた1又は複数の暗号化データブロックを受信し、前記検索要求に応じた1又は複数の暗号化データブロックを復号することで1又は複数の平文データブロックを生成し、前記1又は複数の平文データブロックから、前記検索条件を満たす平文データブロックを抽出する処理を実行させるための検索プログラム

請求項10

データ格納部に格納された複数のデータブロックに含まれるインデックスの複数の値をグループ化するグループ化部と、前記複数のデータブロックの各々について、当該データブロックに含まれるインデックスの値が属するグループを識別するデータを特定し、前記複数のデータブロックの各々について、当該データブロックについて特定された前記データと当該データブロックの暗号化データとを含む検索用データを生成する生成部と、を有する情報処理装置

請求項11

インデックスの値を含む検索条件を受け付ける入力部と、インデックスの値が属するグループを特定するためのデータを格納するデータ格納部から、前記検索条件に含まれる前記インデックスの値が属するグループを特定し、前記グループを識別するデータを含む検索要求を生成する生成部と、所属するグループを識別するデータと対応する暗号化データブロックとを各々含む複数の検索用データブロックを保持する他のコンピュータに対して、前記検索要求を送信する送信部と、前記他のコンピュータから、前記検索要求に応じた1又は複数の暗号化データブロックを受信する受信部と、前記検索要求に応じた1又は複数の暗号化データブロックを復号することで1又は複数の平文データブロックを生成し、前記1又は複数の平文データブロックから、前記検索条件を満たす平文データブロックを抽出する抽出部と、を有する情報処理装置。

技術分野

0001

本技術は、情報の秘匿検索技術に関する。

背景技術

0002

検索のためのインデックス値秘匿化してデータベース登録し、当該データベースに対する検索時にもキーワードを秘匿したまま検索するという要求が存在する。このため、例えば、検索のためのインデックス値を、鍵付ハッシュ関数で暗号化してデータベースに登録して検索に用いる方法がある。

0003

例えば図1のようなデータを考える。一番右の「詳細」の列以外の5列は検索用インデックスだとする。図1のまま登録するとデータベースの管理者からデータを秘匿できないので、暗号化して登録する。

0004

そこで、例えば図2のように暗号化することが考えられる。Hk()は鍵付ハッシュ関数で、例えばHMAC(Keyed-Hashing for Message Authentication code)などである。Ek()は可逆暗号化関数で、たとえばAES(Advanced Encryption Standard)などである。

0005

図2を見ても、鍵Kを知らないデータベースの管理者等からは平文(すなわち元データ)を一般的には知ることはできない。一方、鍵Kを知っている利用者は検索用インデックス値を使って検索をすることができる。例えば、「姓=佐」の行を知りたい場合は、「姓=Hk(佐藤)」を指定した検索クエリーを用いれば、データベースから検索結果(1行目、... など)を得ることができる。

0006

しかしながら、攻撃者(データベースの管理者など)が平文の出現頻度を知っている場合には、攻撃者は検索用インデックス値の平文を推測できてしまうという問題がある。

0007

例えば、「姓」の平文として、「佐藤」が最頻出であることを攻撃者が知っているとする。そこで、図3に模式的に示すように、図2の「姓」列の出現頻度についてヒストグラムを生成すると、「姓」列の値「HK(佐藤)」が最頻出であると分かれば、攻撃者は、その値の平文は「佐藤」であると容易に推測できる。

0008

また、平文をいくつかの別の平文に変換し、秘匿化文(例えばハッシュ値)の頻度を均一にすることで、頻度情報からの平文推測を防ぐ技術がある。例えば、「姓」の頻度情報として、図4左に示すように、「佐藤」は「山田」の2.5倍頻出するものとする。そうすると、図4右に模式的に示すように、例えば「佐藤」を「佐藤1」乃至「佐藤5」の5種類の値のいずれかにランダムに変換し、「山田」を「山田1」と「山田2」の2種類の値のどちらかにランダムに変換する。そうすると、「佐藤」と「山田」についての変換後のインデックス値の出現頻度は均一化される。そして、図5に示すように、変換後のインデックス値の鍵付ハッシュ値の頻度も均一化されるため、データベースの管理者は暗号文の出現頻度から平文を推測することができない。この例では、少なくとも「佐藤」と「山田」のいずれであるかは分からない。

0009

しかし、この従来技術には、検索結果の頻度から平文を推測されることへの対策がない。例えば、上で述べた例において、利用者が「姓=佐藤」の行を抽出する状況を考える。「佐藤」から「佐藤1」乃至「佐藤5」への変換はランダムであるので、それら個々の値を独立に検索する理由はない。すなわち、「姓=佐藤」の行を知りたい場合、「姓=Hk(佐藤1)」乃至「姓=HK(佐藤5)」の5種類の検索クエリーを短時間内に発行することになる。

0010

その検索結果の行数の総和は、元々「姓=佐藤」だった行数に一致する。よって、データベースの管理人等が、図6に模式的に示すように、検索クエリーとその結果を何度も観測していると、「姓」に対する検索クエリーについて、短時間内の検索結果に含まれる行番号のうち他の検索結果でも必ず共起する行番号の集合を抽出し、図7に示すようにヒストグラムを生成してみる。そうすると、含まれる行の数が最も多い集合が、「姓」が平文「佐藤」の行の集合であることが推定できる。また、含まれる行の数が最も多い集合の行数×約0.4が行数となっている集合についても、「姓」が平文「山田」の行の集合であることを推測できる。このような検索結果における共起をも考慮に入れないと、検索用インデックス値を推測されてしまう。

0011

なお、別の従来技術として、検索クエリーに偽データを含めることで検索クエリーの秘匿性を確保する技術がある。しかし、この従来技術は、あくまで検索クエリーの秘匿性を確保するためのものであり、検索結果における頻度から平文を推測されることへの対策にはならない。

0012

たとえば、前述の例で、「姓=佐藤」の行を知りたい場合、この従来技術では「姓=HK(佐藤1)」乃至「姓=HK(佐藤5)」の5種類に加え「姓=ランダム値」の検索クエリーを短時間内に発行し、「姓=HK(佐藤1)」乃至「姓=HK(佐藤5)」の5種類の検索結果の行を抽出する。しかし、ランダム値が鍵付ハッシュ値に一致することはほぼ無いので、やはり、データベースの管理者等が検索結果を観測すれば、上と同じ方法で、「姓」が平文「佐藤」の行の集合を推定することができる。また、たとえランダム値が「HK(山田1)」などに一致することがあっても、別のランダム値を使った検索結果との共通行集合を求めることで、やはりその共通行集合に含まれる行の「姓」が平文「佐藤」であることを推測できる。

0013

例えば、7行のレコードが登録されていて、「佐藤」に相当する行は {1, 3, 4, 6, 7}行目だとする。短時間内のある検索結果は {1, 2, 3, 4, 6, 7} 行目であり、他のある検索結果は {1, 3, 4, 5, 6, 7}行目であるかもしれない。しかし、どの検索結果を見ても、1行目が含まれているときは常に {1, 3, 4, 6, 7} 行目が含まれているため、その集合に含まれる{1, 3, 4, 6, 7} 行は、頻度が最多の「佐藤」であると推測できてしまう。

0014

特開2010−267227号公報

先行技術

0015

伊藤隆, 服部 充洋,田 規,井 祐介, 太田 和夫.頻度分析耐性を持つ高速秘匿検索方式.電子情報通信学会技術研究報告. ISEC,情報セキュリティ, Vol. 110, Num. 443, pp. 1-6, 2011.

発明が解決しようとする課題

0016

従って、本技術の目的は、一側面によれば、データベースのインデックス値を秘匿するための技術を提供することである。

課題を解決するための手段

0017

本技術の第1の態様に係るデータ生成方法は、(A)データ格納部に格納された複数のデータブロックに含まれるインデックスの複数の値をグループ化し、(B)複数のデータブロックの各々について、当該データブロックに含まれるインデックスの値が属するグループ識別するデータを特定し、(C)複数のデータブロックの各々について、当該データブロックについて特定された上記データと当該データブロックの暗号化データとを含む検索用データを生成する処理を含む。

0018

本技術の第2の態様に係る検索方法は、第1のコンピュータにより実行され、(A)インデックスの値を含む検索条件受け付け、(B)インデックスの値が属するグループを特定するためのデータを格納するデータ格納部から、検索条件に含まれるインデックスの値が属するグループを特定し、(C)グループを識別するデータを含む検索要求を生成して、所属するグループを識別するデータと対応する暗号化データブロックとを各々含む複数の検索用データブロックを保持する第2のコンピュータに対して送信し、(D)第2のコンピュータから、検索要求に応じた1又は複数の暗号化データブロックを受信し、(E)検索要求に応じた1又は複数の暗号化データブロックを復号することで1又は複数の平文データブロックを生成し、(F)1又は複数の平文データブロックから、検索条件を満たす平文データブロックを抽出する処理を含む。

発明の効果

0019

一側面によれば、データベースのインデックス値を秘匿できるようになる。

図面の簡単な説明

0020

図1は、検索対象データの一例を示す図である。
図2は、暗号化された検索対象データの一例を示す図である。
図3は、攻撃者による攻撃を説明するための図である。
図4は、従来技術を説明するための図である。
図5は、従来技術を説明するための図である。
図6は、従来技術の問題点を説明するための図である。
図7は、従来技術の問題点を説明するための図である。
図8は、本技術の実施の形態におけるシステム概要図である。
図9は、データ登録装置機能ブロック図である。
図10は、データ登録装置の第1データ格納部に格納されるデータの一例を示す図である。
図11は、データ検索装置の機能ブロック図である。
図12は、データ登録装置により実行される処理の処理フローを示す図である。
図13は、インデックス値の出現回数計数結果の一例を示す図である。
図14は、グループ構成データの一例を示す図である。
図15は、グループ構成データの一例を示す図である。
図16は、データ登録装置により実行される処理の処理フローを示す図である。
図17は、秘匿化データの一例を示す図である。
図18は、データ検索装置により実行される処理の処理フローを示す図である。
図19は、第1の実施の形態に係るクエリ生成処理の処理フローを示す図である。
図20は、抽出処理の処理フローの一例を示す図である。
図21は、第2の実施の形態におけるグループ構成のデータの一例を示す図である。
図22は、第2の実施の形態においてデータ登録処理により実行される処理の処理フローを示す図である。
図23は、第2の実施の形態における秘匿化データの一例を示す図である。
図24は、第2の実施の形態におけるクエリ生成処理の処理フローを示す図である。
図25は、第3の実施の形態においてデータ登録処理により実行される処理の処理フローを示す図である。
図26は、コンピュータの機能ブロック図である。

実施例

0021

[実施の形態1]
本技術の実施の形態に係るシステムの概要を図8に示す。例えばインターネットなどのネットワーク1には、クラウドなどに含まれる検索サーバ7と、1又は複数のデータ検索装置5と、データ登録装置3とが接続されている。検索サーバ7は、秘匿化されたデータを蓄積しているデータベース(DB)71を管理し、データ検索装置5からの検索要求(すなわちクエリ)に応じて検索を行って、検索結果を返信する。検索サーバ7自体の処理は従前とほぼ同様であるからここではこれ以上説明しない。データ検索装置5は、特定のインデックス値を含む検索条件を受け付けると、以下で述べるような処理を行って処理結果を含むクエリを検索サーバ7に送信する。そして、データ検索装置5は、検索サーバ7から検索結果を受信し、検索結果から検索条件に合致する検索結果を抽出する。データ登録装置3は、以下で述べるような処理が行われたデータを、検索サーバ7のデータベース71に登録する処理を実行する。

0022

図9に、データ登録装置3の機能ブロック図を示す。データ登録装置3は、第1データ格納部31と、グループ構成生成部32と、第2データ格納部33と、秘匿化データ生成部34と、第4データ格納部35と、第3データ格納部36と、登録処理部37とを有する。

0023

第1データ格納部31には、例えば図10に示すようなデータが格納されている。図10の例では、姓と名と生年月日とが検索用インデックス(検索キーとも呼ぶ)として設定されており、姓と名と生年月日とで特定される患者属性データとしてカルテの内容が登録されている。このようなデータにおけるレコードをデータブロックとも呼ぶことにする。

0024

グループ構成生成部32は、以下で述べる処理を行うことで、検索用インデックスの各々についてインデックス値のグループ化を行って、グループ構成を表すデータを第2データ格納部33に格納する。第4データ格納部35は、共通鍵暗号の暗号鍵Kのデータを格納している。

0025

秘匿化データ生成部34は、第2データ格納部33に格納されているグループ構成のデータを用いて、第1データ格納部31に格納されている各レコードに含まれる各検索用インデックスの値に対して、当該検索用インデックスの値が属するグループの識別子(又はグループを特定するためのデータ)を特定する。そして秘匿化データ生成部34は、第4データ格納部35に格納されている暗号鍵で各レコードを暗号化すると共に、特定されたグループの識別子を検索用インデックスとして付加した秘匿化データを生成し、第3データ格納部36に格納する。

0026

登録処理部37は、第3データ格納部36に格納されている秘匿化データを検索サーバ7に送信し、検索サーバ7が、その秘匿化データをデータベース71へ登録させる。

0027

図11に、データ検索装置5の機能ブロック図を示す。データ検索装置5は、入力部51と、第1データ格納部52と、第2データ格納部53と、クエリ生成部54と、第3データ格納部55と、送信部56と、受信部57と、第4データ格納部58と、抽出部59と、第5データ格納部60と、出力部61と、第6データ格納部62とを有する。

0028

入力部51は、ユーザから検索用インデックスの値を含む検索条件の入力を受け付け、第1データ格納部52に格納する。

0029

第2データ格納部53は、データ登録装置3のグループ構成生成部32により生成されたグループ構成のデータを格納する。グループ構成のデータについては、検索サーバ7に登録しておき、データ検索装置5が検索サーバ7からダウンロードしても良いし、データ登録装置3が、データ検索装置5へ配布するようにしても良い。グループ構成のデータを配布する手法は、これ以外のどのような手法を採用しても良い。

0030

クエリ生成部54は、第2データ格納部53に格納されているグループ構成のデータに従って、第1データ格納部52に格納されている検索条件に含まれる検索用インデックスの値に対応するグループの識別子(又はグループを特定されるためのデータ)を特定し、入力された検索条件を当該グループの識別子を含む検索条件に変換してクエリを生成し、第3データ格納部55に格納する。

0031

送信部56は、第3データ格納部55にクエリのデータが格納されると、検索サーバ7に送信する。

0032

受信部57は、検索サーバ7から検索結果を受信すると、第4データ格納部58に格納する。検索結果については、暗号化されたレコードを含む。また、第6データ格納部62は、共通鍵暗号の暗号鍵Kのデータを格納している。この暗号鍵Kのデータについても、グループ構成のデータと同様に配布されるものとする。

0033

抽出部59は、第4データ格納部58に格納されている暗号化されたレコードを、第6データ格納部62に格納されている暗号鍵Kで復号すると共に、第1データ格納部52に格納されている検索条件を満たしているか否かを判断して、この検索条件を満たしていると判断した場合には、第5データ格納部60に格納する。

0034

出力部61は、第5データ格納部60に格納されているレコードのデータを表示装置印刷装置などの出力装置に出力する。

0035

次に、本実施の形態に係るデータ登録装置3により実行される処理について図12乃至図17を用いて説明する。

0036

まず、グループ構成生成部32は、第1データ格納部31に格納されているデータにおける未処理の検索用インデックスを1つ特定する(図12:ステップS1)。そして、グループ構成生成部32は、特定されたインデックスについて、出現する各インデックス値の出現回数を計数する(ステップS3)。例えば、図13に示すようなデータが生成される。図13の例では、インデックス値(A乃至G)と、対応する出現回数とが格納される。

0037

その後、グループ構成生成部32は、出現回数の最大値を特定する(ステップS5)。図13の例では「A」が特定される。

0038

そして、グループ構成生成部32は、出現回数最大値×グループ数Gがレコード総数を超えないように、グループ数Gを決定する(ステップS7)。

0039

グループの数は多い方がよいので、例えばレコード総数/出現回数最大値における整数部分をグループ数Gとして採用する。グループ数が得られれば、レコード総数/グループ数により1グループあたりのレコード数が得られる。

0040

例えば、図13の例では、レコード総数は「33」であり、出現回数最大値は10であって、33/10=3.3であるからグループ数G=3となる。また、33/3=11であるから、1グループあたりのレコード数は「11」となる。

0041

その後、グループ構成生成部32は、出現するインデックス値についての全グループ構成のうち、グループに所属するインデックス値を含むレコードの数のうち最多レコード数と最少レコード数との比が最小となるグループ構成を特定し、第2データ格納部33に格納する(ステップS9)。

0042

このステップでは、できるだけグループに属するインデックス値を含むレコードの数が均等になるようにグループ構成を決定するものである。すなわち、グループに属するレコードの数にばらつきが可能な限り小さくなるようにグループ構成を決定する。ここでは、上で述べたように、最多レコード数/最少レコード数が最小となるようなグループ構成を特定するため、各グループに属するインデックス値の組み合わせのバリエーションを全て抽出して、最多レコード数/最小レコード数で得られる評価値が最小となるようなバリエーションを最適なグループ構成として特定する。なお、最適化のアルゴリズムを適用して総当たりではなく効率的に最適なグループ構成を特定するようにしても良い。

0043

図13の例では、第1のグループにはインデックス値「A」及び「G」が属し、第2のグループにはインデックス値「B」及び「E」が属し、第3のグループにはインデックス値「C」「D」及び「F」が属するようなグループ構成であれば、上記評価値が「1」となり、各グループについてのレコード数が「11」で均等になるので、最適なグループ構成であると特定される。

0044

従って、図13の例では、図14に示すようなデータが、グループ構成のデータとして第2データ格納部33に格納される。図14の例では、インデックス名と、グループIDと、当該グループに属するインデックス値とが対応付けて格納されている。

0045

その後、グループ構成生成部32は、第1データ格納部31に未処理の検索用インデックスが存在しているか判断する(ステップS11)。未処理の検索用インデックスが存在する場合には、処理ステップS1に戻る。一方、未処理の検索用インデックスが存在しない場合には、処理は端子Aを介して図16の処理に移行する。

0046

なお、このようなループの処理が終了すると、図10のようなデータについて図15に示すようなデータが生成される。図15の例では、インデックス名と、グループIDと、当該グループに属するインデックス値集合とが登録されるようになっている。

0047

図16の処理の説明に移行して、秘匿化データ生成部34は、第1データ格納部31に格納されているレコードのうち、未処理のレコードを1つ特定する(ステップS13)。そして、秘匿化データ生成部34は、特定されたレコードにおける各検索用インデックスについてのグループIDを特定する(ステップS15)。

0048

また、秘匿化データ生成部34は、特定されたレコードのデータを、第4データ格納部35に格納されている暗号鍵Kを用いて暗号化する(ステップS17)。そして、秘匿化データ生成部34は、各検索用インデックスのグループID及び暗号化データを1レコード分のデータとして、第3データ格納部36に格納する(ステップS19)。

0049

その後、秘匿化データ生成部34は、第1データ格納部31に未処理のレコードが存在しているか判断する(ステップS21)。未処理のレコードが存在していれば、処理はステップS13に戻る。一方、未処理のレコードが存在していない場合には、処理はステップS23に移行する。

0050

このような処理を実行することで、図10に示すようなデータに対して、図17に示すような秘匿化データが生成される。図17の例では、検索用インデックスとして、姓についてのグループIDと、名についてのグループIDと、生年月日についてのグループIDとが登録され、レコードの実データの暗号化データもさらに登録されている。EK(X)は、暗号鍵Kで暗号化されたデータXを意味する。

0051

その後、登録処理部37は、第3データ格納部36に格納されている秘匿化データを、検索サーバ7へ送信することで、検索サーバ7が管理するDB71に登録させる(ステップS23)。

0052

このような処理を実行することで、図17に示すような秘匿化データがDB71に登録されるようになっている。検索サーバ7は、このような秘匿化データを受信すると、DB71に登録する。なお、検索サーバ7は、検索用インデックスを用いて検索を行って、該当するレコードの暗号化データを抽出する処理を行う。

0053

次に、図18乃至図20を用いて、データ検索装置5の処理内容について説明する。まず、入力部51は、ユーザから、インデックス値を含む検索条件の入力を受け付け、第1データ格納部52に格納する(ステップS31)。例えば「姓」について「佐藤」を検索するといったような検索条件の入力がなされる。「姓」=「佐藤」といった検索条件のデータが、第1データ格納部52に格納される。

0054

そして、クエリ生成部54は、第2データ格納部53に格納されているグループ構成のデータを用いて、第1データ格納部52に格納されている検索条件のデータに対して、クエリ生成処理を実行し、クエリのデータを第3データ格納部55に格納する(ステップS33)。このクエリ生成処理については、図19を用いて説明する。

0055

まず、クエリ生成部54は、検索条件に含まれるインデックス値を1つ特定する(図19:ステップS51)。そして、クエリ生成部54は、第2データ格納部53に格納されているグループ構成のデータから、特定されたインデックス値が属するグループIDを特定する(ステップS53)。「姓」=「佐藤」というインデックス値が検索条件に含まれる場合には、図15のデータから、グループIDとして「グループ1」という値が得られる。

0056

そして、クエリ生成部54は、未処理のインデックス値が検索条件に含まれているか判断する(ステップS55)。未処理のインデックス値が検索条件に含まれている場合には、処理はステップS51に戻る。一方、未処理のインデックス値が検索条件に含まれていない場合には、クエリ生成部54は、特定されたグループIDを含む検索条件を含むクエリを生成し、第3データ格納部55に格納する(ステップS57)。例えば、「姓」=「グループ1」という検索条件を含むクエリを生成する。

0057

これによって、検索サーバ7においてDB71に対する検索ができるようになる。

0058

図18の処理の説明に戻って、送信部56は、第3データ格納部55に格納されているクエリを、検索サーバ7に送信する(ステップS35)。検索サーバ7は、データ検索装置5からクエリを受信すると(ステップS37)、DB71に対してクエリによる検索処理を実行する(ステップS39)。そして、検索サーバ7は、検索結果として、該当するレコードに含まれる暗号化データを抽出する。

0059

そして、検索サーバ7は、検索結果を、クエリの送信元であるデータ検索装置5に送信する(ステップS41)。これに対してデータ検索装置5の受信部57は、検索結果を検索サーバ7から受信すると、第4データ格納部58に格納する(ステップS43)。

0060

そうすると、抽出部59は、検索結果からの抽出処理を実行し、抽出結果を第5データ格納部60に格納する(ステップS45)。抽出処理については、図20を用いて説明する。

0061

その後、出力部61は、第5データ格納部60に格納されている抽出結果を、表示装置などの出力装置に出力する(ステップS47)。

0062

これによって適切な検索結果をユーザに提示することができるようになる。

0063

次に、抽出処理について説明する。抽出部59は、第4データ格納部58に格納されている検索結果における未処理のレコードを1つ特定する(図20:ステップS61)。そうすると、抽出部59は、第6データ格納部62に格納されている暗号鍵Kを用いて、特定されたレコードを復号することで、平文レコードを生成する(ステップS63)。

0064

その後、抽出部59は、生成された平文レコードが、第3データ格納部55に格納されている検索条件に合致するものであるか判断する(ステップS65)。平文レコードには、図17に示すように「姓」などの検索用インデックスの値も含まれているので、第3データ格納部55に含まれている検索条件に合致するものであるか否かを判断できる。

0065

生成された平文レコードが、第3データ格納部55に格納されている検索条件に合致していない場合には、処理はステップS69に移行する。生成された平文レコードが、第3データ格納部55に格納されている検索条件に合致する場合には、抽出部59は、生成された平文レコードを、第5データ格納部60における抽出結果に追加する(ステップS67)。

0066

そして、抽出部59は、検索結果において未処理のレコードが存在しているか判断し(ステップS69)、未処理のレコードが存在する場合には、処理はステップS61に戻る。一方、未処理のレコードが存在しない場合には呼出元の処理に戻る。

0067

このようにすれば、余分に抽出されたレコードの中から実際に検索条件に合致しているレコードのみが抽出されるようになる。

0068

以上のように、本実施の形態によれば、グループ間検索頻度検索結果数が同程度になるので、グループIDから本来のインデックス値を推測することはできない。

0069

[実施の形態2]
第1の実施の形態では、各グループについてグループIDを付与してグループIDをインデックス値の代わりに用いる例を示したが、グループIDを別途付与せずに処理することも可能である。

0070

例えば、本実施の形態では、図15の代わりに、図21に示すようなグループ構成のデータをステップS9で生成する。図21の例では、1行が1グループを表しており、インデックス名と、1グループに属するインデックス値の集合とが対応付けられている。

0071

そして、本実施の形態では、グループIDの代わりに、インデックス値集合のハッシュ値を用いる。

0072

このため、本実施の形態では、第1の実施の形態における図16の処理の代わりに、図22の処理を実行する。

0073

秘匿化データ生成部34は、第1データ格納部31に格納されているレコードのうち、未処理のレコードを1つ特定する(ステップS71)。そして、秘匿化データ生成部34は、特定されたレコードにおける各検索用インデックスについて、該当するグループ(すなわち図21に示すようなレコード)に属するインデックス値集合のハッシュ値を算出する(ステップS73)。

0074

また、秘匿化データ生成部34は、特定されたレコードのデータを、第4データ格納部35に格納されている暗号鍵Kを用いて暗号化する(ステップS75)。そして、秘匿化データ生成部34は、各検索用インデックスについてのハッシュ値及び暗号化データを1レコード分のデータとして、第3データ格納部36に格納する(ステップS77)。

0075

その後、秘匿化データ生成部34は、第1データ格納部31に未処理のレコードが存在しているか判断する(ステップS79)。未処理のレコードが存在していれば、処理はステップS71に戻る。一方、未処理のレコードが存在していない場合には、処理はステップS81に移行する。

0076

このような処理を実行することで、図10に示すようなデータを処理すると、図23に示すような秘匿化データが生成される。図23の例では、検索用インデックスとして、姓についてのハッシュ値HKと、名についてのハッシュ値HKと、生年月日についてのハッシュ値HKとが登録され、レコードの実データの暗号化データもさらに登録されている。EK(X)は、暗号鍵Kで暗号化されたデータXを意味する。また、HK(Y)は、暗号鍵Kでハッシュ化したデータYを意味する。

0077

その後、登録処理部37は、第3データ格納部36に格納されている秘匿化データを、検索サーバ7へ送信することで、検索サーバ7が管理するDB71に登録させる(ステップS81)。

0078

このような処理を実行することで、図23に示すような秘匿化データがDB71に登録されるようになっている。検索サーバ7は、このような秘匿化データを受信すると、DB71に登録する。なお、検索サーバ7は、検索用インデックスを用いて検索を行って、該当するレコードの暗号化データを抽出する処理を行う。

0079

また、本実施の形態では、図19に示されたクエリ生成処理の代わりに、図24に示すような処理を実行する。

0080

まず、クエリ生成部54は、検索条件に含まれるインデックス値を1つ特定する(図24:ステップS91)。そして、クエリ生成部54は、第2データ格納部53に格納されているグループ構成のデータ(図23)から、特定されたインデックス値が属するグループ(すなわち図23におけるレコード)に属するインデックス値集合のハッシュ値を算出する(ステップS93)。「姓」=「佐藤」というインデックス値が検索条件に含まれる場合には、図23のデータから、「佐藤,...」についてのハッシュ値が算出される。

0081

そして、クエリ生成部54は、未処理のインデックス値が検索条件に含まれているか判断する(ステップS95)。未処理のインデックス値が検索条件に含まれている場合には、処理はステップS91に戻る。一方、未処理のインデックス値が検索条件に含まれていない場合には、クエリ生成部54は、算出されたハッシュ値を含む検索条件を含むクエリを生成し、第3データ格納部55に格納する(ステップS97)。例えば、「姓」=HK(佐藤,...)というような検索条件を含むクエリを生成する。

0082

これによって、検索サーバ7においてDB71に対する検索ができるようになる。

0083

このような実施の形態でも第1の実施の形態と同様の効果を得ることができる。

0084

[実施の形態3]
第1の実施の形態においてグループ構成のデータを生成する処理は、可能な限りグループ間においてレコード数のばらつきを抑えるための処理を含む。

0085

一方、以下で説明するように、一定の許容誤差内にばらつきを抑えるような処理を採用するようにしても良い。

0086

本実施の形態では、図12の処理の代わりに、図25に示すような処理を実行する。

0087

まず、グループ構成生成部32は、第1データ格納部31に格納されているデータにおける未処理の検索用インデックスを1つ特定する(図25:ステップS101)。そして、グループ構成生成部32は、特定されたインデックスについて、出現する各インデックス値の出現回数を計数する(ステップS103)。

0088

その後、グループ構成生成部32は、出現回数の最大値を特定する(ステップS105)。

0089

そして、グループ構成生成部32は、出現回数最大値×グループ数Gがレコード総数を超えないように、グループ数G及び1グループあたりのレコード数を決定する(ステップS107)。

0090

グループの数は多い方がよいので、例えばレコード総数/出現回数最大値における整数部分をグループ数Gとして採用する。グループ数が得られれば、レコード総数/グループ数により1グループあたりのレコード数が得られる。

0091

その後、グループ構成生成部32は、1グループあたりのレコード数に、予め設定されている許容誤差内で近づくように、レコード数が多いインデックス値から順に、インデックス値をグループに設定することで、グループ構成を特定し、第2データ格納部33に格納する(ステップS109)。

0092

図13の例では、3グループ生成することになるので、レコード数が多い「A」「B」「C」の順に、グループ1、グループ2、グループ3に所属させる。その後、グループ1には、1グループあたりのレコード数「11」に近づけるために、「G」を所属させることになる。また、グループ2には、同様に1グループあたりのレコード数「11」に近づけるために、「E」を所属させることになる。さらに、グループ3には、同様に1グループあたりのレコード数「11」に近づけるために、「D」を所属させることになる。但し、1グループあたりのレコード数「11」には「2」少なく、「F」が残っているので、「F」も、グループ3に所属させることにする。このような処理を実行することで、ステップS109で、許容誤差内においてレコード数のばらつきが均一化されたグループ構成が簡易に特定されるようになる。

0093

本実施の形態でも図15に示すようなグループ構成のデータを第2データ格納部33に格納するようにしても良いし、グループIDを含まないようにする図21に示すようなグループ構成のデータを第2データ格納部33に格納するようにしても良い。

0094

その後、グループ構成生成部32は、第1データ格納部31に未処理の検索用インデックスが存在しているか判断する(ステップS111)。未処理の検索用インデックスが存在する場合には、処理ステップS101に戻る。一方、未処理の検索用インデックスが存在しない場合には、処理は端子Aを介して図16の処理に移行する。

0095

上でも述べたように第2の実施の形態についても本実施の形態に適用するようにしても良い。

0096

以上本技術の実施の形態を説明したが、本技術はこれに限定されるものではない。

0097

例えば、処理フローについても処理結果が変わらない限り、処理順番入れ替えたり、ステップを並列に実行したりすることも可能である。また、機能ブロック図についても、プログラムモジュール構成とは一致しない場合もある。

0098

検索頻度や検索結果数が同程度になると推測さえされれば、実際のレコード数に偏りがあったとしても、攻撃者には検索頻度や検索結果数から本来の情報を推測することはできない。これにより、レコードの追加、削除等により、レコード数に変動があったとしてもグループ構成を変更しなくても良い。

0099

なお、上で述べた検索サーバ7、データ登録装置3及びデータ検索装置5は、コンピュータ装置であって、図26に示すように、メモリ2501とCPU(Central Processing Unit)2503とハードディスクドライブ(HDD:Hard Disk Drive)2505と表示装置2509に接続される表示制御部2507とリムーバブルディスク2511用のドライブ装置2513と入力装置2515とネットワークに接続するための通信制御部2517とがバス2519で接続されている。オペレーティング・システム(OS:Operating System)及び本実施例における処理を実施するためのアプリケーションプログラムは、HDD2505に格納されており、CPU2503により実行される際にはHDD2505からメモリ2501に読み出される。CPU2503は、アプリケーション・プログラムの処理内容に応じて表示制御部2507、通信制御部2517、ドライブ装置2513を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ2501に格納されるが、HDD2505に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク2511に格納されて頒布され、ドライブ装置2513からHDD2505にインストールされる。インターネットなどのネットワーク及び通信制御部2517を経由して、HDD2505にインストールされる場合もある。このようなコンピュータ装置は、上で述べたCPU2503、メモリ2501などのハードウエアとOS及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

0100

以上述べた本実施の形態をまとめると、以下のようになる。

0101

本実施の形態の第1の態様に係るデータ生成方法は、(A)データ格納部に格納された複数のデータブロックに含まれるインデックスの複数の値をグループ化し、(B)複数のデータブロックの各々について、当該データブロックに含まれるインデックスの値が属するグループを識別するデータを特定し、(C)複数のデータブロックの各々について、当該データブロックについて特定された上記データと当該データブロックの暗号化データとを含む検索用データを生成する処理を含む。

0102

このようにすれば、インデックス値の秘匿化がなされて、クエリなどからデータベースのインデックス値を推察できなくなる。

0103

さらに、上で述べたグループを識別するデータが、グループの識別子又はグループに含まれるインデックスのハッシュ値である場合もある。いずれの場合も容易に設定できる。

0104

また、上で述べたグループ化する処理が、所属するインデックスの値を含むデータブロックの数のばらつきが最小又は所定の許容範囲内であるように、インデックスの値をグループ化する処理を含むようにしても良い。このようにすれば、秘匿化のレベルが高くなる。

0105

さらに、上で述べたグループ化する処理が、インデックスの複数の値のうち最も多く出現する値の出現回数に応じてグループ数を決定する処理を含むようにしても良い。また、上で述べたグループ化する処理が、インデックスの複数の値のうち最も多く出現する値の出現回数とグループ数との積が複数のデータブロックの数を超えないようにグループ数を決定する処理を含むようにしても良い。このようにすれば、適切なグループ数を設定できるようになる。

0106

本実施の形態の第2の態様に係る検索方法は、第1のコンピュータにより実行され、(A)インデックスの値を含む検索条件を受け付け、(B)インデックスの値が属するグループを特定するためのデータを格納するデータ格納部から、検索条件に含まれるインデックスの値が属するグループを特定し、(C)グループを識別するデータを含む検索要求を生成して、所属するグループを識別するデータと対応する暗号化データブロックとを各々含む複数の検索用データブロックを保持する第2のコンピュータに対して送信し、(D)第2のコンピュータから、検索要求に応じた1又は複数の暗号化データブロックを受信し、(E)検索要求に応じた1又は複数の暗号化データブロックを復号することで1又は複数の平文データブロックを生成し、(F)1又は複数の平文データブロックから、検索条件を満たす平文データブロックを抽出する処理を含む。

0107

このように第2のコンピュータでの検索に加えて第1のコンピュータにおける抽出処理にて、検索結果が得られるようになる。

0108

なお、上で述べたグループを識別するデータが、グループの識別子又はグループに属するインデックスのハッシュ値である場合もある。

0109

なお、上で述べたような処理をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、CD−ROMなどの光ディスク光磁気ディスク半導体メモリ(例えばROM)、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。

0110

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

0111

(付記1)
データ格納部に格納された複数のデータブロックに含まれるインデックスの複数の値をグループ化し、
前記複数のデータブロックの各々について、当該データブロックに含まれるインデックスの値が属するグループを識別するデータを特定し、
前記複数のデータブロックの各々について、当該データブロックについて特定された前記データと当該データブロックの暗号化データとを含む検索用データを生成する
処理を含み、コンピュータにより実行されるデータ生成方法。

0112

(付記2)
前記グループを識別するデータが、グループの識別子又はグループに含まれるインデックスのハッシュ値である
付記1記載のデータ生成方法。

0113

(付記3)
前記グループ化する処理が、
所属するインデックスの値を含むデータブロックの数のばらつきが最小又は所定の許容範囲内であるように、前記インデックスの値をグループ化する処理
を含む付記1又は2記載のデータ生成方法。

0114

(付記4)
前記グループ化する処理が、
前記インデックスの複数の値のうち最も多く出現する値の出現回数に応じてグループ数を決定する処理
を含む付記1乃至3のいずれか1つ記載のデータ生成方法。

0115

(付記5)
前記グループ化する処理が、
前記インデックスの複数の値のうち最も多く出現する値の出現回数とグループ数との積が前記複数のデータブロックの数を超えないように前記グループ数を決定する処理
を含む付記1乃至3のいずれか1つ記載のデータ生成方法。

0116

(付記6)
第1のコンピュータが、
インデックスの値を含む検索条件を受け付け、
インデックスの値が属するグループを特定するためのデータを格納するデータ格納部から、前記検索条件に含まれる前記インデックスの値が属するグループを特定し、
前記グループを識別するデータを含む検索要求を生成して、所属するグループを識別するデータと対応する暗号化データブロックとを各々含む複数の検索用データブロックを保持する第2のコンピュータに対して送信し、
前記第2のコンピュータから、前記検索要求に応じた1又は複数の暗号化データブロックを受信し、
前記検索要求に応じた1又は複数の暗号化データブロックを復号することで1又は複数の平文データブロックを生成し、
前記1又は複数の平文データブロックから、前記検索条件を満たす平文データブロックを抽出する
処理を実行する検索方法。

0117

(付記7)
前記グループを識別するデータが、前記グループの識別子又は前記グループに属するインデックスのハッシュ値である
付記6記載の検索方法。

0118

(付記8)
データ格納部に格納された複数のデータブロックに含まれるインデックスの複数の値をグループ化し、
前記複数のデータブロックの各々について、当該データブロックに含まれるインデックスの値が属するグループを識別するデータを特定し、
前記複数のデータブロックの各々について、当該データブロックについて特定された前記データと当該データブロックの暗号化データとを含む検索用データを生成する
処理を、コンピュータに実行させるためのデータ生成プログラム

0119

(付記9)
第1のコンピュータに、
インデックスの値を含む検索条件を受け付け、
インデックスの値が属するグループを特定するためのデータを格納するデータ格納部から、前記検索条件に含まれる前記インデックスの値が属するグループを特定し、
前記グループを識別するデータを含む検索要求を生成して、所属するグループを識別するデータと対応する暗号化データブロックとを各々含む複数の検索用データブロックを保持する第2のコンピュータに対して送信し、
前記第2のコンピュータから、前記検索要求に応じた1又は複数の暗号化データブロックを受信し、
前記検索要求に応じた1又は複数の暗号化データブロックを復号することで1又は複数の平文データブロックを生成し、
前記1又は複数の平文データブロックから、前記検索条件を満たす平文データブロックを抽出する
処理を実行させるための検索プログラム

0120

(付記10)
データ格納部に格納された複数のデータブロックに含まれるインデックスの複数の値をグループ化するグループ化部と、
前記複数のデータブロックの各々について、当該データブロックに含まれるインデックスの値が属するグループを識別するデータを特定し、前記複数のデータブロックの各々について、当該データブロックについて特定された前記データと当該データブロックの暗号化データとを含む検索用データを生成する生成部と、
を有する情報処理装置

0121

(付記11)
インデックスの値を含む検索条件を受け付ける入力部と、
インデックスの値が属するグループを特定するためのデータを格納するデータ格納部から、前記検索条件に含まれる前記インデックスの値が属するグループを特定し、前記グループを識別するデータを含む検索要求を生成する生成部と、
所属するグループを識別するデータと対応する暗号化データブロックとを各々含む複数の検索用データブロックを保持する他のコンピュータに対して、前記検索要求を送信する送信部と、
前記他のコンピュータから、前記検索要求に応じた1又は複数の暗号化データブロックを受信する受信部と、
前記検索要求に応じた1又は複数の暗号化データブロックを復号することで1又は複数の平文データブロックを生成し、前記1又は複数の平文データブロックから、前記検索条件を満たす平文データブロックを抽出する抽出部と、
を有する情報処理装置。

0122

31 第1データ格納部
32グループ構成生成部
33 第2データ格納部
34秘匿化データ生成部
35 第4データ格納部
36 第3データ格納部
37登録処理部
51 入力部
52 第1データ格納部
53 第2データ格納部
54クエリ生成部
55 第3データ格納部
56 送信部
57 受信部
58 第4データ格納部
59 抽出部
60 第5データ格納部
61 出力部
62 第6データ格納部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ