BR112015032258B1

BR112015032258B1 - Método implementado por computador para segurança de operações em sistemas de autenticação e autorização utilizando informações biométricas e sistema de comunicação para segurança de operações em sistemas de autenticação e autorização utilizando informações biométricas

Info

Publication number: BR112015032258B1
Application number: BR112015032258-1A
Authority: BR
Inventors: José Maria Palazón Romero; Antonio GUZMÁN SACRISTÁN; David BARROSO BERRUETA; José Mária Alonso Cebrián; Daniel KACHAKIL DIB
Original assignee: Telefonica Digital Espana, S.L.U.
Priority date: 2013-06-24
Filing date: 2014-06-23
Publication date: 2023-01-31
Also published as: EP3014837A1; BR112015032258A2; EP3014837B1; BR112015032325A8; ES2754198T3; EP3014836B1; US20160156598A1; US9860248B2; BR112015032325A2; WO2014206945A1; EP3014836A1; WO2014206946A1; BR112015032258A8; BR112015032325B1; US20160277395A1; ES2753349T3

Abstract

MÉTODO IMPLEMENTADO POR COMPUTADOR, SISTEMA DE COMUNICAÇÃO E PRODUTOS DE PROGRAMAS DE COMPUTADOR PARA OPERAÇÕES DE SEGURANÇA EM SISTEMAS DE AUTENTICAÇÃO E AUTORIZAÇÃO UTILIZANDO INFORMAÇÕES BIOMÉTRICAS. O método implementado por computador compreendendo o controle do acesso a diferentes recursos e ações definidos para um usuário por um primeiro servidor, redução do tempo de exposição no qual essas operações estão disponíveis, estabelecimento de uma verificação de canal dupla por meio do uso de um segundo servidor e reforço de um mecanismo de fator de autenticação ao incluir uma verificação de identidade biométrica de informações biométricas do usuário.

Description

CAMPO DA TÉCNICA

[001] A presente invenção é direcionada, em geral, ao campo de métodos e sistemas de autenticação biométrica. Em particular, a invenção se refere a um método implementado por computador, um sistema de comunicação e produtos de programas de computador para operações de segurança em sistemas de autenticação e autorização utilizando informações biométricas.

HISTÓRICO DA INVENÇÃO

[002] Nos últimos anos, o mercado de detecção de fraude na web aumentou consideravelmente, assim, inovação em processos de autenticação e autorização se tornou de grande importância.

[003] A complexidade crescente de aplicações levou à adoção de muitas técnicas de segurança altamente sofisticadas. Umas das classificações que podem ser propostas para o estudo dessas técnicas de segurança permite a distinção entre soluções de autenticação e soluções de autorização. As técnicas de autenticação são projetadas a verificar se uma pessoa é quem reivindica ser. A fim de adicionar mais confiabilidade na verificação de que, de fato, uma pessoa corresponde à identidade que está sendo verificada, muitos esquemas de autenticação alternativos podem ser tomados ou o número de fatores para construir essa autenticação pode ser extenso.

[004] Há muitas soluções projetadas para potencializar os processos de autenticação e, por extensão, para fortificar os processos de autorização. Uma vez que os usuários foram identificados de maneira segura, há esquemas de autorização que permitem flexibilidade e robustez em atribuir permissões a usuários para garantir acesso seguro a recursos de sistema. Entretanto, há ameaças que não podem ser contrariadas ao adotar quaisquer dos esquemas existentes para a autenticação/autorização, ou essa adoção é muito cara de custear. Essas ameaças afetam diretamente a maneira na qual o acesso a recursos específicos é realizada. Um método para tratar dessas ameaças envolve o projeto de novíssimos mecanismos de segurança. Esses mecanismos devem garantir que uma vez que a identidade de um usuário foi verificada e o nível de autorização a um recurso para esse usuário foi verificada, as ações tomadas pelo usuário daquele recurso não interceptadas e modificadas por qualquer invasor.

[005] Em qualquer modelo de autorização, diferentes técnicas que facilitam acesso a diversos recursos de sistema são incluídas. As informações de responsabilidade de usuário, os dados de controle de acesso providos quando o usuário é autenticado, são exemplos de informações que podem ser utilizadas para determinar a quem dar acesso a quais recursos e como esse acesso deve ser concedido. Por fim, a determinação do que deve ser acessado pelos usuários será especificada para cada aplicação. Por esse motivo, algumas vezes, será difícil prover um esquema de autorização geral. Será necessário definir uma lógica específica por aplicação para determinar o que os usuários podem acessar e como realizariam esses acessos. A partir dessa ideia, há muitas soluções que propõe esquemas seguros e flexíveis para a implementação da autorização. Em todas essas soluções, a segurança deve ser garantida pela seleção correta do mecanismo de autenticação e uma implementação correta do esquema de autorização selecionado.

[006] Algumas das soluções proveem flexibilidade ao definir seu próprio SDK para encorajar o uso de seus esquemas para autenticação/autorização. Hoje em dia, a maioria do SDK tem base em conceitos introduzidos por OAuth e não supõe um risco em si. Isso se aplica a Microsoft Live Connect, Facebook PHP SDK e Windows 8 SDK Authentication Broker. Se existirem, as ameaças devem vir de um uso deficiente desses SDK. Na verdade, independentemente das ameaças derivadas por uma má implementação do esquema escolhido, a maioria das ameaças que pode ser definida em um sistema de autorização coincide com as ameaças definidas para sistemas de autenticação. Essa coincidência tem de se fazer com o mau uso das credenciais utilizadas para gestão de permissões que concedem acesso a recursos [2], [5].

[007] Em [2], quatro níveis diferentes são definidos em termos de consequências de erros de autenticação e autorização e mal uso de credenciais. O nível 1 é o nível mais baixo (o mais inseguro) e o nível 4 é o mais alto. • Nível 1 - Um invasor pode realizar testes de registros repetidos ao imaginar possíveis valores do autenticador de token. Um invasor também é capaz de repetir as mensagens capturadas previamente (entre um usuário legítimo e um verificador) para autenticar como aquele usuário ao verificador. NIST recomenda o uso de uma autenticação de único ou múltiplos fatores sem comprovação de identidade, a fim de prover proteção contra essas tentativas online e ataques de repetição. • Nível 2 - Um invasor pode ouvir passivamente ao protocolo de autenticação para capturar informações que podem ser utilizadas em um ataque ativo subsequente para se mascarar como o usuário. NIST recomenda o uso de autenticação de único ou múltiplos fatores para prover proteção contra esses ataques de espionagem e todos os ataques do nível 1. • Nível 3 - O invasor se posiciona entre o usuário e o verificador, de modo que ele/ela possa interceptar e alterar o conteúdo das mensagens de protocolo de autenticação. O invasor tipicamente imita o verificador ao usuário e imita simultaneamente o usuário ao verificador. A condução de uma troca ativa com ambas as partes simultaneamente pode permitir que o invasor utilize mensagens de autenticação enviadas por uma parte legítima para se autenticar com sucesso à outra. NIST recomenda o uso de uma autenticação de múltiplos fatores e amplo uso de OTP. Também sugere um token utilizado para a autenticação a ser destravado pelo usuário utilizando uma senha ou dados biométricos. A adoção dessas soluções provê proteção contra ataques de imitação de verificador, ataques MitM e os ataques de nível 2. • Nível 4 - Um invasor é capaz de se inserir entre um usuário e um verificador subsequente a uma troca de autenticação de sucesso entre as duas últimas partes. O invasor é capaz de representar como um usuário ao verificador, ou vice-versa, para controlar a troca de dados de sessão. Por outro lado, o invasor pode comprometer ou, de outra forma, explorar tokens de autenticação e pode interceptar todas as comunicações de entrada e saída do dispositivo (ataques de Homem no dispositivo (MitD) ou ataques de Homem no Navegador (MitB)). O invasor pode fazer isso infectando o sistema com malware. NIST sugere o uso de autenticação de múltiplos fatores com FIPS-140-2 hardware resistente à interferência certificado (tokens de hardware) [4] para obter proteção contra esses ataques de apropriação de sessão e os ataques do nível 3.

