BRPI0902656A2 - segurança de um dispositivo com base em comportamento atìpico do usuário - Google Patents

Abstract

SEGURANçA DE UM DISPOSITIVO COM BASE EM COMPORTAMENTO ATìPICO DO USUáRIO. Um sistema e método para assegurar o dispositivo móvel aplica as regras para determinar se um evento associado à aplicação é um evento seguro. Se o evento for um evento seguro, o sistema aplica as regras para determinar se o evento é autenticado. Se o evento for autenticado, o evento é autorizado e o sistema atualiza dados de regras associadas ao evento e/ou a outros eventos associados. Atualizar os dados de regras permite que outros eventos associados sejam autenticados. Se o evento não for autenticado, o sistema solicita autenticação do usuário. Se a autenticação for válida, o evento é autorizado e o sistema atualiza os dados de regras associados ao evento e/ou a outros eventos associados. Se a autenticação não for válida, o sistema assegura o dispositivo móvel. Autorizar o evento permite ao usuário acessar a aplicação e/ou dados associados à aplicação.

Description

SEGURANÇA DE UM DISPOSITIVO COM BASE EM COMPORTAMENTO

ATÍPICO DO USUÁRIO

CAMPO TÉCNICO

O sistema e método relacionam-se a sistemas desegurança de dispositivo e, em particular, a sistemas desegurança que monitoram o comportamento do usuário emdispositivos móveis.

HISTÓRICO

Como resultado de sua mobilidade, dispositivos decomunicação móvel às vezes perdem-se ou são roubados. Com oaumento da complexidade dos dispositivos móveis, aquantidade de informação sensível neles armazenada tambémaumenta. O resultado e uma necessidade crescente deproteção da informação sensível armazenada nos dispositivosmóveis.

Atualmente, alguns sistemas de segurança paradispositivos móveis exigem que o usuário avise que odispositivo móvel foi perdido ou roubado. Quando danotificação de que o dispositivo móvel foi perdido ouroubado, um administrador pode enviar um comando para odispositivo móvel que pode travar o dispositivo móvel ouapagar informação sensível do dispositivo móvel.Entretanto, para que este método seja eficaz, o usuárioprecisará avisar ao administrador que o dispositivo móvelfoi perdido ou roubado antes de qualquer informaçãosensível ter sido removida do dispositivo móvel. Ademais, odispositivo móvel precisa estar conectado a uma rede parareceber o comando para travar ou apagar o dispositivomóvel.

Sistemas de segurança para dispositivos móveis comoaquele revelado na Publicação de Patente dos Estados Unidosnúmero 2008/0009264 permitem que o dispositivo móvel sejaassegurado enquanto não conectado a uma rede com base emeventos predefinidos limitados como o usuário travar odispositivo, o dispositivo móvel não estar na proximidadede uma cartucheira, desligar a energia do dispositivomóvel, fechar o dispositivo móvel, ou a falta decomunicação com a rede.

Outros sistemas, como aquele revelado na Patente dosEstados Unidos número 7.3 73.13 7, permitem ao usuáriodefinir um conjunto de número de chamadas autorizado. Istoimpede o usuário não-autorizado de fazer chamadas paraqualquer número que não seja autorizado.

O problema com estes sistemas é que eles não monitorameventos seguros e eventos não-seguros para fornecer ummecanismo robusto para assegurar o dispositivo móvel. Comoresultado, esses sistemas são muito limitados em seusmétodos de assegurar o dispositivo móvel.

SUMÁRIO

O sistema e método são dirigidos a resolver estes eoutros problemas e desvantagens da tecnologia anterior.Tipicamente, o sistema e método são implementados em umdispositivo móvel como uma maneira de assegurar odispositivo móvel. O sistema aplica regras para determinarse um evento associado a uma aplicação é um evento seguro.Se o evento for um evento seguro, o sistema aplica asregras para determinar se o evento é autenticado. Se oevento for autenticado, o evento é autorizado e o sistemaatualiza dados de regras associados ao evento e/ou outroseventos associados. Atualizar os dados de regras permiteque outros eventos associados sejam autenticados. O usuáriopode acessar uma aplicação e/ou dados associados àaplicação.

Se o evento não for autenticado, o sistema solicita aautenticação de um usuário. Se a autenticação for válida, oevento é autorizado e o sistema atualiza os dados de regrasassociados ao evento e/ou outros eventos associados. 0usuário pode acessar a aplicação e/ou dados associados aoevento. Se a autenticação não for válida, o sistemaassegura o dispositivo móvel.

