System and method for non-repudiation within a public key infrastructure

Embodiments of the disclosure provide systems, methods, and computer readable instructions for non-repudiation communications, including provisions for non-repudiation of the identities of the sender and receiver, non-repudiation of the information sent and the information received, the time that various portions of the transaction or communication occurred, and other parameters associated therewith. Embodiments of the disclosure can be readily implemented in conjunction with public key systems to advantageously provide complete non-repudiation of origin and delivery of digital data.

COPYRIGHT NOTICE

TECHNICAL FIELD

Embodiments of the disclosure relate generally to data security and more particularly to a system and method for communication verification within a public key infrastructure.

BACKGROUND

As the digital age progresses, the use of electronic transmission and storage of data has become the norm for many users. Particularly in electronic communications, email has played an ever-increasing role. However, without proper security and privacy measures, this increased importance of email can lead to severe consequences. An information security infrastructure can be useful in providing the confidentiality, integrity and availability of information, which are the main concerns of many individuals as well as entities such as businesses, universities, hospitals, and so on who have a greater need for secure data transmission, storage and maintenance.

Currently, Public Key Infrastructure (PKI) systems enable users to exchange data securely and privately over a network such as the Internet or an intranet through the use of a public and a private cryptographic key pair that may be obtained and shared through a trusted third party authority. The public key cryptography, also known as asymmetric cryptography, is perhaps the most common method on the Internet for authenticating a message sender or encrypting a message. A PKI system has the following features:One or more trusted third party certificate authorities (CAs)—a CA is an organization that issues digital certificates;Digital certificates—these are electronic credentials, each of which identifies an individual or an organization and which includes the public key or information about the public key;One or more registration authorities (RAs)—an RA is an entity that is responsible for identification and authentication of digital certificates but does not sign or issue digital certificates as it is delegated with certain tasks on behalf of an authorized CA;One or more directory services that can store and, when necessary, revoke the digital certificates; andA certificate management system.

In the public key cryptography, a public key and a private key are created simultaneously using the same algorithm provided by a CA. The public key is made publicly available as part of a digital certificate in a directory that all parties can access. The private key is not meant to be shared with anyone or sent across an unsecured network such as the Internet.

As an example, User A can obtain (from User B, a public directory, a network administrator, etc.) User B's public key, encrypt a message using User B's public key, and sends User B the encrypted message over an unsecured network. When User B receives the encrypted message, User B can decrypt the encrypted message using his private key which was created with the public key used by User A to encrypt the message. In addition to encrypting messages to ensure privacy, User A can authenticate herself by using her private key to encrypt a digital certificate or signature. When User B receives the digital certificate, User B can decrypt the encrypted digital certificate using User A's public key. This proves to User B the identity of the sender (i.e., User A).

Despite the benefits provided by electronic communications systems and methods, and more particularly communications systems which rely on PKI, room for improved systems and methods of secure communication exists.

SUMMARY OF THE DISCLOSURE

Many legislative bodies now require PKI for digital signatures and encryption in an enterprise setting. Non-compliance violations can have severe consequences. As a result, there is a growing demand for PKI solutions which can ensure that the identity of the person, application or device that sends or receives an exact set of data at an exact point of time is irrefutably verifiable and unspoofable. However, as the above example illustrates, current PKI systems have several security weaknesses.

More specifically, the encrypted digital signature is neither tied to the encrypted message nor to the time at which the message is sent. Thus, the authentication could be spoofed. Moreover, existing PKI systems are typically complicated to install and difficult to support.

In addition, the sender of information has several concerns. First, the sender and receiver (e.g. user A and user B) are typically concerned that the receiver, and only the receiver, is able to read the sent information. They also typically share a concern that the information be delivered to the receiver uncorrupted. Because the information is signed by the sender, the integrity of the data can be confirmed by the receiver. But the sender has no such assurance. In some cases, a receiver does in fact receive the information in an uncorrupted condition and yet claims otherwise. In such cases, the sender would need to prove that what the sender originally claimed to have sent was indeed sent. Additionally, the sender would need to prove this fact without any reliance on the receiver. The receiver might not retain information or allow access to the receiver's private key to assist the sender in proving the sender's contentions.

The receiver, too, has similar concerns. The receiver may wish to be able to access the information without acknowledging the receipt of the information until the receiver knows that the receiver can indeed access the information. If the sender claims that the sender sent something other than what the receiver actually received, the receiver also needs the ability to prove that the sender is incorrect. As with the sender wanting to be sure that the information only goes to the receiver, the receiver wants to be certain the that information actually came from the sender. Additionally, the parties, and perhaps others, may want to know when the various steps of the transaction occur and what transpired. In the context of digital security, non-repudiation means that it can be verified that the sender and the recipient were, in fact, the parties who claimed to send or receive the message, respectively. More specifically, non-repudiation of origin proves that data has been sent, and non-repudiation of delivery proves it has been received.