[008] Para os primeiros três níveis, ataques e soluções existentes são, ambos, focados na maneira da verificação da identidade do usuário. No nível 4, NIST propõe o uso de soluções contra apropriação de sessão e outros ataques pelos processos de autenticação. Essa apropriação de sessão envolve um invasor levar a vantagem da troca legítima de credenciais que um usuário faz para aderir ao processo de autenticação. Uma vez que essa validação é realizada, o invasor, então, intervém na comunicação que ocorre. Esse tipo de ataque pode ser implementado em duas maneiras: ação ativamente, apropriação da conexão e a deixando ao usuário legítimo, ou, permanecendo oculto e modificando o conteúdo da comunicação de maneira transparente ao usuário. Seja qual for a implementação desse ataque, é importante observar que esse é um ataque que visa quebrar o sistema de autorização, deixando intacto, embora sem uso, o sistema de autenticação. Embora haja muitas alternativas para proteger de maneira proativa os sistemas dessa ameaça, não há solução adequada para diminuir os efeitos do ataque uma vez que o dispositivo do qual o acesso de recurso é solicitado, está comprometido.

[009] NIST sugere o emprego de FIPS-140-2 hardware resistente à intervenção certificado (tokens de hardware) [4]. A utilização desses dispositivos provê os usuários da capacidade de gerar uma senha de único uso (senha de utilização única, OTP) para comprovar sua identidade para cada transação. Além disso, há implementações de hardware desses tokens que podem gerar outras OTPs codificadas para conter informações sobre como concluir uma transação específica.

[010] Diferentes critérios podem ser definidos para estabelecer comparação entre esquemas de autenticação/autorização. Em [1], os autores sugerem a necessidade de definir três critérios, a fim de realizar uma comparação eficaz. Esses aspectos são: segurança, usabilidade e complexidade na implementação (capacidade de implantação). Esse documento apresenta um estudo extenso para instrumentar a comparação por meio da definição de métricas. A tabela a seguir resume as métricas definidas para cada critério.

[011] No caso de critério de segurança, o conjunto de métricas proposto resume todos os aspectos que são comumente estimados na definição de um modelo de ameaça. Na definição desses modelos, é necessário adotar diversas decisões. E essas decisões definem o cenário de trabalho. Por exemplo, no caso de OAuth 2.0 [5], as suposições adotadas são como segue: • O invasor tem total acesso à rede entre o cliente e os servidores de autorização e o cliente e o servidor de recurso, respectivamente. O invasor pode violar a confidencialidade em quaisquer comunicações entre essas partes. Ele não presumiu ter acesso à comunicação entre o servidor de autorização e servidor de recurso. • Um invasor tem recursos ilimitados para organizar um ataque. • Duas dessas três partes envolvidas no protocolo OAuth podem conspirar para montar um ataque contra o terceiro. Por exemplo, o cliente e o servidor de autorização podem estar sob o controle de um invasor e conspirar para trapacear um usuário para ganhar acesso a recursos.

[012] Atendendo às métricas introduzidas acima, é possível determinar que soluções correspondentes ao nível de segurança maior (nível 4) têm desempenho ruim na capacidade de implantação e usabilidade. Uma vez que a avaliação de um sistema permite determinar em qual nível tem de ser implantado seu sistema de autenticação, é necessário avaliar se os usuários são autenticados segura e corretamente. Embora haja algumas ferramentas que ajudam nessa tarefa [3], [6], implantações no nível 4 são difíceis de avaliar corretamente. Em termos de usabilidade, o uso de tokens de hardware resistente à interferência vai de encontro à adoção dessas soluções pelos usuários, e foi comprovado que essa situação leva a um mau uso dos sistemas de credencial. Esses tokens são caros. Eles são dispositivos independentes que o usuário tem de deter e que podem ser empregados com um provedor de serviço somente. Se os usuários tiverem de lidar com mais de um provedor de serviço que adotou esses tokens de hardware resistente à interferência, eles têm de deter o máximo de tokens que os provedores de serviço possuem.

[013] Além disso, em termos de autorização, em [7], os autores explicam que, além de algumas questões de segurança de cada SDK, os desenvolvedores que escolhem se integrar com um deles fazem suposições que podem levar a problemas de segurança. Isso se deve aos SDKs serem geralmente não bem documentados e a segurança explora quase sempre derivação de invasores que encontram maneiras de violar essas suposições com as quais os implementadores do sistema contam.

[014] Junto a essas dificuldades, outros problemas devem ser considerados para entender o aumento constante em fraude que se origina do roubo de identidades digitais. Por exemplo, não é possível medir um nível de segurança homogêneo nas contas digitais de todos os usuários. É necessária uma solução que possa equalizar o nível de segurança de todas as contas digitais que um usuário possui. Essa solução deve estender essa segurança não somente aos processos de autenticação, mas também aos processos de autorização de recurso e todos os procedimentos relacionados a essas contas.

[015] Além disso, numerosas técnicas de identificação e autenticação biométricas estão em uso hoje em dia para aplicações de segurança e controle de acesso. Essas técnicas biométricas incluem identificação de impressão digital, reconhecimento de face, escaneamento de retina, escaneamento de íris, reconhecimento de mão, e análise de voz e assinatura. Entretanto, embora haja muitas vantagens para autenticação biométrica, diversos fatores limitaram sua propagação devido a alguns dos processos poderem ser bastante intrusivos, incômodos e/ou caros. REFERÊNCIAS: [1] Bonneau, J., Herley, C., van Oorschot, P. C., & Stajano, F. (2012, May). The quest to replace passwords: A framework for comparative evaluation of web authentication schemes. In Security e Privacy (SP), 2012 IEEE Symposium on (pp. 553-567). IEEE. [2] Burr, W. E., Dodson, D. F., & Polk, W. T. (2006). Electronic authentication guideline. NIST Special Publication, 800, 63. [3] Dalton, M., Kozyrakis, C., e Zeldovich, N., Nemesis: Preventing Authentication & Access Control Vulnerabilities in Web Application, In Proceedings of the 18th conference on USENIX security symposium, (pp. 267-282) USENIX Association. [4] Evans, D., Bond, P., Bement, A., Security Requirements for Cryptographic Modules, FIPS PUB 140-2 - FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION. Online Resource: http://csrc.nist.gov/publications/fips/fips140- 2/fips1402.pdf [5] McGloin M. & Hunt P. (2013, January) OAuth 2.0 Threat Model and Security Considerations. ISSN: 2070-1721. Online resource: http://tools.ietf.org/pdf/rfc6819.pdf. [6] Sun, F., Xu, L., & SU,Z. (2011,August) Static detection of Access control vulnerability in web applications. In Proceedings of the 20th USENIX conference on Security (pp. 11-11). USENIX. [7] Wang, R., Zhou, Y., Chen, S., Qadeer, S., Evans, D., & Gurevich, Y. (2013). Explicating SDKs: Uncovering Assumptions Underlying Secure Authentication and Authorization (Vol. 37). Microsoft Research Technical Report MSR-TR-2013. [8] DAILEY, Matthew D. Authentication Schemes based on Physically Unclonable Functions. 2009. Tesis Doctoral. WORCESTER POLYTECHNIC INSTITUTE. [9] DODIS, Yevgeniy; REYZIN, Leonid; SMITH, Adam. Fuzzy extractors: How to generate strong keys from biometrics and other noisy data. En Advances in cryptology-Eurocrypt 2004. Springer Berlin Heidelberg, 2004. p. 523-540.

SUMÁRIO DA INVENÇÃO

[016] A presente invenção provê, em um primeiro aspecto, um método implementado por computador para operações de segurança em sistemas de autenticação e autorização utilizando informações biométricas, em que um primeiro servidor recebe, de um usuário tendo um dispositivo de computação, uma solicitação a ser registrada em um dos serviços que o primeiro servidor tem e autentica informações de credenciais do usuário, a fim de autorizar a dita solicitação de serviço.

[017] O método implementado por computador provido é caracterizado pelo uso de um segundo servidor, em conexão com o dispositivo de computação de usuário que tem instalado em si um programa dedicado ou aplicativo móvel, para receber, do primeiro servidor, uma primeira solicitação sobre um status associado ao dito usuário, a fim de auxiliar o primeiro servidor na autorização ou rejeição do registro de serviço solicitado. No caso de o registro de serviço solicitado ser autorizado, e outra solicitação ser feita pelo usuário para realizar uma operação no primeiro servidor, o segundo servidor também: recebe uma segunda solicitação do primeiro servidor sobre um status que o usuário estabeleceu para a dita operação; avaliar o status de operação para verificar se o primeiro servidor está permitido a acessar a configuração de usuário para a dita operação e envia o resultado do status de operação ao primeiro servidor.

