HK1187168B - Systems and methods for securing data using multi-factor or keyed dispersal - Google Patents

Description

System and method for protecting data using multi-factor or keyed dispersal

The present application is a divisional application of the invention patent application No.200980104729.0(PCT/US2009/000083) entitled "system and method for protecting data using multi-factor or key type scattering", which has an international filing date of 2009, 1, 7.

Technical Field

The present invention relates generally to improved systems and methods for protecting data. Some of the systems and methods described herein utilize a keyed information dispersal algorithm (referred to as keyed IDA) and a multi-factor secret sharing technique. The systems and methods described herein may be used in conjunction with other systems and methods described in commonly-owned U.S. patent No.7391865, and commonly-owned U.S. patent application No.10/458928, U.S. patent application No.11/258839, filed on day 11/25 in 2005, U.S. patent application No.11/602667, filed on day 11/20 in 2006, U.S. patent application No.11/983355, filed on day 7 in 2007, U.S. patent application No.11/999575, filed on day 5 in 12 in 2007, and U.S. patent application No.12/209703, filed on day 9/12 in 2008, all of which are incorporated herein by reference in their entirety.

Background

In today's society, individuals and businesses are conducting more and more activities through computer systems. These computer systems include proprietary and non-proprietary computer networks, and often store, archive, and transmit all types of sensitive information. Accordingly, there is an increasing need to ensure that data stored and transmitted by these systems is not read or otherwise compromised.

One common solution to protect computer systems is to provide login and password functionality. However, password administration has proven to be extremely costly since most helpdesk calls are associated with password issues. Furthermore, passwords provide minimal security since they are typically stored in files that are susceptible to improper access, for example, through brute force attacks.

Another solution to protect computer systems is to provide a cryptographic infrastructure. Cryptography generally refers to the protection of data by transforming or encrypting the data into an unreadable format. Only those who possess the encryption key can decrypt the data into a usable format. Cryptography is used to identify a user, such as authentication to allow access privileges, authorization to establish digital certificates and signatures, and the like. One popular cryptographic system is a public key system that uses two keys, a public key known to anyone and a private key known only to its individual or business owner. In general, data encrypted with one key is decrypted with another key, and the other key cannot be reconstructed from either key.

Unfortunately, even the typical public key cryptosystems described above are highly user-dependent for security. For example, the cryptographic system issues the private key to the user, e.g., through the user's browser. Inexperienced users then typically store the private key on a hard disk that others can access through an open computer system (e.g., the internet). On the other hand, a user may select a poor name (e.g., "key") for a file that contains their private key. The result of the above and other actions is to make the key or keys vulnerable.

In addition to the hazards described above, a user may 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, at best through simple login and password access. As mentioned above, login and password access often do not provide sufficient security.

One solution to improve the security of the above cryptographic systems is to include biometrics as part of the authentication or authorization. Biometrics typically include measurable physical characteristics such as a fingerprint or voice that can be examined by an automated system (e.g., pattern matching or recognition of fingerprint patterns or voice patterns). In these systems, the user's biometrics and/or keys may be stored on a mobile computing device (e.g., a smart card, laptop, personal digital assistant, or mobile phone), allowing the biometrics or keys to be used in a mobile environment.

The above-described mobile biometric cryptosystems still have various disadvantages. For example, a mobile user may lose or damage a smart card or portable computing device, thereby completely shutting off his or her access to potentially important data. Alternatively, a malicious person may steal the mobile user's smart card or portable computing device and use it to effectively steal the mobile user's digital proof. On the other hand, portable computing devices may be connected to an open system (e.g., the internet) and, like passwords, storing biometric files may be vulnerable to compromise due to user inadvertence for security or malicious intruders.

Disclosure of Invention

Based on the foregoing, there is a need to provide a cryptographic system that is secure from the user while also supporting mobile users.

Accordingly, one aspect of the present invention provides a method of protecting substantially any type of data from unauthorized access or use. The method includes one or more steps of parsing, splitting and/or separating the data to be protected into two or more portions. The method also includes encrypting the data to be protected. Encryption of the data may be performed before or after the data is first parsed, split, and/or separated. Further, the encryption step may be repeated for one or more portions of the data. Similarly, the parsing, splitting, and/or separating steps may be repeated for one or more data portions. Optionally, the method further comprises storing the parsed, split and/or separated data that has been encrypted in one or more locations. Optionally, the method further comprises reconstructing or repacking the protected data into its original form for authorized access or use. This method may be incorporated into the operation of any computer, server, engine, etc., capable of performing the desired steps of the method.

Another aspect of the invention provides a system that protects substantially any type of data from unauthorized access or use. The system includes a data splitting module, a cryptographic processing module, and optionally a data assembling module. In one embodiment, the system may also include one or more data storage facilities that may store secure data.

Accordingly, one aspect of the present invention provides a secure server or trust engine having a server-centric key or in other words storing a cryptographic key and user authentication data on the server. According to this embodiment, the user accesses a trust engine to perform authentication and cryptographic functions such as, but not limited to: authentication, authorization, digital signature and generation of certificates, storage and retrieval, encryption, notarization and delegation activities, and the like.

Another aspect of the invention provides a reliable or trusted authentication process. Further, upon a trustworthy positive authentication, many different actions may be taken, from providing cryptographic techniques, to system or device authorization and access, to allowing the use or control of one or a large number of electronic devices.

Another aspect of the present invention is to provide cryptographic keys and authentication data in an environment where they are not lost, stolen, or compromised, thereby advantageously avoiding the need to continually reissue and manage new keys and authentication data. In accordance with another aspect of the invention, the trust engine allows a user to use one key pair for multiple activities, vendors, and/or authentication requests. According to another aspect of the invention, the trust engine performs at least one step in cryptographic processing (such as, but not limited to, encryption, authentication, or signing on the server side), thereby allowing a client or user to possess only minimal computing resources.

According to another aspect of the invention, the trust engine includes one or more storages (repositories) for storing each cryptographic key and part of the authentication data. These portions are created by a data splitting process such that reconstruction cannot be performed without predetermined portions from more than one location in one store or from multiple stores. According to another embodiment, multiple stores may be geographically remote such that a rogue employee or compromised system of one store does not provide access to the user's keys or authentication data.

According to another embodiment, the authentication process advantageously allows the trust engine to process multiple authentication activities in parallel. According to another embodiment, the trust engine may advantageously track failed access attempts and thereby limit the number of times a malicious intruder may attempt to breach the system.

According to another embodiment, a trust engine may include multiple instances, where each trust engine may predict and share processing load with other trust engines. According to another embodiment, the trust engine may include a redundancy module to poll multiple authentication results to ensure that more than one system authenticates a user.

Accordingly, one aspect of the present invention includes a remotely accessible secure cryptographic system for storing any type of data, including, but not limited to, a plurality of private cryptographic keys associated with a plurality of users. The cryptographic system associates each of the plurality of users with one or more different ones of the plurality of private cryptographic keys and performs cryptographic functions for each user using the associated one or more different keys without issuing the plurality of private cryptographic keys to the user. The cryptographic system includes a storage system having at least one server that stores data to be protected, such as a plurality of private cryptographic keys and a plurality of enrollment authentication data. Each enrollment authentication data identifies one of a plurality of users, and each of the plurality of users is associated with one or more different ones of the plurality of private cryptographic keys. The cryptographic system may further comprise an authentication engine for comparing authentication data received by one of the plurality of users with enrollment authentication data corresponding to the one of the plurality of users and received from the depository system, thereby generating an authentication result. The cryptographic system may further comprise a cryptographic engine that performs a cryptographic function on behalf of the one of the plurality of users using the associated one or more different keys received from the storage system when the authentication result indicates correct identification of the one of the plurality of users. The cryptographic system may also include a transaction engine connected to route data from a plurality of users to the repository server system, the authentication engine, and the cryptographic engine.

Another aspect of the invention includes a secure cryptographic system, optionally remotely accessible. The cryptographic system includes a storage system having at least one server that stores at least one private key and any other data (such as, but not limited to, a plurality of enrollment authentication data), where each enrollment authentication data identifies one of a possible plurality of users. Optionally, the cryptographic system may further comprise an authentication engine that compares authentication data received by the user with enrollment authentication data corresponding to the user and received from the repository system, thereby generating an authentication result. The cryptographic system further comprises a cryptographic engine that performs cryptographic functions on behalf of the user using at least the private key receivable from the storage system when the authentication result indicates correct identification of the user. Optionally, the cryptographic system may further include a transaction engine connected to transfer data from the user to other engines or systems (such as, but not limited to, a storage server system, an authentication engine, and a cryptographic engine).

Another aspect of the invention includes a method of facilitating execution of a cryptographic function. The method includes associating one of the plurality of users with one or more of a plurality of private cryptographic keys stored at a secure location (e.g., a secure server). The method also includes receiving authentication data from the user and comparing the authentication data to authentication data corresponding to the user to verify the identity of the user. The method also includes performing a cryptographic function using the one or more keys without issuing the one or more keys to a user.

Another aspect of the invention includes an authentication system for uniquely identifying a user through secure storage of the user's enrollment authentication data. The authentication system includes one or more data storage facilities, wherein each data storage facility includes a computer accessible storage medium storing at least a portion of enrollment authentication data. The authentication system also includes an authentication engine in communication with the one or more data storage facilities. The authentication engine includes a data splitting module that operates on enrollment authentication data to create a plurality of portions, a data assembly module that processes the portions from the at least one data storage facility to assemble enrollment authentication data, and a data comparison module that receives current authentication data from a user and compares the current authentication data to the assembled enrollment authentication data to determine whether the user is uniquely identified.

Another aspect of the invention includes a cryptographic system. The cryptographic system includes one or more data storage facilities, wherein each data storage facility includes a computer accessible storage medium storing at least a portion of one or more cryptographic keys. The cryptographic system also includes a cryptographic engine in communication with the data storage facility. The cryptographic engine also includes a data splitting module that operates on the cryptographic key to establish a plurality of portions, a data assembling module that processes the portions from the data at least one storage facility to assemble the cryptographic key, and a cryptographic processing module that receives the assembled cryptographic key and performs a cryptographic function therewith.

Another aspect of the present invention includes a method of storing any type of data, including but not limited to authentication data, in a geographically remote, secure data storage facility, thereby protecting the data from the composition of any individual data storage facility. The method includes receiving data at a trust engine, combining the data with a first base random value at the trust engine to form a first combined value, and combining the data with a second base random value to form a second combined value. The method includes establishing a first pairing of the first substantially random value and the second combined value, establishing a second pairing of the first substantially random value and the second substantially random value, and storing the first pairing in the first secure data storage facility. The method includes 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 any type of data, including but not limited to authentication data, the method including receiving data, combining the data with a first set of bits to form 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 includes establishing a first pairing of the first set of bits and the third set of bits. The method also includes establishing a second pairing of the first set of bits and the fourth set of bits, and storing one of the first and second pairings in a first computer-accessible storage medium. The method also includes storing the other of the first and second pairs in a second computer accessible storage medium.

Another aspect of the invention includes a method of storing encrypted data in a geographically remote, secure data storage facility, thereby protecting the encrypted data from composition by any individual data storage facility. The method includes receiving, at a trust engine, encrypted data, combining, at the trust engine, the encrypted data with a first base random value to form a first combined value, and combining, at the trust engine, the encrypted data with a second base random value to form a second combined value. The method also includes establishing a first pairing of the first substantially random value and the second combined value, establishing a second pairing of the first substantially random value and the second substantially random value, and storing the first pairing in the first secure data storage facility. The method also includes 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 encrypted data that includes receiving authentication data and combining the encrypted data with a first set of bits to form a second set of bits. The method also includes combining the encrypted data with the third set of bits to form a fourth set of bits, establishing a first pairing of the first set of bits with the third set of bits, and establishing a second pairing of the first set of bits with the fourth set of bits. The method also includes 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 present invention includes a method of processing sensitive data of any type or form within a cryptographic system, wherein the sensitive data is present in a useable form only during an action performed by an authorized user with the sensitive data. The method further includes receiving in the software module substantially randomized or encrypted sensitive data from a first computer accessible storage medium, and receiving in the software module substantially randomized or encrypted data, which may or may not be sensitive data, from one or more other computer accessible storage media. The method also includes processing the substantially randomized pre-encrypted sensitive data and the substantially randomized or encrypted data, which may or may not be sensitive data, in a software module to assemble the sensitive data and performing an action with the sensitive data in a software engine. The action includes, but is not limited to, one of authenticating a user and performing a password function.

Another aspect of the invention includes a secure authentication system. The secure authentication system includes a plurality of authentication engines. Each authentication engine receives enrollment authentication data designed to uniquely identify a user with a certain degree of certainty. Each authentication engine receives current authentication data for comparison with enrollment authentication data, and each authentication engine determines an authentication result. The secure authentication system also includes a redundant system that receives the authentication results of the at least two authentication engines and determines whether the user is uniquely identified.

Another aspect of the invention comprises a secure data in a sports system by means of which data can be transmitted in different parts protected according to the invention, so that any one part that is compromised does not provide enough data for recovering the original data. This may apply to any data transmission, whether it is wired, wireless or physical.

Another aspect of the present invention includes integrating the secure data parser of the present invention into any suitable system that stores or communicates data. For example, an email system, a RAID system, a video broadcast system, a database system, or any other suitable system may have a secure data parser integrated at any suitable level.

Another aspect of the invention includes generating the multiple share data using any suitable parsing and splitting algorithm. For parsing and splitting data, randomness, pseudo-randomness, determinism, or any combination thereof may be employed.

Drawings

The present invention will be described in more detail hereinafter with reference to the accompanying drawings, which are meant to illustrate and not to limit the invention, and in which:

FIG. 1 shows a block diagram of a cryptographic system in accordance with aspects of an embodiment of the invention;

FIG. 2 illustrates a block diagram of the trust engine of FIG. 1 in accordance with aspects of an embodiment of the present invention;

FIG. 3 illustrates a block diagram of the transaction engine of FIG. 2 in accordance with aspects of an embodiment of the invention;

FIG. 4 illustrates a block diagram of the storage of FIG. 2 in accordance with aspects of an embodiment of the invention;

FIG. 5 illustrates a block diagram of the authentication engine of FIG. 2 in accordance with aspects of an embodiment of the invention;

FIG. 6 illustrates a block diagram of the cryptographic engine of FIG. 2, in accordance with aspects of an embodiment of the present invention;

FIG. 7 shows a block diagram of a storage system in accordance with aspects of another embodiment of the invention;

FIG. 8 shows a flow diagram of a data splitting process in accordance with aspects of an embodiment of the invention;

FIG. 9A illustrates a data flow of a registration process in accordance with aspects of an embodiment of the invention;

FIG. 9B illustrates a flow diagram of an interoperability process according to aspects of an embodiment of the invention;

FIG. 10 illustrates a data flow of an authentication process in accordance with aspects of an embodiment of the invention;

FIG. 11 illustrates a data flow of a signing process in accordance with aspects of an embodiment of the present invention;

FIG. 12 shows a data flow of an encryption/decryption process in accordance with aspects of another embodiment of the invention;

FIG. 13 shows a simplified block diagram of a trust engine system in accordance with aspects of another embodiment of the present invention;

FIG. 14 shows a simplified block diagram of a trust engine system in accordance with aspects of another embodiment of the present invention;

FIG. 15 shows a block diagram of the redundancy module of FIG. 14, in accordance with aspects of an embodiment of the present invention;

FIG. 16 illustrates a process of evaluating authentication in accordance with an aspect of the subject invention;

FIG. 17 illustrates a process for assigning values to an authentication in accordance with an aspect of the present invention as illustrated in FIG. 16;

FIG. 18 illustrates a process for performing trust arbitration in one aspect of the present invention as illustrated in FIG. 17; and

FIG. 19 illustrates a sample transaction between a user and a seller, where an initial web-based contract results in a sales contract signed by both parties, in accordance with aspects of an embodiment of the invention.

FIG. 20 illustrates a sample user system with a cryptographic service provider module that provides security functions to the user system.

FIG. 21 illustrates a process of parsing, splitting, and/or separating data in the case of encryption and the storage of an encryption master key with the data.

FIG. 22 illustrates a process of parsing, splitting, and/or separating data in the case of encryption and the encryption master key being stored separately from the data.

FIG. 23 illustrates an intermediate key process of parsing, splitting, and/or separating data in the case of encryption and the storage of an encrypted master key with the data.

FIG. 24 illustrates an intermediate key process of parsing, splitting, and/or separating data in the case of encryption and the encryption master key being stored separately from the data.

FIG. 25 illustrates the utilization of the cryptographic method and system of the present invention by a small workgroup.

FIG. 26 is a block diagram of an exemplary physical token security system employing a secure data parser in accordance with an embodiment of the present invention.

FIG. 27 is a block diagram of an exemplary arrangement for integrating a secure data parser into a system in accordance with one embodiment of the present invention.

FIG. 28 is a block diagram of an exemplary mobile data system according to one embodiment of the invention.

Fig. 29 is a block diagram of another exemplary in-motion data system in accordance with an embodiment of the present invention.

FIGS. 30-32 are block diagrams of illustrative systems incorporating a secure data parser in accordance with an embodiment of the invention.

FIG. 33 is a process flow diagram of an illustrative process for parsing and splitting data in accordance with an embodiment of the invention.

FIG. 34 is a process flow diagram of an illustrative process for restoring a data portion to the original data in accordance with an embodiment of the invention.

FIG. 35 is a process flow diagram of an illustrative process for splitting data at the bit level in accordance with an embodiment of the invention.

Fig. 36 is a process flow diagram of illustrative steps and features that may be used in any suitable combination (with any suitable additions, deletions, or modifications) in accordance with an embodiment of the invention.

Fig. 37 is a process flow diagram of illustrative steps and features that may be used in any suitable combination (with any suitable additions, deletions, or modifications) in accordance with an embodiment of the invention.

FIG. 38 is a simplified block diagram of storage keys and data components within shares that may be used in any suitable combination (with any suitable additions, deletions, or modifications) according to an embodiment of the invention.

FIG. 39 is a simplified block diagram of storage keys and data components within shares using workgroup keys that may be used in any suitable combination (with any suitable additions, deletions, or modifications) in accordance with an embodiment of the present invention.

Fig. 40A and 40B are simplified and illustrative process flow diagrams for header generation and data splitting for moving data that may be used in any suitable combination (with any suitable additions, deletions, or modifications) according to one embodiment of the invention.

Fig. 41 is a simplified block diagram of an exemplary portion format that may be used in any suitable combination (with any suitable additions, deletions, or modifications) according to an embodiment of the invention.

Detailed Description

One aspect of the present invention is to provide a cryptographic system in which one or more secure servers or trust engines store cryptographic keys and user authentication data. Users access the functionality of traditional cryptographic systems through network access to a trust engine, however, the trust engine does not issue the actual keys and other authentication data, and thus these keys and data remain secure. Such server-centric storage of keys and authentication data provides user-independent security, portability, availability, and immediacy.

Because users can trust or trust the cryptographic system to perform user and document authentication, as well as other cryptographic functions, a wide variety of functions may be included within the system. For example, a trust engine provider may ensure that protocol repudiation does not occur by, for example, authenticating participants to the protocol, digitally signing the protocol on behalf of or for the participants, and storing a record of the protocol digitally signed by each participant. Further, the cryptographic system may monitor the agreement and determine to apply varying degrees of authentication, e.g., based on price, user, vendor, geographic location, place of use, etc.

To facilitate a complete understanding of the present invention, the remainder of the detailed description describes the invention with reference to the accompanying drawings, wherein like elements are referred to by like numerals throughout.

Fig. 1 shows a block diagram of a cryptographic system 100 in accordance with aspects of an embodiment of the invention. As shown in fig. 1, the cryptographic system 100 includes a user system 105, a trust engine 110, a certificate authority 115, and a vendor system 120 that communicate over a communication link 125.

According to one embodiment of the invention, the user system 105 comprises a conventional general purpose computer having one or more microprocessors (e.g., Intel-based processors). In addition, the user system 105 includes a suitable operating system, such as one capable of including graphics or Windows (e.g., Windows, Unix, Linux, etc.). As shown in fig. 1, the user system 105 may include a biometric device 107. The biometric device 107 may advantageously acquire a user's biometric and communicate the acquired biometric to the trust engine 110. According to one embodiment of the invention, the biometric device may advantageously comprise a device having similar properties and characteristics as disclosed in the following documents: U.S. patent application No.08/926277 entitled "RELIEFOBJECT IMAGE GENERATOR" filed on 5.9.1997, U.S. patent application No.09/558634 entitled "IMAGING DEVICE FOR A RELIEF OBJECT AND SYSTEM AND METHOD OF USE THE IMAGEDEVICE" filed on 26.4.26.5.1999, U.S. patent application No.09/435011 entitled "RELIEF OBJECTOR ADAPTOR" filed on 5.11.1999, and U.S. patent application No.09/477934 entitled "PLANAR IMAGE SENSOR AND SYSTEM FOR GENERATING AN ELECTRONIC IMAGE OF ARIEF GENE OBCT FOR FINGERPINT READING" filed on 5.1.2000, all OF which are owned by the present assignee and are incorporated herein by reference.

Further, the subscriber system 105 may be connected to the communication link 125 through a conventional service provider (e.g., dial-up, Digital Subscriber Line (DSL), cable modem, fiber connection, etc.). According to another embodiment, the user system 105 is connected to the communication link 125 through network connectivity (e.g., a local area network or a wide area network). According to one embodiment, the operating system includes a TCP/IP stack that handles all incoming and outgoing message traffic passing over the communication link 125.

Although the user system 105 is disclosed with reference to the above embodiments, the present invention is not limited thereto. Rather, the skilled artisan will recognize from the disclosure herein a wide variety of alternative embodiments of the user system 105, including virtually any computing device capable of sending or receiving information from another computer system. For example, the user system 105 may include, but is not limited to, a computer workstation, an interactive television, an interactive kiosk, a personal mobile computing device (e.g., digital assistant, mobile phone, laptop, etc.), a wireless communication device, a smart card, an embedded computing device, etc., capable of interacting with the communication link 125. In these alternative systems, the operating systems are likely to be different and modified for a particular device. However, according to one embodiment, the operating system advantageously continues to provide the appropriate communication protocols needed to establish communication with the communication link 125.

Fig. 1 shows a trust engine 110. According to one embodiment, the trust engine 110 includes one or more secure servers for accessing and storing sensitive information, which may be any type or form of data such as, but not limited to, text, audio, video, user authentication data, and public and private cryptographic keys. According to one embodiment, the authentication data includes data designed to uniquely identify the user of the cryptographic system 100. For example, the authentication data may include a user identification number, one or more biometrics, and a series of questions and answers generated by the trust engine 110 or user but initially answered by the user at enrollment. The questions may include demographic data (e.g., birth place, address, anniversary, etc.), personal data (e.g., mother's maiden name, favorite ice cream, etc.), or other data designed to uniquely identify the user. The trust engine 110 compares the authentication data of the user associated with the current transaction with previously (e.g., at the time of enrollment) set authentication data. The trust engine 110 may advantageously require the user to generate authentication data each time a transaction occurs, or the trust engine 110 may advantageously allow the user to generate authentication data periodically (e.g., at the beginning of a string of transactions or upon logging into a particular vendor's website).

According to an embodiment where the user generates biometric data, the user provides physical characteristics to the biometric device 107, such as, but not limited to, a facial scan, a hand scan, an ear scan, an iris scan, a retinal scan, a blood vessel pattern, DNA, a fingerprint, handwriting, or speech. The biometric device advantageously generates an electronic pattern or biometric of the physical characteristic. The electronic pattern is transmitted to the trust engine 110 through the user system 105 for enrollment or authentication.

Once the user has generated the appropriate authentication data and the trust engine 110 determines an explicit match between this authentication data (current authentication data) and the authentication data set at enrollment (enrollment authentication data), the trust engine 110 provides the user with a full cryptographic function. For example, a properly authenticated user may advantageously employ the trust engine 110 to perform hashing, digital signing, encryption and decryption (often collectively referred to as encryption), building or distributing digital certificates, and the like. However, the private cryptographic key used in the cryptographic function will not be available outside of the trust engine 110, thereby ensuring the integrity of the cryptographic key.

According to one embodiment, the trust engine 110 generates and stores cryptographic keys. According to another embodiment, at least one cryptographic key is associated with each user. Further, when the cryptographic keys comprise public key technology, each private key associated with a user is generated within, but not issued from, the trust engine 110. Thus, as long as the user has access to the trust engine 110, the user may perform cryptographic functions using his or her private or public key. Advantageously, such remote access allows the user to remain fully mobile and access the password functionality through virtually any internet connection (e.g., cellular and satellite phones, kiosks, laptops, hotel rooms, etc.).

According to another embodiment, the trust engine 110 performs cryptographic functions using a key pair generated for the trust engine 110. According to this embodiment, the trust engine 110 first authenticates the user and, after the user has correctly generated authentication data that matches the enrollment authentication data, the trust engine 110 performs a cryptographic function on behalf of the authenticated user using its own cryptographic key pair.

The skilled artisan will recognize from the disclosure herein that the cryptographic keys may advantageously comprise all or some of a symmetric key, a public key, and a private key. Furthermore, the skilled artisan will recognize from the disclosure herein that a wide variety of algorithms (e.g., RSA, ELGAMMA, etc.) available from commercial technology may be employed to implement the above-described keys.

Fig. 1 also shows a certification authority 115. According to one embodiment, the certificate authority 115 may advantageously comprise a trusted third party organization or company that issues digital certificates, such as VeriSign, Baltimore, Entrust, and the like. The trust engine 110 may advantageously send a request for a digital certificate to the certificate authority 115 via one or more conventional digital certificate protocols (e.g., PKCS 10). In response, the certificate authority 115 will issue digital certificates for one or more of a number of different protocols (e.g., PKCS 7). According to one embodiment of the invention, the trust engine 110 requests digital certificates from several or all of the primary certificate authorities 115, such that the trust engine 110 may access digital certificates corresponding to any requesting party's certificate standard.

According to another embodiment, the trust engine 110 performs certificate issuance internally. In this embodiment, the trust engine 110 may access the credential system used to generate the credential and/or may generate the credential internally when the credential is requested (e.g., at key generation) or in the credential criteria requested at the time of the request. The trust engine 110 will be disclosed in more detail below.

Fig. 1 also shows a vendor system 120. According to one embodiment, vendor system 120 advantageously includes a Web server. A typical Web server typically provides content over the internet using one of several internet markup languages or document format standards, such as hypertext markup language (HTML) or extensible markup language (XML). The Web server accepts requests from browsers such as Netscape and Internet Explorer and then returns the appropriate electronic document. Multiple server or client technologies can be used to improve the Web server's ability to pass its ability to deliver standard electronic documents. For example, these technologies include Common Gateway Interface (CGI) scripts, Secure Sockets Layer (SSL) security, and dynamic server pages (ASPs). Vendor system 120 may advantageously provide electronic content related to business, personal, educational, or other transactions.

Although the vendor system 120 is disclosed with reference to the above embodiments, the present invention is not limited thereto. Rather, skilled artisans will recognize from the disclosure herein that vendor system 120 may advantageously comprise any one or combination of the devices described with reference to user system 105.

Fig. 1 also shows a communication link 125 connecting the user system 105, the trust engine 110, the certification authority 115, and the vendor system 120. According to one embodiment, the communication link 125 preferably comprises the Internet. The internet, as used herein, is a global network of computers. The structure of the internet, as known to those of ordinary skill in the art, includes a network backbone and networks branching from the backbone. These branches then have networks branching from them, and so on. Routers move packets between network levels and then from network to network until the packet reaches the vicinity of its destination. The host of the destination network directs packets from the destination to the appropriate end or node. In one advantageous embodiment, the internet routing hub includes a Domain Name System (DNS) server using the transmission control protocol/internet protocol (TCP/IP) as is well known in the art. The routing hub is connected to one or more other routing hubs via a high-speed communication link.

