Introduction

The EFTtools set consist of applications supporting payment transaction service development, testing and benchmarking. It currently consists of following components: Cryptographic Calculator and HSM Commander.

This tutorial focuses on Cryptographic Calculator functionality and is provided in six separated parts as per functionality topics covered by its main menu – Generic, Cipher, Keys, Payments, EMV and Development tools. This tutorial also aspires to provide bits of basic history on algorithms in use.

EMV Cryptography

This set of tools focuses on working with EMV cryptography algorithms used across payments related to their practical usage.

Application Cryptograms

EMV 4.1

EMV Session Key Derivation

Master Key

Generates an Card Authentication Key Unique Derived Key (UDK), which is being used for eg. card’s Master Key personalisation (see EMV Book v4.1. pg. 134 – Option A & B).

EMV Cryptography: UDK derivation finished
****************************************
MDK:                 0123456789ABCDEF0123456789ABCDEF
PAN:                 43219876543210987
PAN sequence nr.:    00
Derivation option:   Option A
Key parity:          Right odd
—————————————-
UDK:                 C8B507136D921FD05864C81F79F2D30B
KCV:                 0DA897

Session Key

The Session key function derives a 16-byte Application Cryptogram Session Key SKAC from the ICC Application Cryptogram Master Key MKAC and the 2-byte Application Transaction Counter (ATC) of the ICC. The Master key should be provided in dual or triple length and initial vector (IV) is expected to be 64 bytes long (32 hexadecimal characters). Its value 32×0 is considered to be secure as following key derivation is cryptographic process strong enough not to be inflicted by it. Branch factor and height are mandatory values and their default values are 4 for branch factor and 8 for height. ATC value stands for application transaction counter and is usually lodged on a chip and accepts hexadecimal values from ‘0000’ to ‘FFFF’. Final handler also provides an option to force a parity on a final session key generated. The Odd parity is selected as default.

EMV Cryptography: Session key derivation finished
****************************************
Master key:          0123456789ABCDEF0123456789ABCDEF
Initial vector:      00000000000000000000000000000000
Branch factor:       4
Height:              8
ATC:                 0001
Key parity:          Right odd
—————————————-
Key generated:       022551C4FDF76E45988089BA31DC077C
KCV:                 14B1CA

AAC/ARQC/TC

Application cryptogram frame also allows generating Authorization Request Cryptogram (ARQC, Online Authorization), Transaction certificate (TC, offline approval), Application Authentication Cryptogram (AAC, Offline decline), or Application Authorisation Referral (AAR) values needed for ICC card authorization. Session key value can be amended manually or it will populate itself on “Session key” generation as described above. This also applies for ICC data field, where the substring <4-8> will be replaced by ATC value from previous screen.

The terminal data field value is based on data objects received from the terminal in the transaction-related data field included in the C-APDU of the GENERATE AC command: Amount Authorised, Amount Other, Transaction Currency Code, transaction date, transaction type, Terminal Country Code, TVR, and unpredictable number. These are usually provided to ICC based on content of CDOL1 or CDOL2 objects.

EMV Cryptography: AAC generation finished
****************************************
Session key: 022551C4FDF76E45988089BA31DC077C
Terminal data: 0000000010000000000000000710000000000007101302050030901B6A
ICC data: 3C00000103A4A082
Padding method: Method 1 (ISO-9797)
—————————————-
AC generated: 92791D36B5CC31B5

ARPC

Generates an authorisation response cryptogram (ARPC). Session key value is always updated by the value generated on the ‘Session key’ derivation tabs. Transaction cryptogram (TC) is being updated by an value generated on AAC/ARQC/TC tab.

EMV Cryptography: ARPC generation finished
****************************************
ARPC Method: 1
Response Code: Y3
Session key: 022551C4FDF76E45988089BA31DC077C
Transaction Cryptogram:92791D36B5CC31B5
—————————————-
ARPC generated: E4E0BD6721957E2B

EMV 4.2

EMV Session Key Derivation

Master Key

Generates an Card Authentication Key Unique Derived Key (UDK), which is being used for eg. card’s Master Key personalisation (see EMV Book v4.2).

EMV Cryptography: UDK derivation finished
****************************************
MDK:                 0123456789ABCDEF0123456789ABCDEF
PAN:                 43219876543210987
PAN sequence nr.:    00
Derivation option:   Option A
Key parity:          Right odd
—————————————-
UDK:                 C8B507136D921FD05864C81F79F2D30B
KCV:                 0DA897

Common Session Key

EMV Cryptography: Common Session key derivation finished
****************************************
Master key:       0123456789ABCDEF0123456789ABCDEF
ATC:              0001
Key parity:
—————————————-
Key generated:    4917E0A383B92F11169F0B0B6C80DC78
KCV:              F51856

AAC/ARQC/TC

Application cryptogram frame also allows generating Authorization Request Cryptogram (ARQC, Online Authorization), Transaction certificate (TC, offline approval), Application Authentication Cryptogram (AAC, Offline decline), or Application Authorisation Referral (AAR) values needed for ICC card authorization. Session key value can be amended manually or it will populate itself on “Session key” generation as described above. This also applies for ICC data field, where the substring <4-8> will be replaced by ATC value from previous screen.

The terminal data field value is based on data objects received from the terminal in the transaction-related data field included in the C-APDU of the GENERATE AC command: Amount Authorised, Amount Other, Transaction Currency Code, transaction date, transaction type, Terminal Country Code, TVR, and unpredictable number. These are usually provided to ICC based on content of CDOL1 or CDOL2 objects.

