(57)【特許請求の範囲】
【請求項１】
利用者の属性情報を管理する属性管理手段と、
前記利用者の属性情報を記憶する記憶手段と、
関数型暗号方式により暗号化されたデータを復号するための属性鍵を生成する鍵生成手段と、を備え、
前記鍵生成手段は、利用者の属性情報を含む前記属性鍵の生成要求を受け付けると、該生成要求に含まれる属性情報の正当性の確認を前記属性管理手段に要求し、前記属性管理手段により正当性が確認された属性情報に基づき前記属性鍵を生成し、
前記記憶手段は、前記属性情報が変更された際に、変更前の属性情報と変更後の属性情報とで、前記データへのアクセス権限を変更する必要がない場合には、変更後の属性情報と共に変更前の属性情報を記憶し、
前記属性管理手段は、正当性の確認が要求された属性情報が、前記記憶手段により記憶されている変更後の属性情報または変更前の属性情報と一致する場合には、前記正当性の確認が要求された属性情報は正当であると判定することを特徴とする暗号システム。
【請求項２】
利用者の属性情報を記憶する記憶部と、
関数型暗号方式により暗号化されたデータを復号するための属性鍵を生成する鍵生成装置から利用者の属性情報の正当性の確認を要求されると、該属性情報の正当性を、前記記憶部に記憶されている前記利用者の属性情報に基づき判定し、判定結果を前記鍵生成装置に通知する属性管理部と、を有し、
前記記憶部は、前記属性情報が変更された際に、変更前の属性情報と変更後の属性情報とで、前記データへのアクセス権限を変更する必要がない場合には、変更後の属性情報と共に変更前の属性情報を記憶し、
前記属性管理部は、正当性の確認が要求された属性情報が、前記記憶部に記憶されている変更後の属性情報または変更前の属性情報と一致する場合には、前記正当性の確認が要求された属性情報は正当であると判定することを特徴とする属性管理装置。
【請求項３】
属性管理装置と鍵生成装置とを有する暗号システムにおける鍵生成方法であって、
前記属性管理装置が、利用者の属性情報を管理するステップと、
前記属性管理装置が、前記利用者の属性情報を記憶するステップと、
前記鍵生成装置が、関数型暗号方式により暗号化されたデータを復号するための属性鍵であって、利用者の属性情報を含む属性鍵の生成要求を受け付けるステップと、
前記鍵生成装置が、前記生成要求に含まれる属性情報の正当性の確認を前記属性管理装置に要求するステップと、
前記属性管理装置が、前記生成要求に含まれる属性情報の正当性を、前記管理されている属性情報に基づき確認するステップと、
前記鍵生成装置が、正当性が確認された属性情報に基づき前記属性鍵を生成するステップと、を含み、
前記属性管理装置が、前記属性情報が変更された際に、変更前の属性情報と変更後の属性情報とで、前記データへのアクセス権限を変更する必要がない場合には、変更後の属性情報と共に変更前の属性情報を記憶し、
前記属性管理装置が、正当性の確認が要求された属性情報が、前記記憶されている変更後の属性情報または変更前の属性情報と一致する場合には、前記正当性の確認が要求された属性情報は正当であると判定する鍵生成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、関数型暗号を用いた暗号システム、属性管理装置、鍵生成装置および鍵生成方法に関する。
【背景技術】
【０００２】
クラウドなどを利用した情報（データ）のやりとりにおいて、安全性を担保するための仕組みの１つとして、データへのアクセス権限を制御する条件文を暗号自身に組み込むことができる関数型暗号方式を用いた暗号システムがある（例えば、特許文献１参照）。
【０００３】
関数型暗号方式を用いた暗号システムでは、利用者の所属する会社名、部署、利用者の役職などの属性情報を含む条件文が暗号に組み込まれる。そして、暗号システムに設けられた鍵発行センタ（ＫＧＣ：Ｋｅｙ  Ｇｅｎｅｒａｔｉｏｎ  Ｃｅｎｔｅｒ）により、利用者の属性情報に基づき属性鍵が生成され、利用者に対して発行される。利用者が暗号化されたデータへのアクセス権限を有する場合には、その利用者の属性情報に基づき生成された属性鍵により、暗号化されたデータを復号することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−２３２４７５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来、鍵発行センタは、利用者から申請される属性情報については、申請内容が正しいものと仮定して、属性鍵を生成していた。そのため、なりすましや虚偽の属性情報を検知することができないという問題があった。
【０００６】
申請された属性情報についての公開鍵証明書を要求することで、なりすましや虚偽の属性情報を検知することができる。しかし、利用者に公開鍵証明書を要求することは、利用者の工数負荷が大きく、また、属性情報が変更された場合には、公開鍵証明書を再度取得する必要が生じ、手間がかかるという問題があった。
【０００７】
本発明の目的は、上述した課題を解決し、利用者の手間を増大させることなく、安全性を高めることができる暗号システム、属性管理装置、鍵生成装置および鍵生成方法を提供することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明に係る暗号システムは、利用者の属性情報を管理する属性管理手段と、関数型暗号方式により暗号化されたデータを復号するための属性鍵を生成する鍵生成手段と、を備え、前記鍵生成手段は、利用者の属性情報を含む前記属性鍵の生成要求を受け付けると、該生成要求に含まれる属性情報の正当性の確認を前記属性管理手段に要求し、前記属性管理手段により正当性が確認された属性情報に基づき前記属性鍵を生成する。
【０００９】
また、上記課題を解決するため、本発明に係る属性管理装置は、利用者の属性情報を記憶する記憶部と、関数型暗号方式により暗号化されたデータを復号するための属性鍵を生成する鍵生成装置から利用者の属性情報の正当性の確認を要求されると、該属性情報の正当性を、前記記憶部に記憶されている前記利用者の属性情報に基づき判定し、判定結果を前記鍵生成装置に通知する属性管理部と、を有する。
【００１０】
また、上記課題を解決するため、本発明に係る鍵生成装置は、関数型暗号方式により暗号化されたデータを復号するための属性鍵を生成する鍵生成装置であって、利用者の属性情報を含む前記属性鍵の生成要求を受け付けると、該生成要求に含まれる属性情報の正当性の確認を、前記利用者の属性情報を管理する属性管理装置に要求し、前記属性管理装置により正当性が確認された属性情報に基づき前記属性鍵を生成する鍵発行部を有する。
【００１１】
また、上記課題を解決するため、本発明に係る鍵生成方法は、利用者の属性情報を管理するステップと、関数型暗号方式により暗号化されたデータを復号するための属性鍵であって、利用者の属性情報を含む属性鍵の生成要求を受け付けるステップと、前記生成要求に含まれる属性情報の正当性を、前記管理されている属性情報に基づき確認するステップと、正当性が確認された属性情報に基づき前記属性鍵を生成するステップと、を含む。
【発明の効果】
【００１２】
本発明に係る暗号システム、属性管理装置、鍵生成装置および鍵生成方法によれば、利用者の手間を増大させることなく、安全性を高めることができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施形態に係る暗号システムの構成を示す図である。
【図２】図１に示す属性管理サーバおよび鍵発行センタの構成を示すブロック図である。
【図３】図１に示す属性管理サーバおよび鍵発行センタの動作を示すフロー図である。
【図４】図２に示す属性ＤＢが記憶する属性情報を示す図である。
【図５】図２に示す鍵発行部が受け付ける属性鍵の生成要求に含まれる属性情報を示す図である。
【図６】図２に示す鍵属性ＤＢが記憶する属性情報を示す図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について説明する。
【００１５】
図１は、本発明の一実施形態に係る暗号システム１の構成を示す図である。本実施形態に係る暗号システム１は、利用者により関数型暗号方式を用いて暗号化されたデータを、クラウドなどを利用してやりとりするサービスにおいて、安全性を確保するためのものである。
【００１６】
図１に示す暗号システム１は、ネットワーク２を介して互いに接続された認証サーバ１０と、鍵生成手段としての鍵発行センタ２０と、サービスプロバイダ３０とを有する。
【００１７】
認証サーバ１０は、本人認証サーバ１１と、属性管理手段としての属性管理サーバ１２とを有する。
【００１８】
本人認証サーバ１１は、サービスを利用する利用者の本人認証を行う。
【００１９】
属性管理サーバ１２は、利用者の属性情報を管理する属性管理装置である。利用者の属性情報としては、利用者が所属する会社名、利用者の所属部、利用者の所属課、利用者の役職などの情報がある。
【００２０】
鍵発行センタ２０は、関数型暗号方式により暗号化されたデータを復号するための属性鍵を、利用者からの要求に応じて生成し、要求元の利用者に発行する鍵生成装置である。
【００２１】
サービスプロバイダ３０は、利用者の要求に応じて、データのアップロードあるいはダウンロードなどのサービスを提供する。
【００２２】
次に、鍵発行センタ２０および属性管理サーバ１２の構成について、図２を参照して説明する。なお、本人認証サーバ１１およびサービスプロバイダ３０の構成は当業者にとってよく知られており、また、本発明と直接関係しないため、説明を省略する。
【００２３】
まず、鍵発行センタ２０の構成について説明する。
【００２４】
図２に示す鍵発行センタ２０は、鍵発行部２０１と、鍵属性ＤＢ２０２とを有する。
【００２５】
鍵発行部２０１は、利用者から属性鍵の生成要求を受け付ける。属性鍵の生成要求には、要求元の利用者の属性情報が含まれる。鍵発行部２０１は、属性鍵の生成要求を受け付けると、生成要求に含まれる属性情報の正当性の確認を属性管理サーバ１２に要求する。そして、鍵発行部２０１は、属性管理サーバ１２により正当性が確認された属性情報に基づき属性鍵を生成し、要求元の利用者に発行する。
【００２６】
鍵属性ＤＢ２０２は、属性管理サーバ１２により正当性が確認された利用者の属性情報を記憶する。
【００２７】
次に、属性管理サーバ１２の構成について説明する。
【００２８】
図２に示す属性管理サーバ１２は、属性ＤＢ１２１と、属性管理部１２２とを有する。
【００２９】
属性ＤＢ１２１は、利用者の属性情報が入力され、入力された利用者の属性情報を管理（記憶）する記憶部である。利用者の属性情報が変更された場合には、変更後の属性情報が属性ＤＢ１２１に入力され、記憶される。
【００３０】
属性管理部１２２は、鍵発行センタ２０から利用者の属性情報の正当性の確認が要求されると、属性ＤＢ１２１に記憶されているその利用者の属性情報に基づいて、正当性の確認が要求された属性情報の正当性を判定する。そして、属性管理部１２２は、属性情報の正当性についての判定結果を、鍵発行センタ２０に回答（通知）する。
【００３１】
次に、鍵発行センタ２０および属性管理サーバ１２の動作について説明する。
【００３２】
図３は、鍵発行センタ２０および属性管理サーバ１２の動作を示すフロー図である。
【００３３】
属性ＤＢ１２１は、利用者の属性情報を管理（記憶）している。なお、以下では、属性ＤＢ１２１は、ある会社（会社名「○○産業」）の従業員の属性情報を管理しているものとする。
【００３４】
図４は、属性ＤＢ１２１が管理する属性情報の構成を示す図である。
【００３５】
図４に示すように、属性ＤＢ１２１は、属性情報として、利用者（「○○産業」の従業員）の氏名と、利用者の役職と、利用者の所属部と、利用者の所属課とを対応付けて記憶している。利用者（「○○産業」の従業員）の属性情報は、例えば、「○○産業」のシステム管理者などにより、属性ＤＢ１２１に入力される。なお、利用者の所属する部課の変更があった場合、部課名に変更があった場合など、利用者の属性情報に変更があった場合には、都度、変更内容が属性ＤＢ１２１に入力される。
【００３６】
ここで、利用者の所属する部課の名称が単に変更されることがある。通常、部課の名称が変更されただけでは、名称が変更された部課に所属する利用者のデータへのアクセス権限を変更する必要がない。この場合、変更前の属性情報と変更後の属性情報とは同値であるとみなすことができる。属性ＤＢ１２１は、変更前の属性情報と変更後の属性情報とが同値であるとみなすことができる場合には、変更後の属性情報と併せて変更前の属性情報を記憶しておく。
【００３７】
以下では、例えば、利用者Ｂの所属部の名称が営業部からセールス部に変更されたとする。この場合、属性ＤＢ１２１は、図４に示すように、利用者Ｂの所属部として、変更後の名称である「セールス部」を記憶するとともに、変更前の名称（旧名称）である「営業部」も記憶する。
【００３８】
図３を再び参照すると、利用者Ｂから鍵発行センタ２０に、属性鍵の生成が要求されたとする（ステップＳ１）。上述したように、属性鍵の生成要求には、要求元の利用者の属性情報が含まれている。
【００３９】
図５は、属性鍵の生成要求に含まれる利用者Ｂの属性情報を示す図である。
【００４０】
図５に示すように、属性鍵の生成要求には、要求元である利用者Ｂの氏名と、利用者Ｂの所属する会社名「○○産業」と、利用者Ｂの役職「課長」と、利用者Ｂの所属部「営業部」と、利用者Ｂの所属課「外販課」とが、属性情報として含まれている。なお、上述したように、利用者Ｂの所属部の名称は、「営業部」から「セールス部」に変更されている。しかし、利用者Ｂからは所属部を旧名称である「営業部」として申請が行われている。
【００４１】
図３を再び参照すると、鍵発行部２０１は、利用者Ｂからの属性鍵の生成要求を受け付けると、その生成要求に含まれる利用者Ｂの属性情報の正当性の確認を属性管理サーバ１２に要求する（ステップＳ２）。
【００４２】
図５に示すように、生成要求に含まれる属性情報の会社名には「○○産業」が設定されている。そのため、鍵発行部２０１は、「○○産業」の従業員の属性情報を管理する属性管理サーバ１２に、生成要求に含まれる利用者Ｂの属性情報の正当性の確認を要求する。
【００４３】
属性管理部１２２は、生成要求に含まれる利用者Ｂの属性情報の正当性の確認が要求されると、その属性情報と、属性ＤＢ１２１に記憶されている利用者Ｂの属性情報とを比較し、比較結果に基づき、生成要求に含まれる属性情報の正当性を判定する。そして、属性管理部１２２は、判定結果を鍵発行センタ２０に回答（通知）する（ステップＳ３）。
【００４４】
属性管理部１２２は、正当性の確認が要求された属性情報（利用者Ｂの属性情報）と属性ＤＢ１２１に記憶されている利用者Ｂの属性情報とが一致する場合には、正当性の確認が要求された属性情報は正当なものであると判定する。一方、属性管理部１２２は、正当性の確認が要求された属性情報（利用者Ｂの属性情報）と属性ＤＢ１２１に記憶されている利用者Ｂの属性情報とが一致しない場合には、正当性の確認が要求された属性情報は正当なものではないと判定する。
【００４５】
図４に示す属性ＤＢ１２１に記憶されている利用者Ｂの属性情報と、図５に示す生成要求に含まれる利用者Ｂの属性情報とを比較すると、役職、所属課については一致している。一方、所属部については、属性ＤＢ１２１には「セールス部」と記憶されているのに対し、生成要求では「セールス部」の旧名称である「営業部」が設定されている。
【００４６】
上述したように、属性ＤＢ１２１は、属性情報が変更されても、データへのアクセス権限を変更する必要が無く、変更前の属性情報と変更後の属性情報とが同値であるとみなすことができる場合には、変更後の属性情報と共に、変更前の属性情報についても記憶している。図４の例では、属性ＤＢ１２１は、利用者Ｂの所属部として、「セールス部」と共に、「セールス部」の旧名称である「営業部」も記憶している。
【００４７】
属性管理部１２２は、利用者Ｂの所属部として、現在の所属部の名称である「セールス部」と共に、旧名称である「営業部」が属性ＤＢ１２１に記憶されているため、生成要求に含まれる利用者Ｂの属性情報と、属性ＤＢ１２１に記憶されている利用者Ｂの属性情報とが一致すると判定する。この場合、属性管理部１２２は、生成要求に含まれる利用者Ｂの属性情報の正当性が確認された旨とともに、所属部の新名称は「セールス部」である旨を鍵発行センタ２０に通知する。
【００４８】
鍵発行部２０１は、属性管理サーバ１２により正当性が確認された属性情報を鍵属性ＤＢ２０２に記憶させる。
【００４９】
図６は、鍵属性ＤＢ２０２が記憶する属性情報を示す図である。
【００５０】
図６に示すように、鍵属性ＤＢ２０２は、利用者Ｂの氏名と、利用者Ｂの所属する会社名と、利用者Ｂの役職と、利用者Ｂの所属部と、利用者Ｂの所属課とを対応付けて記憶する。ここで、上述したように、生成要求に含まれる利用者Ｂの属性情報の正当性が確認された旨とともに、所属部の新名称は「セールス部」である旨が属性管理部１２２から通知されている。この場合、鍵属性ＤＢ２０２は、利用者Ｂの所属部については、利用者から申請された「営業部」ではなく、属性管理サーバ１２から通知された「セールス部」を記憶する。
【００５１】
鍵発行部２０１は、鍵属性ＤＢ２０２に記憶されている利用者Ｂの属性情報に基づき属性鍵を生成し、利用者Ｂに発行する（ステップＳ４）。なお、鍵発行部２０１は、生成要求に含まれる属性情報の正当性が確認できない旨が属性管理サーバ１２から通知された場合には、属性鍵を発行できない旨を利用者Ｂに通知する。
【００５２】
このように本実施形態によれば、暗号システム１は、属性管理サーバ１２と、鍵発行センタ２０とを有する。属性管理サーバ１２は、利用者の属性情報を管理する。鍵発行センタ２０は、利用者の属性情報を含む属性鍵の生成要求を受け付けると、生成要求に含まれる属性情報の正当性の確認を属性管理サーバ１２に要求する。属性管理サーバ１２は、管理している利用者の属性情報に基づき、鍵発行センタ２０から正当性の確認を要求された属性情報の正当性を判定する。そして、鍵発行センタ２０は、属性管理サーバ１２により正当性が確認された属性情報に基づき、属性鍵を生成する。
【００５３】
そのため、属性管理サーバ１２により利用者から申請された属性情報の正当性が判定され、正当性が確認された属性情報に基づき、属性鍵が生成されるので、なりすましや虚偽の属性情報を検知し、安全性を高めることができる。また、属性管理サーバ１２が利用者の属性情報を管理しているため、利用者に公開鍵証明書などを要求する必要が無く、利用者の手間の増大を抑制することができる。
【００５４】
また、本実施形態によれば、属性管理サーバ１２は、属性情報が変更された際に、変更前の属性情報と変更後の属性情報とが同値であるとみなせる場合には、変更後の属性情報と共に変更前の属性情報を記憶する。そして、属性管理サーバ１２は、正当性の確認が要求された属性情報が、記憶している変更後の属性情報または変更前の属性情報と一致する場合には、正当性の確認が要求された属性情報は正当であると判定する。
【００５５】
そのため、アクセス権限を変更する必要が無いような属性情報の変更があった場合に、利用者はその変更を意識することなく、属性鍵の生成を要求することができるので、利用者の手間の増大を抑制することができる。
【００５６】
本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各ブロックおよびステップに含まれる機能等は論理的に矛盾しないように再配置可能であり、複数のブロックおよびステップを１つに組み合わせたり、或いは分割したりすることが可能である。
【符号の説明】
【００５７】
１    暗号システム
１０    認証サーバ
１１    本人認証サーバ
１２    属性管理サーバ
２０    鍵発行センタ
３０    サービスプロバイダ
１２１    属性ＤＢ
１２２    属性管理部
２０１    鍵発行部
２０２    鍵属性ＤＢ
【図１】
0006348072.tif 000002
【図２】
0006348072.tif 000003
【図３】
0006348072.tif 000004
【図４】
0006348072.tif 000005
【図５】
0006348072.tif 000006
【図６】
0006348072.tif 000007