A CVM List (8E): Como um Cartão Escolhe PIN vs Assinatura vs Nada

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

A CVM List em 90 segundos:

A tag 8E é a lista ordenada do cartão sobre como ele vai verificar o portador: dois limiares de valor (X e Y) de 4 bytes seguidos por uma sequência de Regras de CVM de 2 bytes.

Cada regra é um código de CVM (PIN offline, PIN online, assinatura, nenhum CVM…) mais um código de condição (sempre, se acima de X, se saque não assistido, se o terminal suportar…).

O terminal percorre as regras em ordem; a primeira regra cuja condição é satisfeita e cujo método o terminal suporta vence.

O bit 0x40 no código de CVM significa "se este método falhar, tente a próxima regra" — o fallback que produz "pediu PIN e depois aceitou assinatura".

O desfecho é registrado no CVM Results (9F34): qual método, sua condição e sucesso/falha.

Todo debate sobre "chip e PIN versus chip e assinatura" é, no fundo, um debate sobre o conteúdo de um objeto de dados: a Cardholder Verification Method List, tag 8E. É a cédula ordenada do cartão — um conjunto ordenado de formas pelas quais ele aceita que o terminal confirme a pessoa que o segura, cada uma condicionada. O terminal a lê, percorre de cima para baixo e escolhe a primeira entrada que se aplica e é suportada. Aprenda a decodificar a 8E e toda a fase de verificação do portador — por que um cartão pede PIN e outro não, por que uma transação caiu para assinatura, por que uma aproximação não pediu nada — se torna legível em vez de misteriosa. Isto segue o EMVCo Book 3; cito a estrutura, não o texto da especificação.

A estrutura da tag 8E

A CVM List tem uma cabeça fixa e uma cauda variável:

text

[ Valor X (4 bytes) ][ Valor Y (4 bytes) ][ Regra de CVM 1 (2 bytes) ][ Regra de CVM 2 ] ...

Os dois valores de 4 bytes, X e Y, são limiares aos quais os códigos de condição se referem (ambos expressos nas unidades menores da moeda da aplicação). Depois deles vem uma sequência de Regras de CVM, cada uma com dois bytes: o primeiro byte é o Código de CVM (o método), o segundo é o Código de Condição (quando esta regra se aplica). A lista é percorrida em ordem, e a ordem é tudo — o cartão classifica suas preferências colocando-as primeiro.

O Código de CVM: qual método

O primeiro byte de cada regra é o método, e seus seis bits inferiores o nomeiam (EMVCo Book 3):

0x00 — falhar o processamento de CVM (um "nenhum método funciona, pare" deliberado).
0x01 — PIN offline em texto claro.
0x02 — PIN online (cifrado, enviado ao emissor).
0x03 — PIN offline em texto claro e assinatura.
0x04 — PIN offline cifrado.
0x05 — PIN offline cifrado e assinatura.
0x1E — assinatura.
0x1F — nenhum CVM exigido.

E o bit que pega todo mundo: o bit 7 (0x40) é o sinalizador "aplicar a regra seguinte se este CVM não tiver sucesso". Se estiver ligado e o método escolhido falhar, o terminal não recusa de imediato — ele passa para a próxima regra da lista. Se estiver desligado e o método falhar, o processamento de CVM falha. Esse único bit é por que você vê "o terminal pediu PIN, o teclado estava quebrado e ele aceitou uma assinatura em vez disso": a regra de PIN offline tinha 0x40 ligado, o método não pôde ser executado, e o terminal caiu para uma regra de assinatura abaixo dela.

O Código de Condição: quando a regra se aplica

O segundo byte diz em quais circunstâncias a regra é sequer elegível. Códigos de condição comuns (EMVCo Book 3):

