BRPI0605830A2 - Método para instruir transações eletrônicas a uma instituição - Google Patents

Abstract

METODO PARA INSTRUIR TRANSAÇOES ELETRÔNICAS A UMA INSTITUIÇAO. Refere-se a presente invenção a um método para permitir que um usuário autorize e assine transaç5es eletrônicas utilizando programas token, mesmo que o software utilizado para realizar as transações eletrônicas seja executado no mesmo dispositivo terminal que executa o programa token, como ocorre em telefones celulares. Um usuário utiliza uma aplicação de acesso ou browser (11) para submeter transações eletrônicas (41) através de um dispositivo terminal (10) para uma aplicação (22) de uma instituição 20 não as executando de imediato, deixando-as pendentes (23) . Em seguida, o usuário aciona o programa token (12), que consulta em (42) as transaç5es pendentes (23) em um dispositivo no servidor (21) da instituição (20). O usuário lê a descrição de cada transação aprovando ou não aprovando as transações, que são transmitidas em (43) ou (44) de volta para a aplicação (22) da instituição (20) com a devida autorização ou assinatura, utilizando um segredo capaz de ser interpretado por esta aplicação. Somente as transações corretamente autorizadas/assinadas são concretizadas pela aplicação da instituição.

Description

"MÉTODO PARA INSTRUIR TRANSAÇÕES ELETRÔNICAS A UMA INSTITUIÇÃO" Campo da invenção Refere-se a presente invenção a um método para permitir que um usuário de uma instituição com requisitos de proteção a operações, tal como uma instituição bancária, autorize e assine transações eletrônicas utilizando tokens, dispositivos ou programas equivalentes para autenticação ou assinatura eletrônica, mesmo que o software utilizado para realizar as transações eletrônicas seja executado no mesmo dispositivo que executa o programa token. O método ora proposto é particularmente adequado quando o dispositivo terminal a ser operado pelo usuário da instituição e utilizado para executar as aplicações, não possui a capacidade de executar ambas as aplicações envolvidas simultaneamente. Estado da técnica A proliferação de cavalos-de-tróia, de vírus, equipamentos de espionagem instalados em terminais de auto-atendimento, etc., utilizados por fraudadores para interceptação de senhas de acesso a instituições de acesso protegido, tal como as instituições bancárias, criou a necessidade de novos métodos para garantir uma correta e segura identificação (autenticação) dos usuários da instituição.

Em um extremo do espectro de soluções, encontram-se os tokens físicos e sistemas biométricos, apresentando um alto custo para a sua adoção em larga escala. Os tokens físicos, inicialmente utilizados para a geração de OTP (One-Time Passwords), ou seja, senhas que são utilizáveis uma única vez, passaram a receber cada vez mais recursos, como geração de senhas por evento, por tempo ou desafio-resposta, além de assinatura de transações. Programas token implementados em hardware dedicado possuem custo elevado de fabricação e distribuição. Em contrapartida, há tokens implementados em software que podem rodar em diversas plataformas ou dispositivos, como telefones celulares e PDAs.

Aplicações com maiores requisitos de segurança podem necessitar de algo mais forte que uma simples autenticação do usuário, para autorizar a execução de uma transação, pois há ataques de interceptação que podem permitir a um atacante obter e usar um OTP (one time password). Nestes casos, a operação de assinatura de transações utilizando tokens é bastante conveniente, pois o usuário visualiza as informações que descrevem a transação que ele está autorizando e as assina digitalmente.

Num cenário corriqueiro, por exemplo, quando se acessa uma aplicação de internet banking, uma senha (OTP) gerada por um programa token pode ser solicitada. A cada nova autenticação, uma senha diferente é fornecida, dificultando que um atacante, que intercepta as senhas, as reutilize. Igualmente à autenticação inicial, a cada transação eletrônica efetuada, o sistema de internet banking pode solicitar uma nova senha gerada pelo programa token. Um usuário que utiliza um computador pessoal e um token conseguirá realizar estas operações de navegação no sistema de internet banking e utilização do token sem muitos problemas. Isto normalmente se deve a dois cenários possíveis. No primeiro cenário, o browser de acesso ao internet banking roda em um computador e o token está em um dispositivo separado. Durante a navegação no internet banking, a cada solicitação de operação do programa token, o usuário aciona seu programa token para realizar a operação pedida, como gerar senha ou assinar uma transação. No segundo cenário, o computador pessoal roda tanto o browser quanto o software do token. A cada vez que o sistema de internet banking solicitar uma operação do token, o usuário dispara o programa token ou chaveia (alterna) de tarefa para o programa token caso ele já esteja rodando, sem finalizar a sessão do internet banking. Realizada a operação do token solicitada, o usuário chaveia de tarefa novamente, retornando para o browser e fornece o dado fornecido pelo programa token. De modo resumido, no primeiro cenário há a independência de dispositivos e no segundo, a capacidade de chavear tarefas em um mesmo dispositivo sem terminá-las.