BREVE DESCRIÇÃO DOS DESENHOS

Estes e outros recursos e vantagens do sistema emétodo tornar-se-ão mais aparentes da consideração dadescrição seguinte de uma versão ilustrativa do sistema emétodo junto com os desenhos, em que:

A Figura 1 é um diagrama de blocos que ilustra umsistema para assegurar um dispositivo.

A Figura 2 é um diagrama de blocos que ilustra umsistema para assegurar um dispositivo móvel.

A Figura 3 é um fluxograma que ilustra um método paraassegurar um dispositivo.

A Figura 4 é um fluxograma que ilustra um método paraassegurar um dispositivo.

A Figura 5 é um fluxograma que ilustra um método paradeterminar se eventos são eventos seguros ou eventos não-seguros e para associar eventos.

DESCRIÇÃO DETALHADA

A Figura 1 é um diagrama de blocos que ilustra umsistema 110 para assegurar um dispositivo 100. O sistema110 compreende um dispositivo 100, que inclui um módulo deautenticação 102, um módulo de comportamento 103, regras104, e uma ou mais aplicações 105. As aplicações 105 contêmdados de aplicação 106. As regras 104 contêm regras seguras104a, regras não-seguras 104B, e dados de regras 107. Asaplicações geram eventos 101.

O dispositivo 100 poderá ser um dispositivo móvel comoum telefone, um computador laptop, um Assistente DigitalPessoal (PDA), ou um dispositivo não-móvel como umcomputador pessoal (PC) . Uma aplicação 105 poderia serqualquer aplicação 105 tal como, um sistema operacional,uma aplicação de correio eletrônico, uma aplicação decalendário, um browser da Web, uma aplicação de lista decontatos, uma aplicação de telefonia, uma aplicação doSistema de Posicionamento Global (GPS), uma aplicação paraprotocolo de dispositivo, um gerenciador de memória, eassemelhados. Os dados da aplicação 106 são dadosassociados à aplicação 105. Por exemplo, um sistemaoperacional tem arquivos, diretórios e unidades de discoassociados que contêm dados de aplicação 106 que sãoutilizados pelo sistema operacional. Da mesma forma, umaaplicação de calendário tem dados de aplicação associados aitens do calendário.

Um evento 101 poderia ser qualquer evento gerado poruma aplicação 105 como: acessar uma rede, abrir aaplicação, acessar um arquivo, acessar um diretório,acessar um dispositivo de memória, inserir um dispositivodentro de uma estação de protocolo, remover um dispositivode memória, inserir um dispositivo de memória, receber umacorrespondência eletrônica, enviar uma correspondênciaeletrônica, receber um arquivo, enviar um arquivo, copiarum arquivo, acessar um dispositivo, entrar com umalocalização segura, deixar uma localização segura, conectara uma rede, desconectar de uma rede, acessar um calendário,receber uma chamada telefônica, fazer uma chamadatelefônica, e assemelhados. Exemplos de eventos 101 geradospor aplicações 105 são: abrir um browser da Web, acessaruma lista de contatos em um telefone, inserir um computadorlaptop dentro de uma estação de protocolo, e assemelhados.Um evento 101 pode ser um evento seguro 10IA ou um eventonão-seguro 101B. Um evento seguro 101A é um evento 101 querequer autenticação.

As regras 104 definem a maneira como os eventos 101são autenticados. Uma regra 104 poderá autenticar múltiploseventos 101 com base em um único evento 101. Há regrasseguras 104A, regras não-seguras 104B, e algumas regras 104que são aplicadas tanto a eventos seguros 10 IA como aeventos não-seguros 101B. Regras seguras 104A sãotipicamente associadas a eventos seguros 101A. Regras não-seguras 104B são tipicamente associadas a eventos não-seguros 101B. Um evento não-seguro 101B não requerautenticação. O evento não-seguro 101B pode tornar-se umevento seguro 101A com base nas regras 104. O evento seguro101A pode tornar-se um evento não-seguro 101B com base nasregras 104. As regras 104 também contêm dados de regra 107.

Os dados de regra 107 têm informação tal como quais eventos101 foram autenticados, o número de vezes que um evento 101ocorreu, se o usuário está registrado em uma rede, se olaptop está conectado a uma estação de protocolo,informação de cronômetro, e assemelhados.

