JP3513324B2 - ディジタル署名処理方法 - Google Patents

ディジタル署名処理方法

Info

Publication number
JP3513324B2
JP3513324B2 JP10822696A JP10822696A JP3513324B2 JP 3513324 B2 JP3513324 B2 JP 3513324B2 JP 10822696 A JP10822696 A JP 10822696A JP 10822696 A JP10822696 A JP 10822696A JP 3513324 B2 JP3513324 B2 JP 3513324B2
Authority
JP
Japan
Prior art keywords
signature
public key
group
information processing
signer
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 - Fee Related
Application number
JP10822696A
Other languages
English (en)
Other versions
JPH09298537A (ja
Inventor
和臣 大石
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
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
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP10822696A priority Critical patent/JP3513324B2/ja
Priority to EP97302857A priority patent/EP0804003A3/en
Priority to US08/845,405 priority patent/US6154841A/en
Publication of JPH09298537A publication Critical patent/JPH09298537A/ja
Application granted granted Critical
Publication of JP3513324B2 publication Critical patent/JP3513324B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

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/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
    • H04L9/3255Cryptographic 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 using group based signatures, e.g. ring or threshold signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42Anonymization, e.g. involving pseudonyms

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)

Description

【発明の詳細な説明】
【0001】
【発明の属する技術分野】本発明はディジタル署名処理
方法に関し、例えば、情報通信システムで用いるディジ
タル署名に関する。
【0002】
【従来の技術】コンピュータおよび通信ネットワークの
発展と広範な普及に伴い、社会的活動のような機能をネ
ットワーク上においても実現できるようになった。しか
し、誰が、何時、何処で、何を行ったか、も容易に把握
することができ、それに対抗するため、匿名で処理を行
うことによりネットワーク上で多様な機能を実現し、か
つプライバシも保護する方法が考えられている。
【0003】後述する公開鍵暗号を用いれば、送信者は
通信内容を意図する受信者だけに送り、しかも受信者は
その通信の送信者が誰であるかを確実に確認することが
可能である。後述する零知識証明を利用すれば、ユーザ
がある秘密情報を保持していることを、その秘密を明ら
かにすることなく他者に証明できる。これらを応用した
情報通信システムが、Masahiro MAMBO, Eiji OKAMOTO
「A method to publiclyspecify a signer with hiding
identity, The 18th Symposium on Information Theor
y and Its Applications」October 1995で提案されてい
る。これを、以下では「MOシステム」と呼ぶことにす
る。
【0004】以下、最初に公開鍵暗号を、次に零知識証
明を、それからMOシステムを詳細に説明する。
【0005】[公開鍵暗号] 公開鍵暗号とは、暗号鍵と復号鍵とが異なり、暗号鍵を
公開し、復号鍵を秘密にする暗号方式であり、以下のよ
うな特徴をもつ。 (1)暗号鍵と復号鍵とが異なり、暗号鍵を公開すること
ができるため、暗号鍵を秘密に配送する必要がなく、鍵
の配送が容易である。 (2)各利用者は、暗号鍵を公開し、各自、復号鍵だけを
秘密にし記憶しておけばよい。 (3)送られてきた通信文の送信者が偽者でないこと、お
よび、その通信文が改竄されていないことを、受信者が
確認するための認証機能(ディジタル署名)を実現でき
る。
【0006】通信文(平文)Mに対して、公開の暗号鍵k
pを用いた暗号化操作をE(kp, M)とし、秘密の復号鍵ks
を用いた復号操作をD(ks, M)とすると、公開鍵暗号アル
ゴリズムは、まず次の二つの条件を満たす。 (1)暗号鍵kpが与えられたときE(kp, M)の計算は容易で
あり、復号鍵ksが与えられたときD(ks, M)の計算は容易
である。 (2)もし復号鍵ksを知らないなら、暗号鍵kp、暗号化操
作Eの計算手順、暗号であるC=E(kp, M)を知ったとして
も、平文Mを決定することは、その計算量から困難であ
る。
【0007】さらに、上記(1)(2)に加えて、次の条件
(3)が成立することにより、秘密通信が実現できる。 (3)すべての平文Mに対し、E(kp, M)を定義することがで
き、次式が成立する。 D(ks, E(kp, M)) = M
【0008】つまり、暗号鍵kpは公開されているため、
誰もがE(kp, M)を計算することができるが、D(ks, E(k
p, M))を計算して平文Mを得ることができるのは、秘密
の復号鍵ksを記憶している本人だけである。
【0009】一方、上記(1)(2)に加えて、次の条件(4)
が成立することにより、認証通信(ディジタル署名)が
実現できる。 (4)すべての平文Mに対し、D(ks, M)を定義することがで
き、次式が成立する。 E(kp, D(ks, M)) = M
【0010】つまり、D(ks, M)を計算できるのは秘密の
復号鍵ksを記憶している本人だけであり、他人が偽の鍵
ks'を用いてD(ks', M)を計算し、秘密の復号鍵ksを記憶
する本人になりすまそうとしても、E(kp, D(ks', M))≠
Mであり、受信者は受取った情報が不正なものであるこ
とを知ることができる。
【0011】同様に、D(ks, M)が改竄されても、E(kp,
D(ks, M)')≠Mであり、受信者は受取った情報が不正な
ものであることを知ることができる。このD(ks, M)をM
に対する「ディジタル署名」と呼ぶ。
【0012】代表的な公開鍵暗号方式を以下に挙げる。
秘密通信と認証通信ができる方式として、RSA暗号(R.
L. Rivest, A. Shamir and L. Adleman「A method of o
btaining digital signatures and public key cryptos
ystems」Comm. of ACM, 1978)、R暗号(M. Rabin「Digit
alized signatures and public-key cryptosystems」MI
T/LCS/TR-212, Technical Report MIT, 1979)、W暗号
(H. C. Williams「A modification of the RSA public-
key encryption procedure」IEEE Trans. Inf. Theory,
IT-26, 6, 1980)などがある。
【0013】また、秘密通信だけができる方式として、
CR暗号(B. Chor and R. L. Rivest「A knapsack type p
ublic key cryptosystem based on arithmetic in fini
tefield」Proc. Crypto 84)、M暗号(R. J. McEliece「A
public-key cryptosystembased on algebraic coding
theory」DSN Progress Rep., Jet Propulsion Lab., 19
78)、E暗号(T. E. ElGamal「A public key cryptosyste
m and a signaturescheme based on discrete logarith
ms」IEEE Transaction on Information Theory, Vol. I
T-31, No.4, pp.469-472, 1985)などがある。
【0014】認証通信だけができる方式として、S暗号
(A. Shamir「A fast signature scheme」Report MIT/LC
S/TM-107, MIT laboratory for computer science, Cam
bridge, Mass., 1978)、L暗号(K. Lieberherr「Uniform
complexity and digital signature」Lecture Notes i
n Computer Science 115 Automata, Language and Prog
ramming, Eight Colloquium Acre, Israel, 1981)、GMY
暗号(S. Goldwasser, S. Micali and A. Yao「Strong s
ignature schemes」ACM Symp. on Theory of Computin
g, 1983)、GMR暗号(S. Goldwasser, S. Micali and R.
L. Rivest「A 'paradoxical' solution to the signatu
re problem」ACM Symp. on Foundation ofComputer Sci
ence, 1984)、E暗号(T. E. ElGamal「A public key cry
ptosystemand a signature scheme based on discrete
logarithms」IEEE Transaction on Information Theor
y, Vol. IT-31, No.4, pp.469-472, 1985)、OS暗号(岡
本,白石「多項式演算によるディジタル署名方式」信学
論(D), J68-D, 5, 1985; T.Okamoto and A. Shiraisi
「A fast signature scheme based on quadratic inequ
alities」IEEE Symp. on Theory of Computing, 198
4)、Fiat-Shamir暗号(A. Fiat, A. Shamir「How to pro
ve yourself: practical solutions of identification
and signature problems」Proc. of CRYPTO'86, 198
7)、Schnorr暗号(C. P. Schnorr「Efficient signature
generation by smart cards」Journal of Cryptology,
vol.4, pp.161-174, 1991)などがある。
【0015】具体的な一例として、離散対数を求めるこ
との困難性に安全性の根拠をおき、偽造に対する安全性
が極めて高いとされ、署名のサイズが小さい署名方式で
あるSchnorr暗号を説明する。
【0016】例えば、大きな素数pと、q|p-1(qはp-1を
割り切る)なる大きな素数qを選ぶとき、{1, 2, …, q-
1}の中の一つをαとすると、αx≡u (mod p)を満たすx
(=DL(u,α)と記す)は、ガロア体GF(p)上における離散
対数であり、p, q, α, uを与えられた上でxを効率的に
求めることは難しいとされている。
【0017】Schnorr暗号では、鍵認証センタ(KAC: Key
Authentication Center)がシステムの初期化を行う。
署名者が鍵生成と署名生成を行い、認証者が署名を受け
取り確認する。システムの中では、一方向性ハッシュ関
数を用いる。一方向性ハッシュ関数とは、衝突を起こし
にくい圧縮関数である。つまり、任意の長さの値を入力
して固定の長さの値を出力し、同じ値を出力する異なる
入力を見つけることが困難である。Zは整数の集合で、Z
qは0以上q未満の整数の集合である。
【0018】●システム初期化 (1)鍵認証センタ(KAC)は、大きな素数p(≧2512)とq(≧2
140)を選び公開する。ただし、q|p-1である。 (2)KACは、α∈Zpかつαq = 1 (mod p)なるα(≠1)を選
び公開する。 (3)KACは、h: Zq×Z → {0, …, 2t - 1}を選び公開す
る。ここで、tを「セキュリティパラメータ」と呼ぶ。 (4)KACは、自分の署名用の公開鍵と秘密鍵を選び、公開
鍵を公開する(例えば、Fiat-Shamir暗号など)。
【0019】●鍵生成 システムに加入するユーザ(署名者)は、0<s≦qなる
任意の整数sを選び、v= α-s mod pを計算する。署名者
の秘密鍵はsであり、公開鍵はvである。認証者は、署名
者の公開鍵の正当性を、例えば、署名者の公開鍵に対し
てKACが(例えば、Fiat-Shamir暗号で)署名を付ける、
あるいは、署名者の公開鍵が公開データベースに登録さ
れる、などによって確認することができる。
【0020】●署名生成(メッセージmに対する署名) (1)署名者は、乱数r∈{1, …, q}を選び、x = αr (mod
p)を計算する。 (2)署名者は、e = h(x, m)を求める。 (3)署名者は、y = r + s・e (mod q)を計算する。(e,
y)が、メッセージmに対する署名である。
【0021】●署名検証 メッセージmと署名(e, y)を受取った認証者は、前述の
方法でvの正当性を確認し、次式を確認する。 x' = αy・ve (mod p) e = h(x', m)
【0022】[零知識証明] 零知識証明とは、ある命題を証明者が検証者に証明する
ことであり、以下の三条件を満たす。 (1)完全性: 証明が正しければ、検証者は1または1に限
りなく近い確率(圧倒的確率)で受理する。 (2)健全性: 証明が誤っていれば、検証者は1または1に
限りなく近い確率(圧倒的確率)で棄却する。 (3)零知識性: 証明が正しければ、検証者がどのように
振る舞っても、証明の正しさ以外の情報は一切洩れな
い。
【0023】ある秘密(数値)を知っている証明者が、
その秘密に関する情報を一切漏らさずに、その秘密を知
っていることを検証者に証明する零知識証明の方法が幾
つか提案されていて、身元証明やディジタル署名などに
応用され、情報セキュリティの分野における重要な基板
技術となっている。
【0024】具体的な一例として、J. Boyar, D. Chau
m, I. Damard, T. Pedersen「Convertible undeniable
signatures」Proc. of CRYPTO'90において提案された、
z = DL(u, α)を知っている証明者が、zを明らかにする
ことなくDL(v, w) = DL(u, α)を証明する零知識証明プ
ロトコルを説明する。ただし、DL(u, α)は適当な群に
おける離散対数を意味する(例えば、前述のGF(p)の場
合、αDL(u, α) ≡ (modp))。
【0025】●DL(v, w) = DL(u, α)を証明する零知識
証明プロトコル 以下では、証明者をP(Prover)、検証者をV(Verifier)と
記す。PもVもv, w, u,αを知っている。 (1)検証者Vは、乱数aとbを選び(a, b∈Zq)、ch = wa
αbを求め、chを証明者Pに送る。 (2)証明者Pは、乱数tを選び(t∈Zq)、h1 = ch・αtとh2
= h1zを求め、(h1, h2)を検証者Vに送る。 (3)検証者Vは、(a, b)を証明者Pに送る。 (4)証明者Pは、ch = wa・αbを確認し、tを検証者Vに送
る。 (5)検証者Vは、h1 =wa・αb+tとh2 = va・ub+tを確認す
る。
【0026】[ディジタル署名方式] 以上に説明した公開鍵暗号や零知識証明を応用したディ
ジタル署名方式が、D.Chaum, E. van Heyst「Group Sig
natures」Proc. of EUROCRYPT'91, pp.257-265 (1991)
に提案されている。これはグループ署名と呼ばれ、以下
の性質を満たす。 (1)グループメンバのみが署名を行える。 (2)署名を受取った者は、それが正当な署名であること
は確認できるが、グループのどのメンバが証明をしたの
かはわからない。 (3)後で必要が生じたときに署名者を明らかにするため
に、署名は(グループメンバの助力を得て、あるいは、
得ずに)開示されることができる。
【0027】グループ署名の用途には、例えば、入札シ
ステムがある。ある入札に参加する応札者をメンバと
し、応札者は自分の付ける値段や条件に対してグループ
署名を生成する。落札しない限り誰がどんな値段や条件
を提示したかは不明であるが、落札の際には落札者、つ
まり署名者を明らかにすることができる。
【0028】
【発明が解決しようとする課題】前述したChaum等の論
文には四つのグループ署名方式が提案されていて、それ
ぞれ、署名者名を開示する際に特別に信頼されたオーソ
リティ(以下、これをZAで表す)を要する方式と、そう
でない方式、グループメンバの新規加入が容易な方式
と、そうでない方式など、幾つかの基準により分類され
る特徴をもつ。しかし、その何れの方式も、署名の正当
性を確認するために用いるグループの公開鍵は、メンバ
の数に比例した大きさになるという性質がある。
【0029】一方、S. J. Park, I. S. Lee, D. H. Won
「A practical group signature」Proc. of the 1995 J
apan-Korea Workshop on Information Security and Cr
yptology, IV-3, pp.127-133 (1995)に提案されている
グループ署名方式は、グループの公開鍵の大きさはメン
バ数に比例せず、メンバの新規加入が容易であるという
特徴をもち、署名の開示の際にZAが必要な方式である。
【0030】本発明は、上述の問題を解決するためのも
ので、グループの公開鍵の大きさをグループメンバ数に
比例させる必要をなくすことを目的とする。
【0031】さらに、各メンバによる、その署名が自分
が作成した署名か否かの証明が可能なグループ署名にす
ることを他の目的とする。
【0032】
【課題を解決するための手段】本発明は、前記の目的を
達成する一手段として、以下の構成を備える。
【0033】本発明のディジタル署名処理方法は、信頼
されたオーソリティに相当する第一の情報処理装置、お
よび、複数のユーザに相当する複数の第二の情報処理装
置が互いに匿名で通信可能な匿名通信ネットワーク、並
びに、前記第一および第二の情報処理装置が共通にアク
セス可能なデータベースを有するシステムにおけるディ
ジタル署名処理方法であって、前記データベースにシス
テム共通のデータ群を登録し、前記第二の情報処理装置
それぞれが自身の秘密鍵および公開鍵を生成して当該公
開鍵を前記データベースに登録するとともに、前記第一
の情報処理装置が自身の秘密鍵および公開鍵を生成して
当該公開鍵をグループの公開鍵として前記データベース
に登録し、前記第一の情報処理装置が、前記第二の情報
処理装置の中から署名者に相当する第三の情報処理装置
を選択して、秘密に選んだ第一の乱数により前記第三の
情報処理装置の公開鍵を変換し、変換後の公開鍵、前記
共通データ群、前記第一の乱数および自身の秘密鍵を用
いて生成した前記第三の情報処理装置に対する匿名公開
鍵証明書を前記ネットワークを介して前記第三の情報処
理装置に送信し、前記第三の情報処理装置が、メッセー
ジ、秘密に選んだ第二の乱数、自身の秘密鍵および前記
データベースに登録された共通データ群を用いてディジ
タル署名を生成して、当該ディジタル署名および前記匿
名公開鍵証明書を合せて生成したグループ署名を、前記
第二の情報処理装置の中で確認者となる第四の情報処理
装置に前記ネットワークを介して送信し、前記第四の情
報処理装置が、受信したグループ署名中の匿名公開鍵証
明書を前記グループの公開鍵を用いて検証し、当該匿名
公開鍵証明書中の値を用いて当該グループ署名中の前記
署名者が生成したディジタル署名を検証し、当該グルー
プ署名が前記署名者によって生成されたグループ署名で
あることを確認し、前記署名者以外の前記第二の情報処
理装置それぞれが、自身の秘密鍵と前記グループ署名の
生成に用いられた前記署名者の秘密鍵とが異なることを
証明することで、前記署名者を開示することを特徴とす
る。
【0034】
【発明の実施の形態】以下、本発明にかかる一実施形態
の情報通信システムを図面を参照して詳細に説明する。
【0035】本発明にかかるディジタル署名方式は、後
述する匿名公開鍵証明書方式を応用して、信頼されたオ
ーソリティZAが指定者、メンバが署名者になり、匿名公
開鍵証明書に基づくディジタル署名をグループ署名とす
るものであり、本発明にかかる匿名公開鍵証明方式によ
れば、以下のような機能を実現することができる。
【0036】指定者が、乱数により、共通の公開パラメ
ータと署名者のディジタル署名の公開鍵を変換し、変換
した公開鍵に対する指定者のディジタル署名1を生成す
る。署名者の秘密鍵と、変換されたパラメータおよび公
開鍵との間には、以前と同じ関係が成り立つので、署名
者は秘密鍵を用いて任意の平文に対してディジタル署名
2を生成することができる。
【0037】ディジタル署名1および同2の受信者は、デ
ィジタル署名1により、変換されたパラメータおよび公
開鍵が指定者に認められていることを確認し、それらを
用いて、ディジタル署名2と平文の対応関係を確認する
ことができる。なお、ディジタル署名1および同2を合わ
せた署名は、それから署名者を明らかにすることが困難
なので匿名署名と呼ぶ。
【0038】このように、指定者が信頼されたオーソリ
ティZAになり、指定者に指定されたユーザ、すなわち署
名者がメンバになるので、オーソリティZAの使う公開鍵
はグループの公開鍵になり、匿名署名はグループ署名に
なる。この署名はグループ署名の最初の二つの条件を満
たす。
【0039】署名者の開示は、次のような方法をとる。
信頼されたオーソリティZAは、どのメンバにどの証明書
を発行したかを記録し、グループ署名が与えられたと
き、その証明書の部分からそれがどのメンバにより生成
されたかを判別することができる。さらに、その証明書
に用いた乱数を知っているので、その乱数を利用して証
明者名を開示することができる。
【0040】一方、あるグループ署名に対して、各メン
バがその署名者であるか否かは、そのグループ署名に使
われた秘密鍵と各メンバの秘密鍵が等しいか否かで判別
することができる。従って、署名者ではないメンバは、
自分の秘密鍵と対象のグループ署名に使われた秘密鍵と
が異なることを証明できるので、すべてのメンバに対し
て、その証明を要求することにより誰が証明者であるか
を判別することができる。
【0041】
【第1実施形態】以下では、匿名公開鍵証明書方式(APK
C: Anonymous Public Key Certificate)を最初に説明
し、次に、それを応用したグループ署名を説明する。
【0042】[匿名公開鍵証明書方式] 図1は公開鍵暗号を応用した匿名公開鍵証明書を説明す
るための図で、図2は公開鍵証明書に関する処理の流れ
の概要を示すフローチャートである。
【0043】このシステムは、指定者(証明書の発行
者)と複数のユーザ、ユーザの中から選ばれる署名者、
署名者の作成する署名を確認する確認者からなり、通信
内容から判別できる場合を除き送受信者を突き止めるこ
とが困難な通信を可能とするネットワーク(以下「匿名
通信ネットワーク」と呼ぶ)上で実現することができ
る。
【0044】図1において、「公開値(Public Values)」
は後述するシステム共通のデータ、「公開データベース
(Public Database)」は公開されたデータベース、矢印
はデータの取得,送信,受信を示し、括弧で囲まれた番
号は処理の手順を示す。また、「署名者(Specified Sig
ner)」は、「指定者(Specifier)」によりユーザの中か
ら選ばれた署名者を表し、「確認者(Verifier)」は署名
を確認する者を表す。
【0045】Step 0(準備): システム共通のデータと
して、素数pとq(q|p-1)、Zp*の元であり位数qのα(αq
≡1 (mod p)、Zp*はZqかつpと互いに素である整数の集
合)、一方向性ハッシュ関数h: Zq×Z → {0, …, 2t -
1}を用意する。これらは、システムに参加しているす
べてのユーザがアクセスでき、かつ不当な改竄などが起
こらないように適切に管理されている公開のデータベー
スに登録されているものとする。なお、以下の説明にお
いて、a_bはaに下付き添字bが付いた状態を表す場合が
ある。
【0046】指定者iは公開鍵viと秘密鍵si(vi = α
-s_i} mod p)を生成し、公開鍵を公開のデータベースに
登録する。署名者になり得るユーザjは、公開鍵vjと秘
密鍵vj(vj = α-s_j mod p)を生成し、公開鍵を公開の
データベースに登録する。ユーザは複数存在し、署名者
も複数存在し得る。
【0047】Step 1(ユーザ指定と公開): 指定者i
は、複数の中からあるユーザ、すなわち署名者jを選び
(図1に示す矢印101)、署名者jの公開鍵vjを乱数rj
用いて変換したzjを計算し、zjに対する署名(Schnorr
暗号による署名)を求め(図1に示す手順(1))、その署
名(証明書)を署名者jに安全に送る(図1に示す矢印10
2)。なお、安全に送る一方法として、前述したE暗号を
用いる方法がある。
【0048】具体的には、指定者iは(秘密の)乱数r
j(rj ∈ Zq*)を選び、次式により各パラメータを求め、
署名(yj, ej,zj)を署名者jに送る。なお、rj ∈ Zq*
は、Zq*からランダムにrjを選ぶことを表している。 xj = αr_j mod p zj = vj r_j mod p ej = h(xj, zj) yj = rj + ej・si mod q
【0049】Step 2(署名の生成): 署名者jは、署名
(yj, ej, zj)を手に入れ、次式を確認する。 ej = h(αy_j・vi e_j mod p, zj) zj = (αy_j・vi e_j mod p)-s_k mod p … (1)
【0050】そして、署名したいメッセージm(j)に対
し、次の署名方式で署名を生成する。つまり、署名者j
は、秘密の乱数r(j)を選び(r(j) ∈ Zq*)、次式を計算
する。 x(j) = xj r(j) mod p e(j) = h(x(j), m(j)) y(j) = r(j) + e(j)・sj mod q
【0051】そして、((yj, ej, zj), y(j), e(j), m
(j))を署名として、必要な相手に送る(図1に示す手順
(3)、矢印103)。
【0052】Step 3(署名の確認): 上記署名を受信し
た確認者は最初に、式(1)を確認し、次に次式を確認す
る(図1に示す手順(4))。 e(j) = h(xj y(j)・zj e(j) mod p, m(j))
【0053】上記が確認できたならば、受信者(確認
者)は、メッセージm(j)に対する署名は指定者iに選ば
れた署名者によって生成された署名であると納得する。
【0054】以上の匿名公開鍵証明書方式には次の性質
がある。 (1)指定者iだけが署名者jを指定でき、その証拠が証明
書(指定者iの生成したディジタル署名)になる。 (2)指定された署名者jは、証明書と自分の秘密鍵を用い
て匿名のままで署名を生成できる。 (3)受信者は、指定者iの公開鍵を用いて上記匿名署名の
正当性を確認できる。 (4)匿名署名からその署名者jを判別すること、および、
匿名署名を偽造することは困難である。
【0055】[匿名公開鍵証明書に基づくグループ署名
方式] 図3は本発明にかかる匿名公開鍵証明書に基づくグルー
プ署名方式(Group Signature based on APKC)を用いた
システムの概念図で、匿名通信ネットワーク(Anonymous
Communication Network)を介して、複数のユーザが互
いに匿名で通信を行える状況を表している。
【0056】図3に示す環境には、信頼されたオーソリ
ティZA、ユーザj, k, Vなどがアクセスできる公開デー
タベースが存在し、そこに各ユーザの公開鍵や、共通の
パラメータなどが登録されている。公開データベース
は、そこに登録された情報をすり替えるような不当な行
為を防ぐように、適切に管理されている。また、図3に
おいて、あるグループの公開鍵をvZAとし、そのグルー
プはj, kを含むメンバからなるものとする。
【0057】同じグループに所属するメンバj, kは、匿
名公開鍵証明書(yj, ej, zj)および(yk, ek, zk)をそれ
ぞれ、オーソリティZAから発行してもらい、それに基づ
き、メンバ固有の署名部分(y(j), e(j), z(j))を生成
し、匿名通信ネットワークを介して、ユーザVにグルー
プ署名((yj, ej, zj),y(j), e(j), z(j))を送る。
【0058】ユーザVは、グループの公開鍵vZAを用い
て、匿名公開鍵証明書(yj, ej, zj)を検証し、それから
計算される値を用いて(y(j), e(j), z(j))を検証するこ
とにより、グループ署名の正当性を確認することができ
る。
【0059】以上の具体的な内容を図4を参考にして説
明する。図4は匿名公開鍵証明書に基づくグループ署名
方式を説明するための図、図5はグループ署名方式に関
する処理の流れの概要を示すフローチャートで、オーソ
リティZAに指定されたメンバjがグループ署名を生成
し、グループ署名を受信した確認者がグループ署名を確
認する例を示している。
【0060】Step 10(準備): 匿名公開鍵証明書方式
のStep 0と同じ。
【0061】Step 11(メンバに対する証明書の発行):
オーソリティZAは、ユーザjをグループのメンバにする
ことを認め、メンバjの公開鍵を乱数rjを用いて変換し
たzjを計算し、zjに対する署名(Schnorr暗号による署
名)を求め(図4に示す手順(1))、メンバjに直接送る
(図4に示す手順(2)、矢印402)。
【0062】具体的には、指定者iは(秘密の)乱数r
j(rj ∈ Zq*)を選び、次式により各パラメータを求め、
署名(yj, ej, zj)をメンバjに送る。 xj = αr_j mod p zj = vj r_j mod p ej = h(xj, zj) yj = rj + ej・sZA mod q
【0063】Step 12(グループ署名の作成): メンバj
は、署名(yj, ej, zj)を手に入れ、次式を確認する。 ej = h(αy_j・vZA e_j mod p, zj) zj =(αy_j・vZA e_j mod p)-s_j mod p … (2)
【0064】ここで、xj = αy_j・vZA e_j mod pが成り
立っているので、以降は、表記を簡略化するためにxj
用いる。そして、メンバjは、署名したいメッセージm
(j)に対し、次の署名方式でグループ署名を生成する。
つまり、メンバjは、秘密の乱数r(j)を選び(r(j) ∈ Zq
*)、次式を計算する。 x(j) = xi r(j) mod p e(j) = h(x(j), m(j)) y(j) = r(j) + e(j)・sj mod q
【0065】そして、((yj, ej, zj), y(j), e(j), m
(j))をグループ署名として、必要な相手に送る(図4に
示す手順(3)、矢印403)。
【0066】Step 13(グループ署名の確認): 上記署
名を受信した確認者は最初に、式(2)を確認し、次に次
式を確認する(図4に示す手順(4))。 e(j) = h(xj y(j)・zj e(j) mod p, m(j))
【0067】上記が確認できたならば、受信者(確認
者)は、メッセージm(j)に対する署名はオーソリティZA
に認められたメンバによって生成されたグループ署名で
あると納得する。
【0068】[グループ署名の開示方法] あるグループ署名を誰が生成したのかを明らかにする、
すなわちグループ署名の開示は、次の二つの方法で実現
することができる。ただし、対象のグループ署名を
((ek, yk, zk), e(k), y(k), m)、その署名者をメンバ
k、オーソリティZAが生成したzkに対応する乱数をrk
する。
【0069】方法1(信頼されたオーソリティによる開
示): 信頼されたオーソリティZAは、証明書を生成する
際に用いた乱数rkを記憶しておくことができるので、あ
るグループ署名が与えられたとき、その証明書の中のzk
に対応するメンバが誰かを判別することができる。従っ
て、オーソリティZAは、署名者がメンバkで、乱数はr
k(= DL(zk, vk))であることがわかる。
【0070】オーソリティZA(証明者P)は、証明書の
公開鍵に対応する秘密鍵と、メンバの公開鍵に対応する
秘密鍵とが等しいことを証明する。つまり、前述したDL
(v,w) = DL(u, α)を証明する零知識証明プロトコルを
利用して、DL(zk, vk) = DL(xk, α)を認証者Vに対して
証明する。ただし、xk = αy_k・vi e_k mod pである。
なお、メンバの公開鍵は公開のデータベースに登録され
ている。
【0071】● DL(zk, vk) = DL(xk, α)を証明する零
知識証明プロトコル (1)証明者Pは、vkを認証者Vに送る。 (2)認証者Vは、乱数aとb(a, b ∈ Zq)を選び、ch = vk a
・αbを計算し、証明者Pに送る。 (3)証明者Pは、乱数t(t ∈ Zq)を選び、h1 = ch・αtとh
2 = h1r_kを計算し、それらを認証者Vに送る。 (4)認証者Vは、(a, b)を証明者Pに送る。 (5)証明者Pは、ch = vk a・αbを確認し、tを認証者Vに
送る。 (6)認証者Vは、h1 = vk a・αb+tとh2 = zk a・xk b+tを確
認する。 なお、上記のプロトコルの代わりに、同様の証明が可能
なプロトコルを使うこともでき、上記のプロトコルだけ
が利用可能なものというわけではない。
【0072】方法2(各メンバによる署名の否認): も
う一つの開示方法は、対象のグループ署名が、自分が生
成した署名ではないことを、各メンバが証明することに
よって実現する。
【0073】メンバj(証明者P)は、そのグループ署名
に使われているzkに対応する秘密鍵が自分の公開鍵に対
応する秘密鍵sj = DL(zj, xj)とは異なることを(認証
者Vに)示す。つまり、DL(vj, α) ≠ DL(zk, xk)を以
下のプロトコルで証明する。ただし、p, q, α, vi,
vj, zkおよびxk = αy_k・vi e_k mod pは、証明者Pと認
証者Vの両方が知っていて、両者がパラメータγに合意
した上で、以下のプロトコルが実行される。
【0074】なお、BC(γ, R)は、乱数Rを入力したビッ
トγのビットコミットメントと呼ばれる。これは、ある
ビットについて‘0’か‘1’の何れかを選択し、その値
が何れかかは、乱数Rが明らかにならない限りわからな
いような変換値である。従って、乱数Rを示すことでコ
ミットした値を開示でき、同じ変換値に対して違うビッ
トをコミットしたと偽ることが困難であるという性質を
もつ。例えば、I. B.Damgard「Practical and provably
secure release of a secret and exchangeof a signa
ture」Proc. of EUROCRYPT'93, pp.207-217 (1994)に具
体例が示されている。
【0075】●DL(vj, α) ≠ DL(zk, xk)を証明する零
知識証明プロトコル なお、表記を簡略化するために、以下の説明においては
mod pを一部省略する。 (1)認証者Vは、乱数e(e ∈ Zq*)とβ ∈ {0, 1}を選
び、(a, b)を次のように計算し、得られた(a,b)を証明
者Pに送る。 β =‘0’ならば (a, b) = (αe, vj e) β =‘1’ならば (a, b) = (xk e, zk e) (2)証明者Pは、A-sj ≡ b (mod p)の成立を確認し、成
り立つならばγ =‘1’とし、成り立たないならばγ =
‘0’とし、g = BC(γ, R)を認証者Vに送る。 (3)認証者Vは、eを証明者Pに送る。 (4)証明者Pは、(a, b) = (αe, vj e)あるいは(a, b) =
(xk e, zk e)が成立することを確認し、どちらかが成り立
つならばans = Rとし、どちらも成り立たないならばans
= stopとし、ansを認証者Vに送る。 (5)認証者Vは、ans = stopの場合はプロトコルの処理を
中止し、そうでない場合はBC(γ, R) = gを確認する。 (6)上記(1)から(5)を合計r回繰り返す。
【0076】なお、上記のプロトコルの代わりに、同様
の証明が可能なプロトコルを使うこともでき、上記のプ
ロトコルだけが利用可能なものというわけではない。
【0077】受信者が開示したいグループ署名を有する
ときに、以上の二つの方法の何れか片方だけを実行する
ように制御することに加え、以下のように制御すること
も可能である。つまり、第一は、二つの方法を任意に選
択して実行できるように制御する方法である。第二は、
自動的に方法1を実行し、オーソリティZAが有効に機能
しない場合は、方法2を実行する制御方法である。第三
は、自動的に方法2を実行し、コンタクトできないメン
バがあるなどの理由で開示できない場合は、方法1を実
行する制御方法である。
【0078】グループが複数存在する場合は、各グルー
プ(a, b, …とする)に対応する信頼できるオーソリテ
ィZAa, ZAb, …を設け、各オーソリティZAが固有の公開
鍵va, vb, …を管理する、あるいは、信頼できる単一の
オーソリティZAが各グループに対応する個別の公開鍵
va, vb, …を管理する、あるいは、それらの中間的な方
法があり得る。何れの場合にせよ、上記の説明と同様に
してそれぞれのグループ署名を実現できる。
【0079】以上の実施形態において、指定者あるいは
信頼されたオーソリティ、署名者あるいはメンバ、確認
者あるいは署名の受信者は、情報処理および通信に関す
る能力をもつ情報処理装置、例えばパーソナルコンピュ
ータ上において実現可能である。指定者、オーソリテ
ィ、署名者、メンバ、確認者、受信者の間における通信
は、例えばインターネットのようなネットワーク上で匿
名通信を可能にするサービスを運用することによって実
現できる。
【0080】そして、パーソナルコンピュータのような
装置により、上記の計算を行い、上記のサービスが利用
できる通信ネットワーク上で通信を行うことにより、上
記の各ステップを実行して、匿名公開鍵証明書に基づく
ディジタル署名をグループ署名として用いた情報通信シ
ステムを構築することができる。勿論、インターネット
に限らず外部と分離された環境、例えば企業内のローカ
ルエリアネットワーク(LAN)においても、情報処理装置
を用いて通信ネットワークおよびサービスを構築するこ
とにより、匿名公開鍵証明書に基づくディジタル署名を
グループ署名として用いた情報通信システムを構築する
ことができる。
【0081】また、上記では、オーソリティZAが、匿名
公開鍵証明書をメンバに直接送る例を説明したが、用途
によっては、同証明書を公開データベースに登録し、メ
ンバおよび署名の受信者が公開データベースにアクセス
するという方法もあり得る。
【0082】以上説明したように、本実施形態にかかる
匿名公開鍵証明書に基づくディジタル署名をグループ署
名として用いた情報通信システムによれば、グループの
公開鍵の大きさはグループメンバ数に比例せず、各メン
バが、その署名は自分が作成した署名か否かを証明する
ことが可能なグループ署名を実現することができる。従
って、公開鍵の大きさがメンバ数に比例しない場合で
も、必ずしもオーソリティZAを必要とせず、データサイ
ズの低減と開示の際の融通性を同時に達成でき、コスト
低減と使い勝手の向上を達成することができる。
【0083】また、本実施形態にかかるグループ署名方
式は、あるグループ署名に対して、オーソリティZAは、
その署名の開示を行うことが可能であり、かつ、各メン
バは、その署名は自分が作成した署名か否かを証明する
ことも可能である。従って、オーソリティZAが有効に機
能しない場合にも、署名の開示を行うことができ、また
その逆も可能であり、より柔軟性のあるシステム、使い
勝手のよいシステムにすることができる。
【0084】また、本実施形態にかかるグループ署名方
式は、グループの公開鍵の大きさはグループメンバ数に
比例せず、かつ、オーソリティZAは、あるグループ署名
に対して、その署名の開示を行うことが可能であり、か
つ、各メンバは、その署名は自分が作成した署名か否か
を証明することが可能である。従って、データサイズが
小さくなる上、オーソリティZAを用いて署名の開示を行
うことも、オーソリティZAが有効に機能しない場合に署
名の開示を行うこともでき、データサイズの低減と開示
の際の融通性の最適化が図れ、コスト低減と使い勝手の
最適化を実現することができる。
【0085】さらに、本実施形態にかかるグループ署名
方式は、メンバの新規加入が容易であるという特徴をも
つので、メンバの加入の度に処理を繰り返す必要がな
く、システム全体の効率を向上することができる。
【0086】また、前述したPark等が提案するグループ
署名方式における公開鍵の大きさと、本発明にかかる方
式の公開鍵の大きさとを、素数pを688ビット、一方向性
ハッシュ関数のセキュリティパラメータを70ビットに揃
えて比較すると、Park等のグループ署名の大きさが1676
ビットになる(k'λ = 70とした)のに対して、本発明
にかかる方式のグループ署名の大きさは1108ビットであ
る。従って、署名の大きさを約34%削減でき、その分、
通信のコストを下げることができる。
【0087】
【第2実施形態】以下、本発明にかかる第2実施形態の
情報通信システムを説明する。なお、第2実施形態にお
いて、第1実施形態と略同様の構成については、同一符
号を付して、その詳細説明を省略する。
【0088】前述した実施形態においては、zjに対する
公開鍵証明書をSchnorr暗号の署名を用いて生成し、p,
q, xj, zjを公開鍵、sjを秘密鍵として、メッセージmj
に対してSchnorr暗号の署名を適用した。これに対し、
第2実施形態においては、メッセージmjに対して、Schno
rr暗号の署名ではなくE暗号(T. E. ElGamal「A publick
ey cryptosystem and a signature scheme based on di
screte logarithms」IEEE Transaction on Information
Theory, Vol. IT-31, No. 4, pp.469-472, 1985)を適
用する。
【0089】以下では、第1実施形態と異なる点だけを
説明する。
【0090】Step 12(グループ署名の作成): 署名者j
は、署名をしたいメッセージm(j)に対し、次の方式で署
名を生成する。署名者jは、秘密の乱数k(j)を選び(k(j)
∈Zq*)、次式を計算する。 r(j) = xj k(j) mod p s(j) = (m(j) + sj・r(j))・k(j)-1 mod (p - 1)
【0091】そして、((yj, ej, zj), r(j), s(j), m
(j))を署名として、必要な相手に送る。
【0092】Step 13(グループ署名の確認): 上記署
名を受信した確認者は最初に、式(2)を確認し、次に次
式を確認する。 xj m(j) ≡ zj r(j)・r(j)s(j) mod p
【0093】上記が確認できたならば、受信者(確認
者)は、メッセージm(j)に対する署名はオーソリティZA
に認められたメンバによって生成された署名であると納
得する。
【0094】
【第3実施形態】以下、本発明にかかる第3実施形態の
情報通信システムを説明する。なお、第3実施形態にお
いて、第1実施形態と略同様の構成については、同一符
号を付して、その詳細説明を省略する。
【0095】前述した第1および第2実施形態において
は、zjに対する公開鍵証明書をSchnorr暗号の署名を用
いて生成し、メッセージmjに対してSchnorr暗号またはE
暗号を適用する例を説明した。同様に、ディジタル署名
標準案としてNIST (National Institute of Standard a
nd Technology)に提案されたDSA(「Digital Signature
Algorithm」岡本栄司著、暗号理論入門、共立出版、pp.
136-138参照)をメッセージmjに対して用いることも可
能である。
【0096】p, q, xj, zjを公開鍵、sjを秘密鍵として
用いる。
【0097】Step 12(グループ署名の作成): 署名者j
は、署名をしたいメッセージm(j)に対し、次の方式で署
名を生成する。署名者jは、秘密の乱数k(j)を選び(k(j)
∈Zq*)、次式を計算する。 r(j) = (xj k(j) mod p) mod q s(j) = k(j)-1・(H(m(j)) - sj・r(j)) mod q
【0098】そして、(((yj, ej), zj), ((r(j), s
(j)), m(j)))を署名として、必要な相手に送る。
【0099】Step 13(グループ署名の確認): 上記署
名を受信した確認者は最初に、式(2)を確認し、0<r(j)
<q, 0<s(j)<qを確認した後、次の処理を行う。 w = s(j)-1 mod q u1 = H(m(j))・w mod q u2 = r(j)・w mod q v = (xj u1・zj u2 mod p) mod q
【0100】そして、以上の計算結果からv = r(j)を確
認し、確認できたならば受信者はm(j)に対する署名はオ
ーソリティZAに選ばれたメンバによって生成された署名
であると納得する。
【0101】
【第4実施形態】以下、本発明にかかる第4実施形態の
情報通信システムを説明する。なお、第4実施形態にお
いて、第1実施形態と略同様の構成については、同一符
号を付して、その詳細説明を省略する。
【0102】前述した第1から第3実施形態においては、
zjに対する公開鍵証明書をSchnorr暗号の署名を用いて
生成し、メッセージmjに対してSchnorr暗号、E暗号また
はDSAを適用する例を説明した。これに対して、zjに対
する公開鍵証明書の生成にSchnorr暗号の署名の代わっ
て、E暗号を適用することも可能である。ただし、xjとz
jが次式の関係を満たすことが保証できるように、署名
を適用することに注意する。 xj = αr_j mod p zj = vj r_j mod p
【0103】具体的には、以下のとおりである。
【0104】Step 11(メンバに対する証明書の発行):
オーソリティZAは、メンバjに対して、秘密の乱数rj
選び(rj ∈ Zq*)、次式を計算する。 xj = αr_j mod p zj = vj r_j mod p Sj = (zj + si・xj)・rj -1 mod (p - 1)
【0105】そして、(xj, Sj, zj)を公開鍵証明書とす
る。
【0106】Step 12(グループ署名の作成): メンバj
は、次式が成り立つことで公開鍵証明書の正当性を確認
することができる。 αz_j ≡ vi x_j・xj S_j mod p zj = xj -S_j mod p
【0107】
【第5実施形態】以下、本発明にかかる第5実施形態の
情報通信システムを説明する。なお、第5実施形態にお
いて、第1実施形態と略同様の構成については、同一符
号を付して、その詳細説明を省略する。
【0108】前述した第4実施形態においては、zjに対
する公開鍵証明書の生成にSchnorr暗号の署名の代わり
にE暗号を適用する例を説明した。これに対して、Schno
rr暗号やE暗号の代わりに、DSAを適用することも可能で
ある。ただし、xjとzjが次式の関係を満たすことが保証
できるように、署名を適用することに注意する。 xj = αr_j mod p zj = vj r_j mod p
【0109】具体的には、以下のとおりである。
【0110】Step 11(メンバに対する証明書の発行):
オーソリティZAは、メンバjに対して、秘密の乱数rj
選び(rj ∈ Zq*)、次式を計算する。 xj = αr_j mod p zj = vj r_j mod p Sj = rj -1・(H(zj) - si・xj) mod q
【0111】そして、(xj, Sj, zj)を公開鍵証明書とし
て、メンバjに送る。
【0112】公開鍵証明書の正当性は、次のように確認
できる。まず、0<xj< p, 0<Sj<qを確認した後、次
の処理を行う。
【0113】Step 12(グループ署名の作成): メンバj
は、次式が成り立つことで公開鍵証明書の正当性を確認
することができる。まず、0<xj<p, 0<Sj<q を確認
した後、次の処理を行う。 w = Sj -1 mod q u1 = H(zj)・w mod q u2 = xj・w mod q v = αu1・vi u2 mod p
【0114】そして、v = xjを確認する。公開鍵証明書
の正当性は、次式が成り立つことで確認できる。 zj = xj -S_j mod p
【0115】
【他の実施形態】なお、本発明は、複数の機器(例えば
ホストコンピュータ、インタフェイス機器、リーダ、プ
リンタなど)から構成されるシステムに適用しても、一
つの機器からなる装置(例えば、複写機、ファクシミリ
装置など)に適用してもよい。
【0116】また、本発明の目的は、前述した実施形態
の機能を実現するソフトウェアのプログラムコードを記
録した記憶媒体(または記録媒体)を、システムあるい
は装置に供給し、そのシステムあるいは装置のコンピュ
ータ(またはCPUやMPU)が記憶媒体に格納されたプログ
ラムコードを読み出し実行することによっても、達成さ
れることは言うまでもない。この場合、記憶媒体から読
み出されたプログラムコード自体が前述した実施形態の
機能を実現することになり、そのプログラムコードを記
憶した記憶媒体は本発明を構成することになる。また、
コンピュータが読み出したプログラムコードを実行する
ことにより、前述した実施形態の機能が実現されるだけ
でなく、そのプログラムコードの指示に基づき、コンピ
ュータ上で稼働しているオペレーティングシステム(OS)
などが実際の処理の一部または全部を行い、その処理に
よって前述した実施形態の機能が実現される場合も含ま
れることは言うまでもない。
【0117】さらに、記憶媒体から読み出されたプログ
ラムコードが、コンピュータに挿入された機能拡張カー
ドやコンピュータに接続された機能拡張ユニットに備わ
るメモリに書込まれた後、そのプログラムコードの指示
に基づき、その機能拡張カードや機能拡張ユニットに備
わるCPUなどが実際の処理の一部または全部を行い、そ
の処理によって前述した実施形態の機能が実現される場
合も含まれることは言うまでもない。
【0118】本発明を上記記憶媒体に適用する場合、そ
の記憶媒体には、先に説明したフローチャートに対応す
るプログラムコードを格納することになるが、簡単に説
明すると、図6Aおよび6Bのメモリマップ例に示す各モジ
ュールを記憶媒体に格納することになる。すなわち、少
なくとも「生成」「確認」および「開示」の各モジュー
ル、または、「底生成」「公開鍵生成」「第一の署名生
成」「確認」「第二の署名生成」および「開示」の各モ
ジュールのプログラムコードを記憶媒体に格納すればよ
い。
【0119】
【発明の効果】以上説明したように、本発明によれば、
グループの公開鍵の大きさをグループメンバ数に比例さ
せる必要をなくすことができる。
【0120】さらに、各メンバによる、その署名が自分
が作成した署名か否かの証明が可能なグループ署名にす
ることができる。
【図面の簡単な説明】
【図1】本発明にかかる公開鍵暗号を応用した匿名公開
鍵証明書を説明するための図、
【図2】公開鍵証明書に関する処理の流れの概要を示す
フローチャート、
【図3】本発明にかかる匿名公開鍵証明書に基づくグル
ープ署名方式を用いたシステムの概念図、
【図4】匿名公開鍵証明書に基づくグループ署名方式を
説明するための図、
【図5】グループ署名方式に関する処理の流れの概要を
示すフローチャートで、
【図6A】本発明にかかるプログラムコードを格納した
記憶媒体のメモリマップ例を示す図、
【図6B】本発明にかかるプログラムコードを格納した
記憶媒体のメモリマップ例を示す図である。
───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平4−264485(JP,A) David Chaum and E ugene van Heyst,“G roup Signatures”,L ecture Notes in Co mputer Science(EUR OCRYPT’91),1991年12月 9 日,Vol.547,pp.257−265 L Harn,“Group−ori ented(t,n) thersho ld digital signatu re scheme and digi tal multisignatur e”,IEE PROCEEDINGS COMPUTERS AND DIG ITAL TECHNIQUES,1994 年10月13日,Vol.141,No.5, pp.307−313 (58)調査した分野(Int.Cl.7,DB名) H04L 9/32 G09C 1/00 640

Claims (4)

    (57)【特許請求の範囲】
  1. 【請求項1】 信頼されたオーソリティに相当する第一
    の情報処理装置、および、複数のメンバに相当する複数
    の第二の情報処理装置が互いに匿名で通信可能な匿名通
    信ネットワーク、並びに、前記第一および第二の情報処
    理装置が共通にアクセス可能なデータベースを有するシ
    ステムにおけるディジタル署名処理方法であって、 前記データベースにシステム共通のデータ群を登録し、 前記第二の情報処理装置それぞれが自身の秘密鍵および
    公開鍵を生成して当該公開鍵を前記データベースに登録
    するとともに、前記第一の情報処理装置が自身の秘密鍵
    および公開鍵を生成して当該公開鍵をグループの公開鍵
    として前記データベースに登録し、 前記第一の情報処理装置が、前記第二の情報処理装置の
    中から署名者に相当する第三の情報処理装置を選択し
    て、秘密に選んだ第一の乱数により前記第三の情報処理
    装置の公開鍵を変換し、変換後の公開鍵、前記共通デー
    タ群、前記第一の乱数および自身の秘密鍵を用いて生成
    した前記第三の情報処理装置に対する匿名公開鍵証明書
    を前記ネットワークを介して前記第三の情報処理装置に
    送信し、 前記第三の情報処理装置が、メッセージ、秘密に選んだ
    第二の乱数、自身の秘密鍵および前記データベースに登
    録された共通データ群を用いてディジタル署名を生成し
    て、当該ディジタル署名および前記匿名公開鍵証明書を
    合せて生成したグループ署名を、前記第二の情報処理装
    置の中で確認者となる第四の情報処理装置に前記ネット
    ワークを介して送信し、 前記第四の情報処理装置が、受信したグループ署名中の
    匿名公開鍵証明書を前記グループの公開鍵を用いて検証
    し、当該匿名公開鍵証明書中の値を用いて当該グループ
    署名中の前記署名者が生成したディジタル署名を検証
    し、当該グループ署名が前記署名者によって生成された
    グループ署名であることを確認し、 前記署名者以外の前記第二の情報処理装置それぞれが、
    自身の秘密鍵と前記グループ署名の生成に用いられた前
    記署名者の秘密鍵とが異なることを証明することで、前
    記署名者を開示することを特徴とするディジタル署名処
    理方法。
  2. 【請求項2】 さらに、前記第一の情報処理装置は、前
    記第一の乱数を保存し、該第一の乱数を用いて、前記グ
    ループ署名中の匿名公開鍵証明書に利用された公開鍵に
    対応する秘密鍵と、特定の情報処理装置の公開鍵に対応
    する秘密鍵とが等しいことを証明することで、前記署名
    者を開示することを特徴とする請求項1に記載されたデ
    ィジタル署名処理方法。
  3. 【請求項3】 前記ディジタル署名は、Schnorr暗号の
    署名、E暗号の署名およびDSA方式の署名の何れかとして
    生成されることを特徴とする請求項1に記載されたディ
    ジタル署名処理方法。
  4. 【請求項4】 前記匿名公開鍵証明書は、Schnorr暗号
    の署名、E暗号の署名およびDSA方式の署名の何ずれかを
    用いて生成されることを特徴とする請求項1に記載され
    たディジタル署名処理方法。
JP10822696A 1996-04-26 1996-04-26 ディジタル署名処理方法 Expired - Fee Related JP3513324B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP10822696A JP3513324B2 (ja) 1996-04-26 1996-04-26 ディジタル署名処理方法
EP97302857A EP0804003A3 (en) 1996-04-26 1997-04-25 Digital signature method and communication system
US08/845,405 US6154841A (en) 1996-04-26 1997-04-25 Digital signature method and communication system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP10822696A JP3513324B2 (ja) 1996-04-26 1996-04-26 ディジタル署名処理方法

Publications (2)

Publication Number Publication Date
JPH09298537A JPH09298537A (ja) 1997-11-18
JP3513324B2 true JP3513324B2 (ja) 2004-03-31

Family

ID=14479257

Family Applications (1)

Application Number Title Priority Date Filing Date
JP10822696A Expired - Fee Related JP3513324B2 (ja) 1996-04-26 1996-04-26 ディジタル署名処理方法

Country Status (1)

Country Link
JP (1) JP3513324B2 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100434721B1 (ko) * 2001-12-18 2004-06-07 이임영 유·무선 통합 멀티캐스트 키 관리 방법
JP4610169B2 (ja) * 2002-07-23 2011-01-12 パナソニック株式会社 通信方法および通信システム
US7490070B2 (en) * 2004-06-10 2009-02-10 Intel Corporation Apparatus and method for proving the denial of a direct proof signature
TW201017514A (en) * 2004-12-21 2010-05-01 Sandisk Corp Memory system with versatile content control
JP4679163B2 (ja) * 2005-01-21 2011-04-27 株式会社東芝 デジタル署名情報生成装置、デジタル署名情報生成方法及びプログラム
CN101155032A (zh) * 2006-09-25 2008-04-02 日电(中国)有限公司 匿名可选择凭证系统及其方法
KR100901693B1 (ko) * 2006-12-04 2009-06-08 한국전자통신연구원 동시 수행 환경에서의 링 인증 방법
US7975142B2 (en) 2006-12-04 2011-07-05 Electronics And Telecommunications Research Institute Ring authentication method for concurrency environment
JP5347263B2 (ja) * 2007-11-22 2013-11-20 日本電気株式会社 クライアント装置および通信方法
US9104618B2 (en) 2008-12-18 2015-08-11 Sandisk Technologies Inc. Managing access to an address range in a storage device

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
David Chaum and Eugene van Heyst,"Group Signatures",Lecture Notes in Computer Science(EUROCRYPT’91),1991年12月 9日,Vol.547,pp.257−265
L Harn,"Group−oriented(t,n) thershold digital signature scheme and digital multisignature",IEE PROCEEDINGS COMPUTERS AND DIGITAL TECHNIQUES,1994年10月13日,Vol.141,No.5,pp.307−313

Also Published As

Publication number Publication date
JPH09298537A (ja) 1997-11-18

Similar Documents

Publication Publication Date Title
Brickell et al. Enhanced privacy ID: A direct anonymous attestation scheme with enhanced revocation capabilities
US6202150B1 (en) Auto-escrowable and auto-certifiable cryptosystems
US6154841A (en) Digital signature method and communication system
US5606617A (en) Secret-key certificates
US6292897B1 (en) Undeniable certificates for digital signature verification
US6282295B1 (en) Auto-recoverable and auto-certifiable cryptostem using zero-knowledge proofs for key escrow in general exponential ciphers
US6411715B1 (en) Methods and apparatus for verifying the cryptographic security of a selected private and public key pair without knowing the private key
US7590850B2 (en) Digital signature method based on identification information of group members, and method of acquiring identification information of signed-group member, and digital signature system for performing digital signature based on identification information of group members
US6389136B1 (en) Auto-Recoverable and Auto-certifiable cryptosystems with RSA or factoring based keys
US8654975B2 (en) Joint encryption of data
US20100142704A1 (en) Cryptographic encoding and decoding of secret data
US6122742A (en) Auto-recoverable and auto-certifiable cryptosystem with unescrowed signing keys
JPWO2008146667A1 (ja) 匿名認証システムおよび匿名認証方法
US20160269397A1 (en) Reissue of cryptographic credentials
CA2554368A1 (en) Group signature system, method, device, and program
US8015398B2 (en) Set membership proofs in data processing systems
JPH11231781A (ja) 認証方法および装置
JP3513324B2 (ja) ディジタル署名処理方法
AU737037B2 (en) Auto-recoverable auto-certifiable cryptosystems
JP2004228958A (ja) 署名方法および署名プログラム
Huang et al. New constructions of convertible undeniable signature schemes without random oracles
Bultel et al. Improving the efficiency of report and trace ring signatures
JPH09200198A (ja) メッセージ認証システム
JP3331329B2 (ja) 公開検証可依頼復元ブラインド署名方法、その装置及びプログラム記録媒体
JP2000231330A (ja) ブラインド署名方法、そのシステム、その装置およびプログラム記録媒体

Legal Events

Date Code Title Description
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20031215

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20040109

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

Free format text: PAYMENT UNTIL: 20090116

Year of fee payment: 5

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

Free format text: PAYMENT UNTIL: 20090116

Year of fee payment: 5

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

Free format text: PAYMENT UNTIL: 20100116

Year of fee payment: 6

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

Free format text: PAYMENT UNTIL: 20110116

Year of fee payment: 7

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

Free format text: PAYMENT UNTIL: 20120116

Year of fee payment: 8

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

Free format text: PAYMENT UNTIL: 20130116

Year of fee payment: 9

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

Free format text: PAYMENT UNTIL: 20140116

Year of fee payment: 10

LAPS Cancellation because of no payment of annual fees