Estamos trabajando en nuestra versión beta. ¡Mantente al tanto de su lanzamiento oficial! También puedes contactar a tu ejecutivo de cuenta para más información.
Para obtener las llaves criptográficas de trabajo que se usarán en el proceso de derived unique key per transaction (DUKPT), Kushki y el cliente realizarán las actividades que se detallan a continuación:
Existe una sesión entre Kushki y el comercio donde se revisan las condiciones para intercambiar llaves con terceros. Este proceso requiere que el proveedor de HSM del comercio acepte los términos de la ceremonia de intercambio de llaves. Si se acepta, establecen los mecanismos de trabajo y los canales seguros para intercambiar información sensible entre Kushki y el comercio, además de definir al menos dos security officers (SOs) por parte del comercio.
NOTA: El comercio debe contar con un hardware security module (HSM) debido al proceso de intercambio de llaves criptográficas.
El comercio debe estar preparado para intercambiar componentes con el proveedor de HSM en nombre de Kushki. A continuación, los pasos a seguir:
Firmar el NDA del proveedor de HSM de Kushki y tener acceso al portal;
Crear y mantener SOs con datos de contacto correctos y grupos de SOs en el portal;
Estar preparado para seguir el proceso de intercambio de llaves tal como se define en esta documentación.
Solicitud y validación de la documentación requerida#
Kushki solicita la documentación requerida para registrar al comercio en el servicio de HSM en nombre de Kushki y para registrarlo en la Kushki Console. Una vez obtenida la documentación solicitada, el proceso continúa.Kushki recibe y valida la documentación solicitada.
Generación y envío de los componentes de una Key Encryption Key (KEK)#
Kushki genera y envía tres componentes de llave para la key encryption key (KEK), así como su respectivo Key Checksum Value (KCV) para el checksum de cada llave criptográfica, por los medios seguros establecidos arriba a los security officers definidos previamente. Al solicitar el envío de los componentes, los SOs que reciben los componentes recibirán un correo con lo siguiente:
Información de referencia de la llave
Datos de contacto (sin incluir la dirección) del SO remitente correspondiente
Los detalles del envío y el número de serie de la bolsa con evidencia de manipulación
Un link a la página del Portal donde se debe completar el checklist tras la recepción
NOTA: Según el entorno de trabajo, Kushki puede enviar las KEK de forma electrónica o física.
Para que Kushki realice el intercambio de llaves, los custodios de seguridad (SOs) deben:
Estar registrados en el portal del servicio de HSM de Kushki.
Cada uno de los SOs que participa en el intercambio debe tener una cuenta activa en el portal del servicio de HSM de Kushki.
Deben estar ubicados en los grupos de SO correctos (1, 2 o 3).
Deben mantener actualizada la dirección de envío de los componentes físicos.
Al momento de registrar al SO en el portal, recibirá información sobre su cuenta en el portal del proveedor de HSM de Kushki, que será útil más adelante.
Kushki puede enviar los componentes de la KEK por medios electrónicos seguros (correo, bóveda de seguridad, SFTP). Un ejemplo puede ser por correo cifrado. El comercio recibirá la información en una tabla como la siguiente:
Kushki enviará tres sobres de seguridad, cada uno con un componente de llave impreso en papel, a al menos dos custodios de seguridad que no reporten a la misma persona.
NOTA: El envío de los componentes suele tomar aproximadamente dos semanas, según la ubicación de los SOs.
El comercio recibe los componentes y los checksums de cada llave para poder cargarlos y validarlos en su HSM. Si la verificación fue exitosa, el comercio debe:
Informar a Kushki que la carga fue exitosa enviando un correo a la dirección seguridad@kushkipagos.com con “KEK component check successful - [MERCHANT_NAME]” en el asunto y “Check successful” en el mensaje.
Se pedirá a los SOs completar el checklist de confirmación de recepción a través del Portal del Proveedor del Servicio de HSM de Kushki que llegará por correo, siguiendo las instrucciones allí indicadas.
En caso de cualquier problema con la validación, debes informar a Kushki a la misma dirección de correo.
NOTA: Una vez que el componente ha sido activado en el portal del servicio de HSM de Kushki, es necesario que los SOs lo destruyan.
Generación y envío de la Base Derivation Key (BDK)#
Kushki registra al comercio en la Kushki Console, donde el comercio puede obtener su merchant_id, su llave privada de seguridad para transar (Private-Credential-Id), entre otra información relevante. Una vez registrado el comercio, Kushki generará dos base derivation keys (BDK), una para data y otra para pin (pin_block), que se intercambiarán de forma cifrada con la KEK en TR-31. El intercambio será por medios electrónicos seguros.Ejemplo de una BDK cifrada con una KEK en formato TR-31:RD0112B0TX00N00004FD842D565C0BDD9741A3EAB5106A78087A4D0729A56319F32AF9FBFC6FAE0A184DA40D08FA279FBB50E7598936AD18F
NOTA: Las BDK del entorno de producción se compartirán por medios electrónicos seguros (por ejemplo, 1password).
Una vez obtenidas las BDK, el comercio debe ejecutar sus procesos internos para la gestión de las terminales POS con el proceso DUKPT.
