特許 6571145 デジタルアイデンティティ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6571145

(24)【登録日】2019年8月16日

(45)【発行日】2019年9月4日

(54)【発明の名称】デジタルアイデンティティ

(51)【国際特許分類】

   H04L 9/32 20060101AFI20190826BHJP

   G06F 21/31 20130101ALI20190826BHJP

   H04W 12/06 20090101ALI20190826BHJP

【ＦＩ】

   H04L9/00 675A

   G06F21/31

   H04W12/06

   H04L9/00 673A

【請求項の数】15

【全頁数】15

(21)【出願番号】特願2017-178868(P2017-178868)

(22)【出願日】2017年9月19日

(65)【公開番号】特開2018-50294(P2018-50294A)

(43)【公開日】2018年3月29日

【審査請求日】2018年7月9日

(31)【優先権主張番号】16020338.6

(32)【優先日】2016年9月20日

(33)【優先権主張国】EP

(73)【特許権者】

【識別番号】597149146

【氏名又は名称】ドイッチェ テレコム アーゲー

(74)【代理人】

【識別番号】100093067

【弁理士】

【氏名又は名称】二瓶 正敬

(72)【発明者】

【氏名】モハマド スバイティ

(72)【発明者】

【氏名】トビアス ヴェルナード

【審査官】 行田 悦資

(56)【参考文献】

【文献】 特表２０１０−５３１００５（ＪＰ，Ａ）

【文献】 特表２０１４−５２２００９（ＪＰ，Ａ）

【文献】 特表２００７−５０５５５５（ＪＰ，Ａ）

【文献】 国際公開第２０１５／０１３５２２（ＷＯ，Ａ１）

【文献】 特開２０１２−０２２７０８（ＪＰ，Ａ）

【文献】 特表２０１６−５１２６３５（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ９／３２

Ｇ０６Ｆ ２１／３１

Ｈ０４Ｗ １２／０６

(57)【特許請求の範囲】

【請求項1】

唯一のユーザ関連固有デジタル識別子（Ｄ−ＩＤ）を介して、プライバシー及びセキュリティを考慮したネットワーク内の少なくとも１つのサービスプロバイダの異なるサービスへの各アクセスをユーザに提供するシステムであって、少なくとも、Ｄ−ＩＤミドルウェア（１００、３２０、４００、５２０、６２０）と、Ｄ−ＩＤエージェント（３１０、５１０、６１０）とを備え、
−前記Ｄ−ＩＤエージェント（３１０、５１０、６１０）は、前記ユーザの任意且つ所望の端末デバイス上で少なくとも部分的に稼働され、前記Ｄ−ＩＤ、前記ユーザの少なくとも１つのハンドルネーム、及びユーザ規定のハンドルネーム特有のシークレット番号を生成し、前記シークレット番号及び暗号学的ハッシュ関数を使用して、そのリーフとして前記シークレット番号を有するハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅ（２００、６５０）のルート値を計算し、ともに認証暗号化法を使用して暗号化された前記少なくとも１つのハンドルネーム及び前記ハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅの前記ルート値を前記Ｄ−ＩＤミドルウェア（１００、３２０、４００、５２０、６２０）に送信し、前記システム外の前記少なくとも１つのサービスプロバイダ（ＳＰ１、ＳＰ２、ＳＰ３、ＳＰ６３０）の前記異なるサービスのうち、所望の１つのサービスにアクセスする際、必要に応じて、前記シークレット番号の１つを使用するように構成され、
−前記Ｄ−ＩＤミドルウェア（１００、３２０、４００、５２０、６２０）は、オペレータによって稼働され、前記ユーザの前記Ｄ−ＩＤの検証に対して、前記ユーザの前記端末デバイス及び前記少なくとも１つのサービスプロバイダの間にミドルウェアを構築し、前記Ｄ−ＩＤミドルウェア（１００、３２０、４００、５２０、６２０）は、前記ユーザの前記Ｄ−ＩＤ、前記各ハンドルネーム及び前記ハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅの前記ルート値を備えるＭｅｒｋｌｅ ｔｒｅｅルート要素、並びに各ルート要素に対する信頼レベルを受信及び維持するように構成され、前記ユーザが前記少なくとも１つのサービスプロバイダ（ＳＰ１、ＳＰ２、ＳＰ３、ＳＰ６３０）の前記異なるサービスのうち、前記所望の１つのサービスにアクセスすることを意図する時にはいつでも、前記ユーザは、前記少なくとも１つのハンドルネームのうちの１つを選択し、前記Ｄ−ＩＤエージェント（３１０、５１０、６１０）は、サービスプロバイダ（ＳＰ１、ＳＰ２、ＳＰ３、ＳＰ６３０）に対して、前記ハンドルネーム特有のシークレット番号の１つと、前記ハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅ（２００、６５０）から導き出される対応の認証パスとを明らかにし、前記ハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅの前記ルート値及び信頼レベルを受信するために、前記Ｄ−ＩＤミドルウェア（１００、３２０、４００、５２０、６２０）に前記ハンドルネームが転送され、前記サービスプロバイダ（ＳＰ１、ＳＰ２、ＳＰ３、ＳＰ６３０）が、前記シークレット番号の１つ及び前記認証パスに基づき、ルート値を計算し、それが前記ハンドルネームについて前記Ｄ−ＩＤミドルウェア（１００、３２０、４００、５２０、６２０）から受信した前記ルート値に合致するか否かを検証できるようにし、前記ユーザが前記ハンドルネームの所有者であることが検証され、そうであれば、前記選択されたハンドルネームの前記信頼レベルが前記少なくとも１つのサービスプロバイダ（ＳＰ１、ＳＰ２、ＳＰ３、ＳＰ６３０）によって要求されたものに対応する場合、前記ユーザが、前記異なるサービスのうち、前記所望の１つのサービスにアクセス可能となる、システム。

【請求項2】

