BRPI0621168A2 - token de segurança e método para autenticação de um usuário com o token de segurança - Google Patents

Abstract

TOKEN DE SEGURANçA E MéTODO PARA AUTENTICAçãO DE UM USUáRIO COM O TOKEN DE SEGURANçA. Um token de segurança compreende uma memória de dados pessoais para armazenar dados personalizados de um usuário como credenciais de identidade digital (33, 34) Um dispositivo de entrada é usado para permitir a checagem dos citados dados pessoais, preferivelmente com uma verificação de identidade a bordo usando fatores de autenticação 2 ou 3. O token compreende uma memória de dados de registro (71, 75) para armazenar uma pluralidade de credenciais de identidade inicializadas por uma autoridade de certificação e possivelmente atribuidas a diferentes provedores de serviço. Ele adicionalmente compreende uma unidade transmissora e receptora para criar um canal seguro diretamente ou indiretamente com um servidor de autenticação ou operador de aplicação ou autoridade de certificação para manusear o citado registro chave (71, 75) relacionado com o citado servidor de autenticação. Uma unidade de controle é provida para controlar a unidade transmissora e receptora bem como a memória de dados de registro chave (71, 75) em vista do citado manuseio, compreendendo uma ação do grupo e interpretação, decifração, criação, checagem, renovação, extração e ações adicionais de manuseio de registro chave. Isto permite o usuário usar identidades federalizadas em um ambiente altamente seguro, usando dados biométricos para se autenticar com o dispositivo, mas sem repassar tais dados biométricos a terceiros.

Description

"TOKEN DE SEGURANÇA E MÉTODO PARA AUTENTICAÇÃO DE UM USUÁRIO COM O TOKEN DE SEGURANÇA".

Campo da invenção

A invenção relaciona-se com um método e um dispositivo para autenticar um usuário, para proporcionar acesso a um sistema que é seguro e para facilitar a administração de identidades digitais pessoais.

Técnica anterior e antecedentes da invenção

Existem vários dispositivos e métodos para autenticar o usuário para um sistema, o qual pode ser um sistema de edifício, ou para uma rede de computadores, ou um sistema de informação remoto. 0 objetivo da autenticação pode ser acesso físico a um edifício, p.ex., para abrir uma porta, ou acesso lógico a um serviço de rede, p.ex., acesso a uma página da rede ou para recuperação de informações, p.ex., a partir de um sistema de computador remoto. Dessa maneira o usuário usa geralmente seu nome o qual também já está designado como uma ID de usuário em combinação com a senha ou um Código-PIN. Após a autenticação com sucesso o usuário tem acesso a uma rede de computadores ou ao citado sistema. 0 link mais fraco em um sistema seguro é geralmente o usuário. Isto é devido ao fato que o usuário é usualmente negligente em vista de escolher senhas fortes. Adicionalmente senhas não são freqüentemente tratadas como segredos altamente valiosos. Adicionalmente o usuário também pode ser um alvo para ataques de engenharia social como phishing [pescaria], onde nomes de usuários e correspondentes senhas são roubados ou seqüestrados por terceiros.

Um usuário típico de sistemas de computador e serviços de Internet teria que memorizar e administrar mais que 50 IDs de usuário, senhas e códigos PIN, todas estas informações têm que ser tratadas como segredos reais como é suposto pela maioria dos sistemas de autenticação de hoje. É um fato bem conhecido que os usuários não tratam tais credenciais de identidade como segredos valiosos. Os usuários escolhem ou senhas simples ou regras simples para memorizar senhas. Ataques de dicionário podem quebrar tais segredos de senhas declaradas dentro de segundos. Para aumentar a segurança da autenticação os operadores distribuem tokens passivos ou ativos (cartões, listas OTP, geradores de código de passe dependentes da hora, certificados digitais, etc.). O manuseio de todas estas credenciais de identidade físicas e virtuais torna a vida não mais fácil para seu proprietário. Muitos serviços de internet já não são mais usados porque os usuários se esqueceram de como acessar o sítio. Os usuários restringem suas relações comerciais a poucos operadores o que naturalmente reduz as oportunidades de negócios para e-commerce [comércio eletrônico]. Embora muitos sistemas ofereçam funções de administração de identidade para operadores o problema da administração de identidade do lado do usuário permanece não resolvido. O propósito de uma autenticação em uma porta física ou um portal virtual é o mesmo. O acesso a um sítio restrito deve ser limitado a pessoas autorizadas. Somente a política de segurança deve definir quais credenciais de identidade são aceitáveis para um controle de acesso específico. No mundo real entretanto muitas organizações operam sistemas de controle de acesso diferentes e mais ou menos separados com credenciais de identidade independentes para acesso físico (acesso a edifícios e sítios, etc.) e lógico (acesso a sistemas de computadores e informações, etc.). Esta inconsistência cria sobrecarga administrativa, complicações para os usuários e por último mas não menos importante uma falha de segurança. Há muitos anos sistemas de administração de identidade federalizada (FIM) e de. assinatura única (SSO) ou sistemas de assinatura reduzida por empreendimento são sugeridos para reduzir esta carga de autenticação múltipla para o usuário. Isto está correto, entretanto, o principal problema de tais sistemas FIM é a necessidade que diferentes firmas ou provedores de serviços têm que coordenar seu trabalho e aceitar entre si os usuários comuns. Isto não é trabalhável. Estes esforços são - no fim - ineficientes para resolver este problema. A WO 02/15626 se relaciona com um telefone móvel usável como dispositivo de autenticação, onde o usuário se autentica com o telefone móvel em um ou mais modos incluindo características biométricas e então o telefone móvel se autentica com o serviço requerido. A WO 02/15626 se empenha em evitar a transmissão de um token do usuário para o dispositivo, onde uma autenticação pode ser usada desde que todos os provedores de serviço de autenticação usem os mesmos protocolos.

Sumário da invenção

Um objetivo da presente invenção é prover um método e um dispositivo, que permita uma autenticação de usuário que seja mais segura do que usando os métodos da técnica anterior.

É um objetivo adicional da presente invenção otimizar a relação usuário-operador em termos de eficiência e segurança.

É ainda um objetivo adicional prover um método e dispositivo mais ergonômico para conceder acesso a um sistema seguro.

É ainda um objetivo adicional prover o usuário com um sistema de administração de identidade pessoal (PIMS) que administre suas identidades digitais e credenciais de identidade com um mínimo de interação do usuário. É ainda um objetivo adicional prover um usuário com um PIMS modular que possa ser particularizado a qualquer momento com um token adicional que contenha informações para um novo processo de autenticação ou prestação de serviço.

De acordo com a invenção é provido um token de segurança compreendendo uma memória de dados pessoais para armazenar dados pessoais e personalizados do usuário como credenciais de identidade digital, um dispositivo de entrada para permitir a checagem dos citados dados pessoais ou personalizados, uma memória de dados de registro chave para armazenar credenciais de identidade de um servidor de autenticação ou operador de aplicação, uma unidade transmissora e receptora para criar um canal seguro diretamente ou indiretamente com o citado servidor de autenticação ou operador de aplicação para manusear o citado registro chave relacionando com o citado servidor de aplicação ou operador de aplicação, uma unidade de controle para controlar a unidade transmissora e receptora bem como a memória de dados de registro chave em vista do citado manuseio, compreendendo uma ação a partir do grupo de interpretação, decifração, criação, checagem, renovação, extração e ações adicionais de manuseio de registro chave. Ele pode ser opcionalmente equipado com um mecanismo de fixação que permita a conexão com um token adicional com informações de particularização (veja abaixo). Ele preferivelmente adicionalmente compreende uma unidade de suprimento de energia e um canal protegido para atualizações de firmware [programa residente de inicialização].

