WO2001025883A2

WO2001025883A2 - A method for preventing repudiation of an executed transaction without a trusted third party

Info

Publication number: WO2001025883A2
Application number: PCT/US2000/027070
Authority: WO
Inventors: Chunru Zhang; Ming Cai
Original assignee: Ecomxml Inc.
Priority date: 1999-10-01
Filing date: 2000-10-02
Publication date: 2001-04-12
Also published as: WO2001025883A3; CA2386522A1; AU7745200A

Abstract

A protocol for prohibiting subsequent denial by one of the transacting parties of an already executed electronic transaction. This protocol enables secure Internet electronic commerce without the necessity of using a trusted third party. In this protocol, a sending party transmits to a receiving party, an encrypted first message that includes a desired product encrypted with a required key, but that does not include the required key. The receiving party uses the encrypted first message as evidence of non-repudiation of origin, i.e., evidence of non-repudiation that the sending party sent the transaction. The receiving party transmits to the sending party a second message requesting for the required key. The sending party may use the second message as evidence of non-repudiation of receipt, i.e., evidence of non-repudiation that the receiving party received the transaction. Thereafter, the sending party publishes a third message with the encrypted required key on the sending party's web site, and the receiving party is required to go to the web site to fetch the third message. This protocol therefore ensures non-repudiation of origin and non-repudiation of receipt without a trusted third party involved in the electronic transaction.

Description

A Method for Prohibiting Transacting Parties from Subsequently Repudiating an

Executed Transaction Without a Trusted Third Party

FIELD OF THE INVENTION

The present invention relates to protocols for ensuring security during electronic

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

parties involved in an electronic commerce transaction from later repudiating the

transaction.

BACKGROUND OF THE INVENTION

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

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

involved in EDI employed a combination of technologies including dedicated

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

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

VAN service providers typically provide data communication services and assist

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

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

prohibited entities and individuals involved in short-term, low- volume trading from

engaging in electronic commerce. Transacting parties employing VAN services traditionally required weeks of

preparation before the actual electronic transaction occurred. This preparation typically

included negotiating technical and administrative protocols and executing legal

agreements. Electronic trading relationships between transacting parties generally

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

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

commerce using VAN service providers. The emergence of the Internet, however,

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

transacting parties to engage in electronic commerce.

The Internet now provides an efficient means of transacting business between

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

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

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

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

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

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

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

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

commerce security issues.

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

EDI transaction is secured, security requirements, such as confidentiality, integrity, authenticity, authorization and non-repudiation, must be satisfied. Many computer

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

each 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

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

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

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

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

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

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

messages in electronic transactions remain confidential despite wiretapping, the messages

must be encrypted.

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

intended recipient can unscramble them, thereby fulfilling the confidentiality

requirement. Hence, a third party who intercepts a copy of the encrypted message will be

unable to extract information from encrypted message. As would be understood, several

encryption technologies exist. For example, symmetric key encryption algorithms or

secret key cryptography have been developed to satisfy the confidentiality requirement.

The encryption algorithms enable a sender to encrypt a message in a non-distinguishable

cipher by using a secret key and only a recipient holding the same shared secret key can

decrypt the encrypted message. To satisfy the integrity requirement, hash functions may be used to generate a

message integrity check in order for the recipient of the message to determine its

integrity. In general, together with public key cryptography, cryptographic hashing

mechanisms encode the message in a message authentication code that a third party

cannot break or forge. 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 or not. A digital signature mechanism that includes a pair of keys, may also

be used to authenticate the sender of a message. The sender signs the message with one

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

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

to verify the message. The recipient knows who sent the message because only the

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

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

message was created. Controlling who has responsibility for each item of information

and how such responsibility is delegated to others satisfies the authorization requirement.

Despite these technical advances in electronic commerce, a transacting party may

subsequently deny sending or receive a message in the transaction or the entire

transaction. The inventive protocol prohibits one or more transacting parties from

repudiating the transaction, thereby satisfying the non-repudiation requirement.

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