[018] Então, se o dito resultado for ajustado como válido, um mecanismo de fator de autenticação extra incluindo uma verificação de identidade biométrica de informações biométricas do usuário é utilizado, de modo que se habilite o segundo servidor confirmando a autenticação do usuário, e o segundo servidor incluindo uma senha de única utilização dentro do envio do resultado de status de operação ao primeiro servidor.

[019] As informações biométricas podem incluir uma impressão digital, um escaneamento de voz, um escaneamento facial, um escaneamento de íris, um escaneamento da palma, dentre outros.

[020] De acordo com a invenção, a primeira solicitação realizada pelo primeiro servidor compreende: uma troca de credencial entre o primeiro servidor e o segundo servidor, a fim de prover autenticação mútua; verificação, pelo segundo servidor, do dito status associado do usuário, o dito status associado foi ajustado previamente como válido ou como inválido pelo dito usuário e armazenado em uma memória do segundo servidor; e o envio, pelo segundo servidor, do status associado do usuário ao primeiro servidor.

[021] A troca de credenciais para assegurar a autenticação mútua entre o primeiro servidor e o segundo servidor, é realizada, preferencialmente, por meio de um procedimento de autenticação padrão com base em troca de certificados definindo, como resultado, um canal seguro. A troca é realizada para verificar que tanto um primeiro servidor quanto segundo servidor são quem reivindicam ser.

[022] O segundo servidor pode notificar o usuário no caso de a dita solicitação a ser registrada em um serviço do primeiro servidor ser rejeitada. Por exemplo, pelo envio de um Serviço de Mensagem Curta (SMS), de um e-mail, de ou uma mensagem por um aplicativo de envio de mensagem de smartphone, ou somente ao destacar ou impulsionar no dito programa dedicado do dito dispositivo de computação de usuário.

[023] O status associado é estabelecido como válido (destravado) ou como inválido (travado) por um determinado período de tempo e pode ser modificável pelo usuário sempre que desejar após isso. Por exemplo, o usuário pode planejar uma política de travamento/destravamento para automatizar a administração de suas contas mantidas com diferentes servidores utilizando diferentes critérios: hora, geolocalização (diferentes políticas para casa, trabalho etc.). Outra possibilidade para modificar o dito status associado pode ser ao delegar o controle que o dito usuário tem de suas contas a outros usuários. Isso pode ser feito ao considerar duas opções diferentes. Na primeira, um mecanismo de controle parental é utilizado, assim controle de acesso de contas de crianças (original) é delegado ao mecanismo de controle de pais. Na segunda, uma única conta permite múltiplas travas. Nesse último caso, a ação de destravar precisará que múltiplos usuários destravem suas travas de maneira simultânea. Em ambos os casos, a delegação é realizada de maneira segura mantendo a privacidade de cada usuário inalterada.

[024] Além disso, a solicitação a ser registrada em um serviço e/ou a solicitação para realizar uma operação pode ser registrada a fim de prover dados estatísticos. Dessa forma, o usuário pode obter dados estatísticos de uso do sistema que refletem a atividade do sistema e rastrear as tentativas da imitação. Esses dados estatísticos informam sobre quando alguém tentou acessar um serviço com o nome de usuário do usuário.

[025] De acordo com uma realização, o mecanismo de fator de autenticação extra incluindo a verificação de identidade biométrica de informações biométricas do usuário e geração de tokens que podem ser utilizados como senhas de única utilização (OTP) é realizada pelo segundo servidor por:

[026] recuperação de uma assinatura biométrica armazenada previamente do usuário e um vetor de ponderações desta;

[027] seleção de um conjunto de coeficientes da dita assinatura biométrica armazenada a ser utilizada como chave criptográfica, hash do conjunto selecionado de coeficientes para produzir uma chave válida, e geração de uma sequência auxiliadora; e

[028] cifragem da OTP com a chave válida produzida e envio da OTP cifrada junto pelo menos à sequência auxiliadora gerada ao programa dedicado...

[029] Após isso, o programa dedicado captura uma assinatura biométrica do usuário, a dita assinatura biométrica capturada sendo capturada ao empregar a mesma técnica biométrica como a dita assinatura biométrica armazenada; e utiliza a sequência auxiliadora recebida para determinar o conjunto de coeficientes a ser utilizado pelo menos para a dita assinatura biométrica capturada do usuário e realiza hash do conjunto de coeficientes para produzir a chave válida para decifragem da OTP recebida.

[030] Preferencialmente, a assinatura biométrica do usuário e o vetor de ponderações são armazenados no segundo servidor após o programa dedicado ter executado um procedimento de treinamento. O procedimento de treinamento inclui a captura de diferentes medidas biométricas do usuário de acordo com padrões predefinidos gerados pelo segundo servidor e o processamento das medidas biométricas para a realização do cálculo da assinatura biométrica e do vetor de ponderações.

[031] Como uma melhoria da invenção, um número aleatório também pode ser empregado, como um salto criptográfico, para aumentar a entropia da chave criptográfica e para evitar ataques de repetição na geração da sequência auxiliadora.

[032] Em um segundo aspecto, a invenção propõe um sistema de comunicação para operações de segurança em sistemas de autenticação e autorização utilizando informações biométricas, em que um primeiro servidor é configurado para receber de um usuário tendo um dispositivo de computação, uma solicitação a ser registrada em um serviço nele e para autenticar informações de credenciais do dito usuário, a fim de autorizar a dita solicitação de serviço.

[033] O sistema de comunicação é caracterizado pela inclusão de um segundo servidor, em conexão com o dito dispositivo de computação de usuário que tem instalado em si um programa dedicado, que é configurado para: - receber, do primeiro servidor, uma primeira solicitação sobre um status associado ao dito usuário a fim de auxiliar o primeiro servidor na autorização ou rejeição do registro de serviço solicitado; - receber, do primeiro servidor, e no caso do dito registro de serviço solicitado ser autorizado e uma solicitação ser feita pelo usuário para realizar uma operação no primeiro servidor, uma segunda solicitação sobre um status que o usuário estabeleceu para a dita operação; - avaliar o status de operação para verificar se o primeiro servidor é permitido a acessar a configuração de usuário para a dita operação; e - enviar o resultado do status de operação ao primeiro servidor incluindo uma senha de única utilização (OTP), no caso de o resultado ter sido ajustado como válido e um mecanismo de fator de autenticação extra incluindo uma verificação de identidade biométrica de informações biométricas do usuário é utilizada.

[034] No sistema de comunicação para realizar o mecanismo de fator de autenticação extra incluindo a verificação de identidade biométrica de informações biométricas do usuário, o segundo servidor preferencialmente inclui uma pluralidade de módulos que ainda são configurados para: - recuperar, por um módulo biométrico de servidor, uma assinatura biométrica armazenada previamente do usuário e um vetor de ponderações desta; - selecionar, por um módulo de geração, um conjunto de coeficientes da dita assinatura biométrica armazenada a ser utilizado como chave criptográfica, hash do conjunto selecionado de coeficientes para produzir uma chave válida, e gerar uma sequência auxiliadora; e - cifrar, por um módulo de cifra, a OTP gerada com a chave válida produzida e envio, por um módulo de envio, da OTP cifrada junto pelo menos à sequência auxiliadora gerada ao programa dedicado.

[035] Ademais, o programa dedicado preferencialmente também inclui uma pluralidade de módulos que são configurados para: - capturar, por um módulo biométrico, uma assinatura biométrica do usuário; - receber, por um módulo receptor, a OTP cifrada enviada junto à sequência auxiliadora gerada e a assinatura biométrica capturada do usuário; - determinar, por um módulo de reprodução utilizando pelo menos a sequência auxiliadora gerada, o conjunto de coeficientes a ser utilizado para a dita assinatura biométrica capturada do usuário e para realizar hash do conjunto de coeficientes para produzir a chave válida; e - decifrar, por um módulo de decifragem, a OTP recebida utilizando a chave válida produzida.

