O artigo examina os mitos e cenários populares de fraude de pagamento sem contato usando o exemplo de um terminal POS real, cartões PayPass / payWave e telefones com a função Google Pay / Apple Pay.

Tópicos abordados:

• É realmente possível roubar dinheiro apoiando meu terminal de POS no bolso? - Vamos tentar reproduzir totalmente esse cenário de fraude do começo ao fim, usando um terminal POS real e cartões de pagamento em condições reais.
• Qual é a diferença entre os cartões Apple Pay físicos e virtuais? - como o cartão físico e o token Apple Pay estão vinculados e por que o Apple Pay é muito mais seguro que um cartão comum.
• Usamos um sniffer NFC de hardware (ISO 14443A) - usaremos um dispositivo HydraNFC para interceptar dados entre o terminal POS e o cartão. Considere quais dados confidenciais podem ser extraídos do tráfego interceptado.
• Analisamos o protocolo EMV - quais dados o cartão troca com o terminal POS, o formato de solicitação usado, os mecanismos de proteção contra ataques de fraude e repetição.
• Estudamos operações sem cartão (CNP, MO / TO) - em que casos de fato (!) Você pode roubar dinheiro do cartão, tendo apenas os detalhes lidos sem contato e nos quais é impossível.

Atenção!

O artigo descreve em detalhes o esquema hipotético de fraude, do começo ao fim, através dos olhos de um fraudador, a fim de cobrir todos os aspectos nos quais os mitos e erros são cultivados. Apesar do título provocador, a principal conclusão do artigo é que os pagamentos sem contato são bastante seguros e os ataques a eles são demorados e não rentáveis .

Os materiais no artigo são apresentados apenas para fins informativos. Todas as cenas de fraude são encenadas e executadas com o consentimento das partes envolvidas. Todo o dinheiro deduzido dos cartões foi devolvido aos seus proprietários. O roubo do dinheiro do cartão é uma ofensa criminal e é punível por lei.

Como isso funciona?

Para começar, considere os conceitos básicos: qualquer movimentação de dinheiro usando cartões de pagamento é possível apenas através de intermediários conectados ao sistema de pagamento, como VISA ou MasterCard. Diferentemente das transferências entre indivíduos, o débito em dinheiro do cartão está disponível apenas para uma entidade legal (comerciante) com um contrato de aquisição com um banco.


Etapas da transação ao pagar através de um terminal POS

A ilustração acima mostra o esquema de pagamento clássico através de um terminal POS. É essa sequência de ações que ocorre quando, após o pagamento no caixa, você está aguardando confirmação no terminal.

1. O comprador aplica / retém / insere o cartão no terminal POS;
2. Um terminal POS transmite dados para um banco adquirente pela Internet;
3. O banco adquirente através do sistema de pagamento internacional (MPS) entra em contato com o banco emissor e pergunta se um titular de cartão específico pode pagar pela compra;
4. O banco emissor confirma ou rejeita a compra, após a qual um boleto é impresso (segundo cheque).

Há exceções neste esquema, por exemplo, transações offline, as consideraremos ainda mais. Além disso, se o banco adquirente e o banco emissor forem o mesmo banco, as etapas 2 e 4 serão executadas no mesmo banco.

Vendedor (comerciante) - uma pessoa ou organização que fornece bens ou serviços

Banco adquirente é um banco que fornece ao vendedor serviços de aceitação de pagamento por meio de cartões bancários. Nesse banco, geralmente, existe uma conta bancária do vendedor em que o dinheiro debitado no cartão é creditado.

Banco emissor - o banco que emitiu o cartão. Ele contém a conta do titular do cartão, da qual o dinheiro é debitado.

O Sistema Internacional de Pagamentos (MPS) é um sistema intermediário internacional entre bancos de todo o mundo que permite que os bancos façam acordos entre si sem concluir um contrato com cada banco separadamente. Todos os bancos conectados ao Ministério das Ferrovias concordam em trabalhar de acordo com as mesmas regras, o que simplifica bastante a interação. Por exemplo, Visa, MasterCard, UnionPay, American Express, MIR (não, o MIR não funciona no exterior).

Titular do cartão - uma pessoa que assinou um contrato de serviço de cartão com o banco emissor.

Qual é a diferença entre um cartão comum da Apple Pay ou Google Pay?

O procedimento para vincular um cartão bancário ao sistema Apple Pay ou Google Pay devido à incompreensibilidade do processo geralmente gera equívocos, mesmo entre os profissionais de TI. Eu ouvi muitos mitos diferentes sobre essa tecnologia.

Mitos populares da Apple Pay

• O cartão é copiado para o telefone
  Não é assim, o cartão do microprocessador contém uma área de memória protegida com informações criptográficas que não podem ser extraídas após a emissão do cartão. Por esse motivo, um cartão com chip não pode ser copiado, de forma alguma. Para ser justo, é preciso dizer que esses ataques são possíveis, mas seu custo excede a quantidade total de dinheiro que a maioria dos leitores deste artigo gastará em toda a sua vida.
