BR102014017104A2 - pré-geração de chaves de sessão para transações eletrônicas e dispositivos que pré-geram chaves de sessão para transações eletrônicas - Google Patents

Abstract

pré-geração de chaves de sessão para transações eletrônicas e dispositivos que pré-geram chaves de sessão para transações eletrônicas. a presente invenção refere-se a métodos e dispositivos para pré-gerar chaves de sessão para assegurar que transações são providas. uma pluralidade de chaves criptográficas de sessão é gerada a partir de uma chave criptográfica mestre e uma respectiva pluralidade de valores possíveis de um contador de transação. as chaves criptográficas de sessão são criptografadas para prover uma pluralidade de chaves criptográficas de sessão criptografada, que são armazenadas no terminal de usuário. a chave criptográfica mestre é deletada a partir do terminal de usuário após as chaves de sessão ser geradas. para assegurar uma transação, um criptograma é gerado baseado em uma das chaves criptográficas de sessão criptografada e em dados de transação para a transação, e o criptograma é transmitido a um terminal de transação. o contador de transação é atualizado, e a chave criptográfica de sessão criptografada é deletada a partir do terminal de usuário.

Description

Relatório Descritivo da Patente de Invenção para "PRÉ-GERAÇÃO DE CHAVES DE SESSÃO PARA TRANSAÇÕES ELETRÔNICAS E DISPOSITIVOS QUE PRÉ-GERAM CHAVES DE SESSÃO PARA TRANSAÇÕES ELETRÔNICAS".

ANTECEDENTES

[001] Com a proliferação de dispositivos móveis, a indústria de pagamento com cartão está se movendo para pagamento usando o equivalente de um cartão com chip armazenado no dispositivo móvel. Para pagamento móvel, os mesmos dados e algoritmos podem ser armazenados em um dispositivo móvel, e o pagamento credencial é ainda denominado um "cartão" embora não mais fisicamente reside em um cartão de plástico. Como usado no presente documento, a palavra "cartão" significa este tipo de cartão em um dispositivo móvel.

[002] O consórcio "Europay, MasterCard e Visa" (EMV) define especificações para cartões móveis que trabalham dentro d uma infraes-trutura de pagamento segura. Todas as marcas de cartão principais, incluindo Visa, MasterCard, American Express, Discover, etc., são especificações de cartão desenvolvidas que derivam a partir das especificações de EMV.

[003] Em algumas variantes, o cartão contém chaves criptográficas secretas que são armazenadas seguramente e que são usadas para dados de transação com assinatura digital referente a uma transação potencial, tal como uma transação com cartão de crédito ou uma transação com cartão de débito. Os dados de transação assinados digitalmente podem ser usados para verificar a transação, que pode prover segurança melhorada em relação a uma transação com cartão de crédito/débito convencional. Tal cartão pode ser usado, por e-xemplo, em um ponto comercial de terminal (POS) de venda, um caixa eletrônico automático (ATM) ou outro local que provê uma leitora NFC. SUMÁRIO

[004] Algumas modalidades proporcionam métodos de assegurar uma transação entre um terminal de usuário e um terminal de transação. Os métodos incluem gerar uma pluralidade de chaves criptográficas de sessão a partir de uma chave criptográfica mestre e uma respectiva pluralidade de valores possíveis de um contador de transação, armazenar a pluralidade de chaves criptográficas de sessão e uma da respectiva pluralidade de valores do contador de transação no terminal de usuário, criptografar uma pluralidade de chaves criptográficas de sessão para prover uma pluralidade de chaves criptográficas de sessão criptografada, gerar um criptograma baseado em uma primeira da pluralidade de chaves criptográficas de sessão criptografada e dados de transação para a transação, transmitir o criptograma ao terminal de transação, atualizar o contador de transação, e deletar a uma primeira pluralidade de chaves criptográficas de sessão criptografada a partir do terminal de usuário após gerar o criptograma.

[005] Criptografar a pluralidade de chaves criptográficas de sessão pode incluir criptografar com um número de identificação pessoal.

[006] Criptografar a pluralidade de chaves criptográficas de sessão pode incluir camuflar a pluralidade de chaves criptográficas de sessão.

[007] Camuflar a pluralidade de chaves criptográficas de sessão pode incluir criptografar a pluralidade de chaves criptográficas de sessão de tal modo que decodificar qualquer uma da pluralidade de chaves criptográficas de sessão com um número de identificação pessoal incorreto produz uma chave criptográfica de sessão.

[008] Os métodos podem incluir ainda prover a chave criptográfica mestre no terminal de usuário e deletar a chave criptográfica mestre a partir do terminal de usuário após gerar a pluralidade de chaves criptográficas de sessão. Após deletar a chave criptográfica mestre a partir do terminal de usuário, pode haver nenhum dado restante no terminal de usuário que pode ser usado seguramente para decodificar as chaves criptográficas de sessão restantes usando os dados de transação e o criptograma.

[009] Os métodos podem incluir ainda prover a chave criptográfica mestre no terminal de usuário, e deletar a chave criptográfica mestre a partir do terminal de usuário após gerar a pluralidade de chaves criptográficas de sessão.

[0010] Em algumas modalidades, o número de chaves criptográficas de sessão gerado pode incluir um número de valores possíveis do contador de transação e, em outras modalidades, o número de chaves criptográficas de sessão geradas inclui menos do que um número de valores possíveis do contador de transação.

[0011] A chave criptográfica de sessão pode incluir uma pluralidade de chaves criptográficas.

[0012] Gerar o criptograma pode incluir aplicar uma função de ha-sh aos dados de transação e a uma primeira das chaves criptográficas de sessão criptografada.

[0013] Atualizar o contador de transação pode incluir incrementar o contador de transação.

[0014] Um terminal de usuário de acordo com algumas modalidades inclui um processador, uma memória acoplada ao processador, e um módulo de comunicação acoplado ao processador. O processador é configurado para gerar uma pluralidade de chaves criptográficas de sessão a partir de uma chave criptográfica mestre e uma respectiva pluralidade de valores possíveis de um contador de transação, para armazenar as chaves criptográficas de sessão, para criptografar a pluralidade de chaves criptográficas de sessão para prover uma pluralidade de chaves criptográficas de sessão criptografada, para trocar dados de transação referentes a uma transação proposta com um terminal de transação, para gerar um criptograma baseado em uma primei- ra da pluralidade de chaves criptográficas de sessão criptografada e nos dados de transação, para transmitir o criptograma ao terminal de transação usando o módulo de comunicação, para atualizar o contador de transação, e para deletar a uma primeira da pluralidade de chaves criptográficas de sessão criptografada a partir do terminal de usuário.

[0015] Criptografar as chaves criptográficas de sessão pode incluir criptografar a pluralidade de chaves criptográficas de sessão com um número de identificação pessoal.

[0016] O processador pode ser configurado para camuflar a pluralidade de chaves criptográficas de sessão de tal modo que decodificar qualquer uma da pluralidade de chaves criptográficas de sessão criptografada com um número de identificação pessoal incorreto produz uma chave criptográfica de sessão válida.

[0017] Um servidor de provisionamento de acordo com algumas modalidades inclui um processador, uma memória acoplada ao processador e um módulo de comunicação acoplado ao processador. O processador é configurado para gerar uma pluralidade de chaves criptográficas de sessão a partir de uma chave criptográfica mestre e uma respectiva pluralidade de valores possíveis de um contador de transação, e para transmitir a pluralidade de chaves criptográficas de sessão e o contador de transação a um terminal de usuário para uso na segurança de uma transação financeira.

