特許 7472158 メッセージにデジタル署名を提供するための方法

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

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

(11)【特許番号】

(24)【登録日】2024-04-12

(45)【発行日】2024-04-22

(54)【発明の名称】メッセージにデジタル署名を提供するための方法

(51)【国際特許分類】

   G09C 1/00 20060101AFI20240415BHJP

【ＦＩ】

G09C1/00 650Z

【請求項の数】 10

(21)【出願番号】P 2021552496

(86)(22)【出願日】2020-02-07

(65)【公表番号】

(43)【公表日】2022-04-20

(86)【国際出願番号】 EP2020053101

(87)【国際公開番号】W WO2020177977

(87)【国際公開日】2020-09-10

【審査請求日】2022-12-27

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

(32)【優先日】2019-03-05

(33)【優先権主張国・地域又は機関】EP

(73)【特許権者】

【識別番号】521393960

【氏名又は名称】ブロックデーモン・アンパルツセルスケープ

【氏名又は名称原語表記】Ｂｌｏｃｋｄａｅｍｏｎ ＡｐＳ

(74)【代理人】

【識別番号】100145403

【弁理士】

【氏名又は名称】山尾 憲人

(74)【代理人】

【識別番号】100135703

【弁理士】

【氏名又は名称】岡部 英隆

(72)【発明者】

【氏名】ヤコブセン，トマス ペレ

(72)【発明者】

【氏名】ダムゴー，イヴァン ビェアア

(72)【発明者】

【氏名】エスタゴー，ミケール ベクスヴァング

(72)【発明者】

【氏名】ニールセン，イェスパー ブース

【審査官】行田 悦資

(56)【参考文献】

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

【文献】特開２００２－１７５００９（ＪＰ，Ａ）

【文献】特開２００１－１４２３９７（ＪＰ，Ａ）

【文献】米国特許第０９４８９５２２（ＵＳ，Ｂ１）

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

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

Ｇ０９Ｃ １／００

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

【請求項1】

複数のサーバ装置により実行される、デジタル署名アルゴリズムＤＳＡまたは楕円曲線デジタル署名アルゴリズムＥＣＤＳＡにしたがってメッセージＭにデジタル署名を提供するための方法であって、前記方法は、
関数Ｆと、関数Ｈと、位数ｑの巡回群Ｇの生成元ｇとを提供するステップであって、ここで、ｇ∈Ｇであり、ｇ、Ｇ、ＦおよびＨはＤＳＡまたはＥＣＤＳＡによって規定される、ステップと、
少なくとも２つのサーバ装置間のランダムな秘密シェア［ｘ］として秘密鍵ｘを生成するステップと、
前記少なくとも２つのサーバ装置間のランダムな秘密シェア［ａ］および［ｋ］を生成し、［ｗ］＝［ａ］［ｋ］を計算するステップと、
ｋを明らかにすることなく、Ｒ＝ｇ^ｋとして値Ｒを計算するステップであって、
前記少なくとも２つのサーバ装置のそれぞれが、前記値ＲのシェアＲ_ｊをＲ_ｊ＝ｇ^ｋ＿ｊとして計算し、他のサーバ装置のそれぞれに前記シェアを分配するステップと、
前記シェアＲ_ｊから前記値Ｒを計算するステップと、
を前記少なくとも２つのサーバ装置が実行することで、計算するステップと、
オネストなサーバ装置から発信された［ｋ］の少なくともｔ＋１個のシェアからＲ＝ｇ^ｋが計算されることを検証することで、前記少なくとも２つのサーバ装置のそれぞれが、他のサーバ装置から受信した前記シェアＲ_ｊに基づいて、Ｒが正しいことを確認することで、Ｒが正しいと保証するステップと、
Ｒ^ａを計算することで、ａまたはｋを明らかにすることなく、Ｗ＝ｇ^ａｋとして認証符号Ｗを計算するステップであって、
前記少なくとも２つのサーバ装置のそれぞれが、前記認証符号ＷのシェアＷ_ｊをＷ_ｊ＝Ｒ^ａ＿ｊとして計算し、他のサーバ装置のそれぞれに前記シェアを分配するステップと、
前記シェアＷ_ｊから前記認証符号Ｗを計算するステップと、
を前記少なくとも２つのサーバ装置が実行することで、計算するステップと、
オネストなサーバ装置から発信された［ａ］の少なくともｔ＋１個のシェアからＷ＝Ｒ^ａが計算されることを検証することで、前記少なくとも２つのサーバ装置のそれぞれが、他のサーバ装置から受信した前記シェアＷ_ｊに基づいて、Ｗが正しいことを確認することで、Ｗが正しいと保証するステップと、
ｇ^ｗ＝Ｗであるかどうかを確認することで［ｗ］を検証するステップと、
［ｋ^－１］＝［ａ］・ｗ^－１を計算し、［ｘ・ｋ^－１］＝［ｘ］・［ｋ^－１］を計算し、Ｍ、Ｒ、［ｋ^－１］および［ｘ・ｋ^－１］の関数として前記少なくとも２つのサーバ装置間のシェア［ｓ］を生成することで、［ｓ］＝ｍ・ｗ^－１・［ａ］＋ｒ・ｗ^－１・［ａ］・［ｘ］＋［ｄ］を計算することで、前記メッセージＭに署名するステップであって、ここでｒ＝Ｆ（Ｒ）、ｍ＝Ｈ（Ｍ）および［ｄ］はゼロのランダムなシェアであり、ｓは署名対（ｒ，ｓ）の一部を形成する、ステップと、
を前記複数のサーバ装置が実行することを含む、方法。

【請求項2】

ＲまたはＷが正しくないことが明らかになった場合、署名処理を中止するステップを前記複数のサーバ装置が実行することをさらに含む、請求項１に記載の方法。

【請求項3】

［ｗ］を検証するステップがｇ^ｗ≠Ｗであることを明らかにした場合、署名処理を中止するステップを前記複数のサーバ装置が実行することをさらに含む、請求項１または請求項２に記載の方法。

【請求項4】

メッセージＭに署名するステップは、［ｓ］＝ｍ・ｗ^－１・［ａ］＋ｒ・ｗ^－１・［ａ］・［ｘ］＋「ｄ」＋ｍ・［ｅ］を計算することで前記複数のサーバ装置により実行され、ここで、ｒ＝Ｆ（Ｒ）、ｍ＝Ｈ（Ｍ）であり、［ｄ］および［ｅ］はゼロのランダムなシェアである、請求項１から請求項３のいずれか一項に記載の方法。

【請求項5】

少なくとも、秘密鍵ｘを生成するステップと、ランダムな秘密シェア［ａ］および［ｋ］を生成するステップと、値Ｒを計算するステップと、認証符号Ｗを計算するステップとは、前記メッセージＭの生成の前に、前処理によって実行される、請求項１から請求項４のいずれか一項に記載の方法。

【請求項6】

公開鍵ｙをｙ＝ｇ^ｘとして計算するステップと、ｙを前記少なくとも２つのサーバ装置のそれぞれに明らかにするステップと、を前記複数のサーバ装置が実行することをさらに含む、請求項１から請求項５のいずれか一項に記載の方法。

【請求項7】

前記公開鍵ｙを用いて、前記署名を検証するステップを前記複数のサーバ装置が実行することをさらに含む、請求項６に記載の方法。

【請求項8】

前記署名を検証するステップは、ｒ＝Ｆ（ｇ^ｍ／ｓ・ｙ^ｒ／ｓ）であるかどうかを確認するステップをさらに含む、請求項７に記載の方法。

【請求項9】

前記署名を検証するステップは、Ｒ^ｓ＝ｇ^ｍ・ｙ^ｒであるかどうかを確認するステップをさらに含む、請求項７または請求項８に記載の方法。

【請求項10】

ｙの正しさを確認するステップを前記複数のサーバ装置が実行することをさらに含む、請求項６から請求項９のいずれか一項に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、デジタル署名アルゴリズム（ＤＳＡ）または楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）に従って、メッセージにデジタル署名を提供するための方法に関する。本発明によれば、デジタル署名は、多数関係者（マルチパーティ）閾値ＤＳＡまたはＥＣＤＳＡプロトコルを使用して生成される。

【背景技術】

【0002】

デジタル署名は、データおよび／またはエンティティをオンラインで認証するために、オンラインの送信されたデータの整合性を確保するためなどに使用できる。単一の関係者が秘密署名鍵全体を保持できるようにする代わりに、多数の関係者（パーティ）のそれぞれが秘密署名鍵のシェアを保持して、関係者間の秘密のシェア（ｓｈａｒｅ：分散物）として生成される秘密署名鍵を使用することにより、署名システムが危険にさらされるリスクが軽減される。このような方式は、「マルチパーティ署名方式」と呼ばれることもある。マルチパーティ署名方式では、一部の関係者が利用できない、破損している、または危殆化されている場合でも、デジタル署名を生成し得る。セキュリティに違反することなく許容され得る破損した関係者の最大数は、方式のセキュリティ閾値と呼ばれることもあり、「ｔ」で示され得る。

【0003】

デジタル署名アルゴリズムは、デジタル署名の生成に従来使用されてきた。一例はＤＳＡ標準である。これは、素数位数ｑの巡回群Ｇと生成元ｇ∈Ｇ、および２つの関数Ｈ：{０，１}^＊→Ｚ_ｑとＦ：Ｇ→Ｚ_ｑによってパラメータ化された署名方式を考案する。秘密署名鍵ｘはＺ_ｑからランダムに選択され、対応する公開検証鍵はｙ＝ｇ^ｘとして計算される。メッセージＭに署名するには、最初にランダムなノンスｋ∈Ｚ_ｑを選択し、次に署名を（ｒ，ｓ）として計算する。ここで、ｒ＝Ｆ（ｇ^ｋ）およびｓ＝ｋ^－１・（Ｈ（Ｍ）＋ｒ・ｘ）である。公開検証鍵ｙと署名（ｒ，ｓ）が与えられると、ｍ＝Ｈ（Ｍ）を計算し、ｒ＝Ｆ（ｇ^ｍ／ｓ・ｙ^ｒ／ｓ）を確認することで署名を検証できる。