• Cada vez que o telefone se conecta à Internet durante o pagamento
  O Google Pay / Apple Pay não se conecta à Internet durante o pagamento através de um terminal POS. Todas as informações necessárias são armazenadas localmente no telefone.
• Um novo número de cartão (PAN) é gerado para cada pagamento
  Pode parecer que você leia os comunicados de imprensa da Apple sobre a tecnologia Apple Pay. Mas essa é uma interpretação incorreta do conceito de token. De fato, os detalhes do cartão virtual permanecem inalterados por um longo tempo. Você pode verificar isso pelos últimos dígitos do número do cartão no boleto (cheque bancário) ao pagar pelas compras.
• Ao pagar através do Apple Pay / Google Pay, é cobrada uma taxa adicional
  Não é assim, você pagará exatamente o valor indicado no preço e de acordo com os termos do seu contrato com o banco emissor cujo cartão você vinculou.
• O dinheiro pode ser debitado duas vezes
  Esse mito se aplica não apenas ao Google Pay / Apple Pay, mas também aos cartões bancários comuns. Acredito que ele apareceu por causa dos sistemas de pagamento de transporte público, nos quais o terminal deduz dinheiro do ingresso toda vez que é apresentado, para que você possa debitar duas ou mais vezes se trouxer o cartão incorretamente. No caso de terminais POS, esse risco não existe, pois o terminal para de trocar com o cartão assim que recebe os dados necessários.

Associando um cartão físico a um token no telefone

Sistemas como o Apple Pay são equipados com a especificação EMV Payment Tokenisation . O procedimento para associar um cartão físico e telefone ao Apple Pay não foi descrito publicamente, portanto, analisaremos o processo com base em dados conhecidos:

1. O provedor (Google, Apple, Samsung) recebe informações do mapa;
2. Por meio do MPS, o provedor solicita se este cartão (este banco emissor) suporta Tokenização EMV;
3. No lado do MPS, é gerado um cartão virtual (token), que é baixado para o armazenamento seguro no telefone. Não sei onde exatamente a chave privada do cartão virtual é gerada, se é transmitida pela Internet ou gerada localmente no telefone; nesse caso, não importa.
4. Um cartão de token virtual gerado é exibido no telefone, as operações nas quais o banco emissor interpreta como operações no primeiro cartão físico. No caso de bloquear o cartão físico, o token também é bloqueado.

O Apple Pay permite que você leia os detalhes de um cartão virtual. O número do PAN e a data de vencimento diferem do cartão vinculado do Alfa-Bank russo. O BIN do cartão virtual (480099) é determinado pelo MBNA AMERICA BANK.

Ao pagar por telefone, o terminal do PDV vê um VISA ou MasterCard comum e se comunica com ele da mesma maneira que com um cartão físico. Um cartão de token virtual contém todos os atributos de um cartão comum: número PAN, data de validade etc. Ao mesmo tempo, o número do cartão virtual e o período de validade diferem do cartão original anexado.

Cenário 1 - terminal POS normal

Fraudador de terminal POS

A trama mais popular de fraude na mente das pessoas comuns: um fraudador com um terminal ligado é pressionado contra eles na multidão e anula dinheiro. Vamos tentar reproduzir esse cenário na realidade.

As condições são as seguintes :

• O fraudador possui um terminal POS normal, totalmente funcional , conectado a um banco adquirente, o mesmo que em lojas e correios. O firmware do terminal não é modificado. No nosso caso - Ingenico iWL250. Este é um terminal POS portátil com um modem GPRS que suporta pagamentos sem contato, funciona com energia da bateria e é totalmente móvel.
• O fraudador não utiliza meios técnicos adicionais, apenas um terminal POS
• Os fundos debitados são creditados na conta corrente do fraudador, de acordo com todas as regras dos sistemas bancários

Entidade legal

Primeiro, precisamos de uma entidade legal com conta corrente e aquisição conectada. Nós, como golpistas reais, não descobrimos nada em nosso nome, mas tentamos comprar uma entidade legal pronta. a pessoa no site pelos mesmos golpistas. Para fazer isso, consulte os anúncios na primeira página do Google para "buy ip" e "buy ooo".


Ofertas para vender empresas prontas de golpistas (clicáveis)

O preço de uma empresa no mercado negro com uma conta corrente varia de 20 a 300 mil rublos. Consegui encontrar várias ofertas de LLC com um terminal POS a partir de 200 mil rublos. Essas empresas são enquadradas por manequins e o comprador recebe todo o pacote de documentos, juntamente com um "cartão de cache" - este é um cartão bancário vinculado à conta de liquidação da empresa simulada. Com esse cartão, um fraudador pode sacar dinheiro em um caixa eletrônico.

Por uma questão de simplicidade, assumimos que LLC + conta bancária + aquisição e um terminal de PDV custarão ao fraudador 100.000 rublos . Na verdade, mais, mas simplificaremos a vida do nosso golpista hipotético, reduzindo o custo do ataque. Afinal, quanto menor o custo do ataque, mais fácil é implementar.

