BRPI0411332A

Secure data parser method and system

Abstract

"SECURE DATA ANALYZER METHOD AND SYSTEM". The present invention relates to a method and system for securing sensitive data from unauthorized access or use. The method and system of the present invention are useful in a wide variety of scenarios, including commercial scenarios generally available to the public, which can be extremely large or small with respect to the number of users. The method and system of the present invention are also useful in a more private setting, such as with a corporation or government agency, as well as between corporations, government agencies or any other entity.

Term

Term ended

Projected expiry passed 10 June 2024, 2.3 years ago.

26 claims: 14 independent, 12 dependent

1
REIVINDICAÇÕES 1. Método, que compreende:a) a encriptação de um conjunto de dados para a provisão de um conjunto de dados encriptados;b) a separação do conjunto de dados encriptados em duas ou mais porções de dados;c) a encriptação de uma ou mais porções de dados a partir da etapa b);e d) o armazenamento das porções encriptadas de dados a partir da etapa c) em um ou mais locais em um ou mais depósitos de dados.
2
Método, de acordo com a reivindicação 1, onde a separação da etapa b) separa o conjunto de dados encriptados em quatro ou mais porções de dados.
3
Método, de acordo com a reivindicação 2, onde a etapa b) e a etapa c) são repetidas uma ou mais vezes antes do armazenamento da etapa d) e, opcionalmente, onde a encriptação da etapa c) é realizada usandose um algoritmo de encriptação que é diferente do algoritmo de encriptação na etapa a).
4
Método, de acordo com a reivindicação 1, onde o armazenamento da etapa d) é em locais diferentes do mesmo depósito de dados.
5
Método, de acordo com a reivindicação 1, onde o armazenamento da etapa d) é em depósitos de dados diferentes.
6
Método, de acordo com a reivindicação 1, onde o armazenamento da etapa d) é em depósitos de dados diferentes em locais geográficos diferentes.
7
Método, de acordo com a reivindicação 1, onde a encriptação da etapa c) provê uma chave de encriptação, e onde a chave de encriptação é armazenada na etapa d) em conjunto com os dados encriptados, usandose a referida chave de encriptação na etapa c).
8
Método, de acordo com a reivindicação 1, onde a encriptação da etapa c) provê uma chave de encriptação, e onde a chave de encriptação é armazenada na etapa d) separadamente dos dados encriptados usando-se a referida chave de encriptação na etapa c).
9
Método, de acordo com a reivindicação 1, onde o conjunto de dados da etapa a) compreende dados selecionados a partir do grupo que consiste em dados de chave de encriptação, texto, vídeo, áudio, imagens, 5 biométrica e dados digitais.
10
Método, que compreende:a) a separação de um conjunto de dados em duas ou mais porções de dados: b) a encriptação de uma ou mais das porções de dados da etapa 10 a);e c) o armazenamento de uma ou mais porções encriptadas de dados da etapa b) em um ou mais locais em um ou mais depósitos de dados.
11
Método, de acordo com a reivindicação 10, onde a separa15 ção da etapa a) separa o conjunto de dados em quatro ou mais porções de dados.
12
Método, de acordo com a reivindicação 10, onde a etapa a) e a etapa b) são repetidas uma ou mais vezes antes do armazenamento da etapa c) e, opcionalmente, onde a encriptação da etapa b) é repetida usan20 do-se um algoritmo de encriptação diferente.
13
Método, de acordo com a reivindicação 10, onde o armazenamento da etapa c) é em locais diferentes do mesmo depósito de dados.
14
Método, de acordo com a reivindicação 10, onde o armazenamento da etapa c) é em depósitos de dados diferentes. 25 15. Método, de acordo com a reivindicação 10, onde o armazenamento da etapa c) é em depósitos de dados diferentes em locais geográficos diferentes. 16. Método, de acordo com a reivindicação 10, onde a encriptação da etapa b) provê uma chave de encriptação, e onde a chave de encrip30 tação é armazenada na etapa c) em conjunto com os dados encriptados, usando-se a chave de encriptação na etapa b). 17. Método, de acordo com a reivindicação 10, onde a encriptação da etapa b) provê uma chave de encriptação, e onde a chave de encriptação é armazenada na etapa c) separadamente dos dados encriptados usando-se a referida chave de encriptação na etapa b). 18. Método, de acordo com a reivindicação 10, onde o conjunto de dados da etapa a) compreende dados selecionados a partir do grupo que consiste em dados de chave de encriptação, texto, vídeo, áudio, imagens, biométrica e dados digitais. 19. Método, de acordo com a reivindicação 10, onde a encriptação da etapa b) é realizada usando-se um algoritmo de encriptação selecionado a partir do grupo que consiste em RS1, RC4® e OTP. 20. Método, que compreende:a) a geração de uma chave mestra de encriptação e a encriptação de um conjunto de dados usando-se a chave mestra de encriptação;b) a separação de cada uma dentre a chave mestra de encriptação e o conjunto de dados encriptados em duas ou mais porções de dados, de acordo com um padrão de separação e a anexação de uma porção de chave mestra de encriptação a uma porção de conjunto de dados encriptados;c) a geração de uma ou mais chaves de encriptação para as porções de dados a partir da etapa b) e a encriptação das referidas porções de dados usando-se a referida chave de encriptação;e d) o armazenamento das porções encriptadas de dados a partir da etapa c) e as chaves de encriptação da etapa c) em pelo menos um depósito de dados. 21. Método, de acordo com a reivindicação 20, onde o armazenamento das porções de dados encriptados na etapa d) é em dois ou mais locais diferentes de um depósito de dados. 22. Método, de acordo com a reivindicação 20, onde o armazenamento de porções de dados encriptados na etapa d) é em dois ou mais depósitos de dados. 23. Método, de acordo com a reivindicação 20, onde o armazenamento das chaves de encriptação na etapa d) é em dois ou mais locais diferentes de um depósito de dados. 24. Método, de acordo com a reivindicação 20, onde o armazenamento das chaves de encriptação da etapa d) é em dois ou mais depósitos de dados diferentes. 25. Método, de acordo com a reivindicação 20, onde as chaves de encriptação geradas na etapa c) são armazenadas de acordo com a etapa d) com os dados encriptados da etapa c) em diferentes locais em um ou mais depósitos de dados. 26. Método, de acordo com a reivindicação 20, onde a chave de encriptação gerada na etapa c) é armazenada de acordo com a etapa d) em um depósito de dados diferente dos dados encriptados da etapa c) que foram encriptados usando-se a referida chave de encriptação. 27. Método, de acordo com a reivindicação 20, onde os dados encriptados da etapa b) são separados em quatro ou mais porções. 28. Método, de acordo com a reivindicação 20, onde a chave mestra de encriptação da etapa b) é separada em quatro ou mais porções. 29. Método, de acordo com a reivindicação 20, onde a etapa b) e a etapa c) são repetidas uma ou mais vezes e, opcionalmente, onde a encriptação da etapa c) é realizada usando-se um algoritmo de encriptação que é diferente do algoritmo de encriptação usado na etapa a). 30. Método, que compreende: a) a geração de uma chave mestra de encriptação e a encriptação de um conjunto de dados usando-se a chave mestra de encriptação;b) a separação de cada um dentre a chave mestra de encriptação e o conjunto de dados encriptados em duas ou mais porções, de acordo com um padrão de separação e o armazenamento das porções de chave mestra de encriptação em um ou mais locais de um ou mais depósitos de dados;c) a geração de uma ou mais chaves de encriptação para as porções de conjunto de dados encriptados da etapa b) e a encriptação das referidas porções de dados usando-se a referida chave de encriptação;e d) o armazenamento das porções encriptadas da etapa c) e das chaves de encriptação da etapa c) em pelo menos um local de pelo menos um depósito de dados, onde os referidos depósitos de dados são diferentes dos depósitos de dados da etapa b). 31. Método, de acordo com a reivindicação 30, onde o armazenamento de porções de dados encriptados na etapa d) é em dois ou mais locais diferentes de um depósito de dados. 32. Método, de acordo com a reivindicação 30, onde o armazenamento de porções de dados encriptados na etapa d) é em dois ou mais depósitos de dados. 33. Método, de acordo com a reivindicação 30, onde o armazenamento das chaves de encriptação na etapa d) é em dois ou mais locais diferentes de um depósito de dados. 34. Método, de acordo com a reivindicação 30, onde o armazenamento das chaves de encriptação da etapa d) é em dois ou mais depósitos de dados diferentes. 35. Método, de acordo com a reivindicação 30, onde as chaves de encriptação geradas na etapa c) e usadas para encriptação de um conjunto de dados na etapa c) são armazenadas de acordo com a etapa d) com o conjunto de dados encriptados que foi encriptado usando-se a chave de encriptação em um ou mais depósitos de dados. 36. Método, de acordo com a reivindicação 30, onde a chave de encriptação gerada na etapa c) e usada para encriptação de um conjunto de dados na etapa c) é armazenada de acordo com a etapa d) em um local diferente em um ou mais depósitos de dados a partir do conjunto de dados encríptados que foi encriptado usando-se a chave de encriptação. 37. Método, de acordo com a reivindicação 30, onde os dados encriptados da etapa b) são separados em quatro ou mais porções. 38. Método, de acordo com a reivindicação 30, onde a chave mestra de encriptação da etapa b) é separada em quatro ou mais porções. 39. Método, de acordo com a reivindicação 30, onde a etapa b) e a etapa c) são repetidas uma ou mais vezes e, opcionalmente, onde a encriptação da etapa c) é realizada usando-se um algoritmo de encriptação que é diferente do algoritmo de encriptação usado na etapa a). 40. Sistema, que compreende: a) um módulo de divisão de dados;b) um módulo de manipulação criptográfica;e c) um módulo de montagem de dados. 41. Sistema, de acordo com a reivindicação 40, onde o referido módulo de divisão de dados separa os dados em duas ou mais porções. 42. Sistema, de acordo com a reivindicação 40, onde o referido módulo de manipulação criptográfica opera sobre os dados antes de ou depois dos referidos dados serem operados pelo módulo de divisão de dados, e realiza a encriptação dos dados. 43. Sistema, de acordo com a reivindicação 40, onde o referido módulo de montagem de dados opera nos dados que foram operados pelo módulo de divisão de dados ou pelo módulo criptográfico para a restauração dos referidos dados para sua forma original. 44. Método, que compreende: a) a encriptação do conjunto de dados para a provisão de um conjunto de dados encriptados;b) a separação do conjunto de dados encriptados em duas ou mais porções de dados, de acordo com o conteúdo de um valor de chave único;c) a encriptação de uma ou mais das porções de dados a partir da etapa b);e d) o armazenamento das porções encriptadas de dados a partir da etapa c) em um ou mais locais em um ou mais depósitos de dados. 45. Método, de acordo com a reivindicação 44, onde a separação da etapa b) separa o conjunto de dados encriptados em quatro ou mais porções de dados, de acordo com o conteúdo de um valor de chave único. 46. Método, de acordo com a reivindicação 45, onde a etapa b) e a etapa c) são repetidas uma ou mais vezes, antes do armazenamento da etapa d) e, opcionalmente, onde a encriptação da etapa c) é realizada usando-se um algoritmo de encriptação que é diferente do algoritmo de encriptação na etapa a). 47. Método, de acordo com a reivindicação 44, onde o armazenamento da etapa d) é em locais diferentes do mesmo depósito de dados. 48. Método, de acordo com a reivindicação 44, onde o armazenamento da etapa d) é em depósitos de dados diferentes. 49. Método, de acordo com a reivindicação 44, onde o armazenamento da etapa d) é em depósitos de dados diferentes em locais geográficos diferentes. 50. Método, de acordo com a reivindicação 44, onde a encriptação da etapa c) provê uma chave de encriptação, e onde a chave de encriptação é armazenada na etapa d) em conjunto com os dados encriptados usando-se a referida chave de encriptação na etapa c). 51. Método, de acordo com a reivindicação 44, onde a encriptação da etapa c) provê uma chave de encriptação, e onde a chave de encriptação é armazenada na etapa d) separadamente dos dados encriptados usando-se a referida chave de encriptação na etapa c). 52. Método, de acordo com a reivindicação 44, onde o conjunto de dados da etapa a) compreende dados selecionados a partir do grupo que consiste em dados de chave de encriptação, texto, vídeo, áudio, imagens, biométrica e dados digitais. 53. Método, de acordo com a reivindicação 44, onde as referidas porções de dados compreendem um ou mais bits de dados. 54. Método, que compreende: a) a divisão de um conjunto de dados em um número N de unidades de dados;b) a seleção de um número X de compartilhamentos para armazenamento de unidade de dados;c) a geração de um número N de números randômicos que correspondem ao número X de compartilhamentos;d) a atribuição dos números randômicos às unidades de dados;e e) o armazenamento das unidades de dados e do número randômico no compartilhamento que corresponde ao número randômico. 55. Método, de acordo com a reivindicação 54, onde as referidas unidades de dados compreendem pelo menos um bit. 56. Sistema, que compreende: a) um módulo de divisão de dados;b) um módulo de manipulação criptográfica;e c) um módulo de montagem de dados, onde o referido sistema realiza o método como definido na reivindicação 1. 57. Sistema, que compreende: a) um módulo de divisão de dados;b) um módulo de manipulação criptográfica;e c) um módulo de montagem de dados, onde o referido sistema realiza o método como definido na reivindicação 1 e, opcionalmente, onde a encriptação da etapa c) é realizada usando-se um algoritmo de encriptação que é diferente do algoritmo de encriptação usado na etapa a). 58. Sistema, que compreende: a) um módulo de divisão de dados;b) um módulo de manipulação criptográfica;e c) um módulo de montagem de dados, onde o referido sistema realiza o método como definido na reivindicação 10. 59. Sistema, que compreende: a) um módulo de divisão de dados;b) um módulo de manipulação criptográfica;e c) um módulo de montagem de dados, onde o referido sistema realiza o método como definido na reivindicação 10 e, opcionalmente, onde a encriptação da etapa c) é realizada usando-se um algoritmo de encriptação que é diferente do algoritmo de encriptação usado na etapa a). 60. Sistema, que compreende: a) um módulo de divisão de dados;b) um módulo de manipulação criptográfica;e c) um módulo de montagem de dados, onde o referido sistema realiza o método como definido na reivindicação 20. 61. Sistema, que compreende: a) um módulo de divisão de dados;b) um módulo de manipulação criptográfica;e c) um módulo de montagem de dados, onde o referido sistema realiza o método como definido na reivindicação 20 e, opcionalmente, onde a encriptação da etapa c) é realizada usando-se um algoritmo de encriptação que é diferente do algoritmo de encriptação usado na etapa a). 62. Sistema, que compreende: a) um módulo de divisão de dados;b) um módulo de manipulação criptográfica;e c) um módulo de montagem de dados, onde o referido sistema realiza o método como definido na reivindicação 30. 63. Sistema, que compreende: a) um módulo de divisão de dados;b) um módulo de manipulação criptográfica;e c) um módulo de montagem de dados, onde o referido sistema realiza o método como definido na reivindicação 30 e, opcionalmente, onde a encriptação da etapa c) é realizada usando-se um algoritmo de encriptação que é diferente do algoritmo de encriptação usado na etapa a). 64. Sistema, que compreende: a) um módulo de divisão de dados;b) um módulo de manipulação criptográfica;e c) um módulo de montagem de dados, onde o referido sistema realiza o método como definido na reivindicação 44. 65. Sistema, que compreende: a) um módulo de divisão de dados;b) um módulo de manipulação criptográfica;e c) um módulo de montagem de dados, onde o referido sistema realiza o método como definido na reivindicação 44 e, opcionaimente, onde a encriptação da etapa c) é realizada usando-se um algoritmo de encriptação que é diferente do algoritmo de encriptação usado na etapa a). 5 66. Sistema, que compreende: a) um módulo de divisão de dados;b) um módulo de manipulação criptográfica;e c) um módulo de montagem de dados, onde o referido sistema realiza o método como definido na reivindicação 54. 10 67. Sistema, que compreende: a) um módulo de divisão de dados;b) um módulo de manipulação criptográfica;e c) um módulo de montagem de dados, onde o referido sistema realiza o método como definido na reivindicação 54 15 e, opcionaimente, onde a encriptação da etapa c) é realizada usando-se um algoritmo de encriptação que é diferente do algoritmo de encriptação usado na etapa a). 1/26 FIG 1 2/26 FIG 2 3/26 FIG 3 4/26 FIG4 ο «ro ο ro ο Φ ro φ Τ3 φ £Ζ Φ σι ro φ Ω *ro Ο) ο Q. *L_ Ο φ C φ σ ro φ Ω ο «ro ro ω c ro φ Ό φ C φ Ο) ro φ Ω 5/26 ο ο '(0 ι_ Ο) ο ο ο Μ— '(0 σ) ο ο φ C φ Ο) (Π Λ «Ο CL φ σ ο φ Μ—» C φ D) (0 Ο «C0 Ο» π ο F—» C φ C0 φ σ φ -*- c φ D) Φ c Φ σ C3 φ Ο FIG 5 6/26 ο «ro θ' TO (/ C ra ω Ό α C α Ο) ra ra CL Ο « -Ο Q. ω Τ3 ra ι_ ra FIG6 ο ra ο ra C0 c ra Φ •σ φ c φ cn ra φ Ω ο ra ο ra ο c Φ *-» ro φ σ φ *-* C φ Ο) ra φ Ω ο ο 'TO _ σ ο ο φ c Φ Ο) ra Φ Ω 7/26 700 FIG 7 8/26 800 FIG 8 9/26 FIG 9 Painel A 3ΰΰ 10/26 FIG 9 Painel B 11/26 FIG 10 /000 Fluxo de dados de autenticação 12/26 Ζ/Ζξ ZZÍÇ /z v z/jy tt4O FIG 11 13/26 FIG 12 7200 7270 Z2 1205 127$ 7225 V. 7230 123^ 7240^ 724^ 7230 14/26 FIG 13 Agente de Depósito ' Agente de transação autenticação
15
15/26 FIG 14 Γ'
16
16/26 FIG 15 De! At· Módulo de redundância De A2 De A3 Comparador _^Para agente de transação A4
17
17/26 FIG 16 ζλ«·
18
18/26 FIG 17
19
19/26 FIG 18
20
20/26 Usuário Agente de confiança Vendedor
21
21/26 FIG 20
22
22/26 FIG 21 Encriptar Encriptação RC4 com chave mestre de sessão ' Acessar chave mestra de sessão Dividir dados de acordo com chave de sessão compartilhamento encriptado 1 (dados/chave sessão) Analisar gramaticalmente /chave / de / n f compartilhamento encriptado 3 (dados/chave de sessão) Obscurecer compartilhamento encriptado 2 (dados / chave de sessão) Z Chave / TJ compartilhamèntò / encriptado n /. (dados / chave de r sessão) '· _ 7‘ Chave 3 j
23
23/26 FIG 22 Encriptar Obscurecer mpartilhamehto / / encriptadon / C h ® v ® / dados/ID de / 3 / transação) / j .....f
24
24/26 FIG 23 Chave intermediária (mestra de analisador gramatical XOR mestra de Encriptar
25
25/26 FIG 24 f Acessar chave mestra de analisador gramatical Chave intermediária (mestra de analisador gramatical XOR mestra de iGerar chave mestra de sessão Encriptar Dados a serem analisados gramaticalmente Chave de sessão a ser tomada segura gramaticalmente Obscurecer
26
26/26 FIG 25 CEO CFO Gerenciamento Marketing Administrador de AP de VP de rede

Independent claims26

471 paragraphs in 2 sections, as filed

(54) Title: SECURE DATA ANALYZING METHOD AND SYSTEM (30) Unionist Priority: 11/06/2003 us 10 / 458,928 (71) Depositor (s): Security First Corporation (US) (72) Inventor (s): Rick Orsini, John Vanzandt, Mark O'Hare, Roger Davenport (74) Attorney: Dannemann, Siemsen, Bigler & Ipanema Moreira (86) International Request: pct US2004 / 018426 of 10/06/2004 (87) International Publication: wo 2004 / 111791 of 12/23/2004 (57) Abstract: METHOD AND SAFE DATA ANALYZER SYSTEM. The present invention relates to a method and system for securing sensitive data from unauthorized access or use. The method and system of the present invention are useful in a wide variety of scenarios, including commercial scenarios generally available to the public, which can be extremely large or small with respect to the number of users. The method and system of the present invention are also useful in a more private setting, such as with a corporation or government agency, as well as between corporations, government agencies or any other entity.

T4xm

Descriptive Report of the Invention Patent for METHOD AND SAFE DATA ANALYZER SYSTEM.

Background of the Invention

Related Order Reference

The present application claims the benefit under 35 USC § 120 of US Patent Application Serial No. 10 / 458,928, filed on June 11, 2003, which is partly a continuation of the co-pending non-provisional serial number 09 / 666,519, filed on September 20, 2000, which claims priority benefit under 35 USC § 119 (e) of US Provisional Application No. 60 / 154,734, filed on September 20, 1999, entitled SECURE SITE FOR INTERNET TRANSACTIONS '' and US Provisional Application No. 60 / 200,396, filed on April 27, 2000, entitled SECURE SITE FOR INTERNET TRANSACTIONS. Field of the Invention

The present invention relates, in general, to a system for data security regarding unauthorized access or use.

Description of the Related Art

In today's society, individuals and businesses conduct an increasing amount of activities on and by computer systems. These computer systems, including proprietary and non-proprietary computer networks, are frequently storing, archiving and transmitting all types of sensitive information. Thus, there is an increasing need for security of data stored and transmitted by these systems so that they are not read or otherwise compromised.

A common solution for securing computer systems is to provide login and password functionality. However, password management has proven to be quite expensive with a large percentage of calls to call centers regarding password issues. Furthermore, passwords provide little security because they are generally stored in a file susceptible to improper access, for example, through brute force attacks.

Another solution for securing computer systems is to provide cryptographic infrastructures. Encryption, in general, refers to protecting data by transforming or encrypting it in a non-readable format. Only those who have the encryption key (s) can decrypt the data in a usable format. Encryption is used to identify users, for example, authentication, to allow access privileges, for example, authorization, to create digital certificates and signatures, and the like. A popular encryption system is a public key system that uses two keys, a public key known to anyone and a private key known only to the individual or business owner. Generally, data encrypted with one key is decrypted with the other, and no key can be recreated from the other.

Unfortunately, even with the preceding typical public key cryptographic systems, they are still highly confident in the user as to security. For example, cryptographic systems issue the private key to the user, for example, through the user's browser. Unsophisticated users, then, usually store the private key on a hard drive accessible to others through an open computer system, such as, for example, the Internet. On the other hand, users can choose bad names for files containing their private key, such as, for example, a key. The result of previous acts and others is to allow the key or keys to be susceptible to compromise.

In addition to the foregoing compromises, a user can save his or her private key on a computer system configured with an archiving or backup system, potentially resulting in copies of the private key traveling through multiple computer storage devices or other systems. This security breach is often referred to as key migration. Similar to key migration, many applications provide access to a user's private key through, at most, a simple login and password access. As previously mentioned, login and password access often does not provide adequate security.

One solution to increase the security of previous cryptographic systems is to include biometrics as part of authentication or authorization. Biometrics generally includes measurable physical characteristics, such as, for example, fingerprints or dialogue that can be verified by an automated system, such as, for example, a pattern combination or a recognition of fingerprint patterns or dialogue patterns. In these systems, a user's biometrics and / or keys can be stored on mobile computing devices, such as, for example, a smart card, a laptop, a personal digital assistant or a mobile phone, thereby allowing the biometric or the keys are usable in a mobile environment.

The preceding mobile biometric cryptographic system still suffers from a variety of drawbacks. For example, the mobile user may lose or break the smart card or portable computing device, thereby having their access to potentially important data entirely cut off. Alternatively, a malicious person can steal the mobile user's smart card or portable computing device and use it to effectively steal the mobile user's digital credentials. On the other hand, the portable computing device can be connected to an open system, such as the Internet, and like passwords, the file in which the biometric is stored can be susceptible to compromise through the user's inattention to security or to malicious intruders. Summary of the Invention

Based on the precedent, there is a need to provide a cryptographic system whose security is independent of the user, while still supporting mobile users.

Accordingly, an aspect of the present invention is to provide a method for securing virtually any type of data from unauthorized access or use. The method comprises one or more steps of grammatical analysis, division or separation of the data to be made safe in two or more parts or portions. The method also comprises the encryption of the data to be made secure. Encryption of the data can be performed before or after the first grammatical analysis, division or separation of the data. In addition, the encryption step can be repeated for one or more pieces of data. Similarly, the steps of grammatical analysis, division or separation can be repeated for one or more portions of the data. The optionally method also comprises storing the parsed, divided or separated data that has been encrypted in one location or in multiple locations. This method optionally also comprises the reconstitution or remounting of secure data in its original form for authorized access or use. This method can be incorporated into the operations of any computer, server, agent or similar, which is capable of performing the desired steps of the method.

Another aspect of the present invention provides a system for securing virtually any type of data from unauthorized access or use. This system comprises a data division module, a cryptographic manipulation module and, optionally, a data assembly module. The system, in one embodiment, can still comprise one or more data storage facilities, where secure data can be stored.

Therefore, an aspect of the invention is to provide a secure server or a trusted agent, which has server-centric keys or, in other words, the storage of encryption keys and user authentication data on a server. According to this modality, a user accesses the trust agent in order to perform authentication and cryptographic functions, such as, but not limited to, for example, authentication, authorization, digital signature and generation, storage and retrieval of certificates, encryption, notary and proxy type actions, and the like.

Another aspect of the invention is to provide a trusted or secured authentication process. Furthermore, subsequent to reliable positive authentication, a wide number of different actions can be taken, from providing cryptographic technology for authorization and access of a system or device, to allowing the use or control of one or a wide number of electronic devices. .

Another aspect of the invention is to provide encryption keys and authentication data in an environment where they are not lost, stolen or compromised, thereby advantageously avoiding a need to continually reissue and manage new authentication keys and data. According to another aspect of the invention, the trusted agent allows the user to use a key pair for multiple activities, vendors and / or authentication requests. According to yet another aspect of the invention, the trusted agent performs at least one cryptographic processing step, such as, but not limited to, server side encryption, authentication or signature, thereby allowing customers or users to have only minimal computing resources.

In accordance with yet another aspect of the invention, the trusted agent includes one or multiple data stores for storing portions of each encryption key and authentication data. Portions are created through a data-sharing process that prohibits reconstruction without a predetermined portion of more than one location in a warehouse or from multiple stores. According to one embodiment, multiple deposits can be geographically remote, so that a rogue employee or a system otherwise compromised in a deposit does not provide access to a user key or authentication data.

According to yet another modality, the authentication process advantageously allows the trusted agent to process multiple authentication activities in parallel. According to yet another modality, the trusted agent can advantageously monitor failed access attempts and thereby limit the number of times that malicious intruders can attempt to subvert the system.

According to yet another modality, the trusted agent can include multiple instantiations, where each trusted agent can predict and share processing loads with others. According to yet another modality, the trusted agent can include a redundancy module for interrogating a plurality of authentication results to ensure that more than one system authenticates the user.

Therefore, an aspect of the invention includes a secure cryptographic system, which can be remotely accessible, for storing data of any kind, including, but not limited to, a plurality of private cryptographic keys to be associated with a plurality of users. The cryptographic system associates each of the plurality of users with one or more keys other than the plurality of private cryptographic keys and performs cryptographic functions for each user, using one or more different associated keys, without releasing the plurality of private cryptographic keys to the users. The cryptographic system comprises a deposit system that has at least one server, which stores the data to be made secure, such as a plurality of private cryptographic keys and a plurality of registration authentication data. Each registration authentication data identifies one of multiple users and each of the multiple users is associated with one or more keys other than the plurality of private cryptographic keys. The cryptographic system may also comprise an authentication agent, which compares authentication data received by one of the multiple users with registration authentication data corresponding to one from multiple users and received from the deposit system, thereby producing an authentication result. The cryptographic system may also comprise a cryptographic agent which, when the authentication result indicates an appropriate identification of one of the multiple users, performs cryptographic functions on behalf of one of the multiple users, using one or more associated different keys received from the system. deposit. The cryptographic system can also comprise a connected transaction agent to route data from multiple users to the deposit server system, the authentication agent and the cryptographic agent.

Another aspect of the invention includes a secure cryptographic system that is optionally accessible remotely. The cryptographic system comprises a deposit system that has at least one server, which stores at least one private key and any other data, such as, but not limited to, a plurality of registration authentication data, where each of the registration data Registration authentication identifies one of possibly multiple users. The cryptographic system can optionally also comprise an authentication agent which compares the authentication data received by the users with registration authentication data corresponding to the user and received from the deposit system, thereby producing an authentication result. The cryptographic system also comprises a cryptographic agent which, when the authentication result indicates an appropriate identification of one of the multiple users, performs cryptographic functions on behalf of the user, using at least the said private key, which can be received from the deposit system. The cryptographic system can optionally also comprise a connected transaction agent to route user data to other agents or systems, such as, but not limited to, the deposit server system, the authentication agent and the cryptographic agent.

Another aspect of the invention includes a method of facilitating cryptographic functions. The method comprises associating a user of multiple users with one or more keys from a plurality of private cryptographic keys stored in a secure location, such as a secure server. The method also comprises receiving authentication data from the user, and comparing authentication data with authentication data corresponding to the user, thereby verifying the user's identity. The method also comprises the use of one or more keys to perform cryptographic functions, without releasing one or more keys to the user.

Another aspect of the invention includes an authentication system for uniquely identifying a user through secure storage of user registration authentication data. The authentication system comprises one or more data storage facilities, where each data storage facility includes a computer accessible storage medium, which stores at least one of portions of registration authentication data. The authentication system also comprises an authentication agent which communicates with the data storage facility or facilities. The authentication agent comprises a data division module which operates on the registration authentication data for the creation of portions, a data assembly module which processes the portions from at least one of the data storage facilities , for the assembly of registration authentication data, and a data comparator module which receives a user's current authentication data and compares the current authentication data with the registration authentication data set up to determine whether the user has been uniquely identified.

Another aspect of the invention includes a cryptographic system. The cryptographic system comprises one or more data storage facilities, where each data storage facility includes a computer accessible storage medium which stores at least a portion of one or more cryptographic keys. The cryptographic system also comprises a cryptographic agent which communicates with the data storage facilities. The cryptographic agent also comprises a data division module, which operates on cryptographic keys for the creation of portions, a data assembly module, which processes the portions from at least one of the data storage facilities, for the assembly of cryptographic keys, and a cryptographic manipulation module, which receives the assembled cryptographic keys and performs cryptographic functions with them.

Another aspect of the invention includes a method of storing any type of data, including, but not limited to, authentication data in secure geographically remote data storage facilities, thereby protecting the data against a composition of any data storage facility. individual data. The method comprises receiving data from a trusted agent, combining the data agent with a substantially random first value for the formation of a first combined value and combining data with a substantially random second value for the formation second combined value. The method comprises creating a first match of the first substantially random value with the second combined value, creating a second match of the first substantially random value with the second substantially random value, and storing the first match in a first storage facility secure data. The method comprises storing the second pair in a second secure data storage facility remote from the first secure data storage facility.

Another aspect of the invention includes a method of storing any type of data, including, but not limited to, authentication data comprising receiving data, combining the data with a first set of bits for forming a second set of bits , and combining the data with a third set of bits to form a fourth set of bits. The method also comprises creating a first match of the first set of bits with the third set of bits. The method also comprises creating a second match of the first set of bits with the fourth set of bits, and storing the first and second pairings in a first computer-accessible storage medium. The method also comprises storing the other's first and second pairings in a second computer-accessible storage medium.

Another aspect of the invention includes a method of storing cryptographic data in secure geographically remote data storage facilities, thereby protecting the graphical cryptographic data against understanding any individual data storage facility. The method comprises receiving cryptographic data from a trust agent, combining the cryptographic data with a substantially random first value into the trust agent, and combining the cryptographic data with a substantially random second value for the formation of a second combined value. The method also comprises creating a first match of the first substantially random value with the second combined value, creating a second match of the first substantially random value with the second substantially random value and storing the first match in a first storage facility secure data. The method also comprises storing the second pairing in a second secure data storage facility remote from the first secure data storage facility.

Another aspect of the invention includes a method of storing cryptographic data comprising receiving authentication data and combining the cryptographic data with a first set of bits for forming a second set of bits. The method also comprises combining cryptographic data with a third set of bits to form a fourth set of bits, creating a first match of the first set of bits with the third set of bits, and creating a second match of the first set of bits with the fourth set of bits. The method also comprises storing one of the first and second pairings in a first computer accessible storage medium, and storing the other of the first and second pairings in a second computer accessible storage medium.

Another aspect of the invention includes a method of manipulating sensitive data of any type or form in a cryptographic system, where the sensitive data exists in a form usable only during actions by authorized users, using the sensitive data. The method also comprises receipt in a software module of substantially randomized or encrypted sensitive data from a first computer accessible storage medium, and receipt in the software module of substantially randomized or encrypted data which may or may not be data one or more other computer-accessible storage media. The method also comprises the processing of substantially randomized pre-encrypted sensitive data and substantially randomized or encrypted data, which may or may not be sensitive data, in the software module for assembling sensitive data and the use of sensitive data in an agent software to perform an action. The action includes, but is not limited to, authenticating a user and performing a cryptographic function.

Another aspect of the invention includes a secure authentication system. The secure authentication system comprises a plurality of authentication agents. Each authentication agent receives registration authentication data designed to uniquely identify a user to a degree of certainty. Each authentication agent receives current authentication data for comparison with registration authentication data, and each authentication agent determines an authentication result. The secure authentication system also comprises a redundancy system, which receives the authentication result from at least two of the authentication agents and determines whether the user has been uniquely identified.

Brief Description of Drawings

The present invention is described in greater detail below in relation to the accompanying drawings, which are meant to illustrate and not to limit the invention, and in which:

FIGURE 1 illustrates a block diagram of a cryptographic system, according to aspects of an embodiment of the invention;

FIGURE 2 illustrates a block diagram of the trust agent of FIGURE 1, according to aspects of an embodiment of the invention;

FIGURE 3 illustrates a block diagram of the transaction agent of FIGURE 2, according to aspects of an embodiment of the invention;

FIGURE 4 illustrates a block diagram of the depot of FIGURE 2, according to aspects of an embodiment of the invention;

FIGURE 5 illustrates a block diagram of the authentication agent of FIGURE 2, according to aspects of an embodiment of the invention;

FIGURE 6 illustrates a block diagram of the cryptographic agent of FIGURE 2, according to aspects of an embodiment of the invention;

FIGURE 7 illustrates a block diagram of a deposit system, according to aspects of another embodiment of the invention;

FIGURE 8 illustrates a flow chart of a data division process, according to aspects of an embodiment of the invention;

FIGURE 9, Panel A illustrates a data flow from a registration process, according to aspects of an embodiment of the invention;

FIGURE 9, Panel B illustrates a flow chart of an interoperability process according to aspects of an embodiment of the invention;

FIGURE 10 illustrates an automatic process data flow, according to aspects of an embodiment of the invention;

FIGURE 11 illustrates a data flow from a subscription process, according to aspects of an embodiment of the invention;

FIGURE 12 illustrates a data flow and an encryption / decryption process, according to aspects and yet another embodiment of the invention;

FIGURE 13 illustrates a simplified block diagram of a trust agent system, according to aspects of another embodiment of the invention;

FIGURE 14 illustrates a simplified block diagram of a trust agent system, according to aspects of another embodiment of the invention;

FIGURE 15 illustrates a block diagram of the redundancy module of FIGURE 14, according to aspects of an embodiment of the invention;

FIGURE 16 illustrates a process for evaluating authentications, in accordance with an aspect of the invention;

FIGURE 17 illustrates a process for signing a value for authentication, according to one aspect, as shown in FIGURE 16 of the invention;

FIGURE 18 illustrates a process for performing a trust arbitration in one aspect of the invention, as shown in FIGURE 17; and FIGURE 19 illustrates a sample transaction between a user and a seller according to aspects of an embodiment of the invention, where an initial web-based contact leads to a sales contract signed by both parties.

FIGURE 20 illustrates a sample user system with a cryptographic service provider module which provides security functions for a user system.

FIGURE 21 illustrates a process for parsing, dividing or separating data with encryption and storing the master encryption key with the data.

FIGURE 22 illustrates a process for parsing, dividing or separating data with encryption and storing the master encryption key separately from the data.

FIGURE 23 illustrates the intermediate key process for parsing, dividing or separating data with encryption and storing the master encryption key with the data.

FIGURE 24 illustrates the intermediate key process for parsing, dividing or separating data with encryption and storing the master encryption key separately from the data.

FIGURE 25 illustrates the use of the cryptographic methods and systems of the present invention with a small working group.

Detailed Description of the Preferred Mode

One aspect of the present invention is to provide a graphical cryptographic system, where one or more secure servers, or a trusted agent, store encryption keys and user authentication data. Users access the functionality of conventional cryptographic systems through network access to the trusted agent, although the trusted agent does not release the real keys and other authentication data and, therefore, the keys and data remain secure. This server-centric storage of keys and authentication data provides independent user security, portability, availability and straightness.

Due to the fact that users may have belief or trust in the cryptographic system for performing user and document authentication and other cryptographic functions, a wide variety of functionality can be incorporated into the system. For example, the trust agent provider can be secure against a repudiation of an agreement, for example, by authenticating the agreement participants, by digitally signing the agreement on behalf of or for the participants, and by storing an agreement record digitally signed by each participant. In addition, the cryptographic system can monitor agreements and determine the application of varying degrees of authentication, based, for example, on price, user, seller, geographic location, place of use, or similar.

In order to facilitate a complete understanding of the invention, the remainder of the detailed description describes the invention with reference to the figures, where like elements are referenced with like numbers throughout.

FIGURE 1 illustrates a block diagram of a cryptographic system 100, according to aspects of an embodiment of the invention. As shown in FIGURE 1, the cryptographic system 100 includes a user system 105, a trusted agent 110, a certificate authority 115 and a vendor system 120, communicating over a communication link 125.

According to an embodiment of the invention, user system 105 comprises a conventional general purpose computer that has one or more microprocessors, such as, for example, an Intel-based processor. Furthermore, user system 105 includes an appropriate operating system such as, for example, an operating system capable of including graphics or windows, such as Windows, Unix, Linux or the like. As shown in FIGURE 1, user system 105 can include a biometric device 107. Biometric device 107 can advantageously capture a user's biometric and transfer the captured biometric to trusted agent 110. According to an embodiment of the invention, the biometric device can advantageously comprise a device that has attributes and features similar to those shown in the US Patent Application No. 08 / 926,277, filed on September 5, 1997, entitled RELIEF OBJECT IMAGE GENERATOR, in US Patent Application No. 09 / 558,634, filed on April 26, 2000, entitled IMAGING DEVICE FOR A RELIEF OBJECT AND SYSTEM AND METHOD OF USING THE IMAGE DEVICE, US Patent Application No. 09 / 435,011, filed on November 5, 1999, entitled RELIEF OBJECT SENSOR ADAPTER and US Patent Application No. 09 / 477,943, filed on January 5, 2000, entitled PLANAR OPTICAL IMAGE SENSOR AND SYSTEM FOR GENERATING AN ELECTRONIC IMAGE OF A RELIEF OBJECT FOR FINGERPRINT READING, all of which are owned by the present assignee, and all of which are thus incorporated as a reference here.

In addition, user system 105 can connect to communication link 125 through a conventional service provider, such as, for example, a dial-up connection, a digital subscriber line (DSL), a cable modem, fiber or similar. According to another embodiment, user system 105 connects to communication link 125 via network connectivity, such as, for example, a local or wide area network. According to one embodiment, the operating system includes a TCP / IP stack that handles all incoming and outgoing message traffic through communication link 125.

Although user system 105 is shown with reference to the foregoing embodiments, the invention is not intended to be limited in this way. Instead, a person skilled in the art will recognize from the exhibition here a wide number of alternative modalities of the user system 105, including almost any computing device capable of sending or receiving information from another computer system. For example, user system 105 may include, but is not limited to, a computer workstation, an interactive television, an interactive kiosk, a personal mobile computing device, such as a digital assistant, a built-in computing device, or similar, which can interact with communication link 125. In these alternative systems, the operating systems are likely to differ and be adapted to the particular device. However, according to one embodiment, operating systems advantageously continue to provide the appropriate communication protocols necessary for establishing communication with the communication link 125.

FIGURE 1 illustrates the trusted agent 110. According to one embodiment, the trusted agent 110 comprises one or more secure servers for accessing and storing sensitive information, which can be any type or form of data, such as, but not limiting, text, audio, video, user authentication data and public and private cryptographic keys. According to one embodiment, authentication data includes data designed to uniquely identify a user of the cryptographic system 100. For example, authentication data can include a user identification number, one or more biometrics, and a series of questions and responses generated by the trust agent 110 or by the user, but initially answered by the user in the registry. The preceding questions may include demographic data, such as place of birth, address, birthday or similar, personal data, such as the mother's maiden name, favorite ice cream or similar, or other data designed to uniquely identify the user. Trust agent 110 compares a user's authentication data associated with a current transaction with the authentication data provided in a previous time, such as during registration. The trusted agent 110 can advantageously require the user to produce authentication data at the time of each transaction or the trusted agent 110 can advantageously allow the user to periodically produce authentication data, such as at the beginning of a transaction chain or while if you enter a particular seller website.

According to the mode in which the user produces biometric data, the user provides a physical characteristic, such as, but not limited to, a facial scan, a hand scan, an ear scan, an iris scan, a retinal scan , a vascular pattern, DNA, a fingerprint, writing or dialogue, for the biometric device 107. The biometric device advantageously produces an electronic, or biometric, pattern of the physical characteristic. The electronic standard is transferred through the user system 105 to the trust agent 110 for the purposes of registration or authentication.

Once the user produces the appropriate authentication data and the trust agent 110 determines a positive combination between the authentication data (current authentication data) and the authentication data provided at the time of registration (registration authentication data), trust agent 110 provides the user with full cryptographic functionality. For example, the appropriately authenticated user may advantageously employ the trusted agent 110 for hashing, digital signature, encryption and decryption (often together referred to only as encryption), creation or distribution of digital certificates, and the like. However, the private cryptographic keys used in the cryptographic functions will not be available outside the trusted agent 110, thereby ensuring the integrity of the cryptographic keys.

According to one embodiment, the trusted agent 110 generates and stores cryptographic keys. According to another modality, at least one cryptographic key is associated with each user. Furthermore, when cryptographic keys include public key technology, each private key associated with a user is generated in and not released from the trusted agent 110. Thus, as long as the user has access to the trusted agent 110, the user can perform cryptographic functions using his private or public key. Such remote access, advantageously, allows users to remain completely mobile and access cryptographic functionality through virtually any Internet connection, such as cell and satellite phones, kiosks, laptops, hotel rooms and the like.

According to another embodiment, trust agent 110 performs cryptographic functionality using a key pair generated for trust agent 110. According to this modality, the trust agent 110 first authenticates the user and, after the user has properly produced authentication data matching the registration authentication data, the trust agent 110 uses its own cryptographic key pair for the performing cryptographic functions on behalf of the authenticated user.

A skilled technician will recognize from the exhibit here that cryptographic keys can advantageously include some or all of symmetric keys, public keys and private keys. In addition, a skilled technician will recognize from the exhibit here that the preceding keys can be implemented with a wide number of algorithms available from commercial technologies such as, for example, RSA, ELGAMAL or similar.

FIGURE 1 also illustrates certificate authority 115. According to one embodiment, certificate authority 115 can advantageously comprise a trusted third party organization or company that issues digital certificates, such as, for example, VeriSign, Baltimore, Entrust or similar. The trusted agent 110 can advantageously transmit requests for digital certificates, through one or more conventional digital certificate protocols, such as, for example, PKCS10 to the certificate authority 115. In response, the certificate authority19 of 115 will issue a certificate over one or more of several different protocols, such as, for example, PKCS7. According to an embodiment of the invention, the trust agent 110 requests digital certificates from several or all of the prominent certificate authorities 115, so that the trust agent 110 has access to a digital certificate corresponding to the certificate certificate standard. any requesting party.

According to another modality, the trusted agent 110 internally performs certificate issues. In this modality, the trusted agent 110 can access a certificate system for the generation of certificates and / or can generate certificates internally, when they are requested, such as, for example, at the time of key generation or in the required certificate standard. at the time of request. Trust agent 110 will be shown in more detail below.

FIGURE 1 also illustrates vendor system 120. According to one embodiment, vendor system 120 advantageously comprises a web server. Typical web servers generally serve content over the Internet using one of several internet markup languages or document format standards, such as the Hypertext Markup Language (HTML) or the Extensible Markup Language (XML). The web server accepts requests from browsers such as Netscape and Internet Explorer and then returns the appropriate electronic documents. Several of the server or client-side technologies can be used to increase the power of the web server in addition to its ability to send standard electronic documents. For example, these technologies include Common Port Interface Scripts (CGI), secure Sockets Layer security (SSL) and Active Server Pages (ASPs). The vendor system 120 can advantageously provide electronic content relating to business, personal, educational or other transactions.

Although the vendor system 120 is shown with reference to the foregoing embodiments, the invention is not intended to be limited in that way. Instead, a skilled technician will recognize from the exhibit here that the vendor system 120 can advantageously comprise any of the devices described with reference to user system 105 or a combination thereof.

FIGURE 1 also illustrates communication link 125 connecting user system 105, trust agent 110, certificate authority 115 and vendor system 120. According to one embodiment, communication link 125 preferably comprises the Internet . The Internet, as used throughout this exhibition, is a global computer network. The structure of the Internet, which is well known to those of ordinary skill in the art, includes a network framework with networks branching out from the framework. These branches, in turn, have networks branching out from them, and so on. Routers move packets of information between network levels and then from network to network, until the packet reaches the neighborhood of its destination. From the destination, the destination network's main computer directs the information packet to the appropriate terminal or node. In an advantageous embodiment, Internet routing connection centers comprise Domain Name System (DNS) servers using Transmission Control Protocol / Internet Protocol (TCP / IP), as is well known in the art. Routing hubs connect to one or more other routing hubs via high-speed communication links.

A popular part of the Internet is the World Wide Web. The World Network contains different computers, which store documents capable of displaying graphic and textual information. Computers that provide information on the World Wide Web are typically called websites. A website is defined by an Internet address that has an associated website. The website can be identified by a Uniform Resource Locator (URL). Generally, an electronic page is a document that organizes the presentation of text, graphic images, audio, video and so on.

Although the communication link 125 is shown in terms of its preferred modality, one skilled in the art will recognize from the exhibit here that the communication link 125 can include a wide range of interactive communication links. For example, the communication link 125 may include interactive television networks, telephone networks, wireless data transmission systems, two-way cable systems, personalized private or public computer networks, interactive kiosk networks, cashier networks electronics, direct calls, satellite or cellular networks, and the like.

FIGURE 2 illustrates a block diagram of the trust agent 110 of FIGURE 1, according to aspects of an embodiment of the invention. As shown in FIGURE 2, the trust agent 110 includes a transaction agent 205, a deposit 210, an authentication agent 215 and a cryptographic agent 220. According to an embodiment of the invention, the trust agent 110 also includes a store of mass 225. As additionally shown in FIGURE 2, transaction agent 205 communicates with deposit 210, authentication agent 215 and cryptographic agent 220, together with mass storage 225. In addition, deposit 210 communicates with deposit agent authentication 215, cryptographic agent 220 and mass storage 225. Furthermore, authentication agent 215 communicates with cryptographic agent 220. According to an embodiment of the invention, some or all of the foregoing communications advantageously may comprise the transmission of XML documents to IP addresses that correspond to the receiving device. As mentioned earlier, XML documents advantageously allow designers to create their own personalized document labels, allowing for the definition, transmission, validation and interpretation of data between applications and between organizations. Furthermore, some or all of the preceding communications may include conventional SSL technologies.

According to one embodiment, transaction agent 205 comprises a data routing device, such as a conventional web server available from Netscape, Microsoft, Apache or the like. For example, the web server can advantageously receive incoming data from communication link 125. According to an embodiment of the invention, incoming data is addressed to a front-end security system for trust agent 110. For example, the front-end security system can advantageously include a firewall, an intrusion detection system looking for known attack profiles, and / or a virus scanner. After cleaning the frontend security system, data is received by transaction agent 205 and prorated to one of deposit 210, authentication agent 215, cryptographic agent 220 and mass storage 225. In addition, transaction agent 205 monitors data coming in from authentication agent 215 and cryptographic agent 220, and pays the data to private systems via communication link 125. For example, transaction agent 205 can advantageously prorating data to user system 105, certificate authority 115 or vendor system 120.

According to one modality, the data is prorated using conventional HTTP routing techniques, such as, for example, the use of URLs or Uniform Resource Indicators (URIs). URIs are similar to URLs, although URIs typically indicate the origin of files or actions, such as, for example, executables, Scripts and the like. Therefore, according to one embodiment, user system 105, certificate authority 115, vendor system 120 and components of deposit 210 advantageously include sufficient data in URLs or communication URIs for transaction agent 205 to be prorated. data appropriately throughout the cryptographic system.

Although data routing is shown with reference to your preferred modality, a skilled technician will recognize a wide range of possible data routing solutions or strategies. For example, XML data packets or the like can advantageously be unpacked and recognized by their format, content or the like, so that transaction agent 205 can appropriately prorate data across the trust agent 110. Furthermore, a skilled technician will recognize that the data routing can advantageously be adapted to the data transfer protocols in accordance with particular network systems, such as, for example, when the communication link 125 comprises a local network.

In accordance with yet another embodiment of the invention, transaction agent 205 includes conventional SSL encryption technologies, so that previous systems can authenticate themselves, and vice versa, with transaction agent 205 during particular communications. . As will be used throughout this exhibition, the term1/ 2 SSL refers to communications in which the server, but not necessarily the client, is authenticated with SSL, and the term SSL PLENA refers to communications in which the client and server are authenticated with SSL. When the present exhibition uses the term SSL, the communication can comprise1Λ SSL or FULL SSL.

As transaction agent 205 rates data for the various components of cryptographic system 100, transaction agent 205 can advantageously create an audit trail. According to one embodiment, the audit trail includes a record of at least the type and format of data prorated by transaction agent 205 throughout the cryptographic system 100. Such audit data can advantageously be stored in mass storage 225.

FIGURE 2 also illustrates depot 210. According to one embodiment, depot 210 comprises one or more data storage facilities, such as, for example, a directory server, a database server or the like. As shown in FIGURE 2, deposit 210 stores cryptographic keys and registration authentication data. The cryptographic keys can advantageously correspond to the trusted agent 110 or to users of the cryptographic system 100, such as the user or the vendor. Registration authentication data can advantageously include data designed to uniquely identify a user, such as user ID, passwords, answers to questions, biometric data or the like. This registration authentication data can advantageously be acquired at a user's registration or at another alternative time later. For example, trust agent 110 may include periodic or other renewal or reissue of registration authentication data.

According to one embodiment, communication from transaction agent 205 to and from authentication agent 215 and cryptographic agent 220 comprises secure communication, such as, for example, conventional SSL technology. In addition, as mentioned earlier, data from communications to and from deposit 210 can be transferred using URLs, URIs, HTTP or XML documents, with any of the foregoing advantageously having data requests and formats embedded there.

As mentioned above, storage 210 can advantageously comprise a plurality of secure data storage facilities. In such an embodiment, secure data storage facilities can be configured so that a security compromise in an individual data storage facility does not compromise the cryptographic keys or authentication data stored there. For example, according to this modality, cryptographic keys and authentication data are mathematically operated, in order to statistically and substantially randomize the data stored in each data storage facility. According to one modality, the randomization of data from an individual data storage facility makes that data indecipherable. Thus, a compromise of an individual digital image analysis produces only an indecipherable randomized number and does not compromise the security of any cryptographic keys or authentication data as a whole.

FIGURE 2 also illustrates the trust agent 110 including the authentication agent 215. According to one embodiment, the authentication agent 215 comprises a data comparator configured for comparing data from transaction agent 205 with data from deposit 210. For example, during an authentication, a user supplies current authentication data for trust agent 110, so that transaction agent 205 receives the current authentication data. As mentioned earlier, transaction agent 205 recognizes data requests, preferably at the URL or URI, and routes authentication data to authentication agent 215. Furthermore, upon request, deposit 210 forwards authentication data from records corresponding to the user for the authentication agent 215. Thus, the authentication agent 215 has the current authentication data and the registration authentication data for comparison.

According to one embodiment, communications to the authentication agent comprise secure communications, such as, for example, SSL technology. In addition, security can be provided on trust agent components 110 such as, for example, super-encryption using public key technologies. For example, according to one modality, the user encrypts the current authentication data with the authentication agent's public key 215. In addition, deposit 210 also encrypts the registration authentication data with the authentication agent's public key 215. In this way, only the authentication agent's private key can be used for decryption of transmissions.

As shown in FIGURE 2, trust agent 110 also includes cryptographic agent 220. According to one embodiment, the cryptographic agent comprises a cryptographic manipulation module configured to advantageously provide conventional cryptographic functions, such as, for example, a cryptographic functionality. public key infrastructure (PKI). For example, cryptographic agent 220 can advantageously issue public and private keys to users of cryptographic system 100. In this way, cryptographic keys are generated at cryptographic agent 220 and forwarded to deposit 210, so that at least private cryptographic keys are not available outside of trusted agent 110. According to another modality, cryptographic agent 220 randomizes and splits at least the data from private cryptographic keys, thereby storing only the randomized split data. Similar to splitting the registration authentication data, the splitting process ensures that the stored keys are not available outside the cryptographic agent 220. According to one embodiment, the functions of the cryptographic agent can be combined with and performed by the encryption agent 215 authentication.

According to one embodiment, the components to and from the cryptographic agent include secure communications, such as SSL technology. In addition, XML documents can advantageously be used for data transfer and / or making cryptographic function requests.

FIGURE 2 also illustrates the trust agent 110 having mass storage 225. As mentioned in the preceding, 205 maintains data corresponding to an audit trail and stores such data in mass storage 225. Similarly, according to a embodiment of the invention, deposit 210 maintains data corresponding to an audit trail and stores such data in mass storage 225. The deposit audit tracking data is similar to that of transaction agent 205 in that the audit tracking data comprises a record of the requests received by deposit 210 and its response. In addition, mass storage 225 can be used for storing digital certificates by having a user's public key contained therein.

Although the trusted agent 110 is shown with reference to its preferred and alternative modalities, the invention is not intended to be limited in this way. Instead, a skilled technician will recognize in the exhibition here a wide number of alternatives for the trusted agent 110. For example, the trusted agent 110 can advantageously perform only one authentication or, alternatively, only some or all of the cryptographic functions, such as data encryption and decryption. According to these modalities, one of the authentication agent 215 and the cryptographic agent 220 can advantageously be removed, thereby creating a more direct design for the trusted agent 110. In addition, cryptographic agent 220 can also communicate with a certificate authority, so that the certification authority is implemented in trust agent 110. In yet another embodiment, trust agent 110 can advantageously perform authentication and one or more cryptographic functions, such as, for example, digital signature.

FIGURE 3 illustrates a block diagram of the transaction agent 205 of FIGURE 2, according to aspects of an embodiment of the invention. According to this embodiment, the transaction agent 205 comprises an operating system 305 that has a handling wire and a listening wire. The 305 operating system can advantageously be similar to those found on conventional high-volume servers, such as, for example, Web servers available from Apache. The listening wire monitors the incoming communication from one of the communication link 125, the authentication agent 215 and the cryptographic agent 220 for an incoming data stream. The manipulation thread recognizes data structures particular to the incoming data stream, such as, for example, the preceding data structures, thereby routing the input data to one of the communication link 125, depot 210, the agent of authentication 215, cryptographic agent 220 or mass storage 225. As shown in FIGURE 3, the incoming and outgoing data can advantageously be made secure, for example, through SSL technology.

FIGURE 4 illustrates a block diagram of the deposit 210 of FIGURE 2, according to aspects of an embodiment of the invention. In accordance with this embodiment, depot 210 comprises one or more Light Directory Access Protocol (LDAP) servers. LDAP directory servers are available from a wide variety of manufacturers, such as Netscape, ISO and others. FIGURE 4 also shows that the directory server preferably stores data 405 corresponding to cryptographic keys and data 410 corresponding to registration authentication data. According to one embodiment, deposit 210 comprises a unique logical memory structure indexing two and cryptographic key data to a unique user ID. The unique logical memory structure preferably includes mechanisms to guarantee a high degree of confidence, or security, in the data stored there. For example, the physical location of deposit 210 may advantageously include a wide range of conventional security measures, such as limited employee access, modern security systems and the like. In addition, or in lieu of it, physical security, computer system or server can advantageously include software solutions for protecting stored data. For example, deposit 210 can advantageously create and store data 415 corresponding to an audit trail of actions taken. In addition, incoming and outgoing communications can advantageously be encrypted with public key encryption coupled with conventional SSL technologies.

According to another embodiment, storage 210 may comprise separate and physically separate data storage facilities, as further shown with reference to FIGURE 7.

FIGURE 5 illustrates a block diagram of the authentication agent 215 of FIGURE 2, according to aspects of an embodiment of the invention. Similar to transaction agent 205 of FIGURE 3, authentication agent 215 comprises an operating system 505 that has at least one listening wire and one for handling a modified version of a conventional web server, such as, for example , web servers available from Apache. As shown in FIGURE 5, authentication agent 215 includes access to at least one private key 510. Private key 510 can advantageously be used, for example, for the decryption of data from transaction agent 205 or deposit 210, which have been encrypted with a corresponding public key from the authentication agent 215.

FIGURE 5 also illustrates authentication agent 215 with 29 comprising a comparator 515, a data division module 520 and a data assembly module 525. According to the preferred embodiment of the invention, comparator 515 includes a technology capable of comparing potentially complex patterns related to previous biometric authentication data. The technology may include hardware, software, or combined solutions for pattern comparisons, such as, for example, those representing fingerprint patterns or voice patterns. Furthermore, according to one embodiment, comparator 515 of authentication agent 215 can advantageously compare conventional document evidence in order to produce a comparison result. According to an embodiment of the invention, comparator 515 includes the application of heuristics 530 to the comparison. The 530 heuristic can advantageously address circumstances involving an attempted authentication, such as, for example, the time of day, IP address or subnet mask, purchase profile, email address, the processor serial number or ID, or similar.

Furthermore, the nature of comparisons of biometric data can result in varying degrees of confidence being produced by combining current biometric authentication data with registration data. For example, unlike a traditional password, which can only return a positive or negative match, a fingerprint can be determined to be a partial match, for example, a 90% match, a 75% match or a match 10%, rather than just being correct or incorrect. Other biometric identifiers, such as a voice print analysis or face recognition, may share this property of probabilistic authentication, rather than absolute authentication.

When working with such probabilistic authentication or in other cases where an authentication is considered to be less than absolutely reliable, it is desirable to apply the 530 heuristic to determine whether the level of trust in the provided authentication is high enough for the authentication of the transaction. which is being done.

Sometimes, it will be the case that the transmission in question is a relatively low value transaction, in which it is acceptable to be authenticated to a lower confidence level. This could include a transaction which has a low dollar value associated with it (for example, a $ 10 purchase) or a low risk transaction (for example, admission to a members only website).

Conversely, for authentication of other transactions, it may be desirable to require a high degree of trust in authentication, before allowing the transaction to proceed. Such transactions may include large dollar transactions (for example, signing a multi-million dollar supply contract) or a transaction with a high risk if improper authentication occurs (for example, remote entry into the system at a government computer).

The use of the 530 heuristic in combination with confidence levels and transaction values can be used, as will be described below, to allow the comparator to provide a dynamic context sensitive authentication system.

According to another embodiment of the invention, comparator 515 can advantageously track authentication attempts for a particular transaction. For example, when a transaction fails, the trust agent 110 may require the user to re-enter their current authentication data. Comparator 515 of authentication agent 215 may advantageously employ a trial limiter 535 to limit the number of authentication attempts, thereby prohibiting brute force attacks to impersonate a user's authentication data. According to one embodiment, the attempt limiter 535 comprises a software module that monitors transactions for repeated authentication attempts and, for example, limiting authentication attempts for a given transaction to three. Thus, attempt limiter 535 will limit an automated attempt to impersonate an individual's authentication data to, for example, simply three guesses. Through three failures, the attempt limiter 535 can advantageously deny additional authentication attempts. Such a denial can advantageously be implemented through comparator 515, for example, returning a negative result, regardless of the current authentication data being transmitted. On the other hand, transaction agent 205 can advantageously block any additional authentication attempts for a transaction in which three attempts have previously failed.

Authentication agent 215 also includes data division module 520 and data assembly module 525. The data division module 520 advantageously comprises software, hardware or a combination module that has the ability to mathematically operate over various data, in order to substantially randomize and divide the data into portions. According to one embodiment, original data is not recreatable from an individual portion. The data assembly module 525 advantageously comprises software, hardware or a combination module configured to mathematically operate on the substantially randomized preceding portions, so that the combination thereof provides the original deciphered data. According to one embodiment, the authentication agent 215 employs the data division module 520 for randomization and the division of registration authentication data into portions, and employs the data assembly module 525 to reassemble the portions in data from usable registration authentication.

FIGURE 6 illustrates a block diagram of the cryptographic agent 220 of the trust agent 200 of FIGURE 2, according to aspects of an embodiment of the invention. Similar to transaction agent 205 in FIGURE 3, cryptographic agent 220 comprises an operating system 605 that has at least one listening wire and one for handling a modified version of a conventional web server, such as, for example, the web servers available from Apache. As shown in FIGURE 6, cryptographic agent 220 comprises a data division module 610 and a data assembly module 620 that operate similarly to those in FIGURE 5. However, according to one embodiment, the data division module 610 and data assembly module 620 process cryptographic key data, as opposed to previous record authentication data. However, a skilled technician will recognize from the exhibit here that data division module 610 and data assembly module 620 can be combined with those of authentication agent 215.

Cryptographic agent 220 also comprises a cryptographic manipulation module 625 configured to perform one, some or all of a wide number of cryptographic functions. According to one embodiment, the cryptographic manipulation module 625 may comprise software modules or programs, hardware or both. According to another modality, the cryptographic manipulation module 625 can perform data comparisons, grammatical data analysis, data division, data separation, data hashing, data encryption or decryption, digital signature verification or creation, generation digital certificate, storage or requisitions, cryptographic key generation, or the like. Furthermore, a skilled technician will recognize from the exhibit here that cryptographic manipulation module 625 can advantageously comprise a public key infrastructure, such as Pretty Good Privacy (PGP), an RSA-based public key system, or a broad number of alternative key management systems. In addition, the cryptographic manipulation module 625 can perform public key encryption, symmetric key encryption, or both. In addition to the foregoing, the cryptographic manipulation module 625 may include one or more computer programs or modules, hardware, or both, for the implementation of seamless, transparent, interoperable functions.

A skilled technician will also recognize from the exhibit here that cryptographic functionality can include a wide number or a variety of functions generally relating to cryptographic key management systems.

FIGURE 7 illustrates a simplified block diagram of a deposit system 700 according to aspects of an embodiment of the invention. As shown in FIGURE 7, the deposit system 700 advantageously comprises multiple data storage facilities, for example, data storage facilities D1, D2, D3 and D4. However, it is readily understood by those skilled in the art that the deposit system can have only one data storage facility. According to an embodiment of the invention, each of the data storage facilities D1 to D4 can advantageously comprise some or all of the elements shown with reference to storage 210 of FIGURE 4. Similar to storage 210, data storage facilities D1 to D4 communicate with transaction agent 205, authentication agent 215 and cryptographic agent 220, preferably through conventional SSL. Communication links transfer, for example, XML documents. Transaction agent 205 communications can advantageously include data requests, where the request is advantageously broadcast to the IP address of each data storage facility D1 through D4. On the other hand, transaction agent 205 can broadcast requests to particular data storage facilities based on a wide number of criteria, such as, for example, response time, server loads, maintenance schedules or the like.

In response to data requests from transaction agent 205, deposit system 700 advantageously forwards stored data to authentication agent 215 and cryptographic agent 220. The respective data assembly modules receive the forwarded data and assemble the data in formats usable. On the other hand, communications from authentication agent 215 and cryptographic agent 220 to data storage facilities D1 through D4 may include the transmission of sensitive data to be stored. For example, according to one embodiment, authentication agent 215 and cryptographic agent 220 can advantageously employ their respective data-splitting modules to divide sensitive data into indecipherable portions and then transmit one or more indecipherable portions of the data sensitive for a particular data storage facility.

According to one embodiment, each data storage facility, D1 to D4, comprises a separate and independent storage system, such as, for example, a directory server. In accordance with another embodiment of the invention, the deposit system 700 comprises multiple geographically separate independent data storage systems. By distributing sensitive data in separate and independent storage facilities D1 to D4, some or all of which may advantageously be geographically separated, the deposit system 700 provides redundancy together with additional security measures. For example, according to one modality, only data from two of the multiple data storage facilities, D1 to D4, are necessary for deciphering and reassembling sensitive data. Thus, as much as two of the four data storage facilities D1 to D4 can be down due to maintenance, a system failure, a power failure or the like, without affecting the functionality of the trusted agent 110. In addition, due to the fact that, according to one modality, the data stored in each data storage facility is randomized and indecipherable, a compromise of any individual data storage facility does not necessarily compromise sensitive data. Furthermore, in the modality that has a geographic separation of the data storage facilities, a compromise of multiple geographically remote facilities becomes increasingly difficult. In fact, even a rogue employee will be greatly challenged to subvert the multiple independent geographically remote data storage facilities.

Although the deposit system 700 is shown with reference to its preferred and alternative embodiments, the invention is not intended to be limited in this way. Instead, a skilled technician will recognize from the exhibit here a wide range of alternatives to the deposit system 700. For example, the deposit system 700 can comprise one, two or more data storage facilities. In addition, sensitive data can be mathematically operated so that portions of two or more data storage facilities are necessary for reassembling and decrypting sensitive data.

As mentioned earlier, authentication agent 215 and cryptographic agent 220 each include a data sharing module 520 and 610, respectively, for dividing any type or form of sensitive data, such as, for example, text , audio, video, authentication data and cryptographic key data. FIGURE 8 illustrates a flow chart of a data division process 800 performed by the data division module according to aspects of an embodiment of the invention. As shown in FIGURE 8, the data-sharing process 800 begins at step 805, when sensitive data S is received by the data-sharing module of authentication agent 215 or cryptographic agent 220. Preferably, in step 810, the data-sharing module Data splitting then generates a substantially random number, value or string or set of bits, A. For example, the random number A can be generated in a wide number of varied conventional techniques available to someone skilled in the art, for the production of high quality random numbers suitable for use in cryptographic applications. In addition, according to one embodiment, the random number A comprises a bit length which can be any suitable length, such as shorter, longer or equal to the bit length of the sensitive data, S.

In addition, in step 820, the data splitting process 800 generates another statistically random number C. According to the preferred embodiment, the generation of statistically random numbers A and C can advantageously be done in parallel. The data division module then combines the numbers A and C with the sensitive data S, so that new numbers B and D are generated. For example, the number B can comprise the binary combination of A XOR S and the number D can comprise the binary combination of C XOR S. The XOR function, or the exclusive function, is well known to those of ordinary skill in the art. The preceding combinations preferably occur in steps 825 and 830, respectively, and, according to one embodiment, the preceding combinations also occur in parallel. The data splitting process 800 then proceeds to step 835, where the random numbers A and C and the numbers B and D are paired, so that none of the pairings contains enough data in itself for reorganization and deciphering the original sensitive data S. For example, the numbers can be paired as follows: AC, AD, BC, and BD. According to one embodiment, each of the preceding matches is distributed to one of the deposits D1 to D4 of FIGURE 7. According to another modality, each of the previous pairings is randomly distributed to one of the deposits D1 to D4. For example, during a first 800 data sharing process, the AC pairing can be sent to warehouse D2, for example, through a random selection of D2's IP address. Then, during a second data-sharing process 800, the AC pairing can be sent to the D4 warehouse, through, for example, a random selection of the D4 IP address. In addition, pairings can all be stored in a warehouse, and can be stored in separate locations in that warehouse.

Based on the foregoing, the data-sharing process 800 advantageously places portions of the sensitive data in each of four data storage facilities D1 to D4, so that no single data storage facility D1 to D4 includes enough encrypted data to the recreation of the original sensitive data S. As mentioned earlier, such randomization of data into individually unusable encrypted portions increases security and provides confidence in the data, even if one of the D1 to D4 data storage facilities is compromised.

Although the data-sharing process 800 is shown with reference to its preferred embodiment, the invention is not intended to be limited in that way. Instead, a skilled technician will recognize from the exhibition here a wide range of alternatives for the 800 data-sharing process. For example, the data division process can advantageously divide the data into two numbers, for example, the random number A and the number B, and randomly distribute A and B through two data storage facilities. Furthermore, the data-sharing process 800 can advantageously divide the data among a wide number of data storage facilities by generating additional random numbers. The data can be divided into any desired size unit, selected, predetermined or randomly assigned, including, but not limited to, one bit, bits, bytes, kilobytes, megabytes or more, or any combination or sequence of sizes. In addition, varying the sizes of data units resulting from the splitting process can make data more difficult to restore to a usable form, thereby increasing the security of sensitive data. It is readily apparent to those of ordinary skill in the art that divided data unit sizes can be a wide variety of data unit sizes or size patterns or size combinations. For example, data unit sizes can be selected or predetermined to be all the same size, a fixed set of different sizes, a combination of sizes, or to generate random sizes. Similarly, data units can be distributed over one or more shares, according to a predetermined data unit size, a pattern or a combination of data unit sizes, or a randomly generated data unit size or sizes per share.

As mentioned earlier, in order to recreate sensitive S data, the data portions need to be randomized and reorganized. This process can advantageously occur in the data assembly modules, 525 and 620 of the authentication agent 215 and the cryptographic agent 220, respectively. The data mounting module, for example, the data mounting module 525 receives the data portions from the data storage facilities D1 to D4, and remounts the data in a usable form. For example, according to an embodiment in which the data-sharing module 520 employed the data-sharing process 800 of FIGURE 8, the data-mounting module 525 uses data portions from at least two of the data storage facilities D1 to D4 for the re-creation of the sensitive data S. For example, the pairings of AC, AD, BC and BD were distributed so that any two provided one of A and B, or C and D. Noting that S = A XOR B or S = C XOR D indicates that when the data assembly module receives one of A and B, or C and D, the data assembly module 525 can advantageously remount the sensitive data S. Thus , the data mounting module 525 can mount the sensitive data S, when, for example, it receives portions of data from at least the first two data storage facilities D1 to D4 to respond to an assembly request by the trusted agent 110.

Based on the data division and assembly processes, sensitive S data exists in a format usable only in a limited area of the trusted agent 110. For example, when sensitive S data includes registration authentication data, authentication data Usable nonrandomized registration keys are available only at the 215 authentication agent. Likewise, when sensitive S data includes private cryptographic key data, non-randomized private cryptographic key data is available only on cryptographic agent 220.

Although the processes of data sharing and assembly are shown with reference to your preferred embodiments, the invention is not intended to be limited in this way. Instead, a knowledgeable technician will recognize from the exhibit here a wide number of alternatives for dividing and reassembling sensitive S data. For example, public key encryption can be used to further secure data in storage facilities. data D1 to D4. Furthermore, it is readily apparent to those of ordinary skill in the art that the data division module described here is also a separate and distinct modality of the present invention that can be incorporated into, combined with or otherwise made part of any systems of pre-existing computers, sets of software programs, databases or combinations thereof, or other modalities of the present invention, such as the trusted agent, the authentication agent and the transaction agent shown and described here.

FIGURE 9A illustrates a data flow from a registration process 900 according to aspects of an embodiment of the invention. As shown in FIGURE 9A, the registration process 900 begins at step 905, when a user wishes to register with the trusted agent 110 of the cryptographic system 100. According to this embodiment, user system 105 advantageously includes a client-side applet, such as Java-based, that prompts the user to enter registration data, such as demographic data and registration authentication data. According to one embodiment, registration authentication data includes user ID, password (s), biometric (s), or the like. According to one embodiment, during the consultation process, the client-side applet preferably communicates with the trusted agent 110 to ensure that a chosen user ID is unique. When the user ID is not unique, the trusted agent 110 can advantageously suggest a unique user ID. The client-side applet collects the registration data and transmits the registration data, for example, via an XML document, to the trust agent 110 and, in particular, to the transaction agent 205. According to a mode, the transmission is encrypted with the authentication agent's public key 215.

According to one modality, the user performs a single registration during step 905 of the 900 registration process. For example, the user registers as a particular person, such as User Joe. When User Joe wishes to register as User Joe, the CEO of Mega Corp., then, according to this modality, User Joe registers a second time, receives a second unique user ID and the trusted agent 110 does not associate the two identities. In accordance with another embodiment of the invention, the registration process 900 provides multiple wetting identities for a single user ID. Thus, in the example above, the trusted agent 110 can advantageously associate two User Joe identities. As will be understood by a technician versed from the exhibition here, a user may have many identities, for example, User Joe the householder, User Joe the member of Charitable Foundations, and the like. Although the user can have multiple identities, according to this modality, the trust agent 110 preferably stores only one set of registration data. Furthermore, users can advantageously add, edit / update or delete identities as needed.

Although the registration process 900 is shown with reference to your preferred modality, the invention is not intended to be limited in this way. Instead, a skilled technician will recognize from the exhibition here a wide range of alternatives for collecting registration data and, in particular, registration authentication data. For example, the applet can be a applet based on a common object model (COM) or similar.

On the other hand, the authentication process may include a graduated record. For example, at a lower registration level, the user can register via communication link 125 without producing documentation regarding his identity. According to an increased level of registration, the user registers using a trusted third party, such as a digital notary. For example, the user can appear in person to the trusted third party, and the trusted third party can advantageously include, for example, their digital signature in the registration submission. The trusted third party may include a real notary, a government agency, such as the Post Office or the Department of Motor Vehicles, a human resources person at a large company registering an employee or similar. A skilled technician will understand from the exhibit here that a wide number of varying levels of registration can occur during the 900 registration process.

After receiving registration authentication data, in step 915, transaction agent 205, using conventional SSL PLENA technology forwards registration authentication data to authentication agent 215. In step 920, authentication agent 215 decrypts the registration authentication data using the authentication agent's private key 215. In addition, the authentication agent 215 employs the data division module to mathematically operate on the registration authentication data, in order to divide the data into at least two independently indecipherable random numbers. As mentioned earlier, at least two numbers can comprise a statistically random number and a binary XOR number. In step 925, authentication agent 215 forwards each portion of the randomized numbers to one of the data storage facilities D1 through D4. As mentioned earlier, the authentication agent 215 can advantageously randomize which portions are transferred to which deposits.

Often, during the 900 registration process, the user will also want to have a digital certificate issued, so that he or she can receive encrypted documents from others outside the cryptographic system 100. As mentioned earlier, certificate authority 115 generally issues digital certificates according to one or more of several conventional standards. Generally, the digital certificate includes a public key of the user or system, which is known to everyone.

Regardless of whether the user requests a digital certificate at the registry or at another time, the request is transferred through the trust agent 110 to the authentication agent 215. According to one modality, the request includes an XML document that has, for example, the user's first name. According to step 935, authentication agent 215 transfers the request to cryptographic agent 220, instructing cryptographic agent 220 to generate a cryptographic key or key pair.

Upon request, in step 935, cryptographic agent 220 generates at least one cryptographic key. According to one modality, the cryptographic manipulation module 625 generates a key pair, where one key is used as the private key and one is used as the public key. Cryptographic agent 220 stores the private key and, according to one embodiment, a copy of the public key. In step 945, cryptographic agent 220 transmits a request for a digital certificate to transaction agent 205. According to one embodiment, the request advantageously includes a standardized request, such as PKCS10, embedded, for example, in an XML document . The request for a digital certificate can advantageously correspond to one or more certificate authorities and one or more standard formats that the certificate authorities require.

In step 950, transaction agent 205 forwards this request to certificate authority 115, which in step 955 returns a digital certificate. The digital return certificate can advantageously be in a standardized format, such as PKCS7, or in a format proprietary to one or more of the certificate authorities 115. In step 960, the digital certificate is received by the transaction agent 205, and a copy is forwarded to the user and a copy is stored with the trust agent 110. The trust agent 110 stores a copy of the certificate, so that the trusted agent 110 does not need to trust the availability of certificate authority 115. For example, when the user wants to send a digital certificate, or a third party requests the user's digital certificate, the request for the digital certificate is typically sent to certificate authority 115. However, if certificate authority 115 is conducting maintenance or has been the victim of a security breach or compromise, the digital certificate may not be available.

At any time after the issuance of the cryptographic keys, the cryptographic agent 220 can advantageously employ the data splitting process 800 described above, so that the cryptographic keys are divided into independently indecipherable random numbers. Similar to authentication data, in step 965, cryptographic agent 220 transfers the random numbers to data storage facilities D1 through D4.

A knowledgeable technician will recognize from the exhibit here that the user can request a digital certificate at any time after registration. Furthermore, communications between systems can advantageously include FULL SSL technologies or public key encryption. Furthermore, the registration process can issue multiple digital certificates from multiple certificate authorities, including one or more proprietary certificate authorities internal or external to the trusted agent 110.

As shown in steps 935 to 960, a modality of the invention includes requesting a certificate that is eventually stored in trust agent 110. Due to the fact that, according to one modality, the cryptographic manipulation module 625 issues the keys used by the trust agent 110, each certificate corresponds to a private key. Therefore, the trusted agent 110 can advantageously provide interoperability by monitoring the certificates owned by or associated with a user. For example, when cryptographic agent 220 receives a request for a cryptographic function, cryptographic manipulation module 625 can investigate the certificates owned by the requesting user, to determine whether the user has a private key that matches the attributes of the request. When such a certificate exists, the 625 cryptographic manipulation module can use the certificate or the public or private keys associated with it to perform the requested function. When such a certificate does not exist, the cryptographic manipulation module 625 can advantageously or transparently take several actions to try to remedy the lack of an appropriate key. For example, FIGURE 9B illustrates a flowchart of an interoperability process 970, which, according to aspects of one embodiment of the invention, shows the preceding steps to ensure that the cryptographic manipulation module 625 performs cryptographic functions using appropriate keys .

As shown in FIGURE 9B, the interoperability process 970 begins with step 972, where the cryptographic manipulation module 925 determines the type of certificate desired. According to an embodiment of the invention, the type of certificate can advantageously be specified in the request by cryptographic functions, or other data provided by the requester. According to another modality, the type of certificate can be evaluated by the data format of the requester. For example, the cryptographic manipulation module 925 can advantageously recognize that the request corresponds to a particular type.

According to another embodiment, the type of certificate may include one or more algorithm patterns, for example, RSA, ELGAMAL or similar. In addition, the type of certificate may include one or more types of key, such as symmetric keys, public keys, strong encryption keys such as 256-bit keys, less secure keys, or the like. Furthermore, the type of certificate may include updates or replacements to one or more of the preceding algorithm patterns or keys, one or more messages or data formats, one or more encapsulation or data encoding schemes, such as Base 32 or Base 64. The type of certificate may also include compatibility with one or more third-party cryptographic applications or interfaces, one or more communication protocols, or one or more certificate standards or protocols. A skilled technician will recognize from the exhibit here that other differences may exist in types of certificates and translations to and from those different can be implemented as shown here.

Once the cryptographic manipulation module 625 determines the type of certificate, the 970 interoperability process proceeds to step 974, and determines whether the user has a certificate matching the type determined in step 974. When the user has a matching certificate, for example, the trust agent 110 has access to the matching certificate, for example, through previous storage of it, the cryptographic manipulation module 825 knows that a matching private key is also stored in the agent of confidence 110.

For example, the matching private key can be stored in deposit 210 or in deposit system 700. Advantageously, cryptographic manipulation module 625 may require that the matching private key be assembled, for example, from deposit 210 and then in step 976, use the matching private key to perform cryptographic actions or functions. For example, as mentioned earlier, cryptographic manipulation module 625 can advantageously perform hashing, proof comparisons, data encryption or decryption, verification or creation of digital signature or the like.

When the user does not have a matching certificate, the 970 interoperability process proceeds to step 978, where the 625 cryptographic manipulation module determines whether the user has a cross certification certificate. According to one embodiment, cross-certification between certificate authorities occurs when a first certificate authority determines trusted certificates from a second certificate authority. In other words, the first certificate authority determines that certificates from the second certificate authority conform to certain quality standards and, therefore, can be certified as equivalent to the certificates of the first certificate authority. Cross-certification becomes more complex when curvatures issue, for example, certificates having confidence levels. For example, the first certificate authority can provide three levels of trust for a particular certificate, usually based on the degree of reliability in the registration process, while the second certificate authority can provide seven levels of trust. Cross-certification can advantageously track which levels and which certificates of the second can automatically be replaced by which levels and which certificates of the first. When previous cross-certification is done officially and publicly between two certification authorities, mapping certificates and levels to each other is often referred to as chaining.

According to another embodiment of the invention, the cryptographic manipulation module 625 can advantageously develop cross-certifications outside those agreed by the certificate authorities. For example, the 625 cryptographic manipulation module can access a first certificate authority (CPS) certificate practice statement, or another published policy statement and, for example, using the authentication tokens required by levels of trust in In particular, combine the certificates of the first certificate authority with those of another certificate authority.

When, in step 978, the cryptographic manipulation module 625 determines that the user has a cross certification certificate, the interoperability process 970 proceeds to step 976, and performs the cryptographic action or function using the public cross certification key, the private key or both. Alternatively, when cryptographic manipulation module 625 determines that the user does not have a cross certification certificate, the interoperability process 970 proceeds to step 980, where cryptographic manipulation module 625 selects a certificate authority that issues the type of certificate requested, or a cross certification certificate for it. In step 982, the cryptographic manipulation module 625 determines whether the user registration authentication data, discussed above, fits the authentication requirements of that chosen certificate authority. For example, if the user has registered on a network, for example, by answering demographic and other questions, the authentication data provided can establish a lower level of trust than a user providing biometric data and appearing before a third party, such as, for example, a notary. According to one embodiment, the foregoing authentication requirements can advantageously be provided at the chosen authentication authority's CPS.

When the user has provided the trusted agent 110 with the registration authentication data to suit the requirements of the chosen certificate authority, the 970 interoperability process proceeds to step 984, where the 825 cryptographic manipulation module acquires the certificate authority's certificate. chosen certificate. According to one modality, the cryptographic manipulation module 625 acquires the certificate by following steps 945 to 960 of the 900 registration process. For example, cryptographic manipulation module 625 can advantageously employ one or more public keys from one or more of the key pairs already available to cryptographic agent 220, to request the certificate from the certificate authority. According to another embodiment, the cryptographic manipulation module 625 can advantageously generate one or more new key pairs, and use the corresponding public keys to request the certificate authority's certificate.

According to another modality, the trusted agent

110 advantageously it may include one or more certificate issuing modules capable of issuing one or more types of certificate. According to this modality, the certificate issuing module can provide the previous certificate. When the cryptographic manipulation module 625 acquires the certificate, the 970 interoperability process proceeds to step 976, and performs the cryptographic action or function using the public key, the private key, or both corresponding to the purchased certificate.

When the user, in step 982, did not provide the trust agent 110 with the registration authentication data conforming to the requirements of the chosen certificate authority, the cryptographic manipulation module 625 determines, in step 986, if there are other certificate authorities that have different authentication requirements. For example, the cryptographic manipulation module 625 can search for certificate authorities having different authentication requirements. For example, the 625 cryptographic manipulation module can search for certificate authorities having lesser authentication requirements, but still issue the chosen certificates or their cross-certificates.

When the preceding certificate authority having the lowest requirements exists, the 970 interoperability process proceeds to step 980 and chooses that certificate authority. Alternatively, when there is no certificate authority, in step 988, trusted agent 110 may request additional authentication tokens from the user. For example, the trusted agent 110 can request new registration authentication data comprising, for example, biometric data. Also, the trusted agent 110 can request the user to appear before a trusted third party and provide appropriate authentication credentials, such as, for example, appearing before a notary with a driver's license, a social security card, a card bank certificate, birth certificate, reservist certificate or similar. When the trust agent 110 receives updated authentication data, the 970 interoperability process proceeds to step 984 and acquires the previous chosen certificate.

Through the preceding 970 interoperability process, the cryptographic manipulation module 625 advantageously provides seamless and transparent translations and conversions between different cryptographic systems. A skilled technician will recognize from the exhibition here a wide range of advantages and implementations of the preceding interoperable system. For example, step 986 preceding the interoperability process 970 may advantageously include aspects of trust arbitration, discussed in more detail below, where the certificate authority may, under special circumstances, accept lower levels of cross-certification. In addition, the 970 interoperability process may include ensuring interoperability between and using standard certificate revocations, such as using certificate revocation lists (CRL), online certificate status protocols (OCSP), or similar.

FIGURE 10 illustrates a data flow from an authentication process 1000 according to aspects of an embodiment of the invention. According to one embodiment, the 1000 authentication process includes collecting a user's current authentication data and comparing it with the user's registration authentication data. For example, the authentication process 1000 starts at step 1005, where a user wants to carry out a transaction, for example, with a salesperson. Such transactions may include, for example, selecting a call option, requesting access to a restricted area or device of a vendor system 120, or similar. In step 1010, a salesperson provides the user with a transaction ID and an authentication request. The transaction ID can advantageously include a 192-bit quantity having a 32-bit time stamp concatenated with a random 128-bit quantity or a nonce, concatenated with a 32-bit vendor-specific constant. A transaction ID like this uniquely identifies the transaction so that imitation transactions can be refused by the trusted agent 110.

The authentication request advantageously can include what level of authentication is required for a particular transaction. For example, the seller may specify a particular level of trust that is required for the transaction in question. If authentication cannot be done for this level of trust, as discussed below, the transaction will not take place without additional authentication by the user to raise the level of trust or a change in the terms of authentication between the vendor and the server. These issues are discussed more fully below.

According to one embodiment, the transaction ID and authentication request can advantageously be generated by a vendor-side applet or another software program. In addition, the transmission of the transaction ID and authentication data may include one or more encrypted XML documents using conventional SSL technology, such as, for example,1Z- SSL or, in other words, an SSL authenticated on the seller side.

After user system 105 receives the transaction ID and authentication request, user system 105 collects the current authentication data, potentially including current biometric information, from the user. User system 105, in step 1015, encrypts at least the current authentication data B and the transaction ID, with the authentication agent public key 215, and transfers that data to the trust agent 110. The transmission preferably comprises XML documents encrypted with at least one 1Convencional Conventional SSL. In step 1020, transaction agent 205 receives the transmission, preferably recognizes the data format or request in the URL or URI, and forwards the transmission to the authentication agent 215.

During steps 1015 and 1020, the vendor system 120, in step 1025, forwards the transaction ID and authentication request to the trusted agent 110, using the preferred SSL PLENA technology. This communication can also include a seller ID, although the seller identification can also be communicated via a non-random portion of the transaction ID. In steps 1030 and 1035, transaction agent 205 receives the communication, creates a record in the audit trail, and generates a container for user record authentication data to be assembled from data storage facilities D1 to D4. In step 1040, deposit system 700 transfers the portions of the registration authentication data corresponding to the user to the authentication agent 215. In step 1045, authentication agent 215 decrypts the transmission using its private key and compares the registration authentication data with the current authentication data provided by the user.

The comparison of step 1045 can advantageously apply heuristic context sensitive authentication, as mentioned in the preceding, and discussed in more detail below. For example, if the biometric information received does not match perfectly, a lower confidence combination results. In particular modalities, the level of authentication trust is balanced against the nature of the transaction and the wishes of both the user and the seller. Again, this is discussed in more detail below.

In step 1050, the authentication agent 215 fulfills the authentication request with the result of the comparison in step 1045. According to an embodiment of the invention, the authentication request is filled with a YES / NO or TRUE / FALSE result of the authentication process. 1000 authentication. In step 1055, the completed authentication request is returned to the seller for action, for example, allowing the user to complete the transaction that initiated the authentication request. According to one modality, a confirmation message is sent to the user.

Based on the foregoing, the authentication process 1000 advantageously keeps sensitive data safe and produces results configured to maintain the integrity of sensitive data. For example, sensitive data is mounted only within the authentication agent 215. For example, registration authentication data is unencryptable until it is mounted on authentication agent 215 by the data mount module, and the current authentication data is unencryptable until unrolled by conventional SSL technology and the authentication agent's private key. 215. Furthermore, the authentication result transmitted to the seller does not include sensitive data, and the user may not even know whether he or she has produced valid authentication data.

Although the authentication process 1000 is shown with reference to its preferred and alternative modalities, the invention is not intended to be limited in this way. Instead, a skilled technician will recognize from the exhibit here a wide range of alternatives to the 1000 authentication process. For example, the vendor can advantageously be replaced by almost any requesting application, even those residing on the user system 105. For example, a client application, such as Microsoft Word, can use an application program interface (API) or a cryptographic API (CAPI) to request authentication, before unlocking a document. Alternatively, a mail server, a network, a cell phone, a personal or mobile computing device, a workstation or the like, all can make authentication requests that can be fulfilled by the 1000 authentication process. In fact, after the provision of the foregoing 1000 trusted authentication process, the requesting application or device can provide access to or use a wide number of electronic or computer devices or systems.

Furthermore, the authentication process 1000 can employ a wide number of alternative procedures in the event of an authentication failure. For example, authentication failure can maintain the same transaction ID and require the user to re-enter their current authentication data. As mentioned earlier, the use of the same transaction ID allows the authentication agent comparator 215 to monitor and limit the number of authentication attempts for a particular transaction, thereby creating a more secure cryptographic system 100.

In addition, the 1000 authentication process can advantageously be employed for the development of unique elegant signing solutions, such as the unlocking of a sensitive data safe. For example, successful or positive authentication can provide the authenticated user with the ability to automatically access any number of passwords for an almost unlimited number of systems and applications. For example, a user's authentication can provide the user with access to a password, login, financial credentials, or the like, associated with multiple online vendors, a local area network, various personal computing devices, Internet service providers, auction providers, investment brokers, or the like. By using a sensitive data safe, users can choose truly large and random passwords, because they no longer need to remember them through membership. Instead, the 1000 authentication process provides access to it. For example, a user can choose a random alphanumeric string that is more than twenty digits in length, rather than something associated with a memorable date, a name, etc.

According to one embodiment, a sensitive data safe associated with a given user can advantageously be stored in the data storage facilities of depot 210 or divided and stored in deposit system 700. According to this modality, after a positive authentication of user, the trusted agent 110 serves the requested sensitive data, such as, for example, the appropriate password for the requesting application. According to another method, the trust agent 110 may include a separate system for storing the sensitive data vault. For example, trustee 110 may include an independent software agent implementing data vault functionality and figuratively residing behind the trustee 110's preceding front-end security system. According to this modality, the software agent serves the requested sensitive data after the software agent receives a signal indicating positive user authentication from the trusted agent 110.

In yet another modality, the data safe can be implemented by a third party system. Similar to the software agent mode, the third party system can advantageously serve the requested sensitive data after the third party system receives a signal indicating positive user authentication from the trusted agent 110. According to yet another modality , the data safe can be implemented in user system 105. A user-side software agent can advantageously serve the preceding data upon receipt of a signal indicating positive user authentication from the trusted agent 110.

Although the preceding vaults are shown with reference to alternative modalities, a skilled technician will recognize from the exhibition here a large number of additional implementations of it. For example, the data vault in particular may include aspects of some or all of the foregoing modalities. In addition, any of the preceding data vaults can employ one or more authentication requests at varying times. For example, any of the data vaults may require authentication for each or more transactions, periodically, each or more sessions, each access to one or more web pages or websites, at one or more other specified or similar intervals.

FIGURE 11 illustrates a data flow from a subscription process 1100 according to aspects of an embodiment of the invention. As shown in FIGURE 11, the signing process 1100 includes steps similar to those of the authentication process 1000 described earlier with reference to FIGURE 10. According to an embodiment of the invention, the 1100 signature process first authenticates the user and then performs one or more of several digital signature functions, as will be discussed in more detail below. According to another embodiment, the 1100 signature process can advantageously store data related to this, such as proofs of messages or documents or the like. This data can advantageously be used in an audit or in any other event, such as, for example, when a participating party tries to repudiate a transaction.

As shown in FIGURE 11, during the authentication steps, the user and the seller can advantageously agree to a message, such as, for example, a contract. During the subscription, the 1100 subscription process advantageously ensures that the contract signed by the user is identical to the contract supplied by the seller. Therefore, according to one modality, during an authentication, the seller and the user include proof of their respective copies of the message or the contract, in the data transmitted to the authentication agent 215. By using only proof of a message or a contract, the trusted agent 110 can advantageously store a significantly reduced amount of data, providing a more efficient and more cost-effective cryptographic system. In addition, the stored evidence can be advantageously compared with proof of a document in question, to determine whether the document in question matches one signed by either party. The ability to determine whether the document is identical to one relating to a transaction provides additional evidence that can be used against a claim for repudiation by a party to the transaction.

In step 1103, authentication agent 215 assembles the registration authentication data and compares it with the current authentication data provided by the user. When the authentication agent comparator 215 indicates that the registration authentication data matches the current authentication data, the authentication agent comparator 215 also compares the proof of the message provided by the seller with the proof of the message provided by the user. Thus, the authentication agent 215 advantageously ensures that the message agreed by the user is identical to that agreed by the seller.

In step 1105, authentication agent 215 transmits a digital signature request to cryptographic agent 220. According to an embodiment of the invention, the request includes proof of the message or contract. However, a skilled technician will recognize from the exhibit here that cryptographic agent 220 can encrypt virtually any type of data, including, but not limited to, video, audio, biometrics, images or text to form the desired digital signature. Returning to step 1105, the digital signature request preferably comprises an XML document communicated using conventional SSL technologies.

In step 1110, authentication agent 215 transmits a request to each of the data storage facilities D1 to D4, so that each of the data storage facilities D1 to D4 transmits its respective portion of the corresponding cryptographic key or keys to a party by signing. According to another embodiment, cryptographic agent 220 employs some or all of the steps of the interoperability process 970 discussed earlier, so that cryptographic agent 220 first determines the appropriate key or keys for requesting from deposit 210 or the system deposit amount 700 for the signing party, and take actions to provide appropriate matching keys. According to yet another embodiment, authentication agent 215 or cryptographic agent 220 may advantageously request one or more of the keys associated with the part by signing and stored in deposit 210 or deposit system 700.

According to one modality, the signing party includes one or both the user and the seller. In this case, the authentication agent 215 advantageously requests the corresponding cryptographic keys from the user and / or the seller. According to another modality, the signing party includes the trusted agent 110. In this embodiment, the trusted agent 110 is certifying that the authentication process 1000 has properly authenticated the user, the seller or both. Therefore, the authentication agent 215 requests the cryptographic key of the trust agent 110, such as, for example, the key belonging to the cryptographic agent 220, to perform the digital signature. According to another embodiment, the trusted agent 110 performs a digital notary function. In this modality, the signing party includes the user, the seller or both, together with the trusted agent 110. Thus, the trusted agent 110 provides the digital signature of the user and / or the seller and then indicates with its own digital signature that the user and / or the seller have been properly authenticated. In this modality, the authentication agent 215 can advantageously request the assembly of the cryptographic keys cor15 responding to the user, the seller or both. According to another embodiment, the authentication agent 215 may advantageously request the assembly of the cryptographic keys corresponding to the trust agent 110.

According to another modality, the trusted agent

110 performs proxy-type functions. For example, the trust agent

110 you can digitally sign the message on behalf of a third party. In this case, the authentication agent 215 requests the cryptographic keys associated with the third party. According to this embodiment, the signing process 1100 may advantageously include authentication of the third party, before the proxy-type functions are allowed. In addition, the authentication process 1000 may include a check for third party restrictions, such as, for example, business logic or the like dictating when and under what circumstances a third party signature can be used.

Based on the precedent, in step 1110, the authentication agent requested the cryptographic keys for data storage facilities D1 through D4 corresponding to the signing party. In step 1115, data storage facilities D1 to D4 transmit their respective portions of the cryptographic key corresponding to the part signing for cryptographic agent 220. According to one embodiment, the preceding transmissions include SSL technologies. According to an out. According to one mode, previous transmissions include SSL technologies. According to another embodiment, the preceding transmissions can advantageously be over encrypted with the public key of the cryptographic agent 220.

In step 1120, cryptographic agent 220 assembles the party's previous cryptographic keys by signing and encrypts the message with them, thereby forming the digital signature (s). In step 1125 of the signing process 1100, the cryptographic agent 220 transmits the digital signature (s) to the authentication agent 215. In step 1130, authentication agent 215 transmits the completed authentication request along with a copy of the verified message and the digital signature (s) to transaction agent 205. In step 1135, transaction agent 205 transmits a receipt comprising the transaction ID, an indication of whether the authentication was successful, and the digital signature (s) for the seller. According to one embodiment, the preceding transmission advantageously may include the digital signature of the trusted agent 110. For example, the trusted agent 110 can encrypt the proof of receipt with his private key, thereby forming a digital signature to be attached. transmission to the seller.

According to one embodiment, transaction agent 205 also transmits a confirmation message to the user. Although the 1100 signature process is shown with reference to your preferred and alternative modalities, the invention is not intended to be limited in this way. Instead, a skilled technician will recognize from the exhibition here a wide range of alternatives to the 1100 signature process. For example, the salesperson can be replaced by a user application, such as an email application. For example, the user may wish to digitally sign a particular email with his digital signature. In such a modality, the transmission through the 1100 subscription process can advantageously include only one copy of a proof of the message. Furthermore, a knowledgeable technician will recognize from the exhibition here that a large number of client applications can order digital signatures. For example, client applications may include word processors, spreadsheets, emails, voicemail, access to restricted areas of the system or similar.

In addition, a skilled technician will recognize from the exhibit here that steps 1105 to 1120 of the signing process 1100 can advantageously employ some or all of the steps of the 970 interoperability process in FIGURE 9B, thereby providing interoperability between different cryptographic systems that they may need, for example, to process the digital signature under different types of signature.

FIGURE 12 illustrates a data stream from an encryption / decryption process 1200 according to aspects of an embodiment of the invention. As shown in FIGURE 12, the decryption process 1200 begins by authenticating the user using the authentication process 1000. According to one embodiment, the authentication process 1000 includes a synchronous session key in the authentication request. For example, in conventional PKI technologies, skilled technicians understand that encryption or decryption of data using public and private keys is mathematically intense and may require significant system resources. However, in symmetric-key cryptographic systems, or systems where the sender and recipient of a message share a single common key that is used for encrypting and decrypting a message, mathematical operations are significantly simpler and faster. Thus, in conventional PKI technologies, the sender of a message will generate the synchronous session key, and encrypt the message using the simplest and fastest symmetric key system. The sender will then encrypt the session key with the recipient's public key. The encrypted session key will be attached to the encrypted message synchronously and both data will be sent to the recipient. The recipient uses his private key to decrypt the session key and then uses the session key to decrypt the message. Based on the precedent, the simplest and fastest symmetric key system is used for most encryption / decryption processing. Thus, in the decryption process 1200, decryption advantageously assumes that a synchronous key has been encrypted with the user's public key. Thus, as mentioned earlier, the encrypted session key is included in the authentication request.

Returning to the decryption process 1200, after the user has been authenticated in step 1205, authentication agent 215 forwards the encrypted session key to cryptographic agent 220. In step 1210, authentication agent 215 forwards a request to each of the data storage facilities D1 to D4, requesting the user's cryptographic key data. In step 1215, each data storage facility, D1 to D4, transmits its respective portion of the cryptographic key to cryptographic agent 220. According to one embodiment, the preceding transmission is encrypted with the public key of cryptographic agent 220.

At step 1220 of decryption process 1200, cryptographic agent 220 assembles the cryptographic key and decrypts the session key with it. In step 1225, the cryptographic agent forwards the session key to authentication agent 215. In step 1227, authentication agent 215 fulfills the authentication request including the decrypted session key, and transmits the completed authentication request to the agent of transaction 205. In step 1230, transaction agent 205 forwards the authentication request along with the session key to the requesting application or the vendor. Then, according to one modality, the requesting application or the seller uses the session key to decrypt the encrypted message.

Although the decryption process 1200 is shown with reference to its preferred and alternative modalities, a skilled technician will recognize from the exhibition here a wide number of alternatives to the decryption process 1200. For example, the decryption process 1200 may precede encryption synchronous key and rely on full public key technology. In such a modality, the requesting application can transmit the entire message to the cryptographic agent 220, or it can employ some kind of compression or reversible proof, in order to transmit the message to the cryptographic agent 220. A skilled technician will recognize from the exposure here that previous communications can advantageously include XML documents involved in SSL technology.

The encryption / decryption process 1200 also provides the encryption of documents or other data. Thus, in step 1235, a requesting application or vendor can advantageously transmit a request for the user's public key to transaction agent 205 of trust agent 110. The requesting application or the seller makes its request because the requesting application or the seller uses the user's public key, for example, for the encryption of the session key that will be used for the encryption of the document or message. As mentioned in registration process 900, transaction agent 205 stores a copy of the user's digital certificate, for example, in mass storage 225. Thus, in step 1240 of the encryption process 1200, transaction agent 205 requests the user's digital certificate from mass storage 225. In step 1245, mass storage 225 transmits the corresponding digital certificate to the user to the transaction 205. In step 1250, transaction agent 205 transmits the digital certificate to the requesting application or the seller. According to one embodiment, the encryption portion of the encryption process 1200 does not include authentication of a user. This is because the requesting vendor only needs the user's public key, and is not requesting any sensitive data.

A knowledgeable technician will recognize from the exhibit here that if a particular user does not have a digital certificate, trust agent 110 can employ part or all of the 900 registration process in order to generate a digital certificate for that particular user . Then, the trusted agent 110 can initiate the encryption / decryption process 1200 and thereby provide the appropriate digital certificate. In addition, a skilled technician will recognize from the exhibit here that steps 1220 and 1235 to 1250 of the encryption / decryption process 1200 can advantageously employ part or all of the steps in the interoperability process of FIGURE 9B, thereby providing interoperability between different cryptographic systems that may, for example, need to process encryption.

FIGURE 13 illustrates a simplified block diagram of a trust agent system 1300 according to aspects of yet another embodiment of the invention. As shown in FIGURE 13, the trust agent system 1300 comprises a plurality of distinct trust agents 1305, 1310, 1315 and 1320, respectively. To facilitate a more complete understanding of the invention, FIGURE 13 illustrates each trust agent 1305, 1310, 1315 and 1320 as having a transaction agent, a deposit and an authentication agent. However, a skilled technician will recognize that each transport angle can advantageously comprise some, a combination or all of the elements and the communication channels shown with reference to FIGURES 1 to 8. For example, a modality advantageously can include trusted agents having one or more transaction agents, deposits and cryptographic servers or any combination thereof.

According to an embodiment of the invention, each of the trusted agents 1305, 1310, 1315 and 1320 is geographically separated, so that, for example, the trusted agent 1305 can reside in a first location, the trusted agent 1310 can reside in a second location, the trusted agent 1315 can reside in a third location, and the trusted agent 1320 can reside in a fourth location. The preceding geographical separation advantageously decreases the system's response time while increasing the security of the 1300 trusted agent system in general.

For example, when a user enters the cryptographic system 100, the user may be closer to the first location and may wish to be authenticated. As described with reference to FIGURE 10, to be authenticated, the user provides current authentication data, such as a biometric or similar, and the current authentication data is compared with the user's registration authentication data. Therefore, according to an example, the user advantageously provides current authentication data to the nearest geographically trusted agent 1305. Transaction agent 1321 from trusted agent 1305 then forwards the current authentication data to the authentication agent. 1322 also resident in the first location. According to another embodiment, transaction agent 1321 forwards the current authentication data to one or more of the authentication agents of trusted agents 1310, 1315 or 1320.

Transaction agent 1321 also requests the assembly of registration authentication data from deposits, for example, from each of the trusted agents 1305 to 1320. According to this modality, each deposit provides its portion of the authentication data of record for trust agent 1322 of trust agent 1305. The 1322 authentication agent then employs the encrypted data portions, for example, from the first two deposits, to respond, and reassembles the registration authentication data in decrypted form. Authentication agent 1322 compares registration authentication data with current authentication data and returns an authentication result to transaction agent 1321 from trust agent 1305.

Based on the above, the trust agent system 1300 employs the closest to a plurality of geographically separated trust agents 1305 to 1320 to carry out the authentication process. According to an embodiment of the invention, the routing of information to the nearest transaction agent can advantageously be performed in customer-side applets running on one or more of the user system 105, the seller system 120 or the certificate 115. According to an alternative modality, a more sophisticated decision process can be used for the selection of trusted agents 1305 to 1320. For example, the decision can be based on the availability, operability, speed of connections, load, performance, geographical proximity or a combination of them, for a given trusted agent.

In this way, the trusted agent system 1300 decreases its response time while maintaining the security advantages associated with geographically remote data storage facilities, such as those discussed with reference to FIGURE 7, where each data storage facility stores portions randomized sensitive data. For example, a security compromise, for example, on deposit 1325 of trust agent 1315 does not necessarily compromise sensitive data from the trust agent system 1300. This is because deposit 1325 contains only random, non-decipherable data that, without further ado, they are entirely useless.

According to another embodiment, the trusted agent system 1300 may advantageously include multiple cryptographic agents arranged similarly to authentication agents. Cryptographic agents can advantageously perform cryptographic functions such as those discussed with reference to FIGURES 1 to 8. According to yet another embodiment, the trust agent system 1300 can advantageously replace multiple authentication agents with multiple cryptographic agents, thereby performing cryptographic functions such as those shown with reference to FIGURES 1 to 8. According to yet another embodiment of the invention, the trust agent system 1300 can replace each authentication agent with an agent having part or all of the functionality of the authentication agents, cryptographic agents or both, as shown above.

Although the trusted agent system 1300 is shown with reference to its preferred and alternative modalities, a skilled technician will recognize that the trusted agent system 1300 may comprise portions of trusted agents 1305 through 1320. For example, the trusted agent system trust 1300 can include one or more transaction agents, one or more deposits, one or more authentication agents or one or more cryptographic agents or combinations thereof.

FIGURE 14 illustrates a simplified block diagram of a trust agent system 1400 according to aspects of yet another embodiment of the invention. As shown in FIGURE 14, the trust agent system 1400 includes multiple trust agents 1405, 1410, 1415 and 1420. According to one embodiment, each trust agent 1405, 1410, 1415 and 1420 comprises some or all of the elements of the trusted agent 110 discussed with reference to FIGURES 1 to 8. According to this modality, when the client-side applets of user system 105, vendor system 120, or certificate authority 115 communicate with the trusted agent system 1400, those communications are sent to the IP address of each of the trust agents 1405 to 1420. In addition, each transaction agent of each of the trust agents 1405, 1410, 1415 and 1420 behaves similarly to the transaction agent 1321 of the trust agent 1305 discussed with reference to FIGURE 13. For example, during an authentication process, each transaction agent from each of the trusted agents 1405, 1410, 1415 and 1420 transmits the current authentication data to their respective authentication agents and transmits a request for mounting the stored randomized data in each of the deposits of each of the trusted agents 1405 to 1420. FIGURE 14 does not illustrate all of these communications, since this illustration would become too complex. Continuing with the authentication process, each of the deposits then communicates its portion of the randomized data to each of the authentication agents of each of the trusted agents 1405 to 1420. Each of the authentication agents of each of the trusted agents employs your comparator to determine whether the current authentication data matches the registration authentication data provided by the depositors of each of the trusted agents 1405 to 1420. According to this modality, the result of the comparison of each of the authentication agents is then transmitted to a redundancy module of the other three trusted agents. For example, the result of the trust agent authentication agent 1405 is transmitted to the trust agents redundancy modules 1410, 1415 and 1420. Thus, the redundancy module of the trust agent 1405, likewise, receives the result from the trust agents of the trust agents 1410, 1415 and 1420.

FIGURE 15 illustrates a block diagram of the redundancy module of FIGURE 14. The redundancy module comprises a comparator configured to receive the authentication result from the three authentication agents and transmit that result to the transaction agent of the fourth trust agent. The comparator compares the authentication result of the three authentication agents and, if two of the results are in agreement, the comparator concludes that the authentication result must match that of two authentication agents in agreement. This result is then transmitted back to the transaction agent corresponding to the trust agent not associated with the three authentication agents.

Based on the precedent, the redundancy module determines an authentication result from the data received from authentication agents that are preferably geographically remote from the trust agent of that redundancy module. By providing this redundancy functionality, the trust agent system 1400 ensures that an authentication agent compromise from one of the trust agents 1405 through 1420 is insufficient to compromise the authentication result of that particular trust agent's redundancy module. A skilled technician will recognize that the redundancy module functionality of the trust agent system 1400 can also be applied to the cryptographic agent of each of the trust agents 1405 through 1420. However, this cryptographic agent communication was not shown in FIGURE 14 for avoid complexity. Furthermore, a skilled technician will recognize a wide number of alternative authentication result conflict resolution algorithms for the comparator of FIGURE 15 that are suitable for use in the present invention.

According to yet another embodiment of the invention, the trust agent system 1400 can advantageously employ the redundancy module during cryptographic comparison steps. For example, some or all of the foregoing redundancy module display with reference to FIGURES 14 and 15 can advantageously be implemented during a document proof comparison provided by one or more parties during a particular transaction.

Although the foregoing invention has been described in terms of certain preferred and alternative modalities, other modalities will be apparent to those of ordinary skill in the art from the exposition here. For example, trust agent 110 can issue short-term certificates, where the private cryptographic key is released to the user for a predetermined period of time. For example, current certificate standards include a validity field that can be set to expire after a predetermined amount of time. Thus, the trusted agent 110 can release a private key to a user, where the private key would be valid, for example, for 24 hours. According to such an embodiment, the trusted agent 110 can advantageously issue a new cryptographic key pair to be associated with a particular user and then release the private key from the new cryptographic key pair. Then, once the private cryptographic key is released, the trust agent 110 immediately expires any valid internal use of that private key, since it is no longer insurable by the trust agent 110.

In addition, a skilled technician will recognize that cryptographic system 100 or trusted agent 110 may include the ability to recognize any type of devices, such as, but not limited to, a laptop, a cell phone, a network, a biometric device or similar. According to one modality, this recognition may come from data supplied in the request for a particular service, such as a request for authentication leading to access or use, a request for cryptographic functionality, or similar. According to one embodiment, the preceding request may include a unique device identifier, such as, for example, a processor ID. Alternatively, the frame reaction can include data in a particular recognizable data format. For example, mobile and satellite phones often do not include the processing power for full heavy X509.v3 encryption certificates and therefore do not require them. According to this modality, the trusted agent 110 can recognize this type of data format presented and respond only in kind.

As discussed above, authentication is a process of providing that a user is who he says he is. Authentication generally requires a fact to be demonstrated to an authentication authority. The trusted agent 110 of the present invention represents the authority to which a user must authenticate. The user must demonstrate to the trusted agent 110 that he is who he says he is by: knowing something that only the user should know (knowledge-based authentication), having something that only the user should have (card-based authentication) or be something that only the user should be (biometric based authentication).

Examples of knowledge-based authentication include, without limitation, a password, a PIN number, or a combination of locks. Examples of card-based authentication include, but are not limited to, a home key, a physical credit card, a driver's license, or a private phone number. Examples of biometric-based authentication include, without limitation, a fingerprint, a handwriting analysis, a facial scan, a hand scan, an ear scan, an iris scan, a vascular pattern, DNA, an analysis of voice or retinal scan.

Each type of authentication has particular advantages and disadvantages, and each provides a different level of security. For example, it is often more difficult to create a fake fingerprint that matches someone than it is to listen to someone's password and repeat it. Each type of authentication also requires that a different type of data is known to the authentication authority in order to verify someone using that form of authentication.

As used here, authentication refers largely to the general process of verifying the identity of someone who claims to be who they are. An authentication technique will refer to a particular type of authentication based on a particular piece of knowledge, a physical record or a biometric reading. Authentication data refers to information that is sent to or otherwise demonstrated to an authentication authority in order to establish an identity. Registration data will refer to data which is initially submitted to an authentication authority, in order to establish a baseline for comparison with authentication data. An authentication instance will refer to the data associated with an authentication attempt by an authentication technique.

The internal protocols and communications involved in a user's authentication process are described with reference to FIGURE 10 above. The part of this process in which context-sensitive authentication takes place occurs in the comparison step shown as step 1045 in FIGURE 10. This step occurs in authentication agent 215 and involves assembling the registration data 410 retrieved from deposit 210 and comparing the authentication data provided by the user for him. A particular embodiment of this process is shown in FIGURE 16 and described below.

The current authentication data provided by the user and the registration data of the deposit 210 are received by the collar 215 in step 1600 of FIGURE 16. Both of these data sets can contain data which are related to separate authentication techniques. The authentication agent 215 separates the authentication data associated with each individual authentication instance in step 1605. This is necessary, so that authentication data is compared with the appropriate subset of registration data for the user (for example, fingerprint authentication data should be compared with fingerprint registration data, instead of password registration).

Typically, authenticating a user involves one or more authentication instances, depending on which authentication techniques are available to the user. These methods are limited by the registration data which was provided by the user during his registration process (if the wetting did not provide a retinal scan when registering, he will not be able to authenticate using a retinal scan), as well as by the means which may currently be available to the user (for example, if the user does not have a fingerprint reader in his current location, fingerprint authentication will not be practicable). In some cases, a single authentication instance may be sufficient to authenticate a user; however, in certain circumstances, a combination of multiple authentication instances can be used to more reliably authenticate a user for a particular transaction.

Each authentication instance consists of data related to a particular authentication technique (for example, fingerprint, password, smart card, etc.) and the circumstances which involve the capture and sending of data for that particular technique. For example, a particular instance of a password authentication attempt will generate not only the data related to the password itself, but also circumstantial data, known as metadata, related to that password attempt. This circumstantial data includes information such as: the time at which the particular authentication instance occurred, the network address from which the authentication information was sent, as well as any other information as is known to those skilled in the art, which can be determined on the source of the authentication data (the type of connection, the processor serial number, etc.).

In many cases, only a small amount of half of the circumstance is available. For example, if the user is located on a network which uses proxies or a network address translation or another technique which masks the address of the source computer, only the address of the proxy or router can be determined. Similarly, in many cases, information such as the processor serial number will not be available because of limitations in the hardware or operating system being used, a disabling of these features by the system operator, or other limitations in the connection between the user system and trust agent 110.

As shown in FIGURE 16, once the individual authentication instances represented in the authentication data are extracted and separated in step 1605, the authentication agent 215 assesses each instance for its reliability in indicating that the user is who he claims to be. The reliability for a single authentication instance will generally be determined based on several factors. These can be grouped as factors related to the reliability associated with the authentication technique, which are evaluated in step 1610, and factors related to the reliability of the authentication data in particular provided, which are evaluated in step 1815. The first group includes, without limitation, the inherent reliability of the authentication technique being used and the reliability of the registration data being used with that method. The second group includes, without limitation, the degree of combination between the registration data and the data provided with the authentication instance, and the metadata associated with that authentication instance. Each of these factors can vary independently of the others.

The inherent reliability of an authentication technique is based on how difficult it is for an imposter to provide the correct data for another person, as well as the general error rates for the authentication technique. For authentication methods based on passwords and knowledge, this reliability is often reasonably low, because there is nothing to stop someone from revealing their password to someone else and that second person to use that password. Even a more complex knowledge-based system can have only moderate reliability, since knowledge can be transferred from person to person reasonably easily. Token-based authentication, such as having your own smart card or using a particular terminal to perform authentication, in a similar way, is of low reliability used in itself, since there is no guarantee that the correct person will be possession of the appropriate plug.

However, biometric techniques are inherently more reliable because it is often difficult to provide someone else with the ability to use your fingerprints in a convenient way, even intentionally. Because subverting biometric authentication is more difficult, the inherent reliability of biometric methods is generally higher than that of authentication techniques purely based on knowledge or tokens. However, even biometric techniques can have some occasions when false acceptance or false rejection is generated. These occurrences can be reflected by the different reliability for different implementations of the same biometric technique. For example, a fingerprint matching system provided by one company can provide higher reliability than one provided by a different company, because one uses higher quality optics or better scanning resolution or some other enhancement which reduces the occurrence of false acceptances or false rejections.

Note that this reliability can be expressed in different ways. Reliability is desirably expressed in some metrics, which can be used by heuristics 530 and by authentication agent algorithms 215 to calculate the confidence level of each authentication. A preferred way of expressing these reliability is as a percentage or a fraction. For example, fingerprints could be assigned an inherent reliability of 97%, while the password could be assigned only an inherent reliability of 50%. Those skilled in the art will recognize that these particular values are merely examples and may vary between specific implementations.

The second factor on which reliability should be assessed is the reliability of the record. This is part of the graduated registration process mentioned above. This reliability factor reflects the reliability of the identification provided during the initial registration process. For example, if the individual initially registers in a manner in which he physically produces evidence of his identity to a notary or another public official, and the registration data is recorded at that time and endorsed by the notary, the data will be more reliable than that data which is provided by a network during a registration and is only attested by a digital signature or other information which is not truly tied to the individual.

Other registration techniques with varying levels of reliability include, without limitation: registration at a physical office of the trusted agent operator 110; registration at a user's place of employment; registration with a post office or passport agency; registration through an affiliated or trusted party for the trusted agent 110 operator; anonymous or pseudo-anonymous registration in which the registered identity is not yet identified with a particular real individual, as well as other means as are known in the art.

These factors reflect the trust between the trust agent 110 and the source of the identification provided during the registration process. For example, if registration is performed in association with an employer during the initial process of providing evidence of identity, this information can be considered extremely reliable for purposes with the company, but can be relied to a lesser extent by a government agency or by a competitor. Therefore, trust agents operated by each of these organizations can assign different levels of reliability to this record.

Similarly, additional data, which is submitted over a network, but which is authenticated by other trusted data during prior registration with the same trusted agent 110 can be considered as reliable as the original registration data was, although the latest data is submitted via an open network. In such circumstances, a subsequent notary approval will effectively increase the level of reliability associated with the original registration data. In this way, for example, an anonymous or pseudo-anonymous record can then be elevated to a full record by demonstrating to an employee registering the individual's identity matching the recorded data.

The reliability factors discussed above are generally values which can be determined in advance of any particular authentication instance. This is because they are based on registration and technique, rather than actual authentication. In one modality, the step of generating reliability based on these factors involves consulting previously determined values for this particular authentication technique and the user's registration data. In another aspect of an advantageous embodiment of the present invention, such reliability can be included in the registration data itself. In this way, these factors are automatically sent to the authentication agent 215 together with the registration data sent from deposit 210.

While these factors can generally be determined in advance for any particular authentication instance, they still have an effect on each authentication instance which uses that particular authentication technique for that user. Furthermore, although the values may change over time (for example, if a user registers more reliably), they are not dependent on the authentication data itself. In contrast, the reliability factors associated with data for a specific single instance may vary from time to time. These factors, as discussed below, must be evaluated for each new authentication, in order to generate reliability scores in step 1815.

The reliability of the authentication data reflects the combination of the data provided by the user in a particular authentication instance and the data provided during the authentication registration. This is the fundamental question of whether the authentication data matches the registration data for the individual the user is claiming to be. Normally, when the data does not match, the user is considered as not being successfully authenticated, and authentication fails. The way in which this is evaluated can change, depending on the authentication technique used. The comparison of these data is performed by the comparator function 515 of the authentication agent 215, as shown in FIGURE 5.

For example, combinations of passwords are usually evaluated in a binary way. In other words, a password is a perfect match or a failed match. It is usually not desirable to accept even a partial combination of a password which is close to the correct password, if it is not exactly correct. Therefore, when evaluating password authentication, the authentication reliability returned by comparator 515 is typically 100% (correct) or 0% (wrong), with no possibility of intermediate values.

Rules similar to those for passwords are generally applied to card-based authentication methods, such as smart cards. This is because having a smart card which has a similar identifier or which is similar to the correct one is just as wrong as having any other incorrect card. Therefore, tokens also tend to be binary authenticators: a user has the correct token or does not.

However, certain types of authentication data, such as questionnaires and biometrics, are generally not binary authenticators. For example, a fingerprint can combine with a reference fingerprint to varying degrees. To some extent, this may be due to variations in the quality of the data captured during the initial registration or in subsequent authentications. (A fingerprint may be stained or a person may have a healing scar or a burn on a particular finger.) In other cases, the data may match less than perfectly, because the information itself is somewhat variable and based on some combination of pattern. (A voice analysis may seem close, but not quite correct because of background noise, or the acoustics of the environment in which the voice is recorded, or because the person has a cold.) Finally, in situations where large quantities data are being compared, it may simply be the case that many of the data match well, but some do not. (A ten-question questionnaire may have resulted in eight correct answers to personal questions, but two incorrect answers.) For any of these reasons, the combination of registration data and data for a particular authentication instance can desirably be assigned a partial combination value by comparator 515. In this way, digital printing could be said to be an 85% combination, voice printing a 65% combination and the questionnaire an 80% combination, for example.

This measure (degree of combination) produced by comparator 515 is a factor that represents the basic question of whether authentication is correct or not. However, as discussed above, this is only one of the factors which can be used in determining the reliability of a given authentication instance. Also note that although a combination to some partial degree can be determined, it may ultimately be desirable to provide a binary result based on a partial combination. In an alternative mode of operation, it is also possible to treat partial combinations as binary, that is, perfect (100%) or failed (0%) combinations, based on whether or not the degree of combination passes a threshold level in combination. Such a process can be used to provide a simple pass / fail level of combination for systems which would otherwise produce partial combinations.

Another factor to be considered when assessing the reliability of a given authentication instance concerns the circumstances under which the authentication data for that particular instance is provided. As discussed above, the circumstances refer to the metadata associated with a particular authentication instance. This can include, without limitation, information such as: the network address of the authenticator, to the extent that it can be determined; the time of authentication76; the mode of transmission of authentication data (telephone line, cell phone, network, etc.); and the serial number of the authenticator system.

These factors can be used to produce a profile of the type of authentication that is normally requested by the user. So, this information can be used to assess reliability in at least two ways. One way is to consider whether the user is requesting authentication in a way that is consistent with the normal authentication profile for that user. If the user normally makes authentication requests from a network address during business hours (when she is at work) or from a network address during nights or weekends (when she is at home), authentication which occurs from the home address during business hours is less reliable because it is outside the normal authentication profile. Similarly, if the user normally authenticates using a fingerprint biometric and at night an authentication that originates during the day using only a password is less reliable.

An additional way in which circumstantial metadata can be used to assess the reliability of an authentication instance is to determine how much corroboration the circumstance provides that the authenticator is the individual it claims to be. For example, if authentication comes from a system with a serial number known to be associated with the user, this is a good circumstantial indicator that the user is who he claims to be. Conversely, if authentication is coming from a network address which is known to be from Los Angeles when the user is known to reside in London, this is an indication that this authentication is less reliable, based on your circumstances.

It is also possible that a cookie or other electronic data may be placed on the system being used by a user, when he interacts with a vendor system or with the trusted agent 110. This data is written to the user's system storage and can be contain an identification which can be read by a web browser or other software on the user's system. If this data is allowed to reside on the user's system between sessions (a persistent cookie), it can be sent with the authentication data as further evidence of past use of this system during a particular user's authentication. In effect, the metadata of a given instance, particularly a persistent cookie, can form a type of authenticator based on the card itself.

Once the appropriate reliability factors based on technique and authentication instance data are generated as described above in steps 1610 and 1615, respectively, they are used to produce general reliability for the authentication instance provided in step 1620 One way to do this is to simply express each reliability as a percentage and then multiply them together.

For example, suppose that authentication data is being sent from a network address known to be on the user's home computer completely in accordance with the user's past authentication profile (100%), and the technique being used is an ID of fingerprint (97%), and the initial fingerprint data is revealed through the user's employer with the trusted agent 110 (90%), and the combination of authentication data and the original fingerprint template in the registration data is very good (99%). The overall reliability of this authentication instance could then be calculated as the product of these reliability: 100% * 97% * 90% * 99% 86.4% reliability.

This calculated reliability represents the reliability of a single authentication instance. The overall reliability of a single authentication instance can also be calculated using techniques which treat different reliability factors differently, for example, by using formulas in which different weights are assigned to each reliability factor. Furthermore, those skilled in the art will recognize that the actual values used may represent values other than percentages and may use non-arithmetic systems. A modality may include a module used by an authentication requester to regulate weights for each factor and the algorithms used to establish the overall reliability of the authentication instance.

Authentication agent 215 can use the above techniques and variations of them to determine the reliability of a single authentication instance, referred to as step 1620. However, it can be useful in many authentication situations that multiple authentication instances are provided when Same time. For example, while attempting to authenticate himself using the system of the present invention, a user can provide user identification, fingerprint authentication data, a smart card and a password. In this case, three independent authentication instances are being provided for the trust agent 110 for evaluation. Proceeding to step 1625, if authentication agent 215 determines that the data provided by the user includes more than one authentication instance, then each instance in turn will be selected, as shown in step 1630 and evaluated as described above in steps 1610 , 1615 and 1620.

Note that many of the reliability factors discussed can vary from one of these instances to the other. For example, the inherent reliability of these techniques is likely to be different, as well as the degree of match provided between authentication data and registration data. Furthermore, the user may be provided with registration data at different times and under different circumstances for each of these techniques, providing different registration reliability for each of these instances as well. Finally, although the circumstances under which the data for each of these instances are being submitted are the same, the use of these techniques, each one, can adapt to the user's profile differently, and, thus, different circumstantial reliability can be attributed. (For example, the user can usually use their password and fingerprint, but not their smart card.)

As a result, the final reliability for each of these authentication instances may differ from each other. However, by using multiple instances together, the level of general trust for authentication will tend to increase.

Once the authentication agent has performed steps 1610 to 1620 for all authentication instances provided in the authentication data, the reliability of each instance is used in step 1635 to assess the overall authentication confidence level. This process of combining individual authentication instance trusts at the level of authentication trusts can be modeled by various methods relating to the individual trusts produced, and can also address the particular interaction between some of these authentication techniques. (For example, multiple knowledge-based systems, such as passwords, can produce less confidence than a single password and even a reasonably weak biometric, such as basic voice analysis.)

One way in which the authentication agent 215 can combine the reliability of multiple concurrent authentication instances to generate a final trust level is to multiply the unreliability of each instance to achieve total unreliability. Non-reliability is usually the complementary percentage of reliability. For example, a technique which is 84% reliable is 16% unreliable. The three authentication instances described above (fingerprint, smart card, password), which produce 86%, 75% and 72% reliability would have corresponding (100-86)%, (100-75)% and ( 10072)% or 14%, 25% and 28%, respectively. By multiplying these unreliability, a cumulative unreliability of 14% * 25% * 28% - 0.98% of unreliability is obtained, which corresponds to a reliability of 99.02%.

In an additional mode of operation, additional factors and heuristic 530 can be applied to authentication agent 215 to account for the interdependence of various authentication techniques. For example, if someone has unauthorized access to a particular home computer, they probably have access to the phone line at that address as well. Therefore, authentication based on a source phone number as well as the authentication system's serial number does not add much to the total trust in authentication. However, knowledge-based authentication is largely independent of token-based authentication (that is, if someone steals your cell phone or keys, they are not more likely to know your PIN or password than if they didn't).

Furthermore, different vendors or other authentication seekers may wish to consider different aspects of authentication differently. This may include the use of weighting factors or separate algorithms used to calculate the reliability of individual instances, as well as the use of different means for assessing authentication winds with multiple instances.

For example, sellers for certain types of transactions, for example, corporate email systems, may wish to authenticate primarily on the basis of heuristics and other circumstantial data by default. Therefore, they can apply high weights to factors related to metadata and other profile-related information associated with circumstances involving authentication events. This arrangement could be used to ease the burden on users during normal hours of operation, but does not require the user more than that he is connected to the correct machine during business hours. However, any vendor can consider authentications coming from a particular technique in a heavier form, for example, fingerprint combination, because of a political decision that such a technique is more suitable for authentication for the particular purposes of the vendor.

Such variable weights can be defined by the authentication requester when generating the authentication request and sent to the trust agent 110 with the authentication request in an operating mode. Such options could also be regulated as preferences during an initial registration process for the authentication requester and stored in the authentication agent in another mode of operation.

Once the authentication agent 215 produces an authentication trust level for the authentication data provided, this trust level is used to complete the authentication request in step 1640, and this information is forwarded from the authentication agent 215 to transaction agent 205 for inclusion in a message to the authentication requester.

The process described above is purely an example, and those skilled in the art will recognize that the steps need not be performed in the order shown in that it is only desired that some of the steps are performed, or that a variety of combinations of steps may be desired. Furthermore, certain steps, such as assessing the reliability of each provided authentication instance, can be carried out in parallel with another, if circumstances permit.

In another aspect of this invention, a method for accommodating conditions is provided when the level of authentication trust produced by the process described above fails to conform to the required trust level of the seller or another party requiring authentication. In circumstances such as these, where there is a gap between the provided confidence level and the desired confidence level, the trust agent operator 110 is in a position to provide opportunities for one or both parties to provide alternative data or demands, in order to close that space of trust. This process will be referred to as trust arbitration here.

Trust arbitration can take place in a cryptographic authentication framework as described above with reference to FIGURES 10 and 11. As shown there, a seller or other party will request authentication of a particular user in association with a particular transaction. In one circumstance, the seller simply requests authentication, positive or negative, and after receiving the appropriate data from the user, the trusted agent 110 will provide such binary authentication. In circumstances such as these, the degree of trust required to make positive authentication secure is determined based on preferences regulated in the trust agent 110.

However, it is also possible that the seller may request a particular level of trust in order to complete a particular transaction. This required level can be included with the authentication request (for example, authenticating this user to 98% trust) or can be determined by the trust agent 110 based on other factors associated with the transaction (that is, authenticating this user as appropriate for this transaction). One of these factors could be the economic value of the transaction. For transactions that have greater economic value, a higher degree of confidence may be required. Similarly, for transactions with high degrees of risk, a high degree of confidence may be required. Conversely, for transactions which are low risk or low value, lower levels of trust may be required by the seller or other authentication requester.

The trust arbitration process takes place between the steps of the trust agent 110 receiving the authentication data in step 1050 of FIGURE 10 and the return of an authentication result to the seller in step 1055 of FIGURE 10. Among these steps, the process which leads to the assessment of confidence levels and the potential confidence arbitrage occurs, as shown in FIGURE 17. In circumstances where a simple binary authentication is performed, the process shown in FIGURE 17 comes down to having transaction agent 205 directly comparing the authentication data provided with the registration data for the user identified as discussed above with reference to FIGURE 10 , indicating any difference as a negative authentication.

As shown in FIGURE 17, the first step after receiving the data in step 1050 is for transaction agent 205 to determine the level of trust which is required for positive authentication for this particular transaction in step 1710. This step can be performed by one of several different methods. The required trust level can be specified for trust agent 110 by the authentication requester at the time the authentication request is made. The authentication request can also set a preference in advance, which is stored in deposit 210 or other storage, which is accessible by transaction agent 205. This preference can then be read and used each time a authentication request is made by this authentication requester. The preference can also be associated with a particular user as a security measure, so that a particular level of trust is always required in order to authenticate that user, the user preference being stored in deposit 210 or another storage medium accessible by transaction agent 205. The required level can also be derived by the transaction agent 205 or by the authentication agent 215, based on information provided in the authentication request, such as the value and the risk level of the transaction to be authenticated.

In a mode of operation, a policy management module or other software which is used when generating the authentication request is used to specify the required degree of trust for transaction authentication. This can be used to provide a series of rules to follow when assigning the required level of trust based on the policies which are specified in the policy management module. An advantageous mode of operation is for such a module to be incorporated into a seller's web server in order to properly determine the level of trust required for transactions initiated with the seller's web server. In this way, user transaction requests can be assigned a required trust level according to the vendor's policies, and this information can be forwarded to the trust agent 110 along with the authentication request.

This level of confidence required correlates with the degree of certainty that the seller wants to have that the individual authenticating is in fact who he identifies himself as being. For example, if the transaction is one in which the seller wants a reasonable degree of certainty because items are changing hands, the seller may require a confidence level of

85%. For a situation where the seller is merely authenticating the user to allow them to view member-only content or exercise privileges in a chat room, the negative risk may be small enough that the seller requires a level of trust from only 60%. However, to enter into a production contract worth tens of thousands of dollars, the seller may require a confidence level of 99% or more.

This required confidence level represents a metric with which the user must authenticate himself, in order to complete the transaction. If the required level of trust is 85%, for example, the user must provide enough authentication for trust agent 110 for trust agent 110 to say with 85% confidence that the user is who he claims to be. It is the balance between this required confidence level and the authentication confidence level that produces a positive authentication (to the satisfaction of the seller) or a possibility of trust arbitration.

As shown in FIGURE 17, after transaction agent 205 receives the required confidence level, it compares, in step 1720, the required confidence level with the authentication confidence level, which authentication agent 215 calculated for authentication current (as discussed with reference to FIGURE 16). If the authentication trust level is higher than the trust level required for the transaction in step 1730, then the process moves to step 1740, where a positive authentication for this transaction is produced by the transaction agent 205. A message for this purpose will then be inserted into the authentication results returned to the seller by the transaction agent 205, as shown in step 1055 (see FIGURE 10).

However, if the authentication trust level does not meet the trust level required in step 1730, then there is a trust space for current authentication, and trust arbitration is conducted in step 1750. Trust arbitration is described more completely with reference to FIGURE 18 below. This process, as described below, occurs at transaction agent 205 of trust agent 110. Because no authentication or other cryptographic operations are required to perform trust arbitration (other than those required for SSL communication between transaction agent 205 and other components), the process can be performed outside the authentication agent 215. However, as will be discussed below, any reassessment of authentication data or other cryptographic or authentication events will require transaction agent 205 to resubmit appropriate data to authentication agent 215. Those skilled in the art will recognize that the arbitration process could be structured, alternatively, to occur partially or entirely in the authentication agent 215 itself.

As mentioned above, trust arbitration is a process in which the trust agent 110 mediates a negotiation between the seller and a user in an attempt to secure positive authentication when appropriate. As shown in step 1805, transaction agent 205 first determines whether or not the current situation is appropriate for trust arbitration. This can be determined based on the circumstances of the authentication, for example, whether this authentication has already been through multiple arbitration cycles, as well as according to the seller's or user's preferences, as will be further discussed below.

In these circumstances where arbitration is not possible, the process proceeds to step 1810, where transaction agent 205 generates a negative authentication and then inserts it into the authentication results, which are sent to the seller in step 1055 ( see FIGURE 10). A limit which can be used advantageously to prevent authentications from being pending indefinitely is to regulate an expiration period from the initial authentication request. In this way, any transaction that is not positively authenticated within the time limit is denied additional arbitration and is negatively authenticated. Those skilled in the art will recognize that such a time limit may vary depending on the circumstances of the transaction and the wishes of the user and the seller. Limitations can also be imposed on the number of attempts that can be made to provide successful authentication. Such limitations can be manipulated by a trial limiter 535, as shown in FIGURE 5.

If an arbitration is not prohibited in step 1805, the transaction agent 205 will then enter into negotiations with one or both parties to the transaction. The transaction agent 205 can send a message to the user requesting some form of additional authentication, in order to enhance the level of authentication trust produced, as shown in step 1820. In the simplest form, this can simply indicate that an authentication has been insufficient. A request for the production of one or more authentication instances to improve the overall confidence level of authentication can also be submitted.

If the user provides some additional authentication instances in step 1825, then transaction agent 205 adds these authentication instances to the authentication data for the transaction and forwards them to authentication agent 215, as shown in step 1015 (see FIGURE 10), and authentication is reassessed, based on the pre-existing authentication instances for this transaction and the newly provided authentication instances.

An additional type of authentication can be a request from the trusted agent 110 to make some form of person-to-person contact between the operator of the trusted agent 110 (or a trusted associate) and the user, for example, by a phone call. This phone call or other non-computer authentication can be used to provide personal contact with the individual and also to conduct some form of questionnaire-based authentication. This can also provide an opportunity to verify a source phone number and potentially a voice analysis of the user when he calls. Even if no additional authentication data can be provided, the additional context associated with the user's phone number can improve the reliability of the authentication context. Any87 revised data or circumstances based on this phone call are fed to the trusted agent 110 for use considering the authentication request.

Additionally, in step 1820, the trusted agent 110 can provide an opportunity for the user to purchase insurance, effectively purchasing more trusted authentication. The trust agent operator 110 may sometimes just want to make an option like this available, if the trust level of authentication is above a certain threshold to begin with. In effect, this user side insurance is a way for the trust agent 110 to certify the user, when authentication meets the normal trust level required by the trust agent 110 for authentication, but does not meet the required trust level. the seller for this transaction. In this way, the user can still be successful in authentication to a very high level, as may be required by the seller, although he has only authentication instances which produce sufficient trust for the trust agent 110.

This role of the trusted agent 110 allows the trusted agent 110 to vouch for someone who has been authenticated to the satisfaction of the trusted agent 110, but not the seller. This is analogous to the function performed by a notary when adding his signature to a document, in order to indicate to someone reading the document at a later time that the person whose signature appears on the document is in fact the person who signed it. The notary's signature testifies to the act of signature by the user. Likewise, the trustee is providing an indication that the person in transaction is who he says he is.

However, due to the fact that the trust agent 110 is artificially boosting the trust level provided by the user, there is a great risk for the trust agent operator 110, since the user is not really meeting the required trust level. from the seller. The insurance cost is designed to shift the risk of false positive authentication to the trusted agent 110 (who can effectively certify the user's authentications with a notary). The user pays the trust agent operator 110 to take the risk of authenticating to a higher trust level than what was actually provided.

Because an insurance system allows someone to effectively purchase a higher trust rating from trust agent 110, both sellers and users may wish to avoid using user-side insurance in certain transactions. Vendors may wish to limit positive authentications when they know what real authentication data supports the degree of trust they require and thus can indicate to the trust agent 110 that user side insurance is not to be allowed. Similarly, for the protection of their online identity, a user may wish to prevent the use of user-side insurance on their account, or may wish to limit their use to situations where the level of authentication trust without the insurance it is higher than a certain limit. This can be used as a security measure to prevent someone from hearing a password or stealing a smart card and using them to falsely authenticate to a low level of trust and then purchase insurance to produce a very high level (fake ) reliable. These factors can be assessed when determining whether user side insurance is allowed.

If the user purchases insurance in step 1840, then the authentication confidence level is adjusted based on the insurance purchased in step 1845, and the authentication confidence level and the required confidence level are again compared in step 1730 (see FIGURE 17). The process continues from there, and can lead to positive authentication in step 1740 (see FIGURE 17) or back to the trust arbitration process in step 1750 for another arbitration (if allowed) or negative authentication in step 1810, if further arbitration is prohibited.

In addition to sending a message to the user at step 1820, transaction agent 205 can also send a message to the seller at step 1830, which indicates that pending authentication is currently below the required confidence level. The message can also offer several options on how to proceed for the seller. One of these Options is simply to inform the vendor what the current authentication confidence level is and ask if the vendor wants to maintain its current required unfulfilled confidence level. This can be beneficial because, in some cases, the seller may have independent means of authenticating the transaction or a standard set of requirements may have been used, which generally result in a higher level of requirement being initially specified than what it is really necessary for the particular transaction at hand.

For example, it may be standard practice that all purchase order transactions entering with the seller are expected to conform to a 98% confidence level. However, if an order was recently discussed over the phone between the seller and a longtime consumer, and immediately after the transaction is authenticated, but only to a 93% confidence level, the seller may simply wish to lower the acceptance limit for this transaction, because the phone call effectively provides additional authentication for the seller. In certain cases, the vendor may be willing to lower his required trust level, but not all the way down to the current authentication trust level. For example, the seller in the example above might consider that the phone call prior to the order could have a 4% reduction in the necessary degree of confidence; however, this is still greater than the 93% confidence produced by the user.

If the seller adjusts the confidence level required in step 1835, then the authentication confidence level produced by authentication and the required confidence level are compared in step 1730 (see FIGURE 17). If the confidence level now exceeds the required confidence level, positive authentication can be generated at transaction agent 205 in step 1740 (see FIGURE 17). If not, additional arbitration may be attempted, as discussed above, if allowed.

In addition to requesting an adjustment to the required confidence level, transaction agent 205 may also offer seller side insurance to the seller requesting authentication. This insurance serves a purpose similar to that described above for user side insurance. Here, however, instead of the cost corresponding to the risk being taken by the trust agent 110 in the authentication above the real authentication confidence level produced, the insurance cost corresponding to the risk is taken by the seller when accepting a lower confidence level in the authentication.

Rather than just lowering their actual required confidence level, the seller has the option to purchase insurance to protect against the additional risk associated with a lower level of confidence in user authentication. As described above, it may be advantageous for the seller to only consider purchasing such insurance to cover the trust space under conditions where existing authentication is already above a certain threshold.

The availability of this vendor-side insurance allows the vendor the option of: lowering his trust requirement directly at no additional cost to himself, bearing the risk of false authentication himself (based on the lowest required confidence level); or purchase insurance for the trust space between the authentication trust level and your requirement, with the trust agent operator 110 bearing the risk of the lowest trust level provided. By purchasing the insurance, the seller effectively maintains his high confidence level requirement, because the risk of a lack of authentication is shifted to the operator of the trust agent 110.

If the seller purchases insurance in step 1840, the authentication confidence level and the required confidence level are compared in step 1730 (see FIGURE 17), and the process continues, as described above.

Note that it is also possible for the user and seller to respond to messages from the trusted agent 110. Those skilled in the art will recognize that there are multiple ways in which situations like this can be handled. An advantageous way of manipulating the possibility of multiple responses is simply to treat responses in a first-come-first-served manner. For example, if the seller responds with a required level of confidence lowered and immediately thereafter the user also buys insurance to raise their level of authentication, authentication is first reassessed based on the requirement for lowered trust of the seller. If authentication is now positive, the user's insurance purchase is ignored. In another advantageous mode of operation, the user could be taxed for the level of insurance required to suit the new lowered trust requirement of the seller (if a trust space remained, even with the lowered seller confidence requirement).

If no response is received from either party, the trust arbitration process in step 1850 within the time limit set for authentication, the arbitration is reevaluated in step 1805. This effectively begins the arbitration process again. If the time limit was final or other circumstances prevented further arbitration in step 1805, a negative authentication is generated by transaction agent 205 in step 1810 and returned to the seller in step 1055 (see Fl20 GURA 10). If not, new messages can be sent to the user and the seller, and the process can be repeated, as desired.

Note that for certain types of transactions, for example, digital signature documents which are not part of a transaction, there may not necessarily be a seller or another third party; therefore, the transaction is primarily between the user and the trust agent 110. In circumstances such as these, the trust agent 110 will have its own required level of trust, which must be satisfied in order to generate positive authentication. However, in such circumstances, it is often not desirable for the trust agent 110 to offer insurance to the user, so that he raises the confidence of his own signature.

The process described above and shown in FIGURES 16 to 18 can be performed using various modes of communication, as described above with reference to the trusted agent 110. For example, messages can be web based and sent using network connections. SSL between trusted agent 110 and applets transferred in real time to browsers running on vendor or user systems. In an alternative mode of operation, certain dedicated applications may be in use by the user and the seller, which facilitate such arbitration and insurance transactions. In another alternative mode of operation, secure e-mail operations can be used to mediate the arbitration described above, thereby allowing deferred assessments and batch processing of authentications. Those skilled in the art will recognize that different modes of communication can be used as appropriate to the vendor's authentication circumstances and requirements.

The following description with reference to FIGURE 19 describes a sample transaction which integrates the various aspects of the present invention, as described above. This example illustrates the general process between a user and a salesperson as mediated by the trusted agent 110. Although the various steps and components as described in detail above can be used to carry out the following transaction, the illustrated process focuses on the interaction between the trusted agent 110, the user and the seller.

The transaction begins when the user, while viewing web pages online, fills out an order form on the seller's website in step 1900. The user wants to submit this order form to the seller, signed with his digital signature. In order to do this, the user submits the order form with his request for a signature to the trusted agent 110, in step 1905. The user will also provide authentication data which will be used, as described above for the authentication of his identity.

In step 1910, the authentication data is compared with the registration data by the trusted agent 110, as discussed above, and if a positive authentication is produced, proof of the order form, signed with the user's private key, is forwarded to the seller along with the order form itself.

The seller receives the form signed in step 1915, and then the seller will generate an invoice or other contract related to the purchase to be made in step 1920. This contract is sent back to the user with a request for a subscription in step 1925 The seller also sends an authentication request for this contract transaction to the trusted agent 110, in step 1930, including proof of the contract which will be signed by both parties. In order to allow the contract to be digitally signed by both parties, the seller also includes authentication data itself, so that the seller's signature on the contract can be verified later, if necessary.

As discussed above, the trust agent 110 then verifies the authentication data provided by the seller to confirm the seller's identity and, if the data produces positive authentication in step 1935, it continues with step 1955, when the data is received of user. If the vendor's authentication data does not match the digital certificate registration data to the desired degree, a message is returned to the vendor requesting additional authentication. Trust arbitration can be performed here, if necessary, as described above, so that the seller can successfully authenticate himself to the trust agent 110.

When the user receives the contract in step 1940, he reviews it, generates authentication data to sign it, if this is acceptable in step 1945, and then sends proof of the contract and his authentication data to the trusted agent 110 in step 1950. Trust agent 110 checks authentication data in step 1955 and, if authentication is good, proceeds to process the contract, as described below. As discussed above with reference to FIGURES 17 and 18, a trust arbitration can be performed as appropriate to close any trust space that exists between the level of authentication trust and the level of authentication required for the transaction.

The trusted agent 110 signs the proof of contract with the user's private key and sends this signed proof to the seller in step 1960, signing the complete message in his own name, that is, including a proof of the complete message (including the signature encrypted with private agent 510 private key 110. This message is received by the seller in step 1965. The message represents a signed contract (proof of the encrypted contract using the user's private key) and a receipt from the trusted agent 110 (proof of the message including the encrypted signed contract using the private key of the trust agent 110) .

Trust agent 110, similarly, prepares a proof of contract with the seller's private key in step 1970, and forwards this to the user, signed by trust agent 110. This way, the user also receives a copy of the contract , signed by the seller, as well as a receipt, signed by the trusted agent 110, for sending the contract signed in step 1975.

In addition to the foregoing, an additional aspect of the invention provides a cryptographic Service Provider Module (SPM), which may be available to a client-side application as a means of accessing functions provided by the trusted agent 110 described above. An advantageous way of providing a service like this is for the cryptographic SPM to be for mediation of communications between a third party Application Programming Interface (API) and a trusted agent 110, which is accessible over a network or a another remote connection. A sample cryptographic SPM is described below with reference to FIGURE 20.

For example, in a typical system, several APIs are available to programmers. Each API provides a set of function calls which can be made by a 2000 application running on the system. Examples of APIs which provide suitable programming interfaces for cryptographic functions, authentication functions and other security functions include the Cryptographic API (CAPI) 2010 provided by Microsoft with its Windows operating systems, and the Common Data Security Architecture ( CDSA), sponsored by IBM, Intel and other members of the Open Group. CAPI can be used as an example security API in the discussion that follows. However, the cryptographic SPM described could be used with CDSA or other security APIs that are known in the art.

This API is used by a user system 105 or a vendor system 120, when a call is made by a cryptographic function. Among these functions, requests associated with the performance of various cryptographic operations, such as encrypting a document with a private key, signing a document, requesting a digital certificate, verifying a signature using a signed document, can be included among these functions. and such other cryptographic functions as described herein or known to those skilled in the art.

Such cryptographic functions are usually performed locally on the system in which CAPI 2010 is located. This is because generally the functions called require the use of local user system resources 105, such as a fingerprint reader, or software functions which are programmed using libraries which are run on the local machine. Access to these local resources is usually provided by one or more Service Provider Modules (SPMs) 2015, 2020, as mentioned above, which provide resources with which cryptographic functions are performed. Such SPMs may include software libraries 2015 for performing encryption or decryption operations, or 2020 drivers or applications which are capable of accessing specialized 2025 hardware, such as biometric scanning devices. Much of the way in which CAPI 2010 provides functions that can be used by the system 2000 application 105, SPMs 2015, 2020 provide a CAPI with access to the lowest level functions and resources associated with the services available in the system.

According to the invention, it is possible to provide a cryptographic SPM 2030, which is able to access the cryptographic functions provided by the trusted agent 110 and making these functions available to a 2000 application through CAPI 2010. Unlike the modalities in which CAPI 2010 is only able to access resources which are locally available through SPMs 2015, 2020, a 2030 cryptographic SPM as described here would be able to submit requests for cryptographic operations to a remotely located trust agent accessible at 110 in order to carry out the desired operations.

For example, if an application 2000 has a need for a cryptographic operation, such as signing a document, application 2000 makes a function call to the appropriate CAPI 2010 function. CAPI 2010 in turn will perform this function, making use of the resources which are made available to it by SPMs 2015, 2020 and by cryptographic SPM 2030. In the case of a digital signature function, the cryptographic SPM 2030 will generate an appropriate request, which will be sent to the trusted agent 110 via communication link 125.

The operations that take place between cryptographic SPM 2030 and trust agent 110 are the same operations that would be possible between any other system and trust agent 110. However, these functions are effectively made available to a user system 105 through CAPI 2010, so that they appear to be locally available on user system 105 itself. However, unlike common SPMs 2015, 2020, functions are being performed on remote trust agent 110 and the results are transmitted to cryptographic SPM 2030 in response to the appropriate requests via communication link 125.

This cryptographic SPM 2030 makes various operations available for user system 105 or a vendor system 120, which otherwise might not be available. These functions include, without limitation: encryption and decryption of documents; issuing digital certificates; digital signature of documents; verification of digital signatures; and other operations as will be evident to those skilled in the art.

In a separate embodiment, the present invention comprises a complete system for carrying out the methods of securing the data of the present invention in any data set. The computer system of this modality comprises a data division module which comprises the functionality shown in FIGURE 8 and described here. In one embodiment of the present invention, the data division module comprises a grammar analyzer program or a set of software programs which comprises a data division, encryption and decryption, reconstitution or reassembly functionality. This modality can also comprise one data storage facility or multiple data storage facilities as well. The data division module or the grammar analyzer comprises a set of cross-platform software module programs that integrate into an electronic infrastructure, or as an add-on for any application that requires the ultimate security in its elements of Dice. This grammar analysis process operates on any type of data set and on any and all types of files or in a database in any row, column or cell of data in that database.

The grammatical analysis process of the present invention in one embodiment can be designed in a modular queue manner, and any encryption process is suitable for use in the process of the present invention. The modular queues of the parsing process of the present invention can include, but are not limited to: 1) a cryptographic division, dispersed and securely stored in multiple locations; 2) encryption, cryptographic division, dispersed and securely stored in multiple locations; 3) encryption, cryptographic division, encryption of each share, then dispersed and stored securely in multiple locations; and 4) encryption, cryptographic division, encryption of each share with a different type of encryption that was used in the first step, then dispersed and stored securely in multiple locations.

