(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-02-14
(54)【発明の名称】匿名署名スキームのユーザ制御のリンク可能性
(51)【国際特許分類】
H04L 9/32 20060101AFI20240206BHJP
【FI】
H04L9/32 200B
H04L9/32 200E
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023549647
(86)(22)【出願日】2021-04-28
(85)【翻訳文提出日】2023-08-16
(86)【国際出願番号】 EP2021061196
(87)【国際公開番号】W WO2022174933
(87)【国際公開日】2022-08-25
(32)【優先日】2021-02-19
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
(71)【出願人】
【識別番号】517451940
【氏名又は名称】エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー
(71)【出願人】
【識別番号】522176724
【氏名又は名称】イムデア・ソフトウェア・インスティテュート
(74)【代理人】
【識別番号】100108453
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】クラウディオ・ソリエンテ
(72)【発明者】
【氏名】ダリオ・フィオレ
(57)【要約】
リング署名またはグループ署名などの匿名署名スキームは、署名が公的に検証可能であるが、潜在的な署名者のセット内の署名者のアイデンティティを隠すように、メッセージに当事者が署名できるようにする。本発明の実施形態は、当事者のアイデンティティを明らかにすることなく、当事者の署名の任意のサブセットの作成者であることを当事者が証明することを可能にする。言い換えれば、署名者は、署名者の署名の任意のサブセットが「リンクされている」ことを証明することが可能である。本発明は、IoT、ブロックチェーン、およびTEEシナリオにおける直接的な応用性を有し、グループまたはリング署名が認証と匿名とのバランスをとるために使用される。
【特許請求の範囲】
【請求項1】
ユーザ制御のリンク可能性で匿名署名スキームを強化するための方法であって、
リング署名スキーム(10)またはグループ署名スキーム(20)の署名者(11、21)によって、署名者固有の秘密xを生成し、前記生成された秘密xに基づいて秘密鍵を生成するステップと、
前記署名者(11、21)によって、前記秘密xに関係のあるメッセージ特有の値で署名されるようにメッセージを拡張し、これにより拡張されたメッセージを生成するステップと、
前記署名者(11、21)によって、前記署名者の秘密鍵で前記拡張されたメッセージに署名するステップと、
前記署名者(11、21)によって、署名付きメッセージの任意のセットが同じ署名者固有の秘密xを埋め込んでいるという証拠を生み出すステップと、
前記署名者(11、21)によって、第三者の検証者(12、22)による検証のための前記生み出された証拠を匿名で公開するステップと
を含む、方法。
【請求項2】
メッセージに署名するために使用される鍵のペアを前記署名者(11、21)によって生成するステップであって、前記鍵のペアが、選択された秘密xおよび公開鍵に基づく前記秘密鍵を含む、ステップと、
前記署名スキーム(10、20)内で匿名通信のために使用される通信ネットワーク(13、23)を介して前記鍵のペアの前記公開鍵を公開するステップと
をさらに含む、請求項1に記載の方法。
【請求項3】
署名者(11、21)による任意のメッセージに前記署名するステップが、
前記署名者(11、21)のアイデンティティを保護するために公開鍵の任意のリングまたはグループを選ぶステップと、
前記署名付きメッセージ、および前記メッセージに署名するために使用される公開鍵の前記リングまたはグループと共に、前記生成された署名を匿名で公開するステップと
を含む、請求項1または2に記載の方法。
【請求項4】
署名者(11、21)による任意のメッセージに前記署名するステップが、
署名されることになる前記メッセージ、メッセージ特有のパラメータg、および署名されることになる前記メッセージを前記署名者固有の秘密xに結びつける追加のパラメータβを含むタプルを生成するステップと、
前記タプルに署名するステップと
を含む、請求項1から3のいずれか一項に記載の方法。
【請求項5】
前記メッセージ特有のパラメータgがランダムに選ばれ、前記選ばれたパラメータgが有限巡回群Gの生成元として機能する、請求項4に記載の方法。
【請求項6】
前記追加のパラメータβがβ=g
xとして計算されるように決定される、請求項4または5に記載の方法。
【請求項7】
前記署名者固有の秘密xが暗号学的ハッシュ関数Hを使用することによって生成される、請求項4から6のいずれか一項に記載の方法。
【請求項8】
前記暗号学的ハッシュ関数Hが、H():{0,1}
*→Z
qとして定義され、qが前記有限巡回群Gの次数を表し、前記署名者固有の秘密xがZ
qからランダムに選ばれる、請求項7に記載の方法。
【請求項9】
署名の固有セットのリンケージに関して署名者(11、21)によって生み出された証拠を検証するステップが、
前記それぞれのパラメータgに関する前記それぞれのパラメータβの個別ログが、署名の前記固有セットのうちの全ての署名にとって同じであるかどうかをチェックするステップ
を含む、請求項4から8のいずれか一項に記載の方法。
【請求項10】
署名の固有セットの前記リンケージに関して署名者(11、21)によって生み出された証拠を検証するステップが、
署名の前記セットのうちの各署名の有効性をチェックするステップと、
署名の前記セットのうちの全ての署名および前記証拠が有効な場合、署名の前記固有セットのうちの前記署名を、同じ当事者によって発行された有効な署名であると判定するステップと
を含む、請求項1から9のいずれか一項に記載の方法。
【請求項11】
異なるサービスプロバイダ(33)を有するユーザ(32)によって使用される異なるアイデンティティに関係があるブロックチェーン(31)における署名付きユーザ登録トランザクションの固有セットの前記署名が、同じユーザ(32)によって発行された有効な署名であるという判定が、前記サービスプロバイダ(33)の間でユーザ(32)資産を移転するための必要条件として使用される、請求項1から10のいずれか一項に記載の方法。
【請求項12】
サービスプロバイダ(43)に向けたIoTデバイス(44)の測定レポートの固有セットの前記署名が、同じ当事者(42)によって発行された有効な署名であるという判定が、前記サービスプロバイダ(43)からのターゲット提案を前記当事者(42)に提供するための必要条件として使用される、請求項1から10のいずれか一項に記載の方法。
【請求項13】
匿名署名スキーム(10、20)において署名者(11、21)として機能するように構成されるネットワークデバイスであって、前記ネットワークデバイスが、プロセッサおよびメモリを備え、前記メモリが、プロセッサ実行可能命令を備え、前記プロセッサ実行可能命令が、前記プロセッサによって実行されると、
署名者固有の秘密xを生成し、前記生成された秘密xに基づいて秘密鍵を生成することと、
前記秘密xに関係のあるメッセージ特有の値で署名されるようにメッセージを拡張し、これにより拡張されたメッセージを生成することと、
前記署名者の秘密鍵で、前記拡張されたメッセージに署名することと、
署名付きメッセージの任意のセットが同じ署名者固有の秘密xを埋め込んでいるという証拠を生み出すことと、
第三者の検証者(12、22)による検証のために、前記生み出された証拠を匿名で公開することと
を備える、ユーザ制御のリンク可能性で前記匿名署名スキーム(10、20)を強化するための動作を前記プロセッサに実施させる、ネットワークデバイス。
【請求項14】
任意のメッセージへの前記署名が、
署名されることになる前記メッセージ、メッセージ特有のパラメータg、および署名されることになる前記メッセージを前記署名者固有の秘密xに結びつける追加のパラメータβを含むタプルを生成することと、
前記タプルに署名することと
を行うステップを含む、請求項13に記載のネットワークデバイス。
【請求項15】
前記メッセージ特有のパラメータgがランダムに選ばれ、前記選ばれたパラメータg、有限巡回群Gの生成元として機能し、前記追加のパラメータβがβ=g
xとして計算されるように決定される、請求項14に記載のネットワークデバイス。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ユーザ制御のリンク可能性で匿名署名スキームを強化するための方法、および匿名署名スキームにおいて署名者として機能するように構成されるネットワークデバイスに関する。
【背景技術】
【0002】
匿名署名スキーム(すなわち、リング署名およびグループ署名)は、潜在的な署名者のセット内の、公的に検証可能であるが署名者の匿名性を保つ署名を、当事者が生み出すことを可能にする。特に、リング署名は、臨時に選ばれた潜在的な署名者の、「リング」と呼ばれるグループに代わって、当事者が署名を生み出すことを可能にするが、署名は、リング内の署名者を明らかにしない。同様に、グループ署名は、各グループメンバがグループに代わってメッセージに署名できるように、グループマネージャがグループメンバを定義することを可能にする。署名は、公的に検証可能であるが、実際の署名者を開示しない。簡単に言えば、グループ署名のための匿名セットは、グループマネージャによって認められるような全てのグループメンバのセットであり、その一方でリング署名のための匿名セットは、署名を生み出した瞬間に署名者によって任意に選ばれたリングに含まれる公開鍵のセットである。
【0003】
それでも、リング署名もグループ署名も、署名者が署名の任意のセットを生み出したことを、署名者が証明できるようにしていない。特に、リング(またはグループ)署名のセット(σ1、σ2、...、σn)がAliceによって生み出されたと仮定して、現在のスキームは、Aliceがこれらの全てを生み出したことを、Aliceが証明できるようにしていない。
【発明の概要】
【発明が解決しようとする課題】
【0004】
したがって、当事者のアイデンティティを明らかにすることなく,当事者の署名の任意のサブセットが同じエンティティによって生み出されたことを当事者が証明できるような方式で、リング署名スキームおよびグループ署名スキームを改善し、さらに発展させることが本発明の目的である。
【課題を解決するための手段】
【0005】
本発明によれば、前述の目的は、ユーザ制御のリンク可能性で匿名署名スキームを強化するための方法によって達成され、方法は、リング署名スキームまたはグループ署名スキームの署名者によって、署名者固有の秘密xを生成し、生成された秘密xに基づいて秘密鍵を生成することと、署名者によって、秘密xに関係のあるメッセージ特有の値で署名されるようにメッセージを拡張し、これにより拡張されたメッセージを生成することと、署名者によって、署名者の秘密鍵で、拡張されたメッセージに署名することと、署名者によって、署名付きメッセージの任意のセットが同じ署名者固有の秘密xを埋め込んでいるという証拠を生み出すことと、署名者によって、第三者の検証者による検証のために、生み出された証拠を匿名で公開することとを含む。
【0006】
さらに、前述の目的は、匿名署名スキームにおいて署名者として機能するように構成されるネットワークデバイスによって達成され、ネットワークデバイスは、プロセッサおよびメモリを備え、メモリは、プロセッサによって実行されると、署名者固有の秘密xを生成し、生成された秘密xに基づいて秘密鍵を生成することと、秘密xに関係のあるメッセージ特有の値で署名されるようにメッセージを拡張し、これにより拡張されたメッセージを生成することと、署名者の秘密鍵で、拡張されたメッセージに署名することと、署名付きメッセージの任意のセットが同じ署名者固有の秘密xを埋め込んでいるという証拠を生み出すことと、第三者の検証者による検証のために、生み出された証拠を匿名で公開することと、という、ユーザ制御のリンク可能性で匿名署名スキームを強化するための動作をプロセッサに実施させるプロセッサ実行可能命令を備える。
【0007】
本発明の実施形態は、当事者のアイデンティティを明らかにすることなく、当事者の署名の任意のサブセットの作成者であることを当事者が証明することを可能にする。言い換えれば、署名者は、署名者の署名の任意のサブセットが「リンクされている」ことを証明することが可能である。したがって、本発明の実施形態は、匿名と認証とのバランスをとるために匿名署名スキームが使用されるシナリオにおける自然な応用性を見いだす。
【0008】
本発明は、IoT、ブロックチェーン、およびTEEシナリオにおける直接的な応用性を有する。例えば、スマートシティ応用のようなIoT応用では、本発明の実施形態は、レポートされた測定値のプライバシを制御するため、および、例えば、個人向けの統計または提案に対して、これらのデバイスによって生み出された測定値をユーザがリンクできるようにするために、使用されてもよい。同様に、いくつかのブロックチェーン技術は、リング署名を使用して、トランザクションを発行する当事者の匿名性を保証する。本発明の実施形態は、当事者が生み出したトランザクションのセットを当事者が任意に選択すること、および、実際にこれらのトランザクションのうちの全てが、同じ当事者によって生み出された(すなわち、署名された)ことを検証者に証明することを可能にしてもよい。
【0009】
本発明の実施形態によれば、メッセージに署名するために使用される鍵のペアを署名者が生成することであって、鍵のペアは、選択された秘密xおよび公開鍵に基づく秘密鍵を含む、生成することが行われてもよい。鍵のペアの公開鍵は、署名スキーム内の匿名通信のために使用される通信ネットワークを介して公開されてもよい。
【0010】
実施形態によれば、署名者による任意のメッセージへの署名は、署名者のアイデンティティを保護するために公開鍵の任意のリングまたはグループを選ぶことと、署名付きメッセージ、およびメッセージに署名するために使用される公開鍵のリングまたはグループと共に、生成された署名を匿名で公開することとを行うステップを含んでもよい。
【0011】
実施形態によれば、署名者による任意のメッセージmへの署名は、署名されることになるメッセージmと、メッセージ特有のパラメータgと、署名されることになるメッセージを署名者固有の秘密xに結びつける追加のパラメータβとを含むタプルを生成することを行うステップを含んでもよい。ねらいは、メッセージごとに一意であり、鍵生成時に定められた秘密xに関係のある値を、署名されることになる各メッセージに含めることである。したがって、署名者がメッセージmに署名することを望むとき、署名者はむしろ、タプル(m,β,g)に署名する。
【0012】
実施形態によれば、メッセージ特有のパラメータgがランダムに選ばれ、選ばれたパラメータgが、有限巡回群Gの生成元として機能することが行われてもよい。パラメータβは、β=gxとして計算されるように決定されてもよい。
【0013】
実施形態によれば、署名者固有の秘密xは、暗号学的ハッシュ関数Hを使用することによって生成されてもよい。ハッシュ関数Hは、H():{0,1}*→Zqとして定義されてもよく、ここで、qは、有限巡回群Gの次数(order)を表し、署名者固有の秘密xは、Zqからランダムに選ばれる。
【0014】
実施形態によれば、署名の固有セットのリンケージに関して署名者によって生み出された証拠を検証することは、それぞれのパラメータgに関するそれぞれのパラメータβの個別ログが、署名の固有セットのうちの全ての署名にとって同じであるかどうかをチェックすることを含むことが提供されてもよい。例えば、メッセージ(m1,β1,g1)に対する署名σ1およびメッセージ(m2,β2,g2)に対する署名σ2が、同じ当事者によって実際に発行されたことを証明することは、g1に関するβ1の個別ログが、σ2に関するβ2の個別ログに等しいことを知っているという証拠を発行することによって行われてもよい(これは、基本的に、β1およびβ2が指数における同じ「X」を有するという証拠である)。
【0015】
実施形態によれば、署名の固有セットのリンケージに関して署名者によって生み出された証拠を検証することは、署名のセットのうちの各署名の有効性をチェックすることと、署名のセットのうちの全ての署名および証拠が有効な場合、署名の固有セットのうちの署名を、同じ当事者によって発行された有効な署名であると判定することとを含むことが提供されてもよい。
【0016】
本発明の実施形態によれば、ユーザ制御のリンク可能性メカニズムで強化された署名スキームは、追加の機能性を分散型台帳(例えば、ブロックチェーン)応用シナリオに提供するために活用されてもよい。例えば、異なるサービスプロバイダを有するユーザによって使用される異なるアイデンティティに関係があるブロックチェーンにおける署名付きユーザ登録トランザクションの固有セットの署名が、同じユーザによって発行された有効な署名であると判定されたことが、サービスプロバイダ間でユーザ資産を移転するための必要条件として使用されてもよいことが提供されてもよい。
【0017】
本発明の実施形態によれば、ユーザ制御のリンク可能性メカニズムで強化された署名スキームは、追加の機能をIoT(例えば、スマートシティ)応用シナリオに提供するために活用されてもよい。例えば、サービスプロバイダに対するIoTデバイスの測定レポートの固有セットの署名が、同じ当事者によって発行された有効な署名であると判定したことが、サービスプロバイダからの当事者ターゲット提案を提供するための必要条件として使用されてもよいことが提供されてもよい。代替として、サービスプロバイダに対するIoTデバイスの測定レポートの固有セットの署名が、同じ当事者によって発行された有効な署名であるという証拠は、個人向けの統計を生成するための基礎として使用されてもよい。
【0018】
本発明の教示を有利な方式でどのようにデザインし、さらに発展させるかについてのいくつかの方式がある。この目的のために、これは、一方では従属請求項を、および、他方では図で示された本発明の好ましい実施形態の以下の説明を、例として参照することである。図の助力による本発明の好ましい実施形態の説明と共に、教示の一般に好ましい実施形態およびさらなる発展が説明されることになる。
【図面の簡単な説明】
【0019】
【
図1】本発明の実施形態による、リング署名スキームにおいてユーザ制御のリンク可能性を実装するためのメカニズムを示す概略図である。
【
図2】本発明の実施形態による、グループ署名スキームにおいてユーザ制御のリンク可能性を実装するためのメカニズムを示す概略図である。
【
図3】本発明の実施形態による、ブロックチェーン応用シナリオにおけるユーザ制御のリンク可能性で強化された署名スキームの実装形態を示す概略図である。
【
図4】本発明の実施形態による、スマートシティ応用シナリオにおけるユーザ制御のリンク可能性で強化された署名スキームの実装形態を示す概略図である。
【発明を実施するための形態】
【0020】
本発明の実施形態は、特に、リング署名またはグループ署名といった、匿名署名スキームに適用され、潜在的な署名者のセット内の署名者のアイデンティティを同時に隠しつつ、署名が公的に検証可能であるように、署名スキームの当事者がメッセージに署名できるようにする。
図1は、リング署名スキームの文脈で本発明の実施形態を示し、その一方で、
図2は、グループ署名スキームの文脈で本発明の実施形態を示す。
【0021】
図1を参照しながら本発明の実施形態の詳細を説明する前に、まず、従来の先行技術のリング署名スキームの一般的な態様の概観が以下に提供される。
【0022】
一般に、リング署名スキームθは、以下のように定義可能なアルゴリズムのタプルである。
- (SK,PK):=KeyGen(1k)。これは、セキュリティパラメータkの入力と同時に、秘密鍵SKおよび公開鍵PKを出力する鍵生成アルゴリズムである。
- σ:=Sign(SK,R,m)。これは、秘密鍵SK、(サイズ≧2の)公開鍵Rの(「リング」と呼ばれる)セット、およびメッセージmの入力と同時に、署名σを出力する署名アルゴリズムである。
- {1/0}:=Verify(R,m,σ)。これは、公開鍵Rのセット、メッセージm、および署名σの入力と同時に、1(すなわち「有効」)または0(すなわち「無効」)を出力する検証アルゴリズムである。
【0023】
略式では、任意の正の整数nに対して、各(SKi,PKi)がKeyGen(1k)の実行によって出力された任意の{(SK,PKi)}i∈[n]、任意のj∈[n]、および任意のメッセージmに対して、Verify(R,m,Sign(SKj,R,m))=1であることをリング署名スキームθが保持し、ここでRが、PKjを含む{(SKi,PKi)}i∈[n]における公開鍵の任意のサブセットである場合、リング署名スキームθは正しい。
【0024】
略式では、(サイズ≧2の)公開鍵Rの任意のリング、および任意のメッセージmに対して署名σが計算されると仮定して、Rにおける公開鍵に対応する秘密鍵の全ての中で、どの秘密鍵がσを生み出すために使用されたかを相手が言えない場合、リング署名スキームθは匿名である。
【0025】
略式では、2つの署名σi、σjを仮定して、これらの署名が同じ署名者によって生成されたかどうかを相手が言えない場合、リング署名スキームθはリンク不可能である。
【0026】
略式では、Rにおける公開鍵のうちの1つに対応する秘密鍵を相手が知らない限り、または、Rにおける公開鍵のうちの1つに対応する秘密鍵を保持する1人の誠実なユーザが、同じメッセージおよび同じリングに対する署名を以前に出力したことがない限り、公開鍵Rの任意のリング、および任意のメッセージmに対して計算された有効な署名σを相手が生み出せない場合、リング署名スキームθは偽造不可能である。
【0027】
本発明の実施形態は、上述のように、ユーザ制御のリンク可能性をリング署名スキームに追加する。この文脈では、本発明は、当事者の(リング)署名のうちのいずれか2つ以上が、当事者のアイデンティティを明らかにすることなく、同じ当事者によって実際に生み出されたことを、当事者が証明できるようにすることを目標とする。
【0028】
上記で紹介されたようなリング署名スキームθを仮定して、すなわちアルゴリズム(KeyGen、Sign、Verify)を用いて、本発明の実施形態は、以下のようなアルゴリズム(KeyGen、Sign、Verify、LinkProve、LinkVerify)を、ユーザ制御のリンク可能性Δを伴うリング署名スキームに提供する。下記で使用される表記法では、Gは、離散対数想定(discrete logarithm assumption)が保持する有限巡回群を表し、qは、Gの次数を表す。さらに、H():{0,1}*→Zqは、暗号学的ハッシュ関数を表す。
【0029】
Δ.KeyGen(1k)
(SK',PK'):=θ.KeyGen(1k)を計算する
Zqからxをランダムに選ぶ
SK:=(SK',x)およびPK:=PK'をセットする
(SK',PK')を出力する
【0030】
Δ.Sign(SK,R,m)
SKを(SK',x)としてパースする
Gの生成元であるgをランダムに選ぶ
β:=gxを計算する
m':=(m,β,g)をセットする
α:=θ.Sign(SK',R,m')を計算する
σ=(α,β,g)を出力する
【0031】
Δ.Verify(R,m,σ)
σを(α,β,g)としてパースする
m':=(m,β,g)をセットする
θ.Verify(R,m',α)を出力する
【0032】
Δ.LinkProve(SK,(σ1,m1,R1),...,(σn,mn,Rn))
SKを(x,SK')としてパースする
i∈[n]の場合、σiを(αi,βi,gi)としてパースする
i∈[n]の場合、Si=H(m1,...,mn,i)を計算する
h=Πi=1..ngi
s
iを計算する
Zqからrをランダムに選び、t:=hrをセットする
c:=H(σ1,...,σn,m1,...,mn,R1,...,Rn,t)を計算する
z:=r+x・cを計算する
π=(t,z)を出力する
【0033】
Δ.LinkVerify(((σ1,m1,R1),...,(σn,mn,Rn)),π)
πを(t,z)としてパースする
i∈[n]の場合、σiを(αi,βi,gi)としてパースする
i∈[n]の場合、Si=H(m1,...,mn,i)を計算する
h=Πi=1..ngi
s
iを計算する
β=Πi=1..nβi
s
iを計算する
c:=H(σ1,...,σn,m1,...,mn,R1,...,Rn,t)を計算する
hz=t・βcの場合、1を出力し、そうでない場合、0を出力する。
【0034】
ユーザ制御のリンク可能性を伴わないリング/グループ署名スキームに比べて、上記のアルゴリズムを適用することによって、Zqにおける1つの要素およびGにおける1つの要素によって、署名のサイズが増加する。
【0035】
図1は、本発明の実施形態による、リング署名スキーム10におけるユーザ制御のリンク可能性を実装するためのメカニズムを示している。メカニズムは、上記で紹介されたアルゴリズムに基づいて説明されることになるが、これらのアルゴリズムは例示にすぎず、アルゴリズムの具体的な実装形態は、上記で示された仕様とは異なってもよいことが当業者によって認識されよう。
【0036】
図1に示されたシナリオの文脈では、署名者/証明者11および検証者12が匿名通信ネットワーク13を介して通信することが想定されている。この想定がない場合、-リング署名によって要求されるような-匿名は、有効でなくなるはずであることに留意されたい。
【0037】
まず、
図1に示されていないが、署名者/証明者11は、上記で指定されたような、アルゴリズムΔ.KeyGenを実行することによって鍵のペアを計算する。公開鍵は、例えば、パブリッククラウド上または分散型台帳上に、通信ネットワーク13を介して公開される。この時点から、署名者/証明者11は、そのアイデンティティを保護するために、公開鍵の任意のリングを選ぶことによって任意のメッセージに署名可能である。署名手順は、上記で指定されたような、アルゴリズムΔ.Signを実行することによって実行されてもよく、これは、ステップS110
1において第1の署名σ
1について、およびステップS110
2において第2の署名σ
2について、
図1に例示的に示されている。署名σ
iは、署名付きメッセージm
i、および署名するために使用されるリングR
iと共に、ステップS120
1およびS120
2に示されたように、通信ネットワーク13を介して匿名で公開される。
【0038】
ある時点で、署名者/証明者11は、署名者/証明者11が生み出した署名の任意のサブセットが、署名者/証明者11のアイデンティティを明らかにすることなく、同じ当事者によって生み出されたことを、検証者12に対して証明することを望む。特に、
図1のシナリオでは、署名σ
1およびσ
2が同じ当事者によって生み出されたことを証明することを署名者/証明者11が望むことが想定されている。そうするために、ステップS130に示されたように、署名者/証明者11は、Δ.LinkProveを実行し、証拠πを生み出す。ステップS140に示されたように、証拠πも、通信ネットワーク13を介して匿名で公開される。
【0039】
その一方で、ステップS150に示されたように、検証者12は、各署名、すなわち図示のシナリオにおけるσ1およびσ2の有効性を、これらの署名のそれぞれに対してΔ.Verifyを実行することによって最初にチェックする。追加として、検証者12は、Δ.LinkVerifyを実行することによって証拠πをチェックする。全ての署名および証拠が有効な場合、検証者12は、σ1およびσ2が、同じ当事者によって発行された2つの有効な署名であると結論を下す。
【0040】
図2は、グループ署名スキームに関する本発明の実施形態を示す。一般に、グループ署名スキームは、リング署名スキームのものと類似の匿名対策を有するデジタル署名スキームである。特に、グループ署名スキームには、システムをセットアップし、グループ公開鍵を公開するグループマネージャがある。グループマネージャはまた、当事者に署名鍵を提供することによって当事者がグループに加わることを認める。グループに加わった後、各当事者は、グループに代わってメッセージに署名することができ、その結果、署名は、グループ公開鍵を使用して公的に検証可能になるが、署名は、グループの全てのメンバ間で実際の署名者の匿名性を維持する。
【0041】
一般に、グループ署名スキームは、以下のアルゴリズムを含んでもよい。
- (gSK,uSK1,...,uSKn,gPK):=KeyGen(1k)。これは、セキュリティパラメータkの入力と同時に、グループマネージャのための秘密鍵gSK、n個のユーザ秘密鍵、およびグループ公開鍵gPKを出力する鍵生成アルゴリズムである。ユーザ秘密鍵は、グループのメンバにセキュアに配布され、その一方でグループ公開鍵は公開される。
- σ:=Sign(uSK,m)。これは、ユーザ秘密鍵uSKおよびメッセージmの入力と同時に、署名σを出力する署名アルゴリズムである。
- {1/0}:=Verify(gPK,m,σ)。これは、グループ公開鍵gPK、メッセージm、および署名σの入力と同時に、1(すなわち「有効」)または0(すなわち「無効」)を出力する検証アルゴリズムである。
【0042】
略式では、任意の正の整数nに対して、KeyGen(1k)によって出力された鍵の任意のセット(gSK,uSK1,...,uSKn,gPK)、任意のj∈[n]、および任意のメッセージmに対して、Verify(gPK,m,Sign(uSKj,m))=1を有する場合、Γは正しい。
【0043】
略式では、署名σがメッセージmに対して計算されると仮定して、(uSK1,...,uSKn)の中から、σを生み出すためにどの秘密鍵が使用されたかを相手が言えない場合、Γは匿名である。
【0044】
略式では、2つの署名を仮定して、2つの署名が同じ署名者によって生成されたかどうかを相手が言えない場合、Γはリンク不可能である。
【0045】
略式では、相手が秘密鍵uSKj、j∈[n]を知らない限り、または1つの誠実なグループメンバが、同じメッセージおよび同じリングに対する署名を以前に出力したことがない限り、任意のメッセージmに対して計算された有効な署名σを相手が生み出せない場合、Γは偽造不可能である。
【0046】
上記の説明は、静的なグループ(すなわち、KeyGenを介してグループマネージャによってグループのメンバ署名鍵が定義されたグループ)を定義することに留意されたい。それでも、いくつかのグループ署名スキームは、発行者とそれぞれのメンバとの間で双方向の結合プロトコルによってメンバ署名鍵が出力される動的なグループを可能にする。さらに、グループ署名スキームは、グループマネージャまたは別の指名された当事者が、署名を「開く」こと、すなわち、固有署名の署名者の匿名性を解除することを可能にする。本発明の実施形態によれば、本明細書で説明される技術は、グループ定義が静的か動的かに関わらず、および開く機能に関わらず、ユーザ制御のリンク可能性を任意のグループ署名スキームに提供するために使用可能である。
【0047】
本発明の実施形態は、上述のようなグループ署名スキームにユーザ制御のリンク可能性を追加する。この文脈では、本発明は、当事者のグループ署名のうちのいずれか2つ以上が、当事者のアイデンティティを明らかにすることなく、実際に同じ当事者によって生み出されたことを、当事者が証明できるようにすることを目標とする。
【0048】
上記で紹介されたようなグループ署名スキームΓを仮定して、すなわち、アルゴリズム(KeyGen、Sign、Verify)を用いて、本発明の実施形態は、以下のように、アルゴリズム(KeyGen、uKeyGen、Sign、Verify、LinkProve、LinkVerify)を、ユーザ制御のリンク可能性Δを伴うグループ署名スキームに提供する。下記で使用される表記法では、Gは、離散対数想定が保持する有限巡回群を表し、qは、Gの次数を表す。さらに、H():{0,1}*→Zqは、暗号学的ハッシュ関数を表す。
【0049】
Δ.KeyGen(1k)
(gSK,uSK1,...,uSKn,gPK):=Γ.KeyGen(1k)を計算する
(gSK,uSK1,...,uSKn,gPK)を出力する
【0050】
Δ.uKeyGen(uSK,1k)
Zqからxをランダムに選ぶ
SK:=(uSK,x)セットする
(SK)を出力する
【0051】
Δ.Sign(SK,m)
SKを(uSK,x)としてパースする
Gの生成元であるgをランダムに選ぶ
β:=gxを計算する
m':=(m,β,g)をセットする
α:=Γ.Sign(uSK,m')を計算する
σ=(α,β,g)を出力する
【0052】
Δ.Verify(gPK,m,σ)
σを(α,β,g)としてパースする
m':=(m,β,g)をセットする
Γ.Verify(gPK,m',α)を出力する
【0053】
Δ.LinkProve(SK,(σ1,m1),...,(σn,mn))
SKを(uSK,x)としてパースする
i∈[n]の場合、σiを(αi,βi,gi)としてパースする
i∈[n]の場合、si=H(m1,...,mn,i)を計算する
h=Πi=1..ngi
s
iを計算する
Zqからrをランダムに選び、t:=hrをセットする
c:=H(σ1,...,σn,m1,...,mn,t)を計算する
z:=r+x・cを計算する
π=(t,z)を出力する
【0054】
Δ.LinkVerify(((σ1,m1),...,(σn,mn)),π)
πを(t,z)としてパースする
i∈[n]の場合、σiを(αi,βi,gi)としてパースする
i∈[n]の場合、si=H(m1,mn,i)を計算する
h=Πi=1..ngi
s
iを計算する
β=Πi=1..nβi
s
iを計算する
c:=H(σ1,...,σn,m1,...,mn,t)を計算する
hz=t・βcの場合、1を出力し、そうでない場合、0を出力する。
【0055】
図2は、本発明の実施形態による、グループ署名スキーム20におけるユーザ制御のリンク可能性を実装するためのメカニズムを示している。メカニズムは、上記で紹介されたアルゴリズムに基づいて説明されることになるが、これらのアルゴリズムは例示にすぎず、アルゴリズムの具体的な実装形態は、上記で示された仕様とは異なってもよいことが当業者によって認識されよう。
【0056】
グループマネージャ(
図2に図示せず)は、上記で紹介されたような、例えば、Δ.KeyGenを実行することによって、公開鍵および秘密鍵を定義する。グループ公開鍵は、例えば、パブリッククラウド上または分散型台帳上で公開されることになるが、各メンバ秘密鍵は、それぞれのグループメンバにセキュアに移送される。次に、各グループメンバは、例えば、Δ.uKeyGenを実行することによって、受信した秘密鍵を使用して、独自のユーザ固有の秘密鍵を生成する。
【0057】
具体的には、
図2は、本発明の実施形態による、グループメンバが、どのようにメッセージに署名し、リンク可能性を証明するかを示している。署名者/証明者21および検証者22は、匿名通信ネットワーク23を介して互いに通信することが想定されている。この想定がない場合、-グループ署名によって要求されるような-匿名は、有効でなくなるはずであることに留意されたい。
【0058】
任意のメッセージへの署名は、上記で指定されたような、アルゴリズムΔ.Signを実行することによって実行されてもよく、これは、ステップS210
1において第1の署名σ
1について、およびステップS210
2において第2の署名σ
2について、
図2に例示的に示されている。署名σ
iは、署名付きメッセージm
iと共に、ステップS220
1およびS220
2に示されたように、通信ネットワーク23を介して匿名で公開される。
【0059】
ある時点で、署名者/証明者21は、当事者が生み出した任意の署名のサブセットが、当事者のアイデンティティを明らかにすることなく、同じ当事者によって生み出されたことを、検証者22に証明することを望む。特に、
図2のシナリオでは、署名σ
1およびσ
2が同じ当事者によって生み出されたことを証明することを署名者/証明者21が望むことが想定されている。そうするために、ステップS230に示されたように、署名者/証明者11は、Δ.LinkProveを実行し、証拠πを生み出す。ステップS240に示されたように、証拠πも、通信ネットワーク23を介して匿名で公開される。
【0060】
その一方で、ステップS250に示されたように、検証者22は、各署名、すなわち図示のシナリオにおけるσ1およびσ2の有効性を、これらの署名のそれぞれに対して、例えば、Δ.Verifyを実行することによって最初にチェックする。追加として、検証者22は、例えば、Δ.LinkVerifyを実行することによって、証拠πをチェックする。全ての署名および証拠が有効な場合、検証者22は、σ1およびσ2が、同じ当事者によって発行された2つの有効な署名であると結論を下す。
【0061】
本発明の実施形態によれば、ユーザ制御のリンク可能性メカニズムは、分散型台帳システムのコンテキストで実装されてもよい。この点に関して、
図3は、追加の機能をブロックチェーン応用シナリオ30に提供するために本発明が活用される可能なユースケースを示している。より詳細には、
図3は、アイデンティティ管理のために使用されるブロックチェーン31を示しており、ここでは、ユーザ32が自分のアイデンティティを登録し、
図3にSPaおよびSPbと表されたサービスプロバイダ33が、ブロックチェーン31を活用してユーザ32を認証する。
【0062】
ユーザは、異なるサービスプロバイダで使用されることになる複数のアイデンティティを有することがある。例えば、
図3に示されたように、ユーザ32は、サービスプロバイダSPaに対するアイデンティティIDa、およびサービスプロバイダSPbに対するアイデンティティIDbを使用する。アイデンティティ登録は、ステップS310においてユーザ32の第1のアイデンティティIDaのために、およびステップS320においてユーザ32の第2のアイデンティティIDbのために示されたように、トランザクションをブロックチェーン31に発行することによって実行される。
【0063】
本発明の実施形態によれば、アイデンティティ登録トランザクションのそれぞれは、合法ユーザ32のアイデンティティを維持しつつ、合法ユーザ32によってトランザクションが発行されたことを保証するために、グループまたはリング署名で署名される。サービスプロバイダ33は、例えば、上述のΔ.Verifyルーチンを実行することによって、署名の有効性をチェックし、これによりユーザのアイデンティティIDaおよびIDbを認証することによって、検証者として機能してもよい。サービスプロバイダSPaに対して、この認証は、ステップS330において示され、同様に、サービスプロバイダSPbに対しては、ステップS340において示されている。
【0064】
後のステージにおいて、この同じユーザ32は、SPaの自分のアカウントからSPbの自分のアカウントに資産を移転することを望むことがある。そうするために、ユーザ32は、本発明の実施形態による匿名署名のリンク可能性を達成するためのユーザ制御のメカニズムを実行してもよい。具体的には、このようなメカニズムは、ステップS350に示されたように、ユーザ32の2つのアイデンティティをリンクするため、すなわち、IDaおよびIDbが同じユーザ32に属することを示すために、使用されてもよい。例えば、これは、上述のΔ.LinkProveルーチンを実行することによって、ユーザ32によって実施可能である。その一方で、サービスプロバイダSPaおよびSPbは、上述のΔ.LinkVerifyルーチンを実行してもよい。このルーチンが成功した場合、SPaおよびSPbは、資産移転を合法であると考えてもよく、リクエストを承諾してもよく、すなわち、ステップS360に示されたように、資産移転が実行される。
【0065】
実施形態によれば、本発明は、ブロックチェーン技術を使用して1つのサービスプロバイダSPaからもう1つのサービスプロバイダSPbにユーザ32の資産を移転するための方法を提供し、ユーザ32およびサービスプロバイダ33は、リング署名またはグループ署名スキームのメンバである。ユーザ32は、それぞれの登録トランザクションによって、ユーザ32がサービスプロバイダ33に対して使用するユーザ32のアイデンティティをブロックチェーン31に登録する。各登録トランザクションは、ユーザ固有の秘密を含み、ユーザ32によって署名される。署名された登録トランザクション(ならびに、それぞれの公開鍵、署名自体、および署名のために使用されるリング)は、ブロックチェーン31上で公開される。
【0066】
第1のサービスプロバイダSPaから第2のサービスプロバイダSPbへの資産移転を開始するために、ユーザ32は、第1および第2のサービスプロバイダSPa、SPbに対して使用されるユーザ32のアイデンティティに関する署名付き登録トランザクションが、同じユーザ固有の秘密を埋め込んでいるという証拠を生み出す。ユーザ32は、ブロックチェーン31上でこの証拠を匿名で公開してもよく、またはユーザ32は、検証のために第1および第2のサービスプロバイダSPa、SPbのうちの少なくとも1つに、証拠を直接的または間接的に匿名で伝送してもよい。証拠の検証が成功した場合、サービスプロバイダSPa、SPbは、登録されたアイデンティティが同じユーザ32に属することを確信でき、資産移転は、(合法であると考えられるので)実行可能である。その一方で、証拠の検証が失敗した場合、サービスプロバイダSPa、SPbは、登録されたアイデンティティが同じユーザ32に属さないことを認識し、したがってリクエストを拒否することが可能である。
【0067】
本発明の別の実施形態によれば、ユーザ制御のリンク可能性メカニズムが、スマートシティすなわちIoT応用のコンテキストで実装されてもよい。この点に関して、
図4は、スマートシティ応用シナリオ40における可能なユースケースを示しており、ここでは、(ユーザ42が制御しているか、ユーザ42に属する)複数のデバイス44が、仲介者41を介して異なるセンサからの測定値(例えば、湿度、温度、電気消費量、等)を提供し、その結果、複数のサービスプロバイダ43および他のステークホルダーが、レポートされたデータに関する統計を計算することが可能である。仲介者41は、対応するサービスプロバイダ43への測定レポートの配布を担当している。例えば、ステップS420に示されたように、仲介者41は、入ってくる温度測定値をサービスプロバイダ1に、入ってくる電気消費量測定値をサービスプロバイダ2になど、転送するように構成されてもよい。
【0068】
仲介者41に伝送される匿名レポートは、ステップS410に示されたように、それぞれのデバイス44の匿名性を維持しつつ、レポートが正式なものであることを保証するために、グループまたはリング署名スキームで署名されてもよい。レポートの信憑性は、不正な測定値をレポートすることが、有効な署名鍵を要求するので、レポートの質についてのより大きな保証をサービスプロバイダ43に提供する。レポートの匿名性は、レポートが匿名でない場合、自分のデータを共有することに同意しなくてもよいユーザによるレポートを奨励してもよい。さらに、サービスプロバイダ43は、ターゲット提案を参加するユーザに提供してもよい。
【0069】
後のステージで、ユーザ42は、例えば固有のサービスプロバイダ43による電力計画についての、例えば、ターゲット提案を取得するために、ユーザ42のセンサ/デバイス44の測定値のうちのいくつかをリンクすることが望むことがある。そうするために、ユーザ42は、本発明の実施形態による匿名署名のリンク可能性を達成するためのユーザ制御のメカニズムを実行してもよい。具体的には、このようなメカニズムは、ステップS430に示されたように、ユーザ42の異なる測定レポートをリンクするため、すなわち、(S410に示されたような)異なるレポートが同じユーザ42に属することを示すために、使用されてもよい。例えば、これは、上述のΔ.LinkProveルーチンを実行することによって、ユーザ42によって実施可能である。その一方で、サービスプロバイダ43のうちのそれぞれ1つは、上述のΔ.LinkVerifyルーチンを実行してもよい。このルーチンが成功した場合、サービスプロバイダ43は、ユーザ42を合法であると考えてもよく、ステップS440に示されたように、ターゲット提案をユーザ42に提供してもよい。
【0070】
本発明の実施形態によるユーザ制御のリンク可能性メカニズムを伴う匿名署名スキームを使用することによって、レポートをまたがるリンケージの証拠がアイデンティティを何も明らかにしないことを達成でき、すなわちユーザ42は、自分の匿名性を依然として維持できる。ユーザ42がサービスプロバイダ43の提案を受け入れることを望む場合のみ、ユーザ42は、例えば、それぞれの契約に署名するために、ユーザ42のアイデンティティを明らかにしてもよい。
【0071】
実施形態によれば、本発明は、ユーザ42が制御しているセンサ/デバイス44の測定レポートを匿名でリンクするための方法を提供し、測定レポートは、複数のサービスプロバイダ43にさらに配布するために仲介者41に伝送される。ユーザ42およびサービスプロバイダ43は、リング署名またはグループ署名スキームのメンバであることが想定される。
【0072】
ユーザ42は、S410に示されたように、それぞれの匿名レポートによって、ユーザ42のデバイス44の測定値を仲介者41に伝送する。各レポートは、測定値に加えて、ユーザ固有の秘密を含む。ユーザ固有の秘密と一緒に、各レポート、すなわち測定値(および場合によっては、固有の実装形態に応じたさらなる情報)が、ユーザ42によって署名される。それぞれの公開鍵、署名、署名のために使用されるリング、および署名付きレポートは、ユーザ42およびサービスプロバイダ43が互いに通信する通信ネットワーク内で、公的に利用可能になる。
【0073】
例えば、固有のサービスプロバイダ43からのターゲット提案を取得するために、ユーザ42のセンサ/デバイス44の測定値のうちのいくつかをリンクすることをユーザ42が望むとき、ユーザ42は、それぞれの測定値に関する署名付きレポートが、同じユーザ固有の秘密を埋め込んでいるという証拠を生み出してもよい。ユーザ42は、基礎をなす通信ネットワークを介してこの証拠を匿名で公開してもよく、またはユーザ42は、検証のためにサービスプロバイダ43のうちのそれぞれ1つに、証拠を直接的または間接的に匿名で伝送してもよい。証拠の検証が成功した場合、サービスプロバイダ43は、それぞれの測定レポートが同じユーザ42に由来していることを確信でき、ユーザ42は、S440に示されたように、ターゲット提案へのアクセスを承諾されることが可能である。その一方で、検証の失敗は、それぞれの測定レポートが同じユーザ42によって伝送されたものではないことを示し、したがってサービスプロバイダ43は、ターゲット提案を拒否することが可能である。
【0074】
さらなる応用シナリオに関しては、信頼できる実行環境(TEE)がリモート証明プロトコルにおけるグループ署名を使用して、証明されるTEEのアイデンティティを保護することが指摘される。TEEを使用するDRM(デジタル著作権管理)応用では、DRM保護された内容の固有セットをクライアントが利用したことを証明するためのタスクを、クライアントが課されてもよい。そうするために、クライアントは、本発明の実施形態による匿名署名のリンク可能性を達成するためのユーザ制御のメカニズムを実行してもよい。具体的な実装形態は、ブロックチェーンおよびスマートシティ応用シナリオと共に、上述の原理を(それぞれ適合させて)使用してもよい。
【0075】
本明細書で説明された本発明の多くの変更形態および他の実施形態が、前述の説明および関連付けられた図面に提示された教示の利益を有する本発明に関係がある当業者には、思い浮かぶであろう。したがって、本発明は、開示された固有の実施形態に限定されるべきではなく、変更形態および他の実施形態が添付の特許請求の範囲の範囲内に含まれることが意図されることを理解されたい。固有の用語が本明細書で採用されるが、これらは、一般的および説明的な意味でしか使用されず、限定のためには使用されない。
【符号の説明】
【0076】
10 リング署名スキーム
11 署名者/証明者
12 検証者
13 匿名通信ネットワーク、通信ネットワーク
20 グループ署名スキーム
21 署名者/証明者
22 検証者
23 匿名通信ネットワーク、通信ネットワーク
30 ブロックチェーン応用シナリオ
31 ブロックチェーン
32 ユーザ
33 サービスプロバイダ
40 スマートシティ応用シナリオ
41 仲介者
42 ユーザ
43 サービスプロバイダ
44 デバイス、センサ/デバイス
【国際調査報告】