[0018] As chaves criptográficas de sessão podem incluir primeiras chaves criptográficas de sessão, em que o número de primeiras chaves criptográficas de sessão inclui menos do que um número de valores possíveis do contador de transação, e o processador pode ser ainda configurado para gerar chaves criptográficas de sessão adicionais e transmitir as chaves criptográficas de sessão adicionais ao terminal de usuário quando o suprimento de primeiras chaves criptográficas de sessão ao terminal de usuário é reduzido para um nível predetermina- do.

[0019] Algumas modalidades proporcionam métodos incluindo gerar uma pluralidade de itens secretos correspondendo a uma respectiva pluralidade de valores possíveis de um índice, armazenar a pluralidade de itens secretos e uma primeira da pluralidade de valores possíveis do índice em um primeiro terminal, gerar uma mensagem correspondendo a uma primeira da pluralidade de valores possíveis do índice usando um primeiro dos itens secretos, transmitir a mensagem ao segundo terminal, atualizar o índice e deletar a uma primeira da pluralidade de itens secretos a partir do primeiro terminal após gerar a mensagem. A pluralidade de itens secretos pode ser uma senha de uso. O índice pode ser um índice de transação, e a mensagem pode ser um resumo de transação para uma transação entre o primeiro terminal e o segundo terminal.

[0020] Produtos de programa de computador relacionados são divulgados. Nota-se que os aspectos descritos no presente documento com respeito a uma modalidade podem ser incorporados em modalidades diferentes embora não especificamente descritos em relação às mesmas. Isto é, todas as modalidades e/ou aspectos de quaisquer modalidades podem ser combinadas em qualquer modo e/ou combinação. Além do mais, outros sistemas, métodos e/ou produtos de programa de computador de acordo com as modalidades serão ou tornar-se-ão evidentes a um perito na técnica na revisão dos seguintes desenhos e descrição detalhada. É pretendido que todos estes sistemas adicionais, métodos e/ou produtos de programa de computador sejam incluídos nesta descrição, estejam dentro do escopo da presente divulgação, e sejam protegidos pelas reivindicações anexas.

BREVE DESCRIÇÃO DOS DESENHOS

[0021] Os aspectos da presente divulgação são ilustrados a título de exemplo e não estão limitados às figuras anexas.

[0022] A figura 1 é um diagrama de bloco ilustrando siste- mas/métodos de processamento de cartão incluindo um cartão, um ponto de terminal de venda e um emissor do cartão.

[0023] A figura 2 é um diagrama de bloco ilustrando siste- mas/métodos de processamento de cartão incluindo um cartão em um terminal de usuário, um ponto de terminal de venda e um emissor do cartão.

[0024] A figura 3 é um diagrama de bloco ilustrando a geração de um criptograma de transação por um cartão.

[0025] A figura 4 é um diagrama ilustrando a autenticação de uma transação com cartão.

[0026] As figuras 5 e 6 são fluxogramas ilustrando siste- mas/métodos de acordo com as várias modalidades.

[0027] A figura 7 é um diagrama de bloco de um terminal de usuário de acordo com algumas modalidades.

[0028] A figura 8 é um diagrama de bloco ilustrando um servidor de provisionamento de acordo com algumas modalidades.

[0029] A figura 9 é um fluxograma ilustrando sistemas/métodos de provisionamento de acordo com várias modalidades.

[0030] A figura 10 é um fluxograma ilustrando operações para gerar uma chave de sessão camuflada de acordo com algumas modalidades.

DESCRIÇÃO DETALHADA

[0031] As modalidades da presente divulgação serão descritas mais totalmente a seguir com referência aos desenhos anexos. Outras modalidades podem tomar muitas formas diferentes e não devem ser interpretadas como limitadas às modalidades descritas no presente documento. Números iguais referem-se a elementos completamente iguais.

[0032] Nos últimos anos, o consórcio EMV projetou uma solução de pagamento pela qual os dados e algoritmos do cartão podem ser armazenados em um terminal de usuário, tal como um dispositivo móvel, em vez de em um cartão. Neste contexto, o terminal de usuário pode incluir um dispositivo móvel, tal como um telefone móvel, telefone inteligente, tablet, laptop, assistente digital pessoal (PDA) ou qualquer outro dispositivo de computação móvel. No entanto, o termo "terminal de usuário" não é limitado a dispositivos de computação móveis ou sem fio. A credencial de pagamento no dispositivo móvel pode ser ainda denominada um "cartão" para conveniência.

[0033] Para simplicidade, a seguinte discussão será limitada a uma descrição do ponto de compras de venda. No entanto, a descrição é igualmente aplicável a transações de ATM ou similares.

[0034] Com referência à figura 1, durante a compra com cartão, um cartão 10 troca uma pluralidade de manganês com um terminal (POS) de ponto de venda 20 através de um link de comunicação 12. O cartão 10 e o terminal (POS) 20 negociam se a transação será realizada, e em caso afirmativo, como ela será realizada. A informação recebida pelo terminal POS 20 pode ser usada para verificar a transação com o emissor do cartão 30.

[0035] O cartão 10 pode ser um cartão EMV, isto é, qualquer cartão que cumpre com os padrões EMV, ou outra tecnologia similar, ou qualquer outro cartão que inclui um processador e memória.

[0036] Para se comunicar com um terminal POS do comerciante, um terminal de usuário pode usar comunicações de campo próximas (NPC) em vez do contato elétrico físico usado para um cartão. A comunicação de campo próxima (NPC) é um conjunto de padrões que possibilitam uma faixa curta, comunicação sem fio bidirecional entre dispositivos par tocar os mesmos juntos ou trazer os mesmos em estreita proximidade, geralmente não mais do que algumas polegadas. Os padrões NFC cobrem os protocolos de comunicações e os forma- tos de troca de dados e são baseados em padrões de identificação de frequência de rádio (RFID) existentes.

[0037] Com referência à figura 2, um terminal de usuário 100 pode incluir credenciais de pagamento eletrônico, isto é, um "cartão" 110 armazenado em uma memória do terminal 100, e um módulo NFC 115. O módulo NFC pode incluir um transceptor e software e/ou firm-ware associado que possibilita que o terminal de usuário 100 engate em comunicações NFC. Para usar o terminal de usuário 100 possibilitado por NFC para conduzir uma transação, o dispositivo móvel 100 pode ser colocado contra (ou próximo a) ao terminal POS 20 durante vários segundos, durante esse tempo um caminho de comunicação sem fio 112 é estabelecido entre o dispositivo móvel 100 e o terminal POS 20. A transação pode ser negociada entre o cartão 110 e o terminal POS usando o caminho de comunicação sem fio 112.

[0038] Outros tipos de protocolos de comunicação sem fio, tais como Bluetooth e Wi-Fi podem ser usados para estabelecer o caminho de comunicação sem fio 112;

[0039] Como mencionado acima, as credenciais de pagamento e-letrônico no cartão 110 podem incluir chaves criptográficas que são usadas para dados de transação assinado digitalmente para fins de verifícação/autenticação. Para fins de segurança, não é geralmente desejável armazenar este dado sensível em uma memória normal que pode ser submetida a adulteração ou hacker. Em vez disso, os cartões são tipicamente armazenados em um "Elemento Seguro" (SE), que é um chip resistente a adulteração que proporciona armazenagem de dados segunda junto com um microprocessador criptográfico para facilitar a autenticação e segurança da transação, e proporciona memória segura para armazenas aplicações de pagamento. As aplicações de pagamento também podem funcionar no Elemento Seguro.