One popular part of the internet is the world wide web. The world wide web contains various computers that store documents capable of displaying graphical and textual information. Computers that provide information on the world wide web are commonly referred to as "web sites". A web site is defined by an internet address with associated electronic pages. The electronic page can be identified by a Uniform Resource Locator (URL). Typically, an electronic page is a document that organizes the presentation of text, graphical images, audio, video, etc.

Although the communication link 125 is disclosed with respect to its preferred embodiment, one of ordinary skill in the art will recognize from the disclosure herein that the communication link 125 may include a variety of interactive communication links. For example, the communication link 125 may include an interactive television network, a telephone network, a wireless data transmission system, a two-way cable system, a customized private or public computer network, an interactive kiosk network, an automated teller machine network, a direct link, a satellite or cellular network, and so forth.

FIG. 2 illustrates a block diagram of the trust engine 110 of FIG. 1 in accordance with aspects of an embodiment of the present invention. As shown in fig. 2, the trust engine 110 includes a transaction engine 205, a repository 210, an authentication engine 215, and a cryptographic engine 220. The trust engine 110 also includes mass storage 225, according to one embodiment of the present invention. As further shown in fig. 2, the transaction engine 205 is in communication with a repository 210, an authentication engine 215, and a cryptographic engine 220, and a mass storage 225. In addition, the storage 210 is in communication with an authentication engine 215, a cryptographic engine 220, and a mass storage 225. Further, the authentication engine 215 communicates with the cryptographic engine 220. According to one embodiment of the invention, some or all of the above communications may advantageously include sending the XML document to an IP address corresponding to the receiving device. As described above, XML documents advantageously allow designers to create their own customized document markup to enable the definition, transmission, validation, and interpretation of data between applications and between organizations. Further, some or all of the above communications may include conventional SSL technology.

According to one embodiment, the transaction engine 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 may advantageously receive input data from the communication link 125. According to one embodiment of the invention, the input data is addressed to the front-end security system of the trust engine 110. For example, the front-end security system may advantageously include a firewall, an intrusion detection system that searches for known attack profiles, and/or a virus scanner. After passing through the front-end security system, the data is received by the transaction engine 205 and routed to one of the store 210, the authentication engine 215, the cryptographic engine 220, and the mass storage 225. In addition, the transaction engine 205 monitors input data from the authentication engine 215 and the cryptographic engine 220 and routes the data to a particular system over the communication link 125. For example, the transaction engine 205 may advantageously route the data to the user system 105, the certification authority 115, or the vendor system 120.

According to one embodiment, data is routed using conventional HTTP routing techniques, such as using URLs or Uniform Resource Indicators (URIs). URIs are similar to URLs, however, URIs typically indicate the source of a file or action (e.g., executable file, script, etc.). Thus, according to one embodiment, the components of the user system 105, the certificate authority 115, the vendor system 120, and the trust engine 210 advantageously include sufficient data within the communication URL or URI for the transaction engine 205 to properly route data throughout the cryptographic system.

Although data routing is disclosed with reference to its preferred embodiments, the skilled artisan will recognize a large number of possible data routing schemes or strategies. For example, XML or other data packets may advantageously be unpacked and identified by their format, content, etc., so that the transaction engine 205 may properly route data throughout the trust engine 110. Furthermore, the skilled artisan will recognize that, advantageously, when the communication link 125 comprises a local area network, for example, the data routing may be modified to accommodate data transmission protocols that conform to a particular network system.

According to another embodiment of the invention, the transaction engine 205 includes conventional SSL encryption technology, so that during a particular communication, the above-described systems can authenticate themselves and vice versa via the transaction engine 205. As used herein, the term "1/2 SSL" refers to SSL-authenticated communications by the server (but not necessarily by the client), and the term "full SSL" refers to communications by both the client and the server. When the term "SSL" is used in this disclosure, the communication may include 1/2SSL or full SSL.

The transaction engine 205 may advantageously establish an audit trail (audit trail) as the transaction engine 205 routes data to various components of the cryptographic system 100. According to one embodiment, the audit trail includes records of at least the type and format of data routed by transaction engine 205 throughout cryptographic system 100. Such audit data may be advantageously stored in mass storage 225.

Fig. 2 also shows a reservoir 210. According to one embodiment, storage 210 includes one or more data storage facilities, such as directory servers, database servers, and the like. As shown in fig. 2, the storage 210 stores a cryptographic key and enrollment authentication data. The cryptographic key may advantageously correspond to the trust engine 110 or a user (e.g., a user or vendor) of the cryptographic system 100. The enrollment authentication data may advantageously include data designed to uniquely identify the user, such as a user ID, a password, an answer to a question, biometric data, and the like. Advantageously, this enrollment authentication data may be obtained at the time of enrollment of the user or at another alternative later time. For example, the trust engine 110 may include periodic or other updates or re-issues of enrollment authentication data.

According to one embodiment, the communications from the transaction engine 205 to the authentication engine 215 and the cryptographic engine 220 and from the authentication engine 215 and the cryptographic engine 220 to the transaction engine 205 include secure communications (e.g., conventional SSL technology). Further, as described above, the data of the communications to and from the repository 210 may be communicated using URL, URI, HTTP or XML documents, advantageously with data requests and formats embedded within any of the above.

As described above, the depository 210 may advantageously comprise a plurality of secure data storage facilities. In such embodiments, the secure data storage facility may be configured such that compromise of the security of one individual data storage facility will not compromise the cryptographic keys or authentication data stored therein. For example, according to this embodiment, the cryptographic key and the authentication data are mathematically operated so as to statistically substantially randomize the data stored in each data storage facility. According to one embodiment, randomization of the data of the individual data storage facilities renders the data indecipherable. Thus, compromise of the individual data storage facilities only generates randomized undecipherable numbers and does not compromise the security of any cryptographic keys or authentication data as a whole.

Figure 2 also shows the trust engine 110 including an authentication engine 215. According to one embodiment, the authentication engine 215 includes a data comparator configured to compare data from the transaction engine 205 with data from the store 210. For example, during the authentication process, the user provides the current authentication data to the trust engine 110 so that the transaction engine 205 receives the current authentication data. As described above, the transaction engine 205 identifies data requests that are preferred in URLs or URIs and routes authentication data to the authentication engine 215. Further, when requested, the repository 210 forwards enrollment authentication data corresponding to the user to the authentication engine 215. Thus, the authentication engine 215 has the current authentication data and the enrollment authentication data for comparison.

According to one embodiment, the communications to the authentication engine include secure communications (e.g., SSL technology). Additionally, security (e.g., super encryption using public key technology) may be provided within the trust engine 110 component. For example, according to one embodiment, the user encrypts the current authentication data with the public key of the authentication engine 215. In addition, the repository 210 encrypts the enrollment authentication data with the public key of the authentication engine 215. In this way, only the private key of the authentication engine can be used to decrypt the transmission.

As shown in fig. 2, the trust engine 110 also includes a cryptographic engine 220. According to one embodiment, the cryptographic engine includes a cryptographic processing module configured to advantageously provide conventional cryptographic functionality (e.g., Public Key Infrastructure (PKI) functionality). For example, the cryptographic engine 220 may advantageously issue public and private keys to users of the cryptographic system 100. In this manner, the cryptographic key is generated at the cryptographic engine 220 and forwarded to the repository 210, such that at least the private cryptographic key is not available outside of the trust engine 110. According to another embodiment, the cryptographic engine 220 randomizes and splits at least the private cryptographic key data, thereby storing only the randomized split data. Similar to the splitting of enrollment authentication data, the splitting process ensures that the stored keys are not available outside of the cryptographic engine 220. According to another embodiment, the functions of the cryptographic engine may be combined with the authentication engine 215 and performed by the authentication engine 215.

According to one embodiment, communications to and from the cryptographic engine include secure communications, such as SSL technology. Furthermore, XML documents may be advantageously employed to transfer data and/or to make cryptographic function requests.

FIG. 2 also shows a trust engine 110 having mass storage 225. As described above, the transaction engine 205 maintains data corresponding to the audit trail and stores this data in the mass storage 225. Similarly, according to one embodiment of the invention, the storage 210 holds data corresponding to the audit trail and stores this data in the mass storage 225. The vault audit index data is similar to that of the transaction engine 205 in that it includes a record of requests received by the vault 210 and their responses. Additionally, mass storage 225 may be used to store digital certificates that internally contain the user's public key.

Although the trust engine 110 is disclosed with reference to its preferred and alternate embodiments, the present invention is not limited thereto. Rather, the skilled artisan will recognize from the disclosure herein a number of alternatives for the trust engine 110. For example, the trust engine 110 may advantageously perform only authentication, or only some or all cryptographic functions, such as data encryption and decryption. According to these embodiments, one of the authentication engine 215 and the cryptographic engine 220 may advantageously be eliminated, thereby creating a simpler design for the trust engine 110. Additionally, the cryptographic engine 220 may also communicate with a certification authority to implement the certification authority within the trust engine 110. According to another embodiment, the trust engine 110 may advantageously perform authentication and one or more cryptographic functions, such as digital signatures.

FIG. 3 illustrates a block diagram of the transaction engine 205 of FIG. 2 in accordance with aspects of an embodiment of the invention. According to this embodiment, transaction engine 205 includes an operating system 305 having a processing thread and a listening thread. Operating system 305 may advantageously be similar to those found in conventional high-volume servers, such as Web servers available from Apache. The listening thread monitors incoming communications from one of the communication link 125, the authentication engine 215, and the cryptographic engine 220 for incoming data streams. The processing thread identifies a particular data structure (e.g., the data structure described above) of the incoming data stream, thereby routing the incoming data to one of the communication link 125, the storage 210, the authentication engine 215, the cryptographic engine 220, or the mass storage 225. As shown in fig. 3, the input and output data may advantageously be protected by, for example, SSL technology.

Fig. 4 illustrates a block diagram of the storage 210 of fig. 2, in accordance with aspects of an embodiment of the invention. According to this embodiment, the storage 210 includes one or more Lightweight Directory Access Protocol (LDAP) servers. LDAP directory servers are available from various manufacturers (e.g., Netscape, ISO, etc.). Fig. 4 also shows that the directory server preferably stores data 405 corresponding to the cryptographic key and data 410 corresponding to the enrollment authentication data. According to one embodiment, the storage 210 includes a single logical storage structure for indexing the authentication data and the cryptographic key data to a unique user ID. The single logical storage structure preferably includes a mechanism to ensure a high degree of trust or security of the data stored therein. For example, the physical location of the storage 210 may advantageously include a number of traditional security measures, such as limited employee access, modern monitoring systems, and the like. In addition to or instead of physical security, the computer system or server may advantageously include a software scheme to protect the stored data. For example, the storage 210 may advantageously establish and store data 415 corresponding to an audit trail of actions taken. Furthermore, incoming and outgoing communications may advantageously be encrypted with public key encryption in combination with conventional SSL technology.

According to another embodiment, the storage 210 may comprise different and physically separate data storage facilities, as disclosed further with reference to fig. 7.

Fig. 5 illustrates a block diagram of the authentication engine 215 of fig. 2, in accordance with aspects of an embodiment of the invention. Similar to the transaction engine 205 of fig. 3, the authentication engine 215 includes an operating system 505, the operating system 505 having at least a modified version of a traditional Web server (e.g., a Web server available from Apache) listening and processing threads. As shown in fig. 5, authentication engine 215 includes access to at least one private key 510. Advantageously, the private key 510 may be used, for example, to decrypt data from the transaction engine 205 or the storage 210 that was encrypted with the corresponding public key of the authentication engine 215.

Fig. 5 also shows the authentication engine 215 including a comparator 515, a data splitting module 520, and a data assembling module 525. According to a preferred embodiment of the present invention, the comparator 515 comprises a technique capable of comparing potentially complex patterns associated with the biometric authentication data described above. The techniques may include hardware, software, or a combination of schemes for pattern comparison (e.g., representing fingerprint patterns or voice patterns). Further, according to one embodiment, the comparator 515 of the authentication engine 215 may advantageously compare traditional hash values of documents to present a comparison result. According to one embodiment of the invention, comparator 515 includes applying heuristics (hemristics) 530 to the comparison. Advantageously, the heuristics 530 may address circumstances surrounding an authentication attempt (e.g., time, IP address or subnet mask, purchase profile, email address, processor serial number or ID, etc.).

Furthermore, the nature of the biometric data comparison may result in varying degrees of confidence resulting from the matching of the current biometric authentication data with the enrollment data. For example, rather than simply being a correct or incorrect, a fingerprint may be determined to be a partial match, such as a 90% match, a 75% match, or a 10% match, as opposed to a traditional password that may simply return a positive or negative match. Other biometric identification methods, such as voiceprint (voice print) analysis or facial recognition, may share the attribute of this probabilistic authentication, rather than an absolute authentication.

When working with such probabilistic authentication, or in other situations where the authentication is considered less than absolutely reliable, it is desirable to apply the heuristic 530 to determine whether the confidence level of the authentication set is high enough to authenticate the transaction in progress.

There are sometimes the following cases: the transaction in question is a relatively low value transaction in which it can be authenticated with a lower confidence level being accepted. This may include transactions having a low monetary value associated with them (e.g., $10 purchase) or low risk transactions (e.g., entering a affiliate website).

Conversely, to authenticate other transactions, it may be desirable to require a high authentication confidence before allowing the transaction to proceed. These transactions may include large monetary transactions (e.g., signing millions of dollar supply contracts) or transactions with high risk in the event of incorrect authentication (e.g., logging into a government computer remotely).

As described below, the use of heuristics 530 combined with confidence levels and transaction values may be used to allow comparators to provide a dynamic context-sensitive authentication system.

According to another embodiment of the invention, the comparator 515 may advantageously track authentication attempts for a particular transaction. For example, when a transaction fails, the trust engine 110 may request the user to re-enter his or her current authentication data. The comparator 515 of the authentication engine 215 may advantageously utilize an attempt limiter 535 to limit the number of authentication attempts, thereby prohibiting brute force attempts to impersonate the user's authentication data. According to one embodiment, the attempt limiter 535 comprises a software module that monitors for repeated authentication attempts for a transaction and limits the authentication attempts for a given transaction to, for example, three times. Thus, the attempt limiter 535, for example, limits the automatic attempts to impersonate an individual's authentication data to only three "guesses". When three failures, the attempt limiter 535 may advantageously reject additional authentication attempts. Advantageously, such rejection is achieved, for example, by the comparator 515 returning a negative result regardless of the current authentication data being sent. On the other hand, the transaction engine 205 may advantageously block any additional authentication attempts pertaining to transactions for which three attempts have previously failed.

The authentication engine 215 also includes a data splitting module 520 and a data assembling module 525. The data splitting module 520 advantageously comprises a software, hardware, or combination module having the ability to mathematically operate on various data to substantially randomize and split the data into portions. According to one embodiment, the original data may not be reconstructed from the individual parts. The data assembly module 525 advantageously comprises a software, hardware or combination module configured to mathematically operate on the substantially randomized portions such that their combination provides the original deciphered data. According to one embodiment, the authentication engine 215 randomizes and splits enrollment authentication data into portions using the data splitting module 520 and reassembles the portions into usable enrollment authentication data using the data assembling module 525.

FIG. 6 illustrates a block diagram of the cryptographic engine 220 of the trust engine 200 of FIG. 2, in accordance with aspects of one embodiment of the present invention. Similar to the transaction engine 205 of fig. 3, the cryptographic engine 220 includes an operating system 605, the operating system 605 having at least a modified version of a traditional Web server (e.g., a Web server available from Apache) listening and processing threads. As shown in fig. 6, the cryptographic engine 220 includes a data splitting module 610 and a data assembling module 620 that function similarly to fig. 5. However, according to one embodiment, the data splitting module 610 and the data assembling module 620 process cryptographic key data, unlike the enrollment authentication data described above. However, skilled artisans will recognize from the disclosure herein that the data splitting module 910 and the data splitting module 620 may be combined with corresponding modules of the authentication engine 215.

The cryptographic engine 220 also includes a cryptographic handling module 625, the cryptographic handling module 625 being configured to perform one, some, or all of a number of cryptographic functions. According to one embodiment, the cryptographic handling module 625 may comprise software modules or programs, hardware, or both. According to another embodiment, the cryptographic handling module 625 may perform data comparison, data parsing, data splitting, data hashing, data encryption or decryption, digital signature verification or creation, digital certificate generation, storage, or request, cryptographic key generation, and so forth. Furthermore, skilled artisans will recognize from the disclosure herein that the cryptographic processing module 825 may advantageously comprise a public key infrastructure, such as good privacy (PGP), RSA-based public key system, or a number of alternative key management systems. Further, the cryptographic handling module 625 may perform public key encryption, symmetric key encryption, or both. In addition to the above, the cryptographic handling module 625 may include one or more computer programs or modules, hardware, or both for performing seamless, transparent interoperability functions.

Skilled artisans will also recognize from the disclosure herein that cryptographic functions may include a large or diverse number of functions typically associated with cryptographic key management systems.

FIG. 7 shows a simplified block diagram of a storage system 700 according to aspects of an embodiment of the invention. As shown in fig. 7, the storage system 700 advantageously includes a plurality of data storage facilities, for example, data storage facilities D1, D2, D3, and D4. However, one of ordinary skill in the art will readily appreciate that a storage system may have only one data storage facility. According to one embodiment of the invention, each of the data storage facilities D1 through D4 may advantageously include some or all of the components disclosed with reference to the storage 210 of fig. 4. Similar to the depository 210, the data storage facilities D1 through D4 preferably communicate with the transaction engine 205, the authentication engine 215, and the cryptographic engine 220 through conventional SSL. The communication link transmits, for example, an XML document. The communications from the transaction engine 205 may advantageously include a request for data, wherein the request is advantageously broadcast to the IP address of each data storage facility D1 through D4. On the other hand, the transaction engine 205 may broadcast requests to particular data storage facilities based on a number of criteria (e.g., response time, server load, maintenance schedule, etc.).

In response to a request for data from the transaction engine 205, the depository system 700 advantageously forwards the stored data to the authentication engine 215 and the cryptographic engine 220. The corresponding data assembly module receives the forwarded data and assembles the data into a usable format. On the other hand, communications from the authentication engine 215 and the cryptographic engine 220 to the data storage facilities D1 through D4 may include the transmission of sensitive data to be stored. For example, according to one embodiment, the authentication engine 215 and the cryptographic engine 220 may advantageously utilize their respective data splitting modules to divide sensitive data into multiple undecipherable portions and then send one or more of the undecipherable portions of the sensitive data to a particular data storage facility.

According to one embodiment, each data storage facility D1-D4 includes a separate and independent storage system (e.g., a directory server). According to another embodiment of the invention, the storage system 700 includes a plurality of geographically separated independent data storage systems. By distributing the sensitive data to different and independent storage facilities D1-D4 (some or all of the storage facilities D1-D4 may advantageously be geographically separated), the storage system 700 provides redundancy along with additional security measures. For example, according to one embodiment, only data from two of the plurality of data storage facilities D1 through D4 are required for the sensitive data to be deciphered and reassembled. Thus, two of the four data storage facilities D1 through D4 may be inoperative due to maintenance, system failure, power failure, etc., which does not affect the functionality of the trust engine 110. Further, according to one embodiment, since the data stored in each data storage facility is randomized and undecipherable, a compromise to any individual data storage facility does not necessarily compromise sensitive data. Furthermore, in embodiments having geographically separated data storage facilities, the hazards to multiple geographically remote facilities become increasingly difficult. Indeed, even a rogue employee, wanting to destroy the multiple independent geographically distant data storage facilities required is extremely challenging.

Although the reservoir system 700 is disclosed with reference to its preferred and alternative embodiments, the present invention is not so limited. Rather, the skilled artisan will recognize from the disclosure herein a wide variety of alternatives for the reservoir system 700. For example, the storage system 700 may include one, two, or more data storage facilities. Furthermore, the sensitive data may be mathematically manipulated such that portions from two or more data storage facilities are required for the sensitive data to be reassembled and deciphered.

As described above, the authentication engine 215 and the cryptographic engine 220 include data splitting modules 520 and 610, respectively, for splitting sensitive data of any type or form (e.g., text, audio, video, authentication data, and cryptographic key data). FIG. 8 shows a flow diagram of a data splitting process 800 performed by the data splitting module in accordance with aspects of an embodiment of the present invention. As shown in fig. 8, the data splitting process 800 begins at step 805 when the sensitive data "S" is received by the data splitting module of the authentication engine 215 or the cryptographic engine 220. Preferably, at step 810, the data splitting module generates a substantially random number, value, or string or set of bits "a". For example, the random number a may be generated in a number of different conventional techniques available to those of ordinary skill in the art for generating high quality random numbers suitable for cryptographic applications. Furthermore, according to an embodiment, the random number a comprises a bit length that may be any suitable length, e.g. 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 statistical random number "C". According to a preferred embodiment, the generation of the statistical random numbers a and C can advantageously be done in parallel. The data splitting module then combines the numbers a and C with the sensitive data S to generate new numbers "B" and "D". For example, number B may comprise a binary combination of A XOR S, and number D may comprise a binary combination of C XOR S. XOR functions or "exclusive or" functions are well known to those of ordinary skill in the art. Preferably, the above combinations occur in steps 825 and 830, respectively, and according to one embodiment, the above combinations may also occur in parallel. The data splitting process 800 then proceeds to step 835 where the random numbers a and C and numbers B and D are paired such that none of the pairs contain sufficient data that the original sensitive data S can be reorganized and deciphered by themselves. For example, these numbers may be paired as follows: AC. AD, BC, and BD. According to one embodiment, each of the above-described pairs is distributed to one of the reservoirs D1 through D4 of fig. 7. According to another embodiment, each of the above-mentioned pairs is randomly distributed to one of the storages D1 to D4. For example, during the first data splitting process 800, the pairing AC may be sent to the store D2, e.g., by random selection of the IP address of D2. Then, during the second data splitting process 800, the pairing AC may be sent to the storage D4, for example, by random selection of the IP address of D4. Furthermore, these pairs may all be stored on one reservoir, and may be stored at separate locations of the reservoir.

Based on the above description, it is advantageous that the data splitting process 800 places portions of the sensitive data in each of the four data storage facilities D1 through D4 such that no single data storage facility D1 through D4 includes sufficient encrypted data to reconstruct the original sensitive data S. As described above, by randomizing the data into encrypted portions that are not available to the individual, security is improved and trust in the data can be maintained even if one of the data storage facilities D1 through D4 is compromised.

Although the data splitting process 800 is disclosed with reference to a preferred embodiment thereof, the present invention is not limited thereto. Rather, the skilled artisan will recognize from the disclosure herein a number of alternatives to the data splitting process 800. For example, the data splitting process may advantageously split the data into two numbers, e.g., random number a and number B, and randomly distribute a and B through two data storage facilities. Furthermore, by generating additional random numbers, the data splitting process 800 may advantageously split data between a large number of data storage facilities. The data may be split into any desired, selected, predetermined, or randomly specified size units, including but not limited to one bit, multiple bits, bytes, kilobytes, megabytes or more, or any combination or sequence of sizes. In addition, changing the size of the data elements resulting from the splitting process may make it more difficult to restore the data to a usable form, thereby increasing the security of sensitive data. One of ordinary skill in the art will readily appreciate that the split data unit size may be a wide variety of data unit sizes or patterns of sizes or combinations of sizes. For example, the data unit sizes may be selected or predetermined to all have the same size, fixed sets of different sizes, a combination of sizes, or randomly generated sizes. Similarly, the data units may be distributed into one or more shares according to a fixed or predetermined data unit size, a pattern or combination of data unit sizes, or a randomly generated data unit size per share.

As mentioned above, in order to reconstruct the sensitive data S, the data portions need to be de-randomized and reorganized. This process may advantageously be performed in the data assembly modules 525 and 620 of the authentication engine 215 and the cryptographic engine 220, respectively. Data assembly modules (e.g., data assembly module 525) receive data portions from the data storage facilities D1 through D4 and reassemble the data into a usable form. For example, according to one embodiment in which the data splitting module 520 employs the data splitting process 800 of fig. 8, the data assembly module 525 reconstructs the sensitive data S using data portions from at least two of the data storage facilities D1 through D4. For example, pairs of AC, AD, BC, and BD are distributed to provide either A and B or C and D for any two. It is noted that S-a XOR B or S-C XOR D indicates that the data assembly module 525 may advantageously reassemble the sensitive data S when the data assembly module receives one of a and B or C and D. Thus, the data assembly portion 525 may assemble the sensitive data S when the data assembly module 525 receives data portions from at least the first two of the data storage facilities D1 through D4, for example, in response to an assembly request by the trust engine 110.

Based on the above data splitting and assembling processes, sensitive data S in usable formats exists only within a limited area of the trust engine 110. For example, when the sensitive data S includes enrollment authentication data, available non-randomized enrollment authentication data is only available in the authentication engine 215. Likewise, when the sensitive data S includes private cryptographic key data, available non-randomized private cryptographic key data is only available in the cryptographic engine 220.

Although the data splitting and assembling process is disclosed with reference to preferred embodiments thereof, the present invention is not limited thereto. Rather, the skilled artisan will recognize from the disclosure herein a number of alternatives for splitting and reassembling sensitive data S. For example, public key encryption may be used to further protect data in the data storage facilities D1 through D4. Moreover, those of ordinary skill in the art will readily appreciate that the data splitting modules described herein are also separate and distinct embodiments of the present invention, or other embodiments of the present invention, such as the trust engine, authentication engine, and transaction engine disclosed and described herein, that may be incorporated, combined, or otherwise made part of any pre-existing computer system, software suite, database, or combination thereof.

Fig. 9A illustrates a data flow of a registration process 900 according to aspects of an embodiment of the invention. As shown in fig. 9A, the enrollment process 900 begins at step 905 when a user wishes to enroll with the trust engine 110 of the cryptographic system 100. According to this embodiment, the user system 105 advantageously includes a client-side Java applet (applet), for example, based on Java, that queries the user to enter enrollment data (e.g., demographic data and enrollment authentication data). According to one embodiment, the enrollment authentication data includes a user ID, a password, a biometric, and the like. According to one embodiment, during the interrogation process, the client-side Java applet preferably communicates with the trust engine 110 to ensure that the selected user ID is unique. When the user ID is not unique, the trust engine 110 may advantageously suggest a unique user ID. The client-side Java applet collects the enrollment data and transmits the enrollment data to the trust engine 110, in particular to the transaction engine 205, e.g. by means of an XML document. According to one embodiment, the transmission is encoded with the public key of the authentication engine 215.

According to one embodiment, the user performs a single enrollment in step 905 of the enrollment process 900. For example, a User registers himself or herself as a particular person (e.g., Joe User). When Joe User wishes to register as Joe User (CEO of Mega corporation), according to this embodiment, Joe User registers a second time, receives a second unique User ID and the trust engine 110 does not associate the two identities. According to another embodiment of the invention, the registration process 900 provides multiple user identities for one user ID. Thus, in the above example, the trust engine 110 would advantageously associate the two identities of Joe User. It will be apparent to those skilled in the art from this disclosure that a User may have many identities, such as Joe User, charitable fund member, and the like. Even though the user may have multiple identities, the trust engine 110 preferably stores only one set of enrollment data according to this embodiment. Furthermore, advantageously, the user can add, edit/update or delete identities when needed.

Although the registration process 900 is disclosed with reference to a preferred embodiment thereof, the present invention is not limited thereto. Rather, the skilled artisan will recognize from the disclosure herein a number of alternatives for collecting enrollment data, and in particular enrollment authentication data. For example, a Java applet may be a Common Object Model (COM) based Java applet or the like.