【0004】

別の例は、基本的にＤＳＡと同じように機能する署名方式を定める、ＥＣＤＳＡ標準であるが、Ｇは代わりに楕円曲線上の点ｇによって生成される。楕円曲線暗号を適用するデジタル署名アルゴリズムは、通常、楕円曲線デジタル署名アルゴリズムまたはＥＣＤＳＡと呼ばれ、デジタル署名の生成に従来使用されてきた。このようなアルゴリズムは、信頼性の高いデジタル署名を提供するのに適していることが知られている。

【0005】

ＤＳＡを説明するときは乗法表記を使用するのが一般的であるが、ＥＣＤＳＡの場合は加法表記を使用する。本明細書では、ＤＳＡとＥＣＤＳＡの両方にこの方法を適用できる場合でも、乗法表記を使用する。つまり、群Ｇの要素ａ、ｂについては、ａ・ｂ、または単にａｂを使用して、２つの要素に適用される群演算を示す。体Ｚ_ｑ内の要素の計算は、体の内で行われると想定される。つまり、ｒ・ｘまたはｍ／ｓを書くと、暗黙的に、ｑを法として考える。

【先行技術文献】

【特許文献】

【0006】

【文献】国際公開第２０１５／１６０８３９号

【非特許文献】

【0007】

【文献】Ｒｏｓａｒｉｏ Ｇｅｎｎａｒｏ， ｅｔ ａｌ．： “Ｒｏｂｕｓｔ Ｔｈｒｅｓｈｏｌｄ ＤＳＳ Ｓｉｇｎａｔｕｒｅｓ”， Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｍｐｕｔａｔｉｏｎ， ｖｏｌ． １６４， ｐａｇｅｓ ５４－８４ （２００１）

【発明の概要】

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

【0008】

特許文献１は、楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）に基づくデジタル署名を分散方式で生成するためのシステムおよび方法を開示する。秘密分散プロトコルは、クライアントとｎ台のサーバのセットとの間で初期化されて、ｎ台のサーバのセット間の秘密鍵のシェアのセットを分散する。サーバのセットは、プロトコルを初期化して、秘密鍵を再構築または公開することなく、秘密鍵のシェアのセットを使用してメッセージにデジタル署名を生成する。ｎ台のサーバのｎ／２以下の閾値ｔ（つまり、ｔ≦ｎ／２）は、秘密鍵の機密性や生成された署名の正確性を危殆化することなく、悪意を持って完全に破損または危殆化される可能性がある。

【0009】

特許文献１に開示されているシステムおよび方法は、デジタル署名を生成するためにかなりのラウンド回数の相互作用を必要とする。さらに、システムおよび方法は、高い処理能力および通信帯域幅を必要とする。

【0010】

非特許文献１は、マルチパーティ閾値署名方式を使用してデジタル署名を提供するための方法を開示している。この論文に記載されたプロトコルは、多項式補間を適用し、関係者の数ｎが３ｔ＋１以上の場合、最大ｔ個の悪意のある攻撃者に対して頑健であり偽造できない。したがって、１人の悪意のある敵を許容するには、関係者の数を少なくとも４個にする必要がある。さらに、この方法では、デジタル署名を生成するために、かなりのラウンド回数の相互作用が必要である。

【0011】

本発明の実施形態の目的は、機密性を危殆化することなくデジタル署名を生成するために必要な相互作用のラウンド回数が低減される、マルチパーティＤＳＡまたはＥＣＤＳＡに基づくデジタル署名を提供するための方法を提供することである。

【0012】

本発明の実施形態のさらなる目的は、機密性を危殆化することなく処理能力への要件が低減される、マルチパーティＤＳＡまたはＥＣＤＳＡに基づくデジタル署名を提供するための方法を提供することである。

【0013】

本発明の実施形態のさらなる目的は、機密性を危殆化することなく通信帯域幅への要件が低減される、マルチパーティＤＳＡまたはＥＣＤＳＡに基づくデジタル署名を提供するための方法を提供することである。

【0014】

本発明の実施形態のさらなる目的は、悪意を持って破損された最大ｔ個の関係者を許容できるマルチパーティＤＳＡまたはＥＣＤＳＡに基づくデジタル署名を提供するための方法を提供することである。ここで、ｔ＞ｎ／３である。

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

【0015】

本発明は、デジタル署名アルゴリズムＤＳＡまたは楕円曲線デジタル署名アルゴリズムＥＣＤＳＡにしたがって、メッセージＭにデジタル署名を提供するための方法を提供し、本方法は、
関数Ｆと、関数Ｈと、位数ｑの巡回群Ｇに生成元器ｇとを提供するステップであって、ここで、ｇ∈Ｇであり、ｇ、Ｇ、ＦおよびＨは、ＤＳＡまたはＥＣＤＳＡによって規定される、ステップと、
少なくとも２つの関係者間のランダムな秘密シェア［ｘ］として秘密鍵ｘを生成するステップと、
少なくとも２つの関係者間のランダムな秘密シェア［ａ］および［ｋ］を生成し、［ｗ］＝［ａ］［ｋ］を計算するステップと、
ｋを明らかにすることなく、Ｒ＝ｇ^ｋとして値Ｒを計算するステップと、
オネストな（ｈｏｎｅｓｔ：適切な）関係者から発信された［ｋ］の少なくともｔ＋１個のシェアからＲ＝ｇ^ｋが計算されることを検証することでＲが正しいと保証するステップと、
Ｒ^ａを計算することで、ａまたはｋを明らかにすることなく、Ｗ＝ｇ^ａｋとして認証符号Ｗを計算するステップと、
オネストな関係者から発信された［ａ］の少なくともｔ＋１個のシェアからＷ＝Ｒ^ａが計算されることを検証することでＷが正しいと保証するステップと、
ｇ^ｗ＝Ｗであるかどうかを確認することで［ｗ］を検証するステップと、
［ｋ^－１］＝［ａ］・ｗ^－１を計算し、［ｘ・ｋ^－１］＝［ｘ］・［ｋ^－１］を計算し、Ｍ、Ｒ、［ｋ^－１］および［ｘ・ｋ^－１］の関数として、少なくとも２つの関係者間のシェア［ｓ］を生成することで、メッセージＭに署名するステップと、
を含む。

【0016】

したがって、本発明の方法は、メッセージＭにＤＳＡに基づくまたはＥＣＤＳＡに基づくデジタル署名を提供するための方法である。本発明の方法に従って適用されるデジタル署名は、例えば、オンライン金融取引中などに、例えば、送信者の信憑性を保証するために、送信されたデータの整合性を確保するために使用され得る。

【0017】

本発明の方法によれば、位数ｑの巡回群Ｇの生成元ｇ、関数Ｆ、および関数Ｈが最初に提供される。生成元ｇは、巡回群Ｇの要素、つまりｇ∈Ｇである。巡回群Ｇ、生成元ｇ、および関数Ｆ、Ｈは、すべてＤＳＡまたはＥＣＤＳＡによって規定される。したがって、使用される特定のＤＳＡまたはＥＣＤＳＡが決定されると、これらが定められる。

【0018】

次に、秘密鍵［ｘ］は、少なくとも３つの関係者間など、少なくとも２つの関係者間でのランダムな秘密シェアとして生成される。本明細書では、「秘密シェア」という用語は、各関係者が秘密鍵のシェアを保持し、いずれの関係者も秘密鍵全体を保持しないように、秘密鍵が少なくとも２つの関係者に配布されることを意味すると解釈されるべきである。したがって、本発明の方法は、マルチパーティシステムを適用する。これにより、いずれの関係者も、信頼できる唯一の情報源を構成せず、秘密鍵全体にアクセスするために、いくつかの関係者、つまり少なくともｔ＋１個の関係者が悪意を持って共謀する必要がある。これにより、特に機密性の観点から、システムのセキュリティが向上する。

【0019】

秘密分散法の例は、加法分散である。秘密ｘは、各関係者Ｐ_ｉがｘ＝ｘ_１＋ｘ_２＋…＋ｘ_ｎのようなランダムなシェアｘ_ｉを保持している場合、ｎ個の関係者Ｐ_１、Ｐ_２、…、Ｐ_ｎの間で加法的に分散されると言われる。秘密を再構築するにはｎ個のシェアの全てが必要であるため、加法分散は閾値ｔ＝ｎ－１を有する。つまり、ｘを再構築するには、全てのｎ個の関係者の協力が必要であり、１つを除くすべてのシェアを所有しても、ｘを再構築できない。別の例は、シャミア（Ｓｈａｍｉｒ）の分散法である。ここで、秘密ｘは、各関係者Ｐ_ｉがｆ（０）＝ｘを条件とするランダム多項式ｆの値ｆ（ｉ）をシェアとして保持するときに分散される。シャミアのシェアの次数は、多項式ｆの次数として定められる。この次数がｔの場合、任意のｔ＋１個の関係者は、多項式補間を使用してシェアを秘密に再結合できるが、ｔ個以下の関係者のサブセットによって保持されるシェアは、ｘについて何も明らかにしない。

【0020】

本明細書では、「ランダムな秘密シェア」という用語は、分散された秘密もランダムな値になるように、シェアがランダムに選択される秘密シェアであると解釈されるべきである。加法分散の場合、これはシェアが完全にランダムであることを意味する。閾値ｔのシャミアのシェアの場合、シェアがランダムな次数ｔの多項式上の点であることを意味する。

