JP6401875B2

JP6401875B2 - データ処理システム

Info

Publication number: JP6401875B2
Application number: JP2017567893A
Authority: JP
Inventors: 尚宜佐藤
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2016-02-18
Filing date: 2016-02-18
Publication date: 2018-10-10
Anticipated expiration: 2036-02-18
Also published as: US20210194694A1; WO2017141399A1; JPWO2017141399A1; US11290277B2

Description

本発明は、データ処理システムに係り、特に、クラウドサービスなどによりデータ預託をおこなった場合に、処理負荷をあまりかけずに、データの完全性を検証するのに好適なデータ処理システムに関する。

情報システムの開発の効率化、運用管理費の低減などを目的に、近年、情報システムを自身で保持せず、外部業者に委託するクラウドと呼ばれる運用管理形態の利用が広がっている。しかし、効率化やコスト低減の反面、クラウドにおいては、情報システムを管理する業者が、情報システムを利用するユーザとは異なるため、ユーザは外部業者も含めた第三者への機密情報漏えいや改ざんについて不安を抱くことになる。

機密情報漏洩や改ざんに対しては、暗号技術が有効であり、ＡＥＳ暗号やメッセージ認証子、デジタル署名などの従来技術によりこれらのセキュリティ要件を達成することが可能である。

一方、情報システムの適用が広がり、通常の計算機の計算能力より低い能力しか持たないセンサーや組み込み機器などにも通信機能を持たせ、情報収集などをさせる動きがある（モノのインターネット、ＩｏＴ：Internet of Thingsなどと呼ばれる）。収集される情報は有用であり、また場合によっては個人のプライバシーに関わる情報であることもあり、これらの情報の秘匿性や完全性を保証することが必要であるが、一般にセンサーなどでは計算能力が低いことからデジタル署名等の公開鍵暗号技術を適用することは効率面から望ましくないのが現状である。

共通鍵暗号技術では実装規模や処理効率の面で上記状況には適しているが、暗復号化や、メッセージ認証子の生成／検証の鍵は共通であり、送受信者が異なる場合にはその鍵の共有が問題となる。またユーザ（センサー）数が多い場合にも同一の鍵で運用するのはセキュリティ上の脆弱性を生み、望ましくない。よって、各ユーザが別々の鍵を用いるシステムが必要である。

クラウドを介して情報を送受信／共有するシステムにおいては、クラウド上の計算リソースを活用することが考えられる。共通鍵暗号技術を用いて上記の個別鍵による情報共有システムを運用する場合、クラウド管理者が全ての個別鍵を集約して持ち、復号やメッセージ認証子の再生成などをおこなったうえで、送信する方法が考えられるが、クラウドなどの計算リソースアウトソーシングにおいて、その管理者は外部のものであり、情報の漏えい、改ざんに対して強い保証をすることは困難である。そこでクラウド上の計算リソースを利用しつつ、クラウド管理者へも情報を漏らさない、また改ざんの能力を与えない方法が望まれる。

このような諸問題に関して、公開鍵暗号技術に基づく再暗号化技術を用いれば、クラウド管理者などへの情報漏えいを防ぎつつ、個別の鍵による情報の完全性保証や情報漏えい防止などが実現可能である。この公開鍵暗号技術をもとにした再暗号化技術については、例えば、特許文献１に開示がある。

国際公開第２０１２／１４７８６９号明細書

上記特許文献１に記載の再暗号化技術では、再暗号化装置が、第１ユーザの秘密鍵、第２ユーザの公開鍵、および、乱数に基づいて、再暗号化鍵を生成することにより、プロキシ再暗号化方式において、ユーザとサーバの管理者が結託した場合でも、復号権限が移譲元の許可なく再移譲されることを阻止しうるものとしている。

しかしながら、特許文献１に記載された公開鍵をベースにした再暗号化技術では、多大な処理負荷がかかるため、上記のＩｏＴ分野における計算リソースの乏しいセンサーなどでは利用が困難であるという問題点があった。

また、上記特許文献１に記載の再暗号化技術では、データを移譲されたユーザがどのようにデータの完全性を確認するかについても考慮されていない。

本発明は、上記問題点を解決するためになされたもので、その目的は、データ預託をおこなった場合に、データを移譲されたものが、処理負荷をあまりかけずに、データの完全性を検証でき、データが暗号化されている場合には、処理負荷をあまりかけずに、復号しうるデータ処理システムを提供することにある。