Alternatively, the registration process may include hierarchical registration. For example, at the lowest registration level, a user may register via the communication link 125 without generating documentation about his or her identity. According to the increased enrollment level, the user enrolls using a trusted third party (e.g., a digital notary). For example, a user may be physically present to a trusted third party, generate proofs (e.g., birth proofs, drivers 'licenses, military officers' licenses, etc.), and the trusted third party may advantageously include, for example, their digital signature in the enrollment submission. Trusted third parties may include real notaries, government agencies (e.g., the post office or automotive department), human resource personnel in large corporations that recruit employees, and the like. It will be apparent to those skilled in the art from this disclosure that a number of different levels of registration can be performed during the registration process 900.

Upon receiving the enrollment authentication data, the transaction engine 205 forwards the enrollment authentication data to the authentication engine 215 using conventional full SSL techniques at step 915. In step 920, the authentication engine 215 decrypts the enrollment authentication data using the private key of the authentication engine 215. In addition, the authentication engine 215 performs a mathematical operation on the enrollment authentication data using a data splitting module to split the data into at least two independently undecipherable random numbers. As described above, the at least two numbers may include a statistical random number and a binary exclusive or number. In step 925, the authentication engine 215 forwards each portion of the random number to one of the data storage facilities D1 through D4. As described above, the authentication engine 215 may also advantageously randomize which portions are transferred to which store.

In the enrollment process 900, the user often also wishes to issue a digital certificate so that he or she can receive encrypted documents from someone other than the password system 100. As described above, the certificate authority 115 typically issues digital certificates in accordance with one or more of several conventional standards. Typically, a digital certificate includes the public key of every known user or system.

Whether the user requests a digital certificate at enrollment or at another time, the request is communicated through the trust engine 110 to the authentication engine 215. According to one embodiment, the request includes, for example, an XML document with the correct name of the user. The authentication engine 215 communicates the request to the cryptographic engine 220 to instruct the cryptographic engine 220 to generate a cryptographic key or key pair, according to step 935.

Upon being requested, the cryptographic engine 220 generates 935 at least one cryptographic key. According to one embodiment, the cryptographic handling module 625 generates a key pair, where one key is used as a private key and one key is used as a public key. The cryptographic engine 220 stores a private key and, according to one embodiment, a copy of a public key. In step 945, the cryptographic engine 220 sends a request for a digital certificate to the transaction engine 205. According to one embodiment, the request advantageously comprises a standardized request such as PKCS10, for example, embedded within an XML document. The request for a digital certificate may advantageously correspond to one or more certification authorities and one or more standard formats required by those certification authorities.

The transaction engine 205 forwards the request to the certificate authority 115 in step 950, and the certificate authority 115 returns a digital certificate in step 955. Advantageously, the returned digital certificate may be in a standardized format, such as PKCS7, or in a proprietary format of one or more certification authorities 115. In step 960, the digital certificate is received by the transaction engine 205, a copy is forwarded to the user and the copy is stored by the trust engine 110. The trust engine 110 stores a copy of the certificate so that the trust engine 110 will not need to rely on the availability of the certificate authority 115. For example, when a user wishes to send a digital certificate or a third party requests the user's digital certificate, a request for a digital certificate is typically sent to the certificate authority 115. However, if the certificate authority 115 is performing maintenance or is a victim of a malfunction or security hazard, the digital certificate cannot be obtained.

At any time after issuing the cryptographic key, the cryptographic engine 220 may advantageously utilize the data splitting process 800 described above such that the cryptographic key is split into independently undecipherable random numbers. Similar to the authentication data, in step 965, the cryptographic engine 220 transmits the random numbers to the data storage facilities D1 through D4.

Skilled artisans will recognize from the disclosure herein that a user may request a digital certificate at any time after enrollment. Further, the communication between the systems may advantageously include full SSL or public key encryption techniques. In addition, the enrollment process may issue multiple digital certificates from multiple certification authorities, including one or more proprietary certification authorities internal or external to the trust engine 110.

As disclosed in steps 935 through 960, one embodiment of the present invention includes a request for a certificate that is ultimately stored on the trust engine 110. According to one embodiment, each certificate corresponds to a private key, as the cryptographic handling module 625 issues keys used by the trust engine 110. Thus, the trust engine 110 may advantageously provide interoperability by monitoring credentials owned by or associated with a user. For example, when the cryptographic engine 220 receives a request for a cryptographic function, the cryptographic handling module 625 may investigate a certificate that the requesting user possesses to determine whether the user possesses a private key that matches the attributes of the request. When such a certificate exists, the cryptographic handling module 625 may perform the requested function using the certificate or a public or private key associated therewith. When such credentials are not present, the cryptographic handling module 625 may advantageously and transparently perform a number of actions to attempt to remedy the lack of an appropriate key. Fig. 9B illustrates a flow diagram of an interoperability process 970, which discloses the above steps to ensure that the cryptographic handling module 625 performs cryptographic functions using appropriate keys, in accordance with aspects of embodiments of the present invention.

As shown in fig. 9B, the interoperability process 970 begins at step 972 where the cryptographic handling module 925 determines the type of certificate desired at step 972. According to one embodiment of the invention, it is advantageous to specify the type of certificate in the request for a cryptographic function or other data provided by the requester. According to another embodiment, the certificate type may be determined by the data format of the request. For example, cryptographic processing module 925 may advantageously identify requests corresponding to a particular type.

According to one embodiment, the certificate type may include one or more algorithmic criteria, such as RSA, ELGAMMA, and the like. Further, the certificate types may include one or more key types, e.g., symmetric keys, public keys, strong encryption keys such as 256-bit keys, less secure keys, etc. Further, the certificate types may include upgrades or replacements for one or more of the above-described algorithm standards or keys, one or more messages or data formats, one or more data packaging or encoding schemes (e.g., Base32 or Base 64). The certificate type 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. Skilled artisans will recognize from the disclosure herein that other differences may exist in the certificate types, and that translations from or to these differences may be performed as disclosed herein.

Once the cryptographic handling module 625 determines the certificate type, the interoperability process 970 proceeds to step 974 and determines whether the user has a certificate matching the determined type in step 974. When the user possesses a matching certificate, for example, the trust engine 110 can access the matching certificate by, for example, its previous storage, the cryptographic processing module 825 knows that the matching private key is also stored within the trust engine 110. For example, the matching private key may be stored within the storage 210 or the storage system 700. Advantageously, the cryptographic handling module 625 may request that a matching private key be assembled from, for example, storage 210, and then perform a cryptographic operation or function using the matching private key in step 976. For example, as described above, the cryptographic handling module 625 may advantageously perform hashing, hash comparison, data encryption or decryption, digital signature verification or establishment, and so forth.

When the user does not possess a matching certificate, the interoperability process 970 proceeds to step 978 where, at step 978, the cryptographic handling module 625 determines whether the user possesses a cross-certified certificate. According to one embodiment, cross-certification between certification authorities occurs when a first certification authority determines to trust a certificate from a second certification authority. In other words, the first certification authority determines that the certificate from the second certification authority meets certain quality criteria and thus may be "certified" as equivalent to the certificate of the first certification authority itself. Cross-certification becomes more complicated when a certification authority issues, for example, certificates with a trust level. For example, a first certification authority may provide three levels of trust to a particular certificate, typically based on the reliability of the enrollment process, while a second certification authority may provide seven levels of trust. Advantageously, cross-certification may track which levels and certificates from the second certification authority may replace which levels and certificates from the first certification authority. When the above-described cross-certification is formally done openly between two certification authorities, the mapping of the certificate and the hierarchy to each other is generally referred to as "chaining".

According to another embodiment of the invention, the cryptographic handling module 625 may advantageously exploit cross-authentication beyond that agreed upon by a certification authority. For example, the cryptographic handling module 625 may access a certificate operation statement (CPS) or other published policy statement of a first certificate authority and match the certificate of the first certificate authority with the certificate of another certificate authority, e.g., using a certificate token (token) required by a particular trust level.

When the cryptographic handling module 625 determines in step 978 that the user possesses the cross-certified certificate, the interoperability process 970 proceeds to step 976 and performs a cryptographic operation or function using the cross-certified public key, private key, or both. Alternatively, when the cryptographic handling module 625 determines that the user does not possess a cross-certified certificate, the interoperability process 970 proceeds to step 980 where the cryptographic handling module 625 selects the certification authority to which the requested certificate type or cross-certified certificate is issued at step 980. In step 982, the cryptographic handling module 625 determines whether the user enrollment authentication data discussed above meets the authentication requirements of the selected certification authority. For example, if a user logs in via a network, such as by answering a population and other questions, the authentication data provided may establish a lower level of trust than a user that provides biometric data and appears in front of a third party (e.g., a notary). According to one embodiment, the above-mentioned certification requirements may advantageously be provided in the CPS of the selected certification authority.

When the user has provided enrollment authentication data to the trust engine 110 that meets the requirements of the selected certificate authority, the interoperability process 970 proceeds to step 984 where the cryptographic handling module 825 obtains a certificate from the selected certificate authority at step 984. According to one embodiment, the cryptographic handling module 625 obtains the certificate through the following steps 945 to 960 of the enrollment process 900. For example, the cryptographic handling module 625 may advantageously request a certificate from a certificate authority using one or more public keys of one or more key pairs that are already available to the cryptographic engine 220. According to another embodiment, the cryptographic handling module 625 may advantageously generate one or more new key pairs and request a certificate from the certificate authority using the public key corresponding thereto.

According to another embodiment, the trust engine 110 may advantageously include one or more certificate issuing modules capable of issuing one or more certificate types. According to this embodiment, the certificate issuing module may provide the above-described certificate. When the cryptographic handling module 625 acquires the certificate, the interoperability process 970 proceeds to step 976 and performs a cryptographic operation or function using the public key, the private key, or both corresponding to the acquired certificate.

When the user does not provide the trust engine 110 with enrollment authentication data that meets the requirements of the selected certificate authority in step 982, the cryptographic handling module 625 determines in step 986 whether there are other certificate authorities with different authentication requirements. For example, the cryptographic handling module 625 may look for a certificate authority that has lower authentication requirements but still issues the selected certificate or a cross-certificate thereof.

When the certificate authority with lower requirements described above is present, interoperability process 970 proceeds to step 980 and selects the certificate authority. Alternatively, when no such authentication authority exists, the trust engine 110 may request additional authentication tokens from the user in step 988. For example, the trust engine 110 may request new enrollment authentication data including, for example, biometric data. Additionally, the trust engine 110 may request that the user appear before trusting a third party and provide the appropriate authentication credentials (e.g., appear before a notary for a driver's license, social security card, bank card, birth credentials, military officer's license, etc.). When the trust engine 110 receives the updated authentication data, the interoperability process 970 proceeds to step 984 and obtains the selected certificate.

Through the interoperability process 970 described above, the cryptographic handling module 625 advantageously provides seamless transparent translation and conversion between different cryptographic systems. The skilled artisan will recognize from the disclosure herein a number of advantages and embodiments of the above-described interoperability system. For example, the above-described step 986 of the interoperability process 970 may advantageously include an aspect of trust arbitration (discussed in more detail below), wherein a certification authority may be subject to a lower level of cross-certification under particular circumstances. Further, interoperability process 970 may include ensuring interoperability between and utilization of standard certificate revocation, e.g., utilizing a Certificate Revocation List (CRL), Online Certificate Status Protocol (OCSP), etc.

Fig. 10 illustrates a data flow of an authentication process 1000 in accordance with aspects of an embodiment of the invention. According to one embodiment, the authentication process 1000 includes collecting current authentication data from a user and comparing it to the user's enrollment authentication data. For example, the authentication process 1000 begins at step 1005, where a user wishes to perform a transaction with, for example, a vendor at step 1005. Such transactions may include, for example, selecting a purchase option, requesting access to a restricted area or device of vendor system 120, and so forth. In step 1010, the vendor provides the user with a transaction ID and an authentication request. The transaction ID may advantageously comprise a 192 bit quantity (32 bit timestamp, concatenated with a 128 bit random quantity or "nonce", concatenated with a 32 bit vendor specific constant). Such a transaction ID uniquely identifies the transaction and thereby enables the trust engine 110 to reject spoofed transactions.

The authentication request may advantageously include what level of authentication is required for a particular transaction. For example, the vendor may specify a particular confidence level for the transaction requirements in question. If authentication cannot be made to this confidence level, as described below, no transaction will occur without further authentication by the user to raise the confidence level or without changes 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 may advantageously be generated by a vendor-side Java applet or other software program. Further, the transmission of the transaction ID and authentication data may include one or more XML documents encrypted using conventional SSL technology (e.g., 1/2 SSL or in other words vendor-side authenticated SSL).

After the user system 105 receives the transaction ID and the authentication request, the user system 105 collects current authentication data from the user, potentially including current biometric information. At step 1015, the user system 105 encrypts at least the current authentication data "B" and the transaction ID with the public key of the authentication engine 215 and transmits the data to the trust engine 110. The transmission preferably comprises an XML document encrypted at least using conventional 1/2 SSL technology. In step 1020, the transaction engine 205 receives the transmission, preferably identifying a data format or request in a URL or URI, and forwards the transmission to the authentication engine 215.

In steps 1015 and 1020, the vendor system 120 forwards the transaction ID and authentication request to the trust engine 110 using the preferred full SSL technique in step 1025. The communication may also include a vendor ID, although vendor identification may also be transmitted by a non-random portion of the transaction ID. At steps 1030 and 1035, the transaction engine 205 receives the communication, builds a record of the audit index, and generates a request for enrollment authentication data for the user to be assembled from the data storage facilities D1 through D4. At step 1040, the depository system 700 transmits the portion of enrollment authentication data corresponding to the user to the authentication engine 215. At step 1045, the authentication engine 215 decrypts the transmission using its private key and compares the enrollment authentication data with the current authentication data provided by the user.

The comparison of step 1045 may advantageously apply heuristic context-sensitive authentication (mentioned above and discussed in more detail below). For example, if the received biometric information does not have a perfect match, a lower confidence match results. In particular embodiments, the confidence level of the authentication is balanced against the nature of the transaction and the desires of both the user and the vendor. This is discussed in more detail below.

In step 1050, the authentication engine 215 populates the authentication request with the results of the comparison of step 1045. According to one embodiment of the invention, the authentication request is populated with a yes/no or true/false result of the authentication process 1000. At step 1055, the populated authentication request is returned to the vendor for compliance by the vendor, e.g., to allow the user to complete the transaction that initiated the authentication request. According to one embodiment, the confirmation message is delivered to the user.

Based on the above description, it is advantageous that the authentication process 1000 keeps sensitive data secure and generates results structured to maintain the integrity of the sensitive data. For example, sensitive data is only assembled within the authentication engine 215. For example, enrollment authentication data is undecipherable prior to being assembled within the authentication engine 215 by the data assembly module, and current authentication data is undecipherable prior to being developed (unwrap) by conventional SSL techniques and the private key of the authentication engine 215. Furthermore, the authentication result sent to the seller does not include sensitive data, and the user cannot even know whether he or she generated valid authentication data.

Although the authentication process 1000 is disclosed with reference to preferred and alternative embodiments thereof, the present invention is not limited thereto. Rather, the skilled artisan will recognize from the disclosure herein a number of alternatives to the authentication process 1000. For example, the vendor may advantageously be replaced by almost any requesting application (even an application residing within the user system 105). For example, a client application (e.g., Microsoft Word) may request authentication using an Application Program Interface (API) or a cryptographic API (capi) before unlocking a document. Alternatively, a mail server, network, cellular telephone, personal or mobile computing device, workstation, or the like may form an authentication request that can be populated by authentication process 1000. In practice, after providing the trusted authentication process 1000 described above, a requesting application or device may access or use a large number of electronic or computer devices or systems.

Further, in the event of authentication failure, authentication process 1000 may employ a number of alternative processes. Authentication failure may keep the same transaction ID and request that the user reenter his or her current authentication data. As described above, using the same transaction ID allows the comparator of the authentication engine 215 to monitor and limit the number of authentication attempts for a particular transaction, thereby creating a more secure cryptographic system 100

Further, advantageously, the authentication process 1000 can be used to develop an elegant single sign-on scheme (e.g., unlocking a sensitive data warehouse (vault)). For example, successful or positive authentication may provide an authenticated user with the ability to automatically access any number of passwords for an almost unlimited number of systems and applications. For example, authentication of a user may provide the user with access to passwords, logins, financial certificates, etc., associated with multiple online sellers, local area networks, various personal computing devices, internet service providers, auctioneers, investment brokerages, etc. By employing a sensitive data store, users can choose truly large and random passwords, as they no longer need to remember them through association. Also, authentication process 1000 provides access to them. For example, the user may select a random alphanumeric string of 20 bits in length, rather than an alphanumeric string associated with memorable data, a name, or the like.

According to one embodiment, the sensitive data warehouse associated with a given user may be advantageously stored within the data storage facility of the storage 210, or split and stored within the storage system 700. In accordance with this embodiment, upon positive user authentication, the trust engine 110 provides the requested sensitive data (e.g., an appropriate password) to the requesting application. According to another embodiment, the trust engine 110 may comprise a separate system for storing the sensitive data repository. For example, the trust engine 110 may comprise a stand-alone software engine for performing data warehouse functions and visually residing "behind" the aforementioned front-end security system of the trust engine 110. According to this embodiment, after the software engine receives a signal from the trust engine 110 indicating a positive user authentication, the software engine provides the requested sensitive data.

In another embodiment, the data warehouse may be implemented by a third party system. Similar to the software engine embodiment, advantageously, the third party system may provide the requested sensitive data upon receiving a signal from the trust engine 110 indicating a positive user authentication. According to another embodiment, the data warehouse may be implemented on the user system 105. The user-side software engine may advantageously provide the above data upon receiving a signal from the trust engine 110 indicating a positive user authentication.

Although the data warehouse described above is disclosed with reference to alternative embodiments, a skilled artisan will recognize from the disclosure herein a number of additional implementations thereof. For example, a particular data warehouse may include aspects of some or all of the above embodiments. Further, any of the above data warehouses may employ one or more authentication requests at different times. For example, any data warehouse may require authentication periodically for each transaction or transactions, for each session or sessions and for each visit to one or more web pages or sites, at one or more other specified intervals, and so forth.

FIG. 11 shows a data flow of a signing process 1100 in accordance with aspects of an embodiment of the present invention. As shown in fig. 11, the signing process 1100 includes similar steps as the authentication process 1000 described above with reference to fig. 10. According to one embodiment of the invention, the signing process 1100 first authenticates the user and then performs one or more of several digital signing functions (described in more detail below). According to another embodiment, the signing process 1100 may advantageously store data associated therewith, such as a hash value of a message or document, and the like. Advantageously, this data may be used for auditing or any other event, such as when a participant attempts to repudiate a transaction.

As shown in fig. 11, in the authentication step, the user and the seller may advantageously agree on a message (e.g., a contract). In the signing process, the signing process 1100 advantageously ensures that the contract signed by the user is the same as the contract provided by the seller. Thus, according to one embodiment, in the authentication process, the seller and the user include hash values of respective copies of the message or contract in the data sent to the authentication engine 215. By employing only hash values of messages or contracts, the trust engine 110 may advantageously store significantly reduced amounts of data, providing a more efficient and cost-effective cryptographic system. Furthermore, advantageously, the stored hash value may be compared with the hash value of the document in question to determine whether the document in question matches a document signed by either party. The ability to determine whether a document is the same as one related to a transaction provides additional evidence that can be used to counter a claim for repudiation of the transaction by a party.

At step 1103, the authentication engine 215 assembles enrollment authentication data and compares it to current authentication data provided by the user. When the comparator of the authentication engine 215 indicates that the enrollment authentication data matches the current authentication data, the comparator of the authentication engine 215 also compares the hash value of the message provided by the vendor to the hash value of the message provided by the user. Thus, advantageously, the authentication engine 215 ensures that the message agreed upon by the user is the same as the message agreed upon by the vendor.

In step 1105, the authentication engine 215 sends a digital signature request to the cryptographic engine 220. According to one embodiment of the invention, the request includes a hash value of the message or contract. However, skilled artisans will recognize from the disclosure herein that the cryptographic engine 220 may encrypt virtually any type of data (including but not limited to video, audio, biometric, image, or text) to form the desired digital signature. Returning to step 1105, the digital signature request preferably comprises an XML document transmitted by conventional SSL techniques.

In step 1110, the authentication engine 215 sends a request to each of the data storage facilities D1 through D4, causing each of the data storage facilities D1 through D4 to send their respective portions of the one or more cryptographic keys corresponding to the signing party. According to another embodiment, the cryptographic engine 220 employs some or all of the steps of the interoperability process 970 described above, such that the cryptographic engine 220 first determines the appropriate key or keys that the signer is to request from the storage 210 or the storage system 700 and takes action to provide the appropriate matching key. According to another embodiment, the authentication engine 215 or the cryptographic engine 220 may advantageously request one or more keys associated with the signing party and stored in the depository 210 or depository system 700.

According to one embodiment, the signatory includes one or both of the user and the seller. In this case, the authentication engine 215 advantageously requests a cryptographic key corresponding to the user and/or vendor. According to another embodiment, the signer includes a trust engine 110. In this embodiment, the trust engine 110 is proving that the authentication process 1000 properly authenticated the user, the vendor, or both. Thus, the authentication engine 215 requests a cryptographic key of the trust engine 110 (e.g., a key belonging to the cryptographic engine 220) to perform a digital signature. According to another embodiment, the trust engine 110 performs digital notary-like functions. In this embodiment, the signer includes a user, a vendor, or both along with the trust engine 110. Thus, the trust engine 110 provides a digital signature of the user and/or vendor, and then indicates with its own digital signature that the user and/or vendor is properly authenticated. In this embodiment, the authentication engine 215 may advantageously request the assembly of a cryptographic key corresponding to the user, the vendor, or both. According to another embodiment, the authentication engine 215 may advantageously request the assembly of a cryptographic key corresponding to the trust engine 110.