前記Ｄ−ＩＤは、前記ユーザによって規定され、前記Ｄ−ＩＤミドルウェア（１００、３２０、４００、５２０、６２０）により、個人ＩＤ等、適切な手段を介して検証される、請求項１に記載のシステム。

【請求項3】

前記信頼レベルは、前記認証暗号化法と、前記少なくとも１つのハンドルネーム及び前記ハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅの前記ルート値を前記Ｄ−ＩＤエージェント（３１０、５１０、６１０）から前記Ｄ−ＩＤミドルウェア（１００、３２０、４００、５２０、６２０）に送信する手法に基づき、前記Ｄ−ＩＤミドルウェア（１００、３２０、４００、５２０、６２０）によって割り当てられる、請求項１又は２に記載のシステム。

【請求項4】

各Ｍｅｒｋｌｅ ｔｒｅｅルート要素について、前記Ｄ−ＩＤミドルウェア（１００、３２０、４００、５２０、６２０）は、前記各ハンドルネーム及び前記ハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅの前記ルート値に加え、現在のシークレットカウンタを記憶するように構成される、請求項１〜３のいずれか一項に記載のシステム。

【請求項5】

前記少なくとも１つのハンドルネームが生成される時、前記シークレットカウンタは、ゼロに設定され、前記ユーザが前記ハンドルネーム特有のシークレット番号の１つを使用する度に、１ずつ自動で増加される、請求項４に記載のシステム。

【請求項6】

前記ハンドルネーム特有のシークレット番号の各々は、前記ハンドルネーム、前記現在のシークレットカウンタ、及び乱数に基づいて編成される、請求項５に記載のシステム。

【請求項7】

前記ハンドルネーム特有のシークレット番号の各々は、サービスプロバイダ（ＳＰ１、ＳＰ２、ＳＰ３、ＳＰ６３０）のサービスにアクセスするために１回に限って使用可能な１回限定シークレット番号である、請求項１〜６のいずれか一項に記載のシステム。

【請求項8】

前記ユーザは、異なる種別のサービスに対して異なるハンドルネームを生成することができる、請求項１〜７のいずれか一項に記載のシステム。

【請求項9】

前記Ｄ−ＩＤエージェント（３１０、５１０、６１０）は、セキュアクラウド内で部分的に稼働される、請求項１〜８のいずれか一項に記載のシステム。

【請求項10】

唯一のユーザ関連固有デジタル識別子（Ｄ−ＩＤ）を介して、プライバシー及びセキュリティを考慮したネットワーク内の少なくとも１つのサービスプロバイダの異なるサービスへの各アクセスをユーザに提供する方法であって、前記方法は、
−前記ユーザの任意且つ所望の端末デバイス上で少なくとも部分的に稼働するＤ−ＩＤエージェントをもうけることと、
−前記ユーザの任意且つ所望の端末デバイス上で少なくとも部分的に稼働している前記Ｄ−ＩＤエージェントにより、前記Ｄ−ＩＤ、前記ユーザの少なくとも１つのハンドルネーム、及びユーザ規定のハンドルネーム特有のシークレット番号とを生成することと、
−前記Ｄ−ＩＤエージェントにより、前記シークレット番号及び暗号学的ハッシュ関数を使用して、そのリーフとして前記シークレット番号を有するハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅのルート値を計算することと、
−前記Ｄ−ＩＤエージェントにより、ともに認証暗号化法を使用して暗号化された前記少なくとも１つのハンドルネーム及び前記対応のルート値を１つのＤ−ＩＤミドルウェアに送信することと、
−前記Ｄ−ＩＤミドルウェアを、前記ユーザの前記Ｄ−ＩＤの検証に対する、前記ユーザ及び前記少なくとも１つのサービスプロバイダの間のミドルウェアとして提供することと、
−前記Ｄ−ＩＤミドルウェアにより、前記ユーザのＤ−ＩＤ、前記各ハンドルネーム及び前記ハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅの前記ルート値を備える前記ユーザの前記少なくとも１つのハンドルネームの各々に対するＭｅｒｋｌｅ ｔｒｅｅルート要素、並びに各Ｍｅｒｋｌｅ ｔｒｅｅルート要素に対する信頼レベルを受信及び維持することと、
−前記ユーザが前記異なるサービスのうち、所望の１つのサービスにアクセスすることを意図する時、前記少なくとも１つのハンドルネームのうちの１つを選択し、前記Ｄ−ＩＤエージェントにより、サービスプロバイダに対して、前記選択されたハンドルネームと、前記ハンドルネーム特有のシークレット番号の１つと、前記ハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅから導き出される対応の認証パスとを明らかにし、前記サービスプロバイダにより、前記ハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅの前記ルート値及び信頼レベルを受信するために、前記Ｄ−ＩＤミドルウェアに前記ハンドルネームを転送し、前記サービスプロバイダにより、前記シークレット番号の１つ及び前記認証パスに基づき、ルート値を計算し、前記サービスプロバイダにより、それが前記ハンドルネームについて前記Ｄ−ＩＤミドルウェアから受信した前記ルート値に合致するか否かを検証することにより、前記ユーザが前記ハンドルネームの所有者であることを検証し、そうであれば、前記選択されたハンドルネームの前記信頼レベルが前記少なくとも１つのサービスプロバイダによって要求されたものに対応する場合、前記ユーザに、前記少なくとも１つのサービスにアクセスさせる、方法。

【請求項11】

前記信頼レベルは、前記認証暗号化法と、前記少なくとも１つのハンドルネーム及び前記ハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅの前記ルート値を前記Ｄ−ＩＤエージェントから前記Ｄ−ＩＤミドルウェアに送信する手法に基づき、前記Ｄ−ＩＤミドルウェアによって割り当てられる、請求項１０に記載の方法。

【請求項12】

前記信頼レベルは、ともに暗号化された前記少なくとも１つのハンドルネーム及び前記ハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅの前記ルート値を前記Ｄ−ＩＤミドルウェアに送信する時、他の認証方法を使用して更新される、請求項１１に記載の方法。

【請求項13】