O módulo de autenticação 102 aplica as regras 104 emconjunto com os dados de regra 107 para determinar se umevento 101 é um evento seguro 10IA ou um evento não-seguro101B. O módulo de autenticação 102 pode autenticar umevento 101 com uma variedade de mecanismos como uma senha,uma biométrica, um cartão de ID, e assemelhados. O módulode autenticação 102 também aplica as regras 104 em conjuntocom os dados de regra 107 para determinar quais eventos 101são autorizados e quais eventos 101 precisam serautenticados. O módulo de comportamento 103 funciona emconjunto com o módulo de autenticação 102 para atualizar osdados de regra 107, autorizar eventos 101, determinar se oseventos 101 são eventos estáticos, e assegurar odispositivo 100.

Quando um evento 101 é gerado, o módulo deautenticação 102 aplica as regras 104 e os dados de regra107 para determinar se o evento 101 é um evento seguro101A. Se o evento 101 for um evento não-seguro 101B, omódulo de comportamento 103 autoriza o evento 101 eatualiza os dados de regra 107. O módulo de autenticação102 então espera por outro evento 101.

Se o evento 101 for um evento seguro 10IA, o módulo deautenticação 102 determina se o evento 101 foi autenticadoanteriormente. A autenticação pode ser efetuada de umavariedade de modos com base nas regras 104. Por exemplo, ousuário poderá haver entrado anterior4mente com um códigode acesso para permitir a chamada de um número de telefoneou um código de área.

Se o evento 101 for autenticado, o módulo decomportamento 103 autoriza o evento 101 e atualiza os dadosde regra 107. Se o evento 101 não for autenticado, o módulode autenticação 102 solicita a autenticação. 0 módulo deautenticação 102 determina se a autenticação é válida. Se aautenticação for válida, o módulo de comportamento 103autoriza o evento 101 e atualiza os dados de regra 107.Caso contrário, se a autenticação não for válida, o módulode comportamento 103 assegura o dispositivo 100. 0dispositivo 100 pode ser assegurado de muitas maneiras. Porexemplo, parte ou a totalidade dos dados da aplicação 106pode ser apagada do dispositivo 100. Ou, as aplicações 105podem ser deletadas do dispositivo 100. Outros exemplosincluem, sem a eles se limitar, criptografar dados daaplicação 106 e travar o dispositivo 100.

Para fornecer uma visão geral de um fluxo de evento deum sistema de correspondência eletrônica, considere oexemplo seguinte. Bob tem um laptop novo 100 que tem umaaplicação de correspondência eletrônica 105. A aplicação decorrespondência eletrônica 105 tem um conjunto de listas decontato para correspondência eletrônica 106. O laptop 100contém cinco regras 104: 1) uma regra segura 104A de queabrir a aplicação de correspondência eletrônica 105 é umevento seguro 101A, 2) uma regra segura 104A de que enviarcorrespondências eletrônicas é um evento seguro 101A, 3)uma regra não-segura 104B de que se registrar edesregistrar da rede de trabalho é um evento não-seguro101B, 4) uma regra 104 que autoriza o acesso a todas asaplicações 105 no laptop 100 enquanto registrado em umarede de trabalho, e 5) uma regra 104 que autentica toda acorrespondência eletrônica enviadas por Bob enquantoregistrado na rede de trabalho. A quarta e quinta regrassão regras 104 que associam um evento 101 a outros eventos101. A regra quatro associa o evento 101 de registrar narede de trabalho aos eventos 101 de processar aplicações105 no laptop 100. A regra cinco associa o evento 101 deregistrar na rede de trabalho ao evento 101 de enviarcorrespondência eletrônica.

