BRPI0618725A2 - método analisador de dados seguro e sistema - Google Patents

Abstract

MéTODO ANALISADOR DE DADOS SEGURO E SISTEMA. A presente invenção refere-se a um analisador de dados seguro é provido que pode ser integrado em qualquer sistema adequado para armazenar e comunicar dados com segurança. O analisador de dados seguro analisa os dados e a seguir divide os dados em múltiplas porções que são armazenadas ou comunicadas distintamente. A criptografia dos dados originais, das porções dos dados ou de ambos pode ser utilizada para segurança adicional. O analisador de dados seguro pode ser usado para proteger os dados em movimento dividindo os dados originais em porções de dados, que podem ser com unicadas usando múltiplas trajetórias de comunicações.

Description

Relatório Descritivo da Patente de Invenção para "MÉTODO ANALISADOR DE DADOS SEGURO E SISTEMA".

Referência Cruzada a Pedidos Relacionados

Esse pedido reivindica o benefício do pedido provisório U.S. No. 60/738.231, depositado em 18 de novembro de 2005, que é aqui incorpora- do por referência na sua integridade.

Campo da Invenção

A presente invenção refere-se, em geral, a um sistema para pro- teger os dados contra o acesso ou uso desautorizado.

Antecedentes da Invenção

Na sociedade atual, indivíduos e negócios conduzem uma quan- tidade cada vez mais crescente de atividades em e através dos sistemas de computador. Esses sistemas de computador, incluindo redes de computador proprietárias e não proprietárias, estão freqüentemente armazenando, arqui- vando e transmitindo todos os tipos de informação sensível. Assim, uma ne- cessidade cada vez mais crescente existe para garantir que os dados arma- zenados e transmitidos através desses sistemas não possam ser lidos ou de outra forma comprometidos.

Uma solução comum para garantir os sistemas de computador é prover a funcionalidade de conexão e senha. Entretanto, o gerenciamento de senha provou ser muito oneroso com uma grande porcentagem de chama- das ao suporte técnico relacionadas com emissões de senha. Além do mais, as senhas provêem pouca segurança já que elas são geralmente armazena- das em um arquivo suscetível ao acesso desapropriado, através, por exem- pio, de ataques de força bruta.

Uma outra solução para garantir os sistemas de computador é prover infra-estruturas criptográficas. A criptografia, em geral, se refere à proteção de dados pela transformação, ou criptografia, dos mesmos em um formato ilegível. Somente esses que possuem a(s) chave(s) para a criptogra- fia podem decriptografar os dados em um formato utilizável. A criptografia é usada para identificar usuários, por exemplo, autenticação, para permitir pri- vilégios de acesso, por exemplo, autorização, para criar certificados e assi naturas digitais e assim por diante. Um sistema de criptografia popular é um sistema de chave pública que usa duas chaves, uma chave pública conheci- da para qualquer um e uma chave privada conhecida somente para o indiví- duo ou o dono do negócio do mesmo. De forma geral, os dados criptografa- dos com uma chave são decriptografados com a outra e nenhuma das cha- ves pode ser recriada a partir da outra.

Infelizmente, mesmo os sistemas criptográficos típicos prece- dentes de chave pública são ainda altamente dependentes do usuário para segurança. Por exemplo, os sistemas criptográficos emitem a chave privada para o usuário, por exemplo, através do navegador do usuário. Usuários não sofisticados então geralmente armazenam a chave privada em uma unidade rígida acessível para outros através de um sistema de computador aberto, tal como, por exemplo, a Internet. Por outro lado, os usuários podem esco- lher nomes fracos para arquivos contendo sua chave privada, tal como, por exemplo, "chave". O resultado do precedente e outras ações é permitir que a chave ou chaves fiquem suscetíveis ao comprometimento.

Além dos comprometimentos precedentes, um usuário pode sal- var a sua chave privada em um sistema de computador configurado com um sistema de arquivo ou sobressalente, potencialmente resultando em cópias da chave privada percorrendo através de múltiplos dispositivos de armaze- namento de computador ou outros sistemas. Essa brecha da segurança é freqüentemente conhecida como a "migração de chave". Similar à migração de chave, muitas aplicações provêem acesso a uma chave privada do usuá- rio através, quando muito, de simples acesso de conexão e senha. Como mencionado no precedente, o acesso de conexão e senha freqüentemente não provê segurança adequada.

Uma solução para aumentar a segurança dos sistemas cripto- gráficos precedentes é incluir biométrica como parte da autenticação ou au- torização. Biométricas geralmente incluem características físicas mensurá- veis, tais como, por exemplo, impressões do dedo ou fala que podem ser verificados por um sistema automatizado, tal como, por exemplo, combina- ção de padrão ou reconhecimento dos padrões de impressão de dedo ou padrões de fala. Em tais sistemas, a biométrica de um usuário e/ou chaves podem ser armazenadas em dispositivos de computação móveis, tais como, por exemplo, um cartão inteligente, laptop, assistente digital pessoal ou tele- fone móvel, dessa maneira permitindo que a barométrica ou chaves sejam utilizáveis em um ambiente móvel.

O sistema criptográfico biométrico móvel precedente ainda sofre de uma variedade de desvantagens. Por exemplo, o usuário móvel pode perder ou quebrar o cartão inteligente ou dispositivo de computação portátil, dessa maneira tendo o seu acesso aos dados potencialmente importantes inteiramente interrompido. Alternativamente, uma pessoa maliciosa pode roubar o cartão inteligente ou dispositivo de computação portátil do usuário móvel e usá-lo para efetivamente roubar as credenciais digitais do usuário móvel. Por outro lado, o dispositivo de computação portátil pode ser conec- tado em um sistema aberto, tal como a Internet, e, como as senhas, o arqui- vo onde a biométrica está armazenada pode ser suscetível ao comprometi- mento através da desatenção do usuário aos invasores de segurança ou maliciosos.

Sumário da Invenção

Com base no precedente, existe uma necessidade de prover um sistema criptográfico cuja segurança é independente do usuário enquanto ainda suportando usuários móveis.

Dessa maneira, um aspecto da presente invenção é prover um método para proteger virtualmente qualquer tipo de dados do acesso ou uso desautorizado. O método compreende uma ou mais etapas de análise, divi- são e/ou separação dos dados a serem protegidos em duas ou mais partes ou porções. O método também compreende criptografar os dados a serem protegidos. A criptografia dos dados pode ser executada antes de ou depois da primeira análise, divisão e/ou separação dos dados. Além disso, a etapa de criptografia pode ser repetida para uma ou mais porções dos dados. Simi- larmente, as etapas de análise, divisão e/ou separação podem ser repetidas para uma ou mais porções dos dados. O método também compreende op- cionalmente armazenar os dados analisados, divididos e/ou separados que foram criptografados em uma localização ou em múltiplas localizações. Esse método também compreende opcionalmente reconstituir ou remontar os da- dos seguros na sua forma original para acesso ou uso autorizado. Esse mé- todo pode ser incorporado nas operações de qualquer computador, servidor, mecanismo ou similares, que é capaz de executar as etapas desejadas do método.

Um outro aspecto da presente invenção provê um sistema para proteger virtualmente qualquer tipo de dados do acesso ou uso desautoriza- do. Esse sistema compreende um módulo de divisão de dados, um módulo de manipulação criptográfico e, opcionalmente, um módulo de montagem de dados. O sistema pode, em uma modalidade/ainda compreender uma ou mais facilidades de armazenamento de dados onde os dados seguros po- dem ser armazenados.

Dessa maneira, um aspecto da invenção é prover um servidor seguro, ou mecanismo de confiança, tendo chaves centrais do servidor, ou em outras palavras, armazenando chaves criptográficas e dados de autenti- cação do usuário em um servidor. De acordo com essa modalidade, um u- suário acessa o mecanismo de confiança a fim de executar a autenticação e funções criptográficas, tais como, mas não-limitado a, por exemplo, autenti- cação, autorização, assinatura e geração digital, armazenamento e recupe- ração de certificados, criptografia, ações semelhantes a notários e similares à procuração legal e assim por diante.

Um outro aspecto da invenção é prover um processo de autenti- cação confiável ou de confiança. Além do mais, subseqüente a uma autenti- cação positiva digna de confiança, um amplo número de ações diferentes pode ser adotado, do provimento da tecnologia criptográfica, para autoriza- ção e acesso do sistema ou dispositivo, até a permissão do uso ou controle de um ou um amplo número de dispositivos eletrônicos.

Um outro aspecto da invenção é prover chaves criptográficas e dados de autenticação em um ambiente onde eles não são perdidos, rouba- dos ou comprometidos, dessa maneira vantajosamente evitando uma ne- cessidade de continuamente reeditar e gerenciar novas chaves e dados de autenticação. De acordo com um outro aspecto da invenção, o mecanismo de confiança permite que um usuário use um par de chaves para múltiplas atividades, fornecedores e/ou solicitações de autenticação. De acordo com ainda um outro aspecto da invenção, o mecanismo de confiança executa pelo menos uma etapa de processamento criptográfico, tal como, mas não- Iimitado a, criptografia, autenticação ou assinatura, no lado do servidor, des- sa maneira permitindo que clientes ou usuários possuam somente recursos mínimos de computação.

De acordo com ainda um outro aspecto da invenção, o meca- nismo de confiança inclui um ou múltiplos depositários para armazenar por- ções de cada chave criptográfica e dados de autenticação. As porções são criadas através de um processo de divisão de dados que proíbe a reconstru- ção sem uma porção predeterminada de mais do que uma localização em um depositário ou de múltiplos depositários. De acordo com uma outra mo- dalidade, os múltiplos depositários podem estar geograficamente distantes tal que um empregado perigoso ou sistema de outra forma comprometido em um depositário não proverá acesso a uma chave do usuário ou dados de autenticação.

De acordo com ainda uma outra modalidade, o processo de au- tenticação vantajosamente permite que o mecanismo de confiança processe múltiplas atividades de autenticação em paralelo. De acordo com ainda uma outra modalidade, o mecanismo de confiança pode acompanhar vantajosa- mente tentativas de acesso falhas e dessa maneira limitar o número de ve- zes que invasores maliciosos podem tentar subverter o sistema.

De acordo com ainda uma outra modalidade, o mecanismo de confiança pode incluir múltiplas instâncias onde cada mecanismo de confi- ança pode predizer e compartilhar cargas de processamento com os outros. De acordo com ainda uma outra modalidade, o mecanismo de confiança po- de incluir um módulo de redundância para consultar seqüencialmente uma pluralidade de resultados de autenticação para garantir que mais do que um sistema autentique o usuário.

Portanto, um aspecto da invenção inclui um sistema criptográfi- co seguro, que pode ficar remotamente acessível, para armazenar dados de qualquer tipo, incluindo, mas não-limitado a, uma pluralidade de chaves crip- tográficas privadas a ser associada com uma pluralidade de usuários. O sis- tema criptográfico associa cada uma da pluralidade de usuários com uma ou mais chaves diferentes da pluralidade de chaves criptográficas privadas e executa funções criptográficas para cada usuário usando uma ou mais cha- ves diferentes associadas sem liberar a pluralidade de chaves criptográficas privadas para os usuários. O sistema criptográfico compreende um sistema depositário tendo pelo menos um servidor que armazena os dados a serem garantidos, tal como uma pluralidade de chaves criptográficas privadas e uma pluralidade de dados de autenticação de inscrição. Cada dado de au- tenticação de inscrição identifica um de múltiplos usuários e cada um dos múltiplos usuários está associado com uma ou mais chaves diferentes da pluralidade de chaves criptográficas privadas. O sistema criptográfico tam- bém pode compreender um mecanismo de autenticação que compara os dados de autenticação recebidos por um dos múltiplos usuários com os da- dos de autenticação de inscrição correspondendo com o um de múltiplos usuários e recebidos do sistema depositário, dessa maneira produzindo um resultado de autenticação. O sistema criptográfico também pode compreen- der um mecanismo criptográfico que, quando o resultado de autenticação indica identificação apropriada do um dos múltiplos usuários, executa fun- ções criptográficas em nome do um dos múltiplos usuários usando uma ou mais chaves diferentes associadas recebidas do sistema depositário. O sis- tema criptográfico também pode compreender um mecanismo de transação conectado para encaminhar os dados dos múltiplos usuários para o sistema do servidor depositário, o mecanismo de autenticação e o mecanismo crip- tográfico.

Um outro aspecto da invenção inclui um sistema criptográfico seguro que é opcionalmente acessível remotamente. O sistema criptográfico compreende um sistema depositário tendo pelo menos um servidor que ar- mazena pelo menos uma chave privada e quaisquer outros dados, tais co- mo, mas não-limitado a, uma pluralidade de dados de autenticação de ins- crição, onde cada dado de autenticação de inscrição identifica um de possi- velmente múltiplos usuários. O sistema criptográfico pode também compre- ender opcionalmente um mecanismo de autenticação que compara os dados de autenticação recebidos pelos usuários com os dados de autenticação de inscrição correspondendo com o usuário e recebidos do sistema depositário, dessa maneira produzindo um resultado de autenticação. O sistema cripto- gráfico também compreende um mecanismo criptográfico que, quando o re- sultado de autenticação indica a identificação apropriada do usuário, executa funções criptográficas em nome do usuário usando pelo menos a dita chave privada, que pode ser recebida do sistema depositário. O sistema criptográ- fico pode também opcionalmente compreender um mecanismo de transação conectado para encaminhar dados dos usuários para outros mecanismos ou sistemas tais como, mas não-limitados a, o sistema do servidor depositário, o mecanismo de autenticação e o mecanismo criptográfico.

Um outro aspecto da invenção inclui um método de facilitação das funções criptográficas. O método compreende associar um usuário de múltiplos usuários com uma ou mais chaves de uma pluralidade de chaves criptográficas privadas armazenadas em uma localização segura, tal como um servidor seguro. O método também compreende receber dados de au- tenticação do usuário e comparar os dados de autenticação com os dados de autenticação correspondendo com o usuário, dessa maneira verificando a identidade do usuário. O método também compreende utilizar uma ou mais chaves para executar funções criptográficas sem liberar a uma ou mais cha- ves para o usuário.

Um outro aspecto da invenção inclui um sistema de autentica- ção para identificar unicamente um usuário através do armazenamento se- guro dos dados de autenticação de inscrição do usuário. O sistema de au- tenticação compreende uma ou mais facilidades de armazenamento de da- dos, onde cada facilidade de armazenamento de dados inclui um meio de armazenamento acessível pelo computador que armazena pelo menos uma das porções dos dados de autenticação de inscrição. O sistema de autenti- cação também compreende um mecanismo de autenticação que se comuni- ca com a facilidade ou facilidades de armazenamento de dados. O meca- nismo de autenticação compreende um módulo de divisão de dados que o- pera nos dados de autenticação de inscrição para criar porções, um módulo de montagem de dados que processa as porções de pelo menos uma das facilidades de armazenamento de dados para montar os dados de autentica- ção de inscrição e um módulo comparador de dados que recebe dados de autenticação atuais de um usuário e compara os dados de autenticação atu- ais com os dados de autenticação de inscrição montados para determinar se o usuário foi unicamente identificado.

Um outro aspecto da invenção inclui um sistema criptográfico. O sistema criptográfico compreende uma ou mais facilidades de armazena- mento de dados, onde cada facilidade de armazenamento de dados inclui um meio de armazenamento acessível pelo computador que armazena pelo menos uma porção de uma ou mais chaves criptográficas. O sistema cripto- gráfico também compreende um mecanismo criptográfico que se comunica com as facilidades de armazenamento de dados. O mecanismo criptográfico também compreende um módulo de divisão de dados que opera nas chaves criptográficas para criar porções, um módulo de montagem de dados que processa as porções de pelo menos uma das facilidades de armazenamento de dados para montar as chaves criptográficas e um módulo de manipulação criptográfico que recebe as chaves criptográficas montadas e executa fun- ções criptográficas com elas.

Um outro aspecto da invenção inclui um método de armazena- mento de qualquer tipo de dados, incluindo, mas não-limitado a, dados de autenticação em facilidades de armazenamento de dados seguras geografi- camente remotas, dessa forma protegendo os dados contra a composição de qualquer facilidade de armazenamento de dados individual. O método compreende receber dados em um mecanismo de confiança, combinar no mecanismo de confiança os dados com um primeiro valor substancialmente aleatório para formar um primeiro valor combinado e combinar os dados com um segundo valor substancialmente aleatório para formar um segundo valor combinado. O método compreende criar um primeiro par do primeiro valor substancialmente aleatório com o segundo valor combinado, criar um se- gundo par do primeiro valor substancialmente aleatório com o segundo valor substancialmente aleatório e armazenar o primeiro par em uma primeira faci- lidade de armazenamento de dados segura. O método compreende armaze- nar o segundo par em uma segunda facilidade de armazenamento de dados segura distante da primeira facilidade de armazenamento de dados segura.

Um outro aspecto da invenção inclui um método de armazena- mento de qualquer tipo de dados, incluindo, mas não-ümitado a, d3dos do autenticação compreendendo receber os dados, combinar os dados com um primeiro conjunto de bits para formar um segundo conjunto de bits e combi- nar os dados com um terceiro conjunto de bits para formar um quarto con- junto de bits. O método também compreende criar um primeiro par do pri- meiro conjunto de bits com o terceiro conjunto de bits. O método também compreende criar um segundo par do primeiro conjunto de bits com o quarto conjunto de bits e armazenar um dos primeiro e segundo pares em um pri- meiro meio de armazenamento acessível por computador. O método tam- bém compreende armazenar o outro dos primeiro e segundo pares em um segundo meio de armazenamento acessível pelo computador.

Um outro aspecto da invenção inclui um método de armazena- mento de dados criptográficos em facilidades de armazenamento de dados seguras geograficamente remotas, dessa maneira protegendo os dados crip- tográficos contra comprometimento de qualquer facilidade de armazenamen- to de dados individual. O método compreende receber dados criptográficos em um mecanismo de confiança, combinar no mecanismo de confiança os dados criptográficos com um primeiro valor substancialmente aleatório para formar um primeiro valor combinado e combinar os dados criptográficos com um segundo valor substancialmente aleatório para formar um segundo valor combinado. O método também compreende criar um primeiro par do primei- ro valor substancialmente aleatório com o segundo valor combinado, criar um segundo par do primeiro valor substancialmente aleatório com o segundo valor substancialmente aleatório e armazenar o primeiro par em uma primei- ra facilidade de armazenamento de dados segura. O método também com- preende armazenar o segundo par em uma segunda facilidade de armaze- namento de dados segura distante da primeira facilidade de armazenamento de dados segura.

Um outro aspecto da invenção inclui um método de armazena- mento de dados criptográficos compreendendo receber dados de autentica- ção e combinar os dados criptográficos com um primeiro conjunto de bits para formar um segundo conjunto de bits. O método também compreende combinar os dados criptográficos com um terceiro conjunto de bits para for- mar um quarto conjunto de bits, criar um primeiro par do primeiro conjunto de bits com o terceiro conjunto de bits e criar um segundo par do primeiro conjunto de bits com o quarto conjunto de bits. O método também compre- ende armazenar um dos primeiro e segundo pares em um primeiro meio de armazenamento acessível por computador e armazenar o outro dos primeiro e segundo pares em um segundo meio de armazenamento acessível por computador.

Um outro aspecto da invenção inclui um método de manipulação de dados sensíveis de qualquer tipo ou forma em um sistema criptográfico, onde os dados sensíveis existem em uma forma utilizável somente durante ações por usuários autorizados, utilizando os dados sensíveis. O método também compreende receber em um módulo de software, dados sensíveis substancialmente randomizados ou criptografados de um primeiro meio de armazenamento acessível por computador, e receber no módulo de softwa- re, dados substancialmente randomizados ou criptografados que podem ou não ser dados sensíveis, de um ou mais outros meios de armazenamento acessíveis por computador. O método também compreende processar os dados sensíveis substancialmente randomizados pré-criptografados e os dados substancialmente randomizados ou criptografados que podem ou não ser dados sensíveis, no módulo de software para montar os dados sensíveis e utilizar os dados sensíveis em um mecanismo de software para executar uma ação. A ação inclui, mas não é limitada a, uma de autenticação de um usuário e execução de uma função criptográfica.

Um outro aspecto da invenção inclui um sistema de autentica- ção seguro. O sistema de autenticação seguro compreende uma pluralidade de mecanismos de autenticação. Cada mecanismo de autenticação recebe dados de autenticação de inscrição projetados para identificar unicamente um usuário até um grau de certeza. Cada mecanismo de autenticação rece- be dados de autenticação atuais para comparar com os dados de autentica- ção da inscrição, e cada mecanismo de autenticação determina um resulta- do de autenticação. O sistema de autenticação seguro também compreende um sistema de redundância que recebe o resultado de autenticação de pelo menos dois dos mecanismos de autenticação e determina se o usuário foi unicamente identificado.

Um outro aspecto da invenção inclui um sistema seguro de da- dos em movimento por meio do qual os dados podem ser transmitidos em porções diferentes que são garantidas de acordo com a presente invenção tal que qualquer uma porção que se torna comprometida não deve prover dados suficientes para restaurar os dados originais. Isso pode ser aplicado em qualquer transmissão de dados, quer ela seja conectada, sem fio ou físi- ca.

Um outro aspecto da invenção inclui a integração do analisador de dados seguro da presente invenção em qualquer sistema adequado onde os dados são armazenados ou comunicados. Por exemplo, sistema de e- mail, sistemas RAID, sistemas de difusão de vídeo, sistemas de banco de dados ou qualquer outro sistema adequado pode ter o analisador de dados seguro integrado em qualquer nível adequado.

Um outro aspecto da invenção inclui usar qualquer algoritmo adequado de análise e divisão para gerar compartilhamentos de dados. Qualquer combinação aleatória, pseudo-aleatório, determinística ou qualquer outra dela pode ser utilizada para analisar e dividir os dados.

Breve Descrição dos Desenhos

A presente invenção é descrita em mais detalhes abaixo em conjunto com os desenhos anexos, que são planejados para ilustrar e não para limitar a invenção e nos quais:

figura 1 ilustra um diagrama de blocos de um sistema criptográ- fico, de acordo com aspectos de uma modalidade da invenção,

figura 2 ilustra um diagrama de blocos do mecanismo de confi- ança da figura 1 ,.de acordo com aspectos de uma modalidade da invenção, figura 3 ilustra um diagrama de blocos do mecanismo de transa- ção da figura 2, de acordo com aspectos de uma modalidade da invenção,

figura 4 ilustra um diagrama de blocos do depositário da figura 2,

de acordo com aspectos de uma modalidade da invenção,

figura 5 ilustra um diagrama de blocos do mecanismo de auten- ticação da figura 2, de acordo com aspectos de uma modalidade da inven- ção,

figura 6 ilustra um diagrama de blocos do mecanismo criptográ- fico da figura 2, de acordo com aspectos de uma modalidade da invenção,

figura 7 ilustra um diagrama de blocos de um sistema depositá- rio, de acordo com aspectos de uma outra modalidade da invenção, figura 8 ilustra um fluxograma de um processo de divisão de da-

dos de acordo com aspectos de uma modalidade da invenção,

figura 9, painel A ilustra um fluxo de dados de um processo de inscrição de acordo com aspectos de uma modalidade da invenção,

figura 9, painel B ilustra um fluxograma de um processo de inte- roperabilidade de acordo com aspectos de uma modalidade da invenção,

figura 10 ilustra um fluxo de dados de um processo de autenti- cação de acordo com aspectos de uma modalidade da invenção,

figura 11 ilustra um fluxo de dados de um processo de assinatu- ra de acordo com aspectos de uma modalidade da invenção,

figura 12 ilustra um fluxo de dados e um processo de criptografi- a/decriptografia de acordo com aspectos e ainda uma outra modalidade da invenção,

figura 13 ilustra um diagrama de blocos simplificado de um sis- tema de mecanismo de confiança de acordo com aspectos de uma outra modalidade da invenção,

figura 14 ilustra um diagrama de blocos simplificado de um sis- tema de mecanismo de confiança de acordo com aspectos de uma outra modalidade da invenção,

figura 15 ilustra um diagrama de blocos do módulo de redun- dância da figura 14, de acordo com aspectos de uma modalidade da inven- ção,

figura 16 ilustra um processo para avaliar as autenticações de acordo com um aspecto da invenção,

figura 17 ilustra um processo para assinar um valor em uma au- tenticação de acordo com um aspecto como mostrado na figura 16 da inven- ção,

figura 18 ilustra um processo para executar arbitragem de confi- ança em um aspecto da invenção como mostrado na figura 17 e

figura 19 ilustra uma transação exemplar entre um usuário e um fornecedor de acordo com aspectos de uma modalidade da invenção onde um contato com base na web inicial leva a um contrato de vendas assinado por ambas as partes.

figura 20 ilustra um sistema de usuário exemplar com um módu- lo provedor de serviço criptográfico que provê funções de segurança para um sistema do usuário.

figura 21 ilustra um processo para analisar, dividir e/ou separar os dados com criptografia e armazenamento da chave-mestre de criptografia com os dados.

figura 22 ilustra um processo para analisar, dividir e/ou separar os dados com criptografia e armazenamento da chave-mestre de criptografia separadamente dos dados.

figura 23 ilustra o processo de chave intermediária para analisar, dividir e/ou separar dados com criptografia e armazenamento da chave- mestre de criptografia com os dados.

figura 24 ilustra o processo de chave intermediária para analisar, dividir e/ou separar dados com criptografia e armazenamento da chave- mestre de criptografia separadamente dos dados.

figura 25 ilustra a utilização dos métodos criptográficos e siste- mas da presente invenção com um pequeno grupo de trabalho. figura 26 é um diagrama de blocos de um sistema de segurança de ficha física ilustrativo utilizando o analisador de dados seguro de acordo com uma modalidade da presente invenção.

figura 27 é um diagrama de blocos de uma disposição ilustrativa na qual o analisador de dados seguro é integrado em um sistema de acordo com uma modalidade da presente invenção.

figura 28 é um diagrama de blocos de um sistema ilustrativo de dados em movimento de acordo com uma modalidade da presente invenção.

figura 29 é um diagrama de blocos de um outro sistema ilustrati- vo de dados em movimento de acordo com uma modalidade da presente invenção.

figuras 30-32 são diagramas de bloco de um sistema ilustrativo tendo o analisador de dados seguro integrado de acordo com uma modali- dade da presente invenção.

figura 33 é um diagrama de fluxo de processo de um processo ilustrativo para analisar e dividir os dados de acordo com uma modalidade da presente invenção.

figura 34 é um diagrama de fluxo de processo de um processo ilustrativo para restaurar porções dos dados em dados originais de acordo com uma modalidade da presente invenção.

figura 35 é um diagrama de fluxo de processo de um processo ilustrativo para dividir dados no nível do bit de acordo com uma modalidade da presente invenção,

figura 36 é um diagrama de fluxo de processo de etapas ilustra- tivas e aspectos, que podem ser usados em qualquer combinação adequa- da, com quaisquer adições adequadas, exclusões ou modificações de acor- do com uma modalidade da presente invenção.

figura 37 é um diagrama de fluxo de processo de etapas ilustra- tivas e aspectos, que podem ser usados em qualquer combinação adequa- da, com quaisquer adições adequadas, exclusões ou modificações de acor- do com uma modalidade da presente invenção.

figura 38 é um diagrama de blocos simplificado do armazena- mento da chave e componentes de dados dentro de compartilhamentos, que podem ser usados em qualquer combinação adequada, com quaisquer adi- ções adequadas, exclusões ou modificações de acordo com uma modalida- de da presente invenção.

figura 39 é um diagrama de blocos simplificado do armazena- mento da chave e componentes de dados dentro de compartilhamentos u- sando uma chave do grupo de trabalho, que podem ser usados em qualquer combinação adequada, com quaisquer adições adequadas, exclusões ou modificações de acordo com uma modalidade da presente invenção.

figuras 40A e 40B são diagramas de fluxo de processo simplifi- cados e ilustrativos para geração de cabeçalho e divisão de dados para da- dos em movimento, que podem ser usados em qualquer combinação ade- quada, com quaisquer adições adequadas, exclusões ou modificações de acordo com uma modalidade da presente invenção.

figura 41 é um diagrama de blocos simplificado de um formato de compartilhamento ilustrativo, que pode ser usado em qualquer combina- ção adequada, com quaisquer adições adequadas, exclusões ou modifica- ções de acordo com uma modalidade da presente invenção.

Descrição Detalhada da Invenção.

Um aspecto da presente invenção é prover um sistema cripto- gráfico onde um ou mais servidores seguros, ou um mecanismo de confian- ça, armazenam chaves criptográficas e dados de autenticação do usuário. Os usuários acessam a funcionalidade dos sistemas criptográficos conven- cionais através do acesso de rede para o mecanismo de confiança, entretan- to, o mecanismo de confiança não libera chaves reais e outros dados de au- tenticação e, portanto, as chaves e os dados permanecem seguros. Esse armazenamento central do servidor de chaves e dados de autenticação pro- vê segurança independente do usuário, portabilidade, disponibilidade e obje- tividade.

Pelo fato de que os usuários podem ser confiantes, ou confiar, no sistema criptográfico para executar autenticação do usuário e documento e outras funções criptográficas, uma ampla variedade de funcionalidade po- de ser incorporada no sistema. Por exemplo, o provedor do mecanismo de confiança pode garantir contra repúdio de autorização, por exemplo, autenti- cando os participantes da autorização, assinando digitalmente a autorização em nome de ou para os participantes e armazenando um registro da autori- zação digitalmente assinada por cada participante. Além disso, o sistema criptográfico pode monitorar as autorizações e determinar aplicar graus vari- ados de autenticação, com base, por exemplo, no preço, usuário, fornece- dor, localização geográfica, local de uso ou similares.

Para facilitar um entendimento completo da invenção, o restante da descrição detalhada descreve a invenção com referência às figuras, onde elementos semelhantes são citados com numerais semelhantes por todas elas.

A figura 1 ilustra um diagrama de blocos de um sistema cripto- gráfico 100, de acordo com aspectos de uma modalidade da invenção. Co- mo mostrado na figura 1, o sistema criptográfico 100 inclui um sistema de usuário 105, um mecanismo de confiança 110, uma autoridade de certificado 115 e um sistema de fornecedor 120, se comunicando através de uma liga- ção de comunicação 125.

De acordo com uma modalidade da invenção, o sistema do usu- ário 105 compreende um computador convencional de uso geral tendo um ou mais microprocessadores, tal como, por exemplo, um processador com base em Intel. Além do mais, o sistema do usuário 105 inclui um sistema operacional apropriado, tal como, por exemplo, um sistema operacional ca- paz de incluir gráficos ou janelas, tais como o Windows, Unix, Linux ou simi- lares. Como mostrado na figura 1, o sistema do usuário 105 pode incluir um dispositivo biométrico 107. O dispositivo biométrico 107 pode capturar vanta- josamente o biométrico do usuário e transferir o biométrico capturado para o mecanismo de confiança 110. De acordo com uma modalidade da invenção, o dispositivo biométrico pode compreender vantajosamente um dispositivo tendo atributos e aspectos similares a esses descritos no Pedido de Patente U.S. No. 08/926.277, depositado em 5 de setembro de 1997, intitulado "RE- LIEF OBJECT IMAGE GENERATOR", Pedido de Patente U.S. No. 09/558.634, depositado em 26 de abril de 2000, intitulado "IMAGING DEVI- CE FOR A RELIEF OBJECT AND SYSTEM AND METHOD OF USING THE IMAGE DEVICE", Pedido de Patente U.S. No. 09/435.011, depositado em 5 de novembro de 1999, intitulado "RELIEF OBJECT SENSOR ADAPTOR" e Pedido de Patente U.S. No. 09/477.943 depositado em 5 de janeiro de 2000, intitulado "PLANAR OPTICAL IMAGE SENSOR AND SYSTEM FOR GENE- RATING AN ELECTRONIC IMAGE OF A RELIEF OBJECT FOR FINGER- PRINT READING", todos os quais são possuídos pelo presente procurador e todos os quais são aqui incorporados por referência.

Além disso, o sistema do usuário 105 pode se conectar na liga- ção de comunicação 125 através de um provedor de serviço convencional, tais como, por exemplo, uma discagem, linha de assinante digital (DSL), modem a cabo, conexão de fibra ou similares. De acordo com uma outra modalidade, o sistema do usuário 105 conecta a ligação de comunicação 125 através da conectividade de rede tal como, por exemplo, uma rede local ou remota. De acordo com uma modalidade, o sistema operacional inclui uma pilha TCP/IP que manipula todo o tráfico de mensagem que chega e que sai passado através da ligação de comunicação 125.

Embora o sistema do usuário 105 seja descrito com referência às modalidades precedentes, a invenção não é planejada para ser limitada por elas. De preferência, um versado reconhecerá a partir dessa descrição, um amplo número de modalidades alternativas do sistema do usuário 105, incluindo quase qualquer dispositivo de computação capaz de enviar ou re- ceber informação de um outro sistema de computador. Por exemplo, o sis- tema do usuário 105 pode incluir, mas não é limitado a, uma estação de tra- balho de computador, uma televisão interativa, um quiosque interativo, um dispositivo de computação móvel pessoal, tais como um assistente digital, telefone móvel, Iaptop ou semelhante, um dispositivo de comunicações sem fio, um cartão inteligente, um dispositivo de computação embutido ou simila- res, que podem interagir com a ligação de comunicação 125. Em tais siste- mas alternativos, os sistemas operacionais provavelmente irão diferir e ser adaptados para o dispositivo particular. Entretanto, de acordo com uma mo- dalidade, os sistemas operacionais vantajosamente continuam a prover os protocolos de comunicações apropriados necessários para estabelecer a comunicação com a ligação de comunicação 125.

A figura 1 ilustra o mecanismo de confiança 110. De acordo com uma modalidade, o mecanismo de confiança 110 compreende um ou mais servidores seguros para acessar e armazenar informação sensível, que po- de ser qualquer tipo ou forma de dados, tal como, mas não-limitado a texto, áudio, vídeo, dados de autenticação do usuário e chaves criptográficas pú- blicas e privadas. De acordo com uma modalidade, os dados de autentica- ção incluem dados projetados para unicamente identificar um usuário do sis- tema criptográfico 100. Por exemplo, os dados de autenticação podem incluir um número de identificação do usuário, um ou mais biométricos e uma série de perguntas e respostas geradas pelo mecanismo de confiança 110 ou o usuário, mas respondidas inicialmente pelo usuário na inscrição. As pergun- tas precedentes podem incluir dados demográficos, tais como local de nas- cimento, endereço, aniversário ou similares, dados pessoais, tais como o nome de solteira da mãe, sorvete favorito ou similares ou outros dados pla- nejados para unicamente identificar o usuário. O mecanismo de confiança 110 compara os dados de autenticação de um usuário associado com uma transação atual, com os dados de autenticação providos em um momento anterior, tal como, por exemplo, durante a inscrição. O mecanismo de confi- ança 110 pode requerer vantajosamente que o usuário produza os dados de autenticação no momento de cada transação ou, o mecanismo de confiança 110 pode vantajosamente permitir que o usuário produza periodicamente dados de autenticação, tal como no começo de uma seqüência de transa- ções ou na conexão em um website de um fornecedor particular.

De acordo com a modalidade onde o usuário produz dados bio- métricos, o usuário provê uma característica física, tais como, mas não- limitado a, varredura facial, varredura de mão, varredura de orelha, varredu- ra da íris, varredura da retina, padrão vascular, DNA, uma impressão digital, escrita ou fala, para o dispositivo biométrico 107. O dispositivo biométrico vantajosamente produz um padrão eletrônico, ou biométrico, da característi- ca física. O padrão eletrônico é transferido através do sistema do usuário 105 para o mecanismo de confiança 110 para finalidades de inscrição ou autenticação.

Depois que o usuário produz os dados de autenticação apropri- ados e o mecanismo de confiança 110 determina uma combinação positiva entre esses dados de autenticação (dados de autenticação atuais) e os da- dos de autenticação providos no momento da inscrição (dados de autentica- ção da inscrição), o mecanismo de confiança 110 provê o usuário com fun- cionalidade criptográfica completa. Por exemplo, o usuário apropriadamente autenticado pode vantajosamente utilizar o mecanismo de confiança 110 para executar a comprovação, assinatura digital, criptografia e decriptografia (freqüentemente citadas juntas somente como criptografia), criação ou distri- buição de certificados digitais e assim por diante. Entretanto, as chaves crip- tográficas privadas usadas nas funções criptográficas não ficarão disponí- veis fora do mecanismo de confiança 110, dessa maneira garantindo a inte- gridade das chaves criptográficas.

De acordo com uma modalidade, o mecanismo de confiança 110 gera e armazena chaves criptográficas. De acordo com uma outra mo- dalidade, pelo menos uma chave criptográfica é associada com cada usuá- rio. Além do mais, quando as chaves criptográficas incluem tecnologia de chave pública, cada chave privada associada com um usuário é gerada den- tro, e não liberada, do mecanismo de confiança 110. Assim, contanto que o usuário tenha acesso ao mecanismo de confiança 110, o usuário pode exe- cutar funções criptográficas usando sua chave privada ou pública. Tal aces- so remoto permite vantajosamente que os usuários permaneçam completa- mente móveis e acessem a funcionalidade criptográfica através de pratica- mente qualquer conexão da Internet, tais como telefones celulares e de saté- lite, quiosques, laptops, salas de hotel e assim por diante.

De acordo com uma outra modalidade, o mecanismo de confi- ança 110 executa a funcionalidade criptográfica usando um par de chaves gerado para o mecanismo de confiança 110. De acordo com essa modalida- de, o mecanismo de confiança 110 primeiro autentica o usuário e depois que o usuário produziu apropriadamente dados de autenticação combinando com os dados de autenticação da inscrição, o mecanismo de confiança 110 usa o seu próprio par de chaves criptográficas para executar funções cripto- gráficas em nome do usuário autenticado.

Um versado reconhecerá a partir dessa descrição que as cha- ves criptográficas podem vantajosamente incluir algumas ou todas as cha- ves simétricas, chaves públicas e chaves privadas. Além disso, um versado reconhecerá a partir dessa descrição que as chaves precedentes podem ser implementadas com um amplo número de algoritmos disponíveis de tecno- logias comerciais, tais como, por exemplo, RSA, ELGAMAL ou similares.

A figura 1 também ilustra a autoridade de certificado 115. De acordo com uma modalidade, a autoridade do certificado 115 pode compre- ender vantajosamente uma organização de terceiros de confiança ou com- panhia que emite certificados digitais, tais como, por exemplo, VeriSign, Bal- timore, Entrust ou similares. O mecanismo de confiança 110 pode vantajo- samente transmitir solicitações por certificados digitais, através de um ou mais protocolos de certificado digital convencionais, tais como, por exemplo, PKCS10, para a autoridade de certificado 115. Em resposta, a autoridade de certificado 115 emitirá um certificado digital em um ou mais de um número de protocolos diferentes, tal como, por exemplo, PKCS7. De acordo com uma modalidade da invenção, o mecanismo de confiança 110 solicita certifi- cados digitais de várias ou todas as autoridades de certificado proeminentes 115, tal que o mecanismo de confiança 110 tem acesso a um certificado digi- tal correspondendo com o padrão de certificado de qualquer parte solicitan- te.

De acordo com uma outra modalidade, o mecanismo de confi- ança 110 executa internamente emissões de certificado. Nessa modalidade, o mecanismo de confiança 110 pode acessar um sistema de certificado para gerar certificados e/ou pode internamente gerar certificados quando eles são solicitados, tal como, por exemplo, no momento da geração da chave ou no padrão de certificado solicitado no momento da solicitação. O mecanismo de confiança 110 será descrito em maiores detalhes abaixo. A figura 1 também ilustra o sistema do fornecedor 120. De acor- do com uma modalidade, o sistema do fornecedor 120 vantajosamente com- preende um servidor da Web. Servidores da Web típicos geralmente servem o conteúdo através da Internet usando uma de várias linguagens de marca- ção da Internet ou padrões de formato de documento, tais como a linguagem de marcação de hipertexto (HTML) ou a linguagem de marcação extensível (XML). O servidor da Web aceita solicitações de navegadores como Netsca- pe e Internet Explorer e a seguir retorna os documentos eletrônicos apropri- ados. Um número de tecnologias do lado do servidor ou cliente pode ser u- sado para aumentar o poder do servidor da Web além da sua capacidade para entregar documentos eletrônicos padrões. Por exemplo, essas tecnolo- gias incluem roteiros da interface de portão comum (CGI), segurança da ca- mada de soquetes segura (SSL) e páginas dé servidor ativas (ASPs). O sis- tema do fornecedor 120 pode vantajosamente prover conteúdo eletrônico relacionado com transações comerciais, pessoais, educacionais ou outras.

Embora o sistema do fornecedor 120 seja descrito com referên- cia às modalidades precedentes, a invenção não é planejada para ser limita- da por isso. De preferência, um versado reconhecerá da descrição aqui que o sistema do fornecedor 120 pode compreender vantajosamente qualquer um dos dispositivos descritos com referência ao sistema do usuário 105 ou combinação dele.

A figura 1 também ilustra a ligação de comunicação 125 conec- tando o sistema do usuário 105, o mecanismo de confiança 110, a autorida- de do certificado 115 e o sistema do fornecedor 120. De acordo com uma modalidade, a ligação de comunicação 125 preferivelmente compreende a Internet. A Internet, como usada por toda essa descrição é uma rede global de computadores. A estrutura da Internet, que é bem-conhecida para esses versados na técnica, inclui um suporte de rede com redes ramificando do suporte. Essas ramificações, por sua vez, têm redes ramificando delas e as- sim por diante. Roteadores movem os pacotes de informação entre níveis de rede, e a seguir de rede para rede, até que o pacote alcança a proximidade de seu destino. Do destino, o hospedeiro da rede de destino direciona o pa- cote de informação para o terminal apropriado, ou nó. Em uma modalidade vantajosa, bocas de conexão de roteamento da Internet compreendem ser- vidores do sistema de nome do domínio (DNS) usando o protocolo de con- trole de transmissão/protocolo da Internet (TCP/IP) como é bem-conhecido na técnica. As bocas de conexão de roteamento se conectam em uma ou mais outras bocas de conexão de roteamento via ligações de comunicação de alta velocidade.

Uma parte popular da Internet é a World Wide Web. A World Wide Web contém computadores diferentes, que armazenam documentos capazes de exibir a informação gráfica e de texto. Os computadores que provêem informação na World Wide Web são tipicamente chamados "websi- tes". Um website é definido por um endereço da Internet que tem uma pági- na eletrônica associada. A página eletrônica pode ser identificada por uma localização constante de recursos (URL). De forma geral, uma página ele- trônica é um documento que organiza a apresentação do texto, imagens grá- ficas, áudio, vídeo e assim por diante.

Embora a ligação de comunicação 125 seja revelada em termos da sua modalidade preferida, alguém versado na técnica reconhecerá a par- tir dessa descrição que a ligação de comunicação 125 pode incluir uma am- pia faixa de ligações de comunicações interativas. Por exemplo, a ligação de comunicação 125 pode incluir redes de televisão interativas, redes de telefo- ne, sistemas de transmissão de dados sem fio, sistemas a cabo de dois sen- tidos, redes de computador privadas ou públicas personalizadas, redes de quiosque interativas, redes de caixas eletrônicos, ligações diretas, redes de satélite ou celular e assim por diante.

A figura 2 ilustra um diagrama de blocos do mecanismo de con- fiança 110 da figura 1 de acordo com aspectos de uma modalidade da in- venção. Como mostrado na figura 2, o mecanismo de confiança 110 inclui um mecanismo de transação 205, um depositário 210, um mecanismo de autenticação 215 e um mecanismo criptográfico 220. De acordo com uma modalidade da invenção, o mecanismo de confiança 110 também inclui ar- mazenamento de massa 225. Como também mostrado na figura 2, o meca- nismo de transação 205 se comunica com o depositário 210, o mecanismo de autenticação 215 e o mecanismo criptográfico 220, junto com o armaze- namento de massa 225. Além disso, o depositário 210 se comunica com o mecanismo de autenticação 215, o mecanismo criptográfico 220 e o arma- zenamento de massa 225. Além do mais, o mecanismo de autenticação 215 se comunica com o mecanismo criptográfico 220. De acordo com uma mo- dalidade da invenção, algumas ou todas as comunicações precedentes po- dem compreender vantajosamente a transmissão de documentos XML para endereços IP que correspondem com o dispositivo receptor. Como mencio- nado no precedente, documentos XML vantajosamente permitem que os projetistas criem suas próprias marcas de documento personalizado, possibi- litando a definição, transmissão, validação e interpretação dos dados entre aplicações e entre organizações. Além do mais, algumas ou todas as comu- nicações precedentes podem incluir tecnologias SSL convencionais.

De acordo com uma modalidade, o mecanismo de transação 205 compreende um dispositivo de roteamento de dados, tal como um servi- dor convencional da Web disponível de Netscape, Microsoft, Apache ou si- milares. Por exemplo, o servidor da Web pode vantajosamente receber os dados que chegam da ligação de comunicação 125. De acordo com uma modalidade da invenção, os dados que chegam são endereçados para um sistema de segurança do primeiro plano para o mecanismo de confiança 110. Por exemplo, o sistema de segurança do primeiro plano pode vantajo- samente incluir uma barreira de proteção, um sistema de detecção de intru- são pesquisando por perfis de ataque conhecidos e/ou um scanner de vírus. Depois de limpar o sistema de segurança do primeiro plano, os dados são recebidos pelo mecanismo de transação 205 e encaminhados para um do depositário 210, do mecanismo de autenticação 215, do mecanismo cripto- gráfico 220 e do armazenamento de massa 225. Além disso, o mecanismo de transação 205 monitora os dados que chegam do mecanismo de autenti- cação 215 e mecanismo criptográfico 220 e roteia os dados para sistemas particulares através da ligação de comunicação 125. Por exemplo, o meca- nismo de transação 205 pode vantajosamente ratear os dados para o siste- ma do usuário 105, a autoridade do certificado 115 ou o sistema do fornece- dor 120.

De acordo com uma modalidade, os dados são roteados usando técnicas convencionais de roteamento de HTTP, tal como, por exemplo, Litili- zando URLs ou indicadores de recurso constante (URIs). URIs são similares aos URLs, entretanto, os URIs tipicamente indicam a fonte de arquivos ou ações, tal como, por exemplo, executáveis, roteiros e similares. Portanto, de acordo com uma modalidade, o sistema do usuário 105, a autoridade do cer- tificado 115, o sistema do fornecedor 120 e os componentes do mecanismo de confiança 210 incluem vantajosamente dados suficientes dentro dos UR- Ls ou URIs de comunicação para o mecanismo de transação 205 apropria- damente rotear os dados por todo o sistema criptográfico.

Embora o roteamento dos dados seja descrito com referência a sua modalidade preferida, um versado reconhecerá um amplo número de soluções ou estratégias de roteamento de dados possíveis. Por exemplo, XML ou outros pacotes de dados podem ser vantajosamente retirados do pacote e reconhecidos por seu formato, conteúdo ou similares, tal que o me- canismo de transação 205 pode apropriadamente rotear os dados por todo o mecanismo de confiança 110. Além do mais, um versado reconhecerá que o roteamento dos dados pode ser vantajosamente adaptado aos protocolos de transferência de dados que se conformam com sistemas de redes particula- res, tal como, por exemplo, quando a ligação de comunicação 125 compre- ende uma rede local.

De acordo com ainda uma outra modalidade da invenção, o me- canismo de transação 205 inclui tecnologias de criptografia SSL convencio- nais, tal que os sistemas precedentes podem se autenticar e vice-versa, com o mecanismo de transação 205, durante comunicações particulares. Como será usado por toda essa descrição, o termo "1/2 SSL" se refere às comuni- cações onde um servidor, mas não necessariamente o cliente, é autenticado em SSL e o termo "SLL completo" se refere às comunicações onde o cliente e o servidor são autenticados em SSL. Quando a descrição atual usa o ter- mo "SSL", a comunicação pode compreender 1/2 ou SSL completa. Quando o mecanismo de transação 205 roteia os dados para os vários componentes do sistema criptográfico 100, o mecanismo de transa- ção 205 pode vantajosamente criar um rastro de auditoria. De acordo com uma modalidade, o rastro de auditoria inclui um registro de pelo menos o tipo e o formato dos dados rateados pelo mecanismo de transação 205 por todo o sistema criptográfico 100. Tais dados de auditoria podem ser vantajosa- mente armazenados no armazenamento de massa 225.

A figura 2 também ilustra o depositário 210. De acordo com uma modalidade, o depositário 210 compreende uma ou mais facilidades de ar- mazenamento de dados, tais como, por exemplo, um servidor de diretório, um servidor do banco de dados ou similares. Como mostrado na figura 2, o depositário 210 armazena as chaves criptográficas e os dados de autentica- ção de inscrição. As chaves criptográficas podem vantajosamente corres- ponder com o mecanismo de confiança 110 ou com usuários do sistema criptográfico 100, tal como o usuário ou fornecedor. Os dados de autentica- ção de inscrição podem incluir vantajosamente dados projetados para identi- ficar unicamente um usuário, tais como, o ID do usuário, senhas, respostas a perguntas, dados biométricos ou similares. Esses dados de autenticação de inscrição podem ser vantajosamente adquiridos na inscrição de um usuário ou um outro tempo posterior alternativo. Por exemplo, o mecanismo de con- fiança 110 pode incluir um periódico ou outra renovação ou reedição dos dados de autenticação de inscrição.

De acordo com uma modalidade, a comunicação do mecanismo de transação 205 para e do mecanismo de autenticação 215 e do mecanis- mo criptográfico 220 compreendem comunicação segura, tal como, por e- xemplo, tecnologia SSL convencional. Além disso, como mencionado no precedente, os dados das comunicações para e do depositário 210 podem ser transferidos usando URLs, URIs, documentos HTTP ou XML, com qual- quer um do precedente vantajosamente tendo solicitações de dados e for- matos embutidos neles.

Como mencionado acima, o depositário 210 pode vantajosa- mente compreender uma pluralidade de facilidades de armazenamento de dados seguros. Em uma tal modalidade, as facilidades de armazenamento de dados seguras podem ser configuradas tal que um comprometimento da segurança em uma facilidade de armazenamento de dados individual não comprometerá as chaves criptográficas ou os dados de autenticação arma- zenados nela. Por exemplo, de acordo com essa modalidade, as chaves criptográficas e os dados de autenticação são matematicamente operados de modo a estatística e substancialmente randomizar os dados armazena- dos em cada facilidade de armazenamento de dados. De acordo com uma modalidade, a randomização dos dados de uma facilidade de armazenamen- to de dados individual torna esses dados indecifráveis. Assim, o comprome- timento de uma facilidade de armazenamento de dados individual produz somente um número indecifrável randomizado e não compromete a segu- rança de quaisquer chaves criptográficas ou os dados de autenticação como um todo.

A figura 2 também ilustra o mecanismo de confiança 110 inclu- indo o mecanismo de autenticação 215. De acordo com uma modalidade, o mecanismo de autenticação 215 compreende um comparador de dados con- figurado para comparar dados do mecanismo de transação 205 com os da- dos do depositário 210. Por exemplo, durante a autenticação, um usuário supre dados de autenticação atuais para o mecanismo de confiança 110 tal que o mecanismo de transação 205 recebe os dados de autenticação atuais. Como mencionado no precedente, o mecanismo de transação 205 reconhe- ce as solicitações de dados, preferivelmente no URL ou URI, e roteia os da- dos de autenticação para o mecanismo de autenticação 215. Além do mais, com a solicitação, o depositário 210 envia os dados de autenticação de ins- crição correspondendo com o usuário para o mecanismo de autenticação 215. Assim, o mecanismo de autenticação 215 tem ambos os dados de au- tenticação atuais e os dados de autenticação da inscrição para comparação.

De acordo com uma modalidade, as comunicações para o me- canismo de autenticação compreendem comunicações seguras, tal como, por exemplo, tecnologia SSL. Adicionalmente, a segurança pode ser provida dentro dos componentes do mecanismo de confiança 110, tal como, por e- xemplo, supercriptografia usando tecnologias de chave pública. Por exem- plo, de acordo com uma modalidade, o usuário criptografa os dados de au- tenticação atuais com a chave pública do mecanismo de autenticação 215. Além disso, o depositário 210 também criptografa os dados de autenticação da inscrição com a chave pública do mecanismo de autenticação 215. Dessa maneira, somente a chave privada do mecanismo de autenticação pode ser usada para decriptografar as transmissões.

Como mostrado na figura 2, o mecanismo de confiança 110 também inclui o mecanismo criptográfico 220. De acordo com uma modali- dade, o mecanismo criptográfico compreende um módulo de manipulação criptográfico, configurado para vantajosamente prover funções criptográficas convencionais, tal como, por exemplo, a funcionalidade da infra-estrutura de chave pública (PKI). Por exemplo, o mecanismo criptográfico 220 pode emitir vantajosamente chaves públicas e privadas para usuários do sistema cripto- gráfico 100. Dessa maneira, as chaves criptográficas são geradas no meca- nismo criptográfico 220 e enviadas para o depositário 210 tal que pelo me- nos as chaves criptográficas privadas não ficam disponíveis fora do meca- nismo de confiança 110. De acordo com uma outra modalidade, o mecanis- mo criptográfico 220 randomiza e divide pelo menos os dados da chave crip- tográfica privada, dessa maneira armazenando somente os dados divididos randomizados. Similar à divisão dos dados de autenticação de inscrição, o processo de divisão garante que as chaves armazenadas não fiquem dispo- níveis fora do mecanismo criptográfico 220. De acordo com uma outra mo- dalidade, as funções do mecanismo criptográfico podem ser combinadas com e executadas pelo mecanismo de autenticação 215.

De acordo com uma modalidade, as comunicações para e do mecanismo criptográfico incluem comunicações seguras, tal como tecnologia SSL. Além disso, os documentos XML podem ser vantajosamente utilizados para transferir dados e/ou fazer solicitações de função criptográfica.

A figura 2 também ilustra o mecanismo de confiança 110 tendo o armazenamento de massa 225. Como mencionado no precedente, o me- canismo de transação 205 mantém dados correspondendo com um rastro de auditoria e armazena tais dados no armazenamento de massa 225. Similar- mente, de acordo com uma modalidade da invenção, o depositário 210 man- tém os dados correspondendo com um rastro de auditoria e armazena tais dados no dispositivo de armazenamento de massa 225. Os dados do rastro de auditoria do depositário são similares a esses do mecanismo de transa- ção 205 já que os dados do rastro de auditoria compreendem um registro das solicitações recebidas pelo depositário 210 e a resposta do mesmo. A- lém disso, o armazenamento de massa 225 pode ser usado para armazenar certificados digitais tendo a chave pública de um usuário contida neles.

Embora o mecanismo de confiança 110 seja descrito com refe- rência às suas modalidades preferidas e alternativas, a invenção não é pla- nejada para ser limitada a isso. De preferência, um versado reconhecerá a partir dessa descrição, um amplo número de alternativas para o mecanismo de confiança 110. Por exemplo, o mecanismo de confiança 110 pode vanta- josamente executar somente a autenticação, ou alternativamente, somente algumas ou todas as funções criptográficas, tais como criptografia e decrip- tografia dos dados. De acordo com tais modalidades, um do mecanismo de autenticação 215 e do mecanismo criptográfico 220 pode ser vantajosamen- te removido, dessa forma criando um projeto mais direto para o mecanismo de confiança 110. Além disso, o mecanismo criptográfico 220 pode também se comunicar com uma autoridade de certificado tal que a autoridade do cer- tificado é personificada dentro do mecanismo de confiança 110. De acordo com ainda uma outra modalidade, o mecanismo de confiança 110 pode van- tajosamente executar a autenticação e uma ou mais funções criptográficas, tal como, por exemplo, a assinatura digital.

A figura 3 ilustra um diagrama de blocos do mecanismo de tran- sação 205 da figura 2, de acordo com aspectos de uma modalidade da in- venção. De acordo com essa modalidade, o mecanismo de transação 205 compreende um sistema operacional 305 tendo um encadeamento de mani- pulação e um encadeamento de escuta. O sistema operacional 305 pode ser vantajosamente similar a esses encontrados em servidores convencionais de alto volume, tal como, por exemplo, servidores da Web disponíveis de Apache. O encadeamento de escuta monitora a comunicação que chega de um da ligação de comunicação 125, do mecanismo de autenticação 215 e do mecanismo criptográfico 220 para o fluxo dos dados que chegam. O en- cadeamento de manipulação reconhece estruturas de dados particulares do fluxo de dados que chega, tal como, por exemplo, as estruturas de dados precedentes, dessa maneira rateando os dados que chegam para um da ligação de comunicação 125, do depositário 210, do mecanismo de autenti- cação 215, do mecanismo criptográfico 220 ou do armazenamento de massa 225. Como mostrado na figura 3, os dados que chegam e que saem podem ser vantajosamente garantidos através, por exemplo, da tecnologia SSL.

A figura 4 ilustra um diagrama de blocos do depositário 210 da figura 2 de acordo com aspectos de uma modalidade da invenção. De acor- do com essa modalidade, o depositário 210 compreende um ou mais servi- dores de protocolo de acesso de diretório leve (LDAP). Os servidores do di- retório LDAP estão disponíveis de uma ampla variedade de fabricantes tais como Netscape, ISO e outros. A figura 4 também mostra que o servidor do diretório preferivelmente armazena dados 405 correspondendo com as cha- ves criptográficas e os dados 410 correspondendo com os dados de autenti- cação de inscrição. De acordo com uma modalidade, o depositário 210 com- preende uma única estrutura de memória lógica indexando os dados de au- tenticação e os dados da chave criptográfica em um único ID de usuário. A estrutura de memória lógica única preferivelmente inclui mecanismos para garantir um alto grau de confiança, ou segurança, nos dados armazenados nela. Por exemplo, a localização física do depositário 210 pode vantajosa- mente incluir um amplo número de medidas de segurança convencionais, tais como acesso limitado do empregado, sistema de vigilância moderno e assim por diante. Além de, ou no lugar de, as seguranças físicas, o sistema de computador ou o servidor pode vantajosamente incluir soluções de soft- ware para proteger os dados armazenados. Por exemplo, o depositário 210 pode vantajosamente criar e armazenar dados 415 correspondendo com um rastro de auditoria das ações adotadas. Além disso, as comunicações que chegam e que saem podem ser vantajosamente criptografadas com cripto- grafia de chave pública unida com tecnologias SSL convencionais.

De acordo com uma outra modalidade, o depositário 210 pode compreender as facilidades de armazenamento de dados distintas e fisica- mente separadas, como descrito mais com referência à figura 7.

A figura 5 ilustra um diagrama de blocos do mecanismo de au- tenticação 215 da figura 2 de acordo com aspectos de uma modalidade da invenção. Similar ao mecanismo de transação 205 da figura 3, o mecanismo de autenticação 215 compreende um sistema operacional 505 tendo pelo menos um encadeamento de escuta e um de manipulação de uma versão modificada de um servidor convencional da Web, tal como, por exemplo, servidores da Web disponíveis de Apache. Como mostrado na figura 5, o mecanismo de autenticação 215 inclui acesso a pelo menos uma chave pri- vada 510. A chave privada 510 pode ser usada vantajosamente, por exem- plo, para decriptografar os dados do mecanismo de transação 205 ou o de- positário 210, que foram criptografados com uma chave pública correspon- dente do mecanismo de autenticação 215.

A figura 5 também ilustra o mecanismo de autenticação 215 compreendendo um comparador 515, um módulo de divisão de dados 520 e um módulo de montagem de dados 525. De acordo com a modalidade prefe- rida da invenção, o comparador 515 inclui tecnologia capaz de comparar padrões potencialmente complexos relacionados com os dados de autenti- cação biométricos precedentes. A tecnologia pode incluir hardware, software ou soluções combinadas para comparações de padrões, tal como, por e- xemplo, essas representando padrões de impressão digital ou padrões de voz. Além disso, de acordo com uma modalidade, o comparador 515 do me- canismo de autenticação 215 pode vantajosamente comparar provas con- vencionais de documentos a fim de apresentar um resultado de comparação. De acordo com uma modalidade da invenção, o comparador 515 inclui a a- plicação de heurística 530 na comparação. A heurística 530 pode vantajo- samente tratar circunstâncias que circundam uma tentativa de autenticação, tais como, por exemplo, a hora do dia, endereço IP ou máscara da sub-rede, perfil de compra, endereço de e-mail, número serial ou ID do processador ou similares.

Além do mais, a natureza das comparações dos dados biométri- cos pode resultar em graus variados de confiança sendo produzidos a partir da combinação de dados de autenticação biométricos atuais com os dados de inscrição. Por exemplo, ao contrário de uma senha tradicional que pode somente retornar uma combinação positiva ou negativa, uma impressão digi- tal pode ser determinada como sendo uma combinação parcial, por exemplo, uma combinacao de 90%, uma combinacao de 75% ou uma combinacao de 10%, em vez de simplesmente ser correta ou incorreta. Outros identificado- res biométricos, tais como a análise de impressão de voz ou reconhecimento de face, podem compartilhar essa propriedade da autenticação probabilísti- ca, em vez da autenticação absoluta.

Quando trabalhando com tal autenticação probabilística ou em outros casos onde uma autenticação é considerada menos do que absolu- tamente confiável, é desejável aplicar a heurística 530 para determinar se o nível de confiança na autenticação provida é suficientemente alto para au- tenticar a transação que está sendo feita.

Algumas vezes haverá o caso em que a transação em questão é uma transação de valor relativamente baixo onde é aceitável que ela seja autenticada em um nível inferior de confiança. Isso poderia incluir uma tran- sação que tem um baixo valor de dólar associado com ela (por exemplo, uma compra de $10) ou uma transação com baixo risco (por exemplo, ad- missão em um website somente de membros).

Inversamente, para autenticar outras transações, pode ser dese- jável requerer um alto grau de confiança na autenticação antes de permitir que a transação prossiga. Tais transações podem incluir transações de grande valor de dólar (por exemplo, a assinatura de um contrato de forneci- mento de multimilhões de dólares) ou a transação com um alto risco se uma autenticação imprópria ocorre (por exemplo, remotamente se conectar em um computador do governo).

O uso da heurística 530 em combinação com níveis de confian- ça e valores de transações pode ser usado como será descrito abaixo para permitir que o comparador proveja um sistema de autenticação dinâmico sensível ao contexto.

De acordo com uma outra modalidade da invenção, o compara- dor 515 pode vantajosamente rastrear as tentativas de autenticação para uma transação particular. Por exemplo, quando uma transação falha, o me- canismo de confiança 110 pode solicitar que o usuário insira de novo os seus dados de autenticação atuais. O comparador 515 do mecanismo de autenticação 215 pode utilizar vantajosamente um limitador de tentativa 535 para limitar o número de tentativas de autenticação, dessa maneira proibindo tentativas de força bruta para representar os dados de autenticação de um usuário. De acordo com uma modalidade, o limitador de tentativa 535 com- preende um módulo de software monitorando as transações para repetir as tentativas de autenticação e, por exemplo, limitar as tentativas de autentica- ção para uma dada transação a três. Assim, ò limitador de tentativa 535 Iimi- tará a tentativa automática para representar os dados de autenticação de um indivíduo para, por exemplo, simplesmente três "chutes". Com três falhas, o limitador de tentativa 535 pode vantajosamente negar tentativas de autenti- cação adicionais. Tal negação pode ser vantajosamente implementada atra- vés, por exemplo, do comparador 515 retornando um resultado negativo a despeito dos dados de autenticação atuais sendo transmitidos. Por outro lado, o mecanismo de transação 205 pode vantajosamente bloquear quais- quer tentativas de autenticação adicionais pertencentes a uma transação na qual três tentativas falharam previamente.

O mecanismo de autenticação 215 também inclui 2 o módulo de divisão de dados 520 e o módulo de montagem de dados 525. O módulo de divisão de dados 520 vantajosamente compreende um software, hardware ou módulo de combinação tendo a capacidade de operar matematicamente vários dados de modo a substancialmente randomizar e dividir os dados em porções. De acordo com uma modalidade, os dados originais não podem ser recriados a partir de uma porção individual. O módulo de montagem dos da- dos 525 vantajosamente compreende um software, hardware ou módulo de combinação configurado para operar matematicamente nas porções prece- dentes substancialmente randomizadas, tal que a sua combinação provê os dados decifrados originais. De acordo com uma modalidade, o mecanismo de autenticação 215 utiliza o módulo de divisão de dados 520 para randomi- zar e dividir os dados de autenticação de inscrição em porções, e utiliza o módulo de montagem de dados 525 para remontar as porções em dados de autenticação de inscrição utilizáveis.

A figura 6 ilustra um diagrama de blocos do mecanismo cripto- gráfico 220 do mecanismo de confiança 200 da figura 2 de acordo com as- pectos de uma modalidade da invenção. Similar ao mecanismo de transação 205 da figura 3, o mecanismo criptográfico 220 compreende um sistema o- peracional 605 tendo pelo menos um encadeamento de escuta e um de ma- nipulação de uma versão modificada de um servidor convencional da Web, tal como, por exemplo, servidores da Web disponíveis de Apache. Como mostrado na figura 6, o mecanismo criptográfico 220 compreende um módu- lo de divisão de dados 610 e um módulo de montagem de dados 620 que funcionam similares a esses da figura 5. Entretanto, de acordo com uma modalidade, o módulo de divisão de dados 610 e o módulo de montagem dos dados 620 processam dados de chave criptográfica, em oposição aos dados de autenticação de inscrição precedentes. Contudo, um versado re- conhecerá a partir dessa descrição que o módulo de divisão de dados 910 e o módulo de divisão de dados 620 podem ser combinados com esses do mecanismo de autenticação 215.

O mecanismo criptográfico 220 também compreende um módulo de manipulação criptográfica 625 configurado para executar um, alguns ou todos de um amplo número de funções criptográficas. De acordo com uma modalidade, o módulo de manipulação criptográfica 625 pode compreender módulos ou programas de software, hardware ou ambos. De acordo com uma outra modalidade, o módulo de manipulação criptográfica 625 pode e- xecutar comparações de dados, análise de dados, divisão de dados, separa- ção de dados, comprovação de dados, criptografia ou decriptografia de da- dos, verificação ou criação de assinatura digital, geração de certificado digi- tal, armazenamento ou solicitações, geração de chave criptográfica ou simi- lares. Além do mais, um versado reconhecerá a partir dessa descrição que o módulo de manipulação criptográfica 825 pode compreender vantajosamen- te uma infra-estrutura de chave pública, tal como Privacidade Razoável (PGP), um sistema de chave pública com base em RSA ou um amplo núme- ro de sistemas de gerenciamento de chave alternativos. Além disso, o módu- lo de manipulação criptográfica 625 pode executar criptografia de chave pú- blica, criptografia de chave simétrica ou ambos. Além do precedente, o mó- dulo de manipulação criptográfica 625 pode incluir um ou mais programas ou módulos de computador, hardware ou ambos, para implementar funções de interoperabilidade transparentes sem junção.

Um versado também reconhecerá a partir dessa descrição que a funcionalidade criptográfica pode incluir um amplo número ou variedade de funções geralmente relacionadas com sistemas de gerenciamento de chave criptográfica.

A figura 7 ilustra um diagrama de blocos simplificado de um sis- tema depositário 700 de acordo com aspectos de uma modalidade da inven- ção. Como mostrado na figura 7, o sistema depositário 700 compreende vantajosamente múltiplas facilidades de armazenamento de dados, por e- xemplo, facilidades de armazenamento de dados D1, D2, D3 e D4. Entretan- to, é prontamente entendido por aqueles versados na técnica que o sistema depositário pode ter somente uma facilidade de armazenamento de dados. De acordo com uma modalidade da invenção, cada uma das facilidades de armazenamento de dados D1 a D4 pode vantajosamente compreender al- guns ou todos os elementos descritos com referência ao depositário 210 da figura 4. Similar ao depositário 210, as facilidades de armazenamento de dados D1 a D4 se comunicam com o mecanismo de transação 205, o meca- nismo de autenticação 215 e o mecanismo criptográfico 220, de preferência através de SSL convencional. Ligações de comunicação transferindo, por exemplo, documentos XML. As comunicações do mecanismo de transação 205 podem incluir vantajosamente solicitações por dados, onde a solicitação é vantajosamente difundida para o endereço IP de cada facilidade de arma- zenamento de dados D1 a D4. Por outro lado, o mecanismo de transação 205 pode difundir solicitações para facilidades de armazenamento de dados particulares com base em um amplo número de critérios, tais como, por e- xemplo, tempo de resposta, cargas do servidor, cronogramas de manuten- ção ou similares.

Em resposta às solicitações por dados do mecanismo de tran- sação 205, o sistema depositário 700 vantajosamente envia os dados arma- zenados para o mecanismo de autenticação 215 e o mecanismo criptográfi- co 220. Os módulos de montagem de dados respectivos recebem os dados enviados e montam os dados em formatos utilizáveis. Por outro lado, as co- municações do mecanismo de autenticação 215 e do mecanismo criptográfi- co 220 para as facilidades de armazenamento de dados D1 a D4 podem in- cluir a transmissão de dados sensíveis a serem armazenados. Por exemplo, de acordo com uma modalidade, o mecanismo de autenticação 215 e o me- canismo criptográfico 220 podem vantajosamente utilizar seus módulos de divisão de dados respectivos para dividir os dados sensíveis em porções indecifráveis, e a seguir transmitir uma ou mais porções indecifráveis dos dados sensíveis para uma facilidade de armazenamento de dados particular.

De acordo com uma modalidade, cada facilidade de armazena- mento de dados, D1 a D4, compreende um sistema de armazenamento se- parado e independente, tal como, por exemplo, um servidor de diretório. De acordo com uma outra modalidade da invenção, o sistema depositário 700 compreende múltiplos sistemas de armazenamento de dados independentes geograficamente separados. Pela distribuição dos dados sensíveis em facili- dades de armazenamento distintas e independentes D1 a D4, algumas ou todas as quais podem ser vantajosamente separadas geograficamente, o sistema depositário 700 provê redundância junto com medidas adicionais de segurança. Por exemplo, de acordo com uma modalidade, somente os da- dos de duas das múltiplas facilidades de armazenamento de dados, D1 a D4, são necessários para decifrar e remontar os dados sensíveis. Assim, tantas quantas duas das quatro facilidades de armazenamento de dados D1 a D4 podem ficar inoperáveis devido à manutenção, falha do sistema, falha de força ou semelhante, sem afetar a funcionalidade do mecanismo de con- fiança 110. Além disso, pelo fato de que, de acordo com uma modalidade, os dados armazenados em cada facilidade de armazenamento de dados são randomizados e indecifráveis, o comprometimento de qualquer facilidade de armazenamento de dados individual não compromete necessariamente os dados sensíveis. Além do mais, na modalidade tendo separação geográfica das facilidades de armazenamento de dados, um comprometimento de múl- tiplas facilidades geograficamente remotas se torna cada vez mais difícil. Na realidade, até mesmo um empregado perigoso será grandemente desafiado a subverter as múltiplas facilidades de armazenamento de dados indepen- dentes geograficamente remotas necessárias.

Embora o sistema depositário 700 seja descrito com referência às suas modalidades preferidas e alternativas, a invenção não é planejada para ser limitada a isso. De preferência, um versado reconhecerá a partir dessa descrição, um amplo número de alternativas para o sistema depositá- rio 700. Por exemplo, o sistema depositário 700 pode compreender uma, duas ou mais facilidades de armazenamento de dados. Além disso, os da- dos sensíveis podem ser matematicamente operados tal que porções de duas ou mais facilidades de armazenamento de dados são necessárias para remontar e decifrar os dados sensíveis.

Como mencionado no precedente, o mecanismo de autentica- ção 215 e o mecanismo criptográfico 220 incluem, cada um, um módulo de divisão de dados 520 e 610, respectivamente, para dividir qualquer tipo ou forma de dados sensíveis, tais como, por exemplo, texto, áudio, vídeo, os dados de autenticação e os dados da chave criptográfica. A figura 8 ilustra um fluxograma de um processo de divisão de dados 800 executado pelo módulo de divisão de dados de acordo com aspectos de uma modalidade da invenção. Como mostrado na figura 8, o processo de divisão de dados 800 começa na etapa 805 quando os dados sensíveis "S" são recebidos pelo módulo de divisão de dados do mecanismo de autenticação 215 ou o meca- nismo criptográfico 220. De preferência, na etapa 810, o módulo de divisão de dados então gera um número substancialmente aleatório, valor ou se- qüência ou conjunto de bits, "A". Por exemplo, o número aleatório A pode ser gerado em um amplo número de técnicas convencionais variadas dispo- níveis para alguém versado na técnica, para produzir números aleatórios de alta qualidade adequados para uso nas aplicações criptográficas. Além dis- so, de acordo com uma modalidade, o número aleatório A compreende um comprimento de bit que pode ser de qualquer comprimento adequado, tal como mais curto, mais longo ou igual ao comprimento de bit dos dados sen- síveis, S.

Além disso, na etapa 820 o processo de divisão de dados 800 gera um outro número estatisticamente aleatório "C". De acordo com a mo- dalidade preferida, a geração dos números estatisticamente aleatórios AeC pode ser feita vantajosamente em paralelo. O módulo de divisão de dados então combina os números AeC com os dados sensíveis S tal que novos números "B" e "D" são gerados. Por exemplo, o número B pode compreen- der a combinação binária de A XOR Seo número D pode compreender a combinação binária de C XOR S. A função XOR, ou a função "ou exclusivo", é bem-conhecida para aqueles versados na técnica. As combinações prece- dentes de preferência ocorrem nas etapas 825 e 830, respectivamente, e, de acordo com uma modalidade, as combinações precedentes também ocor- rem em paralelo. O processo de divisão de dados 800 então prossegue para a etapa 835 onde os números aleatórios A e C e os números BeD são co- locados em pares tal que nenhum dos pares contém dados suficientes, por eles próprios, para reorganizar e decifrar os dados sensíveis originais S. Por exemplo, os números podem ser colocados em pares como segue: AC, AD, BC e BD. De acordo com uma modalidade, cada um dos pares precedentes é distribuído para um dos depositários D1 a D4 da figura 7. De acordo com uma outra modalidade, cada um dos pares precedentes é aleatoriamente distribuído para um dos depositários D1 a D4. Por exemplo, durante um pri- meiro processo de divisão de dados 800, o par AC pode ser enviado para o depositário D2, através, por exemplo, de uma seleção aleatória de endereço IP do D2. A seguir, durante um segundo processo de divisão de dados 800, o par AC pode ser enviado para o depositário D4 através, por exemplo, de uma seleção aleatória de endereço IP de D4. Além disso, os pares podem ser todos armazenados em um depositário e podem ser armazenados em localizações separadas no dito depositário.

Com base no precedente, o processo de divisão de dados 800 vantajosamente coloca porções dos dados sensíveis em cada uma das qua- tro facilidades de armazenamento de dados D1 a D4, tal que nenhuma facili- dade de armazenamento de dados única D1 a D4 inclui dados criptografa- dos suficientes para recriar os dados sensíveis originais S. Como menciona- do no precedente, tal randomização dos dados em porções criptografadas individualmente não utilizáveis aumenta a segurança e proporciona confian- ça mantida nos dados mesmo se uma das facilidades de armazenamento de dados, D1 a D4, está comprometida.

Embora o processo de divisão de dados 800 seja descrito com referência à sua modalidade preferida, a invenção não é planejada para ser limitada por isso. De preferência, um versado reconhecerá a partir dessa descrição, um amplo número de alternativas para o processo de divisão de dados 800. Por exemplo, o processo de divisão de dados pode vantajosa- mente dividir os dados em dois números, por exemplo, número aleatório A e número B e, aleatoriamente distribuir AeB através de duas facilidades de armazenamento de dados. Além do mais, o processo de divisão de dados 800 pode dividir vantajosamente os dados entre um amplo número de facili- dades de armazenamento de dados através da geração de números aleató- rios adicionais. Os dados podem ser divididos em qualquer unidade de ta- manho desejada, selecionada, predeterminada ou aleatoriamente atribuída, incluindo, mas não-limitado a, um bit, bits, bytes, quilobytes, megabytes ou maiores ou qualquer combinação ou seqüência de tamanhos. Além disso, a variação dos tamanhos das unidades de dados resultantes do processo de divisão pode tornar os dados mais difíceis de restaurar para uma forma utili- zável, dessa maneira aumentando a segurança dos dados sensíveis. É fa- cilmente evidente para aqueles versados na técnica que os tamanhos da unidade dos dados divididos podem ser uma ampla variedade de tamanhos de unidade de dados ou padrões de tamanhos ou combinações de tama- nhos. Por exemplo, os tamanhos da unidade de dados podem ser selecio- nados ou predeterminados para serem todos do mesmo tamanho, um con- junto fixo de tamanhos diferentes, uma combinação de tamanhos ou tama- nhos aleatoriamente gerados. Similarmente, as unidades de dados podem ser distribuídas em um ou mais compartilhamentos de acordo com um tama- nho da unidade de dados fixo ou predeterminado, um padrão ou combinação de tamanhos de unidade de dados ou um tamanho ou tamanhos de unidade de dados aleatoriamente gerados por compartilhamento.

Como mencionado no precedente, a fim de recriar os dados sensíveis S, as porções dos dados precisam ser anuladas da randomização e reorganizadas. Esse processo pode ocorrer vantajosamente nos módulos de montagem de dados, 525 e 620, do mecanismo de autenticação 215 e do mecanismo criptográfico 220, respectivamente. O módulo de montagem dos dados, por exemplo, o módulo de montagem dos dados 525, recebe porções de dados das facilidades de armazenamento de dados D1 a D4 e remonta os dados na forma utilizável. Por exemplo, de acordo com uma modalidade onde o módulo de divisão de dados 520 utilizou o processo de divisão de dados 800 da figura 8, o módulo de montagem dos dados 525 usa porções dos dados de pelo menos duas das facilidades de armazenamento de dados D1 a D4 para recriar os dados sensíveis S. Por exemplo, os pares AC, AD, BC e BD, foram distribuídos tal que quaisquer dois provêem um de A e B, ou, CeD. Observando que S = A XOR B ou S = C XOR D indica que quan- do o módulo de montagem dos dados recebe um de A e B, ou, CeD,o mó- dulo de montagem dos dados 525 pode remontar vantajosamente os dados sensíveis S. Assim, o módulo de montagem dos dados 525 pode montar os dados sensíveis S, quando, por exemplo, ele recebe porções de dados de pelo menos as duas primeiras das facilidades de armazenamento de dados D1 a D4 para responder a uma solicitação de montagem pelo mecanismo de confiança 110.

Com base nos processos acima de divisão e montagem de da- dos, os dados sensíveis S existem no formato utilizável somente em uma área limitada do mecanismo de confiança 110. Por exemplo, quando os da- dos sensíveis S incluem dados de autenticação de inscrição, dados de au- tenticação de inscrição não randomizados utilizáveis ficam disponíveis so- mente no mecanismo de autenticação 215. Da mesma forma, quando os dados sensíveis S incluem dados de chave criptográfica privada, dados de chave criptográfica privada não randomizados utilizáveis ficam disponíveis somente no mecanismo criptográfico 220.

Embora os processos de divisão e montagem de dados sejam descritos com referência às suas modalidades preferidas, a invenção não é planejada para ser limitada por isso. De preferência, um versado reconhece- rá a partir dessa descrição, um amplo número de alternativas para dividir e remontar os dados sensíveis S. Por exemplo, a criptografia de chave pública pode ser usada para garantir mais os dados nas facilidades de armazena- mento de dados D1 a D4. Além disso, é facilmente evidente para aqueles versados na técnica que o módulo de divisão de dados descrito aqui é tam- bém uma modalidade separada e distinta da presente invenção que pode ser incorporada em, combinada ou de outra forma tornada parte de quais- quer sistemas de computador preexistentes, conjuntos de software, banco de dados ou combinações desses ou outras modalidades da presente inven- ção, tais como o mecanismo de confiança, mecanismo de autenticação e mecanismo de transação descritos e descritos aqui.

A figura 9A ilustra um fluxo de dados de um processo de inscri- ção 900 de acordo com aspectos de uma modalidade da invenção. Como mostrado na figura 9A, o processo de inscrição 900 começa na etapa 905 quando um usuário deseja se inscrever com o mecanismo de confiança 110 do sistema criptográfico 100. De acordo com essa modalidade, o sistema do usuário 105 inclui vantajosamente um miniaplicativo do lado do cliente, tal como um baseado em Java, que indaga o usuário para inserir dados de ins- crição, tais como dados demográficos e dados de autenticação da inscrição. De acordo com uma modalidade, os dados de autenticação da inscrição in- cluem ID do usuário, senha(s), biométrico(s) ou similares. De acordo com uma modalidade, durante o processo de questionamento, o miniaplicativo do lado do cliente preferivelmente se comunica com o mecanismo de confiança 110 para garantir que um ID de usuário escolhido é único. Quando o ID do usuário não é único, o mecanismo de confiança 110 pode sugerir vantajo- samente um ID de usuário único. O miniaplicativo do lado do cliente reúne os dados de inscrição e transmite os dados de inscrição, por exemplo, atra- vés do documento XML, para o mecanismo de confiança 110, e em particu- lar, para o mecanismo de transação 205. De acordo com uma modalidade, a transmissão é codificada com a chave pública do mecanismo de autentica- ção 215.

De acordo com uma modalidade, o usuário executa uma inscri- ção única durante a etapa 905 do processo de inscrição 900. Por exemplo, o usuário se inscreve como uma pessoa particular, tal como o usuário Joe. Quando o usuário Joe deseja se inscrever como usuário Joe, CEO de Maga Corp., então de acordo com essa modalidade, o usuário Joe se registra uma segunda vez, recebe um segundo ID de usuário único e o mecanismo de confiança 110 não associa as duas identidades. De acordo com uma outra modalidade da invenção, o processo de inscrição 900 provê múltiplas identi- dades de usuário para um ID único do usuário. Assim, no exemplo acima, o mecanismo de confiança 110 vantajosamente associará as duas identidades do usuário Joe. Como será entendido por um versado a partir dessa descri- ção, um usuário pode ter muitas identidades, por exemplo, usuário Joe o chefe de família, usuário Joe o membro de fundações de caridade e assim por diante. Mesmo embora o usuário possa ter múltiplas identidades, de a- cordo com essa modalidade, o mecanismo de confiança 110 armazena pre- ferivelmente somente um conjunto de dados de inscrição. Além do mais, os usuários podem vantajosamente adicionar, editar/atualizar ou excluir identi- dades quando elas são necessárias.

Embora o processo de inscrição 900 seja descrito com referên- cia à sua modalidade preferida, a invenção não é planejada para ser limitada por isso. De preferência, um versado reconhecerá a partir dessa descrição, um número amplo de alternativas para a reunião dos dados de inscrição, e em particular, dados de autenticação da inscrição. Por exemplo, o miniapli- cativo pode ser miniaplicativo com base em modelo de objeto comum (COM) ou semelhante. Por outro lado, o processo de inscrição pode incluir a inscrição graduada. Por exemplo, em um nível mais baixo de inscrição, o usuário pode se inscrever através da ligação de comunicação 125 sem produzir documen- tação quanto à sua identidade. De acordo com um nível maior de inscrição, o usuário se inscreve usando um terceiro de confiança, tal como um notário digital. Por exemplo, e o usuário pode aparecer em pessoa para o terceiro de confiança, produzir credenciais tais como um certificado de nascimento, licença de motorista; ID militar ou similares, e o terceiro de confiança pode incluir vantajosamente, por exemplo, sua assinatura digital na submissão da inscrição. O terceiro de confiança pode incluir um notário real, uma agência do governo, tal como os correios ou departamentos de veículos motorizados, uma pessoa de recursos humanos em uma grande companhia inscrevendo um empregado ou similares. Um versado entenderá a partir dessa descrição que um amplo número de níveis variados de inscrição pode ocorrer durante o processo de inscrição 900.

Depois de receber os dados de autenticação da inscrição, na e- tapa 915, o mecanismo de transação 205, usando tecnologia SSL completa convencional envia os dados de autenticação da inscrição para o mecanis- mo de autenticação 215. Na etapa 920, o mecanismo de autenticação 215 decriptografa os dados de autenticação de inscrição usando a chave privada do mecanismo de autenticação 215. Além disso, o mecanismo de autentica- ção 215 utiliza o módulo de divisão de dados para operar matematicamente nos dados de autenticação da inscrição de modo a dividir os dados em pelo menos dois números randomizados independentemente indecifráveis. Como mencionado no precedente, pelo menos dois números podem compreender um número estatisticamente aleatório e um número em XOR binário. Na e- tapa 925, o mecanismo de autenticação 215 envia cada porção dos números randomizados para uma das facilidades de armazenamento de dados D1 a D4. Como mencionado no precedente, o mecanismo de autenticação 215 pode também vantajosamente randomizar quais porções são transferidas para quais depositários.

Freqüentemente durante o processo de inscrição 900, o usuário também desejará ter um certificado digital emitido tal que ele ou ela possa receber documentos criptografados de outros fora do sistema criptográfico 100. Como mencionado no precedente, a autoridade do certificado 115 ge- ralmente emite certificados digitais de acordo com um ou mais de vários pa- drões convencionais. De forma geral, o certificado digital inclui uma chave pública do usuário ou sistema, que é conhecida para todo mundo.

Quer o usuário solicite um certificado digital na inscrição, ou em um outro momento, a solicitacao e transferida atraves do mecanismo de con- fiança 110 para o mecanismo de autenticação 215. De acordo com uma mo- dalidade, a solicitação inclui um documento XML tendo, por exemplo, o no- me apropriado do usuário. De acordo com a etapa 935, o mecanismo de au- tenticação 215 transfere a solicitação para o mecanismo criptográfico 220 instruindo o mecanismo criptográfico 220 a gerar uma chave criptográfica ou par de chaves.

Com a solicitação, na etapa 935, o mecanismo criptográfico 220 gera pelo menos uma chave criptográfica. De acordo com uma modalidade, o módulo de manipulação criptográfica 625 gera um par de chaves, onde uma chave é usada como uma chave privada e uma é usada como uma chave pública. O mecanismo criptográfico 220 armazena a chave privada e, de acordo com uma modalidade, uma cópia da chave pública. Na etapa 945, o mecanismo criptográfico 220 transmite uma solicitação por um certificado digital para o mecanismo de transação 205. De acordo com uma modalida- de, a solicitação vantajosamente inclui uma solicitação padronizada, tal co- mo PCKS10, embutida em, por exemplo, um documento XML. A solicitação por um certificado digital pode vantajosamente corresponder com uma ou mais autoridades de certificado e um ou mais formatos-padrão que as auto- ridades do certificado requerem.

Na etapa 950 o mecanismo de transação 205 envia essa solici- tação para a autoridade do certificado 115, que, na etapa 955, retorna um certificado digital. O certificado digital retornado pode vantajosamente estar em um formato padronizado, tal como PKCS7, ou em um formato proprietá- rio de uma ou mais das autoridades de certificado 115. Na etapa 960, o certi- ficado digital é recebido pelo mecanismo de transação 205 e uma cópia é enviada para o usuário e uma cópia é armazenada com o mecanismo de confiança 110. O mecanismo de confiança 110 armazena uma cópia do cer- tificado tal que o mecanismo de confiança 110 não precisará contar com a disponibilidade da autoridade de certificado 115. Por exemplo, quando o u- suário deseja enviar um certificado digital, ou um terceiro solicita o certifica- do digital do usuário, a solicitação pelo certificado digital é tipicamente envi- ada para a autoridade do certificado 115. Entretanto, se a autoridade do cer- tificado 115 está conduzindo a manutenção ou foi vítima de uma falha ou comprometimento da segurança, o certificado digital pode não ficar disponí- vel.

Em qualquer momento depois de emitir as chaves criptográficas, o mecanismo criptográfico 220 pode utilizar vantajosamente o processo de divisão de dados 800 descrito acima tal que as chaves criptográficas são divididas em números randomizados independentemente indecifráveis. Simi- lar aos dados de autenticação, na etapa 965 o mecanismo criptográfico 220 transfere os números randomizados para as facilidades de armazenamento de dados D1 a D4.

Um versado reconhecerá a partir dessa descrição que o usuário pode solicitar um certificado digital a qualquer momento depois da inscrição. Além do mais, as comunicações entre os sistemas podem incluir vantajosa- mente tecnologias de criptografia de SSL completa ou de chave pública. A- lém do mais, o processo de inscrição pode emitir múltiplos certificados digi- tais de múltiplas autoridades de certificado, incluindo uma ou mais autorida- des de certificado proprietário internas ou externas ao mecanismo de confi- ança 110.

Como descrito nas etapas 935 a 960, uma modalidade da in- venção inclui a solicitação por um certificado que é eventualmente armaze- nado no mecanismo de confiança 110. Pelo fato de que, de acordo com uma modalidade, o módulo de manipulação criptográfica 625 emite as chaves usadas pelo mecanismo de confiança 110, cada certificado corresponde com uma chave privada. Portanto, o mecanismo de confiança 110 pode vantajo- samente proporcionar a interoperabilidade através da monitoração dos certi- ficados possuídos por, ou associados com, um usuário. Por exemplo, quan- do o mecanismo criptográfico 220 recebe uma solicitação por uma função criptográfica, o módulo de manipulação criptográfica 625 pode investigar os certificados possuídos pelo usuário solicitante para determinar se o usuário possui uma chave privada que combina com os atributos da solicitação. Quando um tal certificado existe, o módulo de manipulação criptográfica 625 pode usar o certificado ou as chaves públicas ou privadas associadas com ele, para executar a função solicitada. Quando um tal certificado não existe, o módulo de manipulação criptográfica 625 pode vantajosa e transparente- mente executar um número de ações para tentar remediar a falta de uma chave apropriada. Por exemplo, a figura 9B ilustra um fluxograma de um processo de interoperabilidade 970, que de acordo com aspectos de uma modalidade da invenção, revela as etapas precedentes para garantir que o módulo de manipulação criptográfica 625 execute funções criptográficas u- sando chaves apropriadas.

Como mostrado na figura 9B, o processo de interoperabilidade 970 começa com a etapa 972 onde o módulo de manipulação criptográfica 925 determina o tipo de certificado desejado. De acordo com uma modalida- de da invenção, o tipo de certificado pode ser vantajosamente especificado na solicitação por funções criptográficas, ou outros dados providos pelo soli- citante. De acordo com uma outra modalidade, o tipo de certificado pode ser verificado pelo formato de dados da solicitação. Por exemplo, o módulo de manipulação criptográfica 925 pode reconhecer vantajosamente que a solici- tação corresponde com um tipo particular.

De acordo com uma modalidade, o tipo do certificado pode in- cluir um ou mais padrões de algoritmo, por exemplo, RSA, ELGAMAL ou similares. Além disso, o tipo do certificado pode incluir um ou mais tipos de chaves, tais como chaves simétricas, chaves públicas, chave de criptografia forte tal como chaves de 256 bits, chaves menos seguras ou similares. Além do mais, o tipo de certificado pode incluir atualizações ou substituições de um ou mais dos padrões de algoritmo precedentes ou chaves, um ou mais formatos de mensagem ou dados, um ou mais esquemas de encapsulação ou codificação dé dados, tal como base 32 ou base 64. O tipo do certificado pode também incluir compatibilidade com uma ou mais aplicações criptográ- ficas de terceiros ou interfaces, um ou mais protocolos de comunicação ou um ou mais padrões de certificado ou protocolos. Um versado reconhecerá a partir dessa descrição que outras diferenças podem existir nos tipos de certi- ficado e traduções para e dessas diferenças podem ser implementadas co- mo descrito aqui.

Depois que o módulo de manipulação criptográfica 625 determi- na o tipo do certificado, o processo de interoperabilidade 970 prossegue pa- ra a etapa 974 e determina se o usuário possui um certificado que combina com o tipo determinado na etapa 974. Quando o usuário possui um certifica- do que combina, por exemplo, o mecanismo de confiança 110 tem acesso ao certificado que combina através, por exemplo, do seu armazenamento anterior, o módulo de manipulação criptográfica 825 sabe que uma chave privada que combina está também armazenada dentro do mecanismo de confiança 110. Por exemplo, a chave privada que combina pode ser arma- zenada dentro do depositário 210 ou sistema depositário 700. O módulo de manipulação criptográfica 625 pode solicitar vantajosamente que a chave privada que combina seja montada de, por exemplo, o depositário 210, e a seguir na etapa 976, usara chave privada que combina para executar ações ou funções criptográficas. Por exemplo, como mencionado no precedente, o módulo de manipulação criptográfica 625 pode vantajosamente executar a comprovação, comparações de prova, criptografia ou decriptografia de da- dos, verificação ou criação da assinatura digital ou similares.

Quando o usuário não possui um certificado que combina, o processo de interoperabilidade 970 prossegue para a etapa 978 onde o mó- dulo de manipulação criptográfica 625 determina se o usuário possui um cer- tificado com certificação cruzada. De acordo com uma modalidade, a certifi- cação cruzada entre autoridades de certificado ocorre quando uma primeira autoridade do certificado determina confiar em certificados de uma segunda autoridade de certificado. Em outras palavras, a primeira autoridade de certi- ficado determina que os certificados da segunda autoridade de certificado satisfazem certos padrões de qualidade, e, portanto, podem ser "certifica- dos" como equivalentes aos próprios certificados da primeira autoridade de certificado. A certificação cruzada se torna mais complexa quando as autori- dades de certificado emitem, por exemplo, certificados tendo níveis de confi- ança. Por exemplo, a primeira autoridade do certificado pode prover três ní- veis de confiança para um certificado particular, geralmente com base no grau de confiabilidade no processo de inscrição, enquanto a segunda autori- dade de certificado pode prover sete níveis de confiança. A certificação cru- zada pode vantajosamente rastrear quais níveis e quais certificados da se- gunda autoridade de certificado podem ser substituídos por quais níveis e quais certificados da primeira. Quando a certificação cruzada precedente é feita oficial e publicamente entre duas autoridades de certificação, o mape- amento dos certificados e níveis entre si é freqüentemente chamado "enca- deamento".

De acordo com uma outra modalidade da invenção, o módulo de manipulação criptográfica 625 pode desenvolver vantajosamente certifica- ções cruzadas fora dessas acordadas pelas autoridades do certificado. Por exemplo, o módulo de manipulação criptográfica 625 pode acessar a decla- ração de prática de certificado (CPS) da primeira autoridade do certificado, ou outra declaração de diretriz publicada, e usar, por exemplo, as fichas de autenticação requeridas pelos níveis particulares de confiança, combinar os certificados da primeira autoridade do certificado com esses de uma outra autoridade do certificado.

Quando, na etapa 978, o módulo de manipulação criptográfica 625 determina que o usuário possui um certificado com certificação cruzada, o processo de interoperabilidade 970 prossegue para a etapa 976, e executa a ação ou função criptográfica usando a chave pública com certificação cru- zada, chave privada ou ambas. Alternativamente, quando o módulo de ma· nipulação criptográfica 625 determina que o usuário não possui um certifica- do com certificação cruzada, o processo de interoperabilidade 970 prosse- gue para a etapa 980, onde o módulo de manipulação criptográfica 625 se- leciona uma autoridade de certificado que emite o tipo de certificado solicita- do, ou um certificado com certificação cruzada para ele. Na etapa 982, o módulo de manipulação criptográfica 625 determina se os dados de autenti- cação de inscrição do usuário, discutidos no precedente, satisfazem as exi- gências de autenticação da autoridade de certificado escolhida. Por exem- plo, se o usuário se inscreveu através de uma rede, por exemplo, por res- ponder perguntas demográficas e outras, os dados de autenticação providos podem estabelecer um nível inferior de confiança do que um usuário pro- vendo dados biométricos e aparecendo perante um terceiro, tal como, por exemplo, um notário. De acordo com uma modalidade, as exigências de au- tenticação precedentes podem ser vantajosamente providas na CPS da au- toridade de autenticação escolhida.

Quando o usuário tiver provido o mecanismo de confiança 110 com os dados de autenticação de inscrição que satisfazem as exigências da autoridade de certificado escolhida, o processo de interoperabilidade 970 prossegue para a etapa 984, onde o módulo de manipulação criptográfica 825 adquire o certificado da autoridade de certificado escolhida. De acordo com uma modalidade, o módulo de manipulação criptográfica 625 adquire o certificado seguindo as etapas 945 a 960 do processo de inscrição 900. Por exemplo, o módulo de manipulação criptográfica 625 pode utilizar vantajo- samente uma ou mais chaves públicas de um ou mais dos pares de chaves já disponíveis para o mecanismo criptográfico 200, para solicitar o certificado da autoridade de certificado. De acordo com uma outra modalidade, o módu- lo de manipulação criptográfica 625 pode vantajosamente gerar um ou mais novos pares de chaves e usar as chaves públicas correspondendo com eles, para solicitar o certificado da autoridade de certificado.

De acordo com uma outra modalidade, o mecanismo de confi- ança 110 pode incluir vantajosamente um ou mais módulos de emissão de certificado capazes de emitir um ou mais tipos de certificado. De acordo com essa modalidade, o módulo de emissão de certificado pode prover o certifi- cado precedente. Quando o módulo de manipulação criptográfica 625 adqui- re o certificado, o processo de interoperabilidade 970 prossegue para a eta- pa 976, e executa a ação ou função criptográfica usando a chave pública, a chave privada ou ambas correspondendo com o certificado adquirido.

Quando o usuário, na etapa 982, não proveu o mecanismo de confiança 110 com dados de autenticação de inscrição que satisfazem as exigências da autoridade de certificado escolhida, o módulo de manipulação criptográfica 625 determina, na etapa 986, se existem outras autoridades de certificado que têm exigências de autenticação diferentes. Por exemplo, o módulo de manipulação criptográfica 625 pode procurar autoridades de certi- ficado tendo menores exigências de autenticação, mas ainda emitindo os certificados escolhidos, ou suas certificações cruzadas.

Quando a autoridade de certificado precedente tendo menores exigências existe, o processo de interoperabilidade 970 prossegue para a etapa 980 e escolhe essa autoridade de certificado. Alternativamente, quan- do nenhuma tal autoridade de certificado existe, na etapa 988, o mecanismo de confiança 110 pode solicitar fichas de autenticação adicionais do usuário. Por exemplo, o mecanismo de confiança 110 pode solicitar novos dados de autenticação de inscrição compreendendo, por exemplo, dados biométricos. Também, o mecanismo de confiança 110 pode solicitar que o usuário apare- ça perante um terceiro de confiança e proveja credenciais de autenticação apropriadas, tais como, por exemplo, aparecendo perante um notário com uma carteira de motorista, cartão de seguro social, cartão de banco, certidão de nascimento, ID militar ou similares. Quando o mecanismo de confiança 110 recebe os dados de autenticação atualizados, o processo de interopera- bilidade 970 prossegue para a etapa 984 e adquire o certificado escolhido precedente.

Através do processo de interoperabilidade 970 precedente, o módulo de manipulação criptográfica 625 vantajosamente provê traduções e conversões transparentes, sem junção entre diferentes sistemas criptográfi- cos. Um versado reconhecerá a partir dessa descrição, um amplo número de vantagens e implementações do sistema interoperável precedente. Por e- xemplo, a etapa precedente 986 do processo de interoperabilidade 970 pode vantajosamente incluir aspectos da arbitragem de confiança, discutida em mais detalhes abaixo, onde a autoridade de certificado pode, sob circunstân- cias especiais, aceitar níveis inferiores de certificação cruzada. Além disso, o processo de interoperabilidade 970 pode incluir garantir a interoperabilidade entre e a utilização de revogações de certificado-padrão, tal como utilizando listas de revogação de certificado (CRL), protocolos do estado do certificado em linha (OCSP) ou similares.

A figura 10 ilustra um fluxo de dados de um processo de autenti- cação 1000 de acordo com aspectos de uma modalidade da invenção. De acordo com uma modalidade, o processo de autenticação 1000 inclui reunir dados de autenticação atuais de um usuário e comparar esses com os da- dos de autenticação da inscrição do usuário. Por exemplo, o processo de autenticação 1000 começa na etapa 1005 onde um usuário deseja executar uma transação, por exemplo, com um fornecedor. Tais transações podem incluir, por exemplo, selecionar uma opção de compra, solicitar acesso a uma área restrita ou a um dispositivo do sistema do fornecedor 120 ou simi- lares. Na etapa 1010, um fornecedor provê o usuário com um ID da transa- ção e uma solicitação de autenticação. O ID da transação pode vantajosa- mente incluir uma quantidade de 192 bits tendo um carimbo de tempo de 32 bits concatenado com uma quantidade aleatória de 128 bits, ou "nonce", concatenado com uma constante específica do fornecedor de 32 bits. Um tal ID da transação identifica unicamente a transação tal que transações de có- pia podem ser recusadas pelo mecanismo de confiança 110.

A solicitação de autenticação pode vantajosamente incluir qual nível de autenticação é necessário para uma transação particular. Por e- xemplo, o fornecedor pode especificar um nível particular de confiança que é requerido para a transação em questão. Se a autenticação não pode ser fei- ta para esse nível de confiança, como será discutido abaixo, a transação não ocorrerá sem a autenticação adicional pelo usuário para elevar o nível de confiança ou uma mudança nos termos da autenticação entre o fornecedor e o servidor. Esses assuntos são discutidos mais completamente abaixo.

De acordo com uma modalidade, o ID da transação e a solicita- ção de autenticação podem ser vantajosamente gerados por um miniaplica- tivo no lado do fornecedor ou outro programa de software. Além disso, a transmissão do ID da transação e dos dados de autenticação pode incluir um ou mais documentos XML criptografados usando tecnologia SSL convencio- nal, tal como, por exemplo, 1/2 SSL, ou, em outras palavras, SSL autenticado no lado do fornecedor.

Depois que o sistema do usuário 105 recebe o ID da transação e a solicitação de autenticação, o sistema do usuário 105 reúne os dados de autenticação atuais, potencialmente incluindo a informação biométrica atual, do usuário. O sistema do usuário 105, na etapa 1015, criptografa pelo me- nos òs dados dè autenticação atuais "B" e o ID da transação, com a chave pública do mecanismo de autenticação 215 e transfere esses dados para o mecanismo de confiança 110. A transmissão preferivelmente compreende documentos XML criptografados com pelo menos a tecnologia 1/2 SSL con- vencional. Na etapa 1020, o mecanismo de transação 205 recebe a trans- missão, de preferência reconhece o formato de dados ou a solicitação no URL ou URI e envia a transmissão para o mecanismo de autenticação 215.

Durante as etapas 1015 e 1020, o sistema do fornecedor 120, na etapa 1025, envia o ID da transação e a solicitação de autenticação para o mecanismo de confiança 110, usando a tecnologia SSL completa preferi- da. Essa comunicação pode também incluir um ID do fornecedor, embora a identificação do fornecedor possa também ser comunicada através de uma porção não aleatória do ID da transação. Nas etapas 1030 e 1035, o meca- nismo de transação 205 recebe a comunicação, cria um registro no rastro de auditoria e gera uma solicitação pelos dados de autenticação de inscrição do usuário a serem montados a partir das facilidades de armazenamento de dados D1 a D4. Na etapa 1040, o sistema depositário 700 transfere as por- ções dos dados de autenticação da inscrição correspondendo com o usuário para o mecanismo de autenticação 215. Na etapa 1045, o mecanismo de autenticação 215 decriptografa a transmissão usando sua chave privada e compara os dados de autenticação da inscrição com os dados de autentica- ção atuais providos pelo usuário.

A comparação da etapa 1045 pode vantajosamente aplicar au- tenticação sensível ao contexto heurística, como citado no precedente, e discutido em mais detalhes abaixo. Por exemplo, se a informação biométrica recebida não combina perfeitamente, isso resulta em uma combinação de confiança menor. Em modalidades particulares, o nível de confiança da au- tenticação é equilibrado contra a natureza da transação e os desejos de am- bos o usuário e o fornecedor. Novamente, isso é discutido em mais detalhes abaixo.

Ma etapa 1050; o mecanismo de autenticação 215 preenche a solicitação de autenticação com o resultado da comparação da etapa 1045. De acordo com uma modalidade da invenção, a solicitação de autenticação é preenchida com um resultado de SIM/NÃO ou VERDADEIRO/FALSO do processo de autenticação 1000. Na etapa 1055, a solicitação de autentica- ção preenchida é retornada para o fornecedor para o fornecedor agir sobre ela, por exemplo, permitindo que o usuário complete a transação que iniciou a solicitação de autenticação. De acordo com uma modalidade, uma mensa- gem de confirmação é passada para o usuário.

Com base no precedente, o processo de autenticação 1000 van- tajosamente mantém os dados sensíveis seguros e produz resultados confi- gurados para manter a integridade dos dados sensíveis. Por exemplo, os dados sensíveis são montados somente dentro do mecanismo de autentica- ção 215. Por exemplo, os dados de autenticação da inscrição são indecifrá- veis até que eles são montados no mecanismo de autenticação 215 pelo módulo de montagem de dados, e os dados de autenticação atuais são in- decifráveis até que eles são abertos pela tecnologia SSL convencional e a chave privada do mecanismo de autenticação 215. Além do mais, o resulta- do de autenticação transmitido para o fornecedor não inclui os dados sensí- veis e o usuário pode até mesmo não saber se ele ou ela produziu dados de autenticação válidos.

Embora o processo de autenticação 1000 seja descrito com re- ferência às suas modalidades preferidas e alternativas, a invenção não é planejada para ser limitada dessa forma. De preferência, um versado reco- nhecerá a partir dessa descrição um amplo número de alternativas para o processo de autenticação 1000. Por exemplo, o fornecedor pode ser vanta- josamente substituído por quase qualquer aplicação solicitante, mesmo es- sas residindo com o sistema do usuário 105. Por exemplo, uma aplicação do cliente, tais como Microsoft Word, pode usar uma interface do programa a- plicativo (API) ou uma API criptográfica (CAPI) para solicitar a autenticação antes de desbloquear um documento. Alternativamente, um servidor de cor- reio, uma rede, um telefone celular, um dispositivo de computação pessoal ou móvel, uma estação de trabalho ou similares, podem todos fazer solicita- ções de autenticação que podem ser preenchidas pelo processo de autenti- cação 1000. Na realidade, depois de prover o processo de autenticação de confiança precedente 1000, a aplicação solicitante ou dispositivo pode pro- ver acesso à ou usar um amplo número de dispositivos ou sistemas eletrôni- cos ou de computador.

Além do mais, o processo de autenticação 1000 pode utilizar um amplo número de procedimentos alternativos na eventualidade de falha de autenticação. Por exemplo, a falha de autenticação pode manter o mesmo ID da transação e solicitar que o usuário insira novamente os seus dados de autenticação atuais. Como mencionado no precedente, o uso do mesmo ID da transação permite que o comparador do mecanismo de autenticação 215 monitore e limite o número de tentativas de autenticação para uma transa- ção particular, dessa maneira criando um sistema criptográfico 100 mais se- guro.

Além disso, o processo de autenticação 1000 pode ser vantajo- samente utilizado para desenvolver soluções de assinatura única elegante, tal como, desbloquear uma caixa-forte de dados sensíveis. Por exemplo, a autenticação bem-sucedida ou positiva pode prover ao usuário autenticado a capacidade de automaticamente acessar qualquer número de senhas para um número de sistemas e aplicações quase ilimitado. Por exemplo, a auten- ticação de um usuário pode prover ao usuário acesso à senha, conexão, credenciais financeiras ou similares, associados com múltiplos fornecedores em linha, uma rede local, vários dispositivos de computação pessoal, prove- dores de serviço da Internet, provedores de leilão, corretagem de investi- mento ou similares. Pela utilização de uma caixa-forte de dados sensíveis, os usuários podem escolher senhas verdadeiramente grandes e aleatórias porque eles não precisam mais lembrar delas através da associação. De preferência, o processo de autenticação 1000 provê acesso a elas. Ror e- xemplo, um usuário pode escolher uma seqüência alfanumérica aleatória que tem vinte dígitos a mais em comprimento do que alguma coisa associa- da com uma data memorável, nome, etc.

De acordo com uma modalidade, uma caixa-forte de dados sen- síveis associada com um dado usuário pode ser vantajosamente armazena- da nas facilidades de armazenamento de dados do depositário 210 ou divi- dida e armazenada no sistema depositário 700. De acordo com essa moda- lidade, depois da autenticação positiva do usuário, o mecanismo de confian- ça 110 serve os dados sensíveis solicitados, tal como, por exemplo, para a senha apropriada para a aplicação solicitante. De acordo com uma outra modalidade, o mecanismo de confiança 110 pode incluir um sistema separa- do para armazenar a caixa-forte dos dados sensíveis. Por exemplo, o meca- nismo de confiança 110 pode incluir um mecanismo de software indepen- dente implementando a funcionalidade da caixa-forte de dados e de maneira figurativa residente "atrás" do sistema de segurança de primeiro plano pre- cedente do mecanismo de confiança 110. De acordo com essa modalidade, o mecanismo de software serve os dados sensíveis solicitados depois que o mecanismo de software recebe um sinal indicando autenticação positiva do usuário do mecanismo de confiança 110.

Em ainda uma outra modalidade, a caixa-forte de dados pode ser implementada por um sistema de terceiros. Similar à modalidade do me- canismo de software, o sistema de terceiros pode vantajosamente servir os dados sensíveis solicitados depois que o sistema de terceiros recebe um sinal indicando autenticação positiva do usuário do mecanismo de confiança 110. De acordo com ainda uma outra modalidade, a caixa-forte de dados pode ser implementada no sistema do usuário 105. Um mecanismo de soft- ware do lado do usuário pode vantajosamente servir os dados precedentes depois de receber um sinal indicando autenticação positiva do usuário do mecanismo de confiança 110.

Embora as caixas-fortes de dados precedentes sejam reveladas com referência às modalidades alternativas, um versado reconhecerá a par- tir dessa descrição, um amplo número de implementações adicionais da mesma. Por exemplo, uma caixa-forte de dados particular pode incluir as- pectos de algumas ou todas as modalidades precedentes. Além disso, qual- quer uma das caixas-fortes de dados precedentes pode utilizar uma ou mais solicitações de autenticação em temoos variados= Por exemplo. qualquer uma das caixas-fortes de dados pode requerer autenticação a cada uma ou mais transações, periodicamente, a cada uma ou mais sessões, a cada a- cesso a uma ou mais páginas da Web ou websites, em um ou mais outros intervalos especificados ou similares.

A figura 11 ilustra um fluxo de dados de um processo de assina- tura 1100 de acordo com aspectos de uma modalidade da invenção. Como mostrado na figura 11, o processo de assinatura 1100 inclui etapas similares a essas do processo de autenticação 1000 descrito no precedente com refe- rência à figura 10. De acordo com uma modalidade da invenção, o processo de assinatura 1100 autentica, em primeiro lugar, o usuário e a seguir execu- ta uma ou mais das várias funções de assinatura digital como será discutido em mais detalhes abaixo. De acordo com uma outra modalidade, o processo de assinatura 1100 pode vantajosamente armazenar dados relacionados a ele, tal como provas de mensagens ou documentos ou similares. Esses da- dos podem ser usados vantajosamente em uma auditoria ou qualquer outra eventualidade, tal como, por exemplo, quando uma parte participante inte- ressada tenta repudiar uma transação.

Como mostrado na figura 11, durante as etapas de autentica- ção, o usuário e o fornecedor podem vantajosamente concordar em uma mensagem, tal como, por exemplo, um contrato. Durante a assinatura, o processo de assinatura 1100 garante vantajosamente que o contrato assina- do pelo usuário seja idêntico ao contrato suprido pelo fornecedor. Portanto, de acordo com uma modalidade, durante a autenticação, o fornecedor e o usuário incluem uma prova de suas cópias respectivas da mensagem ou contrato, nos dados transmitidos para o mecanismo de autenticação 215. Pela utilização somente de uma prova de uma mensagem ou contrato, o mecanismo de confiança 110 pode armazenar vantajosamente uma quanti- dade de dados significativamente reduzida, proporcionando um sistema crip- tográfico mais eficiente e de custo efetivo. Além disso, a prova armazenada pode ser vantajosamente comparada com uma prova de um documento em questão para determinar se o documento em questão combina com um as- sinado por qualquer uma das partes interessadas. A capacidade de determi- nar se o documento é idêntico a um relacionado com uma transação propor- ciona evidência adicional que pode ser usada contra uma reivindicação por repúdio por uma parte interessada em uma transação.

Na etapa 1103, o mecanismo de autenticação 215 monta os da- dos de autenticação da inscrição e os compara com os dados de autentica- ção atuais providos pelo usuário. Quando o comparador do mecanismo de autenticação 215 indica que os dados de autenticação da inscrição combi- nam com os dados de autenticação atuais, o comparador do mecanismo de autenticação 215 também compara a prova da mensagem suprida pelo for- necedor com a prova da mensagem suprida pelo usuário. Assim, o meca- nismo de autenticação 215 vantajosamente garante que a mensagem con- cordada pelo usuário é idêntica a essa concordada pelo fornecedor.

Na etapa 1105, o mecanismo de autenticação 215 transmite uma solicitação de assinatura digital para o mecanismo criptográfico 220. De acordo com uma modalidade da invenção, a solicitação inclui uma prova da mensagem ou contrato. Entretanto, um versado reconhecerá a partir dessa descrição que o mecanismo criptográfico 220 pode criptografar virtualmente qualquer tipo de dados, incluindo, mas não-limitado a, vídeo, áudio, biomé- trica, imagens ou texto para formar a assinatura digital desejada. De volta para a etapa 1105, a solicitação da assinatura digital preferivelmente com- preende um documento XML comunicado através de tecnologias SSL con- vencionais.

Na etapa 1110, o mecanismo de autenticação 215 transmite uma solicitação para cada uma das facilidades de armazenamento de dados D1 a D4, tal que cada uma das facilidades de armazenamento de dados D1 a D4 transmite sua porção respectiva da chave ou chaves criptográficas cor- respondendo com uma parte interessada que assina. De acordo com uma outra modalidade, o mecanismo criptográfico 220 utiliza algumas ou todas as etapas do processo de interoperabilidade 970 discutido no precedente, tal que o mecanismo criptográfico 220 determina, em primeiro lugar, a chave ou chaves apropriadas para solicitar do depositário 210 ou do sistema depositá- rio 700 para a parte interessada que assina, β adota ações para prover cha- ves de combinação apropriadas. De acordo com ainda uma outra modalida- de, o mecanismo de autenticação 215 ou o mecanismo criptográfico 220 po- de solicitar vantajosamente uma ou mais das chaves associadas com a par- te interessada que assina e armazenadas no depositário 210 ou sistema de- positário 700.

De acordo com uma modalidade, a parte interessada que assina inclui um ou ambos o usuário e o fornecedor. Em tal caso, o mecanismo de autenticação 215 vantajosamente solicita as chaves criptográficas corres- pondendo com o usuário e/ou o fornecedor. De acordo com uma outra mo- dalidade, a parte interessada que assina inclui o mecanismo de confiança 110. Nessa modalidade, o mecanismo de confiança 110 está certificando que o processo de autenticação 1000 autenticou apropriadamente o usuário, fornecedor ou ambos. Portanto, o mecanismo de autenticação 215 solicita a chave criptográfica do mecanismo de confiança 110, tal como, por exemplo, a chave pertencente ao mecanismo criptográfico 220, para executar a assi- natura digital. De acordo com uma outra modalidade, o mecanismo de confi- ança 110 executa uma função semelhante a notário digital. Nessa modalida- de, a parte interessada que assina inclui o usuário, fornecedor ou ambos, junto com o mecanismo de confiança 110. Assim, o mecanismo de confiança 110 provê a assinatura digital do usuário e/ou fornecedor e a seguir indica com sua própria assinatura digital que o usuário e/ou fornecedor foram apro- priadamente autenticados. Nessa modalidade, o mecanismo de autenticação 215 pode solicitar vantajosamente a montagem das chaves criptográficas correspondendo com o usuário, o fornecedor ou ambos. De acordo com uma outra modalidade, o mecanismo de autenticação 215 pode vantajosamente solicitar a montagem das chaves criptográficas correspondendo com o me- canismo de confiança 110.

De acordo com uma outra modalidade, o mecanismo de confi- ança 110 executa as funções semelhantes à procuração. Por exemplo, o mecanismo de confiança 110 pode assinar digitalmente a mensagem em nome de um terceiro. Em tal caso, o mecanismo de autenticação 215 solicita as chaves criptográficas associadas com o terceiro= De acordo com essa modalidade, o processo de assinatura 1100 pode vantajosamente incluir a autenticação do terceiro, antes de permitir as funções semelhantes à procu- ração. Além disso, o processo de autenticação 1000 pode incluir uma verifi- cação das restrições de terceiros, tal como, por exemplo, lógica de negócios ou semelhante ditando quando e em quais circunstâncias a assinatura de um terceiro particular pode ser usada.

Com base no precedente, na etapa 1110, o mecanismo de au- tenticação solicitou as chaves criptográficas das facilidades de armazena- mento de dados D1 a D4 correspondendo com a parte interessada que assi- na. Na etapa 1115, as facilidades de armazenamento de dados D1 a D4 transmitem suas porções respectivas da chave criptográfica correspondendo 20 com a parte interessada que assina para o mecanismo criptográfico 220. De acordo com uma modalidade, as transmissões precedentes incluem tecnolo- gias SSL. De acordo com uma outra modalidade, as transmissões preceden- tes podem ser vantajosamente super-criptografadas com a chave pública do mecanismo criptográfico 220.

Na etapa 1120, o mecanismo criptográfico 220 monta as chaves criptográficas precedentes da parte interessada que assina e criptografa a mensagem com elas, dessa maneira formando a(s) assinatura(s) digital(is). Na etapa 1125 do processo de assinatura 1100, o mecanismo criptográfico 220 transmite a(s) assinatura(s) digital(is) para o mecanismo de autenticação 215. Na etapa 1130, o mecanismo de autenticação 215 transmite a solicita- ção de autenticação preenchida junto com uma cópia da mensagem com- provada e a(s) assinatura(s) digital(is) para o mecanismo de transação 205. Na etapa 1135, o mecanismo de transação 205 transmite um recibo com- preendendo o ID da transação, uma indicação de se a autenticação foi bem- sucedida e a(s) assinatura(s) digital(is), para o fornecedor. De acordo com uma modalidade, a transmissão precedente pode incluir vantajosamente a assinatura digital do mecanismo de confiança 110. Por exemplo, o meca- nismo de confiança 110 pode criptografar a prova do recibo com sua chave privada, dessa maneira formando uma assinatura digital a ser anexada na transmissao para o fornecedor.

De acordo com uma modalidade, o mecanismo de transação 205 também transmite uma mensagem de confirmação para o usuário. Em- bora o processo de assinatura 1100 seja descrito com referência às suas modalidades preferidas e alternativas, a invenção não é planejada para ser limitada por isso. De preferência, um versado reconhecerá a partir dessa descrição, um amplo número de alternativas para o processo de assinatura 1100. Por exemplo, o fornecedor pode ser substituído por uma aplicação de usuário, tal como uma aplicação de e-mail. Por exemplo, o usuário pode de- sejar assinar digitalmenté um e-mail particular com sua assinatura digital. Em uma tal modalidade, a transmissão por todo o processo de assinatura 1100 pode vantajosamente incluir somente uma cópia de uma prova da mensagem. Além do mais, um versado reconhecerá a partir dessa descrição que um amplo número de aplicações de cliente pode solicitar assinaturas digitais. Por exemplo, as aplicações do cliente podem compreender proces- sadores de texto, planilhas, e-mails, correio de voz, acesso a áreas restritas do sistema ou similares.

Além disso, um versado reconhecerá a partir dessa descrição que as etapas 1105 até 1120 do processo de assinatura 1100 podem utilizar vantajosamente algumas ou todas as etapas do processo de interoperabili- dade 970 da figura 9B, dessa maneira provendo interoperabilidade entre sis- temas criptográficos diferentes que podem, por exemplo, precisar processar a assinatura digital sob tipos de assinatura diferentes.

A figura 12 ilustra um fluxo de dados de um processo de cripto- grafia/decriptografia 1200 de acordo com aspectos de uma modalidade da invenção. Como mostrado na figura 12, o processo de decriptografia 1200 começa pela autenticação do usuário usando o processo de autenticação 1000. De acordo com uma modalidade, o processo de autenticação 1000 inclui na solicitação de autenticação, uma chave de sessão síncrona, Por exemplo, nas tecnologias PKI convencionais, é entendido por versados que a criptografia ou a decriptografia dos dados usando chaves públicas e priva- das é matematicamente intensiva e pode requerer recursos significativos do sistema. Entretanto, nos sistemas criptograficos de chave simetrica, ou sis temas onde o remetente e o receptor de uma mensagem compartilham uma única chave comum que é usada para criptografar e decriptografar uma mensagem, as operações matemáticas são significativamente mais simples e mais rápidas. Assim, nas tecnologias PKI convencionais, o remetente de uma mensagem gerará a chave de sessão síncrona e criptografará a men- sagem usando o sistema de chave simétrico mais simples, mais rápido. A seguir, o remetente criptografará a chave de sessão com a chave pública do receptor. A sessão criptografada será anexada na mensagem criptografada sincronamente e ambos os dados são enviados para o receptor. O receptor usa a sua chave privada para decriptografar a chave da sessão e a seguir usa a chave da sessão para decriptografar a mensagem. Com base no pre- cedente, o sistema de chave simétrica mais simples e mais rápido é usado para a maior parte do processamento de criptografia/decriptografia. Assim, no processo de decriptografia 1200, a decriptografia vantajosamente assume que uma chave síncrona foi criptografada com a chave pública do usuário. Assim, como mencionado no precedente, a chave de sessão criptografada é incluída na solicitação de autenticação.

De volta para o processo de decriptografia 1200, depois que o usuário foi autenticado na etapa 1205, o mecanismo de autenticação 215 envia a chave de sessão criptografada para o mecanismo criptográfico 220. Na etapa 1210, o mecanismo de autenticação 215 envia uma solicitação pa- ra cada uma das facilidades de armazenamento de dados, D1 a D4, solici- tando os dados da chave criptográfica do usuário. Na etapa 1215, cada faci- lidade de armazenamento de dados, D1 a D4, transmite sua porção respec- tiva da chave criptográfica para o mecanismo criptográfico 220. De acordo com uma modalidade, a transmissão precedente é criptografada com a cha- ve pública do mecanismo criptográfico 220.

Na etapa 1220 do processo de decriptografia 1200, o mecanis- mo criptográfico 220 monta a chave criptográfica e decriptografa a chave de sessão com ela. Na etapa 1225, o mecanismo criptográfico envia a chave de sessão para o mecanismo de autenticação 215. Na etapa 1227, o mecanis- mo de autenticação 215 preenche a solicitação de autenticação incluindo a chave de sessão decriptografada e transmite a solicitação de autenticação preenchida para o mecanismo de transação 205. Na etapa 1230, o meca- nismo de transação 205 envia a solicitação de autenticação junto com a chave de sessão para a aplicação solicitante ou fornecedor. A seguir, de a- cordo com uma modalidade, a aplicação solicitante ou o fornecedor usa a chave de sessão para decriptografar a mensagem criptografada.

Embora o processo de decriptografia 1200 seja descrito com re- ferência às suas modalidades preferidas e alternativas, um versado reco- nhecerá a partir dessa descrição um amplo número de alternativas para o processo de decriptografia 1200. Por exemplo, o processo de decriptografia 1200 pode preceder a criptografia de chave síncrona e contar com a tecno- Iogia de chave pública completa. Em uma tal modalidade, a aplicação solici- tante pode transmitir toda a mensagem para o mecanismo criptográfico 220 ou pode utilizar algum tipo de compactação ou prova reversível a fim de transmitir a mensagem para o mecanismo criptográfico 220. Um versado também reconhecerá a partir dessa descrição que as comunicações prece- dentes podem vantajosamente incluir documentos XML envolvidos na tecno- logia SSL.

O processo de criptografia/decriptografia 1200 também propor- ciona a criptografia de documentos ou outros dados. Assim, na etapa 1235, uma aplicação solicitante ou fornecedor pode vantajosamente transmitir para o mecanismo de transação 205 do mecanismo de confiança 110, uma solici- tação pela chave pública do usuário. A aplicação solicitante ou fornecedor faz essa solicitação porque a aplicação solicitante ou fornecedor usa a chave pública do usuário, por exemplo, para criptografar a chave de sessão que será usada para criptografar o documento ou mensagem. Como mencionado no processo de inscrição 900, o mecanismo de transação 205 armazena uma cópia do certificado digital do usuário, por exemplo, no armazenamento de massa 225. Assim, na etapa 1240 do processo de criptografia 1200, o mecanismo de transação 205 solicita o certificado digital do usuário do ar- mazenamento de massa 225. Na etapa 1245, o armazenamento de massa 225 transmite o certificado digita! correspondendo com o usuário, para o me- canismo de transação 205. Na etapa 1250, o mecanismo de transação 205 tránsmite o certificado digital para a aplicação solicitante ou fornecedor. De acordo com uma modalidade, a porção de criptografia do processo de crip- tografia 1200 não inclui a autenticação de um usuário. Isso é porque o forne- cedor solicitante precisa somente da chave pública do usuário e não está solicitando quaisquer dados sensíveis.

Um versado reconhecerá a partir dessa descrição que se um usuário particular não tem um certificado digital, o mecanismo de confiança 110 pode utilizar um pouco ou todo o processo de inscrição 900 a fim de ge- rar um certificado digital para esse usuário particular. A seguir, o mecanismo de confiança 110 pode iniciar o processo de criptografia/decriptografia 1200 e dessa maneira prover o certificado digital apropriado. Além disso, um ver- sado reconhecerá a partir dessa descrição que as etapas 1220 e 1235 até 1250 do processo de criptografia/decriptografia 1200 podem vantajosamente utilizar algumas ou todas as etapas do processo de interoperabilidade da figura 9B, dessa maneira provendo interoperabilidade entre sistemas cripto- gráficos diferentes que podem, por exemplo, precisar processar a criptogra- fia.

A figura 13 ilustra um diagrama de blocos simplificado de um sistema de mecanismo de confiança 1300 de acordo com aspectos de ainda uma outra modalidade da invenção. Como mostrado na figura 13, o sistema do mecanismo de confiança 1300 compreende uma pluralidade de meca- nismos de confiança distintos 1305, 1310, 1315 e 1320, respectivamente. Para facilitar um entendimento mais completo da invenção, a figura 13 ilustra cada mecanismo de confiança 1305, 1310, 1315 e 1320 como tendo um me- canismo de transação, um depositário e um mecanismo de autenticação. Entretanto, um versado reconhecerá que cada mecanismo de transação po- de vantajosamente compreender alguns, uma combinação ou todos os ele- mentos e canais de comunicação descritos com referência às figuras 1-8. Por exemplo, uma modalidade pode vantajosamente incluir mecanismos de confiança tendo um ou mais mecanismos de transação, depositários e servi- dores criptográficos ou quaisquer combinações desses.

De acordo com uma modalidade da invenção, cada um dos me- canismos de confiança 1305, 1310, 1315 e 1320 é geograficamente separa- do, tal que, por exemplo, o mecanismo de confiança 1305 pode residir em uma primeira localização, o mecanismo de confiança 1310 pode residir em uma segunda localização, o mecanismo de confiança 1315 pode residir em uma terceira localização e o mecanismo de confiança 1320 pode residir em uma quarta localização. A separação geográfica precedente vantajosamente diminui o tempo de resposta do sistema enquanto aumentando a segurança de todo o sistema do mecanismo de confiança 1300.

Por exemplo, quando um usuário se conecta no sistema cripto- gráfico 100, o usuário pode estar mais próximo da primeira localização e po- de desejar ser autenticado. Como descrito com referência à figura 10, para ser autenticado, o usuário provê dados de autenticação atuais, tal como um biométrico ou semelhante, e os dados de autenticação atuais são compara- dos com os dados de autenticação da inscrição desse usuário. Portanto, de acordo com um exemplo, o usuário vantajosamente provê dados de autenti- cação atuais para o mecanismo de confiança geograficamente mais próximo 1305. O mecanismo de transação 1321 do mecanismo de confiança 1305 então envia os dados de autenticação atuais para o mecanismo de autenti- cação 1322 também residente na primeira localização. De acordo com uma outra modalidade, o mecanismo de transação 1321 envia os dados de au- tenticação atuais para um ou mais dos mecanismos de autenticação dos mecanismos de confiança 1310,1315 ou 1320.

O mecanismo de transação 1321 também solicita a montagem dos dados de autenticação da inscrição a partir dos depositários, por exem- plo, de cada um dos mecanismos de confiança, 1305 a 1320. De acordo com esta modalidade, cada depositário provê sua porção dos dados de au- tenticação de inscrição para o mecanismo de autenticação 1322 do meca- nismo de confiança 1305. O mecanismo de autenticação 1322 então utiliza as porções de dados criptografadas, por exemplo, dos primeiros dois deposi- tários a responder e monta os dados de autenticação da inscrição na forma decifrada. O mecanismo de autenticação 1322 compara os dados de auten- ticação da inscrição com os dados de autenticação atuais e retorna um re- sultado de autenticação para o mecanismo de transação 1321 do mecanis- mo de confiança 1305.

Com base no acima, o sistema do mecanismo de confiança 1300 utiliza o mais próximo de uma pluralidade de mecanismos de confiança geograficamente separados, 1305 a 1320, para executar o processo de au- tenticação. De acordo com uma modalidade da invenção, o roteamento da informação para o mecanismo de transação mais próximo pode ser vantajo- samente executado nos miniaplicativos no lado do cliente executando em um ou mais do sistema do usuário 105, sistema do fornecedor 120 ou auto- ridade do certificado 115. De acordo com uma modalidade alternativa, um processo de decisão mais sofisticado pode ser utilizado para selecionar dos mecanismos de confiança 1305 a 1320. Por exemplo, a decisão pode ser baseada na disponibilidade, operabilidade, velocidade das conexões, carga, desempenho, proximidade geográfica ou uma combinação desses, de um dado mecanismo de confiança.

Dessa maneira, o sistema do mecanismo de confiança 1300 re- duz o seu tempo de resposta enquanto mantendo as vantagens de seguran- ça associadas com facilidades de armazenamento de dados geograficamen- te remotas, tal como essas discutidas com referência à figura 7 onde cada facilidade de armazenamento de dados armazena porções randomizadas dos dados sensíveis. Por exemplo, um comprometimento da segurança, por exemplo, no depositário 1325 do mecanismo de confiança 1315 não com- promete necessariamente os dados sensíveis do sistema do mecanismo de confiança 1300. Isso é porque o depositário 1325 contém somente dados randomizados não decifráveis que, sem mais, são inteiramente inúteis.

De acordo com uma outra modalidade, o sistema do mecanismo de confiança 1300 pode vantajosamente incluir múltiplos mecanismos crip- tográficos dispostos similares aos mecanismos de autenticação. Os meca- nismos criptográficos podem vantajosamente executar funções criptográficas tal como essas reveladas com referência às figuras 1-8. De acordo com ain- da urna outra modalidade, o sistema do mecanismo ds confiança 1300 pode vantajosamente substituir os múltiplos mecanismos de autenticação com múltiplos mecanismos criptográficos, dessa maneira executando funções criptográficas tal como essas reveladas com referência às figuras 1-8. De acordo com ainda uma outra modalidade da invenção, o sistema do meca- nismo de confiança 1300 pode substituir cada múltiplo mecanismo de auten- ticação por um mecanismo tendo alguma ou toda a funcionalidade dos me- canismos de autenticação, mecanismos criptográficos ou ambos, como des- crito no precedente.

Embora o sistema do mecanismo de confiança 1300 seja descri- to com referência às suas modalidades preferidas e alternativas, um versado reconhecerá que o sistema do mecanismo de confiança 1300 pode compre- ender porções dos mecanismos de confiança 1305 a 1320. Por exemplo, o sistema do mecanismo de confiança 1300 pode incluir um ou mais meca- nismos de transação, um ou mais depositários, um ou mais mecanismos de autenticação ou um ou mais mecanismos criptográficos ou combinações desses.

A figura 14 ilustra um diagrama de blocos simplificado de um sistema do mecanismo de confiança 1400 de acordo com aspectos de ainda uma outra modalidade da invenção. Como mostrado na figura 14, o sistema do mecanismo de confiança 1400 inclui múltiplos mecanismos de confiança 1405, 1410, 1415 e 1420. De acordo com uma modalidade, cada um dos mecanismos de confiança 1405, 1410, 1415 e 1420 compreende alguns ou todos os elementos do mecanismo de confiança 1110 descrito com referên- cia às figuras 1-8. De acordo com essa modalidade, quando os miniaplicati- vos no lado do cliente do sistema do usuário 105, do sistema do fornecedor 120, ou da autoridade do certificado 115 se comunicam com o sistema do mecanismo de confiança 1400, essas comunicações são enviadas para o endereço IP de cada um dos mecanismos de confiança 1405 a 1420. Além do que, cada mecanismo de transação de cada um dos mecanismos de con- fiança 1405, 1410, 1415 e 1420 se comporta similar ao mecanismo de tran- sação 1321 do mecanismo de confiança 1305 descrito com referência à figu- ra 13. Por exemplo, durante um processo de autenticação, cada mecanismo de transação de cada um dos mecanismos de confiança 1405, 1410, 1415 e 1420 transmite os dados de autenticação atuais para seus mecanismos de autenticação respectivos e transmite uma solicitação para montar os dados randomizados armazenados em cada um dos depositários de cada um dos mecanismos de confiança 1405 a 1420. A figura 14 não ilustra todas essas comunicações, já que a ilustração se tornaria muito complexa. Continuando com o processo de autenticação, cada um dos depositários então comunica sua porção dos dados randomizados para cada um dos mecanismos de au- tenticação de cada um dos mecanismos de confiança 1405 a 1420. Cada um dos mecanismos de autenticação de cada um dos mecanismos de confiança utiliza seu comparador para determinar se os dados de autenticação atuais combinam com os dados de autenticação da inscrição providos pelos depo- sitários de cada um dos mecanismos de confiança 1405 a 1420. De acordo com essa modalidade, o resultado da comparação por cada um dos meca- nismos de autenticação é então transmitido para um módulo de redundância dos outros três mecanismos de confiança. Por exemplo, o resultado do me- canismo de autenticação do mecanismo de confiança 1405 é transmitido para os módulos de redundância dos mecanismos de confiança 1410, 1415 e 1420. Assim, o módulo de redundância do mecanismo de confiança 1405 da mesma maneira recebe o resultado dos mecanismos de autenticação provenientes dos mecanismos de confiança 1410, 1415 e 1420.

A figura 15 ilustra um diagrama de blocos do módulo de redun- dância da figura 14. O módulo de redundância compreende um comparador configurado para receber o resultado da autenticação de três mecanismos de autenticação e transmitir esse resultado para o mecanismo de transação do quarto mecanismo de confiança. O comparador compara o resultado da autenticação dos três mecanismos de autenticação, e se dois dos resultados concordam, o comparador conclui que o resultado da autenticação deve combinar com esse dos dois mecanismos de autenticação concordantes. Esse resultado é então transmitido de volta para o mecanismo de transação correspondendo com o mecanismo de confiança não associado com os três mecanismos de autenticação.

Com base no precedente, o módulo de redundância determina um resultado de autenticação a partir dos dados recebidos dos mecanismos de autenticação que estão, de preferência, geograficamente distantes do mecanismo de confiança desse módulo de redundância. Provendo tal fun- cionalidade de redundância, o sistema do mecanismo de confiança 1400 garante que um comprometimento do mecanismo de autenticação de um dos mecanismos de confiança 1405 a 1420 é insuficiente para comprometer o resultado da autenticação do módulo de redundância desse mecanismo de confiança particular. Um versado reconhecerá que a funcionalidade do mó- dulo de redundância do sistema do mecanismo de confiança 1400 pode também ser aplicada no mecanismo criptográfico de cada um dos mecanis- mos de confiança 1405 a 1420. Entretanto, tal comunicação do mecanismo criptográfico não foi mostrada na figura 14 para evitar complexidade. Além do mais, um versado reconhecerá que um amplo número de algoritmos de resolução de conflito de resultado de autenticação alternativos para o com- parador da figura 15 é adequado para uso na presente invenção.

De acordo com ainda uma outra modalidade da invenção, o sis- tema do mecanismo de confiança 1400 pode vantajosamente utilizar o mó- dulo de redundância durante etapas de comparação criptográfica. Por e- xemplo, um pouco ou toda a descrição do módulo de redundância preceden- te com referência às figuras 14 e 15 pode ser vantajosamente implementada durante uma comparação de prova de documentos providos por uma ou mais partes interessadas durante uma transação particular.

Embora a invenção precedente tenha sido descrita em termos de certas modalidades preferidas e alternativas, outras modalidades serão evidentes para aqueles versados na técnica a partir dessa descrição. Por exemplo, o mecanismo de confiança 110 pode emitir certificados de curto prazo, onde a chave criptográfica privada é liberada para o usuário por um período de tempo predeterminado. Por exemplo, padrões atuais de certifica- do incluem um campo de validade que pode ser ajustado para expirar depois de uma duração de tempo predeterminada. Assim, o mecanismo de confian- ça 110 pode liberar uma chave privada para um usuário onde a chave priva- da seria válida por, por exemplo, 24 horas. De acordo com uma tal modali- dade, o mecanismo de confiança 110 pode emitir vantajosamente um novo par de chaves criptográficas a ser associado com um usuário particular e a seguir liberar a chave privada do novo par de chaves criptográficas. Em se- guida, depois que a chave criptográfica privada é liberada, o mecanismo de confiança 110 imediatamente expira qualquer uso válido interno de tal chave privada, como se ela não fosse atingível pelo mecanismo de confiança 110.

Além disso, um versado reconhecerá que o sistema criptográfico 100 ou o mecanismo de confiança 110 pode incluir a capacidade de reco- nhecer qualquer tipo de dispositivos, tais como, mas não-limitados a, um laptop, um telefone celular, uma rede, um dispositivo biométrico ou similares. De acordo com uma modalidade, tal reconhecimento pode vir de dados su- pridos na solicitação por um serviço particular, tal como, uma solicitação por autenticação que leva ao acesso ou uso, uma solicitação por funcionalidade criptográfica ou similares. De acordo com uma modalidade, a solicitação precedente pode incluir um identificador de dispositivo único, tal como, por exemplo, um ID do processador. Alternativamente, a solicitação pode incluir dados em um formato de dados reconhecível particular. Por exemplo, telefo- nes móveis e de satélite freqüentemente não incluem a potência de proces- samento para certificados de criptografia pesada X509.v3 completa e, por- tanto, não os solicita. De acordo com essa modalidade, o mecanismo de confiança 110 pode reconhecer o tipo do formato de dados apresentado e responder somente em algo equivalente.

Em um aspecto adicional do sistema descrito aqui acima, a au- tenticação sensível ao contexto pode ser provida usando várias técnicas como será descrito abaixo. A autenticação sensível ao contexto, por exem- plo, como mostrado na figura 16, provê a possibilidade de avaliar não so- mente os dados reais que são enviados pelo usuário quando tentando se autenticar, mas também as circunstâncias que circundam a geração e a en- trega desses dados. As técnicas podem também suportar a arbitragem de confiança específica da transação entre o usuário e o mecanismo de confi- ança 110 ou entre o fornecedor e o mecanismo de confiança 110, como será descrito abaixo.

Cortio discutido acima, a autenticação é o processo de provar que um usuário é quem ele diz que é. De forma geral, a autenticação exige demonstrar algum fato para uma autoridade de autenticação. O mecanismo de confiança 110 da presente invenção representa a autoridade para a qual um usuário deve se autenticar. O usuário deve demonstrar para o mecanis- mo de confiança 110 que ele é quem ele diz ser: sabendo alguma coisa que somente o usuário deve saber (autenticação com base em conhecimento), tendo alguma coisa que somente o usuário deve ter (autenticação com base em ficha) ou sendo alguma coisa que somente o usuário deve ser (autenti- cação com base no biométrico).

Exemplos de autenticação com base no conhecimento incluem sem limitação uma senha, número PIN ou combinação de fechadura. Exem- plos de autenticação com base em ficha incluem sem limitação uma chave de casa, um cartão de crédito físico, uma carteira de motorista ou um núme- ro de telefone particular. Os exemplos de autenticação com base no biomé- tricô incluem sem limitação uma impressão digital, análise da escrita, varre- dura facial, varredura da mão, varredura da orelha, varredura da íris, padrão vascular, DNA, uma análise de voz ou uma varredura de retina.

Cada tipo de autenticação tem vantagens e desvantagens parti- culares, e cada um provê um nível de segurança diferente. Por exemplo, geralmente é mais difícil criar uma falsa impressão digital que combina com a de outra pessoa do que é escutar por acaso a senha de alguém e repeti-la. Cada tipo de autenticação também requer que um tipo diferente de dados seja conhecido para a autoridade de autenticação a fim de verificar uma pessoa usando essa forma de autenticação.

Como usado aqui, "autenticação" se referirá amplamente ao processo geral de verificação da identidade de uma pessoa de modo a veri- ficar se ele é quem ele diz que é. Uma "técnica de autenticação" se referirá a um tipo particular de autenticação com base em um pedaço particular de conhecimento, ficha física ou leitura biométrica. "Dados de autenticação" se referem à informação que é enviada para ou de outra forma demonstrada para uma autoridade de autenticação a fim de estabelecer a identidade. "Dados de inscrição" se referirão aos dados que são inicialmente submetidos a uma autoridade de autenticação a fim de estabelecer uma linha de refe- rência para comparação com os dados de autenticação. Uma "instância de autenticação" se referirá aos dados associados com uma tentativa de auten- ticação por uma técnica de autenticação.

Os protocolos internos e as comunicações envolvidas no pro- cesso de autenticação de um usuário são descritos com referência à figura 10 acima. A parte desse processo dentro do qual a autenticação sensível ao contexto acontece ocorre dentro da etapa de comparação mostrada como etapa 1045 da figura 10. Essa etapa acontece dentro do mecanismo de au- tenticação 215 e envolve montar os dados de inscrição 410 recuperados do depositário 210 e comparar os dados de autenticação providos pelo usuário para ele. Uma modalidade particular desse processo é mostrada na figura 16 e descrita abaixo.

Os dados atuais de autenticação providos pelo usuário e os da- dos de inscrição recuperados do depositário 210 são recebidos pelo meca- nismo de autenticação 215 na etapa 1600 da figura 16. Ambos esses con- juntos de dados podem conter dados que são relacionados com técnicas separadas de autenticação. O mecanismo de autenticação 215 separa os dados de autenticação associados com cada instância de autenticação indi- vidual na etapa 1605. Isso é necessário de modo que os dados de autenti- cação sejam comparados com o subconjunto apropriado dos dados de ins- crição para o usuário (por exemplo, os dados de autenticação da impressão digital devem ser comparados com os dados da inscrição da impressão digi- tal, em vez de os dados de inscrição da senha).

De forma geral, a autenticação de um usuário envolve uma ou mais instâncias de autenticação individuais, dependendo de quais técnicas de autenticação estão disponíveis para o usuário. Esses métodos são limita- dos pelos dados de inscrição que foram providos pelo usuário durante o seu processo de inscrição (se o usuário não proveu uma varredura de retina quando se inscrevendo, ele não será capaz de se autenticar usando uma varredura de retina), bem como o meio que pode estar atualmente disponível para o usuário (por exemplo, se o usuário não tem uma leitora de impressão digital na sua localização atual, a autenticação por impressão digital não se- rá prática). Em alguns casos, uma única instância de autenticação pode ser suficiente para autenticar um usuário, entretanto, em certas circunstâncias, uma combinação de múltiplas instâncias de autenticação pode ser usada a fim de autenticar com mais confiança um usuário para uma transação parti- cular.

Cada instância de autenticação consiste de dados relacionados com uma técnica de autenticação particular (por exemplo, impressão digital, senha, cartão inteligente, etc.) e as circunstâncias que circundam a captura e a entrega dos dados para essa técnica particular. Por exemplo, uma ins- tância particular de tentativa de autenticação via senha gerará não somente os dados relacionados com a própria senha, mas também dados circunstan- ciais, conhecidos como "metadados", relacionados com essa tentativa de senha. Esses dados circunstanciais incluem informação tal como: a hora na qual a instância de autenticação particular aconteceu, o endereço de rede de onde a informação de autenticação foi entregue, bem como qualquer outra informação como é conhecido para aqueles versados na técnica que pode ser determinada sobre a origem dos dados de autenticação (o tipo de cone- xão, o número serial do processador, etc.).

Em muitos casos, somente uma pequena quantidade de meta- dados circunstanciais ficará disponível. Por exemplo, se o usuário está loca- lizado em uma rede que usa proxies ou translação de endereço de rede ou uma outra técnica que mascara o endereço do computador de origem, so- mente o endereço do proxy ou roteador pode ser determinado. Similarmente, em muitos casos, informação, ta! como o número serial do processador, não ficará disponível por causa das limitações do hardware ou sistema operacio- nal sendo usado, desativação de tais aspectos pelo operador do sistema ou outras limitações da conexão entre o sistema do usuário e o mecanismo de confiança 110.

Como mostrado na figura 16, depois que as instâncias de auten- ticação individuais representadas dentro dos dados de autenticação são ex- traídas e separadas na etapa 1605, o mecanismo de autenticação 215 avalia cada instância com relação a sua confiabilidade na indicação de que o usuá- rio é quem ele reivindica ser. A confiabilidade para uma única instância de autenticação geralmente será determinada com base em vários fatores. Es- ses podem ser agrupados como fatores relacionados com a confiabilidade associada com a técnica de autenticação, que são avaliadas na etapa 1610, e fatores relacionados com a confiabilidade dos dados de autenticação parti- culares providos, que são avaliados na etapa 1815. O primeiro grupo inclui sem limitação a confiabilidade inerente da técnica de autenticação sendo usada, e a confiabilidade dos dados da inscrição sendo usados com esse método. O segundo grupo inclui sem limitação o grau de combinação entre os dados da inscrição e os dados providos com a instância de autenticação e os metadados associados com essa instância de autenticação. Cada um desses fatores pode variar independentemente dos outros.

A confiabilidade inerente de uma técnica de autenticação é ba- seada em quanto é difícil para um impostor prover dados corretos de outra pessoa, bem como as taxas de erro gerais para a técnica de autenticação. Para métodos de autenticação com base em senhas e conhecimento, essa confiabilidade é, com freqüência, razoavelmente pequena porque não existe nada que impeça que alguém revele sua senha para uma outra pessoa e que essa segunda pessoa use essa senha. Até mesmo um sistema com ba- se em conhecimento mais complexo pode ter somente confiabilidade mode- rada desde que o conhecimento pode ser transferido de pessoa para pessoa de maneira razoavelmente fácil. A autenticação com base em ficha, tal como tendo um cartão inteligente apropriado ou usando um terminal particular para executar a autenticação, é similarmente de baixa confiabilidade usada por si própria, desde que não existe garantia que a pessoa certa esteja na posse da ficha apropriada.

Entretanto, as técnicas biométricas são mais inerentemente con- fiáveis porque é geralmente difícil prover outra pessoa com a capacidade de usar suas impressões digitais em uma maneira conveniente, mesmo inten- cionalmente. Pelo fato de que a subversão das técnicas de autenticação bi- ométricas é mais difícil, a confiabilidade inerente dos métodos biométricos é geralmente mais alta do que essa das técnicas de autenticação com base puramente em conhecimento ou ficha. Entretanto, até mesmo as técnicas biométricas podem ter algumas ocasiões nas quais uma falsa aceitação ou falsa rejeição é gerada. Essas ocorrências podem ser refletidas por confiabi- Iidades diferentes para implementações diferentes da mesma técnica biomé- trica. Por exemplo, um sistema de combinação de impressão digital provido por uma companhia pode prover uma confiabilidade mais alta do que um provido por uma companhia diferente porque uma usa ótica de qualidade superior ou uma melhor resolução de varredura ou algum outro aperfeiçoa- mento que reduz a ocorrência de falsas aceitações ou falsas rejeições.

Observe que essa confiabilidade pode ser expressa em manei- ras diferentes. A confiabilidade é expressa desejavelmente em alguma mé- trica que pode ser usada pela heurística 530 e algoritmos do mecanismo de autenticação 215 para calcular o nível de confiança de cada autenticação. Um modo preferido de expressar essas confiabilidades é como uma porcen- tagem ou fração. Por exemplo, impressões digitais poderiam ser atribuídas com uma confiabilidade inerente de 97%, enquanto as senhas poderiam so- mente ser atribuídas com uma confiabilidade inerente de 50%. Esses versa- dos na técnica reconhecerão que esses valores particulares são meramente exemplares e podem variar entre implementações específicas.

O segundo fator para o qual a confiabilidade deve ser avaliada é a confiabilidade da inscrição. Essa é parte do processo da "inscrição gradu- ada" citada acima. Esse fator de confiabilidade reflete a confiabilidade da identificação provida durante o processo de inscrição inicial. Por exemplo, se o indivíduo inicialmente se inscreve em uma maneira onde eles fisicamente produzem evidências da sua identidade para um notário ou outro oficial pú- blico, e os dados de inscrição são gravados nesse momento e reconhecidos, os dados serão mais confiáveis do que os dados que são providos através de uma rede durante a inscrição e somente garantidos por uma assinatura digital ou outra informação que não é verdadeiramente restrita ao indivíduo.

Outras técnicas de inscrição com níveis variados de confiabili- dade incluem sem limitação: a inscrição em um escritório físico do operador do mecanismo de confiança 110, a inscrição no local de trabalho de um usu- ário, a inscrição em um correio ou um escritório de passaportes, a inscrição através de uma parte interessada afiliada ou de confiança ao operador do mecanismo de confiança 110, inscrição anônima ou pseudônima na qual a identidade inscrita ainda não está identificada com um indivíduo real particu- lar, bem como tais outros recursos como são conhecidos na técnica.

Esses fatores refletem a confiança entre o mecanismo de confi- ança 110 e a fonte de identificação provida durante o processo de inscrição. Por exemplo, se a inscrição é executada associada com um empregador durante o processo inicial de fornecimento da evidência da identidade, essa informação pode ser considerada extremamente confiável para finalidades dentro da companhia, mas podem ser consideradas de menor grau de confi- ança por uma agência do governo ou por um competidor. Portanto, meca- nismos de confiança operados por cada uma dessas outras organizações podem atribuir níveis diferentes de confiabilidade para essa inscrição.

Similarmente, dados adicionais que são submetidos através de uma rede, mas que são autenticados por outros dados de confiança providos durante uma inscrição prévia com o mesmo mecanismo de confiança 110 podem ser considerados tão confiáveis quanto os dados da inscrição origi- nais foram, mesmo embora os últimos dados tenham sido submetidos atra- vés de uma rede aberta. Em tais circunstâncias, um reconhecimento subse- qüente aumentará efetivamente o nível de confiabilidade associado com os dados de inscrição originais. Dessa maneira, por exemplo, uma inscrição anônima ou pseudônima pode então ser elevada para uma inscrição comple- ta demonstrando para algum oficial de inscrição a identidade do indivíduo que combina com os dados inscritos.

Os fatores de confiabilidade discutidos acima são geralmente valores que podem ser determinados antes de qualquer instância de autenti- cação particular. Isso é porque eles são baseados na inscrição e na técnica, em vez de na autenticação real. Em uma modalidade, a etapa de gerar con- fiabilidade com base nesses fatores envolve procurar valores previamente determinados pára essa técnica de autenticação particular e os dados de inscrição do usuário. Em um aspecto adicional de uma modalidade vantajosa da presente invenção, tais confiabilidades podem ser incluídas com os pró- prios dados de inscrição. Dessa maneira, esses fatores são automaticamen- te passados para o mecanismo de autenticação 215 junto com os dados de inscrição enviados do depositário 210.

Embora esses fatores possam geralmente ser determinados an- tes de qualquer instância de autenticação individual, eles ainda têm um efei- to em cada instância de autenticação que usa essa técnica particular de au- tenticação para esse usuário. Além do mais, embora os valores possam mu- dar com o tempo (por exemplo, se o usuário se inscreve novamente em um modo mais confiável), eles não são dependentes dos próprios dados de au- tenticação. Em contraste, os fatores de confiabilidade associados com os dados de uma única instância específica podem variar em cada ocasião. Esses fatores, como discutido abaixo, devem ser avaliados para cada nova autenticação a fim de gerar contagens de confiabilidade na etapa 1815.

A confiabilidade dos dados de autenticação reflete a combina- ção entre os dados providos pelo usuário em uma instância de autenticação particular e os dados providos durante a inscrição de autenticação. Essa é a questão fundamental de se os dados de autenticação combinam com os da- dos da inscrição para o indivíduo que o usuário está reivindicando ser. Nor- malmente, quando os dados não combinam, o usuário é considerado como não sendo autenticado de maneira bem-sucedida e a autenticação falha. A maneira na qual isso é avaliado pode mudar dependendo da técnica de au- tenticação usada. A comparação de tais dados é executada pela função do comparador 515 do mecanismo de autenticação 215 como mostrado na figu- ra 5.

Por exemplo, combinações de senhas são geralmente avaliadas em um modo binário. Em outras palavras, uma senha é uma combinação perfeita ou uma combinação falha. Geralmente não é desejável aceitar como uma combinação até mesmo parcial uma senha que está próxima da senha correta se ela não está exatamente correta. Portanto, quando avaliando uma autenticação de senha, a confiabilidade da autenticação retornada pelo comparador 515 é tipicamente 100% (correta) ou 0% (errada), sem possibili- dade de valores intermediários.

Regras similares a essas para as senhas são geralmente apli- cadas em métodos de autenticação com base em ficha, tal como cartões inteligentes. Isso é porque ter um cartão inteligente que tem um identificador similar ou que é similar ao correto é ainda tão errado quanto ter qualquer outra ficha incorreta. Portanto, as fichas tendem também a ser autenticado- res binários: um usuário tem a ficha correta ou não tem.

Entretanto, certos tipos de dados de autenticação, tal como questionários e biométricos, não são geralmente autenticadores binários. Por exemplo, uma impressão digital pode combinar com uma impressão digi- tal de referência em graus variados. Até alguma extensão, isso pode ser de- vido a variações na qualidade dos dados capturados durante a inscrição ini- cial ou em autenticações subseqüentes. (Uma impressão digital pode estar suja ou uma pessoa pode ter uma cicatriz ou queimadura ainda em cura em um dedo particular). Em outros casos os dados podem combinar menos do que perfeitamente porque a própria informação está um tanto variável e com base na combinação padrão. (Uma análise de voz pode parecer próxima, mas não muito certa por causa do ruído de fundo, ou a acústica do ambiente no qual a voz é gravada ou porque a pessoa está resfriada). Finalmente, nas situações onde grandes quantidades de dados estão sendo comparadas, pode ser simplesmente o caso em que muita parte dos dados combina bem, mas algumas não. (Um questionário de dez perguntas pode ter resultado em oito respostas corretas à perguntas pessoais, mas duas respostas incorre- tas). Por qualquer uma dessas razões, a combinação entre os dados de ins- crição e os dados para uma instância de autenticação particular podem ser desejavelmente atribuídos com um valor de combinação parcial pelo compa- rador 515. Dessa maneira, a impressão digital poderia ser dita como sendo uma combinação de 85%, a impressão de voz uma combinação de 65% e o questionário uma combinação de 80%, por exemplo.

Essa medida (grau da combinação) produzida pelo comparador 515 é o fator que representa a questão básica de se uma autenticação está correta ou não. Entretanto, como discutido acima, esse é somente um dos fatores que pode ser usado na determinação da confiabilidade de uma dada instância de autenticação. Observe também que até mesmo embora uma comparação até algum grau parcial possa ser determinada, que finalmente, pode ser desejável prover um resultado binário com base em uma combina- ção parcial. Em um modo de operação alternado, é também possível tratar combinações parciais como binárias, isto é, combinações perfeitas (100%) ou falhas (0%), com base em se o grau de combinação passa ou não de um nível limiar particular de combinação. Um tal processo pode ser usado para prover um nível simples de passagem/falha da combinação para sistemas que de outra maneira produziriam combinações parciais.

Um outro fator a ser considerado na avaliação da confiabilidade de uma dada instância de autenticação se refere às circunstâncias sob as quais os dados de autenticação para essa instância particular são providos. Como discutido acima, as circunstâncias se referem aos metadados associ- ados com uma instância de autenticação particular. Isso pode incluir sem limitação tal informação como: o endereço de rede do autenticador, até a extensão que isso pode ser determinado, a hora da autenticação, o modo de transmissão dos dados de autenticação (linha telefônica, celular, rede, etc.) e o número serial do sistema do autenticador.

Esses fatores podem ser usados para produzir um perfil do tipo de autenticação que é normalmente requerido pelo usuário. A seguir, essa informação pode ser usada para avaliar a confiabilidade em pelo menos du- as maneiras. Uma maneira é considerar se o usuário está solicitando auten- ticação em uma maneira que é consistente com o perfil normal de autentica- ção por esse usuário. Se o usuário normalmente faz solicitações de autenti- cação de um endereço de rede durante os dias de negócios (quando ela es- tá no trabalho) e de um endereço de rede diferente durante as noites ou fi- nais de semanas (quando ela está em casa), uma autenticação que ocorre do endereço residencial durante o dia de negócios é menos confiável porque ela está fora do perfil de autenticação normal. Similarmente, se o usuário normalmente se autentica usando uma biométrica de impressão digital e à noite, uma autenticação que se origina durante o dia usando somente uma senha é menos confiável.

Uma maneira adicional na qual os metadados circunstanciais podem ser usados para avaliar a confiabilidade de uma instância de autenti- cação é determinar quanta confirmação a circunstância provê que o autenti- cador é o indivíduo que ele reivindica ser. Por exemplo, se a autenticação vem de um sistema com um número serial conhecido como sendo associado com o usuário, esse é um bom indicador circunstancial que o usuário é quem ele reivindica ser. Inversamente, se a autenticação está vindo de um endereço de rede que é conhecido como estando em Los Angeles quando o usuário é conhecido como residente em Londres, essa é uma indicação que essa autenticação é menos confiável com base nas suas circunstâncias.

É também possível que um cookie ou outro dado eletrônico pos- sa ser colocado no sistema sendo usado por um usuário quando eles intera- gem com um sistema de fornecedor ou com o mecanismo de confiança 110. Esses dados são escritos no armazenamento do sistema do usuário e po- dem conter uma identificação que pode ser lida por um navegador da Web ou outro software no sistema do usuário. Se esses dados têm autorização para residir no sistema do usuário entre sessões (um "cookie persistente"), eles podem ser enviados com os dados de autenticação como evidência a- dicional do uso passado desse sistema durante a autenticação de um usuá- rio particular. Na realidade, os metadados de uma dada instância, particu- larmente um cookie persistente, podem formar uma espécie de autenticador com base em ficha por si próprios.

Depois que os fatores de confiabilidade apropriados com base na técnica e dados da instância de autenticação são gerados como descrito acima nas etapas 1610 e 1615 respectivamente, eles são usados para pro- duzir uma confiabilidade geral para a instância de autenticação provida na etapa 1620. Um modo de fazer isso é simplesmente expressar cada confia- bilidade como uma porcentagem e a seguir multiplicá-las.

Por exemplo, suponha que os dados de autenticação estão sen- do enviados de um endereço de rede conhecido como sendo o computador residencial do usuário completamente de acordo com o perfil de autentica- ção passado (100%) do usuário, e a técnica sendo usada é a identificação da impressão digital (97%), e os dados de impressão digital iniciais foram alardeados através do empregador do usuário com o mecanismo de confi- ança 110 (90%) e a combinação entre os dados de autenticação e o modelo de impressão digital original nos dados da inscrição é muito boa (99%). A confiabilidade geral dessa instância de autenticação poderia então ser calcu- lada como o produto dessas confiabilidades: 100% * 97% * 90% * 99% - con- fiabilidade de 86,4%.

Essa confiabilidade calculada representa a confiabilidade de uma única instância de autenticação. A confiabilidade geral de uma única instância de autenticação pode também ser calculada usando técnicas que tratam os fatores de confiabilidade diferentes de maneira diferente, por e- xemplo, usando fórmulas onde pesos diferentes são atribuídos para cada fator de confiabilidade. Além do mais, aqueles versados na técnica reconhe- cerão que os valores reais usados podem representar valores diferentes de porcentagens e podem usar sistemas não aritméticos. Uma modalidade po- de incluir um módulo usado por um solicitante de autenticação para estabe- lecer os pesos para cada fator e os algoritmos usados no estabelecimento da confiabilidade geral da instância de autenticação.

O mecanismo de autenticação 215 pode usar as técnicas acima e variações dessas para determinar a confiabilidade de uma única instância de autenticação, indicada como etapa 1620. Entretanto, pode ser útil em muitas situações de autenticação que múltiplas instâncias de autenticação sejam providas ao mesmo tempo. Por exemplo, enquanto tentando se auten- ticar usando o sistema da presente invenção, um usuário pode prover uma identificação do usuário, dados de autenticação de impressão digital, um cartão inteligente e uma senha. Em um tal caso, três instâncias de autenti- cação independentes estão sendo providas para o mecanismo de confiança 110 para avaliação. Prosseguindo para a etapa 1625, se o mecanismo de autenticação 215 determina que os dados providos pelo usuário incluem mais do que uma instância de autenticação, então cada instância por sua vez será selecionada como mostrado na etapa 1630 e avaliada como descri- to acima nas etapas 1610, 1615 e 1620.

Observe que muitos dos fatores de confiabilidade discutidos po- dem variar de uma dessas instâncias para outra. Por exemplo, a confiabili- dade inerente dessas técnicas é provável de ser diferente, bem como o grau de combinação provido entre os dados de autenticação e os dados da inscri- ção. Além do mais, o usuário pode ter provido dados de inscrição em tempos diferentes e sob circunstâncias diferentes para cada uma dessas técnicas,, provendo confiabilidades de inscrição diferentes para cada uma dessas ins- tâncias também. Finalmente, mesmo embora as circunstâncias sob as quais os dados para cada uma dessas instâncias estão sendo submetidos sejam as mesmas, o uso de tais técnicas pode se ajustar, cada uma, no perfil do usuário diferentemente e assim pode ser atribuído com confiabilidades cir- cunstanciais diferentes. (Por exemplo, o usuário pode usar normalmente a sua senha e impressão digital, mas não o seu cartão inteligente.).

Como um resultado, a confiabilidade final para cada uma dessas instâncias de autenticação pode ser diferente uma da outra. Entretanto, u- sando múltiplas instâncias juntas, o nível de confiança geral para a autenti- cação tenderá a aumentar.

Depois que o mecanismo de autenticação executou as etapas 1610 a 1620 para todas as instâncias de autenticação providas nos dados de autenticação, a confiabilidade de cada instância é usada na etapa 1635 para avaliar o nível de confiança da autenticação geral. Esse processo de combinação das confiabilidades de instância de autenticação individuais no nível de confiança de autenticação pode ser modelado por vários métodos relacionados com as confiabilidades individuais produzidas, e pode também tratar da interação particular entre algumas dessas técnicas de autenticação. (Por exemplo, múltiplos sistemas com base em conhecimento tal como se- nhas podem produzir menos confiança do que uma única senha e até mes- mo uma biométrica razoavelmente fraca, tal como uma análise de voz bási- ca).

Um meio no qual o mecanismo de autenticação 215 pode com- binar as confiabilidades de múltiplas instâncias de autenticação simultâneas para gerar um nível de confiança final é multiplicar a não confiabilidade de cada instância para chegar a uma não confiabilidade total. A não confiabili- dade é geralmente a porcentagem complementar da confiabilidade. Por e- xemplo, uma técnica que é 84% confiável é 16% não confiável. As três ins- tâncias de autenticação descritas acima (impressão digital, cartão inteligen- te, senha) que produzem confiabilidades de 86%, 75% e 72% teriam não confiabilidades correspondentes de (100-86)%, (100-75)% e (100-72)%, ou. 14%, 25% e 28%, respectivamente. Pela multiplicação dessas não confiabi- lidades, obteve-se uma não confiabilidade cumulativa de 14% * 25% * 28% - .98% de não confiabilidade, que corresponde a uma confiabilidade de 99,02%.

Em um modo de operação adicional, fatores adicionais e heurís- tica 530 podem ser aplicados dentro do mecanismo de autenticação 215 pa- ra considerar a interdependência de várias técnicas de autenticação. Por exemplo, se uma pessoa tem acesso não autorizado a um computador resi- dencial particular, eles provavelmente têm acesso à linha telefônica nesse endereço também. Portanto, autenticação com base em um número de tele- fone de origem bem como sobre o número serial do sistema de autenticação não adiciona muito para a confiança geral na autenticação. Entretanto, a au- tenticação com base no conhecimento é amplamente independente da au- tenticação com base em ficha (isto é, se alguém rouba o seu telefone celular ou chaves, eles não são mais prováveis de saber o seu PIN ou senha do que se eles não tivessem).

Além do mais, fornecedores diferentes ou outros solicitantes de autenticação podem desejar pesar diferentes aspectos da autenticação dife- rentemente. Isso pode incluir o uso de fatores de pesagem separados ou algoritmos usados no cálculo da confiabilidade das instâncias individuais, bem como o uso de meios diferentes para avaliar eventos de autenticação com múltiplas instâncias.

Por exemplo, fornecedores para certos tipos de transações, por exemplo, sistemas de e-mail incorporados, podem desejar autenticar prima- riamente com base na heurística e outros dados circunstanciais por padrão. Portanto, eles podem aplicar altos pesos a fatores relacionados com os me- tadados e outra informação relacionada com o perfil associada com as cir- cunstâncias que circundam os eventos de autenticação. Essa disposição poderia ser usada para facilitar a carga sobre usuários durante horas de o- peração normais, não requerendo mais do usuário do que que ele esteja conectado na máquina correta durante as horas de trabalho. Entretanto, um outro fornecedor pode pesar autenticações que vêm de uma técnica particu- lar mais pesadamente, por exemplo, combinação de impressão digital, por causa de uma decisão de diretriz que uma tal técnica é mais adequada para a autenticação para as finalidades do fornecedor particular.

Tais pesos variados podem ser definidos pelo solicitante de au- tenticação na geração da solicitação de autenticação e enviados para o me- canismo de confiança 110 com a solicitação de autenticação em um modo de operação. Tais opções poderiam também ser estabelecidas como prefe- rências durante um processo de inscrição inicial para o solicitante de auten- ticação e armazenadas dentro do mecanismo de autenticação em um outro modo de operação.

Depois que o mecanismo de autenticação 215 produz um nível de confiança de autenticação para os dados de autenticação providos, esse nível de confiança é usado para completar a solicitação de autenticação na etapa 1640 e essa informação é enviada do mecanismo de autenticação 215 para o mecanismo de transação 205 para inclusão em uma mensagem para o solicitante da autenticação.

O processo descrito acima é meramente exemplar, e aqueles versados na técnica reconhecerão que as etapas não precisam ser executa- das na ordem mostrada ou que somente é desejado executar certas das e- tapas, ou que uma variedade de combinações de etapas pode ser desejada. Além do mais, certas etapas, tal como a avaliação da confiabilidade de cada instância de autenticação provida, podem ser executadas em paralelo uma com a outra se as circunstâncias permitem.

Em um aspecto adicional dessa invenção, um método é provido para acomodar condições quando o nível de confiança da autenticação pro- duzido pelo processo descrito acima falha em satisfazer o nível de confiança requerido do fornecedor ou outra parte interessada requerendo a autentica- ção. Em circunstâncias tal como essas onde uma lacuna existe entre o nível de confiança provido e o nível de confiança desejado, o operador do meca- nismo de confiança 110 fica em uma posição para prover oportunidades pa- ra que uma ou ambas as partes interessadas provejam dados alternados ou exigências de modo a fechar essa lacuna de confiança. Esse processo será citado como "arbitragem de confiança" aqui.

A arbitragem de confiança pode acontecer dentro de uma estru- tura de autenticação criptográfica como descrito acima com referência às figuras 10 e 11. Como mostrado nelas, um fornecedor ou outra parte interes- sada solicitará autenticação de um usuário particular em associação com uma transação particular. Em uma circunstância, o fornecedor simplesmente solicita uma autenticação, positiva ou negativa, e depois de receber dados apropriados do usuário, o mecanismo de confiança 110 proverá uma tal au- tenticação binária. Nas circunstâncias tal como essas, o grau de confiança requerido a fim de garantir uma autenticação positiva é determinado com base nas preferências estabelecidas dentro do mecanismo de confiança 110.

Entretanto, é também possível que o fornecedor possa solicitar um nível particular de confiança a fim de completar uma transação particular. Esse nível requerido pode ser incluído com a solicitação de autenticação (por exemplo, autenticar esse usuário para 98% de confiança) ou pode ser determinado pelo mecanismo de confiança 110 com base em outros fatores associados com a transação (isto é, autenticar esse usuário como apropria- do para essa transação). Um tal fator poderia ser o valor econômico da tran- sação. Para transações que têm maior valor econômico, um grau maior de confiança pode ser requerido. Similarmente, para transações com altos graus de risco, um alto grau de confiança pode ser requerido. Inversamente, para transações que são de baixo risco ou de baixo valor, níveis de confian- ça menores podem ser requeridos pelo fornecedor ou outro solicitante de autenticação.

O processo de arbitragem de confiança ocorre entre as etapas de recepção dos dados de autenticação do mecanismo de confiança 110 na etapa 1050 da figura 10 e o retorno de um resultado de autenticação para o fornecedor na etapa 1055 da figura 10. Entre essas etapas, o processo que leva à avaliação dos níveis de confiança e à arbitragem potencial da confi- ança ocorre como mostrado na figura 17. Nas circunstâncias onde a autenti- cação binária simples é executada, o processo mostrado na figura 17 reduz para ter o mecanismo de transação 205 diretamente comparando os dados de autenticação providos com os dados da inscrição para o usuário identifi- cado como discutido acima com referência à figura 10, indicando qualquer diferença como uma autenticação negativa.

Como mostrado na figura 17, a primeira etapa depois de receber os dados na etapa 1050 é para o mecanismo de transação 205 determinar o nível de confiança que é requerido para uma autenticação positiva para essa transação particular na etapa 1710. Essa etapa pode ser executada por um de vários métodos diferentes. O nível de confiança requerido pode ser espe- cificado para o mecanismo de confiança 110 pelo solicitante de autenticação no momento quando a solicitação de autenticação é feita. O solicitante de autenticação pode também estabelecer uma preferência antecipadamente que é armazenada dentro do depositário 210 ou outro armazenamento que fica acessível pelo mecanismo de transação 205. Essa preferência pode en- tão ser lida e usada toda vez que uma solicitação de autenticação é feita por esse solicitante de autenticação. A preferência pode também estar associa- da com um usuário particular como uma medida de segurança tal que um nível particular de confiança é sempre requerido a fim de autenticar esse usuário, a preferência do usuário sendo armazenada no depositário 210 ou outro meio de armazenamento acessível pelo mecanismo de transação 205. O nível requerido pode também ser derivado pelo mecanismo de transação 205 ou mecanismo de autenticação 215 com base na informação provida na solicitação de autenticação, tal como o valor e o nível de risco da transação a ser autenticada.

Em um modo de operação, um módulo de gerenciamento de di- retriz ou outro software que é usado quando gerando a solicitação de auten- ticação é usado para especificar o grau requerido de confiança para a auten- ticação da transação. Isso pode ser usado para prover uma série de regras a seguir quando atribuindo o nível requerido de confiança com base nas dire- trizes que são especificadas dentro do módulo de gerenciamento de diretriz. Um modo de operação vantajoso é que um tal módulo seja incorporado com o servidor da web de um fornecedor a fim de determinar apropriadamente o nível requerido de confiança para transações iniciadas com o servidor da web do fornecedor. Dessa maneira, as solicitações de transação dos usuá- rios podem ser atribuídas com um nível de confiança requerido de acordo com as diretrizes do fornecedor e tal informação pode ser enviada para o mecanismo de confiança 110 junto com a solicitação de autenticação.

Esse nível de confiança requerido está correlacionado com o grau de certeza que o fornecedor deseja ter que o indivíduo autenticando é na realidade quem ele se identifica. Por exemplo, se a transação é uma on- de o fornecedor deseja um grau razoável de certeza porque mercadorias estão trocando de mãos, o fornecedor pode requerer um nível de confiança de 85%. Para a situação onde o fornecedor está meramente autenticando o usuário para permitir que ele veja conteúdo somente de membros ou privilé- gios de exercício em uma sala de bate-papo, o risco negativo pode ser pe- queno o suficiente que o fornecedor requeira somente um nível de 60% de confiança. Entretanto, para entrar em um contrato de produção com um valor de dezenas de milhares de dólares, o fornecedor pode requerer um nível de confiança de 99% ou mais.

Esse nível de confiança requerido representa uma métrica na qual o usuário deve se autenticar a fim de completar a transação. Se o nível de confiança requerido é 85%, por exemplo, o usuário deve prover autenti- cação para o mecanismo de confiança 110 suficiente para que o mecanismo de confiança 110 diga com 85% de confiança que o usuário é quem ele diz ser. Esse é o equilíbrio entre esse nível de confiança reqüerido e o nível de confiança da autenticação que produz uma autenticação positiva (para a sa- tisfação do fornecedor) ou uma possibilidade de arbitragem de confiança.

Como mostrado na figura 17, depois que o mecanismo de tran- sação 205 recebe o nível de confiança requerido, ele compara na etapa 1720 o nível de confiança requerido com o nível de confiança da autentica- ção que o mecanismo de autenticação 215 calculou para a autenticação a- tual (como discutido com referência à figura 16). Se o nível de confiança da autenticação é mais alto do que o nível de confiança requerido para a tran- sação na etapa 1730, então o processo se move para a etapa 1740 onde uma autenticação positiva para essa transação é produzida pelo mecanismo de transação 205. Uma mensagem para esse efeito será então inserida nos resultados de autenticação e retornada para o fornecedor pelo mecanismo de transação 205 como mostrado na etapa 1055 (ver figura 10).

Entretanto, se o nível de confiança da autenticação não satisfaz o nível de confiança requerido na etapa 1730, então uma lacuna de confian- ça existe para a autenticação atual e a arbitragem de confiança é conduzida na etapa 1750. A arbitragem de confiança é descrita mais completamente com referência à figura 18 abaixo. Esse processo como descrito abaixo a- contece dentro do mecanismo de transação 205 do mecanismo de confiança 110. Pelo fato de que nenhuma autenticação ou outras operações criptográ- ficas são necessárias para executar a arbitragem de confiança (além dessas requeridas para a comunicação SSL entre o mecanismo de transação 205 e outros componentes), o processo pode ser executado fora do mecanismo de autenticação 215. Entretanto, como será discutido abaixo, qualquer reavalia- ção dos dados de autenticação ou outros eventos criptográficos ou de auten- ticação exigirá que o mecanismo de transação 205 submeta novamente os dados apropriados para o mecanismo de autenticação 215. Aqueles versa- dos na técnica reconhecerão que o processo de arbitragem de confiança alternadamente poderia ser estruturado para acontecer parcial ou inteira- mente dentro do próprio mecanismo de autenticação 215.

Como mencionado acima, a arbitragem de confiança é um pro- cesso onde o mecanismo de confiança 110 media uma negociação entre o fornecedor e o usuário em uma tentativa para garantir uma autenticação po- sitiva onde apropriado. Como mostrado na etapa 1805, o mecanismo de transação 205 primeiro determina se a situação atual é ou não apropriada para a arbitragem de confiança. Isso pode ser determinado com base nas circunstâncias da autenticação, por exemplo, se essa autenticação já foi feita através de múltiplos ciclos de arbitragem, bem como sobre as preferências do fornecedor ou usuário, como será discutido mais abaixo.

Em tais circunstâncias onde a arbitragem não é possível, o pro- cesso prossegue para a etapa 1810 onde o mecanismo de transação 205 gera uma autenticação negativa e a seguir a insere nos resultados de auten- ticação que são enviados para o fornecedor na etapa 1055 (ver figura 10). Um limite que pode ser vantajosamente usado para impedir que as autenti- cações fiquem pendentes indefinidamente é estabelecer um período de in- tervalo da solicitação de autenticação inicial. Dessa maneira, qualquer tran- sação que não é positivamente autenticada dentro do limite de tempo não pode ter arbitragem adicional e é negativamente autenticada. Aqueles ver- sados na técnica reconhecerão que um tal limite de tempo pode variar de- pendendo das circunstâncias da transação e dos desejos do usuário e for- necedor. Limitações podem também ser colocadas no número de tentativas que podem ser feitas para prover uma autenticação bem-sucedida. Tais Iimi- tações podem ser manipuladas por um limitador de tentativa 535 como mos- trado na figura 5.

Se a arbitragem não é proibida na etapa 1805, o mecanismo de transação 205 então engajará na negociação com uma ou ambas as partes interessadas da transação. O mecanismo de transação 205 pode enviar uma mensagem para o usuário solicitando alguma forma de autenticação adicio- nal a fim de aumentar o nível de confiança da autenticação produzido como mostrado na etapa 1820. Na forma mais simples, isso pode simplesmente indicar que a autenticação foi insuficiente. Uma solicitação para produzir uma ou mais instâncias de autenticação adicionais para melhorar o nível de confiança geral da autenticação pode também ser enviada.

Se o usuário provê algumas instâncias de autenticação adicio- nais na etapa 1825, então o mecanismo de transação 205 adiciona essas instâncias de autenticação nos dados de autenticação para a transação e as envia para o mecanismo de autenticação 215 como mostrado na etapa 1015 (ver figura 10) e a autenticação é reavaliada com base em ambas as instân- cias de autenticação preexistentes para essa transação e as instâncias de autenticação recentemente providas.

Um tipo adicional de autenticação pode ser uma solicitação do mecanismo de confiança 110 para fazer alguma forma de contato de pessoa para pessoa entre o operador do mecanismo de confiança 110 (ou um asso- ciado de confiança) e o usuário, por exemplo, por chamada telefônica. Essa chamada telefônica ou outra autenticação sem computador pode ser usada para prover contato pessoal com o indivíduo e também para conduzir algu- ma forma de autenticação com base em questionário. Isso também pode proporcionar a oportunidade de verificar um número de telefone de origem e potencialmente uma análise de voz do usuário quando ele telefona. Mesmo se nenhum dado de autenticação adicional pode ser provido, o contexto adi- cional associado com o número de telefone do usuário pode melhorar a con- fiabilidade do contexto de autenticação. Quaisquer dados ou circunstâncias revisadas com base nessa chamada telefônica são alimentados para o me- canismo de confiança 110 para uso na consideração da solicitação de auten- ticação.

Adicionalmente, na etapa 1820 o mecanismo de confiança 110 pode prover uma oportunidade para o usuário adquirir seguro, efetivamente comprando uma autenticação mais segura. O operador do mecanismo de confiança 110 pode, algumas vezes, somente desejar tornar uma tal opção disponível se o nível de certeza da autenticação está acima de um certo li- miar para começar. Na realidade, esse seguro do lado do usuário é uma maneira para que o mecanismo de confiança 110 garanta o usuário quando a autenticação satisfaz o nível de confiança requerido normal do mecanismo de confiança 110 para autenticação, mas não satisfaz o nível de confiança requerido do fornecedor para essa transação. Dessa maneira, o usuário po- de ainda autenticar de maneira bem-sucedida para um nível muito alto como pode ser requerido pelo fornecedor, mesmo embora ele somente tenha ins- tâncias de autenticação que produzem certeza suficiente para o mecanismo de confiança 110.

Essa função do mecanismo de confiança 110 permite que o me- canismo de confiança 110 garanta alguém que é autenticado de acordo com a satisfação do mecanismo de confiança 110, mas não do fornecedor. Isso é análogo à função executada por um notário na adição da sua assinatura em um documento a fim de indicar para alguém que lê o documento em um momento posterior que a pessoa cuja assinatura aparece no documento é: na realidade a pessoa que o assinou. A assinatura do notário testemunha o ato de assinatura pelo usuário. Da mesma maneira, o mecanismo de confi- ança está provendo uma indicação que a pessoa fazendo a transação é quem ela diz ser.

Entretanto, pelo fato de que o mecanismo de confiança 110 está artificialmente aumentando o nível de certeza provido pelo usuário, existe um risco maior para o operador do mecanismo de confiança 110, desde que o usuário não está realmente satisfazendo o nível de confiança requerido do fornecedor. O custo do seguro é projetado para deslocar o risco de uma fal- sa autenticação positiva para o mecanismo de confiança 110 (que pode es- tar efetivamente reconhecendo as autenticações do usuário). O usuário paga o operador do mecanismo de confiança 110 para absorver o risco de auten- ticar em um nível de certeza mais alto do que realmente foi provido.

Pelo fato de que um tal sistema de seguro permite que alguém efetivamente compre uma classificação de certeza mais alta do mecanismo de confiança 110, ambos os fornecedores e usuários podem desejar impedir o uso do seguro no lado do usuário em certas transações. Os fornecedores podem desejar limitar as autenticações positivas às circunstâncias onde eles sabem que os dados de autenticação reais suportam o grau de certeza que eles exigem e assim podem indicar para o mecanismo de confiança 110 que o seguro do lado do usuário não deve ser permitido. Similarmente, para pro- teger a sua identidade em linha, um usuário pode desejar impedir o uso do seguro do lado do usuário por sua causa, ou pode desejar limitar seu uso a situações onde o nível de certeza da autenticação sem o seguro é mais alto do que um certo limite. Isso pode ser usado como uma medida de segurança para impedir que uma pessoa escute por acaso uma senha ou roube um cartão inteligente e os use para autenticar falsamente em um baixo nível de certeza e a seguir adquira o seguro para produzir um nível de certeza (falso) muito alto. Esses fatores podem ser avaliados na determinação se o seguro no lado do usuário é permitido.

Se o usuário adquire o seguro na etapa 1840, então o nível de certeza da autenticação é ajustado com base no seguro adquirido na etapa 1845 e o nível de certeza da autenticação e o nível de confiança requerido são novamente comparados na etapa 1730 (ver figura 17). O processo con- tinua daí e pode levar a uma autenticação positiva na etapa 1740 (ver figura 17) ou de volta para o processo de arbitragem de confiança na etapa 1750 para arbitragem adicional (se permitida) ou uma autenticação negativa na etapa 1810 se a arbitragem adicional é proibida.

Além de enviar uma mensagem para o usuário na etapa 1820, o mecanismo de transação 205 pode também enviar mensagem para o forne- cedor na etapa 1830 que indica que uma autenticação pendente está atual- mente abaixo do nível de confiança requerido. A mensagem pode também oferecer várias opções sobre como proceder para o fornecedor. Uma dessas opções é simplesmente informar ao fornecedor de qual é o nível de certeza de autenticação atual e perguntar se o fornecedor deseja manter o seu nível de confiança requerido não satisfeito atual. Isso pode ser benéfico porque em alguns casos, o fornecedor pode ter meio independente para autenticar a transação ou pode estar usando um conjunto predefinido de exigências que geralmente resultam em um nível requerido mais elevado sendo inicialmente especificado do que é realmente necessário para a transação particular à mão.

Por exemplo, pode ser que seja esperado por prátiça-padrão que todas as transações de pedido de compra que chegam com o fornece- dor satisfaçam um nível de confiança de 98%. Entretanto, se um pedido foi recentemente discutido pelo telefone entre o fornecedor e um cliente existen- te há muito tempo, e imediatamente a seguir a transação é autenticada, mas somente em um nível de certeza de 93%, o fornecedor pode desejar sim- plesmente diminuir o limiar de aceitação para essa transação, porque a chamada telefônica efetivamente provê a autenticação adicional para o for- necedor. Em certas circunstâncias, o fornecedor pode estar desejando dimi- nuir o seu nível de confiança requerido, mas não inteiramente para o nível da certeza de autenticação atual. Por exemplo, o fornecedor no exemplo acima poderia considerar que a chamada telefônica antes do pedido poderia merecer uma redução de 4% no grau de confiança necessário, entretanto, isso é ainda maior do que a certeza de 93% produzida pelo usuário.

Se o fornecedor realmente ajusta o seu nível de confiança re- querido na etapa 1835, então o nível de certeza da autenticação produzido pela autenticação e o nível de confiança requerido são comparados na etapa 1730 (ver figura 17). Se o nível de certeza agora excede o nível de confiança requerido, uma autenticação positiva pode ser gerada no mecanismo de transação 205 na etapa 1740 (ver figura 17). Se não, arbitragem adicional pode ser tentada como discutido acima se é permitido.

Além de solicitar um ajuste para o nível de confiança requerido, o mecanismo de transação 205 pode também oferecer seguro do lado do fornecedor para o fornecedor que solicita a autenticação. Esse seguro serve uma finalidade similar a essa descrita acima para o seguro do lado do usuá- rio. Aqui, entretanto, em vez do custo correspondente ao risco ser absorvido pelo mecanismo de confiança 110 na autenticação acima do nível de certeza de autenticação real produzido, o custo do seguro corresponde com o risco sendo absorvido pelo fornecedor na aceitação de um nível de confiança me- nor na autenticação.

Em vez de apenas reduzir o seu nível de confiança requerido real, o fornecedor tem a opção de adquirir o seguro para se proteger do risco adicional associado com um nível inferior de confiança na autenticação do usuário. Como descrito acima, pode ser vantajoso que o fornecedor conside- re somente a compra de tal seguro para cobrir a lacuna de confiança nas condições onde a autenticação existente já está acima de um certo limiar.

A disponibilidade de tal seguro no lado do fornecedor permite ao fornecedor a opção de: reduzir a sua exigência de confiança diretamente sem custo adicional para ele próprio, suportar o risco de uma falsa autenti- cação por si próprio (com base no nível de confiança menor requerido) ou, comprar seguro para a lacuna de confiança entre o nível de certeza de au- tenticação e sua exigência, com o mecanismo de confiança 110 suportando o risco do nível de certeza menor que foi provido. Pela compra do seguro, o fornecedor efetivamente mantém sua exigência de alto nível de confiança, porque o risco de uma falsa autenticação é deslocado para o operador do. mecanismo de confiança 110.

Se o fornecedor adquire o seguro na etapa 1840, o nível de cer- teza da autenticação e os níveis de confiança requeridos são comparados na etapa 1730 (ver figura 17) e o processo continua como descrito acima.

Observe que também é possível que ambos o usuário e o forne- cedor respondam às mensagens do mecanismo de confiança 110. Aqueles versados na técnica reconhecerão que existem múltiplas maneiras nas quais tais situações podem ser manipuladas. Um modo vantajoso de manipular a possibilidade de múltiplas respostas é simplesmente tratar as respostas em uma maneira de primeira a chegar, primeira servida. Por exemplo, se o for- necedor responde com um nível de confiança requerido reduzido e imedia- tamente a seguir o usuário também compra o seguro para elevar seu nível de autenticação, a autenticação é reavaliada, em primeiro lugar, com base na exigência de confiança reduzida do fornecedor. Se a autenticação é ago- ra positiva, a compra de seguro do usuário é ignorada. Em um outro modo de operação vantajoso, o usuário poderia somente ser cobrado pelo nível de seguro requerido para satisfazer a nova exigência de confiança reduzida do fornecedor (se uma lacuna de confiança permaneceu mesmo com a exigên- cia de confiança reduzida do fornecedor).

Se nenhuma resposta de qualquer parte interessada é recebida durante o processo de arbitragem de confiança na etapa 1850 durante o limi- te de tempo estabelecido para a autenticação, a arbitragem é reavaliada na etapa 1805. Isso efetivamente começa o processo de arbitragem novamen- te. Se o limite dé tempo foi final ou outras circunstâncias impedem a arbitra- gem adicional na etapa 1805, uma autenticação negativa é gerada pelo me- canismo de transação 205 na etapa 1810 e retornada para o fornecedor na etapa 1055 (ver figura 10). Se não, novas mensagens podem ser enviadas para o usuário e fornecedor e o processo pode ser repetido como desejado.

Observe que para certos tipos de transações, por exemplo, a assinatura digital de documentos que não são parte de uma transação, po- dem não existir necessariamente um fornecedor ou outros terceiros, portan- to, a transação é primariamente entre o usuário e o mecanismo de confiança 110. Em circunstâncias tal como essas, o mecanismo de confiança 110 terá seu próprio nível de confiança requerido que deve ser satisfeito a fim de ge- rar uma autenticação positiva. Entretanto, em tais circunstâncias, freqüente- mente não será desejável que o mecanismo de confiança 110 ofereça segu- ro para o usuário a fim de que ele eleve a certeza da sua própria assinatura.

O processo descrito acima e mostrado nas figuras 16-18 pode ser executado usando vários modos de comunicações como descrito acima com referência ao mecanismo de confiança 110. Por exemplo, as mensa- gens podem ser com base na web e enviadas usando conexões SSL entre o mecanismo de confiança 100 e miniaplicativos descarregados em tempo real para navegadores funcionando nos sistemas do usuário ou fornecedor. Em um modo de operação alternado, certas aplicações dedicadas podem estar em uso pelo usuário e fornecedor que facilitam tais transações de arbitragem e seguro. Em um outro modo de operação alternado, operações seguras de e-mail podem ser usadas para mediar a arbitragem descrita acima, dessa maneira permitindo avaliações adiadas e processamento em lote das auten- ticações. Aqueles versados na técnica reconhecerão que modos de comuni- cações diferentes podem ser usados como são apropriados para as cirçuns- tâncias e as exigências de autenticação do fornecedor.

A descrição seguinte com referência à figura 19 descreve uma transação exemplar que integra os vários aspectos da presente invenção como descrito acima. Esse exemplo ilustra o processo geral entre um usuá- rio e um fornecedor como mediado pelo mecanismo de confiança 110. Em- bora as várias etapas e componentes como descritos em detalhes acima possam ser usados para executar a transação seguinte, o processo ilustrado focaliza na interação entre o mecanismo de confiança 110, o usuário e o for- necedor.

A transação começa quando o usuário, enquanto vendo páginas da web em linha, preenche um formulário de pedido no website do fornece- dor na etapa 1900. O usuário deseja submeter esse formulário de pedido para o fornecedor, assinado com sua assinatura digital. A fim de fazer isso, o usuário submete o formulário de pedido com sua solicitação por uma assina- tura para o mecanismo de confiança 110 na etapa 1950. O usuário também proverá dados de autenticação que serão usados como descrito acima para autenticar a sua identidade.

Na etapa 1910 os dados de autenticação são comparados com os dados de inscrição pelo mecanismo de confiança 110 como discutido a- cima, e se uma autenticação positiva é produzida, a prova do formulário do pedido, assinada com a chave privada do usuário, é enviada para o fornece- dor junto com o próprio formulário de pedido.

O fornecedor recebe o formulário assinado na etapa 1915 e a seguir o fornecedor gerará uma fatura ou outro contrato relacionado com a compra a ser feita na etapa 1920. Esse contrato é enviado de volta para o usuário com uma solicitação por uma assinatura na etapa 1925. O fornece- dor também envia uma solicitação de autenticação para sua transação de contrato para o mecanismo de confiança 110 na etapa 1930 incluindo uma prova do contrato que será assinado por ambas as partes interessadas. Para permitir que o contrato seja digitalmente assinado por ambas as partes inte- ressadas, o fornecedor também inclui dados de autenticação por si próprio de modo que a assinatura do fornecedor no contrato possa ser posterior- mente verificada se necessário.

Como discutido acima, o mecanismo de confiança 110 então ve- rifica os dados de autenticação providos pelo fornecedor para confirmar a identidade do fornecedor e se os dados produzem uma autenticação positiva na etapa 1935, continua com a etapa 1955 quando os dados são recebidos do usuário. Se òs dados de autenticação do fornecedor não combinam com os dados da inscrição do fornecedor até o grau desejado, uma mensagem é retornada para o fornecedor solicitando autenticação adicional. A arbitragem de confiança pode ser executada aqui se necessário, como descrito acima, a fim de que o fornecedor autentique com sucesso a si próprio para o meca- nismo de confiança 110.

Quando o usuário recebe o contrato na etapa 1940, ele o revisa, gera os dados de autenticação para assiná-lo se ele é aceitável na etapa 1945 e a seguir envia uma prova do contrato e seus dados de autenticação para o mecanismo de confiança 110 na etapa 1950. O mecanismo de confi- ança 110 verifica os dados de autenticação na etapa 1955 e se a autentica- ção é boa, prossegue para processar o contrato como descrito abaixo. Como discutido acima com referência às figuras 17 e 18, a arbitragem de confiança pode ser executada como apropriado para fechar qualquer lacuna de confi- ança que exista entre o nível de certeza da autenticação e o nível de auten- ticação requerido para a transação.

O mecanismo de confiança 110 assina a prova do contrato com a chave privada do usuário e envia essa prova assinada para o fornecedor na etapa 1960, assinando a mensagem completa em seu próprio nome, isto é, incluindo uma prova da mensagem completa (incluindo a assinatura do usuário) criptografada com a chave privada 510 do mecanismo de confiança 110. Essa mensagem é recebida pelo fornecedor na etapa 1965. A mensa- gem representa um contrato assinado (prova do contrato criptografado u- sando a chave privada do usuário) e uma recepção do mecanismo de confi- ança 110 (a prova da mensagem incluindo o contrato assinado, criptografa- do usando a chave privada do mecanismo de confiança 110).

O mecanismo de confiança 110 prepara similarmente uma prova do contrato com a chave privada do fornecedor na etapa 1970 e envia essa para o usuário, assinada pelo mecanismo de confiança 110. Dessa maneira, o usuário também recebe uma cópia do contrato, assinada pelo fornecedor, bem como um recibo, assinado pelo mecanismo de confiança 110, pela en- trega do contrato assinado na etapa 1975.

Além do precedente, um aspecto adicional da invenção provê um módulo de provedor de serviço (SPM) criptográfico que pode ficar dispo- nível para uma aplicação no lado do cliente como um meio para acessar funções providas pelo mecanismo de confiança 110 descrito acima. Uma maneira vantajosa para prover um tal serviço é para o SPM criptográfico mediar as comunicações entre uma interface de programação de aplicação (API) de terceiros e um mecanismo de confiança 110 que está acessível via uma rede ou outra conexão remota. Um SPM criptográfico exemplar é des- crito abaixo com referência à figura 20.

Por exemplo, em um sistema típico, um número de API1S fica disponível para os programadores. Cada API provê um conjunto de chama- das de função que podem ser feitas por uma aplicação 2000 funcionando no sistema. Exemplos de API's que provêem interfaces de programação ade- quadas para funções criptográficas, funções de autenticação e outras fun- ções de segurança incluem a API criptográfica (CAPI) 2010 provida pela Mi- crosoft com seus sistemas operacionais Windows e a arquitetura de segu- rança de dados comum (CDSA), possuída pela IBM, Intel e outros membros do grupo aberto. CAPI será usado como uma API de segurança exemplar na discussão que segue. Entretanto, o SPM criptográfico descrito poderia ser usado com CDSA ou outras API1S de segurança como são conhecidos na técnica.

Essa API é usada por um sistema do usuário 105 ou sistema do fornecedor 120 quando uma chamada é feita por uma função criptográfica. Incluídas entre essas funções podem estar solicitações associadas com a execução de várias operações criptográficas, tais como criptografar um do- cumento com uma chave particular, assinar um documento, solicitar um cer- tificado digital, verificar uma assinatura sobre um documento assinado e tais outras funções criptográficas como são descritas aqui ou conhecidas para aqueles versados na técnica.

Tais funções criptográficas são normalmente executadas local- mente no sistema sobre o qual o CAPI 2010 está localizado. Isso é porque geralmente as funções chamadas exigem o uso de recursos do sistema do usuário local 105, tal como uma leitora de impressão digital, ou funções de software que são programadas usando bibliotecas que são executadas na máquina local. O acesso a esses recursos locais é normalmente provido por um ou mais módulos de provedor de serviço (SPM's) 2015, 2020 como cita- do acima que provêem recursos com os quais as funções criptográficas são executadas. Tais SPM's podem incluir bibliotecas de software 2015 para e- xecutar operações de criptografia ou decriptografia ou acionadores e aplica- ções 2020 que são capazes de acessar hardware especializado 2025, tal como dispositivos de varredura biométrica. Similar à maneira na qual o CAPI 2010 provê funções que podem ser usadas por uma aplicação 2000 do sis- tema 105, os SPM's 2015, 2020 provêem CAPI com acesso às funções de nível inferior e recursos associados com os serviços disponíveis no sistema.

De acordo com a invenção, é possível prover um SPM criptográ- fico 2030 que é capaz de acessar as funções criptográficas providas pelo mecanismo de confiança 110 e tornar essas funções disponíveis para uma aplicação 2000 através de CAPI 2010. Ao contrário das modalidades onde CAPI 2010 é somente capaz de acessar recursos que estão localmente dis- poníveis através de SPM's 2015, 2020, um SPM criptográfico 2030 como descrito aqui seria capaz de submeter solicitações por operações criptográfi- cas para um mecanismo de confiança acessível pela rede remotamente lo- calizado 110 de modo a executar as operações desejadas.

Por exemplo, se uma aplicação 2000 tem uma necessidade de uma operação criptográfica, tal como assinar um documento, a aplicação 2000 faz uma chamada de função para a função CAPI apropriada 2010. A CAPI 2010, por sua vez, executará essa função, fazendo uso dos recursos que ficam disponíveis para ela pelo SPM1S 2015, 2020 e o SPM criptográfico 2030. No caso de uma função de assinatura digital, o SPM criptográfico 2030 gerará uma solicitação apropriada que será enviada para o mecanismo de confiança 110 através da ligação de comunicação 125.

As operações que ocorrem entre o SPM criptográfico 2030 e o mecanismo de confiança 110 são as mesmas operações que seriam possí- veis entre qualquer outro sistema e o mecanismo de confiança 110. Entre- tanto, essas funções ficam efetivamente disponíveis para um sistema de u- suário 105 através de CAPI 2010, tal que elas aparentam estar localmente disponíveis no próprio sistema do usuário 105. Entretanto, ao contrário dos SPM's comuns 2015, 2020, as funções estão sendo executadas no meca- nismo de confiança remoto 110 e os resultados retransmitidos para o SPM criptográfico 2030 em resposta a solicitações apropriadas através da ligação de comunicação 125.

Esse SPM criptográfico 2030 faz um número de operações dis- poníveis para o sistema do usuário 105 ou um sistema de fornecedor 120 que de outra forma não estaria disponível. Essas funções incluem sem Iimi- tação: criptografia e decriptografia de documentos, emissão de certificados digitais, assinatura digital de documentos, verificação das assinaturas digi- tais e tais outras operações como será evidente para aqueles versados na técnica.

Em uma modalidade separada, a presente invenção compreen- de um sistema completo para executar os métodos de garantia de dados da presente invenção em qualquer conjunto de dados. O sistema de computa- dor dessa modalidade compreende um módulo de divisão de dados que compreende a funcionalidade mostrada na figura 8 e descrita aqui. Em uma modalidade da presente invenção, o módulo de divisão de dados, algumas vezes citado aqui como um analisador de dados seguro, compreende um programa analisador ou conjunto de software que compreende divisão de dados, criptografia e decriptografia, funcionalidade de reconstituição ou nova montagem. Essa modalidade pode também compreender uma facilidade de armazenamento de dados ou múltiplas facilidades de armazenamento de dados, também. O módulo de divisão de dados, ou o analisador de dados seguro, compreende um conjunto de módulo de software de plataforma cru- zada que integra dentro de uma infra-estrutura eletrônica, ou como um com- plemento em qualquer aplicação que requeira a segurança final dos seus elementos de dados. Esse processo de análise opera em qualquer tipo de conjunto de dados, e em qualquer e todos os tipos de arquivo, ou em um banco de dados em qualquer linha, coluna ou célula de dados nesse banco de dados.

O processo de análise da presente invenção pode ser projetado, em uma modalidade, em um modo disposto em fileiras modular, e qualquer processo de criptografia é adequado para uso no processo da presente in- venção. As fileiras modulares do processo de análise e divisão da presente invenção podem incluir, mas não são limitadas a, 1) divisão criptográfica, dispersão e armazenamento com segurança em múltiplas localizações, 2) criptografia, divisão criptograficamente, dispersão e armazenamento com segurança em múltiplas localizações, 3) criptografia, divisão criptografica- mente, criptografia de cada compartilhamento, a seguir dispersão e armaze- namento em segurança em múltiplas localizações e 4) criptografia, divisão criptograficamente, criptografia de cada compartilhamento com um tipo dife- rente de criptografia que foi usado na primeira etapa, a seguir dispersão e armazenamento com segurança em múltiplas localizações.

O processo compreende, em uma modalidade, a divisão dos dados de acordo com os conteúdos de um número aleatório gerado, ou cha- ve e execução da mesma divisão criptográfica da chave usada na criptogra- fia da divisão dos dados a serem garantidos em duas ou mais porções, ou compartilhamentos, de dados analisados e divididos, e em uma modalidade, de preferência em quatro ou mais porções dos dados analisados e divididos, criptografando todas as porções, a seguir dispersando e armazenando essas porções de volta no banco de dados ou relocando-as em qualquer dispositi- vo nomeado, fixado ou removível, dependendo da necessidade do solicitante com relação à privacidade e segurança. Alternativamente, em uma outra modalidade, a criptografia pode ocorrer antes da divisão do conjunto de da- dos pelo módulo de divisão ou analisador de dados seguro. Os dados origi- nais processados como descrito nessa modalidade são criptografados e o- fuscados e ficam seguros. A dispersão dos elementos criptografados, se de- sejada, pode ser virtualmente em qualquer lugar, incluindo, mas não-limitado a, um único servidor ou dispositivo de armazenamento de dados, ou entre facilidades ou dispositivos de armazenamento de dados separados. O ge- renciamento da chave de criptografia em uma modalidade pode ser incluído dentro do conjunto de software, ou em uma outra modalidade pode ser inte- grado em uma infra-estrutura existente ou qualquer outra localização dese- jada.

Uma divisão criptográfica (criptodivisão) divide os dados em um N número de compartilhamentos. A divisão pode ser em qualquer unidade de tamanho de dados, incluindo um bit individual, bits, bytes, quilobytes, me- gabytes ou unidades maiores, bem como qualquer padrão ou combinação de tamanhos de unidade de dados se predeterminados ou aleatoriamente gerados. As unidades podem também ser de um tamanho diferente, com base em um conjunto de valores aleatórios ou predeterminados. Isso signifi- ca que os dados podem ser vistos como uma seqüência dessas unidades. Dessa maneira, o tamanho das próprias unidades de dados pode tornar os dados mais seguros, por exemplo, usando um ou mais padrões predetermi- nados ou aleatoriamente gerados, seqüência ou combinação de tamanhos de unidade de dados. As unidades são então distribuídas (aleatoriamente ou por um conjunto predeterminado de valores) nos N compartilhamentos. Essa distribuição poderia também envolver uma mistura da ordem das unidades nos compartilhamentos. É facilmente evidente para aqueles versados na técnica que a distribuição das unidades de dados nos compartilhamentos pode ser executada de acordo com uma ampla variedade de seleções pos- síveis, incluindo, mas não-limitado a tamanho fixo, tamanhos predetermina- dos ou uma ou mais combinações, padrões ou seqüências de tamanhos de unidade de dados que são predeterminados ou aleatoriamente gerados. Um exemplo desse processo de divisão criptográfica, ou cripto- divisão, seria considerar os dados como sendo de 23 bytes de tamanho, com o tamanho da unidade de dados escolhido para ser de um byte e com o número de compartilhamentos selecionado para ser 4. Cada byte seria dis- tribuído em um dos 4 compartilhamentos. Assumindo uma distribuição alea- tória, uma chave seria obtida para criar uma seqüência de 23 números alea- tórios (r1, r2, r3 até r23), cada um com um valor entre 1 e 4 correspondendo com os quatro compartilhamentos. Cada uma das unidades de dados (nesse exemplo 23 bytes de dados individuais) está associada com um dos 23 nú- meros aleatórios correspondendo com um dos quatro compartilhamentos. A distribuição dos bytes dos dados nos quatro compartilhamentos ocorreria colocando o primeiro byte dos dados no número de compartilhamento r1, o byte dois no compartilhamento r2, o byte três no compartilhamento r3, até o 23Q byte de dados no compartilhamento r23. É facilmente evidente para a- queles versados na técnica que uma ampla variedade de outras etapas pos- síveis ou combinação ou seqüência de etapas, incluindo o tamanho das uni- dades de dados, pode ser usada no processo de criptodivisão da presente invenção e o exemplo acima é uma descrição não-limitadora de um proces- so para criptodividir os dados. Para recriar os dados originais, a operação inversa seria executada.

Em uma outra modalidade do processo de criptodivisão da pre- sente invenção, uma opção para o processo de criptodivisão é prover redun- dância suficiente nos compartilhamentos tal que somente um subconjunto dos compartilhamentos é necessário para remontar ou restaurar os dados para sua forma original ou utilizável. Como um exemplo não-limitador, a crip- todivisão pode ser feita como uma criptodivisão "3 de 4" tal que somente três dos quatro compartilhamentos são necessários para remontar ou restaurar os dados para sua forma original ou utilizável. Isso é também citado como uma "M de N criptodivisão" onde N é o número total de compartilhamentos e M é pelo menos um menos do que N. É facilmente evidente para aqueles versados na técnica que existem muitas possibilidades para criar essa re- dundância no processo de criptodivisão da presente invenção. Em uma modalidade do processo de criptodivisão da presente invenção, cada unidade de dados é armazenada em dois compartilhamen- tos, o compartilhamento primário e o compartilhamento de reserva. Usando o processo de criptodivisão de "3 de 4" descrito acima, qualquer um compar- tilhamento pode estar ausente, e isso é suficiente para remontar ou restaurar os dados originais sem unidades de dados ausentes desde que somente três dos quatro compartilhamentos totais são requeridos. Como descrito a- qui, um número aleatório é gerado que corresponde com um dos comparti- lhamentos. O número aleatório é associado com uma unidade de dados e armazenado no compartilhamento correspondente, com base em uma cha- ve. Uma chave é usada, nessa modalidade, para gerar o número aleatório de compartilhamento primário e de reserva. Como descrito aqui para o pro- cesso de criptodivisão da presente invenção, um conjunto de números alea- tórios (também citado como números de compartilhamento primários) de 0 a 3 é gerado igual ao número das unidades de dados. A seguir, um outro con- junto de números aleatórios é gerado (também citado como números de compartilhamento de reserva) de 1 a 3 igual ao número de unidades de da- dos. Cada unidade de dados é então associada com um número de compar- tilhamento primário e um número de compartilhamento de reserva. Alternati- vãmente, um conjunto de números aleatórios pode ser gerado que é menor do que o número de unidades de dados e repetindo o conjunto de número aleatório, porém isso pode reduzir a segurança dos dados sensíveis. O nú- mero de compartilhamento primário é usado para determinar em qual com- partilhamento a unidade de dados está armazenada. O número de comparti- lhamento de reserva é combinado com o número de compartilhamento pri- mário para criar um terceiro número de compartilhamento entre 0 e 3 e esse número é usado para determinar em qual compartilhamento a unidade de dados está armazenada. Nesse exemplo, a equação para determinar o ter- ceiro número de compartilhamento é:

(número de compartilhamento primário + número de comparti- lhamento de reserva) MOD 4 = terceiro número de compartilhamento.

A modalidade descrita acima onde o número de compartilha- mento primário está entre 0 e 3, e o número de compartilhamento de reserva está entre 1 e 3 garante que o terceiro número de compartilhamento seja diferente do número de compartilhamento primário. Isso resulta na unidade de dados sendo armazenada em dois compartilhamentos diferentes. É facil- mente evidente para aqueles versados na técnica que existem muitas ma- neiras de executar a criptodivisão redundante e a criptodivisão não redun- dante além das modalidades reveladas aqui. Por exemplo, as unidades de dados em cada compartilhamento poderiam ser misturadas utilizando um algoritmo diferente. Essa mistura da unidade de dados pode ser executada quando os dadós originais são divididos nas unidades de dados ou depois que as unidades de dados são colocadas nos compartilhamentos, ou depois que o compartilhamento está completo, por exemplo.

Os vários processos de criptodivisão e processos de mistura de dados descritos aqui, e todas as outras modalidades de criptodivisão e mé- todos de mistura de dados da presente invenção podem ser executados em unidades de dados de qualquer tamanho, incluindo, mas não-limitado a, tão pequenas quanto um bit individual, bits, bytes, quilobytes, megabytes ou maiores.

Um exemplo de uma modalidade de código fonte que executaria o processo de criptodivisão descrito aqui é:

DADOS [1:24] - formação de bytes com os dados a serem divi- didos

COMPARTILHAMENTOS [0:3, 1:24] - arranjo 2-dimensional com cada linha representando um dos compartilhamentos ALEATÓRIO [1:24] - números aleatórios da formação na faixa

de 0..3

51 = 1,

52 = 1,

53 = 1,

30 S4 = 1,

Para J = 1 a 24 fazer

Começar Se ALEATORIO[J[ ==0 então

Começar

COMPARTILHAMENTOS[1,S1] = DADOS [J];

S1 =SI + 1;

E

SE NÃO SE ALEATÓRIO[J[ ==1 então Começar

COMPARTILHAMENTOS[2,S2] = DADOS [J];

S2 = S2 + 1;

E

SE NÃO SE ALEATÓRIO [J[ == 2 então Começar

Corripartilhamentos[3,S3] = dados [J];

S3 = S3 + 1;

E

Se não começar

Compartilhamentos[4,S4] = dados [J];

S4 = S4 + 1;

Fim;

FIM;

Um exemplo de uma modalidade do código fonte que executaria o processo RAID de criptodivisão descrito aqui é:

Gerar dois conjuntos de números, PrimaryShare é 0 a 3, Bac-

kupShare é 1 a 3. A seguir colocar cada unidade de dados no sha- re[primaryshare[1]] e share[(primaryshare[1]+backupshare[1]) mod 4, com o mesmo processo como na criptodivisão descrita acima. Esse método será escalável para qualquer tamanho N, onde somente N-1 compartilhamentos são necessários para restaurar os dados.

A recuperação, recombinação, remontagem ou reconstituição dos elementos de dados criptografados pode utilizar qualquer número de técnicas de autenticação, incluindo, mas não-limitado a, biométrica, tais co- mo reconhecimento de impressão digital, varredura facial, varredura de mão, varredura da íris, varredura da retina, varredura da orelha, reconhecimento de padrão vascular ou análise de DNA. Os módulos de divisão e/ou analisa- dores de dados da presente invenção podem ser integrados em uma ampla variedade de produtos de infra-estrutura ou aplicativos como desejado.

As tecnologias de criptografia tradicionais conhecidas na técnica contam com uma ou mais chaves usadas para criptografar os dados e torná- los inutilizáveis sem a chave. Os dados, entretanto, permanecem completos e intactos e sujeitos ao ataque. O analisador de dados seguro da presente invenção, em uma modalidade, trata desse problema executando uma análi- se e divisão criptográfica do arquivo criptografado em duas ou mais porções ou compartilhamentos, e em uma outra modalidade, preferivelmente quatro ou mais compartilhamentos, adicionando uma outra camada de criptografia em cada compartilhamento dos dados, a seguir armazenando os comparti- lhamentos em localizações físicas e/ou lógicas diferentes. Quando um ou mais compartilhamentos de dados são fisicamente removidos do sistema, usando um dispositivo removível, tal como um dispositivo de armazenamen- to de dados, ou colocando o compartilhamento sob o controle de uma outra parte interessada, qualquer possibilidade de comprometimento dos dados seguros é efetivamente removida.

Um exemplo de uma modalidade do analisador de dados seguro da presente invenção e um exemplo de como eles podem ser utilizados é mostrado na figura 21 e descrito abaixo. Entretanto, é facilmente evidente para aqueles versados na técnica que o analisador de dados seguro da pre- sente invenção pode ser utilizado em uma ampla variedade de maneiras a- lém do exemplo não-limitador abaixo. Como uma opção de desenvolvimento, e em uma modalidade, o analisador de dados seguro pode ser implementa- do com gerenciamento de chave de sessão externa ou armazenamento in- terno seguro das chaves de sessão. Com a implementação, uma chave- mestre do analisador será gerada que será usada para garantir a aplicação e para finalidades de criptografia. Também deve ser observado que a incorpo- ração da chave-mestre do analisador nos dados seguros resultantes permite uma flexibilidade de compartilhamento dos dados seguros por indivíduos dentro de um grupo de trabalho, empreendimento ou audiência estendida.

Como mostrado na figura 21, essa modalidade da presente in- venção mostra as etapas do processo executadas pelo analisador de dados seguro nos dados para armazenar a chave-mestre da sessão com os dados analisados:

1. Gerar uma chave mestra da sessão e criptografar os dados usando a cifra de fluxo RS1.

2. Separar os dados criptografados resultantes em quatro com- partilhamentos ou porções de dados analisados de acordo com o padrão da chave mestra da sessão.

3. Nessa modalidade do método, a chave mestra da sessão se- rá armazenada junto com os compartilhamentos de dados seguros em um depositário de dados. Separar a chave mestra da sessão de acordo com o padrão da chave-mestre do analisador e anexar os dados da chave nos da- dos analisados criptografados.

4. Os quatro compartilhamentos de dados resultantes conterão porções criptografadas dos dados originais e porções da chave-mestre da sessão. Gerar uma chave de cifra de fluxo para cada um dos quatro compar- tilhamentos de dados.

5. Criptografar cada compartilhamento, a seguir armazenar as chaves de criptografia em localizações diferentes das porções de dados crip- tografados ou compartilhamentos: o compartilhamento 1 obtém a chave 4, o compartilhamento 2 obtém a chave 1, o compartilhamento 3 obtém a chave 2, o compartilhamento 4 obtém a chave 3.

Para restaurar o formato de dados original, as etapas são inver- tidas.

É facilmente evidente para aqueles versados na técnica que cer- tas etapas dos métodos descritos aqui podem ser executadas em ordens diferentes, ou repetidas múltiplas vezes, como desejado. É também facil- mente evidente para aqueles versados na técnica que as porções dos dados podem ser manipuladas diferentemente uma da outra. Por exemplo, múlti- pias etapas de análise podem ser executadas em somente uma porção dos dados analisados. Cada porção dos dados analisados pode ser unicamente garantida em qualquer maneira desejável contanto somente que os dados possam ser remontados, reconstituídos, reformados, decriptografados ou restaurados para sua forma original ou outra utilizável.

Como mostrado na figura 22 e descrito aqui, uma outra modali- dade da presente invenção compreende as etapas do processo executado pelo analisador de dados seguro nos dados para armazenar os dados da chave-mestre da sessão em uma ou mais tabelas de gerenciamento de cha- ve separadas:

1. Gerar uma chave mestra da sessão e criptografar os dados usando a cifra de fluxo RS1.

2. Separar os dados criptografados resultantes em quatro com- partilhamentos ou porções de dados analisados de acordo com o padrão da chave-mestre da sessão.

3. Nessa modalidade do método da presente invenção, a chave mestra da sessão será armazenada em uma tabela de gerenciamento de chave separada em um depositário de dados. Gerar um ID único de transa- ção para essa transação. Armazenar o ID de transação e chave-mestre da sessão em uma tabela dé gerenciamento de chave separada. Separar o ID da transação de acordo com o padrão da chave-mestre do analisador e ane- xar os dados nos dados criptografados analisados ou separados.

4. Os quatro compartilhamentos resultantes de dados conterão porções criptografadas dos dados originais e porções do ID da transação.

5. Gerar uma chave de cifra de fluxo para cada um dos quatro compartilhamentos de dados.

6. Criptografar cada compartilhamento, a seguir armazenar as chaves de criptografia em localizações diferentes das porções de dados crip- tografadas ou compartilhamentos: compartilhamento 1 obtém chave 4, com- partilhamento 2 obtém chave 1, compartilhamento 3 obtém chave 2, compar- tilhamento 4 obtém chave 3.

Para restaurar o formato de dados originais, as etapas são in- vertidas.

É facilmente evidente para aqueles versados na técnica que cer- tas etapas do método descrito aqui podem ser executadas em ordem dife- rente, ou repetidas múltiplas vezes, como desejado. Também é facilmente evidente para aqueles versados na técnica que as porções dos dados po- dem ser manipuladas diferentemente uma da outra. Por exemplo, múltiplas etapas de separação ou análise podem ser executadas em somente uma porção dos dados analisados. Cada porção dos dados analisados pode ser unicamente garantida em qualquer maneira desejável contanto somente que os dados possam ser remontados, reconstituídos, reformados, decriptogra- fados ou restaurados para sua forma original ou outra utilizável.

Como mostrado na figura 23, essa modalidade da presente in- venção mostra as etapas do processo executadas pelo analisador de dados seguro nos dados para armazenar a chave mestra da sessão com os dados analisados:

1. Acessar a chave-mestre do analisador associada com o usuá- rio autenticado.

2. Gerar uma única chave-mestre de sessão.

3. Derivar uma chave intermediária de uma função OU exclusivo da chave-mestre do analisador e chave-mestre da sessão.

4. Criptografia opcional dos dados usando um algoritmo de crip- tografia existente ou novo provido de chave com a chave intermediária.

5. Separar os dados resultantes opcionalmente criptografados em quatro compartilhamentos ou porções de dados analisados de acordo com o padrão da chave intermediária.

6. Nessa modalidade do método, a chave mestra da sessão se- rá armazenada junto com os compartilhamentos de dados seguros em um depositário de dados. Separar a chave mestra da sessão de acordo com o padrão da chave-mestre do analisador e anexar os dados da chave nos compartilhamentos de dados analisados opcionalmente criptografados.

7. Os múltiplos compartilhamentos resultantes dos dados conte- rão porções opcionalmente criptografadas dos dados originais e porções da chave-mestre da sessão.

8. Opcionalmente gerar uma chave de criptografia para cada um dos quatro compartilhamentos de dados. 9. Opcionalmente criptografar cada compartilhamento com um algoritmo de criptografia existente ou novo, a seguir armazenar as chaves de criptografia em localizações diferentes das porções de dados criptografados ou compartilhamentos: por exemplo, compartilhamento 1 obtém chave 4, compartilhamento 2 obtém chave 1, compartilhamento 3 obtém chave 2, compartilhamento 4 obtém chave 3.

Para restaurar o formato de dados originais, as etapas são in- vertidas.

É facilmente evidente para aqueles versados na técnica que cer- tas etapas dos métodos descritos aqui podem ser executadas em ordem diferente, ou repetidas múltiplas vezes, como desejado. Também é facilmen- te evidente para aqueles versados na técnica que as porções dos dados po- dem ser manipuladas diferentemente uma da outra. Por exemplo, múltiplas etapas de análise podem ser executadas em somente uma porção dos da- dos analisados. Cada porção dos dados analisados pode ser unicamente garantida em qualquer maneira desejável contanto somente que os dados possam ser remontados, reconstituídos, reformados, decriptografados ou restaurados para sua forma original ou outra utilizável.

Como mostrado na figura 24 e descrito aqui, uma outra modali- dade da presente invenção compreende as etapas do processo executadas pelo analisador de dados seguros nos dados para armazenar os dados da chave-mestre da sessão em uma ou mais tabelas de gerenciamento de cha- ve separadas:

1. Acessar a chave-mestre do analisador associada com o usuá- rio autenticado.

2. Gerar uma chave-mestre de sessão única.

3. Derivar uma chave intermediária de uma função OU exclusivo da chave-mestre do analisador e chave-mestre da sessão.

4. Opcionalmente criptografar os dados usando um algoritmo de criptografia existente ou novo provido de chave com a chave intermediária.

5. Separar os dados resultantes opcionalmente criptografados em quatro compartilhamentos ou porções de dados analisados de acordo com o padrão da chave intermediária.

6. Nessa modalidade do método da presente invenção, a chave- mestre da sessão será armazenada em uma tabela de gerenciamento de chave separada em um depositário de dados. Gerar um único ID de transa- ção para essa transação. Armazenar o ID da transação e chave-mestre da sessão em uma tabela de gerenciamento de chave separada ou passar a chave-mestre da sessão e o ID da transação de volta para o programa que chama para gerenciamento externo. Separar o ID da transação de acordo com o padrão da chave-mestre do analisador e anexar os dados nos dados analisados ou separados opcionalmente criptografados.

7. Os quatro compartilhamentos resultantes de dados conterão porções opcionalmente criptografadas dos dados originais e porções do ID da transação.

8. Opcionalmente gerar uma chave de criptografia para cada um dos quatro compartilhamentos de dados.

9. Opcionalmente criptografar cada compartilhamento, a seguir armazenar as chaves de criptografia em localizações diferentes das porções de dados criptografados ou compartilhamentos. Por exemplo, o comparti- lhamento 1 obtém a chave 4, o compartilhamento 2 obtém a chave 1, o compartilhamento 3 obtém a chave 2, o compartilhamento 4 obtém a chave 3.

Para restaurar o formato de dados originais, as etapas são in- vertidas.

É facilmente evidente para aqueles versados na técnica que cer- tas etapas do método descrito aqui podem ser executadas em ordem dife- rente, ou repetidas múltiplas vezes, como desejado. Também é facilmente evidente para aqueles versados na técnica que as porções dos dados po- dem ser manipuladas diferentemente uma da outra. Por exemplo, múltiplas etapas de separação ou análise podem ser executadas em somente uma porção dos dados analisados. Cada porção dos dados analisados pode ser unicamente garantida em qualquer maneira desejável contanto somente que os dados possam ser remontados, reconstituídos, reformados, decriptogra- fados ou restaurados para sua forma original ou outra utilizável.

Uma ampla variedade de metodologias de criptografia é ade- quada para uso nos métodos da presente invenção, como é facilmente evi- dente para aqueles versados na técnica. O algoritmo de enchimento de um tempo é freqüentemente considerado um dos métodos de criptografia mais seguros, e é adequado para uso no método da presente invenção. O uso do algoritmo de enchimento de um tempo exige que uma chave seja gerada que seja tão longa quanto os dados a serem garantidos. O uso desse méto- do pode ser menos desejável em certas circunstâncias tal como essas resul- tando na geração e gerenciamento de chaves muito longas por causa do tamanho do conjunto de dados a ser garantido. No algoritmo de enchimento de um tempo (OTP), a simples função ou exclusivo, XOR, é usada. Para dois fluxos binários χ e y do mesmo comprimento, χ XOR y significa o ou exclusivo no sentido do bit de χ e y.

No nível de bit é gerado:

0 XOR 0 = 0

0 XOR 1 = 1

1 XOR 0 = 1

1 XOR 1 = 0

Um exemplo desse processo é descrito aqui para um segredo de η bytes, s, (ou conjunto de dados) a ser dividido. O processo gerará um valor aleatório de η byte e a seguir ajusta:

b = a XOR s.

Observe que uma pessoa pode derivar "s" via a equação:

s = a XOR b.

Os valores a e b são citados como compartilhamentos ou por- ções e são colocados em depositários separados. Depois que o segredo s é dividido em dois ou mais compartilhamentos, ele é descartado em uma ma- neira segura.

O analisador de dados seguro da presente invenção pode utili- zar essa função, executando múltiplas funções XOR incorporando múltiplos valores de chave secreta distintos: K1, K2, K3, Kn, K5. No começo da ope- ração, os dados a serem garantidos são passados através da primeira ope- ração de criptografia, dados seguros = dados XOR chave secreta 5:

S = D XOR K5.

A fim de armazenar com segurança os dados criptografados re- sultantes, por exemplo, em quatro compartilhamentos, S1, S2, S3, Sn, os dados são analisados e divididos em "n" segmentos, ou compartilhamentos, de acordo com o valor de K5. Essa operação resulta em "n" compartilhamen- tos pseudoaleatórios dos dados criptografados originais. As funções XOR subseqüentes podem então ser executadas em cada compartilhamento com os valores de chave secreta restantes, por exemplo: segmento de dados seguro 1 = compartilhamento de dados criptografados 1 XOR chave secreta 1:

SD1 = S1 XOR K1

SD2 = S2 XOR K2

SD3 = S3 XOR K3

SDn = SnXORKn.

Em uma modalidade, pode não ser desejado ter qualquer um depositário contendo informação suficiente para decriptografar a informação mantida nele, então a chave requerida para decriptografar o compartilha- mento é armazenada em um depositário de dados diferente:

Depositário 1: SD1, Kn

Depositário 2: SD2, K1

Depositário 3: SD3, K2

Depositário n: SDn, K3.

Adicionalmente, anexa a cada compartilhamento pode estar a informação requerida para recuperar a chave de criptografia da sessão origi- nal, K5. Portanto, no exemplo de gerenciamento de chave descrito aqui, a chave-mestre da sessão original é citada por um ID de transação dividido em "n" compartilhamentos de acordo com os conteúdos da chave-mestre do analisador dependente da instalação (TID1, TID2, TID3, TIDn):

Depositário 1: SD1, Kn, TID1

Depositário 2: SD2, K1, TID2 Depositário 3: SD3, K2, TID3 Depositário η: SDn1 K3, TIDn.

No exemplo da chave de sessão incorporada descrito aqui, a chave-mestre da sessão é dividida em "n" compartilhamentos de acordo com os conteúdos da chave-mestre do analisador dependente da instalação (SK1, SK2, SK3, SKn):

Depositário 1: SD1, Kn1 SK1 Depositário 2: SD2, K1, SK2 Depositário 3: SD3, K2, SK3 Depositário n: SDn, K3, SKn.

A menos que todos os quatro compartilhamentos sejam recupe- rados, os dados não podem ser remontados de acordo com esse exemplo. Mesmo se todos os quatro compartilhamentos são capturados, não existe possibilidade de remontar ou restaurar a informação original sem acesso à chave-mestre da sessão e à chave-mestre do analisador.

Esse exemplo descreveu uma modalidade do método da pre- sente invenção, e também descreve, em uma outra modalidade, o algoritmo usado para colocar compartilhamentos em depositários de modo que os compartilhamentos de todos os depositários podem ser combinados para formar o material de autenticação secreto. As computações necessárias são muito simples e rápidas. Entretanto, com o algoritmo de enchimento de um tempo (OTP) podem existir circunstâncias que fazem com que ele seja me- nos desejável, tal como um grande conjunto de dados a ser garantido, por- que o tamanho da chave é do mesmo tamanho que os dados a serem arma- zenados. Portanto, existiria a necessidade de armazenar e transmitir apro- ximadamente duas vezes a quantidade dos dados originais, o que pode ser menos desejável sob certas circunstâncias.

Cifra de fluxo RS1

A técnica de divisão da cifra de fluxo RS1 é muito similar à téc- nica de divisão do OTP descrito aqui. Em vez de um valor aleatório de η by- te, um valor aleatório de n1 = min(n, 16)-byte é gerado e usado para prover de chave o algoritmo da cifra de fluxo RS1. A vantagem do algoritmo da cifra de fluxo RS1 é que uma chave pseudoaleatória é gerada a partir de um nú- mero semente muito menor. A velocidade de execução da criptografia da cifra de fluxo RS1 é também avaliada em aproximadamente 10 vezes a ve- locidade da criptografia DES tripla bem-conhecida na técnica sem compro- meter a segurança. O algoritmo da cifra de fluxo RS1 é bem-conhecido na técnica e pode ser usado para gerar as chaves usadas na função XOR. O algoritmo da cifra de fluxo RS1 é interoperável com outros algoritmos de cifra de fluxo comercialmente disponíveis, tal como o algoritmo da cifra de fluxo RC4® de RSA Security1 Inc. e é adequado para uso nos métodos da presen- te invenção.

Usando a notação de chave acima, K1 até K5 são agora valores aleatórios de n' byte e estabeleceu-se:

SD1 = S1 XOR E(K1)

SD2 = S2 XOR E(K2)

SD3 = S3 XOR E(K3)

SDn = Sn XOR E(Kn)

onde E(K1) até E(Kn) são os primeiros n' bytes de saída do al- goritmo da cifra de fluxo RS1 provido de chave por K1 até Kn. Os comparti- lhamentos são agora colocados em depositários de dados como descrito aqui.

Nesse algoritmo da cifra de fluxo RS1, as computações requeri- das necessárias são quase tão simples e rápidas quanto o algoritmo OTP. O benefício nesse exemplo usando a cifra de fluxo RS1 é que o sistema preci- sa armazenar e transmitir na média somente aproximadamente 16 bytes a mais do que o tamanho dos dados originais a serem garantidos por compar- tilhamento. Quando o tamanho dos dados originais é mais do que 16 bytes, esse algoritmo RS1 é mais eficiente do que o algoritmo OTP porque ele é simplesmente mais curto. É facilmente evidente para aqueles versados na técnica que uma ampla variedade de métodos de criptografia ou algoritmos é adequada para uso na presente invenção, incluindo, mas não-limitado a RS1, OTP, RC4®, DES triplo e AES.

Existem vantagens principais providas pelos métodos de segu- rança de dados e sistemas de computador da presente invenção sobre os métodos tradicionais de criptografia. Uma vantagem é a segurança obtida pelo movimento dos compartilhamentos dos dados para localizações diferen- tes em um ou mais depositários de dados ou dispositivos de armazenamen- to, que podem estar em localizações lógicas, físicas ou geográficas diferen- tes. Quando os compartilhamentos dos dados são divididos fisicamente e sob o controle de pessoal diferente, por exemplo, a possibilidade de com- prometer os dados é grandemente reduzida.

Uma outra vantagem provida pelos métodos e sistema da pre- sente invenção é a combinação das etapas do método da presente invenção para garantia de dados para prover um processo abrangente de manutenção da segurança dos dados sensíveis. Os dados são criptografados com uma chave segura e divididos em um ou mais compartilhamentos, e em uma mo- dalidade, quatro compartilhamentos, de acordo com a chave segura. A cha- ve segura é armazenada com segurança com um ponteiro de referência que é garantido em quatro compartilhamentos de acordo com uma chave segura. Os compartilhamentos de dados são então criptografados individualmente e as chaves são armazenadas com segurança com compartilhamentos cripto- grafados diferentes. Quando combinado, todo o processo para garantia dos dados de acordo com os métodos descritos aqui se torna um pacote abran- gente para a segurança dos dados.

Os dados garantidos de acordo com os métodos da presente in- venção são facilmente recuperáveis e restaurados, reconstituídos, remonta- dos, decriptografados ou de alguma forma retornados para sua forma origi- nal ou outra adequada para uso. A fim de restaurar os dados originais, os itens seguintes podem ser utilizados:

1. Todos os compartilhamentos ou porções do conjunto de da- dos.

2. Conhecimento de e capacidade de reproduzir o fluxo do pro- cesso do método usado para garantir os dados.

3. Acesso à chave-mestre da sessão.

4. Acesso à chave-mestre do analisador. Portanto, pode ser desejável planejar uma instalação segura onde pelo menos um dos elementos acima pode ser fisicamente separado dos componentes restantes do sistema (sob o controle de um administrador do sistema diferente, por exemplo).

A proteção contra uma aplicação perigosa invocando a aplica- ção dos métodos de segurança de dados pode ser forçada pelo uso da cha- ve-mestre do analisador. Um sinal de estabelecimento de comunicação de autenticação mútuo entre o analisador de dados seguro e a aplicação pode ser necessário nessa modalidade da presente invenção antes de qualquer ação adotada.

A segurança do sistema dita que não existe método de "porta dos fundos" para a recriação dos dados originais. Para instalações onde questões de recuperação de dados podem surgir, o analisador de dados se- guro pode ser aperfeiçoado para prover um modelo dos quatro compartilha- mentos e depositário da chave-mestre da sessão. Opções de hardware tal como RAID (formação redundante de discos baratos, usada para difundir informação através de vários discos) e opções de software tal como replica- ção podem auxiliar também no planejamento da recuperação dos dados.

Gerenciamento da chave

Em uma modalidade da presente invenção, o método de garan- tia dos dados usa três conjuntos de chaves para uma operação de criptogra- fia. Cada conjunto de chaves pode ter armazenamento de chave individual, recuperação, opções de segurança e recuperação, com base na instalação.

As chaves que podem ser usadas incluem, mas não são limitadas a:

A chave-mestre do analisador

Essa chave é uma chave individual associada com a instalação do analisador de dados seguro. Ela é instalada no servidor no qual o anali- sador de dados seguro foi disposto. Existe uma variedade de opções ade- quadas para garantir essa chave incluindo, mas não-limitado a, um cartão inteligente, memória de chave de hardware separada, memórias de chave padrão, memórias de chave sob encomenda ou dentro de uma tabela de banco de dados segura, por exemplo. A chave-mestre da sessão

Uma chave-mestre da sessão pode ser gerada toda vez que os dados são garantidos. A chave-mestre da sessão é usada para criptografar os dados antes das operações de análise e divisão. Ela pode também ser incorporada (se a chave-mestre da sessão não está integrada nos dados analisados) como um meio de análise dos dados criptografados. A chave- mestre da sessão pode ser garantida em uma variedade de maneiras, inclu- indo, mas não-limitado a, uma memória de chave padrão, memória de chave sob encomenda, tabela do banco de dados separada ou garantida dentro dos compartilhamentos criptografados, por exemplo.

As chaves de criptografia do compartilhamento

Para cada compartilhamento ou porções de um conjunto de da- dos que é criado, uma chave de criptografia de compartilhamento individual pode ser gerada para também criptografar os compartilhamentos. As chaves de criptografia do compartilhamento podem ser armazenadas em comparti- lhamentos diferentes do que o compartilhamento que foi criptografado.

É facilmente evidente para aqueles versados na técnica que os métodos de garantia de dados e sistema de computador da presente inven- ção são amplamente aplicáveis em qualquer tipo de dados em qualquer co- locação ou ambiente. Além das aplicações comerciais conduzidas através da Internet ou entre consumidores e fornecedores, os métodos de garantia de dados e sistemas de computador da presente invenção são altamente aplicáveis em colocações ou ambientes não comerciais ou particulares. Qualquer conjunto de dados onde é desejado que o mesmo seja mantido seguro contra qualquer usuário desautorizado pode ser garantido usando os métodos e os sistemas descritos aqui. Por exemplo, o acesso a um banco de dados particular dentro de uma companhia ou organização pode ser van- tajosamente restrito a somente usuários selecionados utilizando os métodos e os sistemas da presente invenção para garantir os dados. Um outro exem- pio é a geração, modificação ou acesso a documentos onde é desejado res- tringir o acesso ou impedir acesso ou descrição desautorizada ou acidental fora de um grupo de indivíduos, computadores ou estações de trabalho sele- cionados. Esses e outros exemplos das maneiras nas quais os métodos e os sistemas de garantia de dados da presente invenção são aplicáveis em qualquer ambiente ou colocação não comercial ou comercial para qualquer colocação, incluindo, mas não-limitado a qualquer organização, agência do governo ou corporação.

Em uma outra modalidade da presente invenção, o método de garantia dos dados usa três conjuntos de chaves para uma operação de criptografia. Cada conjunto de chaves pode ter armazenamento de chave individual, recuperação, opções de segurança e recuperação, com base na instalação. As chaves que podem ser usadas incluem, mas não são limita- das a:

1. A chave-mestre do analisador

Essa chave é uma chave individual associada com a instalação do analisador de dados seguro. Ela é instalada no servidor no qual o anali- sador de dados seguro foi disposto. Existe uma variedade de opções ade- quadas para garantir essa chave incluindo, mas não-limitado a, um cartão inteligente, memória de chave de hardware separada, memórias de chave padrão, memórias de chave sob encomenda ou dentro de uma tabela de, banco de dados segura, por exemplo.

2. A chave-mestre da sessão

Uma chave-mestre da sessão pode ser gerada toda vez que os dados são garantidos. A chave-mestre da sessão é usada em conjunto com a chave-mestre do analisador para derivar a chave intermediária. A chave- mestre da sessão pode ser garantida em uma variedade de maneiras, inclu- indo, mas não-limitado a, uma memória de chave padrão, memória de chave sob encomenda, tabela do banco de dados separada ou garantida dentro dos compartilhamentos criptografados, por exemplo.

3. A chave intermediária

Uma chave intermediária pode ser gerada toda vez que os da- dos são garantidos. A chave intermediária é usada para criptografar os da- dos antes da operação de análise e divisão. Ela pode também ser incorpo- rada como um meio de análise dos dados criptografados. 4. As chaves de criptografia do compartilhamento Para cada compartilhamento ou porções de um conjunto de da- dos que é criada, uma chave de criptografia de compartilhamento individual pode ser gerada para também criptografar os compartilhamentos. As chaves de criptografia do compartilhamento podem ser armazenadas em comparti- lhamentos diferentes do que o compartilhamento que foi criptografado.

É facilmente evidente para aqueles versados na técnica que os métodos de garantia dos dados e sistema de computador da presente inven- ção são amplamente aplicáveis em qualquer tipo de dados em qualquer co- locação ou ambiente. Além das aplicações comerciais conduzidas através da Internet ou entre clientes e fornecedores, os métodos de garantia de da- dos e sistemas de computador da presente invenção são altamente aplicá- veis em colocações ou ambientes não comerciais ou particulares. Qualquer conjunto de dados onde é desejado que o mesmo seja mantido seguro con- tra qualquer usuário desautorizado pode ser garantido usando os métodos e os sistemas descritos aqui. Por exemplo, o acesso a um banco de dados particular dentro de uma companhia ou organização pode ser vantajosamen- te restrito a somente usuários selecionados utilizando os métodos e os sis- temas da presente invenção para garantir os dados. Um outro exemplo é a geração, modificação ou acesso a documentos onde é desejado restringir o acesso ou impedir acesso ou descrição desautorizada ou acidental fora de um grupo de indivíduos, computadores ou estações de trabalho seleciona- dos. Esses e outros exemplos das maneiras nas quais os métodos e os sis- temas de garantia de dados da presente invenção são aplicáveis em qual- quer ambiente ou colocação não comercial ou comercial para qualquer colo- cação, incluindo, mas não-limitado a qualquer organização, agência do go- verno ou corporação.

Segurança de dados de grupo de trabalho, projeto. PC individu- al/laptop ou de plataforma cruzada Os métodos de garantia de dados e sistemas de computador da presente invenção são também úteis na garantia dos dados pelo grupo de trabalho, projeto, PC individual/laptop e qualquer outra plataforma que esteja em uso, por exemplo, em negócios, escritórios, agências do governo ou qualquer colocação na qual dados sensíveis são criados, manipulados ou armazenados. A presente invenção provê métodos e sistemas de computa- dor para garantir os dados que são conhecidos por serem pesquisados pelas organizações, tal como o governo os Estados Unidos., para implementação através de toda a organização do governo ou entre governos em um nível estadual ou federal.

Os métodos de garantia dos dados e sistemas de computador da presente invenção provêem a capacidade de não somente analisar e di- vidir arquivos simples, mas também campos de dados, conjuntos e ou tabe- las de qualquer tipo. Adicionalmente, todas as formas de dados podem ser garantidas sob esse processo, incluindo, mas não-limitado a texto, vídeo, imagens, biométrica e dados de voz. A capacidade de escalação, a veloci- dade e a passagem de dados dos métodos de garantia de dados da presen- te invenção são somente limitadas ao hardware que o usuário tem à sua disposição.

Em uma modalidade da presente invenção, os métodos de ga- rantia de dados são utilizados como descrito abaixo em um ambiente de grupo de trabalho. Em uma modalidade, como mostrado na figura 23 e des- crito abaixo, o método de garantia de dados em escala do grupo de trabalho da presente invenção usa a funcionalidade de gerenciamento de chave pri- vada do mecanismo de confiança para armazenar as relações de usuá- rio/grupo e as chaves privadas associadas (chaves-mestre do grupo do ana- lisador) necessárias para um grupo de usuários compartilhar dados seguros. O método da presente invenção tem a capacidade de garantir dados para uma empresa, grupo de trabalho ou usuário individual, dependendo de como a chave-mestre do analisador foi disposta.

Em uma modalidade, o gerenciamento de chave adicional e os programas de gerenciamento de usuário/grupo podem ser providos, possibi- litando a implementação do grupo de trabalho em ampla escala com um úni- co ponto de administração e gerenciamento de chave. A geração, o gerenci- amento e a revogação da chave são manipulados pelo programa de manu- tenção único, que todos se tornam especialmente importantes à medida que o número de usuários aumenta. Em uma outra modalidade, o gerenciamento da chave pode também ser configurado através de um ou vários administra- dores de sistemas diferentes, que podem não permitir que qualquer pessoa ou grupo controle os dados como necessário. Isso permite que o gerencia- mento de dados seguro seja obtido por funções, responsabilidades, associa- ção, direitos, etc., como definido por uma organização, e o acesso aos da- dos seguros pode ser limitado a apenas esses que têm permissão ou que solicitam ter acesso somente à porção na qual eles estão trabalhando, en- quanto outros, tais como gerentes ou executivos, podem ter acesso a todos os dados seguros. Essa modalidade permite o compartilhamento de dados seguros entre grupos diferentes dentro de uma companhia ou organização enquanto ao mesmo tempo somente permitindo que certos indivíduos sele- cionados, tal como esses com as funções e responsabilidades autorizadas e predeterminadas, observem os dados como um todo. Além disso, essa mo- dalidade dos métodos e sistemas da presente invenção também permite o compartilhamento de dados entre, por exemplo, companhias separadas ou departamentos ou divisões separadas de companhias, ou quaisquer depar- tamentos de organização, grupos, agências ou escritórios separados, ou similares, de qualquer governo ou organização ou qualquer tipo, onde algum compartilhamento é requerido, mas não qualquer parte interessada pode ter permissão de acesso a todos os dados. Exemplos particularmente evidentes da necessidade e utilidade para um tal método e sistema da presente inven- ção são para permitir o compartilhamento, porém manter a segurança, entre áreas de governo, agências e escritórios, e entre divisões, departamentos ou escritórios diferentes de uma grande companhia ou qualquer outra organiza- ção, por exemplo.

Um exemplo da aplicabilidade dos métodos da presente inven- ção em uma escala menor é como segue. Uma chave-mestre do analisador é usada como uma seriação ou marcação do analisador de dados seguros para uma organização. À medida que a escala de uso da chave-mestre do analisador é reduzida de toda a empresa para um grupo de trabalho menor, os métodos de garantia de dados descritos aqui são usados para comparti- lhar arquivos dentro de grupos de usuários.

No exemplo mostrado na figura 25 e descrito abaixo, existem seis usuários definidos junto com seu título ou função dentro da organização.

A barra lateral representa cinco grupos possíveis que os usuários podem pertencer de acordo com sua função. A seta representa a associação pelo usuário em um ou mais dos grupos.

Quando configurando o analisador de dados seguro para uso nesse exemplo, o administrador do sistema acessa a informação do usuário e grupo a partir do sistema operacional por um programa de manutenção. Esse programa de manutenção gera e atribui chaves-mestre do grupo do analisador para usuários com base na sua associação nos grupos.

Nesse exemplo, existem três membros do grupo de assessoria sênior. Para esse grupo, as ações seriam:

1. Acessar a chave-mestre do grupo do analisador para o grupo de assessoria sênior (gerar uma chave se não disponível).

2. Gerar um certificado digital associando CEO com o grupo de assessoria sênior.

3. Gerar um certificado digital associando CFO com o grupo de assessoria sênior.

4. Gerar um certificado digital associando vice-presidente, mer- cadologia com o grupo de assessoria sênior.

O mesmo conjunto de ações seria feito para cada grupo e cada membro dentro de cada grupo. Quando o programa de manutenção está completo, a chave-mestre do grupo do analisador se torna uma credencial compartilhada para cada membro do grupo. A revogação do certificado digi- tal atribuído pode ser feita automaticamente quando um usuário é removido de um grupo através do programa de manutenção sem afetar os membros restantes do grupo.

Depois que as credenciais compartilhadas foram definidas, o processo de análise e divisão permanece o mesmo. Quando um arquivo, documento ou elemento de dados é para ser garantido, o usuário é prepara- do para o grupo-alvo para ser usado quando garantindo os dados. Os dados garantidos resultantes ficam somente acessíveis por outros membros do grupo-alvo. Essa funcionalidade dos métodos e sistemas da presente inven- ção pode ser usada com qualquer outro sistema de computador ou platafor- ma de software, qualquer um pode ser, por exemplo, integrado em progra- mas de aplicação existentes ou usado independente para a segurança do arquivo.

É facilmente evidente para aqueles versados na técnica que qualquer um ou combinação de algoritmos de criptografia são adequados para uso nos métodos e sistemas da presente invenção. Por exemplo, as etapas de criptografia podem ser repetidas, em uma modalidade, para pro- duzir um esquema de criptografia de múltiplas camadas. Além disso, um al- goritmo de criptografia diferente, ou combinação de algoritmos de criptogra- fia, pode ser usado na repetição das etapas de criptografia tal que diferentes algoritmos de criptografia são aplicados nas camadas diferentes do esque- ma de criptografia de múltiplas camadas. Como tal, o próprio esquema de criptografia pode se tornar um componente dos métodos da presente inven- ção para garantir os dados sensíveis contra o uso ou acesso desautorizado.

O analisador de dados seguro pode incluir como um componen- te interno, como um componente externo ou como ambos, um componente de verificação de erro. Por exemplo, em uma abordagem adequada, quando porções de dados são criadas usando o analisador de dados seguro de a- cordo com a presente invenção, para garantir a integridade dos dados dentro de uma porção, um valor de prova é tirado em intervalos preestabelecidos dentro da porção e é anexado no fim do intervalo. O valor de prova é uma representação numérica previsível e reprodutível dos dados. Se qualquer bit dentro dos dados muda, o valor de prova seria diferente. Um módulo de var- redura (como um componente independente externo ao analisador de dados seguro ou como um componente interno) pode então varrer as porções dos dados geradas pelo analisador de dados seguro. Cada porção dos dados (ou alternativamente, menos do que todas as porções dos dados de acordo com algum intervalo ou por uma amostragem aleatória ou pseudoaleatória) é comparada com o valor ou valores de prova anexos e uma ação pode ser empreendida. Essa ação pode incluir um relatório de valores que combinam e não combinam, um alerta para valores que não combinam ou invocação de algum programa externo ou interno para disparar uma recuperação dos da- dos. Por exemplo, a recuperação dos dados poderia ser executada invocan- do um módulo de recuperação com base no conceito que menos do que to- das as porções podem ser necessárias para gerar os dados originais de a- cordo com a presente invenção.

Qualquer outra verificação de integridade adequada pode ser implementada usando qualquer informação de integridade adequada anexa- da em qualquer lugar em todas ou um subconjunto de porções de dados. A informação de integridade pode incluir qualquer informação adequada que pode ser usada para determinar a integridade das porções dos dados. E- xemplos da informação de integridade podem incluir valores de prova calcu- lados com base em qualquer parâmetro adequado (por exemplo, com base em porções de dados respectivas), informação de assinatura digital, a infor- mação do código de autenticação da mensagem (MAC), qualquer outra in- formação adequada ou qualquer combinação desses.

O analisador de dados seguro da presente invenção pode ser usado em qualquer aplicação adequada. A saber, o analisador de dados se- guro descrito aqui tem uma variedade de aplicações em áreas diferentes de computação e tecnologia. Várias tais áreas são discutidas abaixo. Será en- tendido que essas são meramente ilustrativas por natureza e que quaisquer outras aplicações adequadas podem fazer uso do analisador de dados segu- ro. Também será entendido que os exemplos descritos são modalidades meramente ilustrativas que podem ser modificadas de qualquer maneira a- dequada a fim de satisfazer quaisquer desejos adequados. Por exemplo, a análise e a divisão podem ser baseadas em quaisquer unidades adequadas, tal como por bits, por bytes, por quilobytes, por megabytes, por qualquer combinação desses ou por qualquer outra unidade adequada.

O analisador de dados seguro da presente invenção pode ser usado para implementar fichas físicas seguras, por meio do que os dados armazenados em uma ficha física podem ser requeridos a fim de acessar os dados adicionais armazenados em uma outra área de armazenamento. Em uma abordagem adequada, uma ficha física, tal como uma unidade flash USB compacta, um disquete, um disco ótico, um cartão inteligente ou qual- quer outra ficha física adequada, pode ser usada para armazenar uma de pelo menos duas porções dos dados analisados de acordo com a presente invenção. A fim de acessar os dados originais, a unidade flash USB precisa- ria ser acessada. Assim, um computador pessoal mantendo uma porção dos dados analisados precisaria ter a unidade flash USB, tendo a outra porção dos dados analisados, anexada antes que os dados originais possam ser acessados. A figura 26 ilustra essa aplicação. A área de armazenamento 2500 inclui uma porção dos dados analisados 2502. A ficha física 2504, ten- do uma porção dos dados analisados 2506 precisaria ser acoplada na área de armazenamento 2500 usando qualquer interface de comunicações ade- quada 2508 (por exemplo, USB, serial, paralelo, Bluetooth, IR, IEEE 1394, Ethernet ou qualquer outra interface de comunicações adequada) a fim de acessar os dados originais. Isso é útil em uma situação onde, por exemplo, dados sensíveis em um computador são deixados sozinhos e sujeitos às tentativas de acesso desautorizado. Pela remoção da ficha física (por exem- pio, a unidade flash USB), os dados sensíveis ficam inacessíveis. Será en- tendido que qualquer outra abordagem adequada para uso de fichas físicas pode ser usada.

O analisador de dados seguro da presente invenção pode ser usado para implementar um sistema de autenticação seguro por meio do qual os dados de inscrição do usuário (por exemplo, senhas, chaves de crip- tografia privadas, modelos de impressão digital, dados biométricos ou quais- quer outros dados de inscrição do usuário adequados) são analisados e di- vididos usando o analisador de dados seguro. Os dados de inscrição do u- suário podem ser analisados e divididos, por meio disso uma ou mais por- ções são armazenadas em um cartão inteligente, um cartão de acesso co- mum do governo, qualquer dispositivo de armazenamento físico adequado (por exemplo, disco magnético ou ótico, unidade de chave USB, etc.) ou qualquer outro dispositivo adequado. Uma ou mais outras porções dos da- dos da inscrição do usuário analisados podem ser armazenadas no sistema que executa a autenticação. Isso provê um nível adicional de segurança ao processo de autenticação (por exemplo, além da informação de autenticação biométrica obtida da fonte biométrica, os dados da inscrição do usuário de- vem também ser obtidos via a porção de dados analisada e dividida apropri- ada).

O analisador de dados seguro da presente invenção pode ser in- tegrado em qualquer sistema existente adequado a fim de prover o uso da sua funcionalidade no ambiente respectivo em cada sistema. A figura 27 mostra um diagrama de blocos de um sistema ilustrativo 2600, que pode incluir software, hardware ou ambos para implementar qualquer aplicação adequada. O sistema 2600 pode ser um sistema existente no qual o analisa- dor de dados seguro 2602 pode ser retroajustado como um componente in- tegrado. Alternativamente, o analisador de dados seguro 2602 pode ser in- tegrado em qualquer sistema adequado 2600, por exemplo, do seu estágio de projeto mais anterior. O analisador de dados seguro 2600 pode ser inte- grado em qualquer nível adequado de sistema 2600. Por exemplo, o anali- sador de dados seguro 2602 pode ser integrado no sistema 2600 em um nível de segundo plano ("back-end") suficiente tal que a presença do anali- sador de dados seguro 2602 pode ser substancialmente transparente para um usuário final do sistema 2600. O analisador de dados seguro 2602 pode ser usado para analisar e dividir os dados entre um ou mais dispositivos de armazenamento 2604 de acordo com a presente invenção. Alguns exemplos ilustrativos dos sistemas tendo o analisador de dados seguro integrado nele são discutidos abaixo.

O analisador de dados seguro da presente invenção pode ser in- tegrado em um núcleo do sistema operacional (por exemplo, Linux, Unix ou qualquer outro sistema operacional comercial ou proprietário adequado). Essa integração pode ser usada para proteger os dados no nível do disposi- tivo, por meio do que, por exemplo, os dados que seriam ordinariamente ar- mazenados em um ou mais dispositivos são separados em um certo número de porções pelo analisador de dados seguro integrado no sistema operacio- nal e armazenado entre o um ou mais dispositivos. Quando se tenta acessar os dados originais, o software apropriado, também integrado no sistema o- peracional, pode recombinar as porções dos dados analisados nos dados originais em uma maneira que pode ser transparente para o usuário final.

O analisador de dados seguro da presente invenção pode ser in- tegrado em um gerenciador de volume ou qualquer outro componente ade- quado de um sistema de armazenamento para proteger o armazenamento de dados local e em rede através de qualquer uma ou todas as plataformas suportadas. Por exemplo, com o analisador de dados seguro integrado, um sistema de armazenamento pode fazer uso da redundância oferecida pelo analisador de dados seguro (isto é, que é usado para implementar o aspecto de necessidade de menos do que todas as porções separadas dos dados a fim de reconstruir os dados originais) para proteger contra a perda de dados. O analisador de dados seguro também permite que todos os dados escritos em dispositivos de armazenamento, quer usando redundância ou não, fi- quem na forma de porções múltiplas que são geradas de acordo com a aná- lise da presente invenção. Quando se tenta acessar os dados originais, o; software apropriado, também integrado no gerenciador de volume ou outro componente adequado do sistema de armazenamento, pode recombinar as porções de dados analisadas nos dados originais em uma maneira que pode ser transparente para o usuário final.

Em uma abordagem adequada, o analisador de dados seguro da presente invenção pode ser integrado em um controlador RAID (como hardware ou software). Isso permite o armazenamento seguro dos dados em múltiplas unidades enquanto mantendo a tolerância à falha no caso de falha da unidade.

O analisador de dados seguro da presente invenção pode ser in- tegrado em um banco de dados a fim de, por exemplo, proteger a informa- ção da tabela sensível. Por exemplo, em uma abordagem adequada, os da- dos associados com células particulares de uma tabela do banco de dados (por exemplo, células individuais, uma ou mais colunas particulares, uma ou mais linhas particulares, qualquer combinação dessas ou toda uma tabela do banco de dados) podem ser analisados e separados de acordo com a pre- sente invenção (por exemplo, onde as porções diferentes são armazenadas em um ou mais dispositivos de armazenamento em uma ou mais localiza- ções ou em um único dispositivo de armazenamento). O acesso para re- combinar as porções a fim de ver os dados originais pode ser concedido por métodos de autenticação tradicionais (por exemplo, consulta de nome de usuário e senha).

O analisador seguro da presente invenção pode ser integrado em qualquer sistema adequado que envolva dados em movimento (isto é, transferência de dados de uma localização para outra). Tais sistemas inclu- em, por exemplo, e-mail, transferência contínua de difusões de dados e co- municações sem fio (por exemplo, WiFi). Com relação ao e-mail, em uma abordagem adequada, o analisador seguro pode ser usado para analisar as mensagens que saem (isto é, contendo texto, dados binários ou ambos (por exemplo, arquivos anexados em uma mensagem de e-mail)) e enviar as porções diferentes dos dados analisados ao longo de trajetórias diferentes assim criando múltiplos fluxos de dados. Se qualquer um desses fluxos de dados é comprometido, a mensagem original permanece segura porque o sistema pode requerer que mais do que uma das porções seja combinada, de acordo com a presente invenção, a fim de gerar os dados originais. Em uma outra abordagem adequada, as porções diferentes dos dados podem ser comunicadas ao longo de uma trajetória seqüencialmente de modo que se uma porção é obtida, ela pode não ser suficiente para gerar os dados ori- ginais. As porções diferentes chegam na localização do receptor planejado e podem ser combinadas para gerar os dados originais de acordo com a pre- sente invenção.

As figuras 28 e 29 são diagramas de bloco ilustrativos de tais sistemas de e-mail. A figura 28 mostra um sistema de remetente 2700, que pode incluir qualquer hardware adequado, tais como um terminal de compu- tador, computador pessoal, dispositivo portátil (por exemplo, PDA, Blackber- ry), telefone celular, rede de computador, qualquer outro hardware adequado ou qualquer combinação desses. O sistema do remetente 2700 é usado para gerar e/ou armazenar uma mensagem 2704, que pode ser, por exemplo, uma mensagem de e-mail, um arquivo de dados binário (por exemplo, gráfi- co, voz, vídeo, etc.) ou ambos. A mensagem 2704 é analisada e dividida pe- lo analisador de dados seguro 2702 de acordo com a presente invenção. As porções de dados resultantes podem ser comunicadas através de uma ou mais trajetórias de comunicações separadas 2706 através da rede 2708 (por exemplo, a Internet, uma intranet, uma LAN, WiFi, Bluetooth, qualquer outro meio de comunicações adequado ligado ou sem fio ou qualquer combinação desses) no sistema receptor 2710. As porções de dados podem ser comuni- cadas paralelamente no tempo ou alternativamente, de acordo com qualquer retardo de tempo adequado entre a comunicação das porções diferentes dos dados. O sistema do receptor 271Ò pode ser de qualquer hardware adequa- do como descrito acima com relação ao sistema do remetente 2700. As por- ções de dados separadas transportadas ao longo das trajetórias de comuni- cações 2706 são recombinadas no sistema do receptor 2710 para gerar a mensagem original ou os dados de acordo com a presente invenção.

A figura 29 mostra um sistema do remetente 2800, que pode in- cluir qualquer hardware adequado, tais como um terminal de computador, computador pessoal, dispositivo portátil (por exemplo, PDA), telefone celular, rede de computador, qualquer outro hardware adequado ou qualquer combi- nação desses. O sistema do remetente 2800 é usado para gerar e/ou arma- zenar uma mensagem 2804, que pode ser, por exemplo, uma mensagem de e-mail, um arquivo de dados binário (por exemplo, gráficos, voz, vídeo, etc.) ou ambos. A mensagem 2804 é analisada e dividida pelo analisador de da- dos seguro 2802 de acordo com a presente invenção. As porções de dados resultantes podem ser comunicadas através de uma única trajetória de co- municações 2806 através da rede 2808 (por exemplo, a Internet, uma intra- net, uma LAN, WiFi, Bluetooth, qualquer outro meio de comunicações ade- quado ou qualquer combinação desses) para o sistema do receptor 2810. As porções de dados podem ser comunicadas de maneira serial através da tra- jetória de comunicações 2806 com relação uma a outra. O sistema do recep- tor 2810 pode ser qualquer hardware adequado como descrito acima com relação ao sistema do remetente 2800. As porções de dados separadas transportadas ao longo da trajetória de comunicações 2806 são recombina- das no sistema do receptor 2810 para gerar a mensagem original ou os da- dos de acordo com a presente invenção.

Será entendido que a disposição das figuras 28 e 29 é mera- mente ilustrativa. Qualquer outra disposição adequada pode ser usada. Por exemplo, em uma outra abordagem adequada, os aspectos dos sistemas das figuras 28 e 29 podem ser combinados, por meio do que a abordagem de múltiplas trajetórias da figura 28 é usada e na qual uma ou mais das traje- tórias de comunicações 2706 são usadas para transportar mais do que uma porção dos dados como a trajetória de comunicações 2806 faz no contexto da figura 29.

O analisador de dados seguro pode ser integrado em qualquer nível adequado de um sistema de dados em movimento. Por exemplo, no contexto de um sistema de e-mail, o analisador seguro pode ser integrado no nível da interface do usuário (por exemplo, no Microsoft® Outlook), em cujo caso o usuário pode ter controle sobre o uso dos aspectos do analisa- dor de dados seguro quando usando o e-mail. Alternativamente, o analisador seguro pode ser implementado em um componente de segundo plano tal como no servidor de troca, em cujo caso as mensagens podem ser automa- ticamente analisadas, divididas e comunicadas ao longo de trajetórias dife- rentes de acordo com a presente invenção sem qualquer intervenção do u- suário.

Similarmente, no caso da transferência contínua de difusões de dados (por exemplo, áudio, vídeo), os dados que saem podem ser analisa- dos e separados em múltiplos fluxos, cada um contendo uma porção dos dados analisados. Os múltiplos fluxos podem ser transmitidos ao longo de uma ou mais trajetórias e recombinados na localização do receptor de acor- do com a presente invenção. Um dos benefícios dessa abordagem é que ela evita a codificação extra relativamente grande associada com a criptografia tradicional de dados seguida pela transmissão dos dados criptografados a- través de um único canal de comunicações. O analisador seguro da presen- te invenção permite que os dados em movimento sejam enviados em múlti- plos fluxos paralelos, aumentando a velocidade e a eficiência.

Será entendido que o analisador de dados seguro pode ser inte- grado para a proteção de e a tolerância à falha de qualquer tipo de dados em movimento através de qualquer meio de transporte, incluindo, por exem- plo, conectado, sem fio ou físico. Por exemplo, aplicações de protocolo de voz através da Internet (VoIP) podem fazer uso do analisador de dados se- guro da presente invenção. O transporte de dados sem fio ou conectado de ou para quaisquer dispositivos de assistente digital pessoal (PDA) adequa- dos tal como Blackberries e SmartPhones pode ser garantido usando o ana- lisador de dados seguro da presente invenção. Comunicações usando pro- tocolos sem fio 802.11 para redes sem fio com base não hierárquica e de boca de conexão, comunicações de satélite, comunicações sem fio ponto a ponto, comunicações de cliente/servidor da Internet ou quaisquer outras co- municações adequadas podem envolver as capacidades dos dados em mo- vimento do analisador de dados seguro de acordo com a presente invenção. A comunicação de dados entre o dispositivo periférico do computador (por exemplo, impressora, scanner, monitor, teclado, roteador de rede, dispositivo de autenticação biométrica (por exemplo, scanner de impressão digital) ou qualquer outro dispositivo periférico adequado) entre um computador e um dispositivo periférico do computador, entre um dispositivo periférico do com- putador e qualquer outro dispositivo adequado ou qualquer combinação des- ses pode fazer uso dos aspectos dos dados em movimento da presente in- venção.

Os aspectos de dados em movimento da presente invenção po- dem também se aplicar ao transporte físico de compartilhamentos seguros usando, por exemplo, rotas separadas, veículos, métodos, qualquer outro transporte físico adequado ou qualquer combinação desses. Por exemplo, o transporte físico de dados pode acontecer em fitas digitais/magnéticas, dis- quetes, discos óticos, fichas físicas, unidades USB, unidades rígidas removí- veis, dispositivos eletrônicos do consumidor com memória flash (por exem- pio, IPODs Apple ou outros reprodutores de MP3), memória flash, qualquer outro meio adequado usado para transportar dados ou qualquer combinação desses.

O analisador de dados seguro da presente invenção pode pro- ver segurança com a capacidade para recuperação de desastre. De acordo com a presente invenção, menos do que todas as porções dos dados sepa- rados gerados pelo analisador de dados seguro pode ser necessária a fim de recuperar os dados originais. Isto é, dentre as m porções armazenadas, n pode ser o número mínimo dessas m porções necessárias para recuperar os dados originais, onde n <= m. Por exemplo, se cada uma das quatro porções é armazenada em uma localização física diferente em relação às outras três porções, então, se n=2 nesse exemplo, duas das localizações podem estar comprometidas, por meio do que os dados são destruídos ou ficam inaces- síveis, e os dados originais podem ainda ser recuperados das porções nas outras duas localizações. Qualquer valor adequado para n ou m pode ser usado.

Além disso, o aspecto n de m da presente invenção pode ser usado para criar uma "regra de dois homens", por meio do que a fim de evi- tar confiar em um único indivíduo ou qualquer outra entidade com acesso completo ao que podem ser dados sensíveis, duas ou mais entidades distin- tas, cada uma com uma porção dos dados separados analisados pelo anali- sador seguro da presente invenção, podem precisar concordar para colocar suas porções juntas a fim de recuperar os dados originais.

O analisador de dados seguro da presente invenção pode ser usado para prover um grupo de entidades com uma chave de grupo amplo que permite que os membros do grupo acessem informação particular auto- rizada para ser acessada por esse grupo particular. A chave do grupo pode ser uma das porções de dados geradas pelo analisador seguro de acordo com a presente invenção que pode ser requerida para ser combinada com uma outra porção centralmente armazenada, por exemplo, a fim de recupe- rar a informação buscada. Esse aspecto permite, por exemplo, a colabora- ção segura entre um grupo. Ele pode ser aplicado, por exemplo, em redes dedicadas, redes privadas virtuais, intranets ou qualquer outra rede adequa- da.

Aplicações específicas desse uso do analisador seguro incluem, por exemplo, compartilhamento de informação de coalizão na qual, por e- xemplo, forças de governo amistosas multinacionais são munidas com a ca- pacidade de comunicar dados operacionais e de outra forma sensíveis em um nível de segurança autorizado para cada país respectivo através de uma rede única ou uma rede dupla (isto é, quando comparado com as muitas re- des envolvendo processos manuais relativamente substanciais atualmente usados). Essa capacidade é também aplicável para companhias ou outras organizações nas quais a informação que deve ser conhecida por um ou mais indivíduos específicos (dentro da organização ou fora) pode ser comu- nicada através de uma rede única sem a necessidade de se preocupar com os indivíduos desautorizados vendo a informação.

Uma outra aplicação específica inclui uma hierarquia de segu- rança de múltiplos níveis para sistemas de governo. Isto é, o analisador se- guro da presente invenção pode proporcionar a capacidade de operar um sistema de governo em níveis diferentes de informação classificada (por e- xemplo, não classificada, classificada, secreta, ultra secreta) usando uma única rede. Se desejado, mais redes podem ser usadas (por exemplo, uma rede separada para ultra secreto), mas a presente invenção permite subs- tancialmente menos do que a disposição atual na qual uma rede separada é usada para cada nível de classificação.

Será entendido que qualquer combinação das aplicações acima descritas do analisador seguro da presente invenção pode ser usada. Por exemplo, a aplicação da chave de grupo pode ser usada junto com a aplica- ção de segurança dos dados em movimento (isto é, por meio do que os da- dos que são comunicados através de uma rede podem ser somente acessa- dos por um membro do grupo respectivo e onde, embora os dados estejam em movimento, eles são divididos entre múltiplas trajetórias (ou enviados em porções seqüenciais) de acordo com a presente invenção).

O analisador de dados seguro da presente invenção pode ser in- tegrado em qualquer aplicação middleware para possibilitar que as aplica- ções armazenem com segurança os dados em produtos de banco de dados diferentes ou em dispositivos diferentes sem modificação nas aplicações ou banco de dados. Middleware é um termo geral para qualquer produto que permite que dois programas separados e já existentes se comuniquem. Por exemplo, em uma abordagem adequada, o middleware tendo o analisador de dados seguro integrado pode ser usado para permitir que programas es- critos para um banco de dados particular se comuniquem com outros bancos de dados sem codificação personalizada.

O analisador de dados seguro da presente invenção pode ser implementado tendo qualquer combinação de quaisquer capacidades ade- quadas, tal como essas discutidas aqui. Em algumas modalidades da pre- sente invenção, por exemplo, o analisador de dados seguro pode ser imple- mentado tendo somente certas capacidades enquanto que outras capacida- des podem ser obtidas através do uso de software externo, hardware ou ambos em interface direta ou indiretamente com o analisador de dados se- guro.

A figura 30, por exemplo, mostra uma implementação ilustrativa do analisador de dados seguro como o analisador de dados seguro 3000. O analisador de dados seguro 3000 pode ser implementado com muito poucas capacidades embutidas. Como ilustrado, o analisador de dados seguro 3000 pode incluir capacidades embutidas para analisar e dividir os dados em por- ções (também citadas aqui como compartilhamentos) de dados usando o módulo 3002 de acordo com a presente invenção. O analisador de dados seguro 3000 pode também incluir capacidades embutidas para executar re- dundância a fim de ser capaz de implementar, por exemplo, o aspecto m de η descrito acima (isto é, recriar os dados originais usando menos do que to- dos os compartilhamentos dos dados analisados e divididos) usando o mó- dulo 3004. O analisador de dados seguro 3000 pode também incluir capaci- dades de distribuição de compartilhamento usando o módulo 3006 para co- locar os compartilhamentos de dados em armazenamentos temporários dos quais eles são enviados para comunicação para uma localização remota, para armazenamento, etc. de acordo com a presente invenção. Será enten- dido que quaisquer outras capacidades adequadas podem ser embutidas no analisador de dados seguro 3000.

O armazenamento temporário de dados montado 3008 pode ser qualquer memória adequada usada para armazenar os dados originais (em- bora não necessariamente na sua forma original) que será analisado e divi- dido pelo analisador de dados seguro 3000. Em uma operação de divisão, o armazenamento temporário de dados montado 3008 provê entrada para o analisador de dados seguro 3008. Em uma operação de restauração, o ar- mazenamento temporário dos dados montados 3008 pode ser usado para armazenar a saída do analisador de dados seguro 3000.

Armazenamentos temporários de compartilhamentos divididos 3010 podem ser um ou mais módulos de memória que podem ser usados para armazenar os múltiplos compartilhamentos de dados que resultaram da análise e divisão dos dados originais. Em uma operação de divisão, os ar- mazenamentos temporários dos compartilhamentos divididos 3010 mantêm a saída do analisador de dados seguro. Em uma operação de restauração, os armazenamentos temporários dos compartilhamentos divididos mantêm a entrada para o analisador de dados seguro 3000.

Será entendido que qualquer outra disposição adequada de ca- pacidades pode ser embutida para o analisador de dados seguro 3000. Quaisquer aspectos adicionais podem ser embutidos e qualquer um dos as- pectos ilustrados pode ser removido, feito mais robusto, feito menos robusto ou pode ser, de outra maneira, modificado em qualquer forma adequada. Os armazenamentos temporários 3008 e 3010 são da mesma forma meramente ilustrativos e podem ser modificados, removidos ou adicionados em qualquer maneira adequada.

Quaisquer módulos adequados implementados em software, hardware ou ambos podem ser chamados por ou podem chamar o analisa- dor de dados seguro 3000. Se desejado, até mesmo capacidades que são embutidas no analisador de dados seguro 3000 podem ser substituídas por um ou mais módulos externos. Como ilustrado, alguns módulos externos incluem gerador de número aleatório 3012, gerador de chave de realimenta- ção de cifra 3014, algoritmo de prova 3016, qualquer um ou mais tipos de criptografia 3018 e gerenciamento de chave 3020. Será entendido que esses são módulos externos meramente ilustrativos. Quaisquer outros módulos adequados podem ser usados além de ou no lugar desses ilustrados.

O gerador da chave de realimentação de cifra 3014 pode, exter- namente ao analisador de dados seguro 3000, gerar para cada operação de analisador de dados seguro, uma chave única, ou número aleatório (usando, por exemplo, o gerador de número aleatório 3012), a ser usado como um valor semente para uma operação que estende um tamanho de chave de sessão original (por exemplo, um valor de 128, 256, 512 ou 1024 bits) em um valor igual ao comprimento dos dados a serem analisados e divididos. Qualquer algoritmo adequado pode ser usado para a geração da chave de realimentação de cifra, incluindo, por exemplo, o algoritmo de geração de chave de realimentação de cifra AES.

A fim de facilitar a integração do analisador de dados seguro 3000 e seus módulos externos (isto é, camada do analisador de dados segu- ro 3026) em uma camada de aplicação 3024 (por exemplo, aplicação de e- mail, aplicação do banco de dados, etc.), uma camada de envoltório que po- de fazer uso de, por exemplo, chamadas de função API, pode ser usada. Qualquer outra disposição adequada para facilitar a integração da camada do analisador de dados seguro 3026 na camada de aplicação 3024 pode ser usada.

A figura 31 mostra de maneira ilustrativa como a disposição da figura 30 pode ser usada quando um comando de escrita (por exemplo, em um dispositivo de armazenamento), inserção (por exemplo, em um campo do banco de dados) ou transmissão (por exemplo, através de uma rede) é emitido na camada de aplicação 3024. Na etapa 3100 os dados a serem ga- rantidos são identificados e uma chamada é feita para o analisador de dados seguro. A chamada é passada através da camada de envoltório 3022 onde na etapa 3102, a camada de envoltório 3022 transfere de maneira contínua os dados de entrada identificados na etapa 3100 para o armazenamento temporário dos dados montados 3008. Também na etapa 3102, qualquer informação de compartilhamento adequada, nomes de arquivo, qualquer outra informação adequada ou qualquer combinação desses pode ser arma- zenada (por exemplo, como informação 3106 na camada de envoltório 3022). O processador de dados seguro 3000 então analisa e divide os dados que ele pega como entrada do armazenamento temporário de dados monta- do 3008 de acordo com a presente invenção. Ele produz como saída os compartilhamentos de dados em armazenamentos temporários de comparti- lhamentos divididos 3010. Na etapa 3104, a camada de envoltório 3022 ob- tém da informação armazenada 3106 qualquer informação de compartilha- mento adequada (isto é, armazenada pelo envoltório 3022 na etapa 3102) e localizações de compartilhamento (por exemplo, de um ou mais arquivos de configuração). A camada de envoltório 3022 então escreve os compartilha- mentos de saída (obtidos dos armazenamentos temporários dos comparti- lhamentos divididos 3010) apropriadamente (por exemplo, escrito em um ou mais dispositivos de armazenamento, comunicados sobre uma rede, etc.).

A figura 32 mostra de maneira ilustrativa como a disposição da figura 30 pode ser usada quando uma leitura (por exemplo, de um dispositi- vo de armazenamento), a seleção (por exemplo, de um campo do banco de dados) ou a recepção (por exemplo, de uma rede) ocorre. Na etapa 3200, os dados a serem restaurados são identificados e uma chamada para o anali- sador de dados seguro 3000 é feita da camada de aplicação 3024. Na etapa 3202, da camada de envoltório 3022, qualquer informação de compartilha- mento adequada é obtida e a localização do compartilhamento é determina- da. A camada do envoltório 3022 carrega as porções dos dados identificadas na etapa 3200 em armazenamentos temporários de compartilhamentos divi- didos 3010. O analisador de dados seguro 3000 então processa esses com- partilhamentos de acordo com a presente invenção (por exemplo, se somen- te três de quatro compartilhamentos estão disponíveis, então as capacida- des de redundância do analisador de dados seguro 3000 podem ser usadas para restaurar os dados originais usando somente os três compartilhamen- tos). Os dados restaurados são então armazenados no armazenamento temporário de dados montado 3008. Na etapa 3204, a camada de aplicação 3022 converte os dados armazenados no armazenamento temporário de dados montado 3008 para o seu formato de dados original (se necessário) e prove os dados originais no seu formato original para a camada de aplicação 3024.

Será entendido que a análise e a divisão dos dados originais i- lustradas na figura 31 e a restauração das porções dos dados em dados ori- ginais ilustrada na figura 32 são meramente ilustrativas. Quaisquer outros processos adequados, componentes ou ambos podem ser usados além de ou no lugar desses ilustrados.

A figura 33 é um diagrama de blocos de um fluxo de processo i- lustrativo para analisar e dividir os dados originais em duas ou mais porções de dados de acordo com uma modalidade da presente invenção. Como ilus- trado, os dados originais que se deseja analisar e dividir é texto simples 3306 (isto é, a palavra "CUME" é usada como um exemplo). Será entendido que qualquer outro tipo de dados pode ser analisado e dividido de acordo com a presente invenção. Uma chave de sessão 3300 é gerada. Se o com- primento da chave de sessão 3300 não é compatível com o comprimento;, dos dados originais 3306, então a chave de sessão de realimentação da ci- fra 3304 pode ser gerada.

Em uma abordagem adequada, os dados originais 3306 podem ser criptografados antes da análise, divisão ou ambos. Por exemplo, como a figura 33 ilustra, os dados originais 3306 podem ser colocados em XOR com qualquer valor adequado (por exemplo, com a chave de sessão de realimen- tação de cifra 3304 ou com qualquer outro valor adequado). Será entendido que qualquer outra técnica de criptografia adequada pode ser usada no lugar de ou além da técnica XOR ilustrada. Será também entendido que embora a figura 33 seja ilustrada em termos de operações de byte por byte, a opera- ção pode acontecer no nível do bit ou em qualquer outro nível adequado. Será também entendido que, se desejado, não precisará existir qualquer criptografia qualquer que sejam os dados originais 3306.

Os dados criptografados resultantes (ou dados originais se ne- nhuma criptografia aconteceu) são então comprovados para determinar co- mo dividir os dados criptografados (ou originais) entre os depósitos de saída (por exemplo, dos quais existem quatro no exemplo ilustrado). No exemplo ilustrado, a comprovação acontece por bytes e é uma função da chave de sessão de realimentação da cifra 3304. Será entendido que isso é meramen- te ilustrativo. A comprovação pode ser executada no nível do bit, se deseja- do. A comprovação pode ser uma função de qualquer outro valor adequado além da chave de sessão de realimentação da cifra 3304. Em uma outra a- bordagem adequada, a comprovação não precisa ser usada. De preferência, qualquer outra técnica adequada para dividir os dados pode ser utilizada.

A figura 34 é um diagrama de blocos de um fluxo de processo i- lustrativo para restaurar os dados originais 3306 de duas ou mais porções analisadas e divididas dos dados originais 3306 de acordo com uma modali- dade da presente invenção. O processo envolve comprovar as porções ao contrário (isto é, para o processo da figura 33) como uma função da chave de sessão de realimentação da cifra 3304 para restaurar os dados originais criptografados (ou dados originais se não existiu criptografia antes da análise e divisão). A chave de criptografia pode então ser usada para restaurar os dados originais (isto é, no exemplo ilustrado, a chave de sessão da realimen- tação da cifra 3304 é usada para decriptografar a criptografia XOR colocan- do-a em XOR com os dados criptografados). Isso restaura os dados originais 3306.

A figura 35 mostra como a divisão do bit pode ser implementada no exemplo das figuras 33 e 34. Uma prova pode ser usada (por exemplo, como uma função da chave de sessão de realimentação da cifra, como uma função de qualquer outro valor adequado) para determinar um valor de bit no qual dividir cada byte de dados. Será entendido que isso é meramente uma maneira ilustrativa na qual implementar a divisão no nível do bit. Qualquer outra técnica adequada pode ser usada.

Será entendido que qualquer referência à funcionalidade da pro- va feita aqui pode ser feita com relação a qualquer algoritmo de prova ade- quado. Esses incluem, por exemplo, MD5 e SHA-1. Algoritmos de prova dife- rentes podem ser usados em momentos diferentes e por componentes dife- rentes da presente invenção.

Depois que um ponto de divisão foi determinado de acordo com o procedimento ilustrativo acima ou através de qualquer outro procedimento ou algoritmo, uma determinação pode ser feita com relação a quais porções de dados anexar a cada um dos segmentos esquerdo e direito. Qualquer algoritmo adequado pode ser usado para fazer essa determinação. Por e- xemplo, em uma abordagem adequada, uma tabela de todas as distribuições possíveis (por exemplo, na forma de pares de destinos para o segmento es- querdo e para o segmento direito) pode ser criada, por meio do que um valor de compartilhamento de destino para cada um dos segmentos esquerdo e direito pode ser determinado usando qualquer função de prova adequada nos dados correspondentes na chave de sessão, chave de sessão da reali- mentação de cifra ou qualquer outro valor aleatório ou pseudoaleatório ade- quado, que pode ser gerado e estendido para o tamanho dos dados origi- nais. Por exemplo, uma função de prova de um byte correspondente no valor aleatório ou pseudoaleatório pode ser feita. A saída da função de prova é usada para determinar qual par de destinos (isto é, um para o segmento es- querdo e um para o segmento direito) selecionar da tabela de todas as com- binações de destino. Com base nesse resultado, cada segmento da unidade de dados dividida é anexado nos dois compartilhamentos respectivos indica- dos pelo valor de tabela selecionado como um resultado da função de prova.

A informação de redundância pode ser anexada nas porções de dados de acordo com a presente invenção para permitir a restauração dos dados originais usando menos do que todas as porções de dados. Por e- xemplo, se é desejado que duas das quatro porções sejam suficientes para a restauração dos dados, então os dados adicionais dos compartilhamentos podem ser adequadamente anexados em cada compartilhamento em, por exemplo, uma maneira de rodízio (por exemplo, onde o tamanho dos dados originais é 4MB, então o compartilhamento 1 obtém seus próprios comparti- lhamentos bem como esses dos compartilhamentos 2 e 3, o compartilha- mento 2 obtém seu próprio compartilhamento bem como esses dos compar- tilhamentos 3 e 4, o compartilhamento 3 obtém o seu próprio compartilha- mento bem como esses dos compartilhamentos 4 e 1 e o compartilhamento 4 obtém seus próprios compartilhamentos bem como esses dos comparti- lhamentos I e 2). Qualquer tal redundância adequada pode ser usada de acordo com a presente invenção.

Será entendido que qualquer outra abordagem adequada de análise e divisão pode ser usada para gerar porções de dados a partir de um conjunto de dados original de acordo com a presente invenção. Por exem- plo, a análise e a divisão podem ser aleatória ou pseudoaleatoriamente pro- cessadas em uma base de bit por bit. Um valor aleatório ou pseudoaleatório pode ser usado (por exemplo, chave de sessão, chave de sessão de reali- mentação da cifra, etc.), por meio do que para cada bit nos dados originais, o resultado de uma função de prova em dados correspondentes no valor aleatório ou pseudoaleatório pode indicar em qual compartilhamento anexar o bit respectivo. Em uma abordagem adequada, o valor aleatório ou pseudo- aleatório pode ser gerado como, ou estendido para, 8 vezes o tamanho dos dados originais, de modo que a função de prova pode ser executada em um byte correspondente do valor aleatório ou pseudoaleatório com redação a: cada bit dos dados originais. Qualquer outro algoritmo adequado para anali- sar e dividir os dados em um nível de bit por bit pode ser usado de acordo com a presente invenção. Será também evidente que os dados de redun- dância podem ser anexados aos compartilhamentos de dados tal como, por exemplo, na maneira descrita imediatamente acima de acordo com a pre- sente invenção.

Em uma abordagem adequada, a análise e a divisão não preci- sam ser aleatórias ou pseudoaleatórias. De preferência, qualquer algoritmo determinístico adequado para a análise e a divisão de dados pode ser usa- do. Por exemplo, a fragmentação dos dados originais em compartilhamentos seqüenciais pode ser utilizada como um algoritmo de análise e divisão. Um outro exemplo é analisar e dividir os dados originais bit por bit, anexando cada bit respectivo nos compartilhamentos de dados seqüencialmente em uma maneira de rodízio. Será também verificado que os dados de redun- dância podem ser anexados nos compartilhamentos de dados tal como, por exemplo, na maneira descrita acima de acordo com a presente invenção.

Em uma modalidade da presente invenção, depois que o anali- sador de dados seguro gera um número de porções de dados originais, a fim de restaurar os dados originais, certa uma ou mais das porções geradas po- de ser obrigatória. Por exemplo, se uma das porções é usada como um com- partilhamento de autenticação (por exemplo, salvo em um dispositivo de fi- cha física), e se o aspecto de tolerância à falha do analisador de dados se- guro está sendo usado (isto é, onde menos do que todas as porções são necessárias para restaurar os dados originais), então mesmo embora o ana- lisador de dados seguro possa ter acesso a um número suficiente de por- ções dos dados originais a fim de restaurar os dados originais, ele pode re- querer o compartilhamento de autenticação armazenado no dispositivo da ficha física antes que restaure os dados originais. Será entendido que qual- quer número e tipos de compartilhamentos particulares podem ser requeri- dos com base, por exemplo, na aplicação, tipo de dados, usuário, quaisquer outros fatores adequados ou qualquer combinação desses.

Em uma abordagem adequada, o analisador de dados seguro ou algum componente externo ao analisador de dados seguro pode cripto- grafar uma ou mais porções dos dados originais. As porções criptografadas podem precisar ser providas e decriptografadas a fim de restaurar os dados originais. As porções criptografadas diferentes podem ser criptografadas com chaves de criptografia diferentes. Por exemplo, esse aspecto pode ser usado para implementar uma "regra de dois homens" mais segura, por meio da qual um primeiro usuário precisaria ter um compartilhamento particular criptografado usando uma primeira criptografia e um segundo usuário preci- saria ter um compartilhamento particular criptografado usando uma segunda chave de criptografia. A fim de acessar os dados originais, ambos os usuá- rios precisariam ter suas chaves de criptografia respectivas e prover suas porções respectivas dos dados originais. Em uma abordagem adequada, uma chave pública pode ser usada para criptografar uma ou mais porções de dados que pode ser um compartilhamento obrigatório requerido para res- taurar os dados originais. Uma chave privada pode então ser usada para decriptografar o compartilhamento a fim de ser usado para restaurar os da- dos originais.

Qualquer tal paradigma adequado pode ser usado que faça uso de compartilhamentos obrigatórios onde menos do que todos os comparti- lhamentos são necessários para restaurar os dados originais.

Em uma modalidade adequada da presente invenção, a distribu- ição dos dados em um número finito de compartilhamentos de dados pode ser processada aleatória ou pseudoaleatoriamente tal que de uma perspecti- va estatística, a probabilidade que qualquer compartilhamento particular de dados receba uma unidade de dados particular é igual à probabilidade que qualquer um dos compartilhamentos restantes receberá a unidade de dados. Como um resultado, cada compartilhamento de dados terá uma quantidade aproximadamente igual de bits de dados.

De acordo com uma outra modalidade da presente invenção, cada um do número finito de compartilhamentos de dados não precisa ter uma probabilidade igual de recepção das unidades de dados a partir da aná- lise e divisão dos dados originais. De preferência, certo um ou mais compar- tilhamentos podem ter uma probabilidade maior ou menor do que os com- partilhamentos restantes. Como um resultado, certos compartilhamentos podem ser maiores ou menores em termos de tamanho de bit em relação a outros compartilhamentos. Por exemplo, em um cenário de dois comparti- lhamentos, um compartilhamento pode ter uma probabilidade de 1% de re- ceber uma unidade de dados enquanto que o segundo compartilhamento tem uma probabilidade de 99%. Deve seguir, portanto, que uma vez que as unidades de dados tenham sido distribuídas pelo analisador de dados segu- ro entre os dois compartilhamentos, o primeiro compartilhamento deve ter aproximadamente 1% dos dados e o segundo compartilhamento 99%. Quaisquer probabilidades adequadas podem ser usadas de acordo com a presente invenção.

Será entendido que o analisador de dados seguro pode ser pro- gramado para distribuir dados para compartilhamentos de acordo com uma porcentagem exata (ou quase exata) também. Por exemplo, o analisador de dados seguro pode ser programado para distribuir 80% dos dados para um primeiro compartilhamento e os 20% restantes dos dados para um segundo compartilhamento.

De acordo com uma outra modalidade da presente invenção, o analisador de dados seguro pode gerar compartilhamentos de dados, um ou mais dos quais têm tamanhos predefinidos. Por exemplo, o analisador de dados seguro pode dividir os dados originais em porções de dados onde uma das porções é exatamente de 256 bits. Em uma abordagem adequada, se não é possível gerar uma porção de dados tendo o tamanho requisitado, então o analisador de dados seguro pode encher a porção para torná-la do tamanho correto. Qualquer tamanho adequado pode ser usado.

Em uma abordagem adequada, o tamanho de uma porção de dados pode ser o tamanho de uma chave de criptografia, uma chave de divi- são, qualquer outra chave adequada ou qualquer outro elemento de dados adequado.

Como previamente discutido, o analisador de dados seguro po- de usar chaves na análise e divisão dos dados. Para finalidades de clareza e. brevidade, essas chaves serão citadas aqui como "chaves de divisão". Por exemplo, a chave-mestre da sessão, previamente apresentada, é um tipo de chave de divisão. Também, como previamente discutido, chaves de divisão podem ser garantidas dentro de compartilhamentos de dados gerados pelo analisador de dados seguro. Quaisquer algoritmos adequados para garantir as chaves de divisão podem ser usados para garanti-las entre os comparti- Ihamentos de dados. Por exemplo, o algoritmo Shamir pode ser usado para garantir as chaves de divisão, por meio do que a informação que pode ser usada para reconstruir uma chave de divisão é gerada e anexada nos com- partilhamentos de dados. Qualquer outro tal algoritmo adequado pode ser usado de acordo com a presente invenção.

Similarmente, quaisquer chaves de criptografia adequadas po- dem ser garantidas dentro de um ou mais compartilhamentos de dados de acordo com qualquer algoritmo adequado tal como o algoritmo Shamir. Por exemplo, as chaves de criptografia usadas para criptografar um conjunto de dados antes da análise e divisão, as chaves de criptografia usadas para crip- tografar porções de dados depois da análise e divisão ou ambas podem ser garantidas usando, por exemplo, o algoritmo Shamir ou qualquer outro algo- ritmo adequado.

De acordo com uma modalidade da presente invenção, uma transformação de tudo ou nada (AoNT), tal como uma transformação de pa- cote completo, pode ser usada para garantir mais os dados transformando as chaves de divisão, chaves de criptografia, quaisquer outros elementos de dados adequados ou qualquer combinação desses. Por exemplo, uma chave de criptografia usada para criptografar um conjunto de dados antes da análi- se e divisão de acordo com a presente invenção pode ser transformada por um algoritmo de AoNT. A chave de criptografia transformada pode então ser distribuída entre os compartilhamentos de dados de acordo, por exemplo, com o algoritmo Shamir ou qualquer outro algoritmo adequado. A fim de re- construir a chave de criptografia, o conjunto de dados criptografado deve ser restaurado (por exemplo, não necessariamente usando todos os comparti- lhamentos de dados se a redundância foi usada de acordo com a presente invenção) a fim de acessar a informação necessária com relação à transfor- mação de acordo com AoNTs como é bem-conhecido por alguém versado na técnica. Quando a chave de criptografia original é recuperada, ela pode ser usada para decriptografar o conjunto de dados criptografado para recu- perar o conjunto de dados original. Será entendido que os aspectos de tole- rância à falha da presente invenção podem ser usados em conjunto com o aspecto do AoNT. A saber, os dados de redundância podem ser incluídos nas porções de dados tal que menos do que todas as porções de dados são necessárias para restaurar o conjunto de dados criptografado.

Será entendido que a AoNT pode ser aplicada nas chaves de criptografia usadas para criptografar as porções de dados seguinte à análise e divisão no lugar de ou além da criptografia e AoNT da chave de criptogra- fia respectiva correspondendo com o conjunto de dados antes da análise e divisão. Da mesma forma, a AoNT pode ser aplicada nas chaves de divisão. Em uma modalidade da presente invenção, as chaves de cripto- grafia, chaves de divisão ou ambas como usadas de acordo com a presente invenção podem ser também criptografadas usando, por exemplo, uma cha- ve de grupo de trabalho a fim de prover um nível extra de segurança para um conjunto de dados garantido.

Em uma modalidade da presente invenção, um módulo de audi- toria pode ser provido que acompanha sempre que o analisador de dados seguro é invocado para dividir os dados.

A figura 36 ilustra opções possíveis 3600 para usar os compo- nentes do analisador de dados seguro de acordo com a invenção. Gada combinação das opções é esboçada abaixo e marcada com os números de etapa apropriados da figura 36. O analisador de dados seguro pode ser mo- dular por natureza, permitindo que qualquer algoritmo conhecido seja usado dentro de cada um dos blocos de função mostrados na figura 36. Por exem- pio, outros algoritmos de divisão de chave (por exemplo, compartilhamento de segredo) tal como Blakely pode ser usado no lugar de Shamir ou a crip- tografia AES poderia ser substituída por outros algoritmos de criptografia conhecidos tal como DES triplo. As etiquetas mostradas no exemplo da figu- ra 36 representam meramente uma combinação possível de algoritmos para uso em uma modalidade da invenção. Deve ser entendido que qualquer al- goritmo adequado ou combinação de algoritmos pode ser usado no lugar dos algoritmos marcados.

1)3610,3612,3614,3615,3616,3617,3618,3619 Usando dados criptografados previamente na etapa 3610, os dados podem ser eventualmente divididos em um número predefinido de compartilhamentos. Se o algoritmo de divisão exige uma chave, uma chave de criptografia de divisão pode ser gerada na etapa 3612 usando um gera- dor de número pseudoaleatório criptograficamente seguro. A chave de crip- tografia de divisão pode opcionalmente ser transformada usando uma trans- formação de tudo ou nada (AoNT) em uma chave de divisão de transforma- ção na etapa 3614 antes de ser dividida em chave para o número predefini- do de compartilhamentos com tolerância à falha na etapa 3615. Os dados podem então ser divididos no número predefinido de compartilhamentos na etapa 3616. Um esquema de tolerância à falha pode ser usado na etapa 3617 para permitir a regeneração dos dados de menos do que o número total de compartilhamentos. Depois que os compartilhamentos são criados, a informação de autenticação/integridade pode ser embutida nos compartilha- mentos na etapa 3618. Cada compartilhamento pode ser opcionalmente pós-criptografado na etapa 3619.

2)3111,3612,3614,3615,3616,3617,3618,3619.

Em algumas modalidades, os dados de entrada podem ser crip- tografados usando uma chave de criptografia provida por um usuário ou um sistema externo. A chave externa é provida na etapa 3611. Por exemplo, a chave pode ser provida de uma memória de chave externa. Se o algoritmo de divisão exige uma chave, a chave de criptogràfia de divisão pode ser ge- rada usando um gerador de número pseudoaleatório criptograficamente se- guro na etapa 3612. A chave de divisão pode opcionalmente ser transforma- da usando uma transformação de tudo ou nada (AoNT) em uma chave de criptografia de divisão de transformação na etapa 3614 antes de ser dividida em chave para o número predefinido de compartilhamentos com tolerância à> falha na etapa 3615. Os dados são então divididos para um número predefi- nido de compartilhamentos na etapa 3616. Um esquema de tolerância à fa- lha pode ser usado na etapa 3617 para permitir a regeneração dos dados de menos do que o número total de compartilhamentos. Depois que os compar- tilhamentos são criados, a informação de autenticação/integridade pode ser embutida nos compartilhamentos na etapa 3618. Cada compartilhamento pode ser opcionalmente pós-criptografado na etapa 3619.

3) 3612, 3613, 3614, 3615, 3612, 3614, 3615, 3616, 3617, 3618,3619.

Em algumas modalidades, uma chave de criptografia pode ser gerada usando um gerador de número pseudoaleatório criptograficamente seguro na etapa 3612 para transformar os dados. A criptografia dos dados usando a chave de criptografia gerada pode ocorrer na etapa a 3613. A cha- ve de criptografia pode opcionalmente ser transformada usando uma trans- formação de tudo ou nada (AoNT) em uma chave de criptografia de trans- formação na etapa 3614. A chave de criptografia de transformação e/ou a chave de criptografia gerada pode então ser dividida no número predefinido de compartilhamentos com tolerância à falha na etapa 3615. Se o algoritmo de divisão exige uma chave, a geração da chave de criptografia de divisão usando um gerador de número pseudoaleatório criptograficamente seguro pode ocorrer na etapa 3612. A chave de divisão pode opcionalmente ser transformada usando uma transformação de tudo ou nada (AoNT) em uma chave de criptografia de divisão de transformação na etapa 3614 antes de ser dividida em chave para o número predefinido de compartilhamentos com tolerância à falha na etapa 3615. Os dados podem então ser divididos para um número predefinido de compartilhamentos na etapa 3616. Um esquema tolerante à falha pode ser usado na etapa 3617 para permitir a regeneração dos dados de menos do que o número total de compartilhamentos. Depois que os compartilhamentos são criados, a informação de autentica- ção/integridade será embutida nos compartilhamentos na etapa 3618. Cada compartilhamento pode então ser opcionalmente pós-criptografado na etapa 3619.

4)3612,3614,3615,3616,3617,3618,3619

Em algumas modalidades, os dados podem ser divididos em um número predefinido de compartilhamentos. Se o algoritmo de divisão exige uma chave, a geração da chave de criptografia de divisão usando um gera- dor de número pseudoaleatório criptograficamente seguro pode ocorrer na etapa 3612. A chave de divisão pode opcionalmente ser transformada usan- do uma transformação de tudo ou nada (AoNT) em uma chave de divisão transformada na etapa 3614 antes de ser dividida em chave no número pre- definido de compartilhamentos com tolerância à falha na etapa 3615. Os da- dos podem então ser divididos na etapa 3616. Um esquema tolerante à falha pode ser usado na etapa 3617 para permitir a regeneração dos dados de menos do que o número total de compartilhamentos. Depois que os compar- tilhamentos são criados, a informação de autenticação/integridade pode ser embutida nos compartilhamentos na etapa 3618. Cada compartilhamento pode ser opcionalmente pós-criptografado na etapa 3619.

Embora as quatro combinações acima de opções sejam preferi- velmente usadas em algumas modalidades da invenção, quaisquer outras combinações adequadas de aspectos, etapas ou opções podem ser usadas com o analisador de dados seguro em outras modalidades.

O analisador de dados seguro pode oferecer proteção de dados flexível facilitando a separação física. Os dados podem ser criptografados em primeiro lugar, a seguir divididos em compartilhamentos com "m de n" tolerância de falha. Isso permite a regeneração da informação original quan- do menos do qúe o número total de compartilhamentos está disponível. Por exemplo, alguns compartilhamentos podem ser perdidos ou corrompidos na transmissão. Os compartilhamentos perdidos ou corrompidos podem ser recriados a partir da tolerância à falha ou informação de integridade anexada nos compartilhamentos, como discutido em mais detalhes abaixo.

A fim de criar os compartilhamentos, o número de chaves é op- cionalmente utilizado pelo analisador de dados seguro. Essas chaves podem incluir uma ou mais das seguintes:

Chave de pré-criptografia: quando a pré-criptografia dos com- partilhamentos é selecionada, uma chave externa pode ser passada para o analisador de dados seguro. Essa chave pode ser gerada e armazenada externamente em uma memória de chave (ou outra localização) e pode ser usada para opcionalmente criptografar os dados antes da divisão dos dados.

Chave de criptografia de divisão: essa chave pode ser gerada internamente e usada pelo analisador de dados seguro para criptografar os dados antes da divisão. Essa chave pode então ser armazenada com segu- rança dentro dos compartilhamentos usando um algoritmo de divisão de chave.

Chave de sessão de divisão: essa chave não é usada com um algoritmo de criptografia, de preferência, ela pode ser usada para colocar com chave os algoritmos de divisão dos dados quando a divisão aleatória é selecionada. Quando uma divisão aleatória é usada, uma chave de sessão de divisão pode ser gerada internamente e usada pelo analisador de dados seguro para dividir os dados em compartilhamentos. Essa chave pode ser armazenada com segurança dentro dos compartilhamentos usando um algo- ritmo de divisão de chave.

Chave pós-criptografia: quando a pós-criptografia dos comparti- lhamentos é selecionada, uma chave externa pode ser passada para o ana- lisador de dados seguro e usada para pós-criptografar os compartilhamentos individuais. Essa chave pode ser gerada e armazenada externamente em uma memória de chave ou outra localização adequada.

Em algumas modalidades, quando os dados são garantidos u- sando o analisador de dados seguro dessa maneira, a informação pode ser somente remontada contanto que todos os compartilhamentos requeridos e as chaves de criptografia externas estejam presentes.

A figura 37 mostra o processo geral ilustrativo 3700 para usar o analisador de dados seguro da presente invenção em algumas modalidades. Como descrito acima, duas funções bem adequadas para o analisador de dados seguro 3706 podem incluir criptografia 3702 e cópia de segurança 3704. Como tal, o analisador de dados seguro 3706 pode ser integrado com um sistema RAID ou de cópia de segurança ou um hardware ou mecanismo de criptografia de software em algumas modalidades.

Os processos de chave primária associados com o analisador de dados seguro 3706 podem incluir um ou mais do processo de pré- criptografia 3708, processo de criptografia/transformação 3710, processo seguro de chave 3712, processo de análise/distribuição 3714, processo de tolerância à falha 3716, processo de autenticação do compartilhamento 3716 e processo pós-criptografia 3720. Esses processos podem ser executados em várias ordens ou combinações adequadas, como detalhado na figura 36. A combinação e a ordem dos processos usados podem depender da aplica- ção ou uso particular, do nível de segurança desejado, se pré-criptografia opcional, pós-criptografia ou ambas, são desejadas, da redundância deseja- da, das capacidades ou desempenho de um sistema subjacente ou integra- do ou qualquer outro fator adequado ou combinação de fatores.

A saída do processo ilustrativo 3700 pode ser dois ou mais compartilhamentos 3722. Como descrito acima, os dados podem ser distri- buídos para cada um desses compartilhamentos aleatoriamente (ou pseu- doaleatoriamente) em algumas modalidades. Em outras modalidades, um algoritmo determinístico (ou alguma combinação adequada de algoritmos aleatórios, pseudoaleatórios e determinísticos) pode ser usado.

Além da proteção individual dos bens de informação, existe al- gumas vezes uma exigência para compartilhar informação entre grupos dife- rentes de usuários ou comunidades de interesse. Pode então ser necessário controlar o acesso aos compartilhamentos individuais dentro desse grupo de usuários ou compartilhar credenciais entre esses usuários que somente permitiriam que membros do grupo remontassem os compartilhamentos. Para essa finalidade, uma chave de grupo de trabalho pode ser disposta pa- ra membros do grupo em algumas modalidades da invenção. A chave do grupo de trabalho deve ser protegida e mantida confidencial, já que o com- prometimento da chave do grupo de trabalho pode potencialmente permitir que esses fora do grupo acessem a informação. Alguns sistemas e métodos para a disposição e a proteção da chave do grupo de trabalho são discutidos abaixo.

O conceito da chave do grupo de trabalho permite proteção me- Ihorada dos bens de informação criptografando a informação da chave ar- mazenada dentro dos compartilhamentos. Depois que essa operação é exe- cutada, mesmo se todos os compartilhamentos requeridos e chaves exter- nas forem descobertos, um atacante não tem esperança de recriar a infor- mação sem acesso à chave do grupo de trabalho.

A figura 38 mostra o diagrama de blocos ilustrativo 3800 para armazenar a chave e componentes de dados dentro dos compartilhamentos. No exemplo do diagrama 3800, as etapas opcionais de pré-criptografia e pós-criptografia são omitidas, embora essas etapas possam ser incluídas em outras modalidades.

O processo simplificado para dividir os dados inclui criptografar os dados usando a chave de criptografia 3804 no estágio de criptografia 3802. Porções da chave de criptografia 3804 podem então ser divididas e armazenadas dentro dos compartilhamentos 3810 dé acordo com a presente invenção. Porções da chave de criptografia de divisão 3806 podem também ser armazenadas dentro dos compartilhamentos 3810. Usando a chave de criptografia de divisão, os dados 3808 são então divididos e armazenados nos compartilhamentos 3810.

A fim de restaurar os dados, a chave de criptografia de divisão 3806 pode ser recuperada e restaurada de acordo com a presente invenção. A operação de divisão pode então ser invertida para restaurar o texto codifi- cado. A chave de criptografia 3804 pode também ser recuperada e restaura- da e o texto codificado pode então ser decriptografado usando a chave de criptografia.

Quando uma chave de grupo de trabalho é utilizada, o processo acima pode ser alterado ligeiramente para proteger a chave de criptografia com a chave do grupo de trabalho. A chave de criptografia pode então ser criptografada com a chave do grupo de trabalho antes de ser armazenada dentro dos compartilhamentos. As etapas modificadas são mostradas no diagrama de blocos ilustrativo 3900 da figura 39.

O processo simplificado para dividir os dados usando uma cha- ve de grupo de trabalho inclui primeiro criptografar os dados usando a chave de criptografia no estágio 3902. A chave de criptografia pode então ser crip- tografada com a chave do grupo de trabalho no estágio 3904. A chave de criptografia criptografada com a chave do grupo de trabalho pode então ser dividida em porções e armazenada com os compartilhamentos 3912. A cha- ve de divisão 3908 pode também ser dividida e armazenada nos comparti- Ihamentos 3912. Finalmente, porções dos dados 3910 são divididas e arma- zenadas nos compartilhamentos 3912 usando a chave de divisão 3908.

A fim de restaurar os dados, a chave de divisão pode ser recu- perada e restaurada de acordo com a presente invenção. A operação de divisão pode então ser invertida para restaurar o texto codificado de acordo com a presente invenção. A chave de criptografia (que foi criptografada com a chave do grupo de trabalho) pode ser recuperada e restaurada. A chave de criptografia pode então ser decriptografada usando a chave do grupo de trabalho. Finalmente, o texto codificado pode ser decriptografado usando a chave de criptografia.

Existem vários métodos seguros para dispor e proteger chaves do grupo de trabalho. A seleção de qual método usar para uma aplicação particular depende de um número de fatores. Esses fatores podem incluir nível de segurança requerido, custo, conveniência e o número de usuários no grupo de trabalho. Algumas técnicas geralmente usadas, usadas em al- gumas modalidades, são providas abaixo:

Armazenamento da chave com base no hardware

As soluções com base no hardware geralmente provêem as ga- rantias mais fortes para a segurança das chaves de criptografi- a/decriptografia em um sistema de criptografia. Exemplos de soluções de armazenamento com base no hardware incluem dispositivos de ficha de chave resistentes à falsificação que armazenam chaves em um dispositivo portátil (por exemplo, cartão inteligente/chave de hardware) ou em periféri- cos de armazenamento de chave não portáteis. Esses dispositivos são pro- jetados para impedir a fácil duplicação do material da chave por partes de- sautorizadas. As chaves podem ser geradas por uma autoridade de confian- ça e distribuídas para os usuários ou geradas dentro do hardware. Adicio- nalmente, muitos sistemas de armazenamento de chave provêem autentica- ção de múltiplos fatores, onde o uso da chave exige acesso a ambos um objeto físico (ficha) e uma frase de senha ou biométrica.

Armazenamento de chave com base no software

Embora o armazenamento dedicado com base no hardware possa ser desejável para disposições ou aplicações de alta segurança, ou- tras disposições podem eleger armazenar as chaves diretamente no hardwa- re local (por exemplo, discos ou memórias RAM ou RAM não voláteis tal como unidades USB). Isso provê um nível menor de proteção contra ataques de pessoas bem-informadas, ou nos casos onde um atacante é capaz de acessar diretamente a máquina de criptografia.

Para garantir as chaves no disco, o gerenciamento da chave com base no software freqüentemente protege as chaves armazenando-as na forma criptografada sob uma chave derivada de uma combinação de ou- tras métricas de autenticação, incluindo: senhas e frases de senha, presença de outras chaves (por exemplo, de uma solução com base no hardware), biométrica ou qualquer combinação adequada do precedente. O nível de segurança provido por tais técnicas pode variar de mecanismos de proteção de chave relativamente fracos providos por alguns sistemas operacionais (por exemplo, MS Windows e Linux), a soluções mais robustas implementa- das usando autenticação de múltiplos fatores.

O analisador de dados seguro da presente invenção pode ser vantajosamente usado em um número de aplicações e tecnologias. Por e- xemplo, sistemas de e-mail, sistemas RAID, sistemas de difusão de vídeo, sistema de banco de dados ou qualquer outro sistema adequado pode ter o analisador de dados seguro integrado em qualquer nível adequado. Como previamente discutido, será entendido que o analisador de dados seguro pode também ser integrado para proteção e tolerância à falha de qualquer tipo de dados em movimento através de qualquer meio de transporte, inclu- indo, por exemplo, meios de transporte conectados, sem fio ou físicos. Como um exemplo, aplicações de protocolo de voz através da Internet (VoIP) po- dem fazer uso do analisador de dados seguro da presente invenção para resolver problemas relacionados com ecos e retardos que são comumente encontrados em VolΡ. A necessidade de nova tentativa na rede em pacotes interrompidos pode ser eliminada pelo uso da tolerância à falha, que garante a entrega do pacote mesmo com a perda de um número predeterminado de compartilhamentos. Pacotes de dados (por exemplo, pacotes de rede) po- dem também ser eficientemente divididos e restaurados "instantaneamente" com mínimo retardo e armazenamento temporário, resultando em uma solu- ção abrangente para vários tipos de dados em movimento. O analisador de dados seguro pode agir nos pacotes de dados da rede, pacotes de voz da rede, blocos de dados do sistema de arquivo ou qualquer outra unidade a- dequada de informação. Além de ser integrado com uma aplicação VolΡ, o analisador de dados seguro pode ser integrado com uma aplicação de com- partilhamento de arquivo (por exemplo, uma aplicação de compartilhamento de arquivo não hierárquica), uma aplicação de difusão de vídeo, uma aplica- ção de votação eletrônica ou consulta seqüencial (que pode implementar um protocolo de votação eletrônica e assinaturas bloqueadas, tal como o proto- colo Sensus), uma aplicação de e-mail ou qualquer outra aplicação de rede que possa requerer ou desejar a comunicação segura.

Em algumas modalidades, o suporte para dados em movimento da rede pode ser provido pelo analisador de dados seguro da presente in- venção em duas fases distintas - uma fase de geração de cabeçalho e uma fase de partição de dados. O processo de geração de cabeçalho simplificado 4000 e o processo de partição de dados simplificado 4010 são mostrados nas figuras 40A e 40B, respectivamente. Um ou ambos esses processos podem ser executados em pacotes de rede, blocos do sistema de arquivo ou qualquer outra informação adequada.

Em algumas modalidades, o processo de geração de cabeçalho 4000 pode ser executado uma vez na iniciação de um fluxo de pacote de rede. Na etapa 4002, uma chave de criptografia de divisão aleatória (ou pseudoaleatória), K, pode ser gerada. A chave de criptografia de divisão, K, pode então ser opcionalmente criptografada (por exemplo, usando a chave, do grupo de trabalho descrita acima) na etapa de envoltório da chave AES 4004. Embora um envoltório da chave AES possa ser usado em algumas modalidades, qualquer algoritmo adequado de envoltório de chave ou de criptografia de chave pode ser usado em outras modalidades. A etapa do envoltório de chave AES 4004 pode operar em toda a chave de decriptogra- fia de divisão, K, ou a chave de criptografia de divisão pode ser analisada em vários blocos (por exemplo, blocos de 64 bits). A etapa do envoltório da chave AES 4004 pode então operar nos blocos da chave de criptografia de divisão, se desejado.

Na etapa 4006, o algoritmo de compartilhamento de segredo (por exemplo, Shamir) pode ser usado para dividir a chave de criptografia de divisão, K, em compartilhamentos de chave. Cada compartilhamento de chave pode então ser embutido em um dos compartilhamentos de saída (por exemplo, nos cabeçalhos de compartilhamento). Finalmente, um bloco de integridade de compartilhamento e (opcionalmente) uma marca de pós- autenticação (por exemplo, MAC) podem ser anexados no bloco do cabeça- lho de cada compartilhamento. Cada bloco de cabeçalho pode ser projetado para se ajustar dentro de um único pacote de dados.

Depois que a geração do cabeçalho está completa (por exem-

plo, usando o processo de geração de cabeçalho simplificado 4000), o anali- sador de dados seguro pode inserir a fase de partição dos dados usando o processo de divisão de dados simplificado 4010. Cada pacote de dados que chega ou bloco de dados no fluxo é criptografado usando a chave de cripto- grafia de divisão, K, na etapa 4012. Na etapa 4014, a informação de integri- dade do compartilhamento (por exemplo, uma prova H) pode ser calculada no texto codificado resultante da etapa 4012. Por exemplo, uma prova SHA- 256 pode ser calculada. Na etapa 4106, o pacote de dados ou bloco de da- dos pode então ser particionado em dois ou mais compartilhamentos de da- dos usando um dos algoritmos de divisão de dados descrito acima de acordo com a presente invenção. Em algumas modalidades, o pacote de dados ou bloco de dados pode ser dividido de modo que cada compartilhamento de dados contém uma distribuição substancialmente aleatória do pacote de da- dos criptografado ou bloco de dados. A informação de integridade (por e- xemplo, prova H) pode então ser anexada em cada compartilhamento de dados. Uma marca pós-autenticação opcional (por exemplo, MAC) pode também ser calculada e anexada em cada compartilhamento de dados em algumas modalidades.

Cada compartilhamento de dados pode incluir metadados, que podem ser necessários para permitir a reconstrução correta dos blocos de dados ou pacotes de dados. Essa informação pode ser incluída no cabeça- lho do compartilhamento. Os metadados podem incluir tal informação como compartilhamentos de chave criptográfica, identidades de chave, nonces de compartilhamento, valores de assinaturas/MAC e blocos de integridade. A fim de maximizar a eficiência da largura da banda, os metadados podem ser armazenados em um formato binário compacto.

Por exemplo, em algumas modalidades, o cabeçalho de com- partilhamento inclui um pedaço de cabeçalho de texto claro, que não é crip- tografado e pode incluir tais elementos como o compartilhamento de chave Shamir, nonce por sessão, nonce por compartilhamento, identificadores de chave (por exemplo, um identificador da chave do grupo de trabalho e um identificador da chave pós-autenticação). O cabeçalho do compartilhamento pode também incluir um pedaço de cabeçalho criptografado, que é criptogra- fado com a chave de criptografia de divisão. Um pedaço do cabeçalho de integridade, que pode incluir verificações de integridade para qualquer nú- mero dos blocos prévios (por exemplo, os dois blocos prévios) pode também ser incluído no cabeçalho. Quaisquer outros valores adequados ou informa- ção podem também ser incluídos no cabeçalho do compartilhamento.

Como mostrado no formato de compartilhamento ilustrativo 4100 da figura 41, o bloco do cabeçalho 4102 pode ser associado com dois ou mais blocos de saída 4104. Cada bloco de cabeçalho, tal como bloco de ca- beçalho 4102, pode ser projetado para se ajustar dentro de um único pacote de dados de rede. Em algumas modalidades, depois que o bloco de cabeça- lho 4102 é transmitido de uma primeira localização para uma segunda locali- zação, os blocos de saída podem então ser transmitidos. Alternativamente, α bloco do cabeçalho 4102 e os blocos de saída 4104 podem ser transmitidos ao mesmo tempo em paralelo. A transmissão pode ocorrer através de uma ou mais trajetórias de comunicações similares ou dissimilares.

Cada bloco de saída pode incluir a porção de dados 4106 e a porção de integridade/autenticidade 4108. Como descrito acima, cada com- partilhamento de dados pode ser garantido usando uma porção de integrida- de de compartilhamento incluindo a informação de integridade do comparti- lhamento (por exemplo, uma prova SHA-256) dos dados criptografados pré- particionados. Para verificar a integridade dos blocos de saída no tempo de recuperação, o analisador de dados seguro pode comparar os blocos de in- tegridade de compartilhamento de cada compartilhamento e a seguir inverter o algoritmo de divisão. A prova dos dados recuperados pode então ser veri- ficada contra a prova do compartilhamento.

Embora algumas aplicações comuns do analisador de dados seguro sejam descritas acima, deve ser claramente entendido que a presen- te invenção pode ser integrada com qualquer aplicação de rede a fim de aumentar a segurança, tolerância à falha, anonimato ou qualquer combina- ção adequada do precedente.

Adicionalmente, outras combinações, adições, substituições e modificações serão evidentes para o versado em vista dessa descrição. Dessa maneira, a presente invenção não é planejada para ser limitada pela reação das modalidades preferidas, mas é para ser definida por uma refe- rência às reivindicações anexas.

Claims (15)

1. Método para garantir uma transmissão de blocos de dados em um fluxo de dados, o método compreendendo: criptografar cada bloco de dados no fluxo de dados com uma chave de criptografia, distribuir porções da chave de criptografia em pelo menos dois cabeçalhos de compartilhamento, distribuir unidades de dados dos blocos de dados criptografados em pelo menos dois compartilhamentos de dados, onde cada um dos pelo menos dois compartilhamentos de dados contém respeitosamente uma distribuição substancialmente aleatória de um subconjunto respectivo das unidades de dados e transmitir pelo menos dois compartilhamentos de dados e pelo menos dois cabeçalhos de compartilha- mento para uma localização remota sobre pelo menos uma trajetória de co- municações, por meio disso o fluxo de dados é restaurável de pelo menos dois compartilhamentos de dados dos pelo menos dois compartilhamentos de dados e de pelo menos dois cabeçalhos de compartilhamento dos pelo menos dois cabeçalhos de compartilhamento.

2. Método, de acordo com a reivindicação 1, também compre- endendo: gerar informação de integridade para cada bloco de dados crip- tografado no fluxo de dados e transmitir a informação de integridade para a localização remota.

3. Método, de acordo com a reivindicação 2, no qual a informa- ção de integridade é transmitida com pelo menos dois compartilhamentos de dados.

4. Método, de acordo com a reivindicação 2, no qual a informa- ção de integridade é selecionada do grupo consistindo em uma prova, uma assinatura MAC e uma assinatura digital.

5. Método, de acordo com a reivindicação 1, no qual distribuir porções da chave de criptografia compreende distribuir porções da chave de criptografia usando um algoritmo de compartilhamento secreto.

6. Método, de acordo com a reivindicação 5, no qual o algoritmo de compartilhamento secreto é selecionado do grupo consistindo em Shamir e Blakely.

7. Método, de acordo com a reivindicação 1, no qual transmitir os pelo menos dois compartilhamentos de dados e pelo menos dois cabeça- lhos de compartilhamento compreende transmitir os pelo menos dois com- partilhamentos de dados e pelo menos dois cabeçalhos de compartilhamen- to em uma única trajetória de comunicações em uma transmissão serial.

8. Método, de acordo com a reivindicação 1, no qual transmitir os pelo menos dois compartilhamentos de dados e pelo menos dois cabeça- lhos de compartilhamento compreende transmitir os pelo menos dois com- partilhamentos de dados e pelo menos dois cabeçalhos de compartilhamen- to através de múltiplas trajetórias de comunicações em paralelo.

9. Método, de acordo com a reivindicação 1, no qual a transmis- são é executada usando um aplicativo de compartilhamento de arquivo.

10. Método, de acordo com a reivindicação 1, no qual a trans- missão é executada usando um aplicativo de votação ou consulta seqüencial.

11. Método, de acordo com a reivindicação 1, no qual a trans- missão é executada usando um aplicativo de voz através de IP (VolP).

12. Método, de acordo com a reivindicação 1, no qual os blocos, de dados são selecionados do grupo consistindo em pacotes de dados da rede, pacotes de voz da rede e blocos de dados do sistema de arquivo.

13. Método, de acordo com a reivindicação 1, também compre- endendo: anexar informação de redundância em pelo menos dois compar- tilhamentos de dados e transmitir a informação de redundância para a Iocali- zação remota.

14. Método, de acordo com a reivindicação 1, também compre- endendo criptografar a chave de criptografia com uma chave do grupo de trabalho antes de distribuir a chave de criptografia.

15. Método, de acordo com a reivindicação 14, no qual cripto- grafar a chave de criptografia com a chave do grupo de trabalho compreen- de criptografar a chave de criptografia usando uma função de encobrimento de chave AES.