EMV Cryptography: AAC generation finished
****************************************
Session key: 4916E0A283B92F10169E0B0B6D80DC79
Terminal data: 0000000010000000000000000710000000000007101302050030901B6A
ICC data: 3C00005503A4A082
Padding method: Method 1 (ISO-9797)
—————————————-
AC generated: 0AD18EFA20148EE1

ARPC

Generates an authorisation response cryptogram (ARPC). Session key value is always updated by the value generated on the ‘Session key’ derivation tabs. Transaction cryptogram (TC) is being updated by an value generated on AAC/ARQC/TC tab.

EMV Cryptography: ARPC generation finished
****************************************
ARPC Method:          1
Response Code:        Y3
Session key:          4917E0A383B92F11169F0B0B6C80DC78
Transaction Cryptogram:0AD18EFA20148EE1
—————————————-
ARPC generated:       4683F55F0029BABC

MasterCard

EMV Session Key Derivation

UDK

Generates an Card Authentication Key Unique Derived Key (UDK), which is being used for eg. card’s Master Key personalisation (see EMV Book v4.1. pg. 134 – Option A & B).

EMV Cryptography: UDK derivation finished
****************************************
MDK:                 0123456789ABCDEF0123456789ABCDEF
PAN:                 43219876543210987
PAN sequence nr.:    00
Derivation option:   Option A
Key parity:          Right odd
—————————————-
UDK:                 C8B507136D921FD05864C81F79F2D30B
KCV:                 0DA897

Session Key

The Session key function derives a 16-byte Application Cryptogram Session Key SKAC from the ICC Application Cryptogram Master Key MKAC and the 2-byte Application Transaction Counter (ATC) of the ICC. The Master key should be provided in dual or triple length and initial vector (IV) is expected to be 64 bytes long (32 hexadecimal characters). Its value 32×0 is considered to be secure as following key derivation is cryptographic process strong enough not to be inflicted by it. Branch factor and height are mandatory values and their default values are 4 for branch factor and 8 for height. ATC value stands for application transaction counter and is usually lodged on a chip and accepts hexadecimal values from ‘0000’ to ‘FFFF’. Final handler also provides an option to force a parity on a final session key generated. The Odd parity is selected as default.

EMV Cryptography: Session key derivation finished
****************************************
Master key:          0123456789ABCDEF0123456789ABCDEF
Initial vector:      00000000000000000000000000000000
Branch factor:       4
Height:              8
ATC:                 0001
Key parity:          Right odd
—————————————-
Key generated:       022551C4FDF76E45988089BA31DC077C
KCV:                 14B1CA

MC Session Key

AC generation consists of deriving a 16-byte Session Key SKAC from the ICC Application Cryptogram Master Key MKAC using the 2-byte Application Transaction Counter (ATC) of the ICC and a 4-byte terminal Unpredictable Number (UN).

EMV Cryptography: MasterCard Session key derivation finished
****************************************
UDK: C86ED652D5C2CBA21FC175191A5DCBCD
ATC: 0001
Unpredictable nr.: 30901B6A
—————————————-
Session key: 45C44343B64A58B3BF8046F75D943BEA
KCV: 31C65D

AAC/ARQC/TC

Application cryptogram frame also allows generating Authorization Request Cryptogram (ARQC, Online Authorization), Transaction certificate (TC, offline approval), Application Authentication Cryptogram (AAC, Offline decline), or Application Authorisation Referral (AAR) values needed for ICC card authorization. Session key value can be amended manually or it will populate itself on “Session key” generation as described above. This also applies for ICC data field, where the substring <4-8> will be replaced by ATC value from previous screen.

The terminal data field value is based on data objects received from the terminal in the transaction-related data field included in the C-APDU of the GENERATE AC command: Amount Authorised, Amount Other, Transaction Currency Code, transaction date, transaction type, Terminal Country Code, TVR, and unpredictable number. These are usually provided to ICC based on content of CDOL1 or CDOL2 objects.

EMV Cryptography: AAC generation finished
****************************************
Cryptogram: Cryptogram Version 14
Session key: 022551C4FDF76E45988089BA31DC077C
Terminal data: 0000000010000000000000000710000000000007101302050030901B6A
ICC data: 3C00005503A4A082
—————————————-
AC generated: 297670B020B89295

ARPC

Generates an authorisation response cryptogram (ARPC). Session key value is always updated by the value generated on the ‘Session key’ derivation tabs. Transaction cryptogram (TC) is being updated by an value generated on AAC/ARQC/TC tab.

EMV Cryptography: ARPC generation finished
****************************************
ARPC Method: 1
Response Code: Y3
Session key: 022551C4FDF76E45988089BA31DC077C
Transaction Cryptogram:297670B020B89295
—————————————-
ARPC generated: AACC6D10EB90D4D0

VSDC

EMV Session Key Derivation

UDK

Generates an Card Authentication Key Unique Derived Key (UDK), which is being used for eg. card’s Master Key personalisation (see EMV Book v4.1. pg. 134 – Option A & B).

EMV Cryptography: UDK derivation finished
****************************************
MDK:                 0123456789ABCDEF0123456789ABCDEF
PAN:                 43219876543210987
PAN sequence nr.:    00
Derivation option:   Option A
Key parity:          Right odd
—————————————-
UDK:                 C8B507136D921FD05864C81F79F2D30B
KCV:                 0DA897

Common Session Key

EMV Cryptography: Common Session key derivation finished
****************************************
Master key: C8B507136D921FD05864C81F79F2D30B
ATC: 0001
Key parity:
—————————————-
Key generated: D920B6730B9267079220F8491F2FCD68
KCV: 5B1D74

