5 ePassport and eID Technologies
91
:
r
e
d
a
e
r
:
D
I
e
choose y C R Z ∗
q
choose y R R Z ∗
q
Y C = g y C
Y R
Y R = g y R
abort if Y R
∈ g\{1}
Y C
abort if Y C
∈ g\{1}
h = Y
y C
R
h = Y
y R
C
ˆ
g = h · g s
ˆ
g = h · g s
Fig. 5.2 Generic mapping of PACE
combines PACE with authentication of the eID [298]. The initial part of the protocol
is exactly the same as in the case of PACE Generic Mapping (see Fig. 5.2)—which
is important for reasons of backwards compatibility and the costs of upgrading the
protocols. However, in the final part of the protocol the eID must show the discrete
logarithm of its challenge Y C with respect to its public key pk C as the generator.
Note that the eID cannot pass the protocol without being able to derive h and this
requires knowledge of y C such that Y C = g y C . As the eID has to present a w such
that Y C = pk w
C , it follows that pk C = g y C /w where y C and w are both known to the
eID. Consequently, after checking that Y C = pk w
C the terminal can safely conclude
that the eID knows the discrete logarithm of pk C .
Leakage Resistance The protocol PACE-CAM may serve as an example of a
possible defense against malicious or poor implementations. One of the critical
threats for this protocol is the danger of leaking the discrete logarithm of pk C
(thereby enabling cloning of the eID concerned).
Assume that during protocol execution the eID first chooses y C and later
computes w = y C /sk C (as in [73]). Then obviously the key sk C is exposed in
case a weak random number generator has created y C . In [257] the computations
are performed in a slightly different way. Namely, Y C = pk w
C , for w chosen at
random, and there is no computation of w during the final stage. The most important
feature is that the value y C does not appear at all. However, the element h has to be
computed by the eID in a slightly different way: instead of computing h = Y
y C
R ,
the eID computes h = (Y w
R ) sk C . The exponentiation with sk C can be executed in a
separate hardware zone which performs no other operation. In this way the secret
key sk C is essentially secure even if the adversary has access to all values outside
this hardware zone.
Particular care is needed in the case of protocols using signatures such as DSA
and Schnorr. In this case leakage of ephemeral random values leads to leakage of the
long time secret keys and it seems that there is no simple remedy for this problem.
91
:
r
e
d
a
e
r
:
D
I
e
choose y C R Z ∗
q
choose y R R Z ∗
q
Y C = g y C
Y R
Y R = g y R
abort if Y R
∈ g\{1}
Y C
abort if Y C
∈ g\{1}
h = Y
y C
R
h = Y
y R
C
ˆ
g = h · g s
ˆ
g = h · g s
Fig. 5.2 Generic mapping of PACE
combines PACE with authentication of the eID [298]. The initial part of the protocol
is exactly the same as in the case of PACE Generic Mapping (see Fig. 5.2)—which
is important for reasons of backwards compatibility and the costs of upgrading the
protocols. However, in the final part of the protocol the eID must show the discrete
logarithm of its challenge Y C with respect to its public key pk C as the generator.
Note that the eID cannot pass the protocol without being able to derive h and this
requires knowledge of y C such that Y C = g y C . As the eID has to present a w such
that Y C = pk w
C , it follows that pk C = g y C /w where y C and w are both known to the
eID. Consequently, after checking that Y C = pk w
C the terminal can safely conclude
that the eID knows the discrete logarithm of pk C .
Leakage Resistance The protocol PACE-CAM may serve as an example of a
possible defense against malicious or poor implementations. One of the critical
threats for this protocol is the danger of leaking the discrete logarithm of pk C
(thereby enabling cloning of the eID concerned).
Assume that during protocol execution the eID first chooses y C and later
computes w = y C /sk C (as in [73]). Then obviously the key sk C is exposed in
case a weak random number generator has created y C . In [257] the computations
are performed in a slightly different way. Namely, Y C = pk w
C , for w chosen at
random, and there is no computation of w during the final stage. The most important
feature is that the value y C does not appear at all. However, the element h has to be
computed by the eID in a slightly different way: instead of computing h = Y
y C
R ,
the eID computes h = (Y w
R ) sk C . The exponentiation with sk C can be executed in a
separate hardware zone which performs no other operation. In this way the secret
key sk C is essentially secure even if the adversary has access to all values outside
this hardware zone.
Particular care is needed in the case of protocols using signatures such as DSA
and Schnorr. In this case leakage of ephemeral random values leads to leakage of the
long time secret keys and it seems that there is no simple remedy for this problem.