O token de segurança pode ter a forma de um cartão inteligente mas também pode ser um telefone celular ou um PDA. É importante que dados pessoais possam ser alimentados e armazenados. Tais dados pessoais pode ser um segredo ou dados biométricos. Para permitir a autenticação uma memória de dados de registro chave é usada para armazenar credenciais de identidade de um ou mais servidores de autenticação. Estes registros chave são "manuseados" após criar um canal seguro diretamente ou indiretamente com o citado servidor de autenticação, sendo que o manuseio compreende um número de ações.

Ocasionalmente o token de segurança é usado em combinação com um token adicional para executar uma checagem de identidade ao criar um novo registro chave. Tal token adicional pode ser uma senha para uma única vez, para checar uma checagem de autenticação de propriedade da citada senha, ou compreender um elemento de circuito eletrônico com meios transmissores e receptores adicionais para criar um canal seguro adicional para o token de segurança. Isto permite o dispositivo inteiro receber uma carga útil de mensagem a partir do servidor de autenticação que é processada e passada para a citada unidade de controle, para manusear o relevante registro chave. Esta opção torna o dispositivo modular e particularizável para o fornecimento de novos serviços de autenticação que ainda não são conhecidos no instante do fornecimento ao usuário.

Em uma configuração preferida são providos uma pluralidade de registros chave, cada registro atribuído a uma autoridade de certificação ou provedor ou operador de serviço de autenticação. Vários registros chave podem ser atribuídos pela autoridade de certificação e depois serem ativados por diferentes provedores de serviços de autenticação. Isto permite cada autoridade de certificação autenticar a identidade do usuário independentemente dentro do token, enquanto o usuário tem somente este um token e adicionalmente tem controle sobre seus dados pessoais (os dados biométricos são armazenados somente dentro do token). Está a cargo das diferentes organizações decidir como manusear os diferentes registros chave por diferentes servidores de autenticação ou operadores de aplicação. O usuário tem um modo muito conveniente de se autenticar com somente um token de segurança e credenciais de diferentes provedores memorizadas seguramente no citado token. Se um dos servidores de autenticação ou operadores de aplicação quiser renovar e mudar a autorização, isto pode ser feito completamente independente dos registros chave de outras organizações.

A configuração preferida prevê uma USB segura, especialmente mini-USB ou outro conector físico que pode ser usado para o recarregamento do equipamento de suprimento de energia interno e para o bootstrap [rotina de inicialização] do firmware. Ela também pode ser usada para fornecer informações certificadas que não podem ser entregues através dos outros canais disponíveis (p.ex., certificado X509).

Se alguns CAs tiverem uma liderança no mercado, é possível criar dois ou mais segmentos chave compreendendo diferentes registros chave que podem ser habilitados e distribuídos pelas diferentes autoridades de certificação a diferentes servidores de autenticação ou operadores de aplicação. Tal CA [autoridade de certificação] ou um provedor de serviço de autenticação autorizado pelo CA pode operar um portal que proporciona acesso a múltiplos sítios e serviços que necessitam uma autenticação de seus usuários mas que não desejam operar um sistema de autenticação próprio.

O token e o método são, claro, intencionados a prover autenticação positiva do token de segurança para permitir ao usuário um bom número de ações, como p.ex., acessar uma aplicação de software, efetuar um pagamento, criar um tíquete ou permitir acesso físico, especialmente para abrir uma porta. Tal sistema de administração de identidade do lado do usuário deve estar sempre sob o controle do usuário e ele pode ser protegido de qualquer manipulação maliciosa externa. Portanto um sistema de administração de identidade pessoal não deve ser implementado em equipamento de terminal de dados (PC, telefone móvel, etc.) que possa ficar sob controle de um atacante.

A invenção é baseada na visão dos inventores, que as propostas usadas na técnica anterior começam a partir do lado errado da relação usuário-operador. Somente uma administração de identidade do lado do usuário pode manusear múltiplas credenciais de identidade do usuário.

A invenção permite o usuário usar identidades federalizadas em um ambiente altamente seguro, usar dados biométricos para se autenticar com o dispositivo e dentro do método usado, mas sem revelar tais dados biométricos a terceiros.

Descrição resumida dos desenhos Os desenhos serão explicados em maiores detalhes por meio de uma descrição de configurações exemplares, com referência às figuras seguintes:

A figura 1 mostra um método e um dispositivo de acordo com a presente invenção embutidos em um ambiente seguro; A figura 2 mostra os componentes relevantes e os canais de comunicação para o dispositivo da figura 1 e enquanto usando o método de acordo com a invenção;

A figura 3 mostra esquematicamente um cartão para uso com o método e o dispositivo da figura 1;

A figura 4 mostra a arquitetura dos dados de uma administração de credenciais dentro de um cartão de acordo com a presente invenção;

A figura 5 mostra um possível método de preparação de acordo com a presente invenção;

A figura 6 mostra esquematicamente o método e dispositivo de acordo com a presente invenção com um usuário; A figura 7 mostra a interação do cartão com um cartão inteligente de acordo com a presente invenção em combinação;

A figura 8 mostra esquematicamente um cartão de acordo com a presente invenção;

A figura 9 mostra esquematicamente uma bolsa de acordo com a presente invenção,

A figura 10 mostra um modo de operação independente;

A figura 11 mostra uma operação de serviço de autenticação;

A figura 12 mostra uma operação de autoridade de certificação; e

A figura 13 mostra uma operação federalizada.

Descrição detalhada de configurações preferidas As figuras 1 e 2 mostram esquematicamente um arranjo possível do método de acordo com uma configuração da presente invenção.

Assim a figura 1 mostra um subsistema trifuncional 7. 0 subsistema trifuncional 7 compreende um token 8, 9, uma plataforma de autenticação 6, e módulos de autenticação 12. O token 8, 9 é um token de segurança e usado dentro do contexto de uma autenticação multifator como "algo que o usuário tem". O token 8, 9 pode ser um cartão inteligente, um cartão SIM ou compreender um terminal leitor para tal cartão. No último caso o token de segurança 8, 9 é então a combinação de um cartão inteligente e o leitor. Um PDA ou um telefone móvel pode portanto ser considerado como tal token 8, 9. Na descrição seguinte é assumido que o token de segurança seja um cartão 8, 9.

O subsistema trifuncional 7 é responsável por controlar, restringir e autenticar acesso a aplicações seguras subseqüentes 13. É entendido pela pessoa experiente na técnica que tais aplicações 13 não estão limitadas àquela uma que é mostrada e mencionada na figura 1. Deve ser notado que as credenciais providas pelas organizações operando as aplicações 13 podem ser separadas (e portanto fisicamente para serem carregadas no subsistema 7) mas também incluídas nos módulos de autenticação 12 através de uma transferência por software para dentro de uma memória segura como será mostrado abaixo.

Dentro de toda a descrição, algumas abreviações serão usadas as quais estão definidas na lista anexa de numerais de referência no fim da descrição.