The process comprises, in one modality, the division of the data according to the content of a generated random number, or key, and the realization of the same cryptographic division of the key used in the encryption of the division of data to be made secure in two or more portions , or shares, of parsed data, and, in one mode, preferably four or more parsed data, the encryption of all portions, then dispersing and storing these portions back in the database, or relocating them to any named, fixed or removable device, depending on the privacy and security requester's need. Alternatively, in another mode, encryption can occur before the data set is divided by the division module or parser. The original data processed as described in this modality is encrypted and obscured and is safe. The dispersion of encrypted elements, if desired, can be virtually anywhere, including, but not limited to, a single data storage server or device, or between separate data storage facilities or devices. The encryption key management in one mode can be included in the set of software programs or in another mode it can be integrated into an existing infrastructure or any other desired location.

A cryptographic division (cryptodivision) partitions the data into N number of shares. Partitioning can be in any data size unit, including an individual bit, bits, bytes, kilobytes, megabytes or larger units, as well as in any standard or combination of data unit sizes, whether predetermined or randomly generated. Units can also be of different size based on a random or predetermined set of values. This means that the data can be seen as a sequence of these units. In this way, the size of the data units themselves can make data more secure, for example, by using one or more predetermined or randomly generated patterns, sequences or combinations of data unit sizes. The units are then distributed (either 99 micically or by a predetermined set of values) to the N shares. This distribution could also involve shuffling the order of the units in the shares. It is readily apparent to those of ordinary skill in the art that the distribution of data units to shares can be performed according to a wide variety of possible selections, including, but not limited to, fixed size, predetermined sizes or one or more combinations, standard or sequence of data unit sizes that are predetermined or randomly generated.