Vamos roubar dinheiro

Assim, o fraudador tem um terminal de ponto de venda e está pronto para ir a um local lotado para se apoiar nas vítimas e roubar dinheiro dos bolsos. Em nosso experimento, todas as vítimas foram instruídas sobre nossas intenções e todas as tentativas de amortizar o dinheiro foram feitas com o seu consentimento. Nos casos em que os sujeitos não tinham seus próprios cartões bancários sem contato, eles eram solicitados a colocar nosso cartão em sua carteira. Anteriormente, os participantes descobriam exatamente onde e como armazenam seus cartões, para que o fraudador soubesse com antecedência onde o cartão sem contato está na bolsa / bolso.


Vídeo: um fraudador furioso em um shopping center

No caso de uma baixa com êxito, a transação foi cancelada através do menu do terminal e o dinheiro foi devolvido à conta dos participantes. Durante toda a duração do experimento, tentamos "roubar" dinheiro de 20 sujeitos no prédio do shopping e na rua. O resultado do teste é descrito abaixo.

Problema: limite de transação sem PIN

O limite do valor máximo da transação sem confirmação com um código PIN pode ser definido tanto no próprio terminal do PDV (limite obrigatório da CVM) quanto no lado do banco. Na Rússia, essa restrição é igual a 1000 rublos.

---

UPD Nas configurações do cartão, o tipo de autorização dos métodos de verificação do titular do cartão (CVMs) pode ser definido como uma assinatura no cheque. Nesse caso, uma transação sem contato ocorrerá por qualquer quantia sem um código PIN.

---

Nosso fraudador decide amortizar 999,99 rublos por vez. Se você for solicitado a tentar anular novamente a quantia abaixo do limite em um curto período de tempo, também será solicitado a inserir o código PIN e, na maioria dos casos, não será possível anular 999,99 rublos várias vezes seguidas. Portanto, a melhor estratégia não será mais do que uma cobrança de um cartão.


Na Rússia, o valor máximo debitado sem um código PIN é de 1000 rublos.

De fato, muitas baixas contábeis com a quantia de 999,99 rublos em um curto período de tempo podem acionar um sistema antifraude do lado do banco adquirente; portanto, essa estratégia não é ideal para um fraudador. Portanto, na vida real, ele teria que escolher quantidades mais diversas, reduzindo assim a renda potencial.

A propósito, muitos artigos sobre esse tópico em russo dizem que você pode definir manualmente seu próprio limite para transações sem contato sem um código PIN. Não encontrei essa opção nos principais bancos russos. Talvez você saiba sobre essa possibilidade? Trata-se de pagamentos sem contato e não de transações com chip e pin.

Problema: Vários cartões na carteira

Este é um ponto importante nesse cenário de ataque, porque, na realidade, quase ninguém carrega uma única carta no bolso. Na maioria dos casos, o cartão é armazenado na carteira junto com outros cartões sem contato, como bilhetes de viagem ou outros cartões bancários.


Especificamente, meu terminal Igenico iWL250, quando detecta mais de uma placa no campo de ação com um SAK indicando suporte para o protocolo 14443-4, retorna um erro: "apresente uma placa".

Mas nem todos os terminais fazem isso. Por exemplo, os terminais POS do VeriFone Sberbank escolhem um cartão aleatório dentre vários. Alguns terminais simplesmente ignoram todos os cartões se houver mais de um, sem mostrar mensagens de erro.


Tentando ler vários cartões em uma carteira. O terminal POS retorna um erro.

Anticolisão ISO 14443-3

Ler um cartão específico de vários não é uma tarefa fácil no nível físico. Para resolver esse problema, existe um mecanismo de anticolisões. Permite selecionar um cartão se uma resposta foi recebida de vários cartões ao mesmo tempo. Este é o primeiro passo para estabelecer contato com um cartão sem contato no protocolo ISO-14443A. Nesta fase, o leitor não consegue descobrir qual dos cartões apresentados é bancário. A única opção é escolher um cartão mais ou menos semelhante a um cartão bancário, com base na resposta de SAK (Selecionar reconhecimento).

Valor de bit na resposta SAK

Assim, por exemplo, o cartão Troika (padrão Mifare) usado no transporte público de Moscou tem um valor de SAK = 0x08 (b00001000) , no qual o sexto bit é zero. Enquanto para todos os cartões bancários nas respostas SAK, o sexto bit é 1, o que significa suporte ao protocolo ISO 14443-4.

Portanto, tudo o que o terminal pode fazer quando vários cartões são detectados ao mesmo tempo é excluir cartões que não suportam a ISO 14443-4 e escolher um semelhante ao bancário. O suporte ao protocolo ISO 14443-4, a propósito, não garante que este cartão seja um cartão bancário, mas muito provavelmente, na carteira de uma pessoa comum, não haverá outro tipo de cartão que suporte a ISO 14443-4.


Fluxograma do protocolo anticolisão