前記ユーザが前記所望の１つのサービスにアクセスすることを意図する時、前記サービスプロバイダも、最後に使用されたシークレット番号のシークレットカウンタを前記Ｄ−ＩＤミドルウェアから受信し、更に、前記現在選択されたシークレット番号の前記シークレットカウンタが前記最後に使用されたシークレット番号の前記シークレットカウンタ以上であることを検証する、請求項１０、１１、又は１２に記載の方法。

【請求項14】

前記サービスにアクセスするために請求を行うことが必要とされ、前記サービスプロバイダに前記ユーザの前記Ｄ−ＩＤを取得することが許可されない場合、請求情報は、前記Ｄ−ＩＤミドルウェアによって引き継がれ、前記Ｄ−ＩＤミドルウェアが請求代行を行う、請求項１０〜１３のいずれか一項に記載の方法。

【請求項15】

前記ユーザは、前記ハンドルネーム特有のシークレット番号の前記１つ及び前記各認証パスを他のユーザにバウチャとして明らかにし、前記他のユーザは、前記ハンドルネーム特有のシークレット番号の１つ及び前記各認証パスを使用して前記所望の１つのサービスに１回アクセスする、請求項１０〜１４のいずれか一項に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ユーザにネットワーク内の１つ以上のサービスプロバイダの異なるサービスへのアクセスを提供するシステム及び方法に関する。

【背景技術】

【0002】

近年、オペレータ及びその産業協会（ＧＳＭＡ）により、デジタル世界のアイデンティティプロバイダとしてのバリューチェーンにおいて自らの立場を強化するために、いくつかのアプローチがなされてきている。最も最近のアプローチは、Ｍｏｂｉｌｅ Ｃｏｎｎｅｃｔと称され、顧客の識別及び認証を保証するＳＩＭ又はその派生物を使用し、安全且つ容易なログインプロセスが可能となるように、各ＡＰＩをサービスプロバイダ（Ｓｐｏｔｉｆｙ又はＢａｎｋｓ等）に提示するものである。しかしながら、Ｆａｃｅｂｏｏｋ及びＧｏｏｇｌｅが、世界規模であり、この領域でのフロントランナーである。

【0003】

また、Ｆａｃｅｂｏｏｋ及びＧｏｏｇｌｅが、ユーザ／顧客についてのいくつかの個人情報及び嗜好を各サービスプロバイダに伝えるものであるため、これらは、アイデンティティ及びログインのためのパートナーとして、オンラインショップ又はストリーミングサービスのようなＯｖｅｒ Ｔｈｅ Ｔｏｐ（ＯＴＴ）サービスに支持される。

【0004】

オペレータにとっては、個人データについてより多くのコントロールを顧客に加える、プライバシー及びセキュリティを提示した、顧客の擁護者となれるチャンスがあり、この点がＦａｃｅｂｏｏｋ及びＧｏｏｇｌｅの主な課題である。オペレータは、ＯＴＴ競合（特に、金融機関）と比較して、プライバシー及びセキュリティに関して、より信頼性が高いものと認識されている。実際に、彼らは、関連の規制当局の基準に従わなければならないため、ほとんどの場合には、より信頼性が高い。

【発明の概要】

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

【0005】

しかしながら、現在提案されている既存のオペレータによるソリューションは、（例えば、ＳＩＭ又はｅＳＩＭに基づく）ユーザに関連するものでなく、提供者に関連するものである。そのため、ユーザデバイスは、各オペレータのハードウェアベースのソリューションをサポートする必要があり、加えて、ユーザは、自らのデバイスを簡易にシェアすることができない。

【0006】

したがって、本発明の目的は、ユーザが、過剰なパスワードを生成、記憶、及び管理する必要性を伴うことなく、ユーザ中心のプライバシーを考慮したネットワーク内の異なるサービスへのアクセスを実施できるようにすることであった。

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

【0007】

この問題へのソリューションは、独立クレームの特徴を備えたシステム及び方法によって与えられる。このシステム及び方法の実施形態は、各従属項及び以下の説明によって説明を行う。

【0008】

本発明は、唯一のユーザ関連固有デジタル識別子（Ｄ−ＩＤ）を介して、プライバシー及びセキュリティを考慮したネットワーク内の少なくとも１つのサービスプロバイダの異なるサービスへの各アクセスをユーザに提供するシステムを提供するものである。

【0009】

本システムは、少なくとも、Ｄ−ＩＤミドルウェアと、Ｄ−ＩＤエージェントとを備える。

【0010】

Ｄ−ＩＤエージェントは、ユーザにより、通常は、ユーザの任意且つ所望の端末デバイス上で少なくとも部分的に稼働され、Ｄ−ＩＤ、ユーザの少なくとも１つのハンドルネーム、及びユーザ規定のハンドルネーム特有のシークレット番号を生成し、シークレット番号及び暗号学的ハッシュ関数を使用して、そのリーフとしてシークレットを有するハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅのルート値を計算し、ともに認証暗号化法を使用して暗号化された少なくとも１つのハンドルネーム及び対応のルート値をＤ−ＩＤミドルウェアに送信し、少なくとも１つのサービスプロバイダの異なるサービスのうち、１つのサービスにアクセスする際、必要に応じて、シークレット番号のシークレットを使用するように構成される。

【0011】

ユーザは、任意の好適な端末デバイス、すなわち、Ｄ−ＩＤエージェントが少なくとも部分的に実行可能な電子ハードウェアデバイス又は電気機械ハードウェアデバイスを選ぶことができる。そこで、Ｄ−ＩＤエージェントは、携帯電話、ラップトップ等で稼働可能である。Ｄ−ＩＤエージェントは、異なるプロセッサ上で実行可能である。

【0012】

