The BP-Tools set consist of applications supporting payment transaction service development, testing and benchmarking. It currently consists of following components: Cryptographic Calculator and HSM Commander.
EFTlab distributes BP-Tools under Creative Commons Legal Code Attribution-NoDerivs 3.0 Unported and completely free. This package does come with a full support and monthly releases instantly bringing new features.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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
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).
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.
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
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.
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 BP-Tools 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.
