Personalización de Google Pay
El TSH es totalmente capaz de personalizar una aplicación EMV para la solución Google Pay. Aquí está el conjunto de datos requeridos por el TSP en la operación 'submitTokenData'.
Nota1:
El nombre del elemento de datos no distingue mayúsculas de minúsculas. Por ejemplo, DEK_KCV y dek_kcv son equivalentes
Nota2:
Algunos elementos de datos pueden añadirse o eliminarse según la configuración del proyecto
Elementos de datos comunes de PURE y DISCOVER
etiqueta_kek
Cadena ASCII
máx 64
Etiqueta de la clave utilizada para el cifrado de las claves de pago. El valor se define durante la ceremonia de claves.
"G062C.TEST.SGKEK.TKSUK.01"
kek_kcv
Cadena hexadecimal
6
KCV de la clave utilizada para el cifrado de las claves de pago. El KCV de la clave KEK se calcula cifrando 8 bytes de 00h (para 3DES) usando el modo ECB o usando CMAC sobre 16 bytes de 00h (para AES).
"E95500"
etiqueta_dek
Cadena ASCII
máx 64
Etiqueta de la clave utilizada para el cifrado de los Datos de Track2 ("track2_data"). El valor se define durante la ceremonia de claves.
"G062C.TEST.SGDEK.MKDATA.01"
dek_kcv
Cadena hexadecimal
6
KCV de la clave utilizada para el cifrado de los datos de track2. El KCV se calcula cifrando 8 bytes de 00h (para 3DES) o 16 bytes de 01h (para AES) con la clave DEK usando el modo ECB.
"50FE57"
track2_data
Cadena hexadecimal
máx 64
Datos equivalentes de Pista 2 (la longitud máxima es 19 bytes) El formato en claro es:
PAN del token hasta 19 dígitos: 'ppppppppppppppppppp'
'D'
Fecha de caducidad: 'aamm'
Código de servicio: 'sss'
(opcional) Datos discrecionales (dependiendo de la longitud del PAN)
'F' (si es necesario para asegurar el byte completo) track2_data se rellena con 80h + 00h..00h para alcanzar el tamaño de bloque del algoritmo de cifrado (relleno ISO7816-4) track2_data se cifra bajo la clave DEK usando el modo CBC. El algoritmo de cifrado se define durante la configuración del proyecto.
"FAB7FF4EFE1989AC25EBBEC2ED72378BDA79D244B89F7F25"
payment_keys
Cadena
-
Ver formato más abajo.
-
psn
Cadena hexadecimal
2
Número de secuencia del PAN para personalizar en la aplicación.
"01"
par
Bytes ASCII
58
Referencia de la cuenta de pago.
"323352305041594D454E544143434F554E545245464552454E43455858" que representa "23R0PAYMENTACCOUNTREFERENCEXX"
app_preferred_name
Bytes ASCII
max 16
Nombre preferido de la aplicación
"4465626974" que representa "Debit"
Elementos de datos adicionales de PURE
cmk_ac_dki
Cadena hexadecimal
2
DKI de la clave de Criptograma de Aplicación.
"01"
cmk_rp_dki
Cadena hexadecimal
2
DKI de la clave de Pago Remoto.
"02"
Elementos de datos adicionales de DISCOVER
track1_data
Cadena hexadecimal
máx 64
Datos de Pista 1 Una vez descifrados, el formato son bytes ASCII. Una vez decodificado, el formato es:
'B'
PAN del token hasta 19 dígitos: 'ppppppppppppppppppp'
'^'
Nombre, de 2 a 26 caracteres (incluyendo separadores, cuando proceda, entre apellido, nombre, etc.)
'^'
Fecha de expiración: 'aamm' o '^'
Código de servicio: 'sss' o '^'
(opcional) Datos discrecionales (dependiendo de la longitud del PAN)
track1_data se rellena con 80h + 00h..00h para alcanzar el tamaño de bloque del algoritmo de cifrado (relleno ISO7816-4) track1_data se cifra con la clave DEK usando el modo CBC. El algoritmo de cifrado se define durante la configuración del proyecto.
"FAB7FF4EFE1989AC25EBBEC2ED72378BDA79D244B89F7F25"
cmk_emv_dki
Cadena hexadecimal
2
DKI de la clave EMV.
"01"
cmk_cavv_dki
Cadena hexadecimal
2
DKI de la clave CAVV.
"02"
formato de payment_keys
payment_keys es la representación en cadena de un arreglo JSON como se define a continuación:
Nota3: El número máximo de SUKs establecidos (es decir, referidos como objeto arriba) es 40.
Nota4: Para SUKs AES, el algoritmo de cifrado será AES-KW según RFC 3394 y el algoritmo KCV será CMAC sobre 16 bytes de 00h según RFC4493. Para SUKs 3DES, el algoritmo de cifrado será 3DES-ECB y el algoritmo KCV se calculará según EMV-CPS, es decir, cifrando 8 bytes de 00h con la clave relacionada en modo ECB. En ambos casos, los 3 bytes de orden superior se usarán como KCV.
formato payment_keys de PURE
Cada objeto del arreglo definido arriba es un objeto JSON como se define a continuación:
acKey
M
SUK de criptograma de aplicación encriptado con la clave KEK
acKeyKcv
M
KCV del SUK de criptograma de aplicación
rpKey
O
SUK de pago remoto encriptado con la clave KEK
rpKeyKcv
C
KCV del SUK de pago remoto Deberá proporcionarse si rpKey está presente
lcKey
M
SUK de generación de sello CDCVM local encriptado con la clave KEK
lcKeyKcv
M
KCV del SUK de generación de sello CDCVM local
atc
M
Contador de transacciones de la aplicación
Ejemplo:
formato payment_keys de DISCOVER
Cada objeto del arreglo definido arriba es un objeto JSON como se define a continuación:
emvKey
M
SUK de criptograma de aplicación EMV encriptado con la clave KEK
emvKeyKcv
M
KCV del SUK de criptograma de aplicación EMV
cavvKey
O
SUK del Valor de Verificación de Autenticación del Cliente (CAVV) encriptado con la clave KEK
cavvKeyKcv
C
KCV del SUK CAVV Deberá proporcionarse si cavvKey está presente
msKey
O
SUK de banda magnética encriptado con la clave KEK
msKeyKcv
C
KCV del SUK de banda magnética Deberá proporcionarse si msKey está presente
atc
M
Contador de transacciones de la aplicación
Ejemplo:
Elementos de datos CPACE Girocard
type
Cadena
máx 64
Tipo de personalización CPACE. El valor deberá ser "Girocard".
"Girocard"
profile
Cadena Base64
-
Perfil de token según la especificación Perso FF
"ANcB1wLXAA8AhAEBAHFl+OnQaqq2...Fwkf6n"
diversifier
Cadena hexadecimal
32
Valor diversificador de 16 bytes usado como datos de derivación para la generación de claves de sesión
"F5CFEA0C7C17EE5275566A33DAA1DFA9"
Última actualización
¿Te fue útil?