Embodiments of the disclosure provide a system and method for non-repudiation communications including provisions for non-repudiation of the identities of the sender and receiver, non-repudiation of the information sent and the information received, the time that various portions of the transaction (or communication) occurred, and other parameters associated with the communication. Embodiments of the disclosure can be readily implemented on public key systems to advantageously provide complete non-repudiation communications. The necessary programming and networking languages, techniques, and equipment are known to those skilled in the art.

In some embodiments, a method is provided in which a service provider facilitates communication between a sender and a receiver of a message which includes information (or content) the security of which one, or both, of the sender, receiver, or both wish to maintain. In the method, the sender creates the message and a “parcel” with which to deliver it. The parcel may contain the following items: the encrypted data file, a one-way hash of the data file, an encrypted copy of the hash, two differently encrypted copies of the session key, two copies of a file to be used to verify the session key (each copy encrypted differently), and an encrypted copy of the receiver's public key. As will be described herein, these items allow the sender to prove that the sender sent the data file after properly encrypting it with the session key that the sender sent the receiver. The sender can also prove whether the receiver received and decrypted the data file or is falsely alleging otherwise. Likewise, the receiver can prove whether the receiver received the data file and the proper session key sent by the sender. The receiver can also prove whether the sender properly encrypted the data file and the corresponding session key. Additionally, the identities of the sender and the receiver can also be proved by each party. For instance, using the encrypted public key of the receiver, the service provider can validate the identity of the receiver. The system may also verify that the sender sent the parcel by comparing the two versions of the hash in the parcel. If any discrepancies occur during the transaction, the service provider may refuse to further process the transaction and generate appropriate warnings and notifications.

The service provider may also verify that the sender intended to send the session key to the receiver designated by the sender. To do so, the service provider may forward the encrypted session key to the receiver. Since this copy of the session key was encrypted with the receiver's public key, only the receiver should be able to decrypt the copy. Thus, the service provider may verify that the receiver decrypted the session key by, for instance, requiring the receiver to decrypt the encrypted key validation file (with the session key) and return the results before allowing further processing of the transaction. If, the receiver has succeeded in returning the key validation file, then the service provider can release the encrypted data file to the receiver. However, to provide the sender assurance that the receiver receives and decrypts the data file successfully, the service provider may also require that the receiver prove that the receiver did so. In some embodiments, the receiver must therefore return the unencrypted data file to the service provider as proof of success.

