JPH09298537A

JPH09298537A - ディジタル署名方式およびそれを用いた情報通信システム

Info

Publication number: JPH09298537A
Application number: JP8108226A
Authority: JP
Inventors: Kazuomi Oishi; 和臣大石
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1996-04-26
Filing date: 1996-04-26
Publication date: 1997-11-18
Anticipated expiration: 2016-04-26
Also published as: JP3513324B2

Abstract

(57)【要約】【課題】グループ署名の正当性を確認するために用い
るグループの公開鍵は、メンバの数に比例した大きさに
なる。【解決手段】オーソリティZAは、メンバjに対してメ
ンバであることの証明書であるディジタル署名を送る。
証明書を入手したメンバjは、署名したいメッセージm
(j)に対し、グループ署名を生成する。メッセージm(j)
を受信した確認者は、そのグループ署名が、オーソリテ
ィZAに認められたメンバによって生成されたグループ署
名か否かを確認する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はディジタル署名方式
およびそれを用いた情報通信システムに関する。

【０００２】

【従来の技術】コンピュータおよび通信ネットワークの
発展と広範な普及に伴い、社会的活動のような機能をネ
ットワーク上においても実現できるようになった。しか
し、誰が、何時、何処で、何を行ったか、も容易に把握
することができ、それに対抗するため、匿名で処理を行
うことによりネットワーク上で多様な機能を実現し、か
つプライバシも保護する方法が考えられている。

【０００３】後述する公開鍵暗号を用いれば、送信者は
通信内容を意図する受信者だけに送り、しかも受信者は
その通信の送信者が誰であるかを確実に確認することが
可能である。後述する零知識証明を利用すれば、ユーザ
がある秘密情報を保持していることを、その秘密を明ら
かにすることなく他者に証明できる。これらを応用した
情報通信システムが、Masahiro MAMBO, Eiji OKAMOTO,
"A method to publicly specify a signer with hidin
g identity, The 18th Symposium on Information Theo
ry and Its Applications" (October 1995)で提案され
ている。これを、以下では「MOシステム」と呼ぶことに
する。

【０００４】以下、最初に公開鍵暗号を、次に零知識証
明を、それからMOシステムを詳細に説明する。

【０００５】［公開鍵暗号］公開鍵暗号とは、暗号鍵と
復号鍵とが異なり、暗号鍵を公開し、復号鍵を秘密にす
る暗号方式であり、以下のような特徴をもつ。 (1)暗号鍵と復号鍵とが異なり、暗号鍵を公開すること
ができるため、暗号鍵を秘密に配送する必要がなく、鍵
の配送が容易である。 (2)各利用者は、暗号鍵を公開し、各自、復号鍵だけを
秘密にし記憶しておけばよい。 (3)送られてきた通信文の送信者が偽者でないこと、お
よび、その通信文が改竄されていないことを、受信者が
確認するための認証機能（ディジタル署名）を実現でき
る。

【０００６】通信文（平文）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を決定することは、その計算量から困難であ
る。

【０００７】さらに、上記(1)(2)に加えて、次の条件
(3)が成立することにより、秘密通信が実現できる。 (3)すべての平文Mに対し、E(kp, M)を定義することがで
き、次式が成立する。 D(ks, E(kp, M)) = M

【０００８】つまり、暗号鍵kpは公開されているため、
誰もがE(kp, M)を計算することができるが、D(ks, E(k
p, M))を計算して平文Mを得ることができるのは、秘密
の復号鍵ksを記憶している本人だけである。

【０００９】一方、上記(1)(2)に加えて、次の条件(4)
が成立することにより、認証通信（ディジタル署名）が
実現できる。 (4)すべての平文Mに対し、D(ks, M)を定義することがで
き、次式が成立する。 E(kp, D(ks, M)) = M

