A method for prohibiting transacting parties from subsequently repudiating an executed transaction with a trusted third party

0001A Method for Prohibiting Transacting Parties from Subsequently Repudiating an

0002Executed Transaction With a Trusted Third Party

FIELD OF THE INVENTION

0004The present invention relates to protocols for ensuring security during electronic

0005commerce in a computer network, and more particularly, to a protocol for preventing

0006parties involved in an electronic commerce transaction from later repudiating the

0007transaction.

BACKGROUND OF THE INVENTION

0009Electronic commerce, in the form of electronic data interchange (EDI), was

0010initially utilized in inter-business trading by entities in certain industries. Entities

0011involved in EDI employed a combination of technologies including dedicated

0012communications lines, dial-up links, mainframe terminal emulation and packet-switching

0013data networks and they generally relied on value added network (VAN) service providers.

0014VAN service providers typically provide data communication services and assist

0015industries/clients in such areas as software configuration, security, auditing, transaction

0016tracing, and recovery of lost data. The costs associated with VAN services generally

0017prohibited entities and individuals involved in short-term, low-volume trading from engaging in electronic commerce.

0018Transacting parties employing VAN services traditionally required weeks of

0019preparation before the actual electronic transaction occurred. This preparation typically included negotiating technical and administrative protocols and executing legal

0020agreements. Electronic trading relationships between transacting parties generally

0021involved long-term, high-volume trading between familiar, if not primary, business

0022partners. This type of relationship typically justified the high cost of electronic

0023commerce using VAN service providers. The emergence ofthe Internet, however,

0024reduced the need for VAN service providers and enabled one-term or short-term

0025transacting parties to engage in electronic commerce.

0026The Internet now provides an efficient means of transacting business between

0027buyers and sellers of goods and services. For example, Internet users may utilize

0028electronic mail as a quick means of negotiating business agreements, and selling vendors

0029may utilize web sites to enable other vendors or individuals, without long term

0030relationships with the selling vendors, to purchase merchandize on-line from the selling

0031vendor. However, due to the public nature ofthe Internet, a third party may easily

0032intercept and/or manipulate transactions over the World Wide Web (Web), thereby,

0033breaching electronic security. As the volume of Internet electronic commerce between

0034transacting parties with short and long-term relationships grows, so too will electronic

0035commerce security issues.

0036In order to guarantee an electronic commerce system where each message in an

0037EDI transaction is secured, security requirements, such as confidentiality, integrity,

0038authenticity, authorization and non-repudiation, must be satisfied. Many computer

0039systems use a password mechanism to control access to information. In these systems

0040each user typically has a password that is kept secret and when the user needs access to protected information, the user enters the secret password into the system. This scheme

0041works well in conventional computer systems where the user's password is not revealed

0042to others. However, in a network, particularly the Internet where an attached computer is

0043capable of capturing a copy of all network traffic at a routing point, a simple password

0044mechanism is susceptible to eavesdropping. If a user at one location sends a password

0045across the network to a computer at another location, a third party who wiretaps the

0046network may obtain a copy ofthe password. Therefore, to ensure that the content of

0047messages in electronic transactions remain confidential despite wiretapping, the messages

0048must be encrypted.

0049Encryption, in essence, scrambles bits of a message in such a way that only the

0050intended recipient can unscramble them. Hence, a third party who intercepts a copy of

0051the encrypted message will be unable to extract information from encrypted message. As

0052would be understood, several encryption technologies exist. For example, symmetric key

0053encryption algorithms or secret key cryptography have been developed to satisfy the

0054confidentiality requirement. The encryption algorithms enable a sender to encrypt a

0055message in a non-distinguishable cipher by using a secret key and only a recipient

0056holding the same shared secret key can decrypt the encrypted message.

0057To satisfy the integrity requirement, hash functions may be used to generate a

0058message integrity check in order for the recipient ofthe message to determine its integrity

0059In general, together with public key cryptography, cryptographic hashing mechanisms