Um exemplo de tal plataforma de autenticação 6 é ilustrado por meio da figura 2. A plataforma de autenticação 6 compreende um servidor de licença 65, um CA de servidor de autoridade de certificação 64, um AuSP de servidor de provedor de serviço de autenticação 63, características ópticas 61 e/ou meios transmissores de informação 62, tal como características de identificação de radiofreqüência (RFID). A plataforma de autenticação 6 pode ser construída como um portal digital para permitir ao provedor de serviço de autenticação conceder acesso a um sistema de computador ou ela pode ser construída como um portal físico, que controla por exemplo acesso a um edifício. Uma característica original 61 pode ser uma pequena aplicação ["applet"] de plugar ou qualquer outro programa de geração de gráficos que gere um código vibrante que é exibido na tela do computador do usuário p.ex. em uma janela do navegador do cliente (p.ex., como descrito em EP1255178) e será lido por um canal ótico do cartão 8, 9. Como entrada a pequena aplicação ou o programa toma uma mensagem de servidor de autenticação com um cartão, segmento e endereço de registro chave e uma mensagem criptografada. (Esta mensagem é transmitida do servidor de autenticação para o equipamento terminal local através de um canal seguro http-, https- ou um outro protegido por um protocolo ponto-a-ponto adequado, p.ex., protocolo SSL). Durante a sessão o operador pode autenticar ou verificar a presença do usuário autorizado uma ou várias vezes e ligar esta autenticação com informação específica da transação que é acessível somente através do token 8, 9. O canal do servidor para o terminal de dados local é adicionalmente assegurado pelos mecanismos de segurança de rede adicionais (VPN, https ou outros protocolos protegidos SSL).

A característica RFID 62 pode ser uma aplicação para o servidor RFID que transforma o endereço e a mensagem do servidor de autenticação em diálogo de comunicação RFID para o terminal leitor ou cartão 8, 9. A citada mensagem será transmitida usando os mesmos protocolos como descrito acima.

Além destes dois modos de comunicação também é possível que a informação seja transmitida de um modo acústico ou em um modo ótico simples (transmissão por IV) , com as desvantagens usuais de tais modos de transmissão mais lentos.

O servidor AuSP 63 executa o protocolo de autenticação básico e ele gera a pedido do servidor de operador 63 a mensagem de contestação-resposta apropriada, a criptografa, a assina e a transforma em uma mensagem SOAP (Protocolo de Acesso de Objeto Simples). Se necessário (primeiro registro e renovação, matrícula on-line) ele se comunica com o servidor de autoridade de certificação (servidor CA) 64 para conseguir as necessárias chaves, códigos de ativação e renovação.

O servidor CA 64 permite uma autoridade de certificação (CA) inicializar cartões 8, 9 com suas chaves privadas e executar o processo de matrícula.

Um servidor de licença 65 é o sistema de administração de cartões que administra todos os cartões circulando 8, 9, fornece os códigos de acesso para o servidor CA 64 (SAC - código de ativação de segmento 53, KAC - código de ativação de chave 54) e a informação de renovação de licença (KRC - código de renovação de chave com uma nova KED - data de expiração de chave referenciada como 77 na fig. 4) . Os códigos de controle de licença permitem a implementação de modelos comerciais novos, flexíveis e modulares com um custo para um ou vários atos de autenticação ou por um período limitado ou ilimitado (licença por venda do token 8, 9) .

A implementação básica do método de acordo com a presente invenção pode ser feita para aplicações que são oferecidas através da internet. Todo o método de autenticação entretanto também pode ser usado para a autenticação dentro de sistemas operacionais (Windows, Solaris, Linux, etc.) ou em aplicações que necessitam autenticação do usuário (SAP, Secure Adobe, CRMs, CSMs, etc. ) . Se o método de acordo com a presente invenção for usado para sistemas operacionais ou aplicações, o módulo de login [registro] e de autenticação de usuário da citadas aplicações tem que ser substituído com um correspondente módulo de autenticação de acordo com a presente invenção.

O dispositivo de acordo com a presente invenção será explicado por meio das figuras 3, 4, 8 e 9. Uma pessoa ou usuário 1 estabelece uma ligação com um cartão 8, 9 de acordo com o método descrito abaixo. 0 cartão 8, 9 retém dados pessoais (biométricos) 31 (Em uma autenticação multifator esta credencial é "algo que o usuário é") , dados digitais personalizados 33 e credenciais digitais certificadas 34, 34' para a identidade da pessoa em relação a certo provedor de serviço de autenticação e estabelece uma ligação permanente, forte e provável 35, 35' com os servidores AuSP 2, 2'. Juntos os dados digitais personalizados e a credencial certificada 33, 34 formam as informações essenciais do registro chave 75. Isto pode ser feito uma vez e para sempre. As credenciais digitais 33, 34 podem ser inicializadas e apresentadas a um sistema de administração de informações independente (IMS) e seus servidores de autenticação 2, 2'. Entretanto, as credenciais 33, 34, 33', 34' também podem ser apresentadas a qualquer outro sistema como conhecido pela pessoa experiente na técnica. A fig. 3 mostra a possibilidade que uma pluralidade de diferentes credenciais digitais Ian possam ser guardadas no cartão 8 e adicionalmente o cartão 8 está equipado para verificar a identidade dos Servidores IMS 2, 2' pelas credenciais 34, 34' etc. É uma vantagem do dispositivo de acordo com a fig. 3 que a entrada de dados pessoais, isto é dados biométricos ou um segredo, é manuseada através da conexão 10 e é armazenada como fator 31. Estas entradas são usadas, quando criando as chaves privadas 1 a n, mas preferivelmente não necessariamente compreendem tais dados como parte da chave. Isto tem a vantagem que o usuário permanece como proprietário do cartão 8, também proprietário físico sobre seus dados biométricos e nenhuma distribuição destes dados biométricos para fora do cartão 8 é contemplada. Portanto nenhum abuso de tais dados, isto é através de pirataria por terceiros em um servidor mestre armazenando tais dados biométricos, é possível. Isto é importante uma vez que tais dados biométricos não podem ser substituídos como é possível com um PIN.

Por um lado o cartão 8, 9 verifica a identidade do usuário autorizado através de uma autenticação de dois ou três fatores 7, por outro lado ele processa credenciais de identidade e pedidos de autenticação digital que podem ter várias formas diferentes. Tais exemplos de tal serviço de autenticação provido pelo cartão pode ser uma resposta a um protocolo de contestação-resposta como explicado na EP 1 480 107 dos mesmos inventores, uma geração de uma assinatura digital, o fornecimento de um código de autenticação de mensagem ou do código de ativação para um certificado de software. Tal pedido de autenticação digital pode compreender uma contestação relacionada com "algo que o usuário sabe". Dependendo do nível de segurança uma das várias checagens pode ser omitida.

O cartão 8 de acordo com a presente invenção é preferivelmente pré-carregado com um conjunto de endereços 51, 52 e 73, chaves 33, 34, 72, 79 e códigos 53, 54, 76, 77 como pode ser visto a partir de um exemplo de tal cartão mostrado na fig. 4 e exemplos de processos de fabricação 4, 5 como mostrados na fig. 5. O cartão 8 é o assistente de administração de identidade digital pessoal. Isto significa que informações relacionadas com a identidade dos usuários estão armazenadas no cartão 8 bem como outras informações que se relacionam com outros serviços. As informações relacionadas com a identidade dos usuários estão normalmente contidas em dados globais 55 junto com o registro de matrícula 74 etc., representado pelo numerai de referência 31 na fig. 3. O cartão 8 compreende vários segmentos de armazenagem de chave 71, sendo que cada segmento pode compreender um número para registros chave 75. Isto é equivalente a um sistema de administração de identidade interno que contém chaves privadas (parte de 34) em um registro de armazenagem chave 75 dentro de uma seção de armazenagem de chave 71 como credenciais de identidade digital, as correspondentes chaves públicas do AuSP (parte de 34) que usam uma chave privada específica, a chave pública do CA 79 que carregou as chaves privadas, matrícula opcional 78 e informações de acesso de licença. A seção de renovação de chave 77 bem como códigos de ativação de segmento 53 também estão contidos em cada segmento. Entretanto, todos os dados armazenados no cartão são entregues externamente via uma interface adequada e permissões adequadas (licença ou permissões-CA) e/ou podem ser atualizados depois por carregamentos separados. Portanto a estrutura mostrada na fig. 4 mostra um cartão em uso. É possível atribuir a um primeiro CA um segmento 71 com somente um registro 75 e a um segundo CA um outro segmento 71 com p.ex. cinco registros 75. Depois ou sempre é possível estender a alocação de registros do cartão 8 para CA' s adicionais (um novo terceiro CA pode receber um segmento recém criado), ou alocar adicionais ou deletar existentes registros 75 para os citados primeiro ou segundo CA. A colocação física de tais informações dentro da memória do cartão é controlada por números de identidade como IDT 51 para o token, IDS 52 para um segmento e IDX 73 para um registro chave.