AAC/ARQC/TC

EMV Cryptography: AAC generation finished
****************************************
Cryptogram: Cryptogram Version 14
Session key: C8B507136D921FD05864C81F79F2D30B
Terminal data: 0000000010000000000000000710000000000007101302050030901B6A
ICC data: 3C00005503A4A082
—————————————-
AC generated: 163FFB283F9A130D

ARPC

EMV Cryptography: ARPC generation finished
****************************************
ARPC Method:        1
Response Code:      Y3
Session key:        C8B507136D921FD05864C81F79F2D30B
Transaction Cryptogram:163FFB283F9A130D
—————————————-
ARPC generated:     49D9C484463231E9

DDA

Dynamic Data Authentication (DDA) together with Static Data Authentication (SDA) are main security mechanisms in EMV. BP-CryptoCalc provides a good overview how are these mechanisms implemented, while going even further and revealing some internals as validation steps and their results.

Dynamic Data Authentication (DDA) processing is needed to verify the authenticity of the dynamic data in the card is carried out completely by the terminal, while the card generates RSA signature on those data objects needed for completing this verification.
This tutorial won’t cover detailed usage. However what needs to be mentioned is that all functionality is implemented as “rolling” so output from one screen (e.g. CA PK retrieval) goes automatically to its logical consecutive one (e.g. Retrieve ICC PK) forming a flow-chart.

Retrieve CA PK

DDA: Issuer Public Key Recovery
****************************************
CA PK Modulus:
BE9E1FA5E9A803852999C4AB432DB28600DCD9DAB76DFAAA47355A0FE37B1508AC6BF38860D3C6C2E5B12A3CAAF2A7005A7241EBAA7771112C74CF9A0634652FBCA0E5980C54A64761EA101A114E0F0B5572ADD57D010B7C9C887E104CA4EE1272DA66D997B9A90B5A6D624AB6C57E73C8F919000EB5F684898EF8C3DBEFB330C62660BED88EA78E909AFF05F6DA627B
Issuer’s Public Key Certificate:
7F4C6034C33BF35BAFFF53F51C0F8A2B32C8FDE1D033DDB69DCA85C5B4797BD2F55BE970C026B75B76E9C17E8564111FDEB97B26E350F59F6C63C30B0BD80E33123DF73CF8F87B28D54D28E4D6284F44E6E61AD95826474EBF6C28796B9B222DF14194A539E92DB185D86D8EDDD8AA01ECBE93E0EC3F87383D879534FE0BD397D7D59FC6E37012258B894400EE715338
—————————————-
Recovered Data:
6A02457896FF12170314EF01019001E04E4FC478A42241068E2C9CFDEE9D7450F48F812FA66CEFB8ECBE31DD3C26C3B8A3891B77C1AA2A5A7448B869B7213D36C341E9B71302ADF478F67537032C080186C44034B1801D7644B6EEFAEA566D7336A8C83F42B7992F28BF5EA6B9D14C05870AD4DBD8CDAB8771F65F83D800B353B11E1805C7E4529F261C16A38DE756BC
Data Header:                            6A
Data Format:                            02
Issuer Identifier:                      457896FF
Certificate Expiration Date:            1217
Certificate Serial Number:              0314EF
Hash Algorithm Indicator:               01
Issuer Public Key Algorithm Indicator:  01
Issuer Public Key Length:               90
Issuer Public Key Exponent Length:      01
Issuer Public Key:
E04E4FC478A42241068E2C9CFDEE9D7450F48F812FA66CEFB8ECBE31DD3C26C3B8A3891B77C1AA2A5A7448B869B7213D36C341E9B71302ADF478F67537032C080186C44034B1801D7644B6EEFAEA566D7336A8C83F42B7992F28BF5EA6B9D14C05870AD4DBD8CDAB8771F65F
Hash Result:         83D800B353B11E1805C7E4529F261C16A38DE756
Data Trailer:                           BC
Decoded Data Length:                    144
—————————————-
Recovered Data validation:
—————————————-
Step 1: CA PK Modulus and Issuer’s Public Key Certificate having the same size: Passed
Step 2: Recovered Data Trailer check:         Passed
Step 3: Recovered Data Header check (0x6A):   Passed
Step 4: Certificate Format check (0x02):      Passed
Step 5: Hash Input Data:
02457896FF12170314EF01019001E04E4FC478A42241068E2C9CFDEE9D7450F48F812FA66CEFB8ECBE31DD3C26C3B8A3891B77C1AA2A5A7448B869B7213D36C341E9B71302ADF478F67537032C080186C44034B1801D7644B6EEFAEA566D7336A8C83F42B7992F28BF5EA6B9D14C05870AD4DBD8CDAB8771F65F9A2FA99FC6CCA575875E108D7D847600A0D0863C549553E12EC75362597CEB2F16780BF103
Step 6: Hashing Result: 83D800B353B11E1805C7E4529F261C16A38DE756
Step 7: Hash Result Comparison:               Passed
Step 8: Issuer Identifier check:              Skipped (DIY)
Step 9: Certificate Expiry Date check:        Passed
Step 10: RID revocation check:                Skipped (optional DIY)
Step 11: PK Algorithm Indicator check:        Passed
Step 12: Issuer Public Key Modulus:
E04E4FC478A42241068E2C9CFDEE9D7450F48F812FA66CEFB8ECBE31DD3C26C3B8A3891B77C1AA2A5A7448B869B7213D36C341E9B71302ADF478F67537032C080186C44034B1801D7644B6EEFAEA566D7336A8C83F42B7992F28BF5EA6B9D14C05870AD4DBD8CDAB8771F65F9A2FA99FC6CCA575875E108D7D847600A0D0863C549553E12EC75362597CEB2F16780BF1
—————————————-
Issuer’s Public Key Module Recovery succeeded.