本発明のデータ処理システムの構成は、ユーザ端末Ａからデータをデータ保管サーバにアップロードして、ユーザ端末Ｂからデータをアクセスするデータ処理システムであり、ユーザ端末Ａとユーザ端末Ｂは、それぞれ第一の固有鍵、第二の固有鍵を有し、データ保管サーバは、付替鍵を有している。そして、ユーザ端末Ａは、一時鍵を生成し、データと一時鍵により、メッセージ認証子を生成し、一時鍵と第一の固有鍵により、第一の合成鍵を生成し、データ、第一の合成鍵、メッセージ認証子を、データ保管サーバに送信する。データ保管サーバは、受信した第一の合成鍵と付替鍵より、第二の合成鍵を生成し、データ、第二の合成鍵、メッセージ認証子を、ユーザ端末Ｂに送信する。ユーザ端末Ｂは、受信した第二の合成鍵と第二の固有鍵により、一時鍵を生成し、データと生成した一時鍵により、メッセージ認証子を生成し、生成したメッセージ認証子と、受信したメッセージ認証子を比較するようにしたものである。

また、本発明のデータ処理システムの別の構成は、ユーザ端末Ａからデータをデータ保管サーバにアップロードして、第二の端末からデータをアクセスするデータ処理システムであって、第一の端末と第二の端末は、それぞれ第一の固有鍵、第二の固有鍵を有し、データ保管サーバは、付替鍵を有している。そして、第一の端末は、一時鍵を生成し、一時鍵により、平文データより暗号化データを生成し、一時鍵と第一の固有鍵により、第一の合成鍵を生成し、暗号化データ、第一の合成鍵を、データ保管サーバに送信する。データ保管サーバは、受信した第一の合成鍵と付替鍵より、第二の合成鍵を生成し、暗号化データ、第二の合成鍵を、第二の端末に送信する。第二の端末は、受信した第二の合成鍵と第二の固有鍵により、一時鍵を生成し、生成した一時鍵により、暗号化データを復号するようにしたものである。

本発明によれば、データ預託をおこなった場合に、データを移譲されたものが、処理負荷をあまりかけずに、データの完全性を検証でき、データが暗号化されている場合には、処理負荷をあまりかけずに、復号しうるデータ処理システムを提供することができる。

第一の実施形態に係るデータ処理システムの全体構成を示す図である。データ保管サーバの機能構成図である。鍵生成サーバの機能構成図である。ユーザ端末Ａの機能構成図である。ユーザ端末Ａ（コンピュータ）のハードウェア構成図である。データ、鍵情報、メッセージ認証子の組をユーザ端末Ａが作成するまでの概要図である。ユーザ端末Ｂがデータ保管サーバに格納されたデータのデータ完全性を検証するまでの概要図である。データ、鍵情報、メッセージ認証子の組をユーザ端末Ａが作成し、データ保管サーバに送信するまでの処理を示すフローチャートである。鍵生成サーバが付替鍵を生成し、データ保管サーバに送信する処理を示すフローチャートである。データ保管サーバがデータ、鍵情報、メッセージ認証子の組を生成し、ユーザ端末Ｂに送信するまでの処理を示すフローチャートである。ユーザ端末Ｂがデータ完全性の検証をおこなう処理を示すフローチャートである。データ処理システムの処理の全体の処理を示すシーケンス図である。ユーザ端末Ａから暗号化したデータが、アップロードされたときの処理の概要図である。第二の実施形態におけるデータと鍵の受け渡しの階層構造を説明する図である（その一）。第二の実施形態におけるデータと鍵の受け渡しの階層構造を説明する図である（その二）。

以下、本発明に係る各実施形態を、図１ないし図１４Ｂを用いて説明する。

〔実施形態１〕
以下、本発明の第一の実施形態を、図１ないし図１３を用いて説明する。

先ず、図１ないし図５を用いて本発明の第一の実施形態に係るデータ処理システムのシステム構成について説明する。
図１は、第一の実施形態に係るデータ処理システムの全体構成を示す図である。
図２は、データ保管サーバの機能構成図である。
図３は、鍵生成サーバの機能構成図である。
図４は、ユーザ端末Ａの機能構成図である。
図５は、ユーザ端末Ａ（コンピュータ）のハードウェア構成図である。

本実施形態のデータ処理システムは、図１に示されるように、ユーザ端末Ａ３００、ユーザ端末Ｂ４００、鍵生成サーバ１００、データ保管サーバ２００がネットワーク６０により互いに接続された形態である。