0x00 — sempre.
0x01 — se saque não assistido.
0x02 — se não for saque não assistido, nem saque manual, nem compra com troco.
0x03 — se o terminal suportar o CVM.
0x06 — se a transação está na moeda da aplicação e acima de X.
0x07 — se está na moeda da aplicação e abaixo de X.
0x08 — se está na moeda da aplicação e acima de Y.
0x09 — se está na moeda da aplicação e abaixo de Y.

Então X e Y transformam a lista numa política em camadas. Um cartão típico pode dizer: se abaixo de X, nenhum CVM exigido (aproximação pequena, sem solicitação); se acima de X, PIN online; com fallback para assinatura se o teclado estiver ausente. Os dois limiares permitem a um cartão expressar "sem atrito abaixo disto, PIN acima, e um teto alto onde algo mais forte entra".

Percorrendo a lista: um exemplo resolvido

Suponha que a tag 8E decodifique com X = 25,00, Y = 500,00 e as regras:

1F 07 — nenhum CVM exigido, se abaixo de X (25,00).
42 06 — PIN online com fallback (0x02 + 0x40), se acima de X.
1E 03 — assinatura, se o terminal suportar.

Agora rode três transações. Uma compra de 20,00: a condição da regra 1 (abaixo de 25,00) é satisfeita, o método é "nenhum CVM", o terminal suporta — pronto, sem solicitação. Uma compra de 80,00 num terminal com teclado de PIN funcionando: a regra 1 falha (não está abaixo de X), a condição da regra 2 (acima de X) é satisfeita, o método PIN online é suportado — solicita PIN. A mesma compra de 80,00 num terminal cujo teclado está quebrado: a regra 2 é selecionada, o PIN online não pode ser executado, mas seu bit 0x40 está ligado, então o terminal cai para a regra 3 e aceita uma assinatura. Mesmo cartão, mesmo valor, capacidade de terminal diferente, desfecho diferente — tudo determinado por três regras de dois bytes e um bit de fallback.

O recibo: CVM Results (9F34)

Quando o processamento termina, o terminal registra o que aconteceu no CVM Results, tag 9F34, três bytes: o CVM executado (byte 1, o código que efetivamente rodou), a condição sob a qual rodou (byte 2) e o resultado (byte 3: desconhecido, falhou ou bem-sucedido). Este é o registro forense. Quando uma disputa ou uma recusa precisa de explicação, a 9F34 diz qual método cartão e terminal acordaram e se ele teve sucesso — e é uma das tags carregadas no DE 55 para que o emissor também a veja.

Cicatrizes de batalha

O bit de fallback 0x40 é a origem do "aceitou uma assinatura". Quando uma transação verifica com um método mais fraco do que você esperava, cheque se a regra preferida tinha o bit 7 ligado e se seu método não era suportado ou falhou. A lista fez exatamente o que foi instruída; a surpresa está no bit.

Um cartão pode listar um método que o terminal precisa recusar. Se a condição de nenhuma regra é satisfeita por um método que o terminal suporta — por exemplo um cartão só-PIN num terminal só-assinatura — o processamento de CVM pode terminar em falha, o que liga um bit no TVR e pode empurrar a transação para online ou para recusa. "CVM falhou" muitas vezes é incompatibilidade de capacidade, não PIN errado.

Contactless usa sua própria lógica de CVM. A 8E clássica governa contato e alguns fluxos contactless, mas kernels contactless modernos sobrepõem sua própria decisão de CVM — sem CVM abaixo do limite, CDCVM no dispositivo, PIN online acima do limite — como coberto no artigo de contactless. Não assuma que a caminhada da 8E de contato explica uma aproximação; cheque as regras do kernel.

Onde isto se encaixa

A CVM List é a Fase 6 do fluxo da transação. Quando ela seleciona PIN offline, a maquinaria do PIN block assume; quando seleciona PIN online, esse bloco viaja na mensagem ISO 8583 e seu resultado no DE 55. Resolva 8E (CVM List) e 9F34 (CVM Results) no dicionário de tags enquanto decodifica.