We are working on our beta version. Stay tuned for its official release! You can also contact your account manager for more information.
To obtain the working cryptographic keys that will be used in the derived unique key per transaction (DUKPT) process, Kushki and the client will perform the activities that are detailed below:
There is a session between Kushki and the merchant where the conditions for exchanging keys with third parties are reviewed. This process requires the merchant's HSM provider to agree to the terms of the key exchange ceremony. If agreed, they establish the working mechanisms and secure channels for exchanging sensitive information between Kushki and the merchant, as well as defining at least two security officers (SOs) on the part of the merchant.
NOTE: The merchant is required to have a hardware security module (HSM) due to the cryptographic key exchange process.
Kushki requests the required documentation to register the merchant in the HSM service on Kushki's behalf and to register it in the Kushki console. Once the requested documentation is obtained, the process continues.Kushki receives and validates the requested documentation.
Generation and sending of the components of a Key Encryption Key (KEK)#
Kushki generates and sends three key components for key encryption key (KEK) as well as their respective Key Checksum Value (KCV) for the checksum of each cryptographic key, by the secure means established above to the security officers previously defined. When requesting the shipment of the components, the SOs that receive the components will receive an email with the following:
Key reference information
Contact details (excluding address) of the corresponding sending SO
The shipment details and tamper-evident bag serial number
A link to the Portal page where the checklist must be completed following receipt
NOTE: Depending on the work environment, Kushki may send KEKs electronically or physically.
For Kushki to perform the key exchange, security custodians (SOs) must:
Be registered in the Kushki HSM service portal.
Each of the SOs participating in the exchange must have an active account on the Kushki HSM service portal.
They must be placed in the correct SO groups (1, 2 or 3).
They must keep the address for shipping the physical components updated.
At the time of registering the SO on the portal, they will receive information about their account on the Kushki HSM provider portal which will be useful later.
Kushki may ship KEK components by secure electronic means (email, security vault, SFTP). An example may be through encrypted email. The merchant will receive the information in a table like the following:
Kushki will ship three security envelopes with one key-component printed on paper per envelope to at least two security custodians who do not report to the same person.
NOTE: Shipping of components usually takes approximately two weeks, depending on SOs locations.
The merchant receives the components and checksums for each key so they can load and validate them in their HSM. If the verification was successful, the merchant must:
Inform Kushki that the upload was successful by sending an email to the address seguridad@kushkipagos.com with “KEK component check successful - [MERCHANT_NAME]” in the subject line and “Check successful” in the message.
SOs will be required to complete the receipt confirmation checklist through the Kushki HSM Service Provider Portal that will arrive by mail, following the instructions therein.
In case of any problem with validation, you must inform Kushki at the same email address.
NOTE: Once the component has been activated in the Kushki HSM service portal, it is necessary for the SOs to destroy it.
Generation and sending of Base Derivation Key (BDK)#
Kushki registers the merchant in the Kushki console, where the merchant can obtain its merchant_id, its private security key to transact (Private-Credential-Id) among other relevant information. Once the merchant is registered, Kushki will generate two base derivation keys (BDK), one for data and another for pin (pin_block), which will be exchanged in an encrypted manner with the KEK in TR-31. The exchange will be by secure electronic means.Example of a BDK encrypted with a KEK in TR-31 format:RD0112B0TX00N00004FD842D565C0BDD9741A3EAB5106A78087A4D0729A56319F32AF9FBFC6FAE0A184DA40D08FA279FBB50E7598936AD18F
NOTE: The BDKs in the production environment will be shared by secure electronic means (for example 1password).
Once the BDKs are obtained, the merchant must run its internal processes for the management of POS terminals with the DUKPT process.