party, in an electronic transaction, from denying that the transaction occurred. There are two kinds of non-repudiation requirements dealing with subsequent denials of the

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

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

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

long-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

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

may not trust each other.

To solve the repudiation problem, some methodologies implement a traditional

protocol whereby, the sender includes a digital signature in a first message and the

recipient may use the digital signature as evidence of non-repudiation of origin. The

recipient retrieves desired information from the first message and is thereafter expected to

send a reply message, with the recipient's digital signature, to the sender. The sender

may use the reply message as evidence of non-repudiation of receipt. This protocol

works best when the sender trusts the recipient. However, this scheme allows an

unscrupulous recipient to deny receiving the first message and to fail to send the reply

message. Hence, the sender has no way of determining if the recipient actually received

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

was successfully delivered to the recipient or destroyed during a system malfunction.

Thus, this protocol cannot properly ensure non-repudiation of receipt. This protocol may

also be unacceptable in Internet commerce where the trust level between transacting parties is dynamic because it is generally easy for one party to cheat without being

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

recipient of cheating, the sender's trust level for the recipient is likely to change.

Therefore, the sender must somehow ensure that the recipient will always acknowledge

receipt of the message.

Some methods employ a trusted third party in each transaction, that is, each

message in the transaction must pass through the trusted third party. The trusted third

party verifies that each party behaves appropriately in order to prevent repudiation by

both parties and to prevent other breaches in security. Including a trusted third party in

each transaction increases the costs associated with electronic commerce and it increases

the trusted third party's liability. Additionally, as the number of transacting parties and

the number of transactions between transacting parties increase, it may be difficult to find

a trusted third party to process every transaction.

SUMMARY OF THE INVENTION

The present invention relates to a protocol for prohibiting subsequent denial by

one of the transacting parties of an already executed electronic transaction. This protocol

enables secure Internet electronic commerce without the necessity of using a trusted third

party. In this protocol, a sending party transmits to a receiving party, an encrypted first

message that includes a desired product. The desired product is encrypted with a required key. The receiving party uses the encrypted first message as evidence of non-repudiation

of origin, i.e., evidence of non-repudiation that the sending party sent the transaction.

The receiving party transmits to the sending party a second message requesting for the

required key. The sending party may use the second message as evidence of non-

repudiation of receipt, i.e., evidence of non-repudiation that the receiving party received

the transaction. Thereafter, the sending party publishes a third message with the required

key. This protocol therefore ensures non-repudiation of origin and non-repudiation of

receipt without a trusted third party involved in the electronic transaction.

Specifically in the preferred embodiment of the invention, the sending party

transmits the encrypted first message with the sending party's digital signature but

without a session key. The session key is required to decrypt the desired product in the

first encrypted message. The receiving party is therefore unable to access the desired

product in the first message without the session key. The receiving party may use the

encrypted first message with the sending party's digital signature as evidence of non-

repudiation of origin. When the receiving party requests the session key with the second

message that includes the receiving party's digital signature, the sending party may use

the second message as evidence of non-repudiation of receipt. The sending party will

thereafter publish the third message including the encrypted session key in a public key

repository on the sending party's web site. The session key in the third message is

encrypted with the receiving party's public key and only the receiving party can decrypt

the session key with the receiving party's private key. The receiving party is thereafter required to go to the sending party's web site to retrieve the third message. The sending

party maintains the key repository. Therefore by monitoring activity on the sending

party's site, the sending party can prove to the appropriate authorities during subsequent

repudiation by the receiving party that the receiving party retrieved the session key from

the key repository. The inventive protocol therefore requires only one additional message

than those required in traditional protocols to ensure non-repudiation of origin and

receipt.

Additional features and advantages of the invention will be set forth in the

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

learned by practice of the invention. The objectives and advantages of the invention will

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

and claims hereof as well as the appended drawings.

To achieve these and other advantages and in accordance with the purpose of the

