JP5702813B2 - 内在的証明書方式 - Google Patents
内在的証明書方式 Download PDFInfo
- Publication number
- JP5702813B2 JP5702813B2 JP2013038451A JP2013038451A JP5702813B2 JP 5702813 B2 JP5702813 B2 JP 5702813B2 JP 2013038451 A JP2013038451 A JP 2013038451A JP 2013038451 A JP2013038451 A JP 2013038451A JP 5702813 B2 JP5702813 B2 JP 5702813B2
- Authority
- JP
- Japan
- Prior art keywords
- integer
- entity
- public
- key
- mod
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic 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/3263—Cryptographic 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key 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/0841—Key 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/0844—Key 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic 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/3247—Cryptographic 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
本発明は、暗号化鍵の転送および認証のための鍵配送方式に関する。
Diffie−Hellman鍵共有(Diffie-Hellman key agreement)は、暗号システムでの鍵配送問題(Keydistribution problem)に対する最初の実用的な解決策をもたらした。この鍵共有プロトコルでは、事前に会ったことも共有(分散)鍵材料(sharedkeymaterial)を有したこともない2つの当事者が、オープンな(保護されない)チャネルを介してメッセージ(文書)を交換することによって、共有される秘密(sharedsecret)を確立することができる。セキュリティは、Diffie−Hellman問題の扱い難さと、関連する離散対数の計算問題にかかっている。
て公開鍵を格納、配送、または転送することのできる媒介物(vehicle)である。その目
的は、一方の当事者の公開鍵を他方の当事者が入手できるようにし、その認証性(authenticity)および有効性(validity)を検証可能に(verfiable)することである。
CA)のディジタル署名からなり、これによって、エンティティのアイデンティティ(identity;個人情報)が、指定された公開鍵と結びつけられる。CAは信頼できる第三者で
あり、証明書のCAの署名は対象のエンティティに結びつけられた公開鍵の認証性(Authenticity)を保証する。
を用いるが、当事者は、以前のように明示的な公開鍵を有しない。その代わりに、公開鍵は、効果的に、一般に入手可能な当事者のアイデンティティ情報(たとえば氏名またはネットワーク・アドレス)に置換される。当事者を一意に識別し、その当事者に否定不能な形で(undeniably)関連付けることができる、一般に入手可能な情報であれば、どのような情報でもアイデンティティ情報として使用可能である。
るのではなく、再構成(reconstruct)されなければならない。したがって、内在的に証
明される公開鍵は、公開鍵(たとえばDiffie−Hellman鍵)を配送するための代替手段として使用することができる。
1.信頼できるサーバT(trusted server)が、適当な固定された公開の素数p、およびZp *のジェネレータαを選択する。Tは、1≦t≦p−2かつgcd(t,p−1)=1であるランダムな整数tをその秘密鍵(privatekey)として選択し、公開鍵u=αt
mod pをαおよびpと共に公開する。
下で示すように(PA)aを計算することができるようになる。
H(IA)≡t.PA+kAa(mod p−1)
4.Tは、IAに対するTのElGamal署名である対(r,s)=(PA,a)を、保護された形でAに送信する(aは、Diffie−Hellman鍵共有のためのAの秘密鍵である)。
u、PA、p)だけから、AのDiffie−Hellman公開鍵PA αを再構成することができる。
、計算量的に強烈(computationallyintensive)であることが既知である。たとえば、RSA方式は、楕円曲線システムと比較して極端に低速である。しかし、RSAタイプのシステムに対するECシステムの明確な効率にもかかわらず、これは、特に「スマート・カード」、ポケット・ベル、および類似物などの限られた計算能力を有するコンピューティング装置にとって、まだ問題である。
本発明は、既存の方式に対して改良された計算速度をもたらす、効率的なIDに基づく内在的証明書方式の提供を試みる。便宜上、本明細書ではZpに対する方式を説明するが
、これらの方式は、楕円曲線暗号システムでも同等に実施可能である。
(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から比較的効率的に再構成できるようにする方法が提供される。
の公開鍵を含み、公開鍵の1つが内在的に証明される公開鍵になることを特徴とする、公開鍵証明書が提供される。
例えば、本発明は以下を提供する。
(項目1) 少なくとも1つの信頼できるエンティティCAおよび加入者エンティティAを有する保護されたディジタル通信システムで公開鍵を生成する方法であって、
(a)各エンティティAについて、前記CAが、前記エンティティAを区別する一意のアイデンティティIAを選択するステップと、
(b)前記信頼できる当事者CAのジェネレータを前記エンティティAの私的な値(private value)と数学的に組み合わせてエンティティAの公開鍵再構成公開データγAを生成するステップであって、前記対(IA、γA)がAの内在的証明書(implicitcertificate)として働くように前記γAを生成するステップと、
(c)数学関数F(γA、IA)に従って前記内在的証明書情報(IA、γA)を組み合わせてエンティティ情報fを導出するステップと、
(d)前記エンティティ情報fに署名することによって前記エンティティAの秘密鍵(private key)を生成するステップと
前記秘密鍵を前記エンティティAに送信するステップとを備え、
これによって、前記エンティティAの公開鍵は、前記公開情報、前記ジェネレータγA
、および前記アイデンティティIAから比較的効率的に再構成されることできることを特
徴とする公開鍵の生成する方法。
(項目2) ディジタル通信システムにおける公開鍵証明書を生成する方法であって、
(a)公開鍵暗号アルゴリズムに従って、公開鍵証明書を生成するステップと、
(b)複数の公開鍵であって、前記公開鍵の少なくとも1つが、内在的に署名される公開鍵(implicitly signed public key)である前記複数の公開鍵を公開鍵証明書内に埋め込むステップと、
(c)前記証明書を公開するステップと
を含むとを特徴とする公開鍵証明書の生成方法。
(項目3) 信頼できるエンティティCAによって加入者エンティティAの公開鍵証明書を生成する方法であって、
a)前記加入者エンティティAの一意のアイデンティティ情報IAを選択するステップ
と、
b)前記加入者エンティティAの私的な値cAを生成するステップと、
c)前記私的な値(private value)cAから前記エンティティAの公開値γAを生成す
るステップと、
d)値fを生成するために、暗号関数内で前記公開値γAおよび前記アイデンティティ
情報IAを使用するステップと、
e)署名aを作るために前記値fに署名するステップと、
f)前記署名a、公開値γA、および前記アイデンティティ情報IAを前記加入者エンティティに送信するステップと
を含むとを特徴とする公開鍵証明書の生成方法。
図1を参照すると、内在的に証明される公開鍵(Implicitly certified public key)
を有するシステムが、全般的に符号10によって示されている。このシステム10には、信頼できる第三者のCAおよび、少なくとも第1通信者Aおよび第2通信者Bの対が含まれる。通信者AおよびBは、通信チャネルを介して情報を交換し、通信者AおよびBのそれぞれには、認定/検証(finding/verification)および暗号化/非暗号化(解読)(encryption/decryption)を実行する暗号装置(cryptographicunit)が含まれる。
密鍵として1≦c≦q−1のランダムな整数cを選択し、公開鍵β=αcを計算し、(β
、α、p、q)を公開する。
1.各当事者Aについて、CAは、一意の区別される名前またはアイデンティティIA
(たとえば、氏名、住所、電話番号)および、1≦cA≦q−1のランダムな整数cAを選択する。次に、CAは、
の内在的証明書として働く)。
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のジェネレータであり、
Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算し、したがって公開鍵を導出することによって、公開ドメインから当事者Aの(IDに基づく)内在的に検証可能な公開鍵を得ることができる。
γA a=αβ-f(mod p)
このように上述の式から公開鍵を引き出すことは、ただ1つの累乗演算(exponentiation operation)を必要とする。
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)になる。
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.
5.r=r’の場合には、署名が検証される。それと同時に、アリスの(IDに基づく)公開鍵が、内在的に検証される。
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の公開鍵である。
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を含む各ユーザーが、同一のジェネレータαを有する。
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を含む各ユーザーが、同一のジェネレータαを有する。
Aは、まず、整数kをランダムに選択し、αkを計算し、これをCAに送信する。CA
は、
1=cf+cAkA(mod q)
その後、CAは、
)およびγA=(γA 1)k(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をランダムに選択し、
1=ckA+cAf(mod q)
その後、CAは、
注:(γA 1、kA、IA)は、公開チャネルによって送信することができる。
3.Aは、
場合には、ステップ1に戻る)。その後、βa=αγA -fであるかどうかを検査する。ここで、aがAの秘密鍵、βがAのジェネレータ、βaがAの公開鍵になる。Aは、公開ドメ
インで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
方式7:
Aは、まず、整数kをランダムに選択し、αkを計算し、これをCAに送信する。ここ
でCAは、
kA≡cf+cA(mod q)
その後、CAは、
、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開
する。誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
方式8:
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
択する)。
kA≡cAf+c(mod q)
その後、CAは、
注:(γA 1、kA、IA)は、公開チャネルによって送信することができる。
3.Aは、
合には、ステップ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を計算できることである。
1.Aは、まず、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
1=cf+cAkA(mod q)
次に、CAは、K=(ak)c(mod p)および
3.Aは、K=βk(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)
方式10:
1.Aは、まず、整数kをランダムに選択し、βkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
1=ckA+cAf(mod q)
次に、CAは、
注:
3.Aは、
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をランダムに選択し、
を選択する)。
kA=cf+cA(mod q)
次に、CAは、K=(αk)c(mod p)および
注:
3.Aは、K=βk(mod p)、
戻る)。その後、αa=βfγAであるかどうかを検査する。ここで、aがAの秘密鍵、α
がAのジェネレータ、αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、αa=γA f(mod p)を計算することによって、公開ドメインからA
の(IDに基づく)内在的に証明される公開鍵を得ることができる。
1.Aは、まず、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
)kA=cAf+c(mod q)を計算する。
次に、CAは、K=(αk)c(mod p)および
注:
3.Aは、K=βk(mod p)、
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が暗号化され、他人がそれを知ることができなくなっていることである。
1.Aは、まず、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
kA≡cf+cA(mod q)
次に、CAは、K=H((αk)c)および
3.Aは、K=H(βk)、
戻る)。その後、γ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)を減らすことができる。
1.Aは、まず、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
kA≡cf+cA(mod q)
次に、CAは、K=(αk)c(mod p)および
注:
3.Aは、K=βk(mod p)、
戻る)。その後、
の公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
方式5.cのセキュリティ・レベルは、前に述べた他の方式ほどではない。方式5.cは、80ビットのセキュリティだけを有する。しかし、現在の実用的なアプリケーションにはこれでよい。最初の80個の最下位ビットを、γAの半分の下位ビットに拡張するこ
とができる。
1.整数aEをランダムに選択し、
2.Aは、整数kをランダムに選択し、αkを計算し、αkおよび
3.CAは、整数cAをランダムに選択し、
kA=cf+cA(mod q)
その後、CAは、
注:(γA 1、kA、IA)は、公開チャネルによって送信することができる。
4.Aは、a=kA+k(mod q)を計算し(a=0、1の場合には、ステップ1
に戻る)、
名鍵であり、αがAのジェネレータ、αaがAの公開署名鍵であり、aEがAの秘密暗号化鍵、
5.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
注:(方式13〜15について)
1.アイデンティティIAは、CAまたはエンティティAのいずれかによって選択する
ことができる。
2.CAは、エンティティAを認証しなければならない。これは、方式11の注2に記載の方法によって行うことができる。
3.
本発明の方式では、(α、γA)は、AのID、IAに対するCAの署名であり、これは公衆によって知られると思われた。しかし、現在は、ユーザーAだけがaを知る。したがって、本発明の方式を使用するときには、アプリケーション・プロトコルで、ユーザーAが自分自身の秘密鍵を知るようにしなければならない。言い換えると、アプリケーション・プロトコルは、Aが計算に自分の秘密鍵を使用することを保証しなければならない。
1=cf+cAa(mod q) (1)
以下で、1方向関数F(γA、IA)の選択について、新しい方式1がDSAと同等であることを示す。
する。まず、CAは、cAをランダムに選択し、
、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)=γA
h(IA)-1の場合に、式(1)と同等である。これは、誰かが署名方程式(1)を使用
してこの方式を破ることができる場合に、その人物が、DSA方式である署名方程式(2)を使用してこの方式を破ることができることを意味する。
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に基づく内在的に証明される公開鍵方式が動作する方法である。
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つと同等になることに留意されたい。しかし、本明細書で提案される方式は、より高い効率を有する。
1.各エンティティAについて、CAは、一意の区別される名前またはアイデンティティIA(たとえば、氏名、住所、電話番号)および、1<cA<qのランダムな整数cAを
選択する。次に、CAは、
的証明書として働く)。
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のジェネレータ、
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を有する。
1.各エンティティAについて、CAは、一意の区別される名前またはアイデンティティIA(たとえば、氏名、住所、電話番号)および、1<cA<qのランダムな整数cAを
選択する。次に、CAは、
証明書として働く)。
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.この方式では、各ユーザーが同一のシステム・ジェネレータβを有する。
1.各エンティティAについて、CAは、一意の区別される名前またはアイデンティティIA(たとえば、氏名、住所、電話番号)および、1<cA<qのランダムな整数cAを
選択する。次に、CAは、
証明書として働く)。
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.この方式では、各ユーザーが同一のシステム・ジェネレータαを有する。
1.各エンティティAについて、CAは、一意の区別される名前またはアイデンティティIA(たとえば、氏名、住所、電話番号)および、1<cA<qのランダムな整数cAを
選択する。次に、CAは、
証明書として働く)。
2.CAは、f=F(γA、IA、OP)を計算し、aについて次式を解く(a=0、1、またはcの場合には、別のcAを選択し、式をもう一度解く)。
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.この方式では、各ユーザーが同一のシステム・ジェネレータαを有する。
することになる。たとえば、方式1.aでは、検証者がαβ-fを計算し、ユーザーAがaを使用してγA aを計算する場合に、検証者およびユーザーが、一緒に証明書を検証することができる。しかし、検証者は、ユーザーAが実際にaを知っていることを確認しなければならない。したがって、公開鍵の再構成は、ユーザー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.
5.r=r’の場合には、署名が検証される。それと同時に、アリスの(IDに基づく)公開鍵が、内在的に検証される。
対(IA、γA)は、アリスの証明書として働く。DSAの場合、aを知らずにアリスの署名を偽造することが非常に困難であることがわかっている。公開鍵の再構成は、アプリケーション・プロトコルが最後に有効になるときに、内在的検証として働く。公開鍵を取得するために、1回の累乗演算だけが必要であることを想起されたい。この理由から、本発明人は、内在的証明書の検証が、1回の累乗演算を必要とすると主張する。
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
1=cf+cAkA(mod q)
その後、CAは、
3.Aは、a=kAk-1(mod q)を計算し(a=1の場合には、ステップ1に戻
る)、γA=(γA 1)k(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をランダムに選択し、
1=ckA+cAf(mod q)
その後、CAは、
7.Aは、
、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をランダムに選択し、
kA≡cf+cA(mod q)
その後、CAは、
3.Aは、a=kA+k(mod q)を計算し(a=0、1の場合には、ステップ1
に戻る)、
、αが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をランダムに選択し、
cAを選択する)。
kA≡cAf+c(mod q)
その後、CAは、
3.Aは、
、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)は、公開チャネルによって送信することができる。
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
1=cf+cAkA(mod q)
次に、CAは、K=H((αk)c)および
3.Aは、K=H(βk)、
)。その後、γ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をランダムに選択し、
1=ckA+cAf(mod q)
次に、CAは、
3.Aは、
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つ組
3.
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
kA≡cf+cA(mod q)
次に、CAは、K=H((αk)c)および
3.Aは、K=H(βk)、
戻る)。その後、α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をランダムに選択し、
kA≡cAf+c(mod q)
次に、CAは、K=H((αk)c)および
3.Aは、K=H(βk)、
、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((αk)c)を計算し、DESK(AAI)を非暗号化し
てAAIを得る。AAIの有効性を検査した後に、CAはステップ2を継続する。
3.(γA、kA、IA)は、公開チャネルによって送信することができる。
いることである。実際に、kAが知れわたることが、証明書方式のセキュリティを低下さ
せない。kAを暗号化する目的は、エンティティが確実にkを知るようにするためである
。したがって、方式3.a〜3.dについて、証明書方式で注2で説明した方法を使用するならば、DES暗号化部分を除去することができ、
送信することによって上の方式を変更することができる(一般に、γAのサイズは160
ビットより大きく、fはちょうど160ビットであることに留意されたい)。下の方式4.cは、方式3.cの変形形態である。
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
kA≡cf+cA(mod q)
次に、CAは、K=H((αk)c)および
3.Aは、K=H(βk)、
戻る)。その後、γ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に従うことによって、帯域幅を減らすことができる。
1.Aは、整数kをランダムに選択し、αkを計算し、これをCAに送信する。
2.CAは、整数cAをランダムに選択し、
kA≡cf+cA(mod q)
次に、CAは、K=(αk)c(mod p)および
3.Aは、K=βk(mod p)、
戻る)。その後、
の公開鍵になる。Aは、公開ドメインで(α、IA、β、γA、p、q)を公開する。
4.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
方式5.cのセキュリティ・レベルは、前に述べた他の方式ほどではない。方式5.cは、80ビットのセキュリティだけを有する。しかし、現在の実用的なアプリケーションにはこれでよい。最初の80個の最下位ビットを、γAの半分の下位ビットに拡張するこ
とができる。
1.Aは、整数aEをランダムに選択し、
2.Aは、整数kをランダムに選択し、αkを計算し、αkおよび
kA≡cf+cA(mod q)
その後、CAは、
4.Aは、a=kA+k(mod q)を計算し(a=0、1の場合には、ステップ1
に戻る)、
名鍵であり、αがAのジェネレータ、αaがAの公開署名鍵である。aEがAの秘密暗号化鍵、
5.誰もが、次式を計算することによって、公開ドメインからAの(IDに基づく)内在的に証明される公開鍵を得ることができる。
αa=βfγA(mod p)
注:(方式4.c、5.c、6.cについて)
1.アイデンティティIAは、CAまたはエンティティAのいずれかによって選択する
ことができる。
2.CAは、エンティティAを認証しなければならない。これは、方式3.cの注2に記載の方法によって行うことができる。
CA連鎖構造を実施するために、すなわち、CA1がCA2を認証し、CA2がCA3を認証し、CA3がユーザーAを認証する。この節では、CA連鎖内に3つのCAがある例を提示する。基本方式3’を使用して、この例を実証する。
最上位の信頼できる当事者CA1は、大きい素数qについてp=tq+1である適当な素数pと、オーダー(位数)qのジェネレータαを選択する。CA1は、その秘密鍵として1≦c1≦q−1のランダムな整数c1を選択し、公開鍵
フェーズ1 CA2が、CA1からの内在的に証明される公開鍵を問い合わせる。
1.CA2は、整数k2をランダムに選択し、
3.CA1は、関数f1=F(γCA2、ICA2)を選択し、kCA2を計算する(kCA2=0
の場合には、ステップ2で別のcCA2を選択し、kCA2を再計算する)。
kCA2=c1f1+cCA2(mod q)
4.CA1が、
5.CA2が、
ジェネレータ、
注:ユーザーがCA2を信頼するときには、β2を直接に使用することができる。
6.誰もが、次式を計算することによって、公開ドメインからCA2の(IDに基づく)内在的に検証された公開鍵を得ることができる。
1.CA3は、整数k3をランダムに選択し、
3.CA2は、関数f2=F(γCA3、ICA3)を選択し、kCA3を計算する(kCA3=0
の場合には、ステップ2で別のcCA3を選択し、kCA3を再計算する)。
kCA3≡c2f2+cCA3(mod q)
4.CA2が、
5.CA3が、
ジェネレータ、
6.誰もが、次式を計算することによって、公開ドメインからCA3の(IDに基づく)内在的に検証された公開鍵を得ることができる。
1.Aは、整数kをランダムに選択し、αkを計算し、これをCA3に送信する。
2.CA3は、一意の区別される名前またはアイデンティティIAおよび、1≦cA≦q−1のランダムな整数cAを選択する。CA3が、
3.CA3は、注意深く選択された関数f3=F(γA、IA)を選択し、kAを計算する(kA=0の場合には、ステップ2で別のcAを選択し、kAを再計算する)。
4.CA3は、
、βA=αaがAの公開鍵になる。Aは、公開ドメインで(α、IA、β3、βA、γA、p、q)を公開する。
注:ユーザーがAを信頼するときには、β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の公開データを得る。
2.ユーザーAの公開鍵を再構成する。
4.r’=αsβA -e(mod p)を計算する。
5.r=r’の場合には、署名が検証される。それと同時に、CA2、CA3、およびユーザーAの(IDに基づく)公開鍵が、内在的に検証される。
1.検証者がAを信頼する場合には、Aの公開鍵はβAになる。
2.検証者がCA3を信頼する場合には、Aの再構成公開鍵は
以下では、複数のCAが1つの内在的証明書に署名できるようにする方式を説明する。これは、基本方式3’を使用して3つのCAが証明書に連署する場合によって例示される。
CA1、CA2、およびCA3が、次の共通のシステム・パラメータを有すると仮定する。(1)大きい素数qに対してp=tq+1になる素数p、(2)オーダーqのジェネレータα、(3)注意深く選択された関数f=F(γ,(IA1+IA2+IA3))。CA1は、その秘密鍵として1≦c1≦q−1のランダムな整数c1を選択し、公開鍵
ステップ2 CAが、情報を交換し、内在的証明書を計算する。
1.CA1が、一意の区別される名前またはアイデンティティIA1および、1≦cA1≦q−1のランダムな整数cA1を選択し、
2.CA2が、一意の区別される名前またはアイデンティティIA2および、1≦cA2≦q−1のランダムな整数cA2を選択し、(
1.CA1が、
kA1≡c1f+cA1(mod q)
CA1は、
2.CA2が、
kA2≡c2f+cA2(mod q)
CA2は、
kA3≡c3f+cA3(mod q)
CA3は、
ステップ3 Aが、内在的に連署された秘密鍵および公開鍵再構成情報を計算する。
1.Aは、a=kA1+kA2+kA3+k(mod q)を計算する(aが0または1の場合には、ステップ1に戻る)。
2.Aが、
γ(mod p)であるかどうかを検証する。
3.ここで、aがAの内在的に連署された秘密鍵、αがAのジェネレータ、IA=IA1
+IA2+IA3がAの共通ID、(β1β2β3)fγがAの内在的に共同証明される公開鍵である。
4.Aは、公開ドメインで(α、IA1、IA2、IA3、β1、β2、β3、γ、p、q)を
公開する。
以下の例は、CAの署名方程式として方式3(または方式7’)に関して示される。というのは、この方式では全員が同一のジェネレータを共用するからである。各ユーザーは、CAがシステム・パラメータ(p、q、d)を使用し、各ユーザーが同一のジェネレータを有する限り、異なるCAを有することができる。
CA1: システム・パラメータ(α、β1、p、q、d)
アリスが、秘密鍵a、ジェネレータαを有し、公開ドメインで(α、IA、β、γA、p、q)を公開する。
CA2: システム・パラメータ(α、β2、p、q)
ボブが、秘密鍵b、ジェネレータαを有し、公開ドメインで(α、IA、β、γA、p、q)を公開する。
MTI/C0鍵共有プロトコルを使用して、本発明の新方式を使用する方法の実例を示す。アリスとボブが鍵交換を実行したいと思っていると仮定する。
1.アリスは、ボブの公開鍵
CA1: システム・パラメータ(α、β1、p、q)
アリス: 秘密鍵a、ジェネレータα、および公開ドメインの(α、IA、β1、γA、
p、q)。
CA2: システム・パラメータ(α、β2、p、q)
ボブ: 秘密鍵b、ジェネレータα、および公開ドメインの(α、IB、β2、γB、p
、q)。
ボブは、署名され暗号化されたメッセージMをアリスに送信したいと思っている。
ボブが、署名され暗号化されたメッセージMをアリスに送信したいと思っていると仮定する。
ボブは、下記を実行する。
1.アリスの公開鍵
2.整数xをランダムに選択し、鍵r=(αa)x(mod p)を計算する。
3.C=DESr(M)を計算する。
4.e=hash(C IA)を計算する。
5.s=be+x(mod q)を計算する。
6.対(C、s)をアリスに送信し、したがって、Cは、暗号化されたメッセージであり、sは、署名である。
1.e=hash(C IA)を計算する。
2.ボブの公開鍵
3.αas(αb)-ac(mod p)を計算する。これはrである。
4.メッセージM=DESr(C)を非暗号化する。
5.冗長性に関する検査を行う。
したがって、ボブは、2回の累乗演算だけを行い、アリスは、3回の累乗演算を行う。しかし、アリスとボブの両方が、お互いの認証を確信している。この方式の場合、メッセージMが、なんらかの冗長性またはパターンを有しなければならないことに留意されたい。
セット・アップ:
CA1: システム・パラメータ(α、β1、p、q)
アリス: 秘密鍵a、ジェネレータα、および公開ドメインの(α、IA、β1、γA、
p、q)。
CA2: システム・パラメータ(α、β2、p、q)
ボブ: 秘密鍵b、ジェネレータα、および公開ドメインの(α、IB、β2、γB、p
、q)。
る。
2.整数xをランダムに選択し、r=(αa)x(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を得る(内在的証明書方式の場合、ボブの公開鍵
3.αas(αb)-ae(mod p)を計算する。これはrである。
4.メッセージM=DESr(C)を非暗号化する。
1.証明書方式が、本明細書に記載の内在的証明書でない場合には、アリスおよびボブの公開鍵を検証しなければならない。
2.メッセージMが、なんらかの冗長性またはパターンを有しなければならない。
4.一般に、ハッシュeにオプション・パラメータを含めなければならない、すなわち、e=hash(C‖αa‖OP)。たとえば、OP=αbまたはOP=αb‖β1‖β2。
セット・アップ:
アリス: 秘密署名鍵a、秘密暗号化鍵aE、ジェネレータα、および公開ドメインの
ボブ: 秘密署名鍵b、秘密暗号化鍵bE、ジェネレータα、および公開ドメインの
注:このセット・アップは、方式6.cを使用する内在的証明書用である。通常の証明書方式システムの場合、アリスとボブが同一のジェネレータを有することだけが必要である。
2 整数xをランダムに選択し、
3 C=DESr(M)を計算する。
4
5 s=be+x+bE(mod q)を計算する。
6 (C、s)をアリスに送信する。Cは、暗号化されたメッセージであり、sは、署名である。
メッセージを復元するために、アリスは下記を実行する。
2.ボブの公開署名鍵αbおよび公開暗号化鍵
3.
4.メッセージM=DESr(C)を非暗号化する。
1.受信者アリスの秘密鍵がa+aEであると考えることができる。これは、受信者が
、2つの秘密鍵ではなく1つの秘密鍵だけを必要とすることを意味する。しかし、送信者ボブは、2つの秘密鍵を必要とする。通常の証明書の場合、受信者は、1つの秘密鍵だけを必要とする。
2.証明書方式が、本明細書に記載の内在的証明書でない場合には、アリスおよびボブの公開鍵を検証しなければならない。
3.メッセージMが、なんらかの冗長性またはパターンを有しなければならない。
4.
5.1つのrの値を知っても、ポスト・メッセージの情報は明らかにならない。
6.内在的証明書方式を用いると、ボブは、2回の累乗演算だけを実行し、アリスは、4回の累乗演算を実行する。しかし、双方が認証部分(authentificationpart)である
ことを、アリスとボブの双方は秘密にしている(are confidential)。
7.誰かがアリスの秘密鍵a+aEを知るか、ボブが両方の秘密鍵を失った場合、事後
暗号化されたメッセージを保護することはできない。
ッジ(judge)を信頼するならば、否認拒否機能(non-repudiationfeature)を有する。す
なわち、署名者は、自分がサインクリプトされた(signcrypted)メッセージに署名したこ
とを拒否することができない。プロトコル3は、ジャッジが信頼されないときであっても否認拒否機能を有する。次のプロトコルで、ボブが署名を拒否したい場合にジャッジがどのように判断するかを示す。
1.アリスが(C、s)をジャッジに送信する。
2.ジャッジは、
3.ジャッジは、2つの整数r1およびr2をランダムに選択し、
4.アリスは、
5.ジャッジは、
6.Mが正しいフォーマットを有する場合、(C、s)はボブによってサインクリプトされたものに違いない。
7.ジャッジは、判断を行った後に、値
ロトコルは、ジャッジが完全に信頼されるならば類似したものになる。
こともできる。
説明したDSA署名方式は、当技術分野で既知の一般化されたElGamal署名方式の特定の実例(specificinstance)であり、したがって、本発明の技法がこれに適用可能であることに留意されたい。
Claims (19)
- 通信システム内のエンティティを証明するために認証機関のデータ処理装置によって実行される方法であって、前記方法は、前記データ処理装置が、
第1の整数および前記エンティティから受信された値を含む組み合わせに基づいて、公開鍵再構成データを生成することと、
前記第1の整数と、前記認証機関の秘密鍵と、第2の整数とに対する署名方程式の適用に基づいて、秘密鍵貢献データを生成することであって、前記第1の整数は、前記データ処理装置によって選択され、前記第1の整数は、前記エンティティに対応しており、前記第2の整数は、前記公開鍵再構成データに基づいており、前記第2の整数は、前記エンティティの識別子と、前記エンティティの公開暗号化鍵とに基づいており、前記エンティティの前記公開暗号化鍵は、前記エンティティから受信された前記値とは異なる、ことと
を含むオペレーションを実行することを含む、方法。 - 前記秘密鍵貢献データは、前記データ処理装置によって前記エンティティに伝送される、請求項1に記載の方法。
- 前記署名方程式は、kA=cf+cAの形であり、cは、前記認証機関の前記秘密鍵であり、cAは、前記第1の整数であり、fは、前記第2の整数であり、kAは、前記秘密鍵貢献データである、請求項1に記載の方法。
- 前記署名方程式は、kA=cAf+cの形であり、cは、前記認証機関の前記秘密鍵であり、cAは、前記第1の整数であり、fは、前記第2の整数であり、kAは、前記秘密鍵貢献データである、請求項1に記載の方法。
- 前記第2の整数は、ハッシュ関数を用いて生成される、請求項1に記載の方法。
- 前記識別子は、前記データ処理装置によって選択される、請求項1に記載の方法。
- 前記公開鍵再構成データは、前記エンティティからのリクエストに応答して、前記データ処理装置によって生成され、前記リクエストは、前記エンティティから受信された前記値を含む、請求項1に記載の方法。
- 前記エンティティから受信された前記値は、有限体上で定義された楕円曲線群の要素であり、前記組み合わせは、楕円曲線上で定義された加法を含む、請求項1に記載の方法。
- 前記エンティティから受信された前記値は、有限体の乗法群の要素であり、前記組み合わせは、整数乗法を含む、請求項1に記載の方法。
- 命令を含む非一時性コンピュータ読み取り可能媒体であって、前記命令は、認証機関のデータ処理装置によって実行されたときに、通信システム内のエンティティを証明するためのオペレーションを実行するように動作可能であり、前記オペレーションは、
第1の整数および前記エンティティから受信された値を含む組み合わせに基づいて、公開鍵再構成データを生成することと、
前記第1の整数と、前記認証機関の秘密鍵と、第2の整数とに対する署名方程式の適用に基づいて、秘密鍵貢献データを生成することであって、前記第1の整数は、前記データ処理装置によって選択され、前記第1の整数は、前記エンティティに対応しており、前記第2の整数は、前記公開鍵再構成データに基づいており、前記第2の整数は、前記エンティティの識別子と、前記エンティティの公開暗号化鍵とに基づいており、前記エンティティの前記公開暗号化鍵は、前記エンティティから受信された前記値とは異なる、ことと
を含む、コンピュータ読み取り可能媒体。 - 前記署名方程式は、kA=cAf+cの形であり、cは、前記認証機関の前記秘密鍵であり、cAは、前記第1の整数であり、fは、前記第2の整数であり、kAは、前記秘密鍵貢献データである、請求項10に記載のコンピュータ読み取り可能媒体。
- 前記第2の整数は、ハッシュ関数を用いて生成される、請求項10に記載のコンピュータ読み取り可能媒体。
- 前記識別子は、前記データ処理装置によって選択される、請求項10に記載のコンピュータ読み取り可能媒体。
- 前記エンティティから受信された前記値は、有限体上で定義された楕円曲線群の要素であり、前記組み合わせは、楕円曲線上で定義された加法を含む、請求項10に記載のコンピュータ読み取り可能媒体。
- 通信システム内のエンティティを証明するように動作可能なコンピューティング装置であって、前記コンピューティング装置は、
1つ以上のプロセッサ
を含み、前記1つ以上のプロセッサは、
第1の整数および前記エンティティから受信された値を含む組み合わせに基づいて、公開鍵再構成データを生成することと、
前記第1の整数と、認証機関の秘密鍵と、第2の整数とに対する署名方程式の適用に基づいて、秘密鍵貢献データを生成することであって、前記第1の整数は、前記認証機関のデータ処理装置によって選択され、前記第1の整数は、前記エンティティに対応しており、前記第2の整数は、前記公開鍵再構成データに基づいており、前記第2の整数は、前記エンティティの識別子と、前記エンティティの公開暗号化鍵とに基づいており、前記エンティティの前記公開暗号化鍵は、前記エンティティから受信された前記値とは異なる、ことと
を実行するように構成されている、コンピューティング装置。 - 前記署名方程式は、kA=cAf+cの形であり、cは、前記認証機関の前記秘密鍵であり、cAは、前記第1の整数であり、fは、前記第2の整数であり、kAは、前記秘密鍵貢献データである、請求項15に記載のコンピューティング装置。
- 前記第2の整数は、ハッシュ関数を用いて生成される、請求項15に記載のコンピューティング装置。
- 前記識別子は、前記データ処理装置によって選択される、請求項15に記載のコンピューティング装置。
- 前記エンティティから受信された前記値は、有限体上で定義された楕円曲線群の要素であり、前記組み合わせは、楕円曲線上で定義された加法を含む、請求項15に記載のコンピューティング装置。
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA 2232936 CA2232936C (en) | 1998-03-23 | 1998-03-23 | Implicit certificate scheme |
CA2,232,936 | 1998-03-23 | ||
CA2235359A CA2235359C (en) | 1998-03-23 | 1998-04-20 | Implicit certificate scheme with ca chaining |
CA2,235,359 | 1998-04-20 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010023602A Division JP5247740B2 (ja) | 1998-03-23 | 2010-02-04 | 内在的証明書方式 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2013102549A JP2013102549A (ja) | 2013-05-23 |
JP5702813B2 true JP5702813B2 (ja) | 2015-04-15 |
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 Before (2)
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 | 内在的証明書方式 |
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)
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 |
WO2001095068A2 (en) * | 2000-06-09 | 2001-12-13 | 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 |
US20050089173A1 (en) * | 2002-07-05 | 2005-04-28 | Harrison Keith A. | Trusted authority for identifier-based cryptography |
GB0215590D0 (en) * | 2002-07-05 | 2002-08-14 | Hewlett Packard Co | Method and apparatus for generating a cryptographic key |
SG145524A1 (en) * | 2002-08-07 | 2008-09-29 | Mobilastic Technologies Pte Lt | Secure transfer of digital tokens |
WO2004032416A1 (en) * | 2002-08-30 | 2004-04-15 | 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 |
WO2005043807A1 (en) | 2003-10-28 | 2005-05-12 | Certicom Corp. | Method and apparatus for verifiable generation of public keys |
WO2006006124A1 (en) * | 2004-07-08 | 2006-01-19 | 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 |
KR101421202B1 (ko) * | 2006-02-28 | 2014-07-22 | 써티콤 코포레이션 | 제품 등록 시스템 및 방법 |
WO2008058388A1 (en) * | 2006-11-15 | 2008-05-22 | 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 |
WO2008106791A1 (en) * | 2007-03-06 | 2008-09-12 | Research In Motion Limited | Combining interleaving with fixed-sequence windowing in an elliptic curve scalar multiplication |
US8457307B2 (en) | 2007-07-17 | 2013-06-04 | 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 |
US8447971B2 (en) * | 2009-05-05 | 2013-05-21 | 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 |
CN103229452B (zh) * | 2010-09-30 | 2016-11-16 | 因特塞克特国际有限公司 | 移动手持设备的识别和通信认证 |
WO2012108875A1 (en) * | 2011-02-11 | 2012-08-16 | 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 |
WO2012151653A1 (en) | 2011-05-06 | 2012-11-15 | Certicom Corp. | Validating a batch of implicit certificates |
CA2976795C (en) * | 2011-06-10 | 2021-08-03 | Certicom Corp. | Implicitly certified digital signatures |
WO2012170130A1 (en) | 2011-06-10 | 2012-12-13 | Certicom (U.S.) Limited | Implicitly certified public keys |
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 |
WO2013138184A1 (en) | 2012-03-15 | 2013-09-19 | Research In Motion 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 |
DE102015210734B4 (de) * | 2014-10-31 | 2021-03-04 | Hewlett Packard Enterprise Development Lp | Verwaltung kryptographischer schlüssel |
US9479337B2 (en) * | 2014-11-14 | 2016-10-25 | Motorola Solutions, Inc. | Method and apparatus for deriving a certificate for a primary device |
BR112018016819A2 (pt) | 2016-02-23 | 2018-12-26 | Nchain Holdings Ltd | método e sistemas para proteger um recurso digital controlado utilizando uma tabela de dispersão e livro-razão distribuídos e um blockchain |
LT3268914T (lt) | 2016-02-23 | 2018-11-12 | nChain Holdings Limited | Bendros paslapties, skirtos saugiems informacijos mainams, nustatymas ir hierarchiniai determinuoti kriptografiniai raktai |
US11126976B2 (en) | 2016-02-23 | 2021-09-21 | nChain Holdings Limited | 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 |
BR112018016782A2 (pt) | 2016-02-23 | 2018-12-26 | Nchain Holdings Ltd | sistema e método implementado por computador configurado para controlar uma transferência feita através de um blockchain |
WO2017145010A1 (en) | 2016-02-23 | 2017-08-31 | nChain Holdings Limited | Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system |
EP3748903A1 (en) | 2016-02-23 | 2020-12-09 | Nchain Holdings Limited | Universal tokenisation system for blockchain-based cryptocurrencies |
US11308486B2 (en) | 2016-02-23 | 2022-04-19 | nChain Holdings Limited | Method and system for the secure transfer of entities on a blockchain |
JP6942136B2 (ja) | 2016-02-23 | 2021-09-29 | エヌチェーン ホールディングス リミテッドNchain Holdings Limited | デジタルコンテンツの制御及び配信のためのブロックチェーンにより実施される方法 |
WO2017145019A1 (en) | 2016-02-23 | 2017-08-31 | nChain Holdings Limited | Registry and automated management method for blockchain-enforced smart contracts |
EP3420675B1 (en) | 2016-02-23 | 2020-03-11 | Nchain Holdings Limited | Blockchain implemented counting system and method for use in secure voting and distribution |
EP3420669B1 (en) | 2016-02-23 | 2021-03-24 | Nchain Holdings Limited | Cryptographic method and system for secure extraction of data from a blockchain |
BR112018016822A2 (pt) | 2016-02-23 | 2018-12-26 | Nchain Holdings Ltd | método implementado por computador para realizar uma troca de entidades entre um primeiro usuário e um segundo usuário, processador e meio legível por computador |
JP6528008B2 (ja) | 2016-02-23 | 2019-06-12 | エヌチェーン ホールディングス リミテッドNchain Holdings Limited | 秘密共有のための楕円曲線暗号化を利用したパーソナルデバイスセキュリティ |
EP3420507A1 (en) | 2016-02-23 | 2019-01-02 | Nchain Holdings Limited | Tokenisation method and system for implementing exchanges on a blockchain |
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 |
EP3497878B1 (en) * | 2016-09-06 | 2020-05-20 | 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 | 华为技术有限公司 | 私钥生成方法、设备以及系统 |
US11985225B2 (en) | 2018-05-14 | 2024-05-14 | Nchain Licensing Ag | Computer-implemented systems and methods for using veiled values in blockchain |
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)
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 | 松下電器産業株式会社 | ネットワーク利用秘密及び署名通信方法 |
US5199070A (en) * | 1990-12-18 | 1993-03-30 | Matsushita Electric Industrial Co., Ltd. | Method for generating a public key |
JP2942395B2 (ja) * | 1991-08-08 | 1999-08-30 | 松下電器産業株式会社 | 秘密通信用ネットワークシステム |
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 |
-
1998
- 1998-04-20 CA CA2235359A patent/CA2235359C/en not_active Expired - Lifetime
-
1999
- 1999-03-23 AU AU28235/99A patent/AU758044B2/en not_active Expired
- 1999-03-23 JP JP2000538463A patent/JP4588874B2/ja not_active Expired - Lifetime
- 1999-03-23 DE DE69918818T patent/DE69918818T2/de not_active Expired - Lifetime
- 1999-03-23 IL IL13866099A patent/IL138660A0/xx not_active IP Right Cessation
- 1999-03-23 WO PCT/CA1999/000244 patent/WO1999049612A1/en active IP Right Grant
- 1999-03-23 EP EP99908723A patent/EP1066699B1/en not_active Expired - Lifetime
-
2000
- 2000-09-22 US US09/667,819 patent/US6792530B1/en not_active Expired - Lifetime
-
2004
- 2004-08-20 US US10/921,870 patent/US7391868B2/en not_active Expired - Lifetime
-
2008
- 2008-06-11 US US12/137,276 patent/US7653201B2/en not_active Expired - Fee Related
-
2009
- 2009-11-30 US US12/627,906 patent/US8270601B2/en not_active Expired - Fee Related
-
2010
- 2010-02-04 JP JP2010023602A patent/JP5247740B2/ja not_active Expired - Lifetime
-
2012
- 2012-06-19 US US13/527,007 patent/US8712042B2/en not_active Expired - Fee Related
- 2012-06-19 US US13/527,060 patent/US8705735B2/en not_active Expired - Fee Related
-
2013
- 2013-02-28 JP JP2013038451A patent/JP5702813B2/ja not_active Expired - Lifetime
-
2014
- 2014-04-21 US US14/257,781 patent/US20140229730A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
CA2235359A1 (en) | 1999-09-23 |
EP1066699A1 (en) | 2001-01-10 |
US20090041238A1 (en) | 2009-02-12 |
EP1066699B1 (en) | 2004-07-21 |
US20140229730A1 (en) | 2014-08-14 |
JP2010097236A (ja) | 2010-04-30 |
AU758044B2 (en) | 2003-03-13 |
US8705735B2 (en) | 2014-04-22 |
JP2002508529A (ja) | 2002-03-19 |
US7391868B2 (en) | 2008-06-24 |
WO1999049612A1 (en) | 1999-09-30 |
AU2823599A (en) | 1999-10-18 |
DE69918818T2 (de) | 2005-08-25 |
JP2013102549A (ja) | 2013-05-23 |
DE69918818D1 (de) | 2004-08-26 |
IL138660A0 (en) | 2001-10-31 |
JP5247740B2 (ja) | 2013-07-24 |
US20050114651A1 (en) | 2005-05-26 |
JP4588874B2 (ja) | 2010-12-01 |
US20100166188A1 (en) | 2010-07-01 |
US8712042B2 (en) | 2014-04-29 |
US8270601B2 (en) | 2012-09-18 |
US20120300924A1 (en) | 2012-11-29 |
US7653201B2 (en) | 2010-01-26 |
CA2235359C (en) | 2012-04-10 |
US20120303950A1 (en) | 2012-11-29 |
US6792530B1 (en) | 2004-09-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5702813B2 (ja) | 内在的証明書方式 | |
US10530585B2 (en) | Digital signing by utilizing multiple distinct signing keys, distributed between two parties | |
US8522012B2 (en) | Method for the application of implicit signature schemes | |
US7036015B2 (en) | Verification protocol | |
US20160248735A1 (en) | Method and apparatus for verifiable generation of public keys | |
JP5138775B2 (ja) | Idベース暗号化(ibe)に対して暗黙の証明証およびアプリケーションを生成する方法およびシステム | |
JP2003298568A (ja) | 鍵供託を使用しない、認証された個別暗号システム | |
US20040139029A1 (en) | Apparatus and method for generating and verifying ID-based blind signature by using bilinear parings | |
WO2003063410A1 (en) | Cryptosystem | |
KR20010013155A (ko) | 자동 복구가능하고 자동 증명가능한 암호체계들 | |
JP4307589B2 (ja) | 認証プロトコル | |
GB2421407A (en) | Generating a shared symmetric key using identifier based cryptography | |
Hwu et al. | End-to-end security mechanisms for SMS | |
CN109412815B (zh) | 一种实现跨域安全通信的方法和系统 | |
CA2232936C (en) | Implicit certificate scheme | |
Lee | Cryptanalysis of Zhu et al.’s Identity-Based Encryption with Equality Test without Random Oracles | |
Chen et al. | Comment on the Public Key Substitution Attacks. | |
Shieh et al. | An ID-based Proxy Authentication Protocol Supporting Public Key Infrastructure |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20130228 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20131003 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20131226 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20140107 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20140131 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20140205 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20140228 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20140305 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20140328 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20140602 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20140901 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20141015 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20141027 |
|
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: 20150123 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20150220 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5702813 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
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 |