0060encode the message in a message authentication code that a third party cannot break or

0061forge. Thus, only the receiver can use the same hash function to check whether the message is compromised or not, and also to verify whether it came from the real sender

0062or not.

0063A digital signature mechanism that includes a pair of keys, may be used to

0064authenticate the sender of a message. The sender signs the message with one key in the

0065pair of keys known only to the sender, for example, the sender's private key. The

0066recipient uses the other key in the pair of keys, for example the sender's public key, to

0067verify the message. The recipient knows who sent the message because only the sender

0068has the private key. To ensure that the message is not copied and later resent, the original

0069message may also contain a date/time stamp, i.e., the date and time that the message was

0070created. Controlling who has responsibility for each item of information and how such

0071responsibility is delegated to others satisfies the authorization requirement. Despite these

0072technical advances in electronic commerce, a transacting party may subsequently deny

0073sending or receive a message in the transaction or the entire transaction. A protocol that

0074prohibits one or more transacting parties from repudiating the transaction is required to

0075satisfy the non-repudiation requirement.

0076The non-repudiation requirement is a communication attribute that prohibits one

0077party, in an electronic transaction, from denying that the transaction occurred. There are

0078two kinds of non-repudiation requirements dealing with subsequent denials ofthe

0079transaction: non-repudiation of origin, which is non-repudiation by the sender that the

0080transaction was sent; and non-repudiation of receipt, which is non-repudiation by the

0081recipient that the transaction was received. While a sender and recipient, in a VAN, with

0082long-standing relationships may trust each other and thus have limited or no concern about repudiation, this is rarely the case with Internet transactions. Typically in an

0083Internet transaction, one transacting party may not trust the other party or both parties

0084may not trust each other. Moreover, in Internet commerce the trust level between

0085transacting parties is dynamic because it is generally easy for one party to cheat without

0086being discovered. For example, if the sender initially trusts the recipient but later

0087suspects the recipient of cheating, the sender's trust level for the recipient is likely to

0088change.

0089To solve the repudiation problem, some methodologies implement a traditional

0090protocol whereby, the sender includes a desired product and the sender's digital signature

0091in a first message and the recipient may use the digital signature as evidence of non-

0092repudiation of origin. The recipient retrieves the desired product from the first message

0093and is thereafter expected to send a reply message, with the recipient's digital signature,

0094to the sender. The sender may use the reply message as evidence of non-repudiation of

0095receipt. This protocol works best when the sender trusts the recipient. However, this

0096scheme allows an unscrupulous recipient to deny receiving the first message and to fail to

0097send the reply message. Hence, the sender has no way of determining if the recipient

0098actually received the first message. Additionally, the sender has no way of determining if

0099the first message was successfully delivered to the recipient or destroyed during a system

0100malfunction. Since the tradition protocol cannot properly ensure non-repudiation of

0101receipt, the sender must somehow ensure that the recipient will always acknowledge

0102receipt ofthe message.

0103Some methods employ a trusted third party in each transaction, i.e., each message in the transaction must pass through the trusted third party. The trusted third party

0104verifies that each security requirement is fulfilled and that each party behaves

0105appropriately in order to prevent repudiation by both parties and to prevent other breaches

0106in security. Requiring the trusted third party to process all security requirements in each

0107transaction increases the costs associated with electronic commerce. Additionally, as the

0108number of transacting parties and the number of transactions between transacting parties

0109increase, it may be difficult to find a trusted third party to process every transaction.

0110Moreover, other problems exist with the current trusted third party scheme. In the

0111current scheme, the sender includes in the first message a product that is encrypted with a

0112session key and transmits the first message to the recipient. The recipient requests the

0113session key in order to decrypt the product in the first message. The sender transmits the

0114session key that is encrypted with the recipient's public key to the trusted third party.

0115The trusted third party thereafter transmits the session key to the recipient. However, a

0116corrupt recipient may wiretap the network during transmission ofthe session key to the