本実施形態で、ユーザＡがユーザ端末Ａ３００により、データ保管サーバ２００にデータ預託をおこない、ユーザＢがユーザ端末Ｂ４００によりそのデータをアクセスする例を想定する。

データ保管サーバ２００は、ユーザのデータを保管し、それのアクセスを許認可するためのサーバであり、例えば、クラウドサービスによりデータ保管のサービスをおこなう事業者が運営するサーバであり、サービスを享受するエンドユーザは、ユーザ端末からデータ保管サーバ２００にデータをアップロードしたり、ダウンロードすることが可能である。ここで、ユーザ端末は、エンドユーザが、インターネットによりデータ保管サーバ２００のデータにアクセスするデスクトップコンピュータ、ノートブックコンピュータ、タブレット、スマートフォンなどの機器である。

鍵生成サーバ１００は、本実施形態のデータ処理に必要なための暗号化のための鍵を生成して、エンドユーザのユーザ端末やデータ保管サーバ２００に配布するサーバである。

データ保管サーバ２００は、図２に示されるように、機能構成として、制御部２１０と、記録部２２０と、入力部２０１と、出力部２０２と、通信部２０３を備える。

入力部２０１と、出力部２０２は、それぞれ情報の入力と出力をおこなう部分である。通信部２０３は、外部装置とのデータの送受信をおこなう部分である。制御部２１０は、この装置の各部を制御し、プログラムを実行する部分である。記録部２２０は、データやプログラムを記憶する部分である。

制御部２１０は、全体処理部２１１と、鍵付替処理部２１２を備える。

全体処理部２１１は、データ保管サーバ２００における処理を制御し、入力部２０１を介して、受け付けた情報を記録部２２０に格納する。また、ユーザ端末３００、４００との情報の送受信を制御する。さらに、全体処理部２１１は、データを出力部２０２に表示する処理をおこない、記録部２２０に格納されているデータを読み込み、通信部２０３を介して、そのデータをユーザ端末３００、４００へ送信する。

記録部２２０は、データ記録部２３０と、一時情報記録部２５０を備える。

データ記録部２３０には、ユーザデータ２３１が格納されている。ユーザデータ２３１は、ユーザ端末からアップロードされるデータであり、暗号化されていることもあるし、平文のまま格納されることもある。

鍵記録部２４０は、付替鍵２４１が格納されている。

付替鍵２４１は、ユーザの固有鍵から、固有の群演算により生成される鍵（後述）である。

一時情報記録部２５０には、制御部２１０での処理で一時的に必要となるワークデータが格納される。

ユーザ端末Ａ３００は、図３に示されるように、制御部３１０と、記録部３２０と、入力部３０１と、出力部３０２と、通信部３０３を備える。

入力部３０１と、出力部３０２は、それぞれ情報の入力と出力をおこなう部分である。通信部３０３は、外部装置とのデータの送受信をおこなう部分である。制御部３１０は、この装置の各部を制御し、プログラムを実行する部分である。記録部３２０は、データやプログラムを記憶する部分である。

制御部３１０は、全体処理部３１１と、認証子生成／暗号化処理部３１２と、復号化／認証子検証処理部３１３を備える。

全体処理部３１１は、ユーザ端末３００における処理を制御し、入力部３０１を介して、受け付けた情報を記録部３２０に格納する。また、データ保管サーバ２００との情報の送受信を制御する。

さらに、全体処理部３１１は、データを出力部３０２に表示する処理をおこない、記録部３２０に格納されているデータを読み込み、それぞれ、認証子生成／暗号化処理部３１２にデータに対するメッセージ認証子の生成やデータの暗号化をさせ、復号化／認証子検証処理部３１３に暗号化データの復号化やメッセージ認証子の検証をさせ、データを、通信部３０３を介して、データ保管サーバ２００へ送信する。

記録部３２０は、データ記録部３３０と、鍵記録部３４０と、一時情報記録部３５０を備える。

データ記録部３３０には、ユーザＡデータ３３１が記録されている。

鍵記録部３４０には、ユーザＡ固有鍵３４１が格納されている。

一時情報記録部２５０には、制御部２１０での処理で一時的に必要となるワークデータが格納される。
図示しなかったが、ユーザ端末Ｂの機能構成は、制御部３１０に、データ保管サーバ２００に保管されている他のユーザデータにアクセスし、そのデータの完全性を検証する処理部を有している。