De seu laptop 10 0, Bob tenta registrar-se na rede detrabalho. Isto gera o primeiro evento 101. O módulo deautenticação 102 aplica as regras 104 em conjunto com osdados de regra 107 para determinar que o primeiro evento101 de registrar na rede de trabalho é um evento não-seguro101B (ver a regra três acima) . 0 módulo de comportamento103 autoriza Bob a registrar-se na rede de trabalho e Bobregistra-se na rede de trabalho. O módulo de comportamento103 atualiza os dados da regra 107 para indicar que Bobestá agora registrado na rede de trabalho. A seguir, Bobtenta abrir a aplicação de correspondência eletrônica. Istogera um segundo evento 101. O módulo de autenticação 102determina que abrir a aplicação de correspondênciaeletrônica é um evento seguro 10IA com base em uma regrasegura 104A (ver a regra um acima) e que requerautenticação. O módulo de autenticação 102 determina quecomo Bob está registrado na rede de trabalho, o segundoevento 101 de abrir a aplicação de correspondênciaeletrônica 105 é autenticado (ver a regra quatro acima). 0módulo de comportamento 103 autoriza o evento 101 de abrira aplicação de correspondência eletrônica 105. Bob abre aaplicação de correspondência eletrônica 105. 0 módulo decomportamento 103 atualiza os dados de regra 107 paraindicar que a aplicação de correspondência eletrônica 105está agora autenticada.Da aplicação de correspondência eletrônica 105, Bobenvia uma correspondência eletrônica para Tom. Isto gera umterceiro evento 101. O módulo de autenticação 102determina, ao aplicar a regra segura 104A (ver a regracinco acima), em conjunto com os dados de regra 107 queeste é um evento seguro 101A. O módulo de autenticação 102determina que como Bob está registrado na rede de trabalho,o evento 101 de enviar uma correspondência eletrônica paraTom é autenticado (ver a regra cinco acima) . 0 módulo decomportamento 103 autoriza o evento 101 de Bob enviar umacorrespondência eletrônica para Tom. O módulo decomportamento 103 atualiza os dados de regra 107 paraindicar que o evento 101 de Bob enviar uma correspondênciaeletrônica para Tom é autenticado. Bob agora se desregistrada rede de trabalho. Isto gera um quarto evento 101. Omódulo de autenticação 102 aplica a regra não-segura 104B(ver a regra três acima) e determina que o quarto evento101 de se desregistrar da rede de trabalho é um evento não-seguro 101B. O evento não-seguro 101B de se desregistrar darede de trabalho é autorizado pelo módulo de comportamento103. Bob se desregistra da rede de trabalho. Os dados deregra 107 são atualizados para indicar que Bob não estámais registrado na rede de trabalho.

Bob deixa o trabalho e está trabalhando em casa. Bobtenta acessar a aplicação de correspondência eletrônica105. Isto gera um quinto evento 101. 0 módulo deautenticação 102 aplica a regra segura 104a (ver a regra umacima) para determinar que abrir a aplicação decorrespondência eletrônica 105 é um evento seguro 101A. Omódulo de autenticação 102 determina que Bob não está maisregistrado na rede de trabalho ao olhar nos dados de regra107. O módulo de autenticação 102 solicita autenticação deBob, pois o evento 101 de abrir a aplicação decorrespondência eletrônica 105 não está mais autenticado. 0evento de abrir a aplicação de correspondência eletrônica105 não está autenticado, pois Bob não está mais registradona rede de trabalho. Bob autentica ao entrar com uma senha.

O módulo de autenticação 102 determina que a autenticação éválida. Bob é autorizado a utilizar a aplicação decorrespondência eletrônica 105 e os dados de regra 107 sãoatualizados. Bob agora envia uma correspondência eletrônicapara Tom. Isto gera um sexto evento 101. O módulo deautenticação 102 aplica a regra segura 104A (ver a regradois acima) e determina que o evento 101 de enviar umacorrespondência eletrônica é um evento seguro 101A. Omódulo de autenticação 102 aplica a regra segura 104A (vera regra cinco acima) e olha nos dados de regra paradeterminar que o evento 101 de enviar uma correspondênciaeletrônica para Tom é autenticado, pois Bob já enviou umacorrespondência eletrônica para Tom enquanto registrado narede de trabalho.

A seguir, Bob tenta enviar uma correspondênciaeletrônica para Sally. Isto gera um sétimo evento 101. 0módulo de autenticação 102 aplica a regra segura 104A (vera regra 2 acima) para determinar que o evento 101 de enviaruma correspondência eletrônica para Sally não éautenticado, pois Bob nunca enviou correspondênciaeletrônica para Sally enquanto registrado na rede detrabalho. O módulo de autenticação agora solicita que Bobautentique o envio de uma correspondência eletrônica paraSally.

Em um segundo exemplo, suponha que o laptop de Bob 100foi roubado após Bob haver desregistrado da rede detrabalho. O ladrão tenta abrir a aplicação decorrespondência eletrônica 105. Isto gera um evento 101. Omódulo de autenticação 102 aplica as regras seguras 104a(ver a regra um acima) e determina que uma autenticação énecessária. O módulo de autenticação 102 solicita umaautenticação do ladrão, pois o ladrão não está registradona rede de trabalho. Se a autenticação não for válida, omódulo de comportamento 103 assegura o laptop 100.