0117trusted third party. Since the session key is encrypted with the recipient's public key, the

0118recipient may decrypt the session key with the recipient's private key and then decrypt

0119the encrypted product with the intercepted session key. The corrupt recipient may later

0120repudiate the transaction and the sender has no way of proving that the recipient retrieved

0121the session key from the trusted third party. On the other hand, if the sender encrypts the

0122session key with the trusted third party's public key, while trusted third parties are usually

0123reputable organization, a corrupt trusted third party may decrypt the session key with it's

0124private key and then decrypt the encrypted product. The sender may encrypt the session key with the recipient's and trusted third party's public keys and thereby require the

0125recipient to retrieve the key from the trusted third party, however, this solution is difficult

0126to achieve in asymmetric cryptography.

0127A co-pending United States applicationyz/e./ HEREWITH, titled, A Method for

0128Prohibiting Transacting Parties from Subsequently Repudiating an Executed Transaction

0129Without a trusted third party, and incorporated by reference, relates to a protocol that

0130does not have a trusted third party involved in the electronic transaction. In this protocol,

0131the sender sends to the recipient in the encrypted first message, a product that is

0132encrypted with the session key. The first message also includes the sender's digital

0133signature, but it does not include the session key. The encrypted first message is used as

0134evidence of non-repudiation of origin. A second message from the recipient requesting

0135the session key is used as evidence of non-repudiation of receipt. Thereafter, the sender

0136generates a third message containing the session key that is encrypted with the recipient's

0137public key. The sender stores the third message in a public key repository on the sender's

0138web site. The recipient is thereafter required to go to the sender's web site to retrieve the

0139third message. The sender maintains the key repository. By monitoring activity on the

0140sender's site, the sender can prove to the appropriate authorities during subsequent

0141repudiation by the recipient that the recipient retrieved the session key from the key

0142repository. This invention works well in a situation where the sender is trustworthy and

0143the recipient does not have to worry about repudiation by the sender.

0144However in a situation where repudiation by the sender is an issue, this invention

0145may not sufficiently solve the problem since the sender maintains the key repository and the recipient must trust the sender to publish the key at the required time. An

0146unscrupulous sender may publish the key after the required time and manipulate the time

0147stamp in the message with the session key to prove that the key was actually published on

0148time. Hence, when repudiation of origin and receipt is an issue, a protocol that does not

0149require one transacting party to rely on the trustworthiness of another transacting party is

0150required.

SUMMARY OF THE INVENTION

0152The present invention relates to a protocol for prohibiting non-repudiation by

0153transacting parties involved in an executed electronic transaction, whereby a trusted third

0154party is responsible for ensuring non-repudiation. In this protocol, a sender uses a secret

0155sharing technology to divide an original session key into a first sub-session key and a

0156second sub-session key. The first and second sub-session keys must be combined into the

0157original session key in order for a recipient to decrypt a product that is encrypted with the

0158original session key. The sender includes the first sub-session key that is encrypted with

0159a recipient's public key and an encrypted product in a first message. Then the sender

0160transmits the first message to the recipient. The recipient uses the first message as

0161evidence of non-repudiation of origin, i.e., evidence of non-repudiation that the sender

0162sent the transaction. The recipient transmits, to the sender, a second message requesting

0163the second sub-session key. The sender may use the second message as evidence of non-

0164repudiation of receipt, i.e., evidence of non-repudiation that the recipient received the

0165transaction. Thereafter, the sender includes the second sub-session key which is encrypted with the trusted third party's public key in a third message that is forwarded to

0166the trusted third party. The trusted third party decrypts the third message to retrieve the

0167second sub-session key and then re-encrypts the second sub-session key with the

0168recipient's public key. The trusted third party includes the re-encrypted second sub-

0169session key in a fourth message and publishes the fourth message on the trusted third

0170party's web site where the recipient is responsible for retrieving it. This protocol

0171therefore ensures non-repudiation of origin and non-repudiation of receipt without

0172reliance on the trustworthiness of one or more transacting parties. Furthermore, by