invention, as embodied and broadly described, the present invention provides a method

for ensuring non-repudiation by transacting parties involved in an executed electronic

transaction, the method includes the steps of sending, to a receiving party from a sending

party, a first encrypted message with a digital signature of the sending party, the first

encrypted message not including a required key but including a desired product that is

encrypted with a required key; requesting, by the receiving party from the sending party,

the required key in a second encrypted message with the receiving party's digital

signature; publishing after the step of receiving, by the sending party, on the sending party's web site, a third encrypted message including the required key that is encrypted

with the receiving party's public key; and retrieving the third encrypted message from the

sending party's web site by the receiving party.

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

transacting parties involved in an executed electronic transaction, the system comprises

means for sending, to a receiving party from a sending party, a first encrypted message

with a digital signature of the sending party, the first encrypted message not including a

required key but including a desired product that is encrypted with a required key; means

for requesting, by the receiving party from the sending party, the required key in a second

encrypted message with the receiving party's digital signature; means for publishing after

the step of receiving, by the sending party, on the sending party's web site, a third

encrypted message including the required key that is encrypted with the receiving party's

public key; and means for retrieving the third encrypted message from the sending party's

web site by the receiving party.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a further

understanding of the invention and are incorporated in and constitute a part of this

specification, illustrate embodiments of the invention that together with the description

serve to explain the principles of the invention.

In the drawings: Fig. 1 illustrates a computer network in which the inventive non-repudiation

protocol may be incorporated;

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

communications between components on the computer network;

Fig. 3 illustrates a preferred embodiment of the inventive non-repudiation

protocol; and

Fig. 4 illustrates the steps implemented according to the preferred embodiment of

the inventive non-repudiation protocol in Fig. 3; and

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

protocol may be practiced.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

invention described below extends the functionality of the inventive non-repudiation

protocols and methods for utilizing the protocol in a system.

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

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

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

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

server 102 and/or as clients and/or servers for each other and/or for other components connected to LAN 100. Components on LAN 100 are preferably connected together by

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

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

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

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

such as Ethernet, may be used.

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

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

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

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

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

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

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

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

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

connected 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.

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

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

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

Application layer protocols 202 specify how each software application connected to the network uses the network. Transport layer protocols 204 specify how to ensure reliable

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

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

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

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

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

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

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

or indirectly to one of the attached networks.

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

Browser ™, connects users on computer systems 104-110 to the Internet. Most browser

applications display information on computer 104-110 screens and permit a user to

navigate through the Web using a mouse. Like other network applications, Web

browsing uses the client-server paradigm. When given the Uniform Resource Locator

(URL) of a document, the browser application becomes a client and it contacts the server

specified in the URL to request a document. After receiving 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 two applications follow the

HyperText Transport Protocol (HTTP). HTTP allows the browser application to request

a specific item, which the server application then returns. To ensure that browser

applications and server applications inter-operate unambiguously, HTTP defines the exact format for request sent from the browser application to the server application as well as

the format of replies that the server application returns.

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

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

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

After displaying the web page, the transacting party may submit a transaction to the other

transacting party through the displayed web page and the browser application. During

transmission, a third party may intercept the transaction or the system may malfunction

before all messages in the transaction are submitted to the appropriate server application.

Additionally, one of the transacting parties may later deny that the transaction actually

occurred. To ensure that each transaction is securely delivered to the appropriate

transacting party, security requirements such as confidentiality, integrity, authenticity,

authorization and non-repudiation must be fulfilled.

For example, a buyer on the Internet, wishing to purchase a software application,

may enter the URL of a seller into the browser application. The browser displays the

corresponding web page and the seller may order the software application through the

web page. Upon receiving the order, the seller may transmit the software application

through the seller's web page to the buyer. To ensure that security requirements are

fulfilled during each transmission current encryption technologies ensure fulfillment of

the confidentiality, integrity, authenticity and authorization requirements. However, the

buyer may subsequently deny receiving the already delivered software application. Moreover, the transmission of the software application to the buyer may have been