An example of this cryptographic division or cryptodivision process would be to consider the data to be 23 bytes in size with the data unit size chosen to be one byte, and the number of shares selected to be 4. Each byte would be distributed to one of 4 shares. Assuming a random distribution, a key would be obtained to create a sequence of 23 random numbers (r1, r2, r3 to r23), each with a value between 1 and 4 corresponding to the four shares. Each of the data units (in this example 23 individual bytes of data) is associated with one of the 23 random numbers corresponding to one of the four shares. The distribution of data bytes to the four shares would occur by placing the first data byte in share number r1, byte two in share r2, byte three in share r3 up to the 23rd byte of data in share r23. It is readily apparent to those of ordinary skill in the art that a wide variety of other possible steps or combination or sequence of steps, including the size of the data units, can be used in the cryptodivision process of the present invention, and the example above is a description not limiting a process for cryptodivision of data. To recreate the original data, the reverse operation would be performed.

In another embodiment of the cryptodivision process of the present invention, an option for the cryptodivision process is to provide sufficient redundancy in shares so that only one set

100 sharing is necessary for reassembling or restoring the data to its original or usable form. As a non-limiting example, cryptodivision can be done as a 3 of 4 cryptodivision so that only three out of four shares are required for reassembly or restoring the data to its original or usable form. This is also referred to as a cryptodivision M of N, where N is the total number of shares, and M is at least one less than N. It is readily apparent to those of ordinary skill in the art that there are many possibilities for creating this redundancy. in the cryptodivision process of the present invention.

