Solutions Customers Resources Company Contact

Cryptographic Calculator – Payments

menu
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.

Payments Cryptography

This set of tools is focuses on working with cryptography algorithms used across payments, extended with
further features as MAC generation and validation, PIN formats and calculation and other common
payments security techniques.

AS2805

AS2805 is the Australian standard for financial messaging. It is near-exclusively used in Australia for the
operation of card-based financial transactions among banks, automatic teller machines and EFTPOS
devices. Financial messages described by this standard are closely related to ISO 8583, but pre-dates it
by two years (1985 vs 1987).

AS2805 functionality provided by CCALC handles Terminal Keys Set generation, PIN Block translation,
plus MAC and OWF generation.

Generate Terminal Key Set

Generates set of terminal keys like a Terminal PIN Key (TPK), Terminal Authentication Key Receive
(TAKr), Terminal Authentication Key Send (TAKs), Terminal Encryption Key Receive (TEKr) and Terminal
Encryption Key Send (TEKs) and return each key encrypted under a variant of a Terminal Master Key
(TMK) or KMA and the appropriate LMK pair. CCALC generates a key check value (KCV) for every output
key.

KEK Flag specifies what key is used 1 = KEK1, 2 = KEK2, 3 = TEKr.

Key Encryption Key receive (KEKr) has to be always provided in hexadecimal digits (0-9 | A-F) and key
length allowed is 32. The key is encrypted under the appropriate variant of LMK pair 14-15.

Key Scheme KEK says what Key Scheme will be used for encrypting keys under KEKr.
Key Scheme LMK says what Key Scheme will be used for encrypting keys under LMK.

KCV Type sets the length of the key check value (1 = KCV 6H )

AS2805: Generate Terminal Key Set operation finished

****************************************
KEK Flag: 1
KEKr: D045461C8C49FC0C9729AC0D5FA0E4E4
Key Scheme KEK: H
Key Scheme LMK: U
Key Check Value Type:1
—————————————-
TPK under LMK: UD6CAF1AF4084B33306684F966F8B73ED
TPK under KEK: HAA25A3709EA011CD59728FD78F259BAF
KCV of TPK: 2D66C2
TAKs under LMK: UC3980C1FA678CBECB1B0B0C6BF905189
TAKr under LMK: U221159822BEC80B177D292005F20DCB8
TAKs under KEK: H8D5C26B2687F5A4805DE2EA05789ECE9
TAKr under KEK: H5E933F6802C36FC31A71DFBF45481E79
KCV of TAKs: C0B4B8
KCV of TAKr: 910A49
TEKs under LMK: U8261BE1B0BABCE128F5B01DE5CC40B98
TEKr under LMK: U5CB533A83C3AB17F0E85FE11BE16AA9B
TEKs under KEK: H14F29CBB9FBF9E2A87130348F2FB5C33
TEKr under KEK: H129C77D9C3F8373B62198AE6505F91C9
KCV of TEKs: 647EEB
KCV of TEKr: C4D177
DES operations count:2

Translate PIN Block

This fuction translates a PIN block from encryption under a PIN Encryption Key (KPE) to encryption
under a Zone PIN Key (ZPK). The KPE is derived from a Terminal PIN Key (TPK) and two other values, the
Systems Trace Audit Number (STAN) and the transaction amount.

Zone PIN Key (ZPK) has to be always provided in hexadecimal digits (0-9 | A-F) and key length allowed is
32. The key is encrypted under the variant 0 of LMK pair 06-07.
Terminal PIN Key (TPK) has to be always provided in hexadecimal digits (0-9 | A-F) and key length allowed
is 32. The key is encrypted under the variant 0 of LMK pair 14-15.

Received and Responding PIN Block formats have to be a valid PIN block format code (eg. 01, 46).

ReceivedPIN Block is encrypted under KPE.

Account number provided as last 12 digits from PAN except the check value (12N).

The following diagram demonstrates PIN Block translation from KPE to ZPK and conversion between the
PIN Block formats.

AS2805: Translate PIN Block operation finished

****************************************
System ZPK: U16B8E012BF7E66740E7314F50285D100
Terminal TPK: UA342F36E4DD5390FA48833B18AC7D3DE
STAN: 000324
Transaction Amount: 000000000328
In PIN Bl. Format: 46
Out PIN Bl. Format: 1
Incoming PIN Block: 449ECFEA9FBCFE4B
Account Number: 430300010094
—————————————-
Outgoing PIN Block: D191B5DC48D8FD0D

MAC
Message Authentication Code (MAC) is generated using Terminal Authentication Key (TAK) as per
method defined in AS2805.4 (1985). It takes double length MAC key and applies the procedure on
hexadecimal data provided in the Data field.

Key (TAK) has to be always provided in hexadecimal digits (0-9 | A-F) and key length allowed is 32. Note
that the input key is in its plain form (unencrypted).

