Source: http://www.google.com/patents/US7376835?ie=ISO-8859-1&dq=%22Meaning-based+advertising+and+document+relevance+determination%22
Timestamp: 2015-05-25 01:49:38
Document Index: 694785985

Matched Legal Cases: ['arty 312', 'arty 412', 'arty 412', 'arty 412', 'arty 412', 'arty 412', 'arty 412', 'arty 412', 'arty 412', 'arty 412', 'arty 412', 'arty 412', 'arty 412', 'arty 412']

Patent US7376835 - Implementing nonrepudiation and audit using authentication assertions and ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA communication system (410) wherewith sources (414) and targets (416) employ a key server (420) to exchange transactions (424). A first request to the key server includes a source assertion (422) from an authentication authority (418), and optionally a key (430). The key server provides a transaction...http://www.google.com/patents/US7376835?utm_source=gb-gplus-sharePatent US7376835 - Implementing nonrepudiation and audit using authentication assertions and key serversAdvanced Patent SearchPublication numberUS7376835 B2Publication typeGrantApplication numberUS 10/707,191Publication dateMay 20, 2008Filing dateNov 25, 2003Priority dateApr 25, 2000Fee statusPaidAlso published asCA2506120A1, EP1573474A2, US20040151323, WO2004049137A2, WO2004049137A3Publication number10707191, 707191, US 7376835 B2, US 7376835B2, US-B2-7376835, US7376835 B2, US7376835B2InventorsTerry M. Olkin, Jahanshah MorehOriginal AssigneeSecure Data In Motion, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (17), Non-Patent Citations (1), Referenced by (3), Classifications (18), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetImplementing nonrepudiation and audit using authentication assertions and key servers
US 7376835 B2Abstract
A communication system (410) wherewith sources (414) and targets (416) employ a key server (420) to exchange transactions (424). A first request to the key server includes a source assertion (422) from an authentication authority (418), and optionally a key (430). The key server provides a transaction ID (428), and the key if not already provided, in reply to this request. The key server stores the transaction ID and source assertion. The source encrypts the transaction and sends it with the transaction ID to the targets. A second request to the key server includes a target assertion and the transaction ID. The key server provides the key in reply to this request. The key server also stores the target assertion in association with the transaction ID. The respective assertions then establish the source and targets of the transaction in a manner that cannot plausibly be repudiated.
1. A method for a transaction source and a transaction target to exchange a transaction that cannot be repudiated, the method comprising:
(a) receiving a first request for a transaction identifier to identify the transaction, wherein said request includes a source authentication assertion;
(b) verifying said source authentication assertion;
(c) storing said transaction identifier and information from said source authentication assertion, thereby establishing information making the transaction source unable to plausibly repudiate once it encrypts and sends the transaction;
(d) providing said transaction identifier in reply to said first request so that the transaction and said transaction identifier can be sent to the transaction target;
(e) receiving a second request for a decryption key to decrypt the transaction once it has been received by the transaction target, wherein said second request includes said transaction identifier and a target authentication assertion;
(f) verifying said target authentication assertion;
(g) storing information from said target authentication assertion with the transaction identifier; and
(h) providing said decryption key in reply to said second request so that the transaction can be decrypted, thereby establishing information making the transaction target unable to plausibly repudiate being a recipient of the transaction.
2. The method of claim 1, wherein said step (d) includes also providing an encryption key to encrypt the transaction.
(i) receiving an information request for source information about the transaction source, wherein said information request includes said transaction identifier;
(j) retrieving at least some of said information from said source authentication assertion stored in said step (c) with said transaction identifier and determining said source information therefrom; and
(k) providing said source information in reply to said information request.
(i) receiving an information request for target information, wherein said information request includes said transaction identifier and information identifying the transaction target;
(j) determining if said information identifying the transaction target matches with any said information from said target authentication assertion stored with the transaction identifier stored in said step (g) and determining said target information therefrom; and
(k) providing said target information in reply to said information request.
5. A method for establishing a transaction as nonrepudiate able by a transaction source that is the origin of the transaction, the method comprising:
(a) receiving a request for a transaction identifier to identify the transaction, wherein said request includes a source authentication assertion;
(c) storing said transaction identifier and information from said source authentication assertion; and
(d) providing said transaction identifier in reply to said request, thereby establishing information making the transaction source unable to plausibly repudiate being the origin of the transaction.
6. The method of claim 5, wherein said step (d) includes also providing an encryption key to encrypt the transaction.
7. The method of claim 5, the method further comprising:
(e) receiving an information request for source information about the transaction source, wherein said information request includes said transaction identifier;
(f) retrieving at least some of said information from said source authentication assertion stored in said step (c) with said transaction identifier and determining said source information therefrom; and
(g) providing said source information in reply to said information request.
8. The method of claim 7, wherein said source information indicates who the transaction source actually is.
said information request received in said step (e) also includes information identifying a party believed to be the transaction source; and
said source information provided in said step (g) indicates merely whether said party is the transaction source, thereby responding to said information request without specifically identifying the transaction source.
said step (c) includes also storing a decryption key usable to decrypt the transaction; and
said step (g) includes also providing said decryption key, thereby facilitating decryption of the transaction by a party making said information request even when said party is not the transaction source or a target of the transaction.
said information request received in said step (e) also includes the transaction; and
said step (g) includes decrypting the transaction before providing said source information in reply to said information request.
said source information provided in said step (g) indicates merely whether said party is the transaction source, thereby responding to the second request without specifically identifying the transaction source.
13. The method of claim 11, wherein said step (g) includes also providing the transaction in decrypted form in said reply to said information request, thereby facilitating a party making said information request being able to confirm the content of the transaction even when said party is not the transaction source or a target of the transaction.
14. A method for establishing a transaction as nonrepudiate able by a transaction target that is a recipient of the transaction, wherein a transaction identifier identifying the transaction and a decryption key usable to decrypt the transaction have been pre-stored, the method comprising:
(a) receiving a request for the decryption key, wherein said request includes the transaction identifier and a target authentication assertion;
(b) verifying said target authentication assertion;
(c) storing information from said target authentication assertion with the transaction identifier; and
(d) providing the decryption key in reply to said request, thereby establishing information making the transaction target unable to plausibly repudiate being a recipient of the transaction.
(e) receiving an information request for target information, wherein said information request includes said transaction identifier and information identifying the transaction target;
(f) retrieving at least some of said information from said target authentication assertion stored in said step (c) with said transaction identifier and determining said target information therefrom; and
(g) providing said target information in reply to said information request.
said step (g) includes also providing said decryption key, thereby facilitating decryption of the transaction by a party making said information request even when said party is not the transaction source or a transaction target.
said step (g) includes decrypting the transaction before providing said identity information.
18. The method of claim 17, wherein said step (g) includes also providing the transaction in decrypted form in said reply to said information request, thereby facilitating a party making said information request being able to confirm the content of the transaction even when said party is not the transaction source or a transaction target.
19. A system for a transaction source and a transaction target to exchange a transaction that cannot be repudiated, comprising:
a computerized key server;
said key server suitable for receiving a first request via a network for a transaction identifier to identify the transaction, wherein said first request includes a source authentication assertion;
said key server suitable for receiving a second request via said network for a decryption key usable to decrypt the transaction, wherein said second request includes said transaction identifier and a target authentication assertion;
said key server suitable for verifying said source authentication assertion and said target authentication assertion;
said key server suitable for storing said transaction identifier, information from said source authentication assertion, and information from said target authentication in association in a database;
said key server suitable for providing a first reply to said first request via said network that includes said transaction identifier; and
said key server suitable for providing a second reply to said second request via said network that includes said decryption key, thereby establishing information making the transaction source unable to plausibly repudiate once it encrypts and sends the transaction and also making the transaction target unable to plausibly repudiate once it is provided said decryption key.
20. The system of claim 19, wherein said key server is further suitable for providing an encryption key to encrypt the transaction in said first reply.
said key server is further suitable for receiving an information request for source information about the transaction source, wherein said information request includes said transaction identifier;
said key server is further suitable for retrieving said information from said source authentication assertion stored with said transaction identifier from said database and determining said source information therefrom; and
said key server is further suitable for providing said source information in reply to said information request.
said key server is further suitable for receiving an information request for target, wherein said information request includes said transaction identifier and information identifying the transaction target;
said key server is further suitable for determining if said information identifying the transaction target matches with any said information from said target authentication assertion stored with the transaction identifier and determining said target information therefrom; and
said key server is further suitable for providing said target information in reply to said information request.
23. A system for establishing a transaction as nonrepudiate able by a transaction source that is the origin of the transaction, comprising:
said key server suitable for receiving a request via a network for a transaction identifier to identify the transaction, wherein said request includes a source authentication assertion;
said key server suitable for verifying said source authentication assertion;
said key server suitable for storing said transaction identifier and information from said source authentication assertion in a database; and
said key server suitable for providing a reply via said network that includes said transaction identifier, thereby establishing information making the transaction source unable to plausibly repudiate once it encrypts and sends the transaction.
24. The system of claim 23, wherein said key server is further suitable for providing an encryption key to encrypt the transaction in said reply.
said key server is further suitable for retrieving information from said source authentication assertion stored with said transaction identifier from said database, and determining said source information therefrom; and
26. A system for establishing a transaction as nonrepudiate able by a transaction target that is a recipient of the transaction, wherein a transaction identifier identifying the transaction and a decryption key usable to decrypt the transaction have been pre-stored in a database, comprising:
said key server suitable for receiving a request via a network for the decryption key, wherein said request includes the transaction identifier and a target authentication assertion;
said key server suitable for verifying said target authentication assertion;
said key server suitable for storing information from said target authentication assertion with the transaction identifier in the database; and
said key server suitable for providing a reply via said network that includes the decryption key, thereby establishing information making the transaction target unable to plausibly repudiate.
said key server is further suitable for receiving an information request for target information, wherein said information request includes said transaction identifier and information identifying the transaction target;
said key server is further suitable for retrieving at least some of said information from said target authentication assertion stored with said transaction identifier and determining said target information therefrom; and
This is a continuation-in-part of application Ser. No. 10/707,190, filed Nov. 25, 2003, which is a continuation-in-part of application Ser. No. 10/305,726, filed Nov. 26, 2002, which is a continuation-in-part of application Ser. No. 09/558,691, filed Apr. 25, 2000, now issued as U.S. Pat. No. 6,584,564 on Jun. 24, 2003.
The present invention relates generally to providing security for messages communicated in networks, including the Internet, and specifically to establishing information to audit the messages and make them nonrepudiate able.
For illustration purposes we will use electronic email to provide background. E-mail is good for this because it always involves a transaction (the e-mail), a transaction originator (the sender of the e-mail), and transaction targets (one or more recipients of the e-mail). It also assumes a decoupled environment, where the sender and recipients do not directly communicate with each other. The reading of an e-mail constitutes an event, and not reading an e-mail within a specified period of time also constitutes an event. Knowledge of such events can be particularly useful, both in business and other contexts.
Accordingly, prior art cryptosystems, and PKI systems in particular, have also proven to be wanting when it comes to determining events related to digital communications, including but not necessarily limited to business communications. As this increasingly became apparent, the present inventors developed a “System For Implementing Business Processes Using Key Server Events.” This is covered in U.S. patent application Ser. No. 10/707,190, hereby incorporated by reference in its entirety.
The approaches discussed above have still not addressed all concerns with the use digital communications. The general prior art systems, as well as the prior work by the present inventors, have not provided ways to that well address two particularly vexing problems: communication nonrepudiation and auditing.
Existing systems for digital message communications that attempt to provide either nonrepudiation or auditing have a number of limitations. For instance, these systems are not transparent. Technologies such as PKI burden the user with maintaining a private key and actively using it for producing a signature. Additionally, a party needing to verify a transaction must have a copy of, or otherwise retrieve the digital certificate of the transaction signer. Moreover, existing technologies do not provide a single service for both nonrepudiation and audit. PKI-based technologies require the use of a Public Key Infrastructure that is trusted by all parties (both originator and target of a transaction). Non-PKI technologies (e.g., storing a transaction log in a database) use a completely different mechanism and do not interoperate with PKI. The existing systems thus use PKI-based technology or non-PKI technology, but are unable to practically interoperate with both and yet not require either. The existing technologies also offer only a single level of strength for nonrepudiation, when varying degrees are usually appropriate for varying situations. For example, in PKI the strength of nonrepudiation is equivalent to the assurance level of the underlying certificate. The transacting party can only change the strength by using a different certificate, having a different level of assurance. Existing technologies also provide rigid trust rules for nonrepudiation and audit. For example, in a PKI system the party that verifies the transaction must trust the certificate of the signer. In a non-PKI system, the verifier must trust the system that keeps the transaction logs.
Accordingly, prior art crypto and PKI systems have not adequately solved the problems of nonrepudiation and auditing in digital message communications.
Briefly one preferred embodiment of the present invention is a method for a transaction source and a transaction target to exchange a transaction that cannot be repudiated.
A first request for a transaction identifier to identify the transaction is received, wherein this request includes a source authentication assertion. The source authentication assertion is then verified. The transaction identifier and information from the source authentication assertion are stored, thereby establishing information making the transaction source unable to plausibly repudiate once it encrypts and sends the transaction. The transaction identifier is provided in reply to the first request so that the transaction and the transaction identifier can be sent to the transaction target. A second request for a decryption key to decrypt the transaction is received, once it has been received by the transaction target, wherein the second request includes the transaction identifier and a target authentication assertion. The target authentication assertion is then verified. Information from the target authentication assertion is also stored with the transaction identifier. And the decryption key is then provided in reply to the second request so that the transaction can be decrypted, and thereby establishing information making the transaction target unable to plausibly repudiate being a recipient of the transaction.
Briefly another preferred embodiment of the present invention is a method for establishing a transaction as nonrepudiate able by a transaction source that is the origin of the transaction. A request for a transaction identifier to identify the transaction is received, wherein this request includes a source authentication assertion. The source authentication assertion is then verified. The transaction identifier and information from the source authentication assertion are stored. And the transaction identifier is provided in reply to the request, thereby establishing information making the transaction source unable to plausibly repudiate being the origin of the transaction.
Briefly another preferred embodiment of the present invention is a method for establishing a transaction as nonrepudiate able by a transaction target that is a recipient of the transaction, wherein a transaction identifier identifying the transaction and a decryption key usable to decrypt the transaction have been pre-stored. A request for the decryption key is received, wherein this request includes the transaction identifier and a target authentication assertion. The target authentication assertion is then verified. Information from the target authentication assertion is stored with the transaction identifier. And the decryption key is provided in reply to the request, thereby establishing information making the transaction target unable to plausibly repudiate being a recipient of the transaction.
Briefly another preferred embodiment of the present invention is system for a transaction source and a transaction target to exchange a transaction that cannot be repudiated. A computerized key server is provided. The key server is suitable for receiving a first request, via a network, for a transaction identifier to identify the transaction, wherein this first request includes a source authentication assertion. The key server is also suitable for receiving a second request, via the network, for a decryption key usable to decrypt the transaction, wherein this second request includes the transaction identifier and a target authentication assertion. The key server is also suitable for verifying the source authentication assertion and the target authentication assertion. The key server is also suitable for storing the transaction identifier, information from the source authentication assertion, and information from the target authentication in association in a database. The key server is also suitable for providing a first reply to the first request, via the network, that includes the transaction identifier. And the key server is also suitable for providing a second reply to the second request, via the network, that includes the decryption key, thereby establishing information making the transaction source unable to plausibly repudiate once it encrypts and sends the transaction and also making the transaction target unable to plausibly repudiate once it is provided the decryption key.
Briefly another preferred embodiment of the present invention is a system for establishing a transaction as nonrepudiate able by a transaction source that is the origin of the transaction. A computerized key server is provided. The key server is suitable for receiving a request, via a network, for a transaction identifier to identify the transaction, wherein this request includes a source authentication assertion. The key server is also suitable for verifying the source authentication assertion. The key server is also suitable for storing the transaction identifier and information from the source authentication assertion in a database. And the key server is also suitable for providing a reply, via the network, that includes the transaction identifier, thereby establishing information making the transaction source unable to plausibly repudiate once it encrypts and sends the transaction.
Briefly another preferred embodiment of the present invention is a system for establishing a transaction as nonrepudiate able by a transaction target that is a recipient of the transaction, wherein a transaction identifier identifying the transaction and a decryption key usable to decrypt the transaction have been pre-stored in a database. A computerized key server is provided. The key server is suitable for receiving a request, via a network, for the decryption key, wherein this request includes the transaction identifier and a target authentication assertion. The key server is also suitable for verifying the target authentication assertion. The key server is also suitable for storing information from the target authentication assertion with the transaction identifier in the database. And the key server is also suitable for providing a reply, via the network, that includes the decryption key, thereby establishing information making the transaction target unable to plausibly repudiate.
An advantage of the present invention is that it provides a single service for both nonrepudiation and audit.
Another advantage of the invention is that it permits multiple levels of strength for nonrepudiation, to use when varying degrees are appropriate for varying situations.
And, another advantage of the invention is that it is nonburdensome to users, not relying on the need for pre-obtained keys, digital certificates, directories to look up such data in beforehand for all transaction targets, and all transacting parties having to use a rigid uniform scheme for such.
FIG. 2 a-c depict e-mail forms which may be used by the embodiment in FIG. 1, wherein FIG. 2 a is a conventional send form, FIG. 2 b is a send form which is modified to work with the embodiment in FIG. 1, and FIG. 2 c is a conventional receive form;
FIG. 6 a-e are the tables in FIG. 5 with descriptions for the fields used therein, wherein FIG. 6 a is of user data, FIG. 6 b is of message data, FIG. 6 c is of destination data, FIG. 6 d is of alias data for users, FIG. 6 e is of optional distribution list data, and FIG. 6 f is of member data for such distribution lists;
FIG. 11 is a block diagram depicting a communication system able to determine process events that may use four basic components;
FIG. 12 is a block diagram showing the flow of information related to controlling events;
FIG. 13 is a block diagram showing the flow of information related to positive events;
FIG. 14 is a block diagram showing the flow of information related to negative events;
FIG. 15 is a block diagram depicting how an embodiment of the present inventive communication system may use four basic components;
FIG. 16 is a flow chart depicting a suitable process by which the communication system can establish data in a database for later nonrepudiation and audit purposes;
FIG. 17 is a flow chart depicting a suitable process by which data established in the database can be used to counter attempted repudiation by the source; and
FIG. 18 is a flow chart depicting a suitable process by which data established in the database can be used to counter attempted repudiation by the target.
Unknown; A preferred embodiment of the present invention is a system for implementing nonrepudiation and audit using authentication assertions and key servers. As illustrated in the various drawings herein, and particularly in the view of FIG. 15, preferred embodiments of the invention are depicted by the general reference character 410.
Before discussing the present inventive communication system 410, we first discuss the background of key servers for secure messaging. This is essentially the content of application Ser. No. 10/707,190, application Ser. No. 10/305,726, and U.S. Pat. No. 6,584,564 by the present inventors.
In a stage 38 the sending unit 18 sends the now encrypted secure e-mail 14. This can be essentially transparent or seamless to the sender 12, being handled in the software module 26 of the sending unit 18 by passing the now encrypted secure e-mail 14 to a conventional e-mail type application and automatically providing a suitable “Send” command. The secure e-mail 14 then proceeds in conventional manner to the e-mail server 22, arriving in the in-box of each of the target receivers 16. Notably, the body of the secure e-mail 14 is encrypted during the entire time that it is passing between the sending unit 18 and the receiving units 20. Optionally, the subject may also be encrypted during this time.
In a stage 40 the secure e-mail 14 arrives in the in-box of each receiver 16. When a receiver 16 opens the secure e-mail 14, using their receiving unit 20, the software module 26 for the receiving unit 20 detects that the secure e-mail 14 is encrypted. Depending upon its configuration, the software module 26 can then prompt the receiver 16 for a password or use one already known to it.
FIG. 2 a-c depict e-mail forms 50 which the secure e-mail system 10 may use. FIG. 2 a is a conventional send form 52 a. FIG. 2 b is a send form 52 b that is essentially the same as send form 52 a, but that is modified to work with the secure e-mail system 10. And FIG. 2 c is a conventional receive form 54 that can be used with the secure e-mail system 10.
The send forms 52 a-b both include receiver id fields 56, subject fields 58, and body fields 60. They also both include a conventional send button 62. The only difference between the send form 52 a of FIG. 2 a (conventional) and the send form 52 b of FIG. 2 b (modified) is that the latter also includes a send securely button 64. While it may be desirable in some embodiments to entirely replace the send button 62 with the send securely button 64, that is not anticipated to become common. The receive form 54 of FIG. 2 c includes receiver id fields 56 (To: and Cc), a subject field 58, a body field 60, and also a sender id field 66. Understanding the various fields in these forms will be helpful for the following discussion.
Since a key goal of the secure e-mail system 10 is ease of use, employing it with web-based e-mail applications particularly facilitates operation by new users and simplifies operation by existing, sophisticated Internet users. Many Internet service providers (ISPs) today supply browser application software to their users. One example is America Online (AOL,™), which provides its users with a pre-configured “private label” browser application. The pre-installed option 44 permits including the secure e-mail system 10 in the private label browser, and minimizes any set-up burden. Default settings can be set for any configuration options, and the senders 12 and receivers 16 can then optionally tailor the software modules 26 as desired.
The user-installed option 46 may be implemented in many variations. One variation 46 a is permanent installation of the software module 26 as a plug-in. Another variation 46 b is transitory “installation” of the software module 26 as an applet upon each use of the secure e-mail system 10, e.g., a Java applet obtained by using a particular web portal such as Yahoo!(™). Still another variation 46 c is a script driven installation, i.e., essentially a conventional full blown software application installation rather than a compartmentalized plug-in type installation. And yet other variations 46 d are possible, say, combinations of those described or even new approaches to installation entirely.
Particular examples of settings in the configuration options 48 may include: an encrypt subject setting 48 a, a cache password setting 48 b, a cache time setting 48 c, an expiration setting 48 d, a maximum reads setting 48 e, and others 48 f. The encrypt subject setting 48 a controls whether a software module 26 encrypts the subject field 58 (FIG. 2 a-c) as well as the body field 60 of the secure e-mail 14. The default typically will be to not encrypt the subject.
In the inventors' presently preferred embodiment only two fields are typically modified. The body field 60 is always modified by encrypting it. And depending on the configuration settings, specifically the encrypt subject setting 48 a described above, the subject field 58 may also be changed.
The database 100 also includes a sentMail table 104. This includes records each having fields for: a messageId 104 a, a senderId 104 b, a dateSent 104 c, a numRecipients 104 d, a messageKey 104 e, a maxDeliveries 104 f, an expiration 104 g, a sealSalt 104 h, a subject 104 i, a lastRead 104 j, and a deliverAfter 104 k. A receivers table 106 is provided as well. As can be seen in FIG. 5, the messageId 104 a in the sentMail table 104 is relationally linked to a messageId 106 a in the receivers table 106. Thus, this receivers table 106 contains data for the receivers 16 specified in respective secure e-mails 14. The receivers table 106 further includes records each having fields for: a receiverAddr 106 b, a firstRequest 106 c, and a numRequests 106 d. FIG. 6 a-f are tables of the data fields used by the preferred embodiment. The tables in FIG. 6 a-d are important to the core operation of the secure e-mail system 10, while the tables of FIG. 6 e-f relate to optional features of the secure e-mail system 10.
The text in the tables of FIG. 6 a-d describes some of the particular fields, with the primary fields discussed further presently. FIG. 6 a is the users table 102 of FIG. 5. This contains data records for each user, sender 12 or receiver 16, which is registered with the secure e-mail system 10. As each user registers, they are assigned a UserId (userId 102 a) and they choose a Password (password 102 b) that are stored here. The preferred value of the Password (password 102 b) is H(p+s) where p is the cleartext password and 0 is a salt (salt 102 c) concatenated with the cleartext password. FIG. 6 b is the sentMail table 104 of FIG. 5. This contains data records for each secure e-mail 14 in the secure e-mail system 10. FIG. 6 c is the receivers table 106 of FIG. 5. This contains destination data for each secure e-mail 14 which is to be deliverable by the secure e-mail system 10. Since a record gets generated in this table for each receiver 16 (individual or list group) of each secure e-mail 14 that is sent, it is expected that this table will be the largest by far in the secure e-mail system 10. A null value in the FirstRequest field (firstRequest 106 c) implies that the receiver 16 has not requested to read the secure e-mail 14. FIG. 6 d is the user aliases table 103 of FIG. 5. This contains data for all known e-mail addresses (emailAddress 103 a) for each given user (userId 103 b, relationally linked to userId 102 a in the users table 102). Thus single users may be known by multiple e-mail addresses, or aliases.
The fields of FIG. 6 e-f are not discussed further beyond the following. These tables are used by optional features, and the text in them provides sufficient detail such that one skilled in the art can appreciate the uses of these fields. FIG. 6 e is a table of the data used to permit the use of e-mail distribution lists. This table allows the users to create distribution lists. An owner can always update the list, but the owner need not actually be a member of the list. This latter feature is particularly useful for list administrators. And FIG. 6 f is a table of the data used to permit the use of the distribution lists. This table contains data about the members of each distribution list.
Of course, other tables and other fields for other data than this shown in FIG. 5 and FIG. 6 a-f are also possible, and some of the above fields may be optional and can be omitted in some embodiments of the secure e-mail system 10.
The use of secure socket layer (SSL) was mentioned above. Since a goal of the present secure e-mail system 10 is ease of use, the inventors' present preferred embodiment employs SSL. It is currently considered secure in the industry, being widely used in common browsers, with the average Internet user today using it and not even being aware that they are doing so. It should be appreciated, however, that the use of SSL is not a requirement. Other security protocols may alternately be used.
Km=One-time, unique key associated with an e-mail;
Ps=Sender's password;
Pr=Receiver's password;
{p}k=p encrypted with key k;
{p}ssl=p encrypted with the SSL session key; and
H(p)=One-way hash of p.
FIG. 7 is a flow chart depicting the presently preferred encryption process 120. At the time the sender 12 is ready to send a secure e-mail 14, an HTML send form 52 b (FIG. 2 b) is present with plaintext in the body field 60. It is assumed here that the sender 12 has already registered with the security server 24 and that an appropriate software module 26 has been installed into their browser. It is also assumed that the sender 12 is using only a browser to send the secure e-mail 14. The security aspects should be the same regardless of the actual mail client used, and this is used to keep the following explanation simple.
the e-mail address of the sender 12 (emailAddress 103 a);
the contents of the To, CC, and BCC: fields (instances of receiverAddr 106 b);
1) If the emailAddress 103 a for the sender 12 is unknown, the encryption process 120 can determine a known emailAddress 103 a or stop. The emailAddress 103 a might be unknown for various reasons. One common example will be that the sender 12 is new to the security server 24. In this case the software module 26 can be directed to open a separate browsing window which allows the sender 12 to register on the spot. Another reason that the emailAddress 103 a can be unknown is due to a user error. One simple source of such errors can be that multiple users share the same browser. A sender 12 can then be requested to clarify their identity.
----------BEGIN SECURECORP SECURED EMAIL----------
<encrypted Part>encrypted body</encrypted Part>
----------END SECURECORP SECURED EMAIL----------
If this part of the secure e-mail 14 includes an encrypted body, this is converted from a raw bit stream (post encryption) to an encoded stream so that the encrypted body element is composed of rows of printable (ASCII) characters. If this is an attachment, that is not necessary.
Finally, in a step 140 the software module 26 performs the same action as if the sender 12 had pressed the send button 62 in the send form 52 b in the first place. It posts to the e-mail server 22 (perhaps via an e-mail capable web server, e.g., Yahoo!(™), Hotmail(™), etc.). The difference is that the value in the body field 60 of the form being posted is now encrypted and encoded as described above. Similarly, any attachments are encrypted as described above. From the point of view of a conventional e-mail server 22 or a web server, the result looks like a normal e-mail message whose body is just a bunch of gibberish. The secure e-mail 14 can then travel through the normal Internet mail system to arrive at its various destinations.
Returning briefly to FIG. 4, this also stylistically depicts the preferred approach for the software modules 26 to determine whether a secure e-mail 14 is being received. The software module 26 in the receiving unit 20 examines the stream 70 of pages 72 looking for any that contain a secure e-mail 14. The software module 26 can determine whether a page 72 contains a secure e-mail 14 by scanning for “----------BEGIN SECURECORP SECURED EMAIL----------” type tags. This can be done quickly, permitting minimal latency in delivering pages which should not be processed further. If an actual candidate page 72 a is found it is removed from the stream 70, processed as now discussed, and replaced into the stream 70 as a processed page 72 b, and thus made available for reading by the receiver 16.
In a step 158 the following information is then sent to the security server 24 (via SSL):the e-mail address of the receiver 16 (emailAddress 103 a); the password 102 b of the receiver 16; and the messageId 104 a. In a step 160 the security server 24 proceeds depending on the result of an authentication sub-process.
1) The security server 24 hashes the receiver's password with the salt 102 c to determine the password 102 b. 2) The password 102 b is verified, based in part on association with the emailAddress 103 a of the receiver 16. If this part of the authentication fails, the response to the software module 26 results in the receiver 16 being prompted for the correct password 102 b or the decryption process 150 aborting.
The use of the seal provides for nonrepudiation via the operator of the security server 24 acting as a trusted third-party notary. In particular, a judge can determine whether a message was actually sent from a sender 12 by giving the operator of the security server 24 the seal, the hash of the message and the name (to map to the userId 102 a) of the sender 12. As was described for the preferred embodiment, a receiver 16 can verify that a seal is genuine (which proves that the sender 12 actually wrote and sent a particular secure e-mail 14), by sending the seal and a hash of the body of the received message to the security server 24. The security server 24 can then provide an assurance in this regard. The seal is used at the security server 24 to determine whether it is genuine by recomputing it based on the three known quantities. This technique is known as “nonrepudiation with secret keys” and is taught by Kaufman et al. in “Network Security: Private Communication in a Public World,” Prentice-Hall, 1995, pp. 343-44.
Up to this point the discussion has been primarily presentation of the secure e-mail system 10. The concept of a key server can, however, be used much more generally to build and deploy a variety of solutions that address the problem of secure communication. For example, this approach can also particularly facilitate enterprise instant messaging (EIM), video-conferencing, and secure real-time document editing. These are just additional examples of communication schemes employing message headers to deliver or route message content, and the a key server can be used with effectively any such communication scheme.
The key server 216 creates the conversation keys 220 or it can receive them from source participants 212 a. The key server 216 then stores and releases the conversation keys 220 to the parties that are the collaboration participants 212 (presumably after authentication and authorization, but various schemes can be used for that and it is not a topic that is germane here). The key server 216 can also create or store conversation keys 220 in bulk, releasing an arbitrary number upon request. A client that is a server-class device (e.g., an email gateway) can thus get a bulk set of conversation keys 220 and protect each message 218 with a unique one, without needing to ask the key server 216 for a unique conversation key 220 every time.
A collaboration technology that is based on IPSec must use individual Security Associations (SA). First, an SA is ephemeral and SA keys can practically only protect collaboration data while in transit. Second, an SA is specific to a source/destination pair. Therefore, collaboration applications (e.g., Instant Messaging) that work based on a hub-and-spoke model require protection of data as information travels through multiple SAs. In contrast, the security server system 210 can protect collaboration data (message content 224) while in transit and in storage using the same base technology.
A collaboration technology that uses SSL/TLS requires multiple SSL/TLS sessions. First, a session is ephemeral and session keys can practically only protect the collaboration data while in transit. Second, a session is specific to a client/server pair. Therefore, collaboration applications (e.g., Instant Messaging) that work based on a hub-and-spoke model will require protection of data as information travels through multiple sessions. In contrast, the security server system 210 can protect collaboration data while in transit and in storage (i.e., a transcript) using the same base technology.
FIG. 11 is a block diagram depicting how a communication system 310 can consists of four basic components: a communicating party 312 (an originator 314 or a recipient 316), an authentication authority 318, and a key server 320.
The originator 314 next constructs the communication 324, by encrypting the data using the key 330 and adding the resource ID 328 in the clear. The originator 314 then transmits the communication 324 to all of the recipients 316 using conventional means. Note, the originator 314 need not, and in most embodiments will not, ever send the communication 324 to either the key server 320 or the authentication authority 318.
Finally, the recipient 316 decrypts the communication 324 with the key 330. Coincidental with this, the integrity of the content of the communication 324 is validated by whether decryption is successful and, optionally, by comparing a cryptographic checksum that has been included in the communication 324. Such a checksum can be in the clear part of the communication 324, along with the resource ID 328, but more typically will be included in the encrypted part along with the content of the communication 324. Such a checksum can also encompass different parts of the overall communication 324. For instance, it may be derived from only the content part of the communication 324, or it may be derived from other parts of the communication 324. An example when the communication 324 is in email form might be to include the subject and the encryption time in the checksum. In this manner, the recipient 316 can tell if a subject portion sent in the clear has been altered or if the communication 324 has been unduly delayed.
TABLE 1 shows a schema for the content of the database 332 maintained by the key server 320. The ResourceID field is straightforward, it is the resource ID 328 we have already discussed. The ResourceType field provides the scope of the application type for which the key 330 is created. For example, Email and Instant Messaging could use different resource types. This will relieve different applications from needing to coordinate resource ID 328 uniqueness. The combination of the ResourceID and ResourceType fields is always unique. The ResourceKey is simply the key 330, also already discussed. Only one ResourceKey is needed if the key 330 is a symmetric key, i.e., the same key 330 is used by both the originator 314 and the recipient 316. Embodiments of the communication system 310 may also use asymmetric keys. In this case, if the key server 320 provides the encryption key 330 to the originator 314, it will have a ResourceEncryptKey field for that as well as a ResourceDecryptKey field to store the decryption key 330 that should be provided to the recipient 316. If the originator 314 handles key generation, it may send both the encryption and decryption keys 330 to the key server 320, or just the decryption key 330.
Continuing with the schema, the KeySize field is optional. One size key may be used exclusively, but there is no limitation that this be the case. Some users may want the very strong encryption that a bigger key can provide, while others may want the reduced processing burden that a smaller key can provide. Another consideration is that keys have tended to become bigger as cracking resources have become more powerful. This trend will likely continue, and embodiments may thus need to handle different key sizes just to deal with legacy key size and upgrade key size issues.
The KeyCreator field may also be optional. Embodiments are possible where only the key server 320 creates the keys 330, or where the originators 314 always create the keys 330. Having this field permits either of these, or a mixed arrangement where the keys 330 are sometimes created by the key server 320 and other times created by the originators 314. Having such capability present in an embodiment, of course, does not limit policies being used to specify which arrangement is used or to specify arrangements that must be used for particular originators 314.
The communication system 310 enables the construction of three sets of business events. Controlling events 340 (FIG. 12) consist of a set of actions taken by an originator 314 to control when and how many times a recipient 316 can view a communication 324. Positive events 342 (FIG. 13) consist of a set of actions taken by a recipient 316. And negative events 344 (FIG. 14) consist of a set of actions that were expected from a recipient 316 but have not yet been initiated.
FIG. 15 is a block diagram depicting how an embodiment of the present inventive communication system 410 may use four basic components: a transacting party 412 (a source 414 or a target 416), an authentication authority 418, and a key server 420.
The transacting party 412 communicates with the authentication authority 418 to authenticate itself. The transacting party 412 uses a protocol that is specific to the authentication authority 418 (e.g., user ID and password over Transport Layer Security, two factor authentication, challenge/response protocol using PKI certificates, etc.). As a result of successful authentication, the authentication authority 418 issues the transacting party 412 an authentication assertion 422. The authentication authority 418 signs this assertion 422 (typically, using a PKI private key). The assertion 422 includes the identity of the transacting party 412; the identity of the authentication authority 418; the validity period of the authentication assertion 422; and optional confirmation data, used by the key server 420 to prove that the transacting party 412 is the rightful owner of the assertion 422. One example of such confirmation data may be a temporary public key whose private key is known to the transacting party 412. The transacting party 412 may create this private key and, via the authentication protocol, ask the authentication authority 418 to assert that the corresponding public key belongs to the transacting party 412. Alternatively, the authentication authority 418 can create the key pair, securely deliver the private key to the transacting party 412, and assert that the corresponding public key belongs to the transacting party 412. The former method is generally preferable because the authentication authority 418 will then not have knowledge of the private key.
As mentioned before, the source 414 authenticates with the authentication authority 418 and receives an assertion 422. Subsequently, typically just before when the source 414 wishes to communicate a transaction 424 to one or more of the targets 416, the source 414 communicates with the key server 420. The key server 420 assigns a transaction ID 428 to the transaction 424 and creates an encryption key 430 for the transaction 424. (The encryption key 430 may or may not be the same key 430 that is usable for decryption.) Optionally, the source 414 can send the key 430 to the key server 420 and ask it to associate the key 430 with the transaction 424. The key server 420 records the key 430, the transaction ID 428 and the assertion 422 of the source 414 all in a database 432 which the key server 420 maintains. Finally, the source 414 protects the confidentiality and integrity of the data in the transaction 424 using the key 430 and transmits the transaction 424 to the target 416. This transmission may be via entirely conventional means, not traveling via either of the authentication authority 418 or the key server 420.
The communication system 410 achieves nonrepudiation of origin by associating the assertion 422 of the source 414 with the transaction ID 428 and the key 430 that protects the transaction 424. The key 430 thus “cryptographically” binds the transaction 424 and the source 414. For example, in an embodiment where the transaction 424 is embodied in an email, the communication system 410 can be used to prove that the source 414 originated the email and was authenticated via a specific authentication method at a specific authentication authority 418.
If the source 414 later attempts to repudiate the transaction 424, a party seeking to contest this can proceed in various ways. If the party is the target 416, this can be as simple as providing the transaction ID 428 and the identity of the putative source 414 to the key server 420 and asking it for confirmation that the putative source 414 provided the assertion 422 associated with the transaction ID 428. Alternately, the target 416 can provide just the transaction ID 428 and ask the key server 420 who the source 414 was that received the transaction ID 428.
Of course, the source 420 or others may still not be willing to simply concede that the target 416 has adequately confirmed the origin of the transaction 424. However, the party resolving matters can also be one other than a transacting party 412 (source 414 or target 416), say, an arbitrator, a court, or a bank. The party here can then provide the transaction ID 428 to the key server 420 and be advised who the source 414 is that provided the assertion 422 that resulted in issuance of that transaction ID 428 and what the key 430 is that should decrypt the transaction 424 and verify its integrity. If that key 430 does decrypt the transaction 424 and verifies its integrity, the question of origin is settled. Alternately, possibly even more typically, the party can provide both the transaction 424 and the transaction ID 428 to the key server 420, the key server 420 can determine if the key 430 it has decrypts the transaction 424 and verifies its integrity, and the key server 420 can then advise accordingly. Note, here also the identity of the putative source 414 can be provided to the key server 420 and it can confirm (i.e., provide a yes or no answer) whether the putative source 414 provided the assertion 422 associated with the transaction ID 428.
As also mentioned before, the transaction target 416 also authenticates with an authentication authority 418 (not necessarily the same one used by the source 414, however) and also receives an assertion 422. The target 416 then must retrieve a decryption key 330 from the key server 420 in order to decipher the data in the transaction 424 and validate its integrity. Prior to releasing the key 330 for this, the key server 420 records the assertion 422 of the target 416 and also associates it with the transaction ID 428.
The communication system 410 thus achieves nonrepudiation of receipt by associating the assertion 422 of the target 416 with the transaction ID 428 and the key 330 that protected the transaction 424. For example, in an embodiment where the transaction 424 is embodied in an email, the communication system 410 can be used to prove that the target 416 received and opened the email and was authenticated via a specific authentication method at a specific authentication authority 418.
If the target 416 later attempts to repudiate receipt of the transaction 424, matters can be simply determined by providing the transaction ID 428 and the identity of the target 416 to the key server 420 and asking it for confirmation that the target 416 requested the key 430, that the target 416 proffered a valid assertion 422 as part of its request, and that the target 416 was only then provided the key 430. This leaves only the question of whether the target 416 in fact used the key 430 to open the transaction 424. As described above, however, the requests by transacting parties 412 will typically be handled by software (e.g., software modules 26, FIG. 3). Thus, for at least the targets 416, receiving the key 430 and using it can easily be made automatic and essentially contemporaneous. This provides a very difficult to overcome presumption that targets 416 who have received keys 430 have also used them to open transactions 424.
The key server 420 can permanently record the assertions 422 of the source 414 and all of the targets 416 in its database 432. Since the communication system 410 associates these assertions 422 with the transaction ID 428, the database 432 can be used to reconstruct the events of originating the transaction 424 and each receipt of the transaction 424. This serves as the basis of a comprehensive audit system.
FIG. 16 is a flow chart depicting a suitable process 450 by which the communication system 410 can establish data in the database 432 for later nonrepudiation and audit purposes. The process 450 starts in a step 452, wherein the existence of the authentication authority 418 and key server 420 is presumed and the source 414 has already obtained an assertion 422 from the authentication authority 418.
In a step 454, a request is sent to the key server 420. It is expected that in most embodiments this request will be made directly by the source 414, but there is no technical reason that it cannot also be made by an intermediary acting on behalf of the source 414 (of course, there can be excellent policy reasons to not allow this). The request will include the assertion 422 of the source 414 and information about the contemplated transaction 424 (see e.g., TABLE 1). As discussed previously, such information will at least identify the targets 416, and may also set times and quantities of permitted releases of the decryption key 430 for the transaction 424. The request will also include the decryption key 430, if the source 414 is providing that.
In a step 456, the key server 420 determines if the assertion 422 of the source 414 is valid (and if at least minimal other information is provided, e.g., at least one target 416 is identified). If not, in a step 458 the key server 420 can take what is deemed appropriate action for the particular embodiment. Since the failed determination may be due to innocent error, it is expected that most embodiments will allow at least one corrected request. The key server 420 can, of course, log all attempted requests in the database 432.
If step 456 determines that the process 450 should continue, in a step 460 the key server 420 assigns a transaction ID 428 (“t-id” in the figures) and stores it along with the assertion 422 of the source 414 and a decryption key 430 in the database 432. Recall, as a matter of design or configuration, the encryption key 430 and the decryption key 430 may or may not be the same. If they are different, the key server 420 can store both if desired.
In a step 462, the key server 420 replies to the request by providing the transaction ID 428, and the encryption key 430 if it is providing that.
No steps are shown in FIG. 16 for the encrypting, sending, and receiving of the transaction 424. To keep things simple here these are treated generally as their labels imply, and more details are provided, below.
In a step 464, it is presumed that the target 416 has received the transaction 424 and already obtained an assertion 422 from the authentication authority 418. What this step then includes is receipt of another request by the key server 420. It is expected that in most embodiments this request will also be made directly by the target 416, but there is no technical reason that a request cannot be made by an intermediary. This request includes the transaction ID 428 that came with the transaction 424 and the assertion 422 of the target 416.
In a step 466, the key server 420 determines if the assertion 422 of the target 416 is valid (and if the transaction ID 428 is for a transaction 424 that the target 416 is presently authorized to view). If not, in a step 468 the key server 420 can take what is deemed appropriate action. Since a failed determination may here also be due to innocent error, it is expected that most embodiments will allow at least one corrected request. The key server 420 can, however, here also, log all attempt requests in the database 432.
If step 466 determines that the process 450 should continue, in a step 470 the key server 420 stores the assertion 422 of the target 416 in the database 432, associated with the transaction ID 428 and the identity of the target 416.
In a step 472, the key server 420 retrieves the decryption key 430, which was previously stored in association with the transaction ID 428, and replies to the present request by providing the decryption key 430.
Finally, in a step 474, the process 450 ends. Data is now established in the database 432 for nonrepudiation and audit purposes. Presumably, but with very high likelihood if the communication system 410 uses software that automates request-reply handling for the target 416 (e.g., the software module 26, FIG. 3), the transaction 424 is decrypted and viewed.
As noted in passing above, the act of using the encryption key 430 “cryptographically” binds the transaction 424 and the source 414. There are, however, different approaches and variations of those approaches that are suitable for this, and some representative examples are now presented.
If a public/private key system is employed, the source 414 can include the public key (the decryption key 430) in the assertion 422 it provides to the key server 420. The source 414 then effectively “signs” the transaction 424 by encrypting it using the corresponding private key (the encryption key 430) and cannot repudiate the transaction 424. This is conceptually similar to how PKI systems achieve nonrepudiation, but this approach employs the key server 420 and permits additional benefits to be obtained.
If a single key is used for both encryption and decryption, the source 414 and the key server 420 can cooperate to create a “seal” that will prove that the transaction 424 originated from the source 414. There can be many variations on this approach, and the following describes the inventors' presently preferred one. Many features in this are optional.
Here the source 414 requests the transaction ID 428 and encryption key 430 from the key server 420, as described previously, and the key server 420 provides these as well as a key-creation timestamp and an identity of the source 414. [Typically the identity will be an email address, but this is not necessarily the case. For instance, the key server 420 may use its customer number for identifying the source 414. Often the source 414, will full well know “its” identity, but “parroting” it back from the key server 420 and using that exact bit-for-bit copy in the next stage avoids possible errors.] The source 414 then combines the data for the transaction 424, the transaction ID 428, the timestamp, and the identity together and generates a hash. The source 414 encrypts the hash with a “salt,” say, a randomly generated number, and this encrypted hash becomes the seal.
Next, the source 414 encrypts the data for the transaction 424, and this becomes what is actually sent to the targets 416. Note, here the source 414 creates the seal and the salt. It sends the key server 420 the seal, but not the transaction or the salt. The source 414 sends each target 416 the transaction 424, which is encrypted and includes the salt but (preferably) not the seal.
Upon receiving the transaction 424, the target 416 sends the transaction ID 428 and its assertion 422 to the key server 420. If all is in order, the key server 420 replies with the decryption key 430, the key-creation timestamp, the identity of the source 414, and the seal. With the decryption key 430, the target 416 decrypts the transaction 424, accesses the salt, and now recreates the process the source 414 used to create the seal. It combines the data for the transaction 424, the transaction ID 428, the timestamp, and the identity together and generates a hash. Then it then encrypts this hash with the salt. If the result matches the seal created by the source 414 and now provided from the key server 420, the source 414 cannot repudiate the transaction 424. This also prevents the target 416 from concocting a transaction 424, encrypting it with the decryption key 430, and later claiming that the transaction 424 originated from the source 414.
FIG. 17 is a flow chart depicting a suitable process 480 by which data established in the database 432 can be used to counter attempted repudiation by the source 414.
In a step 482, the process 480 starts. Presumably, data already has been established in the database 432 for a transaction 424.
In a step 484, a request to verify the source 414 is made to the key server 420, or to another system having at least read access to the database 432. Such a request can potentially come from a target 416 or any other party that can identify the subject transaction 424 in some manner (of course, a policy can impose limitations on this if desired). Most typically, identification will be by the transaction ID 428, but other data can potentially also be used to search the database 432 and determine the transaction ID 428 (e.g., a key 430, an assertion 422, actual transacting party 412 identity information, transaction 424 send or received times, etc.).
In a step 486, the identify of the source 414 is determined by inspecting the assertion 422 it initially provided, which has been stored all along in association with the transaction ID 428.
In a step 488, the present request is replied to by verifying the source 414. The reply and the nature of verification can, however, take many forms. For instance, the reply can simply identify the source 414. Alternately, if the request included a suspected source 414, the reply can merely include a “Yes” or “No” answer and not provide an actual identify. The reply can even include the decryption key 430 for the transaction 424, presumably only in appropriate circumstances (e.g., when a court has so ordered). Or the request can include the encrypted transaction 424 and the reply can include the decrypted transaction 424, again presumably only in appropriate circumstances.
Finally, in a step 490, the process 480 ends. The source 414 is now unable to plausibly repudiate the transaction 424.
FIG. 18 is a flow chart depicting a suitable process 500 by which data established in the database 432 can be used to counter attempted repudiation by the target 416.
In a step 502, the process 500 starts. Presumably, data has already been established in the database 432 for a transaction 424.
In a step 504, a request to verify that the target 416 received the transaction 424 is made to the key server 420 or another system having at least read access to the database 432. Such a request may come from the source 414 or any other party (subject to policy considerations) that can identify the subject transaction 424 and a suspected target 416 in some way. Most typically, identification will be by the transaction ID 428, but here as well, other data can potentially also be used to search the database 432.
In a step 506, whether the target 416 received the transaction 424, received it a specific number of times, or received it at one or more specific times is determined by inspecting the target assertions 422 and other data (see e.g., TABLE 1) that has been stored in association with the transaction ID 428. If this does not include an assertion 422 of the target 416, or includes one but other criteria are not met, in a step 508 an appropriate reply is made to the request.
Alternately, if the database 432 reflects that an assertion 422 of the target 416 is present in association with the transaction ID 428, and also that any optional criteria are met, in a step 510 an appropriate reply for this case is made to the request.
Note, the replies and the nature of verification can also take many forms here. For instance, the reply can simply verify that the target 416 asked for and was provided the decryption key 430 for the subject transaction 424. Alternately, if the request asks and the embodiment permits, the reply can inform how often and when the target 416 was provided the decryption key 430. The reply can also include the decryption key 430, presumably only in appropriate circumstances. Or the request can include the encrypted transaction 424 and the reply can include the decrypted transaction 424, again presumably only in appropriate circumstances.
Finally, in a step 512, the process 500 ends. The target 416 is now unable to plausibly repudiate the transaction 424.
As for auditing the passage of transactions 424 between sources 414 and targets 416, the database 432 will contain extensive data suitable for this. As long as such data is stored with timestamps and remains in the database 432, responding to audit requests should be a straightforward task of lookup and report generation.
The present invention, which has been illustrated herein with the communication system 410 as an example, is well suited for application in current network environments, such as the Internet, to implementing nonrepudiation and audit using authentication assertions and key servers. As has been described above, prior art approaches have still not addressed all concerns with the use digital communications. In particular, it has not addressed the two particularly vexing problems of transaction nonrepudiation and auditing.
The present invention is largely transparent to transacting parties, transaction sources and targets. The authenticated identities of transacting parties are used to implement nonrepudiation by either party. Additionally, by persistently storing information from or the complete authentication assertion of the transacting party at a key server, both nonrepudiation and audit may be provided using the same system. In contrast, existing technologies (e.g., Public Key Infrastructure, PKI) burden their users with maintaining a private key and actively using it for producing a signature. Additionally, a party needing to verify a transaction must have a copy of, or otherwise retrieve the digital certificate of the transaction signer. Moreover, such existing technologies do not provide a single service for both nonrepudiation and audit.
The present invention may still interoperate with PKI, but it does not require it. A transaction source, target, or both can use any method, including PKI, to provide nonrepudiation of origin and receipt. Furthermore, the method the transaction source uses may be the same or different than the method the transaction target uses. In contrast, PKI-based technologies require the use of an infrastructure that is trusted by all parties (transaction source and target). Also, non-PKI technologies (e.g., storing a transaction log in a database) use a completely different mechanism and do not interoperate with PKI.
The present invention is able to provide varying degree of strengths. It associates the degree of strength with the authentication of the transacting party. By increasing the strength of authentication (e.g., from a user ID/password to a two factor authentication), the transacting party dynamically and automatically increases the strength of nonrepudiation. In contrast, most prior art technologies only offer a single level of strength for nonrepudiation. For example, in PKI the strength of nonrepudiation is equivalent to the assurance level of the underlying certificate. Here a party can only change the strength by using a different certificate, having a different level of assurance.
The present invention is also able to enforce specific trust rules. It enables flexible trust rules that follow business relationships. For example, an organization can enforce the rule of authenticating each transacting party, thereby enforcing a rule of only trusting its own authentication assertions. Or, an organization can enforce a rule of owning and maintaining its own key server, thereby enforcing a rule of only trusting its own audit server. In contrast, most prior art technologies provide rigid trust rules for nonrepudiation and audit. Using PKI again as an example, in a system based on it the party that verifies the transaction must trust the certificate of the signer. In prior art non-PKI based systems, the verifier must trust the system that keeps the transaction logs.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4897875Sep 3, 1987Jan 30, 1990The Manitoba Telephone SystemKey management system for open communication environmentsUS5200999Sep 27, 1991Apr 6, 1993International Business Machines CorporationPublic key cryptosystem key management based on control vectorsUS5495533 *Apr 29, 1994Feb 27, 1996International Business Machines CorporationPersonal key archiveUS5748735Jun 7, 1996May 5, 1998Bell Atlantic Network Services, Inc.Securing E-mail communications and encrypted file storage using yaksha split private key asymmetric cryptographyUS5841865Apr 11, 1997Nov 24, 1998Certco LlcEnhanced cryptographic system and method with key escrow featureUS5848161May 16, 1996Dec 8, 1998Luneau; GregMethod for providing secured commerical transactions via a networked communications systemUS5864667Aug 22, 1997Jan 26, 1999Diversinet Corp.Method for safe communicationsUS6009173Jan 31, 1997Dec 28, 1999Motorola, Inc.Encryption and decryption method and apparatusUS6023700Jun 17, 1997Feb 8, 2000Cranberry Properties, LlcElectronic mail distribution system for integrated electronic communicationUS6055314Mar 22, 1996Apr 25, 2000Microsoft CorporationSystem and method for secure purchase and delivery of video content programsUS6230156Jul 7, 1998May 8, 2001Microsoft CorporationElectronic mail interface for a network serverUS6289105Jul 26, 1996Sep 11, 2001Kabushiki Kaisha ToshibaMethod and apparatus for encrypting and transferring electronic mailsUS6442686 *Sep 21, 1998Aug 27, 2002Networks Associates Technology, Inc.System and methodology for messaging server-based management and enforcement of crypto policiesUS7146009 *Feb 5, 2002Dec 5, 2006Surety, LlcSecure electronic messaging system requiring key retrieval for deriving decryption keysUS20030147536Feb 5, 2002Aug 7, 2003Andivahis Dimitrios EmmanouilSecure electronic messaging system requiring key retrieval for deriving decryption keysUS20040128541 *Dec 31, 2002Jul 1, 2004Iinternational Business Machines CorporationLocal architecture for federated heterogeneous systemUS20040139319 *Jul 24, 2003Jul 15, 2004Netegrity, Inc.Session ticket authentication scheme* Cited by examinerNon-Patent CitationsReference1Australian Patent Office, Written Opinion, App. No. SG 200503239-6, Date of mailing Dec. 22, 2005 [a report prepared for and communicated to the Singapore Registry of Patents and ultimately received by Applicant on Mar. 8, 2006].Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8135786Jan 30, 2009Mar 13, 2012International Business Machines CorporationMessage-based technique for sharing distribution list contents within electronic messaging systemsUS8806207Dec 22, 2008Aug 12, 2014Cocoon Data Holdings LimitedSystem and method for securing dataUS20120151214 *Dec 13, 2010Jun 14, 2012Markus PutzeMethod for the use of a mobile appliance using a motor vehicle* Cited by examinerClassifications U.S. Classification713/168, 713/176, 713/155, 380/278, 705/75International ClassificationH04L29/06, H04L12/58, H04L9/00Cooperative ClassificationG06Q20/401, H04L63/062, H04L63/08, H04L12/5875, H04L51/30, H04L63/0428European ClassificationH04L63/06B, G06Q20/401, H04L51/30, H04L12/58RLegal EventsDateCodeEventDescriptionDec 1, 2011SULPSurcharge for late paymentDec 1, 2011FPAYFee paymentYear of fee payment: 4Aug 15, 2008ASAssignmentOwner name: PROOFPOINT, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SECURE DATA IN MOTION, INC., DBA SIGABA;REEL/FRAME:021387/0782Effective date: 20080804Apr 15, 2004ASAssignmentOwner name: SECURE DATA IN MOTION, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:OLKIN, TERRY M.;MOREH, JAHANSHAH;REEL/FRAME:014524/0788Effective date: 20031125RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services