【0021】

この開示全体を通して、角括弧［］内に配置された文字は、多くの関係者間での要素のシェアを表している。角括弧のない同じ文字は、要素全体を表す。したがって、例えば、ｘは秘密鍵全体を表し、［ｘ］は秘密鍵ｘの秘密シェアを表す。

【0022】

秘密を公開せずに、秘密シェアの計算を実行できる。これは、研究分野「安全なマルチパーティ計算」の主題である。ほとんどの種類の秘密シェアでは、関係者は２つの秘密シェアの合計を簡単に計算できる。つまり、［ｘ］および［ｙ］が与えられると、ｘまたはｙを明らかにすることなくシェア［ｘ＋ｙ］を計算できる。同様に、すべての関係者が公開定数ｃに同意する場合、ｘを明らかにすることなく、ｃおよび［ｘ］からシェア［ｃ・ｘ］を簡単に計算できる。これらの演算には、表記［ｘ］＋［ｙ］およびｃ・［ｘ］を使用するだろう。

【0023】

［ｘ］および［ｙ］から積［ｘｙ］を計算することもできる。ｘとｙを明らかにせずにそうすることは、特定のセキュリティ閾値（ｔ）の関係者までが悪意を持って共謀する可能性がある場合、可能であるが、多くの場合、困難で非効率的である。このため、２つのランダムなシェア［ｘ］と［ｙ］には、乗算の「弱い」概念が使用されることがある。弱い乗算は、多くともｔ個の関係者が悪意のあるものである限り、ｘとｙに関する情報が漏洩しないという意味で機密性を保証する。しかし、弱い乗算は結果の正確さを保証しない。むしろ、すべての関係者が正しく動作する場合にのみ、正しい結果［ｘｙ］を計算する。単一の悪意のある関係者が、例えば、結果のシェア［ｚ］がｘｙのシェアではないように結果を台無しにすることができる。以下では、簡単にするために、特に明記しない限り、表記［ｚ］＝［ｘ］［ｙ］を使用して弱い乗算を示す。

【0024】

例えば、セキュリティ閾値ｔがｔ＜ｎ／２を満たす限り、シャミアのシェアに対して弱い乗算を構築できる。より大きな閾値、つまり最大閾値ｔ＝ｎ－１までの場合、ペイエ（Ｐａｉｌｌｉｅｒ）の暗号化方式などの加法準同型暗号化方式をいわゆるゼロ知識証明と組み合わせることにより、加法分散に対して弱い乗算を取得できる。弱い乗算のこのような構成の例は、安全なマルチパーティ計算の研究文献に記載されている。

【0025】

関係者は、例えば、互いに物理的に分離され得る別個のサーバの形態であり得る。関係者は、一方の関係者が利用できる情報が他方の関係者が利用できないという意味で、別個または独立していることが好ましい場合がある。しかし、ｔ＋１個以上の関係者のサブセットがすべての情報を所有していない限り、一部の関係者が一部の情報を分散することは除外されない。

【0026】

次に、ランダムな秘密シェア［ａ］と［ｋ］が、少なくとも２つの関係者間で生成される。したがって、少なくとも２つの関係者のそれぞれは、ａのシェアおよびｋのシェアを保有する。さらに、［ｗ］＝［ａ］［ｋ］は、少なくとも２つの関係者間での秘密シェアとしても計算される。これは、ａとｋのシェアからｗのシェアを計算する少なくとも２つの関係者のそれぞれによって実行され得る。さらに、［ｗ］は「公開される」可能性がある。つまり、少なくとも２つの関係者のそれぞれに秘密ｗが明らかにされる可能性がある。これは、例えば、少なくとも２つの関係者のそれぞれが、他の関係者のそれぞれにｗのシェアを明らかにすることによって得られる。［ｗ］は、［ａ］および／または［ｋ］を公開せずとも、つまりａとｋの値を秘密にしたまま、公開され得ることに留意するべきである。

【0027】

次に、値Ｒは、ｋを明らかにせずに、Ｒ＝ｇ^ｋとして計算される。これは、例えば、少なくとも２つの関係者のそれぞれが、ｋのシェアに基づいてＲのシェアを計算することを含むことができる。これについては、以下でさらに詳しく説明する。別の方法として、ｋが明らかにされないことが保証されている限り、Ｒは別の方法で計算され得る。しかし、Ｒは少なくとも２つの関係者のそれぞれに明らかにされる可能性がある。標準のＤＳＡ／ＥＣＤＳＡも基づいている「離散対数」の仮定として知られている一般的に受け入れられている暗号学的仮定のため、値Ｒ＝ｇ^ｋを見てｋに関する何らかの情報を推測することはできないことに留意すべきである。

【0028】

さらに、Ｒが正しいことが保証される。本明細書では、これは、Ｒがｇ^ｋに等しいことを意味すると解釈されるべきである。ここで、ｋは秘密シェア［ｋ］によって定められた一意の値ｋである。Ｒが正しいことを確認するステップは、Ｒ＝ｇ^ｋがオネストな関係者から発信された［ｋ］の少なくともｔ＋１個のシェアから計算されたことを検証することによって実行される。ここで、ｔは署名方式の閾値を示し、つまり最大ｔ個の悪意のある、破損した、不正なまたは利用できない関係者は許容され得る。したがって、Ｒの正しさを確認する場合、関係者のオネストさが調査され、少なくともｔ＋１個の関係者がオネストであることが証明できる場合にのみ、Ｒが正しいと結論付けられる。これについては、以下でさらに詳しく説明する。

【0029】

Ｒが正しくないことが判明した場合、署名処理が中止され得る。例えば、各オネストな関係者は、（１）値Ｒ＝ｇ^ｋを取得すること、または（２）この時点で中止を出力することが保証される。つまり、最大ｔ個の関係者が破損している場合であっても、残りのｎ－ｔ個の関係者はＲ＝ｇ^ｋを取得するか、中止するだろう。これについては、以下でさらに詳しく説明する。

【0030】

次に、認証符号ＷがＷ＝ｇ^ａｋとして計算される。これは、ｇ^ａｋを直接計算するのではなくＲ^ａを計算することによって、かつａまたはｋを明らかにせずに、行われる。これは、Ｒがｇの代わりに基礎として使用されることを除いて、Ｒが計算された方法と同じ方法で行われ得る。この場合も、オネストな関係者から発信された［ａ］の少なくともｔ＋１個のシェアからＷ＝Ｒ^ａが計算されることを確認することにより、Ｗが正しいことが保証される。そうでない場合は、署名処理が中止され得る。

【0031】

したがって、処理のこの段階では、正しいＲ＝ｇ^ｋと正しいＷ＝ｇ^ａｋが計算されているが、値ｋおよびａは秘密のままである。

【0032】

次に、ｇ^ｗ＝Ｗであるかどうかを確認することで［ｗ］を検証する。これは、各関係者へ［ｗ］を公開することを含んでもよい。［ｗ］の計算にはシェアの弱い乗算が使用されたため、すべての関係者がオネストで、この時点までプロトコルに従った場合にのみ、ｗは積ａｋに等しくなることに留意すべきである。Ｗ＝ｇ^ａｋが正しいことがすでにわかっているため、ｇ^ｗ＝Ｗであることを確認すると、ｗ＝ａｋであることが保証される。この時点で、Ｗ、ｇおよびｗはすべての関係者に知られているため、どの関係者もこの方法でその値ｗの正しさを検証できる。さらに、これは、ａを明らかにすることなく、またｋを明らかにすることなく行うことができる。

【0033】

したがって、処理のこの段階で、少なくとも２つの関係者のうちの各オネストな関係者によってｗの正しい値が計算されていることが保証されている。

【0034】

上記のすべてのステップは、署名されるメッセージＭの知識がなくても実行され得る。したがって、これらのステップは、前処理プロセスで、例えば非ピーク期間中に、実行され得る。これにより、処理装置の負荷が平準化され、ピーク時に実行され得るトランザクションの数を増加させ得る。また、メッセージＭが表示されてから、Ｍの署名が計算されるまでの応答時間が短縮され得る。

【0035】

最後に、メッセージＭは、［ｋ^－１］＝［ａ］・ｗ^－１を計算し、［ｘ・ｋ^－１］＝［ｘ］・［ｋ^－１］を計算し、Ｍ、Ｒ、［ｋ^－１］および［ｘ・ｋ^－１］の関数として、少なくとも二つの関係者間での、シェア［ｓ］を生成することで、署名される。

【0036】

ＭのＤＳＡまたはＥＣＤＳＡデジタル署名は通常、対（ｒ，ｓ）で構成される。ここで、ｒ＝Ｆ（ｇ^ｋ）およびｓ＝ｋ^－１（Ｈ（Ｍ）＋ｒｘ）である。対（ｒ，ｓ）は、公開鍵ｙを使用して公開および検証され得る。生成されたシェア［ｓ］は、署名対の後半部分ｓのシェアである。対の最初の部分ｒは、ｒ＝Ｆ（Ｒ）として生成され得る。ここで、Ｆは、ＥＣＤＳＡによって最初に提供および規定された関数の１つである。シェア［ｓ］は、次のように生成される。最初に、ｋの逆数のシェアが［ｋ^－１］＝ｗ^－１［ａ］として計算される。ｗがａｋに等しいことが確認されているため、ｗ^－１［ａ］＝［ａｗ^－１］＝［ａ（ａｋ）^－１］＝［（ａａ^－１）ｋ^－１］＝［ｋ^－１］であるため、ｋ^－１が正しく分散される。さらに、シェア［ｘ・ｋ^－１］は、［ｘ］・［ｋ^－１］として計算される。シェア［ｓ］は、例えば、最初に［Ａ］＝Ｈ（Ｍ）［ｋ^－１］、［Ｂ］＝［ｋ^－１］［ｘ］を計算し、最後に［ｓ］＝［Ａ］＋ｒ［Ｂ］を計算することによって計算される。

