WO2003081840A1

WO2003081840A1 - Method and system relating to a non-repudiation message exchange

Info

Publication number: WO2003081840A1
Application number: PCT/GB2003/000965
Authority: WO
Inventors: Melih Abdulhayoglu
Original assignee: Melih Abdulhayoglu
Priority date: 2002-03-19
Filing date: 2003-03-07
Publication date: 2003-10-02
Also published as: AU2003214390A1; GB0206429D0

Abstract

There is disclosed a communication method comprising a sender (A) sending to a recipient (B) a digital communication (M) encrypted with an encryption for which there is a release key (Kr) and a message identifier, the recipient communicating the message identifier to a third party (T), the third party verifying the message identifier and communicating the release key (Kr) to the recipient for the recipient to decrypt the encrypted digital communication (Kr(M)).

Description

METHOD AND SYSTEM RELATING TO A NON-REPUDIATION MESSAGE EXCHANGE

Field of the Invention

The present invention relates to methods of communication and to communication systems.

Background to the Invention

In this specification the following terminology is used:

M represents an original message.

H represents a one way digest function such as a hash. Where different hash functions are used, these are distinguished as HI, H2 etc. For convenience the one-way digest functions are agreed between the parties.

Kr represents a release key used to decrypt an encrypted message M. Often this will also be the encryption key.

K represents a symmetric key. Kl is a first symmetric key, K2 a second symmetric key etc.

Xpk represents a public key using user X's key.

Xsk represents a private key using user X's key.

Xsig (M) is X's digital signature of message M ie Xsk(H(M) ) .

A is a message originator/sender. B is a message recipient.

T is a third party trusted transaction authority.

R is a transaction record.

Thus:

K(M) is a message encrypted using a key K.

Bpk (Asi (K( ) ) ) is a message encrypted using a key K, taking a hash of K(M) , which is further encrypted using a secret key of A and finally encrypted using a public key of B.

For transactions, especially business-to-business transactions, to become common over the internet, in particular financial transactions, a certified message delivery system is essential.

To fulfil all the needs of a certified delivery, any such method and system should have the following properties:

1. A sender (A) must have some way of proving that a recipient (B) received the message, should B later try to deny it .

2. B must have some way of proving that B could not read the message, should A later try to claim that B could do so. In some methods and systems it is enough for just one of the criteria to be satisfied.

A certified e-mail delivery communication method and system is suggested in "A Certified E-mail Protocol" by Bruce Schneier and James Riordan available at www. counterpane . com/certified-email .pdf .

According to this protocol A chooses a random key Kr and sends to B the encrypted message Kr (M) . B sends to A a digitally signed message requesting A to publish the key for the received encrypted message, the hash of which is H(Kr(M)) by date D at location , which is a public record. A publishes the pair H(Kr(M)) and Kr in L on or before date D. B retrieves the key, Kr from L and decrypts the message.

Typically, location L will be a newspaper, _.a world-wide web kiosk service or a Usenet newsgroup.

This method has the disadvantages that it involves an unnecessary number of process steps, B has to break the method to refuse delivery and the use of a public location for key release storage is potentially unreliable.

It is an aim of preferred embodiments of the preferred embodiments of the present invention to obviate or overcome a problem of the prior art, whether refused to herein or otherwise. Summary of the Invention

According to the present invention in a first aspect, there is provided a communication method comprising a sender (A) sending to a recipient (B) a digital communication (M) encrypted with an encryption for which there is a release key (Kr) and a message identifier, the recipient communicating the message identifier to a third party (T) , the third party verifying the message identifier and communicating the release key (Kr) to the recipient for the recipient to decrypt the encrypted digital communication (Kr(M)).

Suitably, the release key is generated as a session key.

Suitably, the message identifier comprises a one-way function of predetermined data, which suitably is at least part of the encrypted message.

Suitably, the message identifier is encrypted.

Suitably, the message identifier sent from A to B is encrypted by a session key (K2) and the session key is communicated to B encrypted by B's public key (Bpk(K2)) .

Suitably, the communication from A to B includes a digital signature from A. Suitably the digital signature comprises Ask(H(K2)).

Suitably, A communicates the message identifier to T in encrypted form. Suitably, A communicates to T Ask(H (Kr (M) ) ) . Suitably, A' s communication to T comprises a digital signature. Suitably, the digital signature comprises Ask(H(Kl)). Suitably, A communicates Tpk(Kl) to T.