A Figura 2 é um diagrama de blocos que ilustra umsistema 210 para assegurar um dispositivo móvel. 0 sistema210 compreende um dispositivo 200, que inclui um módulo deautenticação 102, e um módulo de comportamento 103. Osistema 210 inclui regras 104, que ainda incluem regrasseguras 104A, regras não-seguras 104B, e dados de regras107. O sistema 210 inclui as seguintes aplicações 105: umaaplicação de interface de estação de protocolo 201, umaaplicação de rede celular/Wi-Fi/Bluetooth 202, umaaplicação GPS 203, um sistema operacional 204, umaaplicação de interface de cartão de memória/SIM 206, e umaaplicação de correspondência eletrônica/calendário 205. 0sistema 210 inclui dados de aplicação 106 associados àsaplicações 105. As listas de contatos 207 estão associadasà aplicação de correspondência eletrônica/calendário. Osarquivos 208 estão associados ao sistema operacional 208 epossivelmente outras aplicações como a aplicação GPS 203.

Cada uma das aplicações 201-206 pode gerar um ou maiseventos 101. Quando um evento 101 é gerado, o módulo deautenticação 102 aplica as regras 104 em conjunto com osdados de regra 107 para determinar se o evento 101 é umevento seguro 101A. Se o evento 101 for um evento não-seguro 101B, o evento 101 é autorizado, os dados de regra107 são atualizados, e o módulo de autenticação 102 esperapor outro evento 101.

Se o evento 101 for um evento seguro 10IA, o módulo deautenticação 102 aplica as regras 104 em conjunto com osdados de regra 107 e determina se o evento 101 estáautenticado. Se o evento 101 estiver autenticado, o módulode comportamento 103 autoriza o evento e atualiza os dadosde regra 107.

Se o evento 101 não estiver autenticado, o módulo deautenticação 102 solicita autenticação. O módulo deautenticação 102 determina se a autenticação é válida (porexemplo, três tentativas de autenticação falhadas). Se aautenticação for válida, o módulo de comportamento 103autoriza o evento 101 e atualiza os dados de regra 107.

Caso contrário, se a autenticação não for válida, o módulode comportamento 103 assegura o dispositivo 100 ao travá-lo, ou ao apagar e/ou criptografar os dados 207, 208.

A Figura 3 é um diagrama de fluxo que ilustra ummétodo para assegurar um dispositivo 100. De maneirailustrativa, o módulo de autenticação e o módulo decomportamento 103 são implementados como uma entidadecontrolada por programa armazenado, como um computador, queefetua o método das Figuras 3 a 5 ao executar um programaarmazenado em um meio de armazenagem, como uma memória oudisco. O processo espera 300 por um evento 101 ser gerado.

Após o evento 101 ser gerado, o processo aplica as regras104 em conjunto com os dados de regra 107 para determinar301 se o evento 101 é um evento seguro 10IA. Se o evento101 for um evento não-seguro 101B, o processo espera 300pelo próximo evento 101.

Se o processo determina 301 que o evento 101 é umevento seguro 101A, o processo aplica as regras 104 emconjunto com os dados de regra 107 para determinar 3 02 se oevento 101 é autenticado. Se o evento 101 for autenticado,o processo autoriza 307 o evento 101, atualiza 306 os dadosde regra 107, e espera 300 pelo evento 101 seguinte. Se oevento 101 não for autenticado, o processo solicita 303autenticação. Solicitar 303 autenticação poderia ser exibiruma orientação de registro ao usuário, enviar uma mensagem,e assemelhados. Após receber a autenticação de um usuário,o processo determina 3 04 se a autenticação é válida. Se aautenticação não for válida, o processo assegura 308 odispositivo 100. Se a autenticação for determinada 304 comosendo válida, o processo autoriza 307 o evento 101,atualiza 306 os dados de regra 107, e espera 300 para opróximo evento 101.

A Figura 4 é um fluxograma que ilustra um métodoalternativo para assegurar um dispositivo 100. O processoespera 4 00 por um evento 101 ser gerado. Após o evento 101ser gerado, o processo aplica as regras 104 em conjunto comos dados de regra 107 para determinar 4 01 se o evento 101 éum evento seguro 101A. Se o evento 101 for um evento não-seguro 101B, o processo autoriza 407 o evento 101, atualiza406 os dados de regra 107, e espera 400 para o próximoevento 101.