According to another embodiment, the trust engine 110 performs an authorization class function. For example, the trust engine 110 may digitally sign a message on behalf of a third party. In this case, the authentication engine 215 requests a cryptographic key associated with the third party. According to this embodiment, the signing process 1100 may advantageously include authenticating a third party before authorizing the book-like functionality. Further, the authentication process 1000 may include a check for third party constraints (e.g., business logic that specifies when and under what circumstances a particular third party's signature may be used, etc.).

Based on the above description, in step 1110, the authentication engine requests a cryptographic key from the data storage facilities D1 through D4 corresponding to the signer. In step 1115, the data storage facilities D1 through D4 transmit their respective portions of the cryptographic key corresponding to the signing party to the cryptographic engine 220. According to one embodiment, the transmission comprises SSL technology. According to another embodiment, the transmission may advantageously be super-encrypted with the public key of the cryptographic engine 220.

In step 1120, cryptographic engine 220 assembles the above-described cryptographic key of the signer and encrypts the message with it, forming a digital signature. In step 1125 of the signing process 1100, the cryptographic engine 220 sends the digital signature to the authentication engine 215. In step 1130, the authentication engine 215 sends the populated authentication request to the transaction engine 205 along with a copy of the hashed message and the digital signature. In step 1135, the transaction engine 205 transmits a receipt to the seller that includes the transaction ID, an indication of whether the authentication was successful, and a digital signature. According to one embodiment, the transmission may advantageously include a digital signature of the trust engine 110. For example, the trust engine 110 may encrypt a hash value of the receipt with its private key, thereby forming a digital signature to be appended to the transmission to the seller.

According to one embodiment, the transaction engine 205 also sends an acknowledgement message to the user. Although the signing process 1100 is disclosed with reference to preferred and alternative embodiments thereof, the present invention is not limited thereto. Rather, the skilled artisan will recognize from the disclosure herein a number of alternatives to the signing process 1100. For example, the vendor may be replaced with a user application, such as an email application. For example, a user may wish to digitally sign a particular email with his or her digital signature. In such an embodiment, advantageously, the transmission throughout the signing process 1100 may include only one copy of the hash value of the message. Furthermore, the skilled artisan will recognize from the disclosure herein that a wide variety of client applications may request digital signatures. For example, the client application may include a word processor, spreadsheet, email, voicemail, access to a restricted system area, and the like.

Furthermore, the skilled artisan will recognize from the disclosure herein that steps 1105 through 1120 of the signing process 1100 may advantageously employ some or all of the steps of the interoperability process 970 of FIG. 9B, thereby providing interoperability between different cryptographic systems that need to process digital signatures under different signature types, for example.

Fig. 12 shows a data flow of an encryption/decryption process 1200 according to aspects of an embodiment of the invention. As shown in fig. 12, the decryption process 1200 begins by authenticating a user using an authentication process 1000. According to one embodiment, the authentication process 1000 includes the sync session key in the authentication request. For example, in conventional PKI technology, skilled artisans appreciate that encryption or decryption using public and private keys is computationally intensive and may require significant system resources. However, in a symmetric key cryptosystem or a system where the sender and receiver of a message share one common key for encrypting and decrypting the message, the mathematical operations are significantly simpler and faster. Thus, in conventional PKI technology, the sender of a message will generate a synchronized session key and encrypt the message using a simpler, faster symmetric key system. The sender then encrypts the session key with the public key of the receiver. The encrypted session key will be appended to the synchronously encrypted message and both data are sent to the recipient. The recipient decrypts the session key using his or her private key and then decrypts the message using the session key. Based on the above description, a simpler and faster symmetric key system is used for most of the encryption/decryption process. Thus, in the decryption process 1200, decryption advantageously assumes that the synchronization key has been encrypted with the user's public key. Thus, as described above, 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, the authentication engine 215 forwards the encrypted session key to the cryptographic engine 220. In step 1210, the authentication engine 215 forwards a request to each of the data storage facilities D1 through D4 requesting the user's cryptographic key data. In step 1215, each of the data storage facilities D1 through D4 transmits their respective portions of the cryptographic key to the cryptographic engine 220. According to one embodiment, the transmission is encrypted with the public key of the cryptographic engine 220.

In step 1220 of the decryption process 1200, the cryptographic engine 220 assembles the cryptographic key and decrypts the session key with it. In step 1225, the cryptographic engine forwards the session key to the authentication engine 215. In step 1227, the authentication engine 215 populates the authentication request including the decrypted session key and sends the populated authentication request to the transaction engine 205. In step 1230, the transaction engine 205 forwards the authentication request along with the session key to the requesting application or vendor. The requesting application or vendor then decrypts the encrypted message using the session key, according to one embodiment.

Although the decryption process 1200 is disclosed with reference to its preferred and alternative embodiments, a skilled artisan will recognize from the disclosure herein a number of alternatives to the decryption process 1200. For example, the decryption process 1200 may precede synchronous key encryption and rely on full public key technology. In such embodiments, the requesting application may send the entire message to the cryptographic engine 220, or may employ some type of compression or reversible hashing to send the message to the cryptographic engine 220. The skilled artisan will also recognize from the disclosure herein that the above communications may advantageously comprise XML documents packaged in SSL technology.

The encryption/decryption process 1200 also provides for encryption of documents or other data. Thus, in step 1235, the requesting application or vendor may advantageously send a request to the transaction engine 205 of the trust engine 110 for the user's public key. The requesting application or vendor generates this request because the requesting application or vendor encrypts a session key that will be used to encrypt the document or message, for example, using the user's public key. As described in the enrollment process 900, the transaction engine 205 stores, for example, a copy of the user's digital certificate in the mass storage 225. Thus, in step 1240 of the encryption process 1200, the transaction engine 205 requests the user's digital certificate from the mass storage 225. In step 1245, the mass storage 225 sends the digital certificate corresponding to the user to the transaction engine 205. In step 1250, the transaction engine 205 sends the digital certificate to the requesting application or vendor. According to one embodiment, the encrypted portion of the encryption process 1200 does not include authentication of the user. This is because the requesting vendor only needs the public key of the user and does not request any sensitive data.

Skilled artisans will recognize from the disclosure herein that if a particular user does not have a digital certificate, the trust engine 110 may employ some or all of the enrollment process 900 to generate a digital certificate for the particular user. The trust engine 110 may then initiate the encryption/decryption process 1200 and thereby provide the appropriate digital certificate. Furthermore, the skilled artisan will recognize from the disclosure herein that steps 1220 and 1235 through 1250 of the encryption/decryption process 1200 may advantageously employ some or all of the steps of the interoperability process of FIG. 9B, thereby providing interoperability between different cryptographic systems that may need to process encryption, for example.

FIG. 13 shows a simplified block diagram of a trust engine system 1300 in accordance with aspects of another embodiment of the present invention. As shown in fig. 13, the trust engine system 1300 includes a plurality of different trust engines 1305, 1310, 1315, and 1320. To facilitate a more complete understanding of the present invention, FIG. 13 illustrates each trust engine 1305, 1310, 1315 and 1320 as having a transaction engine, a repository and an authentication engine. However, the skilled person realizes that each transaction engine may advantageously comprise some, a combination or all of the components and communication channels disclosed with reference to fig. 1 to 8. For example, one embodiment may advantageously include a trust engine having one or more transaction engines, a repository, and a cryptographic server, or any combination thereof.

According to one embodiment of the invention, each of the trust engines 1305, 1310, 1315, and 1320 are geographically separated such that, for example, the trust engine 1305 may reside in a first location, the trust engine 1310 may reside in a second location, the trust engine 1315 may reside in a third location, and the trust engine 1320 may reside in a fourth location. Advantageously, the geographic separation described above reduces system response time while increasing the security of the entire trust engine system 1300.

For example, when a user logs into the password system 100, the user may be closest to a first location and may wish to be authenticated. As described with reference to fig. 10, to obtain authentication, the user provides current authentication data (e.g., biometrics or the like), and the current authentication data is compared with the enrollment authentication data of the user. Thus, according to one example, it is advantageous for a user to provide current authentication data to the geographically closest trust engine 1305. The transaction engine 1321 of the trust engine 1305 then forwards the current authentication data to the authentication engine 1322, which also resides at the first location. According to another embodiment, the transaction engine 1321 forwards the current authentication data to one or more of the authentication engines of the trust engines 1310, 1315, or 1320.

The transaction engine 1321 also requests the assembly of enrollment authentication data from the repository, e.g., each of the trust engines 1305 through 1320. According to this embodiment, each store provides its enrollment authentication data portion to the authentication engine 1322 of the trust engine 1305. The authentication engine 1322 then responds with, for example, encrypted data portions from the first two stores, and assembles the enrollment authentication data into a deciphered form. The authentication engine 1322 compares the enrollment authentication data with the current authentication data and returns the authentication result to the transaction engine 1321 of the trust engine 1305.

Based on the above, the trust engine system 1300 performs an authentication process with the closest one of the plurality of geographically separated trust engines 1305 through 1320. According to one embodiment of the invention, routing of information to the nearest transaction engine may advantageously be performed at a client-side Java applet executing on one or more of the user system 105, vendor system 120 or certificate authority 115. According to an alternative embodiment, a more sophisticated decision process may be employed to select from the trust engines 1305 through 1320. For example, the determination may be based on availability, operability, connection speed, load, performance, geographic proximity, or a combination thereof, of a given trust engine.

In this way, the trust engine system 1300 reduces its response time while maintaining the security advantages associated with geographically remote data storage facilities (e.g., those described with reference to fig. 7, where each data storage facility stores randomized portions of sensitive data). For example, a security hazard at the store 1325, e.g., the trust engine 1315, does not necessarily compromise sensitive data of the trust engine system 1300. This is because storage 1325 contains only undecipherable randomized data, which are completely useless without more data.

According to another embodiment, the trust engine system 1300 may advantageously include a plurality of cryptographic engines arranged similarly to the authentication engine. The cryptographic engine may advantageously perform cryptographic functions, such as those disclosed with reference to fig. 1-8. According to another embodiment, the trust engine system 1300 may advantageously replace multiple authentication engines with multiple cryptographic engines to perform cryptographic functions such as those disclosed with reference to fig. 1-8. According to another embodiment of the invention, the trust engine system 1300 may replace each of the plurality of authentication engines with an engine having some or all of the functionality of the authentication engine, the cryptographic engine, or both disclosed above.

Although the trust engine system 1300 is disclosed with reference to its preferred and alternative embodiments, skilled artisans will recognize that the trust engine system 1300 may include portions of the trust engines 1305 through 1320. For example, the trust engine system 1300 may include one or more transaction engines, one or more repositories, one or more authentication engines, one or more cryptographic engines, or a combination thereof.

FIG. 14 shows a simplified block diagram of a trust engine system 1400 in accordance with aspects of another embodiment of the invention. As shown in fig. 14, the trust engine system 1400 includes a plurality of trust engines 1405, 1410, 1415, and 1420. According to one embodiment, each of the trust engines 1405, 1410, 1415 and 1420 includes some or all of the components of the trust engine 110 disclosed with reference to fig. 1-8. According to this embodiment, when the user system 105, vendor system 120, or client-side Java applet of the certification authority 115 communicates with the trust engine system 1400, these communications are sent to the IP address of each of the trust engines 1405 through 1420. In addition, the behavior of each transaction engine of each of the trust engines 1405, 1410, 1415, and 1420 is similar to the behavior of the transaction engine 1321 of the trust engine 1305 disclosed with reference to FIG. 13. For example, in the authentication process, each transaction engine of each of the trust engines 1405, 1410, 1415, and 1420 sends current authentication data to their respective authentication engines and sends requests to assemble randomized data stored in each repository of each of the trust engines 1405 through 1420. Not all of these communications are shown in fig. 14, as such an illustration would become overly complex. Continuing from the authentication process, each of the repositories then sends its portion of randomized data to each authentication engine of each of the trust engines 1405 through 1420. Each authentication engine of each of the trust engines determines, using its comparator, whether the current authentication data matches the enrollment authentication data provided by the repository of each of the trust engines 1405 through 1420. According to this embodiment, the results of the comparisons made by each authentication engine are then sent to the redundant modules of the other three trust engines. For example, the results from the authentication engine of the trust engine 1405 are sent to the redundant modules of the trust engines 1410, 1415, and 1420. Thus, the redundant module of the trust engine 1405 likewise receives the results of the authentication engines from the trust engines 1410, 1415, and 1420.

FIG. 15 shows a block diagram of the redundancy module of FIG. 14. The redundancy module includes a comparator configured to receive authentication results from the three authentication engines and send the results to a transaction engine of a fourth trust engine. The comparator compares the authentication results from the three authentication engines and if two of the results agree, the comparator concludes that the authentication result should match the authentication results of the two agreeing authentication engines. This result is then sent back to the transaction engine corresponding to the trust engine not associated with the three authentication engines.

Based on the above description, the redundancy module determines an authentication result from data received from an authentication engine that is preferably geographically remote from the trust engine of the redundancy module. By providing such redundancy functionality, the trust engine system 1400 ensures that the compromise of the authentication engine of one of the trust engines 1405 through 1420 is not sufficient to compromise the authentication results of the redundant modules of that particular trust engine. Skilled artisans will recognize that the redundant module functionality of the trust engine system 1400 may also be applied to the cryptographic engines of each of the trust engines 1405 through 1420. However, such cryptographic engine communication is not shown in fig. 14 to avoid complexity. Furthermore, the skilled artisan will recognize that a number of alternative authentication result conflict resolution algorithms for the comparator of FIG. 15 are suitable for use with the present invention.

According to another embodiment of the present invention, the trust engine system 1400 advantageously utilizes redundant modules within the cryptographic comparison step. For example, some or all of the redundancy modules disclosed above with reference to fig. 14 and 15 may advantageously be implemented in a hash comparison process of documents provided by one or more parties during a particular transaction.

While the above invention has been described with respect to certain preferred and alternative embodiments, other embodiments will occur to those skilled in the art based on the disclosure herein. For example, the trust engine 110 may issue a short-term certificate in which a private cryptographic key is issued to a user for a predetermined length of time. For example, current certificate criteria include a validity field that may be set to expire after a predetermined amount of time. Thus, the trust engine 110 may issue a private key to the user, where the private key is valid, for example, within 24 hours. According to such embodiments, the trust engine 110 may advantageously issue a new cryptographic key pair associated with a particular user and then issue the private key of the new cryptographic key pair. Then, once the private cryptographic key is issued, the trust engine 110 immediately expires any internal valid use of such private key, since it can no longer be protected by the trust engine 110.

Furthermore, skilled artisans will recognize that the cryptographic system 100 or trust engine 110 may include the ability to identify any type of device (such as, but not limited to, a laptop, a cellular phone, a network, a biometric device, etc.). According to one embodiment, such identification may come from data provided in a request for a particular service (e.g., a request for authentication to cause access or use, a request for a cryptographic function, etc.). According to one embodiment, the request may include a unique device identifier, such as a processor ID. Alternatively, the request may include data in a particular identifiable data format. For example, mobile and satellite phones often do not include the processing power to full x509.v3 re-encrypted certificates, and therefore do not request them. According to this embodiment, the trust engine 110 may recognize the type of data format provided and simply respond in the same manner.

In additional aspects of the above-described system, context-sensitive authentication may be provided using various techniques, which will be described below. Context sensitive authentication, such as that shown in fig. 16, provides the possibility to evaluate not only the actual data sent by the user when the user attempts to authenticate itself, but also circumstances surrounding the generation and delivery of that data. These techniques may also support transaction-specific trust arbitration between users and the trust engine 110 or between sellers and the trust engine 110, as will be described below.

As described above, authentication is the process of proving that the user is the person he says he is. Typically, authentication requires that some facts be exposed to the authentication authority. The trust engine 110 of the present invention represents an authority to which users must authenticate themselves. The user must show to the trust engine 110 that he is who he says he is by: knowing what only the user should know (knowledge-based authentication), having what only the user should have (token-based authentication), or by becoming what only the user should be (biometric-based authentication).

Examples of knowledge-based authentication include, but are not limited to, passwords, PIN codes, or combination locks. Examples of token-based authentication include, but are not limited to, house keys, physical credit cards, driver's licenses, or specific telephone numbers. Examples of biometric-based authentication include, but are not limited to, fingerprints, handwriting analysis, facial scans, hand scans, ear scans, iris scans, vascular patterns, DNA, voice analysis, or retinal scans.

Each type of authentication has certain advantages and disadvantages and each provides a different level of security. For example, it is generally more difficult to create a fake fingerprint that matches the fingerprint of another person than to eavesdrop on one's password and repeat it. Each type of authentication also requires that the authentication authority know different types of data in order to verify someone using that form of authentication.

As used herein, "authentication" broadly refers to the overall process of verifying the identity of a person as to which he says he is. "authentication technique" refers to a particular type of authentication based on particular knowledge, physical tokens, or biometric readings. "authentication data" refers to information sent to or otherwise presented to a certification authority to establish identity. "enrollment data" refers to data initially submitted to a certification authority to establish a baseline against which the certification data is compared. An "authentication instance" refers to data associated with an attempt to authenticate in accordance with an authentication technique.

The internal protocols and communications involved in authenticating a user are described with reference to fig. 10 above. The portion of this process that performs context-sensitive authentication occurs within the comparison step as shown in step 1045 of fig. 10. This step occurs within the authentication engine 215 and involves assembling enrollment data 410 retrieved from the repository 210 and comparing authentication data provided by the user to it. One particular embodiment of this process is shown in fig. 16 and described below.

In step 1600 of fig. 16, the authentication engine 215 receives the current authentication data provided by the user and enrollment data retrieved from storage. The two sets of data may contain data relating to different authentication techniques. In step 1605, the authentication engine 215 separates the authentication data associated with each individual authentication instance. This is necessary so that the authentication data is compared with an appropriate subset of the user's enrolment data (e.g. the fingerprint authentication data should be compared with the fingerprint enrolment data rather than the password enrolment data).

Typically, authenticating a user involves one or more individual authentication instances, depending on which authentication techniques are available to the user. These methods are limited by the enrollment data provided by the user during his enrollment process (if the user does not provide a retinal scan when enrolling, he will not be able to authenticate himself using the retinal scan) and by the devices currently available to the user (e.g. if the user does not have a fingerprint reader at his current location, fingerprint authentication is not practical). In some cases, a single authentication instance may be sufficient to authenticate a user, however, in some circumstances, a combination of multiple authentication instances may be used to more confidently authenticate a user for a particular transaction.

Each authentication instance includes data related to a particular authentication technology (e.g., fingerprint, password, smart card, etc.) and circumstances surrounding the capture and delivery of the data for that particular technology. For example, a particular instance of attempting to authenticate via a password will produce not only data relating to the password itself, but also contextual data called "metadata" relating to the password attempt. This context data includes information such as: the time at which a particular authentication instance occurred, the network address from which authentication information was passed, and any other information known to those skilled in the art that may be determined as to the origin of the authentication data (type of connection, processor serial number, etc.).

In many cases, only a small amount of contextual metadata is available. For example, if the user is on a network that uses a proxy server or network address translation or another technique that masks the address of the originating computer, only the address of the proxy server or router may be determined. Similarly, in many cases, information such as the processor serial number is not available due to limitations of the hardware or operating system used (system operator disables these features) or other limitations of the connection between the user's system and the trust engine 110.

As shown in fig. 16, once the individual authentication instances represented within the authentication data are extracted and separated in step 1605, the authentication engine 215 evaluates the authenticity of each instance indicating that the user is who he claims to be. Typically, the reliability of a single authentication instance is determined based on several factors. They may be grouped into factors that are evaluated in step 1610 regarding the reliability associated with the authentication technique and factors that are evaluated in step 1815 regarding the reliability of the particular authentication data provided. The first group includes, but is not limited to, the inherent reliability of the authentication technique being used and the reliability of the enrollment data used with the method. The second group includes, but is not limited to, a degree of match between enrollment data and data provided by the authentication instance and metadata associated with the authentication instance. Each of these factors may vary independently of the others.

The inherent reliability of authentication techniques is based on the difficulty of imposters providing others' correct data and the overall error rate of the authentication technique. For password and knowledge based authentication methods, this reliability is often quite low, because one cannot be prevented from revealing their password to another person and the second person using the password. Even more sophisticated knowledge-based systems may still have only moderate reliability, since knowledge is fairly easy to transfer from one person to another. Token-based authentication (e.g. having a correct smart card or performing authentication using a specific terminal) is also less reliable when used by itself, since it cannot be guaranteed that a rightful person has the correct token.

However, the inherent reliability of biometric technology is higher, as it is generally difficult to provide others with the ability to use your fingerprint in a convenient way (even intentionally). Since it is more difficult to break biometric authentication techniques, the inherent reliability of biometric methods is generally higher than purely knowledge or token based authentication techniques. However, even biometric techniques may have some instances of false acceptance or false rejection. These situations can be reflected by the different reliabilities of different implementations of the same biometric technology. For example, a fingerprint matching system provided by one company may provide greater reliability than a fingerprint matching system provided by a different company because one company uses higher quality optics or better scanning resolution or some other improvement that reduces the occurrence of false acceptances or false rejections.

It is noted that the reliability may be expressed in different ways. It is desirable to express reliability in some measure that can be used by the heuristics 530 and algorithms of the authentication engine 215 to compute a confidence level for each authentication. One preferred way to express these reliabilities is a percentage or fraction. For example, a fingerprint may be assigned an intrinsic reliability of 97%, while a password may be assigned an intrinsic reliability of only 50%. Those of ordinary skill in the art will recognize that these specific values are merely exemplary and may vary between specific implementations.

The second factor that must be evaluated for reliability is the reliability of the registration. This is part of the "hierarchical registration" process mentioned above. The reliability factor reflects the reliability of the identification provided during the initial registration process. For example, if an individual initially enrolls in such a way that they physically generate proof of their identity to a notary or other public official, and at this point the data is recorded and notarized, the reliability of the data is stronger than data provided during the enrollment process via the network and vouched for only by a digital signature or other information that does not truly rely on the individual.

Other registration techniques with different reliability levels include, but are not limited to: registration at the physical office of the trust engine 110 operator, registration at the user's employment location, registration at the post office or passport office, registration to the trust engine 110 operator by affiliation or trust, anonymous or penname registration where the identity of the registration has not been identified as a real individual, and other means known in the art.

These factors reflect trust between the trust engine 110 and the identified source provided during the enrollment process. For example, if registration is performed in association with an employer during the initial process of providing identification, this information may be considered very reliable for use within a company, but less trusted by government agencies or competitors. Thus, the trust engine operated by each of these other organizations may assign a different level of reliability to this registration.

Similarly, additional data submitted over the network but authenticated by other trust data previously provided during registration with the same trust engine 110 may be considered as reliable as the original registered data, even if the latter data was submitted over an open network. In such circumstances, subsequent notarization will effectively increase the level of reliability associated with the original enrollment data. Thus, for example, anonymous or pseudonymous registrations may then be promoted to full registrations by presenting the identity of the individual matching the registered data to a certain registration officer.

Generally, the reliability factor described above is a value determined prior to any particular authentication instance. Because they are based on registration and technology rather than actual authentication. In one embodiment, the step of generating a reliability based on these factors includes looking up a previously determined value for this particular authentication technique and the enrollment data of the user. In another aspect of an advantageous embodiment of the invention, these reliabilities may be included in the enrollment data itself. In this way, these factors are automatically passed to the authentication engine 215 along with the enrollment data sent from the repository 210.

Although these factors can generally be determined before any individual authentication instance, they still have an impact on each authentication instance that uses that particular authentication technique for that user. In addition, although these values may change over time (e.g., if the user re-registers in a more reliable manner), they do not depend on the authentication data itself. By contrast, the reliability factor associated with data of a single particular instance may vary for each instance. In step 1815, these factors described below must be evaluated for each new authentication to generate a reliability score.

The reliability of the authentication data reflects the match between the data provided by the user in a particular authentication instance and the data provided within the authentication enrollment process. This is the basic question of whether the authentication data matches the registration data of the individual claimed by the user. Generally, when the data do not match, the user is considered to have not been successfully authenticated and the authentication fails. The manner in which this is evaluated may vary depending on the authentication technique used. The comparison of such data is performed by the comparator 515 function of the authentication engine 215 as shown in fig. 5.

For example, matching of passwords is typically evaluated in a binary manner. In other words, the passwords either match exactly or fail to match. If the password is not completely correct, it is generally not acceptable even if it is a partial match (a password close to the correct password). Thus, when evaluating the password authentication, the reliability of the authentication returned by the comparator 515 is typically either 100% (correct) or 0% (wrong), without the possibility of intermediate values.

Typically, rules similar to those of passwords apply to token-based authentication methods (e.g., smart cards). This is because having a smart card with a similar identifier or similar to the correct smart card is still erroneous as having any other incorrect token. Thus, tokens also tend to be binary authenticated: the user either has the correct token or not.

However, certain types of authentication data (e.g., questionnaires and biometrics) are not typically binary authenticators. For example, fingerprints may be matched to different degrees with reference fingerprints. To some extent, this may be due to variations in the quality of the data captured during the initial enrollment process or during subsequent authentications. (fingerprints may be dirty, or a person has a therapeutic scar or burn on a particular finger). In other cases, the data does not match as perfectly, since the information itself is somewhat variable and based on pattern matching. (the speech analysis may look close but not quite correct due to background noise, or the acoustics of the environment in which the speech is recorded, or due to a human cold). Finally, in the case of a large amount of data to be compared, there are the following cases: many data match well, but some do not. (a questionnaire of ten questions would result in eight correct answers to the individual questions and two incorrect answers). For any of these reasons, it is desirable to assign a partial match value by the comparator 515 to the match between the enrollment data and the data of the particular authentication instance. Thus, for example, a fingerprint may be said to be an 85% match, a voiceprint may be said to be a 65% match, and a questionnaire may be said to be an 80% match.

This measure (degree of match) generated by the comparator 515 is a factor representing a fundamental question of whether the authentication is correct or not. However, as noted above, this is only one of the factors that may be used to determine the reliability of a given authentication instance. Note also that even though some partial degree of matching may be determined, ultimately, it is desirable to provide a binary result based on partial matching. In another mode of operation, partial matches may also be considered binary, i.e., either perfect (100%) or fail (0%), based on whether the degree of match passes a certain threshold match level. Such a process may be used to provide a simple pass/fail level of matching to a system that otherwise generates partial matches.

Another factor to consider in evaluating the reliability of a given authentication instance relates to circumstances under which authentication data for this particular instance is provided. As described above, these circumstances refer to metadata associated with a particular authentication instance. This may include, but is not limited to, the following information: the network address of the authenticator, the time of authentication, the transmission mode of the authentication data (phone line, cellular phone, network, etc.), and the serial number of the system of the authenticator can be determined.

These factors can be used to generate a profile of the type of authentication typically requested by the user. This information can then be used to assess reliability in at least two ways. One way is to consider whether the user is requesting authentication in a manner consistent with a normal profile of authentication for that user. If a user typically makes an authentication request to one network address on weekdays (when she is at work) and to a different network address on the evening or weekend (when she is at home), the authentication that occurs from the home address on weekdays is less reliable because it is outside of the normal authentication profile. Similarly, if a user typically uses fingerprint biometrics and authenticates at night, authentication initiated using only passwords during the day is less reliable.

Another way in which the context metadata can be used to assess the reliability of an instance of authentication is to determine how truly the context-providing authenticator is the person it claims to be. For example, if the authentication is from a system that knows the serial number associated with the user, then this is a good contextual indicator that the user is who they claim to be. Conversely, if the authentication is from a network address known to be located in los angeles and the user is known to be located in london, this is an indication that the authentication is less reliable based on its circumstances.

When a user interacts with the vendor system or trust engine 110, cookies or other electronic data may be placed on the system used by the user. This data is written to the user's system memory and may contain an identification that is readable by the Web browser or other software on the user's system. If this data is allowed to reside on the user's system ("persistent cookie") between sessions, it may be sent with the authentication data during the authentication process of a particular user as further evidence of past use of this system. In fact, the metadata of a given instance (particularly the persistent cookie) may itself form a token-based authenticator.

Once the appropriate reliability factors based on the technology and data of the authentication instance are generated in step 1610 and step 1615, respectively, as described above, they are used to generate the overall reliability of the provided authentication instance in step 1620. One way to do this is to simply represent each reliability as a percentage and then multiply them together.

For example, assume that: authentication data is fed in from a network address that is completely known to the user's home computer based on the user's past authentication profile (100%), the technique used is fingerprinting (97%), initial fingerprint data is registered by the user's employer through the trust engine 110 (90%), and the match between the authentication data and the original fingerprint template in the registered data is very good (99%). The total reliability of this authentication instance can then be calculated as the product of these reliabilities (100% × 97% × 90% × 99% ═ 86.4% reliability).

This computed reliability represents the reliability of an instance of authentication. Techniques that treat different reliability factors differently may also be used, for example, by using formulas that assign different weights to each reliability factor to calculate the overall reliability of an authentication instance. Additionally, one skilled in the art will recognize that the actual values used may represent values other than percentages and that non-arithmetic systems may be used. One embodiment may include a module for use by an authentication requester to set the weight of each factor and the algorithm used to establish the overall reliability of the authentication instance.

The authentication engine 215 may use the above techniques and variations thereof to determine the authenticity of an authentication instance, as shown in step 1620. However, in many authentication scenarios it is useful for multiple authentication instances to be provided simultaneously. For example, when attempting to authenticate itself using the system of the present invention, a user may provide a user identification, fingerprint authentication data, a smart card, and a password. In this case, three separate authentication instances are provided to the trust engine 110 for evaluation. Proceeding to step 1625, if the authentication engine 215 determines that the data provided by the user includes more than one authentication instance, each instance will be selected in turn as shown in step 1630 and evaluated in steps 1610, 1615, and 1620 as described above.

It is noted that many of the described reliability factors differ from one of these examples to another. For example, the inherent reliability of these techniques and the degree of match provided between the authentication data and the enrollment data are likely to be different. In addition, the user may have provided enrollment data for each of these technologies at different times and under different circumstances, as well as providing different enrollment reliabilities for each of these instances. Finally, the use of these techniques may each adapt differently to the user's profile, even if the circumstances under which the data of each of these instances is submitted are the same. (for example, users may use their passwords and fingerprints normally, rather than their smart cards).

As a result, the ultimate reliabilities of each of these authentication instances may differ from one another. However, by using multiple instances together, the overall confidence level of the authentication will tend to increase.

Once the authentication engine has performed steps 1610 through 1620 for all authentication instances provided in the authentication data, the reliability of each instance is used to evaluate the overall authentication confidence level in step 1635. This process of combining individual authentication instance reliabilities into an authentication confidence level may be modeled by various methods related to the individual reliabilities generated, and may also address specific interactions between some of these authentication techniques. (e.g., knowledge-based systems such as passwords may generate lower confidence than a password or even a rather weak biometric such as basic speech analysis).

One way that the authentication engine 215 may combine the reliabilities of multiple concurrent authentication instances to produce a final confidence level is to multiply the unreliability of each instance to arrive at a total unreliability. Generally, unreliability is a complementary percentage of reliability. For example, a 84% reliable technology is 16% unreliable. The three authentication instances described above (fingerprint, smartcard, password) that generate 86%, 75% and 72% reliability will have corresponding (100-86)%, (100-75)% and (100-72)%, or 14%, 25% and 28% unreliability, respectively. By multiplying these unreliability, we get a cumulative unreliability of 14% x 25% x 28%, i.e. an unreliability of 0.98%, which corresponds to a reliability of 99.02%.

In another mode of operation, additional factors and heuristics 530 may be applied within the authentication engine 215 to address the dependencies of various authentication techniques. For example, if someone has unauthorized access to a particular home computer, they are likely to have access to the address's phone line as well. Thus, authentication based on the originating telephone number and the serial number of the authentication system does not increase the overall confidence of the authentication by much. However, knowledge-based authentication is largely independent of token-based authentication (i.e., if someone steals your cell phone or key, they are unlikely to know your PIN or password without your PIN or password).

In addition, different vendors or other authentication requestors may wish to weight different aspects of authentication differently. This may include using separate weighting factors or algorithms for calculating the reliability of each instance and using different ways to evaluate an authentication event with multiple instances.

For example, a vendor of certain types of transactions (e.g., a corporate email system) may wish to authenticate by default based primarily on heuristics and other contextual data. Thus, they may apply high weight to factors related to metadata and other profile-related information associated with the circumstances surrounding the authentication event. This arrangement can be used to reduce the burden on the user during normal work hours by not requiring more from the user than the user logs into the correct machine during work hours. However, another vendor may weigh the authentication the most heavily from a particular technology (e.g., fingerprint matching) because such technology is best suited for policy decisions for authentication for the particular vendor's purpose.

In one mode of operation, these different weights are defined by the supplicant when generating the authentication request, and are sent to the trust engine 110 with the authentication request. In another mode of operation, these options may also be set to preferences for the authentication requester during the initial enrollment process and stored in the authentication engine.

Once the authentication engine 215 has generated an authentication confidence level for the provided authentication data, this confidence level is used to complete the authentication request in step 1640, and this information is forwarded from the authentication engine 215 to the transaction engine 205 for inclusion in the message to the authentication requester.

The above-described process is merely exemplary, and those skilled in the art will recognize that: the steps need not be performed in the order shown, or only certain steps, or various combinations of steps may be desired. Additionally, certain steps (e.g., providing an evaluation of the authenticity of each authentication instance) may be performed in parallel with each other if circumstances permit.

In another aspect of the invention, a method is provided that accommodates situations when the authentication confidence level generated by the above-described process fails to meet the required trust level of the seller or other party requiring authentication. In circumstances where there is a gap between the level of confidence provided and the level of trust desired, for example, the operator of the trust engine 110 can provide one or both parties with the opportunity to provide alternative data or requirements to close this trust gap. This process will be referred to herein as "trust arbitration".

Trust arbitration may occur within the framework of cryptographic authentication described above with reference to fig. 10 and 11. As shown there, the vendor or other party will request authentication of a particular user associated with a particular transaction. In one circumstance, the vendor simply requests authentication (either positive or negative), and upon receiving appropriate data from the user, the trust engine 110 will provide such binary authentication. In circumstances such as these, the confidence required to protect a positive authentication is determined based on preferences set within the trust engine 110.

However, the vendor may also request a particular trust level to complete a particular transaction. This desired level may be included in the authentication request (e.g., to 98% confidence in the authentication of this user), or may be determined by the trust engine 110 based on other factors associated with the transaction (i.e., to properly authenticate this user for this transaction). One such factor may be the economic value of the transaction. For transactions with larger economic values, a higher degree of trust may be required. Similarly, a high degree of trust may be required for transactions with a high degree of risk. Conversely, a vendor or other authentication requestor may require a lower trust level for low risk or low value transactions.

The process of trust arbitration occurs between the step of trust engine 110 receiving the authentication data in step 1050 of FIG. 10 and the step of returning the authentication result to the vendor in step 1055 of FIG. 10. Between these steps, a process occurs as shown in FIG. 17 that results in the evaluation of trust levels and potential trust arbitration. In the case where simple binary authentication is performed, the process shown in figure 17 reduces to having the transaction engine 205 compare the provided authentication data directly with the enrolment data of the identified user, marking any differences as negative authentication, as described above with reference to figure 10.

As shown in fig. 17, the first step after receiving the data in step 1050 is for the transaction engine 205 to determine the level of trust required for a positive authentication for this particular transaction in step 1710. This step can be performed by one of several different methods. When making an authentication request, the authentication requester may specify a required trust level to the trust engine 110. The authentication requester may also preset preferences that are stored in storage 210 or other memory accessible by the transaction engine 205. This preference can then be read and used each time the authentication requester makes an authentication request. The preferences may also be associated with a particular user as a security measure such that a particular trust level is always required to authenticate that user, the user preferences being stored in storage 210 or other storage medium accessible by the transaction engine 205. The required level may also be derived by the transaction engine 205 or the authentication engine 215 based on information provided in the authentication request (e.g., the value and risk level of the transaction to be authenticated).

In one mode of operation, a policy management module or other software used when generating an authentication request is used to specify a required level of trust for authentication of a transaction. This may be used to provide a series of rules to be followed when assigning a required trust level based on policies specified within the policy management module. One advantageous mode of operation is to include such a module within the seller's Web server to properly determine the required trust level for transactions initiated by the seller's Web server. In this way, transaction requests from users may be assigned a desired trust level according to the vendor's policy, and such information may be forwarded to the trust engine 110 along with the authentication request.

This required level of trust is related to the certainty that the seller wishes to have that the personal authentication is in fact the person he recognizes himself. For example, if the transaction is one for which the seller desires a reasonable degree of certainty (since the goods are handedness), the seller may require a trust level of 85%. For situations where the vendor only authenticates the user to allow him to view membership content or practice privileges in a chat room, the adverse risk is small enough that the vendor only requires a 60% trust level. However, in order to participate in a ten thousand dollar production contract, a vendor may require a 99% or higher level of trust.

This required trust level represents a measure of how well the user must authenticate himself to complete the transaction. For example, if the required trust level is 85%, the user must provide the trust engine 110 with sufficient authentication for the trust engine 110 to say with 85% confidence that the user is who they say they are. This is a balance between the required trust level and the authentication confidence level that generates a positive authentication (to the satisfaction of the seller) or possible trust arbitration.

As shown in fig. 17, after the transaction engine 205 receives the required trust level, the required trust level is compared to an authentication confidence level (discussed with reference to fig. 16) that the authentication engine 215 calculates for the current authentication in step 1720. If the authentication confidence level is higher than the required trust level for the transaction in step 1730, the process moves to step 1740 and the transaction engine 205 generates a positive authentication for this transaction in step 1740. A message indicating this will then be inserted into the authentication result and returned to the vendor by the transaction engine 205, as shown in step 1055 (see fig. 10).

However, if the authentication confidence level does not meet the required confidence level in step 1730, then a confidence gap exists for the current authentication and trust arbitration occurs in step 1750. Trust arbitration is described more fully below with reference to FIG. 18. This process described below occurs within the transaction engine 205 of the trust engine 110. This process may be performed outside of the authentication engine 215, since authentication or other cryptographic operations (other than those required for SSL communication between the transaction engine 205 and other components) are not required to perform trust arbitration. However, as described below, any re-evaluation of the authentication data or other password or authentication event will require the transaction engine 205 to re-submit the appropriate data to the authentication engine 215. Those skilled in the art will recognize that the trust arbitration process may instead be structured to occur partially or entirely within the authentication engine 215 itself.

As described above, trust arbitration is the process by which the trust engine 110 mediates negotiations between vendors and users in an attempt to properly ensure positive authentication. As shown at step 1805, the transaction engine 205 first determines whether the current situation is suitable for trust arbitration. This may be determined based on the circumstances of the authentication (e.g., whether this authentication has undergone multiple rounds of arbitration) and the vendor or user's preferences, as will be discussed further below.

In these circumstances where arbitration is not possible, the process proceeds to step 1810, where the transaction engine 205 generates a negative authentication and then inserts it into the authentication result, which is sent to the seller in step 1055 (see FIG. 10). One limitation that may be advantageously used to prevent authentication from being pending indefinitely is to set a timeout period from the initial authentication request. In this way, any transaction that has not been positively authenticated within the time limit is denied further arbitration and is negatively authenticated. Those skilled in the art will recognize that such time limits may vary depending on the circumstances of the transaction and the desires of the user and vendor. The number of attempts that can be made in providing successful authentication may also be limited. These limits may be handled by an attempt limiter 535 as shown in fig. 5.

If arbitration is not disabled at step 1805, the transaction engine 205 will then negotiate with one or both of the transaction parties. As shown in step 1820, the transaction engine 205 may send a message to the user requesting some form of additional authentication to increase the generated authentication confidence level. In its simplest form, this may simply indicate that the authentication is insufficient. A request to generate one or more additional authentication instances to increase an overall confidence level of the authentication may also be sent.

If the user provides some additional authentication instances in step 1825, the transaction engine 205 adds these authentication instances to the transaction's authentication data and sends it to the authentication engine 215, as shown in step 1015 (see FIG. 10), and re-evaluates the authentication based on the pre-existing authentication instance for this transaction and the newly provided authentication instance.

An additional type of authentication may be a request from the trust engine 110 for some form of person-to-person contact between the trust engine 110 operator (or trusted partner) and the user, for example by a telephone call. This phone call or other non-computer authentication can be used to provide a private contact with the individual and perform some form of questionnaire-based authentication. This may also give the opportunity to verify the originating telephone number and potential user voice parsing when incoming calls. Even if additional authentication data cannot be provided, the additional context associated with the user's phone number may still improve the reliability of the authentication context. Any revised data or circumstances based on this phone call are fed into the trust engine 110 for consideration of the authentication request.

Further, in step 1820, the trust engine 110 may provide the user with an opportunity to purchase insurance, thereby effectively purchasing a more confident authentication. The operator of the trust engine 110 may sometimes only wish to make this option available if the confidence level of the authentication is above a certain threshold. In effect, this user-side insurance is the way in which the trust engine 110 vouches for the user when the authentication meets the normal required trust level for the trust engine 110 for the authentication, but does not meet the required trust level for the seller of this transaction. In this way, a user can successfully authenticate to a very high level required by the vendor even if he only has authentication instances that generate sufficient confidence for the trust engine 110.

This functionality of the trust engine 110 allows the trust engine 110 to vouch for someone who is authenticated as satisfying the trust engine 110, rather than satisfying the vendor. This is similar to the function performed by a notary when adding the notary's signature to a document to indicate to someone reading the document later that the person whose signature appears on the document is actually the person who signed it. The notary's signature validates the user's signed action. In the same way, the trust engine provides an indication that the person performing the transaction is who they say they are.

However, because the trust engine 110 manually boosts the confidence level provided by the user, there is a greater risk to the trust engine 110 operator because the user does not actually meet the vendor's desired trust level. The cost of insurance is designed to offset the risk of false positive authentication to the trust engine 110 (which can effectively justify the user's authentication). The user pays the trust engine 110 operator to risk authenticating to a higher confidence level than actually provided.