0173involving the trusted third party in minimal transaction processing, i.e., only non-

0174repudiation processing, the responsibility and liability ofthe trusted third party is

0175reduced, thereby reducing the cost associated with trusted third parties in electronic

0176transactions.

0177Specifically in the preferred embodiment ofthe invention, the sender encrypts a

0178requested product with the session key and includes the encrypted product, the sender's

0179digital signature and the first sub-session key in the first message. Only the recipient can

0180decrypt the first sub-session key with the recipient's private key. In order to decrypt the

0181first message and retrieve the requested product, the recipient must also obtain the second

0182sub-session key. The recipient may use the encrypted first message with the first sub-

0183session key and the sender's digital signature as evidence of non-repudiation of origin.

0184When the recipient requests the second sub-session key with a message that includes the

0185recipient's digital signature, the sender may use the request message as evidence of non-

0186repudiation of receipt. The sender thereafter encrypts the second sub-session key with the trusted third party's public key and includes the encrypted second sub-session key in the

0187third message. Thus, only the trusted third party can obtain the second sub-session key.

0188The trusted third party decrypts the third message in order to obtain the second sub-

0189session key. The trusted third party re-encrypts the second sub-session with the

0190recipient's public key and includes the re-encrypted second sub-session key in a fourth

0191message. The trusted third party publishes the fourth message in a key repository on

0192trusted third party's web site. Thereafter, only the recipient can decrypt the second sub-

0193session key with the recipient's private key.

0194The recipient is required to go to the trusted third party's web site to retrieve the

0195fourth message. Subsequently, the recipient combines the first and second sub-session

0196keys to form the original session key in order to decrypt the encrypted product in the first

0197message. The trusted third party maintains the key repository. By monitoring activity on

0198the trusted third party's site, the trusted third party can prove to the appropriate

0199authorities during subsequent repudiation by the recipient that the recipient retrieved the

0200second sub-session key from the key repository.

0201Additional features and advantages ofthe invention will be set forth in the

0202description that follows, and in part will be apparent from the description, or may be

0203learned by practice ofthe invention. The objectives and advantages ofthe invention will

0204be realized and attained by the system particularly pointed out in the written description

0205and claims hereof as well as the appended drawings.

0206To achieve these and other advantages and in accordance with the purpose ofthe

0207invention, as embodied and broadly described, the present invention provides a method for ensuring non-repudiation by transacting parties involved in an executed electronic

0208transaction, the transacting parties using a trusted third party to resolve repudiation

0209disputes, the method comprising the steps of: generating, by a sending party, a session

0210key and dividing the session key into a plurality of sub-session keys comprising a first

0211sub-session key and a second sub-session key; sending, by the sending party to a

0212receiving party, a first cryptographic message, the first cryptographic message including a

0213product that is encrypted with the session key, a digital signature ofthe sending party,

0214and the first sub-session key; requesting upon receipt ofthe first cryptographic message,

0215by the receiving party from the sending party, the second sub-session key in a second

0216message, the second message including the receiving party digital signature; transmitting

0217upon receipt ofthe second message, from the sending party to a trusted third party, a third

0218cryptographic message with the second sub-session key, the second sub-session key

0219encrypted with the trusted third party's public key; obtaining, by the trusted third party,

0220the second sub-session key from the third cryptographic message and generating a fourth

0221cryptographic message; publishing, by the trusted third party, the fourth cryptographic

0222message on the trusted third party's web site; retrieving, by the receiving party, the fourth

0223cryptographic message from the trusted third party's web site; and combining, by the

0224receiving party, a predefined number ofthe plurality of sub-session keys into a required

0225session key in order to retrieve encrypted product from the first cryptographic message.

0226The invention alternatively provides a system for ensuring non-repudiation by

0227transacting parties involved in an executed electronic transaction, the transacting parties

0228using a trusted third party to resolve repudiation disputes, the system comprises: means for generating, by a sending party, a session key and dividing the session key into a