【００１０】つまり、D(ks, M)を計算できるのは秘密の
復号鍵ksを記憶している本人だけであり、他人が偽の鍵
ks'を用いてD(ks', M)を計算し、秘密の復号鍵ksを記憶
する本人になりすまそうとしても、E(kp, D(ks', M))≠
Mであり、受信者は受取った情報が不正なものであるこ
とを知ることができる。

【００１１】同様に、D(ks, M)が改竄されても、E(kp,
D(ks, M)')≠Mであり、受信者は受取った情報が不正な
ものであることを知ることができる。このD(ks, M)をM
に対する「ディジタル署名」と呼ぶ。

【００１２】代表的な公開鍵暗号方式を以下に挙げる。
秘密通信と認証通信ができる方式として、RSA暗号(R.
L. Rivest, A. Shamir and L. Adleman: "A method of
obtaining digital signatures and public key crypto
systems", Comm. of ACM, 1978)、R暗号(M. Rabin: "Di
gitalized signatures and public-key cryptosystem
s", MIT/LCS/TR-212, Technical Report MIT, 1979)、W
暗号(H. C. Williams: "Amodification of the RSA pub
lic-key encryption procedure", IEEE Trans. Inf. Th
eory, IT-26, 6, 1980)などがある。

【００１３】また、秘密通信だけができる方式として、
CR暗号(B. Chor and R. L. Rivest:"A knapsack type p
ublic key cryptosystem based on arithmetric in fin
itefield", Proc. Crypto 84)、M暗号(R. J. McEliece:
"A public-key cryptosystem based on algebraic cod
ing theory", DSN Progress Rep., Jet PropulsionLa
b., 1978)、E暗号(T. E. ElGamal: "A public key cryp
tosystem and a signature scheme based on discretre
logarithms", IEEE Transaction on Information Theo
ry, Vol. IT-31, No.4, pp.469-472, 1985)などがあ
る。

【００１４】認証通信だけができる方式として、S暗号
(A. Shamir: "A fast signature scheme", Report MIT/
LCS/TM-107, MIT laboratory for computer science, C
ambridge, Mass., 1978)、L暗号(K. Lieberherr: "Unif
orm complexity and digitalsignature", Lecture Note
s in Computer Science 115 Automata, Language andPr
ogramming, Eigtht Colloquium Acre, Israel, 1981)、
GMY暗号(S. Goldwasser, S. Micali and A. Yao: "Stro
ng signature schemes", ACM Symp. on Theory of Comp
uting, 1983)、GMR暗号(S. Goldwasser, S. Micali and
R. L. Rivest: "A 'paradoxical' solution to the si
gnature problem", ACM Symp. on Foundation of Compu
ter Science, 1984)、E暗号(T. E. ElGamal: "A public
key cryptosystem and a signature scheme based on
discretre logarithms", IEEE Transaction on Informa
tion Theory, 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 qua
dratic inequalities", IEEE Symp. on Theory of Comp
uting, 1984)、

【００１５】Fiat-Shamir暗号(A. Fiat, A. Shamir: "H
ow to prove yourself: practicalsolutions of identi
fication and signature problems", Proc. of CRYPTO'
86,1987)、Schnorr暗号(C. P. Schnorr: "Efficient si
gnature generation by smart cards", Journal of Cry
ptology, vol.4, pp.161-174, 1991)などがある。

【００１６】具体的な一例として、離散対数を求めるこ
との困難性に安全性の根拠をおき、偽造に対する安全性
が極めて高いとされ、署名のサイズが小さい署名方式で
あるSchnorr暗号を説明する。なお、以下の説明におい
て、a^bはaのb乗を表す。

【００１７】例えば、大きな素数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を効率的に
求めることは難しいとされている。

【００１８】Schnorr暗号では、鍵認証センタ(KAC: Key
Authentication Center)がシステムの初期化を行う。
署名者が鍵生成と署名生成を行い、認証者が署名を受取
り確認する。システムの中では、一方向性ハッシュ関数
を用いる。一方向性ハッシュ関数とは、衝突を起こしに
くい圧縮関数である。つまり、任意の長さの値を入力し
て固定の長さの値を出力し、同じ値を出力する異なる入
力を見つけることが困難である。Zは整数の集合で、Zq
は0以上q未満の整数の集合である。

【００１９】●システム初期化 (1)鍵認証センタ(KAC)は、大きな素数p(≧2^512)とq(≧
2^140)を選び公開する。ただし、q|p-1である。 (2)KACは、α∈Zpかつα^q = 1 (mod p)なるα(≠1)を
選び公開する。 (3)KACは、h: Zq×Z → {0, …, 2^t - 1}を選び公開す
る。ここで、tを「セキュリティパラメータ」と呼ぶ。 (4)KACは、自分の署名用の公開鍵と秘密鍵を選び、公開
鍵を公開する（例えば、Fiat-Shamir暗号など）。

【００２０】●鍵生成システムに加入するユーザ（署名者）は、0 < s≦qなる
任意の整数sを選び、v= α^{-s} mod pを計算する。署
名者の秘密鍵はsであり、公開鍵はvである。認証者は、
署名者の公開鍵の正当性を、例えば、署名者の公開鍵に
対してKACが（例えば、Fiat-Shamir暗号で）署名を付け
る、あるいは、署名者の公開鍵が公開データベースに登
録される、などによって確認することができる。

【００２１】●署名生成（メッセージmに対する署名） (1)署名者は、乱数r∈{1, …, q}を選び、x = α^r (mo
d p)を計算する。 (2)署名者は、e = h(x, m)を求める。 (3)署名者は、y = r + s・e (mod q)を計算する。(e, y)
が、メッセージmに対する署名である。

【００２２】●署名検証メッセージmと署名(e, y)を受取った認証者は、前述の
方法でvの正当性を確認し、次式を確認する。 x' = α^y・v^e (mod p) e = h(x', m)

【００２３】［零知識証明］零知識証明とは、ある命題
を証明者が検証者に証明することであり、以下の三条件
を満たす。 (1)完全性: 証明が正しければ、検証者は1または1に限
りなく近い確率（圧倒的確率）で受理する。 (2)健全性: 証明が誤っていれば、検証者は1または1に
限りなく近い確率（圧倒的確率）で棄却する。 (3)零知識性: 証明が正しければ、検証者がどのように
振る舞っても、証明の正しさ以外の情報は一切洩れな
い。

【００２４】ある秘密（数値）を知っている証明者が、
その秘密に関する情報を一切漏らさずに、その秘密を知
っていることを検証者に証明する零知識証明の方法が幾
つか提案されていて、身元証明やディジタル署名などに
応用され、情報セキュリティの分野における重要な基板
技術となっている。

【００２５】具体的な一例として、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, α)} ≡(mod p)）。

【００２６】●DL(v, w) = DL(u, α)を証明する零知識
証明プロトコル以下では、証明者をP(Prover)、検証者をV(Verifier)と
記す。PもVもv, w, u,αを知っている。 (1)検証者Vは、乱数aとbを選び(a, b∈Zq)、ch = w^a・
α^bを求め、chを証明者Pに送る。 (2)証明者Pは、乱数tを選び(t∈Zq)、h1 = ch・α^tとh2
= h1^zを求め、(h1, h2)を検証者Vに送る。 (3)検証者Vは、(a, b)を証明者Pに送る。 (4)証明者Pは、ch = w^a・α^bを確認し、tを検証者Vに
送る。 (5)検証者Vは、h1 = w^a・α^{b+t}とh2 = v^a・u^{b+t}
を確認する。

【００２７】［ディジタル署名方式］以上に説明した公
開鍵暗号や零知識証明を応用したディジタル署名方式
が、D.Chaum, E. van Heyst, "Group Signatures", Pro
c. of EUROCRYPT'91, pp.257-265 (1991)に提案されて
いる。これはグループ署名と呼ばれ、以下の性質を満た
す。 (1)グループメンバのみが署名を行える。 (2)署名を受取った者は、それが正当な署名であること
は確認できるが、グループのどのメンバが証明をしたの
かはわからない。 (3)後で必要が生じたときに署名者を明らかにするため
に、署名は（グループメンバの助力を得て、あるいは、
得ずに）開示されることができる。

【００２８】グループ署名の用途には、例えば、入札シ
ステムがある。ある入札に参加する応札者をメンバと
し、応札者は自分の付ける値段や条件に対してグループ
署名を生成する。落札しない限り誰がどんな値段や条件
を提示したかは不明であるが、落札の際には落札者、つ
まり署名者を明らかにすることができる。

【００２９】

【発明が解決しようとする課題】前述したChaum等の論
文には四つのグループ署名方式が提案されていて、それ
ぞれ、署名者名を開示する際に特別に信頼されたオーソ
リティ（以下、これをZAで表す）を要する方式と、そう
でない方式、グループメンバの新規加入が容易な方式
と、そうでない方式など、幾つかの基準により分類され
る特徴をもつ。しかし、その何れの方式も、署名の正当
性を確認するために用いるグループの公開鍵は、メンバ
の数に比例した大きさになるという性質がある。

【００３０】一方、S. J. Park, I. S. Lee, D. H. Wo
n, "A practical group signature",Proc. of the 1995
Japan-Korea Workshop on Information Security and
Cryptology, IV-3, pp.127-133 (1995)に提案されてい
るグループ署名方式は、グループの公開鍵の大きさはメ
ンバ数に比例せず、メンバの新規加入が容易であるとい
う特徴をもち、署名の開示の際にZAが必要な方式であ
る。

【００３１】本発明は、上述の問題を解決するためのも
のであり、グループの公開鍵の大きさがグループメンバ
数に比例する必要がないディジタル署名方式およびそれ
を用いた情報通信システムを提供することを目的とす
る。

【００３２】また、メンバの新規加入が容易であるディ
ジタル署名方式およびそれを用いた情報通信システムを
提供することを他の目的とする。

【００３３】また、オーソリティが署名の開示を行うこ
とが可能であるとともに、各メンバが、その署名は自分
が作成した署名か否かを証明することが可能なディジタ
ル署名方式およびそれを用いた情報通信システムを提供
することを他の目的とする。

【００３４】

【課題を解決するための手段】本発明は、前記の目的を
達成する一手段として、以下の構成を備える。

【００３５】本発明にかかるディジタル署名方式は、グ
ループメンバに用いられ、ディジタル署名を生成する生
成手段と、グループの公開鍵を用いて、対象とする署名
が前記グループメンバにより生成されたことを確認する
確認手段と、対象とする署名の署名者を開示する開示手
段とを有することを特徴とする。

【００３６】また、複数ユーザ間で共通に使われる第一
の底の値に対して各ユーザの秘密鍵を指数値として指数
計算を行った結果を各ユーザの第一の公開鍵とするディ
ジタル署名方式であって、前記底に対して乱数を指数値
として指数計算を行った結果を第二の底とする底生成ス
テップと、所定のユーザの公開鍵に対して前記乱数を指
数値として指数計算を行った結果を第二の公開鍵とする
公開鍵生成ステップと、前記所定のユーザが、自身の秘
密鍵を用いて、任意の平文に対して第一のディジタル署
名を生成する第一の署名生成ステップと、前記第二の底
および前記第二の公開鍵を用いて、前記第一のディジタ
ル署名の正当性を確認する確認ステップと、単一または
複数の特別なユーザが、前記複数のユーザそれぞれに対
応する前記第二の公開鍵に対して、第二のディジタル署
名を生成する第二の署名生成ステップと、前記第一およ
び第二のディジタル署名の組からなる第三のディジタル
署名から、その署名者を開示する開示ステップとを有す
ることを特徴とする。

【００３７】本発明にかかる情報通信システムは、グル
ープメンバに用いられ、ディジタル署名を生成する生成
手段と、グループの公開鍵を用いて、対象とする署名が
前記グループメンバにより生成されたことを確認する確
認手段と、対象とする署名の署名者を開示する開示手段
とを有するディジタル署名方式を用いることを特徴とす
る。

【００３８】

【発明の実施の形態】以下、本発明にかかる一実施形態
の情報通信システムを図面を参照して詳細に説明する。

【００３９】本発明にかかるディジタル署名方式は、後
述する匿名公開鍵証明書方式を応用して、信頼されたオ
ーソリティZAが指定者、メンバが署名者になり、匿名公
開鍵証明書に基づくディジタル署名をグループ署名とす
るものであり、本発明にかかる匿名公開鍵証明方式によ
れば、以下のような機能を実現することができる。

【００４０】指定者が、乱数により、共通の公開パラメ
ータと署名者のディジタル署名の公開鍵を変換し、変換
した公開鍵に対する指定者のディジタル署名1を生成す
る。署名者の秘密鍵と、変換されたパラメータおよび公
開鍵との間には、以前と同じ関係が成り立つので、署名
者は秘密鍵を用いて任意の平文に対してディジタル署名
2を生成することができる。

【００４１】ディジタル署名1および同2の受信者は、デ
ィジタル署名1により、変換されたパラメータおよび公
開鍵が指定者に認められていることを確認し、それらを
用いて、ディジタル署名2と平文の対応関係を確認する
ことができる。なお、ディジタル署名1および同2を合わ
せた署名は、それから署名者を明らかにすることが困難
なので匿名署名と呼ぶ。

【００４２】このように、指定者が信頼されたオーソリ
ティZAになり、指定者に指定されたユーザ、すなわち署
名者がメンバになるので、オーソリティZAの使う公開鍵
はグループの公開鍵になり、匿名署名はグループ署名に
なる。この署名はグループ署名の最初の二つの条件を満
たす。

【００４３】署名者の開示は、次のような方法をとる。
信頼されたオーソリティZAは、どのメンバにどの証明書
を発行したかを記録し、グループ署名が与えられたと
き、その証明書の部分からそれがどのメンバにより生成
されたかを判別することができる。さらに、その証明書
に用いた乱数を知っているので、その乱数を利用して証
明者名を開示することができる。

【００４４】一方、あるグループ署名に対して、各メン
バがその署名者であるか否かは、そのグループ署名に使
われた秘密鍵と各メンバの秘密鍵が等しいか否かで判別
することができる。従って、署名者ではないメンバは、
自分の秘密鍵と対象のグループ署名に使われた秘密鍵と
が異なることを証明できるので、すべてのメンバに対し
て、その証明を要求することにより誰が証明者であるか
を判別することができる。

【００４５】

【第1実施形態】以下では、匿名公開鍵証明書方式(APK
C: Anonymous Public Key Certificate)を最初に説明
し、次に、それを応用したグループ署名を説明する。

【００４６】［匿名公開鍵証明書方式］図1は公開鍵暗
号を応用した匿名公開鍵証明書を説明するための図で、
図2は公開鍵証明書に関する処理の流れの概要を示すフ
ローチャートである。

【００４７】このシステムは、指定者（証明書の発行
者）と複数のユーザ、ユーザの中から選ばれる署名者、
署名者の作成する署名を確認する確認者からなり、通信
内容から判別できる場合を除き送受信者を突き止めるこ
とが困難な通信を可能とするネットワーク（以下「匿名
通信ネットワーク」と呼ぶ）上で実現することができ
る。

【００４８】図1において、「公開値(Public Values)」
は後述するシステム共通のデータ、「公開データベース
(Public Database)」は公開されたデータベース、矢印
はデータの取得，送信，受信を示し、括弧で囲まれた番
号は処理の手順を示す。また、「署名者(Specified Sig
ner)」は、「指定者(Specifier)」によりユーザの中か
ら選ばれた署名者を表し、「確認者(Verifier)」は署名
を確認する者を表す。

【００４９】Step 0（準備）: システム共通のデータと
して、素数pとq(q|p-1)、Zp*の元であり位数qのα（α^
q≡1 (mod p)、Zp*はZqかつpと互いに素である整数の集
合）、一方向性ハッシュ関数h: Zq×Z → {0, …, 2^t
- 1}を用意する。これらは、システムに参加しているす
べてのユーザがアクセスでき、かつ不当な改竄などが起
こらないように適切に管理されている公開のデータベー
スに登録されているものとする。なお、以下の説明にお
いて、a_bはaに下付き添字bが付いた状態を表す。

【００５０】指定者iは公開鍵v_iと秘密鍵s_i(v_i = α
^{-s_i} mod p)を生成し、公開鍵を公開のデータベース
に登録する。署名者になり得るユーザjは、公開鍵v_jと
秘密鍵v_j(v_j = α^{-s_j} mod p)を生成し、公開鍵を
公開のデータベースに登録する。ユーザは複数存在し、
署名者も複数存在し得る。

【００５１】Step 1（ユーザ指定と公開）: 指定者i
は、複数の中からあるユーザ、すなわち署名者jを選び
（図1に示す矢印101）、署名者jの公開鍵v_jを乱数r_j
を用いて変換したz_jを計算し、z_jに対する署名（Schn
orr暗号による署名）を求め（図1に示す手順(1)）、そ
の署名（証明書）を署名者jに安全に送る（図1に示す矢
印102）。なお、安全に送る一方法として、前述したE暗
号を用いる方法がある。

【００５２】具体的には、指定者iは（秘密の）乱数r_j
(r_j ∈ Zq*)を選び、次式により各パラメータを求め、
署名(y_j, e_j，z_j)を署名者jに送る。なお、r_j ∈ Z
q*は、Zq*からランダムにr_jを選ぶことを表している。 x_j = α^{r_j} mod p z_j = {v_j}^{r_j} mod p e_j = h(x_j, z_j) y_j = r_j + e_j・s_i mod q

【００５３】Step 2（署名の生成）: 署名者jは、署名
(y_j, e_j, z_j)を手に入れ、次式を確認する。 e_j = h(α^{y_j}・{v_i}^{e_j} mod p, z_j) …(1) z_j =(α^{y_j}・{v_i}^{e_j} mod p)^{-s_k} mod p

【００５４】そして、署名したいメッセージm(j)に対
し、次の署名方式で署名を生成する。つまり、署名者j
は、秘密の乱数r(j)を選び(r(j) ∈ Zq*)、次式を計算
する。 x(j) = {x_j}^{r(j)} mod p e(j) = h(x(j), m(j)) y(j) = r(j) + e(j)・s_j mod q

【００５５】そして、((y_j, e_j, z_j), y(j), e(j),
m(j))を署名として、必要な相手に送る（図1に示す手順
(3)、矢印103）。

【００５６】Step 3（署名の確認）: 上記署名を受信し
た確認者は最初に、式(1)を確認し、次に次式を確認す
る（図1に示す手順(4)）。 e(j) = h({x_j}^{y(j)}・{z_j}^{e(j)} mod p, m(j))

【００５７】上記が確認できたならば、受信者（確認
者）は、メッセージm(j)に対する署名は指定者iに選ば
れた署名者によって生成された署名であると納得する。

【００５８】以上の匿名公開鍵証明書方式には次の性質
がある。 (1)指定者iだけが署名者jを指定でき、その証拠が証明
書（指定者iの生成したディジタル署名）になる。 (2)指定された署名者jは、証明書と自分の秘密鍵を用い
て匿名のままで署名を生成できる。 (3)受信者は、指定者iの公開鍵を用いて上記匿名署名の
正当性を確認できる。 (4)匿名署名からその署名者jを判別すること、および、
匿名署名を偽造することは困難である。

【００５９】［匿名公開鍵証明書に基づくグループ署名
方式］図3は本発明にかかる匿名公開鍵証明書に基づく
グループ署名方式(Group Signature based on APKC)を
用いたシステムの概念図で、匿名通信ネットワーク(Ano
nymous Communication Network)を介して、複数のユー
ザが互いに匿名で通信を行える状況を表している。

【００６０】図3に示す環境には、信頼されたオーソリ
ティZA、ユーザj, k, Vなどがアクセスできる公開デー
タベースが存在し、そこに各ユーザの公開鍵や、共通の
パラメータなどが登録されている。公開データベース
は、そこに登録された情報をすり替えるような不当な行
為を防ぐように、適切に管理されている。また、図3に
おいて、あるグループの公開鍵をv_{ZA}とし、そのグル
ープはj, kを含むメンバからなるものとする。

【００６１】同じグループに所属するメンバj, kは、匿
名公開鍵証明書(y_j, e_j, z_j)および(y_k, e_k, z_k)
をそれぞれ、オーソリティZAから発行してもらい、それ
に基づき、メンバ固有の署名部分(y(j), e(j), z(j))を
生成し、匿名通信ネットワークを介して、ユーザVにグ
ループ署名((y_j, e_j, z_j)，y(j), e(j), z(j))を送
る。

【００６２】ユーザVは、グループの公開鍵v_{ZA}を用
いて、匿名公開鍵証明書(y_j, e_j,z_j)を検証し、それ
から計算される値を用いて(y(j), e(j), z(j))を検証す
ることにより、グループ署名の正当性を確認することが
できる。

【００６３】以上の具体的な内容を図4を参考にして説
明する。図4は匿名公開鍵証明書に基づくグループ署名
方式を説明するための図、図5はグループ署名方式に関
する処理の流れの概要を示すフローチャートで、オーソ
リティZAに指定されたメンバjがグループ署名を生成
し、グループ署名を受信した確認者がグループ署名を確
認する例を示している。

【００６４】Step 10（準備）: 匿名公開鍵証明書方式
のStep 0と同じ。

【００６５】Step 11（メンバに対する証明書の発行）:
オーソリティZAは、ユーザjをグループのメンバにする
ことを認め、メンバjの公開鍵を乱数r_jを用いて変換し
たz_jを計算し、z_jに対する署名（Schnorr暗号による
署名）を求め（図4に示す手順(1)）、メンバjに直接送
る（図4に示す手順(2)、矢印402）。

【００６６】具体的には、指定者iは（秘密の）乱数r_j
(r_j ∈ Zq*)を選び、次式により各パラメータを求め、
署名(y_j, e_j，z_j)をメンバjに送る。 x_j = α^{r_j} mod p z_j = {v_j}^{r_j} mod p e_j = h(x_j, z_j) y_j = r_j + e_j・s_{ZA} mod q

【００６７】Step 12（グループ署名の作成）: メンバj
は、署名(y_j, e_j, z_j)を手に入れ、次式を確認す
る。 e_j = h(α^{y_j}・{v_{ZA}}^{e_j} mod p, z_j) …(2) z_j =(α^{y_j}・{v_{ZA}}^{e_j} mod p)^{-s_j} mod p

【００６８】ここで、x_j = α^{y_j}・{v_{ZA}}^{e_j}
mod pが成り立っているので、以降は、表記を簡略化す
るためにx_jを用いる。そして、メンバjは、署名したい
メッセージm(j)に対し、次の署名方式でグループ署名を
生成する。つまり、メンバjは、秘密の乱数r(j)を選び
(r(j) ∈ Zq*)、次式を計算する。 x(j) = {x_j}^{r(j)} mod p e(j) = h(x(j), m(j)) y(j) = r(j) + e(j)・s_j mod q

【００６９】そして、((y_j, e_j, z_j), y(j), e(j),
m(j))をグループ署名として、必要な相手に送る（図4に
示す手順(3)、矢印403）。

【００７０】Step 13（グループ署名の確認）: 上記署
名を受信した確認者は最初に、式(2)を確認し、次に次
式を確認する（図4に示す手順(4)）。 e(j) = h({x_j}^{y(j)}・{z_j}^{e(j)} mod p, m(j))

【００７１】上記が確認できたならば、受信者（確認
者）は、メッセージm(j)に対する署名はオーソリティZA
に認められたメンバによって生成されたグループ署名で
あると納得する。

【００７２】［グループ署名の開示方法］あるグループ
署名を誰が生成したのかを明らかにする、すなわちグル
ープ署名の開示は、次の二つの方法で実現することがで
きる。ただし、対象のグループ署名を((e_k, y_k, z_
k), e(k), y(k), m)、その署名者をメンバk、オーソリ
ティZAが生成したz_kに対応する乱数をr_kとする。

【００７３】方法1（信頼されたオーソリティによる開
示）: 信頼されたオーソリティZAは、証明書を生成する
際に用いた乱数r_kを記憶しておくことができるので、
あるグループ署名が与えられたとき、その証明書の中の
z_kに対応するメンバが誰かを判別することができる。
従って、オーソリティZAは、署名者がメンバkで、乱数
はr_k(= DL(z_k, v_k))であることがわかる。

【００７４】オーソリティZA（証明者P）は、証明書の
公開鍵に対応する秘密鍵と、メンバの公開鍵に対応する
秘密鍵とが等しいことを証明する。つまり、前述したDL
(v,w) = DL(u, α)を証明する零知識証明プロトコルを
利用して、DL(z_k, v_k) = DL(x_k, α)を認証者Vに対
して証明する。ただし、x_k = α^{y_k}・v_i^{e_k} mod
pである。なお、メンバの公開鍵は公開のデータベース
に登録されている。

【００７５】●DL(z_k, v_k) = DL(x_k, α)を証明する
零知識証明プロトコル (1)証明者Pは、v_kを認証者Vに送る。 (2)認証者Vは、乱数aとb(a, b ∈ Zq)を選び、ch = {v_
k}^a・α^bを計算し、証明者Pに送る。 (3)証明者Pは、乱数t(t ∈ Zq)を選び、h1 = ch・α^tと
h2 = {h1}^{r_k}を計算し、それらを認証者Vに送る。 (4)認証者Vは、(a, b)を証明者Pに送る。 (5)証明者Pは、ch = {v_k}^a・α^bを確認し、tを認証者
Vに送る。 (6)認証者Vは、h1 = {v_k}^a・α^{b+t}とh2 = {z_k}^a・
{x_k}^{b+t}を確認する。

【００７６】なお、上記のプロトコルの代わりに、同様
の証明が可能なプロトコルを使うこともでき、上記のプ
ロトコルだけが利用可能なものというわけではない。

【００７７】方法2（各メンバによる署名の否認）: も
う一つの開示方法は、対象のグループ署名が、自分が生
成した署名ではないことを、各メンバが証明することに
よって実現する。

【００７８】メンバj（証明者P）は、そのグループ署名
に使われているz_kに対応する秘密鍵が自分の公開鍵に
対応する秘密鍵s_j = DL(z_j, x_j)とは異なることを
（認証者Vに）示す。つまり、DL(v_j, α) ≠ DL(z_k,
x_k)を以下のプロトコルで証明する。ただし、p, q,
α, v_i, v_j, z_kおよびx_k = α^{y_k}・{v_i}^{e_k}
mod pは、証明者Pと認証者Vの両方が知っていて、両者
がパラメータγに合意した上で、以下のプロトコルが実
行される。

【００７９】なお、BC(γ, R)は、乱数Rを入力したビッ
トγのビットコミットメントと呼ばれる。これは、ある
ビットについて‘0’か‘1’の何れかを選択し、その値
が何れかかは、乱数Rが明らかにならない限りわからな
いような変換値である。従って、乱数Rを示すことでコ
ミットした値を開示でき、同じ変換値に対して違うビッ
トをコミットしたと偽ることが困難であるという性質を
もつ。例えば、I. B.Damgard, "Practical and provabl
y secure release of a secret and exchangeof a sign
ature", Proc. of EUROCRYPT'93, pp.207-217 (1994)に
具体例が示されている。

【００８０】●DL(v_j, α) ≠ DL(z_k, x_k)を証明す
る零知識証明プロトコルなお、表記を簡略化するために、以下の説明においては
mod pを一部省略する。 (1)認証者Vは、乱数e(e ∈ Zq*)とβ ∈ {0, 1}を選
び、(a, b)を次のように計算し、得られた(a,b)を証明
者Pに送る。

【００８１】 β =‘0’ならば (a, b) = (α^e, {v_j}^e) β =‘1’ならば (a, b) = ({x_k}^e, {z_k}^e) (2)証明者Pは、A^{-sj} ≡ b (mod p)の成立を確認し、
成り立つならばγ =‘1’とし、成り立たないならばγ
=‘0’とし、g = BC(γ, R)を認証者Vに送る。 (3)認証者Vは、eを証明者Pに送る。 (4)証明者Pは、(a, b) = (α^e, {v_j}^e)あるいは(a,
b) = ({x_k}^e, {z_k}^e)が成立することを確認し、ど
ちらかが成り立つならばans = Rとし、どちらも成り立
たないならばans = stopとし、ansを認証者Vに送る。 (5)認証者Vは、ans = stopの場合はプロトコルの処理を
中止し、そうでない場合はBC(γ, R) = gを確認する。 (6)上記(1)から(5)を合計r回繰り返す。

【００８２】なお、上記のプロトコルの代わりに、同様
の証明が可能なプロトコルを使うこともでき、上記のプ
ロトコルだけが利用可能なものというわけではない。

【００８３】受信者が開示したいグループ署名を有する
ときに、以上の二つの方法の何れか片方だけを実行する
ように制御することに加え、以下のように制御すること
も可能である。つまり、第一は、二つの方法を任意に選
択して実行できるように制御する方法である。第二は、
自動的に方法1を実行し、オーソリティZAが有効に機能
しない場合は、方法2を実行する制御方法である。第三
は、自動的に方法2を実行し、コンタクトできないメン
バがあるなどの理由で開示できない場合は、方法1を実
行する制御方法である。

【００８４】グループが複数存在する場合は、各グルー
プ（a, b, …とする）に対応する信頼できるオーソリテ
ィZA_a, ZA_b, …を設け、各オーソリティZAが固有の公
開鍵v_a, v_b, …を管理する、あるいは、信頼できる単
一のオーソリティZAが各グループに対応する個別の公開
鍵v_a, v_b, …を管理する、あるいは、それらの中間的
な方法があり得る。何れの場合にせよ、上記の説明と同
様にしてそれぞれのグループ署名を実現できる。

【００８５】以上の実施形態において、指定者あるいは
信頼されたオーソリティ、署名者あるいはメンバ、確認
者あるいは署名の受信者は、情報処理および通信に関す
る能力をもつ情報処理装置、例えばパーソナルコンピュ
ータ上において実現可能である。指定者、オーソリテ
ィ、署名者、メンバ、確認者、受信者の間における通信
は、例えばインターネットのようなネットワーク上で匿
名通信を可能にするサービスを運用することによって実
現できる。

【００８６】そして、パーソナルコンピュータのような
装置により、上記の計算を行い、上記のサービスが利用
できる通信ネットワーク上で通信を行うことにより、上
記の各ステップを実行して、匿名公開鍵証明書に基づく
ディジタル署名をグループ署名として用いた情報通信シ
ステムを構築することができる。勿論、インターネット
に限らず外部と分離された環境、例えば企業内のローカ
ルエリアネットワーク(LAN)においても、情報処理装置
を用いて通信ネットワークおよびサービスを構築するこ
とにより、匿名公開鍵証明書に基づくディジタル署名を
グループ署名として用いた情報通信システムを構築する
ことができる。

【００８７】また、上記では、オーソリティZAが、匿名
公開鍵証明書をメンバに直接送る例を説明したが、用途
によっては、同証明書を公開データベースに登録し、メ
ンバおよび署名の受信者が公開データベースにアクセス
するという方法もあり得る。

【００８８】以上説明したように、本実施形態にかかる
匿名公開鍵証明書に基づくディジタル署名をグループ署
名として用いた情報通信システムによれば、グループの
公開鍵の大きさはグループメンバ数に比例せず、各メン
バが、その署名は自分が作成した署名か否かを証明する
ことが可能なグループ署名を実現することができる。従
って、公開鍵の大きさがメンバ数に比例しない場合で
も、必ずしもオーソリティZAを必要とせず、データサイ
ズの低減と開示の際の融通性を同時に達成でき、コスト
低減と使い勝手の向上を達成することができる。

【００８９】また、本実施形態にかかるグループ署名方
式は、あるグループ署名に対して、オーソリティZAは、
その署名の開示を行うことが可能であり、かつ、各メン
バは、その署名は自分が作成した署名か否かを証明する
ことも可能である。従って、オーソリティZAが有効に機
能しない場合にも、署名の開示を行うことができ、また
その逆も可能であり、より柔軟性のあるシステム、使い
勝手のよいシステムにすることができる。

【００９０】また、本実施形態にかかるグループ署名方
式は、グループの公開鍵の大きさはグループメンバ数に
比例せず、かつ、オーソリティZAは、あるグループ署名
に対して、その署名の開示を行うことが可能であり、か
つ、各メンバは、その署名は自分が作成した署名か否か
を証明することが可能である。従って、データサイズが
小さくなる上、オーソリティZAを用いて署名の開示を行
うことも、オーソリティZAが有効に機能しない場合に署
名の開示を行うこともでき、データサイズの低減と開示
の際の融通性の最適化が図れ、コスト低減と使い勝手の
最適化を実現することができる。

【００９１】さらに、本実施形態にかかるグループ署名
方式は、メンバの新規加入が容易であるという特徴をも
つので、メンバの加入の度に処理を繰り返す必要がな
く、システム全体の効率を向上することができる。

【００９２】また、前述したPark等が提案するグループ
署名方式における公開鍵の大きさと、本発明にかかる方
式の公開鍵の大きさとを、素数pを688ビット、一方向性
ハッシュ関数のセキュリティパラメータを70ビットに揃
えて比較すると、Park等のグループ署名の大きさが1676
ビットになる（k'λ = 70とした）のに対して、本発明
にかかる方式のグループ署名の大きさは1108ビットであ
る。従って、署名の大きさを約34%削減でき、その分、
通信のコストを下げることができる。

【００９３】

【第2実施形態】以下、本発明にかかる第2実施形態の情
報通信システムを説明する。なお、第2実施形態におい
て、第1実施形態と略同様の構成については、同一符号
を付して、その詳細説明を省略する。

【００９４】前述した実施形態においては、z_jに対す
る公開鍵証明書をSchnorr暗号の署名を用いて生成し、
p, q, x_j, z_jを公開鍵、s_jを秘密鍵として、メッセ
ージm_jに対してSchnorr暗号の署名を適用した。これに
対し、第2実施形態においては、メッセージm_jに対し
て、Schnorr暗号の署名ではなくE暗号(T. E. ElGamal:
"Apublic key cryptosystem and a signature scheme
based on discretre logarithms, IEEE Transaction on
Information Theory, Vol. IT-31, No. 4, pp.469-47
2, 1985)を適用する。

【００９５】以下では、第1実施形態と異なる点だけを
説明する。

【００９６】Step 12（グループ署名の作成）: 署名者j
は、署名をしたいメッセージm(j)に対し、次の方式で署
名を生成する。署名者jは、秘密の乱数k(j)を選び(k(j)
∈Zq*)、次式を計算する。 r(j) = {x_j}^{k(j)} mod p s(j) = (m(j) + s_j・r(j))・k(j)^{-1} mod (p - 1)

【００９７】そして、((y_j, e_j, z_j), r(j), s(j),
m(j))を署名として、必要な相手に送る。

【００９８】Step 13（グループ署名の確認）: 上記署
名を受信した確認者は最初に、式(2)を確認し、次に次
式を確認する。 {x_j}^{m(j)} ≡ {z_j}^{r(j)}・r(j)^{s(j)} (mod p)

【００９９】上記が確認できたならば、受信者（確認
者）は、メッセージm(j)に対する署名はオーソリティZA
に認められたメンバによって生成された署名であると納
得する。

【０１００】

【第3実施形態】以下、本発明にかかる第3実施形態の情
報通信システムを説明する。なお、第3実施形態におい
て、第1実施形態と略同様の構成については、同一符号
を付して、その詳細説明を省略する。

【０１０１】前述した第1および第2実施形態において
は、z_jに対する公開鍵証明書をSchnorr暗号の署名を用
いて生成し、メッセージm_jに対してSchnorr暗号または
E暗号を適用する例を説明した。同様に、ディジタル署
名標準案としてNIST(NationalInstitute of Standard a
nd Technology)に提案されたDSA（Digital SignatureAl
gorthm: 岡本栄司著、暗号理論入門、共立出版、pp.136
-138参照）をメッセージm_jに対して用いることも可能
である。

【０１０２】p, q, x_j, z_jを公開鍵、s_jを秘密鍵と
して用いる。

【０１０３】Step 12（グループ署名の作成）: 署名者j
は、署名をしたいメッセージm(j)に対し、次の方式で署
名を生成する。署名者jは、秘密の乱数k(j)を選び(k(j)
∈Zq*)、次式を計算する。 r(j) = ({x_j}^{k(j)} mod p) mod q s(j) = k(j)^{-1}・(H(m(j)) - s_j・r(j)) mod q

【０１０４】そして、(((y_j, e_j), z_j), ((r(j), s
(j)), m(j)))を署名として、必要な相手に送る。

【０１０５】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 = ({x_j}^{u1}・{z_j}^{u2} mod p) mod q

【０１０６】そして、以上の計算結果からv = r(j)を確
認し、確認できたならば受信者はm(j)に対する署名はオ
ーソリティZAに選ばれたメンバによって生成された署名
であると納得する。

【０１０７】

【第4実施形態】以下、本発明にかかる第4実施形態の情
報通信システムを説明する。なお、第4実施形態におい
て、第1実施形態と略同様の構成については、同一符号
を付して、その詳細説明を省略する。

【０１０８】前述した第1から第3実施形態においては、
z_jに対する公開鍵証明書をSchnorr暗号の署名を用いて
生成し、メッセージm_jに対してSchnorr暗号、E暗号ま
たはDSAを適用する例を説明した。これに対して、z_jに
対する公開鍵証明書の生成にSchnorr暗号の署名の代わ
って、E暗号を適用することも可能である。ただし、x_j
とz_jが次式の関係を満たすことが保証できるように、
署名を適用することに注意する。

【０１０９】x_j = α^{r_j} mod p z_j = {v_j}^{r_j} mod p

【０１１０】具体的には、以下のとおりである。

【０１１１】Step 11（メンバに対する証明書の発行）:
オーソリティZAは、メンバjに対して、秘密の乱数r_j
を選び(r_j ∈ Zq*)、次式を計算する。 x_j = α^{r_j} mod p z_j = {v_j}^{r_j} mod p S_j = (z_j + s_i・x_j)・{r_j}^{-1} mod (p - 1)

【０１１２】そして、(x_j, S_j，z_j)を公開鍵証明書
とする。

【０１１３】Step 12（グループ署名の作成）: メンバj
は、次式が成り立つことで公開鍵証明書の正当性を確認
することができる。 α^{z_j} ≡ {v_i}^{x_j}・{x_j}^{S_j} (mod p) z_j = {x_j}^{-S_j} mod p

【０１１４】

【第5実施形態】以下、本発明にかかる第5実施形態の情
報通信システムを説明する。なお、第5実施形態におい
て、第1実施形態と略同様の構成については、同一符号
を付して、その詳細説明を省略する。

【０１１５】前述した第4実施形態においては、z_jに対
する公開鍵証明書の生成にSchnorr暗号の署名の代わり
にE暗号を適用する例を説明した。これに対して、Schno
rr暗号やE暗号の代わりに、DSAを適用することも可能で
ある。ただし、x_jとz_jが次式の関係を満たすことが保
証できるように、署名を適用することに注意する。 x_j = α^{r_j} mod p z_j = {v_j}^{r_j} mod p

【０１１６】具体的には、以下のとおりである。

【０１１７】Step 11（メンバに対する証明書の発行）:
オーソリティZAは、メンバjに対して、秘密の乱数r_j
を選び(r_j ∈ Zq*)、次式を計算する。 x_j = α^{r_j} mod p z_j = {v_j}^{r_j} mod p S_j = {r_j}^{-1}・(H(z_j) - s_i・x_j) mod q

【０１１８】そして、(x_j, S_j, z_j)を公開鍵証明書
として、メンバjに送る。

【０１１９】公開鍵証明書の正当性は、次のように確認
できる。まず、0 < x_j < p, 0 < S_j < q を確認した
後、次の処理を行う。

【０１２０】Step 12（グループ署名の作成）: メンバj
は、次式が成り立つことで公開鍵証明書の正当性を確認
することができる。まず、0 < x_j < p, 0 < S_j < q
を確認した後、次の処理を行う。 w = {S_j}^{-1} mod q u1 = H(z_j)・w mod q u2 = x_j・w mod q v = α^{u1}・{v_i}^{u2} mod p

【０１２１】そして、v = x_jを確認する。公開鍵証明
書の正当性は、次式が成り立つことで確認できる。 z_j = {x_j}^{-S_j} mod p

【０１２２】

【他の実施形態】なお、本発明は、複数の機器（例えば
ホストコンピュータ，インタフェイス機器，リーダ，プ
リンタなど）から構成されるシステムに適用しても、一
つの機器からなる装置（例えば、複写機，ファクシミリ
装置など）に適用してもよい。

【０１２３】また、本発明の目的は、前述した実施形態
の機能を実現するソフトウェアのプログラムコードを記
録した記憶媒体を、システムあるいは装置に供給し、そ
のシステムあるいは装置のコンピュータ（またはCPUやM
PU）が記憶媒体に格納されたプログラムコードを読出し
実行することによっても、達成されることは言うまでも
ない。この場合、記憶媒体から読出されたプログラムコ
ード自体が前述した実施形態の機能を実現することにな
り、そのプログラムコードを記憶した記憶媒体は本発明
を構成することになる。プログラムコードを供給するた
めの記憶媒体としては、例えば、フロッピディスク，ハ
ードディスク，光ディスク，光磁気ディスク，CD-ROM，
CD-R，磁気テープ，不揮発性のメモリカード，ROMなど
を用いることができる。

【０１２４】また、コンピュータが読出したプログラム
コードを実行することにより、前述した実施形態の機能
が実現されるだけでなく、そのプログラムコードの指示
に基づき、コンピュータ上で稼働しているOS（オペレー
ティングシステム）などが実際の処理の一部または全部
を行い、その処理によって前述した実施形態の機能が実
現される場合も含まれることは言うまでもない。

【０１２５】さらに、記憶媒体から読出されたプログラ
ムコードが、コンピュータに挿入された機能拡張カード
やコンピュータに接続された機能拡張ユニットに備わる
メモリに書込まれた後、そのプログラムコードの指示に
基づき、その機能拡張カードや機能拡張ユニットに備わ
るCPUなどが実際の処理の一部または全部を行い、その
処理によって前述した実施形態の機能が実現される場合
も含まれることは言うまでもない。

【０１２６】本発明を上記記憶媒体に適用する場合、そ
の記憶媒体には、先に説明したフローチャートに対応す
るプログラムコードを格納することになるが、簡単に説
明すると、図6Aおよび6Bのメモリマップ例に示す各モジ
ュールを記憶媒体に格納することになる。すなわち、少
なくとも「生成」「確認」および「開示」の各モジュー
ル、または、「底生成」「公開鍵生成」「第一の署名生
成」「確認」「第二の署名生成」および「開示」の各モ
ジュールのプログラムコードを記憶媒体に格納すればよ
い。

【０１２７】

【発明の効果】以上説明したように、本発明によれば、
グループの公開鍵の大きさがグループメンバ数に比例す
る必要がないディジタル署名方式およびそれを用いた情
報通信システムを提供することができる。

【０１２８】また、メンバの新規加入が容易であるディ
ジタル署名方式およびそれを用いた情報通信システムを
提供することができる。

【０１２９】また、オーソリティが署名の開示を行うこ
とが可能であるとともに、各メンバが、その署名は自分
が作成した署名か否かを証明することが可能なディジタ
ル署名方式およびそれを用いた情報通信システムを提供
することができる。

【図面の簡単な説明】

【図１】本発明にかかる公開鍵暗号を応用した匿名公開
鍵証明書を説明するための図、

【図２】公開鍵証明書に関する処理の流れの概要を示す
フローチャート、

【図３】本発明にかかる匿名公開鍵証明書に基づくグル
ープ署名方式を用いたシステムの概念図、

【図４】匿名公開鍵証明書に基づくグループ署名方式を
説明するための図、

【図５】グループ署名方式に関する処理の流れの概要を
示すフローチャートで、

【図６Ａ】本発明にかかるプログラムコードを格納した
記憶媒体のメモリマップ例を示す図、

【図６Ｂ】本発明にかかるプログラムコードを格納した
記憶媒体のメモリマップ例を示す図である。

Claims

【特許請求の範囲】

【請求項１】グループメンバに用いられ、ディジタル
署名を生成する生成手段と、グループの公開鍵を用いて、対象とする署名が前記グル
ープメンバにより生成されたことを確認する確認手段
と、対象とする署名の署名者を開示する開示手段とを有する
ことを特徴とするディジタル署名方式。
【請求項２】前記グループの公開鍵は、グループメン
バ数に比例しない大きさであることを特徴とする請求項
1に記載されたディジタル署名方式。
【請求項３】前記確認手段は、対象とする署名の署名
者を確認できないことを特徴とする請求項1または請求
項2に記載されたディジタル署名方式。
【請求項４】前記開示手段は、前記署名者を開示する
ために特別なユーザを用いないことを特徴とする請求項
1に記載されたディジタル署名方式。
【請求項５】前記開示手段による前記署名者の開示
は、特別なユーザを用いる場合と、前記特別なユーザを
用いない場合とがあることを特徴とする請求項1に記載
されたディジタル署名方式。
【請求項６】複数ユーザ間で共通に使われる第一の底
の値に対して各ユーザの秘密鍵を指数値として指数計算
を行った結果を各ユーザの第一の公開鍵とするディジタ
ル署名方式であって、前記底に対して乱数を指数値として指数計算を行った結
果を第二の底とする底生成ステップと、所定のユーザの公開鍵に対して前記乱数を指数値として
指数計算を行った結果を第二の公開鍵とする公開鍵生成
ステップと、前記所定のユーザが、自身の秘密鍵を用いて、任意の平
文に対して第一のディジタル署名を生成する第一の署名
生成ステップと、前記第二の底および前記第二の公開鍵を用いて、前記第
一のディジタル署名の正当性を確認する確認ステップ
と、単一または複数の特別なユーザが、前記複数のユーザそ
れぞれに対応する前記第二の公開鍵に対して、第二のデ
ィジタル署名を生成する第二の署名生成ステップと、前記第一および第二のディジタル署名の組からなる第三
のディジタル署名から、その署名者を開示する開示ステ
ップとを有することを特徴とするディジタル署名方式。
【請求項７】離散対数を求めることの困難性に安全性
の根拠をおくことを特徴とする請求項6に記載されたデ
ィジタル署名方式。
【請求項８】 Schnorr署名方式および/またはElGamal
署名方式および/またはDSA方式を用いることにより、前
記離散対数を求めることを困難にすることを特徴とする
請求項7に記載されたディジタル署名方式。
【請求項９】前記開示ステップは、前記単一または複
数の特別なユーザにより署名者を開示することを特徴と
する請求項6から請求項8の何れかに記載されたディジタ
ル署名方式。
【請求項１０】前記開示ステップは、前記グループメ
ンバそれぞれが、前記第一のディジタル署名の生成者が
自分であるか否かを証明することを特徴とする請求項6
から請求項8の何れかに記載されたディジタル署名方
式。
【請求項１１】請求項1から請求項10の何れかに記載
されたディジタル署名方式を用いることを特徴とする情
報通信システム。
【請求項１２】ディジタル署名方式に関するプログラ
ムコードが格納されたコンピュータ可読メモリであっ
て、グループメンバに用いられ、ディジタル署名を生成する
生成手段のコードと、グループの公開鍵を用いて、対象とする署名が前記グル
ープメンバにより生成されたことを確認する確認手段の
コードと、対象とする署名の署名者を開示する開示手段のコードと
を有することを特徴とするコンピュータ可読メモリ。
【請求項１３】複数ユーザ間で共通に使われる第一の
底の値に対して各ユーザの秘密鍵を指数値として指数計
算を行った結果を各ユーザの第一の公開鍵とするディジ
タル署名方式を用いた情報通信システムに関するプログ
ラムコードが格納されたコンピュータ可読メモリであっ
て、前記底に対して乱数を指数値として指数計算を行った結
果を第二の底とする底生成ステップのコードと、所定のユーザの公開鍵に対して前記乱数を指数値として
指数計算を行った結果を第二の公開鍵とする公開鍵生成
ステップのコードと、前記所定のユーザが、自身の秘密鍵を用いて、任意の平
文に対して第一のディジタル署名を生成する第一の署名
生成ステップのコードと、前記第二の底および前記第二の公開鍵を用いて、前記第
一のディジタル署名の正当性を確認する確認ステップの
コードと、単一または複数の特別なユーザが、前記複数のユーザそ
れぞれに対応する前記第二の公開鍵に対して、第二のデ
ィジタル署名を生成する第二の署名生成ステップのコー
ドと、前記第一および第二のディジタル署名の組からなる第三
のディジタル署名から、その署名者を開示する開示ステ
ップのコードとを有することを特徴とするコンピュータ
可読メモリ。