A figura 8 mostra uma primeira configuração de tal cartão 8 de acordo com a presente invenção. O cartão 8 tem um tamanho similar a um cartão de crédito usual, mas é tipicamente mais espesso que um cartão de crédito, usualmente de duas a três vezes (a representação nas figs. 8 e 9 está exagerada). Informações pessoais 83 são armazenadas no cartão por meios de armazenagem. Os meios de armazenagem podem ser uma simples figura, um código de barras, um chip de radiofreqüência ou qualquer outro meio adequado. Adicionalmente o cartão 8 compreende uma cavidade de recepção para receber um cartão de chip adicional 84 que pode ser inserido e removido como indicado pela seta 82. O cartão de chip adicional 84 pode ser um cartão de chip análogo ao cartão SIM que pode ser inserido no cartão 8. O cartão de chip 84 também pode ser designado como um token adicional. Vários diferentes cartões de chip podem ser editados por diferentes CA's, AuSP's e operadores.

Além de adicionar fisicamente o token de segurança adicional também é possível carregar as citadas informações para uma memória como será visto na descrição relacionada com a fig. 7. Um AuSP ou operador pode aceitar tal carregamento como suficiente para acessar seus serviços ou solicitar a presença de um token físico 84 ou 94 dentro do cartão 8 ou 9.

A figura 9 mostra uma segunda configuração de uma bolsa 9 de acordo com a presente invenção. A bolsa 9 também tem tamanho similar ao cartão 8 na primeira configuração. Informações pessoais 83 são armazenadas na bolsa por meios de armazenagem. Os meios de armazenagem podem ser uma simples figura, um código de barras, um chip de radiofreqüência ou qualquer outro meio adequado.

Adicionalmente a bolsa 9 compreende uma fenda 91 para receber um cartão de dados adicional 94, que pode ser inserido e removido como indicado pela seta 92. 0 cartão de dados adicional 94 pode ser um cartão inteligente com conectores elétricos ou interface RFID. Entretanto o cartão de dados adicional 94 pode ser enganchado na bolsa 9 por alguns conectores mecânicos. 0 cartão de dados adicional 94 também pode ser designado como um token adicional.

Uma terceira configuração pode consistir do cartão de dados 8 sozinho sem interfaces adicionais para cartões de chip ou cartões inteligentes.

Para fins de simplicidade o cartão 8 bem como a bolsa 9 serão agora designados como cartão 8, 9 e o cartão de chip bem como o cartão de dados adicional serão agora designados como token adicional 84, 94.

Adicionalmente o cartão 8, 9 pode compreender várias interfaces 85, 95. As interfaces 85, 95 podem ser uma interface ótica, uma interface de radiofreqüência ou uma interface elétrica. Entretanto qualquer outra interface como conhecida pela pessoa experiente na técnica também pode ser usada. A interface ótica, por exemplo, é capaz de ler um código vibrante que é provido por um navegador de cliente 61. Adicionalmente, também é possível que o cartão 8, 9 compreenda meios de display para exibir status e outras informações para o usuário. Meios de display podem ser LEDs para informações de status ou display de cristal líquido para sinalizar informações mais complexas.

Para transmitir dados do token adicional 84, 94 para o cartão 8, uma conexão segura usando um canal de comunicação seguro ou canal de comunicação criptografado 40 entre os dois será estabelecida. Esta conexão será estabelecida na primeira vez que o cartão adicional 84, 94 entrar em contato com o token 8. Após esta primeira inserção o uso do cartão 84, 94 pode ser restringido ao token 8, 9 dependendo da política do editor do cartão adicional.

O cartão 8 como mostrado na fig. 4 contém um sistema de administração de credencial de identidade interno que contém chaves privadas como credenciais de identidade, as correspondentes chaves públicas do AuSP 63 que usa uma chave privada específica, a chave pública do CA 64 que carregou as chaves privadas, matrícula, acesso de licença e informações de atualização de software.

Para habilitar múltiplas relações independentes entre operadores (provedor de serviços, etc.) e usuários (portador do cartão) um sistema de administração de chave e inicialização é necessário.

Os serviços de identidade digital trabalham ou com as credenciais de identidade internas sozinhas, como providas dentro dos segmentos 71 e registros chave 75, com as credenciais de identidade internas e algumas informações recebidas ad-hoc que entram no cartão 8 através de uma das interfaces disponíveis preferivelmente ótica, radiofreqüência ou contato elétrico ou com as credenciais de identidade internas, algumas informações recebidas ad-hoc que entram no token por uma das interfaces disponíveis e algumas informações adicionais a partir do token adicional substituível e personalizável 84, 94 que é enganchado no token.

O token adicional 84, 94 pode conter informações que especifiquem a natureza do serviço de autenticação para prover um relacionamento comercial com o editor ou provedor do token adicional 84, 94. Ele também pode conter credenciais de identidade adicionais que só podem ser usadas por um proprietário específico do cartão 8. Tipicamente o token adicional 84, 94 pode ser emitido por terceiros. O token adicional 84, 94 pode ser emitido, por exemplo, por uma instituição comercial tal como um banco, loja on-line, companhia de seguros. Ou o token adicional pode ser emitido por uma companhia para seus funcionários para obter acesso a um sistema interno de computadores. O token adicional também pode ser um token que tenha sido emitido para o usuário antes dos cartões 8,9.

O usuário 1 da fig. 7 usa um cartão 8 ou 9. O uso de um novo serviço necessita autenticação. Tal serviço pode ser o primeiro serviço ou pode ser um de uma pluralidade de 20 serviços já existentes. De acordo com a identificação biométrica o cartão 8 está ligado diretamente ao usuário 1. O provedor do novo serviço agora transmite um token 84 para o usuário 1. Este token 84 pode ser emitido a partir do AuSU, AXS-CA ou AXS-PI. Só é importante que o provedor de serviço confie no remetente do token 84. O fornecimento do token 94 portanto recebeu o numerai de referência 47. O token pode ser, como sugerido pela forma gráfica na fig. 7, um cartão inteligente, o chip de um Cartão-SIM ou equivalente ou uma senha de uso único ou link para acessar uma página segura da rede. Só é importante que com o primeiro uso do token 84 o cartão 8 inicie um canal seguro 41 entre o cartão e o AuSU bem como um acesso seguro para o novo segmento 71 ou registro 75 a ser ativado. Claro que é possível que o token seja um cartão inteligente 84 criando ele mesmo um canal seguro 40 entre o cartão 8 e o cartão inteligente 84, mas também é possível que o token de uso único seja usado dentro do cartão 8 sem hardware externo.