Retrieve ICC PK

DDA: ICC Public Key Recovery
****************************************
Issuer PK Modulus:
E04E4FC478A42241068E2C9CFDEE9D7450F48F812FA66CEFB8ECBE31DD3C26C3B8A3891B77C1AA2A5A7448B869B7213D36C341E9B71302ADF478F67537032C080186C44034B1801D7644B6EEFAEA566D7336A8C83F42B7992F28BF5EA6B9D14C05870AD4DBD8CDAB8771F65F9A2FA99FC6CCA575875E108D7D847600A0D0863C549553E12EC75362597CEB2F16780BF1
ICC’s Public Key Certificate:
1640CA8EEC4BA011D575D46F601DFBB22252076BDFD5360D7773BC38BE971A8526A3CEE1EDFD9BDC69CEE6E71D91A4B731C8B4290F5E4ADD046AAB8245CC07794030038C5FCB4270B15DEA6D895CCF67916314D5EC7F86BDD640792454870773BE5D28740FF1970C02A694C7AAEB9145D89F2BED9D8C982A2D388EFA0F26E86F73AFDB32A93913E28C6569F04DE4C509
—————————————-
Recovered Data:
6A044578965000000016FFFF071600000601017001A5ECC75561EFE21E8DD77F32C05B41F39902B6F430C09F270FB09B53CA22F3E90CDD4613073AC20DF17528BACA7E18C2FDCECD33105D180FB2074727456AE104FE81FE1A0AB922A0CC8A394DE782D7888F636F3F07535864CBFB0DA32C22A2C704F4F209CF90D96B71B09EE20E842A7D26133B2FB1E07BC7250DBC
Data Header:                            6A
Data Format:                            04
Issuer Identifier:                      45789650
Certificate Expiration Date:            0716
Certificate Serial Number:              000006
Hash Algorithm Indicator:               01
ICC Public Key Algorithm Indicator:     01
ICC Public Key Length:                  70
ICC Public Key Exponent Length:         01
ICC Public Key:
A5ECC75561EFE21E8DD77F32C05B41F39902B6F430C09F270FB09B53CA22F3E90CDD4613073AC20DF17528BACA7E18C2FDCECD33105D180FB2074727456AE104FE81FE1A0AB922A0CC8A394DE782D7888F636F3F07535864CBFB0DA32C22A2C704F4F209CF90
Hash Result:         D96B71B09EE20E842A7D26133B2FB1E07BC7250D
Data Trailer:                           BC
Decoded Data Length:                    144
—————————————-
Recovered Data validation:
—————————————-
Step 1: Issuer’s PK Modulus and ICC Public Key Certificate having the same size: Passed
Step 2: Recovered Data Trailer check:         Passed
Step 3: Recovered Data Header check (0x6A):   Passed
Step 4: Certificate Format check (0x04):      Passed
Step 5: Hash Input Data:
044578965000000016FFFF071600000601017001A5ECC75561EFE21E8DD77F32C05B41F39902B6F430C09F270FB09B53CA22F3E90CDD4613073AC20DF17528BACA7E18C2FDCECD33105D180FB2074727456AE104FE81FE1A0AB922A0CC8A394DE782D7888F636F3F07535864CBFB0DA32C22A2C704F4F209CF902F40C2050FCB169EF11D032000
Step 6: Hashing Result: D96B71B09EE20E842A7D26133B2FB1E07BC7250D
Step 7: Hash Result Comparison:               Passed
Step 8: Issuer Identifier check:              Skipped (DIY)
Step 9: Certificate Expiry Date check:        Passed
Step 10: PK Algorithm Indicator check:        Passed
Step 11: ICC Public Key Modulus:
A5ECC75561EFE21E8DD77F32C05B41F39902B6F430C09F270FB09B53CA22F3E90CDD4613073AC20DF17528BACA7E18C2FDCECD33105D180FB2074727456AE104FE81FE1A0AB922A0CC8A394DE782D7888F636F3F07535864CBFB0DA32C22A2C704F4F209CF902F40C2050FCB169EF11D
—————————————-
ICC’s Public Key Module Recovery succeeded.

Verify SDAD

DDA: Signed Dynamic Application Data Verification
****************************************
ICC PK Modulus:
A5ECC75561EFE21E8DD77F32C05B41F39902B6F430C09F270FB09B53CA22F3E90CDD4613073AC20DF17528BACA7E18C2FDCECD33105D180FB2074727456AE104FE81FE1A0AB922A0CC8A394DE782D7888F636F3F07535864CBFB0DA32C22A2C704F4F209CF902F40C2050FCB169EF11D
Signed Dynamic Application Data:
55F1B26B7E65E03EDA9408EE0A5F9DFD81E0F5C138C1BF4432CE489DEB0E0DEB9E0F764FE729D24873306FB2C06CDE36775BD5878CCB545CF99294B1D7FCC36691B7DD2DFECC0CDD0AB21CC2982034E723C998F318A987B27CBCD1E85009243CD5076E4C70E54658D6150F02BAACF646
—————————————-
Recovered Data:
6A050103020089BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB64A912F76F3C01FF8FAD0E2E5A2395D0FE802DB9BC
Data Header:                            6A
Signed Data Format:                     05
Hash Algorithm Indicator:               01
Dynamic Data length:                    03
ICC Dynamic Data:                       020089
Pad Pattern:
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
Hash Result:         64A912F76F3C01FF8FAD0E2E5A2395D0FE802DB9
Data Trailer:                           BC
—————————————-
Recovered Data validation:
—————————————-
Step 1: Issuer PK Modulus and Signed Static Application Data having the same length: Passed
Step 2: Recovered Data Trailer check:         Passed
Step 3: Recovered Data Header check (0x6A):   Passed
Step 4: Certificate Format check (0x03):      Passed
Step 5: Hash Input Data:
050103020089BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBCFCD8956000000000100071001FE7836E0
Step 6: Hashing Result: 64A912F76F3C01FF8FAD0E2E5A2395D0FE802DB9
Step 7: Hash Result Comparison:               Passed
—————————————-
DDA Validation Succeed.