Por experiência pessoal: apesar da existência de um protocolo de anticolisões, se houver pelo menos três cartões sem contato em sua carteira, é EXTREMAMENTE difícil ler com êxito o cartão desejado. A maioria das tentativas resulta em erros de leitura. É ainda mais difícil fazer isso em fuga, agarrando-se aos bolsos e bolsas de outra pessoa.

No entanto, consideraremos que nosso fraudador tem muita sorte e essa restrição não o incomoda.

Transações offline vs online

Em notícias assustadoras, eles falam sobre golpistas com terminais POS em vagões do metrô, que escrevem dinheiro dos seus bolsos no caminho. Essas histórias não mencionam de onde o fraudador obteve Internet móvel no vagão do metrô. Talvez o terminal dele suporte transações offline?

As especificações EMV permitem transações offline. Nesse modo, o débito ocorre sem confirmação on-line do banco emissor. Isso funciona, por exemplo, no transporte público em Moscou e São Petersburgo. Para não entrar na fila do ônibus, enquanto o terminal conclui a confirmação on-line, eles permitem que você entre imediatamente, sem verificar se você tem dinheiro suficiente em sua conta para pagar a tarifa. No final do dia, quando a Internet aparece no terminal, as transações assinadas são enviadas ao banco emissor. Se neste momento você não tiver dinheiro para pagar a tarifa, o cartão será adicionado à lista de paradas em todos os terminais da cidade. Você pode pagar a dívida através da sua conta pessoal pelo número do cartão. Leia mais sobre o pagamento do ônibus em São Petersburgo.

Pessoalmente, não consegui obter um terminal POS que suporte essa função; portanto, no cenário com o terminal POS "civil" usual, não consideraremos a possibilidade de débito offline. Isso não muda nada, exceto que o invasor precisará da Internet no terminal; portanto, o ataque, por exemplo, no metrô, é muito mais complicado.
Existem modelos de terminal que suportam WiFi e, em teoria, nosso fraudador poderia usar Wi-Fi no metrô, tendo anteriormente assumido a compra de acesso sem anúncios para o endereço MAC de seu terminal POS, de modo que a autenticação não precisaria ser feita através do portal cativo, já que no POS o terminal não pode fazer isso.

Calcular lucro

Em nosso cenário, o custo do ataque foi de 100.000 rublos. Isso significa que, para pelo menos retornar os investimentos, nosso herói precisa concluir pelo menos 100 transações de mil rublos cada. Imagine que ele era ágil o suficiente e percorreu a cidade o dia inteiro, agarrando-se a todos em uma fila, de modo que, no final do dia, ele fez 120 baixas com êxito. Não levaremos em consideração a comissão de aquisição (em média 2%), a comissão de desconto (4-10%) e outras comissões.

Ele pode sacar dinheiro com sucesso usando um cartão vinculado a uma conta corrente?

Na realidade, nem tudo é tão simples. O dinheiro será creditado na conta do fraudador apenas em alguns dias! Durante esse período, nosso fraudador deve esperar que nenhuma das cento e vinte vítimas desafie a transação, o que é extremamente improvável. Portanto, na realidade, a conta do fraudador será bloqueada antes mesmo que o dinheiro seja creditado nela.

Se uma pessoa notou que foi feita uma compra em seu cartão que ela não fez, deve entrar em contato com o banco emissor e registrar uma reclamação. 30 , , — 60 . - -, - , .

, ()

Conclusão

O custo de um ataque em nosso cenário é de 100.000 rublos. De fato, será várias vezes maior, portanto, o fraudador precisará de muito mais esforço para obter lucro.

Em nosso cenário, o fraudador sempre baixa 999,99 rublos, o que provavelmente resultará na operação do sistema antifraude do lado do banco adquirente. Na realidade, o fraudador precisará anular quantias menores.

Para pelo menos recuperar os investimentos, o fraudador precisará processar várias centenas de vítimas. Se uma dúzia deles entrar em contato com o banco emissor e contestar a transação, a conta do fraudador provavelmente será bloqueada. O cenário em que o banco adquirente está em conluio com o fraudador é improvável, porque a licença para trabalhar com o MPS custa muito mais do que qualquer lucro potencial desse tipo de fraude.

Dos 20 sujeitos, apenas três conseguiram cancelar o dinheiro do cartão, o que representa 15% de sucesso em todas as tentativas. Esses eram casos artificiais quando havia um único cartão no seu bolso. Nos casos com carteira e vários cartões, o terminal retornou um erro. Em um cenário com um terminal que usa firmware modificado e implementa um mecanismo anticolisão, a porcentagem de cobranças bem-sucedidas pode ser maior. No entanto, mesmo no caso de usar anticolisões, em condições reais em fuga, é tão difícil contar uma carta de várias, para que o débito bem-sucedido nessas condições possa ser considerado sorte. Na realidade, a parcela de baixas com êxito dificilmente excederá 10% do número de tentativas.

, , , . - , .

2 — POS-