Um cenário que, em muitos casos, não possui as características de independência de dispositivos e a capacidade de chavear tarefas acima descritas é o uso de aparelhos de telefone celulares para o acesso de um mobile banking (banking para dispositivos móveis) com a utilização de um token de software que roda neste mesmo aparelho. Como se trata de apenas um dispositivo, a independência de dispositivos é naturalmente inexistente. A capacidade de rodar duas aplicações simultâneas, como um browser e um programa token ou simplesmente token, é inexistente na maioria dos aparelhos atuais. Conseqüentemente, não é possível chavear entre estas aplicações sem terminar a que está sendo executada.

Um usuário que desejar se autenticar no sistema acessado pelo browser, teria que memorizar uma senha gerada pelo programa token, terminar a aplicação do token, acionar o browser e fornecer esta senha para autenticação. Porém, a aplicação acessada pelo browser não poderia solicitar outras operações do token sem terminar o acesso com o browser, pois o usuário seria obrigado a terminar a aplicação atual para acionar o programa token em seguida. Esta limitação torna o uso do programa token muito inconveniente em dispositivos com estas características. Nos poucos dispositivos em que o chaveamento é permitido, ainda há o inconveniente de a operação ser pouco prática, exigindo o pressionamento de uma série de botões, o que é suscetível à introdução de erros no processo.

Sumário da invenção Em função das limitações acima mencionadas e presentes em diversos dispositivos, é um objetivo da presente invenção prover um método que permita a um usuário submeter, autorizar e/ou assinar transações eletrônicas, com uma instituição protegida, utilizando um dispositivo terminal capaz de executar, de modo não simultâneo, uma aplicação, por meio da qual o usuário submete as transações a um sistema de interação da instituição, e um programa token para realizar as operações de autorização e assinatura. Isto pode ser concretizado com a utilização de um novo tipo de programa token com características especiais de autorização e assinatura de transações. Além disto, é necessário criar ou modificar aplicações para que não funcionem no modo tradicional para a execução de transações.

Aplicações tradicionais normalmente aceitam transações para serem executadas mediante uma autenticação do usuário ou assinatura realizada logo em seguida à especificação da transação. Isto quer dizer que a aplicação deve estar ativa desde o instante em que o usuário especifica qual transação quer efetuar até o instante em que o sistema libera a transação para ser concretizada. Esta liberação ocorre logo após o fornecimento da autenticação ou operação de assinatura realizada pelo programa token.

Para esta invenção, as aplicações devem adotar uma nova abordagem, deixando as transações pendentes, pois sofrerão a concretização em uma etapa posterior à sua especificação e submissão. Nestas outras etapas é que o programa token será acionado para autorizar as transações e permitir que elas sejam concretizadas. Num cenário de duas etapas, quando o usuário aciona o programa token, este se conecta ao servidor da instituição, verificando se há transações pendentes. Cada transação pendente é apresentada para o usuário, que pode autorizar ou desautorizá-la. O resultado desta autorização é devolvido para o servidor da instituição, que concretiza ou não cada transação, conforme selecionado pelo usuário.

Na solução em questão, a instituição é provida de uma determinada aplicação e de um dispositivo servidor capaz de executá-la quando acionado, por um canal de comunicação, a partir de pelo menos um dispositivo terminal operado por um respectivo usuário da instituição para executar, de modo não simultâneo, uma aplicação de acesso e um programa de token.

