D.7 DDA mechanisms

One possibility of implementing DDA is by using a challenge-response mechanism. For every new execution of the DDA protocol, the verifying entity generates a "fresh" challenge, which is sent to the proving entity. The proving entity applies a cryptographic transformation parameterized by a specific key on the received challenge to elaborate a response, which is sent back to the verifying entity. After assessing the correctness of the response with respect to both the challenge and the cryptographic material, the verifying entity decides whether the proving entity is the one claiming to be. The mechanism prevents replay attacks, since the value of the response is always different for a new challenge, being suitable for implementing the timeliness security service (see Appendix C, Section C.1).

If the proving entity is a chip card, the mechanism precludes the counterfeiting of the card, since only the card that stores the appropriate cryptographic key can compute a correct response to each new challenge. Moreover, the response can prove the legitimacy of critical data stored in the card, covering in this way the functionality of SDA mechanisms, if this critical data is included in the computation of the response.

D.7.1 MAC-based DDA

DDA can be implemented with a MAC primitive (see Section D.2) that uses a session key SSK mutually shared by the proving entity and the verifying entity.

When the proving entity is the chip card (which is operated by the terminal at the point of service) and the verifying entity is the issuer host, the mechanism is also called on-line DDA or even on-line card authentication. The session key SSK is derived for each transaction with respect to a transaction counter TC that changes for each execution of the protocol. The SSK key is derived from a common secret key SK _i associated by the issuer with the card since the personalization stage, and which is stored in the tamperresistant EEPROM of the card.

The protocol of the DDA based on a MAC is as follows . The terminal submits to the card the data describing the conditions of a transaction at the point of service, transaction_data , concatenated with a challenge r that is generated at random for every new transaction. To the information sent by the terminal, the card appends the transaction counter TC , and also some financial data financial_data _i specific to the card, which also contains the card identifier. The card computes the dynamic authenticator Dynamic_Auth _i = MAC ( SSK )[ transaction_data r TC financial_data _i ] and returns it to the terminal. The terminal forwards to the issuer the authorization request auth_req = transaction_data r TC financial_data _i together with the authenticator Dynamic_Auth _i . After receiving the authorization request, the issuer uses the card identifier in the financial_data _i and retrieves the secret key of the card SK _i . Using this key, the issuer recomputes the session key SSK corresponding to the transaction counter TC . The issuer computes the authenticator verification value AVV = MAC ( SSK )[ auth_req ]. The card is considered genuine (not counterfeit) and its critical data authentic if the authenticator verification value computed by the issuer equals the dynamic authenticator sent by the card (i.e., Dynamic_Auth _i = AVV ).

Note that in the case when the acquirer and the card issuer have previously established a business relationship, the computation of the authenticator verification value AVV can be delegated by the issuer to a SAM plugged in the terminal. This is the case when the card is an e-purse and the verifying entity is the POS or ATM terminal at the point of service.

D.7.2 Digital signature “based DDA

If the terminal where the transaction is performed has no possibility of online communication with the issuer and the acquirer responsible for the terminal has no business relationship with the card issuer, a MAC-based DDA is technically not possible. In this case DDA can be implemented with a digital signature scheme.

To this end, the chip card has a hardware architecture that includes a cryptographic coprocessor, which is able to efficiently perform a digital signature. Assume for simplicity that during the personalization stage the issuer generates at random a pair of a private signing key and a public verification key ( KS _card , KV _card ) that are uniquely linked to the card. The issuer uses its private signing key KS _ISS to generate a certificate on the public verification key of the card, Cert_KV _card = Cert ( KS _ISS )[ KV _card ]. This certificate proves the authenticity of the key KV _card and its link to the card. However, since there is no business agreement between the acquirer and card issuer, the terminal has no authentic copy of the public verification key KV _ISS of the issuer, and thus it cannot assess the certificate Cert_KV _card . Therefore, the issuer has to obtain a certificate on its own public verification key KV _ISS from a certification authority, Cert _ KV _ISS = Cert ( KS _CA )[ KV _ISS ], which establishes the authenticity of KV _ISS . The card association can play the role of the CA. The only business constraint is that both the acquirer (which manages the terminal) and the issuer (which is responsible for the card) are members of this card association. The acquirer has to make provisions that an authentic copy of the public verification key of the CA, denoted KV _CA , is loaded in all the terminals.

During the personalization stage, the issuer securely loads in the tamper-resistant EEPROM of the chip card the key pair ( KS _card , KV _card ) together with the certificates needed for assessing the authenticity of KV _card (i.e., Cert_KV _card and Cert _ KV _ISS ). The protocol of the DDA based on a digital signature is as follows. The terminal submits to the card the data describing the environment of a transaction at the point of service, environment_data , concatenated with a challenge r that is generated at random for every new transaction. To the information sent by the terminal, the card appends the financial data financial_data _i specific to the card, the integrity of which has to be checked. The card computes the dynamic authenticator as a digital signature with its private signing key KS _card on the message M = environment_data r financial_data _i (i.e., Dynamic_Auth _i = Sign ( KS _card )[M]). The card forwards the terminal with the dynamic authenticator Dynamic_Auth _i together with KV _card , Cert_KV _card and Cert _ KV _ISS . The terminal verifies the dynamic authenticator as follows:

Using the public verification key KV _CA of the certification authority, recover from the certificate Cert _ KV _ISS the public verification key KV _ISS of the issuer, which can be now accepted as authentic.
Using the public verification key KV _ISS of the issuer, recover from the certificate Cert _ KV _card the public verification key KV _card of the card, which can be now accepted as authentic.
Using the public verification key KV _card of the card, check the dynamic authenticator produced by the card, Verify ( KV _card )[ Dynamic_Auth _i , M ] ?= True . If the verification is passed, the card is considered genuine (not counterfeit) and its critical financial data is accepted as unaltered.

D.7.3 One-time passwords

Another possibility for implementing DDA in devices that do not have cryptographic capabilities is the use of one-time passwords. The limitation of this mechanism, however, is that the verifying entity has to have a business agreement with the issuer of the device implementing the proving entity.

When personalizing the device of the proving entity, the issuer generates an initial seed X , and starting from this value it recurrently applies a hash function H to compute the sequence X _i = H ( X _i _{ˆ’ 1} ), with i = 1, , n . The sequence of arguments { X _i } _{i = 0, , n ˆ’ 1} is stored in the permanent memory of the device implementing the proving entity, which is tamper resistant protected. The issuer transfers to the verifying entity the first hash code X ₁ = H ( X ), from which the verifying entity can compute the sequence of hash codes { H ( X _{i “ 1} )} _{i = 2, , n} . In this setup, the personalization sequence suffices for n executions of the protocol.

The first time the proving entity authenticates to the verifying entity, it will send X _{n “ 1} . The verifying entity applies the hash function H on X _{n “ 1} and compares it with X _n = H ( X _{n “ 1} ) from the sequence of hash codes it computed itself. If the verification holds true, the authentication is successful and both entities delete from the list of passwords X _{n “ 1} and X _n = H ( X _{n “ 1} ), respectively. In the next authentication, the proving entity uses X _{n ˆ’ 2} , while the verifying entity uses X _{n “ 1} = H ( X _{n “ 2} ). The process can be repeated n times until the proving entity uses X while the verifying entity uses X ₁ = H ( X ).