[0040] No entanto, pode ser pouco prático ou de outro modo inde- sejável para incluir ou usar um Elemento Seguro em um dispositivo móvel. Isto leva a um problema potencial, em que uma chave criptográfica armazenada em um dispositivo móvel pode ser comprometida se o dispositivo móvel é perdido ou furtado. Algumas modalidades proporcionam métodos para gerar, armazenar e/ou usar chaves criptografias de tal modo que elas são menos prováveis de ser comprometidas mesmo se não são armazenadas em um Elemento Seguro ou ambiente similar.

[0041] Algumas modalidades são descritas no presente documento no contexto de uma transação de pagamento compatíveis com EMV em um terminal (POS) de ponto de venda do comerciante usando comunicações de campo próximas (NFC). No entanto, será apreciado que as modalidades descritas no presente documento podem ser usadas em conexão com transações ATM, transações de quiosque abandonado ou de máquina de venda, e outras transações similares. Além do mais, existem muitas variações de protocolo em transações EMV para NFC. As modalidades descritas no presente documento podem ser empregadas com outros protocolos ou padrões.

[0042] Além do mais, embora descrito em conjunto com dispositivos móveis que são configurados para se comunicar através de interface sem fio, será apreciado que algumas modalidades podem ser a-plicáveis a outros tipos de terminais de usuário. Um terminal de usuário pode incluir qualquer dispositivo de computação.

[0043] Com referência novamente à figura 2, para conduzir uma transação, um usuário pode selecionar um cartão 110 dentre a pluralidade de cartões armazenados em um terminal de usuário 100. O cliente pode então reter o terminal de usuário 100 próximo ao terminal POS 20 do comerciante. O terminal POS 20 e o terminal de usuário 100 iniciam uma sessão onde eles se comunicam através de uma interface de NFC 112. O cartão 110 e o terminal POS 20 trocam mensagens de acordo com o protocolo EMV. Incluídos nestas mensagens estão dados de identificação do cartão (dados do cartão), dados de identificação de terminal (dados de terminal), outros dados de transação, e saída de dados por algoritmos de transação funcionando no terminal POS 20 e no cartão 110. Os dados do cartão podem incluir, por exemplo, o Número de Contas Primário (PAN) do cartão 110, o nome do titular do cartão, dados de validade, etc. O dados de terminal podem incluir um código do país do terminal, etc. Os outros dados de transação podem incluir a data, tipo de transação, quantidade de transação, etc. Os dados do cartão, os dados de terminal e/ou os outros dados de transação, ou quaisquer porções destes itens, podem ser referidos geralmente como "dados de transação".

[0044] Ao usar os dados de transação, o cartão 110 e o terminal POS 20 negociam o modo no qual a transação irá prosseguir. O terminal POS 20 pode usar os dados de transação para autorizar a transação com o emissor do cartão 30.

[0045] Com referência à figura 3, no processo de conduzir a transação, o cartão 110 pode gerar um criptograma 126, que é uma mensagem criptografada que é uma forma de resumo de transação que pode ser usada para autenticar a transação para o emissor do cartão 30. O criptograma é gerado codificando os dados de transação 122 usado uma chave criptográfica 120 armazenada no terminal de usuário 100.

