token is valid, anonymously, without leaking informa-
tion about his identity or previous uses of the token.
That is why the authentication phase is anonymous
and unlinkable to previous authentication phases. The
provided proof is always randomized, thus the single
token can be used many times without the concern
about its tracing.
The last protocol is the revelation protocol. This
protocol is executed between AS and PA when some
disputes occur in the system. In that case, AS can con-
tact PA and give proofs about disputes, rule breaking
or e.g. some thefts in his systems. The PA then de-
cides, whether proofs are strong enough, and if yes, it
continues in user revelation. The user can be anony-
mously removed from the system, traced in the sys-
tem (but not identified) or completely identified. The
level of revelation depends on PA, therefore AS can-
not break users’ privacy without proofs of strong pol-
icy violation.
All described protocols are efficient, their com-
plexity does not depend on the number of users. The
authentication protocol, which will be the most used
protocol, is practical for smart-card implementation.
The whole communication pattern is depicted in Fig-
ure 1. The figure also includes cryptographic primi-
tives placement, described in Section 2.3.
2.3 Used Primitives
In this section we provide information on our choice
of used cryptographic primitives together with their
placement in the scheme. In the registration protocol,
the discrete logarithm (DL) commitments and proofs
of representation (Camenisch and Stadler, 1997) are
used during the communication with AS. During the
communication with PA, we use proofs of represen-
tation and Bao’s verifiable encryption (Bao, 2000).
We also assume the existence of a secure signature
scheme, like RSA.
The registration protocol starts with the user
choosing a random number and creating a DL com-
mitment to it. The knowledge of the secret number
is then proven to AS by running the proof of repre-
sentation on the commitment. AS can therefore link
user identity with the commitment, while user’s secret
number remains hidden. AS stores the commitment
in its database and provides the user with the signa-
ture on the commitment. The user then anonymously
contacts PA and anonymously provides the commit-
ment and AS’s signature. He also has to provide the
proof of knowledge of the secret number in the com-
mitment using (Schnorr, 1991). Based on this infor-
mation, PA creates the token with user’s commitment
inside. The token is unlinkable to user’s secret num-
ber and to his commitment for anyone except PA. The
user then transfers the token to his smart-card.
The authentication phase is a proof of represen-
tation (Camenisch and Stadler, 1997; Schnorr, 1991)
of the token, thus a proof of knowledge of a secret
number chosen by the user and a second secret num-
ber given by PA during the registration. Based on
the proof of representation, AS can be efficiently con-
vinced about the right token construction.
The revelation protocol is based on the DL verifi-
able encryption (Bao, 2000). The secret user number
is hidden in a verifiable encryption and given to AS
during the authentication protocol. AS can verify the
construction of the encryption, but is unable to de-
crypt. The only entity able to decrypt is PA, therefore
AS can resend the verifiable encryption to PA, which
is able to decrypt and either remove the user from the
system or release the real identity of the user to PA.
The removal of the user is done by publishing the DL
commitment of users secret value. Such published
values create a ”blacklist” of removed users, who are
no more able to be successfully authenticated.
The described primitives (the verifiable encryp-
tion (VE), commitments (comm) and proofs of rep-
resentation (ZK)) are placed in the scheme as visible
in Figure 1. The detailed description of primitives and
all supporting mechanisms is out of the scope of this
short paper and will be published in the full paper.
3 TESTING SMART-CARD
IMPLEMENTATION
One of our main goals is to provide a scheme effi-
cient enough for a smart-card implementation. The
implementation of modular addition, subtraction or
exponentiation is easy due to low complexity and the
ability to delegate some computations to RSA crypto
co-processor. Multiplication is more difficult to im-
plement since no direct function is available in the
framework. We compared more approaches to mod-
ular multiplication, from paper-and-pencil method,
Comba’s method, Montgomery multiplication to the
trick provided in (Bichsel et al., 2009). From the re-
sults it is obvious that the most efficient method is
the so called RSA tunnel method from (Bichsel et al.,
2009), where multiplication is converted to exponen-
tiation using the binomial formula and then acceler-
ated using the RSA function. This method is intro-
duced for Java smart-cards in (Bichsel et al., 2009).
3.1 Performance Analysis
Based on modular multiplication and exponentiation
PRACTICAL ANONYMOUS AUTHENTICATION - Designing Anonymous Authentication for Everyday Use
407