Programa de autenticação de chip - Chip Authentication Program

Um dispositivo Gemalto EZIO CAP com estilo Barclays PINsentry

O Chip Authentication Program (CAP) é uma iniciativa e especificação técnica da MasterCard para usar cartões inteligentes bancários EMV para autenticar usuários e transações em serviços bancários on-line e por telefone. Também foi adotado pela Visa como Dynamic Passcode Authentication (DPA). A especificação CAP define um dispositivo portátil ( leitor CAP ) com um slot de smartcard, um teclado numérico e um display capaz de exibir pelo menos 12 caracteres (por exemplo, um display starburst ). Os clientes bancários aos quais foi emitido um leitor CAP por seu banco podem inserir seu cartão Chip e PIN ( EMV ) no leitor CAP para participar de um dos vários protocolos de autenticação suportados . CAP é uma forma de autenticação de dois fatores, pois um cartão inteligente e um PIN válido devem estar presentes para que uma transação seja bem-sucedida. Os bancos esperam que o sistema reduza o risco de clientes desavisados ​​inserirem seus dados em sites fraudulentos depois de ler os chamados e - mails de phishing .

Princípio de operação

A especificação CAP oferece suporte a vários métodos de autenticação. O usuário primeiro insere seu smartcard no leitor CAP e o habilita inserindo o PIN. Um botão é então pressionado para selecionar o tipo de transação. A maioria dos leitores tem dois ou três tipos de transação disponíveis para o usuário sob uma variedade de nomes. Algumas implementações conhecidas são:

Codificar / identificar

Sem a necessidade de qualquer entrada adicional, o leitor CAP interage com o smartcard para produzir uma senha decimal de uso único , que pode ser usada, por exemplo, para fazer login em um site de banco.

Resposta

Esse modo implementa autenticação de desafio-resposta , em que o site do banco pede ao cliente para inserir um número de "desafio" no leitor CAP e, em seguida, copie o número de "resposta" exibido pelo leitor CAP para o site.

Assinar

Este modo é uma extensão do anterior, em que não apenas um valor de "desafio" aleatório, mas também detalhes cruciais da transação, como o valor transferido, a moeda e o número da conta do destinatário, devem ser digitados no leitor CAP.

Os tipos de transação mencionados acima são implementados usando um dos dois modos. Um desses modos tem duas formas de operar, criando três modos distintos, embora não sejam nomeados dessa forma na especificação.

Mode1

Este é o modo para transações monetárias normais, como uma compra online através de um comerciante. Um valor de transação e moeda são incluídos no cálculo do criptograma. Se o cartão não exigir ou o terminal não aceitar, o valor e a moeda serão zerados.

Modo 2

Este modo pode ser útil para autenticar um usuário no qual nenhuma transação está ocorrendo, como fazer login em um sistema bancário da Internet. Nenhum valor de transação, moeda ou outros dados são incluídos, tornando essas respostas muito fáceis de pré-calcular ou reutilizar.

Com assinatura de dados de transação (TDS)

Este modo pode ser usado para transações mais complicadas, como uma transferência de fundos entre contas. Vários campos de dados pertencentes à transação são concatenados e, em seguida, hash com um criptograma Mode2 como a chave para o algoritmo de hash. O hash resultante é usado no lugar do criptograma calculado em uma operação não-TDS Mode2.

O Modo 1 se parece muito com um uso específico do Modo 2 com TDS, mas há uma diferença crítica. Na operação Modo1, os dados de transação (valor e tipo de moeda) são usados ​​no cálculo do criptograma, além de todos os valores usados ​​no Modo2 sem TDS, enquanto o Modo2 inclui seus dados de transação em uma etapa sucessiva em vez de incluí-los na etapa de cálculo do criptograma . Se não fosse por essa diferença, todas as operações poderiam ser generalizadas como uma única operação com dados de transação opcionais variados.

Detalhes do protocolo

Um leitor de código eletrônico Nordea

