Quebrar VISA PIN
02. De julho de 2008 na Banca e Eftpos
Abaixo está um artigo que encontrei recentemente. Esta uma das mais completas descrições do PIN Verification Value (PVV) hacking.
Eu pensei que ela iria replicar aqui para o meu local de referência.
Como observação, foram feitas sobre a gramática usada no texto original, tenho corrigido alguns dos erros óbvios, mantendo o contexto do material original.
http://69.46.26.132/ ~ biggold1/fastget2you/tutorial.php
--- Texto original ----
Prefácio
Você já se perguntou o que aconteceria se você perder o seu cartão de crédito ou débito e alguém encontra-lo. Será que essa pessoa seja capaz de retirar dinheiro de um caixa eletrônico adivinhação, de alguma forma, o seu PIN? Além disso, se você acha que alguém do cartão que você tentar adivinhar a senha e ter a chance de obter algum dinheiro fácil? Claro que a resposta às duas questões devem ser "não". Este trabalho não trata da segunda questão, é uma questão de ética pessoal. Herewith tento responder à primeira pergunta.
Todas as informações utilizadas para este trabalho é público e pode ser encontrado livremente na Internet. O resto é uma questão de matemática e programação, assim podemos aprender alguma coisa e ter algum divertimento. Eu não revelam segredos. Além disso, o objectivo (e conclusão), do presente trabalho é demonstrar que a PIN algoritmos ainda são fortes o suficiente para proporcionar segurança suficientes. Todos sabemos tecnologia não é o ponto fraco.
Este trabalho analisa uma das mais comuns PIN algoritmos, VISA PVV, utilizada por muitos ATM cartões (de crédito e de débito) e tenta descobrir como é resistente a PIN guessing ataques. Por "adivinhar" Não me refiro a uma escolha aleatória PIN e tentar-lo em um caixa eletrônico. É sabido que geralmente são dadas nos três ensaios consecutivos para entrar à direita PIN, se não ATM mantém o cartão. Como VISA PIN é quatro dígitos longa, é fácil deduzir que a chance de um aleatória PIN adivinhação é de 3 / 10000 = 0,0003, parece baixo o suficiente para ser seguro, isso significa que você precisa perder o seu cartão de mais de três mil vezes ( ou a perder mais de três mil cartões ao mesmo tempo:) até que haja uma hipótese razoável de perder dinheiro.
O que eu realmente entende por "adivinhar" foi quebrar o PIN algoritmo de modo que, dado qualquer cartão que você pode saber imediatamente os associados PIN. Por conseguinte, este documento estudos essa possibilidade, analisando o algoritmo e propor um método para o ataque. Finalmente vamos dar uma ferramenta que implementa o ataque e apresentar resultados sobre a estimativa chance de quebrar o sistema. Note que, enquanto outros bancos de segurança relacionados com algoritmos (outros PIN formatos, como a IBM PIN ou cartão de assinaturas, como a validação CVV ou CVC) são semelhantes aos VISA PIN, a mesma análise pode ser feito rendendo quase os mesmos resultados e conclusões.
Um dos mais comuns PIN algoritmos é o VISA PIN Verification Value (PVV). O cliente é atribuído um PIN e uma banda magnética cartão. Encoded na banda magnética é um número de quatro algarismos, chamado PVV. Este número é um criptográfico assinatura do PIN e outros dados relacionados ao cartão. Quando um usuário digita o seu PIN a ATM lê a banda magnética, criptografa e envia todas essas informações para um computador central. Há um julgamento PVV é calculado utilizando o cliente entrou PIN e as informações de cartão com uma criptografia algoritmo. O julgamento PVV é comparado com o PVV armazenados no cartão, se corresponderem a volta para o computador central ATM autorização para a operação. Veja mais em pormenor.
A descrição da PVV algoritmo pode ser encontrada em dois documentos ligados na página anterior. Em resumo, consiste na encriptação de um byte 8 (64 bits) seqüência de dados, chamado Transformado Security Parameter (SFT), com DES algoritmo (DEA) em Eletrônica Código Livro modo (BCE), utilizando uma chave secreta 64 bits. O PVV é proveniente da produção da criptografia processo, que é um byte 8 string. Os quatro algarismos do PVV (da esquerda para a direita) correspondem aos quatro primeiros dígitos decimais (da esquerda para a direita) da saída do DES quando considerada como um 16 caracteres hexadecimais (16 bits x 4 = 64 bits) string. Caso não haja quatro dígitos decimais entre os 16 caracteres hexadecimais então o PVV é completado tomada (da esquerda para a direita) não decimais caracteres e decimalizing-los usando a conversão A-> 0, B-> 1, C-> 2, D -> 3, E-> 4, F-> 5. Aqui está um exemplo:
Saída de DES: 0FAB9CDEFFE7DCBA
PVV: 0975
A estratégia de evitar decimalização saltando por até quatro caracteres dígitos decimais são encontrados (o que acontece com a quase totalidade das vezes como veremos mais adiante) é muito inteligente, porque evita um viés importante na distribuição de dígitos que tem sido provado ser fatal para outros sistemas, embora o impacto sobre o sistema seria muito menor. Veja também relacionada com um problema que não se aplicam a VISA PVV.
O SFT, considerada como um 16 caracteres hexadecimais (64 bits) string, é formada (da esquerda para a direita) com os 11 dígitos direita do PAN (número de cartão), excluindo o último dígito (check dígito), um dígito 1-6 que seleciona o segredo encriptando-chave e, finalmente, a quatro dígitos do código PIN. Aqui está um exemplo:
PAN: 1234 5678 9012 3445
Chave seletor: 1
PIN: 2468
TSP: 5678901234412468
É óbvio que o problema da quebra VISA PIN consiste em encontrar a chave secreta de encriptação DES. O método para isso é fazer uma pesquisa de força bruta a tecla espaço. Note-se que este não é o único método, pode-se tentar encontrar um ponto fraco na DEA, muitos tentaram, mas este padrão antigo ainda está em ampla utilização (agora substituído por AES e RSA, embora). Isto demonstra que é robusto o suficiente para que a força bruta é o único método viável (existem alguns ataques, mas não melhor prática no nosso caso, para um resumo ver LASEC memória e para ver os detalhes sujos Biham & Shamir 1990, Biham & Shamir 1991, Matsui 1993, Biham & Biryukov 1994 e Heys 2001).
A chave era muito provável algarismos selector introduzidas para cobrir a possibilidade de um compromisso fundamental. Nesse caso, eles só têm de emitir novos cartões usando outra chave selector. Antigas cartas podem ser substituídas por novas, ou simplesmente a ATM transparente pode escrever uma nova PVV (que corresponde à nova chave e mantendo o mesmo PIN) próxima vez que o cliente usa o seu cartão. Para o shake de segurança todos os usuários devem ser convidados a mudar os seus PINs, porém, seria embaraçoso para o banco a explicar a razão, muito provavelmente não teriam de fazer tal pedido.
Preparando o ataque
A força bruta ataque consiste em encriptando SFT com uma conhecida PVV utilizando todas as possíveis chaves encriptando e comparar cada obtidos PVV com as conhecidas PVV. Quando uma correspondência for encontrada, temos um candidato chave. Mas quantas chaves temos de tentar? Como dissemos acima da chave é de 64 bits de comprimento, o que significa que temos de tentar 2 ^ 64 chaves. Contudo, isto não é verdade. De facto, apenas 56 bits são eficazes na DES chaves porque um bit (o menos significativo) de cada octeto foi historicamente reservado como um checksum para os outros, na prática os 8 bits (uma para cada um dos 8 octetos) são ignoradas.
Assim, o DES tecla espaço é composto por 2 ^ 56 chaves. Se tentarmos todas estas chaves encontraremos um e só um jogo, o que corresponde ao banco chave secreta? Certamente que não. Iremos obter muitos correspondentes chaves. Isto porque o PVV é apenas uma pequena parte (um quarto) do DES saída. Além disso, o PVV é degenerada porque alguns dos dígitos (aqueles entre 0 e 5 após o último, visto a partir da esquerda para a direita, algarismos entre 6 e 9) podem ser provenientes de uma casa decimal de um dígito ou dígitos hexadecimais decimalized do DES saída. Assim, muitas chaves irá produzir uma DES saída que produz a mesma correspondência PVV.
Então o que podemos fazer para encontrar a verdadeira chave entre os outros falsos positivos chaves? Simplesmente temos de encriptar um segundo diferentes TSP, também conhecida com PVV, mas utilizando apenas o candidato que deu as chaves uma correspondência positiva com o primeiro-TSP PVV par. No entanto não há garantia de que não irá receber novamente muitos falsos positivos, juntamente com a verdadeira chave. Se assim for, teremos um terceiro TSP-PVV par, repita o processo e assim por diante.
Antes de começarmos o nosso ataque, temos de saber quantos TSP-PVV pares vamos precisar. Por que temos que calcular a probabilidade de um aleatória DES produção para produzir uma correspondência PVV apenas por acaso. Existem várias formas de calcular este número, e aqui vou usar uma abordagem simples de fácil compreensão, mas que exige uma certa experiência em matemática de probabilidade.
A probabilidade pode ser sempre visto como a razão de casos favoráveis a possíveis casos. No nosso problema, o número de casos possíveis é dada pela permutação de 16 elementos (de 0 a F dígitos hexadecimais) em um grupo de 16 deles (os 16 dígitos hexadecimais do DES de saída). Esta é dada por 16 ^ 16 ~ 1,8 * 10 ^ 19, que obviamente coincide com 2 ^ 64 (números diferentes de 64 bits). Este conjunto de números podem ser divididos em cinco categorias:
Aqueles com pelo menos quatro dígitos decimais (0 a 9) entre os 16 dígitos hexadecimais (0 a F) do DES saída.
Aqueles com exactamente apenas três dígitos decimais.
Aqueles com exactamente apenas duas casas decimais.
Aqueles com exactamente apenas um dígito decimal.
Aqueles que não dígitos decimais (todos entre A e F).
Vamos calcular quantos números caem em cada categoria. Se nos rótulos dos 16 dígitos hexadecimais do DES X1 como saída para X16 então podemos rotular os primeiros quatro dígitos decimais de um determinado número de primeira categoria como Xi, XJ, XK e XL. O número de combinações diferentes com este perfil é dada pelo produto 6 i-1 * 10 * 6 undecies-i-1 * 10 * 6k-j-1 * 10 * 6 lk-1 * 10 * 1616-l quando a 6 ' s vir a partir do número de possibilidades de um dígito A a F, os 10's provêm as possibilidades de um dígito de 0 a 9 e as 16 trata das possibilidades de um 0 a F dígito. Já os números totais na primeira categoria é simplesmente dado pelo somatório do produto ao longo do i, j, k, l 1-16, mas com i <j <k <l. Se você fizer alguma matemática trabalho você verá esta é igual ao produto de 104 / 6, com o somatório sobre i 4-16 de (i-1) * (i-2) * (i-3) * 6i-4 * 16 16-i ~ 1/8 * 1019.
Analogamente, o número de casos na segunda categoria é dada pelo somatório sobre i, j, k 1-16 com i <j <k do produto 6i-1 * 10 * 6 undecies-i-1 * 10 * 6k-j -1 * 10 * 616-k, que você pode trabalhar para fora para ser 16! / (3! * (16-13)!) * 103 * 6 13 = 16 * 15 * 14 / (3 * 2) * 103 * 613 = 56 * 104 * 613 * 1015 ~ 7/3. Do mesmo modo para a terceira categoria que temos sobre o somatório i, j 1-16 com i <j, de 6 i-1 * 10 * 6 undecies-i-1 * 10 * 616-J, que é igual a 16! / (2! (16-14)!) * 102 * 614 = 2 * 103 * 615 * 1014 ~ 9,4. Mais uma vez, para a quarta categoria, temos o somatório sobre i 1-16 de 6i-1 * 10 * 616-i = 160 * 615 * 1013 ~ 7,5. E, finalmente, a quantidade de casos na quinta categoria é dada pela permutação de seis elementos (A a F dígitos) em um grupo de 16, ou seja, 616 ~ 2,8 * 1012.
Espero que você seguiu os cálculos até este ponto, a parte mais difícil está feito. Agora, como uma prova de que tudo está a direita, você pode soma do número de casos em 5 categorias e ver o que equivale ao número total de casos possíveis é calculado antes. Será que as operações com números de 64 bits ou de arredondamento (para carros alegóricos), ou por transbordamento (para inteiros) erros não vão deixar você obter o resultado exato.
Até agora temos calculado o número de casos possíveis em cada uma das cinco categorias, mas estamos interessados em obter o número de casos favoráveis vez. É muito fácil obter o último dos antigos como esta é apenas a fixação do conjunto de quatro dígitos decimais (ou o exigido dígitos hexadecimais, se não houver quatro casas decimais) do PVV vez de deixá-las livres. Na prática, isso significa transformar os 10's na fórmula acima em 1 e do montante exigido é de 6 em 1's, se não houver quatro casas decimais. Isto é, temos que dividir o primeiro resultado por 104, o segundo um por 103 * 6, o terceiro um por 102 * 62, a um quarto por 10 * 63 eo quinto um por 64. Em seguida, o número de casos favoráveis nas cinco categorias são aproximadamente 1,8 * 1015, 1.2 * 1012, 2.6 * 1011, 3.5 * 1010, 2,2 * 109, respectivamente.
Agora somos capazes de obter o que é a probabilidade de um DES de saída para combinar uma PVV por acaso. Só temos de somar os cinco números de casos favoráveis e dividi-lo pelo número total de casos possíveis. Fazendo isso obtemos que a probabilidade é muito 0,0001 ou aproximadamente um em cada dez mil. É estranho esse bem arredondadas resultado? Nem por isso, basta ter um olhar para os números que acima calculada. A primeira categoria domina por várias ordens de grandeza do número de casos favoráveis e possíveis. Isto é bastante intuitivo como parece claro que é muito pouco provável que não tenha quatro dígitos decimais (10 chances de 16 por algarismos), entre 16 dígitos hexadecimais. Já vimos anteriormente que a relação entre o número de casos possíveis e favoráveis na primeira categoria foi uma divisão de 10 ^ 4, que é onde o nosso resultado p = 0,0001 vem.
O nosso objectivo para todos estes cálculos foi para descobrir quantos TSP-PVV pares precisamos para transportar uma força bruta bem sucedido ataque. Agora somos capazes de calcular o número esperado de falsos positivos em uma primeira pesquisa: ele será o número de julgamentos vezes a probabilidade de um único aleatória falso positivo, ou seja, p * t em que t = 2 ^ 56, o tamanho da chave espaço. Isto equivale a cerca de 7,2 * 10 ^ 12, um número bastante grande. O número esperado de falsos positivos no segundo pesquisa (restrito ao chaves positivo encontrado na primeira busca) será (t * p) * p, para uma terceira pesquisa será ((t * p) * p) * p e assim por diante. Assim, para pesquisas n é o número esperado de falsos positivos serão p * t ^ s.
Podemos obter o número de pesquisas necessárias para esperar apenas um falso positivo, expressando a equação t * p ^ n = 1 e para a resolução n. Então n é igual ao logarítmo na base de 1 p / t, o que por propriedades dos logaritmos que produz n = log (1 / t) / log (p) ~ 4.2. Uma vez que não podemos fazer uma pesquisa fraccionária é conveniente ronda até este número. Portanto o que é o número esperado de falsos positivos quando realizamos cinco pesquisas? É p * t ^ 5 ~ 0,0007 ou aproximadamente 1 em 1400. Assim, usando cinco TSP-PVV pares é segura para obter a verdadeira chave secreta, sem falsos positivos.
O ataque
Uma vez que sabemos que precisamos cinco TSP-PVV pares, o que fazer para obtê-los? Claro que precisamos de pelo menos um cartão com conhecidos PIN, e devido à natureza do PVV algoritmo, que é a única coisa que precisamos. Com outros PIN sistemas, como a IBM, que precisamos cinco cartões, no entanto, este não é necessária com VISA PVV algoritmo. Só temos de ler a banda magnética e, em seguida, alterar o PIN quatro vezes, mas a leitura do cartão após cada mudança.
É necessário ler a tarja magnética do cartão para obter o PVV e os encriptando chave selector. Você pode comprar um comercial magnética leitor ou fazer uma você mesmo, seguindo as instruções que você pode encontrar na página anterior e links nele. Uma vez que você tenha um leitor ver esta descrição do padrão magnético trilhas para saber como obter o PVV a partir dos dados lidos. Nesse documento, o PVV campo em faixas 1 e 2 é dito ser cinco caracteres de comprimento, mas, na verdade, o verdadeiro PVV consiste dos últimos quatro dígitos. O primeiro dos cinco dígitos é a chave selector. Só tenho visto cartas com um valor de 1 dígito no presente, o que é consistente com o padrão e com a chave secreta não seja comprometida (e, portanto, eles não precisam se deslocar para outra chave mudar o seletor).
Eu fiz um simples programa C, getpvvkey.c, para realizar o ataque. Consiste em um loop para experimentar todas as chaves possíveis para criptografar o primeiro TSP, se o derivado PVV corresponde à verdade PVV um novo TSP é julgado, e assim sucessivamente até que haja um desfasamento, caso em que a chave é descartado e um novo é julgado, ou a cinco derivados PVVs correspondem a verdade corre PVVs, caso em que podemos assumir que temos o banco chave secreta, no entanto o ciclo prossegue até que se esgota a tecla espaço. Isto é feito para garantir que encontramos a verdadeira chave, porque existe uma chance (embora muito baixo) a primeira chave encontrada é um falso positivo.
Espera-se que o programa iria demorar muito tempo para terminar e para minimizar os riscos de um corte de energia, computador sair, etc faz verificação no arquivo getpvvkey.dat de vez em quando (o tempo exato depende da velocidade do computador, é de cerca de uma hora para os mais rápidos computadores actualmente em uso). Pela mesma razão, se for encontrada uma chave positiva é escrito no arquivo getpvvkey.key. O programa só exibe uma mensagem no início, a tomada de posição inicial a verificação se algum arquivo, depois que nada mais é exibido.
O DES algoritmo é um ponto fundamental no programa, é, pois, muito importantes para otimizar a sua velocidade. Eu testei várias implementações: libdes, SSLeay, openssl, cryptlib, NSS, libgcrypt, catacumbas, libtomcrypt, cryptopp, UFC-crypt. O DES funções dos primeiros quatro são baseados no mesmo código de Eric Young e é o que teve melhor desempenho (inclui C otimizada e x86 assembler code). Assim eu escolhi o que era o original libdes execução e condensado código relevante em todos os arquivos encrypt.c (versão C) e x86encrypt.s (montador versão x86). O código é ligeiramente modificada para realizar algumas melhorias em uma força bruta ataque: a primeira permutação é um fixo comum íngremes em cada TSP criptografia e, portanto, podem ser feitas apenas uma vez no início. Outra melhoria é que eu escrevi uma função totalmente nova setkey (Chamei-a de nextkey), o que é óptimo para uma força bruta loop.
Para obter o programa de trabalho que você só precisa digitar o lugar correspondente TSPs cinco e os seus PVVs e então compilá-lo. Eu testei-o apenas em plataformas UNIX, usando o makefile para compilar Makegetpvvkey (use o comando "make-f Makegetpvvkey"). Pode compilar em outros sistemas, mas pode ser necessário corrigir algumas coisas. Certifique-se de que a definição do tipo long64 corresponde a um 64 bits inteiro. Em princípio não existe uma dependência do endianness do processador. Tenho compilado com sucesso e executá-la no Pentium-Linux, Alpha-Tru64, Mips-sparc-Irix e Solaris. Se você não tem e não quiser instalar o Linux (você não sabe o que está faltando ;-) você ainda tem a opção para executar o Linux em CD e usar o meu programa, ver a minha página executando o Linux sem instalá-lo.
Depois de ter encontrado o segredo bancário chave se você quiser descobrir a senha de um arbitrário cartão você só tem que escrever um programa semelhante (desculpe eu não tenho escrito, sou muito preguiçosa:) que julgar todos os 10 ^ 4 pinos por gerar o correspondente TSP, criptografando-a com a (não mais) chaves secretas, decorrentes da PVV e compará-lo com o PVV na banda magnética do cartão. Você vai ter um jogo para os verdadeiros PIN. Apenas um jogo? Lembre-se do que vimos acima, temos uma chance de que uma 0,0001 encriptação aleatória corresponde à PVV. Estamos a tentar 10000 PINs (e, portanto, TSPs), assim esperamos 10000 * 0,0001 = 1 falso positivo em média.
Este é um resultado muito interessante, isso significa que, em média, cada cartão tem dois PINs válido: o cliente PIN eo esperado falso positivo. Eu chamo-lhe "falsas", mas nota que, enquanto que gera o verdadeiro PVV é um PIN como válida como a de um cliente. Além disso, não há maneira de saber qual é qual, mesmo para a ATM; único cliente sabe. Mesmo se os falsos positivos não foram válidos como PIN, você ainda tem três ensaios no ATM mesmo assim, suficiente, em média. Portanto, a probabilidade é calculada no início do presente documento sobre aleatória guessing do código PIN tem de ser corrigido. Na verdade ele é o dobro desse valor, ou seja, é 0,0006 ou um dos mais de 1600, ainda pouco segura.
Resultados
É importante para otimizar a compilação do programa e para executá-lo no processador mais rápido possível, devido à longa espera correr tempo. Achei que o compilador otimização-O pavilhão obtém o melhor desempenho, o pensamento é conseguido adicionando algumas melhorias a-fomit-frame-pointer bandeira ontário Pentium-Linux, a espícula-bandeira na Alfa-Tru64, o IPA-bandeira na Mips-Irix e do fast-bandeira na Sparc-Solaris. Especial bandeiras (-DDES_PTR-DDES_RISC1-DDES_RISC2-DDES_UNROLL-DASM) para o DES código, geralmente têm benefícios tão bem. Todas estas bandeiras já foram testadas e eu escolhi a melhor combinação para cada processador (ver makefile), mas você pode tentar afinar outros pavilhões.
De acordo com a minha testa o melhor desempenho é alcançado com o processador AMD Athlon 1600 MHz, superior a 3,4 milhões de chaves por segundo. É interessante que obtém melhores resultados do Intel Pentium IV 1800 MHz e 2000 MHz (veja números abaixo, clique nelas para ampliar). Penso que isto é devido a alguns I / O saturação, certamente cache ou de acesso à memória, que o processador AMD (que tem metade do cache do Pentium) ou da placa-mãe em que ela está funcionando, consegue evitar. Na primeira figura abaixo você pode ver que o DES quebrar velocidade de todos os processadores tem mais ou menos uma relação linear com a velocidade do processador, exceto para os dois Intel Pentium que eu mencionei antes. Isto é lógico, isso significa que, para um duplo processador velocidade você obterá dupla quebrar a velocidade, mas esteja atento para a saturação efeitos, neste caso, é melhor o AMD Athlon 1600 MHz, que será ainda mais barato do que o Intel Pentium 1800 MHz ou 2000 MHz.
Na segunda figura podemos ver em maior detalhe o que poria intrínseco DES quebrar o poder do processador. Recebo este valor simplesmente dividindo a velocidade por quebrar a velocidade do processador, ou seja, obtemos o número de DES chaves tentou por segundo e por MHz. Esta é uma medida do desempenho do processador tipo, independentemente da sua velocidade. Os resultados mostram que o melhor processador para esta tarefa é o AMD Athlon, em seguida, vem o Alpha e depois de muito perto, é o Intel Pentium (exceto para a velocidade mais elevada aquelas que desempenham muito pobre, devido à saturação efeito). Seguinte é o processador Mips e no último lugar está o Sparc. Alguns processadores Alpha e Mips estão localizados na parte inferior da escala porque são libertações antecipadas não incluindo acessórios da tarde versões. Note que eu incluído o desempenho dos processadores x86 para C e montador código, dado que existe uma grande diferença. Parece que o gcc não é um bom gerador de código otimizado máquina, mas obviamente não sabemos se uma otimização manual de montagem código para os outros processadores (Alpha, MIPS, Sparc) iria aumentar os seus resultados comparados com os nativos compiladores C (Eu não uso o gcc para essas outras plataformas), tal como acontece com o processador x86.
Atualizar
Aqui está um artigo em que estas técnicas podem ter sido utilizados.