Ｄ−ＩＤミドルウェアは、オペレータによって稼働され、ユーザのＤ−ＩＤの検証に対する、ユーザの端末デバイス及び少なくとも１つのサービスプロバイダの間のミドルウェアを構成する。Ｄ−ＩＤミドルウェアは、ユーザのＤ−ＩＤ、各ハンドルネーム及び対応のルート値を備えるユーザの少なくとも１つのハンドルネームの各々に対するＭｅｒｋｌｅ ｔｒｅｅルート要素、並びに各ルート要素に対する信頼レベルを受信及び維持するように構成される。

【0013】

システムは、ユーザが異なるサービスのうち、所望の１つのサービスにアクセスすることを意図する時にはいつでも、ユーザは、少なくとも１つのハンドルネームのうちの１つを選択しなければならず、この選択されたハンドルネームに基づき、Ｄ−ＩＤエージェントは、サービスプロバイダに対して、ハンドルネーム特有のシークレット番号のシークレットと、ハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅから導き出される対応の認証パスとを明らかにし、サービスプロバイダは、対応のルート値及び信頼レベルを受信するために、Ｄ−ＩＤミドルウェアにハンドルネームを転送し、シークレット及び認証パスに基づき、ルート値を計算し、それがハンドルネームについてＤ−ＩＤミドルウェアから受信したルート値に合致するか否かを検証することにより、ユーザがハンドルネームの所有者であることを検証し、そうであれば、選択されたハンドルネームの信頼レベルが少なくとも１つのサービスプロバイダによって要求されたものに対応する場合、ユーザに、所望のサービスへアクセスさせるように構成される。

【0014】

提案のシステムの一実施形態によると、Ｄ−ＩＤは、ユーザによって規定され、Ｄ−ＩＤミドルウェアにより、個人ＩＤ等、適切な手段を介して検証される。

【0015】

提案のシステムの更に他の可能な実施形態によると、信頼レベルは、少なくとも１つのハンドルネーム及び対応のルート値をＤ−ＩＤエージェントからＤ−ＩＤミドルウェアに送信する手法に基づき、ミドルウェアによって割り当てられる。

【0016】

更に、各ルート要素について、ミドルウェアは、各ハンドルネーム及び対応のルート値に加え、現在のシークレットカウンタを記憶するように構成される。

【0017】

少なくとも１つのハンドルネームが生成される時、シークレットカウンタは、ゼロに設定され、ユーザがハンドルネーム特有のシークレット番号のシークレットを使用する度に、１ずつ自動で増加される。

【0018】

Ｄ−ＩＤミドルウェアに関してまとめると、Ｄ−ＩＤミドルウェアは、ユーザのＩＤの検証に対して、ユーザ（すなわち、ユーザが所望のサービスにアクセスするために実際に使用する、ユーザの各端末デバイス）及びサービスプロバイダの間のミドルウェアであると言える。Ｄ−ＩＤミドルウェアは、例えば、通信会社のオペレータや、その他任意の組織によって稼働することができる。図１は、後述するが、Ｄ−ＩＤミドルウェアによって維持される情報の概略図を提供するものである。Ｄ−ＩＤミドルウェアは、そのユーザに関する以下の情報を管理する。
−ユーザによって選択され、Ｄ−ＩＤミドルウェアのプロバイダによって適切な手段（例えば、個人ＩＤ）を介して検証され得る固有識別子である、ユーザのＤ−ＩＤ。
−各ユーザに対するいくつかのＭｅｒｋｌｅ ｔｒｅｅルート要素（これらは、ユーザによって生成され、ミドルウェアに送信される）及び各ルート要素の対応信頼レベル（これは、送信方法、すなわち、使用される認証暗号化法に基づき、ミドルウェアによって割り当てられる）。

【0019】

各ルート要素について、以下のパラメータが記憶される。
〇ユーザのハンドルネーム
〇対応のルート要素値（ルート値）
〇現在のシークレットカウンタ（Ｓ−Ｃｏｕｎｔｅｒ）

【0020】

以下、上に挙げた３つの情報をルート要素と指定する。シークレットカウンタは、以下、Ｓ−Ｃｏｕｎｔｅｒとも称するが、最初は常にゼロであり、ユーザがサービスへのアクセスを得るためにシークレットを使用する度に１ずつ増加することにも留意する。

【0021】

更なる実施形態によると、ハンドルネーム特有のシークレット番号の各シークレットは、ハンドルネーム、現在のシークレットカウンタ（すなわち、シークレットカウンタの現在の値）、及び乱数に基づいて編成される。

【0022】

本発明に係るシステムの更に他の実施形態によると、ハンドルネーム特有のシークレット番号の各シークレットは、サービスプロバイダのサービスにアクセスするために１回に限って使用可能な１回限定シークレットである。

【0023】

ユーザは、対応する異なる種別のサービスに対して異なるハンドルネームを生成することができる。しかしながら、ユーザは、同一種別のサービスに対して異なるハンドルネームを生成することもできる。これは、ユーザが各サービスに対して少なくとも１つのハンドルネームを生成することができるため、サービスプロバイダその他は、ユーザのアクティビティを追跡することができないことを意味する。

【0024】

本発明に係るシステムの１つの可能な実施形態において、Ｄ−ＩＤエージェントは、セキュアクラウドにおいて部分的に稼働される。これは、Ｄ−ＩＤエージェントが所望のサービスへのアクセスを得るために実際に使用するユーザの各端末デバイス上で部分的に稼働され、セキュアクラウドで部分的に稼働されることを意味する。

【0025】

本発明に係るシステムは、以下の品質特性に繋がる。
−デバイス及び認証方法に依存しない。ユーザは、自らのスマートフォン、ラップトップ、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）、その他を任意のレガシー又は新たな認証方法とともに使用することができる。
−ユーザ中心であり、ユーザは、Ｄ−ＩＤ及びそのプライバシーに多大なコントロールを有する。
−計算オーバーヘッドの低い、ポスト量子セキュリティ機構を特徴とする。
−動的である。すなわち、リアルタイムで変化することがある。また、その信頼レベルも動的に変化し得る。
−トランザクションレベルで簡易にシェア可能である。

【0026】