SDA

Dynamic Data Authentication (DDA) together with Static Data Authentication (SDA) are main security mechanisms in EMV. BP-CryptoCalc provides a good overview how are these mechanisms implemented, while going even further and revealing some internals as validation steps and their results.

Static Data Authentication (SDA) processing is needed to verify the authenticity of the data in the card is carried out completely by the terminal, while the card only stores those data objects needed for completing this verification.
This tutorial won’t cover detailed usage. However what needs to be mentioned is that all functionality is implemented as “rolling” so output from one screen (e.g. Retrieve CA PK) goes automatically to its logical consecutive one (e.g. Verify SSAD) forming a flow-chart.

Retrieve CA PK

SDA: Issuer Public Key Recovery
****************************************
CA PK Modulus:
AF0754EAED977043AB6F41D6312AB1E22A6809175BEB28E70D5F99B2DF18CAE73519341BBBD327D0B8BE9D4D0E15F07D36EA3E3A05C892F5B19A3E9D3413B0D97E7AD10A5F5DE8E38860C0AD004B1E06F4040C295ACB457A788551B6127C0B29
Issuer’s Public Key Cert.:
191AB5AC03365D5E9515C398CCC5C744A728A4FCFDE194D0B88B0FA1673AEBDD8AAADF0EDBBC12414E7107A9F2B02DFB3985167C0EE9CDF3CB78749BF6D0AAE60E4C979F7E2AE635A77451B0E2F2EB136AB02076CBE1E70CC4EE5529434A9EC6
—————————————-
Recovered Data:
6A02476173FF123000024401015001E114557C29B988766A39FBC88AEE7C85A40F66A700AF73E0D889199FDDAA3836516D8587BD68EBCA5B99021E4175D3BA4BEB87B7D08C7B51C2B6F3E58F75912D421507ADC387E7B95A6121F0C745707EBC
Data Header:                            6A
Data Format:                            02
Issuer Identifier:                      476173FF
Certificate Expiration Date:            1230
Certificate Serial Number:              000244
Hash Algorithm Indicator:               01
Issuer Public Key Algorithm Indicator:  01
Issuer Public Key Length:               50
Issuer Public Key Exponent Length:      01
Issuer Public Key:
E114557C29B988766A39FBC88AEE7C85A40F66A700AF73E0D889199FDDAA3836516D8587BD68EBCA5B99021E4175D3BA4BEB87B7D08C7B51C2B6F3E5
Hash Result:         8F75912D421507ADC387E7B95A6121F0C745707E
Data Trailer:                           BC
Decoded Data Length:                    96
—————————————-
Recovered Data validation:
—————————————-
Step 1: CA PK Modulus and Issuer’s Public Key Certificate having the same size: Passed
Step 2: Recovered Data Trailer check:         Passed
Step 3: Recovered Data Header check (0x6A):   Passed
Step 4: Certificate Format check (0x02):      Passed
Step 5: Hash Input Data:
02476173FF123000024401015001E114557C29B988766A39FBC88AEE7C85A40F66A700AF73E0D889199FDDAA3836516D8587BD68EBCA5B99021E4175D3BA4BEB87B7D08C7B51C2B6F3E5CFB8D4885D960967179F982D42CE54ECC205468303
Step 6: Hashing Result: 8F75912D421507ADC387E7B95A6121F0C745707E
Step 7: Hash Result Comparison:               Passed
Step 8: Issuer Identifier check:              Skipped (DIY)
Step 9: Certificate Expiry Date check:        Passed
Step 10: RID revocation check:                Skipped (optional DIY)
Step 11: PK Algorithm Indicator check:        Passed
Step 12: Issuer Public Key Modulus:
E114557C29B988766A39FBC88AEE7C85A40F66A700AF73E0D889199FDDAA3836516D8587BD68EBCA5B99021E4175D3BA4BEB87B7D08C7B51C2B6F3E5CFB8D4885D960967179F982D42CE54ECC2054683
—————————————-
Issuer’s Public Key Module Recovery succeeded.

Verify SSAD

SDA: SSAD Verification
****************************************
Issuer PK Modulus:
E114557C29B988766A39FBC88AEE7C85A40F66A700AF73E0D889199FDDAA3836516D8587BD68EBCA5B99021E4175D3BA4BEB87B7D08C7B51C2B6F3E5CFB8D4885D960967179F982D42CE54ECC2054683
Signed Static Application Data:
110BB9DF2D21981906B29A301411F9FA60CF494DBABABF54B1797C9C4B5D99B5E67AB73049E771FC5FDC23E58350B781005324D31DC87AD0FBF636733808056D66074632711E7CBF14073796E1B60D4D
—————————————-
Recovered Data:
6A0301DAC5BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFE1865437CB34DF9FE2F9E5057956D9F67FBDA8FBC
Data Header:                            6A
Signed Data Format:                     03
Hash Algorithm Indicator:               01
Data Authentication Code:               DAC5
Pad Pattern:
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
Hash Result:         FE1865437CB34DF9FE2F9E5057956D9F67FBDA8F
Data Trailer:                           BC
—————————————-
Recovered Data validation:
—————————————-
Step 1: Issuer PK Modulus and Signed Static Application Data having the same length: Passed
Step 2: Recovered Data Trailer check:         Passed
Step 3: Recovered Data Header check (0x6A):   Passed
Step 4: Certificate Format check (0x03):      Passed
Step 5: Build Hash Input Data:
0301DAC5BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB5A0847617390010100105F340101
Step 6: Hashing Result: FE1865437CB34DF9FE2F9E5057956D9F67FBDA8F
Step 7: Hash Result Comparison:               Passed
—————————————-
SDA Validation Succeed.

