Dynamic Data Authentication (DDA)
Dynamic Data Authentication (DDA) is a more securer way of authentication because it authenticates the card itself. After the authentication we can trust on the uniqueness of the card.
Contrast between SDA and DDA
SDA guarantees that data on cards is valid because we trust a high level certification authority which signs the data. But an attacker can record a card session and build for example a new virtual card.
In contrast to SDA the card creates during the DDA process an own signature with their private key (SIC). This signature is different in every card session because it contains a random number generated by the terminal. The corresponding public key is stored in an ICC Public Key Certificate signed by the Certification Authority. With the public key we can proof the signature on genuineness.
Authentication Process
The dynamic authentication process is related to SDA.
With PCA the terminal proofs the signature of the Issuer PK Certificate and extract the P1 key. The terminal proofs with P1 the signature of the ICC PK Certificate to get the PIC key. Now it is time to send an Internal Authenticate command to the card that contains a random number and initiates the card to compute the signature (Signed Dynamic Application Data/SDAD). With the PIC key the terminal checks the SDAD for guineness.
Retrieval of ICC Public Key (PIC)
The retrieval of ICC Public Key starts after the Retrieval of Certification Authority Public Key and Retrieval of Issuer Public Key described in the chapter SDA.
First we have to decrypt the ICC Public Key Certificate.
The decrypted certificate contains the following data:
Field Name | Length | Description |
---|---|---|
Recovered Data Header | 1 | Hex Value ‘6A’ |
Certificate Format | 1 | Hex Value ’04’ |
Application PAN | 10 | PAN (padded to the right with Hex ‘F’s) |
Certificate Expiration Date | 2 | MMYY after which this certificate is invalid |
Certificate Serial Number | 3 | Binary number unique to this certificate assigned by the issuer |
Hash Algorithm Indicator | 1 | Identifies the hash algorithm used to produce the Hash Result in the digital signature scheme |
ICC Public Key Algorithm Indicator | 1 | Identifies the digital signature algorithm to be used with the ICC Public Key |
ICC Public Key Length | 1 | Identifies the length of the ICC Public Key Modulus in bytes |
ICC Public Key Exponent Length | 1 | Identifies the length of the ICC Public Key Exponent in bytes |
ICC Public Key or Leftmost Digits of the ICC Public Key* | NI – 42 | If NIC <= NI – 42, consists of the full ICC Public Key padded to the right with NI – 42- NIC bytes of value ‘BB’. If NIC > NI – 42, consists of the NI – 42 most significant bytes of the ICC Public Key |
Hash Result | 20 | Hash of the ICC Public Key and its related information |
Recovered Data Trailer | 1 | Hex value ‘BC’ |
With step 1 to 4 we check whether the decryption was succesfull.
Step 1: ICC Public Key Certificate and Issuer Public Key Modulus have the same length
Step 2: The Recovered Data Trailer is equal to ‘BC’
Step 3: The Recovered Data Header is equal to ‘6A’
Step 4: The Certificate Format is equal to ’04’
Step 5 implements the concatenation which is necessary to apply the hash algorithm in the next step.
For the concatenation we need from the ICC Public Key Certificate:
- Certificate Format
- Application PAN
- Certificate Expiration Date
- Certificate Serial Number
- Hash Algorithm Indicator
- ICC Public Key Algorithm Indicator
- ICC Public Key Lnegth
- ICC Public Key Exponent Length
- ICC Public Key or Leftmost Digits of the ICC Public Key
Also we need
- ICC Public Key Remainder (if present)
- ICC Public Key Exponent
- Data located by the AFL
- SDA Tag List
Step 6: Generate hash from concatenation.
Step 7: Compare recovered hash with generated hash.
Step 8: Verify that the Issuer Identifier matches the lefmost 3-8 PAN digits.
Step 9: Verify that the last day of the month specified in the Certification Expiration Date is equal to or later than today’s date.
Step 10: Check the ICC Public Key Algorithm Indicator
Step 11: Concatenate the Leftmost Digits of the ICC Public Key and the ICC Public Key Remainder (if present) to obtain the ICC Public Key Modulus
Dynamic Data Authentication
Internal Authenticate
The Internal Authenticate command initiates the card to sign with their Privat Key (SIC) Dynamic Application Data and a random number generated by the terminal. The card will return the Signed Dynamic Application Data.
Structure of the Internal Authenticate command:
Code | Value |
---|---|
CLA | ’00’ |
INS | ’88’ |
P1 | ’00’ |
P2 | ’00’ |
Lc | Length of authentication-related data |
Data | Authentication-related data (random number) |
Le | ’00’ |
Signed Dynamic Application Data
Now we decode the Signed Dynamic Application Data
Field Name | Length | Description |
---|---|---|
Recovered Data Header | 1 | Hex value ‘6A’ |
Signed Data Format | 1 | Hex value ’05’ |
Hash Algorithm Indicator | 1 | Identifies the hash algorithm used to produce the Hash Result in the digital signature scheme |
ICC Dynamic Data Length | 1 | Identifies the length of the ICC Dynamic Data in bytes |
ICC Dynamic Data Length | LDD | Dynamic data generated by and/or stored in the ICC |
Pad Pattern | NIC – LDD – 25 | (NIC – LDD – 25) padding bytes of value ‘BB’ |
Hash Result | 20 | Hash of the Dynamic Application Data and its related infromation |
Recovered Data Trailer | 1 | Hex value’BC’ |
If the following 7 steps were successful, DDA was successful.
Step 1: SDAD and ICC Public Key Modulus have the same length
Step 2: The Recovered Data Trailer is equal to ‘BC’
Step 3: The Recovered Data Header is equal to ‘6A’
Step 4: The Signed Data Format is equal to ’05’
Step 5: Concatenation of Signed Data Format, Hash Algorithm Indicator, ICC Dynamic Data Length, ICC Dynamic Data, Pad Pattern, random number
Step 6: Genereate hash from concatenation
Step 7: Compare recovered hash with generated hash