Since such an insurance system allows someone to effectively purchase a higher confidence level from the trust engine 110, both the vendor and the user may wish to prevent the use of user-side insurance in certain transactions. Vendors may wish to limit positive authentication to the point where they know that the actual authentication data supports the confidence they require, and thus may indicate to the trust engine 110 that user-side insurance is not allowed. Similarly, to protect his online identity, the user may wish to prevent the use of user-side insurance on his account or may wish to limit its use to situations where the authentication confidence level of no insurance is above a certain limit. This can be used as a security measure to prevent someone from eavesdropping on a password or stealing a smart card and using them to impersonate an authentication to a low confidence level and then purchase insurance to generate a very high (false) confidence level. These factors may be evaluated in determining whether user-side insurance is allowed.

If the user purchases insurance in step 1840, the authentication confidence level is adjusted based on the purchased insurance in step 1845, and the authentication confidence level is again compared to the required trust level in step 1730 (see FIG. 17). The process continues from step 1730 and may result in a positive authentication in step 1740 (see fig. 17) or return to the trust arbitration process in step 1750 to arbitrate further, if allowed, or a negative authentication in step 1810 if further arbitration is prohibited.

In addition to sending a message to the user in step 1820, the transaction engine 205 may also send a message to the vendor in step 1830 indicating that the pending authentication is currently below the required trust level. The message may also provide various options regarding how to proceed to the seller. One of these options is to simply inform the seller what the current authentication confidence level is and ask whether the seller wishes to maintain their current unsatisfied required confidence level. This is beneficial because in some cases the vendor may have a separate means for authenticating the transaction or may have used a default set of requirements that typically results in an initial assignment of a higher required level than is actually required for the particular transaction at hand.

For example, it is standard practice that all incoming purchase order transactions with the seller are expected to meet a 98% trust level. However, if the order was recently discussed by telephone between the seller and the long-term customer, and the transaction was authenticated immediately thereafter, but only to a 93% confidence level, the seller may wish to simply lower the acceptance threshold for this transaction because the telephone call effectively provides additional authentication to the seller. In some circumstances, vendors may be willing to lower their required trust level, but not always to the current authentication trust level. For example, the vendor in the above example may consider that a phone call before an order may have a 4% reduction in required confidence, however, this is still greater than the 93% confidence generated by the user.

If the vendor does adjust their required trust level in step 1835, the authentication confidence level generated by the authentication is compared to the required trust level in step 1730 (see FIG. 17). If the confidence level now exceeds the required trust level, a positive authentication may be generated in the transaction engine 205 in step 1740 (see FIG. 17). If not, further arbitration may be attempted as described above if allowed.

In addition to requesting an adjustment to the required trust level, the transaction engine 205 may also provide vendor-side insurance to the vendor requesting authentication. This insurance serves the same purpose as described above for user-side insurance. Here, however, the cost does not correspond to the risk borne by the trust engine 110 in the actual authentication confidence level generated by the above authentication, and the cost of the insurance corresponds to the risk borne by the seller in accepting a low trust level in the authentication.

Rather than just reducing their actual required trust level, sellers may choose to purchase insurance to protect themselves from the additional risks associated with a low trust level in user authentication. As described above, it is advantageous for the seller to consider purchasing only such insurance to cover the trust gap, provided that the existing certification is already above a certain threshold.

Obtaining such vendor-side insurance allows the vendor the following options: directly reducing his trust requirements without additional costs to himself; risk of self-error authentication (based on a required low trust level); or to purchase insurance against a trust gap between the authentication confidence level and his requirements, where the risk of a low confidence level having been provided is taken up by the trust engine 110 operator. By purchasing insurance, the seller effectively maintains his high trust level requirements because the risk of misidentification is transferred to the trust engine 110 operator.

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

It is noted that it is also possible that both the user and the vendor respond to messages from the trust engine 110. Those skilled in the art will recognize that there are a variety of ways in which these situations can be handled. One advantageous mode of handling the possibility of multiple responses is to simply handle the responses in a first-come-first-served manner. For example, if the seller responds with a reduced required trust level and the user also purchases insurance immediately thereafter to increase his authentication level, the authentication is first re-evaluated based on the reduced trust requirements from the seller. If the authentication is now positive, the user's insurance purchase is ignored. In another advantageous mode of operation, the user may be charged only for the level of insurance required to meet the new reduced seller's trust requirements (if a trust gap still exists even if the seller's trust requirements are reduced).

If no response is received from either party within the time limit set for authentication during the trust arbitration in step 1850, the arbitration is re-evaluated in step 1805. This effectively starts the arbitration process again. If the time limit expires at step 1805 or other circumstances prevent further arbitration, a negative authentication is generated by the transaction engine 205 at step 1810 and returned to the seller (see FIG. 10) at step 1055. Otherwise, a new message may be sent to the user and the vendor, and the process may be repeated as desired.

It is noted that for some types of transactions, for example, digitally signing a document that is not part of the transaction, there is not necessarily a vendor or other third party, and thus the transaction is primarily between the user and the trust engine 110. In circumstances such as these, the trust engine 110 will have its own required level of trust that must be satisfied to produce a positive authentication. However, in these circumstances, it is often undesirable for the trust engine 110 to provide insurance to the user so that he can raise the confidence of his own signature.

The processes described above and shown in fig. 16-18 may be performed using various communication modes described above with reference to the trust engine 110. For example, these messages may be web-based and sent using an SSL connection between the trust engine 110 and a Java applet downloaded in real time to a browser running on the user or vendor system. In another mode of operation, certain specialized applications that facilitate such arbitration and insurance transactions may be used by users and vendors. In another mode of operation, secure e-mail operations may be used to mediate the above-described arbitration, thereby enabling batch processing of delayed evaluations and authentications. Those skilled in the art will recognize that different communication modes may be applicable to the vendor's authentication requirements and circumstances.

The following description of FIG. 19 describes a sample transaction that incorporates various aspects of the present invention described above. This example illustrates the entire process between a user mediated by the trust engine 110 and a vendor. While the various steps and components described in detail above may be used to perform the following transactions, the illustrated process focuses on interactions between the trust engine 110, the user, and the vendor.

In step 1900, the transaction begins when the user fills out an order form on the vendor's website while viewing the web page online. The user wishes to submit this order form, signed with his digital signature, to the seller. To do so, the user submits the order form and his request for a signature to the trust engine 110 in step 1905. The user will also provide authentication data that will be used to authenticate his identity as described above.

In step 1910, the authentication data is compared to the enrollment data by the trust engine 110 as described above, and if a positive authentication is generated, the hash value of the order form signed with the user's private key is forwarded to the vendor along with the order form itself.

In step 1915, the seller receives the signed form, and then in step 1920, the seller will generate an invoice or other contract relating to the purchase to be made. In step 1925, this contract and the request for signature are sent back to the user. In step 1930, the vendor also sends an authentication request (including the hash value of the contract to be signed by both parties) for this contract transaction to the trust engine 110. To allow the contract to be digitally signed by both parties, the seller also includes authentication data for itself to enable later verification of the seller's signature on the contract, if necessary.

The trust engine 110 then verifies the authentication data provided by the seller to confirm the identity of the seller, as described above, and continues from step 1955 when data is received from the user if the data generates a positive authentication in step 1935. If the seller's authentication data does not match the seller's enrollment data to the desired extent, a message is returned to the seller requesting further authentication. As described above, in order for the seller to successfully authenticate itself to the trust engine 110, trust arbitration may be performed here, if desired.

When the user receives the contract at step 1940, he checks the contract, generates authentication data to sign it if the contract is acceptable at step 1945, and then sends the hash value of the contract along with his authentication data to the trust engine 110 at step 1950. In step 1955, the trust engine 110 verifies the authentication data and, if the authentication is good, proceeds to process the contract as described below. As described above with reference to fig. 17 and 18, trust arbitration may be performed as appropriate to bridge any trust gap that exists between the authentication confidence level and the desired authentication level for the transaction.

In step 1960, the trust engine 110 signs the hash value of the contract with the user's private key and sends the signed hash value to the vendor, signing the complete message on behalf of itself, i.e., including the hash value of the complete message (including the user's signature) encrypted with the trust engine's 110 private key 510. In step 1965, this message is received by the seller. The message represents a signed contract (the hash of the contract encrypted using the user's private key) and a receipt from the trust engine 110 (the hash of the message including the signed contract encrypted using the trust engine's 110 private key).

In step 1970, the trust engine 110 similarly prepares a hash value for the contract with the seller's private key and forwards this contract, signed by the trust engine 110, to the user. Thus, in step 1975, the user also receives a copy of the contract signed by the seller and a receipt signed by the trust engine 110 that delivers the signed contract.

In addition to the above, additional aspects of the invention provide a cryptographic Service Providing Module (SPM) that can be used by client-side applications as a means of accessing the functionality provided by the trust engine 110 described above. One advantageous way in which the cryptographic SPM provides such services is to mediate communications between a third party Application Programming Interface (API) and the trust engine 110, which is accessible via a network or other remote connection. The sample crypto SPM is described below with reference to fig. 20.

For example, on a typical system, a programmer may use multiple APIs. Each API provides a set of function calls that may be made by an application 2000 running on the system. Examples of APIs that provide programming interfaces suitable for cryptographic functions, authentication functions, and other security functions include the cryptographic API (capi)2010 provided by microsoft in its Windows operating system and the public data security architecture (CDSA) initiated by IBM, Intel, and other members of the open group. In the discussion that follows, CAPI will be used as an exemplary security API. However, the cryptographic SPM described may also be used with a CDSA or other security API known in the art.

This API is used by the user system 105 or the vendor system 120 when the password function is invoked. Included among these functions may be requests associated with performing various cryptographic operations, such as encrypting a document with a particular key, signing a document, requesting a digital certificate, verifying a signature on a signed document, and other cryptographic functions described herein or known to those skilled in the art.

Typically, these cryptographic functions are performed locally on the system in which CAPI2010 resides. This is because the generally invoked function requires a software function that is programmed using a resource of the local user system 105 (e.g., a fingerprint reader) or using a library executing on the local machine. Access to these local resources is typically performed by one or more Service Providing Modules (SPMs) 2015, 2020 mentioned above that provide resources for use in performing cryptographic functions. These SPMs may include a software library 2015 that performs encryption or decryption operations or a driver and application 2020 that has access to dedicated hardware 2025 (e.g., a biometric scanner). Much like the way in which CAPI2010 provides functionality that can be used by applications 2000 of system 105, SPMs 2015, 2020 provide CAPI with access to low-level functions and resources associated with available services on the system.

According to the present invention, a cryptographic SPM2030 may be provided that is capable of accessing cryptographic functions provided by the trust engine 110 and making these functions available to the application 2000 through the CAPI 2010. Unlike embodiments in which CAPI2010 only has access to resources that are locally available through SPMs 2015 and 2020, the cryptographic SPM2030 described herein will be able to submit a request for cryptographic operations to a remotely located network accessible trust engine 110 to perform the desired operations.

For example, if the application 2000 requires a cryptographic operation, such as signing a document, the application 2000 makes a function call to the appropriate CAPI2010 function. CAPI2010 would then perform this function, utilizing the resources made available through SPMs 2015 and 2020 and cryptographic SPM 2030. In the case of a digital signature function, the cryptographic SPM2030 will generate an appropriate request to be sent to the trust engine 110 over the communication link 125.

The operations that occur between the cryptographic SPM2030 and the trust engine 110 are the same operations that can be performed between any other system and the trust engine 110. However, these functions may be made available to the user system 105 through CAPI2010, making them appear to be available locally to the user system 105 itself. However, unlike ordinary SPMs 2015 and 2020, these functions are performed on the remote trust engine 110 and, in response to appropriate requests, the results are relayed to the cryptographic SPM2030 via the communication link 125.

This cryptographic SPM2030 makes a large number of operations available to the user system 105 or vendor system 120 that may not otherwise be available. These functions include, but are not limited to: encryption and decryption of documents, issuance of digital certificates, digital signature of documents, verification of digital signatures, and other operations that will be apparent to those skilled in the art.

In a separate embodiment, the present invention includes a complete system for performing the data protection method of the present invention on any data set. The computer system of this embodiment includes a data splitting module that includes the functionality shown in fig. 8 and described herein. In one embodiment of the invention, the data splitting module, sometimes referred to herein as a secure data parser, comprises a parser program or software suite that includes data splitting, encryption and decryption, reconstruction, or repacking functions. This embodiment may also include one data storage facility or a plurality of data storage facilities. The data splitting module or the secure data parser comprises a suite of cross-platform software modules that are integrated within the electronic infrastructure or as an adjunct to any application that requires maximum security of its data elements. This parsing process operates on any type of data set, and on any and all file types, or on any row or column or cell of data in the database, in the database.

In one embodiment, the parsing process of the present invention may be designed in a modular hierarchical fashion, and any encryption process is suitable for use with the process of the present invention. The module layers of the parsing and splitting process of the present invention may include, but are not limited to: 1) the password is split, and is dispersed and safely stored in a plurality of positions; 2) encryption, password splitting, scattering and safe storage in a plurality of positions; 3) encrypting, splitting a password, encrypting each share, and then dispersing and safely storing the encrypted shares in a plurality of positions; and 4) encryption, password splitting, encryption of each share with a different type of encryption than that used in the first step, and then distributed and securely stored in multiple locations.

In one embodiment, this process includes splitting the data based on the content of the generated random number or key, and performing the same cipher splitting on the key used in the encryption of the parsed or split data (preferably, in one embodiment, four or more portions of parsed and split data) that splits the data to be protected into two or more portions or shares, encrypting all of the portions, and then dispersing and storing the portions back in the database or relocating them to any designated device, fixed or removable, as required by the requestor for privacy and security. Alternatively, in another embodiment, encryption may be performed prior to splitting of the data set by the splitting module or the secure data parser. The original data processed as described in this embodiment is encrypted and scrambled and protected. Indeed, if desired, the encrypted elements may be dispersed anywhere, including but not limited to a single server or data storage device, or between multiple independent data storage facilities or devices. In one embodiment, the encryption key management may be included within the software suite, or in another embodiment, may be integrated into an existing infrastructure or any other desired location.

Cipher-splitting (cipher-splitting) divides the data into N shares. The partitioning may be based on data units of any size, including any pattern or combination of one bit, multiple bits, bytes, kilobytes, megabytes, or larger units, and predetermined or randomly generated data unit sizes. The cells may also have different sizes 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 manner, the size of the data units themselves may make the data more secure, for example, by using a pattern, sequence, or combination of one or more predetermined or randomly generated data unit sizes. These cells are then distributed (randomly or according to a set of predetermined values) into N shares. The distribution may also involve scrambling (shuffle) the order of the units in each share. It will be readily apparent to one of ordinary skill in the art that the distribution of data units into multiple shares may be performed according to a wide variety of possible choices, including but not limited to one or more combinations, patterns, or sequences of fixed size, predetermined size, or predetermined or randomly generated data unit size.

One example of such a cipher splitting process or cipher splitting would consider a data size of 23 bytes, a data unit size chosen to be 1 byte, and a selected number of copies to be 4. Each byte will be distributed into one of these 4 shares. Assuming a random distribution, the key will be obtained to establish a sequence of 23 random numbers (r1, r2, r3 through r23), where each random number has a value of 1 through 4 corresponding to the 4 shares. Each unit of data (in this example, 23 independent bytes of data) is associated with one of 23 random numbers corresponding to one of 4 shares. Bytes of data may be distributed into these 4 shares by placing the first byte of data into the share number r1, the second byte into the share r2, the third byte into the share r3 only until the 23 rd byte of data is placed into the share r 23. Those of ordinary skill in the art will readily appreciate that a wide variety of other possible steps or combinations or sequences of steps (including the size of a data unit) may be used in the cryptographic splitting process of the present invention, and the above example is a non-limiting description of one process for cryptographic splitting of data. To reconstruct the original data, the reverse operation will be performed.

In another embodiment of the cryptographic splitting process of the present invention, the option for the cryptographic splitting process is to provide sufficient redundancy in the shares so that only a subset of the shares is needed to be able to reassemble or restore the data into its original or useable form. As a non-limiting example, the cryptographic split may be performed in accordance with a "3 out of 4" cryptographic split, such that only 3 of the 4 shares are needed to reassemble or restore the data to its original or usable form. This is also referred to as "N-out-of-M cipher splitting," where N is the total number of copies and M is at least 1 less than N. Those of ordinary skill in the art will readily appreciate that there are many possibilities for establishing such redundancy during the cryptographic splitting process of the present invention.

In one embodiment of the cryptographic splitting process of the present invention, each unit of data is stored in two shares (a primary share and a backup share). Using the "3 out of 4" cryptographic splitting process described above, any one share can be lost, and since only 3 out of the 4 shares are needed, this is still sufficient to reassemble or recover the original data without losing data units. Random numbers are generated corresponding to one of these shares, as described herein. Based on the key, the random number is associated with the data unit and stored in the corresponding share. In this embodiment, one key is used to generate the primary and backup share random numbers. As described herein, for the cryptographic splitting process of the present invention, a set of random numbers (also referred to as prime numbers) from 0 to 3 is generated equal to the number of data units. Then, another set of random numbers (also called backup numbers) from 1 to 3 equal to the number of data units is generated. Each unit of data is then associated with a primary share number and a backup share number. Alternatively, a set of random numbers less than the number of data units may be generated and repeated, but this reduces the security of the sensitive data. The primary copy number is used to determine in which copy the data unit is stored. The backup share number is combined with the primary share number to establish a third share number of 0 to 3, and this number is used to determine in which share the data unit is stored. In this example, the equation used to determine the third digit is:

(primary share number + backup share number) MOD4 ═ third share number

In the above-described embodiments where the primary share numbers are 0 to 3 and the backup share numbers are 1 to 3, it is ensured that the third share number is different from the primary share number. This results in the data unit being stored in two different shares. One of ordinary skill in the art will readily appreciate that there are many ways to perform redundant and non-redundant cryptographic splitting in addition to the embodiments disclosed herein. For example, different algorithms may be used to shuffle the data units in each share. For example, the data unit scrambling may be performed when the original data is split into a plurality of data units, or after the data units are placed into shares, or after the shares are full.

The various cryptographic splitting processes and data shuffling processes described herein, as well as all other embodiments of the cryptographic splitting and data shuffling methods of the present invention, may be performed on data units of any size, including but not limited to one bit, multiple bits, bytes, kilobytes, megabytes, or greater.

An example of one embodiment of source code that performs the cryptographic splitting process described herein is:

an example of one embodiment of source code to perform the cryptographically split RAID process described herein is:

Two sets of numbers are generated, PrimaryShare is 0 to 3 and BackupShare is 1 to 3. Each data unit is then placed in share [ primaryshare [1] ] and share [ (primaryshare [1] + backup upshare [1]) mod4] following the same procedure as the above described cipher splitting. This method can be adjusted to any size N, where only N-1 shares are needed to recover the data.

The acquisition, reassembly, or reconstruction of the encrypted data elements may utilize any number of authentication techniques, including but not limited to biometrics, such as fingerprint recognition, facial scan, hand scan, iris scan, retinal scan, ear scan, blood vessel pattern recognition, or DNA analysis. The data splitting and/or parser modules of the present invention may be integrated into a wide variety of base products or applications, as desired.