鍵生成サーバ１００は、図４に示されるように、制御部１１０と、記録部１２０と、入力部１０１と、出力部１０２と、通信部１０３を備える。

入力部１０１と、出力部１０２は、それぞれ情報の入力と出力をおこなう部分である。通信部１０３は、外部装置とのデータの送受信をおこなう部分である。制御部１１０は、この装置の各部を制御し、プログラムを実行する部分である。記録部１２０は、データやプログラムを記憶する部分である。

制御部１１０は、全体処理部１１１と、鍵生成部１１２と、付替鍵生成部１１３を備える。

全体処理部１１１は、鍵生成サーバ１００における処理を制御し、入力部１０１を介して、受け付けた情報を記録部１２０に格納する。また、ユーザ端末３００、４００や、データ保管サーバ２００との情報の送受信を制御する。

さらに、全体処理部１１１は、データを出力部１０２に表示する処理をおこない、記録部１２０に格納されているデータを読み込み、それぞれ、鍵生成部１１２にメッセージ認証子生成／検証鍵や暗号化鍵を生成させ、付替鍵生成部１１３に付替鍵を生成する。さらに生成された鍵をユーザ端末３００、４００へ送信し、付替鍵をデータ保管サーバ２００へ送信する。

記録部１２０は、鍵記録部１４０と、一時情報記録部１５０を備える。

鍵記録部１４０には、ユーザ固有鍵１４１と、付替鍵１４２が格納される。

一時情報記録部１５０には、制御部１１０での処理で一時的に必要となるワークデータが格納される。

以上に示したユーザ端末Ａ３００は、例えば、図５に示すような、ＣＰＵ（Central Processing Unit）４０１と、主記憶装置４０２と、補助記憶装置４０３と、読書装置４０７と、入力装置４０６と、出力装置４０５と、通信装置４０４と、システムバス４０９とを備えた一般的なコンピュータ４００で実現できる。

ＣＰＵ４０１は、主記憶装置４０２上のプログラムを命令語として実行する半導体装置である。主記憶装置４０２は、ワークデータやプログラムを記憶するＲＡＭ（Random Access Memory）などの記憶装置である。補助記憶装置４０３は、ＳＤＤ（Solid State Drive）やＨＤＤ（Hard Disk Drive）等の大容量のデータ記憶装置である。読書装置４０７は、ＣＤやＤＶＤ等の可搬性を有する記録媒体４０８に対して情報を読み書きするディスクドライブなどの装置である。入力装置４０６は、キーボードやマウス等のユーザが情報を入力する装置である。出力装置４０５は、ディスプレイやプリンタ等の情報を表示、印刷するための装置である。通信装置４０４は、ＮＩＣ（Network Interface Card）等の通信ネットワークに接続するための装置である。

例えば、記録部３２０は、ＣＰＵ４０１がメモリ４０２または補助記憶装置４０３を利用することにより実現可能であり、制御部３１０と制御部３１０に含まれる各処理部は、補助記憶装置４０３に記録されている所定のプログラムをメモリ４０２にロードしてＣＰＵ４０１で実行することで実現可能である。また、入力部３０１は、ＣＰＵ４０１が入力装置４０６を利用することで実現可能であり、出力部３０２は、ＣＰＵ４０１が出力装置４０５を利用することで実現可能であり、通信部３０３は、ＣＰＵ４０１が通信装置４０４を利用することで実現可能である。

この所定のプログラムは、読書装置４０７を介して記録媒体４０８から、あるいは、通信装置４０４を介してネットワークから、補助記憶装置４０３に記録（ダウンロード）され、それから、メモリ４０２上にロードされて、ＣＰＵ４０１により実行されるようにしてもよい。また、読書装置４０７を介して、記録媒体４０８から、あるいは通信装置４０４を介してネットワークから、メモリ４０２上に直接ロードされ、ＣＰＵ４０１により実行されるようにしてもよい。

データ保管サーバ２００や鍵生成サーバ１００も同様に、図５に示すような一般的な情報処理装置の形態で実現することができる。

