Cryptographic key exchange

October 14, 2024

Learn how you can obtain cryptographic keys to enable secure information exchange between Kushki and your business.

How can I obtain cryptographic keys?

To obtain the cryptographic keys that your merchant will use to communicate with Kushki and enable the processing of card-present transactions, you need to follow these steps:

The steps mentioned are detailed below:

1. Definition of agreements and operational conditions

As the first step, a session will be conducted between your merchant and Kushki to establish the course of the following actions:

1.1. Review and approval of the conditions of the key exchange ceremony

• The HSM is a hardware security module that generates, protects, and manages the keys that will be used to encrypt and decrypt transaction processing data in your merchant.
• Your HSM provider must agree to the conditions of the cryptographic key exchange ceremony.

Once your merchant agrees to these conditions, you will need to exchange components with Kushki’s HSM provider and make the following requests:

Sign a Non-Disclosure Agreement (NDA) for the HSM (Hardware Security Module) service, in which the information of the shared cryptographic keys will be loaded. This process will ensure the safeguarding of the keys, allowing your merchant to access the HSM portal. Create and maintain information for Security Officers (SOs), including contact details and the correct SO groups within the portal. These individuals will be responsible for security in the key exchange process. Follow the step-by-step process outlined in this article to complete the key exchange process.

1.2. Establishment of work mechanisms and secure channels

Work mechanisms and secure channels will be established through which sensitive information will be shared between your merchant and Kushki. At least two (2) security custodians (known as Security Officers) will be defined, who will be responsible for executing the key exchange on your merchant’s POS terminals. These security custodians should not report to the same person.

2. Kushki requests required information

To initiate the cryptographic key exchange process:

• We will request required information from you in the affiliation process and obtaining the card-present service.
• This process will be carried out to enable Kushki’s HSM service and make your merchant information available in the Kushki console.

3. Kushki receives information from your merchant

Your merchant will share the requested data, which will be received by Kushki to initiate the review process and thus begin the integration process of the card-present service.

4. Kushki validates information to register your merchant

Upon receiving the requested information, Kushki will review and validate this data in order to register your merchant and enable the service through the HSM, providing your merchant with a secure and highly available host connection for processing your merchant’s transactions.

Once the information is received and validated, the process will continue.

5. Kushki generates and sends KEK and KCV

Kushki will generate and send the following key components for encryption:

• The KEK (Key Encryption Key) corresponds to a transport key, which is shared by Kushki through secure packaging (production environment) or secure electronic means (testing environment). This key will allow encryption and decryption of other keys that will be shared in the future between Kushki and your merchant; therefore, this information must be stored under strict confidentiality standards in your merchant’s Hardware Security Module(HSM).

• The KCVs (Key Checksum Value) corresponding to verify the integrity of the generated keys. This information will be sent directly via email to the security custodians (Security officer/s) defined in step 1.1.1. When the components are sent, these individuals will receive the following information:

• Reference information of the generated key (Key reference information).

• Contact information (excluding address) of the Security Officer who sends the cryptographic key component.

• Shipment details and the serial number of the security bag (TEA bag)

• A link to the HSM Portal page where the verification checklist must be completed after receipt.

6. Your merchant receives information on Kushki’s HSM portal

Once your merchant’s Security Officers have met the requirements mentioned in the previous section, they will receive information about your merchant’s account on Kushki’s HSM provider portal. The reception of this information will depend on the working environment.

• UAT testing environment

In this environment, components can be sent through secure electronic means such as encrypted email, a secure vault, and SFTP (SSH File Transfer Protocol). The information you will receive will appear in a format similar to the following:

• Production environment:

Kushki will send three envelopes with a physical key component sent via secure packaging, exchanged to at least two of the security custodians who do not report to the same person.

7. Your merchant validates and loads the components into your HSM.

Receive the components and checksums of each key to upload and validate them in your HSM. If the verification was successful, you need to perform the following steps:

• Inform to Kushki that the upload was successful via email to seguridad@kushkipagos.com

• Your merchants’ Security Officers (SOs) must complete the verification checklist to confirm the receipt of the key components through Kushki’s HSM service provider portal. This information will be received via email, following the instructions included therein.

If you encounter any issues with the loading and validation of the components in your HSM, please communicate this information to seguridad@kushkipagos.com.

8. Kushki enables your merchant information in the console

Kushki will register your merchant in the console. In this platform, you will be able to verify the following information:

• Merchant_id: identifier of your merchant in Kushki’s platforms.
• Private-Credential-Id (private key): private security key to validate and authorize all transactions of your merchant.
• Other relevant information, such as the Public-Credential-Id (public key), which is an exclusive alphanumeric key from Kushki that allows you to authenticate executed transactions.

9. Generation and Sending of the BDK

Kushki will generate two (Base Derivation Key, BDK) keys. These keys will allow you to perform the corresponding derivation to continue with the DUKPT process.

• The first Base Derivation Key will be created for the data field.
• The second Base Derivation Key will be created for the pin (pin_block) field.

These keys will be exchanged encrypted and through secure electronic means with the (KEK) (Key Encryption Key) in TR-31 format.

The delivery times (SLAs) for this information are as follows:

An example of the BDK information encrypted with a KEK in TR-31 format is as follows:

RD0112B0TX00N00004FD842D565C0BDD9741A3EAB5106A78087A4D0729A56319F32AF9FBFC6FAE0A184DA40D08FA279FBB50E7598936AD18F

10. Your merchant executes internal processes for POS terminal management

Now that your merchant’s Security Officers (SOs) have received the BDKs, it is time for you to execute internal processes to manage this information on the POS terminals using the DUKPT process.