ICC Dynamic Number

MasterCard (EMV 3.1.1)

ICC Dynamic Number generation consists of deriving a 16-byte Session Key from the ICC Dynamic Number Master Key MK-DN using the 2-byte Application Transaction Counter (ATC) of the ICC and a 4-byte terminal Unpredictable Number (UN).

EMV Cryptography: MasterCard ICC Dynamic Number derivation finished
****************************************
MK-DN: 23232323232323233434343434343434
PAN: 9503493362330001
ATC: 0001
Unpredictable nr.: 92ED9B7F
—————————————-
Session Key: 0D2FDB1304D0CBA1A51C56F660276EDA
Dynamic Number: 465B

Data Storage Partial Key

MasterCard

MasterCard: DSPK (Data Storage Partial Key) derivation.
DSPK is an input for the hash function used in OWHF1 and OWHF2. OWHF1 is the one way hash function used to generate the DS Summary, while OWHF2 is the one way hash function that generates the DS Digest. The DSPK must always be personalized when the DS ID is personalized in the card, in other words when IDS is used.

Data Storage Partial Key (DSPK)

EMV Cryptography: MasterCard Data Storage Partial Key derivation finished
****************************************
DS ID: 5168624300900697
—————————————-
DSPK: 66887C5600B47C5600B40CC2

DS Summary (OWHF1)

EMV Cryptography: MasterCard OWHF1 derivation finished
****************************************
DS Summary 1: 1223344556677889
Amount Authorized: 000000001234
Transaction Currency Code: 840
Reference Control Parameter: 80
First/Second Generate AC Indicator: 01
DS Unpredictable nr.: 11223344
Unpredictable nr.: 11223344
DSPK: 66887C5600B47C5600B40CC2
—————————————-
A: 9840
X1: 1223344544534BCD
X2: 9840112233441122
K1: 66887C5600B41122
K2: 7C5600B40CC23344
K3: FC5C0B2C60AC2DCD
—————————————-
DS Summary: FC96571A6E95FFA4

DS Digest (OWHF2)

EMV Cryptography: MasterCard OWHF2 derivation finished
****************************************
DS Input T: 1223344556677889
DS Req. Operator Id: 8199829983998499
DSPK: 66887C5600B47C5600B40CC2
—————————————-
X: 93BAB6DCD5FEFC10
K1: 66887C5600B48399
K2: 7C5600B40CC28499
—————————————-
DS Digest: 659C8EBFAA816DB5

Secure Messaging

MasterCard

Session Key

MasterCard Secure Messaging: Session Key derivation finished
****************************************
MK-SMI: 862F13DF807A13B9D9AEAEC885FE7CA4
KCV: 8D2921
MK-SMC: BF89B32308CDADDC04B952C7DF0715E0
KCV: 760B6D
UDK-SMI: AEB0F198A498E067C4E63D94A770A80E
KCV: CA2DB2
UDK-SMC: 640167C1D3C7623804FE97A75E2FC102
KCV: 70BEF3
AC: 51DB71A5DCC47F8A
Command nr.: 0
—————————————-
SK-SMI: 1241B9DB1E953A02D5620E8B97418AE8
KCV: D338D4
SK-SMC: 46AEA9871A61315C4E174FD9EBEB8AAC
KCV: A77DB4

PIN

MasterCard Secure Messaging: PIN encryption finished
****************************************
Session Key Enc: 46AEA9871A61315C4E174FD9EBEB8AAC
KCV: A77DB4
New PIN: 3356
PIN block: Standard EMV
—————————————-
Plaintext PIN block: 243356FFFFFFFFFF
Encrypted PIN block: 0ED11FDBC43F8F1A

MAC

MasterCard Secure Messaging: MACing operation finished
****************************************
Session Key MAC: 1241B9DB1E953A02D5620E8B97418AE8
KCV: D338D4
MAC Data: 8400000210001051DB71A5DCC47F8A0ED11FDBC43F8F1A80
—————————————-
MAC: D758292B52F9FF74

Visa

Session Key

Visa Secure Messaging: Session Key derivation finished
****************************************
UDK: 94E3194C02105E3B153438D562D5A49D
KCV: 086020
ATC: 0003
—————————————-
Session key: 94E3194C02105E38153438D562D55B61
KCV: 2268BC

PIN

Visa Secure Messaging: PIN encryption finished
****************************************
Session Key Enc: 94E3194C02105E38153438D562D55B61
KCV: 2268BC
UDK Enc: 64C8621A76A2EA9EF23D5749FE1A64F1
KCV: E23347
New PIN: 4222
—————————————-
Encrypted PIN block: B3511E3333BF9DC56E1EDF6458BB52B6

MAC