AS2805: MAC operation finished

****************************************
Key: 9486EB87AC3A4FDD9325A70B97D7D9F8
Data:
02107238000102C000111670343010001006660000000000000000000912065731000092155726091
—————————————-
Encrypted MAC: 2DFF2261

OWF
The One-way Function (OWF) is a backbone of AS2805 and is used in majority of previous key generation
functions. CCALC implementation complies with the AS2805.5.4 standard as it is described below.

Let K be a DES key and let D be a data block, of arbitrary length, n bits.
If n is not a multiple of 64 then append a single binary ‘1’ followed by as many binary zeros as necessary to make the data a multiple of 64 bits
(possibly none).
Let D* denote the padded data.

Key (TAK) has to be always provided in hexadecimal digits (0-9 | A-F) and key length allowed is 32. The key
is in its plain form (unencrypted).

AS2805: OWF calculation finished

****************************************
Key: 23232323232323234545454545454545
Data: 33334444555566667777888899991111AAAAAAAABBBBB
—————————————-
Calculated OWF: 5026FC017850298D6A037A566251AF84A905F282FEE94
KCV of TEKs: 647EEB
KCV of TEKr: C4D177
DES operations count:2

ISO8583 Bitmap
Support for ISO8583 Bitmap preparation. Parses bitmap (hexadecimal data) into bits and construct a
bitmap back from binary data provided. Screen reacts on Enter in Bitmap input and also on each bit-
checkbox tick. NOTE: Algorithm detects 1st bit to be set to indicate secondary bitmap presence as per
ISO8583 standard.

Card Validation

CVVs
Card Verification Values – This screen provides facility to generate and validate all major card not present
(CNP) values – CVV/iCVV/CVV2(CVC2)/dCVV.

Card Verification Key pair (CVK A/B) has to be always provided in hexadecimal digits (0-9 | A-F) and key
length allowed is 32H.

Primary Account Number (PAN) according to ISO/IEC 7812.

Generate

CNP: Generate verification value operation finished

****************************************
CVK A/B: 0123456789ABCDEFFEDCBA9876543210
PAN: 4999988887777000
Expiration date: 9105
Service Code: 101
—————————————-
Verification value: 539
Validate

CNP: Validate verification value operation finished

****************************************
CVK A/B: 0123456789ABCDEFFEDCBA9876543210
Card Verification Val.:539
PAN: 4999988887777000
Expiration date: 9105
Service Code: 101
—————————————-
Validation Status: OK

AMEX CSCs
Card Security Code (AMEX) – This screen provides facility to generate and validate CSC version 1 and
version 2. Version 2 supports following verification value types:

CSC
Magstripe only Card
Contact/Contacless Chip Card
Contact Chip iCSC
Contactless Chip iCSC

CSC Key has to be always provided in hexadecimal digits (0-9 | A-F) and key length allowed is 32H.

Primary Account Number (PAN) according to ISO/IEC 7812.

Generate
AMEX CSC: Generate security code operation finished
****************************************
CSC Key: 0123456789ABCDEFFEDCBA9876543210
PAN: 371234567890123
Expiration date: 9912
Service Code: 702
Value Type: CSC
—————————————-
CSC-5: 21334
CSC-4: 5068
CSC-3: 221
Validate

AMEX CSC: Validate security code operation finished

****************************************
CSC Key: 0123456789ABCDEFFEDCBA9876543210
CSC-5:21334
CSC-4:5068
CSC-3:221
PAN: 371234567890123
Expiration date: 9912
Service Code: 702
Value Type: CSC
—————————————-
CSC-5 validation: PASSED
CSC-4 validation: PASSED
CSC-3 validation: PASSED

MasterCard dynamic CVC3

Card Verification Value (MasterCard) – This screen provides facility to generate and validate dynamic
CVC3 and PIN-CVC3 values.

IMK Key has to be always provided in hexadecimal digits (0-9 | A-F) and key length allowed is 32H.

Primary Account Number (PAN) according to ISO/IEC 7812.

Generate

MasterCard dynamic CVC3: Generate verification code operation finished

****************************************
IMK Key: 01234567899876543210012345678998
PAN: 5413123456784808
PAN Seq. N.: 00
Track 1/2: 0000000000000000000000000000000000000000000000000000000000000000
Unpredictable N.: 00000899
ATC: 005E
Type: dynamic CVC3
——————–
Derived Key: 462FC416E0E93D042CD0B00731AB4637
Parity: ODD
Derived Key KCV: AF59
—————————————-
dynamic CVC3: 33204

Validate

MasterCard dynamic CVC3: Validate verification code operation finished

****************************************
IMK Key: 01234567899876543210012345678998
PAN: 5413123456784808
PAN Seq. N.: 00
Track 1/2: 0000000000000000000000000000000000000000000000000000000000000000
Unpredictable N.: 00000899
ATC: 005E
Type: dynamic CVC3
——————–
Derived Key: 462FC416E0E93D042CD0B00731AB4637
Parity: ODD
Derived Key KCV: AF59
—————————————-
dynamic CVC3: 33204
dynamic CVC3: PASSED

DUKPT

DUKPT (ISO 9797)

DUKPT panels consists of tabs following ISO-9797 – IPEK derivation, PEK derivation, PIN encryption and
MAC encryption. Method described in ISO-9797 uses Initial Pin Encryption Key (PEK) and Pin Encryption
Key (PEK) to encrypt PIN block encryption with unique key per transaction as well as using variant of this
key for MAC generation on transaction data provided.

PEK Derivation
IPEK and PEK derivation functions are the first options available. These require Base Derivation Key
(BDK) and Key Serial Number (KSN), or IPEK & KSN for PEK derivation, as input parameters. BKD and
IPEK keys are expected to be entered in its hexadecimal form and needs to be double length. The KSN has
hexa-decimal digits (0-9 | A-F) and input size has to be 20 characters.

DUKPT: PEK derivation finished

****************************************
BDK: C1D0F8FB4958670DBA40AB1F3752EF0D
KSN: FFFF9876543210E10004
—————————————-
Derived IPEK: 74E912996F1245CC1CF6F5C1E02FD05A
KCV: 18DCD7
Derived PEK: 4EC2A2974ECA53F5691E5273963EBE5C
KCV: 3C2BEF
DUKPT PIN

DUKPT PIN screen allows PIN block encryption/decoding with a PEK key. Input values are similar to
previous screens, just note that entered PEK will be XOR-ed with the value of 00000000000000FF
00000000000000FF (see ANSI X9.24-2004 Appendix A, A.5, page 42) as part of the processing. So there
is no need to do that operation in advance (it would exactly negate the previous change).
Encryption:

DUKPT: PIN operation finished

****************************************
PEK: 93A497589EBE6781DE37D2CBBDE5D436
PIN block: 04124389999AAAAB
—————————————-
Encrypted PIN: 23CB4612E05DE24D

Decryption:

DUKPT: PIN operation finished

****************************************
PEK: 93A497589EBE6781DE37D2CBBDE5D436
PIN block: 23CB4612E05DE24D
—————————————-
Decoded PIN: 04124389999AAAAB
DUKPT MAC
DUKPT MAC screen takes BDK, KSN and Data fields and outputs ANSI X9.24-2004 MAC with filling
option 1. All input fields are expected to be in a hexadecimal format with their appropriate lengths
(single/double/triple DEA). Note that the data field size is limited to 8120 characters. The 3DES switch
serves to indicate whether the last cryptographic operation applied on hashing value should should be
single or triple DES (default).

Entered PEK value will be XOR-ed with the value of 000000000000FF00 000000000000FF00 (see ANSI
X9.24-2004 Appendix A, A.5, page 42) as part of the processing.

DUKPT: MAC operation finished

****************************************
PEK: 4EC2A2974ECA53F5691E5273963EBE5C
Data:
30313030f23e069529e081800000000030303730353730303330303330303039393939393939393939
—————————————-
MAC: 01FE54357EF29DEA

DUKPT Data

The last screen provides facility to encrypt or decode data with current PEK key. Entered PEK value will
be XOR-ed with the data key variant of 0000000000FF0000 0000000000FF0000. (Unchecking Data
Variant checkbox will revert to 00000000000000FF 00000000000000FF).
And in order to have a high degree of isolation between the data encrypting key and the PIN key, the data
encryption key shall be in this case processed by a OWF before use. The OWF defined here is that the
derived variant value is encrypted using itself as the key.
Encryption:

DUKPT: DATA operation finished

****************************************
PEK: 4EC2A2974ECA53F5691E5273963EBE5C
KEY: A4E5BEF08AD403C9AFE3181E424CA0A4
Data:
2542353435323330303535313232373138395E484F47414E2F5041554C2020202020205E303830343
—————————————-
Encrypted DATA:
900D314BF59C1E4A25BFD725E12E547F52EEFCFF5C4848591FF8ADB050ADF220E4745D3566503AD

Decryption:

DUKPT: DATA operation finished

****************************************
PEK: 4EC2A2974ECA53F5691E5273963EBE5C
KEY: A4E5BEF08AD403C9AFE3181E424CA0A4
Data:
900D314BF59C1E4A25BFD725E12E547F52EEFCFF5C4848591FF8ADB050ADF220E4745D3566503AD
—————————————-
Decoded DATA:
2542353435323330303535313232373138395E484F47414E2F5041554C2020202020205E3038303433

Decoded DATA (binary): %B5452300551227189^HOGAN/PAUL ^08043210000000725000000?

DUKPT (AES)
DUKPT panels consists of tabs following ANSI X9.24-3-2017 – IPEK derivation, PEK derivation, PIN
encryption and MAC encryption.

The standard describes the AES DUKPT algorithm, which is used to derive key(s) from an initial terminal
DUKPT key based on the transaction number.
Derived keys can be used for a variety of functions, such as encryption of PINs, data or other keys, for
derivation of other keys, for message authentication, etc.
AES DUKPT supports the derivation of AES-128, AES-192, AES-256, and double and triple length TDEA
keys from AES-128, AES-192, and AES-256 initial keys.

PEK Derivation
IPEK and PEK derivation functions are the first options available. These require Base Derivation Key
(BDK) and Key Serial Number (KSN), or IPEK & KSN for PEK derivation, as input parameters. BKD and
IPEK keys are expected to be entered in its hexadecimal form. The KSN has hexa-decimal digits (0-9 | A-F)
and input size has to be 16 to 24 characters.

DUKPT (AES): Working keys derivation finished

****************************************
BDK: FEDCBA9876543210F1F1F1F1F1F1F1F1
KSN: 123456789012345600000005
—————————————-
Initial Key: 1273671EA26AC29AFA4D1084127652A1
KSN (working): 123456789012345600000005
Transaction Counter: 00000005
Initial Key Id: 1234567890123456
—————————————-
PIN Encryption Key: 35A43BC9EFEB09C756204B57E3FB7D4D
Msg. Auth. Gen. Key: 0588185FE1FF8C7E22FAD78C1C61F065
Msg. Auth. Ver. Key: 75923E6509A80723C60DB75884F4C984
M. Auth. Both Ways Key: 082FAFAAC478050328DE6F3725EFE4B4
Data Encr. Encrypt Key: CA02DF6F30B39E14BD0B4A30E460920F
Data Encr. Decrypt Key: 666F64FBA90777C17DF22C0BF2D1142F
D. Encr. Both Ways Key: 948BE71B8C8DD81362C88061D462A946
Key Encryption Key: 507838E817F32B6D75151FC9E8EF1A80
Key Derivation Key: E61C7FB544669AF1E49D8264FF8E3979
DUKPT PIN

DUKPT PIN screen allows PIN block encryption/decoding with a PEK key.
Encryption:

DUKPT (AES): PIN operation finished

****************************************
PEK: 35A43BC9EFEB09C756204B57E3FB7D4D
PIN block: 04124389999AAAABAAAAAAAAAAAAAAAA
—————————————-
Encrypted PIN: AD444123078A462677E5718CDD833280

Decryption:

DUKPT (AES): PIN operation finished

****************************************
PEK: 35A43BC9EFEB09C756204B57E3FB7D4D
PIN block: AD444123078A462677E5718CDD833280
—————————————-
Decoded PIN: 04124389999AAAABAAAAAAAAAAAAAAAA

DUKPT MAC

DUKPT MAC screen takes BDK, KSN and Data fields and outputs ANSI X9.24-3-2017 MAC. All input
fields are expected to be in a hexadecimal format with their appropriate lengths. Note that the data field
size is limited to 8120 characters.

DUKPT (AES): MAC operation finished

****************************************
MAC Key: 0588185FE1FF8C7E22FAD78C1C61F065
Data:
30313030f23e069529e081800000000030303730353730303330303330303039393939393939393939
—————————————-
MAC: 91F061EDC15B3EBC

DUKPT Data
The last screen provides facility to encrypt or decode data with current PEK key.
Encryption:

DUKPT (AES): DATA operation finished

****************************************
DEK: CA02DF6F30B39E14BD0B4A30E460920F
Data:
900D314BF59C1E4A25BFD725E12E547F52EEFCFF5C4848591FF8ADB050ADF220E4745D3566503AD
—————————————-
Encrypted DATA (hexdec):
C5ECF7D9A76A37B1D352148DA24FB85018D7D9F00ACC2918CAAD0B3F856449620283BF26EA7DE5

Decryption:

DUKPT (AES): DATA operation finished

****************************************
DEK: CA02DF6F30B39E14BD0B4A30E460920F
Data:
C5ECF7D9A76A37B1D352148DA24FB85018D7D9F00ACC2918CAAD0B3F856449620283BF26EA7DE5
—————————————-
Decoded DATA (hexdec):
900D314BF59C1E4A25BFD725E12E547F52EEFCFF5C4848591FF8ADB050ADF220E4745D3566503AD
Decoded DATA (ASCII):
900D314BF59C1E4A25BFD725E12E547F52EEFCFF5C4848591FF8ADB050ADF220E4745D3566503AD
MAC Algorithms

ISO/IEC 9797-1
ISO/IEC 9797-1 MACs screen supports MAC generation algorithms specified in ISO-9797-1. Supported
algorithms are:

MAC Algorithm 1 (CBC-MAC)

MAC Algorithm 2
MAC Algorithm 3 (Retail MAC)
MAC Algorithm 4
MAC Algorithm 5 (CMAC)
MAC Algorithm 6

ANSI X9.9 & X9.19

ANSI X9.9 (Wholesale MAC)

ANSI X9.9 MAC screen is for message authentication code (MAC) generation as described in ANSI X9.9
specification. This is reasonably old retail banking technique which still proves to be very fast and
protects data consistency along its way between POS and transaction acquirer.

Screen gets single length DEA cryptographic key and hexadecimal data and outputs MAC.
ANSI MAC operation finished
****************************************
Algorithm: ANSI MAC X9.9 (Wholesale MAC)
Key (K) : 0123456789ABCDEF
Data: 4E6F77206973207468652074696D6520666F7220616C6C20
Data (padded): 4E6F77206973207468652074696D6520666F7220616C6C20
Truncation: 4
—————————————-
MAC: 70A30640CC76DD8B
Truncated MAC: 70A30640

ANSI X9.19 (Retail MAC)

ANSI X9.19 is yet another banking standard created by the ANSI X9 working group and published by the
American Bankers Association. X9.19 is essentially an update of ANSI X9.9, with a few minor changes to
deal with the change from wholesale banking in X9.9 to retail banking in X9.19.

ANSI X9.19 MAC generator uses ANSI 9.19 (ISO/IEC 9797-1, algorithm 3) with padding method 1
algorithm for generating message authentication code in payments industry. It takes two single length
DEA keys and applies procedure described in ANSI X9.19 MAC on hexadecimal data provided in the Data
field.

ANSI MAC operation finished

****************************************
Algorithm: ANSI MAC X9.19 (Retail MAC)
Key (K) : 0123456789ABCDEF
Key (K’): FEDCBA9876543210
Data: 4E6F77206973207468652074696D6520666F7220616C6C20
Data (padded): 4E6F77206973207468652074696D6520666F7220616C6C20
Truncation: 4
—————————————-
MAC: A1C72E74EA3FA9B6
Truncated MAC: A1C72E74
AS2805.4.1
AS2805 MACs screen supports two MAC alogorithms specified in AS2805.4.1 (MAC Method 1)

MAC Method 1

AS2805.4.1 MAC operation finished

****************************************
Algorithm: AS2805.4.1 MAC Method 1
Key (K): 0123456789ABCDEFFEDCBA9876543210
Data: 4E6F77206973207468652074696D6520666F7220616C6C20
Data (padded): 4E6F77206973207468652074696D6520666F7220616C6C20
Truncation: 4
—————————————-
MAB: 93462A6DB9B4A4D1
MAC: 93462A6D

MAC Method 2 (same as ISO9797-1 MAC Algorithm 3)

AS2805.4.1 MAC operation finished

****************************************
Algorithm: AS2805.4.1 MAC Method 2
Key (KL): 0123456789ABCDEF
Key (KR): FEDCBA9876543210
Data: 4E6F77206973207468652074696D6520666F7220616C6C20
Data (padded): 4E6F77206973207468652074696D6520666F7220616C6C20
Truncation: 4
—————————————-
MAB: A1C72E74EA3FA9B6
MAC: A1C72E74

TDES CBC-MAC
TDES CBC-MAC – A cipher block chaining message authentication code (CBC-MAC) is a technique for
constructing a message authentication code from a block cipher. The message is encrypted with some
block cipher algorithm in CBC mode to create a chain of blocks such that each block depends on the
proper encryption of the previous block. This interdependence ensures that a change to any of the
plaintext bits will cause the final encrypted block to change in a way that cannot be predicted or
counteracted without knowing the key to the block cipher.

TDES MAC operation finished

****************************************
Algorithm: TDES CBC-MAC
Key (K): 0123456789ABCDEFFEDCBA9876543210
Padding: ISO9797-1 (Padding method 1)
Data: 4E6F77206973207468652074696D6520666F7220616C6C20
Data (padded): 4E6F77206973207468652074696D6520666F7220616C6C20
Truncation: 4
—————————————-
MAC: 93462A6DB9B4A4D1
Truncated MAC: 93462A6D

HMAC
In cryptography, an HMAC (sometimes expanded as either keyed-hash message authentication code or
hash-based message authentication code) is a specific type of message authentication code (MAC)
involving a cryptographic hash function and a secret cryptographic key. As with any MAC, it may be used
to simultaneously verify both the data integrity and the authenticity of a message.
HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with
a secret shared key.

The cryptographic strength of HMAC depends on the properties of the underlying hash function.

HMAC SHA-256: operation finished

****************************************
Key: 0123456789ABCDEFFEDCBA9876543210
Data: 4E6F77206973207468652074696D6520666F7220616C6C20
—————————————-
HMAC: 4B9C609944D6F0F7C3AAC555EBDB5420048CC1123E7F113AAD781ABF290F18ED
CMAC
CMAC (Cipher-based Message Authentication Code) is a block cipher-based message authentication code
algorithm. It may be used to provide assurance of the authenticity and, hence, the integrity of binary data.
This mode of operation fixes security deficiencies of CBC-MAC (CBC-MAC is secure only for fixed-length
messages).

CMAC (AES): operation finished

****************************************
Key: 2B7E151628AED2A6ABF7158809CF4F3C
Data:
6BC1BEE22E409F96E93D7E117393172AAE2D8A571E03AC9C9EB76FAC45AF8E5130C81C46A35CE41
—————————————-
CMAC: 51F0BEBF7E3B9D92FC49741779363CFE

Retail
On this screen you may manually simulate, with using combination of input parameters, the:

Wholesale MAC (ANSI X9.9)

Retail MAC operation finished
****************************************
Key: 0123456789abcdefFEDCBA9876543210
Algorithm: DES
Finalize: None
Data: 4E6F77206973207468652074696D6520666F7220616C6C20
—————————————-
MAC: 70A30640CC76DD8B

Retail MAC (ANSI X9.19)

Retail MAC operation finished

****************************************
Key: 0123456789abcdefFEDCBA9876543210
Algorithm: DES
Finalize: 3DES
Data: 4E6F77206973207468652074696D6520666F7220616C6C20
—————————————-
MAC: A1C72E74EA3FA9B6

TDES CBC MAC

Retail MAC operation finished

****************************************
Key: 0123456789abcdefFEDCBA9876543210
Algorithm: 3DES
Finalize: None
Data: 4E6F77206973207468652074696D6520666F7220616C6C20
—————————————-
MAC: 93462A6DB9B4A4D1

PIN Blocks

PIN Blocks General

BP-CryptoCalc handles PIN block encoding and decoding for all most common PIN block formats:
 Format 0 (ISO-0)
Format 1 (ISO-1)
Format 2 (ISO-2)
Format 3 (ISO-3)
Format 4 (ISO-4)
ANSI X9.8
Docutel & Diebold & NCR ATMs
ECI-1
ECI-2
ECI-3
ECI-4
IBM 3621
IBM 3624
IBM 4704 Encrypted PIN Pad
IBM 5906
VISA-1
VISA-2
VISA-3
VISA-4
Europay/MasterCard (Pay Now & Pay Later)

The first option picks a format. Other input fields are Primary Account Number (PAN) and Personal
Identification Number (PIN) for encoding operation, where fields PIN block and PAN are needed for
decoding operation. PAN field length is limited to numbers and size 13..19, PIN field takes 4 up to 12
digits and PIN block takes 16 hexadecimal values only. For some algorithms the Padding character is
needed.

Encode
PIN blocks: PIN block encrypt operation finished
****************************************
PAN: 43219876543210987
PIN: 1234
—————————————-
Clear PIN block: 0412AC89ABCDEF67

Decode
PIN blocks: PIN block decode operation finished
****************************************
PIN block: 0412AC89ABCDEF67
PAN: 43219876543210987
—————————————-
Decoded PIN: 1234

PIN Blocks AES

AES (Advanced Encryption Standard) OLP Format 4 encryption. This screen provided the encryption to
and decoding from the PIN Block format 4.

AES OLP PIN Block Format 4 operation finished

****************************************
Key: C1D0F8FB4958670DBA40AB1F3752EF0D
PIN: 56798
PIN Block: 4556798AAAAAAAAAC8BC2AE3BAAAB916
PAN: 432198765432109870
PAN Block: 64321987654321098700000000000000
Mode: AES-ECB
—————————————-
Intermediate Block A: 235CF89BDD6D9EA9A7DBEC50A583AA7C
Intermediate Block B: 476EE11CB82EBFA020DBEC50A583AA7C
—————————————-
Encrypted PIN Block: 31A033E822A05EACEF025611999014B4

AES OLP PIN Block Format 4 operation finished

****************************************
Key: C1D0F8FB4958670DBA40AB1F3752EF0D
PIN Block: 31A033E822A05EACEF025611999014B4
PAN: 432198765432109870
PAN Block: 64321987654321098700000000000000
Mode: AES-ECB
—————————————-
Intermediate Block B: 476EE11CB82EBFA020DBEC50A583AA7C
Intermediate Block A: 235CF89BDD6D9EA9A7DBEC50A583AA7C
—————————————-
Decoded PIN Block: 4556798AAAAAAAAAC8BC2AE3BAAAB916
PIN: 56798
PAN: 432198765432109870

PIN Offset (IBM 3624 Method)

Offset
To allow the customer to select his own PIN, a PIN offset is used by the IBM 3624 PIN generation
algorithm to relate the customer-selected PIN to the generated PIN.

The PIN offset generation algorithm requires two parameters in addition to those used in the 3624 PIN
generation algorithm. They are a customer-selected PIN and a 4-bit PIN check length. The length of the
customer-selected PIN is equal to the assigned-PIN length.

The offset data value is the result of subtracting (modulo 10) the leftmost n digits of the intermediate PIN
from the customer-selected PIN.

PIN offset (IBM 3624 Method): PIN offset derivation finished

****************************************
PVK: 0123456789ABCDEFFEDCBA9876543210
PAN: 1234567899876543
PIN: 3196
Decimalisation table: 0123456789012345
Validation Data: 0000000N0000
—————————————-
Intermediate PIN: 3196
PIN Offset: 0000
PIN
Functionality of this screen generates a n-digit PIN based on 3624 PIN Generation Algorithm. Inputs are
Pin Derivation Key, PAN, PIN and decimalisation table. The assigned PIN offset length parameter is
hardcoded = 4.

PIN offset (IBM 3624 Method): PIN offset validation finished

****************************************
PVK: 0123456789ABCDEFFEDCBA9876543210
PAN: 1234567899876543
PIN offset: 0000
Decimalisation table: 0123456789012345
PAD char: F
—————————————-
Native PIN: 3196
PIN: 3196

PIN PVV Calculator

The VISA method generates a PIN verification value (PVV). Similar to the offset value, it can be stored on
the card’s track data, or in a database at the card issuer. This is called the reference PVV.
The VISA method takes the rightmost eleven digits of the PAN excluding the checksum value, a PIN
validation key index (PVKI, chosen from one to six) and the required PIN value to make a 64 bit number,
the PVKI selects a validation key (PVK, of 128 bits) to encrypt this number. From this encrypted value, the
PVV is found.

To validate the PIN, the issuing bank calculates a PVV value from the entered PIN and PAN and compares
this value to the reference PVV. If the reference PVV and the calculated PVV match, the correct PIN was
entered.

Unlike the IBM method, the VISA method doesn’t derive a PIN. The PVV value is used to confirm the PIN
entered at the terminal, was also used to generate the reference PVV. The PIN used to generate a PVV
can be randomly generated or user selected or even derived using the IBM method.

This algorithm generates a 4-digit PVV. Inputs are Pin Derivation Key, PAN, PIN and PIN Verification Key
Indicator (PVKI). The assigned PVV length parameter is hardcoded = 4.

PVV
PIN PVV: PIN PVV derivation finished
****************************************
PVK: 0123456789ABCDEFFEDCBA9876543210
PAN: 1234567899876543
PIN: 1234
PVKI: 1
—————————————-
PVV: 9365

PIN
PIN PVV: PIN extraction finished
****************************************
PVK: 0123456789ABCDEFFEDCBA9876543210
PAN: 1234567899876543
PVV: 9365
PVKI: 1
—————————————-
PIN: 1234
VISA Certificates

VISA Certificates handling

Issuer Signing Request Validation – parses data in file provided, decodes self-signing certificate and
validates certificate signature.
Signed Issuer Public Key Data Validation – parses data in file provided, decodes Signed Issuer Public Key
Data and validates certificate signature with CA PK.

Validate Issuer Signing Request

Issuer Certificate Validation

****************************************
Reading CA Public Key File
—————————————-
File: None
Header: 22
Length Modulus PK Issuer: B0(1408)
Modulus PK Issuer:
E103EC0217E385D60E3C470893DA4AD73A7EE32E20128D6C993EE2D7CB5C1072CC7E13D262AC0F
Length Exponent PK Issuer: 01(8)
Exponent PK Issuer: 03
Tracking Number: 982189
Enc Data:
AFB775FA5C596F9A5105D82399682C8C7E7F4D63ED51DB500409AC3DEF0546B740E9339657A2F2B
Hash Data:
AFB775FA5C596F9A5105D82399682C8C7E7F4D63ED51DB500409AC3DEF0546B740E9339657A2F2B
Dec Data:
231010000002445513FF12229821890101B001E103EC0217E385D60E3C470893DA4AD73A7EE32E20
—————————————-
Validating Self-Signed Issuer Public Key Data
—————————————-
Header: 23
Service Identifier: 10100000
Certificate Format: 02
Expiration Date: 1222
Tracking Number: 982189
Hash Algorithm Id: 01
PK Algorithm Id: 01
Length Modulus PK Issuer: B0(1408)
Length Exponent PK Issuer: 01(8)
PK Leftmost Portion:
E103EC0217E385D60E3C470893DA4AD73A7EE32E20128D6C993EE2D7CB5C1072CC7E13D262AC0F
Exponent: 03
Hash: 37D171620210D61A00032B667B80F68F271B35AF
Hash validation passed
—————————————-
Result: Validation Successful

Validate Signed Issuer Public Key Data

Issuer Signed Data file Validation

