WO2002007376A1 - Intermediated delivery scheme for asymmetric fair exchange of electronic items - Google Patents
Intermediated delivery scheme for asymmetric fair exchange of electronic items Download PDFInfo
- Publication number
- WO2002007376A1 WO2002007376A1 PCT/US2001/022074 US0122074W WO0207376A1 WO 2002007376 A1 WO2002007376 A1 WO 2002007376A1 US 0122074 W US0122074 W US 0122074W WO 0207376 A1 WO0207376 A1 WO 0207376A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- sender
- recipient
- message
- encrypted message
- receipt
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/60—Digital content management, e.g. content distribution
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/88—Medical equipments
Definitions
- the invention is generally directed to a methodology and system which facilitates the exchange of electronic information in a confidential and fair manner.
- Fair exchange is a classical problem in cryptographic research. By “fair” we mean that neither of the parties should have a significant chance of securing the desired object of the exchange while simultaneously frustrating the other party. For instance, a protocol which would allow the sender to obtain a receipt without disclosing the electronic information to the receiver would not be “fair”.
- a protocol which would allow the sender to obtain a receipt without disclosing the electronic information to the receiver would not be “fair”.
- At a high level we can broadly classify the existing protocols for fair exchange of information as cryptological, optimistic or online. Though strictly speaking, online protocols are not fair exchange protocols, they are of practical relevance, especially in the case of the asymmetric type of exchange. Furthermore one can speak of the fairness of an online protocol in similar terms as with optimistic protocols, by formal derivations from a set of trust assumptions. Cryptological fair exchange protocols use successive rounds of communication in which the two items are progressively transmitted.
- the second item is a receipt which includes a description of the first item.
- the receipt cannot be fully generated until the first item is entirely known.
- the cryptological protocols function in a way that at each round, the probability that each party will be able to determine the exact contents of the message from the information received up to that round progressively increases towards 1 (100%).
- Online protocols are those that employ a trusted third party which act as a delivery channel. Both parties send their items to the trusted party. This trusted party can then check for their integrity, ensuring the validity and fairness of the exchange, and forward the items to the intended receivers.
- Such protocols have been implemented and commercialized by companies providing various certified or secure services on the Internet. See, for instance, http://www.certifiedemail.com. This company accepts e-mails for delivery and provides the sender with a receipt. The contents of the exchange are either revealed to the company or else may be encrypted, but in that case the receipt does not validate the message, only an encryption using an unknown key which is not validated by the receipt.
- a fair exchange is an optimistic scheme if the parties cooperate directly in the exchange without the direct intervention of a trusted party. In case both parties act honestly the protocol terminates with both parties satisfied with the outcome. If however one of the parties cheat, the other party has enough evidence to secure him/herself a satisfactory outcome by requesting the help of a trusted third party. Thus it is a category of adjudicated protocols (protocols in which a trusted entity adjudicates disputes but is not needed when the parties are honest) and is called optimistic because one of the parties must be the first to disclose the desired information to the other. J. Riordan and B. Schneier present two protocols for certified e-mail
- the sender (conventionally named ) Alice sends the receiver Bob an encrypted message.
- Bob publishes a dated request for the key in the trusted publishing location, which in practice could be implemented as a secure database server. If Alice submits the key for publishing within the time period appointed by Bob, that will constitute Alice's evidence of delivery, i.e., her receipt.
- Alice sends the key directly to Bob, who then responds with a receipt for the key. If Bob does not reply within reasonable time, then the protocol reverts to the online version.
- Alice Upon verifying the receipt, Alice sends to Bob the message, now encrypted only with Bob's public key, Bob decrypts the message and reads it. In the case that Alice does not respond with the message in the third message, Bob can take the first message and his signature to the TTP. The TTP will then decrypt the message and give it to Bob, while forwarding the message to Mce. Since the message was first encrypted with Bob's public key, the confidentiality of the transaction is guaranteed even in the special case. While simple and elegant, the above protocol has a disadvantage. It places too large a burden on Bob. After Bob has issued and released the receipt, he does not know what kind of time interval to wait for a reply from Alice before complaining to the trusted third party.
- the communication with Alice is asynchronous, for example, via e-mail, then a waiting interval of several days may be reasonable.
- Bob must decide what he will consider an acceptable wait time, and then resort to help. During that time, he has exonerated Alice of any responsibility by giving her his receipt, though he cannot utilize the information sent by Alice. This is a serious inconvenience of the protocol which might discourage user acceptance of the protocol.
- optimistic exchanges achieve timeliness of exchange only at the expense of monotonicity or of homogeneity of outcome. For instance, in the case of certified e-mail the receiver of the e-mail can be guaranteed timeliness for his/her part in the transaction only if he/she is allowed to request that his/her signature on a receipt be revoked by the trusted party.
- one of the parties first discloses the item in his/her possession. If it does not immediately receive the item it desires in return, he/she will have to decide how long to wait before it concludes that the other party is cheating or broken and resort to the trusted third party.
- U.S. Patent Number 6,137,884 (10/24/2000) of Silvio Micali describes two schemes that utilize a third party (therein called a post office) to effectuate the simultaneous exchange of information and receipt.
- a sending-receipt method Alice sends to the post office an encrypted message that only Bob can read.
- the post office signs and forwards the message to Bob while simultaneously sending to Alice a properly signed receipt indicating that the message has been forwarded to Bob.
- the use of electronic signatures allows Alice to identify the receipt she gets from the post office with the message she sent to Bob.
- a drawback to this method is that Alice can obtain a receipt without Bob ever having received the message if, for example, a disruption in the communication between the post office and Bob occurs.
- Micali teaches a second scheme in which the post office sends the signed receipt back to Alice and forwards onto Bob an encrypted version of the message.
- Bob cannot read the message until he acknowledges receipt and thereby obtains from the post office the information necessary to decrypt the message.
- the post office may or may not return this second receipt to Alice.
- Alice has already received a signed receipt acknowledging that her message was sent onto
- a drawback to this approach is that Alice can obtain a valid receipt without Bob having received a useable (i.e., decodable) message.
- Bob cannot turn to an independent party to obtain the decoded message, and thus is left vulnerable if the post office misbehaves.
- TTP trusted third party
- Our protocol is an online protocol which adopts a different structure from existing ones. It distributes responsibilities so that one server must be highly secure, but not necessarily highly available. The communication demands on it are lower than in traditional online schemes.
- Several servers are preferably employed for the delivery of messages. Preferably, these can be easily duplicated so they do not need to be highly secure. This will increase the availability of the system at a lower cost.
- the secure server we refer to as the trusted third party (TTP), while the other servers are called agents.
- the protocol we describe solves the prior problems of certified e- mail schemes for electronic information exchange by introducing an asymmetry in the exchange. From the point of view of the party initiating the exchange it is an online protocol with the agent a trusted delivery channel. From the point of view of the second party it is an optimistic protocol performed with an online agent contracted by the other party.
- online protocol we mean any protocol in which a first party communicates electronically with other parties through the intermediation of a party trusted to all parties. The first party of an online protocol has no legal resort or protection against misbehavior of the intermediating party.
- An example of an online protocol is the one described in patent #6, 137, 884 of S . Micali, which is herein incorporated by reference.
- the sender's view of the protocol is logically that of an online protocol, though the sender's trust on the postal agent may be reduced by using a multiplicity of postal agents and a simple secret sharing scheme of "xor" shares, as described in the invention.
- optimistic protocol we mean any protocol in which two parties, not mutually trusting each other, engage in an electronic exchange and at least one of the parties has a legal resort to a trusted third party for arbitration in the case the other party misbehaves.
- the outcome of each application of an optimistic protocol is guaranteed to be fair to both parties, whether or not that application involved arbitration by the trusted party.
- Example of an optimistic protocol is such as in papers of Asokan et al., "Optimistic protocols for multi-party fair exchange", IBM Research Report RZ 2892 (Dec. 9, 1996) and Asokan et al. , “Optimistic fair exchange of digital signatures", IBM research report.
- the recipient's view of the protocol is that of an optimistic exchange with a live party. This is an important difference between optimistic protocols such as described in patent #5,666,420 of S. Micali, which is herein incorporated by reference. Micali assumes asynchronous communication and cannot give strong timeliness guarantees and ours, which gives de facto timeliness guarantees to the recipient of the message.
- This asymmetric model of communication results from an asymmetrical, but realistic, trust model.
- Alice as initiator of the exchange, chooses the agent to intermediate the exchange, not unlike contracting a real agent in the physical world. Thus it is not unreasonable to expect that she should trust the agent.
- Bob does not need to trust the agent. However, Bob can expect the agent to be available. Any delays on the agent's part (which is a dedicated server) can be reasonably construed by
- the full cycle of exchange includes asynchronous exchange - as in the case of certified e-mail - a delay of days on the part of the initiator of the exchange does not necessarily constitute an indication of dishonesty on her part, while a delay of a few minutes on the part of the agent server, which is always online, may constitute enough reason for an appeal to the trusted party. This gives de facto timeliness guarantees to both parties, which in turn should result in a smaller number of disputes, as long as the agents remain available and functional the number of complaints should be minimal.
- Figure 1 is a schematic diagram showing the sequence of messages in the optimistic exchange
- Figure 2 is a schematic diagram illustrating a first protocol according to the present invention
- FIG 3 is a schematic diagram illustrating a second protocol according to the present invention
- Figure 4 is a flow diagram showing the sequencing of the first protocol according to the present invention.
- FIG. 5 is a flow diagram showing the sequencing of the second protocol according to the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS OF THE INVENTION
- the invention is directed to a method and system for the fair exchange of electronic information.
- the invention has particular application to a certified e-mail service which uses cryptographic tools to provide proof that a particular message was delivered between two parties at a certain time.
- invention can be adapted for use in a variety of methods and systems where it is necessary to assure that two parties in an electronic transaction are provided with a fair and confidential means of exchange.
- the invention is designed to achieve the following.
- TTP invisibility A TTP is visible if the end result of an exchange makes it obvious that the TTP participated during the protocol.
- Non-repudiation of receipt The recipient of the message should not be able to deny having received the message if indeed the message was delivered.
- Non-repudiation of origin The sender should not be able to deny having sent the message.
- Realistic trust models The trust model should be based on realistic assumptions the users are comfortable with. A system that places less trust in outside parties is more likely to be accepted.
- Timeliness Roughly speaking, timeliness guarantees that both parties will achieve obtaining their desired items in the exchange within a finite time or that at least one party has the ability to decide to abort the normal operation of the protocol and adopt a scheme for protocol resolution that can be executed in a finite, preferably short, period of time.
- Confidentiality In case the exchange is deemed confidential, the protocol should not need to disclose the message contents to any other party except for sender and recipient. In particular, other trusted or semi-trusted parties acting as intermediaries should not be able to read the contents of the confidential e-mail. Most of the protocols of fair exchange of electronic items in the prior art do not provide any level of confidentiality.
- TTP which is needed as an arbitrator to ensure fairness
- This invention allows the arbitration to be performed without violating the confidentiality of the exchange.
- the e-mail messages are certified without revealing their contents to third parties. This should promote the commercial development of certified e-mail services since the third party will be trusted to perform transmission, storage and dispute resolution, but will not need to be trusted to keep the information involved private.
- the invention is a hybrid protocol which combines the strengths and overcomes the disadvantages of both optimistic and online approaches.
- the invention is applicable for scale up.
- the invention introduces the- notion of postal agents (PAs) which are distributed servers act on behalf of the TTP, with each PA requiring minimal trust in itself.
- PAs postal agents
- the PAs are online but they do not resolve disputes, which are still handled by the TTP.
- the protocol is monotonic, in that each party cannot revoke a message after it has been sent (like physical certified mail) and make use of conventional, publicly available cryptographic technology, such as digital signatures and public-key cryptography. Additionally, the protocol provides TTP's invisibility, and achieves confidentiality from both the TTP and the PAs which are able to verify the validity of a proof-of-receipt and proof-of-origin without knowing the e-mail content.
- the PAs are semi-trusted, in the sense that they can fail or misbehave, and, in addition they can conspire with either of the parties involved in the exchange.
- the TTP is trusted in that it cannot fail or misbehave or conspire with any of the parties.
- Figure 1 shows a simple optimistic protocol that will be used as a sub-protocol in the inventive method and system.
- the protocol terminates successfully without intervention of the trusted party if sender and recipient both act honestly. Only in case of dispute, the TTP is involved.
- the general ideas is as follows: The initiator, Alice 40, first encrypts a message m with the public-key of the recipient, Bob 42. The result ⁇ m) is further encrypted under TTP's public-key, achieving
- This doubly encrypted message is sent to Bob.
- Bob then issues a receipt by sensing Alice his signature on Z. Upon verifying the receipt, Alice then sends Bob the message m. If Alice does not reply, Bob sends Z and his signature on it to the TTP which will then recover P Bob (w) and give it to Bob, while forwarding Bob's receipt to Alice. Since the message was first encrypted with Bob's public-key, the confidentiality of the transaction is guaranteed even in this special case.
- This three step protocol provides simplicity, but it needs to be modified slightly in order to achieve timely termination.
- a time limit should be incorporated into the protocol, otherwise Bob might never reply or might decide to resolve the protocol with the TTP after a certain amount of time that may be unacceptable to Alice.
- Alice Based on the premise that Alice wishes to send a message m to Bob, and wants a signed receipt back, Alice produces an identification token for herself containing her name and e-mail address for responses and other identified information (such as a public-key certificate). This is identified as Id A . The generation of this token involves no secrets and can be done by any entity from publicly available information about Alice. In fact, Alice also generates (or retrieves) a similar token for Bob (Id B ) and for the TTP (Id TTP ).
- the identification tokens will be combined with other parameters, such as a timestamp, a nonce n A (a random number), and a time limit in a protocol header (PH).
- a PH within the context of this invention will be any information attached to a message that provides attributes about or concerning the message, but is not inherently a part of the message. In this protocol, both timestamps and nonces are needed to prevent replay attacks.
- the header also should contain other pertinent information about the protocol, such as the encryption, authentication, and signature algorithms used. Equation 2 sets forth the relationship of these variables.
- Equation 4 sets forth this operation as is depicted in Figure 1.
- Sig A ii ce (') implies that the signed plaintext is also available, either because the signature scheme allows for message recovery or because the plaintext is attached to the signature.
- a receipt within the context of this invention is any return message which inherently authenticates that a given message has reached its intended destination.
- Bob can discard the message or he may decide to read the content, which implies a receipt must be sent to Alice.
- the receipt is a signature of Bob, as set forth in Equation 5.
- C) Equation 5 The signature of Bob is shown in Figure 1, and serves the function of stating that he has indeed received a message from encrypted as specified in PH.
- a signature within the context of this invention is any confidential electronic notation that inherently and uniquely identifies the signer.
- the new protocol header PH' contains a new timestamp and the specifications of the signature algorithm. It also includes the old PH and indicates that the signed message is indeed a receipt. Upon receiving Bob's receipt, Alice releases the message m.
- the only place where the protocol can be interrupted with an unfair outcome is after the transmission of the second message, when Alice has Bob's signature but Bob cannot yet read the message. If Alice does not send Bob the third message, Bob contacts the TTP, forwarding the contents of the messages in the first two steps.
- the TTP decrypts C, checks the protocol headers, and then verifies Bob's receipt. If all is correct, it gives Bob the message P Bob ( 7W ) an d forwards the receipt to Alice (in case Bob didn't send the second message before complaining).
- Bob is signing encrypted information which constitutes a statement to the fact that he received the message. This is made explicit in the receipt by the concatenation of the protocol header PH' with the encrypted message. Since Bob can take steps to ensure recovery of the message contents, he cannot repudiate his signed receipt on the sole basis that the message received was encrypted and unintelligible.
- the verification of the receipt can be done by encrypting twice the message m in order to compute C and then checking Bob's signature via public verification algorithms specified in PH'. Alice must also provide the signed message of the first step of the protocol.
- the message in the third step is concatenated with another protocol header in order to allow the recipient to properly link this protocol step with the two previous ones. If confidentiality is not required, the encryption with Bob's public key could be avoided without compromising the other guarantees of the protocol.
- the inventive system contemplates a highly-secure and fully-trusted server (TTP) and several low- cost semi-trusted servers which are referred to as Agents (Postal Agents).
- TTP highly-secure and fully-trusted server
- Agents Postal Agents
- a PA within the context of this invention is any computer, server or other device which is aware of the necessary sequence of exchange of information between a sender and the receiver and is used to facilitate the fairness of the exchange.
- the inventive protocol distributes responsibilities so that the TTP need not be highly available, thus lowering the communication demand on it.
- the Agents are semi-trusted servers acting as intermediaries between the two parties involved in the exchange. This increases the availability of the entire system at a lower cost.
- the inventive system and method addresses the situation where the Agents conspire with either of the main parties.
- the Agent server is initially chosen by the message originator. Because of this, it is assumed that the PA will not conspire with the recipient of the message.
- FIG 2 illustrates one embodiment of the processes of this invention and is also shown in the flow diagram of Figure 4.
- Alice 50 recruits the PA 52 to intermediate the interchange on her behalf (100).
- She gives PA 52 the message m encrypted with Bob's public key ( * Bob (m)).
- the protocol proceeds with an optimistic exchange between PA 52 and Bob 54.
- PA 52 forwards Bob's receipt to Alice 50.
- the communication is performed through private and authenticated channels.
- Protocol 1 The five message version is shown in Figure 2 and is also shown in the flow diagram of Figure 4 and works as follows: Alice encrypts the message m first with Bob's public-key (101), and concatenates the protocol header PH to the ciphertext (102). She then encrypts the result under TTP's public-key and signs it (103). The signature is sent to PA along with Pbob (w) (104). Optionally, Alice could ask PA to provide her with a proof-of- mailing (a receipt from PA) in reply to her first message. Next, PA and Bob perform an optimistic exchange. Specifically, PA sends Bob the request from Alice along with its own commitment to the transaction in the form of a signature.
- Bob checks the signatures and sends the receipt to PA (106) which replies with the encrypted message J? Bob (m) while forwarding the receipt to Alice (107).
- PA can fail or conspire with Alice.
- Bob can complain with the TTP if he does not receive the last message from PA, in which case, he forwards the TTP the content of the first message received from the PA and his receipt (108).
- the TTP performs the necessary checks, sends P Bob (7w) to Bob and, finally, forward's Bob's receipt to Alice (109).
- the signature of Alice, S constitutes the proof-of-origin.
- each protocol header, such as PH must include the identities of all parties involved.
- PH must be included in the encryption under TTP's public-key. All this is done to prevent subtle replay attacks. For instance, Bob could claim that the encrypted message m had been sent to him by a colluding partner. The TTP would then decrypt the message for Bob and forward Bob's receipt to the cheater, who would conveniently (for Bob) dispose of it.
- a time limit should be included in the protocol headers, which implies that Bob cannot recover the message after that specified time. Since a proof-of-origin is useless without the corresponding message body. Alice's liability immediately ends after the time limit if Bob has not recovered the message, and provided Alice with the receipt.
- Protocol 2 The second version of this invention is shown in Figure 3 and the flow diagram of Figure 5, and is very similar to Protocol 1, but it only requires four messages, which is optimal for online protocols.
- the system and method addresses the situation where the PA can misbehave, fail, or conspire with the message originator. This is achieved as follows: Alice 60 recruits a postal agent PA 62 to act as intermediary (201). She sends the signature S in Protocol 1 directly to Bob along with P Bob (flz) but encrypted under PA's public-key (202) (203) (204). Bob checks the signature and generates a receipt. Bob cannot read the message m since it has been encrypted for the postal agent. Alice's message is then forwarded to PA 62 by Bob 64, along with the receipt (205). If the receipt is valid, it is sent to Alice 60 by PA 62, which also forwards P Bob (w) to Bob 64 (206). In case of a dispute, Bob contacts the TTP as discussed above.
- Protocol 2 Bob should sign both C and T in his message.
- Bob only needs to complain to the TTP if the PA is not forthcoming. This is an unlikely event.
- Alice sends Bob the contents directly, and Bob cannot verify that C and T are linked in any way.
- Bob signed only C he would have to rely on the TTP to solve further disputes, as he does not trust the PA to discard his signature after Alice's dishonesty has been verified. The entire role of the PA would thus be a redundant one.
- Protocol 2 is more efficient, there are advantages to
- Protocol 1 it may be preferred that Bob should have a signature from PA before issuing the receipt. This signature constitutes a commitment of the PA to the transaction and helps Bob collecting evidence that can be useful in case of dispute.
- PA may not be willing to act on Alice's behalf at some point. For instance, PA may charge Alice for its service, but Alice may refuse to pay. If this is the case, then Alice and PA should first negotiate payment terms and then involve Bob in the exchange.
- PA may decide not to terminate the protocol, after Bob generated and forwarded the receipt because of issues with Alice, thus requiring bob to complain with the TTP.
- Bob does not receive all the shares or the message is not the one expected, he can complain with the TTP. Bob would still be protected against any of the agents cheating, while Alice would have the guarantee that Bob could not retrieve anything useful unless all the agents she hired conspire with Bob.
- the shares can be made by xoring the ciphertext with random numbers with the same bitlength. For three agents, Alice would generate two random numbers rj and r 2 . Then, she would send to the first agent the message defined by Equation 6.
- the verifier checks the signatures of Bob that constitutes the proof-of-receipt. This verification is also performed by Bob when he received P Bob ( ⁇ r ⁇ ) from PA in order to check that the message he is reading is the same contained in the receipt R. If the message is different, then Bob contacts the TTP to solve the dispute.
- P B public encryption algorithms
- P TT p() should be deterministic. If they are randomized, then Alice must also provide the random parameters used during the encryption phase.
- MAC Message Authentication Code
- a practical construction for a MAC function is described in Bellare et al., Keying hash functions for message authentication, pages 1-15, called HMAC. Then one would encrypt m according to Equation 9.
- E ⁇ wlHMAC/w) Equation 9
- E k is a symmetric encryption algorithm, such as DES in CBC mode
- k and 1 are random session keys.
- the keys k and 1 can be encrypted using public-key cryptography, as set forth in Equation 10.
- l) Equation 10 where P Bob (') ⁇ s deterministic, such as plain-RSA. Hence, Alice reveals the random session keys to the verifier during the verifying process.
- This encryption method also provides protection against the adaptive chosen ciphertext attack, although this protection is only heuristic and not achieved for at the instantiations of the encryption algorithm.
- each participant takes an input of the ciphertext and his share and returns as output the original plaintext. If at least t participants follow the decryption protocol, then the original message is recorded successfully.
- This invention can be modified to support multiple TTPs, in either protocol, by selecting the encryption function P TTP O as a threshold cryptosystem.
- the approach presented does not require the TTP to keep state (the TTP does not store any value).
- the approach does require a reliable channel between Bob and the TTP, however, the number of disputes will be drastically reduced because the protocols will promote the PA to act honestly more often than a totally untrusted sender. This should increase Bob's willingness to participate by providing his signature; Bob will only be signing receipts for requests originating from certified agents, rather than from unknown senders.
- Bob has a further incentive: the duration of his interchange with PA is likely short, preferably in terms of seconds. This is because PA is an online server always available, whereas Alice, the sender, may not reply promptly, putting Bob at risk.
- An example of a suitable system implementation may be as follows. It is preferably to have an efficient platform, but it is also preferable to have a system that is highly usable and able to support several authentication methods (e.g., PGP-type or X.509 certificates).
- PGP-type or X.509 certificates An important parameter to consider on the platform type is that it should be able to incorporate existing, freely available cryptographic libraries. Good results have been obtained when employing OpenSSL to provide SSL capabilities (http://openssl.org) and a modified Gnu GPG library (http://www.gnupg.org) to sign and encrypt messages.
- the client application preferably provides a user interface through a SSL-enabled web server.
- the PA servers can be implemented on Linux machines running the Apache web server (http://www.apache.org) with the module mod_ssl enabled which allows the SSL secure connections (http:/www.mod_ssl.org). Daemons running these computers performed all the agents' transactions automatically.
- the use interface ideally should be a standalone application, with capabilities of web browsing (including SSL connections). However, one can also borrow the web servers running the postal agents.
- the TTP is the security critical server.
- the requests are logged into the trusted server, and the operator immediately prompts for assistance.
- the trusted server itself can be a machine dedicated to this service that is protected by a firewall and unavailable for remote login.
- a suitable machine may be an 800 MHz pentium III, 256 MB RAM Linux box.
- the client graphical user interface (GUT) is preferably extremely simple. For example, Alice the sender, can be prompted on the display for an TD and password.
- a button can be provided which is labeled "Resources" which, if pressed, will pop up a window from where Alice can specify the files containing information such as certificates and keys, and also enter bookmarks to web directories from where user certificates/public-keys can be downloaded. Alice's own certificates are preferably displayed in a list window.
- the certificates and Ids of the postal agents can be shown in a list window.
- Alice can specify the name of the recipient in a field labeled "Receiver Identification”, and, by pressing a "Fetch certificate” button, download the corresponding certificate which will be displayed in a list window.
- Most messages will consist only of attached files. However, a simple text composer can also be included for convenience and be activatable by a button.
- Alice can send the encrypted request to the postal agent.
- the receiver, Bob will receive a secure URL to point to. Then using an SSL-enabled browser, he provides the receipt and receives back the message promptly.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU2001277879A AU2001277879A1 (en) | 2000-07-14 | 2001-07-13 | Intermediated delivery scheme for asymmetric fair exchange of electronic items |
US10/332,614 US20040073790A1 (en) | 2001-07-13 | 2001-07-13 | Intermediated delivery scheme for asymmetric fair exchange of electronic items |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US21817200P | 2000-07-14 | 2000-07-14 | |
US60/218,172 | 2000-07-14 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2002007376A1 true WO2002007376A1 (en) | 2002-01-24 |
Family
ID=22814035
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2001/022074 WO2002007376A1 (en) | 2000-07-14 | 2001-07-13 | Intermediated delivery scheme for asymmetric fair exchange of electronic items |
Country Status (2)
Country | Link |
---|---|
AU (1) | AU2001277879A1 (en) |
WO (1) | WO2002007376A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7676677B2 (en) | 2003-10-01 | 2010-03-09 | Hewlett-Packard Development Company, L.P. | Digital signature method and apparatus |
US10623468B1 (en) | 2014-05-30 | 2020-04-14 | Mbr Innovations Llc | Systems and methods for simultaneous electronic file exchange |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5757913A (en) * | 1993-04-23 | 1998-05-26 | International Business Machines Corporation | Method and apparatus for data authentication in a data communication environment |
US6175921B1 (en) * | 1994-04-28 | 2001-01-16 | Citibank, N.A. | Tamper-proof devices for unique identification |
-
2001
- 2001-07-13 WO PCT/US2001/022074 patent/WO2002007376A1/en active Application Filing
- 2001-07-13 AU AU2001277879A patent/AU2001277879A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5757913A (en) * | 1993-04-23 | 1998-05-26 | International Business Machines Corporation | Method and apparatus for data authentication in a data communication environment |
US6175921B1 (en) * | 1994-04-28 | 2001-01-16 | Citibank, N.A. | Tamper-proof devices for unique identification |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7676677B2 (en) | 2003-10-01 | 2010-03-09 | Hewlett-Packard Development Company, L.P. | Digital signature method and apparatus |
US10623468B1 (en) | 2014-05-30 | 2020-04-14 | Mbr Innovations Llc | Systems and methods for simultaneous electronic file exchange |
Also Published As
Publication number | Publication date |
---|---|
AU2001277879A1 (en) | 2002-01-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5666420A (en) | Simultaneous electronic transactions | |
US9634843B2 (en) | Apparatus and methods for the secure transfer of electronic data | |
US6988199B2 (en) | Secure and reliable document delivery | |
Kremer et al. | An intensive survey of fair non-repudiation protocols | |
Zhou et al. | Evidence and non-repudiation | |
US20040073790A1 (en) | Intermediated delivery scheme for asymmetric fair exchange of electronic items | |
Ateniese et al. | TRICERT: A Distributed Certified E-Mail Scheme. | |
US6141750A (en) | Simultaneous electronic transactions with subscriber verification | |
US6134326A (en) | Simultaneous electronic transactions | |
US5509071A (en) | Electronic proof of receipt | |
Asokan et al. | Server-supported signatures | |
US7251728B2 (en) | Secure and reliable document delivery using routing lists | |
US20030190046A1 (en) | Three party signing protocol providing non-linkability | |
WO1998027688A2 (en) | Method and apparatus for simultaneous electronic exchange using a semi-trusted third party | |
Schneier et al. | A certified e-mail protocol | |
Zhou | Non-repudiation | |
US6243466B1 (en) | Auto-escrowable and auto-certifiable cryptosystems with fast key generation | |
Vogt et al. | Modular fair exchange protocols for electronic commerce | |
KR20010013155A (en) | Auto-recoverable auto-certifiable cryptosystems | |
EP0815671B1 (en) | Simultaneous electronic transactions | |
Onieva et al. | Non-repudiation protocols for multiple entities | |
Shao et al. | Some common attacks against certified email protocols and the countermeasures | |
Zhou | Achieving fair nonrepudiation in electronic transactions | |
Al-Hammadi et al. | Certified exchange of electronic mail (CEEM) | |
WO2002007376A1 (en) | Intermediated delivery scheme for asymmetric fair exchange of electronic items |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
122 | Ep: pct application non-entry in european phase | ||
ENP | Entry into the national phase |
Ref document number: 2003130267 Country of ref document: RU Kind code of ref document: A Format of ref document f/p: F |
|
WWE | Wipo information: entry into national phase |
Ref document number: 10332614 Country of ref document: US |
|
NENP | Non-entry into the national phase |
Ref country code: JP |