Visa Secure Messaging: MACing operation finished
****************************************
Session Key MAC: FB169D8F19C43B62C7258F7C1AE58083
KCV: 422C6A
MAC Data: 84240002180003EFB5340A1BF07421B3511E3333BF9DC56E1EDF6458BB52B680
—————————————-
MAC: 8433A315DC674B26

HCE

Host card emulation (HCE) is the software architecture that provides exact virtual representation of various electronic identity (access, transit and banking) cards using only software. Prior to the HCE architecture, near field communication (NFC) transactions were mainly carried out using secure elements.

HCE enables mobile applications running on supported operating systems to offer payment card and access card solutions independently of third parties while leveraging cryptographic processes traditionally used by hardware-based secure elements without the need for a physical secure element. This technology enables the merchants to offer payment cards solutions more easily through mobile closed-loop contactless payment solutions, offers real-time distribution of payment cards and allows for an easy deployment scenario that does not require changes to the software inside payment terminals. (source Wikipedia)

Visa

UDK

EMV Cryptography: UDK derivation finished
****************************************
MDK: 0123456789ABCDEF0123456789ABCDEF
PAN: 43219876543210987
PAN sequence nr.: 00
Derivation option: Option A
Key parity: Right odd
—————————————-
UDK: C8B507136D921FD05864C81F79F2D30B
KCV: 0DA897

LUK key

Visa HCE: LUK Key derivation finished
****************************************
UDK: C8B507136D921FD05864C81F79F2D30B
Current Year: 0
Current Hours: 5702
Hourly Counter: 01
—————————————-
LUK key: 3EA78DED27B7BB01F9069B8E34C443BC

MSD

Visa HCE: MSD Verification Value derivation finished
****************************************
LUK: 3EA78DED27B7BB01F9069B8E34C443BC
ATC: 0001
Device Type: AAAA000000000001
—————————————-
MSD Verification Value: 675

qVSDC

Visa HCE: qVSDC cryptogram finished
****************************************
LUK key: 3EA78DED27B7BB01F9069B8E34C443BC
Terminal data: 0000000010000000000000000710000000000007101302050030901B6A
ICC data: 3C00005503A4A082
—————————————-
Cryptogram: 7A578B8A6F9E09B1

CAP Token Computation

MasterCard International has developed MasterCard SecureCodeTM to offer flexible, robust, and easy to implement solutions for cardholder authentication for electronic commerce and other alternative channels. SecureCode allows for several different cardholder authentication methods.

The Chip Authentication Program (CAP) is one such cardholder authentication method. It is an online process that leverages the authentication capabilities inherent in an EMV payment chip card to provide:

• Powerful remote cardholder authentication.
• Evidence that the payment card is present at the point of interaction (POI).
• Optionally, CAP can also provide evidence of cardholder approval of transaction details.

CAP can be used for remote authentication of the cardholder in online e-commerce transactions, for example in the context of the 3-D Secure protocol, where it can help reduce chargebacks for Reason Codes 4837 – No Cardholder Authorization and 4863 – Cardholder Does Not Recognize.

At their discretion and liability, issuers may also choose to use CAP in other online applications and services, such as online banking.

EMV Cryptography: CAP Token derivation finished
****************************************
Token data:        008000015AC19AC9FE1360F306010A03A41000
Binary Token data:
0000 0000 1000 0000 0000 0000 0000 0001
0101 1010 1100 0001 1001 1010 1100 1001
1111 1110 0001 0011 0110 0000 1111 0011
0000 0110 0000 0001 0000 1010 0000 0011
1010 0100 0001 0000 0000 0000
IPB data:        00007FFFFF0000000000000000000020800000
Binary IPB data:
0000 0000 0000 0000 0111 1111 1111 1111
1111 1111 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0010 0000
1000 0000 0000 0000 0000 0000
Compressed data:    0000000000000010101101001
Token:            1385

ATR data parser

The Answer To Reset (ATR) is a message output by a contact Smart Card conforming to ISO/IEC 7816 standards, following electrical reset of the card’s chip by a card reader. The ATR conveys information about the communication parameters proposed by the card, and the card’s nature and state.

The presence of an ATR is often used as a first indication that a Smart Card appears operative, and its content examined as a first test that it is of the appropriate kind for a given usage.
ATR data parser parses SmartCard’s Answer to Reset Data into human readable form.
Note that application input is written to remove all non-hexadecimal characters and is not case sensitive.
Example ATR data input:

EMV: ATR data parsing finished
****************************************
Data: 3B 6D 00 00 00 31 C0 71 D6 64 19 16 01 02 84 90 00
—————————————-
Output:
TS = 0x3B
T0 = 0x6D
Y(1): b01101101
K: 13 (Historical Bytes)
TB(1) = 0x00
VPP is not electrically connected
TC(1) = 0x00
Extra guard time: 0
Historical Bytes:compact TLV data object):
Tag: 3, Len: 1 (card service data byte):
Card service data byte:
Application selection: by full DF name
Application selection: by partial DF name
EF.DIR and EF.ATR access services:
by the READ RECORD (S) command (record structure)
Card with MF
Tag: 7, Len: 1 (card capabilities):
Selection methods: D6
DF selection by full DF name
DF selection by partial DF name
DF selection by file identifier
Short EF identifier supported
Record number supported
Tag: 6, Len: 4 (pre-issuing data):
Data: 19 16 01 02 “….”
Mandatory status indicator (3 last bytes):
LCS (life card cycle): Proprietary
SW SW: 90 00
—————————————-

TLV data parser

This feature parses EMV data into human-readable form.