次に、図６ないし図１３を用いて第一の実施形態に係るデータ処理システムの処理について説明する。
図６は、データ、鍵情報、メッセージ認証子の組をユーザ端末Ａが作成するまでの概要図である。
図７は、ユーザ端末Ｂがデータ保管サーバに格納されたデータのデータ完全性を検証するまでの概要図である。
図８は、データ、鍵情報、メッセージ認証子の組をユーザ端末Ａが作成し、データ保管サーバに送信するまでの処理を示すフローチャートである。
図９は、鍵生成サーバが付替鍵を生成し、データ保管サーバに送信する処理を示すフローチャートである。
図１０は、データ保管サーバがデータ、鍵情報、メッセージ認証子の組を生成し、ユーザ端末Ｂに送信するまでの処理を示すフローチャートである。
図１１は、ユーザ端末Ｂがデータ完全性の検証をおこなう処理を示すフローチャートである。
図１２は、データ処理システムの処理の全体の処理を示すシーケンス図である。
図１３は、ユーザ端末Ａから暗号化したデータが、アップロードされたときの処理の概要図である。

本実施形態では、ユーザＡがユーザ端末Ａ３００より、データＭをデータ保管サーバ２００にアップロードし、ユーザＢがユーザ端末Ｂ４００より、そのデータＭをダウンロードして利用する際に、そのデータ完全性を検証するものとする。

先ず、鍵生成サーバ１００は、ユーザＡ固有鍵（Ｋ_Ａと表記）を生成し（図１２のＳ０１）、ユーザ端末Ａ３００に送信し（Ａ０１）、同様に、ユーザＢ固有鍵（Ｋ_Ｂと表記）を生成し（Ｓ０２）、ユーザ端末Ｂ４００に送信する（Ａ０２）。ユーザＡ固有鍵Ｋ_Ａ、ユーザＢ固有鍵Ｋ_Ｂは、所定の長さのビット列で、ランダムに生成すればよい。

ユーザＡは、ユーザ端末ＡにデータＭを入力するか、格納されているデータＭを指定し、鍵生成サーバ１００により送信されてきたユーザＡ固有鍵Ｋ_Ａを指定する（Ｓ６０１）。

次に、ユーザ端末Ａ３００は、乱数Ｒを生成する（Ｓ６０２、Ｓ０３）。

次に、生成された乱数Ｒを鍵とするメッセージ認証子（ｔａｇ＝ＭＡＣ（Ｒ，Ｍ）と表記）を計算する（Ｓ６０３、Ｓ０３）。ここで、Ｓ６０３で利用するメッセージ認証子は、ハッシュ関数を用いたものやブロック暗号を用いたものなど一般的に用いられているものでよい。

次に、乱数ＲとユーザＡ固有鍵Ｋ_Ａの合成鍵であるｋ＝（Ｒ＊Ｋ_Ａ）を計算する（Ｓ６０４、Ｓ０３）。ここで＊は、ビット列（固定長でよい）の集合上に定義された任意の群演算を表す。例えば、ビットごとの排他的論理和ＸＯＲなどを用いることができる。

次に、ユーザ端末Ａ３００は、Ｃ＝（Ｍ，ｋ，ｔａｇ）をデータ保管サーバ２００に送信する（Ａ０４）。ここで「（，）」はビット列の結合を表し、順番は入れ替えてもよい。

次に、鍵生成サーバ１００は、鍵記録部１４０の固有鍵１４１に記録しているユーザＡ固有鍵Ｋ_ＡとユーザＢ固有鍵Ｋ_Ｂを読み出し（Ｓ７０１）、付替鍵（Ｋ_Ａ→Ｂと表記）を生成する（Ｓ０４）。付替鍵Ｋ_Ａ→Ｂは、（Ｋ_Ａ）^−１＊Ｋ_Ｂにより計算される（Ｓ７０２）。ここで、（Ｋ_Ａ）^−１は、群演算＊におけるＫ_Ａの逆元である。なお、＊がビットごとの排他的論理和の場合はＫＡ^−１＝ＫＡになる。そして、鍵生成サーバ１００は、生成した付替鍵Ｋ_Ａ→Ｂを、データ保管サーバ２００に送信する（Ｓ７０３、Ａ０３）。なお、鍵生成サーバ１００は、生成した付替鍵Ｋ_Ａ→Ｂを、鍵記録部１２０に記録して保管してもよい。

次に、ユーザＢがデータ保管サーバ２００にアップロードされたデータを入手して、データの完全性を確認する手順を説明する。

