Information Technology Reference
In-Depth Information
5.2
Forgery of a User's Pseudonym (Impersonation)
Another central problem of pseudonyms (presented in this paper) is, that a
pseudonym which has been disclosed to a verifier may be used by the verifier
to impersonate its original holder. This is possible, because after disclosure the
verifier knows
d
,
p
,and
q
. Hence he can act like the original holder; he may use
and disclose the 'stolen' pseudonym to proof the ownership, which enables him
to impersonate the original holder.
A straight-forward solution for this problem is to sign the ID-Block (
UID
||
Data
||
PAD
) and to replace the original ID-Block by the new ID-Block
UID
||
Validity
PAD
.HereSIGN
d
s
(
m
)
is the signature of the hash value of
m
using the private signing key (
d
s
,n
s
)
with the according public verification key (
e
s
,n
s
). The value
Validity
holds the
time of generation (i.e. the time, the pseudonym was requested by some applica-
tion) and the time-to-live of the pseudonym. These values may be used to check
the freshness of a presented (and disclosed) pseudonym, after the signature has
been verified by use of the public key which may be retrieved from a certificate
issued by a trusted certification authority. A drawback of this approach is, that
only the application that requested the pseudonym is able to verify the value of
Validity
. All other applications which also use the pseudonym do not know the
point in time when the pseudonym has been requested (and generated). Hence,
they cannot verify the freshness.
If the freshness of the pseudonym cannot be checked by the application using
the pseudonym, we need some other mechanism to avoid the reuse of a previ-
ously disclosed pseudonym. Now, the verifier of the pseudonym simply checks
if the presenter (i.e. the supposed holder) of the pseudonym has generated the
signature within the pseudonym. This can again be checked by verifying, that
the holder knows the according private key (
d
s
,n
s
). As above, we will employ a
challenge-response protocol to accomplish this proof.
The certificates used to sign the ID-Block, show a method to retrieve a unique
user identifier. This identifier may be the distinguished name of the certificate
issuer concatenated with the distinguished name of the owner of the certificate.
It would be more practical to replace the distinguished name of the owner of
the certificate by the serial number of the certificate. Since the verifier of a
disclosed pseudonym knows the issuer and the serial number, he may retrieve
the according certificate and use the public key to check (as described above), if
the supposed holder of the pseudonym knows the private signing key. If we use
this method, there is no need to include a signature in the pseudonym. In order
to verify a presented pseudonym, it is sucient to check that the presenter of
the pseudonym knows the private key belonging to the certificate holding the
identifier of the pseudonym's holder.
||
Data
||
SIGN
d
s
(
UID
||
Validity
||
Data
||
PAD
)
||
6
Analysis of the Proposed Scheme
For security reasons (i.e. to withstand factorization) the length of a modulus
(which is the product of two primes) has to be significantly larger than 512 bit
