SDA, DDA, CDA: Como um Terminal Confia num Cartão Offline

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

Autenticação de dados offline em 90 segundos:

O terminal pode verificar que um cartão é genuíno sem ir online, usando uma cadeia de chaves públicas RSA que ele já carrega: chave da CA da bandeira → Chave Pública do Emissor → Chave Pública do ICC.

O SDA (Estático) verifica uma assinatura sobre os dados estáticos do cartão. Prova que os dados são autênticos — mas os mesmos dados assinados podem ser copiados, então o SDA é clonável.

O DDA (Dinâmico) adiciona uma chave privada no cartão. O terminal emite um desafio; o cartão o assina. Um clone sem a chave privada não consegue responder, então o DDA derrota a cópia.

O CDA (Combinado) funde a assinatura dinâmica com o criptograma do GENERATE AC, de modo que a assinatura também cobre o criptograma desta transação — o método mais forte e hoje o padrão.

Tudo repousa na função de recuperação RSA do EMV: assinaturas que você decifra para revelar dados mais um hash, com um byte trailer BC.

Existe um momento em toda transação com chip, antes de o terminal decidir qualquer coisa, em que ele faz uma pergunta que a tarja magnética nunca pôde responder: este cartão é real? Não "esta conta é válida" — isso é trabalho do emissor, online — mas "o plástico no meu slot é um cartão genuíno e não uma cópia fabricada". O EMV responde a isso com a Autenticação de Dados Offline (ODA), um mecanismo de chave pública que permite a um terminal, portando nada além de um punhado de chaves raiz de bandeira, verificar a autenticidade de um cartão sem rede alguma. Há três métodos de força crescente — SDA, DDA e CDA — e entender por que cada um existe é entender como a clonagem de cartões foi derrotada. Isto segue o EMVCo Book 2; cito a estrutura, não o texto da especificação, e nenhum material de chave privada aparece aqui.

A cadeia de certificados que o terminal carrega

A ODA é uma cadeia de confiança de chave pública, e o terminal é o verificador. Ela funciona porque o terminal vem pré-carregado com um pequeno conjunto de chaves públicas de Autoridade Certificadora (CA) — as raízes das bandeiras, um conjunto por rede de pagamento, identificadas por um Registered Application Provider Identifier (RID) e um CA Public Key Index. Quando um cartão é lido, a tag 8F diz ao terminal qual índice de chave de CA usar, e o terminal busca a raiz correspondente que já detém.

Dessa raiz, a cadeia desce:

O terminal usa a chave da CA para verificar o Issuer Public Key Certificate (tag 90), recuperando a chave pública do emissor. Dependendo do método, ele então verifica o Signed Static Application Data do cartão (SDA) com essa chave do emissor, ou desce um nível a mais para recuperar e usar a chave pública do ICC (DDA/CDA). A confiança flui de cima, de uma raiz em que o terminal já confia — exatamente como a PKI da web, mas com as raízes embutidas no terminal e a folha sendo um cartão de pagamento.

A função de recuperação RSA

Os três métodos repousam sobre uma primitiva que o EMV usa em todo lugar: a função de recuperação RSA. Assinaturas EMV não são MACs desacoplados; são operações RSA que você decifra para revelar um bloco estruturado contendo os dados assinados (ou seu hash) mais bytes de cabeçalho e trailer. Quando o terminal "verifica" um certificado ou assinatura, ele aplica a chave pública da CA/emissor/ICC para recuperar um bloco, então checa se o bloco tem o formato certo — um byte de cabeçalho, os dados ou sua representação, um hash SHA-1 sobre os campos relevantes, e um byte trailer BC. Se o bloco recuperado é bem formado, o hash casa com o hash recalculado e o trailer é BC, a assinatura é válida.

É por isso que "o certificado falhou" no EMV normalmente significa uma de poucas coisas concretas: o trailer recuperado não era BC, o hash recuperado não casou, a data de validade do certificado passou, ou o índice de CA apontou para uma chave que o terminal não detém. Cada uma é uma condição específica e diagnosticável, não uma falha vaga.

SDA: autêntico, mas copiável

A Static Data Authentication é a original e a mais fraca. O emissor, no momento da personalização, assina um conjunto estático dos dados do cartão e armazena o resultado no cartão como Signed Static Application Data (tag 93). No momento da transação o terminal verifica essa assinatura pela cadeia: a chave da CA verifica o certificado do emissor, a chave do emissor verifica o SSAD. Sucesso prova que os dados estáticos foram genuinamente assinados pelo emissor e não foram alterados.