【0037】

さらに、本発明による方法では、処理の正確性に関して疑わしい場合、中止が許可される、すなわち、終了保証が提供されない。ただし、終了保証は、多くの従来技術の方法の要件である。このような疑いは、例えば、１以上の関係者が危殆化されているか悪意があることが原因であり得る。または、単に関係者間の通信中にパッケージが失われたことが原因であり得る。処理を中止すると、正しい署名を提供しようとするために処理が再起動されるだけである。

【0038】

終了保証が提供される署名方法は、通常、同期ネットワーク、すなわちパッケージ遅延の上限を保証するネットワークを想定することによって終了保証を実現する。インターネットなどのオープンな通信ネットワークを使用してこのような方法を適用するには、インターネットが本質的に非同期であるため、各関係者にローカルクロックを提供する必要がある。また、特定の一定の待ち時間内に関係者が予期されるメッセージを受信しない場合は、ローカルクロックにより、それは単に送信者を破損しているとして扱う。

【0039】

これはジレンマをもたらす。待ち時間が小さい場合、インターネット上で頻繁に発生するパッケージの遅延により、プロトコルが許容できるよりも多くの関係者が、例えばｎ個の関係者のｎ／２個またはｎ／３個以上が、破損したものとしてすぐに扱われるリスクが高くなる。その結果、秘密の署名鍵が漏洩する可能性がある。これを回避するには、待ち時間を非常に高く設定する必要がある。ただし、これには、単一の悪意のある関係者が他の関係者に送信する各メッセージを意図的に遅延させることにより、システムに非常に高い遅延をもたらすことができるという欠点がある。つまり、タイムアウトが発生しそうになるまでメッセージを保留できる。本発明による方法は、プロトコルに中止を許容することにより、当該ジレンマを回避する。これにより、非常に小さな待ち時間を使用できるようになり、システム全体の遅延がわずかになる。これが可能なのは、すべてのメッセージが遅延した場合でさえ、発生する可能性のある最悪の事態がプロトコルが停止することであり、先に開示されているいくつかの方法のように秘密署名鍵が漏洩しないことを保証するように設計されているためである。

【0040】

値Ｒを計算するステップは、
少なくとも二つの関係者のそれぞれが、値ＲのシェアＲ_ｊをＲ_ｊ＝ｇ^ｋ＿ｊとして計算し、シェアを他の各関係者に分配するステップと、
シェアＲ_ｊから値Ｒを計算するステップと、
を含んでもよく、
Ｒが正しいことを保証するステップは、
関係者のそれぞれが、他の関係者から受信したシェアＲ_ｊに基づいて、Ｒが正しいことを確認するステップ、
を含み得る。

【0041】

それぞれの関係者Ｐ_ｊが、秘密ｋのシェアｋ_ｊを保持していることを想起する。本実施形態によれば、値Ｒは、以下の方法で少なくとも２つの関係者によって計算される。少なくとも２つの関係者のそれぞれは、ＲのシェアＲ_ｊを計算する。ここで、Ｒ_ｊは、関係者ｊによって計算されるＲのシェアを示す。Ｒ_ｊはＲ_ｊ＝ｇ^ｋ＿ｊとして計算される。ここで、ｋ＿ｊは、関係者ｊが保持する［ｋ］のシェアを示す。したがって、各関係者は、［ｋ］の独自のシェアに基づいて、Ｒ_ｊのシェアを計算する。

【0042】

次に、少なくとも２つの関係者のそれぞれが、ＲのシェアＲ_ｊを他の各関係者に分配する。つまり、シェアＲ_ｊが公開される。しかし、離散対数の仮定により、シェアｋ＿ｊは秘密のままであり、したがって秘密のノンスｋは秘密のままである。

【0043】

次に、値Ｒは、公開されたシェアＲ_ｊから計算される。これは、例えば、「指数で」シェアＲ_ｊを補間することを含み得る。例えば、値Ｒは、少なくとも２つの関係者によって計算されてもよく、および／またはそれは中央でまとめてに計算されてもよい。本明細書において、「指数での補間」という用語は、たとえばｇ^ｋ＿１、ｇ^ｋ＿２などからｇ^ｋを計算するなど、「指数での」秘密が再構築される多項式補間を意味すると解釈されるべきである。

【0044】

最後に、少なくとも２つの関係者のそれぞれが、他の関係者から受信したシェアＲ_ｊに基づいて、Ｒが正しいことを確認する。

【0045】

この方法の一実施形態によれば、シェアはシャミアのシェアであってもよく、少なくとも３つの関係者が存在し（すなわち、ｎ≧３）、セキュリティ閾値ｔは、ｔ＜ｎ／２を満たす。本実施形態では、少なくとも３つの関係者のそれぞれは、他の関係者から受信したシェアＲ_ｊのそれぞれが、第１のｔ＋１個のシェアによって一意に定められる次数ｔの多項式ｆと一致することを確認することによって、Ｒが正しいことを検証できる。これは、例えば、シェアＲ_ｔ＋２、Ｒ_ｔ＋３、…、Ｒ_ｎのそれぞれを、例えば指数でのラグランジュ補間を使用する第１のｔ＋１個のシェアＲ_１、Ｒ_２、…、Ｒ_ｔ＋１から算出され得る予想されるシェアと比較することによって実行され得る。全ての場合において、受信したシェアが予想されるシェアと等しい場合、受信した全てのシェアＲ_ｊは正しいと結論付けることができる。これは、シェアＲ_ｊの少なくともｔ＋１個がオネストな関係者から受信したものであり、したがって正しいことがわかっているため、結論付けることができる。いずれかの関係者が、シェアＲ_ｊのいくつかが欠落しているか、第１のｔ＋１個の受信したシェアによって決定された多項式と一致しないことを発見した場合、関係者はプロトコルを中止できる。

【0046】

当該方法の代替的な実施形態によれば、シェアは加法分散であってもよく、セキュリティ閾値は最大ｔ＝ｎ－１であってもよい。当該実施形態では、各関係者Ｐ_ｉのシェアｇ^ｋ＿ｉは、ゼロ知識証明、例えば、非対話型ゼロ知識証明を含んでもよく、それにより、Ｐ_ｉは、ｋ_ｉに関する情報を明らかにすることなく、シェアＲ_ｉが正しく計算されたことを他の関係者に証明する。当該代替的な実施形態において、Ｒの正しさを検証することは、別の関係者からシェアＲ_ｊを受信する関係者がゼロ知識証明を検証し、証明が無効である場合に中止することを含んでもよい。

【0047】

一実施形態によれば、Ｒの正確さは、以下の方法で保証され得る。３つの参加関係者（ｎ＝３）があり、１つの危殆化された、または利用できない関係者が許容できる、つまりｔ＝１、と想定する。この場合、Ｒの正しい値は、２つ以上のオネストな関係者から発信されたシェアＲ_ｊから計算できる。次に、３つの参加関係者のそれぞれは、それぞれのｋのシェアに基づいてＲのシェアを計算し、上記のように、計算されたＲのシェアを他の２つの関係者のそれぞれに分配できる。それぞれの関係者は、Ｒの３つのシェア、つまり、関係者自体で計算されたシェアと、他の２つの参加関係者から受信した２つのシェアを所有する。３つの関係者全てがオネストである場合、Ｒはこれらのシェアの２つの任意の組み合わせから正しく計算され得る。したがって、関係者は、利用可能なシェアの２つの可能な組み合わせに基づいて、Ｒを計算する。この例では、（Ｒ_１，Ｒ_２）、（Ｒ_１，Ｒ_３）、および（Ｒ_２，Ｒ_３）の３つの組み合わせになる。３つの組み合わせ全てがＲの同じ値になる場合、３つの関係者全てがオネストであり、Ｒが正しいと結論付けることができる。少なくとも１つの組み合わせに基づいて計算されたＲの値が、他の組み合わせのいずれかに基づいて計算されたＲの値と異なる場合、少なくとも１つの関係者が不正であると結論付けることができる。しかし、どの関係者が不正であるかを判断できないため、いずれのＲの計算値が正しいかを判断することはできない。この場合、Ｒが正しくないと単純に判断され、署名処理が中止され得る。これにより署名処理が遅れる可能性があるが、秘密は明らかにされない。

【0048】

値Ｒを計算するステップ、およびＲが正しいことを確認するステップは、逆の順序で実行できる。すなわち、関係者は、値Ｒを計算する前に、受信したシェアＲ_ｊが正しいことを確認できる。値Ｒは、正しいことがわかった場合にのみ計算されてもよい。

【0049】

値Ｒを計算するステップ、および認証符号Ｗを計算するステップは、同じプロトコルを使用して実行できる。例えば、認証符号Ｗを計算するステップは、本質的に、値Ｒに関連する上記の方法で実行され得るが、ｇの代わりにＲを基礎として使用することによって実行され得る。したがって、この場合、少なくとも２つの関係者のそれぞれが認証符号ＷのシェアＷ_ｊをＷ_ｊ＝Ｒ^ａ＿ｊとして計算し、シェアを他の関係者のそれぞれに分配し、認証符号ＷはシェアＷ_ｊから計算され、関係者のそれぞれは、他の関係者から受信したシェアＷ_ｊに基づいて、例えば上記の方法で、Ｗが正しいことを確認する。

【0050】

この方法は、ＲまたはＷが正しくないことが明らかになった場合に、署名処理を中止するステップをさらに含み得る。これにより、秘密鍵が悪意のある関係者に公開されないことが保証される。しかし、署名処理が中止された場合、有効な署名の取得を再試行するために処理を再開しても安全であることが証明できる。