[036] O assunto aqui descrito pode ser implementado em software em combinação com hardware e/ou firmware, ou uma combinação adequada destes. Por exemplo, o assunto aqui descrito pode ser implementado em software executado por um processador.

[037] De acordo com um terceiro aspecto, a invenção provê um programa de computador compreendendo meios de código de programa de computador adaptados para realizar as etapas de acordo com o método implementado por computador do primeiro aspecto da invenção, quando o dito programa estiver executando em um computador, um processador de sinal digital, uma matriz de porta de campo programável, um circuito integrado específico por aplicação, um microprocessador, um microcontrolador, ou qualquer outra forma de hardware programável.

[038] As realizações da invenção também compreendem um produto de programa de computador incluindo meios de código de programa adaptados para realizar outras realizações da invenção, de acordo com os métodos, de acordo com as reivindicações 3, ou 5.

BREVE DESCRIÇÃO DOS DESENHOS

[039] As vantagens e aspectos anteriores e outros serão mais profundamente entendidos a partir da descrição detalhada das realizações a seguir, com referência aos anexos, que devem ser considerados de maneira ilustrativa e não limitante, em que:

[040] A Figura 1 é uma ilustração da arquitetura geral da presente invenção.

[041] A Figura 2 é um fluxograma que ilustra uma sequência de pareamento de conta com autorização.

[042] A Figura 3 é um fluxograma que ilustra como um status de uma conta de usuário pode ser verificado para autorização.

[043] A Figura 4 ilustra a estrutura geral do mecanismo proposto para reforçar o mecanismo de fator de autenticação extra ao incluir uma verificação de identidade biométrica de informações biométricas do usuário.

[044] A Figura 5 ilustra a estrutura proposta para o procedimento de geração proposto (Gen).

[045] A Figura 6 ilustra a estrutura proposta para o procedimento de reprodução proposto (Rep).

[046] A Figura 7 é o fluxograma que ilustra a realização na qual o fator de autenticação extra proposto é reforçado com informações biométricas do usuário.

[047] A Figura 8 é o fluxograma que ilustra o processo de treinamento proposto pela invenção.

DESCRIÇÃO DETALHADA DA INVENÇÃO E DAS DIVERSAS REALIZAÇÕES

[048] Com referência à Figura 1, é apresentada a arquitetura geral da presente invenção. Referente à Figura 1, um dispositivo de computação de usuário 100, como um telefone móvel, um smartphone, um PC-Tablet ou um PDA dentre quaisquer outros, é utilizado pelo dito usuário, a fim de registrar-se em um programa dedicado 102 em comunicação com um segundo servidor 200 e para administrar o status para cada um primeiro servidor 300 com o qual um usuário deseja solicitar um serviço.

[049] Com essa nova proposta, o dito usuário 100 pode desbloquear a dita operação definida para uma conta particular criada com o dito um primeiro servidor 300. Conforme declarado abaixo, essa ação pode aprimorar o controle definido para essa conta por decisão do primeiro servidor 300. Nessa decisão, o primeiro servidor 300 pode escolher incorporar um novo controle de segurança além da opção padrão de bloqueio/desbloqueio ou segundo mecanismo de fator de autenticação. Esse controle de segurança consiste em prover um canal de comunicação do usuário 100 ao primeiro servidor 300, por meio do segundo servidor 200. O primeiro servidor 300 pode configurar o sistema para solicitar ao usuário 100 uma informação particular relacionada à dita operação a ser realizada. Essas informações podem ser utilizadas pelo segundo servidor 200 para verificar se o usuário 100 é quem realmente está pleiteando a dita operação e para confirmar se a operação que chegou ao primeiro servidor 300 é exatamente aquele que o usuário 100 solicitou.

[050] Presumindo que o primeiro servidor 300 poderia desejar verificar a integridade da operação, podem ser selecionados quais parâmetros são cruciais para garantir a integridade da operação. Nesse caso, é importante que as informações solicitadas correspondam de maneira unívoca com o parâmetro crucial de operação, a fim de identificá-lo corretamente.

[051] Nessa arquitetura, o usuário 100, além de ter uma conta no segundo servidor 200, pode ter múltiplas contas com diferentes provedores de serviço. Um desses provedores de serviço é o primeiro servidor 300. Uma vez que o usuário 100 conclui o processo de registro com essas contas, ele ou ela terá acesso a múltiplas operações específicas a cada um dos provedores de serviço. O segundo servidor 200 facilita como o primeiro servidor 300 pode integrar esse controle dentro da lógica de suas aplicações.

[052] Quando um primeiro servidor 300 decidir integrar seus serviços, ele proverá a capacidade de ligar suas contas com as contas que o usuário 100 tem no segundo servidor 200. Quando o usuário 100 decidir estabelecer essa ligação, ela ou ele inicia um processo de pareamento que garante a privacidade completa ao usuário 100. Uma vez que o processo de pareamento é concluído, o usuário 100 pode acessar a configuração do controle da conta com o primeiro servidor 300 de um programa dedicado 102 (isto é, um aplicativo móvel).

[053] Cada vez que as configurações associadas com uma conta são alteradas no dito aplicativo móvel, essa modificação é imediatamente propagada ao segundo servidor 200 para alterar o status da conta que pode ser acessada pelo primeiro servidor 300.

[054] O núcleo do segundo servidor implementa a função principal do segundo servidor 200: trava ou destrava a dita conta do usuário com o primeiro servidor 300 e as operações providas pelo primeiro servidor 300. A fim de fazer isso, o segundo servidor 200 aceita e processa as solicitações de verificação de status enviadas do primeiro servidor 300. Esse segundo servidor 200 também administra todos os dados sobre as ligações com o dito primeiro servidor 300 definida pelo usuário 100 e as solicitações para o pareamento de novos travamentos. O principal é que o usuário 100 nunca seja solicitado sobre quaisquer informações privadas. Uma vez que o usuário 100 cria sua conta com o segundo servidor 200, ele pode estabelecer travas com diferentes provedores de serviço, como o dito primeiro servidor 300. Para ativar essas travas, o segundo servidor 200, de acordo com uma realização, gera um token. Um token exclusivo e a definição de canais seguros são necessários para concluir o processo de pareamento entre o usuário 100 e o primeiro servidor 300. Como resultado desse processo de pareamento, o token criptográfico é enviado do segundo servidor 200 ao primeiro servidor 300, que tem de armazenar essas informações com seus dados pessoais de usuário. Depois, esse token criptográfico será utilizado para solicitar o status de travamento correspondente. O usuário 100 pode modificar o status de suas travas, pela ativação ou configuração das diferentes opções que o segundo servidor 200 provê.

[055] No caso de o usuário 100 ter configurado uma trava com um segundo mecanismo de fator de autenticação (ou extra) por uma conta ou ação particular, o segundo servidor 200 incorporará toda a lógica necessária para a geração e comunicação da OTP. Quando o segundo servidor 200 receber uma solicitação do primeiro servidor 300 solicitando o status de conta do usuário, um segundo fator de autenticação é disparado. Uma OTP é gerada e enviada ao usuário 100. A mesma OTP é enviada ao primeiro servidor 300 junto ao status de conta. Se o status estiver LIGADO e o usuário 100 tiver ativado o segundo fator, o primeiro servidor 300 deve incitar o usuário a introduzir a OTP para proceder com a operação.

[056] Agora, se o usuário 100 tiver configurado uma trava pela dita operação com um fator de integridade para verificar que os parâmetros de operação não foram modificados, o dito segundo servidor 200 incorpora a lógica necessária para obter as informações cruciais do usuário 100 e do primeiro servidor 300 e para verificar se ambos são iguais. O segundo servidor 200 envia o resultado da verificação como o status da conta ao primeiro servidor 300. No caso de não correspondência, o primeiro servidor 300 pode concluir que um intruso pode estar interceptando as informações do usuário 100. O primeiro servidor 300 pode, então, incorporar mecanismos para evitar a fraude e para originar alertas de segurança.