Digamos que nosso golpista trabalhe no caixa em uma loja ou em um mensageiro com um terminal de PDV móvel. Nesse caso, ele tem a oportunidade de coletar dados do cartão, que, em alguns casos, podem ser suficientes para pagar na Internet.

Primeiro, vamos descobrir como é exatamente uma transação sem contato e que tipo de dados o cartão troca com um terminal POS. Como estamos com preguiça de ler milhares de páginas da documentação das Especificações sem contato do EMV , simplesmente interceptamos a troca no nível físico usando o farejador HydraNFC.

Há alguma diferença entre a especificação EMV para MasterCard PayPass e Visa payWave. Essa é a diferença no formato da assinatura e em alguns dados. Mas para nós isso não é essencial.

Farejador NFC

O HydraNFC é um sniffer independente de código aberto ISO-14443A que salva comandos APDU interceptados em um cartão SD. A antena farejadora está localizada entre o terminal e o cartão e captura passivamente todas as informações transmitidas.

→ Site sobre o HydraBus e o escudo HydraNFC
→ Fontes de firmware


Demonstração de interceptação da troca entre o terminal POS e o telefone com a Apple Pay

Olhando para o futuro, devo dizer que, nesse nível, o pagamento por telefone e um cartão plástico comum não é diferente. Para um terminal POS, este é um cartão VISA comum. No entanto, pagar por telefone é muito mais seguro do que usar um cartão físico e analisaremos o porquê.

Análise de protocolo EMV

Veja como é o depósito de lixo registrado ao pagar chocolate e uma garrafa de água por um valor total de 142,98 rublos usando o Apple Pay:


Vamos analisar cada linha do despejo interceptado separadamente.

R >> - dados transmitidos pelo terminal POS
T >> - dados transmitidos pelo cartão (no nosso caso, um telefone com Apple Pay)

14443-A Select

No início da troca, o terminal estabelece uma conexão com o cartão no nível do canal. Para aqueles que estão familiarizados com redes e o modelo OSI, será conveniente apresentá-lo como o nível L2 e o UID (Identificador Único) da placa como o endereço MAC do host.

Na terminologia padrão ISO-14443:
PCD (dispositivo de acoplamento de proximidade) é o nome do leitor; no nosso caso, é um PIC-terminal
PICC (cartão de circuito integrado de proximidade) é um cartão; no nosso caso, o telefone desempenha esse papel

Uma diferença importante entre um cartão de pagamento regular da Apple Pay é que o cartão é sempre legível e não permite que você controle o processo de leitura. Ele pode ser lido de maneira descontrolada pelas roupas, enquanto o telefone, caindo no campo de ação do leitor, solicita que o usuário ative um cartão virtual. Até o usuário confirmar, o telefone não transmite dados e o leitor nem sabe que existe um cartão virtual por perto.

R>> 52 // WUPA (wake up)
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
R>> 52 // WUPA
T<< 04 00 // ATQA (Answer To Request type A) 
R>> 93 20 // Select cascade 1 (Anti Collision CL1 SEL)
T<< 08 fe e4 ec fe // UID (4 bytes) + BCC (Bit Count Check)
R>> 93 70 08 fe e4 ec fe dd 6e // SEL (select tag 0x9370) + UID + CRC16
T<< 20 fc 70  // SAK (Select Acknowledge 0x20) + CRC16 
R>> 50 00 57 cd // HALT (Disable communocaion 0x5000) + CRC16
R>> 26 // REQA
R>> 52 // WUPA
T<< 04 00 // ATQA
R>> 93 70 08 fe e4 ec fe dd 6e // SELECT
T<< 20 fc 70 // SAK
R>> e0 80 31 73 // RATS (Request Answer to Select 0xE080) + CRC16
T<< 05 78 80 70 02 a5 46 // ATS (Answer to select response)

O terminal envia constantemente o comando 0x52 Wake-up (WUPA) e, assim que o cartão aparece no campo de ação, ele responde com o comando Atender a solicitar o tipo A (ATQA), no caso, é 0x04 0x00 . A resposta ATQA pode variar de acordo com os fabricantes de chips.

Após receber uma resposta ATQA, o terminal inicia um procedimento de detecção de colisão para determinar se há mais de um cartão no campo de ação. O comando 0x93 0x20 Select cascade level 1 (SEL CL1) solicita a todos os cartões no campo de ação que relatem a primeira parte de seus UIDs.

A placa responde com 0x08 0xFE 0xE4 0xEC 0xFE , os quatro primeiros bytes são o UID da placa virtual Apple Pay e a verificação de contagem de bits 0xFE (BCC) no final.

Após receber os identificadores do cartão, o leitor acessa o cartão específico com o comando 0x93 0x70 (SELECT). Para uma equipe para ser cartão UID 0x08 0xfe 0xe4 0xec + 0xfe o BCC + 0xDD 0x6E CRC16.

O cartão responde com 0x20 Selecione Confirmação (SAK) + 0xfc 0x70 CRC16.