ユーザは、本発明に係るシステムを使用することにより、唯一のユーザ関連固有デジタル識別子（Ｄ−ＩＤ）を使用して、１つ又は異なる端末デバイスから、異なるセキュリティ／信頼レベルを更に要求する異なるサービスプロバイダによって提供される異なるサービスへの各アクセスを得ることができるようになる。このシステムにより、ユーザに、第三者に対してのみならず、各サービスプロバイダに対しても、プライバシーを達成することができるようにする。

【0027】

量子計算は、データに演算を実施するため、重ね合わせ及びもつれ等、量子機構現象を直接使用する論理計算システム（量子コンピュータ）を研究するものである。大型量子コンピュータは、ショアアルゴリズムを使用する整数因数分解等、現在最もよく知られているアルゴリズムを使用した任意の旧知のコンピュータに比較して、格段に速く、特定の問題を論理的に解決することができるであろう。可能な任意の確率的な旧知のアルゴリズムに比較して、速く稼働する、サイモンアルゴリズム等の量子アルゴリズムが存在する。一方で、量子コンピュータは、多くの暗号法の基礎となる問題を効率的に解決することができるため、これらの暗号法を実行不可能なものにしてしまう。しかしながら、本発明に係るシステム及び方法は、ともにＭｅｒｋｌｅ ｔｒｅｅの形態でハッシュベースの暗号化を使用するポスト量子セキュリティを提供するものであり、ハッシュベースの暗号化は、量子コンピュータに対して安全である（例えば、ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｐｏｓｔ−ｑｕａｎｔｕｍ＿ｃｒｙｐｔｏｇｒａｐｈｙを参照のこと）。

【0028】

本発明は、また、唯一のユーザ関連固有デジタル識別子（Ｄ−ＩＤ）を介して、プライバシー及びセキュリティを保証するネットワーク内の少なくとも１つのサービスプロバイダの少なくとも１つの、通常は、異なるサービスに対するアクセスをユーザに提供する方法にも関連する。この方法は、少なくとも、以下のステップを備える。
−ユーザの任意且つ所望の端末デバイス上で少なくとも部分的に稼働しているＤ−ＩＤエージェントを提供するステップと、
−Ｄ−ＩＤエージェントにより、ユーザのＤ−ＩＤ、ユーザの少なくとも１つのハンドルネーム、及びユーザ規定のハンドルネーム特有のシークレット番号とを生成するステップと、
−Ｄ−ＩＤエージェントにより、シークレット番号及び暗号学的ハッシュ関数を使用して、そのリーフとしてシークレットを有するハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅのルート値を計算するステップと、
−Ｄ−ＩＤエージェントにより、ともに認証暗号化法を使用して暗号化された少なくとも１つのハンドルネーム及び対応のルート値をＤ−ＩＤミドルウェアに送信するステップと、
−Ｄ−ＩＤミドルウェアを、ユーザのＤ−ＩＤの検証に対する、ユーザ及び少なくとも１つのサービスプロバイダの間のミドルウェアとして提供するステップと、
−Ｄ−ＩＤミドルウェアにより、ユーザのＤ−ＩＤ、各ハンドルネーム及び対応のルート値を備えるユーザの少なくとも１つのハンドルネームの各々に対するＭｅｒｋｌｅ ｔｒｅｅルート要素、並びに各ルート要素に対する信頼レベルを受信及び維持するステップと、
−ユーザが少なくとも１つのサービスプロバイダの異なるサービスのうち、所望の１つのサービスにアクセスすることを意図する時、少なくとも１つのハンドルネームのうちの１つを選択し、Ｄ−ＩＤエージェントにより、サービスプロバイダに対して、ハンドルネーム特有のシークレット番号のシークレットと、ハンドルネーム特有のＭｅｒｋｌｅ ｔｒｅｅから導き出される対応の認証パスとを明らかにし、サービスプロバイダにより、対応のルート値及び信頼レベルを受信するために、Ｄ−ＩＤミドルウェアにハンドルネームを転送し、サービスプロバイダにより、シークレット及び認証パスに基づき、ルート値を計算し、サービスプロバイダにより、それがハンドルネームについてＤ−ＩＤミドルウェアから受信したルート値に合致するか否かを検証することにより、ユーザがハンドルネームの所有者であることを検証し、そうであれば、選択されたハンドルネームの信頼レベルが少なくとも１つのサービスプロバイダによって要求されたものに対応する場合、ユーザに、少なくとも１つのサービスにアクセスさせるステップとを備える。

【0029】

本発明の方法の一実施形態によると、信頼レベルは、少なくとも１つのハンドルネーム及び対応のルート値をＤ−ＩＤエージェントからＤ−ＩＤミドルウェアに送信する手法に基づき、ミドルウェアによって割り当てられる。

【0030】

したがって、信頼レベルは、ともに暗号化された少なくとも１つのハンドルネーム及び対応のルート値をＤ−ＩＤミドルウェアに送信する時、他の認証暗号化方法を使用して更新される。認証方法／プロトコルは、通常、ユーザを識別、すなわち、ユーザのアイデンティティを検証し、最善のケースでは、そのユーザがアクティブである（リプレイアタックでない）ことを確認するために使用される方法である。このような認証方法の例として、Ｋｅｒｂｅｒｏｓ、ＩＰｓｅｃ、認証ベースＳＳＬ、パスワードベースＳＳＬ、任意のＳｉｎｇｌｅ Ｓｉｇｎ Ｏｎ Ｓｏｌｕｔｉｏｎ等が挙げられる。暗号化方法は、データの暗号化に使用される。通常、認証方法の実施中、キーが導き出され、これらが後に暗号化方法によって使用される。このような暗号化方法の例として、ＡＥＳ、ＳＮＯＷ、３Ｇ、又は任意のコード化機構が挙げられる。

【0031】

ユーザが少なくとも１つのサービスプロバイダの異なるサービスのうち、所望の１つのサービスへのアクセスを意図する時、サービスプロバイダは、また、最後に使用したシークレットのシークレットカウンタをＤ−ＩＤミドルウェアから受信し、更に、現在選択されたシークレットのシークレットカウンタが最後に使用したシークレットのシークレットカウンタ以上であることを検証する。

