ARQC a Partir do Zero: Criptogramas de Aplicação Sem Caixa-Preta

💡 TL;DR (Too Long; Didn't Read)

O criptograma em 90 segundos:

• O ARQC (Authorisation Request Cryptogram) é um MAC sobre a transação, gerado pelo cartão, que só o emissor pode verificar. É o que torna uma transação com chip infalsificável e não repetível.
• Construir um é uma cadeia: Chave Mestra do Emissor → Chave Mestra do ICC (diversificada por PAN + número de sequência) → Chave de Sessão (diversificada pelo ATC) → MAC sobre os dados da transação.
• O MAC é o ISO/IEC 9797-1 Algoritmo 3 (Retail MAC) para as versões de criptograma da era DES, ou AES-CMAC para as modernas. O CVN no Issuer Application Data diz qual.
• O emissor responde com um ARPC, um criptograma de resposta derivado do ARQC, para que o cartão também possa verificar o emissor.
• A regra que torna isto embarcável: criptografia com chave roda no cliente (WebCrypto/WASM) ou on-premise. Você nunca envia uma chave de produção ao servidor de outra pessoa — incluindo o nosso. A ferramenta determinística, checada contra vetores de teste publicados, é a fonte da verdade; a IA nunca é.

Cada parte desta série até aqui vinha construindo em direção a este objeto. Na Parte 1 o cartão encerrou a transação devolvendo um Application Cryptogram na tag 9F26. Na Parte 3 a lógica de decisão do terminal decidiu qual criptograma solicitar. Agora abrimos o criptograma em si. O ARQC — a variante de autorização online do Application Cryptogram — é o único mecanismo que faz o EMV valer o custo enorme de ser implantado: um valor que prova que esta transação específica foi autorizada por este cartão específico, que não pode ser repetido, e que só o emissor do cartão pode validar. Entenda como ele é construído e você entende por que o chip venceu a tarja magnética.

Vou construir um do zero, e vou fazê-lo honestamente, o que significa duas disciplinas às quais você deve me cobrar. Primeira, não vou imprimir um valor hexadecimal específico de 8 bytes dizendo "este é o ARQC correto", porque uma saída criptográfica fabricada é pior que inútil — é uma mina para quem a copiar. Os valores intermediários e finais reais vêm dos vetores de teste no EMVCo Book 2 e são reproduzidos por uma implementação determinística que você pode conferir. Vou mostrar o processo com entradas claramente rotuladas como ilustrativas e dizer exatamente onde vivem os vetores autoritativos. Segunda, todo passo aqui que toca uma chave é um passo que precisa rodar onde a chave já vive — o cartão do portador, o HSM do emissor, ou, para aprender, uma aba de navegador com chaves de teste que nunca a deixam. Isso não é uma nota de rodapé de compliance; é a arquitetura.

O problema que o ARQC resolve

Uma transação de tarja magnética envia dados estáticos: o PAN, a validade, o service code, tudo copiado direto da trilha. Capture uma vez e você pode repetir para sempre. Essa é a economia inteira de fraude de tarja numa frase. A resposta do EMV é fazer cada transação carregar um valor dinâmico vinculado aos detalhes daquela transação e a um contador, calculado sob um segredo que o cartão detém e nunca revela.

Esse valor é um Message Authentication Code — um checksum com chave. O cartão calcula um MAC sobre os dados da transação usando uma chave derivada de um segredo que compartilha (indiretamente) com seu emissor. O emissor, detendo o segredo pai, pode re-derivar a mesma chave e recalcular o mesmo MAC para verificá-lo. Um atacante que captura o ARQC não aprende nada reutilizável: mude qualquer entrada — o valor, o contador — e o MAC muda completamente; e sem a chave ele não consegue forjar um MAC para uma transação que não aconteceu. O contador, o Application Transaction Counter (ATC), incrementa a cada transação, então até uma compra de aparência idêntica produz um criptograma diferente. Replay está morto.

A elegância está na hierarquia de chaves que permite a um segredo do emissor proteger bilhões de transações em milhões de cartões sem nunca colocar esse segredo num cartão.

Passo 1 — Da Chave Mestra do Emissor à Chave Mestra do ICC

No topo está a Issuer Master Key para Application Cryptograms (IMK-AC) — uma chave de comprimento duplo guardada no HSM do emissor e, por política, em nenhum outro lugar. Você não coloca a IMK num cartão; se colocasse, extrair um cartão comprometeria todos os cartões. Em vez disso, cada cartão recebe uma chave diversificada, única para ele, derivada da IMK usando dados que identificam o cartão.

A derivação (EMV Book 2, Anexo A1.4, "Opção A") diversifica pelo PAN e pelo PAN Sequence Number:

Entradas ilustrativas (NÃO é uma chave real — apenas a forma):
  IMK-AC (chave 3DES de comprimento duplo) : guardada no HSM
  PAN                                       : 4761 7300 0000 0119
  PAN Sequence Number (PSN)                 : 00

  X  = 16 dígitos mais à direita de (PAN || PSN), preenchidos com zeros à esquerda → 8 bytes
  ZL = 3DES_encrypt(IMK-AC, X)
  ZR = 3DES_encrypt(IMK-AC, X XOR 0xFFFFFFFFFFFFFFFF)
  MK-AC = ajustar_paridade( ZL || ZR )     // a chave mestra ICC única de 16 bytes do cartão

Dois detalhes importam e ambos são bugs comuns. A entrada X são os dezesseis dígitos mais à direita do PAN concatenado com o número de sequência — para um PAN de 16 dígitos com um PSN de um byte você descarta os dígitos mais à esquerda, e para PANs mais curtos preenche com zeros à esquerda. E a chave final recebe ajuste de paridade ímpar conforme a convenção DES; pule o ajuste de paridade e você vai derivar uma chave "quase certa", o que em criptografia significa inteiramente errada. O resultado, MK-AC, é a chave mestra deste cartão — ainda nunca usada diretamente numa transação.

Passo 2 — Da Chave Mestra do ICC à Chave de Sessão

Derivar uma chave por cartão não basta, porque uma chave por cartão reutilizada em todas as transações permitiria a um atacante coletar muitos MACs sob a mesma chave. Então o EMV diversifica de novo, por transação, usando o ATC. Esta é a derivação da Chave de Sessão, e o método comum (EMV Book 2, Anexo A1.3, "Common Session Key") se parece com isto:

Ilustrativo (apenas a forma):
  MK-AC : a chave mestra do cartão do Passo 1
  ATC   : 0x0005   (esta é a 5ª transação neste cartão)

  F_L = ATC || 0xF0 || 0x00 0x00 0x00 0x00 0x00      // bloco de 8 bytes
  F_R = ATC || 0x0F || 0x00 0x00 0x00 0x00 0x00      // bloco de 8 bytes
  SK_L = 3DES_encrypt(MK-AC, F_L)
  SK_R = 3DES_encrypt(MK-AC, F_R)
  SK-AC = ajustar_paridade( SK_L || SK_R )           // chave de sessão por transação

O ATC atravessa todo o desenho: torna a chave de sessão única por transação, aparece na entrada do MAC, e permite ao emissor detectar cartões clonados observando contadores que retrocedem ou se duplicam. Um contador de dois bytes, fazendo três trabalhos.

Agora — e é aqui que disciplina importa — a derivação exata depende do esquema e da versão do criptograma. O bloco acima é o método comum; os CVNs mais antigos da Visa usam um esquema diferente de chave de sessão (alguns efetivamente usam a chave mestra diretamente com o ATC dobrado nos dados do MAC). Qual se aplica não é algo que você adivinha.

Passo 3 — O Cryptogram Version Number decide tudo

O Issuer Application Data (tag 9F10) devolvido com o criptograma contém um Cryptogram Version Number (CVN). O CVN é o byte mais importante para quem tenta validar um ARQC, porque ele seleciona a receita inteira: qual derivação de chave de sessão roda, exatamente quais elementos de dados entram no MAC e em qual ordem, se há preenchimento, e qual algoritmo de MAC é usado. Um validador que assume um CVN e recebe outro vai calcular um criptograma perfeitamente formado e completamente errado.

É por isso que "implementar ARQC" não é um único algoritmo, mas uma família deles indexada por CVN, e por que o ônus da correção é real. Você não detecta um CVN incompatível no olho; você o pega rodando sua implementação contra os vetores de teste publicados para aquele CVN e confirmando casamento byte a byte.

Passo 4 — Calculando o MAC

Com a chave de sessão derivada e o CVN dizendo o que alimentar a ela, o ARQC é um MAC sobre os dados da transação. Para as versões de criptograma da família DES o algoritmo é o ISO/IEC 9797-1 MAC Algoritmo 3 — o "Retail MAC":

Dados = concatenação, na ordem do CDOL1, dos elementos exigidos, tipicamente:
  Amount Authorised, Amount Other, Terminal Country Code,
  Terminal Verification Results (o tag 95 da Parte 3!),
  Transaction Currency Code, Transaction Date, Transaction Type,
  Unpredictable Number, AIP, ATC, e extras específicos do CVN (ex.: IAD/CVR)

1. Preencha os Dados com 0x80 e então 0x00... até múltiplo de 8 bytes (ISO 9797-1 método 2)
2. CBC-MAC de todos os blocos com single-DES usando a metade ESQUERDA de SK-AC
3. No bloco final, aplique a transformação 3DES:
     decifre com a metade DIREITA, então cifre novamente com a ESQUERDA
4. ARQC = o bloco resultante de 8 bytes (8 bytes mais à esquerda)

Olhe o que entra nesse MAC: o valor, a moeda, o país, a data, o tipo, um Unpredictable Number aleatório, o AIP, o ATC — e o TVR da Parte 3. O criptograma vincula criptograficamente os próprios resultados de verificação do terminal à afirmação. Adultere o valor depois e o MAC quebra. Repita o criptograma de ontem e o ATC e o Unpredictable Number não casam mais. Essa é a propriedade antifraude, e não é nada mais exótico que um MAC sobre as entradas certas.

As versões modernas de criptograma substituem o Retail MAC DES por AES-CMAC sobre dados análogos, seguindo o mesmo princípio com uma primitiva mais forte. A migração de 3DES para criptogramas AES é uma dessas re-plataformizações silenciosas de vários anos acontecendo pelo mundo emissor agora; se você está construindo novo, constrói para CVNs AES.

Passo 5 — O ARPC: o emissor responde

Autenticação no EMV é mútua. Depois que o emissor valida o ARQC, ele calcula um ARPC (Authorisation Response Cryptogram) para que o cartão possa verificar o emissor — é assim que o cartão sabe que o "aprovado" que ouve realmente veio de seu emissor e não de um intermediário. A derivação clássica (Método 1) é compacta:

Ilustrativo (apenas a forma):
  ARC = Authorisation Response Code (2 bytes, ex.: "00" = aprovado)
  ARPC = 3DES_encrypt( SK-AC,  ARQC XOR (ARC || 0x00 0x00 0x00 0x00 0x00 0x00) )

O emissor envia o ARPC e o ARC de volta; o terminal os passa ao cartão no segundo GENERATE AC; o cartão recalcula e compara. Se casar, a autenticação do emissor teve sucesso — e se não casar, o cartão liga o bit de autenticação-do-emissor-falhou no byte 5 do TVR, exatamente o bit que conhecemos na Parte 3. As versões mais novas de criptograma usam um ARPC baseado em CMAC (Método 2) sobre o ARQC mais um Card Status Update, mas a intenção é a mesma: provar que a resposta é genuína.

A regra que torna isto seguro de embarcar

Agora a arquitetura, porque tudo acima só é responsável se rodar no lugar certo.

Criptografia com chave roda onde a chave já está. Um ARQC real é calculado no cartão, sob uma chave que nunca o deixa. Uma validação real roda no HSM do emissor, sob a IMK que nunca o deixa. Quando o gsstk construir uma Calculadora de ARQC como ferramenta, ela vai rodar no cliente — no seu navegador via WebCrypto/WASM — com chaves de teste que você fornece e que nunca atravessam a rede. Nós não temos um endpoint "nos envie sua IMK". Nunca teremos. Num domínio em que confiança é o produto inteiro, uma ferramenta de pagamentos que pede uma chave de produção num servidor remoto não é uma ferramenta, é um incidente esperando por uma intimação. Isso está escrito em nossas regras de EMV como política, não preferência.

E a camada de IA fica em cima do cálculo determinístico, nunca por baixo. Um modelo de linguagem pode explicar um CVN, narrar um fluxo ou notar que seu ATC parece obsoleto — mas nunca é a coisa que calcula um criptograma, porque um MAC errado de aparência plausível é a saída mais perigosa deste campo. A implementação determinística, validada byte a byte contra os vetores de teste do Book 2, é a fonte da verdade. É o mesmo princípio que encerrou a Parte 2 (o decodificador testado acima do laço esperto) e é a espinha do produto inteiro: correção que você pode reproduzir, não correção que você espera.

Onde isto te deixa

Você agora consegue traçar um criptograma de um segredo do emissor até uma afirmação verificável e de volta à autenticação mútua, sem que nenhuma parte seja mágica. Esse é o conceito mais difícil em pagamentos com cartão presente, e tudo que as bandeiras estão construindo para a era agêntica — os mandatos e tokens escopados do texto-ponte desta série — é uma variação exatamente deste padrão: uma afirmação assinada, protegida por contador, derivada de chave, de que uma ação específica foi autorizada.

O final regional leva todo esse rigor a um lugar inesperado: o QR code que o Brasil inteiro usa. PIX e o EMVCo Merchant-Presented Mode são a mesma disciplina — dados de pagamento estruturados, com checksum, definidos por especificação — numa forma que você imprime num guardanapo. Quando o gsstk lançar a Calculadora de ARQC, ela fará o cálculo acima no seu navegador, com seus vetores de teste, para você ver cada valor intermediário se resolver e conferi-lo contra o Book 2 você mesmo.

Leitura Relacionada no gsstk

• O TVR, o TSI e Como um Terminal Decide te Recusar — Parte 3: o TVR que é vinculado a este MAC.
• O Que Realmente Acontece Quando Você Insere um Chip — Parte 1: onde a 9F26 e o GENERATE AC vivem.
• Comércio Agêntico e o Retorno do HTTP 402 — a analogia mandato/token = "um criptograma para delegação".
• PIX, BR Code e o EMVCo MPM — Parte 5: a mesma disciplina em forma de QR code.

Ferramentas: inspecione as tags do criptograma no Dicionário de Tags EMV — 9F26 (AC), 9F10 (IAD), 9F36 (ATC) — e a Tabela de Chaves Públicas para as chaves de CA por trás da autenticação de dados offline. (Uma Calculadora de ARQC/ARPC no cliente está no roadmap.)

Arquivado em: EMV · Payment Crypto · Payments · Acquiring · Card Issuing

Este artigo foi arquitetado por humanos e sintetizado com assistência de IA sob a persona Daedalus (AI).