[057] Com referência à Figura 2, é ilustrado um processo de pareamento da conta do usuário 100 do segundo servidor 200 com diferentes contas para diferentes primeiros servidores 300. Na Figura 2, uma vez que um usuário 100, utilizando, por exemplo, o programa dedicado 101, como um navegador, conclui o processo de registro (A-B) com um primeiro servidor 300 (nesse caso particular, um Banco online, uma rede social, um provedor de cartão de crédito etc.), o usuário 100 decide realizar o dito processo de pareamento de contas. O usuário 100 solicita o pareamento ao primeiro servidor 300 (C) utilizando o navegador 101. Como resposta, o primeiro servidor 300 solicita um token de pareamento (D). O usuário 100, então, utiliza o programa dedicado 102 (D’) para obter esse token de pareamento do segundo servidor 200, após um processo de registro anterior. O segundo servidor 200 gera um token (por exemplo, como uma OTP) (E) e o envia ao programa dedicado do usuário 102 (F). Esse token pode ser utilizado para diversos processos de pareamento, enquanto for válido. O usuário obtém o token (OTP) do programa dedicado 102 e o introduz na página da web exibida no navegador 101 pelo primeiro servidor 300 (G-G’). O primeiro servidor 300, então, envia o token recebido ao segundo servidor 200, após uma troca de credenciais anterior (H). Se a identidade do primeiro servidor 300 for validada, o segundo servidor 200 armazena a ligação entre o usuário 100 e o primeiro servidor 300 e gera um novo token que identifica essa ligação. Esse token (accountID) é enviado ao primeiro servidor 300 (I) e é armazenado para comunicações futuras (J). No fim, reconhecimentos de pareamento são enviados ao navegador do usuário 101 (K).

[058] Com referência, agora, à Figura 3, é ilustrado como um status de uma conta de usuário pode ser verificado para autenticação. Na Figura 3, um usuário 100, utilizando, por exemplo, um navegador 101, solicita que seja registrado em um serviço (A) de um primeiro servidor 300, assim, uma vez que a existência do usuário foi validada (B) pelo dito primeiro servidor 300, o último solicita ao segundo servidor 200 o status de conta de usuário (C). Então, o segundo servidor 200 inicializa a troca de credenciais antes que o resultado das informações de status de conta seja enviado (D). Com o status de resultado, o primeiro servidor 300 toma a decisão de permitir ou bloquear o acesso de usuário (E).

[059] Em uma realização, se o status de conta for destravado ou válido, mas o segundo fator de autenticação estiver ligado, dentro da pergunta de solicitação de status, o segundo servidor 200 envia uma OTP ao primeiro servidor 300 que tem de empregar para concluir a autenticação. O primeiro servidor 300, então, solicita ao usuário 100 a OTP que será um segundo fator temporal (F). Então, o segundo servidor 200 envia a mesma OTP ao programa dedicado do usuário 102 (G). O usuário 100 recupera a OTP do programa dedicado 102 e a introduz no navegador 101 (H) e a envia ao primeiro servidor 300 (I). O primeiro servidor 300 pode verificar se a OTP enviada por meio do navegador 101 corresponde à recebida com o status de conta (J). Dependendo dos resultados dessa verificação, o primeiro servidor realiza o processo de autenticação (K) e comunica o resultado ao usuário por meio de 101.

[060] Quando um primeiro servidor 300 enviar uma Status_Request, o segundo servidor 200 entende que alguém, com as informações de identificação de serviço adequadas (isto é, ID e senha), está tentando acessar o serviço. Se o status de conta for ajustado como bloqueado, ou se essa solicitação vier em um momento que não está incluído no intervalo definido pelo usuário 100, o segundo servidor 200 registra esse evento como uma tentativa de falsificação. O segundo servidor 200 poderia enviar, de acordo com uma realização, um alerta desse evento ao usuário, se o dito usuário tiver assim configurado (por exemplo, ao enviar um Serviço de Mensagem Curta (SMS), um e-mail, uma mensagem por um aplicativo para enviar mensagens de smartphone, por um destaque ou impulsão no dito programa dedicado 102 do dito dispositivo de computação do usuário 100 etc.) ou somente atualiza os dados estatísticos para uma revisão posterior. Então, o segundo servidor 200 retorna o status associado à conta como travado.

[061] Com o objetivo de melhorar a segurança de qualquer sistema de autorização, o uso do dito segundo servidor 200 é proposto como uma nova camada que dá aos usuários a chance de controlar o acesso aos recursos e procedimentos associados a suas contas, definidos com quaisquer primeiros servidores. Esses recursos e procedimentos são vistos como operações que dependem das ações principais definidas para uma conta (isto é, processo de registro). Essa dependência é estabelecida como uma hierarquia na qual as alterações nas entradas de origem são propagadas a suas crianças.

[062] Além disso, o uso de canais “fora da faixa” permite prover uma solução segura para comunicar os usuários e os provedores de serviço. Até então, a invenção tem incorporada uma troca de OTP utilizando esse canal seguro, a fim de aumentar o nível de autenticação. Agora, o primeiro servidor pode determinar se o usuário 100 deseja que uma operação tenha um status particular (travado ou destravado) e pode verificar se esse usuário 100 está em posse das credenciais de sua conta com o segundo servidor 200 para receber o token utilizado como segundo fator de autenticação. Esse é somente um uso particular que pode ser implantado utilizando esse canal seguro extra conforme também é, por exemplo, o uso desse canal pelos provedores de serviço para alertar os usuários sobre informações de seu interesse particular (por exemplo, anormalidade detectadas com suas credenciais). Nesse ponto, a invenção também aumenta o nível de autenticação da solução, reforçando o segundo fator descrito anteriormente. Esse reforço conta com as informações de biometria para permitir que o segundo servidor 200 verifique se quem está em posse das credenciais necessárias para interagir com o sistema é, de fato, o usuário em si. O objetivo final é proteger o sistema contra roubo das credenciais do usuário. É importante ressaltar que essa solução não significa qualquer proteção se o dispositivo onde os usuários introduzem suas credenciais estiver comprometido (homem no dispositivo).

[063] A invenção considera que o programa dedicado 102 é capaz de capturar e processar os dados biométricos do usuário 100 para produzir uma chave que pode ser utilizada para cifrar e decifrar as informações enviadas do segundo servidor 200 ou pelo primeiro servidor 300 por meio do segundo servidor 200. A origem das informações não afeta o procedimento em si. O fato é que o primeiro servidor 300 pode contar que aquela pessoa que recebe essas informações é quem se espera que seja, devido ao segundo servidor 200 realizar uma verificação biométrica. Em consequência, o mesmo processo é necessário ao segundo servidor 200, mas o primeiro servidor 300 não precisa integrar esses procedimentos. Os esforços realizados pelo primeiro servidor 300 são somente relacionados ao processo das informações (por exemplo, processamento da OTP recebida).

[064] Além disso, na invenção, para administrar o segundo fator de autenticação, o token que será utilizado como OTP não somente comprova que o usuário 100 que está solicitando uma operação tem as credenciais do usuário legítimo do segundo servidor 200, mas também demonstram que esse usuário 100 é quem reivindica ser. Portanto, a proteção para lidar contra o roubo do dispositivo ou as credenciais do usuário do segundo servidor levando em consideração esses dados biométricos é aumentada.

[065] A ideia principal é capaz de gerar uma chave de criptografia dos aspectos biométricos previamente registrados para um usuário particular pelo segundo servidor 200 durante uma fase de treinamento. Essa fase de treinamento supõe que quando o usuário 100 decide operar com um mecanismo de fator de autenticação extra reforçado, ou é o provedor de serviço (um primeiro servidor 300) que configura suas operações dessa forma, o programa dedicado 102 instalado no dispositivo do usuário executa um procedimento de treinamento. Esse procedimento requer que o usuário 100 facilite diferentes medidas biométricas de acordo com modelos pré-fixados. Isso é feito diversas vezes com alterações menores nos padrões subsequentes. Cada vez que o usuário 100 conclui uma medição, o programa dedicado 102 processa os dados biométricos adquiridos e calcula a assinatura biométrica que identifica o usuário 100. Tipicamente, essa assinatura pode ser vista como uma sequência de coeficientes: , em que N é o número máximo de coeficientes que dependem da técnica biométrica empregada.