Se o processo determina 401 que o evento 101 é umevento seguro 101A, o processo aplica as regras 104 emconjunto com os dados de regra 107 para determinar 402 se oevento 101 está autenticado. Se o evento 101 forautenticado, o processo autoriza 4 07 o evento 101, atualiza406 os dados de regra 107, e espera 4 00 para o próximoevento 101. Se o evento 101 não estiver autenticado, oprocesso solicita 403 autenticação. Após receber umaautenticação do usuário, o processo determina 4 04 se aautenticação é válida. Se a autenticação não for válida, oprocesso assegura 408 o dispositivo 100.

Se a autenticação for determinada 4 04 como sendoválida, o processo determina 405 se o evento 101 é umevento estático. O evento estático é um evento 101 que nãoutiliza dados de regra 107. Por exemplo, um evento seguro101A que sempre requer autenticação independentemente dequalquer estado do dispositivo 100 ou de eventos 101 seriaconsiderado um evento estático (por exemplo, sempreexigindo um registro do laptop independentemente dequalquer outro evento 101) . Se o evento 101 não for umevento estático, o processo autoriza 407 o evento 101,atualiza 406 os dados de regra 107, e espera 400 pelopróximo evento 101. Caso contrário, o processo autoriza 409o evento 101.

A Figura 5 é um fluxograma que ilustra um método paradeterminar se os eventos 101 são eventos seguros 101A oueventos não-seguros 101B e associar eventos 101 a outroseventos. A Figura 5 é uma visão mais detalhada da etapa 406da Figura 4. O processo aplica as regras 104 em conjuntocom os dados de regra 107 para determinar 500 se o evento101 é um evento seguro 101A ou um evento não-seguro 101B. Oevento seguro 101A requer autenticação e um evento não-seguro 101B não requer autenticação. O evento não-seguro101B poderá ser convertido para um evento seguro 101A combase nas regras 104 e nos dados de regra 107. Da mesmaforma, um evento seguro 101A poderá ser convertido em umevento não-seguro 101B com base nas regras 104 e nos dadosde regra 107.

O processo determina 501 se o evento 101 tem qualquerevento associado. Se o evento 101 não tiver outros eventosassociados, o processo atualiza 503 os dados de regra 107para o evento 101. Se o evento 101 tem outros eventosassociados, o processo atualiza 502 os dados de regra 107para os eventos associados e atualiza 503 os dados de regra107 para o evento 101.

Há muitas maneiras com que um evento não-seguro 101Bpode ser convertido em um evento seguro 10IA ou um eventoseguro 10IA pode ser convertido para um evento não-seguro101B. Por exemplo, o evento 101 poderá iniciar como umevento não-seguro 101B. Uma regra 104 para o evento 101 dizque se as listas de contato para chamadas telefônicas sãoacessadas mais de dez vezes dentro de um período de umahora, então o evento não-seguro 101B de acessar a lista decontato tornar-se-á um evento seguro 101A. O usuário teriade re-autenticar da próxima vez que o usuário tentasseacessar a lista de contatos para chamadas telefônicas. Oevento 101 de acessar as listas de contato poderia retornarpara um evento não-seguro 101B após o usuário re-autenticarse as regras 104 assim o indicarem.

Naturalmente, várias mudanças e modificações na versãoilustrativa descrita acima serão aparentes para aqueleshabilitados na tecnologia. Por exemplo, a avaliação deeventos de segurança poderá ocorrer no dispositivo e/ou narede. A conectividade física poderia ser uma conexão semfio, uma conexão USB, ou dispositivos de rede de fiaçãosólida. Eventos de qualquer novo tipo de dispositivo de E/Spoderiam ser monitorados, tais como: telefones ativadospela Web que acessem sítios da Web ou conteúdos novos ousuficientemente diferentes (por exemplo, sítios em idiomasestrangeiros, motores de busca diferentes, e assemelhados),enviar fotos quando fotos nunca foram antes enviadas, e/ouligar a um novo dispositivo Bluetooth. Além disso, eventospoderiam ser monitorados durante o processo de dar partida(boot) de um dispositivo. Outros eventos como a localizaçãoem conjunto com outros eventos poderiam ser utilizados.

Outros exemplos poderiam ser quando a primeira leva deautenticação for boa e um ladrão tenta acessar uma contabancária pelo telefone e tentativas repetidas falharem.