0229plurality of sub-session keys comprising a first sub-session key and a second sub-session

0230key; means for sending, by the sending party to a receiving party, a first cryptographic

0231message, the first cryptographic message including a product that is encrypted with the

0232session key, a digital signature ofthe sending party, and the first sub-session key; means

0233for requesting upon receipt ofthe first cryptographic message, by the receiving party

0234from the sending party, the second sub-session key in a second message, the second

0235message including the receiving party digital signature; means for transmitting upon

0236receipt ofthe second message, from the sending party to a trusted third party, a third

0237cryptographic message with the second sub-session key, the second sub-session key

0238encrypted with the trusted third party's public key; means for obtaining, by the trusted

0239third party, the second sub-session key from the third cryptographic message and

0240generating a fourth cryptographic message; means for publishing, by the trusted third

0241party, the fourth cryptographic message on the trusted third party's web site; means for

0242retrieving, by the receiving party, the fourth cryptographic message from the trusted third

0243party's web site; and means for combining, by the receiving party, a predefined number

0244ofthe plurality of sub-session keys into a required session key in order to retrieve

0245encrypted product from the first cryptographic message.

BRIEF DESCRIPTION OF THE DRAWINGS

0247The accompanying drawings, which are included to provide a further

0248understanding ofthe invention and are incorporated in and constitute a part of this specification, illustrate embodiments ofthe invention that together with the description

0249serve to explain the principles ofthe invention.

0250In the drawings:

0251Fig. 1 illustrates a computer network in which the inventive non-repudiation

0252protocol may be incorporated;

0253Fig. 2 illustrates the TCP/IP Layering Model Protocol used during

0254communications between components on the computer network;

0255Fig. 3 illustrates a secret sharing technology which enables a sender to divide a

0256session key into two keys;

0257Fig. 4 illustrates an alternate embodiment for dividing two session keys into two

0258sub-session keys;

0259Fig. 5 illustrates a preferred embodiment ofthe inventive non-repudiation

0260protocol; and

0261Fig. 6 illustrates the steps implemented according to the preferred embodiment of

0262the inventive non-repudiation protocol in Fig. 5; and

0263Fig. 7 illustrates a security architecture in which the inventive non-repudiation

0264protocol may be practiced.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

0266Reference will now be made in detail to the preferred embodiments ofthe present

0267invention, examples of which are illustrated in the accompanying drawings. The present

0268invention described below extends the functionality ofthe inventive non-repudiation protocols and methods for utilizing the protocol in a system.

0269Fig. 1 is an example of a local area network (LAN) 100 that is configured to

0270utilize a non-repudiation protocol. LAN 100 comprises a server 102, four computer

0271systems 104-110, and peripherals, such as printers and other devices 112, that may be

0272shared by components on LAN 100. Computer systems 104-110 may serve as clients for

0273server 102 and/or as clients and/or servers for each other and/or for other components

0274connected to LAN 100. Components on LAN 100 are preferably connected together by

0275cable media, for example copper or fiber-optic cable and the network typology may be a

0276token ring topology 114. It should be apparent to those of ordinary skill in the art that

0277other media, for example, wireless media, such as optical and radio frequency, may also

0278connect LAN 100 components. It should also be apparent that other network topologies,

0279such as Ethernet, may be used.

0280Data may be transferred between components on LAN 100 in packets, i.e., blocks

0281of data that are individually transmitted over LAN 100. Routers 120, 122 create an

0282expanded network by connecting LAN 100 to other computer networks, such as the

0283Internet, other LANs or Wide Area Networks (WAN). Routers are hardware devices that

0284may include a conventional processor, memory, and separate I/O interface for each

0285network to which it connects. Hence, components on the expanded network may share

0286information and services with each other. In order for communications to occur between

0287components of physically connected networks, all components on the expanded network

0288and the routers that connect them must adhere to a standard protocol. Computer networks

