BP-Tools: SSL certificates with BP-CCALC
January 29, 2016BP-Tools: Cryptographic Calculator – EMV menu
January 29, 2016BP-Tools: Cryptographic Calculator – Payments menu
Introduction
The BP-Tools set consist of applications supporting payment transaction service development, testing and benchmarking. It currently consists of following components: Cryptographic Calculator, EMV Tool, HSM Commander and P3 Card Edit Tool.
EFTlab distributes BP-Tools under Creative Commons Legal Code Attribution-NoDerivs 3.0 Unported and completely free. This package comes with a full support and monthly releases instantly bringing new features.
This tutorial focuses on Cryptographic Calculator functionality and is provided in three separated parts as per functionality topics covered by its main menu– Generic cryptography, Payments cryptography and EMV. 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.
ANSI X9.9
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 X9.19: MAC operation finished
****************************************
Key (first): 0123456789ABCDEF
Key (second): FEDCBA9876543210
Data: 4E6F77206973207468652074696D6520666F7220616C6C20
—————————————-
MAC: A1C72E74EA3FA9B6
ANSI X9.19
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 X9.19: MAC operation finished
****************************************
Key (first): 0123456789ABCDEF
Key (second): FEDCBA9876543210
Data: 4E6F77206973207468652074696D6520666F7220616C6C20
—————————————-
MAC: A1C72E74EA3FA9B6
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: 02107238000102C000111670343010001006660000000000000000000912065731000092155726091206703400393138303030303230343030303133303039373334202020203032390301000000000020202020202020200000000000000000020000000000
—————————————-
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
Card Verification Values
This screen provides facility to generate and validate all major card not present (CNP) values – CVV/iCVV/CVV2.
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 + 1+32H. The key is encrypted under the variant 4 of LMK pair 14-15.
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
DUKPT
DUKPT panels consists of tabs following ISO9797 – IPEK derivation, PEK derivation, PIN encryption and MAC encryption. Method described in ISO9797 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: 30313030f23e069529e08180000000003030373035373030333030333030303939393939393939393939393036323931333236323330303030303431333236323330363239313231323036323930323130303134314330303030303030304330303030303030303034313031353337373430353130303036303030373035373030333d31323132313132373735353131313131343030303030303030303930313131324c5437303633303130303030304c544c543730363330305c5c4b616e74616c69736b6961695c363934383120202020202020204c54552020202020202020203939393030343135313030303333333031363734303531303030363030303730353730313532313031303132313031344331303130303036373760001400000000003130303030303030303930314832486e6455544420202020494453504c202020202020203030303030343030
—————————————-
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: 2542353435323330303535313232373138395E484F47414E2F5041554C2020202020205E30383034333231303030303030303732353030303030303F00000000
—————————————-
Encrypted DATA: 900D314BF59C1E4A25BFD725E12E547F52EEFCFF5C4848591FF8ADB050ADF220E4745D3566503ADFA2A0ECC7D597F6B73D079928E27EFE1C1C59AC4F0A99C9D5
Decryption:
DUKPT: DATA operation finished
****************************************
PEK: 4EC2A2974ECA53F5691E5273963EBE5C
KEY: A4E5BEF08AD403C9AFE3181E424CA0A4
Data: 900D314BF59C1E4A25BFD725E12E547F52EEFCFF5C4848591FF8ADB050ADF220E4745D3566503ADFA2A0ECC7D597F6B73D079928E27EFE1C1C59AC4F0A99C9D5
—————————————-
Decoded DATA: 2542353435323330303535313232373138395E484F47414E2F5041554C2020202020205E30383034333231303030303030303732353030303030303F00000000
Decoded DATA (binary): %B5452300551227189^HOGAN/PAUL ^08043210000000725000000?
PIN Blocks
BP-CryptoCalc handles PIN block encoding and decoding for all most common PIN block formats: ISO-0, ISO-1, ISO-2 and ISO-3. The first option available belongs to the most spread ANSI X9.8 PIN block also known as Format 0. 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.
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 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
PAD char: F
—————————————-
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
—————————————-
Intermediate 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
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 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.