destroyed during a system malfunction. Thus, it is important that the seller have some

evidence of delivery to prevent subsequent repudiation by the buyer.

Fig. 3 illustrates a preferred embodiment of an inventive protocol 300 that

prevents both the sender from repudiating an already sent transaction and the receiver

from repudiating an already received transaction. In protocol 300, sender 302 sends an

encrypted message 306 including a desired product that is further encrypted with a

session key to receiver 304. Message 306 also includes sender's 302 digital signature,

but it excludes the session key. The session key is required to decrypt encrypted product

in message 306, and thus, receiver 304 is unable to retrieve the product. In order to

obtain the session key, receiver 304 must acknowledge receipt of message 306. If

receiver 304 is no longer interested in encrypted message 306 after receiving it, receiver

304 is not required to request the session key and the protocol ends. If receiver 304 did

not receive encrypted message 306 due to a system error and receiver 304 does not

request the session key, sender 302 is then alerted by the fact that receiver 304 did not

request the session key. Sender 302 may thereafter inquire why receiver 304 did not

request the session key and may re-send encrypted message 306 when the system

malfunction no longer exists.

Receiver 304 may use encrypted message 306 as evidence of non-repudiation of

origin. Thereafter, receiver 304 requests the session key from sender 302 in a message

308 that contains receiver's 304 digital signature. Sender 302 may then use message 308 as evidence of non-repudiation of receipt. Upon receipt of the message 308, sender 302

includes the session key which is encrypted with receiver's 304 public key in message

310 and publishes message 310 in a public key repository 312 on sender's 302 web site.

Since the session key is encrypted with receiver's 304 public key, only receiver 304 can

decrypt it with the receiver's private key. Receiver 304 needs to actively retrieve

message 310 from the sender's site by using a persistent protocol such as HTTP or File

Transfer Protocol (FTP).

In this protocol, sender 302 is responsible for taking care of the key repository

312 and publishing the key. Hence, only one additional message is added to the

traditional protocol to ensure non-repudiation of receipt. By tracking activity on the

sender's site, sender 302 can determine when receiver 304 retrieved the session key. If

receiver 304 later denies retrieving the key from the key repository, sender 302 can prove

to an appropriate authority that the key was actually published and received.

Fig 4 illustrates the steps implemented in the inventive protocol. In Step 410 of

protocol 300, sender 302 sends the desired product that is encrypted with the session key

in encrypted message 306. Encrypted message 306 includes sender's 302 digital

signature, but it does not include session key. The session key is required to decrypt the

desired product in encrypted message 306. In Step 420, receiver 304 may use encrypted

message 306 as evidence of non-repudiation of origin. In Step 430, receiver 304 requests

the session key from sender 302 in message 308 containing receiver's 304 digital

signature. Sender 302 may then use message 308 as evidence of non-repudiation of receipt. In Step 440, sender 302 publishes, in public key repository 312 on sender's 302

web site, third message 310 that includes the encrypted session key. The session key is

encrypted with the receiving party's public key. In Step 450, sender may use message

308 as evidence of non-repudiation of receipt.

Fig. 5 illustrates a security architecture 500 in which the inventive protocol may

be practiced. At the base layer of security architecture 500 is a security hardware 502 that

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

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

cryptography system 506 are built on security hardware 502 for providing additional

security. Cryptographic algorithms 508 are built on cryptographic systems 504 and 506.

The inventive non-repudiation protocol 510 and cryptographic protocols 512 are built on

cryptographic algorithms 508. Encryption algorithms and protocols 514a- 514d that

ensure confidentiality, integrity, authenticity and non-repudiation are on cryptographic

protocols 512 and non-repudiation protocol 510. Security administration 516, which

includes key management, authorization and management of access control for a firewall

and proxy server, is built on algorithms and protocols 514a-514d. HTTP 518 and

S/MIME 520, the two most widely used protocols on the Web in electronic data

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

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