Se várias respostas SAK forem recebidas nesta etapa, o leitor poderá reduzir o comprimento do UID no comando SELECT até que um único cartão responda. No entanto, como mostrado acima, alguns terminais POS se recusam a continuar se forem detectadas colisões neste estágio, ou seja, a presença de vários cartões ao mesmo tempo.

UID 4, 7 10 . , , Apple Pay, UID 4 . , Apple Pay UID , , UID . , , , UID .

O leitor envia o comando 0x50 0x00 HALT + 0x57 0xcd CRC16. Este é um comando de finalização.

Em seguida, o procedimento é repetido novamente, o leitor ativa o cartão novamente (WUPA), mas sem verificar colisões, SELECT é executado imediatamente. Por que isso é feito - não sei, talvez seja uma maneira mais confiável de determinar colisões.

Na segunda vez que o leitor já envia o comando 0xE0 0x80 Solicitar resposta para selecionar (RATS) + 0x31 0x73 CRC16.

O cartão responde 0x05 0x78 0x80 0x70 0x02 Responda para selecionar a resposta (ATS) + 0xA5 0x46 CRC16.

Responda para selecionar- A resposta é semelhante a ATR (resposta a redefinição) para cartões de contato. Ele contém informações sobre o tamanho máximo do quadro e os parâmetros da camada de link.

Nesse estágio, o nível de "canal" é concluído e a troca começa em um protocolo de nível superior, dependendo do aplicativo contido no cartão. A operação SELECT é a mesma para todos os cartões sem contato da norma ISO 14443A, incluindo etiquetas NFC, bilhetes de transporte público, etc.

Solicitação de aplicativos disponíveis - SELECT PPSE

Descrição oficial: Especificações sem contato do EMV - PPSE e gerenciamento de aplicativos para elemento seguro

O início da comunicação com um cartão EMV sempre ocorre lendo o PPSE (ambiente do sistema de pagamento). O terminal pergunta ao cartão quais aplicativos de pagamento estão nele.

Na maioria das vezes, esse é um aplicativo, como no nosso exemplo - VISA. No entanto, existem cartões com vários aplicativos de pagamento, por exemplo, existem cartões MIR domésticos especiais com dois aplicativos de pagamento. Como o sistema de pagamento MIR não funciona no exterior, um segundo aplicativo de pagamento é integrado ao cartão, de fato um segundo cartão. Pode ser um aplicativo do sistema de pagamento JCB ou UnionPay. Esses cartões são chamados de cobertura.

Comando APDU SELECT PPSE

'00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00'
  00 A4 04 00 //  select 
   0E //  command data (14 )
    32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 // command data 2PAY.SYS.DDF01
    00 //  

Responder a SELECT PPSE

'6F 23 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 11 BF 0C 0E 61 0C 4F 07 A0 00 00 00 03 10 10 87 01 01 90 00'

Por conveniência, analisaremos a resposta usando o analisador on-line do formato TVL iso8583.info/lib/EMV/TLVs . A mesma resposta processada pelo analisador:


De tudo isso, estamos interessados ​​apenas no identificador de aplicativo de pagamento (AID). Nesse caso, esse valor é A0000000031010 , significando Visa International.

AID é marcado com um marcador 4F . O segundo bit após o token é o comprimento dos dados que ele contém. Embora o comprimento do AID possa variar de 5 a 16 bytes, na maioria dos casos é de 7 bytes.

Grande lista de AID: eftlab.co.uk/knowledge-base/211-emv-aid-rid-pix

Alguns AIDs populares

A0000000031010 Visa International
A0000000032020 Visa International
A0000000041010 Mastercard International
A0000000043060 Mastercard International United States Maestro (Debit)

Indicador de prioridade do aplicativo - indica a prioridade dos aplicativos de pagamento. Por exemplo, nos cartões de cobertura do MIR que possuem vários aplicativos de pagamento, esse campo indica qual dos dois aplicativos é priorizado. Como temos apenas um pedido da Visa International, ele aponta para ele e não há prioridade.

Iniciar aplicativo de pagamento - SELECIONE AJUDA

'00 A4 04 00 07 A0 00 00 00 03 10 10'
  00 A4 04 00 //  select 
   07 //  command data (7 )
    A0 00 00 00 03 10 10 // AID Visa International

Depois de selecionar o aplicativo de pagamento necessário, o terminal o inicia.

PDOL (Lista de objetos de dados de opções de processamento)

'6f 31 84 07 a0 00 00 00 03 10 10 a5 26 9f 38 18 9f 66 04 9f 02 06 9f 03 06 9f 1a 02 95 05 5f 2a 02 9a 03 9c 01 9f 37 04 bf 0c 08 9f 5a 05 60 08 40 06 43 90 00'

Vamos analisar a resposta com o analisador


Em resposta ao lançamento do aplicativo de pagamento, o cartão relata um conjunto de parâmetros que espera receber do terminal - PDOL (Lista de objetos de dados de opções de processamento). O terminal deve responder estritamente de acordo com esta sequência.