0289connected to the Internet and to other networks typically use TCP/IP Layering Model Protocol. It should be noted that other internetworking protocols may be used.

0290As illustrated in Fig. 2, TCP/IP Layering Model comprises an application layer or

0291(Layer 5) 202, a transport layer or (Layer 4) 204, an Internet layer or (Layer 3) 206, a

0292network interface layer or (Layer 2) 208, and a physical layer or (Layer 1) 210.

0293Application layer protocols 202 specify how each software application connected to the

0294network uses the network. Transport layer protocols 204 specify how to ensure reliable

0295transfer among complex protocols. Internet layer protocols 206 specify the format of

0296packets sent across the network as well as mechanisms used to forward packets from a

0297computer through one or more routers to a final destination. Network interface layer

0298protocols 208 specify how to organize data into frames and how a computer transmits

0299frames over the network; and physical layer protocols 210 correspond to the basic

0300network hardware. By using TCP/IP Layering model protocols, any component

0301connected to the network can communicate with any other component connected directly

0302or indirectly to one ofthe attached networks.

0303A browser application, such as Microsoft Explorer ™ or Netscape Internet

0304Browser ™, connects users on computer systems 104-110 to the World Wide Web (Web)

0305on the Internet. Most browser applications display information on computer 104-110

0306screens and permit a user to navigate through the Web using a mouse. Like other

0307network applications, Web browsing uses the client-server paradigm. When given the

0308Uniform Resource Locator (URL) of a document, the browser application becomes a

0309client and it contacts the server specified in the URL to request the document. After

0310receiving the document from the server, the browser application displays the document for the user. When the browser application interacts with a Web server application, the

0311two applications follow the HyperText Transport Protocol (HTTP). HTTP allows the

0312browser application to request a specific item, which the server application then returns.

0313^• To ensure that browser applications and server applications inter-operate unambiguously,

0314HTTP defines the exact format for request sent from the browser application to the server

0315application as well as the format of replies that the server application returns. It is

0316apparent to those skilled in the art that other protocols may be used.

0317Currently, during an electronic commerce transaction on the Internet, one

0318transacting party enters the URL of another transacting party and the browser application

0319requests a web page associated with the URL from the appropriate server application.

0320After displaying the web page, one transacting party may transmit a transaction to the

0321other transacting party through the displayed web page and the browser application. For

0322example, a buyer on the Internet, wishing to purchase a software application, may enter

0323the URL of a seller into the browser application. The browser displays a corresponding

0324web page and the buyer may order the software application through the web page. Upon

0325receiving the order, the seller may transmit the software application through the seller's

0326web page to the buyer. During transmission, however, a third party may intercept the

0327transaction or the system may malfunction before all messages in the transaction are

0328submitted to the buyer.

0329To ensure that security requirements of confidentiality, integrity, authenticity and

0330authorization are fulfilled during each transmission, current encryption technologies are

0331implemented. However one ofthe transacting parties may later deny that the transaction actually occurred. For example, the buyer may subsequently deny receiving the already

0332delivered software application. Moreover, if there was a system malfunction, the

0333transmission ofthe software application to the buyer may be destroyed during the

0334malfunction and the seller may request payment for the undelivered software application

0335from the buyer. Thus, it is important that both the buyer and the seller have some

0336evidence of a properly executed transaction to prevent subsequent repudiation by either

0337party.

0338The present invention utilizes a secret sharing technology to prevent non-

0339repudiation of origin and receipt. Secret sharing is a key distribution mechanism whereby

0340multiple parties hold separate portions of a required key and a predefined number parties

0341must combine their portions for the required key to be recovered. Secret sharing

0342technology therefore ensures that the recipient of a product must obtain predefined part(s)

0343ofthe required key that encrypts a product, from the sender or a third party, in order for

0344the recipient to decrypt the product.

0345Fig. 3 illustrates a secret sharing technology that enables a sender to divide a

0346session key into two sub-session keys. As illustrated in Fig. 3, the sender generates an

0347original session key (K) and divides it into Kl 302 and K2 304 by using the following