In one embodiment of the cryptodivision process of the present invention, each data unit is stored in two shares, the first share and the backup share. Using the cryptodivision 3 of 4 process described above, any share may be missing, and this is sufficient for reassembling or restoring the original data with no data units missing, since only three of the four total shares are required. As described here, a random number is generated, which corresponds to one of the shares. The random number is associated with a data unit, and stored in the corresponding share, based on a key. A key is used, in this modality, to generate the random number of primary and backup shares. As described here for the cryptodivision process of the present invention, a set of random numbers (also referred to as primary share numbers) from 0 to 3 are generated equal to the number of data units. Then, another set of random numbers is generated (also referred to as backup share numbers) from 1 to 3 equal to the number of data units. Each data unit is then associated with a primary share number and a backup share number. Alternatively, a set of random numbers can be generated that is less than the number of data units, and the set of random numbers is repeated, but this can reduce the security of sensitive data. The primary share number is used to determine in which compartment the data unit is stored. The backup share number is combined with the primary share number to create a third share number between 0 and 3, and this number is used to determine which share the data unit is stored on. In this example, the equation for determining the third share number is:

(primary share number + backup share number) MOD 4 = third share number.

In the mode described above, where the primary share number is between 0 and 3, and the backup share number is between 1 and 3, it is ensured that the third share number is different from the primary share number. This results in the data unit being stored on two different shares. It is readily apparent to those of ordinary skill in the art that there are many embodiments of redundant cryptodivision and non-redundant cryptodivision in addition to the modalities shown here. For example, the data units in each share could be shuffled using a different algorithm. This data unit scrambling can be performed as the original data is divided into the data units, or after the data units are placed in the shares, or after the share is full, for example.