PDOLs para cartões diferentes podem variar. O número total de parâmetros do PDOL é de várias dezenas. Uma lista completa dos parâmetros do PDOL pode ser encontrada aqui .

Vamos dar uma olhada no PDOL. O comprimento indicado após o marcador é o comprimento estritamente esperado da resposta do terminal a esta solicitação. Uma resposta vazia é preenchida com zeros no comprimento desejado.

Análise de solicitação PDOL:

9F 38 18 //   PDOL.  18 (24 ) 
 9F 66 ( 04) // Terminal Transaction Qualifiers (TTQ).    . 
  9F 02 ( 06) //  
   9F 03 ( 06) //  
   9F 1A ( 02) //     ISO3166-1
   95 ( 05) // Terminal Verification Results
    5F 2A ( 02) //  ,    ,   ISO4217
     9A ( 03) //    YYMMDD
      9C ( 01) //   
       9F 37 ( 04) //   

Até este ponto, todos os dados transmitidos são idênticos para todas as transações neste cartão.

Solicitação de cobrança - OBTENHA OPÇÕES DE PROCESSAMENTO

'80A8000023832136A0400000000001429800000000000006430000000000064318091800E011010300'
 80 A8 00 00 //  GET PROCESSING OPTIONS (GPO)
  23 //    (35 )
   83 //  PDOL-
    21 //  PDOL- (33 )
     36 A0 40 00 // Terminal Transaction Qualifiers (TTQ)
      00 00 00 01 42 98 //   (142,98 )
       00 00 00 00 00 00 //   
        06 43 //    (643 - )
         00 00 00 00 00 // Terminal Verification Results (TVR)
          06 43 //  (643 - russian ruble) 
           18 09 18 //  (18  2018 )
            00 //  
             E0 11 01 03 //   

Esta resposta mostra claramente como o terminal, localizado na Rússia, solicita o débito no cartão no valor de 142,98 rublos. Chamamos a atenção para o número aleatório no final (E0110103). Este é o número imprevisível do parâmetro 9F37 . Esta é a primeira menção à criptografia. No futuro, esse número, juntamente com os dados da transação, o cartão terá que assinar com uma assinatura criptográfica. Isso dá ao terminal controle sobre a relevância da assinatura do cartão e protege contra ataques de repetição.

Resposta do cartão a GET PROCESSING OPTIONS

'7762820200409404180101009F360202069F2608D6F56B8ABED78F239F10201F4AFF32A00000000010030273000000004000000000000000000000000000009F6C02008057134800997250511756D23122010000052099995F9F6E04238800009F2701809000'

Esta resposta contém campos de dados específicos do VISA, portanto, usei um analisador com suporte para a especificação de pagamento sem contato VISA (VCSP) .



Perfil de intercâmbio de aplicativos (AIP) - contém informações sobre os parâmetros do aplicativo de pagamento. No nosso caso, o AIP é 00 40 . Considere os valores desse parâmetro do EMV 4.3, livro 3 .


No nosso caso, um bit é definido no segundo byte, que, de acordo com esta tabela, é reservado para uso futuro (RFU). O que isso significa e qual é o objetivo de investir no Apple Pay, eu não sei.

O AIP contém informações importantes sobre os métodos de autenticação suportados (SDA, CDA, DDA) de pagamento. Por que, no meu caso, todas essas bandeiras são iguais a zero - eu não entendo.

AFL (Application File Locator) - Contém informações do intervalo de registros SFI em um AID específico. Com base nesta resposta, o terminal irá gerar uma solicitação de READ RECORD.

Vamos analisar a resposta da AFL com mais detalhes: O

Short File Identifier (SFI) é 0x18. Este parâmetro é codificado com cinco bits em vez de oito. Assim, o valor 0x18 (b00011000) é convertido em b00000011 e obtemos 0x3.
Primeiro registro = 1
Último registro = 1
ou seja, na "pasta" Nº 3, existem entradas de 1 a 1, ou seja, uma entrada.

O Application Transaction Counter (ATC) é um contador de transação incremental que aumenta um a cada vez que uma GET PROCESSING OPTIONS é solicitada. Ao atingir o valor 0xFFFF ou 0x7FFF, o aplicativo de pagamento será bloqueado permanentemente. Eu acredito que isso é feito para proteger contra a força bruta da chave privada do cartão. No nosso caso, pode-se ver que este iPhone com Apple Pay já foi usado para pagar 518 (0x206) vezes.

Criptograma de aplicativo (AC) - uma assinatura criptográfica calculada pelo cartão usando sua chave privada. Essa assinatura é transmitida juntamente com o restante dos dados ao banco emissor, e a autenticidade da transação é verificada com base. Como a chave privada do cartão não pode ser (meio acessível) extraída do cartão, isso elimina a possibilidade de copiar o cartão.

Dados do aplicativo do emissor (IAD) - contém dados proprietários específicos do VISA. Eu não dominava a análise dessa estrutura, ajuda.