Conventional encryption techniques known in the art rely on one or more keys for encrypting data and are made unavailable without keys. However, the data is still monolithic and complete and vulnerable. In one embodiment, the secure data parser of the present invention solves this problem by performing cryptographic parsing on the encrypted file and splitting into two or more parts or shares (preferably 4 or more shares in another embodiment), adding another layer of encryption to each data share, and 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 (e.g., a data storage device) or by placing the shares under control of another party, any possibility of harm to the protected data is effectively removed.

An example of one embodiment of the secure data parser of the present invention and an example of how it may be utilized is shown in FIG. 21 and described below. However, one of ordinary skill in the art will readily appreciate that the secure data parser of the present invention may be utilized in a wide variety of ways, in addition to the following non-limiting examples. As a deployment option, in one embodiment, the secure data parser may be implemented through external session key management or secure internal storage of session keys. When implemented, a parser master key will be generated, which will be used for protection applications as well as encryption purposes. It should also be noted that by adding the parser master key to the resulting protected data, flexibility in sharing the protected data by individuals within a workgroup, business, or extended audience may be achieved.

As shown in fig. 21, this embodiment of the invention shows the steps of performing the process of storing the session master key with the parsed data by the secure data parser on the data:

1. a session master key is generated and the data is encrypted using RS1 stream cipher.

2. The resulting encrypted data is split into four shares or portions of parsed data according to the pattern of the session master key.

3. In this embodiment of the invention, the session master key will be stored in the data store along with the protected data shares. The session master key is separated according to the schema of the parser master key and the key data is appended to the encrypted parsed data.

4. The resulting four shares will contain portions of the encrypted original data as well as portions of the session master key. A stream cipher key is generated for each of the four shares of data.

5. Each share is encrypted and then the encryption key is stored in a different location than the encrypted data portion or share: share 1 gets key 4, share 2 gets key 1, share 3 gets key 2, share 4 gets key 3.

These steps are reversed in order to recover the original data format.

One of ordinary skill in the art will readily appreciate that certain steps of the methods described herein may be performed in a different order or repeated as many times as desired. It will also be readily appreciated by those skilled in the art that these data portions may be processed in different ways from one another. For example, multiple parsing steps may be performed on only one portion of the parsed data. Each portion of parsed data may be uniquely protected in any desired manner so long as the data can be reassembled, reconstructed, reformed, decrypted, or otherwise restored to its original or other usable form.

As shown in fig. 22 and described herein, another embodiment of the present invention includes the steps of a process performed by the secure data parser on data to store session master key data in one or more separate key management tables:

1. a session master key is generated and the data is encrypted using RS1 stream cipher.

2. The resulting encrypted data is split into four shares or portions of parsed data according to the pattern of the session master key.

3. In this embodiment of the method of the present invention, the session master key will be stored in a separate key management table in the data store. A unique transaction ID is generated for this transaction. The transaction ID and the session master key are stored in separate key management tables. The transaction ID is separated according to the pattern of the parser master key and the data is attached to the encrypted parsed data or the separated data.

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

5. A stream cipher key is generated for each of the four shares of data.

6. Each share is encrypted and then the encryption key is stored in a different location than the encrypted data portion or share: share 1 gets key 4, share 2 gets key 1, share 3 gets key 2, share 4 gets key 3.

These steps need to be reversed in order to recover the original data format.

One of ordinary skill in the art will readily appreciate that certain steps of the methods described herein may be performed in a different order or repeated as many times as desired. It will also be readily appreciated by those skilled in the art that these data portions may be processed in different ways from one another. For example, multiple separation or parsing steps may be performed on only one portion of the parsed data. The various portions of parsed data may be uniquely protected in any desired manner so long as the data can be reassembled, reconstructed, reformed, decrypted or otherwise restored to its original or other usable form.

As shown in fig. 23, this embodiment of the invention shows the steps of the process performed by the secure data parser on data to store the session master key and parse the data:

1. a resolver master key associated with the authenticated user is accessed.

2. A unique session master key is generated.

3. The intermediate key is derived from an exclusive or function of the parser master key and the session master key.

4. The data is optionally encrypted using an existing or new encryption algorithm with the intermediate key as the key.

5. The resulting optionally encrypted data is split into four shares or portions of parsed data according to the pattern of the intermediate key.

6. In this embodiment of the method, the session master key will be stored in the data store along with the protected data shares. The session master key is separated according to the schema of the parser master key and key data is appended to the optionally encrypted parsed data shares.

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

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

9. Optionally, each share is encrypted with an existing or new encryption algorithm, and then the encryption key is stored in a different location than the encrypted data portion or share: for example, share 1 gets key 4, share 2 gets key 1, share 3 gets key 2, and share 4 gets key 3.

These steps need to be reversed in order to recover the original data format.

One of ordinary skill in the art will readily appreciate that certain steps of the methods described herein may be performed in a different order or repeated as many times as desired. It is also readily understood by those skilled in the art that these data portions may be processed differently from each other. For example, multiple parsing steps may be performed on only one portion of the parsed data. Each portion of parsed data may be uniquely protected in any desired manner so long as the data can be reassembled, reconstructed, reformed, decrypted, or otherwise restored to its original or other usable form.

As shown in FIG. 24 and described herein, another embodiment of the present invention includes the steps of a process performed by the secure data parser on data to store session master key data in one or more separate key management tables:

1. a resolver master key associated with the authenticated user is accessed.

2. A unique session master key is generated.

3. The intermediate key is derived from an exclusive or function of the parser master key and the session master key.

4. The data is optionally encrypted using an existing or new encryption algorithm with the intermediate key as the key.

5. The resulting optionally encrypted data is split into four shares or portions of parsed data according to the pattern of the intermediate key.

6. In this embodiment of the method of the present invention, the session master key will be stored in a separate key management table within the data store. A unique transaction ID is generated for this transaction. The transaction ID and the session master key are stored in separate key management tables or the session master key and the transaction ID are passed back to the caller for external management. The transaction ID is separated according to the pattern of the parser master key and data is attached to the optionally encrypted parsed data or separated data.

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

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

9. Alternatively, each share is encrypted and then the encryption key is stored in a different location than the encrypted data portion or share. For example, share 1 gets key 4, share 2 gets key 1, share 3 gets key 2, and share 4 gets key 3.

These steps need to be reversed in order to recover the original data format.

One of ordinary skill in the art will readily appreciate that certain steps of the methods described herein may be performed in a different order or repeated as many times as desired. It is also readily understood by those skilled in the art that these data portions may be processed differently from each other. For example, multiple separation or parsing steps may be performed on only one portion of the parsed data. Each portion of parsed data may be uniquely protected in any desired manner so long as the data can be reassembled, reconstructed, reformed, decrypted, or otherwise restored to its original or other usable form.

Those skilled in the art will readily appreciate that a wide variety of encryption methods are suitable for use with the method of the present invention. The One Time Pad (One Time Pad) algorithm is often considered One of the most secure encryption methods and is applicable to the method of the present invention. Using the one-time pad algorithm requires that keys be generated that are as long as the data to be protected. This approach is less desirable in certain circumstances, such as where very long keys are generated and managed due to the size of the data set to be protected. In the one-time pad (OTP) algorithm, a simple XOR function XOR is used. For two binary streams x and y of the same length, x XOR y refers to the bit-wise XOR of x and y.

At the bit level, the following are generated:

0 XOR 0＝0

0 XOR 1＝1

1 XOR 0＝1

1 XOR 1＝0

an example of this process is described herein for an n-byte secret s (or data set) to be split. This process will produce an n-byte random value a and then set:

b＝a XOR s。

note that "s" can be derived by:

s＝a XOR b。

the values a and b are referred to as shares or portions and are located in separate reservoirs. Once the secret s is split into two or more shares, it is discarded in a secure manner.

The secure data parser of the present invention may utilize this function to perform a plurality of XOR functions incorporating a plurality of different secret key values K1, K2, K3, Kn, K5. At the start of the operation, the data to be protected is passed to the first encryption operation, the security data being the data XOR secret key 5:

S＝D XOR K5

to securely store the resulting encrypted data in, for example, four shares S1, S2, S3, Sn, the data is parsed and split into "n" segments or shares according to the value of K5. This operation produces "n" pseudorandom shares of the original encrypted data. The following XOR function may then be performed on each share with the remaining secret key values, for example: secure data segment 1 ═ encrypted data share 1XOR 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 for any one store to contain enough information to decrypt the information it holds, so that the keys needed to decrypt the shares are stored in different data stores:

A storage 1: SD1, Kn

A storage 2: SD2, K1

A storage 3: SD3, K2

A storage n: SDn, K3

In addition, information required to obtain the original session encryption key K5 may be attached to each share. Thus, in the key management example described herein, the original session master key is referenced by a transaction ID split into "n" shares depending on the content of the installed resolver master key (TID1, TID2, TID3, TIDn):

a storage 1: SD1, Kn, TID1

A storage 2: SD2, K1, TID2

A storage 3: SD3, K2, TID3

A storage n: SDn, K3, TIDn

In the join session key example described herein, the session master key is split into "n" shares depending on the content of the installed parser master key (SK1, SK2, SK3, SKn):

a storage 1: SD1, Kn, SK1

A storage 2: SD2, K1, SK2

A storage 3: SD3, K2, SK3

A storage n: SDn, K3, SKn

According to this example, data cannot be reassembled unless all of the quadruplicates are obtained. Even if all fours are captured, it is not possible to reassemble or recover the original information without access to the session master key and parser master key.

This example describes one embodiment of the method of the invention and in another embodiment also an algorithm for placing shares into storage so that the shares in all storages can be combined to form a secret authentication material. The required calculations are very simple and fast. However, with the one-time pad (OTP) algorithm, since the key size is the same as the size of the data to be stored, circumstances may arise where it is less desirable to use such an algorithm, for example, to protect large data sets. Thus, approximately twice the amount of original data would need to be stored and transmitted, which is undesirable in certain circumstances.

Stream cipher RS1

The stream cipher RS1 splitting technique is very similar to the OTP splitting technique described herein. Instead of the n-byte random value, an n' ═ min (n, 16) -byte random value is generated and storedUsed as a key for RS1 stream cipher algorithm. The RS1 stream cipher algorithm has the advantage of generating a pseudo-random key from a much smaller seed number. The RS1 stream cipher encryption is also considered to be performed at approximately 10 times faster than triple DES encryption, which is well known in the art, without compromising security. RS1 stream cipher algorithms are well known in the art and may be used to generate keys for use in XOR functions. The RS1 stream cipher algorithm may be combined with other commercially available stream cipher algorithms (e.g., RC4 from RSA Security Inc^TMStream cipher algorithms) interoperate and are applicable to the method of the present invention.

Using the key notation above, K1 to K5 are now n' byte random values and we set:

SD1＝S1 XOR E(K1)

SD2＝S2 XOR E(K2)

SD3＝S3 XOR E(K3)

SDn＝Sn XOR E(Kn)

where E (K1) through E (Kn) are the first n' bytes of the output of the RS1 stream cipher keyed by K1 through Kn. These shares are now placed into the data store as described herein.

In this stream cipher RS1 algorithm, the necessary calculations required are almost as simple and fast as the OTP algorithm. The benefit of this example of using RS1 stream ciphers is that the system need only store and send, on average, about 16 bytes more than the size of the original data to be protected for each share. When the size of the original data is larger than 16 bytes, the RS1 algorithm is more efficient than the OTP algorithm because the RS1 algorithm is simple and shorter. One of ordinary skill in the art will readily appreciate that a wide variety of encryption methods or algorithms are suitable for use with the present invention, including but not limited to RS1, OTP, RC4 ^TMTriple DES and AES.

The data security method and computer system of the present invention provide significant advantages over conventional encryption methods. One advantage is the security gained from moving shares of data to different locations on one or more data stores or storage devices that may be located in different logical, physical, or geographic locations. For example, when data shares are physically split and under the control of different personnel, the likelihood of compromising the data is greatly reduced.

Another advantage provided by the method and system of the present invention is the combination of the steps of the method of the present invention for protecting data to provide an integrated process that maintains the security of sensitive data. The data is encrypted with a secure key and split into one or more shares (in one embodiment, 4 shares) based on the secure key. The security key is securely stored using a reference pointer that is protected in quadruplicates according to the security key. Each data share is then individually encrypted and the key is securely stored with the different encrypted shares. When combined, the entire process of protecting data according to the methods disclosed herein becomes a comprehensive package of data security.

Data protected in accordance with the method of the present invention is readily retrieved and recovered, reconstructed, reassembled, decrypted or otherwise returned to its original or other suitable form for use. To recover the original data, the following items may be utilized:

1. all shares or portions of the data set.

2. Knowledge of the process flow of the method for protecting data, and the ability to render the process flow.

3. Access to the session master key.

4. Access to the resolver master key.

It is therefore desirable to devise a secure installation in which at least one of the above elements may be physically separated from the rest of the system (e.g., under the control of a different system administrator).

Protection of applications against bad application calls to data protection methods may be enhanced by using the parser master key. In this embodiment of the invention, a mutual authentication handshake may be required between the secure data parser and the application before any action is taken.

The security requirements of the system require that there is no "back door" method for reconstructing the original data. For installations where data recovery issues may arise, the secure data parser may be enhanced to provide a mirror of the four shares and session master key store. Hardware options such as RAID (a redundant array of inexpensive disks used to spread information over several disks) and software options such as replication can also assist in data recovery planning.

Key management

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

parser master key

This key is an individual key associated with the installation of the secure data parser. It is installed on a server that has deployed a secure data parser. There are a number of options suitable for protecting this key, including but not limited to a smart card, a separate hardware keystore, a standard keystore, a custom keystore, or located, for example, in a protected database table.

Session master key

The session master key may be generated each time data is protected. The session master key is used to encrypt data prior to the parsing and splitting operations. It may also be incorporated as a means of parsing the encrypted data (if the session master key is not integrated into the parsed data). The session master key may be protected in various ways (including but not limited to a standard keystore, a custom keystore, a separate database table) or, for example, within an encrypted share.

Share encryption key

For each share or portion of the established data set, a separate share encryption key may be generated to further encrypt the share. The share encryption key may be stored in a different share than the encrypted share.

Those skilled in the art will readily appreciate that the data protection method and computer system of the present invention has broad application to any type of data in any setting or environment. In addition to business applications performed on the internet or between customers and vendors, the data protection method and computer system of the present invention are highly applicable to non-business or private settings or environments. Any data set that is desired to be secured against unauthorized users may be protected using the methods and systems described herein. For example, advantageously, by protecting data using the method and system of the present invention, access to a particular database within a company or organization may be limited to only select users. Another example is the creation, modification or access of documents where it is desirable to restrict access or prevent unauthorized or accidental access or disclosure outside of selected individuals, computers or workstations. These and other examples of the manner in which the data protection methods and systems of the present invention may be applied to any non-commercial or commercial environment or setting to make any setting include, but are not limited to, any organization, government agency, or corporation.

In another embodiment of the present invention, the data protection method uses three key sets for the encryption operation. Each key set may have a separate keystore, retrieval, security, and recovery options based on installation. Keys that may be used include, but are not limited to:

1. parser master key

This key is an independent key associated with the installation of the secure data parser. It is installed on a server that has deployed a secure data parser. There are various options suitable for protecting this key including, but not limited to, a smart card, a separate hardware keystore, a standard keystore, a custom keystore, or located, for example, within a protected database table.

2. Session master key

The session master key may be generated each time data is protected. The session master key is used in conjunction with the parser master key to derive the intermediate key. The session master key may be protected in a variety of ways including, but not limited to, a standard keystore, a custom keystore, a stand-alone database table, or within an encrypted share, for example.

3. Intermediate key

An intermediate key may be generated each time data is protected. The intermediate key is used to encrypt the data prior to the parsing and splitting operations. It may also be incorporated as a means of parsing encrypted data.

4. Share encryption key

For each share or portion of the established data set, a separate share encryption key may be generated to further encrypt the share. The share encryption key may be stored in a different share than the encrypted share.

Those skilled in the art will readily appreciate that the data protection method and computer system of the present invention has broad application to any type of data in any setting or environment. In addition to business applications performed on the internet or between customers and vendors, the data protection method and computer system of the present invention are highly applicable to non-business or private settings or environments. Any data set that is desired to be secured against unauthorized users may be protected using the methods and systems described herein. For example, advantageously, by protecting data using the method and system of the present invention, access to a particular database within a company or organization may be limited to only select users. Another example is the creation, modification or access of documents where it is desirable to restrict access or prevent unauthorized or accidental access or disclosure outside of selected individuals, computers or workstations. These and other examples of the manner in which the data protection methods and systems of the present invention may be applied to any non-commercial or commercial environment or setting to make any setting include, but are not limited to, any organization, government agency, or corporation.

Workgroup, project, personal PC/laptop or cross-platform data security

The data protection method and computer system of the present invention are also used to protect data from workgroups, projects, personal PCs/laptops and any other platform, for example for enterprises, offices, government agencies or any setting for creating, processing or storing sensitive data. The present invention provides methods and computer systems known to be sought by organizations such as the U.S. government for the protection of data implemented across government organizations or between state or federal level governments.

The data protection method and computer system of the present invention provide the ability to parse and split not only regular files, but also any type of data fields, collections, and/or tables. In addition, all forms of data (including but not limited to text, video, image, biometric, and voice data) can be protected under this process. The scalability, speed and data throughput of the method of the present invention for protecting data is limited to hardware at the disposal of the user.

In one embodiment of the invention, a data protection method is utilized in a workgroup environment as described below. In one embodiment, as shown in FIG. 23 and described below, the workgroup-level data protection method of the present invention uses the private key management functions of a trust engine to store the associated private key (parser group master key) and user/group relationships required by a group of users to share secure data. The method of the present invention has the ability to protect data for an enterprise, workgroup, or individual user depending on how the resolver master key is deployed.

In one embodiment, additional key management and user/group management programs may be provided to enable a wide range of workgroup execution modes with a single point of administration and key management. Key generation, management and revocation are handled by a single maintenance program, all of which become particularly important as the number of users increases. In another embodiment, key management may also be set across one or several different system administrators, which does not allow any one person or group to control the data as needed. This allows for the management of protected data to be obtained through roles, responsibilities, membership, rights, etc. defined by the organization, and access to protected data can be limited to only those who are permitted or required to access only the portion of their work, while other people such as managers or executives can access all of the protected data. This embodiment enables sharing of protected data between different groups within a company or organization while allowing only certain selected individuals (e.g., those with authorized and predetermined roles and responsibilities) to view the entire data. Furthermore, this embodiment of the method and system of the present invention also allows sharing of data, for example, between different companies, or different departments or branches of a company, or any different organizational departments, groups, institutions, offices, etc. of any government or organization, etc., where some sharing is required but not any party is permitted access to all data. A particularly obvious example of the need and utility of such a method and system for the present invention is to allow sharing, but maintaining security, between, for example, government regions, institutions and offices, as well as between different branches, divisions or offices of a large corporation or any other organization.

The following are examples of the application of the method of the invention to a smaller extent. The parser master key is used as a serialization or tokenization for the secure data parser to the organization. The data protection methods described herein are used to share files within a group of users as the use of parser master keys shrinks from the entire enterprise to smaller workgroups.

In the example shown in FIG. 25 and described below, six users are defined along with their titles or roles within an organization. The bars represent five possible groups to which the user belongs according to their role. The arrows represent the membership of the user within one or more groups.

When constructing the secure data parser for this example, the system administrator accesses user and group information from the operating system through the maintenance program. This maintenance program generates and assigns a resolver group master key to the user based on the user's membership in the group.

In this example, there are three members in the senior employee group. For this group, the actions are as follows:

1. access a resolver group master key for a senior employee group (where the key is generated if not available);

2. generating a digital certificate associating the CEO with a senior employee group;

3. Generating a digital certificate associating the CFO with a senior employee group;

4. a digital certificate is generated that associates a market-competent vice president with a senior employee group.

The same set of actions will be performed for each group and for each member within each group. When the maintenance procedure is complete, the resolver group master key becomes a shared certificate for each member of the group. Revocation of an assigned digital certificate may be done automatically when a user is removed from a group by a maintenance program without affecting the remaining members of the group.

Once the shared certificate is defined, the parsing and splitting process remains the same. When a file, document, or data element is to be protected, the user is prompted for a target group to be used when protecting the data. The resulting protected data is only accessible by other members of the target group. This functionality of the method and system of the present invention may be used with any other computer system or software platform, or may be integrated into an existing application or used separately for file security, for example.

One of ordinary skill in the art will readily appreciate that any one or combination of encryption algorithms is suitable for use in the methods and systems of the present invention. For example, in one embodiment, the encryption steps may be repeated to generate a multi-layered encryption scheme. Furthermore, different encryption algorithms or combinations of encryption algorithms may be used to repeat the encryption steps so that different encryption algorithms are applied to different layers of the multi-layer encryption scheme. In this way, the encryption scheme itself can become an integral part of the method of the present invention for protecting sensitive data from unauthorized use or access.

The secure data parser may include an error checking component that is an internal component, an external component, or both. For example, in one suitable approach, when a portion of data is created using the secure data parser according to the present invention, to ensure the integrity of the data within a portion, a hash value is taken at preset intervals within that portion and appended to the end of the interval. The hash value is a predictable and reproducible numerical representation of the data. The hash value will be different if any of the bits within the data change. The scan module (either as a separate component external to the secure data parser or as an internal component) may then scan portions of the data generated by the secure data parser. Each data portion (or less than all data portions according to some interval or according to random or pseudo-random sampling) is compared to the appended hash value(s) and action can be taken. This action may include: reporting of matched and unmatched values, alerting of unmatched values, or invoking some external or internal procedure to trigger the recovery of data. For example, the restoration of data may be performed by invoking a restoration module based on the concept that not all parts are needed to produce the original data according to the present invention.

Any other suitable integrity check may be performed using any suitable integrity information appended to all or anywhere in a subset of the data portions. The integrity information may include any suitable information that can be used to determine the integrity of the data portion. Examples of integrity information may include: a hash value calculated based on any suitable parameter (e.g., based on the respective data portion), digital signature information, Message Authentication Code (MAC) information, any other suitable information, or any combination thereof.

The secure data parser of the present invention may be used in any suitable application. That is, the secure data parser described herein has different applications in different areas of computing and technology. Several such areas are discussed below. It should be appreciated that these are merely exemplary in nature and that any other suitable application may utilize the secure data parser. It should also be appreciated that the examples described are merely illustrative embodiments, which may be modified in any suitable manner to meet any suitable desires. For example, parsing and splitting may be based on any suitable units (e.g., bits, bytes, kilobytes, megabytes, any combination thereof, or any other suitable unit).

The secure data parser of the present invention may be used to implement a secure physical token whereby data stored within the physical token may be required in order to access additional data stored within another memory area. In one suitable approach, a physical token (e.g., a compact USB flash drive, a floppy disk, an optical disk, a smart card, or any other suitable physical token) may be used to store one of at least two portions of parsed data in accordance with the present invention. To access the raw data, access to the USB flash drive is required. Thus, a personal computer that holds one part of the parsed data would need to attach a USB flash drive with another part of the parsed data before being able to access the original data. Fig. 26 shows this application. The storage area 2500 includes a portion 2502 of the parsed data. To access the raw data, a physical token 2504 having a portion 2506 of the parsed data needs to be connected to the storage region 2500 using any suitable communication interface 2508 (e.g., USB, serial, parallel, bluetooth, 1R, 1EEE1394, ethernet, or any other suitable communication interface). This is useful, for example, in situations where sensitive data on a computer is left alone and subject to unauthorized access attempts. By removing the physical token (e.g., USB flash drive), no access to sensitive data is possible. It will be appreciated that any other suitable method for utilising a physical token may be used.

The secure data parser of the present invention may be used to implement a secure authentication system whereby user enrollment data (e.g., passwords, private encryption keys, fingerprint templates, biometric data, or any other suitable user enrollment data) is parsed and split using the secure data parser. The user registration data may be parsed and split such that one or more portions are stored on a smart card, a government public access card, any suitable physical storage device (e.g., a magnetic or optical disk, a USB key drive, etc.), or any other suitable device. One or more other portions of the parsed user enrollment data may be stored within the system performing the authentication. This provides an additional level of security to the authentication process (e.g., user enrollment data must be obtained via appropriate parsed and split data portions in addition to biometric authentication information obtained from a biometric source).

The secure data parser of the present invention may be integrated into any suitable existing system, thereby providing for the use of its functionality within the respective environment of each system. Fig. 27 shows a block diagram of an illustrative system 2600, which system 2600 may include software, hardware, or both for implementing any suitable application. System 2600 may be an existing system that secure data parser 2602 may be retrofitted as an integrated component. Alternatively, secure data parser 2602 may be integrated into any suitable system 2600, for example, from the earliest design stage of that system 2600. Secure data parser 2602 may be integrated in any suitable level of system 2600. For example, secure data parser 2602 may be integrated into system 2600 at a sufficient back-end level such that the presence of secure data parser 2602 may be substantially transparent to end users of system 2600. Secure data parser 2602 may be used to parse and split data between one or more storage devices 2604 in accordance with the present invention. Some illustrative examples of systems that internally integrate a secure data parser are discussed below.

The secure data parser of the present invention may be integrated into an operating system kernel (e.g., Linux, Unix, or any other suitable commercial or proprietary operating system). This integration may be used to protect data at the device level, whereby, for example, data stored within one or more devices is typically split into a number of portions and stored between the one or more devices by a secure data parser integrated into the operating system. When attempting to access the raw data, appropriate software, also integrated into the operating system, may reassemble the parsed data portions into the raw data in a manner that is transparent to the end user.

The secure data parser of the present invention may be integrated into a volume manager or any other suitable component of a storage system to secure local and networked data storage across any or all supported platforms. For example, by integrating the secure data parser, the storage system may take advantage of the redundancy provided by the secure data parser (i.e., features used to enable reconstruction of the original data without requiring all of the separate portions of the data) to prevent data loss. Regardless of whether redundancy is used or not, the secure data parser also allows all data written to storage to be in the form of multiple portions generated by parsing in accordance with the present invention. When attempting to access the raw data, appropriate software, also integrated into the volume manager or other suitable component within the storage system, may reassemble the parsed data portions into the raw data in a manner that is transparent to the end user.

In one suitable approach, the secure data parser of the present invention may be integrated into a RAID controller (either as hardware or as software). This allows for the secure storage of data on multiple drives while maintaining fault tolerance in the event of a drive failure.

The secure data parser of the present invention may be integrated into a database, for example, in order to protect sensitive table information. For example, in one suitable approach, data associated with a particular cell of a database table (e.g., an individual cell, one or more particular columns, one or more particular rows, any combination thereof, or the entire database table) may be parsed and separated in accordance with the present invention (e.g., where different portions are stored on one or more storage devices at one or more locations or on a single storage device). Access to reassemble these portions for viewing the original data may be authorized by conventional authentication methods (e.g., username and password).

The secure parser of the present invention may be integrated into any suitable system that includes data in motion (i.e., the transfer of data from one location to another). These systems include, for example, email, streaming data broadcast, and wireless (e.g., WiFi) communication. With respect to email, in one suitable approach, a secure parser can be used to parse an outgoing message (i.e., containing text, binary data, or both (e.g., a file attached to an email message)) and send different portions of the parsed data along different paths, thereby establishing multiple data streams. If any of these data streams are compromised, the original message is still secure, since the system requires more than one part to be combined in order to generate the original data according to the invention. In another suitable approach, different portions of data may be sequentially transmitted along a path such that if one portion is obtained, this is not sufficient to produce the original data. According to the invention, these different parts arrive at the location of the intended recipient and can be combined to produce the original data.