Suitably, the message identifier sent from B to T is generated by an operation carried out on the communication received by B from A. Suitably, the message identifier sent from A to B comprises Hl(Kr(M)) . Suitably, the message identifier sent from B to T comprises H2(Kr( ) wherein H1≠H2.

Suitably, A communicates the release key (Kr) to T. Suitably, the communication of Kr is encrypted. Suitably, A communicates to T Bpk(Kr) . Suitably, A communicates to T Kl(Bpk(Kr) ) .

Suitably, B communicates a message identifier to T with a digital signature. Suitably, the digital signature comprises Bsk(H (Kr (M) ) ) .

Suitably, T communicates to B Bpk(Kr) . Suitably T communicates to B Bpk(Kr) .

Suitably, A communicates a message identifier to a transaction record. Suitably, B communicates a message identifier to a transaction record. Suitably, T communicates the encryption key (Kr) to a transaction record. Suitably, T communicates an encrypted version of the encryption key to the transaction record. Suitably, the message identifier used between A and B differs from that used between A and T and B and T. Suitably, the message identifier used between A and T corresponds to that used between B and T. Suitably, H(Kr(M)) is the message identifier, which is generated by B .

It is noted that B cannot pass on the message identifier to T without some intervention on B's behalf.

If A does not know B's public key (Bpk), A transmits simply the encrypted message (Kr(M)) and the message identifier. This is not as secure as the embodiments in which A knows Bpk, since a third party obtaining Kr could decrypt the message, but is a satisfactory compromise for many applications.

Suitably, the transaction record is time stamped to produce a time stamp record. Suitably, the time stamp record is published.

According to the present invention in a second aspect, there is provided a communication system comprising a senders computer node, a recipients computer node and a third party computer node, which computer nodes are in communication via a distributed electronic network and configured to operate according to the method of the first aspect of the invention.

The message (M) may be data in any form eg financial or database data, as well as letters.

It will be appreciated by those skilled in the art that the steps need not all be carried out in the order set out above . Preferred embodiments of the present invention rely on a public key infrastructure (PKI) , such as RSA, and a recognised digest function such as a hash. The hash is a one-way function.

Brief Description of the Drawings

The present invention will now be described, by way of example only, with reference to the drawings that follow, in which:

Figure 1 shows a schematic functional illustration of a protocol, method and system according to an embodiment of the present invention; and

Figure 2 shows a schematic functional illustration of a protocol, method and system according to a second embodiment of the present invention.

Figure 3 shows a schematic functional illustration of a protocol, method and system according to another embodiment of the present invention.

Description of Preferred Embodiments

A sender referred to as Alice (A) wishes to send to Bob, a recipient (B) a digital message (M) . Trent (T) is used as a trusted third party. The operations of A, B and T are carried out on respective computer nodes 2, 4, 6 connected by a distributed electronic network such as the internet. T maintains a TCP/IP server at computer node 6, typically using an ORACLE (trade mark) database. The database provides user, account, financial, configuration and transaction details to the transaction server 6.

The operations on computer nodes 2, 4, 6 are carried out automatically by software thereon. A given user may set options within the software enabling them to have the opportunity to refuse to accept communications and/or to authorise the onward transmission of data.

In this first embodiment of the present invention, illustrated in Figure 1 of the drawings that follow it is assumed that A knows B's public key.

Typically, the digital message will be an e-mail message.

Step 1

In step 1, A transmits to T a message packet comprising:

la. Kl(Bpk(Kr), Ask (HI (Kr (M) ) , skHl (Kr) ) ) . Thus, A sends to T a session key (Kl) encrypted sub-packet message including the release key (Kr) for the message (M) , encrypted by B's public key and Kl, and a digital signature (AskHl (Kr (M) ) ) of the encrypted message (Kr(M)) . A also sends T a digital signature of Kr for verification purposes.

lb. A sends to T Tpk(Kl) to enable T to decrypt Kl therefrom using Tsk, thereby enabling T to decrypt message sub-packet la.

lc. A transmits to T Ask(Hl(Kl)), ie a digital signature of Kl . Thus, when T has decrypted Kl from step IB above, T can verify A as the source of the communication by verifying the digital signature of this step lc.

Step 2

A sends to B a message packet comprising the following elements :

2a. A sends to B K2(Kr(M), H2(Kr(M)), H2 (Kr) ) . Thus, B has the encrypted message (Kr(M)), but needs the encryption key K2 to obtain Kr (M) and release key Kr to obtain the message M.

2b. A sends to B Bpk(K2) thus enabling B with its secret key Bsk to obtain K2 , thereby enabling it access to Kr(M), to H2(Kr(M)) and to H2 (Kr) . B can use H2(Kr(M)) -from step 2a- to verify the integrity of the received Kr(M) .

2c. A sends to B Ask(H2(K2)) as a digital signature hash of K2 enabling B to verify that the message originates from A.

Step 3

A sends to a transaction record (R) the following message:

3a. A sends to R Ask (HI (Kr (M) ) ) , As (Hl (Kr) ) . The transaction record can, therefore, using A' s public key Apk obtain Hl(Kr(M)) and HI (Kr) as message identifiers and also by deriving this from use of A' s public key Apk, R (or anyone checking R) can verify that this originates from A.

Step 4

4a. B generates Hl(Kr(M) from the decrypted Kr (M) . If necessary information about which hash to use can be communicated to B via an open channel . B sends to T a message packet consisting of Bsk (HI (Kr (M) ) ) . Thus using B's public key (Bpk) T can obtain the message identifier Hl(Kr(M)).

4b. B also transmits to T Bsk(Hl (Kr) ) to T as a Kr verification.

Step 5

T first verifies that the Hl(Kr(M)) received from A matches the Hl(Kr(M)) received from B. Only if the two match does T proceed as follows:

T sends to B a message packet comprising the following elements :

5a. T sends to B Bpk(Kr).

5b. T sends to BTskHl (Bpk (Kr) ) .

Thus, B can use its own secret key (Bsk) to obtain the release key (Kr) , which release key can be used to decrypt the encrypted message (Kr(M)) to obtain the original message (M) . B can verify the release key is correct by generating H2 (Kr) and comparing that with the H2 (Kr) received originally from A.

B can use Tsk (HI (Bpk (Kr) ) as a verifier.

If A and B's supposed Hl(Kr(M)) messages do not match, B is informed that it cannot be sent the decryption key.

Step 6

6a. B sends Bsk (HI (Kr (M) ) ) to the transaction record R.

6b. B sends Bsk HI (Kr) ) to the transaction record R.

Thus the transaction record can verify that it has received from both A and B message identifiers in digested hash form. B can only have obtained the hash digests from A which confirms both B's receipt of the message and A's transmission thereof.

Step 7

7a. T sends to the transaction record Bpk(Kr) .

If A wishes to prove that B received the message M, A can refer to the transaction record showing B has sent Hl(Kr(M)) to R, B can only have generated Hl(Kr(M)) if he has received Kr(M) . A can also show B was able to read Kr (M) because B has sent HI (Kr) to R, and B can only have generated Hl(Kr) if he has received Kr. The fact that Hl(Kr(M)) and HI (Kr) are both encrypted by Bsk shows they can only have been sent by B. The message M can be validated to A by virtue of A's transmission to R of Ask (Hl(Kr(M)), Hl(Kr)). Without this data in the transaction record, B can deny readability of message M.

Referring to Figure 2 of the drawings that follow, there is shown a further embodiment of the present invention in which it is assumed that A knows B's public key.

The embodiment illustrated in Figure 2 is similar to that shown in Figure 1 (and so a further detailed description is not included) apart from the fundamental difference that B is not sent any hash of Kr(M) at all. In this way the hashes used throughout the protocol can remain unchanged. Thus, in this embodiment H1=H2. As a message verifier Asig (Transaction) is sent from A to B, where Transaction is the remainder of the step 2 communication.

It is noted that B must generate Kr (M) itself.

Referring to Figure 3 of the drawings that follow, the method and system of communication is shown for the case in which the sender A does not know the recipient (B) certificate .

Step 1

la. A sends to T Kl (Kr, Asig(Kr(M)), Asig (HI (Kr) ) .

lb. A sends to T Tpk(Kl) . Thus T can obtain Kl, giving it access to Kr, Ask (HI (Kr (M) ) ) and Ask (HI (Kr) ) .

lc. A sends to T Asig(Kl) . Thus T can both verify the integrity of the transmitted Kl and confirm that the message originates with A. Step 2

2a. A sends to B the encrypted message Kr (M) .

2b. A sends to B Asig(Kr(M. Using Apk, B can generate H (Kr) .

2c. A sends to B Asig (Transaction) as a message verifier.

Step 3

3a. A sends to the transaction record R a message consisting of: Asig(Kr( ), Asig(Kr)).

Step 4

From Kr(M), B generates Hl(Kr(M)) .

4a. B transmits to T: Bsig (Kr (M) ) .

4b. B transmits to T Bsig(Kr) as a verifier.

Step 5

T first confirms that the H (Kr(M)) received from B, having been decrypted using Bpk, matches the H (Kr(M)) received from A in step 1 above. If so:

5a. T transmits to B Bpk(Kr) . B can use Bsk to obtain Kr which in turn it can use to decrypt Kr(M) .

5b. T transmits Tsi (Bpk (Kr) ) as a verifier. Step 6

6a. B transmits to R Bsig(Kr(M), Bsig(Kr)) to enable message verification.

Step 7

T transmits to R Kr. Optionally Kr may be encrypted using A or B's public key, or another agreed encryption.

Verification is carried out as for the Figure 1 embodiment .

The method of Figure 3 can also be used in the situation in which B originally does not have a certificate but upon receipt of the original message from A can obtain a certificate for use in the subsequent steps of the method.

In both cases, there is an additional verification step in that if B seeks to interfere with step 6, A can use T to show that B transmitted to T in step 4 Hl(Kr(M)) which it could only have obtained from Kr (M) received from A and T can show that it transmitted a receivable version of Kr to B.

As a final step in either method a time stamp of the transaction record can be generated to enable verification of the transaction record.

It is noted that in a typical embodiment A, B, T and R will be computer nodes and that some or all of the steps 1-7 may be automated thereby. Normally, the transaction record will be at and controlled by T, a trusted third party or certification authority. It can, however, be maintained by another party (not A, B or T) .

The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

All of the features disclosed in this specification (including any accompanying claims, abstract and drawings) , and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) , may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

The invention is not restricted to the details of the foregoing embodiment (s) . The invention extend to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings) , or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

1. A communication method comprising a sender (A) sending to a recipient (B) a digital communication (M) encrypted with an encryption for which there is a release key (Kr) and a message identifier, the recipient communicating the message identifier to a third party (T) , the third party verifying the message identifier and communicating the release key (Kr) to the recipient for the recipient to decrypt the encrypted digital communication (Kr(M)).

2. A communication method as claimed in claim 1, wherein the release key is generated as a session key.

A communication method as claimed in claim 1 or claim 2, wherein the message identifier comprises a one-way function of predetermined data, which suitably is at least part of the encrypted message.

A communication method as claimed in any preceding claim, wherein the message identifier is encrypted.

5. A communication method as claimed in claim 4, wherein the message identifier sent from A to B is encrypted by a session key (K2) and the session key is communicated to B encrypted by B's public key (Bpk(K2)) .

6. A communication method as claimed in any preceding claim, wherein the communication from A to B includes a digital signature from A.

7. A communication method as claimed in claim 6, wherein the digital signature comprises Ask(H(K2)).

8. A communication method as claimed in any preceding claim, wherein A communicates the message identifier to T in encrypted form.

9. A communication method as claimed in claim 8, wherein A communicates to T Ask (H (Kr (M) ) ) .

10. A communication method as claimed in any preceding claim, wherein A's communication to T comprises a digital signature.

11. A communication method as claimed in claim 10, wherein the digital signature comprises Ask(H(Kl)).

12. A communication method as claimed in any preceding claim, wherein A communicates Tpk(Kl) to T.

13. A communication method as claimed in any preceding claim, wherein the message identifier sent from B to T is generated by an operation carried out on the communication received by B from A.

14. A communication method as claimed in claim 13, wherein the message identifier sent from A to B comprises Hl(Kr(M) ) .

15. A communication method as claimed in claim 14, wherein the message identifier sent from B to T comprises H2(Kr(M) wherein H1≠H2.

16. A communication method as claimed in any preceding claim, wherein A communicates the release key (Kr) to T.

17. A communication method as claimed in claim 16, wherein the communication of Kr is encrypted.

18. A communication method as claimed in claim 17, wherein A communicates to T Bpk(Kr) .

19. A communication method as claimed in claim 17, wherein A communicates to T Kl(Bpk(Kr)) .

20. A communication method as claimed in any preceding claim, wherein B communicates a message identifier to T with a digital signature.

21. A communication method as claimed in claim 20, wherein the digital signature comprises Bsk (H (Kr (M) ) ) .

22. A communication method as claimed in any preceding claim, wherein T communicates to B Bpk(Kr) .

23. A communication method as claimed in claim 22, wherein T communicates to B Bpk(Kr) .

24. A communication method as claimed in any preceding claim, wherein A communicates a message identifier to a transaction record.

25. A communication method as claimed in any preceding claim, wherein B communicates a message identifier to a transaction record.

26. A communication method as claimed in any preceding claim, wherein T communicates the encryption key (Kr) to a transaction record.

27. A communication method as claimed in claim 26, wherein T communicates an encrypted version of the encryption key to the transaction record.

28. A communication method as claimed in any preceding claim, wherein the message identifier used between A and B differs from that used between A and T and B and T.

29. A communication method as claimed in any one of preceding claims 1 to 27, wherein the message identifier used between A and T corresponds to that used between B and T.

30. A communication method as claimed in any preceding claim, wherein H(Kr(M)) is the message identifier, which is generated by B.

31. A communication method as claimed in any preceding claim, wherein the transaction record is time stamped to produce a time stamp record.

32. A communication method as claimed in claim 31, wherein the time stamp record is published.

3. A communication system comprising a senders computer node, a recipients computer node and a third party computer node, which computer nodes are in communication via a distributed electronic network and configured to operate according to any one of claims 1 to 32.