【0051】

この方法は、ｗを検証するステップがｇ^ｗ≠Ｗを明らかにする場合、署名処理を中止するステップをさらに含み得る。ｇ^ｗ≠Ｗであることが判明した場合、ｗ≠ａｋであると結論付けることができ、その結果、［ｗ］に基づいて有効な署名は取得され得ない。この場合、署名値ｓを計算して公開しようとすると、悪意のある関係者に秘密鍵ｘに関する情報が公開されることによって、機密性が損なわれる可能性がある。したがって、この場合、上記の状況と同様に、署名処理が中止され、署名処理が再開され得る。

【0052】

メッセージに署名するステップＭは、［ｗ］を開き、［ｓ］＝ｍｗ^－１［ａ］＋ｒｗ^－１［ａ］［ｘ］＋［ｄ］＋ｍ［ｅ］を計算することによって実行され得る。ここで、ｒ＝Ｆ（Ｒ）、ｍ＝Ｈ（Ｍ）、および［ｄ］と［ｅ］は、ゼロのランダムなシェア（いわゆる「ブラインダシェア」）である。

【0053】

いくつかの種類の秘密分散方式では、積［ａｘ］＝［ａ］［ｘ］が計算されると、［ａｘ］のシェアが秘密ａおよびｘについてあまりにも多くの情報を明らかにし得るため、シェア［ａｘ］を開くことは安全ではない。

【0054】

これは、例えば、シェアがシャミアのシェアであって、各関係者が［ａ］および［ｘ］のシェアを乗算することによって［ａｘ］の関係者のシェアが得られる、本方法の第１の実施形態の場合である。この場合、［ａｘ］のシェアはランダムではなく、［ａｘ］を公開するとａまたはｘに関する情報を漏洩する可能性がある。これを回避するために、関係者はランダムなシェアを有することがわかっているゼロ［０］のシェアを最初に計算し、代わりに［ａｘ］＋［０］を開く。［０］を追加しても結果は変わらないが、値ａｘが、［ａｘ］を開いたときに公開される唯一の情報であることが保証される。

【0055】

したがって、［ｓ］は、最初にｍｗ^－１［ａ］＋ｒｗ^－１［ａ］［ｘ］として計算される。この時点でｗが正しいことがわかっているため、［ａ］［ｘ］が正しいと仮定すると、これは［ｓ］＝［ｋ^－１（ｍ＋ｒｘ）］、つまり［ｓ］が、ＤＳＡまたはＥＣＤＳＡによって定められる正しい署名値ｓのシェアであることに留意すべきである。しかし、［ｓ］を開く前に、ゼロシェア［ｄ］が追加される、つまり、［ｓ］＋［ｄ］が開かれる。ｄ＝０であるため、ｄをｓに追加してもｓの値は変更されない。

【0056】

上記されているように、ｗの正しさが確実とされるとすると、いくつかの実施形態では、乗算［ａ］［ｘ］が正しくない可能性がある弱い乗算である場合であっても、上記で計算された署名（ｒ，ｓ）を明らかにしても、正しく計算された署名以上に秘密鍵ｘについて何も漏洩しないことが数学的に証明され得る。［ａ］［ｘ］が正しくない場合に発生する唯一のことは、得られた値（ｒ，ｓ）が有効な署名ではないということである。これは、メッセージＭと公開検証鍵ｙを使用して署名（ｒ，ｓ）を検証するだけで、各関係者によって決定され得る。無効な場合、関係者は署名処理を再開できる。

【0057】

いくつかの実施形態では、［ｓ］＋［ｄ］を開くことは安全であると証明できるが、証明は、オネストな関係者が最初にメッセージＭに署名することに同意することを前提としている。Ｍに同意しない場合、秘密鍵ｘに関する意図しない情報が漏洩し得る。したがって、本明細書に記載の第１の実施形態などのいくつかの実施形態では、関係者は、代わりに、［ｓ］＋［ｄ］＋ｍ・［ｅ］を計算して開くことができる。ここで、［ｄ］および［ｅ］は、ゼロのランダムなシェアであり、ｍ＝Ｈ（Ｍ）である。これらの実施形態では、オネストな関係者が全て同じ値Ｍを使用しなくても、当該シェアを開くことは安全であることが示され得る。オネストな関係者がＭに同意する場合、［ｄ］＋ｍ・［ｅ］は、結果［ｓ］がｘに関する情報を公開することなく開かれ得ることを保証するゼロシェアに変化する。反対に、いくつかの関係者が異なる値のＭを保持している場合、［ｄ］＋ｍ・［ｅ］を［ｓ］に追加すると、［ｓ］が完全にランダムなシェアになり、プロトコルが中止されるが、ｘに関する情報は漏洩しない。これにより、関係者が［ｓ］を開く前にＭの同じ値を使用することを最初に確認する必要がないという特性を実現する。これは、関係者が［ｓ］を開く前にＭの値に同意することを保証するために、さらなる相互作用のラウンドを費やす必要がないことを意味するため、これは実用上重要であり得る。

【0058】

本方法の代替の実施形態では、シェアは加法分散であり得、ペイエの暗号化方式などの加法準同型暗号化方式を使用して、乗算［ａｘ］＝［ａ］［ｘ］を実装する。ここで、ａまたはｘに関する情報を漏洩せずに、積［ａｘ］＝［ａ］［ｘ］のシェアを安全に明らかにできるようにするために、［ａｘ］を計算する処理において、例えば非対話型ゼロ知識照明などの、ゼロ知識証明を含む必要があり得る。処理にそのようなゼロ知識証明を含めることは、例えば、ペイエの暗号化が使用される場合、当業者によって適用され得る公知の技術である。

【0059】

少なくとも、秘密鍵ｘを生成するステップと、ランダムな秘密シェア［ａ］および［ｋ］を生成するステップと、値Ｒを計算するステップと、認証符号Ｗを計算するステップとは、メッセージＭの生成の前に、前処理によって実行され得る。本実施形態によれば、例えば、鍵ペア（［ｘ］，ｙ）を生成するステップと、ＲおよびＷを計算するステップと、ＲまたはＷの正確さを保証するステップと、ゼロシェア［ｄ］および［ｅ］を生成するステップと、シェア［ｗ］を計算するステップと、［ｗ］を開くステップと、ｇ^ｗ＝Ｗであることを確認するステップと、および／または［ａｘ］＝［ａ］［ｘ］を計算するステップとを含むステップのいくつかは、署名されるメッセージＭが関係者に知られる前に実行され得る。上記のように、これにより、デジタル署名が提供されるときに、実行されるステップの数が減り、それによって、処理要件および応答時間が減る。

【0060】

シャミアの秘密シェアなど、多くの種類の秘密シェアには、次の特性がある。例えば［ａ］と［ｘ］など、２つのシェアが与えられると、２つの秘密の合計のシェア［ａ＋ｘ］は関係者の間での相互作用なしに計算され得る。さらに、全ての関係者が特定の公開値ｃを知っている場合、関係者は相互作用なしに積［ｃ・ｘ］のシェアを計算できる。このような秘密分散方式は、「線形」秘密分散方式と呼ばれる。

【0061】

そのような線形秘密シェアが使用される本発明のいくつかの実施形態によれば、前処理段階において、署名されるメッセージＭを知る前に、［ｘ］、［ａ］、ｙ、Ｒ、Ｗ、［ａｘ］およびｗを生成することによって、並びにＲおよびｗの正しさを検証することによって、Ｍが関係者に知られるようになると、関係者は相互作用なしにｒと［ｓ］を生成できる。この理由は、前処理ですでに生成および検証されたシェアおよび値を使用することにより、ｒがそれぞれの関係者によってｒ＝Ｆ（Ｒ）として局所的に計算され得、さらに［ｓ］がシェアの加算およびシェアと公開定数との乗算のみによって計算され得るからである。

【0062】

さらに、いくつかの実施形態によれば、前処理によっていくつかのステップを実行することによって、Ｍが関係者に知られると、最終的な署名（ｒ，ｓ）は、単一ラウンドの相互作用を行うことで受信側の関係者に公開されてもよく、このラウンドでは、それぞれの関係者がＲ、およびその［ｓ］のシェアを受信側の関係者に送信する。

【0063】

さらに、いくつかの実施形態によれば、前処理によっていくつかのステップを実行することによって、Ｍが関係者に知られるようになると、最終的な署名（ｒ，ｓ）は、いくつかの関係者のみが、それらの［ｓ］のシェアを受信関係者に送信する、単一ラウンドの相互作用を行うことで受信関係者に公開され得る。例えば、第１の実施形態では、［ｓ］は、次数２ｔのシャミアのシェアであり、したがって、２ｔ＋１個の関係者が、それらのシェアを単一ラウンドの相互作用で受信関係者に送信することで十分である。

【0064】

線形秘密シェアが使用されるいくつかの実施形態によれば、さらなる前処理ステップを実行することによって、Ｍが与えられると、最終的な署名（ｒ，ｓ）は、関係者のｔ＋１個のみが、Ｒ、およびそれらの［ｓ］のシェアを受信関係者に送信する、単一ラウンドの相互作用で受信関係者に公開され得る。例えば、［ａｘ］が次数２ｔのシャミアのシェアであるいくつかの実施形態では、安全なマルチパーティ計算の分野で知られている標準的な手法を使用して、前処理ステップで［ａｘ］の次数をｔに減らすことができる。これにより、［ｓ］の次数は同様にｔになるため、［ｓ］のｔ＋１個のシェアのみに基づいて、受信関係者がｓを再構築できる。

【0065】