Com a abertura deste canal 41 uma carga útil de mensagem relacionada com a nova identidade é canalizada para o cartão 8 e então ou processada e validada pelo token 84 ou validada diretamente pelo token de uso único como mencionado acima. No fim, ou um novo segmento 71 é inicializado e/ou um novo registro 75 dentro de um segmento 71 existente.

Na plataforma acima descrita as credenciais de identidade podem ser pares de chaves assimétricas assinadas. A chave privada do par está sempre encerrada em uma memória segura da entidade que a usa para se autenticar. A correspondente chave pública é distribuída e assinada pelo CA para todos os casos que desejem identificar o proprietário da parte privada da chave. Todas as mensagens criptografadas através da estrutura de rede são primeiro criptografadas com a chave pública do receptor e assinadas com a chave privada do remetente. 0 sistema pode operar com diferentes esquemas de criptografia assimétrica: RSA, ECC, criptografia ElGamal com comprimento de chave apropriado conhecido pela pessoa experiente na técnica.

A arquitetura de dados da plataforma prevê um registro de chave para cada relação comercial que o portador do cartão tenha com um operador de aplicação (AuSU, 66) que requeira autenticação. 0 serviço de autenticação é provido pelo provedor de serviço de autenticação (AuSP, 63) que está ou integrado no IMS do AuSU 66 ou um serviço externo dedicado. O AuSP 63 registra o Usuário-Final e ativa o correspondente Registro Chave no cartão 8, 9 com a permissão do CA 64 que possui o segmento de armazenagem de chave 71 no cartão. O AuSP 63 fornece ao mesmo tempo sua credencial de identidade no cartão 8 com propósitos de autenticação mútua. Após o registro do cartão 8 no AuSP 63 o registro chave 75 tem uma chave privada ativada (dentro de 76) como credencial de identidade e (opcional) uma chave pública do AuSP 63 que será usada para autenticar o servidor do AuSP 63 pelo cartão 8. No caso de uma bolsa 9 alguns dos registros chave contêm campos adicionais para as informações de chave para a comunicação com o cartão inteligente conectado.

Como mostrado na fig. 13, um cartão 8 é emitido pelo produtor do cartão (AXS-PI, 67). Cada cartão 8, 9 pode ser usado por vários CAs 64 independentes, cada CA 64 usando um segmento 71 do cartão 8 tendo recebido uma licença para tal uso. Cada CA 64 pode armazenar um conjunto de credenciais de identidade (registros chave inicializados) 75 no cartão 8 mediante solicitação do Usuário Final. As credenciais de identidade de um CA 64 estão todas armazenadas em um segmento alocado próprio 71 com um certo número de registros chave 75 que podem ser ativados em um dado momento pelo CA 64 ou um AuSP 63 afiliado ao CA 64. 0 CA 64 emitindo cartão fornece o cartão 8 com o primeiro segmento 71 inicializado. Ele também cuida da primeira matrícula do usuário com o cartão 8. 0 CA 64 que inicializa um segmento de armazenagem de chave 71 adicional depois disso pode requerer a operação de um novo protocolo de matrícula ou pode aceitar a matrícula do CA 64 emissor do cartão. A correspondente informação (código de matrícula pessoal chamado FingerCode para o segmento 71 e o correspondente mapeamento da impressão digital) são armazenados dentro do segmento 71 junto com o certificado do CA (chave pública). A inicialização por um CA adicional também pode acontecer após a emissão do cartão para o usuário. É suficiente que os códigos de acesso necessários sejam pré-def inidos logo após o carregamento do firmware 102 (AXS-PI) no cartão.

Cada registro chave contém informações de manuseio adicionais que definem o comprimento da chave usada, o algoritmo criptográfico e o tratamento dos dados da mensagem. O acesso aos segmentos 71 e a cada chave 75 dentro está sob o controle único do correspondente CA 64. Mas para a inicialização do segmento e dos registros chave o CA 64 tem que obter códigos de acesso de segmento (SAC) e de acesso de registro chave (KAC) que são fornecidos pelo produtor de cartão AXS-PI 67. Para cada registro chave ativado uma data de expiração (KED) é definida. A KED é definida no momento da ativação do registro chave (registro do cartão 8 em um AuSP 63). O registro chave está ativo até que a última data no registro de Registro de Evento e Hora seja mais nova que a KED. Após isso respectivamente no próximo uso da credencial de registro chave a KED deve ser renovada para uma nova data. Esta renovação solicita um código de renovação de chave (KRC) que também é fornecido pelo produtor do cartão. Estes mecanismos de destravamento e renovação permitem uma ativação de licença periódica para todas as credenciais de identidade em uso. Um mecanismo similar permite revogar uma única credencial dentro de um cartão sem afetar a usabilidade do cartão e as outras credenciais no cartão.

Os parâmetros de controle e de meta-dados permitem realizar com o mesmo cartão 8 casos de uso e modelos comerciais completamente diferentes sem alterar o firmware básico.

Um método para preparar tal cartão 8 e um token adicional 84 como descrito acima é ilustrado nas figs. 4 e 5 e descrito como segue.

A produção do cartão 8, 9 compreende as seguintes etapas:

- produção de hardware 100, onde o cartão 8 ou a bolsa 9 serão fabricados.

- Carregar firmware 101. O firmware será carregado no cartão.

- O hardware bem como o firmware serão testados.

Se todos os testes tiverem sucesso, o cartão 8, 9 é designado como "Cartão Anônimo" e então está pronto para carregar os diferentes identificadores, credenciais e códigos.

As etapas seguintes individualizam o cartão anônimo:

Carregar códigos de ativação e renovação de inicialização de cartão 102.

A instância de inicialização alimenta um mapa de identificadores no banco de dados de credenciais de identidade e inicializa o cartão 8, 9 com os identificadores (IDT, IDS, IDX) e os códigos de controle de licença (SAC, KAC, KRC) e define em cada registro a data de expiração da chave (KED) . Após esta etapa o hardware e firmware só são acessíveis através dos canais de comunicação standard (p.ex., RFID, interface ótica, etc.).

Após as etapas de produção e inicialização os cartões individualizados 8, 9 são despachados para o CA 64. 0 CA 64 opera em cada cartão 8, 9 o seguinte protocolo de carregamento de chave: - Carregar a chave pública de CA (PubCA) para o PubCA de lote específico no segmento aberto pelo código SAC 102, 104 .

- Inicializar os registros chave do segmento com a IDX PrivKey [Chave Privada], o código de ativação de chave (KAC) e os controles de comando que definem as operações nas mensagens.

Depois disto as seguintes etapas serão aplicadas:

- Matrícula de usuário com o registro dos gabaritos de referência biométrica no cartão 105

O CA 64 inicializa o cartão com credenciais de identidade criptográfica digital e produz os correspondentes certificados. Ele os fornece (cartões e opcionalmente os certificados) para centros de matrícula afiliados (EC) . Cada certificado contém informações sobre o nível de segurança que foi aplicado para o processo de matrícula pelo CA 64 emissor e respectivamente seu EC. Existem três ambientes de matrícula com diferentes níveis de segurança e com facilidade de organização inversamente proporcional:

Como uma segurança de matrícula de lo nível um modelo de distribuição se aplica. A matrícula pode ser em qualquer lugar após o cartão e um código de habilitação de emitido pelo governo). O novo Usuário-Final então opera o protocolo de matrícula em um terminal dedicado no EC. O código de matrícula é provido pelo oficial do EC. Um usuário 1 que depois desejar um upgrade do nível de segurança de seu cartão 8, 9 tem que passar por um novo processo de matrícula ou uma verificação de que sua matrícula é compatível com o nível de segurança pretendido. O processo de inicialização e matrícula do CA e do EC podem ser certificados através de normas de certificação reconhecidas (CC, IPSEC, FIPS) para garantir confiança mútua se mais que um CA emitir cartões e certificá-los. O processo de matrícula é o mesmo para todos os três níveis de segurança. Ele estabelece um link de fator 2 ou 3 entre o usuário como uma pessoa e o cartão 8, 9. Após uma matrícula correta cada certificado representa uma credencial de identidade digital certificada independente para a identidade do Usuário. Em todos os sistemas de autenticação a matrícula é uma etapa crítica que inclui um conhecimento e convicção a priori sobre a identidade de uma pessoa 1. Na maioria dos casos a informação de identidade inicial vem de um IMS governamental. O registro e administração das identidades de seus cidadãos é uma das mais importantes tarefas de qualquer estado. Todo IMS tem que depender de algum tipo de credenciais emitidas por governo oficial.

Após o término do protocolo de matrícula o nível de segurança de matrícula é escrito no cartão 8, 9 e pode ser pesquisado em processos adicionais de registro ou autenticação.

Após a matrícula o cartão está pronto para ser usado. Para isso o usuário (portador do cartão matriculado) faz as seguintes duas operações:

- Registro no AuSP 106 no primeiro acesso a um novo sítio ou serviço

- Autenticação tão freqüente quanto o usuário necessite para provar sua identidade para acessar sítios ou serviços restritos 107. Após as etapas mencionadas acima, o cartão 8, 9 é um cartão operativo 8, 9 para o uso com o AuSP 66. Entretanto se as credenciais expirarem, elas pode ser destravadas com um código de renovação de chave 108. Se o código for válido, o cartão será destravado. Se o código for inválido a chave específica no cartão será bloqueada. Adicionalmente se a bolsa 9 for usada em combinação com o token adicional 84, uma inicialização 110 da bolsa 9 e do token adicional 94 é necessária.

A opção de bolsa 9 permite uma personalização a posteriori da funcionalidade do token adicional 94. A resposta específica para uma carga útil de mensagem é processada no token adicional 94 que pode ser um cartão inteligente ou um outro token removível que pode ser enganchado no cartão. A bolsa 9 (cartão com uma fenda mecânica 91 para prender um cartão inteligente) serve como um dispositivo de autenticação que transmite a mensagem descriptografada para o SMC através de um canal seguro 40 entre a bolsa e o SMC. Este canal seguro 40 é estabelecido a primeira vez que o token adicional 94 é introduzido na bolsa 9 por um mecanismo simétrico. Após esta inicialização o token adicional 94 pode somente se comunicar com a bolsa inicial 9. Todos os outros canais de comunicação com outros dispositivos (leitores de cartões) não são alterados por esta operação de inicialização. O mesmo é verdadeiro, se a carga útil da mensagem for processada com o auxílio do token de software de uso único adicional para inicializar um dado segmento 71 ou registro 75.

O cartão 8, 9 pode ser registrado no AuSP/AuSU. Quando o usuário entra em uma relação comercial com um operador (AuSU/AuSP) o próximo certificado disponível do cartão 8, 9 do usuário tem que ser fornecido para o servidor de autenticação do operador. Este certificado é então alocado unicamente para a autenticação do usuário nesta rede específica de operador. 0 servidor de autenticação pode ser parte do IMS do próprio operador ou pode ser matrícula especial terem sido enviados ao usuário através de um canal seguro (nível de segurança standard, p.ex. aplicado com distribuição de cartões de crédito). O cartão é despachado para o usuário final por um canal de distribuição não seguro mas confiável (correio terrestre, escritórios de HR dentro de uma organização, etc.). Em paralelo um código de matrícula é despachado para o usuário final através de um canal seguro (p.ex., Correio Registrado). Com o código de matrícula o usuário final pode operar um protocolo de matrícula em qualquer computador conectado à Internet. O protocolo de matrícula é provido pelo servidor de autenticação do CA.

Como uma segurança de matrícula de 2° nível um modelo de árvore confiável se aplica. A matrícula é na presença de uma pessoa de confiança e já matriculada que está autorizada a matricular novos usuários (nível de segurança reforçado). O novo usuário final recebe seu cartão 8, 9 de um agente que o conhece pessoalmente e que já possui um cartão matriculado. O novo usuário final recebe o correspondente código de matrícula em um mesmo canal seguro que no modelo distribuído. Para operar o protocolo de matrícula para o novo cartão 8, 9, o agente tem que se iniciar em qualquer computador conectado à internet com seu cartão 8, 9. Então o novo usuário opera o processo de matrícula standard a partir do mesmo terminal de computador. O agente conhece o novo usuário e portanto garante que somente a pessoa certa seja matriculada. Ele atua como um EC móvel temporário.