[066] Um dos tópicos inevitáveis quando qualquer técnica biométrica for empregada é a necessidade de lidar com determinado nível de incerteza nesse cálculo de coeficientes de assinatura biométrica. Isto é, devido à origem das informações a serem processas ser uma característica humana que deve ser medida, a natureza variável intrínseca dessas características ou os problemas relacionados ao processo de medição, comumente, torna menos provável obter exatamente os mesmos coeficientes para a mesma pessoa para cada processo de medida. Por este motivo, na invenção, o objetivo final dessa fase é fazer o perfil de cada usuário 100 com dois vetores utilizando uma coleção pré- fixada de padrões: um vetor cujos coeficientes são o coeficiente biométrico retornado pela técnica biométrica(C), e outro vetor com a incerteza associada com cada um desses coeficientes (O .

[067] Com base nas informações dadas pelo vetor o, é possível determinar quais coeficientes biométricos definem o usuário correspondente com menos incerteza. Entretanto, esse é agnóstico do significado dos coeficientes. Dependendo da técnica biométrica aplicada, a significância em termos de poder discriminatório dos coeficientes não precisa ser homogênea. Alguns desses coeficientes podem ser mais valiosos que outros na verificação de identidade de um determinado falante (usuário), de modo que possa ser definido um vetor de ponderações W:

, onde Ti e Oi representam a significância do coeficiente i em uma verificação de falante particular e a incerteza desse coeficiente medido durante a fase de treinamento respectivamente. Cada componente

determinaria a eficácia da contribuição do coeficiente i no processo de reconhecimento de usuário geral.

[068] Para a fase de treinamento, dois modos de operação foram projetados para ganhar em flexibilidade: o primeiro modo implica em enviar todos os dados associados ao processo realizado em cada palavra ao segundo servidor 200 uma vez que todas as repetições sejam concluídas. Depois, no segundo servidor 200, uma vez que todas as repetições foram recebidas, é possível selecionar qual método aplicar para determinar o nível de incerteza associado a um falante particular e obter o nível de incerteza relacionado a cada coeficiente de sua assinatura biométrica. O segundo modo leva vantagem desses dispositivos móveis de alta capacidade de computação que pode assumir o custo de desempenho de execução de todos os procedimento expostos antes. Portanto, esse modo alcança uma transmissão que contém os coeficientes médios e o vetor de tolerância calculado, relacionado a um usuário particular e seu nível associado de incerteza.

[069] Com referência à Figura 4, essa figura ilustra a arquitetura geral para reforçar o mecanismo de fator de autenticação extra com uma verificação de identidade biométrica do usuário 100. O procedimento executado para obter uma chave criptográfica da biométrica proposta tem base no uso de um extrator difuso construído de esboços seguros [8] [9]. Por definição, um extrator difuso é um par de procedimentos randomizados: geração (Gen) 202 e reprodução (Rep) 105. Dados os coeficientes derivados da técnica biométrica empregada (C), o procedimento Gen produz uma sequência K e uma sequência auxiliadora P como saída. Ambas dependem de técnicas incluídas na definição de Extrato Difuso. Na invenção, uma vez que são produzidas, a sequência K é a chave de cripto que pode ser utilizada para cifrar a mensagem em um módulo de cifra 204 (isto é, o token utilizado como OTP) e a sequência P pode ser utilizada para lidar com a variabilidade relacionada ao uso de técnicas biométricas. O procedimento Rep obtém como entradas os coeficientes biométricos calculados por um módulo biométrico 103 do programa dedicado 102 de um sinal de áudio (C’) e a sequência auxiliadora P e, se C’ estiver próximo o suficiente de C, produz a sequência K que pode ser utilizada para decifrar 106 a mensagem. Assim, de um ponto de vista geral, para lidar com a incerteza relacionada às técnicas biométricas, é necessário agrupar com a mensagem cifrada (por exemplo, EK[OTP]) a sequência auxiliadora P.

[070] O processo começa quando um padrão particular é selecionado para um usuário específico (ID de Usuário). Esse padrão depende da técnica biométrica empregada e é proposto para expandir o espaço definido pelos aspectos que essa técnica é capaz de extrair de um usuário. Por exemplo, se a técnica biométrica utilizada tiver base na voz do usuário, esse padrão pode ser um subconjunto das palavras utilizadas durante o treinamento do sistema (por exemplo, no caso de técnicas com base em texto pré-fixado) ou um filtro sintético utilizado no caso de técnicas sem um texto pré- fixado. Nessa figura, aparecem dois módulos - Módulo de Envio 205 e Módulo Receptor 104 - que modelam qualquer esquema de comunicação seguro com base em criptografia de chave pública (KP)/Privada (KPR) (por exemplo, SSL).

[071] Conforme declarado antes, a invenção oferece proteção contra vazamento de credenciais ou roubo de dispositivo. Portanto, a invenção é projetada para ser resistente contra ataques de repetição ou ataques de força bruta implantados uma vez que as credenciais são comprometidas. Além disso, o projeto proposto leva em consideração que parte da solução será executada em um dispositivo de computação de baixo desempenho, como um smartphone etc. Para lidar com esses assuntos, a alternativa empregada nessa invenção significa propor um projeto particular desses procedimentos Gen e Rep. Alguma modificação pode ser vista na Figura 4, onde o módulo de geração 202 não somente recebe o vetor de coeficiente biométrico, mas também recebe informações relacionadas à precisão de quaisquer desses coeficientes (W)...

[072] A Figura 5 ilustra o procedimento Gen proposto 202 reforçado com o uso de hashes e valores aleatórios, e a Figura 6 ilustra o procedimento Rep correspondente 105. Uma vez que o procedimento Gen recebe o vetor (W) cujos coeficientes dão informações sobre a incerteza de quaisquer estimadores biométricos, um subconjunto (a>) desses estimadores é definido. A seleção de estimadores desse subconjunto depende de dois aspectos: desempenho e segurança. O número de elementos contidos em rn impacta no desempenho do procedimento Rep. Devido a Rep dever ser executado pelo programa dedicado 102 em um dispositivo de computação de baixo desempenho, o número de elementos em rn pode ser parametrizado e, depois, ajustado de acordo com a energia de computação estimada para cada usuário.

[073] Entretanto, existe um baixo limite no número de elementos. O número de elementos em rn determina quantos coeficientes biométricos são utilizados para produzir uma chave de cripto. Deixando de lado que a complexidade da chave é aumentada pelo uso de uma função hash, as informações exclusivas relacionadas ao usuário 100 são expressas em termos desses coeficientes, assim, é necessário um número mínimo deles. Na verdade, para aumentar a entropia dessa chave de cripto, um número aleatório (x) é adicionado na computação da chave como um salto criptográfico. Então, o subconjunto (O é, então, empregado para determinar quais coeficientes biométricos utilizar para gerar uma chave cripto, e um número aleatório x é adicionado para evitar que o mesmo subconjunto de coeficientes biométricos (c) produza a mesma chave a qualquer momento em que forem selecionados. Esse x impede que invasores construam facilmente uma lista de valores hash para chaves comuns e impede que chaves quebrem esforços de escalamento por muitas comunicações.

[074] Com os vetores rn e C, é possível determinar o subconjunto (c) de coeficientes empregados para gerar uma chave cripto. Para ser capaz de lidar com a variabilidade das técnicas biométricas, um esboço seguro (SS) é proposto para produzir as informações (s) que garantem a recuperação de dados biométricos de um C’ semelhante o suficiente a C. Esses esboços seguros permitem uma construção direta do extrato difuso com a flexibilidade em termos da capacidade de correção de erros. Para evitar qualquer vazamento de informações, um número aleatório (x) é, novamente, empregado para evitar imitação desse s e produzir a sequência auxiliadora P que será enviada ao programa dedicado 102.

[075] Uma vez que o programa dedicado 102 recebe o padrão, ele pode medir, então, os dados biométricos do usuário 100 e obter um C’. Ao mesmo tempo, o programa 102 recupera a P sequência, onde se pode encontrar as informações s para garantir que C possa ser determinado de C’. Os dados contidos na P sequência também facilitam a computação da chave cripto K, uma vez que C é recuperado.

[076] Com referência à Figura 7, é apresentado o processo de verificação de status de operação incluindo o mecanismo de fator de autenticação extra proposto, reforçado com informações biométricas do usuário 100. Essa operação é proposta pelo primeiro servidor 300 incluído na administração da conta. O usuário 100, uma vez que está conectado corretamente no primeiro servidor 300, conforme explicado anteriormente, solicita executar, utilizando, por exemplo, um navegador 101, uma operação relacionada a uma conta (A) do primeiro servidor 300. Essa operação pode ser, por exemplo, para executar alguma ação relacionada aos serviços providos por um primeiro servidor 300 (por exemplo, pagamento de Internet com um cartão de crédito). Assim, uma vez que a existência do usuário foi validada (B) pelo dito um primeiro servidor 300, este faz a correspondência da operação solicitada com a entrada na hierarquia definida por sua conta de usuário (D) e demanda ao segundo servidor 200 esse status de entrada (E).

[077] Então, o segundo servidor 200 inicializa a troca de credenciais antes de avaliar o status de entrada de esquema da origem para a entrada (F). O status da conta do usuário é recuperado e se estiver destravado, a mesma avaliação é realizada com cada etapa estabelecida, até atingir a entrada do esquema. As informações de status de entrada de esquema são enviadas (G) e, com essas informações, o primeiro servidor 300 toma a decisão de permitir ou bloquear o acesso do usuário à operação. Se o status de entrada de esquema estiver destravado e o segundo fator de autenticação for ativado, o segundo servidor 200 envia uma OTP ao primeiro servidor 300 dentro da resposta da solicitação de status de operação. Esse primeiro servidor 300 tem de empregá-la para concluir a autenticação. O primeiro servidor 300 solicita ao usuário 100 a OTP que será um segundo fator temporal (S).

[078] Se o status da entrada do esquema for destravado e o segundo fator de autenticação for reforçado com a verificação de identidade biométrica, então, o segundo servidor 200 tem de recuperar a assinatura biométrica e o vetor de ponderações do armazenamento para o usuário 100 em particular (H). Ao utilizar esses vetores, tem de selecionar um subconjunto de coeficientes a ser utilizado como a semente de uma chave criptográfica robusta (I). Então, o sistema implementado no segundo servidor 200 pode realizar hash desses coeficientes para produzir uma chave válida (J) e gerar uma sequência auxiliadora P que permita lidar com a variabilidade inerente de abordagens biométricas (K). Com a chave cripto, cifra o token utilizado como OTP (L), e a saída desse processo é agrupada à sequência auxiliadora P e todas as informações necessárias que facilitam a tarefa de decifragem dessas informações ao programa dedicado 102 manipulado do usuário 100 (padrão, marcações de tempo etc.).

[079] O segundo servidor 200 envia todas essas informações ao programa dedicado do usuário 102 (M) que recebe as informações e solicita ao usuário 100 que gere uma assinatura biométrica válida, com base no padrão recebido (N). Uma vez que uma nova assinatura biométrica é capturada, o sistema utiliza a sequência auxiliadora P para determinar o subconjunto de coeficientes a ser utilizado como a semente da chave cripto esperada (O). E, então, realiza hash desse subconjunto com outras partes da sequência auxiliadora P para produzir a chave cripto (P) e a utiliza para decifrar a OTP (Q) solicitada pelo primeiro servidor 300 (S). O usuário 100 recupera a OTP do programa dedicado 102 e a introduz no navegador 101 (T) e a envia ao primeiro servidor 300 (U). O primeiro servidor 300 pode verificar se a OTP enviada por meio do navegador 101 corresponde à recebida com o status de conta (V). O primeiro servidor 300 nega a execução da operação se as OTPs não se ajustarem.

[080] A Figura 8 ilustra o processo definido para obter informações biométricas do usuário para realizar o último reconhecimento do usuário. Uma vez que o usuário 100 tenta iniciar uma sessão com o segundo servidor 200 utilizando o programa dedicado 102 instalado em seu dispositivo móvel, ele/ela deve prover credenciais válidas (A) que o segundo servidor 200 verificará (B) antes de confirmar o registro (D). Quando o segundo servidor 200 verificar a correção das credenciais, também recupera as informações de perfil, a fim de saber se há informações biométricas incluídas nela e se essas informações devem existir (C). Se o usuário 100 tiver provido as informações biométricas para interagir com o primeiro servidor 300, deve ser armazenada uma assinatura biométrica válida e um vetor com as informações da tolerância de quaisquer dos coeficientes incluídos nessa assinatura (E).

[081] No caso em que essa assinatura seja necessária, mas não exista no sistema, é necessário solicitar que o usuário 100 participe em um processo de treinamento. Antes do processo de treinamento, um conjunto de padrões é gerado pelo segundo servidor 200 (F) e é enviado ao programa dedicado 102 (G). Uma vez que esse conjunto é recebido no programa dedicado 102, os padrões são utilizados um a um para serem apresentados ao usuário 100, a fim de calcular a assinatura biométrica correspondente (H). No caso apresentado na Figura 8, é o programa dedicado 102 que é responsável por calcular a assinatura biométrica média de todas as amostras pré-calculadas. Durante esse cálculo, é possível determinar a tolerância associada a cada coeficiente (I). Conforme foi explicado antes, essa tolerância dá informações sobre quão discriminatório é um coeficiente no reconhecimento devido desse usuário particular 100. Entretanto, em algumas circunstâncias, pode ser necessário configurar o programa dedicado 102 para enviar os dados obtidos do usuário 100 ao segundo servidor 200 sem processá-los. Nesse caso, os procedimentos biométricos serão computados no segundo servidor 200. Uma vez que a assinatura média e o vetor de tolerância são determinados, eles são enviados ao segundo servidor 200 (J) que os armazena dentro do perfil do usuário 100 (K), prontos para serem utilizados quando uma solicitação de status de operação for recebida e é configurado com esse mecanismo de fator de autenticação extra reforçado.

[082] A invenção proposta pode ser implementada em hardware, software, firmware, ou qualquer combinação destes. Se implementada em software, as funções podem ser armazenadas em ou codificadas como uma ou mais instruções ou código em um meio legível por computador. Meio legível por computador inclui meio de armazenamento de computador. Meio de armazenamento pode ser qualquer meio disponível que possa ser acessado por um computador. A título de exemplo, e não de limitação, esse meio legível por computador pode compreender RAM, ROM, EEPROM, CD-ROM ou outro armazenamento de disco óptico, armazenamento de disco magnético ou outros dispositivos de armazenamento magnéticos, ou qualquer outro meio que possa ser utilizado para carregar ou armazenar código de programa desejado na forma de instruções ou estruturas de dados e que possam ser acessados por um computador. Disco e disco, conforme aqui utilizados, inclui disco compacto (CD), disco laser, disco óptico, disco versátil digital (DVD), disquete e disco Blu-ray, em que discos geralmente reproduzem dados magneticamente, enquanto discos reproduzem dados opticamente com lasers. Combinações do que foi mencionado acima devem ser incluídas dentro do escopo de meio legível por computador. Qualquer processador e o meio de armazenamento podem residir em um ASIC. O ASIC pode residir em um terminal de usuário. Na alternativa, o processador e o meio de armazenamento podem residir como componentes diferentes em um terminal de usuário.

[083] Conforme aqui utilizado, produtos de programa de computador compreendendo meio legível por computador incluindo todas as formas de meio legível por computador exceto, na medida em que esse meio é considerado por ser sinais de propagação transitórios, não regulamentares.

[084] O escopo da presente invenção é definido no seguinte conjunto de reivindicações.

Claims

1 . MÉTODO IMPLEMENTADO POR COMPUTADOR PARA SEGURANÇA DE OPERAÇÕES EM SISTEMAS DE AUTENTICAÇÃO E AUTORIZAÇÃO UTILIZANDO INFORMAÇÕES BIOMÉTRICAS, em que um segundo servidor (200), em conexão com um dispositivo de computação de um usuário (100) que tem instalado em si um segundo programa dedicado (102), é usado para gerenciar um status das contas que o usuário (100) tem em um primeiro servidor (300) e um status das operações definidas para uma conta particular, o dito status de conta e o dito status de operação sendo definidos, sempre que o usuário (100) quiser, como válido ou como inválido pelo usuário (100) através do segundo programa dedicado (102) e armazenado em uma memória do segundo servidor (200), e o dito status de conta e dito status de operação sendo definidos pelo usuário (100) uma vez que um processo de pareamento com o segundo servidor (200) é concluído, o dito processo de pareamento garantindo privacidade para o usuário (100), o método caracterizado por compreender: - recepção, por dito primeiro servidor (300), do usuário (100) por meio de um primeiro programa dedicado (101) incluindo um navegador, de uma solicitação a ser registrada em um serviço do dito primeiro servidor (300), a dita solicitação incluindo a provisão de informações de identificação que validam a identidade do usuário (100) no primeiro servidor (300); - autenticação, pelo dito primeiro servidor (300), de ditas informações de identificação do usuário (100) a fim de autorizar a dita solicitação de registro de serviço; - solicitação, pelo usuário (100), por meio do primeiro programa dedicado (101), uma vez que a solicitação de registro de serviço seja autenticada pelo primeiro servidor (300), para realizar uma operação no primeiro servidor (300) associado ao serviço solicitado; - recepção, pelo segundo servidor (200), do primeiro servidor (300), de uma solicitação sobre um status de operação associado ao o que o usuário (100) estabeleceu para a dita operação solicitada, a fim de auxiliar o primeiro servidor (300) na autorização ou rejeição da operação solicitada; - verificação, pelo segundo servidor (200), do dito status de operação estabelecido previamente pelo usuário (100) para a dita operação solicitada, e se o resultado do dito status de operação sendo estabelecido como válido pelo usuário (100), geração, pelo segundo servidor (200), de um mecanismo de fator de autenticação extra, compreendendo as seguintes etapas: - recuperação, pelo segundo servidor (200), de uma assinatura biométrica armazenada previamente do usuário (100)

e um vetor de ponderações (W) seu; - seleção, pelo segundo servidor (200), de um conjunto de coeficientes

da dita assinatura biométrica armazenada

a ser utilizada como chave criptográfica, hash do conjunto selecionado de coeficientes

para produzir uma chave válida (K), e geração de uma sequência auxiliadora (P); - cifragem, pelo segundo servidor (200), da OTP (one-time password) com a chave válida produzida (K) e envio da OTP cifrada junto a pelo menos a sequência auxiliadora gerada (P) ao segundo programa dedicado (102); - captura, pelo segundo programa dedicado (102), de uma assinatura biométrica do usuário (100)

a dita assinatura biométrica capturada

sendo capturada ao empregar a mesma técnica biométrica que a dita assinatura biométrica armazenada

e - utilização, pelo segundo programa dedicado (102), da sequência auxiliadora recebida (P) para determinar o conjunto de coeficientes

a ser utilizado pelo menos para a dita assinatura biométrica capturada do usuário (100)

e hash do conjunto de coeficientes

para produzir a chave válida para decifragem da OTP cifrada; e - envio, pelo segundo servidor (200), da dita OTP dentro do envio do dito resultado do status de operação ao primeiro servidor (300), a fim de que o último empregue a OTP recebida para proceder com a operação solicitada.

2. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, em que a dita solicitação feita pelo primeiro servidor (300) ao segundo servidor (200) é caracterizada por compreender uma troca de credencial entre o primeiro servidor (300) e o segundo servidor (200), a fim de prover autenticação mútua.

3. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado pela assinatura biométrica do usuário (100)

e o vetor de ponderações (W) serem armazenados no segundo servidor (200) após o segundo programa dedicado (102) ter executado um procedimento de treinamento.

4. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 3, caracterizado pelo procedimento de treinamento incluir a captura de diferentes medidas biométricas do usuário (100), de acordo com padrões predefinidos gerados pelo segundo servidor (200), e o processamento das medidas biométricas para calcular adicionalmente a dita assinatura biométrica

e o dito vetor de ponderações (W).

5. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado por compreender ainda o emprego de um número aleatório (x), como um salto criptográfico, para aumentar a entropia da chave criptográfica e para evitar ataques de repetição na geração da sequência auxiliadora (P).

6. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com qualquer uma das reivindicações 1 a 5, caracterizado pelas informações biométricas incluírem pelo menos um dentre uma impressão digital, um escaneamento de voz, um escaneamento facial ou um escaneamento de íris.

7. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, em que o segundo servidor (200) notifica o usuário (100) se a solicitação a ser registrada em um serviço do dito primeiro servidor (300) for rejeitada, a dita notificação é caracterizada por compreender um dentre um envio de um Serviço de Mensagem Curta (SMS), um envio de um e-mail, um envio de uma mensagem por um aplicativo de envio de mensagem de smartphone, e/ou um destaque ou impulso do dito segundo programa dedicado (102) do dito dispositivo de computação de usuário.

8. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 2, caracterizado pelo dito status de operação ser ajustado como válido ou como inválido por um determinado período de tempo.

9. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado pela solicitação a ser registrada em um serviço do primeiro servidor (300) e/ou a solicitação para realizar uma operação no primeiro servidor (300) serem registradas a fim de prover dados estatísticos.

10. SISTEMA DE COMUNICAÇÃO PARA SEGURANÇA DE OPERAÇÕES EM SISTEMAS DE AUTENTICAÇÃO E AUTORIZAÇÃO UTILIZANDO INFORMAÇÕES BIOMÉTRICAS, compreendendo um primeiro servidor (300) configurado para receber, de um usuário (100) por meio de um primeiro programa dedicado (101) incluindo um navegador, uma solicitação a ser registrada em um serviço nele e para autenticar informações de identificação do dito usuário (100) no primeiro servidor (300) a fim de autorizar a dita solicitação de registro de serviço, caracterizado por compreender ainda: um segundo servidor (200), em conexão com um dispositivo de computação do usuário (100) que tem instalado em si um segundo programa dedicado (102), configurado para: - receber, do segundo programa dedicado (102), sempre que o usuário (100) quiser, informações de configuração que o usuário (100) estabeleceu para as operações providas pelo primeiro servidor (300), as ditas configurações compreendendo uma indicação de que uma operação é permitida, ou estabelecida como válida, pelo usuário (100) ou que uma operação não é permitida, ou estabelecida como inválida, pelo usuário (100), e as configurações sendo estabelecidas uma vez que um processo de pareamento entre o segundo servidor (200) e o usuário (100) é concluído, o processo de pareamento garantindo privacidade ao usuário (100); - receber, do primeiro servidor (300), uma solicitação sobre um status de operação associado ao o que o dito usuário (100) estabeleceu para a dita operação solicitada, a fim de auxiliar o primeiro servidor (300) na autorização ou rejeição da operação solicitada; - verificar o dito status de operação estabelecido previamente pelo usuário (100) para a dita operação solicitada; - gerar, no caso do resultado do dito status de operação ser ajustado como válido pelo usuário (100), um mecanismo de fator de autenticação extra pelo segundo servidor (200) incluindo uma pluralidade de módulos configurados para: - recuperação, por um módulo biométrico de servidor (201), de uma assinatura biométrica armazenada previamente do usuário (100)

e um vetor de ponderações (W) seu; - seleção, por um módulo de geração (202), de um conjunto de coeficientes

da dita assinatura biométrica armazenada

para produzir uma chave válida (K), e geração de uma sequência auxiliadora (P); e - cifragem, por um módulo de cifra (204), da OTP com a chave válida produzida (K) e envio, por um módulo de envio (205), da OTP cifrada junto com pelo menos a sequência auxiliadora gerada (P) ao segundo programa dedicado (102); e pelo segundo programa dedicado (102) incluir uma pluralidade de módulos configurados para: - capturar, por um módulo biométrico (103), uma assinatura biométrica do usuário (100)

- receber, por um módulo receptor (104), a OTP cifrada enviada juntamente com a sequência auxiliar gerada (P) e a assinatura biométrica capturada do usuário (100)

- determinar, por um módulo de reprodução (105), usando pelo menos a sequência auxiliar gerada (P), o conjunto de coeficientes

a ser usado para a dita assinatura biométrica capturada do usuário (100)

e - hash do conjunto de coeficientes

para produzir a chave válida; e - decifrar, por um módulo de decifração (106), a OTP recebida usando a chave válida produzida; e - enviar o resultado do status de operação e a dita OTP ao primeiro servidor (300), a fim de que o primeiro servidor (300) empregue a OTP para proceder com a operação solicitada.