Qualificadores de transação de cartão (CTQ) - lista específica de vistos de especificações de cartões suportadas. Por exemplo, é possível usar esse cartão sem contato para transações em um caixa eletrônico ou não, e que tipo de confirmação será necessária.

Faixa 2 Dados Equivalentes - Oppa!Este campo contém o número do cartão e a data de validade. Mais detalhes sobre essas informações serão discutidos posteriormente.

Indicador Facto do formulário (FFI) - campo específico do VISA. Descreve o fator de forma e as características de um dispositivo de pagamento. No nosso caso, é claro que este é um telefone móvel.

Dados de informações criptográficas (CID) - Não dominei a análise dessa estrutura, ajuda.

Consulta READ DATA RECORD

'00 b2 01 1c 00'

O terminal envia uma solicitação para ler os registros recebidos da AFL:


nesse caso, a partir do byte 0x1C , leia como dois valores, onde os cinco primeiros bits são 0x18 (b000011) e SFI, e os próximos três bits são 0x04 (d100) e compõem o número do registro.

Responder a LER RECORD

'70375F280206439F0702C0009F19060400100302735F3401009F241D5630303130303134363138303430313737313031333936313637363235'

Controle de uso de aplicativos (AUC) - determina se é permitido pagar com um cartão no exterior e os tipos de operações permitidos.

9F19 é algo incompreensível, aparentemente - a desatualização de Tokenização

EMV de Lista de Objetos de Dados de Autenticação de Dados Dinâmicos (DDOL) , Referência de Conta de Pagamento (PAR) é um parâmetro específico para cartões tokenizados (virtuais). Eu não dominava a análise dessa estrutura, ajuda.

O que pode ser extraído de uma transação interceptada?

Analisamos um exemplo específico do tráfego interceptado de uma transação sem contato do Apple Pay com um cartão VISA vinculado. O protocolo MasterCard é um pouco diferente, mas em geral semelhante. A partir da análise, pode-se ver que a transação é protegida por assinatura criptográfica e o protocolo é protegido contra um ataque de repetição. Existe um protocolo de pagamento desatualizado sem contato no modo Magnetic Stripe (MSD), que é muito menos protegido contra ataques de repetição, mas neste artigo eu não vou desmontá-lo, porque, tanto quanto eu sei, ele quase não é suportado no CIS, talvez eu esteja enganado.


A partir dos dados interceptados, você pode extrair o número do cartão (PAN) e a data de validade

Como você pode ver, do tráfego interceptado, você pode extrair o número completo do cartão e a data de validade. Embora o CVV não esteja nesse lixão, esses dados já são suficientes para pagar em algumas lojas online. No caso de um cartão de plástico físico comum, os dados interceptados conterão o mesmo PAN e data de validade impressa no próprio cartão!

Pagamento pela Internet sem CVV (CNP, MO / TO)

No meu artigo anterior “Usamos o cartão Apple Pay e Troika como um passe para o trabalho” sobre o ACS baseado no Apple Pay, fui criticado nos comentários, dizendo que apenas com os últimos 10 dígitos do cartão você pode roubar dinheiro. No despejo acima, não apenas o número completo do meu cartão é indicado, mas também a data de validade. Esses dados são suficientes para pagar em algumas lojas na Internet. Bem, tente fazer isso.


O formulário de adição de cartão da Amazon não requer CVV

Se fosse um número de cartão físico, o dinheiro poderia realmente ser roubado, mas os dados do token Apple Pay podem ser usados ​​SOMENTE para operações de Presente do Cliente (CP) quando o cartão assinar a transação com uma assinatura criptográfica. Esses dados não podem ser utilizados para pagamento na Internet e outras operações como o Cartão não presente (CNP), ou seja, por telefone ou e-mail. É isso aí!

Para todos que desejam verificar isso, informo que os detalhes do despejo do Apple Pay interceptados acima são relevantes no momento e estão vinculados a um cartão válido com dinheiro. No momento da redação deste artigo, são 5 mil rublos. Sugiro tentar roubá-los :)

Por que o Apple Pay é mais seguro que um cartão comum

Apple Pay vs cartão sem contato normal

• Apple Pay ( ) . POS-. , «» , , , , , . Apple Pay , , .
• — Apple Pay (13,56 ), , . . Apple Pay , .
• — Card not present (CNP), , .. Apple Pay .
• — (Cardholder name) . , , . Apple Pay .

. , . .

, Apple Pay . CNP- ( ) , .

---

:

• Empresas tehpos.ru para o hardware.
• Banco Ural de Reconstrução e Desenvolvimento , e pessoalmente a Alexander Paderin (Diretor Gerente do Centro de Segurança da Informação) para consultas.
• Armazenar aj.ru para fornecer iPhones para testar.
• Valeria Aquamine para ilustrações para o artigo.
• Gleb JRun, da Digital Security, para consultoria técnica.
• Alexander AlexGre para consultas sobre o protocolo EMV.
• Habrayuzeru forma para um excelente analisador de EMV: iso8583.info