However, in some embodiments, where it is desired that the security of the data file be maintained, even from the service provider, other proof can be required of the receiver. For instance, the receiver may be required to encrypt (with the receiver's private key) a copy of the encrypted data file which was sent to the receiver. Additionally, the receiver may be required to return a hash (using the same one-way hash function that the sender used to generate the hash) encrypted with the receiver's private key. Thus, the service provider can match the data file that was sent with the data file that was received and verify (by comparing the hashes) that the contents of the data file were successfully delivered.

In some embodiments, a system is provided which can facilitate non-repudiation communications. Through cryptography and other processes described in more detail herein, the system of the current embodiment acts as a broker between the sending and receiving parties. These parties usually desire that they will agree on the data that was actually sent and received and on who sent it and who received it. When a disagreement arises, however, the system allows the party who is correct access to enough information to prove what data was actually sent (or received) and who sent (or received) it. Optionally, the sender can choose to encrypt the data being sent. When encrypted delivery is chosen, the delivery transaction produces metadata that assures the integrity of the delivery process in general and the encrypted data file in particular.

In some embodiments, the system does not have the ability to determine the contents of the message it delivers. For example, the data to be delivered is converted into a form accessible only by the receiver. In this embodiment, to allow the individual parties to prove either the transmission or receipt of the information, the parties may be required to digitally sign particular pieces of information at various stages in the transaction in order to advance to the next stage of the transaction. These pieces of information can be retained by the system so that in the case where the parties do disagree, the retained information can be used by the parties to prove or disprove each other's allegations. Once the parties sign an agreement on the result of the transaction much, if not all, of the information retained during the transaction may be deleted.

As the foregoing demonstrates, embodiments of the disclosure allow the sender to mathematically prove that the sender sent the data file properly encrypted with the session key and can prove that the receiver received the properly encrypted data file and the proper session key with which to decrypt it. Moreover, the sender can do so without any cooperation from the receiver including doing so without the receiver's private key. Likewise, the receiver can prove that the sender sent a corrupted (or incorrect) data file, an incorrect session key, or an improperly encrypted data file. Again, the receiver can do so without needing the sender's private key. Furthermore, embodiments disclosed herein allow the content of the data file to remain secure while providing these other advantages. Accordingly, the parties to the transaction may enjoy secure and verifiable communications in accordance with embodiments of the disclosure.

Thus, from a sender's perspective, embodiments of the disclosure provide several advantages. First, senders may be assured of receiving credit for successfully sending information to a recipient when they have in fact done so. Furthermore, the senders may demonstrate their success with, or without, the cooperation of the receivers. Moreover, the senders may demonstrate their success without compromising the security of the information which they sent. From a receiver's perspective, embodiments of the disclosure provide advantages also. For instance, a receiver may be assured of receiving credit for the information which they received whether it is consistent with the information which the sender sent. For another example, receivers may demonstrate that the received information was inconsistent with the information that was sent and do so with, or without, the sender's cooperation and without compromising the security of the data sent (and received).

DETAILED DESCRIPTION

Preferred embodiments of the disclosure are illustrated in the FIGURES, like numerals generally being used to refer to like and corresponding parts of the various drawings. Embodiments of the disclosure provide systems, apparatus, and methods for verifying communications.

FIG. 1illustrates a prior art communications system100that enables the exchange of information between sender102and receiver106via communication devices104and108. Examples of devices104and108may include personal computers, blackberries, personal digital assistants, JAVA enabled devices, etc. Devices104and108may be connected over a local area network, wide area network (e.g., the Internet), or other communications link110(e.g., a wireless communication or telephony system). InFIG. 1eavesdropper114may intercept message112sent from sender102to receiver106. Eavesdropper114may alter the contents of the message112for malicious or arbitrary reasons. Noise, system100malfunctions, errors on the part of parties102and106, etc. may also cause differences between the transmitted communication112and as-received message116. Thus, in general, message112may be altered to become message116as-received by receiver106.

In some cases, one or both of the users102and106may assert that they either sent message112(which, in fact, they did not send) or that they did not receive message112(when, in fact, they did). In some cases, one of parties102or106may alter message112so that message116has different content than original message112. In these cases, it can be quite difficult to discern the truth of what happened. When the message112or116are encrypted, the situation can be even more difficult because only the party(s) with the key to decrypting the messages112and116can examine the actual content in question to determine what transpired. In these types of situations, party102or106might assert that message112was altered, was never sent, or never received and is said to repudiate the communication or transaction.

FIG. 2depicts an embodiment for facilitating non-repudiated communications between parties102and106. More particularly, system200may be configured to act as a broker for providing non-repudiation of communications between sender102and receiver106. In some embodiments, system200may cause information to be generated such that when there is disagreement between parties102and106regarding the communication, either or both parties102and106may have all of the information necessary to prove his or her assertions.

In some embodiments, sender102can choose to encrypt message112which sender102desires to send. When encryption is chosen, system200can provide a number of assurances about the integrity of the transaction. Many of these assurances may also be provided for unencrypted messages. Thus, message112can be converted into a form which is only accessible by receiver106and still be delivered by system200. In some embodiments, system200may lack the ability to determine the contents of message112. In this context, system200can mathematically prove what actually happened when receiver106claims that message112that was delivered is not the same as message112that was sent.

In some embodiments, system200requires parties102and106to digitally sign particular pieces of information at various stages in the transaction in order to advance to the next stage of the transaction. Some embodiments require that certain pieces of information be retained by system200so that in cases where parties102and106do disagree, the retained information can be used by parties102and106to prove or disprove their allegations. This retained information can be stored until parties102and106“sign” an agreement on the result of the transaction. After which, the received data may be deleted.

In system200, computer or server120is disposed in the communication link110between parties102and106. Computer120can include some form of removable memory device122(e.g., a compact disc drive), processor124, memory126, and (in this case) database128stored in memory126(but shown here separately for illustrative purposes). In some embodiments, computer120may be in communication with public key server130although it need not be. Disc drive122may hold instructions on removable computer readable media that, when read and executed by processor124, allow processor124to operate computer120. Memory126can be a hard drive to hold information (including the instructions) for ready access by processor124. More particularly, memory126can contain database128which stores the various pieces of information associated with the messages112and116that enable each party102and106to prove that they either sent or received message112and116which they claim to have sent or received.

In some embodiments, processor124may communicate with server130to obtain information related to messages112and116such as, for instance, the public keys for parties102and106. However, in some embodiments of the disclosure, system200possesses the ability to generate public/private key pairs without relying on server130or indeed on an external PKI system. Such embodiments are disclosed in co-owned, co-pending U.S. patent application Ser. No. 11/948,512, filed Nov. 30, 2007, entitled “SYSTEM AND METHOD FOR SIMPLIFIED PUBLIC KEY INFRASTRUCTURE ARCHITECTURE AND IMPLEMENTATION,” which is incorporated herein by reference.

In some embodiments, a message involving a data file (e.g., message itself or an attachment) may be processed according to method300illustrated byFIG. 3. If the data file has not been created, sender102may do so as shown at step302. The data file may be any type of file including, but not limited to, an e-mail message, an attachment, a text file, a spreadsheet file, a graphics file, a video file, an image file, an application, etc. At step304, sender102can create a parcel with which the data file will be processed in order to deliver the data file to receiver106. In some embodiments, creation of the parcel is largely automated.

The identities of sender102and receiver106may then be verified using information in the parcel along with certain publicly available information (e.g., the public keys of sender102and receiver106) at operations306and308respectively. If both parties102and106are successfully verified, the method300may proceed. Otherwise, processing of the data file may terminate as shown at operation310.

In some embodiments, with the identities of parties102and106verified, the method300may continue by forwarding an encrypted copy of a session key to receiver106at step312. Along with the session key, a key validation file may also be sent to the receiver (see step312). If receiver106is able to decrypt the session key validation file (and prove it), then the session key sent to receiver106is deemed to be valid and processing may therefore continue (see step316). If not, processing may be discontinued. With the session key validated, the encrypted data file may be forwarded to the receiver at step318. However, in some embodiments, mere delivery of the encrypted data file, though, does not necessarily mean that receiver106will be able to decrypt it successfully. Nor does delivery of the data file, in some embodiments, necessarily mean that sender102sent the correct file, encrypted it correctly, or sent it with the same session key which sender102supposedly also sent to receiver106. Thus, the method300may also require that receiver106provide certain pieces of information after decrypting the data file D. If receiver106cannot, or will not, produce this proof then the communication may be deemed to have failed at step320. Thus, at steps322and324, an examination of the information trail created at various steps in the method300makes it possible to determine when the failure occurred. This is so even without assistance from one, or the other, of parties102and106or access to the unencrypted contents of the data file. Otherwise (that is, if receiver106did indeed provide proof of the information that receiver106actually received and decrypted), the transaction may be deemed a success at step320. Either way, appropriate notifications can be sent to parties102and106and the success or failure of the transaction may be recorded for future reference.

FIG. 4summarizes one embodiment of parcel400which sender102may create in step304ofFIG. 3. Parcel400ofFIG. 4can include: first data file402, hash of unencrypted data file404, first encrypted version of the hash406, first session key408, second version of the session key410, first session key validation file412, second version of the session key validation file414, and encrypted version of the public key of the receiver416.FIG. 5summarizes other pieces of information which may be created during the transaction in accordance with some embodiments. The other pieces of information500created during the processing of the message in some embodiments can include second version of the data file518, first hash time-stamp520, second encrypted version of the hash522, second hash time-stamp524, third version of the session key validation file526, sender validation file528, and second version of the user validation file530.

These pieces of information402,404,406,408,410,412,414,416,518,520,522,524,526,528, and530may include two versions of the data file, an unencrypted hash of the data file, two encrypted versions of the hash, two time-stamps related to the encrypted hashes, two versions of the session key, three versions of a session key validation file, an encrypted version of the receiver's public key, and two versions of a user validation file. In some embodiments, many of these pieces of information402,404,406,408,410,412,414,416,518,520,522,524,526,528, and530are “versions” of some other piece of information because changes may occur to the underlying piece of information between versions.

With reference now toFIG. 6, an automated method600for sending data file D in accordance with some embodiments is illustrated.FIG. 6andFIG. 7(to be discussed below) may be read in conjunction with table800shown inFIG. 8which correlates the pieces of information shown in summaries400and500and certain mathematical terms which can be used to denote these pieces of information. Sender602and the receiver702of the data file are referred to, at times, as “Alice” and “Bob,” respectively, in keeping with a common practice in the art. As such, these names are not intended to limit the disclosure in any fashion. Many of the mathematical terms may be designated with terms corresponding to “Alice” and “Bob” and that include “A”, “a”, “B”, and “b.”FIG. 6also shows that certain entities (i.e., sender602, receiver702ofFIG. 7, software modules, and hardware items) can be involved in the process.FIG. 6also shows sender602, client604(i.e., the sender's computer) associated with sender602, cryptography library606, system608, and database610. In some embodiments, sender's client604can be used to generate, or designate, data file(s) D involved in the transaction as well as to automate many of the actions associated with the sending of data file D to receiver702. For instance, crypto library606may be used to generate cryptographic keys and to perform other cryptographic functions. System608may be used in some embodiments as an intermediary, broker, escrow agent, or service provider for processing data file D and the information summarized inFIGS. 4-5and8. Furthermore, system608may be a software module, program, application, or other entity capable of processing the transaction. Database610may be used to store information that may be received as well as information that may be generated during the processing of transactions.

FIG. 6depicts, that to send data file D, sender602may begin by designating, at step611(via sender's client604), the data file(s) D which sender602desires to send. Note that in some embodiments, certain actions may be attributed to sender602. However, these actions may be executed by client604instead of sender602without departing from the scope of the disclosure. That being said, in addition to data file D, sender602can provide a password (here “keystore”) to access sender's keystore which may be stored on client604. Client604can be configured to respond to sender's designation of data file D by accessing crypto library606to create parcel400for processing data file D.

In some embodiments, crypto library606can be used to create one-way hash a#D (or checksum) of data file D at step612. To do so, client604may send crypto library606a request to sign data file D (that is, to create hash a#D) along with data file D and sender's private key Ka. Crypto library606can then perform the one-way hash on data file D and return results a#D to client604. Since hash a#D has been signed with sender's602private key Ka, the value it produces can be used in some embodiments to verify that sender602(here for example Ann) did sign and send any subsequent hashes which purport to have been created from data file D by sender602. Thus, in some embodiments, hash a#D can be used to represent what sender602claims to be sending to receiver702. Subsequently, receiver702can also hash data file D and compare the result to sender's hash a#D to verify whether the contents of delivered data file D match the contents of data file D as it was sent by sender602.

Additionally, client604can send to crypto library606(at step614) a request for session key Ks. In some embodiments, session key Ks is symmetrical such that any receiver702of files encrypted with session key Ks can decrypt those files if they have session key Ks. In some embodiments, this feature allows intended receiver702to decrypt data file D′ if all parties602and702involved act as they purport to have acted (e.g., sender602sends the correct parcel and receiver702correctly decrypts the actual data file D′ sent in the parcel). At step616, client604can also send a request to crypto library606to encrypt data file D with session key Ks. In some embodiments, system608need not have access to session key Ks so that the security of data file D is preserved even from system608.

In some embodiments, client604can also be configured to send a request to crypto library606to encrypt (already encrypted) hash a#D with sender's private key to arrive at doubly encrypted version a#D′ of hash a#D. This feature allows others to decrypt encrypted hash a#D to arrive at hash a#D. It also allows sender602to attest that data file D′ was sent and was encrypted with session key Ks (see step618). In some embodiments, client604can be configured to generate a session key validation file at step619. The session key validation file can be a file of randomly generated data that is about the size of data file D. Accordingly, the session key validation file will be referred to as “random data” R1hereinafter although session key validation file R1could be any type of data. In some embodiments, random data R1can be used to allow receiver702to prove that receiver702did not receive the proper session key Ks.

Client604can also be configured, in some embodiments, to create the remaining portions of parcel400. For example, client604can create the two versions R1′ and a#R1of encrypted random data R1.FIG. 6depicts that one version of random data R1′ may be encrypted with session key Ks and the other version a#R1of random data R1can be encrypted with sender's602private key Ka at steps620and622respectively. Thus, the first version of encrypted random data R1′ can be decrypted by any entity with access to session key Ks (e.g., intended receiver702). For instance, receiver702can do so to show what the contents of random data R1(that sender602sent) were without the cooperation of sender602.

In step624, of some embodiments, client604can retrieve receiver's public key (here for example Bob's public key kB) for subsequent use in encrypting session key Ks (at step626) to produce one of the encrypted versions of session key Ks′b. The only entity who can decrypt this version of session key Ks′b, in some embodiments, is the receiver (i.e., here, Bob who is the only one with his private key Kb which is required to perform this decryption). Client604may also be configured to request that crypto library606encrypt session key Ks with sender's public key kA at step628to produce the other encrypted version ks′a of session key Ks. This piece of information Ks′a may be retained and used if a dispute regarding the transaction occurs. In some embodiments, this encrypted version Ks′a of session key Ks allows sender602(without cooperation from receiver702) to reproduce session key Ks that sender602sent with parcel400(see step628).

In some embodiments, client604can be configured to request that crypto library606encrypt public key kB of intended receiver702with private key Ka of sender602to produce encrypted version a#kB of the receiver's public key kB of step630. Thus, in some embodiments, this feature of parcel400allows system608, and others (using the sender's public key kA), to determine to whom sender602actually attempted to send data file D.

Next, In some embodiments, client604shown inFIG. 6can assemble parcel400and send it (including hash a#D of the unencrypted data file D, first encrypted version of hash a#D′, first session key Ks′a, second version of session key Ks′b, first session key validation file a#R1, second version of session key validation file R1′, encrypted version of public key of receiver a#kB, and data file D′) to system608at step632. In one embodiment, after doing so, sender602has purportedly completed sender's602portion of the transaction. In some embodiments, after doing so, sender602purports to have sent data file D encrypted with session key Ks to intended receiver702. Because sender602or receiver702might repudiate their activities with respect to the transaction, system608can be configured, in some embodiments, to allow either party or both parties602and702to determine what transpired during the transaction. Indeed, by sending parcel400instead of just encrypted data file D′ (and session key Ks), sender602may be attesting that 1) encrypted data file D′ is the encrypted form of the contents of data file D that produced hash a#D and 2) that session key Ks was encrypted with receiver's public key kB to produce the encrypted session key Ks′b.

In step634, the hash of data file a#D and sender's signature a#D′ of hash a#D can be time-stamped in some embodiments. Thus, without revealing the contents of data file D, system608can create a record of what sender602purports represents the contents of the data file (hash a#D) and sender's signature of that attestation (hash a#D′). System608also verifies sender's signature a#kB of intended receiver's public key kB in step636of some embodiments. To do so, system608can retrieve public key kB corresponding to receiver702which sender602indicated was intended receiver702at step611. Then, in step638of one embodiment, system608can request that crypto library606decrypt sender's signature a#kB of receiver's public key kB. If the results of the decryption do not match known public key kB of receiver702then either, an error (unintended or otherwise) associated with the identity of intended receiver702or the identity of sender602has been detected. Thus, all further processing of the transaction can be stopped and appropriate notifications can be sent out. If the results agree with known public key kB of receiver702, processing can instead continue.

In some embodiments, sender's signature a#D′ of D′ (of encrypted data file D) can be decrypted with public key of sender kA by system608in step640of some embodiments. If the results of step640do not match hash a#D which sender602sent with parcel400, then an error associated with hash a#D, encrypted data file D′, or the identity of sender602has been detected. Accordingly, processing of the transaction can either be stopped or continued depending on the results of the decryption. If, however, both the verification of receiver's public key kB and the verification of hash a#D succeed, system608can save parcel400and attempt to deliver encrypted data file D′ to receiver702.

FIG. 7depicts method700of securely delivering data file D in accordance with some embodiments.FIG. 7also shows a delivery infrastructure700that can mirror sender's infrastructure ofFIG. 6. The delivery infrastructure may include another client704(which may automate many of steps of receiving data file D), and separate crypto library706. In some embodiments, arrangements other than the combined infrastructures ofFIGS. 6 and 7may be used to process transactions.

Method700may begin with system608notifying receiver702that parcel400is awaiting delivery to receiver702. If receiver702desires to receive data file D, receiver702(at step711) may request its delivery. Before sending receiver702any version data file D, in some embodiments, system608may create a user validation file with which to test whether the entity requesting data file D is indeed intended receiver702. The user validation file can be similar to the session key validation file (i.e., random data R1). In some embodiments, the user validation file can contain a relatively small amount of random data. Thus, hereinafter, the user validation file is referred to as random data R2. In some embodiments, at steps712and714, system608can obtain random data R2and public key kB of receiver702indicated by sender602in step611. System608may then have sender's crypto library606encrypt random data R2with receiver's public key kB at step716. Since the identity of sender602has been verified, but not the identity of the requestor, it is the sender's crypto library606that may be used at step716. This use of the sender's crypto library606in some embodiments helps prevent spoofing of the transaction by means of preventing the interception the unencrypted contents of random data R2. Because only receiver702has receiver's private key Kb, only intended receiver702should be able to decrypt encrypted random data R2′. Encrypted random data R2′ may then be sent to the requestor (here, presumably, receiver702).

In some embodiments, the requestor must prove that the requestor is intended receiver702or at least be in possession of receiver's private key Kb which corresponds to the receiver's702public key kB (that sender602claims to have used in encrypting session key Ks′b). Since private keys Ka and Kb are generally held securely, success at this step means that the requestor is indeed intended receiver702. In step718, in some embodiments, method700therefore can require that the requestor decrypt encrypted random data R2′. To prove that the requestor did so, the method700may also require that the requestor send the decrypted random data R2cback to system608. In step720, the decrypted version of random data R2creturned by the requestor may then be compared to the original version of random data R2. If the two versions R2and R2cof the random data differ, processing of the transaction can be stopped since the requestor is apparently not intended receiver702.

Otherwise, transaction processing in accordance with method700may continue since the requestor has proven that the requestor is intended receiver702. In some embodiments, system608can now attempt to deliver the encrypted session key Ks′b. However, to ensure that receiver702cannot successfully repudiate the delivery of session key Ks where receiver702did not act as he purports, method700may also require receiver702to prove that receiver702could use session key Ks to decrypt some data that was supposedly encrypted with session key Ks. In this context, system608may return to receiver702session key Ks′b (now decrypted and re-encrypted with the receiver's public key kB) and encrypted random data R1′ (as-received from sender602and supposedly encrypted with session key Ks). See step720.

If receiver702desires to proceed, receiver702may decrypt session key Ks′b using receiver's private key Kb (which only intended receiver702can do) as in step722. Using decrypted version of session key Ks from step722, receiver702can then decrypt random data R1′ at step724. At step726, and to provide evidence whether receiver702received proper session key Ks, method700can require that receiver702sign random data R1and return the result b#R1to system608for comparison with signed random data a#R1(as received from sender602). Thus, in step728, system608can retrieve the version of random data a#R1signed by sender602(and stored in database610) and decrypt both signed versions a#R1and b#R1of random data R1. These decryptions can be made possible because both versions a#R1and b#R1of the signed random data R1were signed with private keys Ka and Kb of sender602and receiver702. Accordingly, known public keys kA and kB of these parties602and702can be used by system608for the decryptions. If the two decrypted versions of random data a#R1and b#R1differ, an error related to either session key Ks or random data R1has been detected as shown by step728. In this context, processing of the transaction may cease.

In some embodiments, If the comparison was successful, method700may continue with the delivery of encrypted data file D′ to receiver702(see step728). Method700may require proof that the transaction has successfully progressed. For instance, method700may require receiver702to prove that receiver702received encrypted data file D′. Again, it may be desired to continue to safeguard the contents of data file D. Thus, instead of returning a copy of decrypted data file D (in some embodiments), method700may require that receiver702return signed copy b#D′ of encrypted data file (as received from system608) and hash b#D of unencrypted data file D. Receiver's client704can also request that crypto library706encrypt as-received data file D′ with receiver's private key Kb in step730. Even though system608could decrypt this version of data file b#D′, doing so would not compromise the contents of data file D. Rather, in some embodiments, all that system608can recover from the returned version of data file b#D′ is encrypted data file D′ returned by receiver702.

In some embodiments', receiver's client704can decrypt encrypted data file D′ using session key Ks as shown at Step732. Then, to attest to the information that system608actually delivered, receiver's client704can perform a one-way hash on decrypted data file D in step734. Receiver's client704can also be configured to perform the same one-way hash as sender's client604performed so that, in some embodiments, the two versions of hash a#D and b#D (one from sender602and one from receiver702) can be the same. Receiver's client704can then return newly encrypted version b#D′ of as-received data file D′ and hash b#D as calculated by receiver's client704thereby allowing receiver702to attest to the information that receiver702actually received.

At step736, system608may then check the evidence of the transaction (i.e., hash b#D) to determine whether the delivery was successful. In some embodiments, system608compares hash a#D as calculated by sender602and hash b#D as calculated by receiver702(see step736). If the two versions of hash a#D and b#D are equal the version of hash b#D received from receiver702can be time-stamped and saved in database610to record the time that the transaction ended successfully as shown by step740. Subsequently, if a disagreement between what sender602claims sender602sent and what receiver702claims to have received arises, hash a#D generated by sender602(along with the fact that hash b#D produced by receiver702matches the sender's version of hash a#D) can help sender602prove the integrity of encrypted data file D′ that sender602claims to have sent with parcel400.

Otherwise, if the two versions of hash a#D and b#D differ, then failure of the transaction may be recorded in database610, processing may be stopped, and the parties may be notified. In some embodiments, no data is deleted from the system when this failure occurs. One possible reason for not deleting the data is that receiver702has now apparently downloaded data file D′, (in its correct form or not) and session key Ks to decrypt that data file D′. In the previously discussed transaction failures, receiver702apparently never received data file D′ whether correct or not, and it is likely that no one will be claiming (or able to prove) that receiver702did receive data file D′. In contrast, if receiver702has apparently downloaded the data file D′, the disagreement can go to whether or not sender602performed as sender602claims. Methods600and700allow the each party or both parties602and702to prove what actually happened despite the possible refusal of one party to cooperate (e.g., to provide private key Ka or Kb necessary to decrypt certain pieces of information generated during the transaction).

In some embodiments, corruption of data file D′ can occur between when data file D′ was stored by system608(e.g., in database610) and when receiver702received data file D′. This corruption could cause hash a#D and b#D values to differ. As a result, it might initially appear that receiver702did not perform as receiver702claims. However, some embodiments provide that system608may re-try the delivery of data file D′ (at step716) as often as deemed desirable. If necessary, In some embodiments, encrypted data file D′ and session key Ks′b could even be delivered on tangible computer readable medium to ensure that receiver702gets data file D′. When the transaction does complete successfully, system608can record that fact in step738.

However, if the delivery cannot be successfully accomplished, in some embodiments, sender602may want to prove that encrypted data file D′ and encrypted session key Ks′b that sender602sent at step632(i.e., with parcel400) can yield hash b#D of the unencrypted contents of data file D that receiver702sent to system608at step736. Session key Ks′a that sender602encrypted with the sender's public key kA allows sender602to do so in one embodiment as follows. First, sender602can prove that that version of session key Ks′a is the same key as the version of session key Ks′b that was sent to receiver702. Furthermore, because receiver702may not cooperate, sender602may want to prove this assertion without access to receiver's private key Kb or any information in the receiver's702sole possession.

Thus, sender602can decrypt the version of session key Ks′a which sender602included in parcel400using sender's private key Ka. Then sender602can decrypt random data R1′. Using public key kB of receiver702, sender602can also decrypt the random data b#R1returned to system608by receiver702. And, if the results of the two decryptions agree, then sender602has shown that session key Ks′a that successfully decrypted random data R1matches session key Ks′b that receiver702successfully used to decrypt random data R1′. In some embodiments, sender602can use sender's decrypted version of session key Ks′a to decrypt data file D′ which was sent in parcel400. Sender602can also perform the one-way hash on unencrypted data file D to re-generate hash a#D that was sent in the parcel. Thus, if the hash sender602re-generates matches hash a#D sent in parcel400, sender602has proved that sender602sent data file D′ correctly encrypted with session key Ks′b that was sent along with data file D′ in parcel400.

In some embodiments, receiver702may desire to prove that sender602sent some information other than what sender602claims to have sent. To do so receiver702can decrypt session key Ks′b with receiver's private key Kb and use decrypted version of session key Ks (which receiver702downloaded) to decrypt encrypted data file D′ which receiver702also downloaded. The receiver can then 1) encrypt data file D′ with receiver's private key Kb 2) perform the one-way hash on data file D which receiver702decrypted, or 3) both. The results of these operations can then be compared against the proof of the delivery b#D and b#D′ which the receiver provided in step736. If the results of these operations match results b#D and b#D′ stored in step736, it shows that receiver702did receive the information receiver702claims to have received.

To illustrate how sender602(for example “Alice”) and receiver702(for example “Bob”) may conduct a transaction, reference is now made toFIGS. 9-15which illustrate screenshots of a graphic user interfaces (GUI) for conducting such a transaction. To send a parcel Alice may click on the “Parcels” tab shown inFIG. 9so that she can have access to parcel creation functionality discussed with reference toFIG. 6. Alice may then click on the “Distribution Lists” link in the left navigation bar of the GUI shown inFIG. 10to create a distribution list. She can quickly create a distribution list by entering a name in the Distribution List text area and clicking the “Create” button. In the following screen shown inFIG. 11, Alice has created a distribution list called “finance” in this manner. She may then click on the “Find Users” button or enter a search criteria and then click the “Find Users” button. At this point, in some embodiments, Alice will see all users with whom she can securely exchange documents and other information through the embodiments discussed herein. This list of available receivers may be based on group permissions and user roles within the system, enterprise, or other grouping to which Alice may belong. Since, in this embodiment, both Alice and Bob have public and private keys and both have been given send/receive privileges in the finance group, Alice sees the GUI ofFIG. 10. Alice may select the users shown byFIG. 10and may then select the “Add” action from the “Action” menu. The GUI ofFIG. 10shows that the selected users get added to her “finance” distribution list.

To send a document to Bob, for example, Alice then selects Bob's user id and then selects the “New Parcel” action from the “Actions” menu. SeeFIG. 11. Alice may then see a “send parcel” applet in her browser. First, she can enter her password to her keystore to unlock her collection of keys in the GUI ofFIG. 12. Alice may then click “Next” and get prompted to select the documents (or other information) that she wants to send to Bob as shown inFIG. 13. Alice may then click “Next” and be prompted to enter a parcel name and a message (if she desires to do so) as shown inFIG. 14. Alice can then click “Finish” and have the parcel created and sent by her computer. In the alternative, she can click “Next” and view a summary of the parcel. SeeFIG. 15. If she is satisfied with her selections, she may then click “Finish” so that the parcel gets sent to Bob. Thus, in this embodiment Alice sent a document to Bob securely by adding him to a distribution list and then selecting his user id to send a parcel to. Furthermore, because the parcel was created and sent in accordance with an embodiment of the disclosure Alice will be able to prove that she sent the message as she claims. To send the message and to render this proof she did not need to get any information from Bob. A similar set of GUI windows may also be provided for Bob so that his secure receipt of the message (and the documents or other information) may be as user-friendly and verifiable as was Alice's secure creation and transmission of the message.

In addition to the foregoing embodiments, the present disclosure provides programs stored on computer readable medium to operate computers and devices according to the principles of the present disclosure. Computer readable media include, but are not limited to, magnetic storage medium (e.g., hard disk drives, floppy disks, tape, etc.), optical storage (CD-ROMs, optical disks, etc.), and volatile and non-volatile memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs, DRAMs, SRAMs, flash memory, firmware, programmable logic, etc.). Furthermore, computer readable media include transmission media (network transmission line, wireless transmission media, signals propagating through space, radio waves, infrared signals, etc.) and server memories. Moreover, computer readable media includes many other types of memory too numerous for practical listing herein, existing and future types of media incorporating similar functionally as incorporate in the foregoing exemplary types of computer readable media, and any combinations thereof. The programs and applications stored on the computer readable media in turn include one or more computer executable instructions which are read by the various devices and executed. Each of these instructions causes the executing device to perform the functions coded or otherwise documented in it. As persons of ordinary skill in the art can appreciate, such programs can take many different forms such as applications, operating systems, Perl scripts, JAVA applets, C programs, compilable (or compiled) programs, interpretable (or interpreted) programs, natural language programs, assembly language programs, higher order programs, embedded programs, and many other existing and future forms which provide similar functionality as the foregoing examples, and any combinations thereof.

Although the disclosure has been described in detail herein with reference to the illustrated embodiments, it should be understood that the description is by way of example only and is not to be construed in a limiting sense. It is to be further understood, therefore, that numerous changes in the details of the embodiment of the disclosure and additional embodiments of the disclosure will be apparent, and may be made by, persons of ordinary skill in the art having reference to this description. It is contemplated that all such changes and additional embodiments are within scope of the disclosure as claimed below.