Fig. 28 and 29 are exemplary block diagrams of such an email system. Fig. 28 illustrates a sender system 2700 that can include any suitable hardware, such as a computer terminal, a personal computer, a handheld device (e.g., PDA, blackberry), a cellular telephone, a computer network, any other suitable hardware, or any combination thereof. The sender system 2700 is used to generate and/or store a message 2704, the message 2704 can be, for example, an email message, a binary data file (e.g., graphics, voice, video, etc.), or both. Message 2704 is parsed and split by secure data parser 2702 in accordance with the present invention. The resulting data portion can be transmitted to the recipient system 2710 over a network 2708 (e.g., the internet, an intranet, a LAN, WiFi, bluetooth, any other suitable wired or wireless communication means, or any combination thereof) via one or more discrete communication paths 2706. The data portions may be communicated in parallel in time or alternatively in accordance with any suitable time delay between communication of the different data portions. The recipient system 2710 may be any suitable hardware as described above with respect to the sender system 2700. In accordance with the present invention, the individual data portions carried along communication path 2706 are reassembled at recipient system 2710 to produce the original message or data.

Fig. 29 illustrates a sender system 2800 that can include any suitable hardware, such as a computer terminal, a personal computer, a handheld device (e.g., PDA), a cellular telephone, a computer network, any other suitable hardware, or any combination thereof. The sender system 2800 is used to generate and/or store a message 2804, the message 2804 can be, for example, an email message, a binary data file (e.g., graphics, voice, video, etc.), or both. Message 2804 is parsed and split by secure data parser 2802 in accordance with the present invention. The resulting data portion may be transmitted to recipient system 2810 over a network 2808 (e.g., the internet, an intranet, a LAN, WiFi, bluetooth, any other suitable wired or wireless communication means, or any combination thereof) via a single communication path 2806. These data portions may be serially communicated with respect to one another via communication path 2806. Recipient system 2810 may be any suitable hardware described above with respect to sender system 2800. In accordance with the present invention, the various data portions conveyed along communication path 2806 are reassembled at recipient system 2810 to produce the original message or data.

It should be understood that the arrangement of fig. 28 and 29 is merely illustrative. Any other suitable arrangement may be used. For example, in another suitable approach, the features of the systems of fig. 28 and 29 may be combined to use the multi-path approach of fig. 28, and where one or more communication paths 2706 are used to carry more than one data portion, as with communication path 2806 in fig. 29.

The secure data parser may be integrated at any suitable level of the mobile data system. For example, in the case of an email system, the secure parser may be integrated at the user interface level (e.g., into the email system)Outlook), in which case the user may control the use of the secure data parser feature when using email. Alternatively, the secure parser may be implemented in a back-end component (e.g., at a switching server), in which case, according to the present invention, messages may be automatically parsed, split, and transmitted along different paths without any user intervention.

Similarly, in the case of streaming broadcast of data (e.g., audio, video), the output data may be parsed and separated into multiple streams, each stream containing a portion of the parsed data. According to the invention, the multiple streams may be sent along one or more paths and recombined at the recipient's location. One of the benefits of this scheme is that the relatively large overhead associated with conventionally encrypting data and then transmitting the encrypted data over a single communication channel is avoided. The secure parser of the present invention allows moving data to be sent in multiple parallel streams, thereby improving speed and efficiency.

It should be appreciated that the secure data parser may be integrated for protection and fault tolerance of any type of moving data over any transmission medium, including wired, wireless, or physical, for example. For example, a voice over IP (VoIP) application may utilize the secure data parser of the present invention. The secure data parser of the present invention may be used to secure wireless or wired data transmissions to and from any suitable Personal Digital Assistant (PDA) device, such as blackberries and smart phones. Peer-to-peer and hub-based wireless networks communications using wireless 802.11 protocols, satellite communications, peer-to-peer wireless communications, internet client/server communications, or any other suitable communications may include the in-mobile data capability of the secure data parser in accordance with the present invention. Data communication between computer peripheral devices (e.g., printers, scanners, monitors, keyboards, network routers, biometric authentication devices (e.g., fingerprint scanners), or any other suitable peripheral devices), between a computer and a computer peripheral device, between a computer peripheral device and any other suitable device, or any combination thereof, may utilize the in-motion data features of the present invention.

The in-motion data features of the present invention may also be applied to physical transmission, for example, using a separate route, medium, secure copy of the method, any other suitable physical transmission, or any combination thereof. For example, the physical transfer of data may occur from digital/magnetic tape, floppy disk, optical disk, physical token, USB drive, removable hard disk, consumer electronics with flash memory (e.g., apple IPOD or other MP3 player), flash memory, any other suitable medium for transferring data, or any combination thereof.

The secure data parser of the present invention provides disaster recovery capabilities to security. According to the present invention, all portions of the separate data generated by the secure data parser are not required in order to obtain the raw data. That is, among m parts stored, n may be the minimum number required to acquire original data among the m parts, where n ≦ m. For example, if each of the four portions is stored in a different physical location than the other three portions, then if n ═ 2 in this example, two of these locations may be compromised so that the data is corrupted or inaccessible, and the original data may still be retrieved from the portions in the other two locations. For n or m, any suitable value may be used.

Furthermore, the m-to-n feature of the present invention may be used to establish "double-person rules" whereby two or more different entities (each having a portion of separate data parsed by the secure parser of the present invention) need to agree to bring their portions together to obtain the original data in order to avoid delegating full access to transactions that may be sensitive data to a single person or any other entity.

The secure data parser of the present invention may be used to provide a group of entities with a group-wide key that allows group members to access certain information authorized to be accessed by that particular group. The group key may be one of the data parts generated by the secure parser according to the invention that needs to be combined with another part stored in the center, for example in order to retrieve the sought information. This feature allows, for example, secure collaboration within a group. For example, it may be applied to a private network, a virtual private network, an intranet, or any other suitable network.

Specific applications of this use of security resolvers include, for example, federated information sharing, where, for example, multi-country friendly government military forces are given the ability to communicate operationally and otherwise sensitive data over a single network or dual networks (i.e., as compared to many networks involving relatively more manual processing currently in use) based on the level of security authorized for each corresponding country. This capability may also be applied to a company or other organization in which information that needs to be known by one or more particular individuals (within or outside the organization) may be transmitted over a single network without concern for unauthorized individuals viewing the information.

Another particular application includes multiple levels of security hierarchy for government systems. That is, the secure parser of the present invention may provide the ability to operate government systems with different levels of confidential information (e.g., non-confidential, secret, top secret) using a single network. More networks may be used if desired (e.g., a separate network for privacy), but the present invention allows for substantially fewer arrangements than current arrangements using separate networks for each level of confidentiality.

It should be appreciated that any combination of the above-described applications of the secure parser of the present invention may be used. For example, a group key application can be used with a data security application on the move (i.e., whereby data transmitted over a network can only be accessed by members of the corresponding group, and in this case, when the data is moving, it is split (or sent in sequential portions) in multiple paths according to the present invention).

The secure data parser of the present invention may be integrated into any middleware application, thereby enabling the application to securely store data to different database products or different devices without requiring changes to the application or database. Middleware is a general term for any product that enables two separate and already existing programs to communicate. For example, in one suitable approach, middleware that integrates a secure data parser may be used to enable programs written for a particular database to communicate with other databases without custom coding.

The secure data parser of the present invention may be implemented with any combination of any suitable capabilities, such as those described herein. In some embodiments of the present invention, for example, the secure data parser may be implemented with only certain capabilities, but other capabilities may be obtained through the use of external software, hardware, or both that directly or indirectly interface with the secure data parser.

Fig. 30, for example, shows an illustrative embodiment of a secure data parser that is secure data parser 3000. Secure data parser 3000 may be implemented with very little built-in capabilities. As shown, secure data parser 3000 may include built-in capabilities to parse and split data into multiple portions (also referred to herein as shares) using modules 3002 in accordance with the present invention. Secure data parser 3000 may also include built-in capabilities to perform redundancy using module 3004 to enable, for example, the above-described m-n feature (i.e., the original data may be reconstructed without using all of the data shares parsed and split). Secure data parser 3000 may also include share distribution capabilities to place data shares into buffers from which they are sent for transfer to a remote location, storage, etc., using module 3006, in accordance with the present invention. It should be appreciated that any other suitable capabilities may be built into secure data parser 3000.

Assembled data buffer 3008 may be any suitable memory for storing raw data (although not necessarily in its raw form) to be parsed and split by secure data parser 3000. In a split operation, packed data buffer 3008 provides input to secure data parser 3008. During a restore operation, packed data buffer 3008 may be used to store the output of secure data parser 3000.

Split share buffer 3010 may be one or more memory modules operable to store multiple shares of data obtained from parsing and splitting of the original data. In a split operation, split share buffer 3010 holds the output of the secure data parser. In a restore operation, split share buffer maintains input to secure data parser 3000.

It should be appreciated that any other suitable arrangement of capabilities may be built in for secure data splitter 3000. Any additional features may be built in and any illustrated features may be removed, made more robust, less robust, or modified in any suitable manner. Buffers 3008 and 3010 are again merely illustrative and may be modified, removed, or added in any suitable way.

Any suitable module implemented in software, hardware, or both may be called by secure data parser 3000 or may make calls to secure data parser 3000. Even the capabilities built into secure data parser 3000 may be replaced by one or more external modules if desired. As shown, some external modules include a random number generator 3012, a cryptographic feedback key generator 3014, a hashing algorithm 3016, any one or more types of encryption 3018, and key management 3020. It should be understood that these are merely illustrative external modules. Any other suitable modules may be used in addition to or instead of those shown.

Cipher feedback key generator 3014 may be external to secure data parser 3000, generating a unique key or random number for each secure data parser operation (e.g., using random number generator 3012) that is used as a seed value for operations that extend the original session key size (e.g., 128, 256, 512, or 1024 bits of value) to a value equal to the length of the data to be parsed and split. Any suitable algorithm may be used for cipher feedback key generation, including, for example, the AES cipher feedback key generation algorithm.

To facilitate integration of secure data parser 3000 and its external modules (i.e., secure data parser layer 3026) into application layer 3024 (e.g., email applications, database applications, etc.), a wrapper layer may be used that may utilize, for example, API function calls. Any other suitable arrangement that facilitates integrating secure data parser layer 3026 into application layer 3024 may be used.

Fig. 31 illustrates how the arrangement of fig. 30 may be used when issuing a write command (e.g., writing to storage), inserting a command (e.g., into a database field), or sending a command (e.g., via a network) in the application layer 3024. In step 3100, data to be protected is identified and a secure data parser is invoked. The call passes to wrapper layer 3022, and in step 3102 wrapper layer 3022 streams the input data identified in step 3100 to assembly data buffer 3008. Additionally, in step 3102, any suitable share information, file names, any other suitable information, or any combination thereof may be stored (e.g., as information 3106 in wrapper layer 3022). In accordance with the present invention, the secure data processor 3000 then parses and splits the data it retrieves as input from the assembly data buffer 3008. It outputs the data shares to split share buffer 3010. In step 3104, wrapper layer 3022 obtains any suitable share information (i.e., the share information stored by wrapper layer 3022 in step 3102) and share locations (e.g., from one or more configuration files) from stored information 3106. Wrapper layer 3022 then performs write operations (e.g., writes to one or more storage devices, transfers over a network, etc.) on the output shares (obtained from split share buffer 3010) as appropriate.

Fig. 32 illustrates how the arrangement of fig. 30 may be used when performing a read (e.g., from storage), a selection (e.g., from a database field), or a reception (e.g., from a network). In step 3200, data to be restored is identified and secure data parser 3000 is invoked from application layer 3024. In step 3202, any appropriate share information is obtained from the wrapper layer 3022 and the share location is determined. Wrapper layer 3022 loads the portion of the data identified in step 3200 into split share buffer 3010. Secure data parser 3000 then processes the shares in accordance with the present invention (e.g., if only three of the four shares are available, the redundancy capabilities of secure data parser 3000 may be used so that the original data can be recovered using only the three shares). The recovered data is then stored in the assembled data buffer 3008. In step 3204, application layer 3022 converts the data stored in assembled data buffer 3008 into its raw data format (if needed) and provides the raw data in the raw format to application layer 3024.

It should be understood that the parsing and splitting of the original data shown in fig. 31 and the restoration of the data portions to the original data shown in fig. 32 are merely illustrative. Any other suitable processes, components, or both, may be used in addition to or in place of those shown.

FIG. 33 is a block diagram of an exemplary process flow for parsing and splitting raw data into two or more data portions, according to one embodiment of the invention. As shown, the original data desired to be parsed and split is plaintext 3306 (i.e., the word "sumit" is used as an example). It should be appreciated that any other type of data may be parsed and split in accordance with the present invention. A session key 3300 is generated. If the length of session key 3300 is not compatible with the length of original data 3306, then cryptographic feedback session key 3304 may be generated.

In one suitable approach, the original data 3306 may be encrypted before parsing, splitting, or both. For example, as shown in fig. 33, raw data 3306 may be xored with any suitable value (e.g., with cryptographic feedback session key 3304 or with any other suitable value). It should be appreciated that any other suitable encryption technique may be used in addition to or in place of the illustrated XOR technique. It should also be appreciated that although FIG. 33 is shown for byte-by-byte operation, the operation may be performed at the bit level or at any other suitable level. It should also be appreciated that any encryption of the original data 3306 is not required, if desired.

The resulting encrypted data (or the original data (if not encrypted)) is then hashed to determine how to split the encrypted (or original) data between output buckets (e.g., four in the example shown). In the illustrated example, the hash process is performed on a byte basis and is a function of the cryptographic feedback session key 3304. It should be understood that this is merely illustrative. The hashing process may be performed at the bit level, if desired. The hashing process may be a function of any other suitable value other than cryptographic feedback session key 3304. In another suitable approach, no hashing need be used. But any other suitable technique for splitting data may be employed.

FIG. 34 is a block diagram of an illustrative process flow for recovering original data 3306 from two or more parsed and split portions of original data 3306 in accordance with an embodiment of the invention. This processing includes reverse hashing the portions (i.e., reversing the process of fig. 33) based on the cryptographic feedback session key 3304 to recover the encrypted original data (or original data if not encrypted prior to parsing and splitting). The encryption key may then be used to recover the original data (i.e., in the example shown, the XOR encryption is decrypted using cipher feedback session key 3304 by XOR processing cipher feedback session key 3304 with the encrypted data). This restores the original data 3306.

Fig. 35 shows how bit splitting is achieved in the examples of fig. 33 and 34. The hashing process may be used to determine the bit value to split each data byte (e.g., based on a cryptographic feedback session key, based on any other suitable value). It should be appreciated that this is merely one exemplary way to implement the splitting at the bit level. Other suitable techniques may be used.

It should be appreciated that the hash function described herein may be formed for any suitable hash algorithm. These algorithms include, for example, MD5 and SHA-1. Different hashing algorithms may be used by different components of the invention at different times.

After the split point is determined according to the above illustrative process or by any other process or algorithm, it is determined to which data portions each of the left and right segments are appended. Any suitable algorithm may be used to perform this determination. For example, in one suitable approach, a table of all possible distributions (e.g., in the form of a pair of destinations for the left and right segments) may be established whereby a destination share value for each of the left and right segments may be determined by using any suitable hash function on corresponding data of a session key, a cryptographic feedback session key, or any other suitable random or pseudorandom value that may be generated and expanded to the size of the original data. For example, a hash function of the corresponding byte in a random or pseudo-random value may be generated. The output of the hash function is used to determine which destination pair (i.e., one destination for the left segment and one destination for the right segment) to select from a table of all destination combinations. Based on this result, the segments of the split data unit are appended to the corresponding two shares indicated by the table value selected as a result of the hash function.

According to the present invention, redundant information can be attached to data parts so that the original data can be restored without using all the data parts. For example, if two of the four portions are expected to be sufficient to recover the data, additional data in a share may be added to each share accordingly, e.g., in a round-robin fashion (e.g., when the size of the original data is 4MB, share 1 gets its own share and shares 2 and 3, share 2 gets its own share and shares 3 and 4, share 3 gets its own share and shares 4 and 1, share 4 gets its own share and shares 1 and 2). Any such suitable redundancy may be used in accordance with the present invention.

It should be appreciated that any other suitable parsing and splitting scheme may be used to generate the plurality of data portions from the original data set in accordance with the present invention. For example, parsing and splitting may be randomly or pseudo-randomly processed bit by bit. A random or pseudo-random value (e.g., session key, cryptographic feedback session key, etc.) may be used, whereby, for each bit in the original data, the result of the hash function on the corresponding data in the random or pseudo-random value may indicate to which share the corresponding bit is appended. In one suitable approach, the random or pseudo-random value may be generated or extended to 8 times the size of the original data, such that a hash function may be performed on the corresponding byte of the random or pseudo-random value for each bit of the original data. Any other suitable algorithm that parses and splits data bit-by-bit levels may be used in accordance with the present invention. It should also be appreciated that, in accordance with the present invention, redundant data may be appended to a data share, for example, in the manner just described above.

In one suitable approach, the parsing and splitting need not be random or pseudorandom. Moreover, any suitable deterministic algorithm for parsing and splitting data may be used. For example, decomposition of the original data into sequential shares may be employed as a parsing and splitting algorithm. Another example is parsing and splitting the original data bit by bit, appending each corresponding bit sequentially to the data shares in a round robin fashion. It should also be appreciated that redundant data may be appended to a data share in accordance with the present invention, for example, in the manner described above.

In one embodiment of the invention, after the secure data parser generates portions of the original data, one or more of the generated portions may be mandatory in order to recover the original data. For example, if one of these portions is used as an authentication share (e.g., saved on the physical token) and if the fault-tolerant feature of the secure data parser is used (i.e., not all of the data portions are needed to recover the original data), then even if the secure data parser has access to a sufficient number of portions of the original data to recover the original data, the authentication share stored on the physical token is still needed before it recovers the original data. It should be appreciated that any number and type of particular shares may be required, for example, based on the application, the type of data, the user, any other suitable factor, or any combination thereof.

In one suitable approach, the secure data parser, or some external component to the secure data parser, may encrypt one or more portions of the original data. To recover the original data, the encrypted portions need to be provided and decrypted. Different encrypted portions may be encrypted with different encryption keys. This feature may be used, for example, to implement a more secure "two-person rule" whereby a first user would need to have a particular share encrypted using a first encryption key and a second user would need to have a particular share encrypted using a second encryption key. To access the original data, the two users would need to have their respective encryption keys and provide their respective portions of the original data. In one suitable approach, one or more portions of data (possibly mandatory shares needed to recover the original data) may be encrypted with a public key. The shares may then be decrypted with the private key for recovery into the original data.

Any such suitable paradigm using mandatory shares may be used, where not all shares are needed to recover the original data.

In one suitable embodiment of the invention, the data may be distributed into a limited number of data shares, processed randomly or pseudo-randomly, such that, from a statistical standpoint, the probability that any particular data share will receive a particular data unit is equal to the probability that any of the remaining shares will receive that data unit. As a result, each share of data will have approximately equal amounts of data bits.

According to another embodiment of the present invention, each of the limited number of data shares need not have equal probability of receiving a data unit from parsing and splitting of the original data. Also, one or more of the shares may have a higher or lower probability than the rest of the shares. As a result, the bit size may be larger or smaller for some shares compared to other shares. For example, in the case of two shares, one share may have a 1% probability of receiving a data unit, while the second share has a 99% probability. Thus, it should be appreciated that once the data units are distributed into two shares by the secure data parser, the first share should have approximately 1% of the data and the second share should have 99% of the data. Any suitable probability may be used in accordance with the present invention.

It should be appreciated that the secure data parser may be designed to distribute data to shares according to a percentage that is accurate (or approximately accurate). For example, the secure data parser may be designed to distribute 80% of the data to a first share and the remaining 20% of the data to a second share.

According to another embodiment of the present invention, the secure data parser may generate a plurality of data shares, one or more of the data shares having a predetermined size. For example, the secure data parser may split the original data into multiple data portions, where one of the portions is exactly 256 bits. In one suitable approach, if a portion of data having a desired size cannot be generated, the secure data parser may stuff the portion to the correct size. Any suitable size may be used.

In one suitable approach, the size of the data portion may be the size of an encryption key, a split key, any other suitable key, or any other suitable data element.

As described above, the secure data parser may use keys in parsing and splitting data. For clarity and brevity, these keys will be referred to herein as "split keys". For example, the previously introduced session master key is a split key. In addition, as described above, the split key may be protected within the data shares generated by the secure data parser. Any suitable algorithm for protecting split keys may be used to protect them between shares of data. For example, the Shamir algorithm may be used to protect the split key, thereby generating and appending information that may be used to reconstruct the split key to the data share. Any other such suitable algorithm may be used in accordance with the present invention.

Similarly, any suitable encryption key may be protected within one or more data shares according to any suitable algorithm (e.g., the Shamir algorithm). For example, the encryption key used to encrypt the data set prior to parsing and splitting, the encryption key used to encrypt the data portions after parsing and splitting, or both, may be protected using a Shamir algorithm or any other suitable algorithm.

According to one embodiment of the invention, data may be further protected by transforming split keys, encryption keys, any other suitable data elements, or any combination thereof, using All or All no transformations, such as All-wrapped transformations (aonts). For example, the encryption key used to encrypt the data set prior to parsing and splitting according to the present invention may be transformed by the AoNT algorithm. The transformed encryption key may then be distributed among the shares according to, for example, the Shamir algorithm or any other suitable algorithm. In order to reconstruct the encryption key, the encrypted data set must be recovered (e.g., not all shares need to be used if redundancy is used according to the present invention) in order to access the necessary information about the transformation according to AoNT, which is well known to those skilled in the art. When the original encryption key is obtained, it may be used to decrypt the encrypted data set to obtain the original data set. It should be understood that the fault tolerance feature of the present invention can be used in conjunction with the AoNT feature. That is, redundant data may be included in the data portions so that not all of the data portions are needed to recover the encrypted data set.

It should be appreciated that AoNT may be applied to encryption keys used to encrypt data portions after parsing and splitting, in addition to or instead of the encryption and AoNT of the respective encryption keys corresponding to the data set prior to parsing and splitting. Likewise, AoNT can be applied to split keys.

In one embodiment of the invention, the encryption key, the split key, or both used in accordance with the present invention may be further encrypted, for example, using a workgroup key, thereby providing an additional level of security to the protected data set.

In one embodiment of the invention, an audit module may be provided that tracks each time the secure data parser is invoked to split data.

FIG. 36 shows a possible option 3600 for components using the secure data parser in accordance with the present invention. In fig. 36, each combination of options is outlined below and labeled with an appropriate step number. The secure data parser may be modular in nature such that any known algorithm may be used within each of the functional blocks shown in fig. 36. For example, other key splitting (e.g., secret sharing) algorithms (e.g., the Blakely algorithm) may be used in place of Shamir, or AES encryption may be replaced by other known encryption algorithms (e.g., triple DES). The labels shown in the example of FIG. 36 depict only one possible combination of algorithms for use in one embodiment of the invention. It should be appreciated that any suitable algorithm or combination of algorithms may be used in place of the labeled algorithms.

1)3610、3612、3614、3615、3616、3617、3618、3619

Previously encrypted data is used in step 3610, which may eventually be split into a predetermined number of shares. If the split algorithm requires a key, then a cryptographically secure pseudo-random number generator may be used to generate the split encryption key in step 3612. Alternatively, the split encryption key may be transformed into a transformed split key using a total or total invariance (AoNT) in step 3614, and then split into a predetermined number of shares of keys that are fault tolerant in step 3615. The data may then be split into a predetermined number of shares in step 3616. A fault tolerant scheme may be used in step 3617 so that the data may be regenerated without requiring all shares. Once the shares are established, authentication/integrity information may be embedded into the shares in step 3618. Optionally, each share may be post-encrypted in step 3619.

2)3111、3612、3614、3615、3616、3617、3618、3619

In some embodiments, the input data may be encrypted using an encryption key provided by the user or an external system. An external key is provided in step 3611. For example, the key may be provided from an external keystore. If the split algorithm requires a key, then a cryptographically secure pseudorandom number generator may be used to generate the split encryption key in step 3612. Alternatively, the split key may be transformed into a transformed split encryption key using a total or total invariance (AoNT) in step 3614, and then split into a predetermined number of shares of keys with fault tolerance in step 3615. In step 3616, the data is then split into a predetermined number of shares. A fault tolerant scheme may be used in step 3617 so that the data may be regenerated without requiring all shares. Once the shares are established, authentication/integrity information may be embedded into the shares in step 3618. Optionally, each share may be post-encrypted in step 3619.

3)3612、3613、3614、3615、3612、3614、3615、3616、3617、3618、3619

In some embodiments, a cryptographically secure pseudo-random number generator may be used to generate an encryption key to transform the data in step 3612. The generated encryption key may be used to encrypt data in step 3613. Optionally, the encryption key may be transformed into a transformed encryption key using a total or total no transformation (AoNT) in step 3614. Then, in step 3615, the transformed encryption key and/or the generated encryption key may be split into a predetermined number of shares with fault tolerance. If the split algorithm requires a key, then the split encryption key is generated using a cryptographically secure pseudo-random number generator in step 3612. Alternatively, the split key may be transformed into a transformed split encryption key using a total or total invariance (AoNT) in step 3614, and then split into a predetermined number of shares of keys with fault tolerance in step 3615. The data may then be split into a predetermined number of shares in step 3616. A fault tolerant scheme may be used in step 3617 so that the data may be regenerated without requiring all shares. Once the shares are established, authentication/integrity information may be embedded into the shares in step 3618. Optionally, each share may be post-encrypted in step 3619.

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

In some embodiments, the data may be split into a predetermined number of shares. If the split algorithm requires a key, then the split encryption key is generated using a cryptographically secure pseudo-random number generator in step 3612. Alternatively, the split key may be transformed into a transformed split key using a total or total invariance (AoNT) in step 3614, and then split into a predetermined number of shares of keys with fault tolerance in step 3615. The data may then be split into a predetermined number of shares in step 3616. A fault tolerant scheme may be used in step 3617 so that the data may be regenerated without requiring all shares. Once the shares are established, authentication/integrity information may be embedded into the shares in step 3618. Optionally, each share may be post-encrypted in step 3619.

Although the above four option combinations are preferred for some embodiments of the present invention, in other embodiments any other suitable combination of features, steps or options may be used with the secure data parser.

The secure data parser may provide flexible data protection by facilitating physical separation. The data may be first encrypted and then split into shares based on "n-m" fault tolerance. This enables the original information to be regenerated when the full number of shares cannot be acquired. For example, some shares may be lost or damaged during transmission. As described in more detail below, lost or damaged shares may be reconstructed based on integrity information and fault tolerance attached to the shares.

To establish the shares, optionally the secure data parser utilizes multiple keys. These keys may include one or more of the following keys:

pre-encryption key: when the pre-encryption of shares is selected, the external key may be passed to the secure data parser. This key may be generated and stored in an external keystore (or other location) and may be used to optionally encrypt data prior to data splitting.

Splitting the encryption key: this key may be generated internally and used by the secure data parser to encrypt the data prior to splitting. This key can then be securely stored within the shares using a key splitting algorithm.

Splitting a session key: this key is not used in the encryption algorithm and can be used as a key for the data partitioning algorithm when random splitting is chosen. When random splitting is used, the split session key may be generated internally and used by the secure data parser to divide the data into shares. This key may be securely stored within the shares using a key splitting algorithm.

Post-encryption key: when post encryption of the shares is selected, the external key may be passed to the secure data parser and used to post encrypt the shares. This key may be generated and stored in an external keystore or other suitable location.

In some embodiments, when the data is secured using the secure data parser in this manner, only the presence of all required shares and external encryption keys may reassemble the information.

FIG. 37 shows an illustrative overview process 3700 that in some embodiments uses the secure data parser of the present invention. As described above, two very suitable functions of secure data parser 3706 may include encryption 3702 and backup 3704. As such, in some embodiments, secure data parser 3706 may be integrated with a RAID or backup system or a hardware or software cryptographic engine.