【0032】

クレームの方法の更に他の実施形態によると、所望のサービスにアクセスするために請求を行うことが必要とされ、サービスプロバイダにユーザのＤ−ＩＤを取得することが許可されない場合、請求情報は、Ｄ−ＩＤミドルウェアによって引き継がれ、Ｄ−ＩＤミドルウェアが請求代行を行う。

【0033】

以下の詳細な説明及び添付の図面は、本発明の性質及び効果をより理解させるためのものである。

【図面の簡単な説明】

【0034】

【図1】本発明に係るシステムの一実施形態により提供される、Ｄ−ＩＤミドルウェアで維持される情報の概略図である。

【図2】本発明に係るシステムの他の実施形態により提供される、Ｄ−ＩＤエージェントで生成されたＭｅｒｋｌｅ ｔｒｅｅの一例を示している。

【図3】本発明に係るシステムの更に他の実施形態により提供される、Ｄ−ＩＤエージェント及びＤ−ＩＤミドルウェア間の情報交換を概略的に示している。

【図4】本発明のシステムの更に他の実施形態により提供される、Ｄ−ＩＤミドルウェアで実施される信頼レベルの割り当てを例示している。

【図5】本発明のシステムの更に他の実施形態により提供される、Ｄ−ＩＤミドルウェアで実施されるハンドルネームの信頼レベルの更新を例示している。

【図6】クレームのシステムの一実施形態の機能を説明するブロック図を概略的に示している。

【発明を実施するための形態】

【0035】

図１は、本発明に係るシステムの一実施形態によって提供される、Ｄ−ＩＤミドルウェア１００で維持される情報の概略図である。Ｄ−ＩＤミドルウェア１００は、１名以上のユーザ（ここには図示せず）とサービスプロバイダＳＰ１、ＳＰ２、及びＳＰ３との間のミドルウェアを表す。Ｄ−ＩＤミドルウェアは、テーブル１５０の列１１０に示される通り、１名以上のユーザの各Ｄ−ＩＤを維持する。テーブル１５０の各行は、１名のユーザに割り当てられる。各ユーザは、各ユーザが規定可能な１つのＤ−ＩＤを有する。列１１０は、更に、サービスプロバイダＳＰ１、ＳＰ２、及びＳＰ３のうちのいずれのサービスプロバイダが各ユーザのＤ−ＩＤを各々把握するように許可されるかを示している。サービスプロバイダＳＰ１及びＳＰ２は、列１１０の第１行に示される通り、ユーザＡのＤ−ＩＤ「Ｍｓｂｅｉｔｉ」（ユーザＡは、図１には図示せず）を把握することが許可される。サービスプロバイダＳＰ３等、その他のサービスプロバイダは、ユーザＡのハンドルネームのみを知ることになる。サービスプロバイダＳＰ１及びＳＰ３は、列１１０の第２行に示される通り、ユーザＢのＤ−ＩＤ「Ｔｗｅｒｎａｄｏ」を把握することが許可される。サービスプロバイダＳＰ２等、その他のサービスプロバイダは、ユーザＢのハンドルネームのみを知ることになる。Ｄ−ＩＤミドルウェアは、列１１０の第３行において「…」で示される通り、更なるＤ−ＩＤと各サービスプロバイダに対する許可とを記憶及び維持することができる。列１２０において、Ｄ−ＩＤミドルウェアが更に異なるユーザに対するルート要素を管理することが示されている。各ルート要素は、少なくとも、列１２１に示される現在のシークレットカウンタと、列１２２に示されるルート値と、列１２３に示されるハンドルネームとを備える。ここに示される例において、テーブル１５０の第１行に割り当てられたユーザＡは、テーブル１５０の列１２３の第１行に挙げられた２つのハンドルネームＴｅｍｐＡｎｏｎｙｍ１及びＴｅｍｐＡｎｏｎｙｍ２を有する。各ハンドルネームについて、正確に１つのルート値（列１２２に示される）が生成及び記憶される。ハンドルネーム「ＴｅｍｐＡｎｏｎｙｍ１」について、ルート値「ａｃｖｏｊｉｆｊｏｗｉｊｆｅｗｏｊ」が生成される。ハンドルネーム「ＴｅｍｐＡｎｏｎｙｍ２」について、ルート値「ｓｌｈｓｌｊｈｓｌｋｊｄｈｌｓｈｈ」が生成される。これらのルート値は、Ｄ−ＩＤエージェント（ここには図示せず）によって生成される。ハンドルネーム、その対応のルート値、及び現在のシークレットカウンタは、ともに、Ｄ−ＩＤエージェントによって構築され、特定の送信方法を使用してＤ−ＩＤミドルウェア１００に送信されるルート要素を形成する。Ｄ−ＩＤミドルウェアは、列１３０に示される通り、この送信方法に基づき、各ルート要素を特定の信頼レベルに割り当てる。これは、例えば、ルート要素（２５、ａｃｖｏｊｉｆｊｏｗｉｊｆｅｗｏｊ、ＴｅｍｐＡｎｏｎｙｍ１）が信頼レベル「高」に割り当てられ、ルート要素（１２、ｓｌｈｓｌｊｈｓｌｋｊｄｈｌｓｈｈ、ＴｅｍｐＡｎｏｎｙｍ２）が信頼レベル「低」に割り当てられる。これらのルート要素はともに、Ｄ−ＩＤ「Ｍｓｂｅｉｔｉ」を有するユーザＡに割り当てられる。

【0036】

ハンドルネーム「Ｔｗｅｒｎａｄｏ」を有するユーザＢは、ルート要素（１３、Ｓｄｈｆｋｄｓｊｈｋｊｄｓｈｓ、ＴｅｍｐＡｎｏｎｙｍ３）に割り当てられる。Ｄ−ＩＤミドルウェアは、信頼レベル「中」をこのルート要素に割り当てる。