Como uma segurança de matrícula de 3° nível um modelo de autenticação certificada se aplica. A matrícula dentro de um sítio confiável (EC) sob supervisão humana com a apresentação de um passe de identidade oficial (alto nível de segurança). O CA regulamenta e certifica sítios específicos em um ambiente protegido para ser um centro de matrícula (EC). Um novo Usuário-Final recebe o cartão 8, 9 no EC após uma verificação de sua identidade através de um oficial do EC (p.ex. apresentação de um passaporte operado por um Provedor de Serviço de Autenticação (AuSP) externo.

No registro na rede o cartão 8, 9 é registrado em um IMS de um Provedor de Serviço de Autenticação (AuSP). O registro do cartão 8, 9 ativa a próxima chave não usada na lista das chaves armazenadas inicialmente (IDX). A mensagem também contém a PubKey assinada pelo CA do AuSP. Isto permite então autenticação mútua entre o servidor e o cartão 8, 9.

A seção de renovação de chave em cada registro chave é um campo de controle de licença. Ele contém o código de renovação de chave (KRC) que bloqueia o acesso a este campo para mensagens não legítimas. No campo também está o código de expiração de chave, que define a data de validade do registro real. Após passar a data de validade, um novo código de renovação de chave (enviado pela instância autorizada) tem que ser armazenado no registro e a KED tem que ser definida para a nova data de expiração.

Para todos os cartões 8, 9 editados, o provedor mantém um sistema de administração de credenciais. Este sistema fornece os códigos necessários para armazenar, inicializar e operar as credenciais de identidade no cartão. Ele também permitirá reproduzir em colaboração com o CA envolvido cartões perdidos ou roubados sem excessiva interação do usuário (somente a re-matrícula do usuário é necessária).

Com referência à fig. 7, nenhuma rede confiável de operadores é necessária para realizar a federalização de identidades. Muitas organizações de confiança mútua ou de nenhuma confiança diferentes pode usar o mesmo cartão 8, 9 para autenticar seu proprietário. A única restrição é que as organizações devem garantir ou acreditar que o cartão está realmente em mãos do alegado usuário. Isto pode ser feito por uma checagem de matrícula. Cada operador pode fazer tal checagem a qualquer momento através da internet (veja o protocolo de matrícula). Normalmente é suficiente que o operador consiga acesso a uma credencial específica dentro do cartão 8, 9a partir do CA editando. O CA então garante em um nível de segurança especificado que o cartão identificado 8, 9 está na posse única do legítimo proprietário. Uma nova relação comercial é então muito fácil de iniciar. O usuário só registra seu cartão 8, 9 pessoal no IMS do operador. O operador toma o código de acesso para uma das credenciais de identidade pré-inicializadas no cartão 8, 9 e estabelece uma relação biunívoca com este usuário baseado na credencial de identidade alocada específica. Este esquema realiza uma federalização de identidade ilimitada através de todos os operadores que aceitam a autenticação.

Dessa forma o cartão 8, 9 usa as mesmas credenciais de identidade para acesso tanto lógico quanto físico. A separação entre sistemas de acesso lógicos e físicos vem parcialmente do fato que dois diferentes conceitos de comunicação são usados. Para acesso físico nós freqüentemente usamos um cartão de circuito integrado (cartões inteligentes) que retém uma credencial de identidade que nós temos que apresentar (com contato ou sem contato) a um leitor no portal de entrada. Para acesso lógico nós freqüentemente temos que submeter um código secreto através de um teclado no processo de autenticação.

Com o dispositivo e o método de acordo com a presente invenção estas duas formas de autenticação são integradas no mesmo esquema. As mesmas credenciais de identidade são usadas para fornecer as provas de identidade requeridas através de canais de comunicação apropriados. O cartão 8, 9 gera a prova (OTP) e a fornece através da tela de LCD interna para a infra-estrutura de acesso lógico. Para acesso físico a mesma credencial de identidade fornece a prova de identidade através do canal de comunicação RFID embutido (Norma ISO 14443) para o leitor no portal. Isto significa que a unificação de acessos lógico e físico pode ser feita com mínimas mudanças na infra-estrutura existente.

A ISO usa o termo "Cartão de Circuito Integrado" para abranger todos aqueles dispositivos onde um circuito integrado está contido dentro de uma peça de plástico de cartão de identificação ISO 1 do tamanho standard de um cartão de crédito (comumente denominado cartão inteligente). Cartões de Circuito Integrado vêm em duas formas, com contato e sem contato. A tecnologia de cartão inteligente é usada crescentemente em aplicações que devem proteger informações pessoais ou fornecer transações rápidas e seguras.

O cartão 8, 9 de acordo com a presente invenção é capaz de tornar cartões inteligentes acessíveis em qualquer lugar. Dessa forma novas aplicações para propósitos comerciais serão criadas. 0 uso de Cartões Inteligentes depende da disponibilidade de um leitor local o que restringe a mobilidade e os campos de aplicação dos cartões. O cartão 8, 9 é projetado para estabelecer uma conexão segura com cartões inteligentes e servir em alguma extensão como leitor móvel pessoal. Com a solução do cartão 8, 9 novos serviços podem ser pendurados no sistema de autenticação mesmo após lançamento público. 0 operador só envia cartão inteligente particularizado para seu novo serviço aos usuários que podem acessar o novo serviço inserindo o cartão inteligente ou token adicional 94 no cartão 8, 9.

Ao invés de um cartão inteligente com o tamanho standard somente o campo de conexão do cartão inteligente (chip e conector (como um cartão SIM)) pode ser usado como um encaixe no cartão 8. Isto permitiria uma solução simplificada para o conceito de bolsa como descrito acima.

O dispositivo e método de autenticação de acordo com a presente invenção são flexíveis para servir a diferentes modelos de operação de acordo com as necessidades de autenticação do operador ou da comunidade do operador. Isto será ilustrado por meio das figuras 10 a 13. A figura 10 mostra a presente invenção em uma operação independente. Nesta operação uma organização combina as regras do CA, do EC, do AuSP e do AuSU. A organização opera um IMS próprio usando a autenticação para controlar o acesso físico e lógico de usuários autorizados aos recursos da organização. Ele toma o cartão 8 e os códigos de licença do produtor 67 e os distribui a seus usuários. A figura 11 mostra a presente invenção em uma operação de serviço de autenticação. No modelo de operação de serviço de autenticação uma organização 68 fornece a várias organizações 66 o serviço de administração de identidades e verificação de credenciais de identidade. A aplicação principal de tal serviço é a autenticação de usuários on- line para operadores de plataformas comerciais. 0 provedor de serviço de autenticação 68 combina as regras do CA, do EC e do AuSP. Ele distribui os cartões e administra credenciais de identidade para os diferentes operadores que têm uma relação comercial com o Usuário- Final de um cartão. O AuSP pode operar um portal específico baseado na Web para empacotar todos os acessos providos.

A fig. 12 mostra a presente invenção em uma operação de autoridade de certificação. Neste modelo de operação uma organização pública ou privada já estabelecida e reconhecida assume o papel de um CA 64. Ela opera EC e prove outras organizações 69 (AuSP + AuSU) com chaves públicas certificadas dos cartões, tal que estas organizações possam verificar a identidade dos Usuários Finais sempre que eles entrarem em relação comercial com o AuSU.

A figura 13 mostra a presente invenção em uma operação federalizada. Neste modelo vários CAs 64 podem inicializar cartões 8 com sua chave certificada como credenciais de identidade. Cada carta 8 pode conter vários segmentos de credencial de identidade independentes 71 cada um alocado a um diferente CA 64. Cada CA 64 então opera para sua organização cliente 69 como um CA 64 independente para o segmento de credencial no cartão 8 que foi certificado pelo CA 64 específico. Cada CA 64 tem que comprar um código de ativação de segmento que o permita armazenar suas credenciais em um segmento de cartão 71 específico. Este carregamento subseqüente de chaves para um cartão 8 por um CA 64 não interfere com as credenciais dos outros CA's 64 carregadas anteriormente. Cada CA 64 pode requerer uma verificação de matrícula a partir do Usuário Final de acordo com sua política de segurança.

Em uma configuração de tecnologia reforçadora de privacidade especial um CA fornece ao usuário final os certificados assinados para as credenciais carregadas. 0 usuário final então fornece em um processo de registro o correspondente certificado para o AuSP. 0 AuSP pode então verificar o certificado sem perguntar ao CA e aquele não é capaz de rastrear as relações comerciais de um usuário nem pode o AuSP verificar informações pessoais adicionais além daquelas fornecidas com o certificado. Este esquema permite estabelecer o conceito de um pseudônimo confiável e certificado que pode ser diferente para cada AuSP. Isto protege o usuário de ataques de perfilação e o permite manter máxima anonimidade em transações on-line. O sistema de autenticação pode operar todos os modelos de operação descritos acima sem qualquer modificação do cartão 8 ou da plataforma de autenticação. Para isto, uma arquitetura de dados patenteada para a armazenagem virtual e a administração das credenciais de identidade foi desenvolvida como esboçada acima.

Numerais de referência

1 Pessoa física, usuário-final

2 unidade de acesso, servidor de credenciais do IMS ou AuSP

3 Token, realizado como cartão ou bolsa

4 método de fabricação para o cartão, ciclo de vida

5 método de fabricação para a bolsa, ciclo de vida 6 plataforma de autenticação, incluindo servidor de CA, servidor de AuSP

7 Sistema de autenticação completo com os três subsistemas funcionais: token pessoal; plataforma de autenticação com a infra-estrutura específica; módulo de interface para IMS existente e administrações de usuários de aplicação

8 Cartão

9 Bolsa

10 dispositivos de entrada para dados biométricos e de conhecimento secreto

11 Sistema de verificação de identidade a bordo: 2- ou 3- fatores

12 módulos de autenticação, interfaces para sistemas e aplicações existentes

13 aplicações seguras

31 Dados pessoais para verificação de fator de autenticação

32 embutimento interno de dados personalizados (chaves privadas secretas) nos registros chave

33, 33' chave privada, dados digitais personalizados

34, 34' registro de credencial de identidade digital (registro chave)

35, 35' transmissão para o sistema AuSP

40 canal de comunicação seguro/criptografado

41 canal de comunicação seguro/criptografado

42 carga útil com mensagem e instruções secretas

47 fornecimento de token

51 identidade do token (IDT)

52 identidade do segmento (IDS)

53 código de ativação do segmento (SAC)

54 código de ativação de chave (KAC)

55 registro de matrícula global

61 Equipamento de terminal de dados no sítio do usuário final com um display de tela para o código vibrante ótico

62 equipamento leitor de RFID 63 Provedor de serviço de autenticação (AuSP)

64 Autoridade de Certificação (CA)

65 Servidor de Licenças

66 Usuário de serviço de autenticação (AuSU, operador)

67 Produtor de token (AXS-PI)

68 Organização operacional de CA e AuSP combinados

69 Organização operacional de AuSP e AuSu combinados

71 segmento de armazenagem de chave

72 Códigos de controle para tratamento de criptograma e carga útil

73 endereço de registro chave

74 registros de matrícula, gabaritos de referência e segredo

75 registros chave

76 seção de armazenagem de chave

77 seção de renovação de chave

78 registro de matrícula de segmento

79 chave pública do CA

81 cavidade de recepção

82 direção de inserção

83 informações pessoais com meio de armazenagem

84 cartão de dados do chip

85 interfaces

91 fenda

92 direção de inserção

93 informações pessoais

94 cartão de dados adicional

95 interfaces

96 meio de armazenagem

Claims (13)

1. Token de segurança, caracterizado pelo fato de compreender: - uma memória de dados pessoais para armazenar, baseado em dados pessoais (31) do usuário e/ou dados personalizados, credenciais de identidade digital (33, -34; 33', 34'); - um dispositivo de entrada (10) para permitir a checagem dos citados dados pessoais, preferivelmente com uma verificação de identidade a bordo usando 2 ou 3 fatores de autenticação; - uma memória de dados de registro chave (71, 75) para armazenar pelo menos uma credencial de identidade de um servidor de autenticação (63, AuSP) ou de um operador de aplicação (66, AuSU), preferivelmente para armazenar uma pluralidade de credenciais de identidade inicializadas por uma autoridade de certificação (CA) ; - uma unidade transmissora e receptora para criar um canal seguro (41) diretamente ou indiretamente (66) com o citado servidor de autenticação (63, AuSP) ou operador de aplicação (66, AuSU) ou autoridade de certificação (CA) para manusear o citado registro chave (71, 75) relacionado com o citado servidor de autenticação (63, AuSP) ou operador de aplicação (66, AuSU) ou autoridade de certificação (CA), respectivamente; e uma unidade de controle para controlar a unidade transmissora e receptora bem como a memória de dados de registro chave (71, 75) em vista do citado manuseio, compreendendo uma ação a partir do grupo de interpretação, decifração, criação, checagem, renovação, extração e ações adicionais de manuseio de registro chave.

2. Token de segurança, de acordo com a reivindicação 1, caracterizado pelo fato de o conteúdo de um token adicional (84, 94) ser alimentado à unidade de controle para executar uma checagem de identidade ao criar ou ativar um novo registro chave (71, 75) ou usar um registro chave ativado com uma nova instrução de carga útil.

3. Token de segurança, de acordo com a reivindicação 2, caracterizado pelo fato de compreender um elemento de circuito eletrônico como o token adicional (84, 94) compreendendo meios transmissores e receptores adicionais para criar um canal seguro adicional (40) para o citado token de segurança receber uma carga útil de mensagem (42) do servidor de autenticação (63, AuSP) ou operador de aplicação (66, AuSU) , e meios de processamento para fornecer uma mensagem processada para a citada unidade de controle.

4. Token de segurança, de acordo com a reivindicação 2, caracterizado pelo fato de um segredo ser o token adicional (84, 94) como entrada para controlar a unidade de controle.

5. Token de segurança, de acordo com qualquer uma das reivindicações de 1 a 4, caracterizado pelo fato de ser provida uma pluralidade de registros chave (75) , sendo que a unidade de controle compreende elementos de ativação de registro habilitando uma autoridade de certificação (64, CA) ou servidor de autenticação (63, AuSP) para manusear todos os registros para distribuir autorizações para manusear diferentes registros chave (75) para diferentes servidores de autenticação (63, AuSP) ou operadores de aplicação (AuSU), respectivamente.

6. Token de segurança, de acordo com a reivindicação 5, caracterizado pelo fato de dois ou mais segmentos chave (71) serem providos compreendendo pelo menos um de cada da pluralidade de registros chave (75) sendo que a unidade de controle compreende elementos de ativação de segmento habilitando uma autoridade de certificação (64, CA) para manusear todos os registros chave de um segmento chave (71) e para distribuir autorizações para manusear diferentes registros chave (75) para diferentes servidores de autenticação (63, AuSP) ou operadores de aplicação (AuSU).

7. Token de segurança, de acordo com qualquer uma das reivindicações de 1 a 6, caracterizado pelo fato de a memória de dados pessoais e o dispositivo de entrada serem providos para armazenar e checar dados biométricos como dados pessoais e/ou um segredo como dados pessoais do usuário.

8. Método para a autenticação de um usuário com o token de segurança, de acordo com qualquer uma das reivindicações de 1 a 7, caracterizado pelo fato de compreender as etapas de: checar dados pessoais armazenados do usuário para verificar a autorização do usuário para usar o citado token de segurança, - criar um canal seguro entre o token de segurança para manusear um registro chave relacionado com um servidor de autenticação (63, AuSP) ou operador de aplicação (66, AuSU) compreendendo uma ação a partir do grupo de interpretação, decifração, criação, checagem, renovação, extração e ações adicionais de manuseio de registro chave.

9. Método, de acordo com a reivindicação 8, caracterizado pelo fato de uma federalização ilimitada de identidade ser provida pela etapa que o token de segurança (8, 9) recebe uma carga útil de mensagem de um servidor de autenticação (63, AuSP) ou operador de aplicação (66, AuSU) através do canal seguro (41) e submete a citada mensagem através de um canal seguro adicional (40) para um token adicional (84, 94) processando a citada mensagem e enviando a mensagem processada de volta para o token de segurança (8, 9) para autenticar o usuário via este token de segurança.

10. Método, de acordo com a reivindicação 9, caracterizado pelo fato de o canal seguro adicional (40) ser estabelecido a primeira vez que o token adicional (84, 94) é introduzido no cartão (8, 9) para criar, ativar ou ser ligado a um registro chave (71, 75) dentro da memória do token de segurança.

11. Método, de acordo com qualquer uma das reivindicações de 8 a 10, caracterizado pelo fato de o token de segurança ser usado para escanear um código vibrante em um display do operador de aplicação (66, AuSU) para autenticar a validade da interface.

12. Método, de acordo com qualquer uma das reivindicações de 8 a 11, caracterizado pelo fato de a autenticação positiva do token de segurança ser usada para permitir acesso a uma aplicação de software, para efetuar um pagamento, para criar um tíquete, para receber uma mensagem secreta ou para permitir acesso físico, especialmente para abrir uma porta.

13. Método para a autenticação de um usuário com o token de segurança, o token de acordo com qualquer uma das reivindicações de 1 a 7, caracterizado pelo fato de ser com a administração controlada por usuário das credenciais de identidade assinadas pelo CA usáveis para gerar um link seguro e confiável com um dos registros chave (71, 75) dentro do token (8, 9).