BRPI0807776B1

BRPI0807776B1 - Aparelho e método para gerar dados de criptograma intermediários correspondentes a uma senha dinâmica; circuito integrado; cartão; código de controle de processador e meio legível por computador

Info

Publication number: BRPI0807776B1
Application number: BRPI0807776-2A
Authority: BR
Inventors: Jonathan Roshan Tuliani
Original assignee: Cryptomathic Ltd
Priority date: 2007-02-20
Filing date: 2008-02-15
Publication date: 2019-04-24
Also published as: GB2442249A; WO2008102169A3; WO2008102169A2; US7882553B2; DK2122527T3; KR101460627B1; EP2122527B1; AU2008217416A1; CN101632086B; KR20090127282A; MX2009008943A; CA2678101C; ES2558542T3; US20080201577A1; GB2442249B; BRPI0807776A2; GB0703245D0; AU2008217416B2; EP2122527A2; PL2122527T3

Abstract

aparelho e método para gerar dados de criptograma intermediários correspondentes a uma senha dinâmica; circuito integrado; cartão; código de controle de processador e meio legível por computador a presente invenção se refere a um dispositivo e método de autenticação, em particular, a dispositivos e métodos para gerar senhas dinâmicas, e aos cartões portadores do dispositivo e ao meio legível para implementação do método. um aparelho para gerar dados de criptograma intermediários correspondentes a uma senha dinâmica para um primeiro esquema criptográfico, os dados de criptograma intermediários sendo adequados para exibição utilizando-se um dispositivo projetado para um segundo esquema criptográfico diferente, sendo que o aparelho compreende: uma interface de comunicações para comunicação com o dispositivo e um processador acoplado a uma memória, com a memória armazenando código de controle de processador para controlar o processador, quando em execução, para: gerar uma senha dinâmica de acordo com o primeiro esquema criptográfico, e gerar dados criptográficos intermediários correspondentes à senha dinâmica, os dados de criptograma intermediários sendo adequados para emitirem como saída para o dispositivo de forma que, quando o dispositivo processa os dados de criptograma intermediários de acordo com o segundo esquema criptográfico, o dispositivo gera dados adequados para exibirem a senha dinâmica.

Description

“APARELHO E MÉTODO PARA GERAR DADOS DE CRIPTOGRAMA INTERMEDIÁRIOS CORRESPONDENTES A UMA SENHA DINÂMICA; CIRCUITO INTEGRADO; CARTÃO; CÓDIGO DE CONTROLE DE PROCESSADOR E MEIO LEGÍVEL POR COMPUTADOR [001] A presente invenção se refere a um dispositivo e método de autenticação, em particular a dispositivos e métodos para gerar senhas dinâmicas, e aos cartões que transportam o dispositivo e ao meio legível que implementa o método.

[002] A autenticação de usuários remotos é uma parte essencial de muitas aplicações baseadas em Web e rede. Os nomes de usuário e senhas tradicionais oferecem uma solução econômica, porém deficiente. A segurança superior é frequentemente obtida pela emissão de usuários com o “token” - um pequeno dispositivo portátil que gera senhas aparentemente aleatórias, as quais são válidas apenas para um único uso: as chamadas senhas de uma vez (OTPs). Pela apresentação de uma OTP ao sistema, o usuário demonstra possessão do token, que quando combinado com uma senha estática tradicional proporciona forte autenticação de dois fatores.

[003] Existe uma ampla variedade de tokens no mercado, baseados principalmente em tecnologia específica de fornecedor proprietário. Por exemplo, RSA SecureID, VASCO Digipass, Secure Computing and Active Identity. Um esforço de padronização está atualmente ocorrendo dentro da comunidade token-proprietário, chamado a Iniciativa para Autenticação Aberta (OATH)

Petição 870190005168, de 17/01/2019, pág. 12/42

