WO2001030016A2 - A method for non-repudiation using a trusted third party - Google Patents

A method for non-repudiation using a trusted third party Download PDF

Info

Publication number
WO2001030016A2
WO2001030016A2 PCT/US2000/027069 US0027069W WO0130016A2 WO 2001030016 A2 WO2001030016 A2 WO 2001030016A2 US 0027069 W US0027069 W US 0027069W WO 0130016 A2 WO0130016 A2 WO 0130016A2
Authority
WO
WIPO (PCT)
Prior art keywords
party
sub
session key
trusted
message
Prior art date
Application number
PCT/US2000/027069
Other languages
French (fr)
Other versions
WO2001030016A3 (en
Inventor
Chunru Zhang
Ming Cai
Original Assignee
Ecomxml Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ecomxml Inc. filed Critical Ecomxml Inc.
Priority to CA002386502A priority Critical patent/CA2386502A1/en
Priority to AU77451/00A priority patent/AU7745100A/en
Publication of WO2001030016A2 publication Critical patent/WO2001030016A2/en
Publication of WO2001030016A3 publication Critical patent/WO2001030016A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce

Definitions

  • the present invention relates to protocols for ensuring security during electronic
  • Entities initially utilized in inter-business trading by entities in certain industries. Entities
  • VAN value added network
  • VAN service providers typically provide data communication services and assist
  • This preparation typically included negotiating technical and administrative protocols and executing legal
  • Internet users may utilize
  • EDI transaction is secured, security requirements, such as confidentiality, integrity,
  • 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.
  • Encryption in essence, scrambles bits of a message in such a way that only the
  • the encrypted message will be unable to extract information from encrypted message.
  • the encryption algorithms enable a sender to encrypt a
  • hash functions may be used to generate a
  • a digital signature mechanism that includes a pair of keys, may be used to
  • recipient uses the other key in the pair of keys, for example the sender's public key, to
  • message may also contain a date/time stamp, i.e., the date and time that the message was
  • a transacting party may subsequently deny
  • the non-repudiation requirement is a communication attribute that prohibits one
  • one transacting party may not trust the other party or both parties
  • transacting parties is dynamic because it is generally easy for one party to cheat without
  • the sender includes a desired product and the sender's digital signature
  • the recipient may use the digital signature as evidence of non-
  • the recipient retrieves the desired product from the first message
  • the sender may use the reply message as evidence of non-repudiation of
  • the sender has no way of determining if
  • the first message was successfully delivered to the recipient or destroyed during a system
  • Some 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 i.e., each message in the transaction must pass through the trusted third party.
  • the sender includes in the first message a product that is encrypted with a
  • session key and transmits the first message to the recipient.
  • the recipient requests the
  • the sender transmits the
  • session key that is encrypted with the recipient's public key to the trusted third party.
  • the trusted third party thereafter transmits the session key to the recipient.
  • a session key to the recipient.
  • recipient may decrypt the session key with the recipient's private key and then decrypt
  • the corrupt recipient may later
  • a corrupt trusted third party may decrypt the session key with it's
  • the sender may encrypt the session key with the recipient's and trusted third party's public keys and thereby require the
  • the sender sends to the recipient in the encrypted first message, a product that is
  • the first message also includes the sender's digital
  • the encrypted first message is used as
  • the session key is used as evidence of non-repudiation of receipt. Thereafter, the sender
  • the sender stores the third message in a public key repository on the sender's
  • the recipient is thereafter required to go to the sender's web site to retrieve the
  • the sender maintains the key repository. By monitoring activity on the
  • This invention works well in a situation where the sender is trustworthy and
  • the recipient does not have to worry about repudiation by the sender.
  • unscrupulous sender may publish the key after the required time and manipulate the time
  • the present invention relates to a protocol for prohibiting non-repudiation by
  • a sender uses a secret
  • the first and second sub-session keys must be combined into the
  • the sender includes the first sub-session key that is encrypted with
  • the recipient uses the first message as
  • the recipient transmits, to the sender, a second message requesting the transaction.
  • the sender may use the second message as evidence of non-
  • 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
  • the trusted third party decrypts the third message to retrieve the
  • the trusted third party includes the re-encrypted second sub-
  • the sender encrypts a
  • the recipient may use the encrypted first message with the first sub-session key.
  • the sender may use the request message as evidence of non-
  • 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
  • the trusted third party decrypts the third message in order to obtain the second sub-
  • the trusted third party re-encrypts the second sub-session with the
  • recipient's public key includes the re-encrypted second sub-session key in a fourth
  • the trusted third party publishes the fourth message in a key repository on
  • the recipient is required to go to the trusted third party's web site to retrieve the
  • the trusted third party maintains the key repository.
  • the trusted third party can prove to the appropriate
  • the present invention provides a method for ensuring non-repudiation by transacting parties involved in an executed electronic
  • the method comprising the steps of: generating, by a sending party, a session
  • session key in order to retrieve encrypted product from the first cryptographic message.
  • the invention alternatively provides a system for ensuring non-repudiation by
  • transacting parties involved in an executed electronic transaction the transacting parties
  • the system comprises: means for generating, by a sending party, a session key and dividing the session key into a
  • plurality of sub-session keys comprising a first sub-session key and a second sub-session
  • the first cryptographic message including a product that is encrypted with the
  • Fig. 1 illustrates a computer network in which the inventive non-repudiation
  • Fig. 2 illustrates the TCP/IP Layering Model Protocol used during
  • Fig. 3 illustrates a secret sharing technology which enables a sender to divide a
  • Fig. 4 illustrates an alternate embodiment for dividing two session keys into two
  • Fig. 5 illustrates a preferred embodiment ofthe inventive non-repudiation
  • Fig. 6 illustrates the steps implemented according to the preferred embodiment of
  • Fig. 7 illustrates a security architecture in which the inventive non-repudiation
  • Fig. 1 is an example of a local area network (LAN) 100 that is configured to
  • LAN 100 comprises a server 102, four computer
  • peripherals such as printers and other devices 112, that may be
  • 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
  • LAN 100 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 typology may be a
  • wireless media such as optical and radio frequency
  • Data may be transferred between components on LAN 100 in packets, i.e., blocks
  • Routers 120, 122 create an
  • Routers are hardware devices that are connected to the Internet, other LANs or Wide Area Networks (WAN). Routers are hardware devices that are connected to the Internet.
  • the processor may include a conventional processor, memory, and separate I/O interface for each
  • components on the expanded network may share
  • TCP/IP Layering Model comprises an application layer or
  • Layer 5 (Layer 5) 202, a transport layer or (Layer 4) 204, an Internet layer or (Layer 3) 206, a
  • Layer 2 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
  • Transport layer protocols 204 specify how to ensure reliable
  • Internet layer protocols 206 specify the format of
  • Network interface layer
  • protocols 208 specify how to organize data into frames and how a computer transmits
  • a browser application such as Microsoft Explorer TM or Netscape Internet
  • Browser TM connects users on computer systems 104-110 to the World Wide Web (Web)
  • the browser application displays the document for the user.
  • the browser application interacts with a Web server application, the
  • HTTP HyperText Transport Protocol
  • HTTP defines the exact format for request sent from the browser application to the server
  • transacting party enters the URL of another transacting party and the browser application
  • one transacting party may transmit a transaction to the
  • a buyer on the Internet wishing to purchase a software application, may enter
  • the browser displays a corresponding
  • the seller may transmit the software application through the seller's
  • a third party may intercept the
  • the transacting parties may later deny that the transaction actually occurred.
  • the buyer may subsequently deny receiving the already
  • the present invention utilizes a secret sharing technology to prevent non-
  • Fig. 3 illustrates a secret sharing technology that enables a sender to divide a
  • the sender generates an
  • K2 (K + r*ID TTP ) mod 2 64
  • ID R is the recipient's
  • FIG. 4 illustrates an alternate embodiment for dividing two session keys into two
  • the sender As illustrated in Fig. 4, the sender generates two original session keys (K and K') and
  • Kl (K + K'*ID R ) mod 2 64
  • K2 (K + K'*ID TTP ) mod 2 64
  • K and K' can be recreated by the recipient when he/she obtains Kl from
  • Fig. 5 illustrates a preferred embodiment of a non-repudiation protocol 500
  • the trusted third party addresses only non-repudiation issues, thereby minimizing the cost
  • sender 502 includes a
  • Message 508 also includes sender's 502 digital signature and first sub-
  • session key 302/402 that is encrypted with recipient's 504 public key.
  • Recipient 504 may
  • recipient 504 must acknowledge receipt of message 508 to sender 502. If
  • recipient 504 is no longer interested in encrypted message 508 after receiving it, recipient
  • recipient 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
  • sender 502 may
  • Recipient 504 may use encrypted message 508 as evidence of non-repudiation of
  • Recipient 504 may request second sub-session key 304/404 from sender 502 in
  • message 510 includes recipient's 504 digital signature and sender 502 may
  • sender 502 encrypts second sub-session key 304/404 with a trusted third party's
  • trusted third party 506 Upon receipt of message 512, trusted third party 506 decrypts it with trusted third
  • third party 506 includes the re-encrypted second sub-session key 304/404 in message 514
  • recipient 504 can decrypt message 514 with recipient's private key. Recipient 504 and
  • sender 502 need to actively retrieve message 514 from the trusted third party's site by
  • Recipient 504 uses a persistent protocol such as HTTP or File Transfer Protocol (FTP).
  • HTTP HyperText Transfer Protocol
  • FTP File Transfer Protocol
  • first and second sub-session keys 302/402 and 304/404 then combines first and second sub-session keys 302/402 and 304/404 to retrieve the
  • trusted third party 506 is responsible for taking care of the key
  • trusted third party 506 can determine when recipient 504
  • trusted third party 506 can prove to the appropriate authority
  • sender 502 can
  • Trusted third party can then verify whether there is
  • trusted third party 506 is
  • Fig 6 illustrates the steps implemented in a preferred embodiment ofthe inventive
  • Step 610 of protocol 500 sender 502 sends encrypted message 508 with
  • recipient 504 may use encrypted message 508 as evidence of non-
  • Step 630 recipient 504 requests second sub-session key 304/404
  • sender 502 may
  • Step 640 upon request, use message 510 as evidence of non-repudiation of receipt.
  • sender 502 transmits a third message 512 with the encrypted
  • party 506 publishes the fourth message 514 in the public key repository 518 on trusted
  • Step 660 recipient is responsible for retrieving fourth
  • Fig. 7 illustrates a security architecture 700 in which the inventive protocol may
  • security hardware 702 At the base layer of security architecture 700 is a security hardware 702 that
  • cryptography system 706 are built on security hardware 702 for providing additional
  • Cryptographic algorithms 708 are built on cryptographic systems 704 and 706.
  • the inventive non-repudiation protocol 710 and cryptographic protocols 712 are built on
  • HTTP 718 For a firewall and proxy server, is built on algorithms and protocol 714a-714d. HTTP 718
  • certificate authority 724, and certificate authority 724 are built upon security
  • Novell NetwareTM Directory Service The next layer includes public key infrastructure
  • PKI PKI 724
  • PKI 724 combines digital certificates, public key cryptography, secret key
  • the final layer includes non-EDI applications 728 and EDI

Abstract

A protocol for prohibiting non-repudiation by transacting parties involved in an executed electronic transaction, whereby a trusted third party is responsible for ensuring non-repudiation. In this protocol, a sender uses a secret sharing technology to divide the original session key into a first sub-session key and a second sub-session key. The first and second sub-session keys must be combined into the original session key in order for a recipient to decrypt a product that is encrypted with the original session key. The sender includes the first sub-session key that is encrypted with a recipient's public key and an encrypted product in a first message. Then the sender transmits the first message to the recipient. The recipient uses the first message as evidence of non-repudiation of origin, i.e., evidence of non-repudiation that the sender sent the transaction. The recipient transmits, to the sender, a second message requesting the second sub-session key. The sender may use the second message as evidence of non-repudiation of receipt, i.e., evidence of non-repudiation that the recipient received the transaction. 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 the trusted third party.

Description

A Method for Prohibiting Transacting Parties from Subsequently Repudiating an
Executed Transaction With 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 ofthe 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 ofthe 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 ofthe 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. 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 ofthe 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 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. A protocol that
prohibits one or more transacting parties from repudiating the transaction is required to
satisfy 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 ofthe
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. Moreover, in Internet commerce 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.
To solve the repudiation problem, some methodologies implement a traditional
protocol whereby, the sender includes a desired product and the sender's digital signature
in a first message and the recipient may use the digital signature as evidence of non-
repudiation of origin. The recipient retrieves the desired product 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. Since the tradition protocol cannot properly ensure non-repudiation of
receipt, the sender must somehow ensure that the recipient will always acknowledge
receipt ofthe message.
Some 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
verifies that each security requirement is fulfilled and that each party behaves
appropriately in order to prevent repudiation by both parties and to prevent other breaches
in security. Requiring the trusted third party to process all security requirements in each
transaction increases the costs associated with electronic commerce. 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.
Moreover, other problems exist with the current trusted third party scheme. In the
current scheme, the sender includes in the first message a product that is encrypted with a
session key and transmits the first message to the recipient. The recipient requests the
session key in order to decrypt the product in the first message. The sender transmits the
session key that is encrypted with the recipient's public key to the trusted third party.
The trusted third party thereafter transmits the session key to the recipient. However, a
corrupt recipient may wiretap the network during transmission ofthe session key to the
trusted third party. Since the session key is encrypted with the recipient's public key, the
recipient may decrypt the session key with the recipient's private key and then decrypt
the encrypted product with the intercepted session key. The corrupt recipient may later
repudiate the transaction and the sender has no way of proving that the recipient retrieved
the session key from the trusted third party. On the other hand, if the sender encrypts the
session key with the trusted third party's public key, while trusted third parties are usually
reputable organization, a corrupt trusted third party may decrypt the session key with it's
private 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
recipient to retrieve the key from the trusted third party, however, this solution is difficult
to achieve in asymmetric cryptography.
A co-pending United States applicationyz/e./ HEREWITH, titled, A Method for
Prohibiting Transacting Parties from Subsequently Repudiating an Executed Transaction
Without a trusted third party, and incorporated by reference, relates to a protocol that
does not have a trusted third party involved in the electronic transaction. In this protocol,
the sender sends to the recipient in the encrypted first message, a product that is
encrypted with the session key. The first message also includes the sender's digital
signature, but it does not include the session key. The encrypted first message is used as
evidence of non-repudiation of origin. A second message from the recipient requesting
the session key is used as evidence of non-repudiation of receipt. Thereafter, the sender
generates a third message containing the session key that is encrypted with the recipient's
public key. The sender stores the third message in a public key repository on the sender's
web site. The recipient is thereafter required to go to the sender's web site to retrieve the
third message. The sender maintains the key repository. By monitoring activity on the
sender's site, the sender can prove to the appropriate authorities during subsequent
repudiation by the recipient that the recipient retrieved the session key from the key
repository. This invention works well in a situation where the sender is trustworthy and
the recipient does not have to worry about repudiation by the sender.
However in a situation where repudiation by the sender is an issue, this invention
may 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
unscrupulous sender may publish the key after the required time and manipulate the time
stamp in the message with the session key to prove that the key was actually published on
time. Hence, when repudiation of origin and receipt is an issue, a protocol that does not
require one transacting party to rely on the trustworthiness of another transacting party is
required.
SUMMARY OF THE INVENTION
The present invention relates to a protocol for prohibiting non-repudiation by
transacting parties involved in an executed electronic transaction, whereby a trusted third
party is responsible for ensuring non-repudiation. In this protocol, a sender uses a secret
sharing technology to divide an original session key into a first sub-session key and a
second sub-session key. The first and second sub-session keys must be combined into the
original session key in order for a recipient to decrypt a product that is encrypted with the
original session key. The sender includes the first sub-session key that is encrypted with
a recipient's public key and an encrypted product in a first message. Then the sender
transmits the first message to the recipient. The recipient uses the first message as
evidence of non-repudiation of origin, i.e., evidence of non-repudiation that the sender
sent the transaction. The recipient transmits, to the sender, a second message requesting
the second sub-session key. The sender may use the second message as evidence of non-
repudiation of receipt, i.e., evidence of non-repudiation that the recipient received the
transaction. 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
the trusted third party. The trusted third party decrypts the third message to retrieve the
second sub-session key and then re-encrypts the second sub-session key with the
recipient's public key. The trusted third party includes the re-encrypted second sub-
session key in a fourth message and publishes the fourth message on the trusted third
party's web site where the recipient is responsible for retrieving it. This protocol
therefore ensures non-repudiation of origin and non-repudiation of receipt without
reliance on the trustworthiness of one or more transacting parties. Furthermore, by
involving the trusted third party in minimal transaction processing, i.e., only non-
repudiation processing, the responsibility and liability ofthe trusted third party is
reduced, thereby reducing the cost associated with trusted third parties in electronic
transactions.
Specifically in the preferred embodiment ofthe invention, the sender encrypts a
requested product with the session key and includes the encrypted product, the sender's
digital signature and the first sub-session key in the first message. Only the recipient can
decrypt the first sub-session key with the recipient's private key. In order to decrypt the
first message and retrieve the requested product, the recipient must also obtain the second
sub-session key. The recipient may use the encrypted first message with the first sub-
session key and the sender's digital signature as evidence of non-repudiation of origin.
When the recipient requests the second sub-session key with a message that includes the
recipient's digital signature, the sender may use the request message as evidence of non-
repudiation 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
third message. Thus, only the trusted third party can obtain the second sub-session key.
The trusted third party decrypts the third message in order to obtain the second sub-
session key. The trusted third party re-encrypts the second sub-session with the
recipient's public key and includes the re-encrypted second sub-session key in a fourth
message. The trusted third party publishes the fourth message in a key repository on
trusted third party's web site. Thereafter, only the recipient can decrypt the second sub-
session key with the recipient's private key.
The recipient is required to go to the trusted third party's web site to retrieve the
fourth message. Subsequently, the recipient combines the first and second sub-session
keys to form the original session key in order to decrypt the encrypted product in the first
message. The trusted third party maintains the key repository. By monitoring activity on
the trusted third party's site, the trusted third party can prove to the appropriate
authorities during subsequent repudiation by the recipient that the recipient retrieved the
second sub-session key from the key repository.
Additional features and advantages ofthe 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 ofthe invention. The objectives and advantages ofthe 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 ofthe
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 transacting parties using a trusted third party to resolve repudiation
disputes, the method comprising the steps of: generating, by a sending party, a session
key and dividing the session key into a plurality of sub-session keys comprising a first
sub-session key and a second sub-session key; sending, by the sending party to a
receiving party, a first cryptographic message, the first cryptographic message including a
product that is encrypted with the session key, a digital signature ofthe sending party,
and the first sub-session key; requesting upon receipt ofthe first cryptographic message,
by the receiving party from the sending party, the second sub-session key in a second
message, the second message including the receiving party digital signature; transmitting
upon receipt ofthe second message, from the sending party to a trusted third party, a third
cryptographic message with the second sub-session key, the second sub-session key
encrypted with the trusted third party's public key; obtaining, by the trusted third party,
the second sub-session key from the third cryptographic message and generating a fourth
cryptographic message; publishing, by the trusted third party, the fourth cryptographic
message on the trusted third party's web site; retrieving, by the receiving party, the fourth
cryptographic message from the trusted third party's web site; and combining, by the
receiving party, a predefined number ofthe plurality of sub-session keys into a required
session key in order to retrieve encrypted product from the first cryptographic message.
The invention alternatively provides a system for ensuring non-repudiation by
transacting parties involved in an executed electronic transaction, the transacting parties
using 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
plurality of sub-session keys comprising a first sub-session key and a second sub-session
key; means for sending, by the sending party to a receiving party, a first cryptographic
message, the first cryptographic message including a product that is encrypted with the
session key, a digital signature ofthe sending party, and the first sub-session key; means
for requesting upon receipt ofthe first cryptographic message, by the receiving party
from the sending party, the second sub-session key in a second message, the second
message including the receiving party digital signature; means for transmitting upon
receipt ofthe second message, from the sending party to a trusted third party, a third
cryptographic message with the second sub-session key, the second sub-session key
encrypted with the trusted third party's public key; means for obtaining, by the trusted
third party, the second sub-session key from the third cryptographic message and
generating a fourth cryptographic message; means for publishing, by the trusted third
party, the fourth cryptographic message on the trusted third party's web site; means for
retrieving, by the receiving party, the fourth cryptographic message from the trusted third
party's web site; and means for combining, by the receiving party, a predefined number
ofthe plurality of sub-session keys into a required session key in order to retrieve
encrypted product from the first cryptographic message.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are included to provide a further
understanding ofthe invention and are incorporated in and constitute a part of this specification, illustrate embodiments ofthe invention that together with the description
serve to explain the principles ofthe 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 secret sharing technology which enables a sender to divide a
session key into two keys;
Fig. 4 illustrates an alternate embodiment for dividing two session keys into two
sub-session keys;
Fig. 5 illustrates a preferred embodiment ofthe inventive non-repudiation
protocol; and
Fig. 6 illustrates the steps implemented according to the preferred embodiment of
the inventive non-repudiation protocol in Fig. 5; and
Fig. 7 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 ofthe present
invention, examples of which are illustrated in the accompanying drawings. The present
invention described below extends the functionality ofthe 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 typology 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 ofthe attached networks.
A browser application, such as Microsoft Explorer ™ or Netscape Internet
Browser ™, connects users on computer systems 104-110 to the World Wide Web (Web)
on 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 the 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. It is
apparent to those skilled in the art that other protocols may be used.
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, one transacting party may transmit a transaction to the
other transacting party through the displayed web page and the browser application. 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 a corresponding
web page and the buyer 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. During transmission, however, a third party may intercept the
transaction or the system may malfunction before all messages in the transaction are
submitted to the buyer.
To ensure that security requirements of confidentiality, integrity, authenticity and
authorization are fulfilled during each transmission, current encryption technologies are
implemented. However one ofthe transacting parties may later deny that the transaction actually occurred. For example, the buyer may subsequently deny receiving the already
delivered software application. Moreover, if there was a system malfunction, the
transmission ofthe software application to the buyer may be destroyed during the
malfunction and the seller may request payment for the undelivered software application
from the buyer. Thus, it is important that both the buyer and the seller have some
evidence of a properly executed transaction to prevent subsequent repudiation by either
party.
The present invention utilizes a secret sharing technology to prevent non-
repudiation of origin and receipt. Secret sharing is a key distribution mechanism whereby
multiple parties hold separate portions of a required key and a predefined number parties
must combine their portions for the required key to be recovered. Secret sharing
technology therefore ensures that the recipient of a product must obtain predefined part(s)
ofthe required key that encrypts a product, from the sender or a third party, in order for
the recipient to decrypt the product.
Fig. 3 illustrates a secret sharing technology that enables a sender to divide a
session key into two sub-session keys. As illustrated in Fig. 3, the sender generates an
original session key (K) and divides it into Kl 302 and K2 304 by using the following
formula:
Kl - (K + r*IDR) mod 264
K2 = (K + r*IDTTP) mod 264
Where r is a large random number generated by the sender; IDRis the recipient's
unique public identifier; and IDTTPis a trusted third party's unique public identifier. Fig. 4 illustrates an alternate embodiment for dividing two session keys into two
sub-session keys. Using two session keys in a secret sharing technology ensure stronger
security since a third party must obtain two keys in order to decrypt the desired product.
As illustrated in Fig. 4, the sender generates two original session keys (K and K') and
divides them into Kl 402 and K2 404 by using the following formula:
Kl = (K + K'*IDR) mod 264
K2 = (K + K'*IDTTP) mod 2 64
Where K and K' can be recreated by the recipient when he/she obtains Kl from
the sender and K2 from the trusted third party.
Fig. 5 illustrates a preferred embodiment of a non-repudiation protocol 500 where
the trusted third party addresses only non-repudiation issues, thereby minimizing the cost
associated with trusted third party processing. In protocol 500, sender 502 includes a
product that is encrypted with the session key in message 508 and transmits message 508
to the recipient. Message 508 also includes sender's 502 digital signature and first sub-
session key 302/402 that is encrypted with recipient's 504 public key. Recipient 504 may
decrypt first sub-session key 302/402 with recipient's private key. However, recipient
504 is required to obtain the second sub-session key 304/404 in order to decrypt message
508 and retrieve the encrypted product. In order to obtain second sub-session key
304/404, recipient 504 must acknowledge receipt of message 508 to sender 502. If
recipient 504 is no longer interested in encrypted message 508 after receiving it, recipient
504 is not required to request second sub-session key 304, and the protocol ends. If
recipient 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
fact that recipient 504 did not request second sub-session key 304/404. Sender 502 may
thereafter inquire why recipient 504 did not request the second sub-session key and may
re-send encrypted message 508 when the system malfunction no longer exists.
Recipient 504 may use encrypted message 508 as evidence of non-repudiation of
origin. Recipient 504 may request second sub-session key 304/404 from sender 502 in
message 510. Message 510 includes recipient's 504 digital signature and sender 502 may
use message 510 as evidence of non-repudiation of receipt. Upon receipt ofthe message
510, sender 502 encrypts second sub-session key 304/404 with a trusted third party's
public key and includes encrypted sub-session key 304/404 in message 512. Sender 502
thereafter transmits messages 512 to trusted third party 506 who is responsible for
resolving repudiation disputes between sender 502 and recipient 504.
Upon receipt of message 512, trusted third party 506 decrypts it with trusted third
party's private key to obtain second sub-session key 304/404. Trusted third party 506 re-
encrypts second sub-session key 304/404 with recipient's 504 public key. Then trusted
third party 506 includes the re-encrypted second sub-session key 304/404 in message 514
and publishes message 514 in trusted third party's public key repository. Thereafter only
recipient 504 can decrypt message 514 with recipient's private key. Recipient 504 and
sender 502 need to actively retrieve message 514 from the trusted third party's site by
using a persistent protocol such as HTTP or File Transfer Protocol (FTP). Recipient 504
then combines first and second sub-session keys 302/402 and 304/404 to retrieve the
original session key and decrypt the product in message 508. In this protocol, trusted third party 506 is responsible for taking care ofthe key
repository 518 and publishing second sub-session key 304/404. By tracking activity on
the trusted third party's site, trusted third party 506 can determine when recipient 504
retrieved second sub-session key 304/404. If recipient 504 later deny retrieving second
sub-session key304/404, trusted third party 506 can prove to the appropriate authority
that the key was actually published and retrieved. Moreover, if there is a dispute between
sender 502 and recipient 504 about proper transmission of the product, sender 502 can
transmit a fifth message with the first sub-session key 302/402 and the encrypted product
in dispute to trusted third party 506. Trusted third party can then verify whether there
was proper transmission from sender to recipient. Since trusted third party 506 is
generally a disinterested and reputable party, it is easier for trusted third party to resolve
disputes and repudiation issues.
Fig 6 illustrates the steps implemented in a preferred embodiment ofthe inventive
protocol. In Step 610 of protocol 500, sender 502 sends encrypted message 508 with
sender's 302 digital signature, the encrypted product and a first sub-session key to the
recipient. In Step 620, recipient 504 may use encrypted message 508 as evidence of non-
repudiation of origin. In Step 630, recipient 504 requests second sub-session key 304/404
from sender 502 in message 510 with recipient's 504 digital signature. Sender 502 may
then use message 510 as evidence of non-repudiation of receipt. In Step 640, upon
receipt of message 510, sender 502 transmits a third message 512 with the encrypted
second sub-session key to trusted third party. In Step 650, trusted third party 506
decrypts 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
party 506 publishes the fourth message 514 in the public key repository 518 on trusted
third party's 506 web site. In Step 660, recipient is responsible for retrieving fourth
message 514 from the key repository, and sender 502 and recipient 504 may use message
514 as evidence in any later case of repudiation dispute.
Fig. 7 illustrates a security architecture 700 in which the inventive protocol may
be practiced. At the base layer of security architecture 700 is a security hardware 702 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 704 and a public key
cryptography system 706 are built on security hardware 702 for providing additional
security. Cryptographic algorithms 708 are built on cryptographic systems 704 and 706.
The inventive non-repudiation protocol 710 and cryptographic protocols 712 are built on
cryptographic algorithms 708. Encryption algorithms and protocols 714a- 714d that
ensure confidentiality, integrity, authenticity and non-repudiation are built on
cryptographic protocols 712 and non-repudiation protocol 710. Security administration
716, which includes key management, authorization and management of access control
for a firewall and proxy server, is built on algorithms and protocol 714a-714d. HTTP 718
and S/MIME 720, the two most widely used protocols on the Web in electronic data
interchange, are also built on algorithms and protocols 714a-714d. A directory service
722, which implements a key distribution mechanism to distribute public keys in a
certificate authority 724, and certificate authority 724 are built upon security
administration 716 and on algorithms and protocols 714a-714d. Examples ofthe directory services include Microsoft Exchange™ directory, Lotus Notes™ directory, and
Novell Netware™ Directory Service. The next layer includes public key infrastructure
(PKI) 724, which is a comprehensive security infrastructure for enterprise-wide
applications. PKI 724 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 726, a standard making organization, is also in
the layer with PKI 724. The final layer includes non-EDI applications 728 and EDI
applications 730.
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 ofthe appended claims to cover all such variations
and modifications as come within the true spirit and scope ofthe invention.

Claims

WHAT IS CLAIMED:
1. A method for ensuring non-repudiation by transacting parties involved in an
executed electronic transaction, the transacting parties using a trusted third party to
resolve repudiation disputes, the method comprising the steps of:
generating, by a sending party, a session key and dividing the session key into a
plurality of sub-session keys comprising a first sub-session key and a second sub-session
key;
sending, by the sending party to a receiving party, a first cryptographic message,
the first cryptographic message including a product that is encrypted with the session key,
a digital signature ofthe sending party, and an encrypted first sub-session key;
requesting upon receipt ofthe first cryptographic message, by the receiving party
from the sending party, the second sub-session key in a second message, the second
message including the receiving party digital signature;
transmitting upon receipt ofthe second message, from the sending party to a
trusted third party, a third cryptographic message with the encrypted second sub-session
key, the second sub-session key encrypted with the trusted third party's public key;
obtaining, by the trusted third party, the second sub-session key from the third
cryptographic message and generating a fourth cryptographic message;
publishing, by the trusted third party, the fourth cryptographic message on the
trusted third party's web site;
retrieving, by the receiving party, the fourth cryptographic message from the
trusted third party's web site; and combining, by the receiving party, a predefined number ofthe plurality of sub-
session keys into a required session key in order to retrieve encrypted product from the
first cryptographic message.
2. The method of claim 1, comprising the step of using a plurality of keys as the
session key.
3. The method of claim 2, wherein the step of combining a predefined number of the
plurality of sub-session keys further comprising the step of combining the first and
second sub-session keys into the required session key in order to retrieve encrypted
product from the first cryptographic message.
4. The method of claim 3, wherein the step of obtaining further comprising the steps
of:
decrypting, by the trusted third party, the second sub-session key in the third
cryptographic message with the trusted third party's private key to obtain the second sub-
session key; and
re-encrypting, by the trusted third party, the second sub-session key with the
receiving party's public key and including the re-encrypting second sub-session key in
the fourth cryptographic message;
5. The method of claim 4, wherein the step of publishing further comprising the step
of storing, by the trusted third party, the fourth cryptographic message in a public key
repository on the trusted third party's web site.
6. The method of claim 5, further comprising the step of encrypting, by the sending
party, the first sub-session key in the first cryptographic message with the receiving
party's public key.
7. The method of claim 6, further comprising the step of decrypting, by the receiving
party, the first sub-session key in the first cryptographic message with the receiving
party's private key.
8. The method of claim 7, further comprising the step of requiring a predefine
number ofthe plurality of sub-session keys to retrieve information from the first
cryptographic message.
9. The method of claim 8, further comprising the step of requiring the first and
second sub-session keys to retrieve information from the first cryptographic message.
10. The method of claim 9, further comprising the step of using, by the receiving
party, the first cryptographic message as evidence of non-repudiation of origin.
11. The method of claim 10, further comprising the step of using, by the sending
party, the second cryptographic message as evidence of non-repudiation of receipt.
12. The method of claim 11 , further comprising the step of retrieving, by the
5 receiving and sending parties, the fourth cryptographic message from the trusted third
party's web site by using a persistent protocol.
13. The method of claim 12, further comprising the step of auditing, by the trusted
third party, the trusted third party's web site in order to determine when the receiving
10 party retrieves the fourth cryptographic message.
14. The method of claim 13, further comprising the step of proving, by the trusted
third party, receipt ofthe fourth cryptographic message by the receiving party through the
step of auditing.
1.5
15. The method of claim 14, further comprising the step of using the fourth
cryptographic message as evidence of non-repudiation of origin and receipt.
16. The method of claim 15, further comprising the step of sending, from the sending
0 party to the trusted third party, a fifth cryptographic message to resolve a repudiation
dispute between the sending party and the receiving party.
17. The method of claim 16, further comprising the step of including, by the sending
party, the encrypted first sub-session key and the encrypted product in the fifth
cryptographic message.
18. The method of claim 17 further comprising the step of verifying, by the trusted
third party, proper transmission ofthe encrypted first sub-session key and the encrypted
product from the sending party to the receiving party by using the fifth cryptographic
message, and then resolving repudiation dispute between the sending party and receiving
party.
19. The method of claim 18, further comprising the step of using hashing to create the
first, second, third, fourth and fifth cryptographic messages.
20. The method of claim 18, further comprising the step of using encryption to create
the first, second, third, fourth and fifth cryptographic messages.
21. The method of claim 18, further comprising the step of using encoding to create
the first, second, third, fourth and fifth cryptographic messages.
22. A system for ensuring non-repudiation by transacting parties involved in an
executed electronic transaction, the transacting parties using 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 plurality of sub-session keys comprising a first sub-session key and a second
sub-session key;
means for sending, by the sending party to a receiving party, a first cryptographic
message, the first cryptographic message including a product that is encrypted with the
session key, a digital signature ofthe sending party, and an encrypted first sub-session
key;
means for requesting upon receipt ofthe first cryptographic message, by the
receiving party from the sending party, the second sub-session key in a second message,
the second message including the receiving party's digital signature;
means for transmitting upon receipt ofthe second message, from the sending
party to a trusted third party, a third cryptographic message with the encrypted second
sub-session key, the second sub-session key encrypted with the trusted third party's
public key;
means for obtaining, by the trusted third party, the second sub-session key from
the third cryptographic message and generating a fourth cryptographic message;
means for publishing, by the trusted third party, the fourth cryptographic message
on the trusted third party's web site;
means for retrieving, by the receiving party, the fourth cryptographic message
from the trusted third party's web site; and means for combining, by the receiving party, a predefined number ofthe plurality
of sub-session keys into a required session key in order to retrieve encrypted product
from the first cryptographic message.
23. The method of claim 22, comprising means for using a plurality of keys as the
session key.
24. The method of claim 23, further comprising means for combining the first and
second sub-session keys into the required session key in order to retrieve encrypted
product from the first cryptographic message.
25. The method of claim 24, further comprising:
means for decrypting, by the trusted third party, the second sub-session key in the
third cryptographic message with the trusted third party's private key to obtain the second
sub-session key; and
means for re-encrypting, by the trusted third party, the second sub-session key
with the receiving party's public key and including the re-encrypted second sub-session
key in the fourth cryptographic message;
26. The method of claim 25, further comprising means for storing, by the trusted third
party, the fourth cryptographic message in a public key repository on the trusted third
party's web site.
27. The method of claim 26, further comprising means for encrypting, by the sending
party, the first sub-session key in the first cryptographic message with the receiving
party's public key.
28. The method of claim 27, further comprising means for decrypting, by the
receiving party, the encrypted first sub-session key in the first cryptographic message
with the receiving party's private key.
29. The method of claim 28, further comprising means for requiring a predefine
number ofthe plurality of sub-session keys to retrieve information from the first
cryptographic message.
30. The method of claim 29, further comprising means for requiring the first and
second sub-session keys to retrieve information from the first cryptographic message.
31. The method of claim 30, further comprising means for using, by the receiving
party, the first cryptographic message as evidence of non-repudiation of origin.
32. The method of claim 30, further comprising means for using, by the sending
party, the second cryptographic message as evidence of non-repudiation of receipt.
33. The method of claim 32, further comprising means for retrieving, by the receiving
and sending parties, the fourth cryptographic message from the trusted third party's web
site by using a persistent protocol.
34. The method of claim 33, further comprising means for auditing, by the trusted
third party, the trusted third party's web site in order to determine when the receiving
party retrieves the fourth cryptographic message.
35. The method of claim 34, further comprising means for proving, by the trusted
third party, receipt ofthe fourth cryptographic message by the receiving party through the
step of auditing.
36. The method of claim 35, further comprising means for using the fourth
cryptographic message as evidence of non-repudiation of origin and receipt.
37. The method of claim 36, further comprising means for sending, from the sending
party to the trusted third party, a fifth cryptographic message to resolve a repudiation
dispute between the sending party and the receiving party.
38. The method of claim 37, further comprising means for including, by the sending
party, the encrypted first sub-session key and the encrypted product in the fifth
cryptographic message.
39. The method of claim 38 further comprising means for verifying, by the trusted
third party, proper transmission ofthe encrypted first sub-session key and the encrypted
product from the sending party to the receiving party by using the fifth cryptographic
message, and then resolving repudiation dispute between the sending party and receiving
party.
40. The system of claim 39, further comprising means for using hashing to create the
first, second, third, fourth and fifth cryptographic messages.
41. The system of claim 39, further comprising means for using encryption to create
the first, second, third, fourth and fifth cryptographic messages.
42. The method of claim 39, further comprising means for using encoding to create
the first, second, third, fourth and fifth cryptographic messages.
PCT/US2000/027069 1999-10-01 2000-10-02 A method for non-repudiation using a trusted third party WO2001030016A2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CA002386502A CA2386502A1 (en) 1999-10-01 2000-10-02 A method for non-repudiation using a trusted third party
AU77451/00A AU7745100A (en) 1999-10-01 2000-10-02 A method for prohibiting transacting parties from subsequently repudiating an executed transaction with trusted third party

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US41100499A 1999-10-01 1999-10-01
US09/411,004 1999-10-01

Publications (2)

Publication Number Publication Date
WO2001030016A2 true WO2001030016A2 (en) 2001-04-26
WO2001030016A3 WO2001030016A3 (en) 2001-12-13

Family

ID=23627160

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/027069 WO2001030016A2 (en) 1999-10-01 2000-10-02 A method for non-repudiation using a trusted third party

Country Status (4)

Country Link
AU (1) AU7745100A (en)
CA (1) CA2386502A1 (en)
TW (1) TW545021B (en)
WO (1) WO2001030016A2 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001069843A2 (en) * 2000-03-10 2001-09-20 Absolutefuture, Inc. Method and system for coordinating secure transmission of information
WO2003107584A1 (en) * 2002-01-02 2003-12-24 Telefonaktiebolaget Lm Ericsson (Publ) Non-repudiation of service agreements
EP1495408A1 (en) * 2002-04-11 2005-01-12 Andrew Dominic Tune An information storage system
WO2007068668A3 (en) * 2005-12-16 2007-10-11 Ibm Cooperative non-repudiated message exchange in a network environment
US8726009B1 (en) * 2010-01-26 2014-05-13 David P. Cook Secure messaging using a trusted third party
KR101393159B1 (en) 2013-04-10 2014-05-30 숭실대학교산학협력단 Method and apparatus for controlling access based on key in social network service
CN104463451A (en) * 2014-11-28 2015-03-25 中国建设银行股份有限公司 Sales slip managing system and method
US9654294B2 (en) 2015-02-26 2017-05-16 Red Hat, Inc. Non-repudiable atomic commit
US9886573B2 (en) 2015-08-06 2018-02-06 Red Hat, Inc. Non-repudiation of broadcast messaging
US10228967B2 (en) 2016-06-01 2019-03-12 Red Hat, Inc. Non-repudiable transaction protocol

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008259077A (en) * 2007-04-06 2008-10-23 N-Crypt Lab Inc Transmission and reception system, transmitting device, receiving device, method performed by them, and program

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HERDA S: "Non-repudiation: Constituting evidence and proof in digital cooperation" COMPUTER STANDARDS AND INTERFACES,CH,ELSEVIER SEQUOIA. LAUSANNE, vol. 17, no. 1, 1995, pages 69-79, XP004046750 ISSN: 0920-5489 *
ZHOU J ET AL: "A FAIR NON-REPUDIATION PROTOCOL" PROCEEDINGS OF THE IEEE SYMPOSIUM ON SECURITY AND PRIVACY,US,LOS ALAMITOS, IEEE COMP. SOC. PRESS, vol. SYMP. 17, 6 May 1996 (1996-05-06), pages 55-61, XP000634833 ISBN: 0-7803-3527-9 *

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001069843A3 (en) * 2000-03-10 2003-11-06 Absolutefuture Inc Method and system for coordinating secure transmission of information
WO2001069843A2 (en) * 2000-03-10 2001-09-20 Absolutefuture, Inc. Method and system for coordinating secure transmission of information
WO2003107584A1 (en) * 2002-01-02 2003-12-24 Telefonaktiebolaget Lm Ericsson (Publ) Non-repudiation of service agreements
EP1495408A4 (en) * 2002-04-11 2010-04-07 Splitlock Holdings Pty Ltd An information storage system
EP1495408A1 (en) * 2002-04-11 2005-01-12 Andrew Dominic Tune An information storage system
EP2560101A3 (en) * 2002-04-11 2013-08-14 Splitlock Holdings Pty Ltd Information storage system
US8090953B2 (en) 2002-04-11 2012-01-03 Splitlock Holdings Pty Ltd. Information storage system
GB2403880B (en) * 2002-06-12 2005-11-09 Ericsson Telefon Ab L M Non-repudiation of service agreements
GB2403880A (en) * 2002-06-12 2005-01-12 Ericsson Telefon Ab L M Non-repudiation of service agreements
WO2007068668A3 (en) * 2005-12-16 2007-10-11 Ibm Cooperative non-repudiated message exchange in a network environment
US7568106B2 (en) 2005-12-16 2009-07-28 International Business Machines Corporation Cooperative non-repudiated message exchange in a network environment
US8726009B1 (en) * 2010-01-26 2014-05-13 David P. Cook Secure messaging using a trusted third party
KR101393159B1 (en) 2013-04-10 2014-05-30 숭실대학교산학협력단 Method and apparatus for controlling access based on key in social network service
CN104463451B (en) * 2014-11-28 2018-05-18 中国建设银行股份有限公司 A kind of sales slip management system and correlation technique
CN104463451A (en) * 2014-11-28 2015-03-25 中国建设银行股份有限公司 Sales slip managing system and method
US9654294B2 (en) 2015-02-26 2017-05-16 Red Hat, Inc. Non-repudiable atomic commit
US9886573B2 (en) 2015-08-06 2018-02-06 Red Hat, Inc. Non-repudiation of broadcast messaging
US10181025B2 (en) 2015-08-06 2019-01-15 Red Hat, Inc. Non-repudiation of broadcast messaging
US10783236B2 (en) 2015-08-06 2020-09-22 Red Hat, Inc. Non-repudiation of broadcast messaging
US10228967B2 (en) 2016-06-01 2019-03-12 Red Hat, Inc. Non-repudiable transaction protocol
US11150938B2 (en) 2016-06-01 2021-10-19 Red Hat, Inc. Non-repudiable transaction protocol

Also Published As

Publication number Publication date
TW545021B (en) 2003-08-01
WO2001030016A3 (en) 2001-12-13
CA2386502A1 (en) 2001-04-26
AU7745100A (en) 2001-04-30

Similar Documents

Publication Publication Date Title
US11477037B2 (en) Providing forward secrecy in a terminating SSL/TLS connection proxy using ephemeral Diffie-Hellman key exchange
US6988199B2 (en) Secure and reliable document delivery
US8370444B2 (en) Generating PKI email accounts on a web-based email system
US7305548B2 (en) Using atomic messaging to increase the security of transferring data across a network
US6061448A (en) Method and system for dynamic server document encryption
US8145898B2 (en) Encryption/decryption pay per use web service
US8145707B2 (en) Sending digitally signed emails via a web-based email system
JP2005517348A (en) A secure electronic messaging system that requires a key search to derive a decryption key
US20100195824A1 (en) Method and Apparatus for Dynamic Generation of Symmetric Encryption Keys and Exchange of Dynamic Symmetric Key Infrastructure
US20050182937A1 (en) Method and system for sending secure messages over an unsecured network
EP1228462A2 (en) Ephemeral decryptability
US8352742B2 (en) Receiving encrypted emails via a web-based email system
US20070288746A1 (en) Method of providing key containers
WO2002093405A2 (en) Method and device for transmitting an electronic message
EP1493243B1 (en) Secure file transfer
US20060095770A1 (en) Method of establishing a secure e-mail transmission link
Gritzalis et al. A digital seal solution for deploying trust on commercial transactions
US7171000B1 (en) Simplified addressing for private communications
WO2001030016A2 (en) A method for non-repudiation using a trusted third party
WO2001025883A2 (en) A method for preventing repudiation of an executed transaction without a trusted third party
WO2002021793A2 (en) System and method for encrypted message interchange
WO2003081840A1 (en) Method and system relating to a non-repudiation message exchange
Spinellis et al. Deploying a Secure Cyberbazaar by adding Trust on Commercial Transactions
is HTTP VI How secure is the Encryption
Oberholster An audit model for the analysis and evaluation of encryption with reference to RSA

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ 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 UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

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 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)
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ 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 UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

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 BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 2386502

Country of ref document: CA

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP