Today’s electronic payments need a strong and trustful foundation lowering any possibility of fraudulent interference with a transaction. All security mechanisms are implemented in a way that such intrusion can be well detected and customers can stay confident into a financial institution and its technology. From the transaction processing level there are three main points where the payee’s security may come to a question. The first is a cardholder’s authentication, followed by card’s data validity and finally by the transaction integrity over the transfer.
In this article we’ll cover security from the BP-Sim processing – the PIN encryption and transaction integrity validation. (Card’s data validation is usually covered by an implementation of different security mechanisms e.g. LUHN digit check, EMV, CVV and more, which will be covered by one of our future tutorials. We will also focus at some generic functionality related to the security processing as the way how BP-Sim stores and treates its encryption keys in its centralized Key Store.
Finally we will describe a whole security process and its validation as it is being applied from perspective of BP-Source and BP-Host modules.
Before we’ll start with a detailed configuration and processing options implemented in BP-Sim, we need to understand how our application stores its security and encryption keys. As all the keys needs to be shared across the BP-Sim and BP-Host modules BP-Sim manages them through the centralised Key Store. Following configuration screen provides a good overview of all keys available in the system and their parameters configured.
All configuration fields should be self-describing, while we need to tell more about the Key’s type. This list-box contains all key types supported by the BP-Sim and helps GUI to organize those into groups. For example and as it will be shown later, having BKD (Base Derivation Key) type defined for the key means that this key will be listed in all BDK key options across the BP-Sim. Also BP-Host will take advantage of having a key type configured as optimised list of BDK keys will be used for a right BDK key look-up when searching for relevant terminal key through the DUKPT validation procedure.
Card configuration on a screen below shows an PIN configured for the card. This value will be used during a transaction processing as plain PIN input for PIN-block formation.
When the card’s PIN configuration is important, the terminal’s security settings are even more. On a picture below you can see a terminal security screen being divided into sections based on supported security standard. Note that key-related values are taken from the key store mentioned before.
Security standard used is being selected on BP-Source and BP-Host configuration screens. As seen on a screenshot below, each module has again the security tab, which directs is to use certain cryptographic mode and also select appropriate PIN-block format.
In addition to this BP-Source allows setting whether the MAC value should be validated on the response message and in addition to that BP-Host provides an option to carry on with a card validation. Results of these checks and debugging information on which key and method was applied will be then added into the transaction log.
Now when we did cover all configuration ingredients we will present this functionality on DUKPT security example with a step by step guide.
1/ DUKPT heavily relies on the Base Derivation Key (BDK) key being used for a session key derivation. So we’ll start with configuring a BDK key in a Key Store. The name given to the key should correspond with a terminal name, so the key can be easily identified by the BP-Host, where used. Key needs to be configured having the BDK type so it will become available for the terminal security options.
2/ Now we need to setup this BDK key in the selected terminal security tab. This will direct this terminal to use this key for the session key derivation. Second value needed to be filled here is the Key Serial Number based on the DUKPT standard which compromises from BDK key identifier, and counter. Note that this counter will be automatically increased and rolled over by the BP-Source on its processing.
3/ At this stage we need to tell BP-Source to use DUKPT-1 cryptographic mode. Select appropriate PIN-block format and encryption level to be applied in its final stage. Default and selection recommended by the retail security standard is to use triple DES for both encryptions. Note that EFTlab guarantees 2000TPS stress testing from a common office desktop ( Microsoft Windows platform, while 3000TPS for Linux builds) exactly with this setting (DUKPT with 3DES PIN and 3DES MAC) which was selected as the most resource hungry option.
4/ The same needs to be carried for BP-Host. You can select whether these modules will carry on with MAC & PIN-block validation or not. Note that BP-Sim is transaction format orientated simulator so you also need to consider that valid fields will be present in the message (e.g. DE52 & DE53 for ISO8583 based formats).
How would the processing look like itself?
1/ As the first BP-Source will realise that particular terminal was enabled for processing and will construct plain card’s PIN-block based on PIN-block format provided.
2/ When building the message the KSN value and BDK key are being used to generate IPEK and PEK values. During this process BP-Source increases a counter for the KSN value and also stores the IPEK value for later usage.
3/ BP-Source takes PIN-block in plain and encrypts it with the PEK value already prepared.
4/ BP-Source updates message’s KSN value with the value used for PEK derivation.
5/ Re-using IPEK, BP-Source generates full-length-message MAC (Message authentication code) and fills appropriate message’s field. Message is being send upstream
6/ BP-Host receives a message and detects fields needed for DUKPT processing.
7/ BP-Host makes a look-up for through all BDK keys configured using the key descriptor within the KSN value.
8/ BP-Host also tries to locate whether the card details received match any card configured within the BP-Sim and get’s its PIN-block based on its PIN-block format configuration.
9/ BP-Host follows the same procedure as the BP-Source did before, derives IPEK, PEK, re-generates transaction values as PIN-block and MAC and makes a comparison with values received withing the message. Result of this procedure is being logged in a transaction trace.
10/ Generated IPEK is again being used for preparing a response message (MAC only), where the original transaction request KSN value is being used again.
11/ Response message is delivered back to BP-Source, which takes care of the message MAC value validation re-using similar process as BP-Host utilized before. Result of this process is again lodged into the transaction trace.
In this tutorial, we did cover all configuration settings stepping into the BP-Sim secure message processing and we did also present how these settings fit into the bigger picture of transaction processing itself. We did also observed an importance of a proper key naming and described a validation methods being in practice by the BP-Host.