【0037】

異なるサービスプロバイダＳＰ１、ＳＰ２、及びＳＰ３は、異なる信頼レベルを要求する。サービスプロバイダＳＰ１が信頼レベル「高」を要求し、ＳＰ２が信頼レベル「中」を要求し、ＳＰ３が信頼レベル「低」を要求する。ハンドルネームの信頼レベルが、各サービスの要求される各サービスプロバイダが要求するものに対応する場合に限り、ユーザ（及びこのハンドルネームの所有者）は、他のすべてのアクセス条件が満たされれば、そのサービスへのアクセスを得ることができる。

【0038】

図２は、本発明に係るシステムの一実施形態を使用する時、各ユーザについて提供されるルート要素の生成プロセスを概略的に示している。ユーザが望む時にはいつでも、Ｄ−ＩＤエージェントは、２^ｎ個のシークレットを生成するが、ここでｎは、ユーザによって特定される構成パラメータである。各シークレットは、図２の下方に示される通り、形式２２０を有する。そこで、シークレットは、ユーザのハンドルネーム２２３、シークレットカウンタ２２１、及び乱数２２４からなる。

【0039】

Ｄ−ＩＤエージェントは、これらのシークレット及び暗号学的ハッシュ関数を使用して、そのリーフとしてシークレットを有するＭｅｒｋｌｅ ｔｒｅｅ２００のルート値を演算する。ここに示される例において、ユーザは、Ｄ−ＩＤエージェントが４つのシークレットＳｅｃｒｅｔ_１、Ｓｅｃｒｅｔ_２、Ｓｅｃｒｅｔ_３、及びＳｅｃｒｅｔ_４を生成するように、構成パラメータｎを「２」として特定している。ハッシュ関数「Ｈａｓｈ」を各シークレットに適用することにより、４つの値ｈ_１、ｈ_２、ｈ_３、及びｈ_４が各々生成される。各２つの値ｈ_１及びｈ_２と、ｈ_３及びｈ_４が、各々組み合わせられ、２つの値ｈ_１２及びｈ_３４を形成する。これら２つの値ｈ_１２及びｈ_３４は、関数「Ｈａｓｈ」を適用することによって組み合わせられ、結果としてルート値を生じる。

【0040】

図３は、本発明に係るシステムの一実施形態によって提供される、Ｄ−ＩＤエージェント３１０及びＤ−ＩＤミドルウェア３２０の間の一例としての交換を示している。Ｄ−ＩＤエージェント３１０は、各ユーザについて、Ｄ−ＩＤを生成するか、又は各ユーザがＤ−ＩＤを規定及び特定し、Ｄ−ＩＤエージェント３１０がサポートされる任意のデバイス及び認証方法３１１を使用してこのＤ−ＩＤをＤ−ＩＤミドルウェア３２０に送信する。更に、Ｄ−ＩＤエージェント３１０は、暗号化ハンドルネーム交渉３１２を介して各ユーザにより選択されたハンドルネームをＤ−ＩＤミドルウェア３２０に送信する。Ｄ−ＩＤエージェント３１０は、Ｄ−ＩＤミドルウェア３２０を通じて、ハンドルネームが固有であることを検証し、そうでなければ、Ｄ−ＩＤエージェント３１０がそれを再生成する。その後、Ｄ−ＩＤエージェント３１０は、新たに生成されたハンドルネームに対応するルート値３１３をＤ−ＩＤミドルウェア３２０に提出する。認証方法として、ＳＩＭ、パスワード、バイオメトリクス等を使用することができる。ユーザは、異なるハンドルネームを生成することができ、１つは教育用、１つはスポーツ用等とすることができることに留意する。

【0041】

Ｄ−ＩＤミドルウェア３２０は、ハンドルネーム及び対応のルート値をＤ−ＩＤミドルウェア３２０に送信する手法に基づき、信頼レベルを割り当てる。「送信手法」とは、認証方法及びデバイス種別を意味するものである。

【0042】

ステップ３１４において、Ｄ−ＩＤミドルウェア３２０は、例えば、図１に示される通り、異なるユーザのためにＤ−ＩＤミドルウェアが維持するテーブルを更新する。

【0043】

図４は、信頼レベルの割り当てを示している。Ｄ−ＩＤエージェントは、異なるデバイスを使用する。すなわち、Ｄ−ＩＤエージェントは、異なるデバイス上で少なくとも部分的に稼働する。ケース４０１及び４０２では、デバイスＡを使用し、ケース４０２ではデバイスＣを使用する。更に、ユーザのＤ−ＩＤをＤ−ＩＤミドルウェア４００に送信するために、異なる認証方法である認証方法Ａ又は認証方法Ｂを使用する。第１の送信手法４０５において、Ｄ−ＩＤエージェントは、デバイスＡ及び認証方法Ａを使用し、第２の送信手法４０６において、Ｄ−ＩＤエージェントは、デバイスＡ及び認証方法Ｂを使用し、第３の送信手法４０７において、Ｄ−ＩＤエージェントは、デバイスＣ及び認証方法Ｂを使用する。Ｄ−ＩＤミドルウェア４００は、Ｄ−ＩＤエージェントによって使用される各送信手法に対して、すなわち、表に示される通り、デバイス種別４１０及び認証方法４２０の各組み合わせについて、各信頼レベル４３０を記憶する。

【0044】

「認証方法Ａ／デバイス種別Ａ」の組み合わせは、信頼レベル「高」に割り当てられる。「認証方法Ａ／デバイス種別Ｂ」の組み合わせは、信頼レベル「中」に割り当てられる。「認証方法Ｃ／デバイス種別Ｂ」の組み合わせは、信頼レベル「低」に割り当てられる。

【0045】

図５は、いかにしてユーザのハンドルネームの信頼レベルが変更され、例えば、ユーザがアクセスを希望するサービスを提供するサービスプロバイダの要件に関して、任意の要件に合わせて調整可能であるかを概略的に示している。ユーザ、すなわち、Ｄ−ＩＤエージェント５１０は、既存のルート要素５１２の信頼レベルを調整するために、ハンドルネーム及び対応のルート値をＤ−ＩＤミドルウェア５２０に提出する時、他のデバイス及び／又は他の認証方法５１１を随時使用することができる。

