IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ エヌチェーン ホールディングス リミテッドの特許一覧

<>
  • 特表-秘密のシェアの生成 図1
  • 特表-秘密のシェアの生成 図2
  • 特表-秘密のシェアの生成 図3
  • 特表-秘密のシェアの生成 図4
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-07-13
(54)【発明の名称】秘密のシェアの生成
(51)【国際特許分類】
   H04L 9/08 20060101AFI20230706BHJP
   G06F 21/64 20130101ALI20230706BHJP
【FI】
H04L9/08 A
H04L9/08 E
G06F21/64
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022577363
(86)(22)【出願日】2021-05-17
(85)【翻訳文提出日】2023-02-14
(86)【国際出願番号】 EP2021062941
(87)【国際公開番号】W WO2021254702
(87)【国際公開日】2021-12-23
(31)【優先権主張番号】2009062.7
(32)【優先日】2020-06-15
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】ミカエラ・ペティット
(57)【要約】
共有秘密のシェアを生成するコンピュータ実装方法であって、参加者のグループの各々が共有秘密のそれぞれの第1の秘密シェアを有し、グループの第1の参加者によって実行され、共有ブラインド秘密のそれぞれのブラインドシェアを生成するステップと、参加者の第1のグループの各々からそれぞれの中間シェアの少なくともしきい値数を取得するステップであって、それぞれの中間シェアが、それぞれのブラインドシェアおよびそれぞれの第1の秘密シェアに基づいて生成される、ステップと、取得された中間シェアの各々に基づいて中間価値を生成するステップと、共有秘密のそれぞれの第2の秘密シェアを生成するステップであって、それぞれの第2の共有される秘密が、中間値およびそれぞれのブラインドシェアに基づいて生成される、ステップとを備える、方法。
【特許請求の範囲】
【請求項1】
共有秘密のシェアを生成するコンピュータ実装方法であって、参加者のグループの各々が前記共有秘密のそれぞれの第1の秘密シェアを有し、前記グループの第1の参加者によって実行され、
共有ブラインド秘密のそれぞれのブラインドシェアを生成するステップと、
参加者の前記第1のグループの各々からそれぞれの中間シェアの少なくともしきい値数を取得するステップであって、それぞれの中間シェアが、それぞれのブラインドシェアおよびそれぞれの第1の秘密シェアに基づいて生成される、ステップと、
前記取得された中間シェアの各々に基づいて中間価値を生成するステップと、
前記共有秘密のそれぞれの第2の秘密シェアを生成するステップであって、前記それぞれの第2の秘密シェアが、前記中間値および前記それぞれのブラインドシェアに基づいて生成される、ステップと
を備える、方法。
【請求項2】
前記それぞれの中間シェアのうちの第1のものが、前記第1の参加者によって生成される、請求項1に記載の方法。
【請求項3】
前記共有秘密のしきい値が、前記共有ブラインド秘密の前記しきい値に等しい、請求項1または2のいずれか一項に記載の方法。
【請求項4】
前記共有秘密のしきい値が、前記共有ブラインド秘密の前記しきい値と比較して異なる、請求項1または2のいずれか一項に記載の方法。
【請求項5】
前記共有秘密の前記しきい値が、前記共有ブラインド秘密の前記しきい値よりも大きい、請求項4に記載の方法。
【請求項6】
前記共有秘密の前記しきい値が、前記共有ブラインド秘密の前記しきい値未満である、請求項4に記載の方法。
【請求項7】
前記共有ブラインド秘密の前記それぞれのブラインドシェアが、共同の検証可能な秘密共有スキームを使用して生成される、請求項1から6のいずれか一項に記載の方法。
【請求項8】
前記共同秘密共有スキームを使用して前記それぞれのブラインドシェアを生成するステップが、
第1のデータ項目を生成するステップであって、前記第1のデータ項目が第1の多項式である、ステップと、
少なくとも前記しきい値数の参加者からそれぞれのデータ項目を取得するステップであって、それぞれのデータ項目が、それぞれの参加者によって生成されたそれぞれの多項式である、ステップと、
前記第1のデータ項目および前記それぞれのデータ項目の各々に基づいて、前記それぞれのブラインドシェアを生成するステップと
を備える、請求項7に記載の方法。
【請求項9】
前記それぞれのデータ項目を取得するステップが、前記第1の参加者と前記しきい値数の参加者の各々との間のそれぞれの通信チャネルを介して前記それぞれのデータ項目を取得するステップを備える、請求項7または8に記載の方法。
【請求項10】
前記第1の多項式のそれぞれのインスタンスを前記しきい値数の参加者の少なくとも各々に送信するステップを備え、前記第1の多項式の前記それぞれのインスタンスがそれぞれの参加者に基づく、請求項7から9のいずれか一項に記載の方法。
【請求項11】
前記共有ブラインド秘密の前記それぞれのブラインドシェアが、シャミールの秘密共有スキームを使用して生成される、請求項1から7のいずれか一項に記載の方法。
【請求項12】
前記共有秘密の前記それぞれの第1の秘密シェアが、共同の検証可能な秘密共有スキームを使用して生成される、請求項1から11のいずれか一項に記載の方法。
【請求項13】
前記共有秘密の前記それぞれの第1の秘密シェアが、シャミールの秘密共有スキームを使用して生成される、請求項1から11のいずれか一項に記載の方法。
【請求項14】
前記共有秘密が秘密鍵であり、前記それぞれの第2の秘密シェアが前記秘密鍵のそれぞれの秘密鍵シェアである、請求項1から13のいずれか一項に記載の方法。
【請求項15】
前記共有ブラインド秘密がブラインド秘密鍵であり、前記中間値が中間秘密鍵であり、
前記秘密鍵に対応する第1の公開鍵を生成するステップと、
前記ブラインド秘密鍵に対応する第2の公開鍵を生成するステップと、
前記中間秘密鍵に対応する第3の公開鍵を生成するステップと、
前記第1および第2の公開鍵に基づいて第1の値を生成するステップと、
前記第1の値が前記第3の公開鍵と一致するかどうかに基づいて、前記共有秘密の前記第2の秘密シェアが正しく生成されたことを検証するステップと
を備える、請求項14に記載の方法。
【請求項16】
前記第2の秘密シェアが正しく生成されなかったという決定に応答して、他のそれぞれの参加者のうちの1人、一部、または全員に対して、
その参加者の前記それぞれの第1の秘密シェアに対応するそれぞれの第1の公開鍵を取得するステップと、
その参加者の前記それぞれのブラインドシェアに対応するそれぞれの第2の公開鍵を取得するステップと、
その参加者の前記それぞれの中間シェアに対応するそれぞれの第3の公開鍵を取得するステップと、
その参加者の前記それぞれの第1および第2の公開鍵に基づいてそれぞれの第1の値を生成するステップと、
前記それぞれの第1の値が前記それぞれの第3の公開鍵と一致するかどうかに基づいて、前記共有秘密の前記それぞれの第2の秘密シェアがその参加者によって正しく生成されたことを検証するステップと
を実行するステップを備える、請求項15に記載の方法。
【請求項17】
メッセージを取得するステップと、
前記メッセージと、前記秘密鍵の前記それぞれのシェアとに基づいて、デジタル署名シェアを生成するステップと
を備える、請求項14から16のいずれかに記載の方法。
【請求項18】
メッセージを取得するステップと、
第1のメッセージ非依存コンポーネントおよび第1のメッセージ依存コンポーネントを生成するステップであって、前記メッセージ非依存コンポーネントが前記それぞれの秘密鍵シェアに基づいて生成され、前記メッセージ依存コンポーネントが前記メッセージに基づいて生成される、ステップと、
前記第1のメッセージ非依存コンポーネントをコーディネータにとって利用可能にするステップと、
少なくとも前記しきい値数の署名シェアに基づいて署名を生成するために、第1の署名シェアを前記コーディネータにとって利用可能にするステップであって、前記第1の署名シェアが、少なくとも前記メッセージ依存コンポーネントを備える、ステップと
を備える、請求項14から16のいずれか一項に記載の方法。
【請求項19】
1つまたは複数のメモリユニットを備えるメモリと、
1つまたは複数の処理ユニットを備える処理装置であって、前記メモリが、前記処理装置上で実行するように構成されたコードを記憶し、前記コードが、前記処理装置上にあるときに、請求項1から18のいずれかに記載の方法を実行するように構成される、処理装置と
を備える、コンピュータ機器。
【請求項20】
コンピュータ可読ストレージに具現化され、コンピュータ機器上で実行されると、請求項1から18のいずれかに記載の方法を実行するように構成された、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、共有秘密のシェアを生成する方法に関する。たとえば、本方法は、共有秘密鍵の新しいシェアを生成するために使用され得る。
【背景技術】
【0002】
一般に、共有秘密は、参加者のグループ間で分散されるデータ項目を共有するために使用され得る。各参加者は、秘密の異なるシェアを有している。通常、秘密は、特定の数(「しきい値(threshold)」と呼ばれる)の参加者が、たとえば、秘密を計算するために組み合わせるために、それぞれのシェアを利用可能にした場合にのみ再構築することができる。
【0003】
公開鍵暗号方式は、秘密鍵の所有者のみに知られている秘密鍵と、対応する秘密鍵に基づいて生成され、秘密鍵のセキュリティを損なうことなく配布され得る公開鍵との鍵のペアを使用する暗号化システムの一種である。
【0004】
公開鍵暗号化により、送信者は受信者の公開鍵(すなわち、受信者だけに知られている秘密鍵に対応する公開鍵)を使用してメッセージを暗号化することができる。暗号化されたメッセージは、受信者の秘密鍵を使用してのみ復号化することができる。
【0005】
同様に、送信者は、メッセージに署名するために、たとえば、メッセージが送信者によって送信されていることを証明するため、および/または送信者がメッセージに同意することを示すために、独自の秘密鍵を使用することができる。署名者(すなわち、署名を生成する当事者)は、メッセージに基づいてデジタル署名を作成するために、彼らの秘密鍵を使用する。メッセージに基づいてデジタル署名を作成するということは、メッセージと秘密鍵の両方に基づいて署名を生成する関数にメッセージと秘密鍵を提供することを意味する。署名は、メッセージに追加される(たとえば、タグ付けされる)か、メッセージに関連付けられる。署名者の対応する公開鍵を持っている人は誰でも、署名が有効に作成されたかどうか、すなわち、署名が実際に署名者の秘密鍵を使用して作成されたかどうかを確認するために、同じメッセージと、メッセージのデジタル署名とを使用することができる。デジタル署名は、メッセージの信頼性を保証するだけでなく、メッセージの完全性と否認防止も保証する。すなわち、メッセージが署名されてから変更されていないこと、および署名の作成者が署名を作成したことを将来否定できないことを証明するために、デジタル署名を使用することができる。
【0006】
デジタル署名スキームは通常、3つの手順、すなわちアルゴリズムを含む。ランダムな秘密鍵と対応する公開鍵を生成するために、鍵生成アルゴリズムが使用される。メッセージと秘密鍵に基づいて署名を生成するために、署名アルゴリズムが使用される。公開鍵とメッセージが与えられた場合、署名が対応する秘密鍵を使用して、および署名アルゴリズムに従って生成されたかどうかを検証するために、検証アルゴリズムが使用される。
【0007】
共有秘密の一般的な用途は、秘密鍵と公開鍵のペアの共有秘密鍵である。すなわち、秘密鍵は、単一の参加者が秘密鍵にアクセスできないように、参加者のグループ間で分散され得る。したがって、単一の参加者がメッセージの有効な署名を生成することはできない。代わりに、署名を生成するために、一部またはすべての参加者が一緒に秘密鍵を生成する必要がある。
【0008】
参加者は、署名を生成するために秘密鍵シェアを共有する代わりに、しきい値署名スキームを使用し得る。しきい値署名スキームは、グループ内のしきい値数の参加者が、どの参加者も秘密鍵を使用できるようにすることなく、シェア秘密鍵の個々のシェアを使用してメッセージに基づいてデジタル署名を作成することを可能にする。ここで、デジタル署名とは、署名対象のメッセージに基づいて生成される署名である。そのようなスキームにおいては、しきい値の数の参加者がメッセージに署名を生成することに同意した場合にのみ、署名を作成することができる。少数の参加者を使用して署名を生成しようとしても、有効な署名は生成されない。したがって、グループによる有効な署名(すなわち、メッセージと共有秘密鍵を使用して生成された署名)は、署名の生成に同意するしきい値の数の人々がいたことを証明している。これは、敵対者がその秘密鍵で署名を偽造するために、しきい値数の秘密鍵のシェアを取得する必要があることも意味する。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】WO2017145010A1
【発明の概要】
【課題を解決するための手段】
【0010】
共有秘密自体を変更せずに、共有秘密の新しいシェアを生成できることが望ましいシナリオがある。たとえば、共有秘密のそれぞれのシェアを有している1人または複数の参加者は、参加者のグループを離れて、たとえば、しきい値署名スキームの署名シェアを生成するために、それぞれのシェアが共有秘密を再構築するために利用できなくなったり、それらのシェアを使用して計算を実行したりすることができなくなったりする。または、別の例として、参加者がグループを離れた結果としてではなく、失われたり侵害されたりした結果として、秘密の一部のシェアが利用できなくなる場合がある。それらの共有を置き換える必要がある場合がある。別の例として、1人または複数の追加の参加者を含めるために参加者のグループを拡張し得、したがってそれらの参加者は、彼ら自身の共有秘密のシェアを必要とする。
【0011】
同様に、共有秘密のしきい値を変更することが望ましいシナリオがある。すなわち、共有秘密を再構築するために必要な秘密シェアの数を変更することである。たとえば、共有秘密のしきい値を増やすと、共有秘密のセキュリティが向上する可能性があり、これは、悪意のある当事者が共有秘密を再構築するために、より多くのシェアにアクセスする必要があるためである。これは、共有秘密が、データの暗号化またはリソースへのアクセスの制御に使用される秘密鍵である場合に特に重要である。
【0012】
本明細書に開示される一態様によれば、共有秘密のシェアを生成するコンピュータ実装方法であって、参加者のグループの各々が共有秘密のそれぞれの第1の秘密シェアを有し、グループの第1の参加者によって実行され、共有ブラインド秘密のそれぞれのブラインドシェアを生成するステップと、参加者の第1のグループの各々からそれぞれの中間シェアの少なくともしきい値数を取得するステップであって、それぞれの中間シェアが、それぞれのブラインドシェアおよびそれぞれの第1の秘密シェアに基づいて生成される、ステップと、取得された中間シェアの各々に基づいて中間価値を生成するステップと、共有秘密のそれぞれの第2の秘密シェアを生成するステップであって、それぞれの第2の共有される秘密が、中間値およびそれぞれのブラインドシェアに基づいて生成される、ステップとを備える、方法が提供される。
【0013】
本スキームは、共有秘密の有効なシェアを有する参加者の数を増減するために、共有秘密の新しいシェアを生成するために使用され得る。ここで、有効なシェアは、それが第2の秘密シェアのうちの1つであるという意味で有効とみなされる場合があり、参加者のグループ全体による第2の秘密シェアの使用のみが有効な計算になる。
【0014】
本スキームは、共有秘密のしきい値を変更するために、共有秘密の新たなシェアを生成するためにも使用され、共有秘密の第2のシェアは、共有秘密の第1のシェアと比較して異なるしきい値を有する。
【0015】
失われたり侵害されたりしたシェアは、現在のスキームに置き換えられる場合がある。「古い(old)」シェアが侵害された場合、スキームにおける他の参加者は新しいシェアのみを使用するため、本発明はそのシェアを役に立たなくする。したがって、攻撃者は、別のシェアを侵害しようとするという意味で「やり直す(begin again)」必要がある。
【0016】
上述のように、共有秘密は秘密鍵の文脈において使用されることがよくあり、すなわち、秘密鍵は共有秘密である場合がある。より一般的には、共有秘密は、それを明らかにするか、それを用いてより多くの計算を行うために、しきい値の数の人々を必要とする任意のデータである可能性がある。
【0017】
たとえば、データは、医療データまたは他のそのような個人データである可能性があり、実際のデータ(たとえば、個人に関連付けられるバイオメトリックまたは遺伝子データ)を共有しないことが好ましい。共有秘密の形式で医療データを共有すると、機密データを明らかにすることなく、データを用いて計算(たとえば、統計分析)を行うことが可能になる。スキームの参加者のうちの1人または複数がデータの所有者である場合、その所有者は結果の計算に参加する必要があるため、所有者はデータへのアクセスを承認または拒否することができる。シェアを有する他の参加者は、個々の秘密を知ることなく、データを用いて計算を実行し、結果を取得することができる。本発明は、データの所有者が他の参加者をスキームから「取り除く(remove)」ためにシェアを更新することを可能にする。
【0018】
共有秘密を更新するもう1つの使用例は、参加者のグループが同じ共有秘密を用いて複数の「スキーム(scheme)」を作成することであり、これにより、共有秘密のセキュリティが向上する。参加者は、共有秘密を作成し、次いで、共有の再発行を複数回繰り返すか、ラウンドを実行することができる。その結果、参加者全員が同じ共有秘密の複数のシェアを有し、秘密を見つけるために、同じ「スキーム」または「ラウンド(round)」に対応する他の参加者のシェアと組み合わせることができる。これらのシェアがすべて一緒に記憶されている場合、攻撃者は複数の場所(すなわち、参加者)を攻撃する必要があるだけでなく、シェアの正しい組合せを考え出す必要もある。
【0019】
本開示の実施形態の理解を助け、そのような実施形態がどのように実施され得るかを示すために、例としてのみ、添付の図面を参照する。
【図面の簡単な説明】
【0020】
図1】本発明の実施形態による、共有秘密のシェアを更新するための例示的なシステムを概略的に示す図である。
図2】本発明の実施形態による、共有秘密のシェアを更新するための例示的な方法を概略的に示す図である。
図3】本発明のいくつかの実施形態による、メッセージの署名を生成するための例示的なシステムを概略的に示す図である。
図4】本発明の実施形態による、メッセージの署名シェアを生成するための例示的な方法を概略的に示す図である。
【発明を実施するための形態】
【0021】
序文
以下の例は楕円曲線暗号に関して説明されているが、本発明は特定の暗号スキームに限定されるものではなく、一般に任意の暗号スキーム、たとえば、RSAまたは他の公開鍵暗号スキームに適用され得る。
【0022】
楕円曲線グループ
楕円曲線Eは次の式を満たす。
y2=x3+αx+b mod ρ
上式で、
【0023】
【数1】
【0024】
およびα、bは、4α3+27b2≠0を満たす定数である。この楕円曲線上のグループは、単位元である無限遠点
【0025】
【数2】
【0026】
とともにこの式を満たす要素(x、y)の集合として定義される。このグループ内の要素に対するグループ動作は、楕円曲線の点の追加と呼ばれ、+によって示される。このグループは
【0027】
【数3】
【0028】
によって示され、その次数はnによって示される。
【0029】
・によって示される点乗算と呼ばれる要素に対する別の演算を定義するために、このグループ演算を使用することができる。点
【0030】
【数4】
【0031】
とスカラ
【0032】
【数5】
【0033】
の場合、点k・Gは、それ自体にk回追加された点Gとして定義される。
【0034】
楕円曲線暗号において、秘密鍵はスカラ
【0035】
【数6】
【0036】
であると定義され、上式で、
【0037】
【数7】
【0038】
はセット{1、…、n-1}の表記であり、対応する公開鍵は楕円曲線上の点k・Gである。たとえば、一部のブロックチェーンプロトコルにおいて、楕円曲線はsecp256k1楕円曲線として選択され、値α、b、およびρはこの曲線によって完全に指定される。このグループの次数nはこれらの値を考慮して計算されており、この曲線の場合は素数であり、secp256k1規格は、このグループのジェネレータとして使用される点Gも指定する。
【0039】
楕円曲線デジタル署名アルゴリズム
秘密鍵αを用いてメッセージmsgに署名を作成するために、次のステップが実行される。
1.メッセージダイジェストe=hash(msg)を計算し、これは、任意のハッシュ関数であり得る。たとえば、いくつかの例では、hash(msg)=SHA256(SHA256(msg))であり、SHA256(■)はSHA-256ハッシュ関数である。代わりに、同じまたは異なるハッシュ関数を使用して、メッセージが1回だけ、または2回以上ハッシュされる場合があることに留意されたい。
2.ランダムな整数k∈{1,…,n-1}を選択し、nは楕円曲線、たとえばsecp256k1曲線の次数である。以下では、kは一時的な秘密鍵と呼ばれる。
3.この一時的な秘密鍵k・G=(Rx、Ry)に対応する一時的な公開鍵を計算する。
4.γ=Rx mod nを計算する。γ=0の場合、ステップ2に戻る。
5.一時的な鍵k-1 mod nの乗法逆数を計算する。
6.s=k-1(e+αγ)mod nを計算する。s=0の場合、ステップ2に戻る。
7.メッセージmsgの署名は(γ、s)である。
【0040】
一時的な鍵は秘密にしておく必要があり、そうしないと、メッセージと署名があれば秘密鍵を計算できてしまう。さらに、署名が生成されるたびに、異なる一時的な鍵を使用する必要がある。そうではない場合、与えられた2つの異なる署名とそれらに対応するメッセージから秘密鍵αを導き出すことが可能である。
【0041】
メッセージmsg、公開鍵P=α・G、および対応する署名(γ、s)が与えられると、次のステップを完了することによって署名を検証することができる。
1.メッセージダイジェストe=hash(msg)、たとえば、e=SHA256(SHA256(meg))を計算する。
2.nを法とするsの乗法逆数s-1を計算する。
3.j1=es-1 mod nおよびj2=γs-1 mod nを計算する。
4.点Q=j1・G+j2・Pを計算する。
5.
【0042】
【数8】
【0043】
無限遠点である場合、署名は無効である。
6.
【0044】
【数9】
【0045】
である場合、次いで、Q=(Qx、Qy)とし、u=QX mod nを計算する。u=γの場合、署名は有効である。
【0046】
しきい値署名スキームでは、この秘密鍵αは、しきい値スキームグループ内の参加者間で分散される鍵シェアに分割される。
【0047】
共同検証可能ランダム秘密シェア
N人の参加者が、スキームにおいて少なくとも(t+1)人の参加者によってのみ再生成できる共同秘密を作成したいと仮定する。共有秘密を作成するために、次のステップが実行される。
1.参加者は、各参加者の一意のラベルiに同意する。各参加者iは(t+1)個の乱数
【0048】
【数10】
【0049】
を生成し、上式で、∈Rは、セット
【0050】
【数11】
【0051】
のランダムに生成された要素を意味し、上式で、
【0052】
【数12】
【0053】
はセット{1、…、n-1}の表記である。次いで、各参加者は、i=1、…、Nの場合、次数tの秘密多項式
fi(x)=αi0i1x+…+αitxt mod n
を有する。これ以降、mod n表記を省略することに留意されたい。また、整数に対するすべての算術演算は、モジュロnで行われると仮定されている。
2.各参加者iは、たとえば、参加者jのみと安全な通信チャネルを使用して、値fi(j)を参加者jに送信する。
3.各参加者iは、次のように、共有秘密多項式の独自の秘密シェアを計算する。
【0054】
【数13】
【0055】
共有秘密シェアは、(i、αi)という形式の点であり、ここで、iはスキームにおける参加者ラベルである。ステップ1~3において説明したように、αの秘密シェアを作成するためのこの方法は、本明細書では、参加者iの場合、αi=JVRSS(i)によって示される。「JVRSS」は通常、「共同検証ランダム秘密シェアリング(Joint verification random secret sharing)」の略であり、ステップ4と5も含む点に留意されたい。しかしながら、本明細書を通じて、JVRSSは少なくともステップ1から3を実行することを意味すると解釈され、ステップ4と5はオプションのステップである。
【0056】
参加者が共有多項式を生成したので、他の参加者がすべての参加者に正しい情報を共有したこと、およびすべての参加者が同じ共有多項式を有していることをそれぞれ確認することができる。これは次の方法で行わる。
4.各参加者iは、k=0、…、tの難読化された係数αik・Gをすべての参加者にブロードキャストする。
5.各参加者iは、各参加者jがfj(i)・Gを計算し、それを検証することによって、多項式点fj(i)を正しく計算したことをチェックする。
【0057】
【数14】
【0058】
すべての参加者がこの式が各多項式に当てはまることを発見した場合、グループは集合的に、全員が同じ共有多項式を作成したことを確認することができる。
【0059】
共有秘密の再構築
参加者が、共有多項式の0次である共有秘密αを再構築したいと仮定する。この多項式(1、α1),…,((t+1)、αt+1)の形式の(t+1)点が与えられた場合、共有秘密αを見つけるために、次のように計算し、
【0060】
【数15】
【0061】
これは、「ラグランジュ補間(Lagrange Interpolation)」として知られる一般式から導き出される。
【0062】
公開鍵計算
JVRSSのステップ4において共有される、i=1、…、NのN個のゼロ次プライベート多項式係数公開鍵αi0・Gが与えられると、各参加者は共有秘密αに対応する
【0063】
【数16】
【0064】
を使用して共有公開鍵Pを計算する。
【0065】
共有秘密の追加
N人の参加者のグループ間で共有される2つの共有秘密の加算を計算するために、各秘密多項式の次数がtである場合、エンティティが個々の秘密を知ることなく、次のステップが実行される。
1.第1の共有秘密αを生成し、ここで、参加者iのシェアはi=1、…、Nの場合、αi=JVRSS(i)によって与えられ、しきい値は(t+1)である。
2.第2の共有秘密bを生成し、ここで、参加者iのシェアはbi=JVRSS(i)によって与えられ、しきい値は(t+1)である。
3.各参加者iは、独自の加算シェアを計算する
νii+bi mod n.
4.すべての参加者は、加算シェアνiを他のすべての参加者にブロードキャストする。
5.各参加者は、シェアνiの少なくとも(t+1)を補間して、以下を計算する。
ν=interpolate(νi、…、νt+i)=α+b
【0066】
共有秘密を追加するこの方法は、参加者iのADDSS(i)によって示され、各参加者iはν=(α+b)を知ることになる。
【0067】
共有秘密の積
各秘密多項式の次数がtであるN人の参加者のグループ間で共有される2つの共有秘密の積を計算するために、グループは次のステップを実行する。
1.第1の共有秘密αを生成し、参加者iのシェアは、i=1、…、Nの場合、αi=JVRSS(i)によって与えられる。共有秘密多項式の次数はtであり、(t+1)人の参加者がそれを再作成する必要があることを意味する。
2.第2の共有秘密bを生成し、ここで、参加者iのシェアはbi=JVRSS(i)によって与えられ、共有秘密多項式の次数は、やはりtである。
3.各参加者は、以下を使用して独自の乗法シェアμiを計算する。
μiibi
4.すべての参加者は、乗法シェアμiを他のすべての参加者にブロードキャストする。
5.各参加者は、0においてシェアμiの少なくとも(2t+1)を補間して、以下を計算する。
μ=interpolate(μi,…,μ2t+1)=αb.
【0068】
2つの共有秘密の積を計算するためのこの方法は、本明細書では、参加者iについてμ=αb=PROSS(i)によって示される。
【0069】
共有秘密の逆数
共有秘密αの逆数を計算するために、次のステップが実行される。
1.すべての参加者は共有秘密の積PROSS(i)を計算し、その結果はμ=αb mod nである。
2.各参加者は、μの剰余逆数を計算し、その結果は以下のとおりである。
μ-1=(αb)-1 mod n
3.各参加者iは、以下を計算することによって、自身の逆秘密シェアを計算する。
【0070】
【数17】
【0071】
共有秘密の逆数を計算するこの方法は、参加者iの
【0072】
【数18】
【0073】
によって示される。
【0074】
共有秘密鍵の生成および検証
N≧2t+1の参加者間で共有秘密鍵αを計算するために、そのうちのt+1人が署名を作成する必要があり、参加者は、前述のようにt+1のしきい値と公開鍵計算を用いてJVRSSを実行する。その結果、すべての参加者i=1、…、Nは秘密鍵シェアαiと、対応する共有公開鍵P=(α・G)を有することになる。
【0075】
一時的な鍵シェアの生成
一時的な鍵シェアと対応するγを生成するために、署名において必要とされるように、サイズNのグループとしきい値(t+1)の共有秘密鍵αを使用して、次のステップを実行する。
1.共有秘密
【0076】
【数19】
【0077】
の逆シェアを生成し、上式で、再作成するために(t+1)シェアが必要である。
2.各参加者は、kiの検証において共有される難読化された係数を使用して
【0078】
【数20】
【0079】
を計算し、次いで
γ=x mod nを計算する。
3.各参加者iは
【0080】
【数21】
【0081】
を記憶する。
【0082】
異なるしきい値を有する秘密の追加
次数tとt'の秘密の加算の場合、2つの秘密の加算は、それを計算するためにmax(t、t')+1の共有数を必要とする。この背後にある理由は、共有秘密のシェアの追加ステップが新しい多項式のシェアを作成するためである。この新しい加算多項式は、2つの共有秘密の個々の多項式を加算した結果と同等である。2つの多項式を加算すると、xの各次数において対応する係数が加算される。したがって、加法多項式の次数は、2つの多項式の最高次数と同じでなければならない。これは、3つ以上の多項式の加算に一般化することができ、この場合、結果として得られる多項式の次数は、最高次数の個々の多項式の次数と同じになる。
【0083】
しきい値が異なる2つの秘密の加算が計算されると、しきい値の高い秘密のセキュリティが低下する。これは、それぞれのしきい値t、t'で結果(α+b)がわかっている場合、t<t'と仮定すると、t個のシェアでαを計算し、次いで(α+b)-α=bを計算できるためであり、したがって、値bはt個のシェアだけで計算されている。この下限しきい値は、以下ではbの「関連しきい値(implicated threshold)」と呼ばれる。
【0084】
異なるしきい値を有する秘密の乗算
tとt'のしきい値を有する2つの秘密の乗算の場合、乗算の計算にはt+t'+1シェアが必要である。この場合、2つの多項式のシェアを乗算すると、新しい多項式のシェアが得られる。この新しい多項式は、2つの個々の多項式を乗算した結果であるため、結果の次数は2つの個々の多項式の次数の加算である。
【0085】
乗算は、任意の数の共有秘密に一般化することもでき、結果のしきい値は、個々のしきい値に1を加えた合計Σρtρ+1になり、ここで、ρは個々の共有秘密に適用される。
【0086】
加算と同様に、異なるしきい値を有する2つの秘密を乗算すると、より高いしきい値の秘密の関連しきい値が得られる。前述のように、αのしきい値がtでbのしきい値がt'であるαbがわかっており、t<t'である場合、αとbの両方をt個のシェアで計算することができる。第1に、(αb)α-1を使用してαを計算し、秘密のt個のシェアのみでbを見つけることができる。
【0087】
共有秘密の加算と乗算を1つのステップに組み合わせる
加算と乗算の任意の組合せを1つのステップにおいて計算するために、上記を一般化することができる。N人の参加者のグループが結果αb+cを計算したいと仮定し、ここで、α、b、cはそれぞれしきい値(tα+1)、(tb+1)、(tc+1)を有する共有秘密である。max(tα+tb、tc)<Nという条件があり、すなわち、スキームの参加者の数は、秘密cの次数と、秘密αとbの乗算結果の次数との間の最大値より大きくなければならない。
1.各参加者iは、秘密シェアαi=JVRSS(i)、bi=JVRSS(i)、ci=JVRSS(i)を、それぞれしきい値(tα+1)、(tb+1)、(tc+1)で計算する。
2.各参加者iは、シェアλiibi+ciを計算する。
3.各参加者iは、結果λiを他の参加者と共有する。
4.各参加者はmax(tα+tb、tc)+1シェアを補間して、結果λ=int(λ1,…,λi,…)=αb+cを見つる。
【0088】
これは、以下のいくつかの実施形態による共有署名の計算において行われる。すなわち、
【0089】
【数22】
【0090】
に対する補間がある。これは基本的に、上記の
【0091】
【数23】
【0092】
および
【0093】
【数24】
【0094】
の場合である。この場合、tα+tb=2tおよびtc=tであり、補間はmax(tα+tb、tc)+1=2t+1シェアに対するものである。
【0095】
秘密シェアの生成
図1は、本発明の実施形態を実施するための例示的なシステム100を示している。図示されるように、システム100は、複数の当事者(以下では「参加者(participants)」とも呼ばれる)102を備える。図1には3人の参加者102のみが示されているが、一般に、システムは任意の数の参加者を備え得ることを理解されたい。参加者102の各々は、それぞれのコンピューティング機器を動作する。
【0096】
それぞれの参加者102のそれぞれのコンピューティング機器の各々は、1つまたは複数のプロセッサを備える、それぞれの処理装置、たとえば、1つまたは複数の中央処理装置(CPU)、アクセラレータプロセッサ(GPU)、特定用途向けプロセッサ、および/またはフィールドプログラマブルゲートアレイ(FPGA)を備える。それぞれのコンピューティング機器はまた、メモリ、すなわち、非一時的なコンピュータ可読媒体の形態のコンピュータ可読ストレージを備え得る。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、またはEEPROMなどの電子媒体、および/あるいは光ディスクドライブなどの光学媒体を使用する1つまたは複数のメモリユニットを備え得る。それぞれのコンピューティング機器は、たとえば、デスクトップまたはラップトップコンピュータ、タブレット、スマートフォン、あるいはスマートウォッチなどのウェアラブルデバイスなどの少なくとも1つのユーザ端末を備え得る。代替的または追加的に、それぞれのコンピューティング機器は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの1つまたは複数の他のネットワーク化されたリソースを備え得る(クラウドコンピューティングリソースは、1つまたは複数のサイトにおいて実装される1つまたは複数の物理サーバデバイスのリソースを備える)。システム100の当事者によって実行されるものとして説明される任意の行為は、その当事者によって動作されるそれぞれのコンピューティング装置によって実行され得ることが理解されるであろう。
【0097】
参加者102の各々は、LANまたはWAN接続を使用して、または代替のワイヤードまたはワイヤレス通信手段を介して、インターネットを介して他の参加者102のうちの1人、一部、または全員にデータを送信するように構成される。文脈上別段の要求がない限り、データを送信する参加者102への言及は、他の参加者102に、たとえば、第1の参加者102aと第2の参加者102bとの間の安全な通信チャネルを介して個別にデータを送信すること、あるいは電子メールまたは他の手段を介してグループ全体にブロードキャストすることとして理解され得る。やはり文脈上別段の要求がない限り、各参加者102は、生の形式または暗号化された形式でデータを送信し得る。たとえば、データは、受信参加者に送信される前に、受信参加者の公開鍵を使用して暗号化され得る。
【0098】
参加者のうちの1人、一部、または全員が、共有秘密のそれぞれのシェアを有している(たとえば、メモリに記憶している)。共有秘密のシェアを有する参加者は、まとめて参加者の第1のグループと呼ばれる。いくつかの例では、参加者のうちの1人または一部は、共有秘密のそれぞれのシェアを有していない場合がある。たとえば、参加者のそれぞれのシェアが失われたか(たとえば、秘密シェアを記憶するメモリが破損した可能性がある)、盗まれた可能性がある。共有秘密のシェアを有していない参加者は、まとめて参加者の第2のグループと呼ばれる。
【0099】
共有秘密は実際にはデータ項目であり、データ項目がプライベートに保たれる、すなわち公にはアクセスできないことが望ましいという意味で、データ項目は「秘密(secret)」である。共有秘密は、たとえば公開鍵と秘密鍵のペアの共有秘密鍵である場合がある。以下の例では、共有秘密を共有秘密鍵と呼ぶ。これらの例では、共有秘密のシェアを秘密鍵シェアとも呼ぶ。しかしながら、これらは例示にすぎないことを理解されたい。
【0100】
秘密鍵のシェア(および一般的な共有秘密)を生成するための技法は、当業者にはよく知られている。
【0101】
好ましくは、第1の参加者102aは、共同秘密共有スキーム(JVRSS)を使用して、たとえば、上記のJVRSS技法を使用して、秘密鍵αの第1の秘密鍵シェアαiを生成するように構成される。たとえば、第1の参加者102aは、インデックス1を有し、参加者1に対してα1=JVRSS(1)を使用して第1の秘密鍵シェアを生成し得、秘密鍵はαによって示される。各参加者102は、それぞれの秘密鍵シェアαiを生成し得る。たとえば、第2の参加者102bは、参加者2に対してα2=JVRSS(2)を使用して第2の秘密鍵シェアを生成し得、以下同様である。
【0102】
共同秘密シェアスキームを使用して第1の秘密鍵シェアα1を生成することは、数値のセット
【0103】
【数25】
【0104】
を生成することと、次いで、第1の多項式f1(x)=α1011x+・・・+α1txt mod nを生成することとを備え得、ここで、数値のセットは多項式の係数である。他の参加者102の各々は、それぞれの数値のセットを使用してそれぞれの多項式を生成し得る。たとえば、第2の参加者102bは、第2の多項式f2(x)=α2021x+・・・+α2txt mod nを生成する。次いで、参加者102は、他の各参加者に、その他の参加者のインデックスにおいて評価されたそれぞれの関数の値を送信する。たとえば、第1の参加者102aは、第2の参加者102bについてf1(2)を評価し、次いで、その値を第2の参加者102bに送信し、第3の参加者102cについてf1(3)を評価し、次いで、その値を第3の参加者102cに送信し、以下同様である。第1の参加者102aは、第1の参加者のインデックスの関数として、他の参加者102によって生成されたそれぞれの値を取得する。値は、インターネットを介して、または他の手段を介して送信され得る。値は、参加者のそれぞれのペアの間でそれぞれの安全な通信チャネルを介して送信され得る。直接送信する代わりに、1人または複数の参加者102(たとえば、第1の参加者102a)は、それぞれの値をブロードキャストし得る。少なくともしきい値数の参加者から少なくともしきい値数の値を取得すると、第1の参加者102aは、第1の値および互いに取得したデータ値、たとえば、f2(1)、f3(1)などに基づいて第1の秘密鍵シェアを生成する。
【0105】
第1の参加者102aは、難読化された係数のセットに基づいて対応する公開鍵α・Gを計算し得、係数は、各参加者102のそれぞれの秘密鍵シェアαiを生成するために使用される。すなわち、一時的な秘密鍵シェアkiを生成するとき、各参加者102は、難読化された係数αij・Gを他の各参加者102と共有し得る。係数は、選択された楕円曲線上の共通の生成点Gによって難読化される。これらの難読化された係数は、参加者102間で直接送信されてもよく、グループにブロードキャストされてもよい。たとえば、第1の参加者102aは、難読化された係数α10・G、α11・G、α12・Gなどをブロードキャストし得る。次いで、秘密鍵に対応する公開鍵が以下のように計算され得る。
【0106】
【数26】
【0107】
秘密鍵シェアαiを生成するために、対応する公開鍵を生成する必要はなく、したがって、これは、参加者102が選択した場合に実装し得るオプション機能であることを理解されたい。
【0108】
秘密鍵シェアαiは、別の方法を使用して、すなわち、上記のJVRSS方法を使用せずに生成され得ることに留意されたい。秘密鍵シェアを生成するための方法は、それ自体が当技術分野で知られている。同様に、秘密鍵(または、他のそのようなデータ)のシェアを分散するための方法は、それ自体が当技術分野で知られている。そうは言っても、秘密鍵シェアαiは、様々な方法で生成され得る。たとえば、シャミール(Shamir)の秘密共有スキームを使用して、秘密鍵シェアαiのうちの1つ、一部、または全部を生成および分散するために、ディーラ(たとえば、参加者102のうちの信頼できる者、または独立した当事者)が使用され得る。秘密鍵シェアαiを生成および分散するために使用され得る1つのそのようなスキームは、WO2017145010A1に記載されている。
【0109】
秘密鍵シェアを生成するために使用される特定の方法にかかわらず、参加者102の第1のグループの各々は、秘密鍵αのそれぞれの秘密鍵シェアαiを有する(たとえば、記憶する)。
【0110】
新しいスキーム(すなわち、秘密鍵の新しいシェアを有するスキーム)の参加者102の各々は、共有ブラインド鍵のそれぞれのブラインド鍵シェアを生成する。ブラインド鍵シェアは、別の鍵シェアを難読化するか、「ブラインド化する(blind)」または「非表示にする(hide)」ために使用される。すなわち、第1の鍵シェアを非表示にするためにブラインド鍵シェアが第1の鍵シェアに適用され、結果として得られる鍵シェアを、第1の鍵シェアを明らかにすることなく共有できるようになる。単純な例では、第1の鍵シェアが100であり得、またブラインド鍵シェアが74であり得る場合、174の数を共有することが可能になる。ここで、ブラインド鍵シェアが74であることを知らなければ、受信者は第1の鍵シェアを確実に知ることができない。実際には、鍵シェアははるかに大きな数になる可能性があることを理解されたい。
【0111】
「鍵シェア(key share)」と「鍵(key)」は簡潔にするために使用され、一般にそれぞれ「秘密シェア(secret share)」と「秘密(secret)」に置き換えられ得ることを思い出されたい。実際には、「シェア(share)」と「鍵」は大きな数になる可能性がある。これらの参加者102(以下では「新しいグループ(new group)」と呼ばれる)は、参加者の第1グループからの参加者のみを含んでもよく、参加者の第1および第2のグループの組合せからの参加者を含んでもよい。
【0112】
好ましくは、ブラインド鍵シェアκiは、共同秘密共有スキームを使用して、たとえば、上記のJVRSS技法を使用して計算され得る。たとえば、第1の参加者102aは、インデックス1を有し、参加者1に対してκi=JVRSS(1)を使用してブラインド鍵シェアを生成し得、ブラインド鍵はκによって示される。各参加者102は、それぞれのブラインド鍵シェアκiを生成し得る。たとえば、第2の参加者102bは、参加者2に対してκ2=JVRSS(2)を使用して第2のブラインド鍵シェアを生成し得、以下同様である。
【0113】
共同秘密共有スキームを使用してブラインド鍵κ1シェアを生成することは、秘密鍵シェアα1を生成するために上述したのと同じステップを備えるが、ブラインド鍵シェアκ1を生成するために使用される乱数が、秘密鍵シェアα1を生成するために使用されるものとは異なる数である点が異なる。
【0114】
秘密鍵シェアαiと同様に、ブラインド鍵シェアκ1を生成するときに、JVRSSの代替手段が使用され得る。
【0115】
参加者の新しいグループの一部でもある参加者102の第1のグループ(すなわち、それぞれの秘密鍵シェアαiを有する参加者)の少なくともしきい値数は、それぞれのブラインド鍵シェアとそれぞれの秘密鍵シェアαiに基づいて、中間鍵シェアνiを生成する。すなわち、中間鍵シェアνiは、ブラインド鍵シェアと秘密鍵シェアαiの関数である。参加者102の第1のグループの一部である参加者102のみが、秘密鍵シェアαiに依存するため、この中間鍵シェアνiを生成できることに留意されたい。中間鍵シェアνiは、一般に任意の秘密シェアである可能性があり、鍵または秘密鍵であることに特に限定されないことに再度留意されたい。
【0116】
いくつかの例では、中間鍵シェアνiは、ブラインド鍵シェアと秘密鍵シェアの合計、すなわちνiiiとして計算され得る。しかしながら、中間鍵シェアνiが別の方法で、たとえば、νii-κで計算され得ることも除外されない。
【0117】
中間鍵シェアνiを計算した参加者102は、参加者の新しいグループ内の参加者102の各々にそれぞれのシェアνiを送信する。中間鍵シェアνiは、参加者102のペア間で直接送信されてもよく、一般に参加者102の新しいグループにブロードキャストされてもよく、別の方法で公開されてもよい。
【0118】
参加者102の新しいグループの各々は、複数の中間鍵シェアνiを取得する。次いで、参加者102の新しいグループの各々が、複数の中間鍵シェアνiに基づいて中間鍵νを計算する。すなわち、中間鍵νは、複数の中間鍵シェアνiの各々の関数である。たとえば、参加者102の新しいグループの各参加者は、中間鍵シェアνiを補間し得る。
【0119】
次いで、中間鍵νを取得すると、参加者102の新しいグループの各々が、中間鍵νおよびブラインド鍵シェアκiに基づいて、秘密鍵αの新しいシェア(たとえば、更新されたシェア)αi'を生成する。すなわち、秘密鍵αの新しいシェアαi'は、中間鍵νとブラインド鍵シェアκiの関数である。
【0120】
いくつかの例では、新しい秘密鍵シェアαi'は、中間鍵シェアと秘密鍵シェアの合計、すなわちαi'=ν-κiとして計算され得る。しかしながら、新しい秘密鍵シェアαi'が別の方法で、たとえばαi'=ν+κiで計算され得ることも除外されない。
【0121】
一般に、中間シェアνiを生成するために、第1の動作用いて第2の秘密シェアκiが第1の秘密シェアαiに適用され、次いで、中間鍵νを生成するために中間シェアνiを補間する。次いで、第1の秘密の新しいシェアαi'を見つけるために、中間鍵νと第2の秘密シェアκiに対して第1の動作の逆が実行される。
【0122】
これで、参加者102の新しいグループの各々は秘密鍵の新しいシェアを有している。参加者102の新しいグループは、以前は秘密鍵のシェアを有していなかった参加者102を含み得る(すなわち、新しいグループは第2のグループからの参加者102を備える)。または、新しいグループは、参加者102の第1のグループからの参加者102のみを含み得る。
【0123】
秘密鍵αの新しいシェアαi'のしきい値は、ブラインドシェアκiのしきい値に基づいて決定される。ブラインドシェアκiは、秘密鍵の新しいシェアαi'のしきい値が同じままであるように、秘密鍵シェアαiと同じしきい値を有し得る。あるいは、秘密鍵αの新しいシェアαi'のしきい値が以前のシェアαiのしきい値よりも高くなるように、ブラインドシェアκiは、秘密鍵シェアαiよりも高いしきい値を有してもよく、ブラインドシェアκiがより低いしきい値を有する場合はその逆の場合もある。
【0124】
新しいシェアが「発行される(issued)」と、共有秘密を作成する方法が、古いシェアαiを用いる方法と、新しいシェアαi'を用いる方法の2つある。古いシェアと新しいシェアを組み合わせようとすると、計算は間違ったシェアをもたらしてしまう。したがって、この計算は、各参加者が古いシェアαiを使用する場合、または各参加者が新しいシェアαi'を使用する場合にのみ機能する。シェアが更新されると、新しいシェアも使用するために他の参加者の信頼の要素が必要になる場合がある。古いシェアを使用しようとするユーザは、シェアの更新または再発行の前に敵対者とみなされるなど、敵対者とみなされる可能性がある。スキームにおける最小しきい値(つまり、シェアの更新前後のしきい値の最小値)よりも「敵対者(adversaries)」が少ない限り、敵対者が実行できるすべての攻撃が捕捉され、および/または敵対者がスキームから除外されるだけであるため、スキームは安全である。したがって、スキームを攻撃する動機はない。唯一の問題は、しきい値よりも多くの敵対者が存在する場合であるが、これは新しい問題ではなく、一般に、共有秘密スキームに存在する。
【0125】
図2は、スキームの参加者102によって実行される例示的な方法200を示している。この方法は、共有の損失の場合に、または代わりに、共有秘密スキームに参加者102を追加する、または取り除くために使用され得る。追加的または代替的に、本方法は、共有秘密のしきい値を変更するためにも使用され得る。新しいシェアαi'を発行するために、次のステップが実行される。
【0126】
ステップS201において、古いスキームの各参加者は、たとえば、JVRSSを使用して、秘密鍵αのシェアαiを生成した。
【0127】
ステップS202において、新しいスキームの各参加者は、しきい値(t+1)を用いてブラインドシェアκi=JVRSS(i)を生成する。鍵シェアを生成するための別の方法が使用され得ることに留意されたい。
【0128】
ステップS203において、古いシェアαiを有する少なくとも(t+1)人の参加者102が、それぞれ中間秘密シェアνiiiを計算する。秘密鍵シェアαiとブラインド鍵シェアκiの代替関数が使用されてもよい。
【0129】
ステップS204において、これらの参加者102は、すべての参加者102に中間秘密シェアをブロードキャストする。
【0130】
ステップS205において、すべての参加者102が、中間シェアν=interpolate(ν1、…、νt+1)=α+κの(t+1)を用いてブラインド秘密を計算する。
【0131】
ステップS206において、各参加者は、自分の新しい秘密シェアαi'=ν-κi=(α+κ)-κiを計算する。S203において使用する関数によっては、中間鍵νとブラインド鍵シェアκiの代替関数が使用され得る。
【0132】
これらの新しい秘密シェアは、古い秘密シェアと同じ方法で使用することができ、それらを用いて行われた計算は、古い共有秘密になる。シェアを更新する以前の方法は、次数が0の項を有する、すなわち、定数項がゼロである第2の多項式を単純に追加することであった。その結果、ゼロ次項であると定義されている共有秘密を変更していない。これは、次数が1の多項式でゼロ次がゼロの秘密に対してJVRSSを実行できないため、しきい値が2の秘密鍵は、しきい値を増やさないと更新できないことを意味する。
【0133】
しきい値署名スキームのセキュリティは、シェアの更新を使用して2つの方法で改善することができる。第1に、シェアが危険にさらされていることが判明した場合、スキームにおける参加者102は、その共有を役に立たなくするために、この方法を直ちに使用することができる。あるいは、このスキームを実行するグループは、攻撃者が特定の時間枠内で複数の場所を攻撃しなければならないように、シェアを断続的に更新することに同意することができる。これは、スキームが長期にわたって安全であることを意味する。より一般的には、新しいスキームの各参加者は、定期的に、または参加者102のうちの1人からの要求に応じて、S202からS206のステップを実行し得る。
【0134】
シェアの損失の場合、少なくとも(t+1)シェアがまだ知られている場合にのみ、シェアの再発行が可能であることに留意されたい。さらに、参加者102を取り除く場合、残りの参加者102の数は少なくとも(t+1)でなければならず、そうでなければ秘密を作成するために必要な数よりも少ないシェアが存在することになる。(t+1)シェア未満では(α+κ)を計算することができないため、少なくとも(t+1)人の参加者が存在しない限り、ステップS204を通過できないことに留意されたい。これは、しきい値をより高いしきい値に変更する場合にも当てはまる。すなわち、スキームには少なくともそのしきい値の数が必要である。
【0135】
上述したように、共有秘密αのしきい値は変更されてもよい。図2の方法200は、同じ秘密αに対して(t'+1)の新しい共有秘密しきい値を生成するために実装され得、次いで、参加者102は、以下の方法でこのしきい値を用いて新しい共有を生成する。
【0136】
ステップS201において、古いスキームの各参加者は、秘密鍵αのシェアαiを生成しており、それらのシェアはt+1のしきい値を有する。
【0137】
ステップS202において、スキームのすべての参加者102は、しきい値(t'+1)のブラインドシェアκi=JVRSS(i)を生成し、
【0138】
【数27】
【0139】
によって、2つのしきい値のうち最も高いしきい値にラベルを付ける。
【0140】
ステップS203において、少なくとも
【0141】
【数28】
【0142】
の参加者102が、中間秘密シェアνiiiを計算する。秘密鍵シェアαiとブラインド鍵シェアκiの代替関数が使用されてもよい。
【0143】
ステップS204において、これらの参加者102は、中間秘密シェアを他のすべての参加者102にブロードキャストする。
【0144】
ステップS205において、すべての参加者102は、ブラインド秘密
【0145】
【数29】
【0146】
を計算する。
【0147】
ステップS206において、各参加者は、自分の新しい秘密シェアαi'=ν-κi=(α+κ)-κiを計算する。S203において使用する関数によっては、中間鍵νとブラインド鍵シェアκiの代替関数が使用され得る。
【0148】
これらの新しい秘密シェアは(t'+1)のしきい値を有し、しきい値数のシェアに対する補間により、共有秘密αが得られる。次いで、これが署名計算において使用される場合(たとえば、以下で説明するように)、一時的な鍵がtのしきい値を有する場合、新しい署名シェアはt+t'+1のしきい値を有する。
【0149】
いくつかの実施形態では、秘密鍵αのシェアの数αi'および秘密鍵αのしきい値の両方が変更され得る。
【0150】
セキュリティは、「古い」シェアのしきい値数が証明可能に削除された場合にのみ増加する可能性があることに留意されたい。残っている共有の数が古いしきい値よりも少なくなるように、十分な数のシェアを確実に削除する必要がある。
【0151】
秘密がt+1のしきい値を有し、t'>tであるt'+1に増加されると仮定する。n個のシェアがあるとする。次いで、セキュリティを強化するために、残っている古いシェアがt+1未満であることが証明される必要があり、すなわち、スキームは、古いシェアがまだ存在するしきい値よりも少ないことを確認する必要がある。これは、その場合、秘密を古いシェアで計算する方法がないためである。t+1個の古いシェアがまだ存在する場合、たとえより高いしきい値を有する新しいシェアもある場合でも、秘密を計算するためにこれらを使用することができるため、セキュリティはt+1のままである。セキュリティは、秘密を計算するために必要な最小シェア数に基づいている。
【0152】
新しいスキームの参加者102は、新しいシェアαi'が正しく計算されたことを検証し得る。これは、個々の秘密に対応する公開鍵を追加し、それらを追加の結果に対応する公開鍵と比較することによって行われる。
【0153】
上記の序文において説明したように、各秘密α、κを生成するための方法により、公開鍵を計算するために十分な情報が得られる。したがって、公開鍵を計算した後、参加者はα・G、κ・Gを知ることができる。結果を確認するために、各参加者は次のステップを実行し得る。
1.(α・G)+(κ・G)を計算する
2.(α+κ)を使用して、(α+κ)・Gを計算する
3.同じであることを確認するために、これらの結果を比較する。
【0154】
さらに、参加者102が不正確な結果を見つけた場合、参加者はどのシェアが不正確であるかを決定することができる。これを行うために、参加者102は、参加者ごとにαi・Gおよびκi・Gを記憶する。次いで、参加者102はαi・Gおよびκi・Gを知っているので、上記と同じ検証である。参加者はαiiも補間のために共有されるため知っているので、これらの値で同じステップ1~3が繰り返される。ステップ3における値が等しくないという結果になるシェアは、不正確なシェアである。
【0155】
上述のように、新しいシェアαi'は、しきい値署名スキームの一部として使用され得る。すなわち、新しいシェアαi'は、秘密鍵αの秘密鍵シェアである可能性がある。本発明は、署名スキームの署名の基礎となる秘密鍵の参加者のシェアを更新するために使用され得る。新しいシェアαi'の数が変更される可能性があり、および/または新しい秘密鍵シェアαi'のしきい値が変更される可能性がある。
【0156】
図3は、新しい秘密鍵シェアαi'を使用して、しきい値最適署名スキーム、たとえば、しきい値最適ECDSAスキームを実装するための例示的なシステム300を示している。古いシェアが使用された場合、生成された署名は、新しいシェアを使用して生成された署名と同じになることに留意されたい。図示されるように、システム100は、コーディネータ101および参加者102のグループを含む複数の参加者102を備える。図3には3人の参加者102のみが示されているが、一般に、システムは任意の数の参加者を備え得ることを理解されたい。さらに、図1において、コーディネータ101は参加者102とは別個のものとして示されているが、いくつかの実施形態では、コーディネータ101は参加者102のうちの1人、たとえば、第1の参加者102aであってもよい。参加者102は、図1を参照して上記で説明されている。
【0157】
以下では、楕円曲線暗号化スキームを使用して実装されるスキームについて説明するが、一般に、本発明の実施形態は、他の公開鍵暗号化スキーム、たとえば、RSAに適用され得ることに留意されたい。
【0158】
コーディネータ101は、参加者102のグループのそれぞれの参加者によって生成されたしきい値数の署名シェアを使用して署名を開始する当事者である。すなわち、コーディネータ101は、署名対象のメッセージに署名を生成する。繰り返しになるが、メッセージに署名を生成するということは、署名が署名対象のメッセージに依存するか、別の言い方をすれば、署名は署名対象のメッセージの関数であることを意味すると解釈されることに留意されたい。コーディネータ101はまた、署名、およびオプションでメッセージを第三者103に送信するか、さもなければ署名を出力する当事者であってもよい。たとえば、第三者103は、証明機関または他の形態の機関、あるいは別のユーザであり得る。他の例では、データベースまたは他のドキュメントに署名が記録され得る。いくつかの例では、署名は一般に公開されてよく、たとえば、ウェブサイトまたは他の公的にアクセス可能な媒体に記録されてよい。
【0159】
コーディネータ101は、署名対象のメッセージを参加者102に送信し得る。メッセージは、参加者102のすべてに、または参加者のサブセットに、たとえばしきい値数の参加者に送信され得る。図1の例では、参加者のグループは、3人の参加者102a、102b、102cを備える。コーディネータ101はメッセージを1人の参加者に送信し得、参加者はそのメッセージを他の参加者の1人、一部、または全員に転送する。
【0160】
メッセージは、LANまたはWAN接続を使用してインターネット経由で送信されてもよく、代替のワイヤードまたはワイヤレス通信手段を介して送信されてもよい。メッセージは、各参加者102に個別に、たとえばコーディネータ101と各参加者102との間の安全な通信チャネルを介して送信されてもよく、グループ全体に、たとえば、電子メールまたは他の手段を介してブロードキャストされてもよい。メッセージは、生の形式または暗号化された形式で送信され得る。たとえば、メッセージは1回または複数回ハッシュされ得る。
【0161】
参加者102のうちの1人または複数は、代替手段を介して、すなわちコーディネータ101からではなく、メッセージを取得し得る。たとえば、メッセージは、参加者102のうちの1人によって生成されてもよく、そうでなければ公に利用可能であってもよい。1人または複数の参加者102は、第三者103からメッセージを受信し得る。メッセージを取得する参加者102は、1人または複数の他の参加者102にメッセージを(生の形式、または暗号化された形式で)送信し得る。たとえば、第1の参加者102は、メッセージを第2の参加者102bおよび/または第3の参加者102cに送信し得る。
【0162】
コーディネータ101は、しきい値数の署名シェアを取得する(たとえば、受信する)。図1の例では、しきい値は2であり、第1の参加者102aおよび第2の参加者102bのみが、それぞれの署名シェアを生成することを決定する。たとえば、署名シェアを生成する参加者102のうちの1人または複数は、たとえば、安全な通信チャネルを介して、コーディネータ101にそれぞれのシェアを直接送信し得る。あるいは、参加者102のうちの1人または複数が、それぞれのシェアをブロードキャストし、および/またはシェアを公に利用可能にし得る。上述のように、コーディネータ101は参加者であってもよい。それらの実施形態では、コーディネータ101はまた、それぞれの署名シェアを生成し得る。その意味で、しきい値数の署名シェアのうちの少なくとも1つを取得することは、少なくとも1つの署名シェアを生成することを意味し、したがって、コーディネータ101は、しきい値数の署名シェアよりも少ない1つを受信するだけでよい。
【0163】
署名シェアを取得するために、コーディネータ101は、署名シェアの要求をメッセージで送信し得る。たとえば、コーディネータ101は、参加者102のグループの1人、一部、または全員に、署名シェアの要求を送信し得る。
【0164】
少なくともしきい数の署名シェアを取得すると、コーディネータ101は、取得したシェアを使用して署名を生成する。次いで、コーディネータ101は、署名を1つまたは複数の他のエンティティにブロードキャストまたは送信し得る。追加的または代替的に、コーディネータは、署名を記憶し、および/または署名をデジタル記録の一部として、たとえば電子メールまたはその他のドキュメントにおいて記録し得る。
【0165】
次に、署名シェアsiを生成するための方法について説明する。本方法は、第1の参加者102aの観点から説明されているが、署名シェアを生成する他の各参加者102は、他の参加者102に固有の特定のデータを使用するにもかかわらず、同等の方法を使用してそうすることが理解されるであろう。
【0166】
各参加者102は、以下のデータ項目へのアクセスを有する:それぞれの秘密鍵シェアαi'(すなわち、秘密鍵αのシェア)、それぞれの一時的な秘密鍵シェアki、および共通の一時的な公開鍵k・Gに基づいて生成される共通の共有値γ。共通の一時的な公開鍵は、一時的な秘密鍵に対応する、すなわち、一時的な秘密鍵に基づいて生成される。ここで、値または鍵は、各参加者が同じ値または鍵にアクセスできるという意味で共通である場合がある。指定されていない限り、第1の鍵に基づいて第2の鍵を生成しても、第1の鍵自体が知られていることを必ずしも意味しないことに留意されたい。これらのデータ項目がどのように生成され得るかの例を以下に示す。
【0167】
第1の参加者102aは、署名対象のメッセージを取得するか、またはすでにアクセスしている。メッセージは、生の形式(たとえば、平文)であってもよく、暗号化または符号化されていてもよい(たとえば、暗号文)。第1の参加者102aは、コーディネータおよび/または別の参加者102から(いずれかの形式で)メッセージを取得し得る。あるいは、第1の参加者102aは、署名対象のメッセージを生成し得る。
【0168】
第1の参加者102aは、第1の署名シェアs1を生成する。この文脈における「第1の(first)」は、特定の参加者および特定の署名シェアを他の参加者および署名シェアからそれぞれ区別するための任意のラベルとして使用されるだけであり、第1の参加者102aが署名シェアsiを生成する第1の参加者であること、または第1の署名シェアs1が署名シェアsiの順序付けられたリストの第1のものであることを必ずしも意味しないことに留意されたい。
【0169】
いくつかの実施形態では、第1の署名シェアs1は、第1のメッセージ非依存コンポーネント(MIC)および第1のメッセージ依存コンポーネント(MDC)に基づいて生成されてもよく、すなわちこれらの関数であり、「第1の」は、やはりラベルとして使用されるにすぎない。MICは、メッセージとは別に生成される。すなわち、MICは署名対象のメッセージの関数ではなく(つまり、MICはメッセージに基づいて生成されない)、MICを生成するためにメッセージの知識は必要ない。対照的に、MDCは署名対象のメッセージの関数であり、MDCを生成するためにはメッセージの知識が必要である。
【0170】
他の実施形態では、第1の署名は、第1のメッセージ非依存コンポーネント(MIC)の関数ではない可能性がある。これらの実施形態では、第1のメッセージ非依存コンポーネントが生成され、コーディネータ101にとって利用できるようになり、たとえば、コーディネータ101に送信されるか、1人または複数の参加者102にブロードキャストされる。第1のメッセージ非依存コンポーネント(MIC)は、第1の署名シェアに先立って、およびそれとは別個に、コーディネータと共有され得る。
【0171】
コーディネータ101は、少なくともしきい値数の参加者からそれぞれのメッセージ非依存コンポーネント(MIC)を取得し、それぞれの署名シェア(それぞれのメッセージ依存コンポーネント(MDC)の関数である)およびそれぞれのメッセージ非依存コンポーネント(MIC)に基づいて署名を生成する。詳細は以下に記載されている。
【0172】
MICはメッセージの知識を必要としないため、MICは事前に計算することができる。言い換えれば、メッセージを取得する前にMICを生成することができる。したがって、複数の異なるMICを事前に計算することができ、それぞれが異なるメッセージに署名するための異なるそれぞれの署名シェアs1'を生成する際に使用され、プライム(')は、第1の署名シェアの別のインスタンスであることを示す。
【0173】
第1の署名シェアs1を生成すると、第1の参加者102aは、コーディネータ101がメッセージに署名sを生成するために第1の署名シェアs1を利用可能にする。第1の参加者102aがコーディネータ101である場合、コーディネータ101が第1の署名シェアs1を利用できるようにすることは、署名sを生成するための関数に第1の署名シェアs1を出力することを単に意味し得る。そうでなければ、第1の参加者102aは、第1の署名シェアs1をコーディネータ101に、またはコーディネータ101に転送するために1人または複数の他の参加者102に送信するか、または第1の署名シェアs1をブロードキャストするか、またはこれらのオプションの組合せを使用し得る。
【0174】
上述のように、第1の署名シェアs1は、第1のMICおよび第1のMDCに基づいて生成され得る。第1の署名シェアが第1のMICの関数であるかどうかに関係なく、第1のMICは、第1の秘密鍵シェアα1(すなわち、第1の参加者102aに知られている秘密鍵αのシェア)に基づいて生成される(すなわち、その関数である)。第1のMICはまた、第1の一時的な秘密鍵シェアk1(すなわち、第1の参加者102aに知られている一時的な秘密鍵kのシェア)と、一時的な秘密鍵kに対応する一時的な公開鍵k・Gに基づいて生成された共有値γとに基づき得る。第1のMDCは、メッセージ(生の形式、または暗号化された形式)に基づいて生成され(すなわち、その関数であり)、第1の一時的な秘密鍵シェアk1に基づいて生成されてもよい。MICとMDCのバリエーションを以下に示す。
【0175】
第1の一時的な秘密鍵シェアk1は、共同秘密共有スキームを使用して、たとえば、上記のJVRSS技法を使用して計算され得る。たとえば、第1の参加者102aは、インデックス1を有し、参加者1に対してki=JVRSS(1)を使用して第1の一時的な秘密鍵シェアを生成し得、一時的な秘密鍵はkによって示される。各参加者102は、それぞれの一時的な秘密鍵シェアkiを生成し得る。たとえば、第2の参加者102bは、参加者2に対してk2=JVRSS(2)を使用して第2の一時的な秘密鍵シェアを生成し得、以下同様である。
【0176】
共同秘密共有スキームを使用して第1の一時的な秘密鍵k1シェアを生成することは、第1の秘密鍵シェアα1を生成するために上述したのと同じステップを備えるが、一時的な秘密鍵シェアk1を生成するために使用される乱数が、秘密鍵シェアα1を生成するために使用されるものとは異なる数である点が異なる。
【0177】
同じ秘密鍵αと秘密鍵シェアα1が各署名に使用されているが、一時的な秘密鍵kと一時的な秘密鍵シェアk1は署名ごとに変更される(または、それらはランダムに生成され、したがって、意図的に異なるように選択されるのではなく、同じである可能性はほとんどない)ことに留意されたい。
【0178】
共有値γは、一時的な秘密鍵kに対応する一時的な公開鍵k・Gに基づいて生成される。一時的な公開鍵(x、y)は、通常xおよびyコンポーネントと呼ばれる2つのコンポーネントを備える。共有値γは、一時的な公開鍵のxコンポーネントの関数、たとえば、γ=x mod nであり得る。
【0179】
一時的な公開鍵k・Gは、難読化された係数のセットに基づいて生成されてもよく、係数は、各参加者102のそれぞれの一時的な秘密鍵シェアk1を生成するために使用された。すなわち、一時的な秘密鍵シェアk1を生成するとき、各参加者102は難読化された係数k1j・Gを他の各参加者102と共有する。係数は、選択された楕円曲線上の共通の生成点Gによって難読化される。これらの難読化された係数は、参加者102間で直接送信されてもよく、グループにブロードキャストされてもよい。たとえば、第1の参加者102aは、難読化された係数k10・G、k11・G、k12・Gなどをブロードキャストし得る。次いで、一時的な秘密鍵が以下のように計算され得る。
【0180】
【数30】
【0181】
いくつかの実施形態では、第1のMICは、第1の一時的な秘密鍵シェアk1に対応する第1の逆シェア
【0182】
【数31】
【0183】
に基づいて生成される。すなわち、第1の逆シェア
【0184】
【数32】
【0185】
は、第1の一時的な秘密鍵シェアk1の関数である。
【0186】
第1の逆シェア
【0187】
【数33】
【0188】
は、たとえば、参加者1について
【0189】
【数34】
【0190】
を計算することによって生成された共有秘密の逆である可能性がある。上述のように、共有秘密の逆数を計算することは、共有秘密の積を計算することを備える。第1の参加者102aは、第1の一時的な秘密鍵kと第1のブラインド鍵αとの積として中間値μを生成する。たとえば、中間値は、参加者1についてμ=kα=PROSS(1)によって計算され得、その結果はμ=kα mod nである。
【0191】
これは、各参加者102が乗法シェアμi=kiαiを生成することを含み得、ここでαiは第1のブラインド鍵αのシェアである。各参加者102は、共同秘密共有スキームを使用して、たとえば、上記のJVRSS技法を使用して、第1のブラインド鍵αのそれぞれのシェアαiを計算し得る。たとえば、第1の参加者102aは、1のインデックスを有し、参加者1に対してαi=JVRSS(1)を使用して第1のブラインド鍵のシェアを生成し得る。各参加者は、(たとえば、直接送信またはブロードキャストを介して)それぞれの倍数シェアμiを共有し、次いで、倍数シェアμiの各々に基づいて、たとえば補間によって、中間値μを生成する。第1の逆シェア
【0192】
【数35】
【0193】
は、中間値μの逆数を計算することによって生成され得る。たとえば、第1の参加者102aは、μの剰余逆数を計算し得、その結果は以下のとおりである。
μ-1=(kα)-1 mod n
【0194】
次いで、第1の参加者102aは、中間値の剰余逆数μ-1およびそれらのそれぞれの第1のブラインド鍵シェアα1に基づいて、たとえば
【0195】
【数36】
【0196】
を計算することによって、第1の逆シェア
【0197】
【数37】
【0198】
を計算し得る。
【0199】
ブラインド鍵シェアα1の使用はオプションであり、上記のステップから省略され得ることに留意されたい。
【0200】
任意で、MICは、第2のブラインド鍵βのシェア(すなわち、関数)に基づいて生成されてもよい。すなわち、MICは、前述のデータ項目に加えて、第2のブラインド鍵βの第1のシェアβ1にも基づいている。第2のブラインド鍵の第1のシェアは、共同秘密共有スキームを使用して、たとえば、上記のJVRSS技法を使用して計算され得る。たとえば、第1の参加者102aは、インデックス1を有し、参加者1に対してβi=JVRSS(1)を使用して第2のブラインド鍵の第1のシェアを生成し得、第2のブラインド鍵はβによって示される。
【0201】
MICは、第1の中間シェアλ1の関数である第1の署名前シェアσ1と、少なくともしきい値数の参加者102から取得されたそれぞれの中間シェアλ1とに基づいて生成され得る。すなわち、参加者102の各々は、それぞれの中間シェアλ1を生成し、それらの中間シェアλ1を他の参加者102に送信および/またはブロードキャストし得る。第1の参加者102aは、たとえば、中間シェアλ1の補間によって共通の中間値λを生成するために、中間シェアλ1を集めることができる。第1の参加者102a(および、オプションとして、他の参加者102)は、それぞれが異なる署名シェアs1'の生成に使用するために、複数の署名前シェアσ1'を生成し得る。
【0202】
第1の中間シェアλ1は、新しい第1の秘密鍵シェアαi'および第1の逆シェア
【0203】
【数38】
【0204】
の関数であり得る。その場合、少なくともしきい値数の参加者102の各々が、それぞれの秘密鍵シェアαi'およびそれぞれの逆シェア
【0205】
【数39】
【0206】
の関数であるそれぞれの中間シェアλ1を生成し、共有する。
【0207】
あるいは、第1の中間シェアλ1は、第1の秘密鍵シェアαi'と第1のブラインド鍵αiの第1のシェアの関数であってもよい。その場合、少なくともしきい値数の参加者102の各々が、それぞれの秘密鍵シェアαi'および第1のブラインド鍵αiのそれぞれのシェアの関数であるそれぞれの中間シェアλ1を生成し、共有する。
【0208】
いくつかの実施形態では、第1の署名前シェアσ1はまた、第2のブラインド鍵β1の第1のシェアに基づいて生成されてもよい。たとえば、第1の中間シェアλ1は、第2のブラインド鍵β1の第1のシェアの関数であってもよい。追加または代替の実施形態では、第1の中間シェアλ1は、共通値γの関数でもあり得る。
【0209】
図4は、本発明の実施形態に従ってメッセージに署名を生成するための例示的な方法400を示している。ステップS401~S408は、この例ではしきい値数の参加者102(第1の参加者102aを含む)の各々によって実行される。ステップS409は、コーディネータ101によって実行され、コーディネータ101は、ステップS401からS408を実行する参加者のうちの1人でもあり得る。ステップのいくつかが省略されてもよく、異なる順序で実行されてもよいことを理解されたい。
【0210】
例示的な方法400はN≧2t+1の参加者のグループにおけるしきい値(t+1)の共有秘密の作成を可能にし、署名しきい値も(t+1)である。
【0211】
設定:
【0212】
ステップS401において、各参加者102は、共有秘密鍵シェアαi'および対応する公開鍵を計算する。秘密鍵シェアαi'の生成は、上記で説明されている。この時点で、各参加者iは秘密鍵(secret key)シェアと公開鍵(αi'、P)を有しており、ここで、Pは共有秘密鍵に対応する公開鍵の表記である。共有秘密鍵は(t+1)のしきい値を有する。
【0213】
事前計算:
【0214】
ステップS402において、各参加者102は、共有された一時的な鍵シェアおよび対応する公開鍵を計算する。たとえば、各参加者102は、JVRSSおよび序文において与えられた公開鍵の計算を使用して、共有された一時的な鍵を計算し得る。次いで、各参加者102は、一時的な秘密鍵に基づいて逆シェアを計算し得る。これにより、各参加者は逆シェア
【0215】
【数40】
【0216】
,r)を有し、しきい値は(t+1)になる。
【0217】
ステップS403において、各参加者102は、2つの異なる共有ブラインド鍵シェアを作成する。たとえば、各参加者102は、参加者iがシェアαi=JVRSS(i)およびβi=JVRSS(i)を有し、各共有秘密がしきい値(t+1)を有するように、2つの共有秘密を作成し得る。いくつかの例では、すべての共有秘密が同じしきい値を有する必要はないことに留意されたい。
【0218】
ステップS404において、各参加者102は、中間シェアを計算し、その中間シェアを他の参加者にブロードキャストする。たとえば、各参加者iは、中間シェア
【0219】
【数41】
【0220】
を計算し得る。この値は(2t+1)のしきい値を有する。
【0221】
ステップS405において、各参加者102は、少なくとも中間シェアに基づいて中間値を計算する。たとえば、各参加者102は、(2t+1)シェアに対する補間λ=interpolate(λ1、…、λ2t+1)=k-1α+βを使用して中間値を計算し得る。
【0222】
ステップS406において、各参加者102は署名前シェアを計算する。たとえば、各参加者iは、署名前のシェアσi=λ-βi=(k-1α+β)-βiを計算し得る。各参加者102は、(γ、
【0223】
【数42】
【0224】
、σi)を記憶し得、秘密鍵シェア、および対応する公開鍵(αi'、P)を共有する。
【0225】
署名ごとに異なる一時的な鍵が使用されるため、一度に複数の一時的な鍵を設定することができ、すなわち、事前計算中に複数の一時的な鍵を作成し、後で使用するために記憶するためにステップS402からS406を繰り返すことができることに留意されたい。これらは同時に実行できるため、追加の通信ラウンドはない。好ましくは、署名ごとにαおよびβの異なる値が使用されるべきであることに留意されたい。
【0226】
署名の生成:
【0227】
メッセージmsgに署名するために、少なくとも(t+1)人の参加者がステップS407およびS408を実行しなければならない。
【0228】
ステップS407において、少なくともしきい値数の参加者102は、署名対象のメッセージを取得し、メッセージダイジェストを計算する。たとえば、コーディネータ101は、メッセージmsg上で署名シェアを作成するために、(t+1)人の参加者に要求を送信し得る。各参加者iは、メッセージダイジェストe=hash(msg)を計算し得る。いくつかの例では、このハッシュ関数はdouble SHA-256ハッシュ関数である。別のハッシュ関数が使用されてもよい。
【0229】
ステップS408において、少なくともしきい値数の参加者102が署名シェアを計算し、それをコーディネータ101に送信する。たとえば、各参加者iは署名シェア
【0230】
【数43】
【0231】
を計算し、次いで、署名シェア(γ、si)をコーディネータに送信する。値γがすべての参加者によって送信されない場合があることに留意されたい。
【0232】
ステップS409において、コーディネータ101が署名を計算する。たとえば、コーディネータ101は、s=interpolate(si、…、st+1)=k-1(e+αγ)を計算し、最後に署名(γ、s)を計算し得る。
【0233】
署名シェアのメッセージに依存しないコンポーネントを事前に計算するための代替手段がいくつかある。これらは、計算にγを含める場合と(kα)-1を含める場合の2つのバリエーションのセットに大きく分けることができる。これらは互いに独立して選択できるため、上記の方法400には8つのバリエーションがある。
【0234】
1つの修正は、ステップS406の間に(r,
【0235】
【数44】
【0236】
,rσi)を記憶することであり、γが署名前シェアに含まれていることを意味する。もう1つの修正点は、中間シェアの計算中に、γとの乗算が早期に行われる可能性があることである。代わりに、ステップS404において
【0237】
【数45】
【0238】
を定義することによって、ステップS406において、σi=λ-βi=(γk-1α+β)-βiであり、署名シェアの計算は
【0239】
【数46】
【0240】
である。
【0241】
別の修正は、代わりにλiiαi'+βiをλ=(kα)-1(αα+β)、およびσi=λ-(kα)-1βiとなるように計算することである。代替ポイントにγを含める2つのバリエーションは、これと組み合わせて実行することができる。各参加者は、事前計算のステップS402において計算されるので、kαの知識を有する。さらに、すべての参加者102は、自分のλiシェアをブロードキャストする。したがって、各参加者102は、(少なくとも)2t+1シェアと値kαについての知識を有する。次いで、以下を計算することができる。
λ=kα-1×interpolate(λ1、…、λ2t+1)
【0242】
別の変更は、代わりに中間値をλ=(αα+β)として計算し、署名前シェアをσi=λ-βiとして計算することである。最後に、署名シェア
【0243】
【数47】
【0244】
になる。γをいつ計算に含めるかの2つのバリエーションは、これと組み合わせて実行することもできる。各参加者102は、
【0245】
【数48】
【0246】
の計算からkαの知識を有する。次に、これを用いて(kα)-1 mod nを計算し、それをsiの計算に含めることができる。
【0247】
要約すると、各参加者102は、αi'、ki、αi、βiという4つの秘密シェアを生成し得る。例示的な方法400において2つの積を計算する必要があり、kαは、
【0248】
【数49】
【0249】
を計算するために使用され、これらのシェアを補間すると、αがキャンセルされるためk-1が得られ、第1の積を使用する署名において使用するためにk-1αが得られ、したがって、シェアが展開されている場合、計算結果は
【0250】
【数50】
【0251】
になる。kαとαiで構成される
【0252】
【数51】
【0253】
シェアを使用した計算は、最初にαi自体だけで計算を行い、次いで、必要に応じて(kα)-1を乗算することによって実行することができる。
【0254】
上記のスキームの1つのバージョンは、メッセージ非依存コンポーネント(MIC)とメッセージ依存コンポーネント(MDC)で構成されるシェアを使用して署名が計算されると要約することができ、ここで、MICは署名前シェアσiに基づく場合があり、MDCはメッセージeに基づく。
【0255】
同等のスキームは、上記のようにMICを計算し、次いで、たとえばMDCだけで作成された署名シェアを補間した後に、これを署名シェアとともに署名に組み込むことを備える。明示的には、スキームは、事前計算のステップS406まで同じである可能性があり、ここで、中間シェアはγ値、
【0256】
【数52】
【0257】
を含み、補間後、これは
【0258】
【数53】
【0259】
となる。
【0260】
この段階で、参加者は(γ、
【0261】
【数54】
【0262】
λ、βi)の知識を有し、これを秘密鍵シェアおよび対応する公開鍵(αi'、P)とともに記憶する。
【0263】
次いで、メッセージダイジェストe=hash(m)を作成するためにハッシュされる所与のメッセージm上で署名シェアを生成するために、参加者は
【0264】
【数55】
【0265】
を計算し、これをコーディネータに送信する。次いで、コーディネータが
s=interpolate(s1、…、st+1)+λ、
=k-1e+k-1αγ
を計算し、β条件がキャンセルされるため、予想される署名シェアが得られる。(kα)-1とγが計算に含まれる場合、上記の説明のように、このプロトコルの同様のバリエーションを作成することができる。
【0266】
メッセージに依存しないコンポーネントを計算するための次のバリエーションが実装され得る。
i)λ=k-1α+βを計算すると、署名シェアは
【0267】
【数56】
【0268】
になり、署名はs=int(s1、…、st+1)+γλとして生成される。
ii)λ=αα+βを計算すると、署名シェアはsiie-βiになり、署名はs=(kα)-1(int(s1、…、st+1)+λ)として生成される。
iii)λ=αα+βを計算すると、署名シェアは
【0269】
【数57】
【0270】
になり、署名はs=(kα)-1(int(s1、…、st+1)+γλ)として生成される。
iv)λ=ααγ+βを計算すると、署名シェアは
【0271】
【数58】
【0272】
になり、署名はs=(int(s1、…、st+1)+(kα)-1λ)として生成される。
v)λ=αα+βを計算すると、署名シェアは
【0273】
【数59】
【0274】
になり、署名はs=(int(s1、…、st+1)+γ(kα)-1λ)として生成される。
【0275】
シークレットのしきい値は異なる場合があることに留意されたい。すなわち、署名生成スキームを実行するために、α、k、α、β自体のしきい値は必ずしも同じである必要はない。たとえば、6人のグループがあり、3人が署名および/または秘密鍵を作成する必要がある場合、技術的には、kのしきい値を4、他の共有秘密のしきい値を3として計算を行うことができ、それらは依然としてしきい値最適スキームを有する。
【0276】
本発明は、(最適か非最適かを問わず)任意のしきい値署名スキームに適用されてよく、上記の特定のスキームに限定されないことに留意されたい。
【0277】
一般に、任意のメッセージに署名を生成するために、本発明の実施形態を使用することができる。特定の例示的な使用例として、メッセージはブロックチェーントランザクションの一部またはすべてであり得る。すなわち、署名は、ブロックチェーントランザクションの1つまたは複数の入力および/あるいは1つまたは複数の出力に署名するために使用され得る。たとえば、生成された署名は、ブロックチェーントランザクションの出力のロックを解除するために、少なくとも部分的に使用され得る。特定の例として、以前のトランザクションの出力は、公開鍵のハッシュにロックされている公開鍵ハッシュへの支払い(pay-to-public-key-hash、P2PKH)出力である可能性がある。ロックを解除するためには、P2PKH出力を参照する後のトランザクションの入力に、(ハッシュされていない)公開鍵と、公開鍵に対応する秘密鍵に基づいて生成された署名を含める必要がある。
【0278】
スクリプトで表すと、「ロックスクリプト(locking script)」と「ロック解除スクリプト(unlocking script)」は次の形式を取る場合がある。
【0279】
ロックスクリプト=OP_DUP OP_HASH160<Public KeyHash>OP_EQUAL OP_CHECKSIG
ロック解除スクリプト=<Signature> <Public Key>
【0280】
上述の実施形態を参照すると、<Public Key>はP=α・Gと同一視することができ、<Signature>はしきい値署名sを備え、以前のトランザクションは署名対象のメッセージである。上記のように、ECDSA署名は(γ、s)の形式であることに留意されたい。
【0281】
本発明は、どの参加者が署名シェアを生成できるか、したがってどの参加者が集まって資金をアンロックするか、つまりブロックチェーントランザクションの出力をアンロックする必要があるかを変更するために使用され得る。追加的または代替的に、本発明は、資金のロックを解除するために必要な参加者の数を増やすために使用することができる。
【0282】
説明した署名生成方法は、特定の使用例に限定されず、一般に、任意のメッセージに基づいて署名を生成するために使用され得ることに留意されたい。ブロックチェーントランザクションの全部または一部に署名することは、1つの例示にすぎない。記載された方法は、たとえば、法的文書(たとえば、遺言書、証書または他の契約)、1人または複数の当事者間の通信、デジタル証明書(たとえば、認証局によって発行されたもの)、医療処方箋、銀行振込または金融商品、住宅ローンまたはローンの申込みなどに署名および/または承認するために使用され得る。
【0283】
特定の例として、参加者のグループ(たとえば合計5人の参加者)が会社の取締役会を構成する場合がある。会社の投票事項では、取締役会の過半数(すなわち、少なくとも3人の参加者)が特定の投票に同意する必要がある場合がある。理事会は、少なくとも3人の理事会メンバーが特定の結果に賛成票を投じることに同意したことを証明するために、説明された署名生成方法を使用し得る。この例では、署名生成スキームのしきい値は3である。すなわち、コーディネータが署名生成を成功させるためには、少なくとも3人の理事会メンバーがそれぞれの署名シェアを提供する必要がある。署名が正常に生成された場合、少なくともしきい値数(すなわち、3人)の理事会メンバーがその結果に賛成票を投じることに同意している必要がある。したがって、署名の生成が成功すると、投票の記録として機能し、理事会の過半数が特定の方法で投票したことが証明される。
【0284】
本発明は、誰がそのような事項に投票できるかを変更するために、および/または投票の結果を首尾よく決定するために必要な投票数(すなわち、シェア)を増減するために使用され得る。
【0285】
本発明の別の使用例は、デジタル証明書の分野、たとえば、X.509規格によって発行されたデジタル証明書にある。デジタル証明書は、一部のデータに署名する署名を含んでいる。データは一般に任意のデータである可能性があるが、デジタル証明書に含まれるデータの1つの特定の例は公開鍵である。デジタル証明書における公開鍵は、「認証済み公開鍵(certified public key)」と呼ばれることがよくある。デジタル証明書の発行者(「認証局(certificate authority)」)は、公開鍵の所有者に対して1つまたは複数のチェック(たとえば、顧客確認チェック)を実行し得、チェックが成功すると、認証局は、認証された公開鍵を含むデジタル証明書を発行する。ユーザは、自分が誰であるかを証明するために、たとえば認証された公開鍵に対応する秘密鍵でメッセージに署名することによって、認定された公開鍵を使用することができる。
【0286】
認証局の特定の用途の1つは、インターネット上の安全なブラウジングのためにHTTPSにおいて使用される証明書に署名することである。もう1つの一般的な用途は、各国政府によって電子署名文書に使用するためのIDカードを発行することである。認証局は、秘密鍵を使用して公開鍵(または、証明される任意の他のデータ)に署名する。本発明は、どの参加者が秘密鍵のシェアを持っているかを変更するために使用され得る。秘密鍵のセキュリティは、秘密鍵のしきい値を増やすことによっても改善される場合がある。
【0287】
本発明の背後にある原理は、参加者のグループがそれぞれのブラインドシェアに基づいて共有秘密の新しいシェアを生成することである。ブラインドシェアにより、共有秘密の古いシェアを有する参加者は、「中間シェア(intermediary shares)」の形式で、古いシェアのブラインド(すなわち、難読化)バージョンを「新しい(new)」グループの参加者に分散できるようになる。中間シェアは、中間を形成するために組み合わされ(または、補間され)、そこから参加者のグループの各々が、共有秘密のそれぞれの新しいシェアを取得するために、ブラインドシェアを適用(たとえば、減算または加算)することができる。本発明は、主にECCの実装形態に関して説明されてきたが、本発明は、他の実装形態、たとえばRSAにも同様に適用される。
【0288】
上記の実施形態は、例としてのみ説明されていることを理解されたい。より一般的には、以下のステートメントのうちのいずれか1つまたは複数に従って、方法、装置、またはプログラムを提供され得る。
【0289】
ステートメント1.共有秘密のシェアを生成するコンピュータ実装方法であって、参加者のグループの各々が共有秘密のそれぞれの第1の秘密シェアを有し、グループの第1の参加者によって実行され、
共有ブラインド秘密のそれぞれのブラインドシェアを生成するステップと、
参加者の第1のグループの各々からそれぞれの中間シェアの少なくともしきい値数を取得するステップであって、それぞれの中間シェアが、それぞれのブラインドシェアおよびそれぞれの第1の秘密シェアに基づいて生成される、ステップと、
取得された中間シェアの各々に基づいて中間価値を生成するステップと、
共有秘密のそれぞれの第2の秘密シェアを生成するステップであって、それぞれの第2の共有される秘密が、中間値およびそれぞれのブラインドシェアに基づいて生成される、ステップと
を備える、方法。
【0290】
ステートメント2.それぞれの中間シェアのうちの第1のものが、第1の参加者によって生成される、ステートメント1に記載の方法。
【0291】
ステートメント3.共有秘密のしきい値が、共有ブラインド秘密のしきい値に等しい、ステートメント1またはステートメント2に記載の方法。
【0292】
別の言い方をすれば、第2の秘密シェアのしきい値は、第1の秘密シェアと同じである。
【0293】
ステートメント4.共有秘密のしきい値が、共有ブラインド秘密のしきい値と比較して異なる、ステートメント1またはステートメント2に記載の方法。
【0294】
すなわち、第2の秘密シェアのしきい値が、第1の秘密シェアと比較して異なる。
【0295】
ステートメント5.共有秘密のしきい値が、共有ブラインド秘密のしきい値よりも大きい、ステートメント4に記載の方法。
【0296】
ステートメント6.共有秘密のしきい値が、共有ブラインド秘密のしきい値未満である、ステートメント4に記載の方法。
【0297】
ステートメント7.共有ブラインド秘密のそれぞれのブラインドシェアが、共同の検証可能な秘密共有スキームを使用して生成される、ステートメント1から6のいずれかに記載の方法。
【0298】
ステートメント8.共同秘密共有スキームを使用してそれぞれのブラインドシェアを生成するステップが、
第1のデータ項目を生成するステップであって、第1のデータ項目が第1の多項式である、ステップと、
少なくともしきい値数の参加者からそれぞれのデータ項目を取得するステップであって、それぞれのデータ項目が、それぞれの参加者によって生成されたそれぞれの多項式である、ステップと、
第1のデータ項目およびそれぞれのデータ項目の各々に基づいて、それぞれのブラインドシェアを生成するステップと
を備える、ステートメント7に記載の方法。
【0299】
ステートメント9.それぞれのデータ項目を取得するステップが、第1の参加者としきい値数の参加者の各々との間のそれぞれの通信チャネルを介してそれぞれのデータ項目を取得するステップを備える、ステートメント7またはステートメント8に記載の方法。
【0300】
ステートメント10.第1の多項式のそれぞれのインスタンスをしきい値数の参加者の少なくとも各々に送信するステップを備え、第1の多項式のそれぞれのインスタンスがそれぞれの参加者に基づく、ステートメント7から9のいずれかに記載の方法。
【0301】
ステートメント11.共有ブラインド秘密のそれぞれのブラインドシェアが、シャミールの秘密共有スキームを使用して生成される、ステートメント1から7のいずれかに記載の方法。
【0302】
ステートメント12.共有秘密のそれぞれの第1の秘密シェアが、共同の検証可能な秘密共有スキームを使用して生成される、ステートメント1から11のいずれかに記載の方法。
【0303】
ステートメント13.共有秘密のそれぞれの第1の秘密シェアが、シャミールの秘密共有スキームを使用して生成される、ステートメント1から11のいずれかに記載の方法。
【0304】
ステートメント14.共有秘密が秘密鍵であり、それぞれの第2の秘密シェアが秘密鍵のそれぞれの秘密鍵シェアである、ステートメント1から13のいずれかに記載の方法。
【0305】
ステートメント15.共有ブラインド秘密がブラインド秘密鍵であり、中間値が中間秘密鍵であり、
秘密鍵に対応する第1の公開鍵を生成するステップと、
ブラインド秘密鍵に対応する第2の公開鍵を生成するステップと、
中間秘密鍵に対応する第3の公開鍵を生成するステップと、
第1および第2の公開鍵に基づいて第1の値を生成するステップと、
第1の値が第3の公開鍵と一致するかどうかに基づいて、共有秘密の第2の秘密シェアが正しく生成されたことを検証するステップと
を備える、ステートメント14に記載の方法。
【0306】
ステートメント16.
第2の秘密シェアが正しく生成されなかったという決定に応答して、他のそれぞれの参加者のうちの1人、一部、または全員に対して、
その参加者のそれぞれの第1の秘密シェアに対応するそれぞれの第1の公開鍵を取得するステップと、
その参加者のそれぞれのブラインドシェアに対応するそれぞれの第2の公開鍵を取得するステップと、
その参加者のそれぞれの中間シェアに対応するそれぞれの第3の公開鍵を取得するステップと、
その参加者のそれぞれの第1および第2の公開鍵に基づいてそれぞれの第1の値を生成するステップと、
それぞれの第1の値がそれぞれの第3の公開鍵と一致するかどうかに基づいて、共有秘密のそれぞれの第2の秘密シェアがその参加者によって正しく生成されたことを検証するステップと
を実行するステップを備える、ステートメント15に記載の方法。
【0307】
ステートメント17.
メッセージを取得するステップと、
メッセージと、秘密鍵のそれぞれのシェアとに基づいて、デジタル署名シェアを生成するステップと
を備える、ステートメント14から16のいずれかに記載の方法。
【0308】
ステートメント18.
メッセージを取得するステップと、
第1のメッセージ非依存コンポーネントおよび第1のメッセージ依存コンポーネントを生成するステップであって、メッセージ非依存コンポーネントがそれぞれの秘密鍵シェアに基づいて生成され、メッセージ依存コンポーネントがメッセージに基づいて生成される、ステップと、
第1のメッセージ非依存コンポーネントをコーディネータにとって利用可能にするステップと、
少なくともしきい値数の署名シェアに基づいて署名を生成するために、第1の署名シェアをコーディネータにとって利用可能にするステップであって、第1の署名シェアが、少なくともメッセージ依存コンポーネントを備える、ステップと
を備える、ステートメント14から16のいずれかに記載の方法。
【0309】
ステートメント19.
1つまたは複数のメモリユニットを備えるメモリと、
1つまたは複数の処理ユニットを備える処理装置であって、メモリが、処理装置上で実行するように構成されたコードを記憶し、コードが、処理装置上にあるときに、ステートメント1から18のいずれかに記載の方法を実行するように構成される、処理装置と
を備える、コンピュータ機器。
【0310】
ステートメント20.コンピュータ可読ストレージに具現化され、コンピュータ機器上で実行されると、ステートメント1から18のいずれかに記載の方法を実行するように構成された、コンピュータプログラム。
【0311】
本明細書に開示される別の態様によれば、各参加者のアクションを備える方法が提供され得る。
【0312】
本明細書に開示される別の態様によれば、各参加者のコンピュータ機器を備えるシステムが提供され得る。
【0313】
開示された技法の他の変形または使用例は、本明細書の開示が与えられれば、当業者には明らかになるであろう。本開示の範囲は、記載された実施形態によって限定されるのではなく、添付の特許請求の範囲によってのみ限定される。
【符号の説明】
【0314】
100 システム
101 コーディネータ
102 当事者
102 参加者
102a 第1の参加者
102b 第2の参加者
102c 第3の参加者
103 第三者
200 方法
300 システム
400 方法
図1
図2
図3
図4
【国際調査報告】