ユーザＢは、ユーザ端末Ｂ４００より、アクセス認証をおこなう（Ａ０５）。データ保管サーバ２００は、認証処理をおこない（Ｓ０５）、ユーザＢにデータのアクセス権限があると認めたときは、認証ＯＫの通知をおこなう（Ａ０６）。認証の手段は、パスワード認証、生体認証などがある。

次に、データ保管サーバ２００は、付替鍵Ｋ_Ａ→Ｂを用いてｋ′＝ｋ＊Ｋ_Ａ→Ｂを計算する（Ｓ８０１、Ｓ０６）。

次に、データ保管サーバ２００は、Ｃ′＝（Ｍ，ｋ′，ｔａｇ）を、ユーザ端末Ｂ４００に送信する（Ｓ８０２、Ａ０７）。

これを受信したユーザ端末Ｂ４００は、乱数Ｒ＝ｋ′＊Ｋ_Ｂ ^−１を計算し（Ｓ９０１、Ｓ０７）、乱数Ｒを用いてメッセージ認証子（Ｍ，ｔａｇ）の検証をおこなう（Ｓ９０２、Ｓ０８）。その結果に応じて種々の対応をおこなってもよい。例えば、メッセージ認証子の検証でＮＧの場合は付替サーバに再送や、データ完全性の確認依頼をするなどしてよい。

Ｓ８０５で、乱数Ｒ＝ｋ′＊Ｋ_Ｂ ^−１となるのは、ｋ′＝ｋ＊Ｋ_Ａ→Ｂ＝（Ｒ＊Ｋ_Ａ）＊（Ｋ_Ａ ^−１＊Ｋ_Ｂ）＝Ｒ＊（Ｋ_Ａ＊Ｋ_Ａ ^−１）＊Ｋ_Ｂ＝Ｒ＊Ｋ_Ｂであるから、両辺に左から、Ｋ_Ｂ ^−１をかけて、目的の式を得ることができる。

そして、ユーザ端末Ｂ４００で、ＭとＲより、メッセージ認証子ｔａｇ′を生成し、受信したｔａｇと一致するか否かを判定することにより、データＭの完全性を検証することができる。

また、ユーザＡが、データＭを暗号化してデータ保管サーバ２００に格納するときには、図１３に示されるようにすればよい。ここでは、ユーザ端末Ａ３００で乱数Ｒを生成し、その乱数Ｒにより暗号化する（Ｓ１０００）（データＭを、暗号化した暗号化データをＣ（Ｍ）と表記する）ものとする。

そして、暗号化データＣ（Ｍ）と、合成鍵ｋの合成Ｃ_０＝（Ｃ（Ｍ），ｋ）を、データ保管サーバ２００に送信する（Ａ１０１）。データ保管サーバ２００は、Ｃ′_０＝（Ｍ，ｋ′）を生成し、ユーザ端末Ｂ４００に送信する（Ａ１０２）。ここで、付替鍵Ｋ_Ａ→Ｂ＝Ｋ_Ａ ^−１＊Ｋ_Ｂ、合成鍵ｋ＝Ｒ＊Ｋ_Ａ、合成鍵ｋ′＝ｋ＊Ｋ_Ａ→Ｂの定義は、上記と全く同様である。

ユーザＢ端末では、上記同様に、受信したｋ′と、自身のユーザＢ固有鍵Ｋ_Ｂにより、鍵となる乱数Ｒ＝ｋ′＊Ｋ_Ｂ ^−１を計算し（Ｓ１０１０）、それにより、受信したＣ（Ｍ）を復号することができる（Ｓ１０１１）。

このように、本実施形態の手法によれば、上記のようにメッセージ認証子によるデータ完全性の確認のみならず、通常のＡＥＳ（Advanced Encryption Standard：高度暗号化標準）のような共通鍵暗号を用いた暗号化、あるいはメッセージ認証と暗号化を同時に実行できる認証暗号の場合の復号にも適用することができる。

以上のように、本実施形態によれば、データの保管を委託された業者（データ保管サーバの運営業者）は、そのデータと、再暗号化方式による暗号文しか見ることができず、ユーザの固有鍵を個別にみることができないため、保管されているデータの改ざんをすること、また、暗号化してデータが保管されている場合は、その平文を導出することができない。しかしながら、付替鍵により鍵を付け替える技法により、各々のユーザに対して他のユーザの固有鍵の情報を開示することなく、別のユーザが検証や復号可能な状態に変換することができる。そのため、各ユーザは外部に預託しても情報の改ざんや情報漏えいを心配することなく、またデータ本体に比べ少ない固定長の通信を追加で行うだけで鍵の付替えに必要な計算をすべてサービス事業者である外部業者に委託することができる。