[0046] As chaves criptográficas, ou "chaves financeiras", podem incluir, em algumas modalidades, chaves da forma: uma chave simétrica (tal como uma chave 3DES ou um Padrão de Criptografia Avançado (chave AES), um segredo, uma matriz de byte secreta, uma semente, e/ou um dado controlado.

[0047] Para geração do criptograma, versões anteriores de EMV usaram uma chave financeira única, ou chave de criptograma (CK), que é uma chave de 16 bytes (composta de duas chaves DES). Os dados relevantes são combinados, com hash e criptografados usando a CK, para formar o criptograma.

[0048] As versões posteriores de EMV usam um "Aplicativo de Chave Mestre de Criptograma" (MK) de 16 bytes e a partir das quais geram uma "Aplicativo de Chave de Sessão de Criptograma" (SK) de 16 bytes, para cada transação. A chave de sessão é um item secreto que é armazenado no cartão. A chave de sessão, que é diferente para cada transação, é usada para gerar um criptograma em muito do mesmo modo como a CK original que foi usada. Existem vários algoritmos diferentes em uso para gerar uma chave de sessão a partir de uma chave mestre.

[0049] Um criptograma é tipicamente um valor de 8 bytes que pode ser entendido como uma assinatura nos dados de transação. O cartão 110 gera o criptograma ao codificar os dados de transação 122 com a chave criptográfica 120 usando uma função de hash que toma os dados de transação e a chave criptográfica como entradas e gera o criptograma como uma saída. A função de hash usada para gerar o criptograma em uma função matemática de um sentido. Isto é, a chave criptográfica e os dados de transação não podem ser recuperados a partir do criptograma. Também, o criptograma é único para os dados de transação particulares e chave criptográfica que são usados.

[0050] Assim, presumindo que o emissor do cartão 30 conhece a chave criptográfica usada pelo cartão 110, uma vez que o emissor do cartão 30 forneceu os dados de transação pelo terminal POS 20, o e-missor do cartão pode verificar que o cartão 110 gerou o criptograma gerando o criptograma a partir dos dados de transação usando a chave criptográfica conhecida e comparando o mesmo ao criptograma que foi gerado pelo cartão 110.

[0051] Com referência agora à figura 4, para conduzir uma transa- ção, um cartão 110 e um terminal POS podem trocar dados de transação em uma série de mensagens 201. O cartão 110 pode então gerar um criptograma a partir dos dados de transação usando a chave criptográfica armazenada (bloco 202). O cartão 110 transmite o criptograma ao terminal POS 20 através de um link de NFC em uma mensagem 203. Para autenticar a transação, o terminal POS 20 pode então transmitir o criptograma e os dados de transação ao emissor do cartão 30 em uma mensagem 205.

[0052] O emissor do cartão pode verificar o criptograma gerando um criptograma experimental usando os dados de transação providos pelo terminal POS 20 e sua cópia armazenada ou regenerada da chave de criptograma (bloco 206). Baseado no resultado do processo de verificação, o emissor do cartão irá prover uma resposta de autenticação 207 ao terminal POS 20.

[0053] Como indicado acima, as chaves criptográficas podem ser armazenadas em um Ambiente Seguro (SE). O Ambiente Seguro pode ser protegido por um Número de Identificação Pessoal (PIN). Assim, quando o usuário abre o aplicativo de pagamento no terminal de usuário 100, o usuário deve introduzir um PIN, que é checado pelo Ambiente Seguro antes de ser dado acesso aos cartões armazenados no terminal de usuário. O usuário então escolhe um cartão e executa a transação. As chaves criptográficas nunca devem deixar o Ambiente Seguro. Se um ladrão furta um tutu do usuário, o ladrão não pode usar os cartões sem conhecer o PIN. Se o atacante tenta um ataque com "força bruta" experimentando todos os PINs possíveis um após o outro, o atacante geralmente irá falhar, porque o Ambiente Seguro irá travar após um número pré-fixado de tentativas falhadas.

[0054] As comunicações de NFC não são tipicamente criptografadas. Embora seja pretendido que a comunicação de NFC ocorra através de distâncias pequenas de vários centímetros em torno, é possível ler este tráfego através de distâncias maiores usando um receptor sensível. No entanto, mesmo se um atacante intercepta as mensagens de protocolo de EMV contendo dados de transação, o atacante não será capaz de deduzir os valores das chaves criptográficas a partir do criptograma e dos dados de transação.

[0055] Muitos terminais de usuário não têm um Ambiente Seguro. Além do mais, mesmo nos terminais de usuário que incluem um Ambiente Seguro, pode não ser desejável ou possível para uma dada aplicação usar o Ambiente Seguro porque o acesso ao Ambiente Seguro pode ser restrito, por exemplo, pelo sistema de operação do terminal de usuário, pelos fabricantes ou pelo provedor de serviço sem fio.

[0056] Assim, pode ser desejável armazenar os dados do cartão, incluindo chaves criptográficas, em espaço de armazenamento de a-plicação normal em um terminal de usuário. Isto cria um problema, no entanto, no evento do terminal de usuário ser perdido ou furtado, como pode ser geralmente possível (embora difícil) ler o dados do cartão no terminal de usuário.

[0057] Supõe-se, por exemplo, que as chaves financeiras (e outros dados o cartão) foram criptografadas usando um PIN, e armazenadas em memória de aplicativo. Um atacante de posse do terminal de usuário pode instituir um ataque com força bruta contra os dados. Em um ataque com força bruta, um atacante pode tentar cada PIN possível por sua vez até os dados bem formados serem revelados, com nenhum erro relatado.

[0058] Outra forma de proteção da chave financeira (CK ou MK) foi desenvolvida que usa camuflagem criptográfica como descrito, por e-xemplo, na Publicação US n2 2011/0060913, a divulgação da qual é incorporada no presente documento por referência.

[0059] Essencialmente, a camuflagem criptográfica que opera crip-tografando cuidadosamente a chave financeira em um modo que de- codifica a chave com qualquer PIN possível irá revelar uma chave de bloqueio válida, com nenhum relato de erro. Somente tentando uma transação um atacante irá descobrir se o PIN correto foi adivinhado; O emissor do cartão pode bloquear a conta após um número pré-fixado de tentativas, assim anulando o ataque com força bruta.

[0060] No entanto, existe outro ataque que pode derrotar este mecanismo de proteção no contexto de comunicação sem contato (sem fio) entre o terminal de usuário e o terminal POS. Se um atacante grava a troca sem fio entre o terminal de usuário e o terminal POS, e então, subsequentemente, ganha acesso ao terminal de usuário, o atacante estará de posse dos dados de transação e do criptograma a partir da troca de NFC e também estará de posse das chaves camufladas no telefone.

[0061] O atacante pode então testar um ataque com força bruta em que, para cada PIN possível, o atacante descamufla a chave criptográfica, gera um criptograma experimental a partir dos dados de transação, e compara o criptograma experimental ao criptograma atual capturado a partir da troca de NFC. Se o criptograma experimental e o criptograma atual combinam, o atacante sabe qual o PIN correto e, portanto, a chave criptográfica correta foi descoberta.

[0062] Algoritmos do tipo de EMV anteriores para gerar um criptograma usaram a chave criptográfica CK diretamente para criptografar alguns dados e produzir o criptograma. Recentemente, algoritmos mais elaborados foram projetados que não usam a chave criptográfica diretamente. Preferivelmente, a chave criptográfica é tratada como uma "Chave Mestre" (MK), e para cada transação uma "Chave de Sessão" (SK) é gerada a partir da Chave Mestre. A Chave de Sessão é usada no algoritmo de geração do criptograma.

[0063] O algoritmo de EMV denominado "CSK" foi adaptado por várias especificações de cartão importantes para a geração de chaves de sessão a partir da chave mestre. O algoritmo CSK de EMV toma a chave mestre MK e um contador de transação, tal como o Contador de Transação para Aplicação definida por EMV (ATC), como entradas e gera uma chave de sessão SK como uma saída construindo várias sequências de bytes e criptografando as mesmas com a chave mestre, e então escolher certos bytes de saída para se tornar a chave de sessão. O ATC é um contador que é mantido tanto pelo terminal de usuário como pelo emissor do cartão para rastrear o número de transações iniciado pelo terminal de usuário. Em particular, o ATC é um contador que começa em zero e é incrementado uma vez para cada transação. O ATC é armazenado em 2 bytes, e assim suporta 65.536 compras (embora EMV suporte reinicializar o ATC através de um procedimento autenticado envolvendo uma chave financeira diferente. Assim, cada chave de sessão é associada com um valor único do ATC. Outro contador de transação pode ser usado em vez do ATC definido por EMV.

[0064] O ataque de intercepção de protocolo passivo descrito acima trabalha independente de se o cartão usa uma chave criptográfica única, ou usa a chave de sessão alternativa. No caso de chaves de sessão, o atacante pode descamuflar a mestre e usar a mesma para gerar a(s) chave(s) de sessão, que são usadas por sua vez para gerar criptogramas experimentais como acima.

[0065] Algumas modalidades proporcionam uma abordagem que pode superar os interesses de segurança através do armazenamento de dados do cartão, incluindo chaves criptográficas, em um terminal de usuário. De acordo com algumas modalidades, as chaves criptográficas podem ser protegidas no dispositivo, em software, em um modo que diminui a possibilidade de que as chaves financeiras possam ser comprometidas, mesmo se o terminal de usuário for furtado.

[0066] De acordo com algumas modalidades, uma chave criptográfica mestre e um contador de transação são proporcionados. Uma pluralidade de chaves criptográficas de sessão é gerada a partir da chave criptográfica mestre e uma respectiva pluralidade de valores possíveis do contador de transação. As chaves criptográficas de sessão são criptografadas para prover uma pluralidade de chaves criptográficas de sessão criptografada, que são armazenadas no terminal de usuário. A chave criptográfica mestre é então deletada a partir do terminal de usuário.

[0067] Durante a transação, um criptograma é gerado baseado em uma das chaves criptográficas de sessão criptografada e nos dados de transação para a transação. O criptograma é transmitido ao terminal de transação. O contador de transação é atualizado, e a chave criptográfica de sessão criptografada é deletada a partir do terminal de usuário. Assim, mesmo se um atacante intercepta os dados de transação e o criptograma a partir de uma comunicação de NFC, nem a chave de sessão usada para formar o criptograma, nem a chave mestre usada para gerar a chave de sessão pode ser obtida a partir do terminal de usuário.

[0068] Como um exemplo, com referência às figuras 2 e 5, uma chave mestre é provida (bloco 302). Por exemplo, em algumas modalidades, um usuário pode fazer download de dados de cartão para um cartão 110 incluindo uma chave mestre em um terminal de usuário 100. Em outras modalidades, uma chave mestre pode ser provida em um servidor de provisionamento operado pelo emissor do cartão.

[0069] De acordo com algumas modalidades, o servidor de provisionamento ou o terminal de usuário 100 itera através de um número de valores possíveis do contador de transação (possivelmente incluindo todos os valores possíveis do ATC) e gera um número de chaves de sessão usando os valores de contador de transação e a chave mestre (bloco 304). Em algumas modalidades, as chaves de sessão podem ser pré-geradas, por exemplo, por um servidor de provisiona- mento operado pelo emissor do cartão 30 e, subsequentemente, providas ao terminal de usuário 100. Assim, o terminal de usuário 100 não precisa atualmente gerar as chaves de sessão, e a chave mestre não pode ser armazenada no terminal de usuário 100, deste modo aumentando a segurança da chave mestre.

[0070] As chaves de sessão geradas deste modo podem ser armazenadas no terminal de usuário na memória de aplicativo regular. As chaves de sessão podem ocupar muito pouca memória em relação à quantidade de memória disponível nos dispositivos modernos. Por exemplo, 365 chaves de sessão podem ocupar somente cerca de 6 kilobytes de memória. Além do mais, devido a energia de processamento disponível para os dispositivos de computação modernos, o tempo requerido para gerar as chaves de sessão pode ser insignificante. Assim, o cartão 110 pode, em algumas modalidades, gerar um número de chaves de sessão que são esperadas ser usadas no tempo de duração do cartão 110. Em alguns casos, um número de chaves de sessão igual ao número possível total de valores de ATC (por exemplo, 65.536 chaves de sessão) pode ser gerado e armazenado no terminal de usuário 100. As chaves de sessão podem ser armazenadas em uma memória regular do terminal de usuário 100 ou, se estiver disponível, em uma memória segura do terminal de usuário 100. Este número de chaves de sessão pode ocupar cerca de 1 MB de memória no terminal de usuário.

[0071] Em algumas modalidades, nenhuma chave de sessão pode ser armazenada no terminal de usuário, e um usuário pode se conectar a um servidor de provisionamento e adquirir uma chave de sessão como necessário (tanto recebendo a chave mestre temporariamente como tendo o servidor de provisionamento gerado a chave de sessão)l e deletar a chave de sessão imediatamente depois. Notar que isto pode requerer que o usuário esteja online no momento da transação. Es- ta abordagem pode derrotar o ataque de intercepção de mensagem de protocolo também para o método de CK fixo mais antigo que não usa nenhuma chave de sessão.

[0072] O ATC é armazenado em 2 bytes. No entanto, os padrões EMV incluem reiniciar ou "rolar" o ATC após o valor máximo ser alcançado. Neste evento, o suprimento de SKs pode ser reabastecido u-sando um dos métodos acima.

[0073] As novas chaves de sessão podem ser opcionalmente camufladas no modo descrito na Publicação US n- 2011/0060913 referenciada acima (bloco 306). Em particular, as chaves de sessão podem ser camufladas como descrito em mais detalhe abaixo.

[0074] O terminal de usuário então deleta a chave mestre (bloco 308) se ela foi provida ao terminal de usuário.

[0075] Neste ponto, o terminal de usuário armazena (possivelmente em camuflagem) um número de chaves de sessão que podem ser usadas em transações com valores de contador de transação associados.

[0076] Operações para conduzir uma transação são ilustradas nas figuras 2 e 6. Como mostrado ali, quando o usuário deseja conduzir uma transação e introduz o PIN apropriado, o terminal de usuário 100 seleciona uma chave de sessão correta dentre as chaves de sessão pré-armazenadas baseado no valor atual do contador de transação, descamufla a chave de sessão como necessário e usa a chave de sessão para conduzir a transação com um terminal POS 20 (bloco 320).

[0077] Após a transação, o terminal de usuário deleta a chave de sessão (bloco 332) e atualiza o contador de transação (bloco 324). A chave mestre e a chave de sessão usadas podem ser deletadas usando um protocolo que torna a chave de sessão incapaz de ser recuperada a partir do terminal de usuário. Por exemplo, a chave de sessão pode ser apagadas usando técnicas de apagar dados seguras bem conhecidas em que dados pseudo-aleatórios são repetidamente so-brescritos no local de memória físico em que a chave de sessão é armazenada.

[0078] Esta abordagem pode ser altamente resistente à intercepção de protocolo passiva/ ataque com força bruta descrito acima, uma vez que atacante não pode usar PINs experimentais para reproduzir a chave de sessão correspondendo a uma transação anterior. Isto é, devido a chave mestre e a chave de sessão usada terem sido apagadas, elas não estão disponíveis para o atacante usar em uma tentativa de recriar o criptograma e recuperar o PIN. Além do mais, devido as chaves de sessão restantes estarem camufladas, o atacante não pode a-divinhar seguramente as chaves de sessão restantes, mesmo se o a-tacante tiver conhecimento dos dados de transação e do criptograma usados para uma transação anterior.

[0079] Em algumas modalidades, o emissor do cartão pode pré-gerar as chaves de sessão e prover os mesmos ao terminal de usuário. Qualquer número de chaves de sessão pode ser pré-gerado desta forma. Por exemplo, em algumas modalidades um número de tempos de duração de chaves de sessão pode ser pré-gerado. Em outras modalidades, um número de chaves de sessão correspondendo ao número de valores possíveis do contador de transação pode ser pré-gerado. Ainda em outras modalidades, um número limitado de chaves de sessão pode ser pré-gerado, e chaves de sessão adicionais podem ser providos ao terminal de usuário em um tempo de duração tanto provendo as chaves de sessão ao terminal de usuário diretamente ou provendo a chave mestre (ou uma nova chave mestre) ao terminal de usuário e deixando o terminal de usuário gerar mais chaves de sessão a partir da chave mestre.

[0080] As chaves de sessão podem ser derivadas em qualquer tempo antes da transação em que elas são usadas. Isto é, qualquer algoritmo em que o algoritmo de geração de chaves de sessão toma a chave mestre e outros dados de entrada podem ser derivados antes da transação atual contanto que a chave mestre e os outros dados de entrada sejam conhecidos. As chaves de sessão podem, portanto, ser geradas quando o terminal de usuário é provido originalmente. No entanto, qualquer abordagem que não gera todas as chaves de sessão no momento do provisionamento pode envolver manter a chave mestre no servidor de provisionamento, ou prover acesso à mesma.

[0081] A figura 7 é um diagrama de bloco d um terminal de usuário 100 de acordo com algumas modalidades. O terminal de usuário 100 inclui um processador 105, e uma memória 130 e módulo de comunicação 140 acoplados ao processador. A memória 130 armazena o cartão 110 bem como rotinas de processamento que configuram o processador para realizar as operações descritas acima em conexão com as figuras 4 a 6. O módulo de comunicação 140 pode incluir um módulo de comunicação de campo próximo (NFC) 115 que possibilita o terminal de usuário 100 comunicar-se com o terminal POS 20 através do caminho de comunicação sem fio 112 mostrado na figura 2. O módulo de NFC pode incluir um transceptor e software e/ou firmware associado que possibilita o terminal de usuário 100 engatar-se nas comunicações de NFC.

[0082] A figura 8 é um diagrama de bloco de um servidor de provisionamento 400 que pode ser operado, por exemplo, por um emissor do cartão. Algumas operações descritas no presente documento podem ser realizadas pelo servidor de provisionamento 400 quando um cartão é ativado/emitido. Por exemplo, o servidor de provisionamento 400 pode gerar chaves de sessão para ser usadas por um terminal de usuário e transmitir as chaves de sessão ao terminal de usuário. O servidor de provisionamento 400 inclui um processador 412, uma me- mória 414 e um módulo de comunicação 416. O módulo de comunicação 416 pode incluir um transceptor e software/firmware associado que possibilita o servidor de provisionamento 400 a se comunicar com o terminal de usuário 100 através de um link de comunicação 410 que pode incluir, por exemplo, uma rede de comunicação de dados comutados ao pacote, tal como a Internet. A memória 414 pode armazenar rotinas que possibilitam o processador 412 gerar chaves de sessão para o terminal de usuário 100, que podem ser providas ao terminal de usuário 100 através do link de comunicação 410.

[0083] Por exemplo, o servidor de provisionamento pode ser configurado para realizar as operações mostradas na figura 9. Como mostrado ali, quando um cartão 110 é baixado para um terminal de usuário 100 (ver figura 2), ou subsequentemente quando um cartão 110 deve ser atualizado com novas chaves de sessão, o servidor de provisionamento é provido com dados de cartão para o cartão, incluindo uma chave mestre (bloco 452). A chave mestre pode ser uma chave mestre que foi previamente usada para gerar chaves de sessão para o cartão 110, ou pode ser uma nova chave mestre.

[0084] O servidor de provisionamento 400 gera chaves de sessão a partir da chave mestre e de valores possíveis de um contador de transação mantido tanto pelo terminal de usuário 100 como pelo emissor do cartão (bloco 452). O servidor de provisionamento 400 então provê as chaves de sessão geradas ao terminal de usuário 100, por exemplo, através do link de comunicação 410 (bloco 456).

[0085] O servidor de provisionamento 400 pode ser ainda configurado para gerar chaves criptográficas de sessão e transmitir as chaves criptográficas de sessão criptografada adicionais ao terminal de usuário quando o suprimento de chaves criptográficas de sessão no terminal de usuário é reduzido para um nível predeterminado, tal como, por exemplo, para menos do que dez por cento do número original de chaves criptográficas de sessão armazenadas no terminal de usuário.

[0086] A camuflagem das chaves de sessão será agora descrita em mais detalhe. Uma chave de sessão de 16 bytes única é composta internamente de duas chaves DES de 8 bytes. Cada byte de uma chave DES consiste de 7 bits mais ou menos aleatórios, mais um bit de "paridade" que funciona como um tipo de soma de verificação, e é geralmente ignorado. O bit de paridade em cada byte deve ser aleatório, embora a maioria dos algoritmos do tipo CSK não irá fixar os bits de paridade de modo algum, e deixarão os mesmos em um estado pseu-do-aleatório, caso em que nada precisa ser feito. A pode ser criptografada usando um PIN de modo que qualquer decodificação sob qualquer PIN experimental irá produzir uma chave de sessão parecendo válida (isto é, nenhum teste pode provar que a chave de sessão decodificada é inválida). Um modo possível de camuflar a chave de sessão é introduzir o PIN a uma função de geração de máscara e produzir máscara de 16 bytes que é então XOR-ed com chave de sessão.

[0087] A figura 10 ilustra um método 500 para camuflar criptografi-camente uma chave de sessão baseado na figura 2 da Publicação US n- 2011/0060913 referenciada acima. Uma chave de sessão SK de EMV única de 16 bytes é de fato composta de duas chaves DES de 8 bytes. Para camuflar uma chave de sessão é suficiente camuflar cada chave DES e, consequentemente, a seguinte discussão descreve como uma chave DES única pode ser camuflada. No bloco 505, uma chave simétrica é provida para um processo de camuflagem. Nas modalidades ilustradas na figura 10, a chave provida no bloco 505 pode ser de qualquer tipo de chave simétrica, por exemplo, a chave pode ser uma chave Padrão de Criptografia de Dados (DES) que é provida para camuflagem sob um PIN. A chave DES é de 8 bytes de tamanho. Em cada byte, 2 a 8 bits são aleatórios e o primeiro bit é um bit de paridade que é a paridade de 2 a 8 bits. No bloco 510, o bit de paridade em cada byte de chave DES 505 é aleatório, para produzir uma chave modificada no bloco 520. Um PIN é provido no bloco 530, e a chave modificada é criptografa no bloco 540 usando o PIN, para prover uma chave camuflada no bloco 550.

[0088] O método de criptografia usado no bloco 540 pode ser um de vários métodos. A título de exemplo não limitante, três métodos possíveis 540A, 540B, 540C são mostrados na figura 10. O método 540A usa uma Função de Geração de Máscara, tal como MGF1 a partir do padrão PKS #1, para criar uma máscara a partir de PIN 530 e a máscara de XOR (OR exclusivo) com a chave modificada para prover uma chave camuflada no bloco 550. O método 540B criptografa a chave modificada com uma nova chave derivada do PIN para prover uma chave camuflada no bloco 550. Ao usar o método 540B, nenhum preenchimento ou outra informação deve ser armazenada que possa ajudar um intruso a reconhecer uma tentativa de decodificação falhada com um PIN errado, por exemplo, um PIN que não o PIN provido no bloco 530. Embora alguns métodos possíveis sejam descritos no presente documento para criptografar ou ofuscar uma chave modificada para prover uma chave camuflada, é entendido que vários métodos e modalidades alternativos podem ser empregados para criptografar uma chave modificada para prover uma chave camuflada.

[0089] Notar que um atacante usando um ataque com força bruta com todos os PINs possíveis, e com conhecimento total do algoritmo de camuflagem usado no bloco 540, irá produzir sempre uma chave DES validamente camuflada, exceto para os bits de paridade. O atacante não tem nenhum meio de reconhecimento quando o PIN correto foi usado. De acordo com algumas modalidades, a estrutura, se alguma, deve ser removida a partir do dado a ser criptografado/ ofuscado. Isto se aplica aos bits de paridade, no caso de chaves DES, como descrito para a modalidade mostrada na figura 10. No entanto, é en- tendido que uma técnica de camuflagem baseada no método descrito na figura 10, por exemplo, uma combinação de modificar uma chave e criptografar ou ofuscar a chave modificada usando um PIN pode ser usada para qualquer outra chave simétrica padrão, por exemplo, uma chave de Padrão de Criptografia Avançado (AES).

[0090] Como descrito acima, o mecanismo de geração de chave de sessão criptográfica (CSK) de EMV usa uma chave mestre e o Contador de Transação de Aplicativo para gerar uma chave de sessão para uma transação. Alguns algoritmos de geração de chave de sessão também tomam um "Número Imprevisível" (UN) como uma entrada. O UN são vários bytes de dados mais ou menos aleatórios que chegam do terminal do comerciante e devem ser incluídos nos dados de transação usados para o criptograma. Versões de protocolo diferentes usam um UN de tamanho diferente. Além disso, é possível que outros dados, além de, ou em vez do UN possam ser necessários para formar a chave de sessão, mas não conhecidos até o momento da transação.

[0091] Uma vez que UN não é conhecido até o momento da transação, algumas modalidades pré-geram uma chave de sessão para cada UN potencial possível para cada valor possível do contador de transação. O número de transações futuras (valores ATC) suportadas em uma sessão de pré-geração pode ser escolhido apropriadamente baseado nos recursos de computação e/ou armazenamento disponíveis. Por exemplo, para um UN de 2 bytes é possível pré-gerar chaves de sessão para 365 valores ATC em 15 minutos, requerendo 360 MB de armazenamento.

[0092] Como indicado acima, todas as marcas de cartão principais desenvolvem implementações de especificação de EMV. Por exemplo, uma versão MasterCard recente de "PayPass" para pagamentos de NFC móveis usando suas especificações "M/Chip" descreve dois algo- ritmos de geração de SK: um SKD proprietário, e os mecanismos CSK de EMV. O mecanismo de SKD mais antigo toma os MK, ATC e UN como entradas.

[0093] As especificações PayPass também descrevem o mecanismo EMV 2000 para gerar chaves de sessão correspondendo a uma chave mestre financeira diferente (não para gerar criptogramas). Embora a presente discussão tenha focalizado a chave de criptograma, os métodos descritos no presente documento de pré-gerar e camuflar chaves de sessão podem ser aplicáveis neste cenário também.

[0094] Mais geralmente, os sistemas/métodos para pré-gerar e camuflar chaves de sessão podem ser aplicados a muitos sistemas de pagamento com cartão onde os dados do cartão e os algoritmos são armazenados em um dispositivo, e não devem ser considerados limitados aos exemplos específicos descritos no presente documento.

[0095] Como será apreciado por um perito na técnica, os aspectos da presente divulgação podem ser ilustrados e descritos no presente documento em qualquer um de um número de classes patenteáveis ou contexto incluindo qualquer processo novo e útil, máquina, fabricação, ou composição de matéria, ou qualquer melhora nova e útil dos mesmos. Consequentemente, os aspectos da presente divulgação podem ser implementados totalmente em hardware, totalmente em software (incluindo firmware, software residente, microcódigo, etc.) ou combinando implementação de software e hardware que pode ser tudo geralmente referido no presente documento como um "circuito", "módulo", "componente" ou "sistema". Além disso, os aspectos da presente divulgação podem tomar a forma de um produto de programa de computador incorporado em um ou mais meios legíveis por computador tendo código de programa legível por computador incorporado nos mesmos.

[0096] Qualquer combinação de um ou mais meios legíveis por computador pode ser utilizada. Os meios legíveis por computador podem ser um meio de sinal legível por computador ou um meio de armazenamento legível por computador. Um meio de armazenamento legível por computador pode ser, por exemplo, mas não limitado a sistema, aparelho ou dispositivo eletrônico, magnético, ótico, eletromagnético ou semicondutor, ou qualquer combinação apropriada dos acima. Exemplos mais específicos (uma lista não exaustiva) do meio de armazenamento legível por computador podem incluir o seguinte: um disquete de computador portátil, um disco rígido, uma memória de a-cesso aleatório (RAM), uma memória somente de leitura (ROM), uma memória somente de leitura programável que pode ser apagada (E-PROM ou memória Flash), uma fibra ótica apropriada com um repetidor de armazenamento temporário, uma memória somente de leitura de disco compacto portátil (CD-ROM), um dispositivo de armazenamento ótico, um dispositivo de armazenamento magnético, ou qualquer combinação apropriada do acima. No contexto deste documento, um meio de armazenamento legível por computador que pode conter, ou armazenar um programa para uso por ou em conexão com um sistema, aparelho ou dispositivo de execução de instruções.

[0097] Um meio de sinal legível por computador pode incluir um sinal de dados propagado com código de programa legível por computador incorporado no mesmo, por exemplo, na banda base ou como parte de uma onda de transporte. Tal sinal propagado pode tomar qualquer uma de uma variedade de formas, incluindo, mas não limitadas a eletromagnética, ótica ou qualquer combinação apropriada das mesmas. Um meio de sinal legível por computador pode ser qualquer meio legível por computador que não seja um meio de armazenamento legível por computador e que possa comunicar, propagar ou transportar um programa para uso por ou em conexão com um sistema, aparelho ou dispositivo de execução de instruções. O código de pro- grama incorporado em um meio de sinal legível por computador pode ser transmitido usando qualquer meio apropriado, incluindo, mas não limitado sem fio, com fio, cabo de fibra ótica, RF, etc., ou qualquer combinação apropriada do acima.

[0098] O código de programa de computador para transportar as operações para os aspectos da presente divulgação pode ser escrito em qualquer combinação de uma ou mais linguagens de programação, incluindo uma linguagem de programação orientada por objeto tal como JavaScript, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB, NET, Python ou semelhante, linguagens de programação de procedimento convencionais, tais como a linguagem de programação "C", Visual Basic, Fortran 2003, Perl, COBOL, 2002, PHP, ABAP, linguagens de programação dinâmicas tais como Python, Ruby e Groovy, ou outras linguagens de programação. O código de programa pode executar totalmente no computador do usuário, parcialmente no computador do usuário, como um pacote de software autônomo, parcialmente no computador do usuário e parcialmente em um computador remoto ou totalmente no computador remoto ou servidor. No último cenário, o computador remoto pode ser conectado ao computador do usuário a-través de qualquer tipo de rede, incluindo uma rede de área local (LAN) ou uma rede de área de longa distância (WAN), ou a conexão pode ser feita a um computador externo (por exemplo, através da Internet usando um Provedor de Serviço de Internet) ou em um ambiente de computação de nuvem ou ofertado como um serviço tal como um Software como um Serviço (SaaS).

[0099] Os aspectos da presente divulgação são descritos no presente documento com referência às ilustrações de fluxogramas e/ou diagramas de bloco de métodos, aparelhos (sistemas) e produtos de programa de computador de acordo com as modalidades da divulgação. Será entendido que cada bloco das ilustrações de fluxogramas e/ou diagramas de blocos, e combinações de blocos nas ilustrações de fluxogramas e/ou diagramas de bloco, podem ser implementados pelas instruções de programa de computador. Estas instruções de programa de computador podem ser providas a um processador de um computador para fim geral, computador para fim especial, ou outro aparelho de processamento de dados programáveis para produzir uma máquina, de modo que as instruções que executam através do processador do computador ou outro aparelho de execução de instruções programável, criam um mecanismo para implementar as fun-ções/ações especificadas no fluxograma e/ou em bloco ou blocos de diagramas de bloco.

[00100] Estas instruções de programa de computador também podem ser armazenadas em um meio de armazenamento legível por computador que quando executado pode direcionar um computador, outro aparelho de processamento de dados programável ou outros dispositivos para funcionar em um modo particular, de modo que as instruções quando armazenadas no meio de armazenamento legível por computador produzem um artigo de fabricação incluindo instruções que quando executadas fazem com que um computador implemente a função/ação especificado no fluxograma e/ou bloco ou blocos de diagramas de bloco. As instruções de programa de computador também podem ser carregadas em um computador, em outro aparelho de execução de instruções programável, ou em outros dispositivos para fazer com que uma série de etapas operacionais seja realizada no computador, outros aparelhos programáveis ou outros dispositivos para produzir um processo implementado por computador de modo que as instruções que executam no computador ou em outro aparelho programável proporcionam processos para implementar as funções/ações especificados no fluxograma e/ou bloco ou blocos de diagramas de bloco.

[00101] O fluxograma e os diagramas de bloco nas figuras ilustram a arquitetura, funcionalidade e operação de implementações de sistemas, métodos e produtos de programa de computador possíveis de acordo com vários aspectos da presente divulgação. A este respeito, cada bloco no fluxograma ou diagramas de bloco representam um módulo, segmento, ou porção de código, que compreende uma ou mais instruções executáveis para implementar a(s) função(ões) lógi-ca(s) especificada(s). Também deve ser notado que, em algumas implementações alternativas, as funções indicadas no bloco podem ocorrer fora da ordem indicada nas figuras. Por exemplo, dois blocos mostrados em sucessão podem, de fato, ser executados substancialmente concomitantemente, ou os blocos podem às vezes ser executados na ordem inversa, dependendo da funcionalidade envolvida. Também será notado que cada bloco dos diagramas de bloco e/ou ilustração de fluxograma, e combinações de blocos nos diagramas de bloco e/ou i-lustração de fluxograma, pode ser implementado por sistemas baseados em hardware para fim especial que realizam as funções ou ações especificadas, ou combinações de hardware para fim especial e instruções de computador.

[00102] A terminologia usada no presente documento é para o fim de descrever aspectos particulares somente e não se destinam a ser limitante da divulgação. Como usado no presente documento, as formas no singular "uma", "um" e "o" destinam-se a incluir as formas no plural também, a menos que o contexto indique claramente ao contrário. Será ainda entendido que os termos "compreende", "compreendendo", "inclui" e/ou "incluindo", quando usados no presente documento, especificam a presença de aspectos, números inteiros, etapas, o-perações, elementos e/ou componentes determinados, mas não excluem a presença ou adição de um ou mais outros aspectos, números inteiros, etapas, operações, elementos, componentes, e/ou grupos dos mesmos.

[00103] As estruturas, materiais, ações e equivalentes correspondentes de qualquer meio ou etapa mais elementos de função nas reivindicações abaixo são destinadas a incluir qualquer estrutura, material ou ação descrito para realizar a função em combinação com outros elementos reivindicados como especificamente reivindicado. A descrição da presente divulgação foi apresentada para fins de ilustração e descrição, mas não pretende ser exaustiva ou limitada à divulgação na forma divulgada. Muitas modificações e variações serão evidentes aos peritos na técnica sem sair do escopo e espírito da divulgação. Os aspectos da divulgação no presente documento foram escolhidos e descritos a fim de explicar melhor os princípios da divulgação e a aplicação prática, e para capacitar outros peritos na técnica a entender a divulgação com várias modificações como são apropriadas para o uso particular contemplado.

REIVINDICAÇÕES

Claims (23)

1. Método de assegurar uma transação entre um terminal de usuário e um terminal de transação caracterizado pelo fato de compreender: gerar uma pluralidade de chaves criptográficas de sessão a partir de uma chave criptográfica mestre e uma respectiva pluralidade de valores possíveis de um contador de transação; criptografar a pluralidade se chaves criptográficas de sessão para prover uma pluralidade de chaves criptográficas de sessão criptografada; armazenar a pluralidade de chaves criptográficas de sessão criptografada e uma da respectiva pluralidade de valores do contador de transação no terminal de usuário; gerar um criptograma baseado em uma primeira da pluralidade de chaves criptográficas de sessão criptografada e dados de transação para a transação; transmitir o criptograma ao terminal de transação; atualizar o contador de transação; e deletar uma primeira da pluralidade de chaves criptográficas de sessão criptografada a partir do terminal de usuário após gerar o criptograma.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que criptografar a pluralidade de chaves criptográficas de sessão compreende criptografar com um número de identificação pessoal.

3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que criptografar a pluralidade de chaves criptográficas de sessão compreende camuflar a pluralidade de chaves criptográficas de sessão.

4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que camuflar a pluralidade de chaves criptográficas de sessão compreende criptografar a pluralidade de chaves criptográficas de sessão de tal modo que decodificar qualquer uma da pluralidade de chaves criptográficas de sessão com um número de identificação pessoal incorreto produz uma chave criptográfica de sessão válida.

5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de compreender ainda prover a chave criptográfica mestre no terminal de usuário, e deletar a chave criptográfica mestre a partir do terminal de usuário após gerar a pluralidade de chaves criptográficas de sessão, em que após a deleção da chave criptográfica mestre a partir do terminal de usuário, não há nenhum dado restante no terminal de usuário que possa ser usado seguramente para decodificar as chaves criptográficas de sessão restantes usando os dados de transação e o criptograma.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de compreender ainda prover a chave criptográfica mestre no terminal de usuário, e deletar a chave criptográfica mestre a partir do terminal de usuário após gerar a pluralidade de chaves criptográficas de sessão.

7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de transmitir o criptograma compreende transmitir o criptograma ao terminal de transação usando um link de comunicação de campo próximo, um link de comunicação Bluetooth, um link de comunicação Wi-Fi, ou outro link de comunicação sem fio.

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o número de chaves criptográficas de sessão geradas compreende um número de valores possíveis do contador de transação.

9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o número de chaves criptográficas de sessão gera- das compreende menos do que um número de valores possíveis do contador de transação.

10. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a chave criptográfica mestre compreende uma pluralidade de chaves criptográficas.

11. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que gerar o criptograma compreende aplicar uma função de hash aos dados de transação e a uma primeira das chaves criptográficas de sessão criptografada.

12. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que atualizar o contador de transação compreende incrementar o contador de transação.

13. Terminal de usuário, caracterizado pelo fato de compreender: um processador; uma memória acoplada ao processador; e um módulo de comunicação acoplado ao processador; em que o processador é configurado para gerar uma pluralidade de chaves criptográficas de sessão a partir de uma chave criptográfica mestre e uma respectiva pluralidade de valores possíveis de um contador de transação, para codificar a pluralidade de chaves criptográficas de sessão para prover uma pluralidade de chaves criptográficas de sessão criptografada, para armazenar uma pluralidade de chaves criptográficas de sessão criptografada, para trocar os dados de transação referentes a uma transação proposta com um terminal de transação, para gerar um criptograma baseado em uma primeira pluralidade de chaves criptográficas de sessão criptografada e nos dados de transação, para transmitir o criptograma ao terminal de transação usando o módulo de comunicação, para atualizar o contador de transação, e para deletar a uma primeira da pluralidade de chaves cripto- gráficas de sessão criptografada a partir do terminal de usuário.

14. Terminal de usuário, de acordo com a reivindicação 13, caracterizado pelo fato de codificar as chaves criptográficas de sessão compreende codificar a pluralidade de chaves criptográficas de sessão com um número de identificação pessoal.

15. Terminal de usuário, de acordo com a reivindicação 14, caracterizado pelo fato de que o processador é configurado para camuflar a pluralidade de chaves criptográficas de sessão de tal modo que a decodificação de qualquer uma das chaves criptográficas de sessão criptografada com um número de identificação pessoal incorreto produz uma chave criptográfica de sessão válida.

16. Terminal de usuário, de acordo com a reivindicação 13, caracterizado em que o número de chaves criptográficas de sessão geradas compreende um número de valores possíveis do contador de transação.

17. Servidor de provisionamento, caracterizado pelo fato de compreender: um processador; uma memória acoplada ao processador; e um módulo de comunicação acoplado ao processador; em que o processador é configurado para gerar uma pluralidade de chaves criptográficas de sessão a partir de uma chave criptográfica mestre e uma respectiva pluralidade de valores possíveis de um contador de transação, e para transmitir a pluralidade de chaves criptográficas de sessão e o contador de transação a um terminal de usuário para uso na segurança de uma transação financeira.

18. Servidor de provisionamento, de acordo com a reivindicação 17, caracterizado pelo fato de que o número de chaves criptográficas de sessão geradas compreende um número de valores possíveis do contador de transação.

19. Servidor de provisionamento, de acordo com a reivindicação 17, caracterizado pelo fato de que as chaves criptográficas de sessão compreendem primeiras chaves criptográficas de sessão, em que o número das primeiras chaves criptográficas de sessão compreende menos do que um número de valores possíveis do contador de transação, e em que o processador é configurado para gerar chaves criptográficas de sessão adicionais e transmitir as chaves criptográficas de sessão adicionais ao terminal de usuário quando o suprimento das primeiras chaves criptográficas de sessão é reduzido para um nível predeterminado.

20. Produto de programa de computador para assegurar uma transação entre um terminal de usuário e um terminal de transação, caracterizado pelo fato de compreender: um meio de armazenamento legível por computador tendo código de programa legível por computador incorporado no meio, o código de programa legível por computador compreendendo: código de programa legível por computador para gerar uma pluralidade de chaves criptográficas de sessão a partir de uma chave criptográfica mestre e uma respectiva pluralidade de valores possíveis de um contador de transação; código de programa legível por computador para armazenar as chaves criptográficas de sessão e uma da pluralidade de contadores de transação no terminal de usuário; código de programa legível por computador para gerar um criptograma baseado em uma primeira da pluralidade de chaves criptográficas de secção e dados de transação para a transação; código de programa legível por computador para transmitir o criptograma ao terminal de transação; código de programa legível por computador para atualizar o contador de transação; e código de programa legível por computador para deletar a uma primeira da pluralidade de chaves criptográficas de sessão a partir do terminal de usuário após gerar o criptograma.

21. Método, caracterizado pelo fato de compreender: gerar uma pluralidade de itens secretos correspondendo a uma respectiva pluralidade de valores possíveis de um índice; armazenar a pluralidade de itens secretos e uma primeira da pluralidade de valores possíveis do índice em um primeiro terminal; gerar uma mensagem correspondendo a uma primeira da pluralidade de valores possíveis do índice usando um primeiro dos i-tens secretos; transmitir a mensagem ao segundo terminal; atualizar o índice; e deletar a uma primeira da pluralidade de itens secretos a partir do primeiro terminal após gerar a mensagem.

22. Método, de acordo com a reivindicação 21, caracterizado pelo fato de que a pluralidade de itens secretos compreende senhas de uso.

23. Método, de acordo com a reivindicação 21, caracterizado pelo fato de que o índice compreende um índice de transação, e em que a mensagem compreende um resumo de transação para uma transação entre o primeiro terminal e o segundo terminal.