Em todos os três modos, o leitor CAP pede ao cartão EMV para emitir um pacote de dados que confirma o cancelamento de uma transação de pagamento EMV fictícia, que envolve os detalhes inseridos pelo usuário. Esta mensagem de confirmação contém um código de autenticação de mensagem (normalmente CBC-MAC / Triple DES ) que é gerado com a ajuda de uma chave secreta específica do cartão armazenada com segurança no smartcard. Essas mensagens de cancelamento não representam risco de segurança para o aplicativo de pagamento EMV regular, mas podem ser verificadas criptograficamente e são geradas por um cartão EMV somente após o PIN correto ter sido inserido. Ele forneceu aos projetistas do CAP uma maneira de criar fortes evidências criptográficas de que um cartão EMV ativado por PIN está presente e viu alguns dados de entrada fornecidos, sem a necessidade de adicionar novas funções de software aos cartões EMV já em uso.

Um smartcard EMV contém um contador de transações (normalmente de 16 bits) que é incrementado com cada pagamento ou transação CAP. A resposta exibida por um leitor CAP consiste essencialmente nas várias partes da resposta do cartão (Application Transaction Counter, MAC, etc.) que é então reduzida a bits específicos, conforme determinado pelo registro do Issuer Authentication Indicator (IAI) armazenado no cartão ( isso é definido por emissor, embora se um emissor desejar, pode ser definido aleatoriamente para cada cartão, fornecendo um banco de dados do IAI de cada cartão é mantido), finalmente, após os bits indesejados serem descartados (essencialmente, a posição absoluta dos bits é irrelevante, um bit no IAI que é 0 significa que o bit correspondente na resposta da placa será descartado em vez de simplesmente ser definido como 0). Finalmente, o valor é convertido de binário em um número decimal e exibido ao usuário. Um exemplo truncado é fornecido abaixo:

1. O dispositivo CAP seleciona o aplicativo EMV, lê as informações IAI do cartão e o usuário seleciona uma ação a ser executada (neste exemplo, IAI será 111011011000 ₂ ).
2. Após a entrada bem-sucedida do PIN, o dispositivo CAP envia o desafio de 011100111010 ₂ como uma transação do Criptograma de Solicitação de Autorização (ARQC).
3. O cartão inteligente dá uma resposta de 110101110110 ₂ e o dispositivo CAP cancela a transação falsa.
4. O dispositivo CAP usa a máscara IAI: 111011011000 ₂ para descartar bits; os bits que correspondem a 0 na máscara são eliminados.
5. Portanto, a resposta final é 1100110 ₂ ou 102 em decimal.