さらに、本発明の一実施形態によれば、シェア［ａｘ］が値ａｘの正しいシェアであることを確実にするために、さらなる前処理ステップが実行され得る。これは、安全なマルチパーティ計算の分野の標準的な手法で実行され得る。これを行うことにより、前処理ステップ中に処理が中止されない場合、特定の数のオネストな関係者、例えば２ｔ＋１個またはｔ＋１個のオネストな関係者が、最大ｔ個の悪意のある関係者が有効な署名の公開を妨げようとしても、有効な署名（ｒ，ｓ）を開くことができることが保証され得るという特性が達成される。

【0066】

このように通信を簡素化することにより、例えば、署名されるメッセージＭが関係者に知られると必要となる、相互作用のラウンドの数、およびｓの再構築に必要なシェアの数を最小限に抑えることで、マルチパーティ署名方式の実際の適用に利益をもたらすことができる。

【0067】

本方法は、公開鍵ｙをｙ＝ｇ^ｘとして計算し、少なくとも２つの関係者のそれぞれにｙを公開するステップをさらに含み得る。本実施形態によれば、秘密鍵［ｘ］および公開鍵ｙ＝ｇ^ｘの形態の鍵ペアが生成される。当該鍵ペアは、デジタル署名を生成するために使用される。

【0068】

本方法は、公開鍵ｙを使用して署名を検証するステップをさらに含み得る。これは、例えば、ｒ＝Ｆ（ｇ^ｍ／ｓ・ｙ^ｒ／ｓ）であるかどうかを確認することを含み得る。代替的または付加的に、当該ステップは、Ｒ^ｓ＝ｇ^ｍ・ｙ^ｒであるかどうかを確認することを含んでもよい。

【0069】

これは、例えば、少なくとも２つの関係者のそれぞれが、公開検証鍵ｙを使用して、署名の正しさを検証することを含み得る。これは、例えば、Ｒ^ｓ＝ｇ^ｍ・ｙ^ｒを確認することを含み得る。関係者がこれが当該事例に該当すると判断した場合、関係者は、署名（ｒ，ｓ）を受け入れ、結果としてそれを出力する。そうでない場合、関係者は署名処理を中止してもよい。

【0070】

本方法の別の実施形態では、得られた署名（ｒ，ｓ）を受信する必要があるのは、関係者自体ではなく、外部の関係者である。この場合、各関係者Ｐ_ｊは、上記のようにＲと秘密シェア［ｓ］のシェアｓ_ｊとを計算する。各関係者はＲとｓ_ｊを外部の関係者に送信する。外部の関係者は、全ての受信した値Ｒを比較し、値が等しくない場合は中止する。次に、ｒ＝Ｆ（Ｒ）を計算し、多項式補間を介してシェアｓ_ｊからｓを計算し、公開鍵ｙを使用してＲ^ｓ＝ｇ^ｍ・ｙ^ｒであることを検証する。そうである場合、関係者は得られた署名として（ｒ，ｓ）を受け入れる。

【0071】

本方法は、ｙの正しさを確認するステップをさらに含み得る。本発明の一実施形態によれば、当該ステップは、ランダムなシェア［ｋ］を生成し、公開し、Ｒ＝ｇ^ｋの正しさを検証するのと同じ方法で、最初にランダムなシェア［ｘ］を生成し、次にｙ＝ｇ^ｘを公開しｙの正しさを確認するステップを含み得る。

【図面の簡単な説明】

【0072】

【図1】図１は、本発明の第１の実施形態による方法を使用した鍵生成および署名生成を示すブロック図である。

【図2】図２は、本発明の第２の実施形態による方法を使用した鍵生成を示すブロック図である。

【図3a】図３ａは、本発明の第３の実施形態による方法を使用した署名生成を示すブロック図である。

【図3b】図３ｂは、本発明の第３の実施形態による方法を使用した署名生成を示すブロック図である。

【図4】図４は、本発明の第４の実施形態による方法を使用した署名生成を示すブロック図である。

【図5】図５は、本発明の第５の実施形態による方法を使用した鍵生成および署名生成を示すブロック図である。

【図6】図６は、本発明の実施形態による方法を示すフローチャートである。

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

【0073】

本発明は、添付の図面を参照してさらに詳細に説明される。

【0074】

図１は、本発明の第１の実施形態による方法を使用した鍵生成および署名生成を示すブロック図である。本方法は、３つの関係者Ｐ１、Ｐ２およびＰ３をしようすることを含む。ここで、３つの関係者Ｐ１、Ｐ２およびＰ３は、関係者Ｐ１、Ｐ２、Ｐ３の一つに利用可能である情報が他の関係者Ｐ１、Ｐ２、Ｐ３に利用できないという意味で、個別または別個のものである。関係者Ｐ１、Ｐ２、Ｐ３は、例えば、互いに物理的に分離された複数のハードウェアサーバの形態であり得る。当該例では、セキュリティ閾値（ｔ）は１である。つまり、関係者Ｐ１、Ｐ２、Ｐ３の一つが悪意のある場合、その関係者は、他の（オネストな）関係者がＭに署名することを同意しない限り、ｘに関する情報を学習できず、または秘密鍵ｘを用いてメッセージＭに署名できない。

【0075】

クライアント１は、要求「鍵生成」を関係者Ｐ１、Ｐ２、Ｐ３のそれぞれに送信し、関係者Ｐ１、Ｐ２、Ｐ３が秘密鍵［ｘ］および公開鍵ｙを含む鍵ペア（［ｘ］，ｙ）を生成するように要求する。クライアント１は、３つの関係者Ｐ１、Ｐ２、Ｐ３を含むシステムを取り巻く環境に配置されている。すなわち、クライアントは、鍵および署名を生成するシステムの一部を形成していない。

【0076】

要求「鍵生成」の受信に応答して、３つの関係者Ｐ１、Ｐ２、Ｐ３は、３つの関係者Ｐ１、Ｐ２、Ｐ３間でのランダムな秘密シェアとして秘密鍵［ｘ］を生成する。これは、例えば、関係者Ｐ１、Ｐ２、Ｐ３間のいくつかのラウンドの相互作用を含み得、そしてそれは、例えば、図２を参照して後述される方法で実行され得る。結果として、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれが秘密鍵ｘのシェアｘ１、ｘ２、ｘ３を保持するが、関係者Ｐ１、Ｐ２、Ｐ３のいずれも秘密鍵ｘ全体を所有していない。

【0077】

３つの関係者Ｐ１、Ｐ２、Ｐ３は、公開鍵ｙをｙ＝ｇ^ｘとしてさらに計算する。公開鍵ｙは、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれがｙを所有しているという意味で、およびｙが関係者Ｐ１、Ｐ２、Ｐ３のそれぞれによってクライアント１に伝達されるという意味で公にされる。したがって、ｙ＝ｇ^ｘは公にされまたは「公開される」が、ｘは秘密のままである。

【0078】

関係者Ｐ１、Ｐ２、Ｐ３のいずれも悪意がない、または損なわれていない場合、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれによってクライアント１に通信される公開鍵ｙは同じになる。つまり、クライアント１は３つの関係者Ｐ１、Ｐ２、Ｐ３からのｙの３つの同一バージョンを受信する。したがって、クライアント１が３つの同一バージョンのｙを受信した場合、関係者Ｐ１、Ｐ２、Ｐ３のいずれも悪意がない、または損なわれていない、つまり、関係者Ｐ１、Ｐ２、Ｐ３の全てはこれまで正しく動作した、と結論付けることができる。一方、３つの関係者Ｐ１、Ｐ２、Ｐ３から受信したｙの３つのバージョンが互いに異なる場合、関係者Ｐ１、Ｐ２、またはＰ３のうちの少なくとも１つは悪意があるか、または損なわれていると結論付けることができる。その場合、クライアント１は処理を中止させる。

【0079】

鍵ペア（［ｘ］，ｙ）が生成されると、生成された鍵ペア（［ｘ］，ｙ）を適用する署名処理が、クライアント１が要求、署名、および署名されるメッセージＭを関係者Ｐ１、Ｐ２、Ｐ３のそれぞれに送信することによって開始される。

【0080】

要求、署名、およびメッセージＭの受信に応答して、関係者Ｐ１、Ｐ２、Ｐ３は、関係者間のいくつかのラウンドの相互作用を必要とし得る署名生成処理に参加し、それぞれの関係者Ｐ１、Ｐ２、Ｐ３が他の関係者にシェアｘ１、ｘ２、ｘ３を公開することなく、［ｘ］のシェアｘ１、ｘ２、ｘ３を適用する。署名生成処理の最後に、それぞれの関係者Ｐ１、Ｐ２、Ｐ３は、値Ｒと、［ｓ］のシェアｓ１、ｓ２、ｓ３とを所有している。署名生成処理は、例えば、図３を参照して後述する方法で実行され得る。

【0081】

次に、それぞれの関係者Ｐ１、Ｐ２、Ｐ３は、Ｒと、［ｓ］のシェアｓ１、ｓ２、またはｓ３をクライアント１に返す。これに応答して、クライアント１は、例えば補間を使用して、受信したシェアｓ１、ｓ２、ｓ３からｓを計算する。さらに、クライアント１は、ｒ＝Ｆ（Ｒ）を計算し、３つの関係者Ｐ１、Ｐ２、Ｐ３のうちの少なくとも２つから同一バージョンのＲが受信された場合にのみ、有効な署名として（ｒ，ｓ）を受け入れることができる。さらに、クライアント１は、署名（ｒ，ｓ）を有効な署名として受け入れるために、さらなる検証確認（例えば、Ｒ^ｓ＝ｇ^ｍ・ｙ^ｒの検証）を実行してもよい。

【0082】

図２は、本発明の第２の実施形態による方法を使用した鍵生成を示すブロック図である。図２に示される鍵生成は、例えば、図１に示される方法の一部として適用され得る。

【0083】

