Verificar o criptograma de solicitação de autenticação (ARQC) - AWS Criptografia de pagamento

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Verificar o criptograma de solicitação de autenticação (ARQC)

A API do criptograma de solicitação de autenticação de verificação é usada para verificar o ARQC. A geração do ARQC está fora do escopo da criptografia de AWS pagamento e normalmente é realizada em um cartão com chip EMV (ou equivalente digital, como carteira móvel) durante o período de autorização da transação. Um ARQC é exclusivo para cada transação e tem como objetivo mostrar criptograficamente a validade do cartão e garantir que os dados da transação correspondam exatamente à transação atual (esperada).

AWS A criptografia de pagamento fornece uma variedade de opções para validar o ARQC e gerar valores ARPC opcionais, incluindo aqueles definidos no EMV 4.4 Livro 2 e outros esquemas usados pela Visa e pela Mastercard. Para obter uma lista completa de todas as opções disponíveis, consulte a VerifyCardValidationData seção no Guia da API.

Os criptogramas ARQC normalmente requerem as seguintes entradas (embora isso possa variar de acordo com a implementação):

  • PAN - Especificado no PrimaryAccountNumber campo

  • Número de sequência PAN (PSN) - especificado no campo PanSequenceNumber

  • Método de derivação de chave, como Chave de sessão comum (CSK) - especificado no SessionKeyDerivationAttributes

  • Modo de derivação de chave mestra (como EMV Opção A) - Especificado no MajorKeyDerivationMode

  • Dados da transação - uma sequência de vários dados de transação, terminal e cartão, como valor e data - especificados no TransactionData campo

  • Chave mestra do emissor - a chave mestra usada para derivar a chave de criptograma (AC) usada para proteger transações individuais e especificada no campo KeyIdentifier

Construir dados de transação

O conteúdo exato (e a ordem) do campo de dados da transação variam de acordo com a implementação e o esquema de rede, mas os campos mínimos recomendados (e a sequência de concatenação) são definidos no EMV 4.4 Livro 2, Seção 8.1.1 - Seleção de dados. Se os três primeiros campos forem valor (17,00), outro valor (0,00) e país de compra, isso resultaria nos dados da transação começando da seguinte forma:

  • 000000001700: quantidade: 12 posições decimais implícitas de dois dígitos

  • 000000000000: outro valor: 12 posições implícitas decimais de dois dígitos

  • 0124: código de país de quatro dígitos

  • Dados da transação de saída (parcial): 0000000017000000000000000124

Preenchimento de dados da transação

Os dados da transação devem ser preenchidos antes de serem enviados para o serviço. A maioria dos esquemas usa preenchimento ISO 9797 Método 2, em que uma string hexadecimal é anexada por hexadecimal 80 seguido por 00 até que o campo seja um múltiplo do tamanho do bloco de criptografia; 8 bytes ou 16 caracteres para TDES e 16 bytes ou 32 caracteres para AES. A alternativa (método 1) não é tão comum, mas usa somente 00 como caracteres de preenchimento.

Preenchimento ISO 9797 Método 1

Sem preenchimento: 00000000170000000000000008400080008000084016051700000000093800000B03011203 (74 caracteres ou 37 bytes)

Com preenchimento: 00000000170000000000000008400080008000084016051700000000093800000B03011203000000 (80 caracteres ou 40 bytes)

Preenchimento ISO 9797 Método 2

Sem preenchimento: 00000000170000000000000008400080008000084016051700000000093800000B1F220103000000 (80 caracteres ou 40 bytes)

Com preenchimento: 00000000170000000000000008400080008000084016051700000000093800000B1F2201030000008000000000000000 (88 caracteres ou 44 bytes)

Exemplos

Visa CVN10

Neste exemplo, validaremos um ARQC gerado usando Visa CVN10.

Se a criptografia AWS de pagamento for capaz de validar o ARQC, um http/200 será retornado. Se o ARQC não for validado, ele retornará uma resposta http/400.

$ aws payment-cryptography-data verify-auth-request-cryptogram --auth-request-cryptogram D791093C8A921769 \ --key-identifier arn:aws:payment-cryptography:us-east-2:111122223333:key/pw3s6nl62t5ushfk \ --major-key-derivation-mode EMV_OPTION_A \ --transaction-data 00000000170000000000000008400080008000084016051700000000093800000B03011203000000 \ --session-key-derivation-attributes='{"Visa":{"PanSequenceNumber":"01" \ ,"PrimaryAccountNumber":"9137631040001422"}}'
{ "KeyArn": "arn:aws:payment-cryptography:us-east-2:111122223333:key/pw3s6nl62t5ushfk", "KeyCheckValue": "08D7B4" }

Visa CVN18 e Visa CVN22

Neste exemplo, validaremos um ARQC gerado com o uso do Visa CVN18 ou CVN22. As operações criptográficas são as mesmas entre CVN18 e CVN22, mas os dados contidos nos dados da transação variam. Comparado ao CVN10, um criptograma completamente diferente é gerado mesmo com as mesmas entradas.

Se a criptografia AWS de pagamento for capaz de validar o ARQC, um http/200 será retornado. Se o ARQC não for validado, ela retornará um http/400.

$ aws payment-cryptography-data verify-auth-request-cryptogram \ --auth-request-cryptogram 61EDCC708B4C97B4 --key-identifier arn:aws:payment-cryptography:us-east-2:111122223333:key/pw3s6nl62t5ushfk \ --major-key-derivation-mode EMV_OPTION_A --transaction-data 00000000170000000000000008400080008000084016051700000000093800000B1F22010300000000000 \ 00000000000000000000000000000000000000000008000000000000000 --session-key-derivation-attributes='{"EmvCommon":{"ApplicationTransactionCounter":"000B", \ "PanSequenceNumber":"01","PrimaryAccountNumber":"9137631040001422"}}'
{ "KeyArn": "arn:aws:payment-cryptography:us-east-2:111122223333:key/pw3s6nl62t5ushfk", "KeyCheckValue": "08D7B4" }