certificate authority, and the certificate authority is built upon security administration 516

and on algorithms and protocols 514a-514d. Examples of the directory services include Microsoft Exchange™ directory, Lotus Notes™ directory, and Novell Netware™

directory Service. The next layer includes public key infrastructure (PKI) 524, which is a

comprehensive security infrastructure for enterprise-wide applications. PKI 524

combines digital certificates, public key cryptography, secret key cryptography,

certificate authorities and directory services into one to make industry decisions about

security easier. EDI INT 526, a standard making organization, is also in the layer with

PKI 524. The final layer of architecture 500 includes non-EDI applications 528 and EDI

applications 530.

The foregoing description has been directed to specific embodiments of this

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

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

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

and modifications as come within the true spirit and scope of the invention.

Claims

WHAT IS CLAIMED:

1. A method for ensuring non-repudiation by transacting parties involved in an executed

electronic transaction, the method comprising the steps of:

sending, by a sending party to a receiving party, a first cryptographic message with a

digital signature, the first cryptographic message including a product encrypted with a

required key but not including the required key;

requesting, by the receiving party from the sending party, the required key in a second

message with the receiving party's digital signature;

publishing, by the sending party, a third cryptographic message with the required key

which is encrypted with the receiving party's public key on the sending party's web site; and

retrieving the third cryptographic message from the sending party's web site by the

receiving party.

2. The method of claim 1, further comprising the step of requiring the required key in the

third cryptographic message to decrypt the first cryptographic message.

3. The method of claim 2, further comprising the step of using the first cryptographic

message as evidence of non-repudiation of origin.

4. The method of claim 3, further comprising the step of using the second cryptographic

message as evidence of non-repudiation of receipt.

5. The method of claim 4, further comprising the step of decrypting the third

cryptographic message with the receiving party's private key.

6. The method of claim 5, further comprising the step of retrieving the third

cryptographic message on the sending party's web site by using a persistent protocol.

7. The method of claim 6, further comprising the step of auditing the sending party's

web site in order to determine when the receiving party retrieves the third cryptographic

message.

8. The method of claim 7, further comprising the step of using encryption to create

the first, second and third cryptographic messages.

9. The method of claim 8, further comprising the step of using encoding to create the

first, second and third cryptographic messages.

10. The method of claim 9, further comprising the step of using hashing to create the

first, second and third cryptographic messages.

11. A system for ensuring non-repudiation by transacting parties involved in an

executed electronic transaction, the system comprises: means for sending, by a sending party to a receiving party, a first cryptographic

message with a digital signature of a sending, the first cryptographic message including a

product encrypted with a required key buy not including the required key;

means for requesting, by the receiving party from the sending party, the required key

in a second message with the receiving party's digital signature;

means for publishing, by the sending party, a third cryptographic message with the

required key which is encrypted with the receiving party's public key on the sending party's

web site; and

means for retrieving the third cryptographic message from the sending party's web

site by the receiving party.

12. The system of claim 11 , further comprising means for requiring the required key

in the third cryptographic message to decrypt the first cryptographic message.

13. The system of claim 12, further comprising means for using the first

cryptographic message as evidence of non-repudiation of origin.

14. The system of claim 13, further comprising means for using the second

cryptographic message as evidence of non-repudiation of receipt.

15. The system of claim 14, further comprising means for decrypting the third

cryptographic message with the receiving party's private key.

16. The system of claim 15, further comprising means for retrieving the third

17. The system of claim 16, further comprising means for maintaining the sending

party's web site in order to determine when the receiving party retrieves the third

cryptographic message.

18. The system of claim 17, further comprising means for proving to the appropriate

authorities that the receiving party retrieved the third cryptographic message.

19. The system of claim 18, further comprising means for using encryption to create

the first, second and third cryptographic messages.

20. The system of claim 19, further comprising means for using encoding to create the

first, second and third cryptographic messages.

21. The system of claim 20, further comprising means for using hashing to create the

first, second and third cryptographic messages.