図２に示される実施形態では、３つの関係者Ｐ１、Ｐ２、Ｐ３は、鍵ペア（［ｘ］，ｙ）を計算する際に協働する。ここで、［ｘ］は、３つの関係者Ｐ１、Ｐ２、Ｐ３間での秘密シェアの形態の秘密鍵であり、ｙは公開鍵である。本実施形態によれば、シェアはシャミアの秘密シェアであり、セキュリティ閾値は１、すなわちｔ＝１である。

【0084】

関係者Ｐ１、Ｐ２、Ｐ３間の第１のラウンドの相互作用では、秘密鍵［ｘ］が、関係者Ｐ１、Ｐ２、Ｐ３間でのランダムな次数ｔのシャミアの秘密シェアとして生成される。この目的のために、それぞれの関係者Ｐ１、Ｐ２、Ｐ３は、３つのランダム値を生成し、１つはそれ自体用であり、１つは他の関係者Ｐ１、Ｐ２、Ｐ３のそれぞれ用であり、生成された値をそれぞれの他の関係者Ｐ１、Ｐ２、Ｐ３に転送する。したがって、関係者Ｐ１は、値ｘ１，１を生成してそれ自体を保持し、値ｘ１，２を生成して関係者Ｐ２に転送し、値ｘ１，３を生成して関係差Ｐ３に転送する。同様に、関係者Ｐ２は、値ｘ２，１を生成して関係者Ｐ１に転送し、値ｘ２，２を生成してそれ自体を保持し、値ｘ２，３を生成して関係者Ｐ３に転送する。最後に、関係者Ｐ３は、値ｘ３，１を生成して関係者Ｐ１に転送し、値ｘ３，２を生成して関係者Ｐ２に転送し、値ｘ３，３を生成してそれ自体を保持する。

【0085】

したがって、関係者Ｐ１、Ｐ２、Ｐ３間の第１のラウンドの相互作用の終わりに、それぞれの関係者Ｐ１、Ｐ２、Ｐ３は、３つのランダムな値、すなわち、それ自体によって生成された値および他の関係者Ｐ１、Ｐ２、Ｐ３のそれぞれから受信した値を所有している。これらの３つの値に基づいて、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、［ｘ］のシェアｘ１、ｘ２、ｘ３を生成する。

【0086】

関係者Ｐ１、Ｐ２、Ｐ３間の第２のラウンドの相互作用では、関係者Ｐ１、Ｐ２、Ｐ３は、公開鍵ｙを計算する。この目的のために、それぞれの関係者は、ｙｉ＝ｇ^ｘｉを計算する。ここで、ｇは、巡回群Ｇの生成元であり、ｙｉは関係者Ｐｉによって生成された値であり、ｘｉは関係者Ｐｉによって保持される［ｘ］のシェアである。さらに、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、値ｙｉを他の関係者Ｐ１、Ｐ２、Ｐ３のそれぞれに伝達する。したがって、関係者Ｐ１はｙ１＝ｇ^ｘ１を計算し、ｙ１を関係者Ｐ２およびＰ３に通信、等を行う。したがって、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、３つの値ｙ１、ｙ２、およびｙ３のそれぞれを所有している。

【0087】

次に、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、他の２つの関係者から受信した値ｙｉが信頼できるものであることを確認する。これは、例えば、指数での補間の実行を含んでもよい。関係者Ｐ１、Ｐ２、Ｐ３の１つが、他の関係者の少なくとも１つから受信した値ｙｉが信頼できないと結論付けた場合、その関係者Ｐ１、Ｐ２、Ｐ３は「中止」信号を出力し、署名処理は、その結果、中止される。

【0088】

上記のように関係者Ｐ１、Ｐ２、Ｐ３のいずれも「中止」を出力しない場合、署名処理を続行することが許可され、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、値ｙ１、ｙ２、ｙ３に基づいて、および補間を使用して、公開鍵ｙを生成する。ＤＳＡ／ＥＣＤＳＡ標準によると、ｙ＝１は不正な公開鍵であるため、この場合は処理を中止する必要がある。プロトコルを中止した場合、プロトコルが再起動され、別の鍵ペアが生成され得ることに留意すべきである。ｙ≠１だと分かった場合、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、関係者Ｐ１、Ｐ２、Ｐ３間の第３のラウンドの相互作用の一部として、「ＯＫ」信号を他の関係者Ｐ１、Ｐ２、Ｐ３のそれぞれに転送する。関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、他の関係者Ｐ１、Ｐ２、Ｐ３のそれぞれから「ＯＫ」信号を受信した場合にのみ、ｙの自身のバージョンを受け入れる。それ以外の場合、署名処理は中止される。

【0089】

上記のように他の関係者Ｐ１、Ｐ２、Ｐ３から「ＯＫ」信号が受信された場合、公開鍵ｙが出力される。

【0090】

図３は、本発明の第３の実施形態による方法を使用した署名生成を示すブロック図である。図２のように、秘密シェアはシャミアのシェアであり、セキュリティ閾値は１（ｔ＝１）である。処理は、図３ａで始まり、図３ｂに続く。図３に示される署名生成は、例えば、図１に示される方法の一部として適用され得る。

【0091】

図３に示される実施形態では、３つの関係者Ｐ１、Ｐ２、Ｐ３は、秘密鍵［ｘ］を使用して、３つの関係者Ｐ１、Ｐ２，Ｐ３間の秘密シェアの形で、メッセージＭの署名（ｒ，ｓ）の生成に協働する。秘密鍵［ｘ］は、例えば、図２に関する上記の方法で、次数ｔのシャミアのシェアとして生成され得る。

【0092】

図３ａに示されている関係者Ｐ１、Ｐ２、Ｐ３間の第１のラウンドの相互作用では、関係者はランダムな次数ｔの秘密シェア［ｋ］および［ａ］を生成する。これは、基本的に、［ｘ］の生成について図２に関する上記で説明された方法で実行される。関係者はまた、３つのランダムな次数２ｔのゼロシェア［ｂ］、［ｄ］および［ｅ］、つまりブラインドシェアを生成する。したがって、関係者Ｐ１、Ｐ２、Ｐ３間の第１のラウンドの相互作用の終了時に、それぞれの関係者Ｐ１、Ｐ２、Ｐ３は、［ｋ］、［ａ］、［ｂ］、［ｄ］および［ｅ］のそれぞれのシェアを保持し、および関係者Ｐ１、Ｐ２、Ｐ３のいずれも、秘密ａおよびｋに関する情報を所有していない。

【0093】

次に、図３ａにも示されている関係者Ｐ１、Ｐ２、Ｐ３間の第２のラウンドの相互作用で、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれが値ＲｉをＲｉ＝ｇ^ｋｉとして計算する。ここで、ｇは巡回群Ｇの生成元であり、Ｒｉは関係者Ｐｉによって計算された値であり、ｋｉは関係者Ｐｉによって保持されている［ｋ］のシェアである。したがって、関係者Ｐ１はＲ１＝ｇ^ｋ１を計算し、関係者Ｐ２はＲ２＝ｇ^ｋ２を計算し、関係者Ｐ３はＲ３＝ｇ^ｋ３を計算する。

【0094】

さらに、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、値ｗｉをｗｉ＝ｋｉ・ａｉ＋ｂｉとして計算する。ここで、ｗｉは関係者Ｐｉによって計算された値であり、ｋｉ、ａｉおよびｂｉはそれぞれ、関係者Ｐｉによって保持されている［ｋ］、［ａ］および［ｂ］のシェアである。したがって、関係者Ｐ１はｗ１＝ｋ１・ａ１＋ｂ１を計算し、関係者Ｐ２はｗ２＝ｋ２・ａ２＋ｂ２を計算し、関係者Ｐ３はｗ３＝ｋ３・ａ３＋ｂ３を計算する。関係者によって保有されるシェアｗ１、ｗ２、ｗ３は、次数２ｔのシャミアのシェア［ｗ］を形成する。ここで、全ての関係者が所定の動作を正しく実行した場合、ｗはａｋに等しくなる。

【0095】

関係者のそれぞれは、計算された値Ｒｉおよびｗｉを他の関係者のそれぞれに公開する。そのため、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、３つの値Ｒ１、Ｒ２およびＲ３のそれぞれを所有し、３つのシェアｗ１、ｗ２およびｗ３のそれぞれを所有しており、したがってＲ＝ｇ^ｋおよびｗ＝ｋ・ａ＋ｂは、ｋとａのそれぞれが秘密のままであっても、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれによって知られるようになる。これは、Ｒおよびｗを「公開する（オープニング）」と呼ばれ得る。シェア［ｂ］は、［ａｋ］に追加しても秘密を変更せず、シェア［ａｋ］の個々のシェアを「ブラインド」し、それによって、積ａｋを除く［ａｋ］のシェアを確認することによりａまたはｋに関する情報を得ることを不可能にするため、「ブラインダシェア」と呼ばれ得る。

【0096】

関係者Ｐ１、Ｐ２、Ｐ３間の第２のラウンドの相互作用の最後に、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれがＲの正しさを確認する。これは、受信した値Ｒ１、Ｒ２およびＲ３に基づいて、指数の補間を使用して行われる。関係者Ｐ１、Ｐ２、Ｐ３の少なくとも１つがＲが正しくないことを発見した場合、処理は中止される。それ以外の場合、処理は続行される。

【0097】

次に、図３ｂに示す関係者Ｐ１、Ｐ２、Ｐ３間の第３のラウンドの相互作用において、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれが値ＷｉをＷｉ＝Ｒ^ａｉとして計算する。ここで、Ｗｉは関係者Ｐｉによって計算された値であり、ａｉは関係者Ｐｉによって保持されている［ａ］のシェアである。さらに、それぞれの関係者Ｐ１、Ｐ２、Ｐ３は、計算された値Ｗｉを他の関係者Ｐ１、Ｐ２、Ｐ３のそれぞれに明らかにする。したがって、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、値Ｗ１、Ｗ２、Ｗ３のそれぞれを所有しており、指数の補間を使用することにより、Ｗ＝Ｒ^ａは、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれによって計算され得るが、値ａは秘密のままである。これは、Ｗを「公開する」と呼ばれ得る。

