92
L. Hanzlik and M. Kutyłowski
5.3.4 Authenticating the Terminal and Its Rights
A terminal that has guessed or knows the activation password of an eID may attempt
to read sensitive data from the eID. Since it knows the activation password it can
interact with the eID, but should not necessarily be able to access all data. This
problem is solved by Terminal Authentication v.2 (TA v.2), which in fact is a
standard challenge-response protocol: the eID generates a random nonce and the
terminal responds with a signature of this nonce and a fingerprint of an ephemeral
public key—this public key is the challenge for the static Diffie-Hellman key
agreement executed as part of ChA v.2. For the sake of signature verification the
terminal presents a certificate of its public key. The certificate declares in particular
which data from the eID the terminal is allowed to read. To verify the authenticity of
the certificate, the document verifies a chain of certificates supplied by the terminal.
The first supplied certificate is verified using the root of trust, i.e., a public key of
the issuer stored inside the eID (for details see Sect. 5.4).
5.3.5 Proof of Interaction
In this scenario we consider a malicious reader/terminal that tries to sell a transcript
of communications or interactions to a third party. Such a transcript may contain
valuable information about the document owner (e.g., location, services used). The
best protection one can achieve is that a reader/terminal can create a protocol
transcript (including values normally available only to the reader/terminal) that is
indistinguishable from transcripts originating from real executions. This should also
concern executions where a reader/terminal deviates from the protocol description.
Then a transcript presented by a reader/terminal has no value to a third party.
In general, any protocol implemented in an eID should support deniability:
neither the eID nor the terminal/reader should be able to prove that an interaction
with the eID has taken place and had a given form. Note that AA provides a strong
proof of interaction for third parties, while for ChA v.2, PACE, PACE-CAM the
deniability property is fulfilled. For TA v.2 a signature collected from the terminal
is a proof of interaction (with an unspecified eID).
5.3.6 Passive Tracing
Protocols such as PA enable tracing—an eID responds with explicit identification
data. The situation is slightly better for BAC. However, once the adversary learns the
secret key used by the eID of the traced person to set up connections, the adversary
can make trial decryptions of all recorded communications and identify those of
the traced eID. The situation is different for protocols such as PACE and PACE-
L. Hanzlik and M. Kutyłowski
5.3.4 Authenticating the Terminal and Its Rights
A terminal that has guessed or knows the activation password of an eID may attempt
to read sensitive data from the eID. Since it knows the activation password it can
interact with the eID, but should not necessarily be able to access all data. This
problem is solved by Terminal Authentication v.2 (TA v.2), which in fact is a
standard challenge-response protocol: the eID generates a random nonce and the
terminal responds with a signature of this nonce and a fingerprint of an ephemeral
public key—this public key is the challenge for the static Diffie-Hellman key
agreement executed as part of ChA v.2. For the sake of signature verification the
terminal presents a certificate of its public key. The certificate declares in particular
which data from the eID the terminal is allowed to read. To verify the authenticity of
the certificate, the document verifies a chain of certificates supplied by the terminal.
The first supplied certificate is verified using the root of trust, i.e., a public key of
the issuer stored inside the eID (for details see Sect. 5.4).
5.3.5 Proof of Interaction
In this scenario we consider a malicious reader/terminal that tries to sell a transcript
of communications or interactions to a third party. Such a transcript may contain
valuable information about the document owner (e.g., location, services used). The
best protection one can achieve is that a reader/terminal can create a protocol
transcript (including values normally available only to the reader/terminal) that is
indistinguishable from transcripts originating from real executions. This should also
concern executions where a reader/terminal deviates from the protocol description.
Then a transcript presented by a reader/terminal has no value to a third party.
In general, any protocol implemented in an eID should support deniability:
neither the eID nor the terminal/reader should be able to prove that an interaction
with the eID has taken place and had a given form. Note that AA provides a strong
proof of interaction for third parties, while for ChA v.2, PACE, PACE-CAM the
deniability property is fulfilled. For TA v.2 a signature collected from the terminal
is a proof of interaction (with an unspecified eID).
5.3.6 Passive Tracing
Protocols such as PA enable tracing—an eID responds with explicit identification
data. The situation is slightly better for BAC. However, once the adversary learns the
secret key used by the eID of the traced person to set up connections, the adversary
can make trial decryptions of all recorded communications and identify those of
the traced eID. The situation is different for protocols such as PACE and PACE-