JP4588874B2 - 内在的証明書方式 - Google Patents

内在的証明書方式 Download PDF

Info

Publication number
JP4588874B2
JP4588874B2 JP2000538463A JP2000538463A JP4588874B2 JP 4588874 B2 JP4588874 B2 JP 4588874B2 JP 2000538463 A JP2000538463 A JP 2000538463A JP 2000538463 A JP2000538463 A JP 2000538463A JP 4588874 B2 JP4588874 B2 JP 4588874B2
Authority
JP
Japan
Prior art keywords
public
key
mod
public key
entity
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP2000538463A
Other languages
English (en)
Other versions
JP2002508529A (ja
JP2002508529A5 (ja
Inventor
ミンファ クゥ
スコット エイ. ヴァンストーン
Original Assignee
サーティコム コーポレーション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CA 2232936 external-priority patent/CA2232936C/en
Application filed by サーティコム コーポレーション filed Critical サーティコム コーポレーション
Publication of JP2002508529A publication Critical patent/JP2002508529A/ja
Publication of JP2002508529A5 publication Critical patent/JP2002508529A5/ja
Application granted granted Critical
Publication of JP4588874B2 publication Critical patent/JP4588874B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

【0001】
本発明は、暗号化鍵の転送および認証のための鍵配送方式に関する。
【0002】
(発明の背景)
Diffie−Hellman鍵共有(Diffie-Hellman key agreement)は、暗号システムでの鍵配送問題(Key distribution problem)に対する最初の実用的な解決策をもたらした。この鍵共有プロトコルでは、事前に会ったことも共有(分散)鍵材料(shared key material)を有したこともない2つの当事者が、オープンな(保護されない)チャネルを介してメッセージ(文書)を交換することによって、共有される秘密(shared secret)を確立することができる。セキュリティは、Diffie−Hellman問題の扱い難さと、関連する離散対数の計算問題にかかっている。
【0003】
インターネットおよび類似物の出現に伴って、公開鍵(Public key;パブリック・キー)および公開鍵証明書(Public key certificate)の大規模な配送の必要が、ますます重要になりつつある。公開鍵証明書は、それによって、検出不能な改ざんの危険性(danger of undetectable manipulation)なしに、保護されない媒体(unsecured media)を介して公開鍵を格納、配送、または転送することのできる媒介物(vehicle)である。その目的は、一方の当事者の公開鍵を他方の当事者が入手できるようにし、その認証性(authenticity)および有効性(validity)を検証可能に(verfiable)することである。
【0004】
公開鍵証明書は、データ部分および署名部分からなるデータ構造を有する。データ部分には、最低限として公開鍵およびそれに関連する当事者を識別する文字列を含む平文データが含まれる。署名部分は、データ部分に対する認証機関(certification authority、CA)のディジタル署名からなり、これによって、エンティティのアイデンティティ(identity;個人情報)が、指定された公開鍵と結びつけられる。CAは信頼できる第三者であり、証明書のCAの署名は対象のエンティティに結びつけられた公開鍵の認証性(Authenticity)を保証する。
【0005】
アイデンティティに基づくシステム(IDに基づくシステム)は、通常の公開鍵システムに類似し、秘密変換(private transformation)と公開変換(public transformation)を用いるが、当事者は、以前のように明示的な公開鍵を有しない。その代わりに、公開鍵は、効果的に、一般に入手可能な当事者のアイデンティティ情報(たとえば氏名またはネットワーク・アドレス)に置換される。当事者を一意に識別し、その当事者に否定不能な形で(undeniably)関連付けることができる、一般に入手可能な情報であれば、どのような情報でもアイデンティティ情報として使用可能である。
【0006】
公開鍵配送の代替手法では、内在的に証明される公開鍵(Implicitly certified public keys)が使用される。この場合、明示的なユーザー公開鍵が存在するが、その鍵は、証明書に基づくシステムのように公開鍵証明書(public-key certificate)によって運ばれるのではなく、再構成(reconstruct)されなければならない。したがって、内在的に証明される公開鍵は、公開鍵(たとえばDiffie−Hellman鍵)を配送するための代替手段として使用することができる。
【0007】
内在的に証明される公開鍵機能の1例が、Guntherの内在的に証明される(IDに基づく)公開鍵方法である。この方法では、
1.信頼できるサーバT(trusted server)が、適当な固定された公開の素数p、およびZp *のジェネレータαを選択する。Tは、1≦t≦p−2かつgcd(t,p−1)=1であるランダムな整数tをその秘密鍵(private key)として選択し、公開鍵u=αt mod pをαおよびpと共に公開する。
【0008】
2.Tは、各当事者Aに、一意の名前または識別する文字列IAおよび、gcd(kA、p−1)=1であるランダムな整数kA、を割り当てる。Tは、その後、
【0009】
【数1】
Figure 0004588874
【0010】
を計算する。PAは、Aの鍵再構成公開データであり、これを用いて、他の当事者が、以下で示すように(PAaを計算することができるようになる。
【0011】
3.適当なハッシュ関数hを使用して、Tは、aについて下の式を解く。
H(IA)≡t.PA+kAa(mod p−1)
4.Tは、IAに対するTのElGamal署名である対(r,s)=(PA,a)を、保護された形でAに送信する(aは、Diffie−Hellman鍵共有のためのAの秘密鍵である)。
【0012】
5.他の当事者は、次式を計算することによって、一般に入手可能な情報(α、IA、u、PA、p)だけから、AのDiffie−Hellman公開鍵PA αを再構成することができる。
【0013】
【数2】
Figure 0004588874
【0014】
したがって、離散対数問題の場合、証明書への署名は1回の累乗(exponentiation)演算を必要とするが、IDに基づく内在的に証明される公開鍵の再構成は、2回の累乗が必要である。群(group)Zp *での累乗およびE(Fq)内の点のアナログ・スカラ乗算は、計算量的に強烈(computationally intensive)であることが既知である。たとえば、RSA方式は、楕円曲線システムと比較して極端に低速である。しかし、RSAタイプのシステムに対するECシステムの明確な効率にもかかわらず、これは、特に「スマート・カード」、ポケット・ベル、および類似物などの限られた計算能力を有するコンピューティング装置にとって、まだ問題である。
【0015】
(発明の概要)
本発明は、既存の方式に対して改良された計算速度をもたらす、効率的なIDに基づく内在的証明書方式の提供を試みる。便宜上、本明細書ではZpに対する方式を説明するが、これらの方式は、楕円曲線暗号システムでも同等に実施可能である。
【0016】
本発明によれば、少なくとも1つの信頼できるエンティティCAおよび加入者エンティティAを有する保護されたディジタル通信システム内でアイデンティティに基づく公開鍵を生成する方法であって、
(a)各エンティティAについて、CAが、エンティティAを区別する一意のアイデンティティIAを選択するステップと、
(b)信頼できる当事者CAのジェネレータをエンティティAの私的な値(private value)と数学的に組み合わせ、対(IA、γA)がAの内在的証明書として働くようにすることによって、エンティティAの公開鍵再構成公開データγAを生成するステップと、
(c)エンティティ情報fを導出するために、数学関数F(γA、IA)に従って内在的証明書情報(IA、γA)を組み合わせるステップと、
(d)エンティティ情報fに署名することによってエンティティAの秘密鍵を生成するステップと、
秘密鍵をエンティティAに送信するステップとを含み、
これによって、エンティティAの公開鍵を、公開情報、ジェネレータγA、およびアイデンティティIAから比較的効率的に再構成できるようにする方法が提供される。
【0017】
本発明のもう1つの態様によれば、異なるビット強度(bit strengths)を有する複数の公開鍵を含み、公開鍵の1つが内在的に証明される公開鍵になることを特徴とする、公開鍵証明書が提供される。
【0018】
(好ましい実施形態の詳細な説明)
図1を参照すると、内在的に証明される公開鍵(Implicitly certified public key)を有するシステムが、全般的に符号10によって示されている。このシステム10には、信頼できる第三者のCAおよび、少なくとも第1通信者Aおよび第2通信者Bの対が含まれる。通信者AおよびBは、通信チャネルを介して情報を交換し、通信者AおよびBのそれぞれには、認定/検証(finding/verification)および暗号化/非暗号化(解読)(encryption/decryption)を実行する暗号装置(cryptographic unit)が含まれる。
【0019】
図1を参照すると、信頼できる当事者CAは、大きい素数qについてp=tq+1である適当な素数pと、オーダー(order)qのジェネレータαを選択する。CAは、その秘密鍵として1≦c≦q−1のランダムな整数cを選択し、公開鍵β=αcを計算し、(β、α、p、q)を公開する。
【0020】
方式1:
1.各当事者Aについて、CAは、一意の区別される名前またはアイデンティティIA(たとえば、氏名、住所、電話番号)および、1≦cA≦q−1のランダムな整数cAを選択する。次に、CAは、
【0021】
【数3】
Figure 0004588874
【0022】
を計算する(γAは、当事者Aの公開鍵再構成公開データである。対(IA、γA)は、Aの内在的証明書として働く)。
【0023】
2.CAは、関数f=F(IA、γA)を選択する。たとえば、F(γA、IA)=γA+h(IA)またはF(γA、IA)=h(γA+IA)である。ここで、hは、安全なハッシュ関数であり、当事者Aの秘密鍵であるaについて次式を解く。a=0の場合には、CAは、別のcAを選択し、もう一度次式を解く。
1=cf+cAa(mod q)
3.CAは、3つ組(γA、a、IA)を保護された形でAに送信する。この3つ組は、IAに対するCAの署名である。ここで、
αは、Aの秘密鍵であり、
γAは、Aのジェネレータであり、
【0024】
【数4】
Figure 0004588874
【0025】
は、Aの公開鍵である。
Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算し、したがって公開鍵を導出することによって、公開ドメインから当事者Aの(IDに基づく)内在的に検証可能な公開鍵を得ることができる。
γA a=αβ-f(mod p)
このように上述の式から公開鍵を引き出すことは、ただ1つの累乗演算(exponentiation operation)を必要とする。
【0026】
誰でも公開データから当事者Aの公開鍵を再構成することができるが、これは、再構成された公開鍵γA aが証明されたことを意味しない。この方式は、当事者Aが対応する秘密鍵の完全な知識を有することを示すアプリケーション・プロトコルと組み合わされたときに、より効果的になる。たとえば、MQV鍵共有方式またはなんらかの署名方式、特にKCDSA(Korean Certificate based Digital Signature Algorithm)と組み合わされたときである。一般に、この内在的証明書方式は、証明書を検証することを必要とするどの方式とも、共に使用することができる。これは、DSA(Digital Signature Algorithm)署名方式に言及することによって実証することができる。
【0027】
アリスが、公開鍵α、ジェネレータγAを有し、公開ドメインで(α、IA、β、γA、p、q)を公開すると仮定する。次に、アリスは、DSAを使用してメッセージMに署名しようとする。
アリスは、下記を実行する。
1.ランダムにkを選択し、r=γA k(mod p)を計算する。
2.e=sha−1(M)を計算する。
3.s=k-1(e+ar)(mod p)を計算する。
4.Mに対する署名は、(r、s)になる。
【0028】
検証者は、下記を実行する。
1.アリスの公開データ(α、IA、β、γA、p、q)を取得し、公開鍵を再構成する。
δA=γA a=αβ-1(mod p)
2.e=sha−1(M)を計算する。
3.u1=es-1(mod q)およびu2=rs-1(mod q)を計算する。
4.
【0029】
【数5】
Figure 0004588874
【0030】
を計算する。
5.r=r’の場合には、署名が検証される。それと同時に、アリスの(IDに基づく)公開鍵が、内在的に検証される。
【0031】
対(IA、γA)は、アリスの証明書として働く。公開鍵の再構成は、アプリケーション・プロトコルが有効な検証をもたらすときに、内在的検証として働く。公開鍵を取得するために、1回の累乗演算だけが必要であることを想起されたい。
【0032】
代替実施形態では、署名方程式を適当に変更することによって、この方式をほとんどのElGamal署名方式に一般化することができる。以下の節で、いくつかの例を示す。
【0033】
方式2:
CAは、署名方程式l=ca+cAf(mod q)を使用する。CAは、3つ組(γA、a、IA)を保護された形でAに送信し、その後、aがAの秘密鍵、βがAのジェネレータ、βaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
βa=αγA -f(mod p)
この方式では、各ユーザーが、同一のジェネレータβを有し、このβは、CAの公開鍵である。
【0034】
方式3:
CAは、署名方程式a=cf+cA(mod q)を使用する。CAは、3つ組(γA、a、IA)を保護された形でAに送信し、その後、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
この方式では、CAを含む各ユーザーが、同一のジェネレータαを有する。
【0035】
方式4:
CAは、署名方程式a≡cAf+c(mod q)を使用する。CAは、3つ組(γA、a、IA)を保護された形でAに送信し、その後、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=γA fβ(mod p)
この方式では、CAを含む各ユーザーが、同一のジェネレータαを有する。
【0036】
上の方式では、ユーザーまたは当事者Aは、それ自体の秘密鍵を選択する権利を有しない。図2に示された以下の方式は、CAおよびユーザーの両方が、ユーザーの秘密鍵を制御するが、ユーザーだけがその秘密鍵を知っている。
【0037】
方式5’:
Aは、まず、整数kをランダムに選択し、αkを計算し、これをCAに送信する。CAは、
【0038】
【数6】
Figure 0004588874
【0039】
を計算し、kAについて以下の署名方程式を解く。
1=cf+cAA(mod q)
その後、CAは、
【0040】
【数7】
Figure 0004588874
【0041】
を計算し、3つ組(γA 1、kA、IA)をAに送信する。Aは、a=kA-1(mod q)およびγA=(γA 1k(mod p)を計算する。その後、aがAの秘密鍵、γAがAのジェネレータ、γA aがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
γA a=αβ-f(mod p)
方式6:
1.Aは、まず、整数kをランダムに選択し、βkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0042】
【数8】
Figure 0004588874
【0043】
およびf=F(γA、IA)を計算し、kAについて署名方程式を解く(kA=0の場合には、別のcAを選択する)。
1=ckA+cAf(mod q)
その後、CAは、
【0044】
【数9】
Figure 0004588874
【0045】
を計算し、3つ組(γA 1、kA、IA)をAに送信する。
注:(γA 1、kA、IA)は、公開チャネルによって送信することができる。
3.Aは、
【0046】
【数10】
Figure 0004588874
【0047】
、f=F(γA、IA)、およびa=kA−kf(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、βa=αγA -fであるかどうかを検査する。ここで、aがAの秘密鍵、βがAのジェネレータ、βaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
【0048】
βa=αγA -f(mod p)
方式7:
Aは、まず、整数kをランダムに選択し、αkを計算し、これをCAに送信する。ここでCAは、
【0049】
【数11】
Figure 0004588874
【0050】
を計算し、kAについて署名方程式を解く。
A≡cf+cA(mod q)
その後、CAは、
【0051】
【数12】
Figure 0004588874
【0052】
を計算し、3つ組(γA 1、kA、IA)をAに送信する。Aは、
【0053】
【数13】
Figure 0004588874
【0054】
を計算する。その後、a=kA+k(mod q)がAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
方式8:
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0055】
【数14】
Figure 0004588874
【0056】
およびf=F(γA、IA)を計算し、kAを計算する(kA=0の場合には、別のcAを選択する)。
A≡cAf+c(mod q)
その後、CAは、
【0057】
【数15】
Figure 0004588874
【0058】
を計算し、3つ組(γA 1、kA、IA)をAに送信する。
注:(γA 1、kA、IA)は、公開チャネルによって送信することができる。
3.Aは、
【0059】
【数16】
Figure 0004588874
【0060】
、f=F(γA、IA)およびa=kA+kf(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、αa=γA fβであるかどうかを検査する。ここで、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=γA fβ(mod p)
上の方式5〜8では、kAが公開チャネルによって送信されるので、誰もが、ユーザーAの秘密鍵αの部分的な情報を得ることができる。この情報を隠し、上の方式の計算を高速化するために、DES暗号化を導入して、方式5〜8を変更することによって、以下の方式9〜12を得た。方式9〜12の長所は、βが固定されているので、ユーザーが簡単にKを計算できることである。
【0061】
方式9:
1.Aは、まず、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0062】
【数17】
Figure 0004588874
【0063】
およびf=F(γA、β、IA)を計算し、kAについて署名方程式を解く(kA=0の場合には、別のcAを選択する)。
1=cf+cAA(mod q)
次に、CAは、K=(akc(mod p)および
【0064】
【数18】
Figure 0004588874
【0065】
を計算し、3つ組
【0066】
【数19】
Figure 0004588874
【0067】
をAに送信する。
3.Aは、K=βk(mod p)、
【0068】
【数20】
Figure 0004588874
【0069】
、およびa=kA-1(mod q)を計算する(a=1の場合には、ステップ1に戻る)。その後、γA a=αβ-fであるかどうかを検査する。ここで、aがAの秘密鍵、γAがAのジェネレータ、γA aがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
γA a=αβ-f(mod p)
方式10:
1.Aは、まず、整数kをランダムに選択し、βkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0070】
【数21】
Figure 0004588874
【0071】
およびf=F(γA、β、IA)を計算し、kAについて署名方程式を解く(kA=0の場合には、別のcAを選択する)。
1=ckA+cAf(mod q)
次に、CAは、
【0072】
【数22】
Figure 0004588874
【0073】
を計算し、3つ組
【0074】
【数23】
Figure 0004588874
【0075】
をAに送信する。
注:
【0076】
【数24】
Figure 0004588874
【0077】
は、公開チャネルによって送信することができる。
3.Aは、
【0078】
【数25】
Figure 0004588874
【0079】
を計算し、a=kA−kf(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、βa=αγA -fであるかどうかを検査する。ここで、aがAの秘密鍵、βがAのジェネレータ、βaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
βa=αγA -f(mod p)
方式11:
1.Aは、まず、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0080】
【数26】
Figure 0004588874
【0081】
およびf=F(γA、β、IA)を計算し、kAを計算する(kA=0の場合には、別のcAを選択する)。
A=cf+cA(mod q)
次に、CAは、K=(αkc(mod p)および
【0082】
【数27】
Figure 0004588874
【0083】
を計算し、3つ組
【0084】
【数28】
Figure 0004588874
【0085】
をAに送信する。
注:
【0086】
【数29】
Figure 0004588874
【0087】
は、公開チャネルによって送信することができる。
3.Aは、K=βk(mod p)、
【0088】
【数30】
Figure 0004588874
【0089】
、およびa=kA+k(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、αa=βfγAであるかどうかを検査する。ここで、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、αa=γA f(mod p)を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
【0090】
方式12:
1.Aは、まず、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0091】
【数31】
Figure 0004588874
【0092】
およびf=F(γA、β、IA)を計算し、kA(kA=0の場合には、別のcAを選択する)kA=cAf+c(mod q)を計算する。
次に、CAは、K=(αkc(mod p)および
【0093】
【数32】
Figure 0004588874
【0094】
を計算し、3つ組
【0095】
【数33】
Figure 0004588874
【0096】
をAに送信する。
注:
【0097】
【数34】
Figure 0004588874
【0098】
は、公開チャネルによって送信することができる。
3.Aは、K=βk(mod p)、
【0099】
【数35】
Figure 0004588874
【0100】
、f=F(γA、β、IA)、およびa=kA+kf(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、αa=γA fβであるかどうかを検査する。ここで、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=γA fβ(mod p)
方式9〜12の長所は、βが固定されているのでユーザーAがKを簡単に計算できることと、kAが暗号化され、他人がそれを知ることができなくなっていることである。
【0101】
方式5〜12の場合、関数F(γA、β、IA)にオプション・パラメータOPを追加すること(すなわち、f=F(γA、β、IA、OP)によって、これらの方式がより役立つものになる。たとえば、
【0102】
【数36】
Figure 0004588874
【0103】
である。ここでaEは、ユーザーAの秘密暗号化鍵であり、
【0104】
【数37】
Figure 0004588874
【0105】
は、Aの公開暗号化鍵である。下の方式15は、方式7の変形形態である。方式5〜12を、同一の形で変更することができる。方式1〜4も、同一の形で変更することができる。
【0106】
方式13:
1.Aは、まず、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0107】
【数38】
Figure 0004588874
【0108】
およびf=F(γA、IA、OP)を計算し、kAを計算する(kA=0の場合には、別のcAを選択する)。
A≡cf+cA(mod q)
次に、CAは、K=H((αkc)および
【0109】
【数39】
Figure 0004588874
【0110】
を計算し、3つ組
【0111】
【数40】
Figure 0004588874
【0112】
をAに送信する。
3.Aは、K=H(βk)、
【0113】
【数41】
Figure 0004588874
【0114】
、およびa=kA+k(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、γA=αaβ-f(mod p)を計算し、f=F(γA、IA、OP)であるかどうかを検査する。ここで、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
さらに、方式14に従うことによって、帯域幅(bandwidth)を減らすことができる。
【0115】
方式14:
1.Aは、まず、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0116】
【数42】
Figure 0004588874
【0117】
を計算し、
【0118】
【数43】
Figure 0004588874
【0119】
をγAの最初の80個の最下位ビットとしてセットする。その後、
【0120】
【数44】
Figure 0004588874
【0121】
およびkAを計算する(kA=0の場合には、別のcAを選択する)。
A≡cf+cA(mod q)
次に、CAは、K=(αkc(mod p)および
【0122】
【数45】
Figure 0004588874
【0123】
を計算し、3つ組
【0124】
【数46】
Figure 0004588874
【0125】
をAに送信する。
注:
【0126】
【数47】
Figure 0004588874
【0127】
は、公開チャネルによって送信することができる。
3.Aは、K=βk(mod p)、
【0128】
【数48】
Figure 0004588874
【0129】
、およびa=kA+k(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、
【0130】
【数49】
Figure 0004588874
【0131】
、γA=αaβ-f(mod p)を計算し、γAの最初の80個の最下位ビットが
【0132】
【数50】
Figure 0004588874
【0133】
であるかどうかを検査する。ここで、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
方式5.cのセキュリティ・レベルは、前に述べた他の方式ほどではない。方式5.cは、80ビットのセキュリティだけを有する。しかし、現在の実用的なアプリケーションにはこれでよい。最初の80個の最下位ビットを、γAの半分の下位ビットに拡張することができる。
【0134】
内在的証明書は、情報にオプション・パラメータOPを含めることによって、他の有用な情報を証明するのに使用することができる。たとえば、
【0135】
【数51】
Figure 0004588874
【0136】
である。ここで、aEは、Aのもう1つの秘密鍵であり、
【0137】
【数52】
Figure 0004588874
【0138】
は、対応する公開鍵である。下の方式15は、方式7の変形形態である。他の方式も、同一の形で変更することができる。
【0139】
方式15:
1.整数aEをランダムに選択し、
【0140】
【数53】
Figure 0004588874
【0141】
を計算する。
2.Aは、整数kをランダムに選択し、αkを計算し、αkおよび
【0142】
【数54】
Figure 0004588874
【0143】
をCAに送信する。
3.CAは、整数cAをランダムに選択し、
【0144】
【数55】
Figure 0004588874
【0145】
および
【0146】
【数56】
Figure 0004588874
【0147】
(たとえば
【0148】
【数57】
Figure 0004588874
【0149】
)を計算し、kAを計算する(kA=0の場合には、別のcAを選択する)。
A=cf+cA(mod q)
その後、CAは、
【0150】
【数58】
Figure 0004588874
【0151】
を計算し、3つ組(γA 1、kA、IA)をAに送信する。
注:(γA 1、kA、IA)は、公開チャネルによって送信することができる。
4.Aは、a=kA+k(mod q)を計算し(a=0、1の場合には、ステップ1に戻る)、
【0152】
【数59】
Figure 0004588874
【0153】
を計算する。その後、αa=βfγAであるかどうかを検査する。ここで、aがAの秘密署名鍵であり、αがAのジェネレータ、αaがAの公開署名鍵であり、aEがAの秘密暗号化鍵、
【0154】
【数60】
Figure 0004588874
【0155】
がAの公開暗号化鍵である。Aは、公開ドメインで
【0156】
【数61】
Figure 0004588874
【0157】
を公開する。
5.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
注:(方式13〜15について)
1.アイデンティティIAは、CAまたはエンティティAのいずれかによって選択することができる。
2.CAは、エンティティAを認証しなければならない。これは、方式11の注2に記載の方法によって行うことができる。
3.
【0158】
【数62】
Figure 0004588874
【0159】
または
【0160】
【数63】
Figure 0004588874
【0161】
または(γA 1、kA、IA)を、公開チャネルによって送信することができる。本発明の方式では、(α、γA)は、AのID、IAに対するCAの署名であり、これは公衆によって知られると思われた。しかし、現在は、ユーザーAだけがaを知る。したがって、本発明の方式を使用するときには、アプリケーション・プロトコルで、ユーザーAが自分自身の秘密鍵を知るようにしなければならない。言い換えると、アプリケーション・プロトコルは、Aが計算に自分の秘密鍵を使用することを保証しなければならない。
【0162】
新方式のセキュリティは、署名方程式に依存する。たとえば、方式1では、署名方程式は次式である。
1=cf+cAa(mod q) (1)
以下で、1方向関数F(γA、IA)の選択について、新しい方式1がDSAと同等であることを示す。
【0163】
CAが、AのアイデンティティIAに署名するのにDSA署名方程式を使用すると仮定する。まず、CAは、cAをランダムに選択し、
【0164】
【数64】
Figure 0004588874
【0165】
を計算し、次に、CAは、安全なハッシュ関数hを使用してh(IA)を計算し、最後に、CAは、sについて次式を解く。
h(IA)≡cγA+cAs(mod q) (2)
ここで、(γA、s)は、IAに対するCAの署名である。
式(2)にh(IA-1を乗ずることによって、次式が得られる。
1≡cγAh(IA-1+cAsh(IA-1(mod q)
F(γA、IA)=γAh(IA-1であると仮定し、上の式のsh(IA-1をaで置換することによって、式(1)が得られる。明らかに、式(2)は、F(γA、IA)=γAh(IA-1の場合に、式(1)と同等である。これは、誰かが署名方程式(1)を使用してこの方式を破ることができる場合に、その人物が、DSA方式である署名方程式(2)を使用してこの方式を破ることができることを意味する。
【0166】
ヒューリスティックな(heuristic)議論から、F(γA、IA)=γAh(IA)またはF(γA、IA)=h(γA、IA)である場合に、本発明の新方式が、F(γA、IA)の適当な選択について安全であることが暗示される。F(γA、IA)は、なんらかの他の形にすることができ、たとえば、IAが小さく、たとえば20ビットであるが、qが180ビットを超えるときに、F(γA、IA)=γA+IAを使用することができる。新方式の短所は、すべてのユーザーおよびCAが同一のフィールド・サイズを使用することである。しかし、これは、たとえばGiraultのRSAに基づくDiffie−Hellman公開鍵共有方式など、すべてのIDに基づく内在的に証明される公開鍵方式が動作する方法である。
【0167】
もう1組の方式も、次のように説明することができる。
【0168】
システム・セットアップ:信頼できる当事者CAは、大きい素数qについてp=tq+1である適当な素数pと、オーダー(位数)qのジェネレータαを選択する。CAは、その秘密鍵として1<c<q−1のランダムな整数cを選択し、公開鍵β=αc mod pを計算し、(β、α、p、q)を公開する。その後、CAは、特殊な暗号関数f=F(γA、IA、OP)(f:{0、1}*→{1、2、…、(q−1)})を選択し、この関数を用いて、内在的証明書を作るのに使用される署名方式が安全になるようにする。ここで、OPは、ユーザーが関係することのできるなんらかのオプション・パラメータ(日付、またはCAの公開鍵β)を表す。たとえば、hが安全なハッシュ関数であるものとすると、fは、以下の形式のいずれかにすることができる。
1.F(γA、IA、OP)=γA+β+h(IA
2.F(γA、IA、OP)=h(γA‖β‖IA
3.F(γA、IA、OP)=γA+β+IA、ここで、IAは、なんらかのパターン(または、IAが小さく、たとえば20ビットであり、qが180ビットを超えるとき)を有する。
4.F(γA、IA、OP)=γA+h(IA
5.F(γA、IA、OP)=h(γA‖IA
6.F(γA、IA、OP)=γA+IA、ここで、IAは、なんらかのパターン(または、IAが小さく、たとえば20ビットであり、qが180ビットを超えるとき)を有する。
7.パラメータを少し変更して、所与の安全な署名方式から安全な署名方式を得ることは非常に簡単である。したがって、F(γA、IA、OP)は、内在的証明書を作るのに使用された署名方式が安全であることを保障する他の形式とすることができる。F(γA、IA、OP)を適当に選択することによって、これまでに知られているElgamal様署名方式が、変更の後に内在的証明書方式として使用される場合の本明細書で提案される4系列の方式の1つと同等になることに留意されたい。しかし、本明細書で提案される方式は、より高い効率を有する。
【0169】
注:上記のシステム・セットアップが、以下の方式で仮定される。
【0170】
方式1.a:
1.各エンティティAについて、CAは、一意の区別される名前またはアイデンティティIA(たとえば、氏名、住所、電話番号)および、1<cA<qのランダムな整数cAを選択する。次に、CAは、
【0171】
【数65】
Figure 0004588874
【0172】
を計算する。(γAは、Aの公開鍵再構成公開データである。(IA、γA)は、Aの内在的証明書として働く)。
2.CAは、f=F(γA、IA、OP)を計算し、aについて次式を解く(a=0、1、c、cA -1cの場合には、別のcAを選択し、式をもう一度解く)。
1=cf+cAa(mod q)
3.CAは、3つ組(γA、a、IA)を保護された形でAに送信する。この3つ組は、IAに対するCAの署名である。その後、aがAの秘密鍵、γAがAのジェネレータ、
【0173】
【数66】
Figure 0004588874
【0174】
がAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に検証された公開鍵を得ることができる。
γA a=αβ-f(mod p)
注:
1.ステップ1では、アイデンティティIAをエンティティAが選択することができる。2.ステップ2では、a=0、1を排除した。というのは、この場合に、誰もがAの秘密鍵を簡単に知ることができるからである。特にa=0,cA -1cのときには、1=cf(mod q)からCAの秘密鍵cを誰でも簡単に計算することができる。
3.この方式では、各ユーザーが異なるシステム・ジェネレータγAを有する。
【0175】
方式1.b:
1.各エンティティAについて、CAは、一意の区別される名前またはアイデンティティIA(たとえば、氏名、住所、電話番号)および、1<cA<qのランダムな整数cAを選択する。次に、CAは、
【0176】
【数67】
Figure 0004588874
【0177】
を計算する(γAは、Aの公開鍵再構成公開データである。(IA、γA)は、Aの内在的証明書として働く)。
2.CAは、f=F(γA、IA、OP)を計算し、aについて次式を解く(a=0、1、cの場合には、別のcAを選択し、式をもう一度解く)。
1≡ca+cAf(mod q)
3.CAは、3つ組(γA、a、IA)を保護された形でAに送信する。この3つ組は、IAに対するCAの署名である。その後、aがAの秘密鍵、βがAのジェネレータ、βaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に検証された公開鍵を得ることができる。
βa=αγA -f(mod p)
注:
1.ステップ1では、アイデンティティIAをエンティティAが選択することができる。2.ステップ2では、a=0、1を排除した。というのは、この場合に、誰もがAの秘密鍵を簡単に知ることができるからであり、a=0のときには、証明書は、CAに関係しない。
3.この方式では、各ユーザーが同一のシステム・ジェネレータβを有する。
【0178】
方式1.c:
1.各エンティティAについて、CAは、一意の区別される名前またはアイデンティティIA(たとえば、氏名、住所、電話番号)および、1<cA<qのランダムな整数cAを選択する。次に、CAは、
【0179】
【数68】
Figure 0004588874
【0180】
を計算する(γAは、Aの公開鍵再構成公開データである。(IA、γA)は、Aの内在的証明書として働く)。
2.CAは、f=F(γA、IA、OP)を計算し、aについて次式を解く(a=0、1、またはcの場合には、別のcAを選択し、式をもう一度解く)。
a≡cf+cA(mod q)
3.CAは、3つ組(γA、a、IA)を保護された形でAに送信する。この3つ組は、IAに対するCAの署名である。ここで、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に検証された公開鍵を得ることができる。
αa=βfγA(mod p)
注:
1.ステップ1では、アイデンティティIAをエンティティAが選択することができる。2.ステップ2では、a=0、1を排除した。というのは、この場合に、誰もがAの秘密鍵を簡単に知ることができるからである。
3.この方式では、各ユーザーが同一のシステム・ジェネレータαを有する。
【0181】
方式1.d:
1.各エンティティAについて、CAは、一意の区別される名前またはアイデンティティIA(たとえば、氏名、住所、電話番号)および、1<cA<qのランダムな整数cAを選択する。次に、CAは、
【0182】
【数69】
Figure 0004588874
【0183】
を計算する(γAは、Aの公開鍵再構成公開データである。(IA、γA)は、Aの内在的証明書として働く)。
2.CAは、f=F(γA、IA、OP)を計算し、aについて次式を解く(a=0、1、またはcの場合には、別のcAを選択し、式をもう一度解く)。
【0184】
a≡cAf+c(mod q)
3.CAは、3つ組(γA、a、IA)を保護された形でAに送信する。この3つ組は、IAに対するCAの署名である。ここで、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に検証された公開鍵を得ることができる。
αa=γA fβ(mod p)
注:
1.ステップ1では、アイデンティティIAをエンティティAが選択することができる。2.ステップ2では、a=0、1を排除した。というのは、この場合に、誰もがAの秘密鍵を簡単に知ることができるからである。
3.この方式では、各ユーザーが同一のシステム・ジェネレータαを有する。
【0185】
誰でも公開データからユーザーAの公開鍵を再構成することができるが、これは、再構成された公開鍵が証明されたことを意味しない。証明書を明示的に検証するためには、aを知る必要がある。aを知ったならば、検証プロセスは、IAに対するCAの署名を検証することになる。たとえば、方式1.aでは、検証者がαβ-fを計算し、ユーザーAがaを使用してγA aを計算する場合に、検証者およびユーザーが、一緒に証明書を検証することができる。しかし、検証者は、ユーザーAが実際にaを知っていることを確認しなければならない。したがって、公開鍵の再構成は、ユーザーAが対応する秘密鍵の完全な知識を有することを示すアプリケーション・プロトコルと組み合わされる場合に限って、内在的検証として働く。一般に、内在的証明書方式は、対象のエンティティおよび公開鍵の認証を必要とするすべての公開鍵方式と共に使用することができる。
【0186】
内在的に証明される公開鍵システムとしてDSA署名方式を使用し、内在的証明書方式として方式1.aを使用して、これを実証する。
【0187】
アリスが、秘密鍵a、ジェネレータγAを有し、公開ドメインで(α、IA、β、γA、p、q)を公開すると仮定する。次に、アリスは、DSAを使用してメッセージMに署名しようとする。
アリスは、下記を実行する。
1.ランダムにkを選択し、r=γA k(mod p)を計算する。
2.e=sha−1(M)を計算する。
3.s=x-1(e+ar)(mod q)を計算する。
4.Mに対する署名は、(r、s)になる。
検証者は、下記を実行する。
1.アリスの公開データ(α、IA、β、γA、p、q)を取得し、fを計算し、公開鍵を再構成する。
βA=γA a=αβ-f(mod p)
2.e=sha−1(M)を計算する。
3.u1=es-1(mod q)およびu2=rs-1(mod q)を計算する。
4.
【0188】
【数70】
Figure 0004588874
【0189】
を計算する。
5.r=r’の場合には、署名が検証される。それと同時に、アリスの(IDに基づく)公開鍵が、内在的に検証される。
対(IA、γA)は、アリスの証明書として働く。DSAの場合、aを知らずにアリスの署名を偽造することが非常に困難であることがわかっている。公開鍵の再構成は、アプリケーション・プロトコルが最後に有効になるときに、内在的検証として働く。公開鍵を取得するために、1回の累乗演算だけが必要であることを想起されたい。この理由から、本発明人は、内在的証明書の検証が、1回の累乗演算を必要とすると主張する。
【0190】
以下の内在的証明書方式は、CAおよびエンティティの両方が、エンティティの秘密鍵を制御するが、対象のエンティティだけがその秘密鍵を知るように、上の方式を変更することによって導出することができる。
【0191】
この節では、もう1つのシステム・パラメータH(*)が必要であり、このH(*)は、安全なハッシュ関数または1方向関数またはアイデンティティ・マップとすることができる暗号関数である。
【0192】
方式2.a:
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0193】
【数71】
Figure 0004588874
【0194】
およびf=F(γA、IA、OP)を計算し、kAについて署名方程式を解く(kA=0またはcの場合には、別のcAを選択する)。
1=cf+cAA(mod q)
その後、CAは、
【0195】
【数72】
Figure 0004588874
【0196】
を計算し、3つ組(γA 1、kA、IA)をAに送信する。
3.Aは、a=kA-1(mod q)を計算し(a=1の場合には、ステップ1に戻る)、γA=(γA 1k(mod p)を計算する。その後、γA a=αβ-fであるかどうかを検査する。ここで、aがAの秘密鍵、γAがAのジェネレータ、γA aがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
γA a=αβ-f(mod p)
方式2.b:
5.Aは、整数kをランダムに選択し、βkを計算し、これをCAに送信する。
6.CAは、整数cAをランダムに選択し、
【0197】
【数73】
Figure 0004588874
【0198】
およびf=F(γA、IA、OP)を計算し、kAについて署名方程式を解く(kA=0の場合には、別のcAを選択する)。
1=ckA+cAf(mod q)
その後、CAは、
【0199】
【数74】
Figure 0004588874
【0200】
を計算し、3つ組(γA 1、kA、IA)をAに送信する。
7.Aは、
【0201】
【数75】
Figure 0004588874
【0202】
、f=F(γA、IA、OP)、およびa=kA−kf(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、βa=αγA -fであるかどうかを検査する。ここで、aがAの秘密鍵、βがAのジェネレータ、βaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
8.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
βa=αγA -f(mod p)
方式2.c:
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0203】
【数76】
Figure 0004588874
【0204】
およびf=F(γA、IA、OP)を計算し、kAを計算する(kA=cの場合には、別のcAを選択する)。
A≡cf+cA(mod q)
その後、CAは、
【0205】
【数77】
Figure 0004588874
【0206】
を計算し、3つ組(γA 1、kA、IA)をAに送信する。
3.Aは、a=kA+k(mod q)を計算し(a=0、1の場合には、ステップ1に戻る)、
【0207】
【数78】
Figure 0004588874
【0208】
を計算する。その後、αa=βfγAであるかどうかを検査する。ここで、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
方式2.d:
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0209】
【数79】
Figure 0004588874
【0210】
およびf=F(γA、IA、OP)を計算し、kAを計算する(kA=cAの場合には、別のcAを選択する)。
A≡cAf+c(mod q)
その後、CAは、
【0211】
【数80】
Figure 0004588874
【0212】
を計算し、3つ組(γA 1、kA、IA)をAに送信する。
3.Aは、
【0213】
【数81】
Figure 0004588874
【0214】
、f=F(γA、IA、OP)、およびa=kA+kf(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、αa=γA fβであるかどうかを検査する。ここで、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=γA fβ(mod p)
注:(方式2.a、2.b、2.c、2.dについて)
1.アイデンティティIAは、CAまたはエンティティAのいずれかによって選択することができる。
2.CAは、エンティティAを認証しなければならない。これは、CAの面前での存在または保護されたチャネルまたは音声(たとえば電話での)または次の方法のいずれかによって行うことができる。
ステップ2で、3つ組(γA 1、kA、IA)をAに送信する代わりに、CAが、まずγA 1をAに送信する。Aは、γAを計算し、K=H(γA)にセットし、DES(または他の対称鍵システム)によってAの認証情報AAI(VISA情報など)を暗号化し、DESK(AAI)をCAに送信する。CAは、DESK(AAI)を非暗号化してAAIを得る。AAIの有効性を検査した後に、CAは(kA、IA)をAに送信する。
3.(γA 1、kA、IA)は、公開チャネルによって送信することができる。
【0215】
上の方式2.a〜2.dでは、内在的証明書方式が、対象のエンティティおよびCAによって完了される。各方式は、本質的に2つの部分すなわち鍵交換部分および署名部分に分割される。鍵交換部分の機能の1つが、公開チャネルによってCAからAに内在的証明書情報を送信することである(詳細な説明は節6で行う)。上の方式の計算を高速化するために、鍵交換部分を変更することができる。以下の方式3.a〜3.dは、方式2.a〜2.dを変更することによって得られた。方式3.a〜3.dの長所は、βが固定されているので、ユーザーAが、CAから応答を得る前にKを計算できることである。この特性は、特にオンラインの場合に好ましい。
【0216】
方式3.a:
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0217】
【数82】
Figure 0004588874
【0218】
およびf=F(γA、IA、OP)を計算し、kAについて署名方程式を解く(kA=0の場合には、別のcAを選択する)。
1=cf+cAA(mod q)
次に、CAは、K=H((αkc)および
【0219】
【数83】
Figure 0004588874
【0220】
を計算し、3つ組
【0221】
【数84】
Figure 0004588874
【0222】
をAに送信する。
3.Aは、K=H(βk)、
【0223】
【数85】
Figure 0004588874
【0224】
、およびa=kA-1(mod q)を計算する(a=1の場合には、ステップ1に戻る)。その後、γA a=αβ-fであるかどうかを検査する。ここで、aがAの秘密鍵、γAがAのジェネレータ、γA aがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
γA a=αβ-f(mod p)
方式3.b:
1.Aは、整数kをランダムに選択し、βkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0225】
【数86】
Figure 0004588874
【0226】
およびf=F(γA、IA、OP)を計算し、kAについて署名方程式を解く(kA=0の場合には、別のcAを選択する)。
1=ckA+cAf(mod q)
次に、CAは、
【0227】
【数87】
Figure 0004588874
【0228】
およびk ̄A=DESk(KA)を計算し、3つ組
【0229】
【数88】
Figure 0004588874
【0230】
をAに送信する。
3.Aは、
【0231】
【数89】
Figure 0004588874
【0232】
を計算し、a=kA−kf(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、βa=αγA -fであるかどうかを検査する。ここで、aがAの秘密鍵、βがAのジェネレータ、βaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
βa=αγA -f(mod p)
注:(方式3.bについて)
1.アイデンティティIAは、CAまたはエンティティAのいずれかによって選択することができる。
2.CAは、エンティティAを認証しなければならない。これは、CAの面前での存在または保護されたチャネルまたは音声(たとえば電話での)または次の方法のいずれかによって行うことができる。
ステップ2で、3つ組
【0233】
【数90】
Figure 0004588874
【0234】
をAに送信する代わりに、CAが、まずγAをAに送信する。Aは、
【0235】
【数91】
Figure 0004588874
【0236】
を計算し、DES(または他の対称鍵システム)によってAの認証情報AAI(VISA情報など)を暗号化し、DESK(AAI)をCAに送信する。CAは、DESK(AAI)を非暗号化してAAIを得る。AAIの有効性を検査した後に、CAは
【0237】
【数92】
Figure 0004588874
【0238】
をAに送信する。
3.
【0239】
【数93】
Figure 0004588874
【0240】
は、公開チャネルによって送信することができる。
【0241】
方式3.c:
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0242】
【数94】
Figure 0004588874
【0243】
およびf=F(γA、IA、OP)を計算し、kAを計算する(kA=0の場合には、別のcAを選択する)。
A≡cf+cA(mod q)
次に、CAは、K=H((αkc)および
【0244】
【数95】
Figure 0004588874
【0245】
を計算し、3つ組
【0246】
【数96】
Figure 0004588874
【0247】
をAに送信する。
3.Aは、K=H(βk)、
【0248】
【数97】
Figure 0004588874
【0249】
、およびa=kA+k(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、αa=βfγAであるかどうかを検査する。ここで、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
方式3.d:
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0250】
【数98】
Figure 0004588874
【0251】
およびf=F(γA、IA、OP)を計算し、kAを計算する(kA=0の場合には、別のcAを選択する)。
A≡cAf+c(mod q)
次に、CAは、K=H((αkc)および
【0252】
【数99】
Figure 0004588874
【0253】
を計算し、3つ組
【0254】
【数100】
Figure 0004588874
【0255】
をAに送信する。
3.Aは、K=H(βk)、
【0256】
【数101】
Figure 0004588874
【0257】
、f=F(γA、IA、OP)、およびa=kA+kf(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、αa=γA fβであるかどうかを検査する。ここで、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=γA fβ(mod p)
注:(方式3.a、3.c、3.dについて)
1.アイデンティティIAは、CAまたはエンティティAのいずれかによって選択することができる。
2.CAは、エンティティAを認証しなければならない。これは、CAの面前での存在または保護されたチャネルまたは音声(たとえば電話での)または次の方法のいずれかによって行うことができる。
ステップ1で、Aは、αkおよびK=H(βk)を計算し、αkおよびDESK(AAI)をCAに送信する。CAは、K=H((αkc)を計算し、DESK(AAI)を非暗号化してAAIを得る。AAIの有効性を検査した後に、CAはステップ2を継続する。
3.(γA、kA、IA)は、公開チャネルによって送信することができる。
【0258】
方式3.a、3.c、および3.dの長所は、βが固定されているのでユーザーAがKを簡単に計算できることと、kAが暗号化され、他人がそれを知ることができなくなっていることである。実際に、kAが知れわたることが、証明書方式のセキュリティを低下させない。kAを暗号化する目的は、エンティティが確実にkを知るようにするためである。したがって、方式3.a〜3.dについて、証明書方式で注2で説明した方法を使用するならば、DES暗号化部分を除去することができ、
【0259】
【数102】
Figure 0004588874
【0260】
をkAで置換することができる。
【0261】
上の方式の送信帯域幅を節約するために、γAの代わりにf=F(γA、IA、OP)を送信することによって上の方式を変更することができる(一般に、γAのサイズは160ビットより大きく、fはちょうど160ビットであることに留意されたい)。下の方式4.cは、方式3.cの変形形態である。
【0262】
方式4.c:
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0263】
【数103】
Figure 0004588874
【0264】
およびf=F(γA、IA、OP)を計算し、kAを計算する(kA=0の場合には、別のcAを選択する)。
A≡cf+cA(mod q)
次に、CAは、K=H((αkc)および
【0265】
【数104】
Figure 0004588874
【0266】
を計算し、3つ組
【0267】
【数105】
Figure 0004588874
【0268】
をAに送信する。
3.Aは、K=H(βk)、
【0269】
【数106】
Figure 0004588874
【0270】
、およびa=kA+k(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、γA=αaβ-f(mod p)を計算し、f=F(γA、IA、OP)であるかどうかを検査する。ここで、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
さらに、方式5.cに従うことによって、帯域幅を減らすことができる。
【0271】
方式5.c:
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
【0272】
【数107】
Figure 0004588874
【0273】
を計算し、
【0274】
【数108】
Figure 0004588874
【0275】
をγAの最初の80個の最下位ビットとしてセットする。その後、
【0276】
【数109】
Figure 0004588874
【0277】
およびkAを計算する(kA=0の場合には、別のcAを選択する)。
A≡cf+cA(mod q)
次に、CAは、K=(αkc(mod p)および
【0278】
【数110】
Figure 0004588874
【0279】
を計算し、3つ組
【0280】
【数111】
Figure 0004588874
【0281】
をAに送信する。
【0282】
注:
【0283】
【数112】
Figure 0004588874
【0284】
は、公開チャネルによって送信することができる。
3.Aは、K=βk(mod p)、
【0285】
【数113】
Figure 0004588874
【0286】
、およびa=kA+k(mod q)を計算する(a=0、1の場合には、ステップ1に戻る)。その後、
【0287】
【数114】
Figure 0004588874
【0288】
、γA=αaβ-f(mod p)を計算し、γAの最初の80個の最下位ビットが
【0289】
【数115】
Figure 0004588874
【0290】
であるかどうかを検査する。ここで、aがAの秘密鍵、αがAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
方式5.cのセキュリティ・レベルは、前に述べた他の方式ほどではない。方式5.cは、80ビットのセキュリティだけを有する。しかし、現在の実用的なアプリケーションにはこれでよい。最初の80個の最下位ビットを、γAの半分の下位ビットに拡張することができる。
【0291】
内在的証明書は、情報にオプション・パラメータOPを含めることによって、他の有用な情報を証明するのに使用することができる。たとえば、
【0292】
【数116】
Figure 0004588874
【0293】
である。ここで、αEは、Aのもう1つの秘密鍵であり、
【0294】
【数117】
Figure 0004588874
【0295】
は、対応する公開鍵である。下の方式6.cは、方式2.cの変形形態である。他の方式を、同一の形で変更することができる。
【0296】
方式6.c:
1.Aは、整数aEをランダムに選択し、
【0297】
【数118】
Figure 0004588874
【0298】
を計算する。
2.Aは、整数kをランダムに選択し、αkを計算し、αkおよび
【0299】
【数119】
Figure 0004588874
【0300】
をCAに送信する。
【0301】
3.CAは、整数cAをランダムに選択し、
【0302】
【数120】
Figure 0004588874
【0303】
を計算し(たとえば
【0304】
【数121】
Figure 0004588874
【0305】
)、kAを計算する(kA=0の場合には、別のcAを選択する)。
A≡cf+cA(mod q)
その後、CAは、
【0306】
【数122】
Figure 0004588874
【0307】
を計算し、3つ組(γA 1、kA、IA)をAに送信する。
4.Aは、a=kA+k(mod q)を計算し(a=0、1の場合には、ステップ1に戻る)、
【0308】
【数123】
Figure 0004588874
【0309】
を計算する。その後、αa=βfγAであるかどうかを検査する。ここで、aがAの秘密署名鍵であり、αがAのジェネレータ、αaがAの公開署名鍵である。aEがAの秘密暗号化鍵、
【0310】
【数124】
Figure 0004588874
【0311】
がAの公開暗号化鍵である。Aは、公開ドメインで
【0312】
【数125】
Figure 0004588874
【0313】
を公開する。
5.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
注:(方式4.c、5.c、6.cについて)
1.アイデンティティIAは、CAまたはエンティティAのいずれかによって選択することができる。
2.CAは、エンティティAを認証しなければならない。これは、方式3.cの注2に記載の方法によって行うことができる。
【0314】
【数126】
Figure 0004588874
【0315】
または
【0316】
【数127】
Figure 0004588874
【0317】
または(γA 1、kA、IA)を、公開チャネルによって送信することができる。
【0318】
CA連鎖(CA chaining)方式
CA連鎖構造を実施するために、すなわち、CA1がCA2を認証し、CA2がCA3を認証し、CA3がユーザーAを認証する。この節では、CA連鎖内に3つのCAがある例を提示する。基本方式3’を使用して、この例を実証する。
【0319】
システム・セットアップ:
最上位の信頼できる当事者CA1は、大きい素数qについてp=tq+1である適当な素数pと、オーダー(位数)qのジェネレータαを選択する。CA1は、その秘密鍵として1≦c1≦q−1のランダムな整数c1を選択し、公開鍵
【0320】
【数128】
Figure 0004588874
【0321】
を計算し、(β1、α、p、q)を公開する。
フェーズ1 CA2が、CA1からの内在的に証明される公開鍵を問い合わせる。
1.CA2は、整数k2をランダムに選択し、
【0322】
【数129】
Figure 0004588874
【0323】
を計算し、これをCA1に送信する。
【0324】
2.CA1は、一意の区別される名前またはアイデンティティICA2および、1≦cCA2≦q−1のランダムな整数cCA2を選択する。次に、CA1は、
【0325】
【数130】
Figure 0004588874
【0326】
を計算する(γCA2は、CA2の公開鍵再構成公開データである)。
3.CA1は、関数f1=F(γCA2、ICA2)を選択し、kCA2を計算する(kCA2=0の場合には、ステップ2で別のcCA2を選択し、kCA2を再計算する)。
CA2=c11+cCA2(mod q)
4.CA1が、
【0327】
【数131】
Figure 0004588874
【0328】
を計算し、3つ組(γCA2 1、kCA2、ICA2)をCA2に送信する。
5.CA2が、
【0329】
【数132】
Figure 0004588874
【0330】
を計算する。その後、c2=kCA2+k2(mod q)がCA2の秘密鍵、αがCA2のジェネレータ、
【0331】
【数133】
Figure 0004588874
【0332】
がCA2の公開鍵になる。CA2は、公開ドメインで(α、ICA2、β1、β2、γCA2、p、q)を公開する。
注:ユーザーがCA2を信頼するときには、β2を直接に使用することができる。
6.誰もが、次式を計算することによって、公開ドメインからCA2の(IDに基づく)内在的に検証された公開鍵を得ることができる。
【0333】
【数134】
Figure 0004588874
【0334】
フェーズ2 CA3が、CA2からの内在的に証明される公開鍵を問い合わせる。
1.CA3は、整数k3をランダムに選択し、
【0335】
【数135】
Figure 0004588874
【0336】
を計算し、これをCA2に送信する。
【0337】
2.CA2は、一意の区別される名前またはアイデンティティICA3および、1≦cCA3≦q−1のランダムな整数cCA3を選択する。CA2が、
【0338】
【数136】
Figure 0004588874
【0339】
を計算する(γCA3は、CA3の公開鍵再構成公開データである)。
3.CA2は、関数f2=F(γCA3、ICA3)を選択し、kCA3を計算する(kCA3=0の場合には、ステップ2で別のcCA3を選択し、kCA3を再計算する)。
CA3≡c22+cCA3(mod q)
4.CA2が、
【0340】
【数137】
Figure 0004588874
【0341】
を計算し、3つ組(γCA3 1、kCA3、ICA3)をCA3に送信する。
5.CA3が、
【0342】
【数138】
Figure 0004588874
【0343】
を計算する。その後、c3=kCA3+k3(mod q)がCA3の秘密鍵、αがCA3のジェネレータ、
【0344】
【数139】
Figure 0004588874
【0345】
がCA3の公開鍵になる。CA3は、公開ドメインで(α、ICA3、β2、β3、γCA3、p、q)を公開する。
【0346】
注:エンティティがCA3を信頼するときには、β3を直接に使用することができる。
6.誰もが、次式を計算することによって、公開ドメインからCA3の(IDに基づく)内在的に検証された公開鍵を得ることができる。
【0347】
【数140】
Figure 0004588874
【0348】
フェーズ3 ユーザーAが、CA3からの内在的に証明される公開鍵を問い合わせる。
1.Aは、整数kをランダムに選択し、αkを計算し、これをCA3に送信する。
2.CA3は、一意の区別される名前またはアイデンティティIAおよび、1≦cA≦q−1のランダムな整数cAを選択する。CA3が、
【0349】
【数141】
Figure 0004588874
【0350】
を計算する(γAは、Aの公開鍵再構成公開データである)。
3.CA3は、注意深く選択された関数f3=F(γA、IA)を選択し、kAを計算する(kA=0の場合には、ステップ2で別のcAを選択し、kAを再計算する)。
【0351】
A≡c33+cA(mod q)
4.CA3は、
【0352】
【数142】
Figure 0004588874
【0353】
を計算し、3つ組(γA 1、kA、IA)をAに送信する。
【0354】
5.Aが、
【0355】
【数143】
Figure 0004588874
【0356】
を計算する。その後、a=kA+k(mod q)がAの秘密鍵、αがAのジェネレータ、βA=αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β3、βA、γA、p、q)を公開する。
注:ユーザーがAを信頼するときには、βAを直接に使用することができる。
【0357】
6.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に検証された公開鍵を得ることができる。
【0358】
【数144】
Figure 0004588874
【0359】
フェーズ4 ユーザーAの署名および検証
メッセージMに署名するために、ユーザーAは下記を実行する。
1.ランダムにxを選択し、r=αx(mod p)を計算する。
2.e=fA=F(r,M)を計算する。ここで、Fはなんらかの固定された関数である。
3.s=ae+x(mod q)を計算する。
4.Mに対する署名は、(r、s)になる。
検証者は、下記を実行する。
1.CA1、CA2、CA3,およびユーザーAの公開データを得る。
【0360】
(α、ICA2、ICA3、IA、β1、β2、β3、βA、γCA2、γCA3、γA、p、q)
2.ユーザーAの公開鍵を再構成する。
【0361】
【数145】
Figure 0004588874
【0362】
3.e=fA=F(r、M)を計算する。
4.r’=αsβA -e(mod p)を計算する。
5.r=r’の場合には、署名が検証される。それと同時に、CA2、CA3、およびユーザーAの(IDに基づく)公開鍵が、内在的に検証される。
【0363】
ユーザーAの公開鍵の再構成には、3つの既知の基底累乗演算および3つの乗算演算だけが必要である。署名が有効なときには、CA2、CA3、およびユーザーAの(IDに基づく)公開鍵が、内在的に検証される。
【0364】
注:
1.検証者がAを信頼する場合には、Aの公開鍵はβAになる。
2.検証者がCA3を信頼する場合には、Aの再構成公開鍵は
【0365】
【数146】
Figure 0004588874
【0366】
になる。
【0367】
3.検証者がCA2を信頼する場合には、Aの再構成公開鍵は
【0368】
【数147】
Figure 0004588874
【0369】
になる。
【0370】
連署(Co−signing)方式
以下では、複数のCAが1つの内在的証明書に署名できるようにする方式を説明する。これは、基本方式3’を使用して3つのCAが証明書に連署する場合によって例示される。
【0371】
システム・セットアップ:
CA1、CA2、およびCA3が、次の共通のシステム・パラメータを有すると仮定する。(1)大きい素数qに対してp=tq+1になる素数p、(2)オーダーqのジェネレータα、(3)注意深く選択された関数f=F(γ,(IA1+IA2+IA3))。CA1は、その秘密鍵として1≦c1≦q−1のランダムな整数c1を選択し、公開鍵
【0372】
【数148】
Figure 0004588874
【0373】
を計算し、(β1、α、p、q)を公開する。CA2は、その秘密鍵として1≦c2≦q−1のランダムな整数c2を選択し、公開鍵
【0374】
【数149】
Figure 0004588874
【0375】
を計算し、(β2、α、p、q)を公開する。CA3は、その秘密鍵として1≦c3≦q−1のランダムな整数c3を選択し、公開鍵
【0376】
【数150】
Figure 0004588874
【0377】
を計算し、(β3、α、p、q)を公開する。
【0378】
ステップ1 Aは、整数kをランダムに選択し、αkを計算し、これをCA1、CA2、およびCA3に送信する。
ステップ2 CAが、情報を交換し、内在的証明書を計算する。
【0379】
フェーズ1
1.CA1が、一意の区別される名前またはアイデンティティIA1および、1≦cA1≦q−1のランダムな整数cA1を選択し、
【0380】
【数151】
Figure 0004588874
【0381】
を計算し、(
【0382】
【数152】
Figure 0004588874
【0383】
)をCA2およびCA3に送信する。
2.CA2が、一意の区別される名前またはアイデンティティIA2および、1≦cA2≦q−1のランダムな整数cA2を選択し、(
【0384】
【数153】
Figure 0004588874
【0385】
)を計算し、
【0386】
【数154】
Figure 0004588874
【0387】
をCA1およびCA3に送信する。
【0388】
3.CA3が、一意の区別される名前またはアイデンティティIA3および、1≦cA3≦q−1のランダムな整数cA3を選択し、
【0389】
【数155】
Figure 0004588874
【0390】
を計算し、
【0391】
【数156】
Figure 0004588874
【0392】
をCA1およびCA2に送信する。
【0393】
フェーズ2
1.CA1が、
【0394】
【数157】
Figure 0004588874
【0395】
を計算し(γは、Aの公開鍵再構成公開データである)、f=F(γ、(IA1+IA2+IA3))を計算し、kA1を計算する(kA1=0の場合、フェーズ1に戻る)。
A1≡c1f+cA1(mod q)
CA1は、
【0396】
【数158】
Figure 0004588874
【0397】
を計算し、3つ組(γA1 1、kA1、IA1)をAに送信する。
2.CA2が、
【0398】
【数159】
Figure 0004588874
【0399】
を計算し(γは、Aの公開鍵再構成公開データである)、f=F(γ、(IA1+IA2+IA3))を計算し、kA2を計算する(kA2=0の場合、フェーズ1に戻る)。
A2≡c2f+cA2(mod q)
CA2は、
【0400】
【数160】
Figure 0004588874
【0401】
を計算し、3つ組(γA2 1、kA2、IA2)をAに送信する。
【0402】
3.CA3が、
【0403】
【数161】
Figure 0004588874
【0404】
を計算し(γは、Aの公開鍵再構成公開データである)、f=F(γ、(IA1+IA2+IA3))を計算し、kA3を計算する(kA3=0の場合、フェーズ1に戻る)。
A3≡c3f+cA3(mod q)
CA3は、
【0405】
【数162】
Figure 0004588874
【0406】
を計算し、3つ組(γA3 1、kA3、IA3)をAに送信する。
ステップ3 Aが、内在的に連署された秘密鍵および公開鍵再構成情報を計算する。
1.Aは、a=kA1+kA2+kA3+k(mod q)を計算する(aが0または1の場合には、ステップ1に戻る)。
2.Aが、
【0407】
【数163】
Figure 0004588874
【0408】
およびf=F(γ、(IA1+IA2+IA3))を計算する。その後、αa=(β1β2β3fγ(mod p)であるかどうかを検証する。
3.ここで、aがAの内在的に連署された秘密鍵、αがAのジェネレータ、IA=IA1+IA2+IA3がAの共通ID、(β1β2β3fγがAの内在的に共同証明される公開鍵である。
4.Aは、公開ドメインで(α、IA1、IA2、IA3、β1、β2、β3、γ、p、q)を公開する。
【0409】
5.誰もが、(β1β2β3fγ(mod p)を計算することによって、公開ドメインからAの(IDに基づく)内在的に共同証明された公開鍵を得ることができる。
【0410】
応用例
以下の例は、CAの署名方程式として方式3(または方式7’)に関して示される。というのは、この方式では全員が同一のジェネレータを共用するからである。各ユーザーは、CAがシステム・パラメータ(p、q、d)を使用し、各ユーザーが同一のジェネレータを有する限り、異なるCAを有することができる。
【0411】
セット・アップ:
CA1: システム・パラメータ(α、β1、p、q、d)
アリスが、秘密鍵a、ジェネレータαを有し、公開ドメインで(α、IA、β、γA、p、q)を公開する。
CA2: システム・パラメータ(α、β2、p、q)
ボブが、秘密鍵b、ジェネレータαを有し、公開ドメインで(α、IA、β、γA、p、q)を公開する。
MTI/C0鍵共有プロトコルを使用して、本発明の新方式を使用する方法の実例を示す。アリスとボブが鍵交換を実行したいと思っていると仮定する。
【0412】
MTI/C0プロトコル
1.アリスは、ボブの公開鍵
【0413】
【数164】
Figure 0004588874
【0414】
を再構成し、整数xをランダムに選択し、(αbxを計算し、ボブに送信する。
【0415】
2.ボブは、アリスのの公開鍵
【0416】
【数165】
Figure 0004588874
【0417】
を再構成し、整数yをランダムに選択し、(αayを計算し、アリスに送信する。
【0418】
3.アリスは、共有鍵(shared key)
【0419】
【数166】
Figure 0004588874
【0420】
を計算する。
【0421】
4.ボブは、共有鍵(shared key)
【0422】
【数167】
Figure 0004588874
【0423】
を計算する。
【0424】
これは2パス・プロトコルである。本発明の内在的証明書方式を用いると、各当事者は、3つの累乗演算を実行するだけで共有鍵(shared key)を得ると同時に、認証鍵共有および内在的公開鍵検証を実行する。
【0425】
以下は、サインクリプション(signcryption)方式の例である。CAの署名方程式として方式3(または方式7)を使用する。というのは、この方式では、全員が同一のジェネレータを共用するからである。その後の方式では、CAの署名方程式として方式13を使用する。この節のすべての方式について、各ユーザーは、CAが同一のシステム・パラメータ(p、q、α)を使用し、各ユーザーが同一のジェネレータを使用する限り、異なるCAを有することができる。
【0426】
セット・アップ:
CA1: システム・パラメータ(α、β1、p、q)
アリス: 秘密鍵a、ジェネレータα、および公開ドメインの(α、IA、β1、γA、p、q)。
CA2: システム・パラメータ(α、β2、p、q)
ボブ: 秘密鍵b、ジェネレータα、および公開ドメインの(α、IB、β2、γB、p、q)。
ボブは、署名され暗号化されたメッセージMをアリスに送信したいと思っている。
【0427】
サインクリプション・プロトコル1:
ボブが、署名され暗号化されたメッセージMをアリスに送信したいと思っていると仮定する。
ボブは、下記を実行する。
1.アリスの公開鍵
【0428】
【数168】
Figure 0004588874
【0429】
を再構成する。
2.整数xをランダムに選択し、鍵r=(αax(mod p)を計算する。
3.C=DESr(M)を計算する。
4.e=hash(C IA)を計算する。
5.s=be+x(mod q)を計算する。
6.対(C、s)をアリスに送信し、したがって、Cは、暗号化されたメッセージであり、sは、署名である。
【0430】
メッセージを復元するために、アリスは下記を実行する。
1.e=hash(C IA)を計算する。
2.ボブの公開鍵
【0431】
【数169】
Figure 0004588874
【0432】
を再構成する。
3.αas(αb-ac(mod p)を計算する。これはrである。
4.メッセージM=DESr(C)を非暗号化する。
5.冗長性に関する検査を行う。
したがって、ボブは、2回の累乗演算だけを行い、アリスは、3回の累乗演算を行う。しかし、アリスとボブの両方が、お互いの認証を確信している。この方式の場合、メッセージMが、なんらかの冗長性またはパターンを有しなければならないことに留意されたい。
【0433】
サインクリプション・プロトコル2(一般的な場合):
セット・アップ:
CA1: システム・パラメータ(α、β1、p、q)
アリス: 秘密鍵a、ジェネレータα、および公開ドメインの(α、IA、β1、γA、p、q)。
CA2: システム・パラメータ(α、β2、p、q)
ボブ: 秘密鍵b、ジェネレータα、および公開ドメインの(α、IB、β2、γB、p、q)。
【0434】
注:このセット・アップは、内在的証明書用である。通常の証明書方式システムの場合、アリスとボブが同一のジェネレータを有することだけが必要である。
【0435】
アリスへのメッセージをサインクリプト(signcrypt)するために、ボブは下記を実行する。
【0436】
1.アリスの公開鍵αaを得る(内在的証明書方式の場合、アリスの公開鍵
【0437】
【数170】
Figure 0004588874
【0438】
を再構成する)。
2.整数xをランダムに選択し、r=(αax(mod p)を計算する。
3.C=DESr(M)を計算する。
4.e=hash(C‖αa)を計算する。
5.s=be+x(mod q)を計算する。
6.(C、s)をアリスに送信する。Cは、暗号化されたメッセージであり、sは、署名である。
メッセージを復元するために、アリスは下記を実行する。
1.e=hash(C‖αa)を計算する。
2.ボブの公開鍵αbを得る(内在的証明書方式の場合、ボブの公開鍵
【0439】
【数171】
Figure 0004588874
【0440】
を再構成する)。
3.αas(αb-ae(mod p)を計算する。これはrである。
4.メッセージM=DESr(C)を非暗号化する。
【0441】
注:
1.証明書方式が、本明細書に記載の内在的証明書でない場合には、アリスおよびボブの公開鍵を検証しなければならない。
2.メッセージMが、なんらかの冗長性またはパターンを有しなければならない。
【0442】
3.1つの値rを知っているアリスは、値αabが露出されるので、ボブからアリスへのすべてのメッセージを非暗号化することができる。
4.一般に、ハッシュeにオプション・パラメータを含めなければならない、すなわち、e=hash(C‖αa‖OP)。たとえば、OP=αbまたはOP=αb‖β1‖β2
【0443】
上のサインクリプション方式は、署名者が自分の秘密署名鍵を失った場合に、その署名者がサインクリプトしたすべてのメッセージが公衆に露出されるという短所を有する。事後暗号化の保護のために、新しいサインクリプション方式を提案する。新方式では、各ユーザーが、2対の鍵を有し、1対は署名鍵用、もう1対は暗号化鍵である。新方式は、あらゆる証明書方式と共に使用することができる。しかし、本発明の内在的証明書方式と共に使用される場合に、新方式は最も効果的になる。
【0444】
サインクリプション・プロトコル3(一般的な場合):
セット・アップ:
アリス: 秘密署名鍵a、秘密暗号化鍵aE、ジェネレータα、および公開ドメインの
【0445】
【数172】
Figure 0004588874
【0446】

【0447】
CA2: システム・パラメータ(α、β2、p、q)
ボブ: 秘密署名鍵b、秘密暗号化鍵bE、ジェネレータα、および公開ドメインの
【0448】
【数173】
Figure 0004588874
【0449】

注:このセット・アップは、方式6.cを使用する内在的証明書用である。通常の証明書方式システムの場合、アリスとボブが同一のジェネレータを有することだけが必要である。
【0450】
アリスへのメッセージをサインクリプトするために、ボブは下記を実行する。
【0451】
1 アリスの公開署名鍵αaおよび公開暗号化鍵
【0452】
【数174】
Figure 0004588874
【0453】
を得る(内在的証明書方式の場合、アリスの公開署名鍵
【0454】
【数175】
Figure 0004588874
【0455】
を再構成する)。
2 整数xをランダムに選択し、
【0456】
【数176】
Figure 0004588874
【0457】
を計算する。
3 C=DESr(M)を計算する。

【0458】
【数177】
Figure 0004588874
【0459】
を計算する。
5 s=be+x+bE(mod q)を計算する。
6 (C、s)をアリスに送信する。Cは、暗号化されたメッセージであり、sは、署名である。
メッセージを復元するために、アリスは下記を実行する。
【0460】
1.
【0461】
【数178】
Figure 0004588874
【0462】
を計算する。
2.ボブの公開署名鍵αbおよび公開暗号化鍵
【0463】
【数179】
Figure 0004588874
【0464】
を得る(内在的証明書方式の場合、ボブの公開署名鍵
【0465】
【数180】
Figure 0004588874
【0466】
を再構成する)。
3.
【0467】
【数181】
Figure 0004588874
【0468】
を計算する。これはrである。
4.メッセージM=DESr(C)を非暗号化する。
【0469】
注:
1.受信者アリスの秘密鍵がa+aEであると考えることができる。これは、受信者が、2つの秘密鍵ではなく1つの秘密鍵だけを必要とすることを意味する。しかし、送信者ボブは、2つの秘密鍵を必要とする。通常の証明書の場合、受信者は、1つの秘密鍵だけを必要とする。
2.証明書方式が、本明細書に記載の内在的証明書でない場合には、アリスおよびボブの公開鍵を検証しなければならない。
3.メッセージMが、なんらかの冗長性またはパターンを有しなければならない。
4.
【0470】
【数182】
Figure 0004588874
【0471】
の中のパラメータOPは、空またはOP=β1‖β2とすることができる。
5.1つのrの値を知っても、ポスト・メッセージの情報は明らかにならない。
6.内在的証明書方式を用いると、ボブは、2回の累乗演算だけを実行し、アリスは、4回の累乗演算を実行する。しかし、双方が認証部分(authentification part)であることを、アリスとボブの双方は秘密にしている(are confidential)。
7.誰かがアリスの秘密鍵a+aEを知るか、ボブが両方の秘密鍵を失った場合、事後暗号化されたメッセージを保護することはできない。
【0472】
通常の署名の場合、1つの問題は、署名者が、自分がその署名を署名したことを否定することである。これを否認(repudiation)と呼ぶ。上のプロトコル1および2は、ジャッジ(judge)を信頼するならば、否認拒否機能(non-repudiation feature)を有する。すなわち、署名者は、自分がサインクリプトされた(signcrypted)メッセージに署名したことを拒否することができない。プロトコル3は、ジャッジが信頼されないときであっても否認拒否機能を有する。次のプロトコルで、ボブが署名を拒否したい場合にジャッジがどのように判断するかを示す。
【0473】
否認拒否プロトコル:
1.アリスが(C、s)をジャッジに送信する。
2.ジャッジは、
【0474】
【数183】
Figure 0004588874
【0475】
を計算する(注:アリスおよびボブの2対の公開鍵を検証しなければならない。内在的証明書方式の場合、再構成公開データから公開鍵を計算しなければならない)。
3.ジャッジは、2つの整数r1およびr2をランダムに選択し、
【0476】
【数184】
Figure 0004588874
【0477】
を計算し、Lをアリスに送信する。
4.アリスは、
【0478】
【数185】
Figure 0004588874
【0479】
を計算し、ジャッジに送り返す。
5.ジャッジは、
【0480】
【数186】
Figure 0004588874
【0481】
を計算し、M=DESr(C)によってメッセージを復元する。
6.Mが正しいフォーマットを有する場合、(C、s)はボブによってサインクリプトされたものに違いない。
7.ジャッジは、判断を行った後に、値
【0482】
【数187】
Figure 0004588874
【0483】
をアリスおよびボブに送信して、自分の判断を確認する。
【0484】
他の2つのサインクリプション・プロトコルの場合、否認拒否(non-repudiation)プロトコルは、ジャッジが完全に信頼されるならば類似したものになる。
【0485】
結論として、本発明の方式は、ユーザーの秘密鍵を計算に直接に使用しなければならないアプリケーション・プロトコルと組み合わされたときに、内在的に証明される、IDに基づくユーザーの公開鍵を提供する。これらの方式は、鍵認証センタ(Key Authentication Center、KAC)が、内在的に証明される公開鍵をユーザーに配送するのに使用することもできる。
【0486】
内在的に証明される公開鍵のもう1つの応用例は、認証機関のビット強度が、証明されるユーザーまたはエンティティの公開鍵と同一であることである。ビット強度によって、相対的な鍵サイズおよび関係するエンティティの処理能力が暗示される。
【0487】
この問題に対処する手法の1つが、X.509証明書で指定されるものなどの従来の証明書構造に、内在的に証明される公開鍵を埋め込むことである。この場合、証明書に対する署名は、内在的に証明される公開鍵より高いビット強度になる。したがって、CAは、2つの異なるセキュリティ・レベルでユーザー公開鍵を証明している。公開鍵を取り出す他のエンティティは、受け入れたいセキュリティ・レベルについて決定することができる。一部の応用分野では、必要な性能をもたらすために、内在的な値(implicit value)によって提供される、より低いレベルだけが必要になる可能性がある。
【0488】
本発明の特定の実施形態および特定の用途に関して本発明を説明してきたが、請求項に記載された本発明の趣旨から逸脱せずに、当業者は本発明のさまざまな変更形態を思い浮かべるであろう。たとえば、好ましい実施形態の上の説明では、乗法表現(multiplicative notation)を利用したが、本発明の方法は、加法表現(additive notation)を使用しても同様に良好に説明することができる。たとえば、ECDSAで実施された楕円曲線アルゴリズムがDSAと同等であることは周知であり、そして、楕円曲線は離散対数アルゴリズムに類似することは、モジュロ素数の整数(integers moduro a prime)の乗法群Fp *の設定(setting)で通常記述される。群Fp *および楕円曲線群E(Fq)の要素および演算の間には対応関係がある。さらに、この署名技法は、FpおよびF2 上で定義されるフィールド(field)の中で実行される関数にも同様に良好に適用可能である。また、上で説明したDSA署名方式は、当技術分野で既知の一般化されたElGamal署名方式の特定の実例(specific instance)であり、したがって、本発明の技法がこれに適用可能であることに留意されたい。
【図面の簡単な説明】
【図1】 本発明の実施形態に従って構成された第1のシステムの概略図である。
【図2】 本発明の実施形態に従って構成された第2のシステムの概略図である。

Claims (14)

  1. 少なくとも1つの信頼できる当事者CAおよび少なくとも1つの加入者エンティティAを有する安全なディジタル通信システムにおいて公開鍵を生成する方法であって、前記方法は、
    (a)前記信頼できる当事者CAが、前記加入者エンティティAを区別する一意のアイデンティティIを選択するステップと、
    (b)前記信頼できる当事者CAが、前記信頼できる当事者CAおよび前記加入者エンティティAそれぞれの秘密値から得られた公開値を数学的に組み合わせることにより前記加入者エンティティAに対する公開鍵再構成公開データγを生成し、前記加入者エンティティAに対する内在的証明書(I、γ)を得るステップと、
    (c)数学関数F(γ、I)に従って前記内在的証明書(I、γ)を組み合わせることによりエンティティ情報fを導出するステップと、
    (d)前記エンティティ情報fを前記信頼できる当事者CAの前記秘密値にバインドすることによって値kを生成し、前記値kを前記加入者エンティティAに送信することにより、前記加入者エンティティAが、前記値k 前記加入者エンティティAの前記秘密値と前記内在的証明書(I 、γ )とから秘密鍵を生成することを可能にするステップと
    含み、
    これによって、前記加入者エンティティ公開鍵が、公開情報前記公開鍵再構成公開データγ 前記アイデンティティI から再構成されることが可能である、方法。
  2. 前記数学関数Fは、安全なハッシュ関数である請求項1に記載の方法。
  3. 前記加入者エンティティAの前記秘密値は、前記加入者エンティティAにおいて利用可能され、前記秘密値から得られたその対応する公開値は、前記信頼できる当事者CAにおいて利用可能にされる請求項1または請求項2に記載の方法。
  4. 前記ステップ(b)において数学的に組み合わせることは、乗算することである請求項1〜3のいずれか一項に記載の方法。
  5. 前記信頼できる当事者CAの前記秘密値は、前記信頼できる当事者CAの秘密鍵と整数値を含む請求項1〜4のいずれか一項に記載の方法。
  6. 前記ステップ(b)において用いられる前記公開値の1つは、前記信頼できる当事者CAの前記秘密鍵に対応する請求項5に記載の方法。
  7. 前記エンティティ情報fに前記整数を乗算することとその結果に前記信頼できる当事者CAの前記秘密鍵を組み合わせることとを行うことによって、前記値kAが計算される請求項5または請求項6に記載の方法。
  8. ディジタル通信システムにおけるデバイスであって、
    前記デバイスは、信頼できる当事者CAであり、
    前記信頼できる当事者CAは、
    (a)加入者エンティティAを区別する一意のアイデンティティI を選択するステップと、
    (b)信頼できる当事者CAおよび前記加入者エンティティAのそれぞれの秘密値から得られた公開値を数学的に組み合わせることにより前記加入者エンティティAに対する公開鍵再構成公開データγ を生成し、前記加入者エンティティAに対する内在的証明書(I 、γ )を得るステップと、
    (c)数学関数F(γ 、I )に従って前記内在的証明書(I 、γ )を組み合わせることによりエンティティ情報fを導出するステップと、
    (d)前記エンティティ情報fを前記信頼できる当事者CAの前記秘密値にバインドすることによって値k を生成し、前記値k を前記加入者エンティティAに送信することにより、前記加入者エンティティAが、前記値k と前記加入者エンティティAの前記秘密値と前記内在的証明書(I 、γ )とから秘密鍵を生成することを可能にするステップと
    を含むステップを実行するように構成されており、
    これによって、前記加入者エンティティの公開鍵が、公開情報と前記公開鍵再構成公開データγ と前記アイデンティティI とから再構成されることが可能である、デバイス。
  9. 前記数学関数Fは、安全なハッシュ関数である、請求項8に記載のデバイス。
  10. 前記加入者エンティティAの前記秘密値は、前記加入者エンティティAにおいて利用可能にされ、前記秘密値から得られたその対応する公開値は、前記信頼できる当事者CAにおいて利用可能にされる、請求項8または請求項9に記載のデバイス。
  11. 前記ステップ(b)において数学的に組み合わせることは、乗算することである、請求項8〜10のいずれか一項に記載のデバイス。
  12. 前記信頼できる当事者CAの前記秘密値は、前記信頼できる当事者CAの秘密鍵と整数値とを含む、請求項8〜11のいずれか一項に記載のデバイス。
  13. 前記ステップ(b)において用いられる前記公開値の1つは、前記信頼できる当事者CAの前記秘密鍵に対応する、請求項12に記載のデバイス。
  14. 前記エンティティ情報fに前記整数を乗算することと、その結果に前記信頼できる当事者CAの前記秘密鍵を組み合わせることとを行うことによって、前記値kAが計算される、請求項12または請求項13に記載のデバイス。
JP2000538463A 1998-03-23 1999-03-23 内在的証明書方式 Expired - Lifetime JP4588874B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
CA2,232,936 1998-03-23
CA 2232936 CA2232936C (en) 1998-03-23 1998-03-23 Implicit certificate scheme
CA2235359A CA2235359C (en) 1998-03-23 1998-04-20 Implicit certificate scheme with ca chaining
CA2,235,359 1998-04-20
PCT/CA1999/000244 WO1999049612A1 (en) 1998-03-23 1999-03-23 Implicit certificate scheme

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2010023602A Division JP5247740B2 (ja) 1998-03-23 2010-02-04 内在的証明書方式

Publications (3)

Publication Number Publication Date
JP2002508529A JP2002508529A (ja) 2002-03-19
JP2002508529A5 JP2002508529A5 (ja) 2006-04-27
JP4588874B2 true JP4588874B2 (ja) 2010-12-01

Family

ID=25680101

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2000538463A Expired - Lifetime JP4588874B2 (ja) 1998-03-23 1999-03-23 内在的証明書方式
JP2010023602A Expired - Lifetime JP5247740B2 (ja) 1998-03-23 2010-02-04 内在的証明書方式
JP2013038451A Expired - Lifetime JP5702813B2 (ja) 1998-03-23 2013-02-28 内在的証明書方式

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2010023602A Expired - Lifetime JP5247740B2 (ja) 1998-03-23 2010-02-04 内在的証明書方式
JP2013038451A Expired - Lifetime JP5702813B2 (ja) 1998-03-23 2013-02-28 内在的証明書方式

Country Status (8)

Country Link
US (7) US6792530B1 (ja)
EP (1) EP1066699B1 (ja)
JP (3) JP4588874B2 (ja)
AU (1) AU758044B2 (ja)
CA (1) CA2235359C (ja)
DE (1) DE69918818T2 (ja)
IL (1) IL138660A0 (ja)
WO (1) WO1999049612A1 (ja)

Families Citing this family (74)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2235359C (en) * 1998-03-23 2012-04-10 Certicom Corp. Implicit certificate scheme with ca chaining
IL128183A0 (en) * 1999-01-21 1999-11-30 L P K Information Integrity Lt Systems and methods for certifying public keys in digital signatures and key-agreements
US6442696B1 (en) * 1999-10-05 2002-08-27 Authoriszor, Inc. System and method for extensible positive client identification
AU2001267198A1 (en) * 2000-06-09 2001-12-17 Certicom Corp. A method for the application of implicit signature schemes
US7937089B2 (en) * 2002-02-06 2011-05-03 Palo Alto Research Center Incorporated Method, apparatus, and program product for provisioning secure wireless sensors
GB0215590D0 (en) * 2002-07-05 2002-08-14 Hewlett Packard Co Method and apparatus for generating a cryptographic key
US20050089173A1 (en) * 2002-07-05 2005-04-28 Harrison Keith A. Trusted authority for identifier-based cryptography
SG145524A1 (en) * 2002-08-07 2008-09-29 Mobilastic Technologies Pte Lt Secure transfer of digital tokens
AU2002330834A1 (en) * 2002-08-30 2004-04-23 Agency For Science, Technology And Research Public key cryptography and a framework therefor
US8108678B1 (en) * 2003-02-10 2012-01-31 Voltage Security, Inc. Identity-based signcryption system
US20040117626A1 (en) * 2003-09-12 2004-06-17 Pioneer Research Center Usa, Inc. Key exchange based on dsa type certificates
CN1902853B (zh) 2003-10-28 2012-10-03 塞尔蒂卡姆公司 一种公开密钥的可验证生成的方法和设备
US20080098213A1 (en) * 2004-07-08 2008-04-24 Koninklijke Philips Electronics, N.V. Method of Providing Digital Certificate Functionality
US7886144B2 (en) * 2004-10-29 2011-02-08 Research In Motion Limited System and method for retrieving certificates associated with senders of digitally signed messages
GB2421407A (en) * 2004-12-18 2006-06-21 Hewlett Packard Development Co Generating a shared symmetric key using identifier based cryptography
CA2510366C (en) 2005-06-14 2013-02-26 Certicom Corp. System and method for remote device registration
US9692737B2 (en) * 2006-02-28 2017-06-27 Certicom Corp. System and method for product registration
EP2082524B1 (en) * 2006-11-15 2013-08-07 Certicom Corp. Implicit certificate verification
US8219820B2 (en) 2007-03-07 2012-07-10 Research In Motion Limited Power analysis countermeasure for the ECMQV key agreement algorithm
WO2008106793A1 (en) * 2007-03-06 2008-09-12 Research In Motion Limited Power analysis attack countermeasure for the ecdsa
WO2009009869A1 (en) 2007-07-17 2009-01-22 Certicom Corp. Method and system for generating implicit certificates and applications to identity-based encryption (ibe)
WO2009090519A1 (en) * 2008-01-15 2009-07-23 Nxp B.V. Efficient reconstruction of a public key from an implicit certificate
US8327146B2 (en) * 2008-03-31 2012-12-04 General Motors Llc Wireless communication using compact certificates
US8582775B2 (en) * 2009-02-12 2013-11-12 General Motors Llc Method of securing and authenticating data using micro-certificates
US20100241852A1 (en) * 2009-03-20 2010-09-23 Rotem Sela Methods for Producing Products with Certificates and Keys
CA2760934C (en) 2009-05-05 2015-03-17 Certicom Corp. Self-signed implicit certificates
US8429408B2 (en) * 2010-06-11 2013-04-23 Certicom Corp. Masking the output of random number generators in key generation protocols
EP2395698B1 (en) * 2010-06-11 2014-08-13 Certicom Corp. Implicit certificate generation in the case of weak pseudo-random number generators
HUE030543T2 (en) * 2010-09-30 2017-05-29 Entersekt Int Ltd Mobile handset identification and communication authentication
CA2827112C (en) * 2011-02-11 2016-05-31 Certicom Corp. Using a single certificate request to generate credentials with multiple ecqv certificates
US8701169B2 (en) 2011-02-11 2014-04-15 Certicom Corp. Using a single certificate request to generate credentials with multiple ECQV certificates
US8572367B2 (en) 2011-02-28 2013-10-29 Certicom Corp. System and method for reducing computations in an implicit certificate scheme
US20120233457A1 (en) * 2011-03-08 2012-09-13 Certicom Corp. Issuing implicit certificates
US9003181B2 (en) * 2011-03-23 2015-04-07 Certicom Corp. Incorporating data into cryptographic components of an ECQV certificate
US8675869B2 (en) 2011-03-23 2014-03-18 Blackberry Limited Incorporating data into an ECDSA signature component
EP2705629A4 (en) 2011-05-06 2015-07-29 Certicom Corp VALIDATION OF A LOT OF IMPLIED CERTIFICATES
EP2533457B8 (en) 2011-06-10 2019-12-11 BlackBerry Limited Secure implicit certificate chaining
WO2012170131A1 (en) 2011-06-10 2012-12-13 Certicom (U.S.) Limited Digital signatures with implicit certificate chains
US20130091362A1 (en) * 2011-10-10 2013-04-11 Certicom Corp. Generating implicit certificates
US8745376B2 (en) * 2011-10-14 2014-06-03 Certicom Corp. Verifying implicit certificates and digital signatures
US8793485B2 (en) * 2011-12-15 2014-07-29 Texas Instruments Incorporated Combined digital certificate
US9065642B2 (en) * 2012-03-07 2015-06-23 Certicom Corp. Intercepting key sessions
EP2826201B1 (en) 2012-03-15 2019-05-08 BlackBerry Limited Method for securing messages
US9219610B2 (en) 2012-03-15 2015-12-22 Blackberry Limited Method for securing messages
US20130303085A1 (en) 2012-05-11 2013-11-14 Research In Motion Limited Near field communication tag data management
JP5863605B2 (ja) * 2012-09-04 2016-02-16 日本電信電話株式会社 鍵交換システム、要求装置、応答装置、鍵交換方法、およびプログラム
CN102945650B (zh) * 2012-10-30 2015-04-22 合肥京东方光电科技有限公司 一种移位寄存器及阵列基板栅极驱动装置
US9705683B2 (en) 2014-04-04 2017-07-11 Etas Embedded Systems Canada Inc. Verifiable implicit certificates
GB2531848B (en) * 2014-10-31 2017-12-13 Hewlett Packard Entpr Dev Lp Management of cryptographic keys
US9479337B2 (en) * 2014-11-14 2016-10-25 Motorola Solutions, Inc. Method and apparatus for deriving a certificate for a primary device
EP3754901A1 (en) 2016-02-23 2020-12-23 Nchain Holdings Limited Blockchain implemented counting system and method for use in secure voting and distribution
AU2017223129A1 (en) 2016-02-23 2018-07-12 nChain Holdings Limited Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system
GB2561727A (en) 2016-02-23 2018-10-24 Nchain Holdings Ltd Blockchain-based exchange with tokenisation
CA3013182A1 (en) 2016-02-23 2017-08-31 nChain Holdings Limited Universal tokenisation system for blockchain-based cryptocurrencies
EP3860037A1 (en) 2016-02-23 2021-08-04 Nchain Holdings Limited Cryptographic method and system for secure extraction of data from a blockchain
SG10202011641RA (en) 2016-02-23 2021-01-28 Nchain Holdings Ltd Tokenisation method and system for implementing exchanges on a blockchain
EP3420668B1 (en) 2016-02-23 2023-08-23 nChain Licensing AG Method and system for efficient transfer of cryptocurrency associated with a payroll on a blockchain that leads to an automated payroll method and system based on smart contracts
SG11201805472RA (en) 2016-02-23 2018-07-30 Nchain Holdings Ltd Determining a common secret for the secure exchange of information and hierarchical, deterministic cryptographic keys
KR20180114942A (ko) 2016-02-23 2018-10-19 엔체인 홀딩스 리미티드 분산형 해시 테이블 및 블록체인을 사용하여 컴퓨터 소프트웨어를 보호하기 위한 방법 및 시스템
CA3227439A1 (en) 2016-02-23 2017-08-31 nChain Holdings Limited Registry and automated management method for blockchain-enforced smart contracts
KR101999188B1 (ko) 2016-02-23 2019-07-11 엔체인 홀딩스 리미티드 비밀 공유를 위한 타원 곡선 암호를 사용하는 개인용 장치 보안
SG10202011640TA (en) 2016-02-23 2021-01-28 Nchain Holdings Ltd System and method for controlling asset-related actions via a blockchain
EP3420517B1 (en) 2016-02-23 2022-07-06 nChain Holdings Limited A method and system for the secure transfer of entities on a blockchain
CN113595726A (zh) 2016-02-23 2021-11-02 区块链控股有限公司 用于控制和分发数字内容的区块链实现的方法
FR3048319B1 (fr) * 2016-02-25 2018-03-09 Commissariat A L'energie Atomique Et Aux Energies Alternatives Methode de gestion de certificats implicites au moyen d'une infrastructure a cles publiques distribuee
US11283626B2 (en) * 2016-09-06 2022-03-22 Huawei Technologies Co., Ltd. Apparatus and methods for distributed certificate enrollment
CN108574570B (zh) 2017-03-08 2022-05-17 华为技术有限公司 私钥生成方法、设备以及系统
CN108574571B (zh) 2017-03-08 2021-12-03 华为技术有限公司 私钥生成方法、设备以及系统
JP7372938B2 (ja) 2018-05-14 2023-11-01 エヌチェーン ライセンシング アーゲー ブロックチェーンを使って原子的スワップを実行するためのコンピュータ実装されるシステムおよび方法
GB201815396D0 (en) 2018-09-21 2018-11-07 Nchain Holdings Ltd Computer implemented system and method
US11263630B2 (en) 2018-10-12 2022-03-01 Blackberry Limited Method and system for single purpose public keys for public ledgers
GB201909960D0 (en) 2019-07-11 2019-08-28 Nchain Holdings Ltd Computer-implemented system and method
CN112838922B (zh) * 2021-01-22 2023-03-07 广东工业大学 基于混沌映射和选择性Signcryption的DICOM图像非对称加密方法
CN114598460B (zh) * 2022-02-18 2023-05-16 中国人民解放军战略支援部队信息工程大学 基于sm9的多接收者签密方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CH678134A5 (en) * 1989-01-13 1991-07-31 Ascom Radiocom Ag Authenticated cryptographic key exchange in digital subscriber network - using preliminary phase of multiplication in finite galois field with random number selection for public key
JP2956709B2 (ja) * 1990-11-26 1999-10-04 松下電器産業 株式会社 公開鍵生成方法及び装置
JP2945523B2 (ja) * 1991-09-06 1999-09-06 松下電器産業株式会社 ネットワーク利用秘密及び署名通信方法
JP2942395B2 (ja) * 1991-08-08 1999-08-30 松下電器産業株式会社 秘密通信用ネットワークシステム
US5199070A (en) * 1990-12-18 1993-03-30 Matsushita Electric Industrial Co., Ltd. Method for generating a public key
US6085320A (en) * 1996-05-15 2000-07-04 Rsa Security Inc. Client/server protocol for proving authenticity
CA2235359C (en) 1998-03-23 2012-04-10 Certicom Corp. Implicit certificate scheme with ca chaining

Also Published As

Publication number Publication date
IL138660A0 (en) 2001-10-31
DE69918818D1 (de) 2004-08-26
DE69918818T2 (de) 2005-08-25
JP2002508529A (ja) 2002-03-19
JP5702813B2 (ja) 2015-04-15
JP2013102549A (ja) 2013-05-23
US20090041238A1 (en) 2009-02-12
US8712042B2 (en) 2014-04-29
EP1066699B1 (en) 2004-07-21
US20050114651A1 (en) 2005-05-26
US20140229730A1 (en) 2014-08-14
US7653201B2 (en) 2010-01-26
US20120303950A1 (en) 2012-11-29
AU2823599A (en) 1999-10-18
JP5247740B2 (ja) 2013-07-24
CA2235359C (en) 2012-04-10
US8705735B2 (en) 2014-04-22
US20120300924A1 (en) 2012-11-29
US8270601B2 (en) 2012-09-18
JP2010097236A (ja) 2010-04-30
US6792530B1 (en) 2004-09-14
US20100166188A1 (en) 2010-07-01
CA2235359A1 (en) 1999-09-23
WO1999049612A1 (en) 1999-09-30
EP1066699A1 (en) 2001-01-10
US7391868B2 (en) 2008-06-24
AU758044B2 (en) 2003-03-13

Similar Documents

Publication Publication Date Title
JP4588874B2 (ja) 内在的証明書方式
US10530585B2 (en) Digital signing by utilizing multiple distinct signing keys, distributed between two parties
EP0739105B1 (en) Method for signature and session key generation
US7036015B2 (en) Verification protocol
US8522012B2 (en) Method for the application of implicit signature schemes
US7779259B2 (en) Key agreement and transport protocol with implicit signatures
US20010042205A1 (en) Key agreement and transport protocol
JP2003298568A (ja) 鍵供託を使用しない、認証された個別暗号システム
EP0873617A1 (en) Key agreement and transport protocol with implicit signatures
US20040139029A1 (en) Apparatus and method for generating and verifying ID-based blind signature by using bilinear parings
Kuppuswamy et al. A new efficient digital signature scheme algorithm based on block cipher
JP4307589B2 (ja) 認証プロトコル
Hwu et al. End-to-end security mechanisms for SMS
EP2104268B1 (en) Key agreement and transport protocol with implicit signatures
CA2232936C (en) Implicit certificate scheme

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060308

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060308

RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7426

Effective date: 20060308

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20060308

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20060309

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090804

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20091102

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20091102

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20091203

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20091228

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100105

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100108

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100204

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100811

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100909

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130917

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130917

Year of fee payment: 3

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: R3D04

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term