Mas note o que o SDA não prova: que o cartão no slot é o original. Como os dados assinados são estáticos — os mesmos bytes todas as vezes — um atacante que lê um cartão genuíno pode copiar o SSAD e todos os dados assinados para outro cartão, e essa cópia vai passar na verificação SDA, porque a assinatura é sobre dados, não sobre nada único deste cartão ou deste momento. O SDA autentica os dados; não consegue autenticar o cartão. Essa lacuna é por que o SDA está depreciado para qualquer coisa que importe, e por que cartões que suportam SDA ainda podem ser clonados. Ele estabeleceu a necessidade de algo dinâmico.

DDA: prove que você detém a chave privada

A Dynamic Data Authentication fecha a lacuna de clonagem dando ao cartão seu próprio par de chaves RSA. A chave pública é entregue no ICC Public Key Certificate (tag 9F46), que o terminal verifica usando a chave do emissor recuperada — mais um elo na cadeia. A chave privada nunca deixa o cartão.

Agora o terminal faz algo que o SDA não pode: emite um desafio. Pelo comando INTERNAL AUTHENTICATE ele envia dados dinâmicos (incluindo um unpredictable number e dados do terminal especificados pelo DDOL), e o cartão os assina com sua chave privada, devolvendo o Signed Dynamic Application Data (tag 9F4B). O terminal verifica essa assinatura com a chave pública do ICC recuperada. Como a assinatura é sobre dados frescos, fornecidos pelo terminal e exige a chave privada do cartão, um clone que copiou apenas os dados públicos não consegue produzi-la — ele não detém a chave privada. O DDA prova que o cartão é o artigo genuíno, não uma cópia. Este é o mecanismo que tornou cartões com chip significativamente não clonáveis de um jeito que a tarja nunca foi.

CDA: vincular a autenticação à transação

O DDA prova que o cartão é real, mas há uma lacuna sutil entre "o cartão se autenticou" e "o cartão autenticou esta transação". Um ataque sofisticado poderia autenticar um cartão genuíno e então adulterar a troca do criptograma. O Combined DDA/Application Cryptogram (CDA) a fecha soldando a assinatura dinâmica à etapa do GENERATE AC: os dados dinâmicos assinados do cartão agora também cobrem o Application Cryptogram que ele acabou de gerar. Então uma única verificação prova tanto que o cartão é genuíno quanto que o criptograma desta transação específica está vinculado àquele cartão genuíno. Não há janela entre autenticar o cartão e confiar em seu criptograma, porque são a mesma assinatura.

O CDA é o método de ODA mais forte e a expectativa padrão moderna; o fluxo da transação o solicita somando o bit de CDA ao comando GENERATE AC. Se você raciocina sobre uma implantação EMV atual, assuma CDA e trate cartões só-SDA como risco legado.

Cicatrizes de batalha

Um certificado que falha é uma falha específica. "A ODA falhou" não é um humor; é uma de: certificado expirado, índice de CA errado (o terminal não tem a chave), trailer ruim (BC ausente) ou hash incompatível. Liga o bit correspondente no TVR no byte 1, e ler qual bit te diz qual elo quebrou. Não trate a cadeia inteira como um booleano opaco.

Chaves de CA expiradas e índices ausentes são operacional, não criptográfico. Uma fatia grande das falhas reais de ODA é logística: um terminal que nunca recebeu uma nova chave de CA da bandeira, ou um cartão personalizado sob um índice de CA que a tabela de chaves do terminal não inclui. A criptografia está bem; o gerenciamento de chaves atrasou. Mantenha o conjunto de chaves de CA do terminal atual — é o trabalho da Tabela de Chaves Públicas que silenciosamente mantém a autenticação offline viva.

Só-SDA é um achado, não uma nota de rodapé. Se sua frota ainda aprova cartões só-SDA offline para valores relevantes, você está aprovando cartões que podem ser clonados. Isso pode ser um risco aceitável e limitado para tarifas minúsculas de transporte offline; não é aceitável para varejo geral. Conheça a distribuição de métodos de ODA da sua base.

Onde isto se encaixa

A ODA é a Fase 4 do fluxo da transação, e seu resultado alimenta o motor de decisão do TVR. Sua forma mais forte, o CDA, é inseparável do ARQC que ele assina. As chaves de CA e de emissor de que ela depende são exatamente o que a Tabela de Chaves Públicas do gsstk gerencia.