Dynamic Data Authentication (DDA and CDA)

6.6 Dynamic Data Authentication (DDA and CDA)

During dynamic data authentication processing, the terminal uses RSA public key technology to determine whether key data elements from the card have been altered since card personalization and whether the card is counterfeit.

VIS supports two forms of dynamic data authentication: DDA and CDA. With both, the terminal validates that static card data has not been altered and also validates a dynamic cryptogram generated by the card. With DDA, the card generates the dynamic signature using dynamic terminal, card, and transaction data in response to an INTERNAL

AUTHENTICATE command received prior to Card Action Analysis. With CDA, the card responds to the first GENERATE AC command received during Card Action Analysis (and if requested, also to the second GENERATE AC command received during

Completion) by generating a dynamic signature that includes the Application Cryptogram and Cryptogram Information Data as well as the dynamic terminal, card, and transaction data used for DDA.

Note: CDA is described in the EMV specifications. It is optional in VIS (as it is in EMV), and is not discussed in detail in this document. For more information, see the EMV specifications and bulletins.

The Card Data has been combined into a single table for SDA, DDA, and CDA. See section 6.2. The Terminal Data has been moved to section 6.3.

6.6.1 Commands

6.6.1.1 INTERNAL AUTHENTICATE Command

The terminal issues the INTERNAL AUTHENTICATE command during DDA processing.

The command includes the terminal dynamic data specified in the DDOL or Default DDOL.

If the length of data received in the INTERNAL AUTHENTICATE command from the terminal is different from the length of data expected by the card, the card shall

discontinue processing the INTERNAL AUTHENTICATE command and shall return an SW1 SW2 error code to the terminal. The SW1 SW2 error code should be '6700' (Wrong Length).

When the card receives the INTERNAL AUTHENTICATE command, it generates the Signed Dynamic Application Data which it signs with the ICC Private Key. This dynamic signature is included in the INTERNAL AUTHENTICATE command response. Either Format 1 or Format 2 shall be used for the response data.

Visa Integrated Circuit Card Specification (VIS) 6 Offline Data Authentication

Version 1.5 6.6 Dynamic Data Authentication (DDA and CDA)

6.6.1.2 GENERATE APPLICATION CRYPTOGRAM (AC) Command

The terminal issues the first GENERATE AC command during Card Action Analysis processing. The transaction is eligible for CDA if bit 6 of the P1 byte is set to 1b, indicating that a CDA signature is requested by the terminal.

If the transaction is eligible for CDA, then a TC or ARQC returned by the card shall be contained within a cryptographic envelope as described in EMV Book 2, section 6.6.1.

See Chapter 11, Card Action Analysis, for additional information on this command.

6.6.2 Processing

During offline dynamic data authentication processing, the terminal uses RSA public key technology to validate the Issuer PK Certificate, the ICC PK Certificate, and the Signed Dynamic Application Data (the dynamic signature) from the card.

The only function performed by the card during offline dynamic data authentication processing is the generation of the dynamic signature.

DDA and CDA processing are described in more detail in EMV Book 2, section 6, EMV Book 3, section 10.3, and EMV Book 4, section 6.3.2. The following sections provide an overview of the DDA and CDA processes. For detailed information about CDA, see the EMV specifications and bulletins.

6.6.2.1 DDA

DDA processing requires the following steps:

1. Retrieval of CA Public Key

The terminal uses the Registered Application Provider Identifier (RID) and the CA Public Key Index (PKI) to locate the Visa CA Public Key to be used for DDA.

2. Retrieval of Issuer Public Key

The terminal uses the Visa CA Public Key to unlock the Issuer PK Certificate to recover the Issuer Public Key.

3. Retrieval of ICC Public Key

The terminal uses the Issuer Public Key to unlock the ICC PK Certificate and recover the ICC Public Key and the hash of static data. This certificate guarantees the legitimacy of the ICC Public Key. The terminal recalculates the static data hash using the actual data elements received in the clear from the card earlier in the transaction and checks that the calculated hash matches the recovered hash.

6 Offline Data Authentication Visa Integrated Circuit Card Specification (VIS)

6.6 Dynamic Data Authentication (DDA and CDA) Version 1.5

4. Dynamic Signature Generation (DDA only)

The terminal sends the card an INTERNAL AUTHENTICATE command requesting a dynamic signature. This command includes the data requested by the card in the DDOL.

Upon receiving the INTERNAL AUTHENTICATE command, the card shall:

a. Set the ‘Offline dynamic data authentication performed’ bit of the CVR to 1b.

Note: Instead of using the CVR bit as an indicator, implementations may instead set an internal application indicator for the above listed condition if the specified CVR bit is set to the required value during Card Risk

Management processing in the Card Action Analysis for the same transaction.

b. Concatenate the terminal data received in the INTERNAL AUTHENTICATE command and the card data specified in the ICC Dynamic Data with other data.

EMV Book 2, Table 14, shows the format of the concatenation.

c. Generate a hash value from the data concatenated above.

d. Include the hash in the Signed Dynamic Application Data.

e. Sign the Signed Dynamic Application Data with the ICC Private Key.

f. Return the Signed Dynamic Application Data to the terminal in the INTERNAL AUTHENTICATE response.

5. Dynamic Signature Verification (DDA only)

To validate the dynamic signature, the terminal does the following:

a. Uses the ICC Public Key to unlock the dynamic signature (Signed Dynamic Application Data) and recover the hash of data elements.

b. Calculates a hash from the dynamic data elements which are in the clear.

c. Checks that the calculated hash matches the hash recovered from the Signed Dynamic Application Data.

If all of the above steps are successful, then DDA has passed.

Visa Integrated Circuit Card Specification (VIS) 6 Offline Data Authentication

Version 1.5 6.7 Prior Related Processing

6.6.2.2 CDA

CDA requires the following processing:

 The terminal performs Steps 1 to 3 of DDA processing after Read Application Data and prior to Terminal Action Analysis.

 The remaining card step of CDA is the generation of the dynamic signature containing the Application Cryptogram. This step occurs when the first GENERATE AC is received during Card Action Analysis and is described in Chapter 11, Card Action Analysis. This inclusion of the Application Cryptogram in a dynamic signature only occurs when the transaction is eligible for CDA as shown in the GENERATE AC command and the Application Cryptogram is an ARQC or TC.

 The remaining terminal step of CDA is the validation of the dynamic signature which occurs during Online Processing. If the validation of the dynamic signature fails, then the transaction is declined offline by the terminal.

 When CDA is requested in the first GENERATE AC, it also may be requested in the second GENERATE AC according to the rules in Chapter 13.

6.7 Prior Related Processing

Read Application Data

The terminal reads the application data from the card. For cards supporting SDA, this data includes the Issuer PK Certificate, other key-related data, and the Signed Static Authentication Data (SAD). For cards supporting DDA or CDA, the DDOL, ICC PK Certificate, and other ICC key-related data are also included. A list of static data to be authenticated is built from the AFL indicators showing the records involved in offline data authentication and from the Static Data Authentication (SDA) Tag List.

6 Offline Data Authentication Visa Integrated Circuit Card Specification (VIS)

6.8 Subsequent Related Processing Version 1.5

6.8 Subsequent Related Processing

Terminal Action Analysis

The terminal uses SDA, DDA, and CDA results and card and terminal parameters to determine whether the transaction should be declined offline, sent online for

authorization, or approved offline.

Card Action Analysis

If CDA is requested by the terminal, then the card puts ARQC and TC responses in an RSA envelope prior to responding to the terminal.

If the Dynamic Data Authentication Failure Indicator is set to 1b, then the card sets the

‘Offline dynamic data authentication failed on last transaction and transaction declined offline’ bit of the CVR to 1b. A similar bit is set if the Static Data Authentication Failure Indicator is set to 1b.

If the current transaction is declined offline and the ‘Offline dynamic data authentication failed’ bit of the TVR received from the terminal is set to 1b, then the card sets the Dynamic Data Authentication Failure Indicator to 1b. A similar indicator is set for SDA.

Online Processing

If CDA is requested by the terminal and the card response to the first GENERATE AC is a TC or ARQC, then the terminal recovers and validates the data in the RSA signature envelope in the GENERATE AC response.

Completion

The Static Data Authentication Failure Indicator and Dynamic Data Authentication Failure Indicator are reset to 0b when the transaction is processed online and Issuer

Authentication is:

 Performed and passed

 Supported, optional (as shown in the Issuer Authentication Indicator), and not performed, or

 Not supported (the Issuer Authentication Indicator is not present).

If the current transaction is declined offline and the ‘CDA failed’ bit of the TVR received from the terminal is set to 1b, then the card sets the Dynamic Data Authentication Failure Indicator to 1b.

Visa Integrated Circuit Card Specification (VIS) 7 Processing Restrictions

Version 1.5