O processo do mundo real é, obviamente, um pouco mais complexo, pois o cartão pode retornar o ARQC em um de dois formatos (o formato de modelo de mensagem de resposta simples tipo 1 (id. 80 ₁₆ ) ou o mais complexo Formato de modelo de mensagem de resposta 2 (id. 77 ₁₆ ) que divide os dados ARQC em valores TLV separados que precisam ser remontados sequencialmente para corresponder ao formato do tipo 1.

No modo de identificação, a resposta depende apenas dos bits necessários do IAI, pois a quantidade e o número de referência são definidos como zero; isso também significa que selecionar responder e inserir um número de 00000000 irá de fato gerar uma resposta de identificação válida. Mais preocupante, no entanto, se um pedido de resposta for emitido por um banco, usando o modo de sinal com o mesmo número e um valor de ¤0,00 irá gerar novamente um resultado válido que cria a possibilidade de um fraudador instruir um cliente a fazer um "teste "contestação de resposta por um valor de ¤0,00 que, na verdade, será usado pelo fraudador para verificar um comando de resposta para que ele se acrescente como beneficiário na conta da vítima; esses ataques eram possíveis de serem executados contra bancos que usavam dispositivos de autenticação forte que não cancelavam atividades até que um valor de pelo menos 0,01 fosse inserido. A probabilidade desse tipo de ataque foi abordada em 2009, quando novas gerações de dispositivos foram lançadas, implementando a funcionalidade de separação de domínio segura que é compatível com a nota do aplicativo MasterCard datada de outubro de 2010. Da mesma forma, é claro; um banco que implementa o comando de identificação possibilita que um fraudador solicite que uma vítima faça um "teste" de transação de resposta usando 00000000 como referência e, então, será capaz de fazer o login com sucesso na conta da vítima.

O mesmo contador de repetição de PIN no cartão é usado como em outras transações EMV. Assim, como em um terminal ATM ou POS, inserir um PIN incorreto três vezes consecutivas em um leitor CAP irá bloquear o cartão.

Incompatibilidade

A especificação CAP original foi projetada para usar transações EMV normais, de modo que o aplicativo CAP pudesse ser implantado sem atualizar o firmware dos cartões EMV existentes, se necessário. A implementação preferencial usa um aplicativo separado para transações CAP. Os dois aplicativos podem compartilhar certos dados, como PIN, enquanto outros dados não são compartilhados em casos onde são aplicáveis ​​apenas a um aplicativo (ou seja, dados de gerenciamento de risco de terminal para EMV) ou vantagens de ter separado (ou seja, contador de transações, então que as transações EMV e CAP incrementam contadores separados que podem ser verificados com mais precisão). O leitor também carrega dados específicos de implementação, alguns dos quais podem ser substituídos por valores no cartão. Portanto, os leitores CAP geralmente não são compatíveis com cartões de bancos emissores diferentes.

No entanto, os leitores de cartão emitidos pela maioria, possivelmente todos os bancos do Reino Unido estão em conformidade com um subconjunto CAP definido pela APACS , o que significa que, na maioria dos casos, os cartões emitidos por um banco do Reino Unido podem ser usados ​​em um leitor de cartão emitido por um banco diferente.

Vulnerabilidades

Os pesquisadores da Universidade de Cambridge Saar Drimer, Steven Murdoch e Ross Anderson conduziram pesquisas sobre a implementação do CAP, destacando uma série de vulnerabilidades no protocolo e na variante do Reino Unido de leitores e cartões. Inúmeros pontos fracos foram encontrados. Pesquisadores da Radboud University encontraram uma vulnerabilidade no holandês ABN AMRO e.dentifier2, permitindo que um invasor comande um leitor conectado por USB para assinar transações maliciosas sem a aprovação do usuário.

Comercial

Suécia

• Nordea usando CAP em novembro de 2007. A solução Nordea eCode é usada pela Nordea tanto para eBanking, eCommerce (3DS) e também com eID. O leitor, que possui algumas funcionalidades mais avançadas que estendem o CAP, torna as implementações do CAP do Nordea mais seguras contra cavalos de Troia e ataques man-in-the-middle . Quando usado para identidade eletrônica, o usuário pode fazer sua "declaração fiscal" online ou quaisquer funções de governo eletrônico implementadas. O dispositivo também está equipado com uma porta USB, que permite ao banco realizar Assinar o que você vê para aprovação de transações confidenciais.

Reino Unido

Um dispositivo CAP em todo o país com uma moeda de 20p à escala

Um dispositivo Natwest CAP com uma moeda de 10p à escala

• A Administração de Pagamentos do Reino Unido definiu um subconjunto CAP para uso pelos bancos do Reino Unido. Atualmente é usado por:
  • banco Barclays
  • Ulster Bank
  • NatWest
  • Banco Cooperativo e Sorriso
  • Royal Bank of Scotland
  • Lloyds Bank
  • Em todo o país
• Os leitores CAP do Barclays, Lloyds Bank, Nationwide, NatWest, Co-operative Bank / Smile e RBS são todos compatíveis.
• O Barclays começou a emitir leitores CAP (chamados PINsentry ) em 2007. Seu site de banco online usa o modo de identificação para verificação de login e o modo de assinatura para verificação de transação. O modo de resposta é usado como parte do novo aplicativo PingIt Mobile Payment para autenticar os detalhes da conta. O dispositivo agora também é usado em agências, substituindo os tradicionais dispositivos de chip e pin para evitar ainda mais as tentativas de fraude.
• Os cartões bancários emitidos pelo HBOS são tecnicamente compatíveis com o sistema, embora o HBOS (ainda) não tenha introduzido leitores CAP para uso com seus serviços bancários online.

Implementações de software

Existe uma implementação de software escrita em Python com suporte para Modo 1, Modo 2 e Modo 2 com TDS para ser usado apenas para fins educacionais. A função de identificação (sem desafio) corresponde à função m1 com o desafio "00000000".

Observe que o uso deste software para operações financeiras reais pode levar a alguns riscos. Na verdade, a vantagem de usar um leitor autônomo é isolar o cartão bancário do malware potencialmente localizado no PC. Usá-lo em um leitor não seguro é correr o risco de que um keylogger intercepte o PIN e o malware de ponto de venda ganhe acesso aos detalhes do cartão, ou mesmo intercepte uma transação para modificá-lo ou operar sua própria transação.

Veja também

• 3-D Secure

Referências