U.S. patent application number 11/865973 was filed with the patent office on 2008-02-07 for non-transferable anonymous credential system with optimal anonymity revocation.
Invention is credited to Jan Leonhard Camnisch, Anna Lysyanskaya.
Application Number | 20080034203 11/865973 |
Document ID | / |
Family ID | 8170284 |
Filed Date | 2008-02-07 |
United States Patent
Application |
20080034203 |
Kind Code |
A1 |
Camnisch; Jan Leonhard ; et
al. |
February 7, 2008 |
NON-TRANSFERABLE ANONYMOUS CREDENTIAL SYSTEM WITH OPTIMAL ANONYMITY
REVOCATION
Abstract
The present invention relates to a method and system for
securely proving ownership of pseudonymous or anonymous electronic
credentials. A credential system is described consisting of users
and organizations. An organization knows a user only by a
pseudonym. The pseudonyms of the same user, established for use
with different organizations, cannot be linked. An organization can
issue a credential to a pseudonym, and the corresponding user can
prove possession of this credential to another organization that
knows him under another pseudonym. During the prove of possession
of the credential nothing besides the fact that he owns such a
credential is revealed. A refinement of the credential system
provides credentials for unlimited use, so called multiple-show
credentials, and credentials for one-time use, so called one-show
credentials.
Inventors: |
Camnisch; Jan Leonhard;
(Rueschlikon, CH) ; Lysyanskaya; Anna;
(Somerville, MA) |
Correspondence
Address: |
Robert P.Tassinari, Jr.;Intellectual Property Law Dept.
IBM Corporation
P.O. Box 218
Yorktown Heights
NY
10598
US
|
Family ID: |
8170284 |
Appl. No.: |
11/865973 |
Filed: |
October 2, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10000918 |
Nov 2, 2001 |
|
|
|
11865973 |
Oct 2, 2007 |
|
|
|
Current U.S.
Class: |
713/156 |
Current CPC
Class: |
H04L 9/3263 20130101;
H04L 9/3218 20130101; H04L 9/302 20130101; H04L 2209/56 20130101;
G06Q 20/383 20130101; H04L 2209/42 20130101; H04L 9/3013
20130101 |
Class at
Publication: |
713/156 |
International
Class: |
H04L 9/14 20060101
H04L009/14 |
Foreign Application Data
Date |
Code |
Application Number |
Nov 3, 2000 |
EP |
00123976.3 |
Claims
1. A method for establishing a pseudonym system by having a
certificate authority accepting a user as a new participant in said
pseudonym system, the method comprising the steps of receiving a
first public key provided by said user; verifying that said user is
allowed to join the system; computing a credential by signing the
first public key using a secret key owned by said certificate
authority; and publishing said first public key and said
credential.
2. The method according to claim 1, wherein the step of receiving a
first public key further includes receiving an external public key
being registered for said user with an external public key
infrastructure and receiving an encryption of a secret key
encrypted by using said first public key; the step of verifying
that said user is allowed to join the system further includes
verifying that said external public key is indeed registered with
said external public key infrastructure; the step of publishing
said first public key and said credential comprises publishing said
encryption and the name of the external public key infrastructure;
and additionally comprises the step of proving that the secret key
corresponding to said external public key is encrypted in said
received encryption.
3. The method according to claim 2, wherein said first public key
of the user is derived from at least one first secret key composed
by the user.
4. The method according to claim 3, wherein the step of receiving a
first public key derived from a first secret key further comprises
receiving a second public key which is derived from a second and a
third secret key composed by the user; and the step of computing a
credential by signing the first public key using a secret key owned
by said certificate authority further comprises computing a
credential by signing the second public key using said secret key
owned by said certificate authority.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] The present invention relates to the field of computer
network management, it specifically concerns a method and a
technical implementation for secure data exchange over a computer
network. More particularly, the present invention relates to a
method and system for securely proving ownership of pseudonymous or
anonymous electronic credentials.
[0003] 2. Description of the Related Art
[0004] Since the mid 1990s one of the most rapidly growing retail
sectors is referred to as electronic commerce. Electronic commerce
involves the use of the Internet and proprietary networks to
facilitate business-to-business, consumer, and auction sales of
everything imaginable, from computers and electronics to books,
recordings, automobiles and real estate. In such an environment
consumer privacy is becoming a major concern.
[0005] However, the mere fact that electronic commerce is conducted
over an existing open network infrastructure such as the Internet
runs counter to the privacy of the consumer. Often, there are
legitimate reasons for a party to remain anonymous.
OBJECT OF THE INVENTION
[0006] Starting from this, the object of the present invention is
to provide a method and a system for securely proving ownership of
pseudonymous or anonymous electronic credentials, wherein a party
that proves its ownership of the credential can stay anonymous,
i.e., that does not need to reveal its identity.
BRIEF SUMMARY OF THE INVENTION
[0007] The foregoing object is achieved by a method and a system as
laid out in the independent claims. Further advantageous
embodiments of the present invention are described in the sub
claims and are taught in the following description.
[0008] In the independent claims the same invention, and more
particularly, the same system is described having closely related
methods. First a user has to join the whole system. Then, the user
is able to establish more connections to different organizations,
which are also belonging to the system. Finally, the user is able
to show respective credentials, which the user gathered before to a
verifier (or further organizations). Hence, all such methods
realising a single system which is based on the present
invention.
[0009] As the collection and exploitation of secret information
become more of a concern, users are less willing to give out
information, and may want to conduct transactions under a pseudonym
or anonymously. For example, a user in a pseudonymous or anonymous
transaction may receive a credential stating that, e.g., he made a
payment for a newspaper subscription. The user might want to use
the credential at a later point in time or several times in the
future to prove that the particular transaction took place, e.g.,
that the user is entitled to read articles in the newspaper.
[0010] The method and system for proving ownership of an electronic
credential in accordance with the present invention is to be used
in a communication system providing a public key encryption
infrastructure. That is a system of public key encryption using
digital certificates from certificate authorities and other
registration authorities that verify and authenticate the validity
of each party involved in an electronic transaction. The
certificate authority, also called "Trusted Third Party", is an
entity, typically a company, that issues digital certificates to
other entities like organizations or individuals to allow them to
prove their identity to others. The certificate authority might be
an external company that offers digital certificate services or it
might be an internal organization such as a corporate MIS
(Management Information System) department. The Certificate
Authority's chief function is to verify the identity of entities
and issue digital certificates attesting to that identity.
[0011] In comparison, public key encryption is an encryption
scheme, where each person gets a pair of keys, called the public
key and the secret key. Each person's public key is published while
the secret key is kept secret. Messages are encrypted using the
intended recipient's public key and can only be decrypted using his
secret key. This is mechanism can also be used for or in
conjunction with a digital signature.
[0012] The digital signature is formed by extra data appended to a
message which identifies and authenticates the sender and message
data using public-key encryption. The sender uses a one-way hash
function to generate a hash-code of, for example, 160 bits from the
message data. He then encrypts the hash-code with his secret key.
The receiver computes the hash-code from the data as well and
decrypts the received hash with the sender's public key. If the two
hash-codes are equal, the receiver can be sure that data has not
been corrupted and that it came from the given sender.
[0013] The need for sender and receiver to share secret
information, e.g., keys, via some secure channel is eliminated,
since all communications involve only public keys, and no secret
key is ever transmitted or shared. Public-key encryption can be
used for authentication, confidentiality, integrity and
non-repudiation. RSA encryption is an example of a public-key
cryptography system.
[0014] The one-way hash function, also called "message digest
function", used for the digital signature is a function which takes
a variable-length message and produces a fixed-length hash. Given
the hash it is computationally impossible to find a message with
that hash. In fact, one cannot determine any usable information
about a message with that hash, not even a single bit. For some
one-way hash functions it is also computationally impossible to
determine two messages which produce the same hash. A one-way hash
function can be secret or public, just like an encryption function.
A public one-way hash function can be used to speed up a public-key
digital signature system. Rather than signing a long message which
can take a long time, the one-way hash of the message is computed,
and the hash is digitally signed.
[0015] A new credential system is described consisting of users and
organizations. An organization knows a user only by a pseudonym.
The pseudonyms of the same user, established for use with different
organizations, cannot be linked. An organization can issue a
credential to a pseudonym, and the corresponding user can prove
possession of this credential to another organization that knows
him under another pseudonym. During the prove of possession of the
credential nothing besides the fact that he owns such a credential
is revealed. In a refinement of the credential system there are
credentials for unlimited use, so called multiple-show credentials,
and credentials for one-time use, so called one-show
credentials.
[0016] The method and system according to the present invention
works as follows. In order to establish a pseudonym system a
certificate authority accepts a user as a new participant in the
pseudonym system by initially receiving a first public key provided
by said user and an external public key being registered for said
user with an external public key infrastructure. Then, the
certificate authority verifies that the external public key is
indeed registered with said external public key infrastructure. If
this is the case the certificate authority receives an encryption
of a secret key encrypted by using said first public key and proves
that the secret key corresponding to said external public key is
encrypted in said received encryption. Then, it computes a
credential by signing the first public key using a secret key owned
by said certificate authority and, finally, the certificate
authority publishes the first public key, the certificate, the
encryption and the name of the external public key
infrastructure.
[0017] In a second aspect of the present invention to establishing
a pseudonym system a user needs to get registered with an
organization. To do so, the organization receives a first public
key provided by said user and a first encryption of a first secret
key encrypted by using said first public key. Then, it proves that
an existing public key is registered for said user with said other
organization of said pseudonym system and that the secret key
corresponding to said existing public key is encrypted in said
received first encryption. Then, the organization computes a
credential by signing the first public key using a secret key owned
by said organization and publishes the first public key, the
certificate, the first encryption and the name of the other
organization.
[0018] According to a third aspect of the present invention a
verifier validates a credential shown by a user, whereby the
credential is formed by a public key which is registered with a
specified organization. Initially, the verifier receives a first
public key provided by the user and an existing public key being
registered for said user with the aforementioned organization.
Then, the verifier verifies that the existing public key is indeed
registered with said organization and receives a first encryption
of a first secret key encrypted by using the first public key.
Finally, the verifier proves that the secret key corresponding to
the existing public key is encrypted in the received first
encryption.
[0019] The present invention can be realized in hardware, software,
or a combination of hardware and software. Any kind of computer
system--or other apparatus adapted for carrying out the methods
described herein--is suited. A typical combination of hardware and
software could be a general purpose computer system with a computer
program that, when being loaded and executed, controls the computer
system such that it carries out the methods described herein. The
present invention can also be embedded in a computer program
product, which comprises all the features enabling the
implementation of the methods described herein, and which--when
loaded in a computer system--is able to carry out these
methods.
[0020] Computer program means or computer program in the present
context mean any expression, in any language, code or notation, of
a set of instructions intended to cause a system having an
information processing capability to perform a particular function
either directly or after either or both of the following a)
conversion to another language, code or notation; b) reproduction
in a different material form.
BRIEF DESCRIPTION OF THE DRAWING
[0021] The above, as well as additional objectives, features and
advantages of the present invention, will be apparent in the
following detailed written description.
[0022] The novel features of the invention are set forth in the
appended claims. The invention itself, however, as well as a
preferred mode of use, further objectives, and advantages thereof,
will best be understood by reference to the following detailed
description of an illustrative embodiment when read in conjunction
with the accompanying drawing, wherein:
[0023] FIG. 1 shows a general layout of a pseudonym system
according to the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0024] With reference to FIG. 1, there is depicted a general layout
of a pseudonym system according to the present invention. Within
the pseudonym system there are five organizations, a certificate
authority CA, an organization being able to issue a driver's
license DrLi, an insurance company for normal cars Ins, an
insurance company for sports cars SpIns and a car rental
organization CarRO. Furthermore, the pseudonym system includes two
verifiers, a car rental agency CR and a sports car rental agency
SR.
[0025] An arrow from X to Y means that the user showed to entity Y
a credential issued to him by entity X. The dashed line groups
organizations that trust each other to check various credentials
properly. In the shown example of a pseudonym system a user is
enabled to obtain a driver's license through organization DL, a car
insurance through organization Ins, a sports car insurance through
SpIns, and access to a car rental through the car rental
organization CarRO. The access to car rental is as follows.
[0026] The user first registers with the car rental organization
CarRO which verifies that he is a valid user (has got a
CA-credential) and has got a car-insurance (has an Ins-credential).
In the given scenario the car rental organization does not need to
worry whether or not the user has got a driver's license since the
respective insurance is responsible and liable for that. Now, if
the user wants to rent an ordinary car, he goes to the car rental
agency CR which functions as a verifier and proves that he owns a
credential from the car rental organizationCarRO. After he has
proven that he owns the respective credential he will get a
car.
[0027] However, if the user would like to rent a sports car, he
goes to the sports car agency SR.
[0028] There he shows that he owns not only a credential from the
car rental organization CarRO but also from the sports car
insurance SpIns, i.e., that he has a special insurance for sports
cars.
[0029] None of the credentials reveal any information about the
user's real identity or pseudonym. However, the showing of
credentials can be carried out in such a way that a designated
revocation manager can later find the user's identity and/or
pseudonyms. For instance, in case the user has a non-criminal car
accident, the revocation manager reveals the pseudonym the user has
with the corresponding insurance company and the cost of his
insurance will go up. Whereas, if he has a criminal accident, then
the revocation manager also reveals his real identity for further
prosecution.
[0030] In the following all methods needed for the above scenario
are described in greater detail.
[0031] Let {0, 1}* denote the set of all binary strings.
[0032] Computational problems are often modeled as decision
problems: decide whether a given x .di-elect cons. {0, 1}* belongs
to a language L .OR right. {0, 1}*. P is the class of languages for
which this can be decided in polynomial time. NP is the class of
problems for which the decision whether x belongs to L can be
verified in polynomial time when provided a credential (or witness)
of this fact. Clearly P .OR right. NP.
[0033] Let R .OR right. {0, 1}*.times.{0, 1}* be a boolean
relation. We say that R is "polynomially bounded" if there exists a
polynomial p() such that |w|.ltoreq.p(|x|) holds for all (x, w)
.di-elect cons. R. Furthermore, R is an NP-relation if it is
polynomially bounded and if there exists a polynomial-time
algorithm for deciding membership of pairs (x, w) in R. Finally,
L.sub.R={x|.E-backward.w such that (x, w) .di-elect cons. R} is the
language defined by R.
[0034] A language L is in NP if there exists an NP-relation R.sub.L
.OR right. {0, 1}*.times.{0, 1}* such that x .di-elect cons. L if
and only if there exists a w such that (x, w) .di-elect cons.
R.sub.L. Such a w is called a witness of the membership of x in L.
The set of all witnesses of x is denoted as R.sub.L(x).
[0035] It is known that for any NP-relation R, there exits a
so-called proof of knowledge. Such a proof is a protocol between a
prover and a verifier which allows the prover to convince the
verifier that for some given value y he knows a value w such (w, y)
is contained in R. The protocol has the additional property
although the verifier knows y, she does not get any information
about w other than that such a value exists and that the prover
knows it. Realization of such protocols for any relation R are
described in Brassard et al. (G. Brassard, D. Chaum, and C.
Crepeau. Minimum disclosure proofs of knowledge. Journal of
Computer and System Sciences, 37(2):156-189, October 1988, or Boyar
et al. J. Boyar, I. Damgaard, and R. Peralta; Short non-interactive
cryptographic proofs; Journal of Cryptology; 13(4):449-472, October
2000). We will denote these methods as PK{(.alpha.):(.alpha., y)
.di-elect cons. R}, where Greek letters stand for the values the
prover shows knowledge of and that the verifier does not learn
whereas she learns all other parameters. Finally, (.alpha., y)
.di-elect cons. R is the statement that is proven, or, in other
words, the conditions that the (secret) values the prover knows
satisfy.
[0036] There exists also non-interactive variants of these
protocols. They can be obtained from the interactive protocol using
the so-called Fiat-Shamir heuristic (A. Fiat and A. Shamir; How to
prove yourself: Practical solution to identification and signature
problems; in A. M. Odlyzko, editor, Advances in Cryptology--CRYPTO
'86, volume 263 of Lecture Notes in Computer Science, pages
186-194; Springer Verlag, 1987). The resulting protocol can also be
seen as a digital signature. We denote them SPK{(.alpha.):(.alpha.,
y) .di-elect cons. R}(m), where SPK stands for signature based on a
proof of knowledge, and m is the message that gets signed.
[0037] Let Enc and Dec denote the encryption and decryption
algorithm of some public key encryption scheme. Let P be a public
key of such a scheme and S be the corresponding secret key. Then
e=Enc.sub.P(m) means that e is the encryption of some message m
under public key P. Similarly, d=Dec.sub.S(e) means that d is the
decryption of e using the secret key S, where d=m if e is a valid
encryption of m under P. If Enc is a probabilistic algorithm, then
we write e=Enc.sub.P(m, r), where r contains all the random choices
to be made, i.e., Enc.sub.P(.cndot., .cndot.) becomes a
deterministic algorithm.
[0038] Let Sig and Ver denote signature generation and verification
algorithm of some public key signature scheme. The algorithm Sig
takes the secret key x.sub.s and a message m as input and outputs a
signature .sigma. of m. On input of a message m, a signature
.sigma., and the public key y.sub.s of a signer, the the algorithm
Ver outputs true or false. The following must be satisfied. Ver
.function. ( m , .sigma. , y s ) = { true if .times. .times. Prob
.function. ( .sigma. = Sig .function. ( m , x s ) ) > 0 false
otherwise ##EQU1##
[0039] Furthermore, a signature scheme must be unforgeable. This
means that is must be infeasible to compute a signature of a
message with respect to a public key without knowing the
corresponding secret key.
[0040] Let .parallel. denote the concatenation of strings.
[0041] Now, the basic pseudonym scheme is described. It provides
external PKI (Public Key Infrastructure) assured
non-transferability. The following parties are involved:
[0042] a certification authority O.sub.0=CA, organizations O.sub.1,
O.sub.2, . . . , and a user U. Let P.sub.CA, P.sub.O.sub.1, and
P.sub.O.sub.2 denote the respective public keys of the first three
parties of some signature schemes and S.sub.CA, S.sub.O.sub.1, and
S.sub.O.sub.2 denote the respective secret keys.
[0043] For all protocols we assume that it is aborted as soon as
some verification or check fails.
[0044] Let P.sub.U.sup.PKI use U's public key she has registered
with an external PKI and let S.sub.U.sup.PKI denote the
corresponding secret key.
[0045] Let f.sub.X:{0, 1}*.fwdarw.{0, 1}* denote the (one-way)
function that relates secret and public keys a users chooses with
organization X. For instance,
P.sub.U.sup.PKI=f.sub.PKI(S.sub.U.sup.PKI). This function is part
of the public key of X.
[0046] In the following the public key P.sub.U.sup.O.sup.j a user
has established with some organization O.sub.j is considered the
pseudonym of user U with O.sub.j. In practice, P.sub.U.sup.O.sup.j
might serve as key to a database where O.sub.j stores information
it has collected about U.
[0047] Furthermore, in the following the term "showing of a
credential" is used somewhat misleading to actually mean that the
user proves possession of a credential. In particular, the user
never reveals the credential itself to the party he proves
possession (or "shows") of it.
[0048] The following first method describes how a new user enters
the pseudonym system, i.e., registering with the CA. [0049] 1. User
U chooses a new (random) secret key S.sub.U.sup.CA, computes
P.sub.U.sup.CA=f.sub.CA(S.sub.U.sup.CA), and sends P.sub.U.sup.CA
to CA. [0050] 2. User U sends CA her external public key
P.sub.U.sup.PKI. [0051] 3. CA verifies that P.sub.U.sup.PKI is
indeed registered with the external PKI. (Depending on the actual
use of the pseudonym system, the CA might have to check also thing
other than his identity, whether he has sufficient income,
sufficient assurance.) [0052] 4. U chooses a random r, computes
e.sub.1.sup.CA=Enc.sub.P.sub.U.sub.CA(S.sub.U.sup.PKI, r), and
sends e.sub.1.sup.CA to CA [0053] 5. U proves the CA that the
secret key corresponding to P.sub.U.sup.PKI is encrypted in
e.sub.1.sup.CA under the public key P.sub.U.sup.CA. More formally,
U proves the CA the following PK{(.alpha.,
.beta.):P.sub.U.sup.PKI=f.sub.PKI(.alpha.).LAMBDA.e.sub.1.sup.CA=Enc.sub.-
P.sub.U.sub.A(.alpha., .beta.)}. [0054] 6. The CA computes the
credential on P.sub.U.sup.CA, i.e., computes
c.sub.U.sup.CA=Sig(P.sub.U.sup.CA, S.sub.CA) and sends
c.sub.U.sup.CA to U. [0055] 7. CA publishes (P.sub.U.sup.CA,
c.sub.U.sup.CA, e.sub.1.sup.CA, PKI).
[0056] The following second method shows how a user registers with
an organization O.sub.i and obtains a Credential from said
organisation O.sub.i, whereby i>1, i.e., it covers all cases
except of the initial registering with the CA as described above.
[0057] 1. U chooses a new (random) secret key S.sub.U.sup.O.sup.i,
computes P.sub.U.sup.O.sup.i=f.sub.O.sub.i(S.sub.U.sup.O.sup.i),
and sends P.sub.U.sup.O.sup.i to O.sub.i. [0058] 2. Depending on
the requirements of O.sub.i, U has to prove to O.sub.i that U
possesses credentials by various organizations (including CA).
Assume that U has to prove O.sub.i the possession of a credential
by O.sub.j. If O.sub.i requires U to prove the possession of
credentials from other organizations as well, then following steps
are repeated for each of these organizations/credentials. [0059]
(a) U chooses a random r, computes
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.)=Enc.sub.P.sub.U.sub.O(S.sub.U.sup-
.O.sup.j, r), and sends e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.) to
O.sub.i. [0060] (b) U proves to O.sub.i that it established a
public key with O.sub.j, that the corresponding secret key is
encrypted in e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.) under the
public key P.sub.U.sup.O.sup.i, and that U owns a credential by
O.sub.j (w.r.t. the public key U established with O.sub.j). More
formally, U proves O.sub.i the following PK{(.alpha., .beta.,
.gamma.,
.delta.):.alpha.=f.sub.O.sub.j(.beta.).LAMBDA.e.sub.1.sup.(O.sup.i.sup.,O-
.sup.j.sup.)=Enc.sub.P.sub.U.sub.O(.beta.,
.gamma.).LAMBDA.1=Ver(.alpha., .delta., P.sub.O.sub.j)} [0061] 3.
Finally, O.sub.i computes a credential on P.sub.U.sup.O.sup.i,
i.e., computes c.sub.U.sup.O.sup.i=Sig(P.sub.U.sup.O.sup.i,
S.sub.O.sub.i) and sends c.sub.U.sup.O.sup.i to U. [0062] 4.
O.sub.i publishes the triple (P.sub.U.sup.O.sup.i,
c.sub.U.sup.O.sup.i, e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.),
O.sub.j) for all O.sub.j for which it asked for the possession of
credentials of.
[0063] It should be noted that all the steps of this protocol can
be in fact executed at different times (as long as the order is
kept). If this is done, then U has to send O.sub.i the public key
P.sub.U.sup.O.sup.i before each of the steps to let O.sub.i
resynchronize. Example: first step 1 is executed followed by step
2; At some later time, U sends O.sub.i P.sub.U.sup.O.sup.i again
and they execute step 2 again, this time for credentials from
different organization(s); finally step 3 is executed.
[0064] The encryptions e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.)
ensure non-transferability: this is because in order to transfer a
credential to another user U.sup.1, user U needs to reveal
S.sub.U.sup.O.sup.i. Knowing this value, U.sup.1 can compute
P.sub.U.sup.O.sup.i, lookup e.sub.1.sup.O.sup.i.sup.,O.sup.j,
decrypt it, and obtain S.sub.U.sup.O.sup.j. Repeating this process,
U will finally be able to decrypt e.sub.1.sup.CA and obtain the
valuable external secret key of U.
[0065] The triple (P.sub.U.sup.O.sup.i, c.sub.U.sup.O.sup.i,
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.)) can either be published by
the organizations themselves or centrally at one place for the hole
pseudonym system, e.g., the CA could maintain such a list (ordered
by P.sub.U.sup.O.sup.i).
[0066] Now, the same user shows a credential to a verifier V
according to the following third method. In this method "multiple
show" of the credential is possible.
[0067] In order to get access to some service, U has to show
possession of a credential by the organization the verifier
(service provider) V is associated with. Assume that U has to prove
V the possession of a credential by O.sub.j. [0068] 1. U proves to
V that it established a public key with O.sub.j, that U owns a
credential by O.sub.j on that public key, and that U actually knows
the corresponding secret key. More formally, U proves V the
following PK{(.alpha., .beta.,
.delta.):.alpha.=f.sub.O.sub.j(.beta.).LAMBDA.1=Ver(.alpha.,
.delta., P.sub.O.sub.j)}
[0069] In case V requires that U proves possession of credentials
from several organizations, then V has to be treated like an
organization. That is U and V follow the second method (including
the publishing of the encryptions), with the exception that V does
not issue a credential, i.e., step 3 is not executed. Note that if
this is done, U has established a public key (pseudonym) with
V.
[0070] It has to be acknowledged that in order to be fully
anonymous, each time U wants to access the service provided by V he
needs to engage again in the above protocol or according to the
second method without step 3.
[0071] This following describes the additions to the methods from
above to achieve all-or-nothing transferability.
[0072] No changes have to be applied in order to enter the
pseudonym system, i.e., to register with the CA.
[0073] In order to register with O.sub.i and to obtaining a
credential from O.sub.i, i>1, the steps 2 and 4 of the second
method need to be adapted. That is, step 2a and 2b are as follows.
[0074] 2a'. U chooses a random r.sub.1 and r.sub.2, computes the
two encryptions
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.)=Enc.sub.P.sub.U.sub.O(S.sub.U.sup-
.O.sup.j, r.sub.1) and
e.sub.2.sup.(O.sup.i.sup.,O.sup.j.sup.)=Enc.sub.P.sub.U.sub.O(S.sub.U.sup-
.O.sup.i, r.sub.2), and sends
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.) and
e.sub.2.sup.(O.sup.i.sup.,O.sup.j.sup.) to O.sub.i. [0075] 2b'. U
proves to O.sub.i that it established a public key with O.sub.j,
that the corresponding secret key is encrypted in
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.) under the public key
P.sub.U.sup.O.sup.i, and that U owns a credential by O.sub.j
(w.r.t. the public key U established with O.sub.j). Furthermore, U
also proves that e.sub.2.sup.(O.sup.i.sup.,O.sup.j.sup.) is an
encryption of the secret key corresponding to P.sub.U.sup.O.sup.i
under the public key U has established with O.sub.j. More formally,
U proves O.sub.i the following PK{(.alpha., .beta., .gamma.,
.delta., .epsilon.,
.nu.):.alpha.=f.sub.O.sub.j(.beta.).LAMBDA.e.sub.1.sup.(O.sup.i.sup.,O.su-
p.j.sup.)=Enc.sub.P.sub.U.sub.O(.beta.,
.gamma.).LAMBDA.1=Ver(.alpha., .delta.,
P.sub.O.sub.j).LAMBDA.P.sub.U.sup.O.sup.i=f.sub.O.sub.j(.epsilon-
.).LAMBDA.e.sub.2.sup.(O.sup.i.sup.,O.sup.j.sup.)=Enc.sub..alpha.(.epsilon-
., .nu.)} Furthermore, step 4 becomes [0076] 4'. O.sub.i publishes
the list (P.sub.U.sup.O.sup.i, c.sub.U.sup.O.sup.i,
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.),
e.sub.2.sup.(O.sup.i.sup.,O.sup.j.sup.), O.sub.j) for all O.sub.j
for which it asked for the possession of credentials of.
[0077] The remark about publishing the encryption provided to
O.sub.i by U made above applies here as well.
[0078] The encryptions e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.),
e.sub.2.sup.(O.sup.i.sup.,O.sup.j.sup.) ensure non-transferability:
recall that to transfer a credential to another user U', user U
needs to reveal S.sub.U.sup.O.sup.i. Knowing this value, U' can
compute P.sub.U.sup.O.sup.i, lookup
e.sub.1.sup.O.sup.i.sup.,O.sup.j, decrypt it, and obtain
S.sub.U.sup.O.sup.j. Repeating this process, U will finally be able
get S.sub.U.sup.CA, decrypt e.sub.1.sup.CA and obtain the valuable
external secret key of U. Now, as U' known S.sub.U.sup.CA, he can
also decrypt all e.sub.2.sup.(O.sup.i.sup.,CA) and get the secret
keys U chose with any organization U had to prove possession of a
credential by CA. Now, if U' knows the secret key U chose with
organization O.sub.j and U needed to prove O.sub.i possession of a
credential by O.sub.j, user U' can get
e.sub.2.sup.(O.sup.i.sup.,O.sup.j.sup.), decrypt it, and learn the
secret key U chose with O.sub.i. Repeating these process, U' will
eventually get to know all secret keys user U chose and use all the
credentials of user U. Thus, if a user transfers one credential to
another user, he effectively transfers all of them.
[0079] No changes have to be applied to the third method in order
to show a credential to a Verifier V under "multiple show".
[0080] In another refinement the above methods provide
all-or-nothing non-transferability.
[0081] To enter the pseudonym system and to register with the CA,
the steps 4, 5, and 7 can be omitted.
[0082] In order to register with O.sub.i and to obtain a credential
from O.sub.i, i>1, the same modification to the first method as
previously explained have to be made.
[0083] The same method as before can be used to show a credential
to a verifier V under "multiple show".
[0084] In another refinement the above methods provide
revokability. Local anonymity revocation means that whenever U
proved possession of a credential by O.sub.j to a party X, it is
possible to some third party (revocation manager) to retrieve the
pseudonym/public key U has established with O.sub.j from the
information X obtained from U.
[0085] In the following m.sub.R be the text stating under which
conditions the anonymity shall be revoked. This text can be unique
to each showing of a credential. Is it understood that whenever the
revocation manager is asked for revocation he will not reveal the
pseudonym if the conditions stated in m.sub.R are not met For
instance, if m.sub.R states that revocation requires that the
person that proved the possession of a credential needs to be
involved in some crime, then the revocation manager will not revoke
the anonymity until the requesting party can convince the
revocation manager that the user at hand was indeed involved in
some crime (c.f. the car accident example). In order to add local
revokability, one has to apply the following changes to the
respective methods. Of course, local revokability can also be added
after other features were added.
[0086] To allow local revokability, each organization has to
nominate a revocation manager who generates a public and secret key
of a non-malleable encryption scheme, i.e., the revocation manager
R.sub.i responsible for organization O.sub.i generates
S.sub.R.sub.i and P.sub.R.sub.i and publishes P.sub.R.sub.i.
[0087] Entering the pseudonym system and registering with the CA
works without further changes to the respective protocol.
[0088] For registering with O.sub.i and obtaining a credential from
O.sub.i, i>1, the step 2 has to be adapted. That is, steps 2a
and 2b are as follows. Note that it can be decided separately for
each execution of step 2 whether local revokability is required or
not, i.e., whether the step is executed with the additions below,
or not. [0089] 2a''. U chooses a random r.sub.1 and r.sub.3,
computes the two encryptions
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.)=Enc.sub.P.sub.U.sub.O(S.sub.U.sup-
.O.sup.j, r.sub.1), and
v.sup.(O.sup.i.sup.,R.sup.j.sup.)=Enc.sub.P.sub.R(P.sub.U.sup.O.sup.j.par-
allel.m.sub.R, r.sub.3) and sends
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.) and
v.sup.(O.sup.i.sup.,R.sup.j.sup.) to O.sub.i. [0090] 2b''. U proves
to O.sub.i that it established a public key with O.sub.j, that the
corresponding secret key is encrypted in
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.) under the public key
P.sub.U.sup.O.sup.i, and that U owns a credential by O.sub.j
(w.r.t. the public key U established with O.sub.j). Furthermore, U
also proves that v.sup.(O.sup.i.sup.,O.sup.j.sup.) is an encryption
of the public key U has established with O.sub.j under the
O.sub.j's revocation manager's public key P.sub.R.sub.j, More
formally, U proves O.sub.i the following PK{(.alpha., .beta.,
.gamma., .delta., .epsilon.,
.nu.):.alpha.=f.sub.O.sub.j(.beta.).LAMBDA.e.sub.1.sup.(O.sup.i.sup.,O.su-
p.j.sup.)=Enc.sub.P.sub.U.sub.O(.beta.,
.gamma.).LAMBDA.1=Ver(.alpha., .delta.,
P.sub.O.sub.j).LAMBDA.v.sup.(O.sup.i.sup.,R.sup.j.sup.)=Enc.sub.-
P.sub.R(.alpha..parallel.m.sub.R, .nu.)}
[0091] Note that here we assumed that U and O.sub.i both trust the
revocation manager R.sub.j. However, it would also be possible that
they agree upon a different revocation manager.
[0092] Showing a credential to a verifier V under "Multiple show"
works as follows: [0093] 0''. U chooses a random r.sub.3, computes
the encryption
u.sup.(V,R.sup.i.sup.)=Enc.sub.P.sub.R(P.sub.U.sup.O.sup.i.parallel.m.sub-
.R, r.sub.3) and sends u.sup.(V,R.sup.i.sup.) to V. [0094] 1''. U
proves to V that it established a public key with O.sub.j, that U
owns a credential by O.sub.j on that public key, and that U
actually known the corresponding secret key. Furthermore, U also
proves V that u.sup.(V,R.sup.i.sup.) More formally, U proves V the
following PK{(.alpha., .beta., .delta.,
.gamma.):.alpha.=f.sub.O.sub.j(.beta.).LAMBDA.1=Ver(.alpha.,
.delta.,
P.sub.O.sub.j).LAMBDA.u.sup.(O.sup.i.sup.,R.sup.j.sup.)=Enc.sub.P.sub.R(.-
alpha..parallel.m.sub.R, .gamma.)}
[0095] With respect to showing credential of several organizations
the same remark applies as afore-mentioned.
[0096] Global revokability is very similar to local revokability.
Global revokability means basically showing possession of a
CA-credential with (local) revokability as described in the
previous section because when the pseudonym under which a users is
known to the CA is revealed, the CA can determine the user's real
identity.
[0097] In case proving possession of a credential to a verifier V
needs global revokability, a user U need to show V not only the
credential of the associated organization but also the one of the
CA. Thus, U and V need to execute the second method (with the
extensions of the previous section) up to where credential are
granted. As mentioned earlier, instead of publishing the
encryptions obtained from U during the protocol's execution, V
could send them to its associated organization for publication.
[0098] Note: In practice, when requiring global revokability for
proving possession of a credential to a verifier V, one would
probably also want local revokability. If this is the case, it
would be easier to just have local revokability for proving
possession of a credential to a verifier V and then ask for global
revokability when the U registers with the organization associated
with V.
[0099] The methods as described above can be used as "multi-show"
credentials. However, the methods can be refined in a way to
function as "one-show" credentials. A one-show credential is
credential such that when a users shows it more than once then
these different showings can be linked. (Note that although these
showing can be linked, the pseudonym associated with the credential
is not revealed. Hence anonymity is maintained.)
[0100] One-show credentials can be implemented in a similar manner
as multi-show credential, but by having some extra information
revealed about the credential such that using the credential more
than once can be detected. One method to implement them is that
each organization X publishes a suitable one-way function
{circumflex over (f)}.sub.X(.cndot.). This function must have the
property that, given {circumflex over (f)}.sub.X(s) given
f.sub.X(s') it is hard to decide whether s=s'.
[0101] Issuing a one-show credential is not different from issuing
ordinary credentials. Therefore, the protocol for entering the
pseudonym system and registering with the CA remains unchanged.
However, the CA needs of course to publish a function {circumflex
over (f)}.sub.CA as part of its public key and state that all
credentials issued w.r.t. this public key are one-show
credentials.
[0102] The step 2 of the second method has to be adapted to
register with O.sub.i and to obtaining a credential from O.sub.i,
i>1. That is, steps 2a and 2b are as follows. Note that it can
be decided separately for each execution of step 2 whether local
revokability is required or not, i.e., whether the step is executed
with the additions below, or not. [0103] 2a'''. U chooses a random
r, computes
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.)=Enc.sub.P.sub.U.sub.O(S.sub.U.sup-
.O.sup.j, r) and {circumflex over
(P)}.sub.U.sup.O.sup.j={circumflex over
(f)}.sub.O.sub.j(S.sub.U.sup.O.sup.j), and sends
e.sub.1.sup.O.sup.j and {circumflex over (P)}.sub.U.sup.O.sup.j to
O.sub.i. [0104] 2b'''. U proves to O.sub.i that it established a
public key with O.sub.j, that the corresponding secret key is
encrypted in e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.) under the
public key P.sub.U.sup.O.sup.i, and that U owns a credential by
O.sub.j (w.r.t. the public key U established with O.sub.i).
Furthermore, U also proves that the pre-image of {circumflex over
(P)}.sub.U.sup.O.sup.j under under {circumflex over
(f)}.sub.O.sub.j is the secret key of the public key U has
established with O.sub.j. More formally, U proves O.sub.i the
following PK{(.alpha., .beta., .gamma., .delta., .epsilon.,
.nu.):.alpha.=f.sub.O.sub.j(.beta.).LAMBDA.e.sub.1.sup.(O.sup.i.sup.,O.su-
p.j.sup.)=Enc.sub.P.sub.U.sub.O(.beta.,
.gamma.).LAMBDA.1=Ver(.alpha., .delta.,
P.sub.O.sub.j).LAMBDA.{circumflex over
(P)}.sub.U.sup.O.sup.j={circumflex over
(f)}.sub.O.sub.j(.beta.)}
[0105] The organization O.sub.i can now tell whether some user
showed a credential twice by checking whether it has seen
{circumflex over (P)}.sub.U.sup.O.sup.j before. This might for
instance be the case is a user wants to register twice with the
same organizations.
[0106] The third method for proving possession to a verifier needs
to be adapted as follows for one-show credentials. [0107] 0'''.
(new) U computes {circumflex over
(P)}.sub.U.sup.O.sup.j={circumflex over
(f)}.sub.O.sub.j(S.sub.U.sup.O.sup.j) and sends {circumflex over
(P)}.sub.U.sup.O.sup.j to V. [0108] 1'''. U proves to V that it
established a public key with O.sub.j, that U owns a credential by
O.sub.j on that public key, and that U actually known the
corresponding secret key. Furthermore, U also proves that the
pre-image of {circumflex over (P)}.sub.U.sup.O.sup.j under
{circumflex over (f)}.sub.O.sub.j is the secret key of the public
key U has established with O.sub.j. More formally U proves V the
following PK{(.alpha., .beta., .delta.,
.gamma.):.alpha.=f.sub.O.sub.j(.beta.).LAMBDA.1=Ver(.alpha.,
.delta., P.sub.O.sub.j).LAMBDA.{circumflex over
(P)}.sub.U.sup.O.sup.j={circumflex over
(f)}.sub.O.sub.j(.beta.)}
[0109] The verifier V can now tell whether some user showed a
credential twice by checking whether it has seen {circumflex over
(P)}.sub.U.sup.O.sup.j before.
[0110] If a user wants or needs to obtain a second one-show
credential from some organization, the two parties need of course
to run the whole issuing protocol again, e.g., the user needs to
chose a different P.sub.U.sup.O.sup.i.
[0111] We can of course combine one-show credentials with the local
and global revocation mechanism described above.
[0112] In principle a one-show certificate can also be used as a
multi-show credential as they are basically the same credential,
only that some additional information is revealed if it should be
one-show. It is up to the system, whether credentials issued by
organization X are one-show only as soon some as the function
{circumflex over (f)}.sub.X is part of its public key. In practice,
some policy stating when a credential is one-show and when
multi-show would probably be part of the organizations' public
keys.
[0113] A further refinement allows to have a build-in revocation.
This kind of credentials are an extension of the one-show
credentials described above in that provide build-in (local)
revocation: if a users proves possession of the the same credential
more than once (or, in general, k times), then his pseudonym with
the issuing organization gets revealed directly, i.e., without the
help of any revocation manager. However, if the users proves
possession of the same credential only once (or less than k times),
then the user remains anonymous. Note that this is different from
the case where we have one-time credentials with local revocation.
(In case the user is allowed prove possession of a credential up to
k, these different showings are linkeable.)
[0114] In the following we describe the system such that showing a
credential more than once reveals the user's identity. Similarly as
described above, each organization X publishes two suitable one-way
functions {circumflex over (f)}.sub.X(.cndot.):{0, 1}*.fwdarw.{0,
1}* and {circumflex over (f)}.sub.X:{0, 1}*.times.{0,
1}*.fwdarw.{0, 1}*. Furthermore, we require the function
{circumflex over (f)}.sub.X to be homomorphic, i.e., that there are
operations * and .sym. such that {circumflex over
(f)}.sub.X(a)*{circumflex over (f)}.sub.X(b)={circumflex over
(f)}.sub.X(a.sym.b) holds for all a and b. This also defines
"multiplication" with a scalar c: {circumflex over
(f)}.sub.X(ca)={circumflex over (f)}.sub.X(a).sup.c. Furthermore,
{circumflex over (f)}.sub.X must have the property that, given
{circumflex over (f)}.sub.X(s.sub.1), {circumflex over
(f)}.sub.X(s.sub.2), {circumflex over (f)}.sub.X(s.sub.3),
{circumflex over (f)}.sub.X(s.sub.1'), and {circumflex over
(f)}.sub.X(s.sub.2', s.sub.3') it is hard to decide whether any of
the relations s.sub.1=s.sub.1', s.sub.2=s.sub.2' and
s.sub.3=s.sub.3' hold. (All these functions can be realized under
the discrete logarithm or the RSA assumption.)
[0115] In the following the changes are described in case that the
CA issues one-show credentials. Steps 1 and 6 of the first protocol
needs to be modified as follows. [0116] 1''''. U chooses new
(random) secret keys S.sub.U.sup.CA, {tilde over
(S')}.sub.U.sup.CA, {tilde over (S'')}.sub.U.sup.CA, computes the
two public keys P.sub.U.sup.CA=f.sub.CA(S.sub.U.sup.CA) and {tilde
over (P)}.sub.U.sup.CA= f.sub.CA({tilde over (S')}.sub.U.sup.CA,
{tilde over (S'')}.sub.U.sup.CA), and sends P.sub.U.sup.CA and
{tilde over (P)}.sub.U.sup.CA to CA. [0117] 6''''. The CA computes
the credential on P.sub.U.sup.CA, {tilde over (P)}.sub.U.sup.CA,
i.e., computes c.sub.U.sup.CA=Sig(P.sub.U.sup.CA.parallel.{tilde
over (P)}.sub.U.sup.CA, P.sub.CA) and sends c.sub.U.sup.CA to
U.
[0118] In the following, it is assumed (P.sub.U.sup.X, {tilde over
(P)}.sub.U.sup.X) as being one public key, i.e., the one that user
U has established with organization X.
[0119] Now, it is described how a one-show credential with build-in
revocation is issued by organization O.sub.i and we assume that
O.sub.i wants to see a one-show credential with build-in revocation
issued by O.sub.j. From this description is should be clear how to
issue such a credential when requiring to see an ordinary
credential (or a one-show credential without built-in revocation)
as well as how to issue ordinary credentials (or a one-show
credential without built-in revocation) when requiring to see a
credential with build-in revocation. Almost all steps of the second
method are adapted. [0120] 1''''. U chooses a new (random) secret
keys S.sub.U.sup.O.sup.i, {tilde over (S')}.sub.U.sup.O.sup.i,
{tilde over (S'')}.sub.U.sup.O.sup.i, computes the two public keys
P.sub.U.sup.O.sup.i=f.sub.O.sub.i(S.sub.U.sup.O.sup.i) and {tilde
over (P)}.sub.U.sup.O.sup.i={tilde over (f)}.sub.O.sub.i({tilde
over (S')}.sub.U.sup.O.sub.i, {tilde over
(S'')}.sub.U.sup.O.sup.i), and sends P.sub.U.sup.O.sup.i and {tilde
over (P)}.sub.U.sup.O.sup.i to O.sub.i. [0121] 2''''. Depending on
the requirements of O.sub.i, user U has to prove to O.sub.i that U
possesses credentials by various organizations (including CA).
Assume that U has to prove O.sub.i the possession of a one-show
credential with built-in revocation by O.sub.j. If O.sub.i requires
U to prove the possession of credential from other organizations as
well, the following steps are repeated for each of these
organizations/credentials. [0122] (a) U chooses a random r,
computes
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.)=Enc.sub.P.sub.U.sub.O(S.sub.U.sup-
.O.sup.j.parallel.{tilde over
(S')}.sub.U.sup.O.sup.i.parallel.{tilde over
(S'')}.sub.U.sup.O.sup.i, r), {circumflex over
(P')}.sub.U.sup.O.sup.j={circumflex over (f)}.sub.O.sub.j({tilde
over (S')}.sub.U.sup.O.sup.j), and {circumflex over
(P'')}.sub.U.sup.O.sup.j={circumflex over (f)}.sub.O.sub.j({tilde
over (S'')}.sub.U.sup.O.sup.j), and sends e.sub.1.sup.O.sup.j,
{circumflex over (P')}.sub.U.sup.O.sup.j, and {circumflex over
(P'')}.sub.U.sup.O.sup.j to O.sub.i. [0123] (b) U proves to O.sub.i
that it established a public key with O.sub.j, that the
corresponding secret keys are encrypted in
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.) under the public key
P.sub.U.sup.O.sup.i, that the secret key of the second part of the
public key established with O.sub.j are the pre-images of
{circumflex over (P')}.sub.U.sup.O.sup.j and {circumflex over
(P'')}.sub.U.sup.O.sup.j under {circumflex over (f)}.sub.O.sub.j,
and that U owns a credential by O.sub.j (w.r.t. the public keys U
established with O.sub.j). More formally, U proves O.sub.i the
following PK{(.alpha., .beta., .gamma., .delta., .delta.,
.epsilon.,
.phi.):.alpha.=f.sub.O.sub.j(.beta.).LAMBDA..gamma.={tilde over
(f)}.sub.O.sub.j(.delta.,
.epsilon.).LAMBDA.e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.)=Enc.sub.P.sub.U-
.sub.O(.beta..parallel..delta..parallel..epsilon.,
.xi.).LAMBDA.1=Ver(.alpha..parallel..gamma., .phi.,
P.sub.O.sub.j).LAMBDA.{circumflex over
(P')}.sub.U.sup.O.sup.j={circumflex over
(f)}.sub.O.sub.j(.delta.).LAMBDA.{circumflex over
(P'')}.sub.U.sup.O.sup.j={circumflex over
(f)}.sub.O.sub.j(.epsilon.)} [0124] (c) (new step) O.sub.i chooses
a random w .di-elect cons. {0, 1}.sup.l, w.noteq.0, where l is a
suitably defined security parameter, and sends w to U. [0125] (d)
(new step) U checks whether w.noteq.0 and answers with z={tilde
over (S')}.sub.U.sup.O.sup.j.sym.(w{tilde over
(S')}.sub.U.sup.O.sup.j) [0126] (e) (new step) O.sub.i checks
whether {circumflex over (f)}.sub.O.sub.j(z)={circumflex over
(P')}.sub.U.sup.O.sup.j*({circumflex over
(P')}.sub.U.sup.O.sup.j).sup.w [0127] 3''''. Finally, O.sub.i
computes a credential on P.sub.U.sup.O.sup.i, i.e., computes
c.sub.U.sup.O.sup.i=Sig(P.sub.U.sup.O.sup.i.parallel.{tilde over
(P)}.sub.U.sup.O.sup.i, S.sub.O.sub.i) and sends
c.sub.U.sup.O.sup.i to U. [0128] 4''''. O.sub.i publishes the list
(P.sub.U.sup.O.sup.i, c.sub.U.sup.O.sup.i,
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.), O.sub.j for which it asked
for the possession of credentials of.
[0129] When a users show the same credential more than once,
O.sub.i will with high probability have chosen different w's and
hence U will have replied with different z's. Given two different
pairs of w and z, one gets two linear equations with the user's
secrets {tilde over (S')}.sub.U.sup.O.sup.i and {tilde over
(S'')}.sub.U.sup.O.sup.i as unknowns. These secrets can be
retrieved by solving the equations and thus {tilde over
(P)}.sub.U.sup.O.sup.i computed which will identify the user.
[0130] The third protocol for proving possession to a verifier
needs to be adapted as follows for one-show credentials with
built-in revocation. [0131] 0''''. (new) U computes {circumflex
over (P)}'.sub.U.sup.O.sup.j={circumflex over (f)}.sub.O.sub.j(
S'.sub.U.sup.O.sup.j) {circumflex over
(P)}''.sub.U.sup.O.sup.i={circumflex over (f)}.sub.O.sub.j(
S''.sub.U.sup.O.sup.j) and sends {circumflex over
(P)}'.sub.U.sup.O.sup.j) and sends {circumflex over
(P)}'.sub.U.sup.O.sup.j and {circumflex over
(P)}''.sub.U.sup.O.sup.j to V. [0132] 1''''. U proves to V that it
established a public key with O.sub.j, that U owns a credential by
O.sub.j on that public key, and that U actually known the
corresponding secret keys. Furthermore, U proves to V that the
secret key of the second part of the public key established with
O.sub.j are the pre-images of {circumflex over
(P')}.sub.U.sup.O.sup.j and {circumflex over
(P'')}.sub.U.sup.O.sup.j under {circumflex over (f)}.sub.O.sub.j.
More formally, U proves V the following PK{(.alpha., .beta.,
.gamma., .delta., .epsilon., .xi.,
.phi.):.alpha.=f.sub.O.sub.j(.beta.).LAMBDA..gamma.={circumflex
over (f)}.sub.O.sub.j(.delta., 68
).LAMBDA.1=Ver(.alpha..parallel..gamma., .phi.,
P.sub.O.sub.j).LAMBDA.{circumflex over
(P')}.sub.U.sup.O.sup.j={circumflex over
(f)}.sub.O.sub.j(.delta.).LAMBDA.{circumflex over
(P'')}.sub.U.sup.O.sup.j={circumflex over
(f)}.sub.O.sub.j(.epsilon.).LAMBDA.}
[0133] The verifier V can now tell whether some user showed a
credential twice by checking whether it has seen {circumflex over
(P)}.sub.U.sup.O.sup.j before and if this was the case compute the
user's pseudonym.
[0134] Allowing a user to prove possession of a pseudonym up to k
times can be done by letting the user choose k+1 additional secret
keys (now 2) and then provide the image of all these key under
{circumflex over (f)}.sub.X and prove the according statement in
step 2b''. The next steps of 2''' would need to be adapted.
[0135] As described in this section proving possession of the same
credential more than the allowed number of times reveals only some
of the user's secret key of the respective pseudonym. However, the
system could be modified such that all the user's secret key of the
respective pseudonym get revealed. Depending on the mechanism
chosen for the non-transferability, this would mean that also the
user's external secret key or all the secret keys he choose within
the system. This would presents quite a strong initiative for the
user not to show a credential more than the allowed number of
times.
[0136] It is acknowledged that the feature in described above can
easily be combined with other features.
[0137] Now, it is explained how one-show credentials could be used
and provide the changes to the methods as described above such that
our system can by applied for these usages of one-show
credentials.
[0138] One-show credentials can be used for several reasons.
[0139] First, it can be used for tracking the the usage of some
credential, e.g., to detect when the same credential is used with
any verifier or to detect when the same credential is used with the
same verifier, i.e., uses of the same credential with different
verifiers cannot be linked. Second, it can be used for allowing the
user to use a credential only once. This can be realized with the
methods having the one-show credential ability added to it. In
order to track the usage of a user's credential, all data collected
when some user proves possession of a credential by an
organization, say O.sub.j, needs to be send to some central place,
e.g., organization O.sub.j.
[0140] This can be realized with the methods having the one-show
credential ability added with slight modifications applied. Now,
showings of the same credential to different entities must no
longer be linkeable. This can be achieved by using a different
one-way function {circumflex over (f)}.sub.X for each entity
possession of the credential is proved to rather than that it is
specific for the issuer of the credential. To assure that showings
to different entity are indeed not linkeable, the functions
{circumflex over (f)}.sub.X must satisfy the following. Let
{circumflex over (f)}.sub.X.sub.1, . . . , {circumflex over
(f)}.sub.X.sub.n be such functions chosen be the entities X.sub.1
through X.sub.n, and let O.sub.j be the issuer of the credential.
Then, given {circumflex over (f)}.sub.X.sub.1(s.sub.1), . . . ,
{circumflex over (f)}.sub.X.sub.n(s.sub.n), and f.sub.O.sub.j(s')
it must be hard to decide whether s'=s.sub.i for any i in 1, . . .
, n and whether s.sub.i=s.sub.k for any i and k.noteq.i in 1, . . .
, n.
[0141] In case a user is not allowed to show a credential more than
once (or, in general k times), e.g., if the credential represent
electronic money, there are two ways to prevent a user from doing
so. Both ways have in common that a user stays fully anonymous if
he shows a credential only once (or less than k times). Both these
ways are also known "double-spending" prevention mechanisms in
digital money schemes (e.g., S. Brands; An efficient off-line
electronic cash system based on the representation problem;
Technical Report CS-R9323, CWI, April 1993 and D. Chaum, A. Fiat,
and M. Naor; Untraceable electronic cash; In S. Goldwasser, editor,
Advances in Cryptology--CRYPTO '88, volume 403 of Lecture Notes in
Computer Science, pages 319-327; Springer Verlag, 1990).
[0142] In an on-line use, some entity keeps track of whether a
credential was used already or not. This entity could either be the
organization that issued the credential or some independent central
party (possibly a different one for each organization issuing
credentials). For this, the method as described above for one-show
credentials can be used, with the following modification to the
methods 2 and 3: after the organization O.sub.i, resp. the verifier
V, have obtained {circumflex over (P)}.sub.U.sup.O.sup.j, they send
it to the entity keeping track of whether a credentials has been
used. If this entity finds {circumflex over (P)}.sub.U.sup.O.sup.j
already in its database, it tells O.sub.i, resp. V, that the
credential was already used and is thus invalid (or, in general
used more than the allowed number of times); otherwise it adds
{circumflex over (P)}.sub.U.sup.O.sup.j to its database (and/or
increases the related counter) and tells O.sub.i, resp. V. Hence,
O.sub.i, resp. the verifier V will only accept the showing of a
credential if the track-keeping entity says that the credential is
still valid. Thus usage of a credential more than the allowed
number of times is prevented. Note that the users' anonymity is
still guaranteed.
[0143] In an off-line use, the usage of a credential more that the
allowed number of times is not prevented but only detected. To
disencourage users from over-using a credential, over-usage gets
punished. For this the identity/pseudonym of a culprit must be
known. However, the system should nevertheless protect innocent
users. This can be achieved by using one-show credentials with
build-in revocation as described in above. To detect the over-usage
of a credential in cases it gets used with different
verifiers/organizations, there needs to be an entity that collects
all the transcripts of all showing these credentials similar as
above, with the difference that now this entity needs not to be
on-line during the showing credentials: it suffices if the
verifiers/organizations sent the transcripts to this entity, e.g.,
once a day. Upon receiving this transcripts, this entity can check
whether a credential was used more than the allowed number of
times, and if this is the case, retrieve the culprits
identity/pseudonym as described in above, and take according
punishment measures.
[0144] In another refinement of the methods according to the
present invention, the methods provide the ability to have a
designated verifier. This is realized with a special kind of
credentials having the property that a user can show these
credentials only to a particular verifier. Moreover, the user
cannot convince anyone else that the credential is valid.
[0145] For this to work, we need two things. First, each issuing
organization published a homomorphic function {hacek over
(f)}.sub.X(.cndot.,.cndot.). Second, the designated verifier (a
ordinary verifier V or an organization O.sub.i) must have made
available a public key of an homomorphic public key encryption
scheme (e.g., P. Paillier, Public-key cryptosystems based on
composite residuosity classes; in J. Stern, editor, Advances in
Cryptology--EUROCRYPT '99, volume 1592 of Lecture Notes in Computer
Science, pages 223-239; Springer Verlag, 1999).
[0146] Let E.sub.V.sub.i and D.sub.V.sub.i (resp, E.sub.O.sub.i and
D.sub.O.sub.i) denote the public and secret keys of the verifier
(resp., organization) of such an encryption scheme. Thus due to the
homomorphic property we will have that, e.g.
c=Dec.sub.D.sub.V(Enc.sub.E.sub.V(a, r.sub.1)*Enc.sub.E.sub.V(b,
r.sub.2))=a.sym.b. Furthermore, we require that the homomorphic
property of this encryption scheme is "compatible" with the
homomorphic property of function {hacek over (f)}.sub.X( ). That
is, for the above example, we require that {hacek over
(f)}.sub.X(c)={hacek over (f)}.sub.X(a)*{hacek over
(f)}.sub.X(b).
[0147] Let V.sub.k be the designated verifier (which could be an
ordinary verifier or an organization). In order to enter the
pseudonym system, Step 1 of the first method needs to be divided
into several steps: [0148] 1''''' (a) U chooses new (random) secret
keys S.sub.U.sup.CA and {hacek over (S)}.sub.U.sup.CA, computes
{hacek over (P)}={hacek over (f)}.sub.CA(S.sub.U.sup.CA, {hacek
over (S)}.sub.U.sup.CA) and
P.sub.U.sup.CA=f.sub.CA(S.sub.U.sup.CA), and sends {hacek over (P)}
and P.sub.U.sup.CA to CA, and proves CA the following PK{(.alpha.,
.beta.):P.sub.U.sup.CA=f.sub.CA(.alpha.).LAMBDA.{hacek over
(P)}={hacek over (f)}.sub.CA(.alpha., .beta.)} [0149] (b) CA
chooses a random {hacek over (S)} and an r, computes {hacek over
(P)}.sub.U.sup.CA={hacek over (P)}*{hacek over (f)}.sub.CA(0,
{hacek over (S)}) and {hacek over (z)}.sub.U.sup.(CA,
V.sup.k.sup.)=Enc.sub.E.sub.V({hacek over (S)}, r), sends
P.sub.U.sup.CA and {hacek over (z)}.sub.U.sup.(CA,V.sup.k.sup.) to
U, and proves U the following PK{(.alpha., .beta.):{hacek over
(P)}.sub.U.sup.CA={hacek over (P)}*{hacek over (f)}.sub.CA(0,
.alpha.).LAMBDA.{hacek over
(.sub.U.sup.(CA,V.sup.k.sup.)=Enc.sub.E.sub.V(.alpha.,
.beta.)}.
[0150] At the end of the protocol, we have P.sub.U.sup.CA={hacek
over (f)}.sub.CA(S.sub.U.sup.CA, {hacek over
(S)}.sub.U.sup.CA.sym.S), where S is encrypted in {hacek over
(z)}.sub.U.sup.(CA, V.sup.k.sup.) under the encryption public key
of the verifier V.sub.k. Thus U does not know the pre-image of
{hacek over (P)}.sub.U.sup.CA under {hacek over (f)}.sub.CA.
[0151] This section describes how a designated verifier credential
is issued by organization O.sub.i. We assume that O.sub.i requires
the possession of a a designated verifier credential issued by
O.sub.j, where O.sub.i is the designated verifier. From this
description is should be clear how to issue such credential when
requiring another type of credential as well as how to issue other
types of credentials when requiring a designated verifier
credential.
[0152] Almost all steps of the second method have to be adapted.
[0153] 1'''''. (a) U chooses new (random) secret keys
S.sub.U.sup.O.sup.i and {hacek over (S)}.sub.U.sup.O.sup.i,
computes {hacek over (P)}={hacek over
(f)}.sub.O.sub.i(S.sub.U.sup.O.sup.i, {hacek over
(S)}.sub.U.sup.O.sup.i) and
P.sub.U.sup.O.sup.i=f.sub.O.sub.i(S.sub.U.sup.O.sup.i), sends
{hacek over (P)} and P.sub.U.sup.O.sup.i to O.sub.i, and proves
O.sub.i the following PK{(.alpha.,
.beta.):P.sub.U.sup.O.sup.i=f.sub.O.sub.i(.alpha.).LAMBDA.{hacek
over (P)}={hacek over (f)}.sub.O.sub.i(.alpha., .beta.)} [0154] (b)
O.sub.i chooses a random {hacek over (S)} and an r, computes {hacek
over (P)}.sub.U.sup.O.sup.i={hacek over (P)}*{hacek over
(f)}.sub.O.sub.i(0, {hacek over (S)}) and {hacek over
(z)}.sub.U.sup.(O.sup.i.sup.,V.sup.k.sup.)=Enc.sub.E.sub.v({hacek
over (S)}, r), sends P.sub.U.sup.O.sup.i and {hacek over
(z)}.sub.U.sup.(O.sup.i.sup.,V.sup.k.sup.) to U, and proves U the
following PK{(.alpha., .beta.):{hacek over
(P)}.sub.U.sup.O.sup.i={hacek over (P)}*{hacek over
(f)}.sub.O.sub.i(0, .alpha.).LAMBDA.{hacek over
(z)}.sub.U.sup.(O.sup.i.sup.,V.sup.k.sup.)=Enc.sub.E.sub.V(.alpha.,
.beta.)}. [0155] 2'''''. Depending on the requirements of O.sub.i,
user U has to prove to O.sub.i that U possesses credentials by
various organizations (including CA). Assume that U has to prove
O.sub.i the possession of a designated verifier credential by
O.sub.j. If O.sub.i requires U to prove the possession of
credential from other organizations as well, the following steps
are repeated for each of these organizations/credentials. [0156]
(a) U chooses random S', r.sub.1, r.sub.2, and computes z={hacek
over
(z)}.sub.U.sup.(O.sup.j.sup.,O.sup.i.sup.)*Enc.sub.E.sub.O(S'',
r.sub.1) and S={hacek over (S)}.sub.U.sup.O.sup.j.crclbar.S', where
.crclbar. is defined as the inverse operation of .sym.. U also
chooses a random r, computes
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.)=Enc.sub.P.sub.U.sub.O(S.-
sub.U.sup.O.sup.j, r.sub.2), and sends z and e.sub.1.sup.O.sup.j to
O.sub.i. [0157] (b) U proves to O.sub.i that it established a
public key with O.sub.j, that the corresponding secret keys are
encrypted in e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.) under the
public key P.sub.U.sup.O.sup.t, and that U owns a credential by
O.sub.j (w.r.t. the public keys U established with O.sub.j). More
formally, U proves O.sub.i the following {tilde over
(PK)}{(.alpha., .beta., .gamma., .delta., .epsilon.):.alpha.={hacek
over (f)}.sub.O.sub.j(.beta.,
.gamma.).LAMBDA.e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.)=Enc.sub.P.sub.U.s-
ub.O(.beta., .delta.).LAMBDA.1=Ver(.alpha., .epsilon.,
P.sub.O.sub.j)} [0158] The above method is {tilde over (PK)} is not
an ordinary proof of knowledge as all the other proofs considered
so far because U does not know .gamma. (see explanation below).
[0159] 3'''''. Finally, O.sub.i computes a credential on {hacek
over (P)}.sub.U.sup.O.sup.i, i.e., computes
c.sub.U.sup.O.sup.i=Sig({hacek over (P)}.sub.U.sup.O.sup.t,
S.sub.O.sub.i) and sends c.sub.U.sup.O.sup.i to U. [0160] 4'''''. O
publishes the list (P.sub.U.sup.O.sup.t, c.sub.U.sup.O.sup.i,
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.), O.sub.j) for all O.sub.j
for which it asked for the possession of credentials of.
[0161] As already mentioned, the method {tilde over (PK)}{(.alpha.,
.beta., .gamma., .delta., .delta., .epsilon.):.alpha.={hacek over
(f)}.sub.O.sub.j(.beta.,
.gamma.).LAMBDA.e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.)=Enc.sub.P.sub.U.s-
ub.O(.beta., .delta.).LAMBDA.1=Ver(.alpha., .epsilon.,
P.sub.O.sub.j)} is not an ordinary proof of knowledge as described
at the beginning. The reason is that the user does not known the
value .gamma. because this value is shared between the user and the
designated verifier (here O.sub.i): from decrypting z the
designated verifier O.sub.i knows a value, say s.sub.i, such that
{hacek over (P)}.sub.U.sup.O.sup.j={hacek over
(f)}.sub.O.sub.j(S.sub.U.sup.O.sup.j, s.sub.i.sym.S), where S and
S.sub.U.sup.O.sup.j secrets known only to U. Therefore, O.sub.i and
U can only together execute the above proof which now becomes a
"multi-party computation" where both U and O.sub.i have secret
inputs. The output of the computation will be 1 if and only if the
secret inputs .alpha., .beta., .gamma., .delta., .epsilon. of the
two parties satisfy .alpha.={hacek over (f)}.sub.O.sub.j(.beta.,
.gamma.).LAMBDA.e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.)=Enc.sub.P.sub.U.s-
ub.O(.beta., .delta.).LAMBDA.1=Ver(.alpha., .beta., P.sub.O.sub.j).
Technically, this can for instance be realized using techniques
described in M. Ben-Or, S. Goldwasser, and A. Wigderson;
Completeness theorems for non-cryptographic fault-tolerant
distributed computation; In Proc. 20th Annual ACM Symposium on
Theory of Computing (STOC), pages 1-10, 1988.
[0162] In order to allow the showing of a credential to a verifier
V under "multiple-show" the third method is revised as follows:
[0163] 0'''''. (new) U chooses random S' and r, and computes
z={hacek over
(z)}.sub.U.sup.(O.sup.j.sup.,V)*Enc.sub.P.sub.v({hacek over (S)},
r) and S={hacek over (S)}.sub.U.sup.O.sup.j.crclbar.S', where
.crclbar. is defined as the inverse operation of .sym.. U and sends
z to V. [0164] 1'''''. U proves to V that it established a public
key with O.sub.j, and that U owns a designated verifier credential
by O.sub.j. More formally, U proves V the following {tilde over
(PK)}{(.alpha., .beta., .gamma., .delta.):.alpha.={hacek over
(f)}.sub.O.sub.j(.beta., .gamma.).LAMBDA.1=Ver(.alpha., .delta.,
P.sub.O.sub.j)}
[0165] With respect to the method {tilde over (PK)}{(.alpha.,
.beta., .gamma., .delta.):.alpha.={hacek over
(f)}.sub.O.sub.j(.beta., .gamma.).LAMBDA.1=Ver(.alpha., .delta.,
P.sub.O.sub.j)} the same remark as
[0166] aforementioned applies.
[0167] The methods provided in section can easily be adapted such
that a credential can be used for several designated verifiers.
This can be achieved by having the issuing party encrypt their
{hacek over (S)} for each of the designated verifiers. Thus the
users would obtain a {hacek over
(z)}.sub.U.sup.(O.sup.i.sup.,V.sup.k.sup.) for each of these
verifiers.
[0168] Of course, all features can be added as well.
[0169] For some applications it might be necessary that issued
credentials are consistent. That is if some friends that trust each
other pool their credentials they might get some credentials they
might not be able each individual might not be able to get
otherwise. Whereas this is not a problem for, e.g., access to a
database it is for credentials such as driver's licenses.
[0170] To enforce that credentials are consistent, we can require
that a part of a user's secret remains the same for all pseudonym
she generates Thus the function f.sub.O.sub.i needs to take two
arguments, i.e., f.sub.O.sub.i(.cndot.,.cndot.). Now, a user is
required to prove that for all pseudonym of which she proves
possession of the first argument to functions f.sub.O.sub.i are the
same.
[0171] Steps 1 of the first method need to be modified as follows,
in order to enter the pseudonym system, i.e., to register with the
CA. [0172] 1''''''. U chooses a master secret keys S.sub.U.sup.M,
and a second secret key S.sub.U.sup.CA, computes the public keys
P.sub.U.sup.CA=f.sub.CA(S.sub.U.sup.M, S.sub.U.sup.CA), and sends
P.sub.U.sup.CA to CA.
[0173] The step 2 has to be adapted to register with O.sub.i and to
obtain a credential from O.sub.i, i>1, that is, steps 2a and 2b
are as follows. Note that it can be decided separately for each
execution of step 2 whether local revokability is required or not,
i.e., whether the step is executed with the additions below, or
not. [0174] 1''''''. U chooses a new (random) secret key
S.sub.U.sup.O.sup.i, computes
P.sub.U.sup.O.sup.i=f.sub.O.sub.i(S.sub.U.sup.M,
S.sub.U.sup.O.sup.i), and sends P.sub.U.sup.O.sup.i to O.sub.i.
[0175] 2b''''''. U proves to O.sub.i that it established a public
key with O.sub.j, that the corresponding secret key is encrypted in
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.) under the public key
P.sub.U.sup.O.sup.i, and that U owns a credential by O.sub.j
(w.r.t. the public key U established with O.sub.j). More formally,
U proves V the following PK{(.alpha., .beta., .gamma., .delta.,
.epsilon., .xi.):.alpha.=f.sub.O.sub.j(.epsilon.,
.beta.).LAMBDA.e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.)=Enc.sub.P.sub.U.su-
b.O(.beta., .gamma.).LAMBDA.1=Ver(.alpha., .delta.,
P.sub.O.sub.j).LAMBDA.P.sub.U.sup.O.sup.i=f.sub.O.sub.i(.epsilon.,
.xi.)}
[0176] Note that because the master secret key is the same for all
pseudonyms, it is not needed to encrypt it in
e.sub.1.sup.(O.sup.i.sup.,O.sup.j.sup.).
[0177] Showing a credential to a verifier V (Multiple show) works
as follows: [0178] 1'''' U proves to V that it established a public
key with O.sub.j, and that U owns a designated verifier credential
by O.sub.j. More formally, U proves O.sub.i the following
PK{(.alpha., .beta., .gamma.,
.delta.):.alpha.=f.sub.O.sub.j(.beta.,
.gamma.).LAMBDA.1=Ver(.alpha., .delta., P.sub.O.sub.j)}
[0179] The fact that now pseudonyms of the same users contain the
same master secret key allows a user to prove possession of several
credential without first establishing a pseudonym with the
verifier. Assume that U wants to prove V possession of credentials
be O.sub.j and O.sub.k. Then third method becomes as follows.
[0180] 1'''''''. U proves to V that it established a public key
with O.sub.j and O.sub.k, and that U owns a designated verifier
credential by O.sub.j and O.sub.k. More formally, U proves O.sub.i
the following PK{(.alpha., .beta., .gamma., .delta., .epsilon.,
.zeta., .eta.):.alpha.=f.sub.O.sub.j(.beta.,
.gamma.).LAMBDA.1=Ver(.alpha., .delta.,
P.sub.O.sub.j).LAMBDA..epsilon.=f.sub.O.sub.k(.beta.,
.zeta.).LAMBDA.1'Ver(.epsilon., .eta., P.sub.O.sub.j)}
[0181] For the adaptions described in this section, it should
obvious how the methods look like when combined with the other
extensions.
[0182] Encoding an expiration date or other personalized attribute
into a credential can be done in several ways. They could be
encoded in the users' secret key S.sub.U.sup.O.sup.i, the public
keys P.sub.U.sup.O.sup.i, or into the actual credential itself,
e.g., c.sub.U.sup.O.sup.i=Sig(P.sub.U.sup.O.sup.i.parallel.attr,
P.sub.O.sub.i), where attr stands for the attribute that is
checked. Thus, whenever a user proves the possession of a
credential, he needs also to prove that the required attr is
properly encoded. For the latter, the term 1=Ver(.alpha., .delta.,
P.sub.O.sub.j) in the various PK's would become
1=Ver(.alpha..parallel.attr, .delta., P.sub.O.sub.j).
[0183] If the showing methods are interactive, the party to whom a
user proves possession of a credential cannot convince a third
party that the method actually took place. This is due to the
zero-knowledge property of the PK (sub-)methods. In case it is
required that a third party can be convinced that a method took
place, one can turn the PK sub-methods into the corresponding
non-interactive SPK's . The message m that gets signed with such a
SPK should contain all relevant information related to the
respective instance of the showing method.
[0184] A scheme is said to provide pseudonymity only, if different
showing of credentials are linkeable and non-anonymous. Our system
can be used in such a way, if we require that whenever a users
proves possession of a credential he also provides the public key
established with the issuing organization and the credential in
clear.
[0185] Previous pseudonym systems obtained PKI-assured
non-transferability by requiring that all secret keys of users are
constructed such each of them contains as a part the "external
secret key" S.sub.U.sup.PKI. Thus, when a user transfers a
credential he necessarily also needs to transfer the external
secret key. This mechanism could of course also be used in our
scheme (and be combined with the all-or-nothing transferability or
any of the other features we described). If this mechanism is used
the encryptions e.sub.1.sup.(O.sup.j.sup.,O.sup.i.sup.) would no
longer be necessary.
[0186] In the following we provide a description of how the
credential system can be implement more efficiently. Before we can
do so, however, we need to provide some building blocks.
[0187] Our construction is based on the decisional Diffie-Hellman
assumption and the strong RSA assumption. It is provably secure in
the random oracle model. In this section, we outline some of the
less well-known technical points that will be used when we describe
our protocols.
[0188] The flexible RSA problem is the following. Let n=pq be a
randomly generated RSA modulus. Let a random element z from *.sub.n
be given. Find an element u .di-elect cons. *.sub.n and a number e
.di-elect cons. >1 such that z.ident.u.sup.e (mod n). The strong
RSA assumption (SRSA) is that this problem is hard to solve. It is
stronger than the traditional RSA assumption which states that
given a modulus n and an exponent e it is hard to find u, z
.di-elect cons. *.sub.n such that z.ident.u.sup.e (mod n). Although
both assumptions are stronger than assuming integer factorization
to be hard, the only known way of solving the respective problems
involves factoring the modulus.
[0189] The strong RSA assumption was independently introduced by
Bari and Pfitzmann (Bari and Pfitzmann, 1997) and by Fujisaki and
Okamoto (Fujisaki and Okamoto, 1997) and has subsequently proved
instrumental for constructing existentially unforgeable signature
schemes secure against adaptive chosen message attacks (Cramer and
Shoup, 1999; Gennaro et al., 1999), and for constructing other
important primitives such as group signatures (Ateniese et al.,
2000, Camenisch and Michels, 1998) and verifiable secret sharing
(Fujisaki and Okamoto, 1998).
[0190] Let G=<g> denote a group of prime order q. The most
basic protocol we consider is a zero-knowledge proof of knowledge
of the discrete logarithm of some group element y .di-elect cons. G
to the base g (Chaum et al., 1988; Schnorr, 1991). We shortly
recall this protocol and its properties: The prover knowing
x=log.sub.g y sends the verifier the commitment t:=g.sup.r, where r
.di-elect cons..sub.R Z.sub.q. Then, the verifier sends the prover
a random challenge c .di-elect cons..sub.R {0, 1}.sup.k which he
answers with the response s:=r-cx (mod q). (The integer k.gtoreq.1
is a security parameter.) The verifier accepts if t=g.sup.ay.sup.c.
Triples (t, c, s) with t=g.sup.ay.sup.c are called accepting
triples. As x=log.sub.g y can be computed from two accepting
triples (t, c, s) and (t, {dot over (c)}, {dot over (s)}) with
c.noteq.{dot over (c)}, i.e., x:=(s-{dot over (s)})({dot over
(c)}-c).sup.-1 (mod q), this protocol is a proof of knowledge of
log.sub.g y. Furthermore, the protocol is honest-verifier
zero-knowledge..sup.1 Using notation from (Camenisch and Stadler,
1997), this protocol is denoted PK{(.alpha.):y=g.sup.a}, which can
be read as "zero-knowledge Proof of Knowledge of a value a such
that y=g.sup.a holds." The convention is that Greek letters denote
the quantity the knowledge of which is being proved, while all
other parameters are known to the verifier. Using this notation,
the proof can be described by just pointing out its aim while
hiding all details. This helps to see what is proved and to
understand the design of higher-level protocols. .sup.1Thus it can
be made zero-knowledge by requiring the verifier to commit to the
challenge before she receives the prover's commitments.
[0191] These kinds of proofs of knowledge (PK) can be turned into
signature schemes by the so-called Fiat-Shamir heuristic (Fiat and
Shamir, 1987). That is, the prover determines the challenge c by
applying a collision-resistant hash-function H to the commitment t
and the message m that is signed, i.e., c=H(t, m), and then
computes the response as usual. The resulting signature consists of
the challenge and the response. We denote such Signature schemes
based on a zero-knowledge Proof of Knowledge (SPK) similarly as the
PK's, e g., SPK{(.alpha.):y=g.sup.a}(m). Such SPK's can be proved
secure in the random oracle model (Bellare and Rogaway, 1993;
Pointcheval, 1996) given the zero-knowledge and validity
(soundness) properties of the underlying PK's.
[0192] In this paper we apply such PK's and SPK's to the group of
quadratic residues modulo a composite n, i.e., G=QR.sub.n. This
choice for the underlying group has some consequences. First, the
protocols are proofs of knowledge under the strong RSA assumption
(Fujisaki and Okamoto, 1997). Second, the largest possible value
2.sup.k-1 of the challenge c must be smaller that the smallest
factor of G's order. This issue can be addressed by assuring that n
is the product of two equal-sized safe primes, i.e., primes p and q
such that p'=(p-1)/2 and q'=(q-1)/2 are prime (such p' and q' are
called Sophie Germain primes). Then the order of QR.sub.n will be
p'q' and values k<(log {square root over (n)})-4 are fine.
Third, soundness needs special attention in case the verifier is
not equipped with the factorization of n as then deciding
membership of QR.sub.n is believed to be hard. Thus the prover
needs to convince the verifier that the elements he presents are
indeed quadratic residues, i.e., that the square roots of the
presented elements exist. This can in principle be done with a
protocol by Fiat and Shamir (Fiat and Shamir, 1987). However, often
it is sufficient to simply execute
PK{(.alpha.):y.sup.2=(g.sup.2).sup.a} instead of
PK{(.alpha.):y=g.sup.a}. The quantity .alpha. is defined as
log.sub.gy.sup.2 which is the same as log.sub.g y in case y is a
quadratic residue.
[0193] The following lists and reviews briefly those extensions of
the basic PK{(.alpha.):y=g.sup.a} that we need as building blocks.
We also cast these extensions in the notation explained above.
[0194] A proof of knowledge of a representation of an element y
.di-elect cons. G with respect to several bases z.sub.1, . . . ,
z.sub.v .di-elect cons. G (Chaum et al., 1988) is denoted
PK{(.alpha..sub.1, . . . ,
.alpha..sub.v):y=z.sub.1.sup..alpha..sup.1, . . . ,
z.sub.v.sup..alpha..sup.u}. [0195] A proof of equality of discrete
logarithms of two group elements y.sub.1, y.sub.2 .di-elect cons. G
to the bases g .di-elect cons. G and h .di-elect cons. G.
respectively, (Chaum, 1991; Chaum and Pedersen, 1993) is denoted
PK{(.alpha.):y.sub.1=g.sup..alpha..LAMBDA.y.sub.2=h.sup..alpha.}.
Generalizations to prove equalities among representations of the
elements y.sub.1, . . . , y.sub.w .di-elect cons. G to bases
g.sub.1, . . . , g.sub.u .di-elect cons. G are straight forward
(Camenisch and Stadler, 1997). [0196] A proof of knowledge of a
discrete logarithm of y .di-elect cons. G with respect to g
.di-elect cons. G such that log.sub.g y that lies in the integer
interval [a, b] is denoted by
PKI{(A):y=g.sup..alpha..LAMBDA..alpha..di-elect cons. [a, b]}.
Under the strong RSA assumption and if it is assured that the
prover is not provided the factorization of the modulus (i.e., is
not provided the order of the group) this proof can be done
efficiently (Boudot, 2000) (it compares to about six ordinary
PK{(.alpha.):y=g.sup..alpha.}.) [0197] The previous protocol can
also be used to prove that the discrete logarithms of two group
elements y.sub.1 .di-elect cons. G.sub.1, y.sub.2 .di-elect cons.
G.sub.1 to the bases g.sub.1 .di-elect cons. G.sub.1 and g.sub.2
.di-elect cons. G.sub.2 in different groups G.sub.1 and G.sub.2 are
equal (Brickell et al., 1988; Camenisch and Michels, 1999b). Let
the order of the groups be q.sub.1 and q.sub.2, respectively. This
proof can be realized only if both discrete logarithms lie in the
interval [0, min{q.sub.1, q.sub.2}]. The idea is that the prover
commits to the discrete logarithm in some group, say
G=<g>=<h> the order of which he does not know, and then
execute PK{(.alpha.,
.beta.):y.sub.1=g.sub.1.sup..alpha..LAMBDA.y.sub.2=g.sub.2.sup..alpha..LA-
MBDA.C=g.sup..alpha.h.sup..beta..LAMBDA..alpha. .di-elect cons. [0,
min{q.sub.1, q.sub.2}]}, where C is the commitment. This kind of
protocol generalizes to several different groups, to
representations, and to arbitrary modular relations.
[0198] Verifiable encryption is a two-party protocol between a
prover and encryptor P and a verifier and receiver V. Their common
inputs are a public encryption key E, a public value v, and a
binary relation on bit strings. As a result of the protocol, V
either rejects or obtains the encryption e of some value s under E
such that (s, v) .di-elect cons. . For instance, could be the
relation (s, g.sup.s) .OR right..sub.q.times.G. The protocol should
ensure that V accepts an encryption of an invalid s only with
negligible probability and that V learns nothing beyond the fact
that the encryption contains some s with (s, v) .di-elect cons. .
The encryption key E typically belongs to a third party, which is
not involved in the protocol at all.
[0199] Generalizing the protocol of Asokan et al. (Asokan et al.,
2000), Camenisch and Damgard (Camenisch and Damgard, 1998) provide
a verifiable encryption scheme for all relations that have an
honest-verifier zero-knowledge three-move proof of knowledge where
the second message is a random challenge and the witness can be
computed from two transcripts with the same first message but
different challenges. This includes most known proofs of knowledge,
and all proofs about discrete logarithms from the previous section
in particular.
[0200] Their verifiable encryption schemes is itself a three-move
proof of knowledge of the encrypted witness s and is
computationally zero-knowledge if a semantically secure encryption
scheme is used (Camenisch and Damgard, 1998).
[0201] The basic idea of their scheme is that the prover starts the
PK protocol for the relation he wants to prove, i.e., computes the
commitment t. Then, he computes the responses s.sub.0 and s.sub.1
to the challenges c=0 and c=1, encrypts these two responses under
public key E, and sends these encryptions to the verifier.
Receiving these, the verifier randomly chooses one of them and asks
the prover to open it, thus obtaining a response to either c=0 or
c=1. Finally the verifier accepts if the response is valid in the
PK protocol w.r.t. the corresponding challenge. This procedure
needs to be repeated sufficiently many times to obtain validity
(i.e., such that the verifier is assured that at least on of the
unopened encryptions also contains a valid response). It is easy to
see that, assuming that the adversary will never gain access to the
secret key for the underlying encryption scheme, the protocol is
computational zero-knowledge if the PK is so and the encryption
scheme is semantically secure. On the other hand, if the third
party opens the second encryption as well, one gets two accepting
triples and hence can compute the witness by the properties of the
underlying PK. We refer to Camenisch and Damgard (Camenisch and
Damgard, 1998) for further details and efficiency improvements.
[0202] We use a similar notation for verifiable encryption as for
the PK's and denote by, e.g., e:=VE(ElGamal, (g,
y)){.xi.v=g.sup..xi.} the verifiable encryption protocol for the
ElGamal scheme, whereby log.sub.g v is encrypted in e under public
key (y, g). Note that C is not a single encryption, but the
verifier's entire transcript of the protocol and contains several
encryptions, commitments and responses of the underlying PK.
[0203] Our scheme requires each user to encrypt each of her secret
keys under one of her public keys, thereby creating "circular
encryptions". However, the definition of a semantically secure
encryption scheme does not provide security for such encryptions.
Moreover, it is not known whether circular security is possible
under general assumptions. In this paragraph we provide for the
first time a construction for an encryption scheme that provides
security for circular encryptions in the random oracle model given
any semantically secure encryption scheme.
[0204] A semantically secure scheme G=(E, D) on message space {0,
1}.sup.l, is circular-secure if for all probabilistic polynomial
time families of Turing machines {A.sub.k}, for all sufficiently
large k, for all n=poly(k), for all assignments to (i.sub.1, . . .
, i.sub.n) and (j.sub.1, . . . , j.sub.n), |Pr[A.sub.k(C, E.sub.1,
. . . , E.sub.n)=0|(E.sub.1, D.sub.1) .di-elect cons..sub.RG, . . .
, (E.sub.n, D.sub.n) .di-elect cons..sub.RG; C=(E.sub.i.sub.1(0), .
. . , E.sub.i.sub.n(0))]-Pr[A.sub.k(C, E.sub.1, . . . ,
E.sub.n)=0|(E.sub.1, D.sub.1) .di-elect cons..sub.RG, . . . ,
(E.sub.n, D.sub.n) .di-elect cons..sub.RG;
C=(E.sub.i.sub.1(D.sub.j.sub.1), . . . ,
E.sub.i.sub.n(D.sub.j.sub.n))]|=neg(k) Pr [ A k .function. ( C 1
.times. E 1 , .times. , E n ) = 0 .times. ( E 1 , D 1 ) .times.
.di-elect cons. R .times. , .times. , ( E n , D n ) .times.
.di-elect cons. R .times. ; C = ( E i , ( 0 ) , .times. , E i n
.function. ( 0 ) ) ] - Pr [ A k .function. ( C , E 1 , .times. , E
n ) = 0 .times. ( E 1 , D 1 ) .times. .di-elect cons. R .times. ,
.times. , ( E n , D n ) .times. .di-elect cons. R .times. i .times.
C = ( E i .times. .times. 1 .function. ( D j .times. .times. 1 ) ,
.times. , E i n .function. ( D j n ) ) ] = neg .function. ( k )
##EQU2## (I.e., having access to encryptions of the secret keys
does not help the adversary in breaking the semantic security of
the system.)
[0205] Let H: {0, 1}*.fwdarw.{0, 1}.sup.k be a random oracle, and
let .sym. denote the bitwise XOR operation. Let G=(E, D) be a
semantically secure cryptosystem. Construct G'=(E', D') as follows:
generate (E, D) according to G. To encrypt, a message m .di-elect
cons. {0, 1}.sup.k, E' picks a random r .di-elect cons..sub.R{0,
1}.sup.l and sets E'(m):=(E(r), H(r).sym.m). To decrypt tuple (a,
b), D' computes {tilde over (m)}:=H(D(.alpha.)).sym.b.
[0206] If G is semantically secure, G' is a circular-secure.
[0207] As a basis for our circular encryption scheme, we use a
variant of ElGamal encryption (ElGamal, 1985) where the public key
P=a.sup.xb.sup.y is derived from two bases a and b (of possibly
unknown order) and two secret keys x and y. This variant of the
ElGamal cryptosystem is known to be semantically secure under the
decisional Diffie-Hellman assumption The resulting circular
encryption scheme is as follows. Let the order
G=<a>=<b> be.apprxeq.2.sup.l. To encrypt a message m
.di-elect cons. {0, 1}.sub.k, choose a random element r.sub.1
.di-elect cons. G and a random integer r.sub.2 .di-elect cons. {0,
1}.sup.2l, and compute the encryption (u, v, w,
z):=(P.sup.r.sup.2r.sub.1, a.sup.r.sup.2, b.sup.r.sup.2,
H(r.sub.1).sym.m).
[0208] Decryption works by computing H .function. ( u v x .times. w
y ) .sym. z . ##EQU3##
[0209] We denote this encryption scheme by CEIG and write, e.g.,
VE(CEIG, (H, a, b, P)){.xi.:v=g.sup..xi.} when using it for
verifiable encryption.
[0210] Our pseudonym system requires a prover to verifiably encrypt
under a public key that is not revealed to the verifier, that is,
the verifier gets to see only a commitment to this public key.
Moreover, the prover knows the secret key corresponding to this
public key.
[0211] Recall that verifiable encryption protocol described earlier
demands that prover opens encryptions. In case the verifier knows
the encryption public key, the prover can provably open an
encryption just by providing the message and all random choices she
made. The verifier then just reruns the encryption algorithm and
checks whether this results in the same encryption. In case the
verifier does not know the encryption public key, however, this
does not work. In the following we describe how the prover can
nevertheless convince the verifier that an encryption contains the
value she claims. We will use the same encryption scheme as in the
previous section, i.e., P=a.sup.xb.sup.y serves as public key, and
x and y as the corresponding secret keys. Let C=Pg.sup.r be the
commitment to P, where g is a third random generator of
G=<a>=<b>, and let (u, v, w, z)=(P.sup.r.sup.2r.sub.1,
a.sup.r.sup.2, b.sup.r.sup.2, H(r.sub.1).sym.m) be an encryption of
m as above. To convince the verifier that m is indeed encrypted in
(u, v, w, z) under the public key committed to by Cr the prover
reveals r.sub.1 and engages with the verifier in PK{(.alpha.,
.beta., .gamma.,
.delta.):C=a.sup..alpha.b.sup..beta.g.sup..gamma..LAMBDA.v=a.sup..delta..-
LAMBDA.w=b.sup..delta..LAMBDA.u/r.sub.1=v.sup..alpha.w.sup..beta.}.
[0212] The verifier further needs to check if
z=H(r.sub.1).sym.m.
[0213] In the following, we write, e.g., VE(C-CEIG, (H, a, b, g,
C)){.xi.:v=g.sup..xi.} for verifiable encryption with committed
encryption public key.
[0214] We first describe our basic pseudonym system with
all-or-nothing and PKI-assured non-transferability. The basic
system compromises protocols for a user to join the system,
register with an organization, obtaining multi-show credentials,
and showing such credentials. We will then describe extensions that
allow for one-show credentials as well and for revocability.
[0215] Throughout we assume that the users and organizations are
connected by perfectly anonymous channels. Furthermore, we assume
that for each protocol the organizations authenticates itself
towards the users and that they establish a secure channel between
them for each session. For any protocol we describe, we implicitly
assume that is some check or sub-protocol (e.g., some proof of
knowledge PK) fails for some party, it informs the other
participating parties of this and stops.
[0216] In the following we use CA and O.sub.0 as interchangeable
names for the pseudonym system's certification authority.
[0217] Our basic system is composed of the protocols presented
below in the following way.
[0218] System setup: The system parameters are agreed upon and all
organizations (including the CA) choose their keys and make the
public keys available. It is possible that organizations (apart
from the CA join and leave at any time.
[0219] A User Joining the System/Registering with the CA: [0220] 1.
User U identifies herself towards the CA who checks that she is
eligible to join the system. [0221] 2. U chooses a random nym
master secret x.sub.U .di-elect cons. .GAMMA.. [0222] 3. They run
Protocol 1 to establish U pseudonym P.sub.U.sup.CA with the CA.
[0223] 4. Depending on whether we want to have PKI-assured
non-transferability, U and CA run Protocol 5. [0224] 5. O.sub.i
grants U a credential, i.e., they run Protocol 2.
[0225] A User Registering with Organization O.sub.i and Obtaining a
Credential from O.sub.i: [0226] 1. U and O.sub.i run Protocol 1 to
establish U pseudonym P.sub.U.sup.O.sup.i with O.sub.i. [0227] 2.
Let O be the set of organizations of which U must possess a
credential in order to obtain a credential from O.sub.i. For each
O.sub.j .di-elect cons. O, user U and O.sub.i carry out Protocol 4.
[0228] 3. The CA grants U a credential, i.e., they run Protocol 2.
[0229] Note that the above steps could be executed at different
times.
[0230] A User Accessing a Service: [0231] Case I. Assume that a U
wants to access some service from V and that to do so U needs to
hold a credential by O.sub.j. If this is the case, U can access the
service by executing Protocol 3 with V. [0232] Case II. In case U
is required to hold credential from a set O of organizations, U
must first establish a pseudonym with V, i.e., run Protocol 1, and
then run Protocol 4 for each O.sub.j .di-elect cons. O. If it is
understood that the established pseudonym is one-time, i,e., if U
is not allowed to access the service again just be proving
ownership of the established pseudonym, U and V need not execute
the steps 4:3 and 4:2 of the latter protocol.
[0233] The system parameter and key generation work as follows. For
simplicity we assume some common system parameter: the length of
RSA moduli l.sub.n, the integer intervals
.GAMMA.=]-2.sup.l.sup..GAMMA., 2.sup.l.sup..GAMMA.[,
.DELTA.=]-2.sup.l.sup..DELTA., 2.sup.l.sup..DELTA.[,
.LAMBDA.=]2.sup.l.sup..LAMBDA.,
2.sup.l.sup..LAMBDA..sup.+l.sup..SIGMA.[ such that
l.sub..DELTA.=.epsilon.l.sub..GAMMA. and l.sub..GAMMA.=2l.sub.n,
where .epsilon.>1 is a security parameter, and
2.sup.l.sup..LAMBDA.>2(2.sup.2l.sup..GAMMA.+2.sup.l.GAMMA.+2.sup.l.sup-
..DELTA.), and
2(2.sup.l.sup..SIGMA.(2.sup.2l.sup..GAMMA.+2.sup.l.sup..DELTA.)+2.sup.l.s-
up..DELTA.)<2.sup.l.sup..DELTA..
[0234] Each organization O.sub.i (including the CA) chooses random
l.sub.n/2-bit primes p'.sub.O.sub.i, q'.sub.O.sub.i such that
p.sub.O.sub.i=2p'+1 and q.sub.O.sub.i=2q'+1 are prime and sets
modulus n.sub.O.sub.i=p.sub.O.sub.iq.sub.O.sub.i. It also chooses
random elements a.sub.O.sub.i, b.sub.O.sub.i, d.sub.O.sub.i,
g.sub.O.sub.i, h.sub.O.sub.i .di-elect cons. QR.sub.n.sub.O. It
stores S.sub.O.sub.i:=(p.sub.O.sub.i, q.sub.O.sub.i) as its secret
keys and publishes P.sub.O.sub.i:=(n.sub.O.sub.i, a.sub.O.sub.i,
b.sub.O.sub.i, d.sub.O.sub.i, g.sub.O.sub.i, h.sub.O.sub.i) as its
public key together with a proof that n.sub.O.sub.i is the product
of two safe primes (see (Camenisch and Michels, 1999a) for how the
latter can be done) and that the elements a.sub.O.sub.i,
b.sub.O.sub.i, d.sub.O.sub.i, g.sub.O.sub.i, h.sub.O.sub.i lie
indeed in QR.sub.n.sub.O(this can be done by providing their roots;
then, to check that an element s has order at least p'q', one needs
only to test whether gcd(s.+-.1, n.sub.O.sub.i)=1).
[0235] This paragraph describes how a user U establishes a
pseudonym with organization O.sub.i.
[0236] Let x.sub.U .di-elect cons. .GAMMA. be the U's nym master
secret. In case O.sub.i is the CA, i.e., U has no yet entered the
system, U needs to choose a random x.sub.U .di-elect
cons..sub.R.GAMMA. before entering the protocol below. We will see
later how it is ensured that U uses the same x.sub.U with other
organizations.
[0237] To establish a pseudonym P.sub.U.sup.O.sup.t with O.sub.i,
user U engages in Protocol 1 with O.sub.i. The protocol assures
that the established pseudonym is of the right form, i.e., P U O i
= a O i x U .times. b O i s U O i , ##EQU4## with x.sub.U .di-elect
cons..GAMMA. and s.sub.U.sup.O.sup.i .di-elect cons. .DELTA.. The
value s.sub.U.sup.O.sup.i is chosen by jointly by O.sub.i and U but
without O.sub.i learning anything about both values. Note that this
protocol does not assure that U uses the x.sub.U same x.sub.U as
with other organizations as well; this is taken care of later in
Protocol 4.
[0238] Protocol 1. [0239] 1:1. U chooses random r.sub.1 .di-elect
cons..sub.R.DELTA. and r.sub.2, r.sub.3 .di-elect cons..sub.R]{0,
1}.sup.2ln, computes
C.sub.1=g.sub.O.sub.i.sup.r.sup.1h.sub.O.sub.i.sup.r.sup.2 and
C.sub.2=g.sub.O.sub.i.sup.x.sup.U h.sub.O.sub.i.sup.r.sup.3, and
sends C.sub.1 to O.sub.i. [0240] 1:2. U engages with O.sub.i in
PK{(.alpha., .beta., .gamma.,
.delta.):C.sub.1.sup.2=(g.sub.O.sub.i.sup.2).sup..alpha.(h.sub.O.sub.i.su-
p.2).sup..beta..LAMBDA.C.sub.2.sup.2=(g.sub.O.sub.i.sup.2).sup..gamma.(h.s-
ub.O.sub.i.sup.2).sup..delta.} proving that U formed C.sub.1 and
C.sub.2 correctly [0241] 1:3. O.sub.i chooses a random r .di-elect
cons..sub.R .DELTA. and sends r to U. [0242] 1:4. U chooses r.sub.4
.di-elect cons..sub.R {0, 1}.sup.l.sup.n, computes
s.sub.U.sup.O.sup.i=(r.sub.1+r mod
(2.sup.l.sup..DELTA..sup.+1+1))-2.sup.l.sup..DELTA.+1, s ~ = r 1 +
r 2 t .times. .DELTA. + 1 + 1 , P U O i = a O i x U .times. b O i s
U O i , C 3 = g O i s ~ .times. h O i r 4 , ##EQU5## and sends
P.sub.U.sup.O.sup.i and C.sub.3 to O.sub.i. [0243] 1:5. U engages
with O.sub.i in PK .times. { ( .alpha. , .beta. , .gamma. , .delta.
, , .zeta. , , .xi. ) : C 1 2 = ( g O i 2 ) .alpha. .times. ( h O i
2 ) .beta. C 2 2 = ( g O i 2 ) .gamma. .times. ( h O i 2 ) .delta.
C 3 2 = ( g O i 2 ) .times. ( h O i 2 ) .zeta. ( P U O i ) 2 = ( a
O i 2 ) .gamma. .times. ( b O i 2 ) ( C 1 2 .function. ( g O i 2 )
( r - 2 l .times. .DELTA. + 1 ) ) / ( C 3 2 ) ( 2 .times. .DELTA. +
1 + 1 ) = ( g O i 2 ) .times. ( h O i 2 ) .xi. .gamma. .di-elect
cons. .GAMMA. .di-elect cons. .DELTA. } ##EQU6## [0244] proving
that U formed P.sub.U.sup.O.sup.i and C.sub.3 correctly. [0245]
1:6. O.sub.i stores (P.sub.U.sup.O.sup.i).sup.2 and
P.sub.U.sup.O.sup.i. [0246] 1:7. U stores
(P.sub.U.sup.O.sup.i).sup.2, P.sub.U.sup.O.sup.i, and
s.sub.U.sup.O.sup.i.
[0247] Let us explain the steps of this protocol in more detail.
First, U commits to x.sub.U and to her contribution r.sub.1 to
s.sub.U.sup.O.sup.i. She sends O.sub.i these commitments and proves
to O.sub.i that she knows the committed values (this proof is
necessary already at this point of the protocol for the security
proof to work). After this, O.sub.i chooses its contribution r to
s.sub.U.sup.O.sup.i and sends it to U, who computes
s.sub.U.sup.O.sup.i and P.sub.U.sup.O.sup.i, sends
P.sub.U.sup.O.sup.i to O.sub.i, and proves that she computes
P.sub.U.sup.O.sup.i correctly, i.e., that s.sub.U.sup.O.sup.i lies
in .DELTA. and is computed correctly from r and the value she
committed to earlier in C.sub.2. For technical reasons, we consider
P and P to be the same pseudonym if P.sup.2= P.sup.2.
[0248] We now describe how a credential can be generated
efficiently.
[0249] A credential a pseudonym P issued by O.sub.i is a pair (c,
e) .di-elect cons.*.sub.n.sub.O such that
(Pd.sub.O.sub.j).sup.e.ident.c (mod n.sub.O.sub.i). To generate a
credential on a priorly established pseudonym P.sub.U.sup.O.sup.i,
organization O.sub.i and user U carry out the following
protocol.
[0250] Protocol 2. [0251] 2:1. U identifies as owner of
P.sub.U.sup.O.sup.i by engaging in protocol PK{(.alpha.,
.beta.):(P.sub.U.sup.O.sup.i).sup.2=(a.sub.O.sub.i.sup.2).sup..alpha.(b.s-
ub.O.sub.i.sup.2).sup..beta.} with O.sub.i. [0252] 2:2. O.sub.i
looks up P.sub.U.sup.O.sup.i, chooses a random prime
e.sub.U.sup.O.sup.i .di-elect cons..sub.R.LAMBDA., computes
c.sub.U.sup.O.sup.i=(P.sub.U.sup.O.sup.id.sub.O.sub.i).sup.1/e.sup.U.sup.-
O mod n.sub.O.sub.i, sends c.sub.U.sup.O.sup.i to U, and stores
c.sub.U.sup.O.sup.i together with P.sub.U.sup.O.sup.i. [0253] 2:3.
U checks whether c U O i c U O i .ident. P U O i .times. d O i
##EQU7## (mod n.sub.O.sub.i) and stores (c.sub.U.sup.O.sup.i,
e.sub.U.sup.O.sup.i) together with P.sub.U.sup.O.sup.t.
[0254] Step 2:1 can of course be omitted if the Protocol 2 takes
place in the same session as some other protocol where U already
proved ownership of P.sub.U.sup.O.sup.i.
[0255] The following paragraph describes how showing a single
credential can be implemented efficiently.
[0256] Assume a user U wants to prove possession of a certificate
by organization O.sub.j to a verifier V. They engage in the
following protocol.
[0257] Protocol 3. [0258] 3:1. U chooses r.sub.1, r.sub.2 .di-elect
cons..sub.R {0, 1}.sup.2l.sup.n, computes
A=c.sub.U.sup.O.sup.ih.sub.O.sub.j.sup.r.sup.1 and
B=h.sub.O.sub.j.sup.r.sup.1g.sub.O.sub.4.sup.r.sup.2, and sends A,
B to V. [0259] 3:2. U engages with V in PK .times. { ( .alpha. ,
.beta. , .gamma. , .delta. , , .zeta. , .xi. ) : d O j 2 = ( A 2 )
.alpha. .times. ( 1 / ( a O j 2 ) ) .beta. .times. ( 1 / ( b O j 2
) ) .gamma. .times. ( 1 / ( h O j 2 ) ) .delta. B 2 = ( h O j 2 )
.times. ( g O j 2 ) .zeta. 1 = ( B 2 ) .alpha. .times. ( 1 / ( h O
j 2 ) ) .delta. .times. ( 1 / ( g O j 2 ) ) .xi. .beta. .di-elect
cons. .GAMMA. .gamma. .di-elect cons. .DELTA. .alpha. .di-elect
cons. .LAMBDA. } . ##EQU8##
[0260] The PK in step 3:2 proves that U possess a credential issued
by O.sub.i on some pseudonym registered with O.sub.j.
[0261] The following paragraph describes how showing a credential
with respect to a pseudonym can be implemented efficiently.
[0262] Assume a user U wants to prove possession of a certificate
by organization O.sub.j to an organization O.sub.i with whom U
established P.sub.U.sup.O.sup.i. That means O.sub.i not only wants
to be assured that U owns a credential by O.sub.j but also that the
pseudonym connected with this credential contains on the same
master secret key as P.sub.U.sup.O.sup.i. Moreover, the protocol
also assures that if U would give the secrets of
P.sub.U.sup.O.sup.i to one of her friends, then she would also
reveal the secret keys of the pseudonym established with O.sub.j
and vice versa, whereby all-or-nothing transferability gets
assured. Thus U and O.sub.i engage in the following protocol (in
which we assume that O.sub.i has already established that
P.sub.U.sup.O.sup.i .di-elect cons. QR.sub.n.sub.Oi).
[0263] Protocol 4. [0264] 4:1. U chooses random r.sub.1, r.sub.2,
r.sub.3 .di-elect cons..sub.R {0, 1}.sup.2l.sup.n, computes
A=c.sub.U.sup.O.sup.jh.sub.O.sub.j.sup.r.sup.1,
B=h.sub.O.sub.j.sup.r.sup.1g.sub.O.sub.j.sup.r.sup.2, and
C=P.sub.U.sup.O.sup.jh.sub.O.sub.j.sup.r.sup.3, and sends A, B, C
to O.sub.i. [0265] 4:2. U engages with O.sub.i in PK .times. { (
.alpha. , .beta. , .gamma. , .delta. , , .zeta. , .xi. , .eta. ,
.phi. ) : d O j 2 = ( A 2 ) .alpha. .times. ( 1 / ( a O j 2 ) )
.beta. .times. ( 1 / ( b O j 2 ) ) .gamma. .times. ( 1 / ( h O j 2
) ) .delta. B 2 = ( h O j 2 ) .times. ( g O j 2 ) .zeta. 1 = ( B 2
) .alpha. .times. ( 1 / ( h O j 2 ) ) .delta. .times. ( 1 / ( g O j
2 ) ) .xi. ( P U O i ) 2 = ( a O i 2 ) .beta. .times. ( b O i 2 )
.eta. C 2 = ( a O j 2 ) .beta. .times. ( b O j 2 ) .gamma. .times.
( h O j 2 ) .phi. .beta. .di-elect cons. .GAMMA. .gamma. .di-elect
cons. .DELTA. .alpha. .di-elect cons. .LAMBDA. } . ##EQU9## [0266]
4:3. U and O.sub.i engage in the verifiable encryption protocols u
.times. ( P U .times. O i , O j ) = VE .function. ( CEIG , ( H , (
a O i ) 2 , b O i 2 , ( P U .times. O i ) 2 ) ) .times. { ( .alpha.
, .beta. , .gamma. ) : C 2 = ( a O j 2 ) .alpha. .times. ( b O j 2
) .beta. .times. ( h O j 2 ) .gamma. } .times. .times. and .times.
w .times. ( P U .times. O i , O j ) .times. = VE .function. ( C -
CEIG , ( H , a O j 2 , b O j 2 , h O j 2 , C 2 ) ) .times. { (
.alpha. , .beta. ) : ( P U .times. O i ) 2 = ( a O i 2 ) .alpha.
.times. ( b O i 2 ) .beta. } . ##EQU10## [0267] 4:4. O.sub.i
publishes the list (u.sub.(P.sub.U.sub.O.sub.,O.sub.j,
w.sub.(P.sub.U.sub.O.sub., O.sub.j, P.sub.U.sup.O.sup.i,
e.sub.U.sup.O.sup.i, c.sub.U.sup.O.sup.i).
[0268] The first two steps of this protocol are similar to the ones
of Protocol 3, the difference being that here U also commits in C
to the pseudonym established with O.sub.j, and proving that this is
indeed the case. This commitment is need for the encryption is step
4:3. In this step all-or-nothing transferability is achieved by (1)
verifiably encrypting the secrets keys of the pseudonym U
established with O.sub.j using P.sub.U.sup.O.sup.i as the
encryption public key (cf. Section) and (2) verifiably encrypt the
secret keys of P.sub.U.sup.O.sup.i using the pseudonym committed in
C.sup.2 as encryption public key (cf. Section).
[0269] In case we want to have PKI-assured non-transferability
only, the steps 4:3 and 4:2 can be omitted. Furthermore, C is not
necessary either and can be dropped.
[0270] In this paragraph we show how to ensure that if a user gives
away his master secret x.sub.U, then he will also reveal the secret
key of an "external" valuable public key PK.sub.U. This is achieved
by having the CA ask for this public key PK.sub.U and check whether
this is the user's public key (e.g., via some external certificate)
and then require the user to verifiable encrypt the corresponding
secret key such that it can be
[0271] We give an example for how this protocol look in case that U
external public key Y.sub.U is discrete logarithm based, i.e.,
Y.sub.U=g.sup.x for some generator g. Other cases are similar.
[0272] Protocol 5. [0273] 5:1. U sends Y.sub.U and g to CA together
with the certificate on Y.sub.U of the external PKI. The CA checks
the validity of Y.sub.U. [0274] 5:2. U and CA engage in the
protocol w.sub.(P.sub.U.sub.(O.sub.O.sub.)=VE(CEIG, (H,
a.sub.O.sub.0.sup.2, b.sub.O.sub.0.sup.2,
(P.sub.U.sup.O.sub.0).sup.2)){(.alpha.,
.beta.):Y.sub.U=g.sup.a}.
[0275] The following describes how one show credentials can be
implemented efficiently. The credential we considered so far can be
shown an unlimited number of times. However, for some services it
might be required that a credential can only be used once. Of
course, one possibility would be that a user just reveals the
credential to the verifier in clean. This, however, would mean that
the user is not fully anonymous any more as the verifier and the
organization then both know the credential and thus can link the
transaction to the user's pseudonym. Traditionally this problem has
been solved using so-called blind signatures (Chaum, 1983). Here,
we provide a novel and alternative way to approach this problem,
i.e., instead of blinding the signer we blind the verifier. This
approach could also be used to implement anonymous e-cash (just
consider a credential to be money).
[0276] In the following we describe the general idea how it is
realized. The resulting changes that would have to be made to the
individual protocol we do not provide. [0277] Each organization
published an additional provably random generator z.sub.O.sub.i
.di-elect cons. QR.sub.n.sub.O. [0278] A user's pseudonym is formed
slightly different: P U O i = a O i x U .times. b O i s U O i
.times. z O i r U O i , ##EQU11## where r.sub.U.sup.O.sup.i is
chosen be O.sub.i and U together in the same way as is
s.sub.U.sup.O.sup.i. [0279] Credential are issued in the very same
way as before, i.e., U obtains c.sub.U.sup.O.sup.i and
e.sub.U.sup.O.sup.i such that
c.sub.U.sup.O.sup.i.sup.e.sup.U.sup.O.ident.P.sub.U.sup.O.sup.id.sub.O.su-
p.i (mod n.sub.O.sub.i) holds. [0280] When proving possession of a
one-show credential issued by O.sub.j (with respect to a pseudonym
or not), the user provides the verifier V (which might be an
organization) the value H U O j = h O j r U O j ##EQU12## and
proves that it is formed correctly w.r.t. to the pseudonym U
established with O.sub.j. Of course, the various PK's in these
protocols have to be adapted to reflect the different form of the
pseudonym U holds with O.sub.j.
[0281] Now, different usages of the same credential can be linked
to each other but not to the user's pseudonym with the issuing
organization. This allows to prevent users from using the same
credential several times, if the verifier checks with the issuing
organization whether H.sub.U.sup.O.sup.j was already used or not,
similar as it is done for anonymous "on-line" e-cash. Off-line
checking could be done as well. As here double usage can only be
detected but not prevented, a mechanism for identifying
"double-users" is required. This could for instance be achieved
using revocation as described in the previous section, or using
similar techniques that are used in for anonymous "off-line" e-cash
(e.g., (Brands, 1993)). The latter could be done such that using a
one-show credential twice would expose the user's secret keys
connected with corresponding pseudonym. Together with
non-transferability this would be quite a strong incentive for the
users not to use one-show credentials twice.
[0282] We now describe how local and global revocation can be
implemented efficiently. To enable local and global revocation each
organization needs a revocation manager. Given the transaction of a
protocol where some user proved possession of a credential issued
by organization O.sub.i, this organization's revocation manager
R.sub.i will have the task to reveal the pseudonym under which the
user is known to O.sub.i. Each of these managers needs to choose
keys of some non-malleable public key encryption scheme. The
managers' public keys become part of the respective organizations'
public keys. In the following we describe how the protocols for
proving possession of a credential must be adapted such that local
revocation is possible using Cramer-Shoup encryption (Cramer and
Shoup, 1998). We then discuss global revocation. We remark that it
can be decided at the time when the possession of a credential is
proved whether local and/or global revocation shall be possible for
the transaction at hand.
[0283] Setup: Each R.sub.i chooses a group H.sub.R.sub.i of (large)
prime order q.sub.R.sub.i, two provably random generators
g.sub.R.sub.i and h.sub.R.sub.i, and five secret keys
x.sub.(1,R.sub.i.sub.).sub.1 . . . , x.sub.(5,R.sub.i.sub.)
.di-elect cons..sub.R.sub.R.sub.i and computes
(y.sub.(1,R.sub.i.sub.), y.sub.(2,R.sub.i.sub.),
y.sub.(3,R.sub.i.sub.)):=(g.sub.R.sub.i.sup.x(1,R.sup.i.sup.)h.sub.R.sub.-
i.sup.x(2,R.sup.i.sup.),
g.sub.R.sub.i.sup.x(3,R.sup.i.sup.)h.sub.R.sub.i.sup.x(4,R.sup.i.sup.),
g.sub.R.sub.i.sup.x(5,R.sup.i.sup.)) as his public key.
[0284] Protocol 1 is extended by the following steps. [0285] 1:8, U
computes P U R i = g R i x U .times. h R i s U O i ##EQU13## if
i.noteq.0 and P.sub.U.sup.R.sup.0=g.sub.R.sub.0.sup.x.sup.U
otherwise. U sends P.sub.U.sup.R.sup.i to O.sub.i. [0286] 1:9. U
engages with O.sub.i in PK{(.alpha.,
.beta.):(P.sub.U.sup.O.sup.i).sup.2=(a.sub.O.sub.i.sup.2).sup..alpha.(b.s-
ub.O.sub.i.sup.2).sup..beta..LAMBDA.P.sub.U.sup.R.sup.i=g.sub.R.sub.i.sup.-
.alpha.h.sub.R.sub.i.sup..beta.} [0287] if i.noteq.0 and
PK{(.alpha.,
.beta.):(P.sub.U.sup.O.sup.0).sup.2=(a.sub.O.sub.0.sup.2).sup..alpha.(b.s-
ub.O.sub.0.sup.2).sup..beta..LAMBDA.P.sub.U.sup.R.sup.0=g.sub.R.sub.0.sup.-
a} [0288] otherwise, [0289] 1:10. Both O.sub.i and U store
P.sub.U.sup.R.sup.4 with P.sub.U.sup.O.sup.i.
[0290] Let m.sub.j be some agreed-upon text describing under which
condition R.sub.j is allowed to revoke the anonymity of the
transaction of which the current execution of Protocol 3 or 4 is
part of, respectively. In the following we provide the steps to be
executed after Protocol 3 or 4 in order to get local and/or global
revocation,
[0291] Protocol 6 (Local Revocation). [0292] 6:1. U chooses r.sub.1
.di-elect cons..sub.R.sub.R.sub.j and computes c ( 1 , U ) R j := g
R j r 1 , c ( 2 , U ) R j := h R j r 1 , c ( 3 , U ) R j := y ( 3 ,
R j ) r 1 .times. P U R j , and .times. .times. c ( 4 , U ) R j :=
y ( 1 , R j ) r 1 .times. y ( 2 , R j ) r .times. 1 .times. H
.function. ( c ( 1 , .times. U ) .times. R j , c ( 2 , .times. U )
.times. R j , c ( 3 , .times. U ) .times. R j , m .times. j )
.times. .times. .times. and .times. .times. sends .times. .times. (
c ( 1 , U ) R j , .times. c ( 2 , U ) R j , c ( 3 , U ) R j , c ( 4
, U ) R j ) .times. .times. to .times. .times. V . ##EQU14## [0293]
6:2. U and V engage in PK .times. { ( .alpha. , .beta. , .gamma. ,
.delta. , ) : d O j 2 = ( A 2 ) .alpha. .times. ( 1 / ( a O j 2 ) )
.beta. .times. ( 1 / ( b O j 2 ) ) .gamma. .times. ( 1 / ( h O j 2
) ) .delta. c ( 1 , U ) R j = g R j c ( 2 , U ) R j = h R j c ( 3 ,
U ) R j = g R i .beta. .times. h R i .gamma. .times. y ( 3 , R j )
c ( 4 , U ) R j = ( y ( 1 , R j ) .times. y ( 2 , R j ) H
.function. ( c ( 1 , U ) R j , c ( 2 , U ) R j , c ( 3 , U ) R j ,
m j ) ) } ##EQU15##
[0294] Protocol 7 (Global Revocation). [0295] 7:1. U chooses
r.sub.2 .di-elect cons..sub.R.sub.R.sub.0 and computes c ( 1 , U )
R 0 := g R 0 r 2 , c ( 2 , U ) R 0 := h R 0 r 2 , c ( 3 , U ) R 0
:= y ( 3 , R 0 ) r 2 .times. P U R 0 ) , and .times. .times. c ( 4
, U ) R 0 := y ( 1 , R 0 ) r 2 .times. y ( 2 , R 0 ) r 2 .times. H
.function. ( c ( 1 , .times. U ) .times. R 0 , c ( 2 , .times. U )
.times. R 0 , c ( 3 , .times. U ) .times. R 0 , m 0 ) .times.
.times. .times. and .times. .times. sends .times. .times. ( c ( 1 ,
U ) R 0 , .times. c ( 2 , U ) R 0 , c ( 3 , U ) R 0 , c ( 4 , U ) R
0 ) .times. .times. to .times. .times. V . ##EQU16## [0296] 7:2. U
and V engage in PK .times. { ( .alpha. , .beta. , .gamma. , .delta.
, ) : d O j 2 = ( A 2 ) .alpha. .times. ( 1 / ( a O j 2 ) ) .beta.
.times. ( 1 / ( b O j 2 ) ) .gamma. .times. ( 1 / ( h O j 2 ) )
.delta. c ( 1 , U ) R 0 = g R 0 c ( 2 , U ) R 0 = h R 0 c ( 3 , U )
R 0 = g R 0 .beta. .times. y ( 3 , R 0 ) c ( 4 , U ) R 0 = ( y ( 1
, R 0 ) .times. y ( 2 , R 0 ) H .function. ( c ( 1 , U ) R 0 , c (
2 , U ) R 0 , c ( 3 , U ) R 0 , m 0 ) ) } ##EQU17##
REFERENCES
[0297] Asokan, N., Shoup, V., and Waidner, M. (2000). Optimistic
fair exchange of digital signatures. IEEE Journal on Selected Areas
in Communications, 18(4):591-410.
[0298] Ateniese, G., Camenisch, J., Joye, M., and Tsudik, G.
(2000). A practical and provably secure coalition-resistant group
signature scheme. In Bellare, M., editor, Advances in
Cryptology--CRYPTO 2000, volume 1880 of Lecture Notes in Computer
Science, pages 255-270. Springer Verlag.
[0299] Bari , N. and Pfitzmann, B. (1997). Collision-free
accumulators and fail-stop signature schemes without trees. In
Fumy, W., editor, Advances in Cryptology--EUROCRYPT '97, volume
1233 of Lecture Notes in Computer Science, pages 480-494. Springer
Verlag.
[0300] Bellare, M. and Rogaway, P. (1993). Random oracles are
practical: A paradigm for designing efficient protocols. In First
ACM Conference on Computer and Communication Security, pages 62-73.
Association for Computing Machinery.
[0301] Boudot, F. (2000). Efficient proofs that a committed number
lies in an interval. In Preneel, B., editor, Advances in
Cryptology--EUROCRYPT 2000, volume 1807 of Lecture Notes in
Computer Science, pages 431-444. Springer Verlag.
[0302] Brands, S. (1993). Electronic cash systems based on the
representation problem in groups of prime order. In Preproceedings
of Advances in Cryptology--CRYPTO '93, pages 26.1-26.15.
[0303] Brickell, E. F., Chaum, D., Damg ard, I. B., and van de
Graaf, J. (1988). Gradual and verifiable release of a secret. In
Pomerance, C., editor, Advances in Cryptology--CRYPTO '87, volume
293 of Lecture Notes in Computer Science, pages 156-166.
Springer-Verlag.
[0304] Camenisch, J. and Damg ard, I. (1998). Verifiable encryption
and applications to group signatures and signature sharing.
Technical Report RS-98-32, BRICS, Departement of Computer Science,
University of Aarhus.
[0305] Camenisch, J. and Michels, M. (1998). A group signature
scheme with improved efficiency. In Ohta, K. and Pei, D., editors,
Advances in Cryptology--ASIACRYPT '98, volume 1514 of Lecture Notes
in Computer Science, pages 160-174. Springer Verlag.
[0306] Camenisch, J. and Michels, M. (1999a). Proving in
zero-knowledge that a number n is the product of two safe primes.
In Stern, J., editor, Advances in Cryptology--EUROCRYPT '99, volume
1592 of Lecture Notes in Computer Science, pages 107-122. Springer
Verlag.
[0307] Camenisch, J. and Michels, M. (1999b). Separability and
efficiency for generic group signature schemes. In Wiener, M.,
editor, Advances in Cryptology--CRYPTO '99, volume 1666 of Lecture
Notes in Computer Science, pages 413-430. Springer Verlag.
[0308] Camenisch, J. and Stadler, M. (1997). Efficient group
signature schemes for large groups. In Kaliski, B., editor,
Advances in Cryptology--CRYPTO '97, volume 1296 of Lecture Notes in
Computer Science, pages 410-424. Springer Verlag.
[0309] Chaum, D. (1983). Blind signatures for untraceable payments.
In Chaum, D., Rivest, R. L., and Sherman, A. T., editors, Advances
in Cryptology--Proceedings of CRYPTO '82, pages 199-203. Plenum
Press.
[0310] Chaum, D. (1991). Zero-knowledge undeniable signatures. In
Damg ard, I. B., editor, Advances in Cryptology--EUROCRYPT '90,
volume 473 of Lecture Notes in Computer Science, pages 458-464.
Springer-Verlag.
[0311] Chaum, D., Evertse, J.-H., and van de Graaf, J. (1988). An
improved protocol for demonstrating possession of discrete
logarithms and some generalizations. In Chaum, D. and Price, W. L.,
editors, Advances in Cryptology--EUROCRYPT '87, volume 304 of
Lecture Notes in Computer Science, pages 127-141.
Springer-Verlag.
[0312] Chaum, D. and Pedersen, T. P. (1993). Wallet databases with
observers. In Brickell, E. F., editor, Advances in
Cryptology--CRYPTO '92, volume 740 of Lecture Notes in Computer
Science, pages 89-105. Springer-Verlag.
[0313] Cramer, R. and Shoup, V. (1998). A practical public key
cryptosystem provably secure against adaptive chosen ciphertext
attack. In Krawczyk, H., editor, Advances in Cryptology--CRYPTO
'98, volume 1642 of Lecture Notes in Computer Science, pages 13-25,
Berlin. Springer Verlag.
[0314] Cramer, R. and Shoup, V. (1999). Signature schemes based on
the strong rsa assumption. In Proc. 6th ACM Conference on Computer
and Communications Security, pages 46-52. ACM press.
[0315] ElGamal, T. (1985). A public key cryptosystem and a
signature scheme based on discrete logarithms. In Blakley, G. R.
and Chaum, D., editors, Advances in Cryptology--CRYPTO '84, volume
196 of Lecture Notes in Computer Science, pages 10-18. Springer
Verlag.
[0316] Fiat, A. and Shamir, A. (1987). How to prove yourself:
Practical solution to identification and signature problems. In
Odlyzko, A. M., editor, Advances in Cryptology--CRYPTO '86, volume
263 of Lecture Notes in Computer Science, pages 186-194. Springer
Verlag.
[0317] Fujisaki, E. and Okamoto, T. (1997). Statistical zero
knowledge protocols to prove modular polynomial relations. In
Kaliski, B., editor, Advances in Cryptology--CRYPTO '97, volume
1294 of Lecture Notes in Computer Science, pages 16-30. Springer
Verlag.
[0318] Fujisaki, E. and Okamoto, T. (1998). A practical and
provably secure scheme for publicly verifiable secret sharing and
its applications. In Nyberg, K., editor, Advances in
Cryptology--EUROCRYPT '98, volume 1403 of Lecture Notes in Computer
Science, pages 32-46. Springer Verlag.
[0319] Gennaro, R., Halevi, S., and Rabin, T. (1999). Secure
hash-and-sign signatures without the random oracle. In Stern, J.,
editor, Advances in Cryptology--EUROCRYPT '99, volume 1592 of
Lecture Notes in Computer Science, pages 123-139. Springer
Verlag.
[0320] Pointcheval, D. (1996). Les Preuves de Connaissance et leurs
Preuvies de Securite. PhD thesis, Universite de Caen.
[0321] Schnorr, C. P. (1991). Efficient signature generation for
smart cards. Journal of Cryptology, 4(3):239-252.
* * * * *