The master key processes associated with secure data parser 3706 may include one or more of a pre-encryption process 3708, encryption/transformation process 3710, key protection process 3712, parsing/distribution process 3714, fault tolerance process 3716, share authentication process 3716, and post-encryption process 3720. As detailed in fig. 36, these processes may be performed in several suitable orders or combinations. The combination and order of the processes used may depend on the particular application or use, the level of security desired, whether optional pre-encryption, post-encryption, or both, the redundancy desired, the capabilities or performance of the underlying or integrated system, or any other suitable factor or combination of factors.

The output of the illustrative process 3700 may be two or more shares. As described above, in some embodiments, data may be randomly (or pseudo-randomly) distributed to each of the shares. In other embodiments, a deterministic algorithm (or some suitable combination of random, pseudorandom, and deterministic algorithms) may be used.

In addition to individual protection of information assets, it is sometimes desirable to share information between different groups of users or interested parties. It is then necessary to control access to the shares within a group of users or to share credentials between those users who only allow the members of the group to reload the shares. To this end, in some embodiments of the invention, a workgroup key may be deployed to group members. The workgroup key should be protected and kept secret since a compromised workgroup key could potentially allow someone outside the group to access the information. Some systems and methods for workgroup key deployment and protection are discussed below.

The workgroup key concept allows for enhanced protection of information assets by encrypting key information stored within shares. Once this is done, an attacker does not have access to the workgroup key to reconstruct the information even if all the required shares and external keys are found.

FIG. 38 shows an illustrative block diagram 3800 of storing key and data components within a share. In the example of fig. 3800, the optional pre-encryption and post-encryption steps are omitted, but may be included in other embodiments.

The simplified process of splitting data involves encrypting the data using encryption key 3804 at encryption stage 3802. Portions of encryption key 3804 may then be split and stored in shares 3810 in accordance with the present invention. Portions of split encryption key 3806 may also be stored in shares 3810. Using the split encryption key, the data 3808 is then split and stored in shares 3810.

To recover the data, the split encryption key 3806 may be obtained and recovered in accordance with the present invention. The splitting operation may then be reversed to recover the ciphertext. The encryption key 3804 may also be obtained and recovered and then used to decrypt the ciphertext.

When utilizing a workgroup key, the above process may be altered slightly to protect the encryption key with the workgroup key. The encryption key may then be encrypted by the workgroup key before being stored in the share. The steps of the modification are shown in the illustrative block diagram 3900 of fig. 39.

The simplified process of splitting data using the workgroup key includes first encrypting the data using an encryption key in stage 3902. The encryption key may then be encrypted with the workgroup key in stage 3904. The encryption key encrypted with the workgroup key may then be split into portions and stored within shares 3912. Split key 3908 may also be split and stored in shares 3912. Finally, portions of data 3910 are split and stored in shares 3912 using split key 3908.

To recover data, split keys may be obtained and recovered according to the present invention. The splitting operation may then be reversed to recover the ciphertext in accordance with the present invention. The encryption key (which was encrypted using the workgroup key) may be obtained and recovered. The encryption key may then be decrypted using the workgroup key. Finally, the ciphertext may be decrypted using the encryption key.

There are a variety of security methods for deploying and protecting workgroup keys. The selection of which method to use for a particular application depends on a number of factors. These factors may include the level of security required, cost, convenience, and the number of users in the workgroup. Some common techniques used in some embodiments are provided below.

Hardware-based key storage

Hardware-based schemes typically provide the strongest guarantee for the security of encryption/decryption keys within a cryptographic system. Examples of hardware-based storage schemes include tamper-resistant key token devices that store keys in a portable device (e.g., a smart card/dongle) or non-portable key storage peripherals. These devices are designed to prevent easy copying of the keying material by unauthorized parties. The key may be generated by a trusted authority and distributed to the user, or generated within hardware. Furthermore, many key storage systems provide multi-factor authentication, where the use of a key requires access to both a physical object (a token) and a passphrase (passphrase) or biometric.

Software-based key storage

While dedicated hardware-based storage may be desirable for high security deployments or applications, other deployments may be chosen to store the keys directly on local hardware (e.g., disk, RAM, or non-volatile RAM memory such as a USB drive). This provides a lower level of protection against internal attacks or where an attacker has direct access to the crypto engine.

To protect the keys on the disk, software-based key management often protects the keys by storing the keys in encrypted form under keys derived from other authentication metrics, including passwords and passphrases, the presence of other keys (e.g., from hardware-based schemes), biometrics, or any suitable combination of the above. The level of security provided by these techniques may range from relatively weak key protection mechanisms provided by some operating systems (e.g., MS Windows and Linux) to more robust schemes implemented using multi-factor authentication.

Advantageously, the secure data parser of the present invention may be used in a number of applications and technologies. For example, an email system, a RAID system, a video broadcast system, a database system, a tape backup system, or any other suitable system may have a secure data parser integrated at any suitable level. As noted above, it should be appreciated that the secure data parser may also be integrated for protection and fault tolerance of any type of moving data over any transmission medium, including wired, wireless, or physical transmission media, for example. As an example, voice over IP (VoIP) applications may utilize the secure data parser of the present invention to address problems related to echo and delay that are typically present in VoIP. The need for network retries for missing packets can be eliminated by using fault tolerance, which can guarantee packet delivery even in the event of a loss of a predetermined number of shares. Data packets (e.g., network packets) may also be efficiently split and recovered with minimal delay and buffering "on-the-fly," thereby obtaining a comprehensive solution for various types of data in motion. The secure data parser may act on network data packets, network voice packets, file system data blocks, or any other suitable unit of information. In addition to being integrated with a VoIP application, the secure data parser may be integrated with a file sharing application (e.g., a peer-to-peer file sharing application), a video broadcasting application, an electronic voting or poll application (which may implement an electronic voting protocol such as the Sensus protocol and blind signatures), an email application, or any other network application that requires or desires secure communications.

In some embodiments, the secure data parser of the present invention may provide support for in-transit network data in two distinct phases (i.e., a header generation phase and a data striping phase). A simplified header generation process 4000 and a simplified data partitioning process 4010 are shown in fig. 40A and 40B, respectively. One or both of these processes may be performed on network packets, file system blocks, or any other suitable information.

In some embodiments, the header generation process 4000 may be performed once at the beginning of the network packet stream. In step 4002, a random (or pseudorandom) split encryption key K may be generated. The split encryption key K is then optionally encrypted (e.g., using the workgroup key described above) in an AES key wrapping step 4004. Although AES key wrapping may be used in some embodiments, any suitable key encryption or key wrapping algorithm may be used in other embodiments. AES key wrap step 4004 may operate on the entire split encryption key K, or the split encryption key may be parsed into several blocks (e.g., 64-bit blocks). AES key wrap step 4004 may then operate on the blocks of split encryption keys, if desired.

In step 4006, a secret sharing algorithm (e.g., Shamir) may be used to split the split-cipher key K into multiple key shares. Each key share may then be embedded into one of the output shares (e.g., in a share header). Finally, a share integrity block and (optionally) a post-authentication tag (e.g., MAC) may be appended to the header block of each share. Each header block may be designed to fit within a single data packet.

After header generation is complete (e.g., using simplified header generation process 4000), secure data parser may enter the data partitioning phase using simplified data splitting process 4010. In step 4012, each incoming data packet or data block in the stream is encrypted using the split encryption key K. In step 4014, share integrity information (e.g., hash value H) may be calculated for the ciphertext obtained from step 4012. For example, a SHA-256 hash value may be calculated. Then, in step 4016, the data packet or data block may be divided into two or more data shares using one of the data splitting algorithms described above in accordance with the present invention. In some embodiments, the packets or blocks of data may be split such that each share of data contains a substantially random distribution of encrypted packets or blocks of data. Integrity information (e.g., hash value H) may then be appended to each data share. In some embodiments, an optional post-authentication tag (e.g., MAC) may also be computed and appended to each data share.

Each data share may include metadata necessary to allow proper reconstruction of the data block or data packet. This information may be included in the share header. The metadata may include information such as cryptographic key shares, key identities, share nonces, signature/MAC values, and integrity blocks. To maximize bandwidth efficiency, the metadata may be stored in a compact binary format.

For example, in some embodiments, the share header includes a block of plaintext header that is not encrypted and may include elements such as a Shamir key share, a per-session nonce, a per-share nonce, a key identifier (e.g., a workgroup key identifier and a post-authentication key identifier). The share header may also include an encrypted header block that is encrypted by splitting the encryption key. An integrity header block may also be included in the header, which may include an integrity check on any number of previous blocks (e.g., the previous two blocks). Any other suitable value or information may also be included in the share header.

As shown in the exemplary share format 4100 of fig. 41, a header block 4102 may be associated with two or more output blocks 4104. Each header block, such as header block 4102, may be designed to fit within a single network packet. In some embodiments, after header block 4102 is sent from a first location to a second location, the output block may then be sent. Alternatively, the header block 4102 and the output block 4104 may be transmitted simultaneously in parallel. The transmission may be via one or more similar or dissimilar communication paths.

Each output block may include a data portion 4106 and an integrity/authenticity portion 4108. As described above, each data share may be protected using a share integrity portion that includes share integrity information (e.g., SHA-256 hash values) of the encrypted pre-partitioned data. To verify the integrity of the output blocks at recovery time, the secure data parser may compare the share integrity blocks of each share and then reverse the split algorithm. The hash value of the recovered data may then be verified against the share hash value.

As described above, in some embodiments of the present invention, the secure data parser may be used in conjunction with a tape backup system. For example, according to the present invention, individual bands may be used as nodes (i.e., parts). Any other suitable arrangement may be used. For example, a tape library or subsystem consisting of two or more tapes may be viewed as a single node.

Redundancy may also be used with tape in accordance with the present invention. For example, if the data set is distributed among four tapes (i.e., parts/share), two of the four tapes are needed to recover the original data. It should be appreciated that any suitable number of nodes (i.e., less than the full number of nodes) may be required to recover the original data in accordance with the redundancy features of the present invention. This substantially increases the likelihood of recovery when one or more tapes expire.

Each tape may also be digitally protected with SHA-256, HMAC hash values, any other suitable values, or any combination thereof to ensure against tampering. If any data or hash value on a tape changes, that tape will not be a candidate for recovery and any minimum required number of the remaining tapes will be used to recover the data.

In a conventional tape backup system, when a user requests to write data to or read data from a tape, a Tape Management System (TMS) presents a number corresponding to a physical tape mount. This tape mount points to the physical drive where the data will be mounted. The tape is loaded in the tape magazine by a human tape operator or a tape robot.

Under the present invention, a physical tape mount may be considered a logical mount point to multiple physical tapes. This not only increases data capacity but also improves performance due to parallelism.

To improve performance, the tape node may be or may include a RAID array of disks for storing the tape image. This may enable high speed recovery since data is always available in the protected RAID.

In any of the above embodiments, the data to be protected may be distributed into the shares using deterministic, probabilistic, or both deterministic and probabilistic data distribution techniques. To prevent an attacker from starting a cryptographic attack on any cipher block, the bits in the cipher block may be deterministically distributed to shares. For example, the distribution may be performed using a BitSegment routine, or the BlockSegment routine may be modified to allow portions of the block to be distributed to multiple shares. This strategy may defend against an attacker that accumulates less than "M" shares.

In some embodiments, a keyed secret sharing routine may be employed using keyed information dispersal (e.g., by using a keyed information dispersal algorithm or "IDA"). The keys of the keyed IDA may also be protected by one or more external workgroup keys, one or more shared keys, or any combination of workgroup keys and shared keys. In this way, a multi-factor secret sharing scheme may be employed. In some embodiments, at least the "M" share of the outsourced processing is required as a group key (and/or shared key) in order to reconstruct the data. The IDA (or the key of the IDA) may also be brought into the encryption process. For example, the transformations may be brought into the plaintext (e.g., during a pre-processing layer prior to encryption) and may further protect the plaintext prior to encrypting the plaintext.

For example, in some embodiments keyed information dispersal is used to distribute unique portions of data in a data set into two or more shares. Keyed information dispersal may first encrypt a data set using a session key and then distribute the unique portion of the encrypted data of the data set to two or more encrypted data set shares, or both encrypt the data set and distribute the unique portion of the encrypted data of the data set to two or more encrypted data set shares. For example, to distribute a data set or encrypt a unique portion of a data set, secret sharing (or the above-described methods, such as BitSegment or BlockSegment) may be used. The session key may then optionally be transformed (e.g., using a full packet transform or AoNT) and shared, for example, using secret sharing (or keyed information dispersal and session keys).

In some embodiments, the session key may be encrypted using a shared key (e.g., a workgroup key) before the unique portion of the key is distributed or assigned to two or more session key shares. Two or more user shares may then be formed by combining the at least one encrypted data set share with the at least one session key share. In forming the user shares, in some embodiments, the at least one session key share may be interleaved into the encrypted data set shares. In other embodiments, the at least one session key share may be inserted into the encrypted data set share at a location based at least in part on the shared workgroup key. For example, keyed information dispersal may be used to distribute each session key share to a unique encrypted data set share to form a user share. Interleaving or inserting session key shares into encrypted data set shares at locations based at least in part on the shared workgroup may improve security against cryptographic attacks. In other embodiments, one or more session key shares may be appended to the beginning or end of an encrypted data set share to form a user share. The collection of user shares may then be stored individually on at least one data store. The data store or stores may be located at the same physical location (e.g., on the same magnetic or tape storage device) or geographically separated (e.g., on physically separate servers located at different geographic locations). To reconstruct the original data set, a set of authorized user shares and a shared workgroup key are required.

The keyed information dispersion is secure even in the face of the key acquisition affordance (oracle). For example, take a block cipher E and a key acquisition affordance for E that takes a list of input/output pairs (X) for the block cipher₁，Y₁)、......、(X_C，Y_C) And returns a key K consistent with the input/output example (e.g., Y for all i, Y)_i＝E_K(X_i)). If there is no consistent key, the revealing may return a specific value ≠ T. This affordance can simulate a cryptanalysis attack where keys can be recovered from a list of input/output examples.

In the presence of a key acquisition affordance, the standard block cipher based scheme may fail. For example, in the presence of a key acquisition affordance, a CBC encryption or CBCMAC may become completely unsecured.

If pi^IDAIs IDA scheme and pi^EncIs operated by a certain password EMaking the encryption scheme the schema gives, if the Robust Computational Secret Sharing (RCSS) target is reached when both schemes are combined with any perfect secret sharing scheme (PSS) according to HK1 or HK2 in the schema in which the adversary has a key acquisition affordance (Π)^IDA，Π^Enc) Security is provided against key acquisition attacks.

II if IDA scheme exists ^IDAAnd encryption scheme II^EncSo that the pair of schemes provides security against key acquisition attacks, one way to implement the pair of schemes is to have a "clever" IDA and a "fool" encryption scheme. Another way to implement this pair of schemes is to have "fool-down" IDA and "smart" encryption schemes.

To illustrate the use of a smart IDA and a fool-proof encryption scheme, in some embodiments, the encryption scheme may be a CBC and the IDA may have a "weak privacy" property. The weak privacy properties refer to, for example: if the input to the IDA is a random sequence of blocks M-M₁...M₁And the adversary gets shares from an unauthorized set, there is some block index i that makes it impossible for the adversary to compute M_i. A weak privacy IDA may be established by first applying the information theory AoNT (e.g., the AoNT of Stinson) to M and then applying a simple IDA such as BlockSegment or a bit efficient IDA such as a Rabin scheme (e.g., Reed-Solomon encoding).

To illustrate the use of foolish IDA and smart encryption schemes, in some embodiments, a CBC mode may be used that replaces single encryption with double encryption. Now, any IDA can be used even in case of replication. It is useless for an adversary to have a key acquisition affordance for a block cipher, since the adversary will be denied any single encrypted input/output instance.

Although the smart IDA has value, it is also insignificant in some circumstances, meaning that the "smart" version needed to provide security against key acquisition attacks can be "pushed" elsewhere. For example, in some embodiments, regardless of how smart the IDA is, and regardless of what objective is attempted to be reached with the IDA in the context of HK1/HK2, smart can be derived from the IDA and advance the encryption scheme, leaving a fixed and foolproof IDA.

Based on the foregoing, in some embodiments, a "universally robust" smart IDA Π may be used^IDA. For example, IDA is provided so that Π is the case for all encryption schemes^EncPair (Π)^IDA，Π^Enc) Security against key acquisition attacks is commonly provided.

In some embodiments, an encryption scheme is provided that is RCSS-secure in the face of the key acquisition affordance. This scheme can be integrated with HK1/HK2, with any IDA to achieve security in the face of key acquisition. Using the new scheme may be particularly useful, for example, to make the symmetric encryption scheme more secure against key acquisition attacks.

As mentioned above, the classical secret sharing concept is typically not keyed. Thus, the secret is broken down into shares, or reconstructed from the shares in a manner that requires neither the distributor nor the party that reconstructed the secret to hold any type of symmetric or asymmetric key. However, alternatively, the secure data parser described herein may be keyed. The distributor may provide a symmetric key that is needed for data recovery if this symmetric key is used for data sharing. The secure data parser may use the symmetric key to scatter or distribute the unique portion of the message to be protected to two or more shares.

The shared key may enable multi-factor or two-factor secret sharing (2 FSS). Thus, the adversary needs to exclude two fundamentally different types of security to break the security mechanism. For example, to infringe a secret sharing target, an adversary: (1) a need to obtain a set of authorized player shares; (2) it is necessary to obtain a secret key (or to break the cryptographic mechanism that is keyed by this key) that should not be obtained.

In some embodiments, a new set of additional requirements is added to the RCSS target. These additional requirements may include a "second factor," namely key possession. These additional requirements can be added without reducing the original set of requirements. One set of requirements may relate to failing to break a scheme if the adversary knows the secret key but does not obtain enough shares (e.g., classical or first factor requirements), while another set of requirements may relate to failing to break a scheme if the adversary has the secret key but tries to obtain all shares (e.g., new or second factor requirements).

In some embodiments, there are two second factor requirements: privacy requirements and authenticity requirements. In the privacy requirement a game is involved, where the secret key K and bit b are selected by the environment. Adversaries now provide a pair of equal length messages M in the domain of the secret sharing scheme ₁ ⁰And M₁ ¹. Environment computing M₁ ^bTo obtain vector S of shares₁＝(S₁[1]、...、S₁[n]) And it will share S₁(all of them) to the opponent. Using the same key K and hidden bit b, the adversary can now select another pair of messages (M)₂ ⁰，M₂ ¹) And everything goes as above. The adversary's job is to output the bit b' that he believes to be b. The adversary privacy advantage is 1 less than twice the probability of b ═ b'. The game obtains the following concept: even if all shares are known, if the secret key is missing, the adversary cannot know anything about the shared secret.

In the authenticity requirement, a game may be involved in which the environment selects the secret key K and uses it in the next calls to Share and Recover. In some embodiments, Share and Recover may modify their syntax to reflect the presence of this key. The adversary then selects any message M for it in the domain of the secret sharing scheme₁、...、M_qA Share request is made. In response to each Share request, it obtains a Share S₁、...、S_qCorresponding n vectors. The purpose of an adversary is to forge a new plaintext; if it outputs a vector of shares S' such that it produces a vector that is not { M } when fed to the Recover algorithm₁、...、M_qThat is it wins. This is "clear text integrity The concept of sex.

There are two approaches to implementing multi-factor secret sharing. The first scheme is a general scheme, which is general in the sense that the basic (R) CSS scheme is used in a black box manner. The authenticated encryption scheme is used to encrypt the message to be CSS shared, and the resulting ciphertext may then be distributed, for example, using a secret sharing algorithm (e.g., Blakely or Shamir).

A potentially more efficient scheme is to allow the shared key to be a workgroup key. That is, (1) a randomly generated session key of the (R) CSS scheme may be encrypted using a shared key, and (2) an encryption scheme applied to a message (e.g., a file) may be replaced by an authenticated encryption scheme. This scheme will suffer only minimal degradation in performance.

Although some applications of the secure data parser are described above, it should be clearly understood that the present invention may be integrated with any network application to improve security, fault tolerance, anonymity, or any suitable combination of the above.

Moreover, other combinations, additions, substitutions, and modifications will be apparent to the skilled artisan in view of the disclosure herein.

Claims (34)

1. A method of protecting a data set, the method comprising:

encrypting the data set using the session key to generate an encrypted data set;

encrypting the session key with the shared workgroup key;

distributing each unique portion of the encrypted session key into two or more session key shares;

distributing each unique portion of the encrypted data set into two or more encrypted data set shares; and

two or more user shares are formed by interleaving at least one session key share into at least one encrypted data set share, whereby the data set can be recovered from at least two of the two or more user shares and a shared workgroup key.

2. The method of claim 1, wherein at least one of distributing the unique portions of the session key and distributing the unique portions of the encrypted data set is performed using Robust Computational Secret Sharing (RCSS).

3. The method of claim 1, wherein forming two or more user shares by interleaving at least one session key share with at least one encrypted data set share comprises: inserting the at least one session key share into the at least one encrypted data set share at a location based at least in part on the shared workgroup key.

4. The method of claim 1, further comprising: storing the two or more user shares separately on at least one data store.

5. The method of claim 4, wherein separately storing the two or more user shares on at least one data store comprises: storing the two or more user shares in different locations of the same data store.

6. The method of claim 4, wherein separately storing the two or more user shares on at least one data store comprises: storing the two or more user shares on different data stores.

7. The method of claim 4, wherein separately storing the two or more user shares on at least one data store comprises: storing the two or more user shares on different data stores at different geographic locations.

8. The method of claim 1, wherein distributing the unique portions of the encrypted data set into two or more encrypted data set shares comprises:

generating a random number or a pseudo-random number based at least in part on the session key;

associating the random or pseudo-random number with the two or more encrypted data set shares;

Associating the random or pseudo-random number with a data unit in an encrypted data set; and

determining into which of the two or more encrypted data set shares each data unit is to be distributed based at least in part on the association of the random or pseudorandom number with the two or more user shares and with the data unit.

9. The method of claim 8, wherein each data unit comprises one of a data byte in the data set and a data bit in the data set.

10. The method of claim 1, further comprising generating a session key.

11. An apparatus to protect a data set, the apparatus comprising:

means for encrypting the data set using the session key to generate an encrypted data set;

means for encrypting the session key using the shared workgroup key;

means for distributing unique portions of the encrypted session key into two or more session key shares;

means for distributing unique portions of the encrypted data set into two or more encrypted data set shares; and

means for forming two or more user shares by interleaving at least one session key share into at least one encrypted data set share, whereby the data set can be recovered from at least two of the two or more user shares and a shared workgroup key.

12. The apparatus of claim 11, further comprising means for performing at least one of distributing the unique portions of the session key and distributing the unique portions of the encrypted data set using Robust Computational Secret Sharing (RCSS).

13. The apparatus of claim 11, wherein the means for forming two or more user shares by interleaving at least one session key share with at least one encrypted data set share comprises: means for inserting the at least one session key share into the at least one encrypted data set share at a location based at least in part on the shared workgroup key.

14. The apparatus of claim 11, further comprising: means for storing the two or more user shares separately on at least one data store.

15. The apparatus of claim 14, wherein the means for separately storing the two or more user shares on at least one data store comprises: means for storing the two or more user shares separately on different locations of the same data store.

16. The apparatus of claim 14, wherein the means for separately storing the two or more user shares on at least one data store comprises: means for storing the two or more user shares separately on different data stores.

17. The apparatus of claim 14, wherein the means for separately storing the two or more user shares on at least one data store comprises: means for separately storing the two or more user shares on different data stores at different geographic locations.

18. The apparatus of claim 11, wherein the means for distributing unique portions of the encrypted data set into two or more encrypted data set shares comprises:

means for generating a random number or a pseudo-random number based at least in part on the session key;

means for associating the random or pseudo-random number with the two or more encrypted data set shares;

means for associating the random or pseudo-random number with a data unit in an encrypted data set; and

means for determining into which of the two or more encrypted data set shares each data unit is to be distributed based at least in part on the association of the random or pseudorandom number with the two or more user shares and with the data unit.

19. The apparatus of claim 18, wherein each data unit comprises one of a data byte in the data set and a data bit in the data set.

20. The apparatus of claim 18, further comprising means for generating a session key.

21. A method of protecting a data set, the method comprising:

encrypting the data set using the session key to generate an encrypted data set;

distributing each unique portion of the encrypted session key into two or more session key shares;

distributing each unique portion of the encrypted data set into two or more encrypted data set shares; and

two or more user shares are formed by interleaving at least one session key share into at least one encrypted data set share, whereby the data set can be recovered from at least two of the two or more user shares.

22. The method of claim 21, wherein at least one of distributing the unique portions of the session key and distributing the unique portions of the encrypted data set is performed using Robust Computational Secret Sharing (RCSS).

23. The method of claim 21, wherein forming two or more user shares by interleaving at least one session key share with at least one encrypted data set share comprises: inserting the at least one session key share into the at least one encrypted data set share at a location based at least in part on the shared workgroup key.

24. The method of claim 21, further comprising: storing the two or more user shares separately on at least one data store.

25. The method of claim 24, wherein separately storing the two or more user shares on at least one data store comprises one of: storing the two or more user shares in different locations of the same data store; storing the two or more user shares on different data stores; and storing the two or more user shares on different data stores at different geographic locations.

26. The method of claim 21, wherein distributing the unique portions of the encrypted data set into two or more encrypted data set shares comprises:

generating a random number or a pseudo-random number based at least in part on the session key;

associating the random or pseudo-random number with the two or more encrypted data set shares;

associating the random or pseudo-random number with a data unit in an encrypted data set; and

determining into which of the two or more encrypted data set shares each data unit is to be distributed based at least in part on the association of the random or pseudorandom number with the two or more user shares and with the data unit.

27. The method of claim 26, wherein each data unit comprises one of a data byte in the data set and a data bit in the data set.

28. An apparatus to protect a data set, the apparatus comprising:

means for encrypting the data set using the session key to generate an encrypted data set;

means for distributing unique portions of the encrypted session key into two or more session key shares;

means for distributing unique portions of the encrypted data set into two or more encrypted data set shares; and

means for forming two or more user shares by interleaving at least one session key share into at least one encrypted data set share, whereby the data set can be recovered from at least two of the two or more user shares.

29. The apparatus of claim 28, further comprising: means for performing at least one of distributing the unique portions of the session key and distributing the unique portions of the encrypted data set using Robust Computational Secret Sharing (RCSS).

30. The apparatus of claim 28, wherein the means for forming two or more user shares by interleaving at least one session key share with at least one encrypted data set share comprises: means for inserting the at least one session key share into the at least one encrypted data set share at a location based at least in part on the shared workgroup key.

31. The apparatus of claim 28, further comprising: means for storing the two or more user shares separately on at least one data store.

32. The apparatus of claim 31, wherein the means for separately storing the two or more user shares on the at least one data store comprises one of: means for storing the two or more user shares separately on different locations of the same data store; means for storing the two or more user shares separately on different data stores; and means for separately storing the two or more user shares on different data stores at different geographic locations.

33. The apparatus of claim 28, wherein the means for distributing unique portions of the encrypted data set into two or more encrypted data set shares comprises:

means for generating a random number or a pseudo-random number based at least in part on the session key;

means for associating the random or pseudo-random number with the two or more encrypted data set shares;

means for associating the random or pseudo-random number with a data unit in an encrypted data set; and

Means for determining into which of the two or more encrypted data set shares each data unit is to be distributed based at least in part on the association of the random or pseudorandom number with the two or more user shares and with the data unit.

34. The apparatus of claim 33, wherein each data unit comprises one of a data byte in the data set and a data bit in the data set.