Neste caso, o método de autenticação principal seriainvocado e/ou o dispositivo poderia ser travado. Outroexemplo poderia ser utilizar um telefone GPS em conjuntocom um interferômetro para detectar o andar da pessoaversus um padrão de andar costumeiro. Essas mudanças emodificações podem ser feitas sem desviar do espírito eescopo do sistema e método e sem diminuir suas vantagensconseqüentes. Portanto, pretende-se que essas mudanças emodificações sejam cobertas pelas reivindicações seguintesexceto no que seja limitado pela tecnologia anterior.

Claims (10)

1. Sistema para segurança de um dispositivo,caracterizado por compreender:a. um módulo de comportamento para autorizar eventos,atualizar dados de regras, e proporcionar segurança aodispositivo, eb. um módulo de autenticação reativo a um primeiroevento ser um evento seguro, para determinar se o primeiroevento é autenticado;c. reativo ao primeiro evento ser autenticado, paradirigir o módulo de comportamento para autorizar o primeiroevento e atualizar os dados de regras;d. reativo ao primeiro evento não ser autenticado,para determinar se uma autenticação é válida;e. reativo à autenticação ser válida, para dirigir omódulo de comportamento para autorizar o primeiro evento eatualizar os dados de regras; ef. reativo à autenticação não ser válida, para dirigiro módulo de comportamento para assegurar o dispositivo.

2. Sistema, de acordo com a reivindicação 1,caracterizado pelo fato do módulo de autenticação serreativo ao primeiro evento não sendo um evento seguro paradirigir o módulo de comportamento a autorizar o primeiroevento e atualizar os dados de regras e pelo fato do módulode comportamento ser reativo ao primeiro evento sendo umevento não-seguro, atualizando os dados de regras aoconverter o primeiro evento em um evento seguro.

3. Sistema, de acordo com a reivindicação 1,caracterizado pelo fato do primeiro evento ser um eventoseguro, e do módulo de comportamento ser ainda adaptadopara converter o primeiro evento em um evento não-seguro.

4. Sistema, de acordo com a reivindicação 1,caracterizado pelo fato do módulo de autenticação serreativo à autenticação ser válida, para dirigir o módulo decomportamento a determinar se o primeiro evento é um eventoestático, e pelo fato do módulo de comportamento serreativo ao primeiro evento não sendo um evento estático,para autorizar o primeiro evento e atualizar os dados deregras.

5. Sistema, de acordo com a reivindicação 1,caracterizado pelo fato do módulo de autenticação seradaptado para determinar se a autenticação é válida combase em uma autenticação anterior do primeiro evento ou emuma autenticação anterior do evento associado.

6. Método para segurança de um dispositivo,caracterizado por compreender:a. determinar se um primeiro evento é um eventoseguro;b. em resposta a determinação de que o primeiro eventoé um evento seguro, determinar se o primeiro evento éautenticado;c. em resposta a determinação de que o primeiro eventoé autenticado, prosseguir para a etapa (f);d. em resposta a determinação de que o primeiro eventonão é autenticado, determinar se uma autenticação é válida;e. em resposta a determinação de que a autenticação éválida, prosseguir para a etapa (f);f. autorizar o primeiro evento e atualizar dados deregras para o primeiro evento; eg. em resposta a determinação que a autenticação não éválida, assegurar o dispositivo.

7. Método, de acordo com a reivindicação 6,caracterizado por compreender ainda: em resposta adeterminação de que o primeiro evento não é um eventoseguro, prosseguir para a etapa (f) e onde em resposta aoprimeiro evento ser um evento não-seguro, atualizar osdados de regras ao converter o primeiro evento em um eventoseguro.

8. Método, de acordo com a reivindicação 6,caracterizado pelo fato do primeiro evento ser um eventoseguro e em que atualiza os dados de regras aindacompreender converter o primeiro evento em um evento não-seguro.

9. Método, de acordo com a reivindicação 6,caracterizado pelo fato da etapa de determinar se aautenticação é válida, compreender ainda determinar se oprimeiro evento é um evento estático, e em resposta aoprimeiro evento não ser um evento estático, prosseguir paraa etapa (f).

10. Método, de acordo com a reivindicação 6,caracterizado pelo fato da determinação de se autenticaçãoé válida, ter por base uma autenticação anterior doprimeiro evento ou uma autenticação anterior de um eventoassociado.