The various cryptodivision and data shuffling processes described here and all other modalities of the cryptodivision and data shuffling methods of the present invention can be performed on data units of any size, including, but not limited to, as small as an individual bit, bits, bytes, kilobytes, megabytes or larger.

An example of a source code modality that would perform the cryptodivision process described here is:

DATE [1:24] - arrangement of bytes with the data to be divided SHARES [0; 3; 1:24] - two-dimensional arrangement with each re102 line showing one of the shares

RANDOM [1:24] - random arrangement numbers in the range 0 to 3 = 1;

= 1;

For K = 1 to 24 do Begin

IF RANDOM [J [== 0 then Begin

SHARES [1, S1] = DATE [J];

S1 = S1 + 1;

End

ELSE IF RANDOM [J [== 1 then Begin

SHARES [2, S2] = DATE [J];

S2 = S2 + 1;

END

ELSE IF RANDOM [J [== 2 then Begin

Shares [3, S3] = date [Jj:

= S3 + 1;

End

Else begin

Shares [4, S4] = date [J];

= S4 + 1;

End;

END;

An example of a source code modality that would perform the cryptodivision RAID process described here is:

Generate two sets of numbers, PrimaryShare is 0 to 3,

103

BackupShare is 1 to 3. Then, put each data unit in share [primaryshare [1]] and share [(primaryshare [1] + backupshare [1]) mod 4, with the same process as in the cryptodivision described above. This method will be scalable to any size N, where only N-1 shares are required for data restoration.

The recovery, recombination, reassembly or reconstitution of the encrypted data elements can use any number of authentication techniques, including, but not limited to, biometric, such as fingerprint recognition, facial scanning, hand scanning, iris scanning , retinal scan, ear scan, vascular pattern recognition or DNA analysis. The data sharing or parser modules of the present invention can be integrated into a wide variety of infrastructure products or applications, as desired.

Traditional encryption technologies known in the art rely on one or more keys used to encrypt data and to make it useless without the key. The data, however, remains whole and intact and subject to attack. The set of parser software programs of the present invention, in one modality, addresses this problem by performing a cryptographic division or grammatical analysis of the encrypted file into two or more portions or shares, and in a modality preferably four or more shares, adding another layer of encryption to each data share, then storing the shares in different physical and / or logical locations. When one or more data shares are physically removed from the system, by using a removable device, such as a data storage device, or by placing the share under the control of another party, any possibility of compromising secure data is effectively removed.

An example of a modality of the parser software package of the invention and an example of how it

104 can be used are shown in FIGURE 21 and described below. However, it is readily apparent to those of ordinary skill in the art that the set of parser software programs of the present invention can be used in a wide variety of ways in addition to the non-limiting example below. As an employment option, and in one embodiment, the parser can be implemented with external session key management or secure internal session key storage. Upon implementation, a Parser Master Key will be generated, which will be used to secure the application and for encryption purposes. It should also be noted that the incorporation of the Grammar Analyzer Master Key into the resulting secure data allows for flexibility in sharing secure data by individuals in a workgroup, a company or an extended audience.

As shown in Figure 21, this embodiment of the present invention shows the processing steps performed by the set of parser software programs on the data for storing the session master key with the parsed data:

1. Generation of a session master key and data encryption using an RS1 flow cipher.

2. Separation of the encrypted data resulting in four shares or portions of data parsed according to the pattern of the session master key.

3. In this modality of the method, the session master key will be stored together with the secure data shares in a data warehouse. Separation of the session master key according to the standard Parser Master Key and data attachment to the parsed encrypted data.

4. The resulting four shares will contain encrypted portions of the original data and portions of the session master key. Generate a flow cipher key for each of the four shares

105 of data.

5. Encryption of each share, then storing the encryption keys in locations other than the encrypted data portions or shares: Share 1 takes Key 4, Share 2 takes Key 1, Share 3 takes Key 2, Share 4 take Key 3.

To restore the original data format, the steps are reversed.

It is readily apparent to those of ordinary skill in the art that certain steps of the methods described here can be performed in a different order, or repeated multiple times, as desired. It is also readily apparent to those skilled in the art that portions of the data can be manipulated differently from one another. For example, multiple steps of parsing can be performed on only a portion of the parsed data. Each portion of parsed data can only be made safe in any desirable way as long as only the data can be remounted, reconstituted, reformed, decrypted or restored to its original or other usable form.

As shown in FIGURE 22 and described here, another embodiment of the present invention comprises the process steps performed by the set of parser software programs in the data for storing session master key data in one or more management tables. separate keys:

1. Generation of a session master key and data encryption using an RS1 flow cipher.

2. Separation of the encrypted data resulting in four shares or portions of data parsed according to the pattern of the session master key.

3. In this method modality, the session master key will be stored in a separate key management table in a data store. Generation of a unique transaction ID for this transaction. Storing the transaction ID and session master key in a separate key management table. Separation of the transaction ID in accordance with the Parser Master Key standard and attachment of the data to the parsed or encrypted parsed data.

4. The resulting four shares will contain encrypted portions of the original data and portions of the transaction ID.

5. Generation of a flow cipher key for each of the four data shares.

6. Encryption of each share, then storing the encryption keys in locations other than the encrypted data portions or shares: Share 1 takes Key 4, Share 2 takes Key 1, Share 3 takes Key 2, Share 4 take Key 3.

To restore the original data format, the steps are reversed.

It is readily apparent to those of ordinary skill in the art that certain steps of the methods described here can be performed in a different order, or repeated multiple times, as desired. It is also readily apparent to those skilled in the art that portions of the data can be manipulated differently from one another. For example, multiple separation or parsing steps can be performed on only a portion of the parsed data. Each portion of parsed data can only be made safe in any desirable way as long as only the data can be remounted, reconstituted, reformed, decrypted or restored to its original or other usable form.

As shown in Figure 23, this embodiment of the present invention shows the process steps performed by the set of parser software programs in the data for storing the session master key with the parsed data:

1. Access to the parser master key associated with the

107 authenticated user.

2. Generation of a single Session Master Key.

3. Derivation of an Intermediate Key from an exclusive OR function of the Parser Master Key and the Session Master Key.

4. Optional data encryption using an existing or new encryption algorithm keyed with the Intermediate Key.

5. Separation of the encrypted data resulting in four shares or portions of data parsed according to a10 in accordance with the Intermediate Key standard.

6. In this modality of the method, the session master key will be stored together with the secure data shares in a data warehouse. Separation of the session master key according to the Parser Master Key standard and attachment of the key data to the optionally encrypted parsed data.

7. The resulting multiple data shares will contain optionally encrypted portions of the original data and portions of the session master key.

8. Optionally, the generation of an encryption key for each of the four data shares.

9. Optionally, encrypting each share with an existing or new encryption algorithm, then storing the encryption keys in locations other than the encrypted data portions or shares: Share 1 takes the Key 4, Share 2 takes the Key 1, Share 3 takes Key 2, Share 4 takes Key 3.

To restore the original data format, the steps are reversed.

It is readily apparent to those of ordinary skill in the art that certain steps of the methods described here can be performed in a different order, or repeated multiple times, as desired. also

108 it is readily apparent to those skilled in the art that portions of the data can be manipulated differently from one another. For example, multiple steps of parsing can be performed on only a portion of the parsed data. Each portion of parsed data can only be made safe in any desirable way as long as only the data can be remounted, reconstituted, reformed, decrypted or restored to its original or other usable form.

As shown in FIGURE 24 and described here, another embodiment of the present invention comprises the process steps performed by the set of parser software programs in the data for storing session master key data in one or more management tables. separate keys:

1. Access to the Parser Master Key associated with the authenticated user.

2. Generation of a single Session Master Key.

3. Derivation of an Intermediate Key from an exclusive OR function of the Parser Master Key and the Session Master Key.

4. Optional data encryption using an existing or new encryption algorithm keyed with the Intermediate Key.

5. Separation of encrypted data resulting in four shares or portions of data parsed according to the Intermediate Key standard.

6. In this method modality, the session master key will be stored in a separate key management table in a data store. The generation of a unique transaction ID for this transaction. Storing the transaction ID and session master key in a separate key management table or passing the Session Master Key and transaction ID back to the program calling for external management. Separation of the transaction ID according to the Parser Master Key standard and appending109 of the key data to the parsed data optionally optionally encrypted or separated.

7. The resulting four data shares will contain optionally encrypted portions of the original data and portions of the transaction ID.

8. Optionally, the generation of an encryption key for each of the four data shares.

9. Optionally, encrypting each share, then storing the encryption keys in locations other than the encrypted data portions or shares. For example: Share 1 takes Key 4, Share 2 takes Key 1, Share 3 takes Key 2, Share 4 takes Key 3.

To restore the original data format, the steps are reversed.

A wide variety of encryption methodologies are suitable for use in the methods of the present invention, as is readily apparent to those skilled in the art. The One Time Pad algorithm is often considered to be one of the most secure encryption methods, and is suitable for use in the method of the present invention. Using the One Time Pad algorithm requires that a key be generated, which is as long as

110 the data to be made secure. The use of this method may be less desirable in certain circumstances, such as those resulting in the generation and management of very long keys, because of the size of the data set to be made secure. In the One Time Pad (OTP) algorithm, the simple or exclusive function, XOR, is used. For two binary streams x and y of the same length, x XOR y means o or exclusive in the bit sense of x and y.

At the bit level, the following is generated:

XOR 0 = 0

0XOR1 = 1

XOR 0 = 1

XOR1 = 0

An example of this process is described here for an n-byte secret, s (or data set), to be divided. The process will generate a random value of n bytes, a, and then regulate:

b = a XPR s.

Note that s can be derived using the equation: s = a XOR b.

Values a and b are referred to as shares or portions and are placed in separate deposits. Once the secret is divided into two or more shares, it is safely discarded.

The set of parser software programs of the present invention can use this function by performing multiple XOR functions incorporating multiple distinct secret key values: K1, K2, K3, Kn, K5. At the beginning of the operation, the data to be made safe is passed through the first encryption operation, hold data = XOR data secret key 5:

S = D XOR K5.

In order to securely store the resulting encrypted data, for example, in four shares, S1, S2, S3, Sn, the data is parsed in n segments, or shares111, according to the value of K5. This operation results in n pseudo-random sharing of the original encrypted data. Subsequent XOR functions can then be performed on each share with the remaining secret key values, for example: Take secure data segment 1 = encrypted data share 1 XOR secret key 1:

SD1 = S1 XOR K1

SD2 = S2 XOR K2

SD3 = S3 XOR K3

SDn = Sn XOR Kn.

In one embodiment, it may not be desirable to have any deposit containing enough information to decrypt the information held there, so the key required for decryption of the share is stored in a different data deposit:

Deposit 1: SD1, Kn

Deposit 2: SD2, K1

Deposit 3: SD3, K2

Deposit n: SDn, K3.

In addition, the information required to recover the original session encryption key, K5, can be attached to each share. Therefore, in the key management example described here, the original session master key is referenced by dividing the transaction ID into n shares according to the installation content depending on the Parsing Master Key (TID1, TID2, TID3 TIDn ):

Deposit 1: SD1, Kn, TID1

Deposit 2: SD2, K1, TID2

Deposit 3: SD3, K2, TID3

Deposit n: SDn, K3, TIDn.

In the example of the embedded session key described here, the session master key is divided into n shares according to the contents of the installation-dependent Grammar Analysis Master Key (SK1, SK2, SK3, SKn):

Deposit 1: SD1, Kn, SK1

Deposit 2: SD2, K1, SK2

Deposit 3: SD3, K2, SK3

Deposit n: SDn, K3, SKn.

Unless all four shares are recovered, the data cannot be remounted according to this example. Even if the four shares are captured, there is no possibility of reassembling or restoring the original information in access to the session master key and the Parser Master Key.

This example described an embodiment of the method of the present invention and also describes, in another embodiment, the algorithm used for placing shares in deposits, so that shares of all deposits can be combined to form the authentication material of secret. The computations required are very simple and fast. However, with the One Time Pad (OTP) algorithm, there may be circumstances that make this less desirable, such as a large set of data to be made secure, because the key size is the same size as the data to be be stored. Therefore, there would be a need for storage and transmission of twice the amount of original data, which may be less desirable under certain circumstances.

RS1 Flow Cipher

The RS1 flow cipher splitting technique is very similar to the OTP splitting technique described here. Instead of a random value of n bytes, a value n '= random value of min (n, 16) bytes is generated and used for the RS1 Flow Cipher algorithm key. The advantage of the RS1 Flow Cipher algorithm is that a pseudo-random key is generated from a much smaller seed number. The execution speed of RS1 Flow Encryption encryption is also rated at approximately 10 times the speed of triple DES encryption well known in the art, without compromising security. The encryption algorithm

113

RS1 flow is well known in the art, and can be used to generate the keys used in the XOR function. The RS1 Flow Encryption Algorithm is interoperable with other available flow encryption algorithms, such as the RC4® flow encryption algorithm from RSA Security, Inc and is suitable for use in the methods of the present invention.

Using the key notation above, K1 to K5 are now random byte values and it has been established:

SD1 = S1 XOR E (K1)

SD2 = S2 XOR E (K2)

SD3 = S3 XOR E (K3)

SDn = Sn XOR E (Kn) where E (K1) to E (Kn) are the first ri bytes of the RS1 Flow Cipher algorithm switched to K1 to Kn. Shares are now placed in data stores as described here.

In this RS1 flow cipher algorithm, the required computations required are approximately as simple and fast as the OTP algorithm. The benefit in this example using the RS1 Flow Cipher is that the system needs to store and transmit on average only about 16 bytes more than the size of the original data to be made secure by sharing. When the size of the original data is more than 16 bytes, this RS1 algorithm is more efficient than the OTP algorithm, because it is simply shorter. It is readily apparent to those of ordinary skill in the art that a wide variety of encryption methods or algorithms are suitable for use in the present invention, including, but not limited to, RS1, OTP, RC4®, DES Triple and AES.

There are great advantages provided by the data security methods and computer systems of the present invention over traditional encryption methods. One advantage is the security gained from moving data shares to different locations in one or more data warehouses or storage devices, which can be in different logical, physical or geographic locations. When data shares are physically divided and are

114 under the control of different personnel, for example, the possibility of data compromise is greatly reduced.

Another advantage provided by the methods and systems of the present invention is the combination of the steps of the method of the present invention for data security to provide a comprehensive process for maintaining the security of sensitive data. The data is encrypted with a secure key and divided into one or more shares and, in one mode, four shares, according to the secure key. The secure key is securely stored with a reference pointer which is made secure in four shares according to a secure key. The data shares are then individually encrypted and the keys are securely stored with different encrypted shares. When combined, the entire process for securing data according to the methods shown here becomes a comprehensive package for data security.

Data made safe according to the methods of the present invention is readily recoverable and restored, reconstituted, reassembled, decrypted or otherwise returned to its original or other form suitable for use. In order to restore the original data, the following items can be used:

1. All shares or portions of the data set.

2. Knowledge of and ability to reproduce the process flow of the method used to secure the data.

3. Access to the session master key.

4. Access to the Parser Master Key.

Therefore, it may be desirable to plan a secure installation in which at least one of the above elements can be physically separated from the remaining system components (under the control of a different system administrator, for example).

Protection against a rogue application by invoking the application of data security methods can be put in place by using the

115

Parser Master Key. An exchange of mutual authentication code signals between Secure Parser® and the application can be required in this embodiment of the present invention, before any action is taken.

System security dictates that there will be no tailgate method for recreating the original data. For installations where data recovery issues may arise, Secure Parser® can be improved to provide a mirror of the four shares and the session master key deposit. Hardware options, such as RAID (redundant array of cost-effective disks, used to spread information across multiple disks), and software options, such as replication, can also help with data recovery planning. Key Management

In one embodiment of the present invention, the data security method uses three sets of keys for an encryption operation. Each key set can have individual key storage, rescue, security and recovery options, based on the installation. Keys that can be used include, but are not limited to:

1. The Parser Master Key

This key is an individual key associated with the installation of the data analyzer. It is installed on the server on which the parser was employed. There are a variety of options suitable for securing this key, including, but not limited to, a smart card, a separate hardware key store, standardized key stores, custom key stores, or in a secure database table, for example.

2. The Session Master Key

A Session Master Key can be generated each time the data is made secure. The Session Master Key is used for data encryption before the parsing operation. It can also be incorporated (if the Session Master Key is not integrated into the parsed data) as a means of parsing

116 encrypted data. The Session Master Key can be made secure in a variety of ways, including, but not limited to, a standardized key store, a custom key store, a separate database table or made secure on encrypted shares, for example.

3. The Sharing Encryption Keys

For each share or portions of a data set that is created, an individual Share Encryption Key can be generated to further encrypt the shares. Share Encryption Keys can be stored on shares other than those where the share was encrypted.

It is readily apparent to those of ordinary skill in the art that the data security methods and the computer system of the present invention are widely applicable to any type of data in any setting or environment. In addition to applications conducted over the Internet or between consumers and vendors, the data security methods and computer systems of the present invention are highly applicable to non-commercial or private scenarios or environments. Any data set that is intended to be kept safe from an unauthorized user can be made safe using the methods and systems described here. For example, access to a particular database in a company or organization can be advantageously restricted to only users selected by using the methods and systems of the present invention for data security. Another example is the generation, modification or access to documents where you want to restrict access or prevent unauthorized or accidental access or exposure outside a group of selected individuals, computers or workstations. These and other examples of the ways in which the methods and data security systems of the present invention are applicable to any non-commercial or commercial environment or scenario for any scenario, including, but not limited to, any organization, government agency or body117.

In another embodiment of the present invention, the data security method uses three sets of keys for an encryption operation. Each key set can have individual key storage, rescue, security and recovery options, based on the installation. Keys that can be used include, but are not limited to:

1. The Parser Master Key

2. The Session Master Key

A Session Master Key can be generated each time the data is made secure. The Session Master Key is used in conjunction with the Grammar Analysis master key to derive an Intermediate Key. The Session Master Key can also be made secure in a variety of ways, including, but not limited to, a standardized key store, a custom key store, a separate database table, or made secure on encrypted shares, for example .

3. The Intermediate Key

An Intermediate Key can be generated each time the data is made secure. The Intermediate Key is used for data encryption before the parsing operation. It can also be incorporated as a means of grammatical analysis of encrypted data.

4. The Sharing Encryption Keys

Workgroup, Project, Individual or Cross-Platform PC / Laptop Data Security

The data security methods and computer systems of the present invention are also useful in securing data by workgroup, project, individual PC / laptop and any other platform that is in use, for example, in businesses, offices, government agencies or any scenario in which sensitive data is created, manipulated or stored. The present invention provides computer methods and systems for data security that are known to be sought by organizations, such as the American Government, for implementation across the entire governmental organization or between governments at a state or federal level.

The data security computer systems and methods and computer systems of the present invention provide the ability not only to analyze flat files, but also data fields, sets or a table of any kind. In addition, all forms of data are able to be made secure under this process, including, but not limited to, text, video, images, biometrics and voice data. The scalability, speed and data production of the data security methods of the present invention are limited only by the hardware that the user has at his disposal.

In one embodiment of the present invention, data security methods are used as described below in a workgroup environment. In one embodiment, as shown in FIGURE 23 and described below, the Workgroup Scale data security method of the present invention uses the Trust Agent's private key management functionality to store user / group relationships and keys associated private keys (Parser Group Master Keys) required for a group of users to share secure data. The method of the present invention has the ability to secure data for a company, a workgroup or an individual user, depending on how the Parser Master Key was employed.

In one embodiment, additional key management and user / group management programs can be provided, allowing for a large-scale workgroup implementation with a Cynical point of key management and administration. Key generation, management and revocation are handled by the unique maintenance program, all of which becomes especially important according to the number

120 of users increases. In another embodiment, key management can also be established through one or more different system administrators, who cannot allow any person or group to control data as needed. This allows secure data management to be achieved by roles, responsibilities, membership, rights, etc., as defined by an organization, and access to secure data can be limited to only those who are allowed or required to have access only to portion they are working on, while others, such as managers or executives, may have access to all secure data. This modality allows the sharing of secure data between different groups in a company or organization, while, at the same time, only certain individuals, such as those with authorized and predetermined roles and responsibilities, are allowed to observe the data as a whole. In addition, this embodiment of the methods and systems of the present invention also allows for the sharing of data between, for example, separate companies, or separate departments or divisions of companies, or any separate organization departments, groups, agencies or offices, or the like, of any government or organization or any kind, where some sharing is required, but not everyone can afford access to all data. Particularly evident examples of the need and usefulness of a method and system of the present invention like these are to allow sharing, but to maintain security, between government areas, agencies and offices, as well as between different divisions, departments or offices of a large company or any other company. another organization, for example.

An example of the applicability of the methods of the present invention on a smaller scale is as follows. A Grammar Analyzer Master Key is used as a serialization or Grammar Analyzer tag for an organization. As the scale of use of the Parser Master Key is reduced from the entire company to a smaller workgroup, the data security methods described here are used for file sharing among user groups.

121

In the example shown in FIGURE 25 and described below, there are six users defined along with the title or role in the organization. The sidebar represents five possible groups that users can belong to according to their role. The arrow represents an association by the user in one or more of the groups.

When configuring SecureParser for use in this example, the system administrator accesses user and group information from the operating system through a maintenance program. This maintenance program generates and assigns Grammar Analyzer Group Master Keys to users based on their group membership.

In this example, there are three members in the Senior Team group. For this group, the actions would be:

1. Access the Parser Group Master Key for the Senior Team group (generate a key if not available):

2. Generate a digital certificate of association between the CEO and the Senior Team group;

3. Generate a digital certificate associating the CFO with the Senior Team group;

4. Generate a digital certificate associating the Vice President, Marketing with the Senior Team group.

The same set of actions would be done for each group, and each member in each group. When the maintenance program is completed, the Parser Group Master Key becomes a shared credential for each group member. The revocation of the assigned digital certificate can be done automatically when a user is removed from a group through the maintenance program, without affecting the remaining members of the group.

Once the shared credentials have been defined, the Parser process remains the same. When a file, document or data element is to be made secure, the user is alerted to the target group to be used when securing the data. The resulting secure data is only accessible by others

122 members of the target group. This functionality of the methods and systems of the present invention can be used with any other computer system or software platform, any of which can, for example, be integrated into existing application programs or used independently for file security.

It is readily apparent to those of ordinary skill in the art that any one or a combination of algorithms is suitable for use in the methods and systems of the present invention. For example, the encryption steps can be repeated, in one embodiment, to produce a multilayer encryption scheme. In addition, a different encryption algorithm, or a combination of encryption algorithms can be used in repeated encryption steps, so that different encryption algorithms are applied to the different layers of the multilayer encryption scheme. Thus, the encryption scheme itself can become a component of the methods of the present invention for the security of sensitive data from unauthorized use or access.

In addition, other combinations, admissions, substitutions and modifications will be evident to the skilled technician, in view of the description here. Accordingly, the present invention is not to be limited by the reaction of the preferred embodiments, but is to be defined by reference to the appended claims.

Contents2

91 members in 8 offices

This recordMember, by publication datePriority claim

Priority claims2

Priority claims
Document	Office	Kind	Date
45892803	United States of America	A	2003-06-11
2004018426	United States of America	W	2004-06-10

Members91

Family members, oldest first
Document	Office	Kind
WO0122201A1	World Intellectual Property Organization (WIPO)	A1	2001-03-29
WO0122201A1	World Intellectual Property Organization (WIPO)	A1	2001-03-29
WO0122319A1	World Intellectual Property Organization (WIPO)	A1	2001-03-29
WO0122319A1	World Intellectual Property Organization (WIPO)	A1	2001-03-29
WO0122322A2	World Intellectual Property Organization (WIPO)	A2	2001-03-29
WO0122322A2	World Intellectual Property Organization (WIPO)	A2	2001-03-29
WO0122650A2	World Intellectual Property Organization (WIPO)	A2	2001-03-29
WO0122650A2	World Intellectual Property Organization (WIPO)	A2	2001-03-29
WO0122651A2	World Intellectual Property Organization (WIPO)	A2	2001-03-29
WO0122651A2	World Intellectual Property Organization (WIPO)	A2	2001-03-29
AU7596200A	Australia	A	2001-04-24
AU7596200A	Australia	A	2001-04-24
AU7596300A	Australia	A	2001-04-24
AU7596300A	Australia	A	2001-04-24
AU7705200A	Australia	A	2001-04-24
AU7705200A	Australia	A	2001-04-24
AU7705300A	Australia	A	2001-04-24
AU7705300A	Australia	A	2001-04-24
AU7830000A	Australia	A	2001-04-24
AU7830000A	Australia	A	2001-04-24
WO0122322A3	World Intellectual Property Organization (WIPO)	A3	2001-10-11
WO0122322A3	World Intellectual Property Organization (WIPO)	A3	2001-10-11
WO0122651A3	World Intellectual Property Organization (WIPO)	A3	2001-12-27
WO0122651A3	World Intellectual Property Organization (WIPO)	A3	2001-12-27
WO0122650A3	World Intellectual Property Organization (WIPO)	A3	2002-01-10
WO0122650A3	World Intellectual Property Organization (WIPO)	A3	2002-01-10
EP1218813A1	European Patent Office (EPO)	A1	2002-07-03
EP1218841A2	European Patent Office (EPO)	A2	2002-07-03
EP1218842A1	European Patent Office (EPO)	A1	2002-07-03
EP1218860A2	European Patent Office (EPO)	A2	2002-07-03
WO0122650A9	World Intellectual Property Organization (WIPO)	A9	2002-10-03
WO0122650A9	World Intellectual Property Organization (WIPO)	A9	2002-10-03
US2004049687A1	United States of America	A1	2004-03-11
AU2004248616A1	Australia	A1	2004-12-23
CA2529042A1	Canada	A1	2004-12-23
WO2004111791A2	World Intellectual Property Organization (WIPO)	A2	2004-12-23
US6853988B1	United States of America	B1	2005-02-08
WO2004111791A3	World Intellectual Property Organization (WIPO)	A3	2005-04-28
US2005102244A1	United States of America	A1	2005-05-12
EP1639743A2	European Patent Office (EPO)	A2	2006-03-29
BRPI0411332AThis record	Brazil	A	2006-07-25
CN1833398A	China	A	2006-09-13
US7187771B1	United States of America	B1	2007-03-06
US7260724B1	United States of America	B1	2007-08-21
US2008034209A1	United States of America	A1	2008-02-07
US7391865B2	United States of America	B2	2008-06-24
US2008244277A1	United States of America	A1	2008-10-02
AU2004248616B2	Australia	B2	2009-04-09
AU2009201911A1	Australia	A1	2009-06-04
EP1639743A4	European Patent Office (EPO)	A4	2009-06-24
US7577621B2	United States of America	B2	2009-08-18
US2010104101A1	United States of America	A1	2010-04-29
US7802104B2	United States of America	B2	2010-09-21
US2011004933A1	United States of America	A1	2011-01-06
US2011179271A1	United States of America	A1	2011-07-21
US2011179287A1	United States of America	A1	2011-07-21
AU2009201911B2	Australia	B2	2012-05-03
CN1833398B	China	B	2012-05-30
US8214650B2	United States of America	B2	2012-07-03
AU2012203561A1	Australia	A1	2012-07-05
US2012179910A1	United States of America	A1	2012-07-12
CN102664728A	China	A	2012-09-12
US8332638B2	United States of America	B2	2012-12-11
US2013067234A1	United States of America	A1	2013-03-14
EP2602953A1	European Patent Office (EPO)	A1	2013-06-12
EP2602954A1	European Patent Office (EPO)	A1	2013-06-12
EP2605446A1	European Patent Office (EPO)	A1	2013-06-19
US8494969B2	United States of America	B2	2013-07-23
US2013212405A1	United States of America	A1	2013-08-15
US8726033B2	United States of America	B2	2014-05-13
US2014317414A1	United States of America	A1	2014-10-23
US2014372756A1	United States of America	A1	2014-12-18
CN102664728B	China	B	2015-04-29
AU2012203561B2	Australia	B2	2015-08-20
AU2015227516A1	Australia	A1	2015-10-08
US2015286830A1	United States of America	A1	2015-10-08
CN105005719A	China	A	2015-10-28
US9189777B1	United States of America	B1	2015-11-17
AU2015227516B2	Australia	B2	2015-12-17
US9298937B2	United States of America	B2	2016-03-29
US9300649B2	United States of America	B2	2016-03-29
US2016149873A1	United States of America	A1	2016-05-26
US2016255069A1	United States of America	A1	2016-09-01
US9449180B2	United States of America	B2	2016-09-20
HK1217369A	Hong Kong, China	A	2017-01-06
HK1217369A1	Hong Kong, China	A1	2017-01-06
US9613220B2	United States of America	B2	2017-04-04
US2019026479A1	United States of America	A1	2019-01-24
US2019026480A1	United States of America	A1	2019-01-24
US2019042776A1	United States of America	A1	2019-02-07
US11100240B2	United States of America	B2	2021-08-24

4 legal events, as the office reported them to INPADOC

Over the term

Point at a mark for the event

Events

Legal events, newest first
	Event	Code
2018-05-29	Patent application refused [chapter 9.2 patent gazette]B09B	B09B
2018-05-29	Patent application refused [chapter 9.2 patent gazette]MANTIDO O INDEFERIMENTO UMA VEZ QUE NAO FOI APRESENTADO RECURSO DENTRO DO PRAZO LEGALB09B	B09B
2018-03-13	Patent application refused [chapter 9.2 patent gazette]B09B	B09B
2017-11-21	Application suspended after technical examination (opinion) [chapter 7.1 patent gazette]B07A	B07A

Secure data parser method and system

Abstract

Term

END

END;

Priority claims2

Members91

Over the term

Events

Numbers

Titles2

Classification