〔実施形態２〕
以下、本発明に係る第二の実施形態を、図１４Ａおよび図１４Ｂを用いて説明する。
図１４Ａ、図１４Ｂは、第二の実施形態におけるデータと鍵の受け渡しの階層構造を説明する図である。

本実施形態では、図Ｎに示されるように、階層的なツリー構造であり、ルートにあたる所に、ルートサーバ８００があり、各ノードは、ユーザがサービスを受けるノードになっている。

本実施形態のルートサーバ８００は、データ預託の上向きの最終地点であると同時に、下位階層にデータを配布するときのスタート地点でもある。また、下位から受け渡された鍵を、下位階層に受け渡す機能も有する。

各ノードの固有鍵や付替鍵は、このルートサーバ８００が生成して配布するようにしてもよいし、第一の実施形態のように、別途、鍵生成サーバを設けて、それが配布するようにしてもよい。

本実施形態のデータ処理システムでは、以下のルールを仮定する。
（ルール１）各ノードは、そのノードに固有の固有鍵を有する。
（ルール２）各ノードは、接続されたノードに、データと鍵情報の受け渡しが可能であり、受け渡し先への付替鍵を知っている（利用できる）。

また、群演算＊は、全てのノードに共通であるとする。

このルールの下で、図１４Ａに示したルートサーバ８００は、ユーザ端末Ａからユーザ端末Ｂへの付替鍵を知っており、ユーザ端末Ｂ４００は、下位階層のノードであるユーザ端末Ｂ１（４００１）、ユーザ端末Ｂ１（４００２）、ユーザ端末Ｂ３（４００３）の受け渡し先への付替鍵を知っているものとする。

このときに、ユーザＡから鍵ｋがルートサーバ８００に受け渡されときには、ルートサーバ８００では、付替鍵Ｋ_Ａ→Ｂ＝Ｋ_Ａ ^−１＊Ｋ_Ｂを用いて、ｋ′＝ｋ＊Ｋ_Ａ→Ｂに変換して、鍵情報を送信する。

そして、ユーザ端末Ｂ４００が、例えば、ユーザ端末Ｂ１（４００１）に鍵情報を送信するときには、付替鍵Ｋ_Ｂ→Ｂ１＝Ｋ_Ｂ ^−１＊Ｋ_Ｂ１を用いて、ｋ′′＝ｋ＊Ｋ_Ｂ→Ｂ１に変換して、鍵情報を送信する。

これにより、ユーザＢ１（４００１）は、データが送信されてきたときに、自身の固有鍵Ｋ_Ｂにより、メッセージ認証子によるデータの完全性検証や、暗号化されたデータの復号が可能となる。

データ預託の場合にも（ルール２）の代わりに、以下の（ルール２′）を適用することにより、ツリーのノード間で、鍵情報を受け渡すことが可能である。

（ルール２′）各ノードは、接続されたノードに、データと鍵情報の受け渡しが可能であり、受け渡し先のノードは、受け渡し元からの付替鍵を知っている（利用できる）。

この前提の下で、ユーザ端末Ａ３００は、ユーザ端末Ａ１（３００１）、ユーザ端末Ａ２（３００２）からデータと鍵情報が送られてきたときの付替鍵を知っているものとする。

このとき、例えば、ユーザ端末Ａ１（３００１）が、データＭを上位のノードのユーザ端末Ａ３００に預託し、ユーザ端末Ａ３００は、さらに、ルートサーバ８００にデータを預託するものとする。

ユーザ端末Ａ１（３００１）では、乱数Ｒを生成し、合成鍵ｋ_０＝Ｒ＊Ｋ_Ａ１を作成する（実施形態１の図６：Ｓ６０２相当）。次に、メッセージ認証子ｔａｇ＝ＭＡＣ（Ｒ，Ｍ）を計算し（実施形態１の図６：Ｓ６０３相当）、Ｃ_１＝（Ｍ，ｋ_０，ｔａｇ）を、ユーザ端末Ａ３００に送信する。

ユーザ端末Ａ３００では、付替鍵Ｋ_Ａ１→Ａ＝Ｋ_Ａ１ ^−１＊Ｋ_Ａを用いて、合成鍵ｋ′_０＝ｋ_０＊Ｋ_Ａ１→Ａを生成し、Ｃ_１′＝（Ｍ，ｋ_０′，ｔａｇ）を、ルートサーバ８００に送信する。