【0098】

関係者Ｐ１、Ｐ２、Ｐ３間の第３のラウンドの相互作用の最後に、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、受信した値Ｗ１、Ｗ２、Ｗ３に基づいて、指数の補間を使用して、Ｗの正しさを確認する。これは、第２のラウンドの相互作用で値Ｒｉを使用してＲの正しさが確認されたのと同じ方法で、値Ｗｉを使用して行われる。関係者Ｐ１、Ｐ２、Ｐ３の少なくとも１つがＷが正しくないことを検出した場合、処理は中止される。それ以外の場合、処理は続行される。

【0099】

最後に、関係者Ｐ１、Ｐ２、Ｐ３間の第４のラウンドの相互作用では、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれが、値ｗ１、ｗ２、およびｗ３に基づいて、補間を使用してｗを計算する。

【0100】

さらに、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、Ｗ＝ｇ^ｗであることを確認することによってｗを検証する。上記のように、Ｗ＝Ｒ^ａおよびＲ＝ｇ^ｋであることが確実とされる。そうでない場合、処理は先に中止されていただろう。このことから、Ｗ＝ｇ^ｋａとなる。したがって、ｇ^ｗ＝Ｗを確認することにより、ｗ＝ａ・ｋであることが保証される。［ｗ］は、［ａ］［ｋ］としてではなく、［ａ］［ｋ］＋［ｂ］として計算されたが、［ｂ］はゼロのシェアであるため、つまり［ｂ］＝［０］であるため、［ｂ］を追加しても当該確認には何ら違いはないことに留意するべきである。

【0101】

関係者Ｐ１、Ｐ２、Ｐ３の少なくとも１つがＷ≠ｇ^ｗを検出した場合、署名処理は中止される。それ以外の場合、処理は続行され、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、シェア［ｓ］のシェアｓｉを次のように計算する。
ｓｉ＝ｍ・ｈｉ＋ｒ・ｈｉ・ｘｉ＋ｍ・ｄｉ＋ｅｉ
ここで、ｈｉ＝ａｉ・ｗ^－１であり、ｒ＝Ｆ（Ｒ）であり、ここでＦは事前定義された関数であり、ｍ＝Ｈ（Ｍ）、ここでＭは署名されるメッセージであり、Ｈは事前定義された関数である。

【0102】

ｘｉ、ｄｉおよびｅｉは、それぞれ、関係者Ｐｉによって保持されている［ｘ］、［ｄ］、および［ｅ］のシェアである。各関係者が上記のようにそのシェアｓｉを計算するとき、それは関係者が集合的に計算［ｓ］＝ｍ［ｋ^－１］＋ｒ［ｋ^－１］［ｘ］＋ｍ［ｄ］＋［ｅ］を実行することを意味する。全ての関係者が規定どおりに動作を実行すると、ＤＳＡまたはＥＣＤＳＡによって要求されるように［ｓ］＝［ｋ^－１（ｍ＋ｒｘ）］、つまりｓ＝ｋ^－１（ｍ＋ｒｘ）になる。

【0103】

関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、他の関係者Ｐ１、Ｐ２、Ｐ３のそれぞれにシェアｓｉを明らかにし、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、受信したシェアｓ１、ｓ２およびｓ３に基づく補間を使用してｓを計算する。そして、関係者Ｐ１、Ｐ２、Ｐ３は、公開鍵ｙを使用してメッセージＭの署名を検証することにより、つまりＲ＝ｇ^ｍ・ｙ^ｒを確認することにより、ｓの正しさを確認する。ｓの正しさが確認されると、署名（ｒ，ｓ）はメッセージＭの最終署名として受け入れられる。

【0104】

図４は、本発明の第４の実施形態による方法を使用した署名生成を示すブロック図である。図４に示されている処理は、３つの関係者Ｐ１、Ｐ２、Ｐ３間の６つのラウンドの相互作用を含む。関係者Ｐ１、Ｐ２、Ｐ３間の最初の３つのラウンドの相互作用は、図３に示され、上述された最初の３つのラウンドの相互作用と同じである。

【0105】

関係者Ｐ１、Ｐ２、Ｐ３間の第４のラウンドの相互作用では、関係者Ｐ１のみが図３に関する上記された方法でｓ１を計算する。すなわち、次の式である。
ｓ１＝ｍ・ｈ１＋ｒ・ｈ１・ｘ１＋ｍ・ｄ１＋ｅ１

【0106】

次に、Ｐ１は、ｓ１を関係者Ｐ２に転送し、関係者Ｐ１、Ｐ２、Ｐ３間の第５のラウンドの相互作用において、関係者Ｐ２は、図３に関する上記された方法でｓ２を計算し、ｓ１およびｓ２を関係者Ｐ３に転送する。

【0107】

関係者Ｐ１、Ｐ２、Ｐ３間の第６のラウンドの相互作用では、関係者Ｐ３は図３に関する上記された方法でｓ３を計算し、３つのシェアｓ１、ｓ２およびｓ３に基づいて、補間を使用して、ｓを計算する。そして、関係者Ｐ３はｓの正しさを確認し、ｓが正しければ、署名（ｒ，ｓ）は、メッセージＭの得られた署名（ｒ、ｓ）として関係者Ｐ３によって受け入れられる。

【0108】

したがって、図４に示される実施形態では、署名（ｒ，ｓ）は、関係者Ｐ３によってのみ受信され、一方、図３に示される実施形態では、関係者Ｐ１、Ｐ２、Ｐ３のそれぞれは、署名（ｒ、ｓ）を受信する。オンライン段階において、それぞれの関係者Ｐ１、Ｐ２、Ｐ３は１つの関係者に単一のメッセージを送信することだけが必要なのに対し、図３の実施形態では、それぞれの関係者は他の関係者のそれぞれにメッセージを送信する必要があるため、このような実施形態は実用的であり得る。

【0109】

図５は、本発明の第５の実施形態による方法を使用した鍵生成および署名生成を示すブロック図である。図５に示される実施形態は、図１に示される実施形態と非常に類似しているため、ここでは詳細に説明しない。

【0110】

しかしながら、図５に示される実施形態では、処理は、外部クライアントではなく、関係者の一つである関係者Ｐ１によって開始される。したがって、関係者Ｐ１は、図１の実施形態においてクライアントによって実行されるステップ、および図１の実施形態において関係者Ｐ１によって実行されるステップを実行する。

【0111】

図６は、本発明の実施形態による方法を示すフローチャートである。処理は、ステップ２で開始される。ステップ３では、巡回群Ｇ、および巡回群Ｇの生成元ｇが定められる。さらに、関数ＦとＨが定義されている。Ｇ、ｇ、ＦおよびＨは全て、デジタル署名の生成に使用されるデジタル署名アルゴリズム（ＤＳＡ）または楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）によって指定される。

【0112】

ステップ４では、ランダムな秘密シェア［ｘ］が少なくとも２つの関係者間で生成される。ここで、ｘは秘密鍵である。

【0113】

ステップ５では、ランダムな秘密シェア［ａ］および［ｋ］が少なくとも２つの関係者間で生成される。

【0114】

ステップ６で、関係者は［ｗ］＝［ａ］・［ｋ］を計算し、ステップ７で、関係者は値Ｒ＝ｇ^ｋを計算する。例えば、Ｒは、Ｒ_ｊ＝ｇ^ｋ＿ｊとしてシェアＲ_ｊを計算する関係者のそれぞれによって計算され得る。ここで、ｋ＿ｊは、関係者ｊによって保持されている［ｋ］のシェアであり、シェアＲ_ｊから値Ｒを計算する。

【0115】

ステップ８では、Ｒが正しいかどうかが調査される。正しくない場合、処理はステップ９に進められ、署名処理が中止され、処理は、新しい秘密シェア［ａ］および［ｋ］を生成するためにステップ５に戻される。

【0116】

ステップ８でＲが正しいことが明らかになった場合、署名処理は続行され得、処理はステップ１０に進められ、関係者は認証符号Ｗ＝ｇ^ａｋを計算する。これは、Ｒ^ａを計算することによって行われる。

【0117】

ステップ１１では、Ｗが正しいかどうかが調査される。正しくない場合、処理はステップ９に進められ、署名処理が中止され、処理は、新しい秘密シェア［ａ］および［ｋ］を生成するためにステップ５に戻される。

【0118】

ステップ１１でＷが正しいことを明らかになった場合、処理はステップ１２に進められ、ｇ^ｗ＝Ｗであるかどうかが調査される。Ｗ＝Ｒ^ａかつＲ＝ｇ^ｋであるため、Ｗ＝ｇ^ａｋである。ｗ＝ａ・ｋであるため、ｗが正しく計算されている場合、ｇ^ｗ＝Ｗである。したがって、ｇ^ｗ＝Ｗであることが確認できた場合、ｗは正しく計算されたと結論付けることができる。したがって、ステップ１２においてｇ^ｗ≠Ｗが明らかになった場合、処理はステップ９に進められ、署名処理が中止され、処理は、新しい秘密シェア［ａ］および［ｋ］を生成するためにステップ５に戻される。

【0119】

ステップ１２でｇ^ｗ＝Ｗであることが確認された場合、処理はステップ１３に進められ、関係者間でシェア［ｓ］が生成され、署名がメッセージに与えられる。最後に、署名はステップ１４で終了する。

【図1】

【図2】

【図3a】

【図3b】

【図4】

【図5】

【図6】