De acordo com a invenção, o método compreende as etapas de : acessar, eletronicamente, a aplicação no dispositivo servidor da instituição, a partir da aplicação de acesso de um dispositivo terminal do usuário e através do canal de comunicação; submeter, à aplicação do dispositivo servidor da instituição, a partir da aplicação de acesso do dispositivo terminal e através do canal de comunicação, uma instrução de execução de pelo menos uma transação eletrônica; acionar o programa token no dispositivo terminal do usuário, para um dos modos "autorização" e "assinatura" de transações; - receber, no programa token, do dispositivo terminal e através de um respectivo canal de comunicação, instrução de execução da transação eletrônica ainda pendente na aplicação da instituição; acionar o programa token para definir uma das instruções de "autorização", "não-autorização" e "assinatura" da transação instruída; e - transmitir, para a aplicação do dispositivo servidor da instituição, a partir do programa token do dispositivo terminal do usuário e através do respectivo canal de comunicação, uma instrução representativa de uma das condições de "autorização", "não autorização" e "assinatura" da transação eletrônica instruída à instituição;

Breve descrição dos desenhos A invenção será descrita a seguir, fazendo-se referência aos desenhos anexos, dados a título de exemplo de uma concretização da invenção e nos quais: A figura 1 representa um diagrama esquemático dos elementos que compõem a invenção, ilustrando a interação entre os ditos elementos; e A figura 2 representa um diagrama esquemãtico das aplicações que compõem a invenção, ilustrando detalhes de comunicação entre elas e fases de processamento de transações.

Descrição da invenção Como pode ser observado pela figura 1, o método em questão é particularmente adequado â interação entre o usuário utilizando um dispositivo terminal 10, tal como um telefone celular e uma instituição 20 provida de um dispositivo servidor 21, para realizar transações eletrônicas que necessitam de autorização, autenticação ou assinatura. O dispositivo terminal 10, em forma de telefone celular, evidencia bastante as vantagens do método apresentado. Na configuração da figura 1 pode-se observar que no dispositivo terminal 10 é executada uma aplicação de acesso 11 de um usuário. Mais especificamente, o dispositivo terminal 10 executa uma aplicação de acesso 11 ou browser, que permite acessar uma aplicação 22 da instituição 20, descrita adiante, e um programa token 12 . Devido a limitações de muitos dispositivos terminais, duas aplicações diferentes não podem ser executadas simultaneamente, o que inviabiliza executar o programa token 12 em simultaneidade à aplicação de acesso ou browser 11. A aplicação 22 da instituição 20 é executada em um dispositivo servidor 21 e comunica-se com o aparelho celular através de um canal de comunicação 30 adequado qualquer, tal como, por exemplo a rede da operadora ligada à Internet. A aplicação 22 da instituição 20 permite realizar transações eletrônicas que necessitam de autenticação, autorização ou assinatura por parte do usuário desta aplicação. Para contornar a limitação de simultaneidade de execução de aplicações no dispositivo terminal 10, o usuário que deseja realizar transações eletrônicas que necessitam de autenticação, autorização ou assinatura, utiliza o processo objeto desta invenção, operando em duas fases. Na primeira fase é efetuada a submissão de transações e na segunda, a consulta e autorização/assinatura de transações. Estas fases ficam mais claras observando-se a figura 2, onde são apresentadas as trocas de informações entre as aplicações envolvidas.

Na primeira fase, o usuário aciona a aplicação de acesso ou browser 11, que permite que ele registre transações que ele deseja efetuar na aplicação 22 da instituição 20. Estas transações são registradas na instituição 20 pela aplicação 2 2 e marcadas como pendentes 2 3 . Uma transação pendente 2 3 é uma que foi registrada, porém seu efeito não foi concretizado, dependendo de uma ação posterior. Mais precisamente, as transações são concretizadas quando devidamente autorizadas pelo usuário em 43.

Um exemplo seria o de um usuário que deseja realizar uma operação de transferência de dinheiro da sua conta corrente para outra conta. Na primeira fase, ele acessa a aplicação de acesso 11 e especifica a conta destino e o respectivo valor a ser transferido. A aplicação de acesso 11 submete esta transação, em 41, â aplicação 22 da instituição 20, que não executa a transferência monetária e sim a deixa como transação pendente 23.