このようなツリー構造の階層システムで、鍵情報を運用する場合は、例えば、ユーザ端末Ａ１（３００１）やユーザ端末Ａ２（３００２）などが末端のセンサーノードであり、膨大な個数存在するときには、すべての付替鍵の管理をルートサーバ８００に委託すると処理負荷が膨大になる場合がある。このときはユーザ端末Ａ３００にいくつかの子ノード（図のように、ユーザ端末Ａ１（３００１）やユーザ端末Ａ２（３００２）など）を負担させ、ルートサーバ８００に送信する際は、ユーザ端末Ａ３００自身の鍵に付替えて送信することにより、ルートサーバ８００で扱う付替鍵の個数を減らすことが可能である。

さらに、図１４Ａ、図１４Ｂでは、３段のツリー構造で説明したが、さらに段数を増やすことにより、ルートサーバ８００が管理する付替鍵の個数を指数関数的に減らすことができる。

また、本実施形態の手法によれば、上記のようにメッセージ認証子によるデータ完全性の確認のみならず、通常のＡＥＳのような共通鍵暗号を用いた暗号化、あるいはメッセージ認証と暗号化を同時に実行できる認証暗号の場合の復号にも適用することができる。

６０…ネットワーク
１００…鍵生成サーバ
２００…データ保管サーバ
２０１…入力部
２０２…出力部
２０３…通信部
２１０…制御部
２１１…全体処理部
２１２…鍵付替処理部
２２０…記録部
２３０…データ記録部
２３１…ユーザデータ
２４０…鍵記録部
２５０…一時情報記録部
３００…ユーザ端末Ａ
３０１…入力部
３０２…出力部
３０３…通信部
３１０…制御部
３１１…全体処理部
３１２…認証子生成／暗号化処理部
３１３…復号化／認証子検証処理部
３２０…記録部
３３０…データ記録部
３４０…鍵記録部
３４１…固有鍵
３５０…一時情報記録部
４００…ユーザ端末Ｂ
３００１、３００２、４００１〜４００３…ユーザ端末
１０１…入力部
１０２…出力部
１０３…通信部
１１０…制御部
１１１…全体処理部
１１２…鍵生成部
１１３…付替鍵生成部
１２０…記録部
１４０…鍵記録部
１４１…固有鍵
１４２…付替鍵
１５０…一時情報記録部

Claims

第一のユーザ端末からデータをサーバにアップロードして、第二のユーザ端末から前記データをアクセスするデータ処理システムであって、
前記第一のユーザ端末と前記第二のユーザ端末は、それぞれ第一の固有鍵、第二の固有鍵を有し、
前記サーバは、付替鍵を有し、
前記第一のユーザ端末は、一時鍵を生成し、
前記第一のユーザ端末は、前記データと前記一時鍵により、メッセージ認証子を生成し、
前記第一のユーザ端末は、前記一時鍵と前記第一の固有鍵により、第一の合成鍵を生成し、
前記第一のユーザ端末は、前記データ、前記第一の合成鍵、前記メッセージ認証子を、前記サーバに送信し、
前記サーバは、受信した前記第一の合成鍵と前記付替鍵より、第二の合成鍵を生成し、
前記サーバは、前記データ、前記第二の合成鍵、前記メッセージ認証子を、前記第二のユーザ端末に送信し、
前記第二のユーザ端末は、受信した前記第二の合成鍵と前記第二の固有鍵により、前記一時鍵を生成し、
前記第二のユーザ端末は、前記データと前記生成した一時鍵により、メッセージ認証子を生成し、生成したメッセージ認証子と、受信したメッセージ認証子を比較することにより、受信したデータの完全性を判定することを特徴とするデータ処理システム。
前記第一の固有鍵、前記第二の固有鍵、前記付替鍵、前記一時鍵、前記第一の合成鍵、前記第二の合成鍵を定義するデータ空間に、群演算＊が定義されており、
前記第一の合成鍵は、前記一時鍵と前記第一の固有鍵を群演算＊により演算したものであり、
前記付替鍵は、前記第一の固有鍵の逆元と前記第二の固有鍵を群演算＊により演算したものであり、
前記第二の合成鍵は、前記第一の合成鍵と前記付替鍵を群演算＊により演算したものであることを特徴とする請求項１記載のデータ処理システム。