特許ウォッチ

公開番号2025091746
公報種別公開特許公報(A)
公開日2025-06-19
出願番号2023207181
出願日2023-12-07
発明の名称認可システム及び認可方法
出願人株式会社日立製作所
代理人弁理士法人サンネクスト国際特許事務所
主分類G06F 21/64 20130101AFI20250612BHJP(計算;計数)
要約【課題】
無効な検証可能証明書を用いたなりすましを防止すること。
【解決手段】
構造分析部は、認可依頼装置から検証可能依頼要求を受け取ると、第2の検証可能証明書に含まれる前記委任者の属性情報が、前記第1の検証可能証明書に含まれる前記委任者の属性情報と不整合がなく辿れ、かつ、前記第3の検証可能証明書における前記受任者の属性情報が、前記第1の検証可能証明書における前記委任者、並びに、前記第2の検証可能証明書における前記委任者及び前記受任者の属性情報と不整合なく辿れる場合、前記第3の検証可能証明書を含む前記検証可能依頼要求が真正なものと判断する。
【選択図】図6
特許請求の範囲【請求項１】
委任者の属性情報を含む第１の検証可能証明書を発行するとともに、前記委任者として受任者に対する委任情報として前記委任者の属性情報を含む第２の検証可能証明書を発行する発行者装置と、
前記受任者が前記第２の検証可能証明書及び前記第１の検証可能証明書を受け取ると、前記受任者の属性情報を含む第３の検証可能証明書を前記第１の検証可能証明書及び前記第２の検証可能証明書に付加して構成した検証可能依頼要求を発行する認可依頼装置と、
前記認可依頼装置から受け取った前記検証可能依頼要求が真正なものであるか否かを認可する認可装置と、を備え、
前記認可装置は、
前記認可依頼装置から前記検証可能依頼要求を受け取ると、前記第２の検証可能証明書に含まれる前記委任者の属性情報が、前記第１の検証可能証明書に含まれる前記委任者の属性情報と不整合がなく辿れ、かつ、前記第３の検証可能証明書における前記受任者の属性情報が、前記第１の検証可能証明書における前記委任者、並びに、前記第２の検証可能証明書における前記委任者及び前記受任者の属性情報と不整合なく辿れる場合、前記第３の検証可能証明書を含む前記検証可能依頼要求が真正なものと判断する構造分析部を有する
ことを特徴とする認可システム。
続きを表示（約 1,200 文字）【請求項２】
前記構造分析部は、
前記不整合なく辿れない場合、それ以降検証対象から除外する
ことを特徴とする請求項１に記載の認可システム。
【請求項３】
前記認可装置は、
複数の検証可能証明書の関係性を構造化したデータである構造化データの一部の検証可能証明書が失効していると判断した場合、前記構造化データから前記一部の検証可能証明書を削除した残りの構造化データを検証の対象とする検証可能証明書検証部を備える
ことを特徴する請求項１に記載の認可システム。
【請求項４】
前記認可装置は、
複数の検証可能証明書の関係性を構造化したデータである構造化データの一部の検証可能証明書が失効していると判断した場合、前記構造化データから前記一部の検証可能証明書を削除した残りの構造化データを検証の対象とする認可ポリシ検証部を備える
ことを特徴とする請求項１に記載の認可システム。
【請求項５】
所定のサービスの提供を認可すべきか否かに関する判断基準を示す認可ポリシを格納する認可ポリシ格納部を備え、
前記認可ポリシ検証部は、
複数の検証可能証明書の関係性を構造化したデータである構造化データが前記認可ポリシに反しない場合には前記サービスの提供を認可する一方、前記構造化データが前記認可ポリシに反する場合には前記サービスの提供を認可しない
ことを特徴とする請求項４に記載の認可システム。
【請求項６】
発行者のトラスト情報と、前記認可ポリシに記載されている前記発行者のトラストに関する条件、前記発行者の前記構造化データに含まれる前記発行者の情報から、前記認可ポリシを満たしているか検証を行うトラスト検証部を備える
ことを特徴とする請求項４に記載の認可システム。
【請求項７】
電子署名の認証に用いられる公開鍵が格納される公開鍵キャッシュ部を備える
ことを特徴とする請求項１に記載の認可システム。
【請求項８】
検証対象の失効情報が格納される失効情報キャッシュ部を備える
ことを特徴とする請求項１に記載の認可システム。
【請求項９】
前記第１～第３の検証可能証明書は、Verifiable Credentialであり、前記検証可能依頼要求は、Verifiable Presentationである
ことを特徴とする請求項１に記載の認可システム。
【請求項１０】
前記委任者及び前記受任者とやり取りを行うインターフェースと、
少なくとも前記構造分析部、前記検証可能依頼要求検証部、前記検証可能証明書検証部及び前記認可ポリシ検証部を有する検証可能依頼要求認可サーバと、が別体である
ことを特徴とする請求項３及び請求項４に記載の認可システム。
（【請求項１１】以降は省略されています）
発明の詳細な説明【技術分野】
【０００１】
本発明は、認可システム及び認可方法に関し、例えば、Verifiable Credentialsを活用する際におけるなりすましを防止する技術に関する認可システムに適用して好適なものである。
続きを表示（約 2,900 文字）【背景技術】
【０００２】
近年、プライバシ保護、可用性の観点から、検証可能証明書の一例としてVerifiable Credentialsを活用した認可システムが存在している。非特許文献１では、ＶＣ（Verifiable Credential）を用いた認可システムについて定義されており、当該認可システムの構成要素であるＩｓｓｕｅｒ、Ｈｏｌｄｅｒ、Ｖｅｒｉｆｉｅｒ及びＶＤＲ（Verifiable Data Registry）の基本機能が開示されている。ＶＣには、Ｖｅｒｉｆｉｅｒに対して認可を要求するＨｏｌｄｅｒの属性情報が記載されており、ＶｅｒｉｆｉｅｒがＨｏｌｄｅｒより複数ＶＣからなるＶＰ（Verifiable Presentation）を受け取ると、ＶＰに含まれる各ＶＣに記載されている属性情報を元に認可が行われる。
【先行技術文献】
【非特許文献】
【０００３】
https://www.w3.org/TR/ＶＣ-data-model-2.0/
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、悪意のあるＨｏｌｄｅｒが第三者に対して発行されたＶＣをＶＰに含めてＶｅｒｉｆｉｅｒに認可を要求すると、第三者に対して発行されたＶＣは検証において無効であるにも関わらず、Ｖｅｒｉｆｉｅｒは無効であるＶＣを検知することができないという問題があった。
【０００５】
本発明は以上の点を考慮してなされたもので、無効な検証可能証明書を用いたなりすましを防止することができる認可システム及び認可方法を提案しようとするものである。
【課題を解決するための手段】
【０００６】
かかる課題を解決するため本発明においては、委任者の属性情報を含む第１の検証可能証明書を発行するとともに、前記委任者として受任者に対する委任情報として前記委任者の属性情報を含む第２の検証可能証明書を発行する発行者装置と、前記受任者が前記第２の検証可能証明書及び前記第１の検証可能証明書を受け取ると、前記受任者の属性情報を含む第３の検証可能証明書を前記第１の検証可能証明書及び前記第２の検証可能証明書に付加して構成した検証可能依頼要求を発行する認可依頼装置と、前記認可依頼装置から受け取った前記検証可能依頼要求が真正なものであるか否かを認可する認可装置と、を備え、前記認可装置は、前記認可依頼装置から前記検証可能依頼要求を受け取ると、前記第２の検証可能証明書に含まれる前記委任者の属性情報が、前記第１の検証可能証明書に含まれる前記委任者の属性情報と不整合がなく辿れ、かつ、前記第３の検証可能証明書における前記受任者の属性情報が、前記第１の検証可能証明書における前記委任者、並びに、前記第２の検証可能証明書における前記委任者及び前記受任者の属性情報と不整合なく辿れる場合、前記第３の検証可能証明書を含む前記検証可能依頼要求が真正なものと判断する構造分析部を有するようにした。
【０００７】
また、本発明においては、発行者装置が、委任者の属性情報を含む第１の検証可能証明書を発行する第１の発行ステップと、前記発行者装置が、前記委任者として受任者に対する委任情報として前記委任者の属性情報を含む第２の検証可能証明書を発行する第２の発行ステップと、認可依頼装置が、前記受任者が前記第２の検証可能証明書に及び前記第１の検証可能証明書を受け取ると、前記受任者の属性情報を含む第３の検証可能証明書を前記第１の検証可能証明書及び前記第２の検証可能証明書に付加して構成した検証可能依頼要求を発行する第２の発行ステップと、認可装置の構造分析部が、前記認可依頼装置から前記検証可能依頼要求を受け取ると、前記第２の検証可能証明書に含まれる前記委任者の属性情報が、前記第１の検証可能証明書に含まれる前記委任者の属性情報と不整合がなく辿れ、かつ、前記第３の検証可能証明書における前記受任者の属性情報が、前記第１の検証可能証明書における前記委任者、並びに、前記第２の検証可能証明書における前記委任者及び前記受任者の属性情報と不整合なく辿れる場合、前記第３の検証可能証明書を含む前記検証可能依頼要求が真正なものと判断する検証可能依頼要求検証ステップと、を有するようにした。
【発明の効果】
【０００８】
本発明によれば、無効な検証可能証明書を用いたなりすましを防止することができる。
【図面の簡単な説明】
【０００９】
第１の実施形態による認可システムの構成例を示すシステム構成図である。
図１に示すＩｓｓｕｅｒサーバのハードウェア構成の一例を示すブロック図である。
ＶＰの一例を示す図である。
図１に示すＩｓｓｕｅｒサーバのソフトウェア構成の一例を示すブロック図である。
図１に示すＨｏｌｄｅｒ端末のソフトウェア構成例を示すブロック図である。
図１に示すＶｅｒｉｆｉｅｒサーバのソフトウェア構成の一例を示すブロック図である。
発行対象者ベースＶＰ構造化データの一例を示す図である。
ＩｓｓｕｅｒベースＶＰ構造化データの具体例を示す図である。
ＶＤＲの構成例を示すブロック図である。
ＶＰ認可処理の概要を示す図である。
ＶＰ構造分析処理（初回）の手順の一例を示すフローチャートである。
ＶＰ検証処理の手順の一例を示すシーケンスチャートである。
発行対象者ベースＶＰ構造化データを用いてなりすましを検出する一例を示す図である。
なりすましを検出する具体例を示す図である。
ＶＣ検証処理の手順の一例を示すシーケンスチャートである。
ＶＣ検証処理の手順の一例を示すシーケンスチャートである。
失効によりＶＣが無効となる場合の一例を示している図である。
失効によりＶＣが無効となる場合の一例を示している図である。
ＶＰ構造分析処理（２回目以降）の手順の一例を示すフローチャートである。
認可ポリシ検証処理の手順の一例を示すシーケンスチャートである。
第２の実施形態による認可システムの構成例を示すブロック図である。
【発明を実施するための形態】
【００１０】
以下、図面に基づいて、本発明の一実施形態を詳述する。
（１）第１の実施形態
図１は、第１の実施形態による認可システム１０００の構成例を示すシステム構成図である。認可システム１０００は、その構成要素として、例えばＩｓｓｕｅｒ、Ｈｏｌｄｅｒ、Ｖｅｒｉｆｉｅｒ及びＶｅｒｉｆｉｅｒサーバ３００、Ｖｅｒｉｆｉａｂｌｅｄａｔａｒｅｇｉｓｔｒｙ（以下「ＶＤＲ」と省略する）を有する。認可システム１０００は、例えばＶＣ（Verifiable Credential）を用いて認可を行う。
（【００１１】以降は省略されています）

関連特許