Input field takes TLV data in hexadecimal form while output options are a tree and text form. Tree form is easy to navigate though, where the text form output makes easier to handle output data (copy & paste). The EMV parser code as implemented by this tool is also employed for EMV data send/received by EFTlab’s BP-Source and BP-Host suites doing same work to its users.
TLV parser expects data to start with an EMV tag followed by length and value. Parser can handle invalid inputs as well so it will provide warning on data parsing error. Tree output from this parser can be seen on a picture located on right, while its text form is below.
Example TLV data:

EMV: TLV data parser finished
****************************************
Data: 8C 20 9F 02 06 9F 03 06 9F 1A 02 95 05 5F 2A 02 9A 03 9C 01 9F 37 04 9F 35 01 9F 45 02 9F 34 03 9B 02 8D 08 91 0A 8A 02 95 05 9B 02 8E 10 00 00 00 00 00 00 00 00 5F 03 41 03 5E 03 02 03
—————————————-
Output:
Card Risk Management Data Object List 1 (CDOL1) [8C]:
Amount, Authorised (Numeric) [9F02]:
Length: 06
Amount, Other (Numeric) [9F03]:
Length: 06
Terminal Country Code [9F1A]:
Length: 02
Terminal Verification Results (TVR) [95]:
Length: 05
Transaction Currency Code [5F2A]:
Length: 02
Transaction Date [9A]:
Length: 03
Transaction Type [9C]:
Length: 01
Unpredictable Number (UN) [9F37]:
Length: 04
Terminal Type [9F35]:
Length: 01
Data Authentication Code [9F45]:
Length: 02
Cardholder Verification Method (CVM) Results [9F34]:
Length: 03
Transaction Status Information [9B]:
Length: 02
Card Risk Management Data Object List 2 (CDOL2) [8D]:
Issuer Authentication Data [91]:
Length: 0A
Authorisation Response Code (ARC) [8A]:
Length: 02
Terminal Verification Results (TVR) [95]:
Length: 05
Transaction Status Information [9B]:
Length: 02
Cardholder Verification Method (CVM) List [8E]:
Data (Binary): 00 00 00 00 00 00 00 00 5F 03 41 03 5E 03 02 03
00000000 – First amount
00000000 – Second amount
CVM #1: 5F 03
Code: 5F – No CVM required
Condition: 03 – If terminal supports the CVM
Next: Apply succeeding CV Rule if this CVM is unsuccessful
CVM #2: 41 03
Code: 41 – Plaintext PIN verification performed by ICC
Condition: 03 – If terminal supports the CVM
Next: Apply succeeding CV Rule if this CVM is unsuccessful
CVM #3: 5E 03
Code: 5E – Signature (paper)
Condition: 03 – If terminal supports the CVM
Next: Apply succeeding CV Rule if this CVM is unsuccessful
CVM #4: 02 03
Code: 02 – Enciphered PIN verified online
Condition: 03 – If terminal supports the CVM
Next: Fail cardholder verification if this CVM is unsuccessful
—————————————-

EMV tag dictionary

Functionality given by this feature is to provide standalone dictionary of all EMV tags. This can be found handy when analyzing an EMV product in secured environments with a limited access to the Internet and to avoid wasting resources on constant manual look up through the EMV documentation. Dictionary’s search options include searching through “All text data” to list dependencies on related tags; Tags only; searching through Tag names and their descriptions and listing only Tags with matching templates.

Some tags lodged in database also contain “Example” and “Comment” fields, providing additional information on how field values should look like and field practical usage.
Output for ’84’:

EMV: EMV tag dictionary lookup finished
****************************************
Search result(s) for ’84’:
—————————————-
Tag: 84
Name: Dedicated File (DF) Name
Kernel: MasterCard
Source: ICC
Format: binary
Template: ‘6F’
Length: 5-16 [B]
Description: Identifies the name of the DF as described in ISO/IEC 7816-4
—————————————-
Tag: 84
Name: Dedicated File (DF) Name
Kernel: VISA
Source: ICC
Format: binary 40-128
Template: N/A
Length: 5-16 [B]
Description: Identifies the name of the DF as described in ISO/IEC 7816-4
—————————————-
Tag: 84
Name: Dedicated File (DF) Name
Kernel: JCB
Source: ICC
Format: binary
Template: N/A
Length: 5-16 [B]
Description: Identifies the name of the DF as described in ISO/IEC 7816-4
Comment: M
—————————————-
Tag: 9F02
Name: Amount, Authorised (Numeric)
Kernel: MasterCard
Source: Terminal
Format: n 12
Template: N/A
Length: 6 [B]
Description: Authorised amount of the transaction (excluding adjustments). This amount is expressed with implicit decimal point corresponding to the minor unit of currency as defined by [ISO 4217] (for example the six bytes ’00 00 00 00 01 23′ represent USD 1.23 when the currency code is ‘840’). If the initial transaction amount needs to be replaced with a revised transaction amount, the Terminal must provide it before the checkpoint.
Example: 000000010000
—————————————-

APDU response query

EMV Tool’s last screen provides a simple APDU response look up option. Basic list of supported APDU responses is in a table referenced here, but it might be also handy to have it available when there is no Internet connection available as those are not common attachment to the EMV specifications and differs per payment network.

Output for ‘9800’:

EMV: APDU response parsing finished
****************************************
SW1 SW2 [9800] – Application related status, (ISO 7816-3)

Summary

In this article, we went through the functionality of Cryptographic Calculator covered by the EMV Menu.

Cryptographic Calculator and other tools covered in EFTtools suite were designed to help and assist payment industry people in their day to day tasks and make their work the most effective. Our team would be grateful if you would suggest any improvements to our applications or report completely new functionality needed. Feedback from our users like this is exactly what drives the development of its and helps us to share our experience to wide public.