0348formula:

0349Kl - (K + r*ID_R) mod 2⁶⁴

0350K2 = (K + r*ID_TTP) mod 2⁶⁴

0351Where r is a large random number generated by the sender; ID_Ris the recipient's

0352unique public identifier; and ID_TTPis a trusted third party's unique public identifier. Fig. 4 illustrates an alternate embodiment for dividing two session keys into two

0353sub-session keys. Using two session keys in a secret sharing technology ensure stronger

0354security since a third party must obtain two keys in order to decrypt the desired product.

0355As illustrated in Fig. 4, the sender generates two original session keys (K and K') and

0356divides them into Kl 402 and K2 404 by using the following formula:

0357Kl = (K + K'*ID_R) mod 2⁶⁴

0358K2 = (K + K'*ID_TTP) mod 2 64

0359Where K and K' can be recreated by the recipient when he/she obtains Kl from

0360the sender and K2 from the trusted third party.

0361Fig. 5 illustrates a preferred embodiment of a non-repudiation protocol 500 where

0362the trusted third party addresses only non-repudiation issues, thereby minimizing the cost

0363associated with trusted third party processing. In protocol 500, sender 502 includes a

0364product that is encrypted with the session key in message 508 and transmits message 508

0365to the recipient. Message 508 also includes sender's 502 digital signature and first sub-

0366session key 302/402 that is encrypted with recipient's 504 public key. Recipient 504 may

0367decrypt first sub-session key 302/402 with recipient's private key. However, recipient

0368504 is required to obtain the second sub-session key 304/404 in order to decrypt message

0369508 and retrieve the encrypted product. In order to obtain second sub-session key

0370304/404, recipient 504 must acknowledge receipt of message 508 to sender 502. If

0371recipient 504 is no longer interested in encrypted message 508 after receiving it, recipient

0372504 is not required to request second sub-session key 304, and the protocol ends. If

0373recipient 504 did not receive encrypted message 508 due to a system error and recipient 504 does not request second sub-session key 304/404, sender 502 is then alerted by the

0374fact that recipient 504 did not request second sub-session key 304/404. Sender 502 may

0375thereafter inquire why recipient 504 did not request the second sub-session key and may

0376re-send encrypted message 508 when the system malfunction no longer exists.

0377Recipient 504 may use encrypted message 508 as evidence of non-repudiation of

0378origin. Recipient 504 may request second sub-session key 304/404 from sender 502 in

0379message 510. Message 510 includes recipient's 504 digital signature and sender 502 may

0380use message 510 as evidence of non-repudiation of receipt. Upon receipt ofthe message

0381510, sender 502 encrypts second sub-session key 304/404 with a trusted third party's

0382public key and includes encrypted sub-session key 304/404 in message 512. Sender 502

0383thereafter transmits messages 512 to trusted third party 506 who is responsible for

0384resolving repudiation disputes between sender 502 and recipient 504.

0385Upon receipt of message 512, trusted third party 506 decrypts it with trusted third

0386party's private key to obtain second sub-session key 304/404. Trusted third party 506 re-

0387encrypts second sub-session key 304/404 with recipient's 504 public key. Then trusted

0388third party 506 includes the re-encrypted second sub-session key 304/404 in message 514

0389and publishes message 514 in trusted third party's public key repository. Thereafter only

0390recipient 504 can decrypt message 514 with recipient's private key. Recipient 504 and

0391sender 502 need to actively retrieve message 514 from the trusted third party's site by

0392using a persistent protocol such as HTTP or File Transfer Protocol (FTP). Recipient 504

0393then combines first and second sub-session keys 302/402 and 304/404 to retrieve the

0394original session key and decrypt the product in message 508. In this protocol, trusted third party 506 is responsible for taking care ofthe key

0395repository 518 and publishing second sub-session key 304/404. By tracking activity on

0396the trusted third party's site, trusted third party 506 can determine when recipient 504

0397retrieved second sub-session key 304/404. If recipient 504 later deny retrieving second

0398sub-session key304/404, trusted third party 506 can prove to the appropriate authority

0399that the key was actually published and retrieved. Moreover, if there is a dispute between

0400sender 502 and recipient 504 about proper transmission of the product, sender 502 can

0401transmit a fifth message with the first sub-session key 302/402 and the encrypted product

0402in dispute to trusted third party 506. Trusted third party can then verify whether there

0403was proper transmission from sender to recipient. Since trusted third party 506 is

0404generally a disinterested and reputable party, it is easier for trusted third party to resolve

0405disputes and repudiation issues.

0406Fig 6 illustrates the steps implemented in a preferred embodiment ofthe inventive

0407protocol. In Step 610 of protocol 500, sender 502 sends encrypted message 508 with

0408sender's 302 digital signature, the encrypted product and a first sub-session key to the

0409recipient. In Step 620, recipient 504 may use encrypted message 508 as evidence of non-

0410repudiation of origin. In Step 630, recipient 504 requests second sub-session key 304/404

0411from sender 502 in message 510 with recipient's 504 digital signature. Sender 502 may

0412then use message 510 as evidence of non-repudiation of receipt. In Step 640, upon

0413receipt of message 510, sender 502 transmits a third message 512 with the encrypted

0414second sub-session key to trusted third party. In Step 650, trusted third party 506

0415decrypts third message 512, re-encrypts second sub-session key with recipient's public key and stores re-encrypted second sub-session key in fourth message 514. Trusted third

0416party 506 publishes the fourth message 514 in the public key repository 518 on trusted

0417third party's 506 web site. In Step 660, recipient is responsible for retrieving fourth

0418message 514 from the key repository, and sender 502 and recipient 504 may use message

0419514 as evidence in any later case of repudiation dispute.

0420Fig. 7 illustrates a security architecture 700 in which the inventive protocol may

0421be practiced. At the base layer of security architecture 700 is a security hardware 702 that

0422makes it more difficult for a third party to manipulate or steal secret information that is

0423embedded in a software package. A secret key cryptography system 704 and a public key

0424cryptography system 706 are built on security hardware 702 for providing additional

0425security. Cryptographic algorithms 708 are built on cryptographic systems 704 and 706.

0426The inventive non-repudiation protocol 710 and cryptographic protocols 712 are built on

0427cryptographic algorithms 708. Encryption algorithms and protocols 714a- 714d that

0428ensure confidentiality, integrity, authenticity and non-repudiation are built on

0429cryptographic protocols 712 and non-repudiation protocol 710. Security administration

0430716, which includes key management, authorization and management of access control

0431for a firewall and proxy server, is built on algorithms and protocol 714a-714d. HTTP 718

0432and S/MIME 720, the two most widely used protocols on the Web in electronic data

0433interchange, are also built on algorithms and protocols 714a-714d. A directory service

0434722, which implements a key distribution mechanism to distribute public keys in a

0435certificate authority 724, and certificate authority 724 are built upon security

0436administration 716 and on algorithms and protocols 714a-714d. Examples ofthe directory services include Microsoft Exchange™ directory, Lotus Notes™ directory, and

0437Novell Netware™ Directory Service. The next layer includes public key infrastructure

0438(PKI) 724, which is a comprehensive security infrastructure for enterprise-wide

0439applications. PKI 724 combines digital certificates, public key cryptography, secret key

0440cryptography, certificate authorities and directory services into one to make industry

0441decisions about security easier. EDI INT 726, a standard making organization, is also in

0442the layer with PKI 724. The final layer includes non-EDI applications 728 and EDI

0443applications 730.

0444The foregoing description has been directed to specific embodiments of this

0445invention. It will be apparent, however, that other variations and modifications may be

0446made to the described embodiments, with the attainment of some or all of their

0447advantages. Therefore, it is the object ofthe appended claims to cover all such variations

0448and modifications as come within the true spirit and scope ofthe invention.