【0046】

図６は、クレームのシステムの一実施形態の機能を説明するブロック図を概略的に示している。

【0047】

図６は、Ｄ−ＩＤエージェント６１０、Ｄ−ＩＤミドルウェア６２０、及びサービスプロバイダＳＰ６３０を示している。ユーザ（図示せず）は、サービスプロバイダＳＰ６３０によって提供されるサービスへのアクセスを希望している。このサービスを使用するには、サービスプロバイダＳＰ６３０は、信頼レベル「高」を要求する。ユーザは、サービスプロバイダＳＰ６３０のサービスへのアクセスを希望する時にはいつでも、そのサービスに対して使用を希望するハンドルネームのうちの１つを選択し、その後、Ｄ−ＩＤエージェント６１０は、ステップ６１１において、サービスプロバイダＳＰ６３０に対して、シークレットＳｅｃｒｅｔ_１及び対応の認証パス（Ｓｅｃｒｅｔ_１、ｈ_２、ｈ_３４）（これは、適切に生成及び記憶されたＭｅｒｋｌｅ ｔｒｅｅから導き出される）を明らかにする。サービスプロバイダＳＰ６３０は、ステップ６２２で対応のルート値、信頼レベル、最後に使用されたシークレットのカウンタ、及び許可される場合にはＤ−ＩＤを受信するために、ステップ６２１において、ハンドルネームをＤ−ＩＤミドルウェア６２０に転送する。サービスプロバイダＳＰ６３０自体は、Ｓｅｃｒｅｔ_１、ｈ_２、ｈ_３４に基づき、ステップ６６２において、ルート値６５２を計算し、ステップ６５５において、それがそのハンドルネームについてサービスプロバイダＳＰ６３０がＤ−ＩＤミドルウェア６２０から受信したルート値６５１に合致するか否かを検証することにより、ルート値６５１が、Ｄ−ＩＤエージェント６１０によって生成されてＤ−ＩＤミドルウェア６２０によって記憶されたＭｅｒｋｌｅ ｔｒｅｅ６５０の結果として生じる。ルート値６５１をＭｅｒｋｌｅ ｔｒｅｅ６５０から導き出す手法が短線で示されている。ルート値６５１及びルート値６５２が等しく、且つ、ステップ６６１においてＳｅｃｒｅｔ_１のシークレットカウンタがＳ−ｃｏｕｎｔｅｒ_ｎｅｗに等しい場合、サービスプロバイダＳＰ６３０は、ステップ６６０において、シークレットＳｅｃｒｅｔ_１が新しく、ユーザ／Ｄ−ＩＤエージェント６１０がそのハンドルネームの所有者であることを（ユーザのアイデンティティについて把握することなく）確信することができる。結果として、ハンドルネームの信頼レベルがサービスプロバイダＳＰ６３０のサービスへのアクセスに必要とされるものに対応する場合、ユーザはそのサービスへのアクセスを得る。サービスプロバイダＳＰ６３０がミドルウェア６２０への接触後、ユーザの、すなわち、そのシークレット、ハンドルネーム、ルート値の検証に成功する度に、Ｄ−ＩＤミドルウェア６２０は、Ｓ−ｃｏｕｎｔｅｒを１ずつ増加させる。すなわち、検証が成功した場合に限り、Ｓ−ｃｏｕｎｔｅｒは増加される。サービスにアクセスするために請求が必要とされ、サービスプロバイダＳＰ６３０にはユーザのＤ−ＩＤを取得することが許可されていない場合、請求情報は、Ｄ−ＩＤミドルウェアに引き継がれる。すなわち、Ｄ−ＩＤミドルウェア６２０が請求代行を行う。計算オーバーヘッドは、６６０で表される。Ｓｅｃｒｅｔ_１のシークレット構築は、６７０で指定されており、このシークレットは、ハンドルネーム６７２、Ｓ−ｃｏｕｎｔｅｒ６７４、及び乱数６７５からなる。

【0048】

したがって、ユーザのアイデンティティは、サービスプロバイダＳＰ６３０に明らかにされることはない。加えて、システムは、Ｍｅｒｋｌｅ ｔｒｅｅ６５０等のＭｅｒｋｌｅ ｔｒｅｅを使用することにより、量子コンピュータに対してロバストである。その上、図６における検証の計算オーバーヘッド６６０は、例えば、Ｓｂｅｉｔｉ Ｍらによる「Ｐｅｒｆｏｒｍａｎｃｅ ｅｖａｌｕａｔｉｏｎ ｏｆ ＰＡＳＥＲ - ａｎ Ｅｆｆｉｃｉｅｎｔ Ｓｅｃｕｒｅ Ｒｏｕｔｅ Ｄｉｓ−ｃｏｖｅｒｙ Ａｐｐｒｏａｃｈ ｆｏｒ Ｗｉｒｅｌｅｓｓ Ｍｅｓｈ Ｎｅｔｗｏｒｋｓ」ＩＥＥＥ、ＰＩＭＲＣ、オーストラリア、シドニー、２０１２年において説明される通り、本文脈中で広義に使用される非対称コードに比べて、５０倍超高速である。これとは別に、Ｄ−ＩＤエージェント６１０がクラウド内で部分的に稼働された場合、すなわち、シークレットがセキュアクラウドに記憶される場合、ユーザは、簡易に自らのデバイスをシェアすることができる。ユーザは、任意のデバイス上で稼働しているＤ−ＩＤエージェント６１０に自らのＤ−ＩＤを入力し、Ｄ−ＩＤエージェントは、残りすべてを引き受け、（Ｒｅｃｈｅｎｚｅｎｔｒｕｍにおけるコンピュータの一時的使用と同様に）現在のユーザのみに請求が行われるであろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】