(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-02-08
(54)【発明の名称】閾値鍵交換
(51)【国際特許分類】
H04L 9/08 20060101AFI20240201BHJP
H04L 9/32 20060101ALI20240201BHJP
【FI】
H04L9/08 A
H04L9/32 200Z
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023547478
(86)(22)【出願日】2022-01-05
(85)【翻訳文提出日】2023-10-03
(86)【国際出願番号】 EP2022050116
(87)【国際公開番号】W WO2022167163
(87)【国際公開日】2022-08-11
(32)【優先日】2021-02-05
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100108453
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】ミカエラ・ペティット
(57)【要約】
少なくとも1つの共有シークレットに基づいて共有暗号鍵を生成するコンピュータ実装方法であって、第1のグループに属する各々の参加者は、第1のシークレットのそれぞれのシェアを有し、第1のシークレットは、第1の閾値および対応する第1の公開鍵を有し、第2のコーディネータは、第2のシークレットに対応する第2の公開鍵を有し、第2のコーディネータは、同一の共有暗号鍵を生成するように構成される。
【特許請求の範囲】
【請求項1】
少なくとも1つの共有シークレットに基づいて、共有暗号鍵を生成するコンピュータ実装方法であって、第1のグループに属する各々の参加者は、第1のシークレットのそれぞれのシェアを有し、前記第1のシークレットは、第1の閾値および対応する第1の公開鍵を有し、第2のコーディネータは、第2のシークレットに対応する第2の公開鍵を有し、前記コンピュータ実装方法は、前記第1のグループの第1のコーディネータによって実行され、
前記第1のグループの少なくとも前記第1の閾値の数の参加者から、前記共有暗号鍵のそれぞれのシェアを取得するステップであって、前記共有暗号鍵の各々のそれぞれのシェアは、i)前記第1のシークレットの前記それぞれのシェアを計算するために使用されるそれぞれのプライベート多項式のそれぞれのゼロ次係数と、ii)前記第2の公開鍵と、に基づいている、ステップと、
前記暗号鍵の前記取得されたそれぞれのシェアに基づいて、前記共有暗号鍵を生成するステップであって、前記第2のコーディネータは、同一の共有暗号鍵を生成するように構成される、ステップと、
を含む、コンピュータ実装方法。
【請求項2】
前記コーディネータは、前記第1のグループに属する前記参加者の1人である、請求項1に記載のコンピュータ実装方法。
【請求項3】
前記第2の公開鍵を取得するステップと、
前記第1のグループの各々の参加者に前記第2の公開鍵を送信するステップと、
を含む、請求項1または請求項2に記載のコンピュータ実装方法。
【請求項4】
第2のコーディネータに前記第1の公開鍵を送信するステップを含む、請求項1から請求項3のいずれか一項に記載のコンピュータ実装方法。
【請求項5】
前記第1のグループの少なくとも前記第1の閾値の数の参加者から、前記第1の公開鍵のそれぞれのシェアを取得するステップを含み、前記第1の公開鍵の各々のそれぞれのシェアは、前記第1のシークレットの前記それぞれのシェアおよび公開鍵ジェネレータに基づいている、請求項4に記載のコンピュータ実装方法。
【請求項6】
前記第2の公開鍵を取得する前記ステップは、前記第2のコーディネータから前記第2の公開鍵を受信するステップを含む、請求項3、または請求項3の記載を引用する請求項4もしくは5に記載のコンピュータ実装方法。
【請求項7】
前記共有暗号鍵の前記それぞれのシェアは、前記第1のシークレットの前記それぞれのシェアを計算するために使用されるそれぞれのプライベート多項式の前記それぞれのゼロ次係数に基づいて生成され、
前記共有暗号鍵の前記それぞれのシェアを取得する前記ステップは、参加者の前記第1のグループの各々から前記共有暗号鍵のそれぞれのシェアを取得するステップを含み、
前記共有暗号鍵を生成する前記ステップは、前記共有暗号鍵の前記取得されたそれぞれのシェアの点加算を実行するステップを含む、請求項1から請求項6のいずれか一項に記載のコンピュータ実装方法。
【請求項8】
前記共有暗号鍵により第1のメッセージを暗号化するステップを含む、請求項1から請求項7のいずれか一項に記載のコンピュータ実装方法。
【請求項9】
前記第2のコーディネータに、および/または異なるパーティに、前記暗号化された第1のメッセージを送信するステップを含む、請求項8に記載のコンピュータ実装方法。
【請求項10】
ブロックチェーントランザクションを生成するステップであって、前記ブロックチェーントランザクションは、前記暗号化されたメッセージを含む、ステップと、
ブロックチェーンネットワークの1つ以上のノードに対して前記ブロックチェーントランザクションを利用可能にするステップと、
を含む、請求項8または請求項9に記載のコンピュータ実装方法。
【請求項11】
前記共有暗号鍵は、対称鍵であり、前記共有暗号鍵により第2のメッセージが暗号化されており、前記コンピュータ実装方法は、前記共有暗号鍵を使用して、前記第2のメッセージを復号するステップを含む、請求項1から請求項10のいずれか一項に記載のコンピュータ実装方法。
【請求項12】
前記共有暗号鍵に対応する秘密鍵を取得するステップと、
前記対応する秘密鍵を使用して、および/または前記対応する秘密鍵を使用して、デジタル署名を生成して、前記共有暗号鍵により暗号化された第3のメッセージを復号するステップと、
を含む、請求項1から請求項10のいずれか一項に記載のコンピュータ実装方法。
【請求項13】
第1のブロックチェーントランザクションは、前記共有暗号鍵にロックされる出力を含み、前記コンピュータ実装方法は、入力を有する第2のブロックチェーントランザクションを生成するステップであって、前記入力が、前記第1のブロックチェーントランザクションの前記出力を参照し、前記出力をアンロックするための前記デジタル署名を含む、ステップを含む、請求項12に記載のコンピュータ実装方法。
【請求項14】
前記共有暗号鍵に基づいて、1つ以上の追加の暗号鍵を生成するステップを含む、請求項1から請求項13のいずれか一項に記載のコンピュータ実装方法。
【請求項15】
前記1つ以上の追加の暗号鍵を生成する前記ステップは、前記共有暗号鍵にハッシュ関数を適用するステップを含む、請求項14に記載のコンピュータ実装方法。
【請求項16】
前記第2のシークレットは、共有シークレットであり、第2のグループは、複数の参加者を含み、前記第2のグループの各々の参加者は、第2のシークレットのそれぞれのシェアを有し、前記第2のシークレットは、第2の閾値を有する、請求項1から請求項15のいずれか一項に記載のコンピュータ実装方法。
【請求項17】
前記第2のグループの各々の参加者は、前記第2のシークレットの前記それぞれのシェアを計算するために使用されるそれぞれのプライベート多項式のそれぞれのゼロ次係数を有する、請求項16に記載のコンピュータ実装方法。
【請求項18】
コンピュータ機器であって、
1つまたは複数のメモリユニットを含むメモリと、
1つまたは複数の処理ユニットを含む処理装置と、
を備え、前記メモリは、前記処理装置上で動作するように構成されたコードを記憶し、前記コードは、前記処理装置において、請求項1から17のいずれか一項のコンピュータ実装方法を実行するように構成される、
コンピュータ機器。
【請求項19】
コンピュータ可読記憶装置上で具現化され、コンピュータ機器上で動作するときに、請求項1から17のいずれか一項のコンピュータ実装方法を実行するように構成されたコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、共有暗号鍵を生成する方法に関する。
【背景技術】
【0002】
公開鍵暗号法は、鍵のペア:秘密鍵の所有者のみに知られる秘密鍵と、対応する秘密鍵に基づいて生成され、秘密鍵のセキュリティを危うくすることなく普及され得る公開鍵と、を使用するタイプの暗号法システムである。
【0003】
公開鍵暗号法は、送信者が、受信者の公開鍵(すなわち、受信者のみに知られる秘密鍵に対応する公開鍵)を使用して、メッセージを暗号化することを有効にする。暗号化されたメッセージは次いで、受信者の秘密鍵を使用してのみ復号することができる。このタイプの暗号化は、非対称暗号化として知られる。
【0004】
非対称暗号化に対する代替は、対称暗号化である。ここで、メッセージ(いずれかのデータ)を暗号化することと復号することとの両方のために、1つの鍵(シークレット鍵)のみが使用される。対称暗号化を介して通信するエンティティは、復号工程においてそれを使用することができるように、鍵を交換しなければならない。
【0005】
公開鍵暗号法に話を戻すと、送信者は、メッセージに署名し、例えば、メッセージが同送信者によって送信されていることを証明し、および/または同送信者がメッセージに同意することを示すために、それら自身の秘密鍵を使用することができる。署名者(すなわち、署名を生成するパーティ)は、メッセージに対するデジタル署名を作成するために、それらの秘密鍵を使用する。署名者の対応する公開鍵を有する誰もが、署名が有効に作成されたかどうか、すなわち、署名が署名者の秘密鍵を使用して確かに行われたかどうかを検証するために、同一のメッセージおよびメッセージに対するデジタル署名を使用することができる。
【0006】
デジタル署名スキームは典型的には、3つの手順、すなわち、アルゴリズムを伴う。ランダムな秘密鍵および対応する公開鍵を生成するために、鍵生成アルゴリズムが使用される。メッセージおよび秘密鍵に基づいて署名を生成するために、署名アルゴリズムが使用される。公開鍵およびメッセージを仮定して、対応する秘密鍵を使用しておよび署名アルゴリズムに従って署名が生成されたかどうかを検証するために、検証アルゴリズムが使用される。
【0007】
閾値暗号法は、複数の参加者の間で秘密鍵のシェア(スライスと呼ばれる場合がある)を分散する暗号法システムを指す。秘密鍵を再作成するために、閾値(すなわち、最小)数のそれらのシェアが必要とされる。使用される特定のシステムに応じて、秘密鍵が最初に生成され得、次いでシェアに分割され得、または秘密鍵のシェアは、これまでに存在する秘密鍵なしで生成され得る。メッセージは、対応する公開鍵により暗号化され得る。閾値数の参加者が、メッセージを復号するために協調しなければならない。
【0008】
閾値署名スキームは、グループ内の閾値数の参加者が、共有秘密鍵の個々のシェアを使用して、メッセージに対する(すなわち、メッセージの)デジタル署名を作成することを可能にする。ここで、デジタル署名は、署名されることになるメッセージに基づいて生成される署名である。そのようなスキームでは、閾値数の参加者がメッセージに対する署名を生成することに同意する場合のみ、署名を作成することができる。より少ない人数の参加者を使用して署名を生成するいずれの試みも、有効な署名を生成しない。したがって、グループによる有効な署名(すなわち、メッセージおよび共有秘密鍵を使用して生成される1つ)は、閾値数の人が署名を生成することに同意させたことになる。これは、どんな対抗者であっても、その秘密鍵による署名を偽造するためには、閾値数の秘密鍵のシェアを取得することが必要であることも暗に示す。閾値署名シェアの共通の特徴は、秘密鍵シェアのいずれかが失われた場合、閾値数のシェアがなおも利用可能であることを条件に、秘密鍵がなおも復元可能であることができることである。
【0009】
Diffie-Hellman鍵交換は、共有暗号鍵を生成するプロトコルを指す。プロトコルは、以下のように要約することができる。第1のパーティおよび第2のパーティは各々、それぞれの秘密鍵-公開鍵ペアを有する。公開鍵は、各々のパーティに既知である。第1のパーティは、第1のパーティの秘密鍵および第2のパーティの公開鍵の楕円曲線乗算に基づいて、共有鍵を計算することができる。第2のパーティは、第2のパーティの秘密鍵および第1のパーティの公開鍵の楕円曲線乗算に基づいて、同一の共有鍵を計算することができる。これは、個人情報を漏洩することなく、両方のパーティが同一の共有鍵を計算することを可能にする。それらのみがそれらのそれぞれの秘密鍵を知ることを理由に、2つのパーティのみが共有鍵を計算することができる。
【先行技術文献】
【特許文献】
【0010】
【発明の概要】
【発明が解決しようとする課題】
【0011】
既存のDiffie-Hellman(DH)鍵交換方法による課題は、それが単一障害点を導入することである。すなわち、パーティの1人の秘密鍵が攻撃者によって危うくされる場合(、または誤って公開されてしまった場合であっても)、共有鍵を取得することができてしまうのである(これは、他のパーティの公開鍵が既知であることを想定してのことだが、大抵の場合はそうである)。したがって、共有鍵により暗号化されたいずれかのメッセージは、攻撃者によって復号することができる。メッセージがセンシティブなデータ、例えば、個人識別情報、財務データ、医療データなどを包含する場合、これは特に問題となる。
【課題を解決するための手段】
【0012】
したがって、DH鍵交換方法、またはシークレット(例えば、秘密鍵)に基づいた鍵の生成を伴う他の同様の方法のセキュリティを高めることが望ましい。
【0013】
本明細書で開示される1つの態様により、少なくとも1つの共有シークレットに基づいて、共有暗号鍵を生成するコンピュータ実装方法であって、第1のグループに属する各々の参加者は、第1のシークレットのそれぞれのシェアを有し、第1のシークレットは、第1の閾値および対応する第1の公開鍵を有し、第2のコーディネータは、第2のシークレットに対応する第2の公開鍵を有し、方法は、第1のグループの第1のコーディネータによって実行され、第1のグループの少なくとも第1の閾値数の参加者から、共有暗号鍵のそれぞれのシェアを取得するステップであって、共有暗号鍵の各々のそれぞれのシェアは、i)第1のシークレットのそれぞれのシェアまたは第1のシークレットのそれぞれのシェアを計算するために使用されるそれぞれのプライベート多項式のそれぞれのゼロ次係数と、ii)第2の公開鍵と、に基づいている、ステップと、暗号鍵の取得されたそれぞれのシェアに基づいて、共有暗号鍵を生成するステップであって、第2のコーディネータは、同一の共有暗号鍵を生成するように構成される、ステップと、を含む、方法がある。
【0014】
本発明の実施形態は、共有鍵(共有鍵が2つの異なるパーティに既知であるという意味で共有される)のセキュリティを高める。完全シークレット(例えば、秘密鍵)に基づいて共有鍵を生成する代わりに、共有鍵は代わりに、共有シークレット(例えば、共有秘密鍵)に基づいて生成される。共有シークレットは、グループの各々の参加者が共有シークレットのシェア(例えば、共有秘密鍵のシェア)を有するという意味で共有される。この共有シークレットは、2人の異なるパーティに既知でない。その上、共有シークレットは、個人がその鍵を知らないという意味で、シークレット全体(例えば、鍵)として存在し得ない。共有シークレットは、グループの共有シークレットからそれをより容易に区別するために、共有Diffie-Hellman(DH)鍵と以下では称される。しかしながら、これは、便利なラベルとして使用されるにすぎないことを認識されるべきである。共有シークレットは、共通シークレット、すなわち、1人よりも多いパーティに共通の(既知の)シークレットとも称され得る。秘密鍵のシェアは、秘密鍵が存在しないように生成され得ている。当業者は、そのような技術に精通している。したがって、単一のパーティは、共有シークレットへのアクセスを有しない。共有シークレットは、閾値を有し、共有シークレットを再構築するために、共有シークレットの少なくとも閾値数のシェアが必要とされることを意味する。
【0015】
本発明は、1つのパーティの(または、エンティティの)公開鍵および共有シークレットの少なくとも閾値数のシェアに基づいて、共有DH鍵を生成する。共有DH鍵の十分な異なるシェアが利用可能にされる場合、完全共有DH鍵を構築することができるだけである。ここで、共有シークレットが存在しない(すなわち、いずれかの1人の参加者によってそれが記憶されない)と仮定して、それを危うくすることができず、攻撃者が共有DH鍵を取得することをより困難にする。その上、攻撃者が共有シークレットの参加者のシェアを危うくするイベントにおいて、そのシェアは、共有シークレットも共有DH鍵も再構築しないために、十分な情報を手放さない。攻撃者は、閾値数のシェアを危うくする必要があり、単一の秘密鍵を危うくするよりもはるかに困難なタスクである。
【0016】
共有DH鍵のセキュリティを更に改善するために、両方のパーティは、共有シークレットを使用し得る。すなわち、参加者の1つのグループは、第1の共有シークレットのシェアを有し得、参加者の別のグループは、第2の共有シークレットのシェアを有し得る。各々のグループは、他のグループの公開鍵およびそれらの自身のグループの共有シークレットのシェアを使用して、共有DH鍵のそれぞれのシェアを生成する。
【0017】
いくつかの実施形態では、グループの各々の参加者およびあらゆる参加者は、そのグループが共有DH鍵を構築するために、共有DH鍵のシェアを計算することが必要とされ得る。それによって全ての参加者の協調が必要とされる使用ケースに対してこれは特に有用である。
【0018】
本開示の実施形態の理解を支援し、そのような実施形態をどのようにして具体化し得るかを示すために、例としてのみで添付図面に対する参照が行われる。
【図面の簡単な説明】
【0019】
【
図1】本発明のいくつかの実施形態に係る、共有鍵を生成する実施例のシステムを概略的に例示する。
【
図2】本発明のいくつかの実施形態に係る、共有鍵を生成する別の実施例のシステムを概略的に例示する。
【
図3】本発明のいくつかの実施形態に係る、共有鍵を生成する実施例の方法を示す。
【
図4】実施例のブロックチェーントランザクションプロトコルを概略的に例示する。
【発明を実施するための形態】
【0020】
暗号法準備
楕円曲線グループ
楕円曲線Eは、式:y
2=x
3+ax+b mod pを充足し、
【数1】
およびa,bは、4a
3+27b
2≠0を充足する定数である。この楕円曲線にわたるグループは、識別要素である、無限遠点
【数2】
と共にこの式を充足する要素の組(x,y)であると定義される。このグループ内の要素に対するグループ演算は、楕円曲線点加算と呼ばれ、+によって表記される。このグループは、
【数3】
によって表記され、その次数は、nによって表記される。
【0021】
・によって表記される点乗算と呼ばれる、要素に対する別の演算を定義するために、このグループ演算を使用することができる。点
【数4】
およびスカラ
【数5】
について、点k・Gは、k倍でそれ自体に加算された点Gであると定義される。
【0022】
楕円曲線暗号法では、秘密鍵が、スカラ
【数6】
であると定義され、
【数7】
は、組{1,…,n-1}についての表記であり、対応する公開鍵は、楕円曲線上の点k・Gである。例えば、いくつかのブロックチェーンプロトコルでは、楕円曲線は、secp256k1楕円曲線であるように選ばれ、値a,bおよびpは、この曲線によって完全に規定される。このグループの次数nは、この曲線のケースでは一次である、それらの値を仮定して計算されており、secp256k1標準も、このグループのジェネレータとして使用されることになる点Gを規定する。
【0023】
楕円曲線デジタル署名アルゴリズム
秘密鍵aによりメッセージ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.r=Rx mod nを計算する。r=0である場合、ステップ2に戻る。
5.一時的鍵の逆数乗算k-1 mod nを計算する。
6.s=k-1(e+ar) mod nを計算する。s=0である場合、ステップ2に戻る。
7.メッセージmsgに対する署名は、(r,s)である。
【0024】
一時的鍵は、シークレットに維持されなければならず、そうでなければ、メッセージおよび署名を仮定して、秘密鍵を計算できることになる。加えて、署名が生成される都度、異なる一時的鍵が使用されなければならない。これが当てはまらない場合、2つの異なる署名およびそれらの対応するメッセージを仮定して、秘密鍵aを導出することが可能である。
【0025】
メッセージmsg、公開鍵P=a・G、および対応する署名(r,s)を仮定して、以下のステップを完了させることによって、署名を検証することができる:
1.メッセージダイジェストe=hash(msg)、例えば、e=SHA256(SHA256(msg))を計算する。
2.sモジュロnの逆数乗算s
-1を計算する。
3.j
1=es
-1 mod nおよびj
2=rs
-1 mod nを計算する。
4.点Q=j
1・G+j
2・Pを計算する。
5.
【数8】
である場合、無限遠点、署名が無効である。
6.
【数9】
である場合、Q:=(Q
x,Q
y)とし、u=Q
x mod nを計算する。u=rである場合、署名が有効である。
【0026】
閾値署名スキームでは、この秘密鍵aは、閾値スキームグループ内の参加者の間で分散される鍵シェアに分割される。
【0027】
ジョイント検証可能ランダムシークレット共有
N人の参加者が、スキームへの少なくとも(t+1)人の参加者によってのみ再生成することができる、ジョイントシークレットを作成することを望むことを想定する。共有シークレットを作成するために、以下のステップが取られる:
1.参加者が、参加者ごとの一意なラベルiに同意する。各々の参加者iは、(t+1)ランダム数
【数10】
を生成し、∈
Rは、ランダムに生成された組の要素
【数11】
を意味し、
【数12】
は、組{1,…,n-1}についての表記である。次いで、i=1,…,Nについて、各々の参加者は、次数tのシークレット多項式f
i(x)=a
i0+a
i1x+…+a
itx
t mod n、を有する。ここからは、mod nの表記を省略することに留意されたく、整数にわたる全ての算術演算がモジュロnで行われることが想定される。
2.各々の参加者iが、例えば、参加者jとのセキュア通信チャネルのみを使用して、参加者jに値f
i(j)を送信する。
3.各々の参加者iが、
【数13】
として、共有シークレット多項式のそれら自身のプライベートシークレットシェアを計算する。
【0028】
共有シークレットシェアは、フォーム(i,ai)を有する点であり、iは、スキーム内の参加者ラベルである。ステップ1~3において説明されたように、aのシークレットシェアを作成するこの方法は、参加者iについてai=JVRSS(i)によって本明細書で表される。「JVRSS」は典型的には、「ジョイント検証ランダムシークレット共有(Joint verification random secret sharing)」を支持し、ステップ4および5をも含むことに留意されよう。しかしながら、本明細書の全体を通じて、JVRSSは、少なくともステップ1~3を実行することを意味すると見なされ、ステップ4および5は、任意選択のステップである。
【0029】
ここで、参加者は、共有多項式を生成しており、それらは各々、他の参加者が全ての参加者に対する正確な情報を共有しており、全ての参加者が同一の共有多項式を有することを検証することができる。これは、以下のように行われる。
4.各々の参加者iが、全ての参加者に、k=0,…,tについて、難読化係数a
ik・Gを報知する。
5.各々の参加者iが、各々の参加者jが、f
j(i)・Gを計算し、
【数14】
を検証することによって、多項式点f
j(i)を正確に計算したことをチェックする。
【0030】
全ての参加者が、この式が多項式ごとに保持されることを発見する場合、グループは集合的に、それらが全て同一の共有多項式を作成したことを確信することができる。
【0031】
共有シークレットの再構築
参加者が、共有多項式のゼロ次数である、共有シークレットaを再構築することを望むことを想定する。共有シークレットaを発見するために、フォーム(1,a
1),…,((t+1),a
t+1)のこの多項式上の(t+1)点を仮定して、「ラグランジュ補間」として知られる全体式から導出される、
【数15】
を計算する。
【0032】
公開鍵計算
JVRSSのステップ4において共有されるi = 1,…,NについてのNゼロ次数プライベート多項式係数公開鍵a
i0・Gを仮定して、各々の参加者は、共有シークレットaに対応する
【数16】
を使用して、共有公開鍵Pを計算する。
【0033】
共有シークレットの加算
N人の参加者のグループの中で共有される2つの共有シークレットの加算を計算するために、いずれのエンティティも個々のシークレットを知ることなく、各々のシークレット多項式が、次数tを有する場合、以下のステップが取られる:
1.第1の共有シークレットaを生成し、参加者iのシェアは、(t+1)の閾値によりi=1,…,Nについて、ai=JVRSS(i)によって与えられる。
2.第2の共有シークレットbを生成し、参加者iのシェアは、(t+1)の閾値によりbi=JVRSS(i)によって与えられる。
3.各々の参加者iが、それら自身の加算シェア(additive share)vi = ai + bi mod nを計算する。
4.全ての参加者が、全ての他の参加者にそれらの加算シェアviを報知する。
5.各々の参加者が、シェアviの少なくとも(t+1)にわたって補間して、v=interpolate(v1,…,vt+1)=a+bを計算する。
【0034】
共有シークレットの加算のためのこの方法は、各々の参加者iがv=(a+b)を知ることを結果としてもたらす、参加者iについてADDSS(i)によって表記される。
【0035】
共有シークレットの積
N人の参加者のグループの中でその両方が共有される2つの共有シークレットの積を計算するために、各々のシークレット多項式が、次数tを有する場合、グループは、以下のステップを取る:
1.第1の共有シークレットaを生成し、参加者iのシェアは、i=1,…,Nについて、ai=JVRSS(i)によって与えられる。共有シークレット多項式は、次数tを有し、それを再作成するために(t+1)人の参加者が必要とされることを意味する。
2.第2の共有シークレットbを生成し、参加者iのシェアは、bi=JVRSS(i)によって与えられ、共有シークレット多項式は、再度次数tを有する。
3.各々の参加者が、μi=aibiを使用して、それらの乗算シェアμiを計算する。
4.全ての参加者が、全ての他の参加者にそれらの乗算シェアμiを報知する。
5.各々の参加者が、0におけるシェアμiの少なくとも(2t+1)にわたって補間して、μ=interpolate(μ1,…,μ2t+1)=abを計算する。
【0036】
2つの共有シークレットの積を計算するこの方法は、参加者iについてμ=ab=PROSS(i)によって本明細書で表記される。
【0037】
共有シークレットの逆数
共有シークレットaの逆数を計算するために、以下のステップが取られる:
1.全ての参加者が、共有シークレットPROSS(i)の積を計算し、その結果は、μ=ab mod nである。
2.各々の参加者が、μのモジュラ逆数を計算し、それは、μ
-1=(ab)
-1 mod nを結果としてもたらす。
3.各々の参加者iが、
【数17】
を計算することによって、それら自身の逆数シークレットシェアを計算する。
【0038】
共有シークレットの逆数を計算するこの方法は、参加者iについて
【数18】
によって表記される。
【0039】
共有秘密鍵生成および検証
署名を作成するためにそのt+1人が必要とされる、N>=2t+1人の参加者の間で共有秘密鍵aを計算するために、参加者は、t+1の閾値によるJVRSSおよび上記説明されたような公開鍵計算を実行する。結果は、あらゆる参加者i=1,…,Nが、秘密鍵シェアaiおよび対応する共有公開鍵P=(a・G)を有することである。
【0040】
一時的鍵シェア生成
署名において必要とされるように、一時的鍵シェアおよび対応するrを生成するために、閾値(t+1)の共有秘密鍵aを有するサイズNのグループは、以下のステップを実行する:
1.共有シークレット
【数19】
の逆数シェアを生成し、(t+1)個のシェアは、それを再作成するために必要とされる。
2.各々の参加者が、k
iの検証において共有される難読化係数を使用して、
【数20】
を計算し、次いで、それらが、r=x mod nを計算する。
3.各々の参加者iが、
【数21】
を記憶する。
【0041】
共有鍵の生成
本発明の実施形態は、2つのパーティが、共有暗号鍵を生成することを有効にし、それらのパーティのうちの少なくとも1人は、参加者のグループ(例えば、ユーザまたはマシン)を含む。
図1は、共有鍵を生成する実施例のシステム100を例示する。示されるように、システム100は、第1のコーディネータ101および参加者102の第1のグループを含む第1のパーティを含む。
図1では3人の参加者102のみが示されるが、全体的に、第1のグループは、いずれかの数の参加者を含み得ることを認識されよう。更に、
図1では、参加者102とは別個である第1のコーディネータ101が示されるが、いくつかの実施形態では、第1のコーディネータ101も、参加者102、例えば、第1の参加者102aの1人でもあり得る。
図1にも示されるのは、第2のコーディネータ103を含む第2のパーティである。
【0042】
図2に示されるように、いくつかの実施形態では、第2のパーティも、参加者104の第2のグループを含み得る。参加者の第1のグループの場合のように、第2のグループは概して、いずれかの数の参加者104を含み得る。
【0043】
第1のコーディネータ101、第2のコーディネータ103、参加者の第1のグループの各々、および参加者の第2のグループの各々は、それぞれのコンピューティング機器を動作させる。それぞれのコンピューティング機器の各々は、1つ以上のプロセッサ、例えば、1つ以上の中央処理ユニット(CPU)、アクセラレータプロセッサ(GPU)、特定用途プロセッサ、および/またはフィールドプログラマブルゲートアレイ(FPGA)を含む、それぞれの処理装置を含む。それぞれのコンピューティング機器はまた、メモリ、すなわち、非一時的コンピュータ可読媒体(複数可)の形式にあるコンピュータ可読記憶装置を含み得る。メモリは、1つ以上のメモリ媒体、例えば、ハードディスクなどの磁気媒体;ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体;および/または光学ディスクドライブなどの光学媒体、を採用した1つ以上のメモリユニットを含み得る。それぞれのコンピューティング機器は、少なくとも1つのユーザ端末、例えば、デスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを含み得る。代わりにまたは加えて、それぞれのコンピューティング機器は、ユーザ端末を介してアクセスされる1つ以上のクラウドコンピューティングリソース(1つ以上のサイトにおいて実装された1つ以上の物理サーバデバイスのリソースを含むクラウドコンピューティングリソース)など、1つ以上の他のネットワーク化リソースを含み得る。パーティ(例えば、コーディネータ、参加者など)によって実行されるとして説明されるいずれかの行為は、そのパーティによって動作されるそれぞれのコンピューティング装置によって実行され得ることを認識されよう。
【0044】
図1を再度参照して、第1のコーディネータ101(参加者の第1のグループの代わりに)および第2のコーディネータ103は、共有鍵を生成することを望む。この鍵は、共有Diffie-Hellman(DH)鍵と称される。このラベルは、便宜のために使用されるにすぎず、本説明によって課されるもの以外の鍵に対していずれの限定も置かない。
【0045】
図1の実施形態では、第2のコーディネータ103は、秘密鍵に対応する公開鍵を有する。鍵を「有する」ことは、その鍵をメモリに記憶すること、またはそうでなければ、その鍵にアクセスし、およびその鍵を取り出すことが可能であることを意味する。例えば、鍵は、紙に書き出され得、次いで、例えば、ユーザインタフェースを介してデバイスに入力され得る。この実施形態では、秘密鍵は、完全な(すなわち、全部、全体など)鍵である。秘密鍵は、ジェネレータポイントを経由して、対応する公開鍵に直接マッピングする場合、完全鍵であると言われ得る。
【0046】
第1のグループの各々の参加者102は、秘密鍵のシェア(「秘密鍵シェア」)を有する。この秘密鍵は、第1の秘密鍵と称される。第2のコーディネータ103と関連付けられた秘密鍵は、第2の秘密鍵と称される。第1の秘密鍵および第2の秘密鍵は、異なる鍵(例えば、異なる整数)である。いくつかの実施例では、第1のコーディネータ101も、第1の秘密鍵のシェアを有する。
【0047】
第1の秘密鍵は、閾値秘密鍵である。これは、第1の秘密鍵を再構築するために、少なくとも閾値数の第1の秘密鍵シェアが必要とされることを意味する。閾値秘密鍵のシェアを生成する技術自体は、当業者に精通されている。1つのそのような技術は、ジョイント検証可能ランダムシークレット共有(JVRSS)として既知であり、上記説明されている。参加者の第1のグループは各々、第1の秘密鍵のそれらのそれぞれのシェアを生成するために、JVRSSを使用し得る。別の技術は、Shamirのシークレット共有スキーム(SSSS:Shamir's secret sharing scheme)として既知である。参加者の第1のグループは各々、第1の秘密鍵のそれらのそれぞれのシェアを取得するために、SSSSを使用し得る。SSSSがコーディネータ101を必要とするのに対し、JVRSSはそうではないことに留意されよう。秘密鍵シェアを生成および分散する別の技術は、WO2017145010A1において説明されている。
【0048】
第1の秘密鍵は、対応する公開鍵-第1の公開鍵を有する。第1の公開鍵は、第1のコーディネータ101および/または参加者102の1人、数人、または全てに既知であり得る。
【0049】
実施形態では、第1のコーディネータ101は、第2の秘密鍵に対応する公開鍵(第2の公開鍵)を取得し得る。例えば、第2のコーディネータ103は、第1のコーディネータ101に第2の公開鍵を送信し得る。代わりに、第2の公開鍵は、ウェブサイトまたはブロックチェーンなどの公にアクセス可能なソースから取得され得る。代わりに、第1のコーディネータ101は、第2の公開鍵へのアクセスを既に有し得、例えば、それはメモリに記憶され得る。
【0050】
第1のコーディネータ101は、第1のグループの参加者102の数人または全てに第2の公開鍵を送信し得る。第1のコーディネータ101は、各々の参加者102に別々に第2の公開鍵を送信し得、または第1のコーディネータ101は、第1のグループに第2の公開鍵を報知し得る。また、参加者102の数人または全ては、第2の公開鍵へのアクセスを既に有し得、そのケースでは、第1のコーディネータ101がそれらの参加者102に第2の公開鍵を送信する必要がないが、第1のコーディネータ101がなおもそれを行うことを選び得ることが排除されない。
【0051】
第1のコーディネータ101は、共有DH鍵の少なくとも閾値数のそれぞれのシェアを取得する。例えば、第1のコーディネータ101は、共有DH鍵のそれぞれのシェアのための要求を参加者102に送信(報知)し得る。
図1に示されるように、いくつかの実施形態では、共有DH鍵のシェアを生成するために、参加者の全てが必要とされるわけではない。これは、第1の秘密鍵の閾値に依存する。共有DH鍵の各々のシェアは、第1の秘密鍵の異なるそれぞれのシェアに基づいて生成され(すなわち、その関数である)、すなわち、共有DH鍵の各々のシェアは、異なる参加者102によって生成される。共有DH鍵の各々のシェアはまた、第2の公開鍵に基づいて生成される。各々の参加者が、第2の公開鍵を既に有するか、またはそれが第1のコーディネータ101から取得され得るかのいずれかであることが上記から思い出されよう。いくつかの実施例では、シェアの1つは、第1のコーディネータ101によって生成される。
【0052】
共有DH鍵の各々のシェアは、それぞれの第1の秘密鍵シェアおよび第2の公開鍵の楕円曲線乗算を実行することによって生成され得る。共有DH鍵のシェアは、代替的な数学演算を使用して計算されることが排除されない。
【0053】
共有DH鍵のシェアを生成する参加者102の各々は、第1のコーディネータ101に直接、または1つ以上の他の参加者を介して、それらのシェアを送信し得る。シェアは、セキュア通信チャネルにわたって送信され得る。
【0054】
共有DH鍵の必要とされる数の異なるシェアを取得して、第1のコーディネータ101は、完全共有DH鍵を生成する。共有DH鍵は、取得されたシェアの関数である。例えば、共有DH鍵は、共有DH鍵のシェアの楕円曲線補間を実行することによって取得され得る。
【0055】
第2のコーディネータ103は、同一の共有DH鍵を生成するように構成される。いくつかの実施形態では、第2のコーディネータ103は、第1の公開鍵および第2の秘密鍵に基づいて、共有DH鍵を生成する。このケースでは、第2のコーディネータは、全部の、すなわち、単に第2の秘密鍵のシェアではない、第2の秘密鍵へのアクセスを有する。第2のコーディネータ101は、第1の公開鍵へのアクセスを既に有し得、例えば、それは、ブロックチェーンなどの公にアクセス可能なソースから取得され得る。代わりに、第1のコーディネータ101は、第2のコーディネータ103に第1の公開鍵を送信し得る。いくつかの実施例では、各々の参加者102は、第1の秘密鍵のそれらのそれぞれのシェアに対応する第1の公開鍵のシェアを有し得る。第1のコーディネータ101は、第2のコーディネータ103にそれを送信する前に、第1の公開鍵を生成するために、第1の公開鍵の閾値数のシェアを必要とし得る。
【0056】
上記言及されたように、第1の秘密鍵シェアは、JVRSSまたは同等のスキームを使用して生成され得る。それらの実施形態では、第1のグループの各々の参加者は、プライベート多項式のそれぞれのゼロ次係数を有する(上記説明されたJVRSS方法のステップ1を参照されよう)。ここで、第1の秘密鍵のそれらのそれぞれのシェアに基づいて、共有DH鍵のそれらのそれぞれのシェアを計算する代わりに、各々の参加者は、それらのそれぞれのゼロ次係数に基づいて、それらのそれぞれのシェアを生成する。共有DH鍵の各々のシェアも、第2の公開鍵に基づいている。それらの実施例では、共有DH鍵のそれぞれのシェアは、各々の参加者102から取得されなければならない。
【0057】
図2を参照して、第2の秘密鍵は、閾値秘密鍵であり得、第2のグループの各々の参加者104は、第2の秘密鍵のシェアを有し得る。それらの実施形態では、第2のコーディネータ103は、第2のグループの参加者104によって生成された共有DH鍵のそれぞれのシェアに基づいて、共有DH鍵を生成するために、第1のコーディネータに対して同等の演算を実行し得る。例えば、第2のグループの参加者は、第1の公開鍵と、第2の秘密鍵のそれらのそれぞれのシェアまたはそれらのそれぞれのプライベート多項式のそれらのそれぞれのゼロ次係数のいずれかとに基づいて、共有DH鍵のシェアを生成し得る。
【0058】
第2のコーディネータ103によって選ばれた方法に関わらず、第1のコーディネータ101および第2のコーディネータ103の両方は、同一の共有DH鍵を有する。共有DH鍵は次いで、メッセージ、すなわち、いずれかのタイプのデータを暗号化するために使用され得る。例えば、第1のコーディネータ101は、メッセージを暗号化し得、第2のコーディネータ103に暗号化されたメッセージを送信し得、または逆もまたそうである。メッセージは、個人および/または機密情報、例えば、財務データ、医療データ、処方箋データなどを含み得る。メッセージは、契約または他のタイプのドキュメントを含み得る。
【0059】
共有DH鍵は、対称暗号鍵として使用され得、そのケースでは、それは、メッセージを暗号化することおよび復号することの両方に使用され得る。いずれかの適切な対称暗号化スキーム、例えば、データ暗号化標準(DES)、トリプルDES、Blowfish、アドバンスト暗号化標準(AES)、Rivest Cipher 4(RC4)、RC5、またはRC6が使用され得る。例えば、第1のコーディネータ101は、共有DH鍵により暗号化された、暗号化されたメッセージを第2のコーディネータ103から受信し得る。第1のコーディネータ101は次いで、メッセージを復号する(すなわち、プレーンテキストメッセージを取得するために暗号文を復号する)ために、共有DH鍵を使用し得る。
【0060】
いくつかの実施例では、共有DH鍵は、非対称鍵、例えば、公開鍵として使用され得る。このケースでは、メッセージは、共有DH鍵により暗号化され得、その結果、対応する秘密鍵によりのみそれを復号することができる。第1のコーディネータ101も第2のコーディネータ103も、対応する秘密鍵を算出するために十分な情報を有しない。
【0061】
それを行うために、第1のコーディネータ101および第2のコーディネータ103は、閾値算出(例えば、秘密鍵シェアにわたる補間)を実行して、共有DH鍵に対応する秘密鍵を算出し得る。
【0062】
いくつかの実施例では、共有DH鍵に対応する秘密鍵を取得して、第1のコーディネータ101は、署名されることになるメッセージおよび秘密鍵に基づいて、デジタル署名を生成し得る。第2のコーディネータ103も、秘密鍵を使用して、デジタル署名を生成し得る。いくつかの実施例では、共有DH鍵にロックされた出力を含むブロックチェーントランザクションが作成され得る(例えば、第1のコーディネータ101または第2のコーディネータによって)。第1のコーディネータ101または第2のコーディネータ102は、ブロックチェーントランザクションを生成することによって出力をアンロックし得、ブロックチェーントランザクションは、前のブロックチェーントランザクションの出力を参照する入力を含み、秘密鍵を使用して生成されたデジタル署名と、トランザクションの少なくとも一部を含むメッセージと、を含む。
【0063】
第1のコーディネータ101は、共有DH鍵に基づいて、1つ以上の追加の暗号鍵を生成し得る。例えば、共有DH鍵は、ハッシュ関数(例えば、SHA256、SHA512など)に入力され得る。ハッシュダイジェストが追加の暗号鍵として使用され得る。共有DH鍵は、複数の追加の暗号鍵を生成するために複数回ハッシュされ得る。追加の暗号鍵は、代替的な方式において生成され得る。例えば、共有DH鍵は、点加算を使用して、異なる鍵(例えば、異なる公開鍵)と結合され得る。第2のコーディネータ103は、第1のコーディネータと同一の演算(複数可)を実行して、同一の追加の暗号鍵を生成することができる。これは、例えば、鍵の再使用を防止するために、多くの鍵が同一の共有DH鍵から生成されることを可能にする。
【0064】
図3は、共有DH鍵を生成する実施例の方法300を示す。ステップのいくつかは、任意選択であることを認識されよう。ステップS301において、第1のコーディネータ101は、例えば、第2のコーディネータ103から第2の公開鍵を取得する。ステップS302において、第1のコーディネータは、共有DH鍵(共通シークレット)のシェアを要求する要求を、第1のグループの参加者102に送信する。ステップS303において、第1のコーディネータ101は、少なくとも閾値数の共有DH鍵シェアを取得する。ステップS304において、第1のコーディネータ101は、共有DH鍵を算出する。共有DH鍵は次いで、とりわけ、メッセージを暗号化するために使用され得る。
【0065】
以下は、説明される実施形態の更なる実施例を提供する。以下の実施例では、Bobは、第1のコーディネータ101と同等であり、Aliceは、第2のコーディネータ103と同等である。
【0066】
その鍵のうちの少なくとも1つが、N人の参加者のグループの間の共有シークレットである、共有DH鍵を計算するために、以下のステップが取られ得る。Aliceが、Bobの閾値グループによりシークレットチャネルを作成することを望むことを想定する。すなわち、Bobのグループは、N人の参加者を有し、その各々は、秘密鍵bのシェアbiを有し、それらの(t+1)人が秘密鍵を計算するために協働することが必要であることを想定する。AliceおよびBobのグループの対応する公開鍵は、公開されると想定される。
【0067】
グループの(t+1)が協働することを必要とする共有DH鍵を計算するために、以下のステップが取られ得る。
1.Alice103が、Bobのグループの公開鍵b・Gを受信し、点乗算を使用して、a(b・G)を計算する。
2.BobのグループのコーディネータBob101が、a・Gを使用して、共有DH鍵の少なくとも(t+1)個のシェアを要求する。
3.Bobのグループ内の少なくとも(t+1)人の参加者が、Aliceの公開鍵を使用して、bi(a・G)を計算する。
4.(t+1)人の参加者が、セキュア通信チャネルを使用して、Bob101にそれらのシェアを送信する。
5.Bob101が、b(a・G)=ECinterpolate(b1(a・G),…,bt+1(a・G))を使用して、共有DH鍵を計算し、ECinterpolateは、自然数にわたる通常の加算の代わりに、点加算を使用するが、標準補間のための式と同一である。
【0068】
ここで、Alice103およびBobのグループの両方は、それらがメッセージを暗号化するために使用することができる共有鍵ab・Gを有する。共有鍵は、対称または非対称暗号化のために使用され得る。後者のために使用される場合、対応する秘密鍵abは、閾値算出を使用して計算され得る。
【0069】
Aliceの秘密鍵が共有シークレットでもある場合、Aliceのグループも、ステップ2~5にあるのと同一のステップを実行する。
【0070】
楕円曲線補間を回避する、共有DH鍵を計算する別の方式も存在するが、各々の参加者が貢献しなければならない。参加者は、以下のステップを取り得る。
1.Alice103が、Bobのグループの公開鍵b・Gを受信し、a(b・G)を計算する。
2.BobのグループのコーディネータBob101が、a・Gを使用して、DH鍵のシェアを計算することを全てのN人の参加者に要求する。
3.Bobのグループ内のN人の参加者が、Aliceの公開鍵を使用して、b
i0(a・G)を計算し、b
i0は、参加者iのプライベート多項式のゼロ次数である。
4.N人の参加者が、セキュア通信チャネルを使用して、Bob101にそれらのシェアを送信し、またはスキーム参加者のみに報知する。
5.Bob101が、
【数22】
を使用して、共有DH鍵を計算する。
【0071】
この式では、総和は、点加算である。
【0072】
Alice101が閾値スキームの一部でもある場合、Aliceのグループも、ステップ2~5を実行する。
【0073】
両方のスキームのステップ4では、参加者は好ましくは、Bob101とのセキュア通信チャネルを介して、それらのシェアを送信するはずである。それらがパブリックネットワーク上でそれらのシェアを送信し、それらが取得される場合、誰もが共有DH鍵を計算することが可能であり得る。これは、共有DH鍵がAlice103とBobのグループとの間の共有シークレットであるはずであることと矛盾する。
【0074】
2つの方法が組み合わされ得る。例えば、Bobのグループは、第1の方法を使用して、共有DH鍵を計算し得る一方で、Aliceのグループは、第2の方法を使用して、共有DH鍵を計算し、または逆もそうである。第1の方法は、第2の方法よりもわずかに遅いが、損失した場合に、共有DH鍵が復元されることを可能にする。逆に、第2の方法は、第1の方法よりも速いが、Bobのグループの参加者がそれらの共有秘密鍵のそれらのそれぞれのシェアを損失する場合、共有DH鍵が復元可能でない。もちろん、共有DH鍵はなおも、Aliceによって計算され得る。使用ケースが全ての参加者により貢献から利点を得る場合、第2の方法が望ましい。
【0075】
実施例の使用ケース
本発明の実施形態は、様々な使用ケースのために、特に、秘密鍵と関連付けられた単一障害点を取り除くことが望ましい1つの使用ケースのために使用され得る。例えば、全部の秘密鍵が損失する場合、秘密鍵に基づいて生成された共有鍵が復元可能でない。更に、共有鍵が全部の秘密鍵に基づいて生成され、その秘密鍵が盗まれ、またはそうでなければ危うくされる場合、共有鍵により暗号化されたいずれかのメッセージが復号可能であり得る(共有鍵がどのように生成されるかに応じて)。本発明の実施形態はまた、メッセージが容易に復号可能でないように、メッセージの高まったセキュリティが重要である場合に特に有利である。例えば、患者の医療履歴、安全、およびセキュアなどのセンシティブなデータを維持することが重要である。
【0076】
共有DH鍵は、患者の医療データを暗号化および共有するために使用され得る。例えば、患者は、第3のパーティサービスプロバイダまたはデータ会社と、患者の医療データを共有することを選び得る。例えば、患者は、データ分析会社に患者のデータを販売し得る。この実施例では、患者(第2のコーディネータ103と同等の)は、秘密鍵-公開鍵ペアを有し得る。サービスプロバイダ、患者、および患者の医者(参加者102の第1のグループと同等であると共に、サービスプロバイダも第1のコーディネータ101である)は各々、共有秘密鍵のシェアを有し得る。共有DH鍵を構築するために、この実施例における3つのパーティの少なくとも2人が必要とされる。患者およびサービスプロバイダは、共有DH鍵を構築するために、本発明の実施形態を使用する。患者および/または患者の医者が、サービスプロバイダに共有DH鍵のシェアを提供する場合、サービスプロバイダは、同一の共有DH鍵を構築することが可能であるだけである。患者は次いで、共有DH鍵により患者の医療データを暗号化し得、サービスプロバイダに暗号化されたデータを送信し得る。サービスプロバイダは次いで、患者の医療データを復号し、患者の医療データへのアクセスを得るために、共有DH鍵を使用し得る。
【0077】
別の実施例として、共有DH鍵は、例えば、ストリーミングサービスの一部として、メディアコンテンツを共有するために使用され得る。例えば、コンテンツプロバイダ(第2のコーディネータ103)は、ユーザに動画をストリーミングすることを望み得る。コンテンツプロバイダは、秘密鍵-公開鍵ペアを有する。コンテンツプロバイダおよびユーザは、共有秘密鍵のシェアを有する。この実施例では、ユーザは、第1のコーディネータ101と同等である。コンテンツプロバイダは、その秘密鍵および共有秘密鍵に対応する公開鍵を使用して、共有DH鍵を生成する。コンテンツプロバイダは、動画の一部または全てを暗号化し、ユーザに暗号化されたデータを送信する。ユーザは、秘密鍵のユーザのシェアおよびコンテンツプロバイダの公開鍵を使用して、共有DH鍵のシェアを生成し得る。この実施例では、共有DH鍵を生成することに参加するために、秘密鍵シェアの全ての所有者が必要とされる。したがって、コンテンツプロバイダも共有DH鍵のシェアを提供する場合、ユーザは、全部の共有DH鍵を生成することが可能であるだけである。コンテンツプロバイダは、ユーザから支払いの見返りに、共有DH鍵のシェアを提供することを選び得る。
【0078】
概して、いずれかのメッセージを暗号化するために、本発明を使用することができる。特定の実施例の使用ケースとして、メッセージは、ブロックチェーントランザクションの一部または全てであり得る。加えてまたは代わりに、暗号化されたメッセージは、ブロックチェーントランザクションに含まれ得る。
【0079】
閾値署名スキームが上記で簡潔に議論されてきた。そのようなスキームにより、共有シークレットの暗号化されたシェア、すなわち、閾値署名のシェアを生成するために使用される秘密鍵のシェアを記憶するために、本発明の実施形態が使用され得る。次いで、共有シークレットのシェアが失われる場合、それらのシェアを失った参加者のためのシェアを復号することに同意する閾値数の参加者により、シェアを復元することができる。
【0080】
図4は、ブロックチェーンプロトコルの一部として使用するための実施例のトランザクションプロトコルを例示する。実施例のブロックチェーンプロトコルは、文献において良好に文書化されているが、完全性のために、実施例のプロトコルトランザクションの説明がここで提供される。これは、UTXOに基づくプロトコルの実施例である。トランザクション152(「Tx」と短縮化される)は、ブロックチェーンの基本的なデータ構造である(ブロックチェーンの各々のブロックは、1つ以上のトランザクション152を含む)。出力に基づくプロトコルまたは「UTXO」に基づくプロトコルへの参照によって、以下が説明される。しかしながら、これは、全ての可能な実施形態を限定しない。
【0081】
UTXOに基づくモデルでは、各々のトランザクション(「Tx」)152は、1つ以上の入力202および1つ以上の出力203を含むデータ構造を含む。各々の出力203は、未使用トランザクション出力(UTXO:unspent transaction output)を含み得、UTXOは、別の新たなトランザクションの入力202のためのソースとして使用することができる(UTXOがまだ償還されていない場合)。UTXOは、デジタルトークンの量を指定する値、例えば、デジタルアセットの量を表す値を含む。これは、(分散)台帳上のトークンの設定された数を表す。UTXOはまた、他の情報の中で、それから由来したトランザクションのトランザクションIDを包含し得る。トランザクションデータ構造も、ヘッダ201を含み得、ヘッダ201は、入力フィールド(複数可)202および出力フィールド(複数可)203のサイズのインジケータを含み得る。ヘッダ201はまた、トランザクションのIDを含み得る。実施形態では、トランザクションIDは、トランザクションデータ(トランザクションID自体を排除する)のハッシュであり、マイナにサブミットされる未処理トランザクション152のヘッダ201に記憶される。
【0082】
例えば、第1のユーザ、例えば、Aliceは、第2のユーザ、例えば、Bobへ問題のデジタルトークンの量を伝達するトランザクション152jを作成することを望む。
図4では、Aliceの新たなトランザクション152jは、「Tx
1」とラベル付けされる。それは、シーケンス内の先行するトランザクション152iの出力203内でAliceにロックされる或る量のデジタルトークンを要し、Bobにこの少なくとも一部を伝達する。先行するトランザクション152iは、
図4では「Tx
0」とラベル付けされる。Tx
0およびTx
1は、任意のラベルにすぎない。それらは、Tx
0がブロックチェーン内の第1のトランザクションであることを必ずしも意味せず、Tx
1がプール内の中間の次のトランザクションであることも意味しない。Tx
1は、Aliceにロックされる未使用出力203をなおも有するいずれかの先行する(すなわち、先の)トランザクションを再度指し示し得る。
【0083】
AliceがAliceの新たなトランザクションTx1を作成する時に、または、少なくともAliceがネットワーク106にそれを送信する時まで、先行するトランザクションTx0は、既に検証され得、ブロックチェーンに含まれ得る。それは、その時にブロックの1つに既に含まれ得、またはそれはなおも、プール154内で待ち得、そのケースでは、それは、新たなブロックにすぐに含まれる。代わりに、ノードプロトコルが「オーファン」トランザクションをバッファすることを可能にする場合、Tx0およびTx1は共に、作成され、ブロックチェーンネットワークに送信され得、またはTx0は更には、Tx1の後に送信され得る。トランザクションのシーケンスのコンテキストにおいて本明細書で使用されるような用語「先行する」および「後続の」は、トランザクション内で規定されたトランザクションポインタによって定義されるような(どのトランザクションがどの他のトランザクションを再度指し示すかなど)、シーケンス内のトランザクションの順序を指す。それらは、「プレデセッサ」および「サクセサ」、または「アンティセデント」および「ディセンデント」、「ペアレント」および「チャイルド」、または同様のものと等しく置き換えられ得る。それは、それらが作成され、ネットワークに送信され、またはいずれかの所与のノードに到達する順序を必ずしも暗に意味しない。それにも関わらず、先行するトランザクション(アンティセデントトランザクションまたは「ペアレント」)を指し示す後続のトランザクション(ディセンデントトランザクションまたは「チャイルド」)は、ペアレントトランザクションが検証されるまで、およびペアレントトランザクションが検証されない限り検証されない。そのペアレントの前にノードに到達するチャイルドは、オーファンと考えられる。それは、ノードプロトコルおよび/またはマイナの振る舞いに応じて、ペアレントを待つ特定の時間の間に破棄またはバッファされ得る。
【0084】
先行するトランザクションTx0の1つ以上の出力203の1つは、ここでUTXO0とラベル付けられた、特定のUTXOを含む。各々のUTXOは、UTXOによって表されるデジタルトークンの量を規定した値と、後続のトランザクションが検証され、したがって、UTXOが成功して償還されるために、後続のトランザクションの入力202内のアンロッキングスクリプトによって満たされなければならない条件を定義するロッキングスクリプトと、を含む。典型的には、ロッキングスクリプトは、特定のパーティ(それが含まれるトランザクションの受益者)への量をロックする。つまり、ロッキングスクリプトは、典型的には、後続のトランザクションの入力内のアンロッキングスクリプトが、先行するトランザクションがロックされるパーティの暗号署名を含むという条件を含む、アンロッキング条件を定義する。
【0085】
ロッキングスクリプト(aka scriptPubKey)は、ノードプロトコルによって認識されるドメイン特有言語において記述されたコードのピースである。そのような言語の特定の例は、「Script」(大文字S)と呼ばれる。ロッキングスクリプトは、トランザクション出力203、例えば、Aliceの署名の要件を使い果たすためにどの情報が必要とされるかを規定する。アンロッキングスクリプトは、トランザクションの出力内で現れる。アンロッキングスクリプト(aka scriptSig)は、ロッキングスクリプト基準を充足するために必要とされる情報を提供するドメイン特有言語において記述されたコードのピースである。例えば、それは、Bobの署名を包含し得る。アンロッキングスクリプトは、トランザクションの入力202内で現れる。
【0086】
よって、例示される実施例では、Tx0の出力203内のUTXO0は、UTXO0が償還されるために(厳密には、UTXO0を償還することを試みる後続のトランザクションが検証されるために)、Aliceの署名Sig PAを必要とするロッキングスクリプト[Checksig PA]を含む。[Checksig PA]は、Aliceの公開鍵-秘密鍵ペアからの公開鍵PAを包含する。Tx1の入力202は、Tx1を再度指し示す(例えば、実施形態では、全体トランザクションTx0のハッシュである、そのトランザクションID、TxID0の手段によって)ポインタを含む。Tx1の入力202は、Tx0のいずれかの他の可能な出力の中でそれを識別する、Tx0内のUTXO0を識別するインデックスを含む。Tx1の入力202は更に、アンロッキングスクリプト<Sig PA>を含み、アンロッキングスクリプト<Sig PA>は、鍵ペアからのAliceの秘密鍵を予め定義されたデータの部分(暗号法において「メッセージ」と呼ばれる場合がある)に適用する、Aliceによって作成された、Aliceの暗号署名を含む。有効な署名を提供するためにAliceによってどのデータ(または、「メッセージ」)が署名される必要があるかは、ロッキングスクリプトによって、もしくはノードプロトコルによって、またはそれらの組み合わせによって定義され得る。
【0087】
新たなトランザクションTx1がノードに到達するとき、ノードは、ノードプロトコルを適用する。これは、ロッキングスクリプトおよびアンロッキングスクリプトを共に動作させて、アンロッキングスクリプトがロッキングスクリプト内で定義された条件を満たすかどうかをチェックすることを含む(この条件は、1つ以上の基準を含み得る)。実施形態では、これは、2つのスクリプト:<Sig PA><PA>||[Checksig PA]、を連結することを伴う。「||」は、連結を表し、「<…>」は、スタック上にデータを置くことを意味し、「[…]」は、アンロッキングスクリプト(この実施例では、スタックに基づく言語)によって含まれる関数である。同等に、スクリプトは、共通スタックと共に、スクリプトを連結するのではなく、相互に動作し得る。どちらにしても、共に動作するとき、スクリプトは、Tx1の入力内のロッキングスクリプトが、データの予測される部分に署名するAliceの署名を包含することを認証するために、Tx0の出力内のロッキングスクリプトに含まれるような、Aliceの公開鍵PAを使用する。データの予測される部分自体(「メッセージ」)も、この認証を実行するためにTx0に含まれる必要がある。実施形態では、署名されたデータは、Tx0の全体を含む(よって、それが既に本質的に存在するように、明確にデータの署名された部分を規定する別々の要素が含まれる必要がある)。
【0088】
公開-秘密暗号法による認証の詳細は、当業者に精通されている。基本的には、AliceがAliceの秘密鍵によりそれを暗号化することによってメッセージに署名した場合、次いで、Aliceの公開鍵およびメッセージ(暗号化されていないメッセージ)を明確に仮定して、ブロックチェーンネットワークのノードなどの別のエンティティは、メッセージの暗号化されたバージョンがAliceによって署名されたはずであったと認証することが可能である。署名することは典型的には、メッセージをハッシュすること、ハッシュに署名すること、および署名としてメッセージの明確なバージョンにこれをタグ付けし、よって、公開鍵のいずれかのホルダが署名を認証することを有効にすることを含む。したがって、データの特定のピースもしくはトランザクションの一部、または同様のものに署名することへの本明細書におけるいずれかの参照は、実施形態では、データのそのピースまたはトランザクションの一部のハッシュに署名することを意味することができる。
【0089】
Tx1内のアンロッキングスクリプトがTx0のロッキングスクリプト内で規定された1つ以上の条件を満たす場合(よって、示される実施例では、Aliceの署名がTx1内で提供され、認証される場合)、ブロックチェーンノードは、Tx1を有効と見なす。それが採掘ノードである場合、プルーフオブワークを待つトランザクションのプールにそれを追加することを意味する。それが転送ノードである場合、それは、ブロックチェーンネットワーク内で1つ以上の他のノードにトランザクションTx1を転送し、その結果、それは、ネットワークの全体を通じて伝播される。Tx1が検証され、ブロックチェーンに含まれると、これは、Tx0からのUTXO0を使い果たされたとして定義する。それが未使用トランザクション出力203を使い果たす場合のみ、Tx1が有効であることができることに留意されよう。既に別のトランザクションによって使い果たされた出力を使い果たすことをそれが試みる場合、全ての他の条件が満たされる場合でさえ、Tx1は、無効である。よって、ノード104も、先行するトランザクションTx0内の参照されたUTXOが既に使い果たされたかどうか(別の有効なトランザクションへの有効な入力を既に形成したかどうか)をチェックする必要がある。これは、ブロックチェーン150がトランザクションに対して定義された順序を課すことが重要であるという1つの理由である。実際に、所与のノード104は、どのUTXO 203がどのトランザクション内で使い果たされたかをマークする別々のデータベースを維持し得るが、最終的には、UTXOが使い果たされたかどうかを定義するものは、それが、ブロックチェーン内で別の有効なトランザクションへの有効な入力を既に形成したかどうかである。
【0090】
所与のトランザクションの全ての出力203内で規定された総量が、全てのその入力202によって指し示される総量もよりも多い場合、これは、ほとんどのトランザクションモデルにおいて無効性のための別の根拠である。したがって、そのようなトランザクションは、ブロックに伝播も採掘もされない。
【0091】
スクリプトコードが概略的に(すなわち、正確な言語ではない)表されることが多いことに留意されよう。例えば、[Checksig PA]=OP_DUP OP_HASH160<H(PA)>OP_EQUALVERIFY OP_CHECKSIGを意味するために、[Checksig PA]と記述し得る。「OP_…」は、Script言語の特定のオペコードを指す。OP_CHECKSIG(「Checksig」とも呼ばれる)は、2つの入力(署名および公開鍵)を取り、楕円曲線デジタル署名アルゴリズム(ECDSA)を使用して、署名の有効性を検証する、Scriptオペコードである。ランタイムにおいて、スクリプトからいずれの署名(「sig」)の発生も取り除かれるが、ハッシュパズルなどの追加の要件が、「sig」入力によって検証されるトランザクションに残る。別の実施例として、OP_RETURNは、トランザクション内にメタデータを記憶することができ、それによって、ブロックチェーン内で不変にデータを記録することができる、トランザクションの未使用可能出力を作成するScript言語のオペコードである。例えば、メタデータは、ブロックチェーンに記憶することが望ましいドキュメントを含み得る。
【0092】
署名PAは、デジタル署名である。実施形態では、これは、楕円曲線secp256k1を使用するECDSAに基づいている。デジタル署名は、データの特定のピースに署名する。実施形態では、所与のトランザクションについて、署名は、トランザクション入力の一部およびトランザクション出力の全てまたは一部に署名する。それが署名する出力の特定の部分は、SIGHASHフラグに依存する。SIGHASHフラグは、どの出力が署名されるかを(よって、署名の時に固定されるか)を選択するために、署名の終わりに含まれる4-バイトコードである。
【0093】
ロッキングスクリプトは、それぞれのトランザクションがロックされるパーティの公開鍵をそれが含むという事実を参照して、「scriptPubKey」と呼ばれる場合がある。アンロッキングスクリプトは、対応する署名をそれが供給するという事実を参照して、「scriptSig」と呼ばれる場合がある。しかしながら、より一般的に、それは、UTXOが償還される条件が、署名を認証することを含むというブロックチェーンの全ての適用において必須ではない。より一般的に、スクリプト言語は、いずれかの1つ以上の条件を定義するために使用され得る。よって、より一般的な用語「ロッキングスクリプト」および「アンロッキングスクリプト」が好まれ得る。
【0094】
本発明のいくつかの実施形態により、トランザクションは、共有DH鍵のハッシュにロックされる、pay-to-public-key-hash(P2PKH)出力であり得る。アンロックされるために、P2PKH出力を参照する後のトランザクションの入力は、(ハッシュされていない)共有DH鍵と、共有DH鍵に対応する秘密鍵に基づいて生成された署名とを含む必要がある。スクリプトにおいて表されると、「ロッキングスクリプト」および「アンロッキングスクリプト」は、以下の形式を取り得る:
ロッキングスクリプト=OP_DUP OP_HASH160<Public KeyHash>OP_EQUAL OP_CHECKSIG
アンロッキングスクリプト=<Signature><Public Key>
【0095】
上記実施形態が例としてのみ説明されてきたことを認識するであろう。より一般的に、以下のステートメントのうちのいずれか1つ以上に係る方法、装置、またはプログラムが提供され得る。
【0096】
ステートメント1
少なくとも1つの共有シークレットに基づいて、共有暗号鍵を生成するコンピュータ実装方法であって、第1のグループに属する各々の参加者は、第1のシークレットのそれぞれのシェアを有し、第1のシークレットは、第1の閾値および対応する第1の公開鍵を有し、第2のコーディネータは、第2のシークレットに対応する第2の公開鍵を有し、コンピュータ実装方法は、第1のグループの第1のコーディネータによって実行され、
第1のグループの少なくとも第1の閾値数の参加者から、共有暗号鍵のそれぞれのシェアを取得するステップであって、共有暗号鍵の各々のそれぞれのシェアは、i)第1のシークレットのそれぞれのシェアまたは第1のシークレットのそれぞれのシェアを計算するために使用されるそれぞれのプライベート多項式のそれぞれのゼロ次係数と、ii)第2の公開鍵と、に基づいている、ステップと、
暗号鍵の取得されたそれぞれのシェアに基づいて、共有暗号鍵を生成するステップであって、第2のコーディネータは、同一の共有暗号鍵を生成するように構成される、ステップと、
を含む、コンピュータ実装方法。
【0097】
ステートメント2
コーディネータは、第1のグループに属する前記参加者の1人である、ステートメント1に記載のコンピュータ実装方法。
【0098】
ステートメント3
第2の公開鍵を取得するステップと、
第1のグループの各々の参加者に第2の公開鍵を送信するステップと、
を含む、ステートメント1またはステートメント2に記載のコンピュータ実装方法。
【0099】
ステートメント4
第2のコーディネータに第1の公開鍵を送信するステップを含む、ステートメント1からステートメント3のいずれか1つに記載のコンピュータ実装方法。
【0100】
ステートメント5
第1のグループの少なくとも第1の閾値数の参加者から、第1の公開鍵のそれぞれのシェアを取得するステップを含み、第1の公開鍵の各々のそれぞれのシェアは、第1のシークレットのそれぞれのシェアおよび公開鍵ジェネレータに基づいている、ステートメント4に記載のコンピュータ実装方法。
【0101】
ステートメント6
第2の公開鍵を取得する前記ステップは、第2のコーディネータから第2の公開鍵を受信するステップを含む、ステートメント3またはそれに従属するいずれかのステートメントに記載のコンピュータ実装方法。
【0102】
ステートメント7
共有DH鍵の前記それぞれのシェアは、第1のシークレットのそれぞれのシェアに基づいて生成され、共有暗号鍵を生成する前記ステップは、共有暗号鍵の取得されたそれぞれのシェアにわたって楕円曲線補間を実行することを含む、ステートメント1からステートメント6のいずれか1つに記載のコンピュータ実装方法。
【0103】
ステートメント8
共有暗号鍵の前記それぞれのシェアは、第1のシークレットのそれぞれのシェアを計算するために使用されるそれぞれのプライベート多項式のそれぞれのゼロ次係数に基づいて生成され、共有暗号鍵のそれぞれのシェアを取得する前記ステップは、参加者の第1のグループの各々から共有暗号鍵のそれぞれのシェアを取得するステップを含み、共有暗号鍵を生成する前記ステップは、共有暗号鍵の取得されたそれぞれのシェアの点加算を実行するステップを含む、ステートメント1から6のいずれか1つに記載のコンピュータ実装方法。
【0104】
ステートメント9
共有暗号鍵により第1のメッセージを暗号化するステップを含む、ステートメント1からステートメント8のいずれか1つに記載のコンピュータ実装方法。
【0105】
ステートメント10
第2のコーディネータに、および/または異なるパーティに、暗号化された第1のメッセージを送信するステップを含む、ステートメント9に記載のコンピュータ実装方法。
【0106】
ステートメント11
ブロックチェーントランザクションを生成するステップであって、ブロックチェーントランザクションは、暗号化されたメッセージを含む、ステップと、
ブロックチェーンネットワークの1つ以上のノードに対してブロックチェーントランザクションを利用可能にするステップと、
を含む、ステートメント9またはステートメント10に記載のコンピュータ実装方法。
【0107】
ステートメント12
共有暗号鍵は、対称鍵であり、共有暗号鍵により第2のメッセージが暗号化されており、コンピュータ実装方法は、共有暗号鍵を使用して、第2のメッセージを復号するステップを含む、ステートメント1からステートメント11のいずれか1つに記載のコンピュータ実装方法。
【0108】
ステートメント13
共有暗号鍵に対応する秘密鍵を取得するステップと、
対応する秘密鍵を使用して、および/または対応する秘密鍵を使用して、デジタル署名を生成して、共有暗号鍵により暗号化された第3のメッセージを復号するステップと、
を含む、ステートメント1からステートメント12のいずれか1つに記載のコンピュータ実装方法。
【0109】
ステートメント14
第1のブロックチェーントランザクションは、共有暗号鍵にロックされる出力を含み、コンピュータ実装方法は、第1のブロックチェーントランザクションの出力を参照し、前記出力をアンロックするためのデジタル署名を含む、入力を有する第2のブロックチェーントランザクションを生成するステップを含む、ステートメント13に記載のコンピュータ実装方法。
【0110】
ステートメント15
共有暗号鍵に基づいて、1つ以上の追加の暗号鍵を生成するステップを含む、ステートメント1からステートメント14のいずれか1つに記載のコンピュータ実装方法。
【0111】
ステートメント16
1つ以上の追加の暗号鍵を生成する前記ステップは、共有暗号鍵にハッシュ関数を適用するステップを含む、ステートメント15に記載のコンピュータ実装方法。
【0112】
ステートメント17
第2のシークレットは、共有シークレットであり、第2のグループは、複数の参加者を含み、第2のグループの各々の参加者は、第2のシークレットのそれぞれのシェアを有し、第2のシークレットは、第2の閾値を有する、ステートメント1からステートメント16のいずれか1つに記載のコンピュータ実装方法。
【0113】
ステートメント18
第2のグループの各々の参加者は、第2のシークレットのそれぞれのシェアを計算するために使用されるそれぞれのプライベート多項式のそれぞれのゼロ次係数を有する、ステートメント17に記載のコンピュータ実装方法。
【0114】
ステートメント19
コンピュータ機器であって、
1つ以上のメモリユニットを含むメモリと、
1つ以上の処理ユニットを含む処理装置と、を備え、メモリは、処理装置上で動作するように構成されたコードを記憶し、コードは、処理装置上にあるとき、ステートメント1から18のいずれか1つのコンピュータ実装方法を実行するように構成される、
コンピュータ機器。
【0115】
ステートメント20
コンピュータ可読記憶装置上で具体化され、コンピュータ機器上で動作するとき、ステートメント1から18のいずれか1つのコンピュータ実装方法を実行するように構成されたコンピュータプログラム。
【0116】
本明細書で開示される別の態様により、第1の参加者および鍵ジェネレータのアクションを含む方法が提供され得る。
【0117】
本明細書で開示される別の態様により、第1の参加者および鍵ジェネレータのコンピュータ機器を含むシステムが提供され得る。
【0118】
本明細書における開示が与えられると、開示される技術の他の変形または使用ケースが当業者にとって明白になり得る。開示の範囲は、説明される実施形態によっては限定されず、添付の特許請求の範囲によってのみ限定される。
【符号の説明】
【0119】
101 コーディネータ
102a 参加者
102b 参加者
102c 参加者
103 コーディネータ
104a 参加者
104b 参加者
104c 参加者
【国際調査報告】