Na segunda fase, o usuário aciona o programa token 12, que se comunica com a aplicação 22 da instituição 20 e consulta, em 42, as transações pendentes 23. O usuário visualiza cada uma das transações e opta em 43 (ou 44) por autorizar/assinar (ou não-autorizar) cada uma das transações. O programa token 12 então pega o texto que descreve a transação, une uma informação que indica se o usuário autorizou ou não a concretização da transação e realiza operações criptográficas, gerando um bloco de dados transformado por segredos do usuário, como chaves simétricas ou assimétricas e que pode ser conferido pela aplicação 22 da instituição 20. Dependendo da operação criptográfica realizada e dos segredos utilizados, esta operação pode constituir desde uma simples autorização até uma assinatura de transação.

Cada bloco de dados resultante é transmitido para a aplicação da instituição, que o verifica. As transações autorizadas/assinadas 24 são concretizadas. As transações não autorizadas/assinadas 25 são registradas com a devida desautorização.

Deve ser entendido que a aplicação de acesso 11 e o programa token 12 podem ser instalados e executados, geralmente por um mesmo usuário, em um mesmo dispositivo terminal, tal como um telefone celular, ou em respectivos dispositivos terminais 10 distintos, para serem executados pelo mesmo usuário ou por usuários distintos, em momentos diferentes.

Em determinadas situações, é desejável, por exemplo, que a instrução de autorização, não-autorização ou assinatura seja transmitida à instituição 20 após transcorrido um certo tempo, que pode ser limitado pela instituição 20, contado do término da etapa anterior.

Claims (8)

1. Método para instruir transações eletrônicas a uma instituição com requisitos de proteção a operações e provida de uma determinada aplicação (22) e de um dispositivo servidor (21) capaz de executã-la quando acionado, por um canal de comunicação (30) , a partir de pelo menos um dispositivo terminal (10) operado por um respectivo usuário da instituição (20) para executar, de modo não simultâneo, uma aplicação de acesso (11) e um programa de token (12), sendo o método caracterizado pelo fato de compreender as etapas de: acessar, eletronicamente, a aplicação (22) no dispositivo servidor (21) da instituição (20) , a partir da aplicação de acesso (11) de um dispositivo terminal (10) do usuário e através do canal de comunicação (30); - submeter, â aplicação (22) do dispositivo servidor (21) da instituição (20) , a partir da aplicação de acesso (11) do dispositivo terminal (10) e através do canal de comunicação (30), uma instrução de execução de pelo menos uma transação eletrônica; - acionar o programa token (12) no dispositivo terminal (10) do usuário, para um dos modos "autorização" e "assinatura" de transações; receber, no programa token (12), do dispositivo terminal (10) e através de um respectivo canal de comunicação (30), uma instrução de execução da transação eletrônica ainda pendente (23) na aplicação (22) da instituição (20); acionar o programa token (12) para definir uma das instruções de "autorização", "não-autorização" e "assinatura" da transação instruída; e - transmitir, para aplicação (22) do dispositivo servidor (21) da instituição (20), a partir do programa token (12) do dispositivo terminal (10) do usuário e através do respectivo canal de comunicação (30), uma instrução representativa de uma das condições de "autorização", nao autorizaçao" e "assinatura" da transação eletrnrric^ instruída à instituição (20).

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de a aplicação de acesso (11) e o programa token (12) serem instalados e executados em um mesmo dispositivo terminal (10).

3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de o dispositivo terminal (10) ser um telefone celular.

4. Método, de acordo com a reivindicação 2, caracterizado pelo fato de a aplicação de acesso (10) e o programa token (12) serem executados pelo mesmo usuário .

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de a aplicação de acesso (11) e o programa token (12) serem instalados e executados em respectivos dispositivos terminais (10) independentes.

6. Método, de acordo com a reivindicação 4, caracterizado pelo fato de a aplicação de acesso (11) e o programa token (12) serem executados por usuários distintos.

7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de pelo menos uma das etapas de acionar o programa token (12) e de transmitir, para a instituição (20), a instrução definida no programa token (12), serem realizadas após transcorrido um certo período de tempo em relação ao término da etapa anterior.

8. Método, de acordo com a reivindicação 7, caracterizado pelo fato de o período de tempo de espera máximo entre o início da etapa de transmitir, para a instituição (20), a instrução definida no programa token (12) e o término da etapa anterior, ser definido pela instituição (20).