2/23 [http://www.openauthentication.org]. Esta procura promover padrões para tokens geradores de OTP e a infraestrutura necessária para o seu desenvolvimento e uso.

[004] Ao mesmo tempo, a necessidade de autenticação forte no setor financeiro conduziu a MasterCard a preparar o caminho para um padrão alternativo, baseado em uma variante do cartão de pagamento “Chip e PIN” (Figura 1). Neste esquema, chamado Programa de Autenticação de Chip (CAP), utiliza-se uma leitora de cartão de mão (Figura 2) para criar as OTPs com base nas funções de núcleo dentro do cartão. As leitoras de cartão são anônimas e permutáveis, e o conceito exige desenvolvimento amplo para torná-los itens de domicílio ou escritório, necessidade de usuários individuais transportarem consigo a sua leitora de cartão.

lugar-comum em todo eliminando assim a [005] Entretanto, o CAP é um sistema proprietário fechado e não é compatível com outros sistemas. No futuro, as leitoras de cartão compatíveis como o CAP podem tornar-se amplamente disponíveis, mas elas somente serão úteis com cartões de chip e pin compatíveis com CAP em aplicações aprovadas pelos seus bancos emissores, uma vez que somente o banco emissor tem acesso à informação necessária para verificar a OTP gerada pelo cartão.

[006] Na presente invenção será descrito um meio para explorar leitoras de cartões CAP padrão em conjunto com um cartão de não pagamento próprio para gerar OTPs compatíveis com OATH. Uma

Petição 870190005168, de 17/01/2019, pág. 13/42

3/23 vantagem desta abordagem é a de que a infraestrutura de OATH padrão pode ser usada para o desenvolvimento dos cartões e validação das OTP resultantes, enquanto o custo dos tokens é reduzido para o custo de um cartão-chip, pela exploração da base de leitora de cartões desenvolvida. Mais genericamente, será descrita uma substituição de algoritmo em dispositivos de senha de uso único baseados em cartão e leitora. Os cartões podem ser proporcionados para operar, por exemplo, com esquemas de RSA SecureID, VASCO DigiPass, Secure Computing ou ActivIdentity, em vez de ou tão bem como OATH.

[007] Na presente invenção será descrito um circuito integrado para gerar uma senha dinâmica para um primeiro esquema criptográfico, sendo o circuito adequado para o uso com um dispositivo projetado para um segundo esquema criptográfico diferente, sendo que o circuito compreende: uma entrada de fonte de alimentação para fornecer energia para o circuito integrado; uma interface para transmitir dados para e receber dados a partir do circuito integrado; e um processador acoplado a uma memória, a memória armazenando código de controle de processador para controlar o processador, quando em operação, para gerar uma senha dinâmica de acordo com o primeiro esquema e então para intermediários emissão como saída para o dito dispositivo, de forma que o processamento efetuado pelo dispositivo de acordo com o segundo esquema criptográfico resulta em o dispositivo gerar a senha dinâmica criptográfico criptográficos produzir dados adequados para

Petição 870190005168, de 17/01/2019, pág. 14/42

4/23 original de acordo com o primeiro esquema criptográfico.

[008] Na presente invenção será descrito um método de emitir como saída dados de pseudocriptograma correspondentes a uma senha dinâmica de acordo com um primeiro esquema criptográfico, sendo os dados adequados para emissão como saída para um dispositivo projetado para um segundo esquema criptográfico diferente, o método compreendendo gerar a senha dinâmica de acordo com o primeiro esquema criptográfico e, então, gerar dados criptográficos intermediários pela inversão do processamento realizado pelo dispositivo de acordo com o segundo esquema criptográfico e emitindo como saída os ditos dados de criptograma intermediários, de forma que o dispositivo no processamento dos dados gera a senha dinâmica original de acordo com o primeiro esquema criptográfico.

[009] De acordo com um aspecto da presente invenção, proporciona-se um aparelho para gerar dados de criptograma intermediários correspondentes a uma senha para um primeiro esquema criptográfico, sendo o aparelho adequado para o uso com um dispositivo projetado para um segundo esquema criptográfico diferente, com o aparelho compreendendo: uma interface de comunicações para comunicação com um dito dispositivo, e um processador acoplado a memória, com a memória armazenando código controle de processador para controlar processador, quando em operação, para: gerar uma senha de acordo com o primeiro esquema criptográfico, e gerar dados de criptograma uma de o

Petição 870190005168, de 17/01/2019, pág. 15/42

5/23 intermediários correspondentes à dita senha, sendo os dados de criptograma intermediários adequados para emissão como saída para o dito dispositivo de forma tal que, quando o dito dispositivo processa os ditos dados de criptograma intermediários de acordo com o segundo esquema criptográfico, o dito dispositivo gera a dita senha.

[0010] Preferentemente, a senha compreende uma senha dinâmica, ou uma senha que é gerada pela inclusão de bits provenientes de um contador binário ou relógio no cálculo do criptograma, e no caso em que é usado um contador incrementar o contador de cada vez que é gerada uma senha.

[0011] Ocasionalmente, a senha dinâmica do primeiro esquema criptográfico pode ser incompatível com o dispositivo do segundo esquema criptográfico, e o código para gerar uma senha dinâmica pode compreender código para gerar senhas dinâmicas repetidamente até ser encontrada uma senha dinâmica que seja compatível com o segundo esquema criptográfico.

[0012] Esta incompatibilidade pode ser causada por zeros à esquerda que ocorrem em determinadas senhas dinâmicas do primeiro esquema criptográfico, que podem ser incompatíveis com o dispositivo do segundo esquema criptográfico.

[0013] Alternativamente, a incompatibilidade pode ser causada por um dígito de verificação gerado automaticamente pelo dito dispositivo que é incompatível com determinadas senhas dinâmicas do primeiro esquema criptográfico.

[0014] De acordo com outro aspecto

Petição 870190005168, de 17/01/2019, pág. 16/42

6/23 da presente invenção, proporciona-se um método para criptográfico, intermediários gerar dados de criptograma intermediários correspondentes a um criptograma de acordo com um primeiro esquema criptográfico, sendo os dados adequados para exibição em um dispositivo projetado para um segundo esquema criptográfico diferente, sendo que o método compreende: gerar uma senha dinâmica de acordo com o primeiro esquema e gerar dados de criptograma correspondentes à dita senha dinâmica, sendo os ditos dados de criptograma intermediários adequados para emissão como saída para um dito dispositivo de forma tal que, quando o dito dispositivo processa os ditos dados de criptograma intermediários de acordo com o segundo esquema criptográfico, o dito dispositivo emite como saída a dita senha dinâmica.

[0015] A invenção proporciona adicionalmente um código de controle de processador para implementar os métodos anteriormente, por exemplo, em um descritos sistema de computador de propósito geral ou em um processador de sinais integrado digitais (DSP), ou em um circuito dedicado, por exemplo, um cartão inteligente. O código pode ser proporcionado em um portador, tal como um disco, CD- ou DVD-ROM, memória programada, tal como memória somente de leitura (Firmware), ou em um portador de dados tal como um portador de sinal óptico ou elétrico. O código (e/ou dados) para implementar modalidades da invenção pode compreender código de fonte, objeto ou executável em uma linguagem de programação convencional (interpretada ou compilada) tal como

Petição 870190005168, de 17/01/2019, pág. 17/42

7/23 código C, ou Assembly. Os métodos descritos anteriormente também podem ser implementados, por exemplo, em um FPGA (arranjo de portas programáveis por campo) ou em um ASIC (circuito integrado específico de aplicação). Desta forma, o código também pode compreender código para configurar ou controlar um ASIC ou FPGA, ou código para uma linguagem de descrição de hardware, tal como Verilog (marca registrada), VHDL (Linguagem de Descrição de Hardware de circuito integrado de velocidade muito alta), ou código RTL ou SystemC. Hardware tipicamente dedicado é descrito utilizando-se código tal como RTL (código de nível de transferência de registro) ou, em um nível mais alto, utilizando-se uma linguagem tal como C. Tal como será apreciado por aqueles versados na técnica, tal código e/ou dados podem ser distribuídos entre uma pluralidade de componentes acoplados em comunicação uns com os outros.

[0016] Características dos aspectos descritos anteriormente e modalidades da invenção podem ser combinados em qualquer permutação.

[0017] Modalidades destes e outros aspectos da invenção serão descritos em seguida de forma detalhada com referência aos desenhos anexos, em que:

A Figura 3 mostra um fluxograma de um método de acordo com uma modalidade da invenção.

A Figura 4 mostra um diagrama de blocos de um dispositivo de acordo com uma modalidade da invenção.

[0018] Será descrito em primeiro

Petição 870190005168, de 17/01/2019, pág. 18/42

8/23 lugar o Programa de Autenticação de Chip MasterCard.

CARTÕES DE CHIP E PIN [0019] Os cartões de “Chip e PIN” seguem padrões técnicos mais formalmente conhecidos como EMV, depois de Europay, MasterCard e Visa. Eles estão sendo amplamente adotados em muitos países no mundo inteiro, uma vez que oferecem recursos de segurança poderosos que permitem aos emitentes de cartões controlarem várias formas de fraude.

[0020] Utiliza-se um chip embutido em cada cartão EMV para autorizar transações. A autorização é baseada em um criptograma computado usando-se uma chave única para o cartão, em conjunto com detalhes da transação. A chave é embutida dentro do chip durante o processo de emissão, e uma cópia guardada em segurança pelo banco emissor. O chip também mantém um valor de contador, conhecido como Contador Transacional do Aplicativo (ATC), o qual é incluído na computação de criptograma e aumentado com cada transação, como uma proteção contra ataques de segunda ação. Finalmente, o portador do cartão fornece uma PM, que o chip verifica contra um valor de referência armazenado, antes de permitir que o criptograma seja computado.

[0021]

No recebimento de uma transação, o emitente é capaz de recomputar o criptograma utilizando a sua cópia da chave de cartão. Uma vez que ninguém mais tem a chave, um criptograma válido deve originar-se com o cartão, e a verificação do PIN pelo cartão demonstra que o

Petição 870190005168, de 17/01/2019, pág. 19/42

9/23 cartão ainda está de posse do portador de cartão original.

Visão Pouco Mais Detalhada do CAP [0022] Uma classe especial de transações é conhecida como transações de “cartão não presente” (CNP). Estas incluem pedidos por correio, pedidos por telefone e transações de ecommerce baseadas na web. Nestes casos, o pagamento é autorizado pelo banco emissor com base simplesmente nos detalhes visíveis do cartão, tais como número do cartão e data de expiração. Uma vez que estes valores são de natureza estática e facilmente copiada, as transações por meio de CNP constituem um alvo atraente para fraudes.

[0023] A MasterCard, em conjunto com um número de outras organizações na indústria de cartões, desenvolveu um padrão para permitir a segurança dos cartões de Chip e PIN fosse alavancado em cenários de CNP. Este esquema é chamado de Programa de Autenticação de Chip (CAP). O CAP requer que cada portador de cartão seja suprido com uma pequena leitora de cartões manual. Pela inserção do cartão na sua leitora, e inserindo o seu PIN, o portador de cartão pode gerar uma OTP com base na chave e ATC no cartão. O emissor pode verificar a OTP pela recomputação do criptograma com base nos mesmos dados de entrada e chave.

[0024] Observa-se que a leitora de cartões não é de forma alguma pessoal do portador de cartão, e não executa operações de segurança crítica.

Computação de EMV CAP OTP [0025] Os cartões de chip e PIN

Petição 870190005168, de 17/01/2019, pág. 20/42

10/23 foram projetados para o uso em terminais de pagamento de ponto de venda e ATMs, não especificamente para geração de senha de uso único. As leitoras de CAP simulam terminais de pagamento de EMV na sua interação com o cartão, e a leitora é então responsável pela coleta do criptograma de pagamento produzido pelo cartão e conversão do mesmo em uma senha de uso único.

[0026] O processamento realizado pela leitura de CAP encontra-se especificado em detalhes em [Arquitetura de Função de Programa de Autenticação de Chip], mas, em resumo, compreende os seguintes estágios:

1. Coleta de dados de entrada de criptograma.

2. Extração de dados de OTP.

3. Decimalização.

[0027] Cada etapa é exposta em seguida de forma mais detalhada.

Coleta de Dados de Entrada de Criptograma [0028] As duas entradas principais para o processo de computação de criptograma são a chave de cartão e o ATC. Entretanto, com EMV, existe um número de outros parâmetros que são usados como entradas na validação de criptograma. Estes são específicos para pagamentos de cartões, e não têm equivalentes em outros tipos de tokens. A fim de reproduzir o criptograma, o servidor de validação deve usar valores idênticos para estes parâmetros.

[0029] Em um cenário de CAP típico, a maior parte destes parâmetros são ou de valor fixo quando o cartão é emitido, ou podem ser

Petição 870190005168, de 17/01/2019, pág. 21/42

11/23 prognosticados pelo servidor de validação. Entretanto, um pequeno número dos parâmetros pode mudar durante o ciclo de vida do cartão, de acordo como o cartão é usado. Por exemplo, isto inclui parâmetros que limitam o número ou quantidade das transações que o cartão autorizará fora de linha. Uma vez que o servidor de validação não pode prognosticar estes valores, eles devem ser transmitidos do cartão para o servidor, incorporado na própria senha de uso único.

Extração de Dados da OTP [0030] A fim de ser tão amigável quanto possível para o usuário, a senha de uso único produzida deverá ser tão curta quanto for possível, ao mesmo tempo em que mantém um nível de segurança razoável. Uma vez que os dados de entrada de criptograma de EMV, combinados com o próprio criptograma, são demasiadamente grandes para serem incluídos na senha de uso único na sua totalidade, eles são comprimidos.

[0031] O processo de compressão é definido por um campo de CAP específico no cartão, conhecido como Mapa de Bits Proprietário de Emissor (IPB), mas o processo propriamente dito é executado pela leitora de cartões. O IPB define quais os bits provenientes do ATC, criptograma e outros dados de entrada de EMV serão usados na senha de uso único os outros bits são descartados.

[0032] Tipicamente, inclui-se um pequeno número de bits de ATC, para auxiliar na sincronização dos valores de contador entre servidor e cartão, em conjunto com pelo menos 16 bits do criptograma, e finalmente aquelas entradas

Petição 870190005168, de 17/01/2019, pág. 22/42

12/23 de criptograma adicionais que não podem ser prognosticadas pelo servidor. Em alguns casos, onde a aplicação de cartão é usada para CAP somente e não para pagamento, pode acontecer que todas as entradas adicionais possam ser prognosticadas pelo servidor e, desta forma, a OTP é baseada no ATC e criptograma unicamente.

Decimalização [0033] Finalmente, a saída binária proveniente do processo de compressão é decimalizada para exibição para o usuário na tela da leitora. É possível um número de esquemas de decimalização, mas o CAP define um único esquema baseado simplesmente na interpretação da saída de processo de truncamento como a representação binária de um único inteiro. Os zeros à esquerda são ignorados e, deste modo, o comprimento final da OTP pode variar.

[0034] Descrevem-se em seguida os Padrões de Autenticação Aberta (OATH).

Aspecto Geral [0035] A iniciativa para a Autenticação Aberta (OATH) é um organismo de coordenação de indústria que procura promover a padronização do mercado de autenticação baseado em tokens. A OATH publicou uma “arquitetura de referência” que descreve uma visão de um enquadramento de autenticação geral, e está promovendo um número de padrões para as várias interfaces e componentes dentro deste sistema.

[0036] De maior interesse para esta proposta é o “HOTP: Um algoritmo de senha de uso único baseado em HMAC”, que está sendo

Petição 870190005168, de 17/01/2019, pág. 23/42

13/23 padronizado pelo IETF como RFC4226 [HOTP: An HMACBased One-Time Password Algoritmo, http://www.ietf.org/rfc/rfc4226.txt, dezembro de 2005].

Computação do HOTP [0037] Da mesma forma que ocorre com CAP, o algoritmo HOTP é baseado em um primitivo criptográfico fundamental, neste caso HMAC-SHA1. As entradas para este algoritmo definido em HOTP são compreendidas por uma chave de token e um contador - muito semelhante às entradas básicas para uma computação de criptograma EMV, tal como usada por

CAP.

[0038] O processo de computação de

HMAC é o seguinte:

1. Computação de HMAC, baseada na chave de token e contador. O contador é então incrementado automaticamente.

2. “Truncagem Dinâmica do resultado para proporcionar um valor de 31-bits.

3. Decimalização do valor truncado, para proporcionar a OTP.

[0039] Embora os paralelos com a computação de CAP OTP sejam evidentes, é importante observar que os detalhes de cada estágio são inteiramente diferentes. Cada etapa encontra-se descrita e contrastada com seu equivalente CAP adiante.

Computação de HMAC [0040] A computação de HMAC usada é tal como especificada em [HMAC: Keyed Hashing for Message Authentication, RFC2104, http://www.jetf.org/rfc/rfc2104.txt, fevereiro de

Petição 870190005168, de 17/01/2019, pág. 24/42

14/23

1997], utilizando-se SHA1 como o algoritmo arbitrário subjacente [US Secure Hash Algorithm 1 (SHA1), http://www.jetf.org/rfc/rfc3174.txt,

RFC3174, setembro de

2001]. A chave requerida por HMAC-SHA1 é tipicamente de 20 bytes de comprimento, e [HOTP] especifica que se utiliza um contador de 8 bytes como os únicos dados de entrada de HMAC.

[0041]

O resultado um valor binário de 20 bytes, comparado ao criptograma de 8 bytes usado por CAP. Nos dois casos, um objetivo principal é que não devia ser viável recuperar informação acerca da chave proveniente das OTP resultantes. Esta é a razão pela qual, nos dois casos, é empregado um algoritmo criptográfico de alguma espécie.

[0042] O processo de truncagem que é definido por [HOTP] reduz a saída HMAC de 20 bytes para uma série de 31 bits.

[0043] Primeiramente, os últimos 4 bits do último byte da saída de HMAC são considerados como um inteiro n na faixa 0-15. Então, os bytes n, n + 1,..., n + 3 são usados como a saída de truncagem (com o bit precedente ignorado).

[0044] As diferenças com o esquema de compressão usado por CAP são marcadas:

• O CAP IPI3 sempre seleciona bits a partir da mesma posição no criptograma de EMV para o uso na OTP. Na OATH, a posição dos bits varia determinada pelos últimos 4 bits na saída de HMAC, portanto, a razão do termo dinâmico.

• A edição ativa de [HOTP] não proporciona

Petição 870190005168, de 17/01/2019, pág. 25/42

15/23 mecanismo para incluir informação de sincronização de contador na OTP resultante, enquanto o CAP IPB pode especificar um número arbitrário de bits de ATC para inclusão na OTP.

• O CAP IPB pode especificar um número de outros elementos de dados específicos de EMV para inclusão na OTP. Nenhum destes recursos é relevante para HOTP.

Decimalização [0045] A decimalização de HOTP consiste de interpretar a saída de 31 bits proveniente do processo de truncagem dinâmica quanto à representação binária de um inteiro, e então reduzir esse módulo inteiro 10^d, onde d é o número de dígitos desejados na OTP resultante. Em contraste com o CAP, se o resultado tiver menos do que d dígitos, então são inseridos zeros à esquerda para proporcionarem um comprimento total d de OTP.

[0046] Observa-se, também, que este processo de decimalização efetivamente realiza uma truncagem adicional, no sentido de que a saída tem um teor de informação menor do que a entrada. No CAP, não se perde qualquer informação durante a

decimalização.
[0047]		Descreve-se,	em	seguida, a
geração de OATH	OTPs	utilizando-se	uma	leitora de
CAP. A Figura 3	mostra	um exemplo de	um	método para
conseguir isto.
[0048]		Descreve-se	um	meio para

gerar OTPs compatíveis com OATH utilizando-se uma leitora de CAP padrão, não modificada, pela produção de um chip-cartão OATH especial para usar dentro da leitora. Isto permite a uma organização

Petição 870190005168, de 17/01/2019, pág. 26/42

16/23 que deseja desenvolver OATH desenvolver chipscartões de baixo custo em vez de tokens de custo mais elevado, explorando a infraestrutura de leitora de cartões de CAP desenvolvida para usar estes chips-cartões com servidores de validação de OATH fora de prateleira existentes.

[0049] Evidentemente, o chipcartão de OATH reproduz a interface de cartão EMV, ou pelo menos aquelas partes da interface de EMV que são usadas pela leitora de CAP. De outro modo, a leitora rejeitará o cartão.

[0050] A chamada de função de cartão crítica é a chamada GENERATE_AC, que é usada para gerar o próprio criptograma. Observa-se que não é suficiente substituir simplesmente a implementação desta função no cartão com uma função que gera um valor arbitrário de HOPT, como usado na computação de OATH OTPs. Isto acontece porque o processo usado para comprimir e decimalizar o criptograma para a OTP é executado na leitora, e é inteiramente diferente entre CAP e OATH.

[0051] Portanto, o chip-cartão OATH implementa a seguinte sequência de operações:

1. Gerar um valor arbitrário de HOTP 301, com base na chave de cartão e contador, e incrementa o contador 302.

2.

Truncar decimalizar valor arbitrário 303 para produzir a própria OTP.

3. Converter a OTP de volta a um formato binário 304, utilizando um processo que é o inverso do processo de decimalização empregado por uma leitora de CAP.

4. Atenuar os dados binários

Petição 870190005168, de 17/01/2019, pág. 27/42

17/23

resultantes 305	de uma maneira	que é o inverso	do
processo de compressão empregado	por uma leitora	de
CAP (tal como	definido pelo	valor de IPB	no
cartão).
[0052]	Chama-se	o resultado	de

criptograma intermediário. O chip-cartão de OATH passa este criptograma intermediário para a leitora de CAP, como se ele fosse um criptograma de EMV normal.

[0053] Então, a leitora de CAP comprimirá e decimalizará os dados, revertendo efetivamente as etapas 4 e 3 supra, e deste modo o resultado final exibido na tela da leitora será uma OATH OTP, tal como computada pelo cartão de OATH na etapa 2 supra. A Figura 4 mostra um diagrama de blocos de um exemplo de um dispositivo para um chip-cartão de OATH compatível com leitoras de CAP. Casos Especiais [0054] casos especiais, os expostos a seguir. Zeros à Esquerda

Origina-se quais são um número considerados de como [0055] Durante a decimalização, tanto CAP quanto HOTP podem resultar em um resultado decimal que começa com 0. O CAP especifica que tais zeros à esquerda sejam removidos (e, deste modo, a OTP resultante pode variar na extensão), enquanto HOTP especifica que eles sejam incluídos na OTP (que, portanto, tem um comprimento fixo).

[0056] Observe-se que no CAP, o processo de decimalização - incluindo truncagem dos zeros à esquerda - ocorre na leitora. Deste modo,

Petição 870190005168, de 17/01/2019, pág. 28/42

18/23 não é possível forçar uma leitora de CAP a exibir uma HOTP OTP que inclui zeros à esquerda, independentemente do método usado no chip-cartão. Na invenção apresentam-se três soluções possíveis para este problema:

1. A primeira solução possível é simples, mas insatisfatória: instrui os usuários a inserir zeros adicionais na frente da OTP exibida quando ela se encontra abaixo da extensão esperada.

2. A segunda solução possível consiste em ter o servidor de aplicação ou validação de autenticação inserindo quaisquer zeros à esquerda perdidos automaticamente antes da validação da OTP. Isto proporciona uma melhor experiência para o usuário, mas invalida o objetivo original de implementar o OATH usando leitoras de CAP sem quaisquer alterações para a infraestrutura de validação.

3. A terceira abordagem é para o chipcartão de OATH identificar tais casos, e quando eles ocorrem, descartar automaticamente a OTP (na etapa 2 acima), e gerar uma nova OTP com base no valor de contador incrementado.

[0057] Uma vez que o dígito precedente é efetivamente aleatório, é altamente improvável que, em uma longa sequência de senhas, todas elas comecem com zero. Além disso, uma vez que o servidor de validação, em qualquer caso, aceita uma faixa de valores de contador a fim de evitar problemas de sincronização, a omissão da senha ocasional porque ela começa com um zero não faz com que a validação falhe, e isto é despercebido pelo usuário. Por último, embora esta

Petição 870190005168, de 17/01/2019, pág. 29/42

19/23 técnica reduza o número de saídas de HOTP possíveis em cerca de 10%, uma extensão mínima de 6 dígitos proporciona pelo menos 1 milhão de OTPs possíveis e, assim, a segurança global oferecida é ainda plenamente aceitável.

Dígitos de Sincronização de Contador [0058] Atualmente, a HOTP não especifica quaisquer meios de incluir dígitos de sincronização de contador na OTP, enquanto que o CAP oferece um esquema flexível, configurado pela utilização do IPB implantado no cartão. Ao suprimirem-se simplesmente os dígitos de sincronização de CAP com um valor de IPB apropriado, pode alcançar-se compatibilidade.

[0059] Considera-se a possibilidade de que uma versão futura de HOTP pode incluir um meio de incluir informação de sincronização de contador na OTP. É altamente provável que o algoritmo escolhido não seja compatível com aquele usado pelo CAP, uma vez que não há análogo para o CAP IPB na HOTP. Observa-se que pode ser alcançada adicional compatibilidade, ao continuar-se a suprimir a informação de sincronização de CAP utilizando-se a IPB e passando-se os dados de sincronização de HOTP do cartão para a leitora no criptograma intermediário, juntamente com o restante da OTP.

[0060] Considera-se agora o cenário em que a leitora de CAP inclui um dígito de verificação obrigatório ou outros dados de sincronização, mas essa HOTP não. Neste caso, a leitora receberá o criptograma a partir do cartão, e adicionalmente também receberá o valor de ATC

Petição 870190005168, de 17/01/2019, pág. 30/42

20/23 para, a partir deles, extrair dados de sincronização, combinando os dois para proporcionar a OTP exibida. Neste caso, a compatibilidade pode ser ainda mantida, pelo uso de lógica de cartão adicional. O cartão devia computar a HOTP OTP, e separá-la em duas partes - aquela que a leitora extrairá do criptograma intermediário, e aquela que a leitora extrairá da ATC. O cartão então proporciona um criptograma intermediário e uma ATC alternativa para a leitora, sabendo que a leitora combinará estes para reconstruir a OTP original. A observação chave é que a leitora não sabe que o valor na ATC alternativa não é o mesmo que o valor de contador usado para computar a OTP.

[0061] Por último, observa-se que o cenário em que tanto HOTP quanto CAP implementam os esquemas de sincronização, sendo que de forma diferente, pode ser manipulado por uma combinação das técnicas expostas anteriormente neste contexto. Dígitos de Verificação [0062] Por vezes utilizam-se dígitos de verificação para detectarem erros em dados, em particular erros introduzidos por transcrição humana. Atualmente, nem o CAP nem a HOTP incluem um mecanismo de verificação de dígito para as OTP criadas, mas é possível que isto possa mudar no futuro. Se fosse requerida uma leitora de CAP padrão para suportar um dígito de verificação de HOTP, isto poderia ser obtido implantando-se simplesmente o dígito de verificação no criptograma intermediário que se faz passar para a leitora, de forma assemelhada à técnica usada para fazer passar dados de sincronização discutida anteriormente.

Petição 870190005168, de 17/01/2019, pág. 31/42

21/23 [0063] Alternativamente, supõe-se que a leitora de CAP se destinada a incluir automaticamente um dígito de verificação nas OTP, que a HOTP não especificou. Isto criará um problema mais significativo, uma vez que o cartão não terá meios de suprimir esse dígito de verificação. As únicas soluções consistem em modificar a infraestrutura de aplicação ou validação para aceitar HOTP OTPs com dígitos de verificação de CAP anexos, ou ter o cartão personalizado gerando repetidamente as OTPs até (por chance) ser encontrada uma OTP com um dígito de verificação de conexão e um criptograma intermediário apropriado (que não inclui o dígito de verificação, uma vez que ele será adicionado pela leitora) computado.

[0064] Esta última abordagem aumentará enormemente o tempo de computação do cartão, visto que um número de OTPs pode ter de ser calculado antes de ser encontrado um valor adequado. O contador de cartão incrementará bem mais rápido do que o normal, e a tolerância no servidor de validação pode precisar ser ajustada correspondentemente. Enquanto o aumento no contador de cartão requerido seja imprevisível, é provável que um equilíbrio apropriado dos parâmetros do sistema (extensão de OTP, tolerância de servidor de validação) possa ser ainda encontrado oferecendo segurança e confiabilidade aceitáveis contanto que a quantidade de informação de erro-verificação inserida pela leitora de cartão não seja demasiadamente grande.

[0065] Observe-se que esta última técnica é uma repetição da técnica usada para

Petição 870190005168, de 17/01/2019, pág. 32/42

22/23 manipular zeros à esquerda na OTP baseada em HOTP. De uma maneira geral: se a HOTP OTP for incompatível com a leitora de cartões por qualquer razão (nos exemplos dados anteriormente, por causa de um zero à esquerda ou dígito de verificação), é sempre possível para o cartão simplesmente incrementar o valor de contador de cartão até ser encontrada uma OTP compatível. A aplicabilidade desta técnica depende, na prática, do número e da distribuição de OTPs incompatíveis e dos parâmetros de validação de servidor.

[0066] Foi descrito o cenário específico de uma leitora de cartões CAP utilizando-se um cartão especial para conseguir-se compatibilidade de OATH, e alternativas referentes a sincronização de contador e dígitos de verificação. Serão listadas em seguida algumas outras aplicações possíveis:

[0067] Pode-se proporcionar cartões para o uso com leitoras projetadas para qualquer sistema baseado em OTP com base em um motor criptográfico separado em relação à interface de usuário, não exatamente o CAP. Entretanto, o CAP é o sistema com mais probabilidade de conseguir desenvolvimento de alto volume nos próximos poucos anos. Pode-se proporcionar cartões para o uso em qualquer sistema de OTP, não somente OATH. Exemplos incluem RSA SecureID, VASCO DigiPass, Secure Computing and ActivIdentity. Pode-se proporcionar cartões para autenticação de repto-resposta. Podem ser proporcionados cartões para “assinaturas curtas”, em que o token produz uma OTP com base em dados de mensagem inseridos pelo usuário (tanto

Petição 870190005168, de 17/01/2019, pág. 33/42

23/23 incluindo o valor de contador, quanto não incluindo). Aplicações possíveis incluem onde a leitora de cartões é substituída por um telefone móvel (isto é, um telefone móvel com uma leitora de cartões que tem compatibilidade de CAP suficiente para operar com os cartões). Outras aplicações incluem onde o cartão de OATH é inserido em uma leitora de cartões que é conectada ao PC do usuário. Ainda outras aplicações incluem onde a OTP é comunicada verbalmente sobre o telefone, em vez da Internet, ou por e-mail, ou por fax, ou por uma rede interna.

[0068] Evidentemente que muitas outras alternativas efetivas ocorrerão à pessoa versada na técnica. Será compreendido que a invenção não fica limitada às modalidades descritas e abrange modificações que serão evidentes para aquele versado na técnica, situadas dentro do espírito e escopo das reivindicações que se apresentam a seguir.

Petição 870190005168, de 17/01/2019, pág. 34/42

Claims

REIVINDICAÇÕES

1. Aparelho para gerar dados de criptograma intermediários correspondentes a uma senha dinâmica, para um primeiro esquema criptográfico, os dados de criptograma intermediários sendo adequados para produzir uma exibição da senha dinâmica utilizando-se um dispositivo compatível com CAP projetado para um segundo esquema criptográfico para gerar uma senha, em que o segundo esquema criptográfico é um esquema de Programa de Autenticação de Chip (CAP), o aparelho sendo caracterizado por compreender:

- uma interface de comunicações para comunicação com o dispositivo compatível com CAP;

- um processador acoplado a uma memória, com a memória armazenando código de controle de processador para controlar o processador, quando em operação, para:

- gerar uma senha dinâmica de acordo com o primeiro esquema criptográfico, e

- gerar dados de criptograma intermediários a partir da senha dinâmica por:

- converter a senha em dados binários utilizando um processo que é o inverso do processo de decimalização empregado por um dispositivo compatível com CAP, e

- preencher os dados binários de uma maneira que é a inversa do processo de compressão empregado por um dispositivo compatível com CAP, em que os dados de criptograma intermediários são adequados para emissão como saída para o dispositivo compatível com CAP de forma que, quando o dispositivo compatível com CAP

Petição 870190005168, de 17/01/2019, pág. 35/42
2/5 processa os dados de criptograma intermediários de acordo com o segundo esquema criptográfico para gerar uma senha, o dispositivo compatível com CAP gera a senha dinâmica gerada pelo primeiro esquema criptográfico.

2. Aparelho, de acordo com a reivindicação 1, caracterizado por a senha dinâmica compreender uma senha de uso único.
3. Aparelho, de acordo com a reivindicação 1 ou 2, caracterizado por o primeiro esquema criptográfico compreender um esquema de Autenticação Aberta.
4. Aparelho, de acordo com a reivindicação 1 ou 2, caracterizado por o primeiro esquema criptográfico compreender RSA SecureID.
5. Aparelho, de acordo com a reivindicação 1 ou 2, caracterizado por o primeiro esquema criptográfico compreender Vasco Digipass.
6. Aparelho, de acordo com qualquer uma das reivindicações precedentes, caracterizado por o preenchimento dos dados binários incluir inserir bits de acordo com um Mapa de Bits Proprietário de Emissor CAP.
7. Aparelho, de acordo com qualquer uma das reivindicações 1 a 5, caracterizado por o preenchimento dos dados binários incluir incorporar dados de dígito de verificação correspondentes a um ou mais dígitos de verificação.
8. Aparelho, de acordo com qualquer uma das reivindicações 1 a 5, caracterizado por uma parte de possíveis senhas dinâmicas no primeiro esquema criptográfico não poder ser exibida utilizando-se o dispositivo compatível com CAP, e

Petição 870190005168, de 17/01/2019, pág. 36/42

3/5 em que a geração de uma senha dinâmica compreende gerar senhas dinâmicas repetidamente até ser encontrada uma senha dinâmica que pode ser exibida utilizando-se o dispositivo compatível com CAP.
9. Aparelho, de acordo com a reivindicação 8, caracterizado por a parte de senhas dinâmicas possíveis compreender senhas dinâmicas que têm zeros à esquerda.
10. Aparelho, de acordo com a reivindicação 8, caracterizado por o dispositivo compatível com CAP, quando em operação, gerar um dígito de verificação para exibição, e a geração de senhas dinâmicas compreende adicionalmente determinar o dígito de verificação gerado pelo dispositivo compatível com CAP.
11. Aparelho, de acordo com qualquer uma das reivindicações 1 a 10, caracterizado por o dispositivo compatível com CAP ser configurado para processar dados de sincronização adicionalmente aos dados de criptograma intermediários, e em que a geração de dados de criptograma intermediários compreende adicionalmente gerar dados de sincronização para emissão como saída para o dispositivo compatível com CAP de forma que, quando o dispositivo compatível com CAP processa os dados de sincronização e os dados de criptograma intermediários de acordo com o segundo esquema

criptográfico, o dispositivo compatível com CAP gera dados adequados para exibirem a senha dinâmica. 12. Aparelho, de acordo com a reivindicação 11, caracterizado por os dados de sincronização compreenderem um Contador de

Petição 870190005168, de 17/01/2019, pág. 37/42

4/5

Transação de Aplicação (ATC).
13. Aparelho, de acordo com qualquer uma das reivindicações 1 a 12, caracterizado por o dispositivo compatível com CAP compreender uma leitora compatível com CAP.
14. Circuito integrado, caracterizado por incluir o aparelho do tipo definido em qualquer uma das reivindicações precedentes.
15. Cartão, caracterizado por portar o circuito integrado do tipo definido na reivindicação 14.
16. Método para gerar dados de criptograma intermediários correspondentes a uma senha dinâmica, para um primeiro esquema criptográfico, os dados de criptograma intermediários sendo adequados para produzir exibição da senha dinâmica em um dispositivo compatível com CAP projetado para um segundo esquema criptográfico para gerar uma senha, em que o segundo esquema criptográfico é um esquema de Programa de Autenticação de Microplaqueta (CAP), o método sendo caracterizado por compreender:

- gerar uma senha dinâmica de acordo com o primeiro esquema criptográfico, e

- gerar dados de criptograma intermediários a partir da senha dinâmica por:

- converter a senha em dados binários utilizando um processo que é o inverso do processo de decimalização empregado por um dispositivo compatível com CAP, e

- preencher os dados binários de uma maneira que é a inversa do processo de compressão empregado por um dispositivo compatível com CAP,

Petição 870190005168, de 17/01/2019, pág. 38/42

5/5 em que os dados de criptograma intermediários são adequados para emissão como saída para um dispositivo compatível com CAP de forma que, quando o dispositivo compatível com CAP processa os dados de criptograma intermediários de acordo com o segundo esquema criptográfico para gerar uma senha, o dispositivo compatível com CAP emite como saída a senha dinâmica gerada pelo primeiro esquema criptográfico.
17. Método, de acordo com a reivindicação 16, caracterizado por o dispositivo compatível com CAP compreender uma leitora compatível com CAP.
18. Método, de acordo com a reivindicação 16 ou 17, caracterizado por gerar a senha dinâmica compreender gerar um criptograma HMAC-SHA1.
19. Código de controle de processador, caracterizado por controlar um processador para executar, quando em operação, o método do tipo definido em qualquer uma das reivindicações 16 a 18.
20. Meio legível por computador, caracterizado por executar o código de controle de processador do tipo definido na reivindicação 19.

Petição 870190005168, de 17/01/2019, pág. 39/42