****************************************
Reading Issuer’s Public Key Certificate
—————————————-
File: None
Header: 20
Service Identifier: 10100000
Length Modulus PK CA: B0(1408)
Length Exponent PK CA: 01
PK Algorithm Id: 01
RID: A000000003
PKI: 92
Modulus PK CA:
996AF56F569187D09293C14810450ED8EE3357397B18A2458EFAA92DA3B6DF6514EC060195318FD
Exponent PK CA: 03
Hash: 429C954A3859CEF91295F663C963E582ED6EB253
Enc Data:
7D639B3ACAFB00DF0E25CB760CF28E25309E3E3D9C863521F68473F5506C1BF9303E84AEF9E807B
Dec Data:
2110100000A00000000392122201996AF56F569187D09293C14810450ED8EE3357397B18A2458EFAA
Validating Self-Signed CA Public Key Data
—————————————-
Header: 21
Service Identifier: 10100000
RID: A000000003
PKI: 92
Expiration Date: 1222
Length Exponent PK CA: 01
Hash Algorithm Id: 01
PK Algorithm Id: 01
PK Leftmost Portion:
996AF56F569187D09293C14810450ED8EE3357397B18A2458EFAA92DA3B6DF6514EC060195318FD
Hash: 429C954A3859CEF91295F663C963E582ED6EB253
Hash input:
A00000000392996AF56F569187D09293C14810450ED8EE3357397B18A2458EFAA92DA3B6DF6514EC
Hash validation passed
Reading Done

Reading Issuer’s Certificate Output File

—————————————-
File: None
Header: 24
Service Identifier: 10100000
Issuer ID Number: 445513FF
Certificate Serial Number: 033524
Certificate Expiration Date: 1222
IPK Remainder Length: 24
IPK Remainder:
871B2E069C67918CEE508F89F56585F57ECF2896B5CF3B57DC48AB08D69366769D6D07D1
IPK Exponent Length: 01
IPK Exponent: 03
CA PK Index: 92
Enc Data:
0D75783A2E42CFA88A2F4B4DB635F9798D08D776038FC4B446715A6840C6A88D387051F5F2A73FB
Reading Done

Validating Signed Issuer Public Key Data

—————————————-
Dec Data:
6A02445513FF12220335240101B001E103EC0217E385D60E3C470893DA4AD73A7EE32E20128D6C9
Header: 6A
Certificate Format: 02
Issuer ID Number: 445513FF
Certificate Expiration Date: 1222
Certificate Serial Number: 033524
Hash Algorithm Id: 01
PK Algorithm Id: 01
Length PK Issuer: B0(1408)
Length Exponent PK Issuer: 01
Issuer PK Certificate:
E103EC0217E385D60E3C470893DA4AD73A7EE32E20128D6C993EE2D7CB5C1072CC7E13D262AC0F
Hash: 1437ACD494A38DE22C54FF26D1A5845AF90FB280
Trailer: BC
Hash input:
02445513FF12220335240101B001E103EC0217E385D60E3C470893DA4AD73A7EE32E20128D6C993E
Hash validation passed

Validating Detached Signature

—————————————-
Enc Data:
6328B88DDE26F91D6C4D3CA70331525DAF4AADAB187413BFDDD93BBE1C9C672C218928283F179
Dec Data:
0001FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Header: 00
Block Format Code : 01
Padding Characters:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Separator: 00
PKCS#1 Value D Format: 3021300906052B0E03021A05000414
Hash: 9CCC96186581F10ED468ED76E78B3F4C97F7C244
Hash input:
2410100000445513FF033524122224871B2E069C67918CEE508F89F56585F57ECF2896B5CF3B57DC
Hash validation passed
—————————————-
Result: Validation Successful

ZKA

German banks created their own standard very similar to DUKPT. BP-CryptoCalc allows ZKA Session key
derivation and also PIN-block encryption and decryption.

SK Derivation
ZKA: Session key derivation finished
****************************************
MK: 67676767676767672323232323232323
CM: 00004D000341000000004D0003210000
Rnd: 0123456789ABCDEFFEDCBA9876543210
—————————————-
SK: 38A4524C5823C2FE920220CE51E9610B
KCV: 4B9454

PIN Encrypt
ZKA: PIN decode operation finished
****************************************
SK-pac: 38A4524C5823C2FE920220CE51E9610B
PIN block: 04124389999AAAAB
—————————————-
Encrypted PIN: 9DBE4865B4D37F6D

PIN Decode
ZKA: PIN decode operation finished
****************************************
SK-pac: 38A4524C5823C2FE920220CE51E9610B
PIN block: 9DBE4865B4D37F6D
—————————————-
Decoded PIN: 04124389999AAAAB
Summary

In this article, we went through the functionality of Cryptographic Calculator covered by the Payments
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.

Solutions Customers Resources Company

Contact us
Payments Processing Banks Knowledge Base About us

Testing PSPs Brochures Partners

Merchants Tutorials Contact us

Case Studies Blog

Certificates

© EFTlab 2022. All rights reserved. Terms and conditions Privacy Policy Cookie policy Follow us: