WO2003001734A1

WO2003001734A1 - Secure digital communication protocols

Info

Publication number: WO2003001734A1
Application number: PCT/ZA2002/000077
Authority: WO
Inventors: Valentin Kisimov
Original assignee: Valentin Kisimov
Priority date: 2001-06-26
Filing date: 2002-05-16
Publication date: 2003-01-03

Abstract

The invention provides a method of ensuring the integrity and high-security of a message sent from a sender to a receiver, confirming the receipt of the message, approving the exact received content of the message by the receiver to the sender and giving a decision point to the sender to accept or not that the message was sent securely and reliably. Transaction history value is used as a parameter of each message converting the communication protocol into a stateful protocol. The method provides unbreakability of the message content and unrepeatablity of each sent message. A distinctive aspect of the method enhances the security through a protocol, called 'two-message commit protocol with confirmed non-repudiation'. Enforced multi-dimensional factor authentication is used for authentication of the sender to a particular receiver and vice versa.

Description

SECURE DIGITAL COMMUNICATION PROTOCOLS

TECHNICAL FIELD:

This invention relates to a system for secure digital communication protocols, particularly though not exclusively for conducting financial transactions, for use over public network, such as the Internet.

BACKGROUND ART:

It is known to use digital communication for financial transactions over public networks. While security systems or protocols, such as SSL, may be implemented and some security mechanism is done, such as data encryption, these are usually of a low level, insufficient or limited in scope in practice, mostly without authentication of the card, card user or the transaction. Thus it is uncommon for a financial institution, such as a bank, credit card issuer, mutual fund, stock broker and the like, to reverse a transaction and at least initially impose liability on the supplier or customer. As a result the value and volume of the financial transactions are limited, largely by customer resistance. Nevertheless, a strong desire for increasing the use of digital financial systems by financial institutions, their and customers generally still remains, subject to adequate assurance on security, control and protection.

It is also known that so called "smart device" can be used for increasing security and authentication. The term "smart device" means smart cards, smart tokens, SIM cards in pervasive devices and the like that include a processor, non-volatile memory (e.g. ROM, EEPROM, minidisk) and optionally volatile memory (RAM), and an operating system, that can store and process data. Smart devices, while being capable of being used for more functions and on a wider scale, are currently limited in use to identification, authorisation and storing information.

It is also known for authenticating the parties to a communication to each other and for encrypting the data transmitted between them, such as using the 3DES algorithm, for a communication initiator/sender to generate a random number and send this to a receiver encrypted by the delivered by the receiver public key of the receiver, for the receiver to generate a second random number and send this to a sender encrypted by the public key of the sender and for the parties to encrypt data in subsequent messages using a function of the two random numbers. However, other than for passing identification data, such as PIN's and/or passwords at or prior to initiating a "secure" communication channel, neither the sender nor the receiver has confirmation of the other's identity (authentication), or of the receipt of a message/data by the other party, or that a received message has been received intact.

Thus one aspect of this invention seeks to provide a system for implementing secure digital communication protocols suitable for use in transactions over a public network, particularly the Internet.

Another aspect seeks to provide a communication system wherein the receiver of a message has confirmation of the sender's identity (authentication); and/or the sender has confirmation of the receipt of the message (confirmed non- repudiation); and/or there is confirmation to at least one of the sender and the receiver that a message has been received intact.

DISCLOSURE OF THE INVENTION

In the following, typically the party applying or causing the method to be performed would be a financial institution, which may either activate the method when the communication is initiated or is in progress or provide a customer with a suitable program for a smart device or a suitably programmed smart device.

One aspect of the invention provides a method of ensuring the integrity of a message sent from a sender to a receiver, confirming receipt of the message by the receiver to the sender, and authenticating the sender and receiver to each other including the steps of:

• sending from the sender to the receiver a message, comprising first and second data elements with the second data element being a function of the first data element and of the transaction history;

• at the receiver, creating a respective second data element from the received first data element using the same function over that first data element as the sender for generation of second data element and using the transaction history at the receiver, and comparing the respective second data element with the second data element received from the sender, in order to ensure unrepeatability of the message, the integrity of the message and sender's authentication; • sending from the receiver to the sender a return message, comprising third, forth and fifth data elements with the forth data element being a function of the third data element and of the transaction history; and

• at the sender, analysing the return message including comparing parts that are respectively representative of the third and forth data elements and in order to obtain confirmation of correct receipt of the first message, unrepeatability of the confirmation, and the receiver's authentication.

The use of transaction history as a parameter of each message converts the communication protocol into a stateful protocol. The transaction history may vary between empty set and a complex function using the content or a portion of the content of each previous message.

The first and second data elements are compared at the receiver applying to the received first data element a function corresponding to the function applied by the sender using the transaction history stored at the receiver. The third and forth data elements are compared in a similar fashion using transaction history stored at the sender.

The fifth data element has a predefined portion of the first data element in order to confirm the integrity between sent and returned message.

The first data element is or includes the information that is to be sent. Preferably the third data element contains information confirming receipt of the first message.

In the art "hash" means processing data to produce a result of "hash value" that cannot be reverse engineered to determine the original data or the algorithm used. "Hash function" refers to a programme or algorithm used to produce the "hash value". Preferably the functions used to generate the second and forth data elements are hash functions. The hash functions may be the same or may differ from each other.

Preferably each message is digitally signed. Preferably each of the messages is encrypted. Preferably each of the first and second data elements are physically separated from each other in separate physical messages, separately digitally signed and/or separately encrypted.

The method may include authenticating the sender and receiver of the messages to each other by including the steps of:

• using the digital signature of the sender in generation of the second data element from the first data element and encrypted by sender's dedicated receiver's public key in order to authenticate the sender to the particular receiver; and

• using the digital signature of the receiver in generation of the fourth data element from the third data element and encrypted by sender's public key in order to authenticate the receiver to the particular sender;

• using part of the first data element which comprises information signed by the sender and including sender's application data and content, which information is understandable only by the sender's dedicated receiver, to generate the fifth data element in order to mutually authenticate the sender being a person with smart device or an application from one side and the receive from the other side as reliable session partner.

The sender's application data can be application data, secure PIN's biometrics data, logical expressions, family knowledge, etc.

Another aspect of the invention provides a method of communicating securely between two parties, one of which is a sender and the other of which is a receiver for each message which includes a first data element to be sent from the sender to the receiver, including the steps of:

• storing a first value at the receiver and the sender;

• at the sender, generating a temporary second value as a function of the first stored value and the first data element;

• at the sender, generating a second data element as a function of the first data element and the temporary stored second value and sending the first and second data elements;

• at the receiver, performing the same function as in the sender over the received first data element and the stored at the receiver first value performing second data element;

• at the receiver, comparing the performed send data element with the received from the sender second dafa element; • at the receiver, if the comparison between the performing second data element and received second data element is favourable, generation a second value as a function of the first data element received from the sender and from the first value stored at the receiver, using the same function as in the sender;

• at the receiver, if the comparison between the performing second data element and received second data element is favourable, generation a return data element as a function of the second value and first data element; • at the sender, comparing the return data element with a function of the first data element and the temporary second value in order to confirm that the temporary second value is the same as the second value at the receiver, authenticate the receiver to the sender and verify the integrity of the sent and return messages; • storing the temporary second value at the sender for use in the next message.

The development enables generating and storing valid, i.e. identical transaction history values at each of the parties, authenticating the parties to each other, verifying the integrity of each sent message, and securing the communication between the parties. Each transaction history value is dependent of the content of the message exchanged between the parties and of the previous value of the transaction history.

The stored values are clearly variable and substantially unique as they depend on the content of each message and the previous stored value and represent transaction state value (TSV). Using these values in a manner described above makes the communication protocol "stateful" i.e. each communication is dependent on a previous communication.

Accordingly a development of this aspect of the invention provides a method of communication using a stateful protocol, wherein each communication comprises:, sending a message receiving, processing and sending a return message; and analysing the messages, with the content of each sent message being determined by a stored value from a previous communication and the content of the current message. The authentication, identification and confirmation methods described above may be combined for each sent message.

Yet another aspect of the invention provides a method for creating high-level transactional security between two parties communication with each other over a public network using a communication protocol, including the steps by at least one of the parties of:

• activating application or programmable level protocol for at least one of high-level authentication of each of the parties to the other party and of high-level encryption of data transmitted between the parties; and

• introducing an application programming interface (API) between the communication protocol and the application level protocol so that the high-level protocols can be carried by the communication protocol.

The communication protocol may be that known as "Secure Socket Layer (SSL)" or another accepted public network security protocol. This secure protocol provides a first relatively low level of security and the API extends the security to a higher level by providing a further level of authentication and/or encryption over the first level of security.

The communication protocol needs not be a security protocol; it may be any suitable protocol, such as TCP/IP, with the API providing security to the communication protocol.

Further features and aspects of the invention are set out in the claims.

Further features, variants and/or advantages of aspects of the invention will emerge from the following non-limiting description of examples of the invention made with reference to the accompanying schematic drawings.

BRIEF DESCRIPTION OF THE DRAWINGS:

Figure 1 shows a processing structure for creating high-level security and authentication mechanisms and protocols for secure public network communication transactions;

Figure 2 shows a schematic implementation of the structure of Figure 1 in combination with a smart device; Figure 3 shows a processing structure for achieving application level authentication as a part of the high-level authentication of Figure 2; and

Figure 4 shows a programming architecture for achieving a two-message commit, transactional stateful protocol with confirmed non-repudiation.

BEST KNOWN MODE FOR CARRYING OUT THE INVENTION: In the drawings the same or similar parts have the same reference numbers, certain parts having sub-numbers to identify them as part of a component or as substantially equivalent parts in different embodiments.

Figure 1 shows a schematic implementation or program structure 10 for creating high-level security mechanisms and protocols for Internet transactions, comprising a standard communication protocol module 12, such as the known SSL protocol and which for simplicity is referred to hereinafter as "SSL", an application programming interface (API) 14 for the SSL protocol (i.e. "SSL- API") and an application security level processor 16 including a high-level authentication module 16.1 and a high-secure transaction protocol 16.2.

The implementation adds new security and reliability to the known communication protocol. The communication protocol has some security and authentication capabilities, but these are generally regarded as incomplete or vulnerable for secure financial transactions over a public network, such as the Internet. The SSL-API ensures that the SSL protocol is extended with a higher layer called "application SSL protocol". The proposed application SSL protocol in accordance with an aspect of this invention changes the nature of the SSL protocol to make it a stateful protocol, which amongst other things provides the benefits of recording transactions so they cannot subsequently be replayed. An easy way to execute the proposed approach is to use Java realisation with Java based SSL- API.

Figure 2 and 3 are used to explain a three level authentication with smart device (which for simplicity is called "smart card"), supporting the high-level authentication mechanism. Figure 2 shows a three layered authentication and security mechanism 20. The communication protocol 12 authentication providing a first layer authentication. The smart card 22 to hard-holder authentication provides a second layer authentication including card-holder authentication 22.1 and card-holder credentials 22.2. The high-level authentication - third layer authentication, is between the smart card 22 and the high-authentication application module 16.1, which is the application layer authentication. Using this system, the card-holder or user can be uniquely authenticated for enabling the using of the smart card security capabilities for creation of the third level authentication over a public network communication. The low-level authentication normally uses digital certificates entry level. The user is authenticated to the card through his/her credentials, one or more PINs, optionally biometrics (such as fingerprint), and the like as are known, proposed or may be developed. In other words, the second layer authentication is an authentication of the card-holder to the card. The third layer authentication is between the user's smart card and a target server, such as a financial institution server. Appropriate information should exist in the user's smart card and a target server to support the second and third layer authentication.

Ideally, but not necessarily all of, the following information should exist in the user's smart card - this information is not only for authentication, but for the entire security including encryption: • card number; user number; major user's PIN; a few additional secondary user's PINs; major user's biometrics (such as fingerprint of one of the user's finger); a few additionally secondary user's biometrics; master key pairs; key pairs for encryption; key pairs for signing; key pairs for TSV signing; symmetrical encryption key second level such as Blowfish; the financial institution's public key; a stored procedure for level of concatenation for creation of one or more further keys such as 3DES keys.

The TSV is with varying length, is optionally 16 to 20 byte long and its value is changed at the end of each transaction or communication session. The new value of the transaction state is defined from the previous value and a number defined from the last sent data, for example hash-result of the last data sent. The initial value of the transaction state is loaded in the smart card by the issuer of the smart card, for example a financial institution, during personalisation and stored in the financial institution server as well. The stored procedure for the level of concatenation determines how to create a symmetrical key, such as 3DES key, for the application level transaction encryption from two random numbers of the application authentication (see below), i.e. how many bits from the first random number and hoe many bits from the second random number will be used to form a symmetrical key.

Ideally, but not necessarily all of, the following information should exist in the financial institution server, again partly for authentication, security and encryption: • digital certificate and private key (server level) for SSL; private and public keys for high-level secure transaction protocol; signing key pair for TSV; symmetrical encryption key second level such as Blowfish; a stored procedure for level of concatenation for creation of one or more further keys such as 3DES keys.

Additionally, for each customer the following correspondent information should exist in the financial server:

• card number; user number; smart device master key pairs; key pairs for encryption; public key for signing; key pairs for TSV signing; symmetrical encryption key second level such as Blowfish; a stored procedure for level of concatenation for creation of one or more further keys such as 3DES keys.

Figure 3 shows a programming system 30 representing the third level of authentication, i.e. the application level authentication of Figure 1 and 2, which is a part of the high-level authentication mechanism. The drawing shows a set of operations 32.1-5 and 32.16-20 executed in the user's smart device (smart card), the SSL protocol 12 and a set of operation 36.6-15 executed in the financial institution's server. Operations 32.5 and 36.15 represent messages between the smart card and the financial institution server in the directions shown. Operations 32.1-5 generates a random number, encrypts it with the public key of the financial institution to generate RSA1 , calculates the derivative RSA2 from RSA1 for example using a hash function, and sends a digitally signed message containing the encrypted customer number stored in the smart card, RSA1 and RSA2. Operations 36.6-15 finds the public key corresponding to the customer number, derives the random number, calculate a derivative from that number using the same function as in the smart card, decrypts RSA2 and compares it to the calculated derivative value to authenticate the customer, generates a new random number encrypts it with the public key of the smart card to generate RSA3, calculates the derivative RSA4 from RSA3 for example using a hash function, and sends a digitally signed message containing encrypted RSA3 and RSA4 to the smart card. Operations 32.16-20 decrypt RSA3 and RSA4, calculate derivative value from RSA3 and compare it with the received RSA4 to authenticate the financial institution server to the smart card.

The user is authenticated through the smart card to the financial institution server after execution of 36.10 and the financial institution server is authenticated to the user's smart card after execution of 32.18 and 32.20, in both events using keys and functions allocated in the smart card and in the financial institution server only, there being no operations outside of either the smart card or the financial institution server. Thus there is no key exchange over the network, every message is digitally signed and there is double level of authentication of the financial institution server.

Figure 4 shows a system 40 for implementing a two-message commit, transaction stateful protocol with confirmed non-repudiation between the sender 42 in communication with a receiver, who respectively execute operations 42.1-3 and 42.9-11 and a receiver 44 who executes operations 44.1 to 44.4 in the following order:

42.1 send a message with a digital signature;

42.2 calculate a new TSV, producing a function of the current TSV and the values received as a function of the message;

42.3 send RSA encrypted hash value of the TSV using the receiver's public key

44.4 check the correctness of the received encrypted and signed message (non-repudiation stage of the sender)

44.5 calculate TSV value based on the message content of 42.1 and the current TSV in the receiver;

44.6 compare the calculated has function of the TSV based on the received message with the received hash function of the TSV in the sender from 42.3 (two-message commitment);

44.7 store the new calculated TSV in the receiver;

44.8 send an encrypted and digitally signed message consisting of the hash value of the new TSV in the receiver; 42.9 decrypt the received hash value of the TSV in the receiver;

42.10 compare the received hash value from the sender and the calculated hash value from the TSV in the sender, before it was send from the sender environment (confirmed non-repudiation); 42.11 store the new TSV.

A new TSV is calculated and synchronised between the sender and receiver for each message.

The "two-message commit, transaction stateful protocol with confirmed non- repudiation" is intended to be a new communication protocol that:

• converts the standard stateless communication protocol to a stateful protocol, increasing the security, reliability and the data integrity of the exchanged information; • transmits each logical message by means of two separate physical messages, with logical and secure inter-operability and dependence between them;

• ensures each message is digitally signed;

• ensures receipt of every sent message is confirmed by the receiver; • ensures non-repudiation of the sender;

• confirms the receiving of each non-repudiated message with other non- repudiation type of message sent by the receiver to the sender;

• ensures security of the TSV, without sending in the network the value of a TSV.

The invention is not limited to the precise details described above and shown in the drawings. Modifications may be made and other embodiments developed without departing from the scope of the invention as set out in the claims.

Claims

CLAIMS:

1. A method of ensuring the integrity of a message sent from a sender to a receiver, confirming correct receiving of the message by the receiver to the sender, and authenticating the sender and the receiver to each other including the steps of:

• sending from the sender to the receiver a first message, comprising first and second data elements with the second data element being a function of the first data element and of the transaction history; • at the receiver, analysing the received first message including comparing parts that are respectively representative of the second data element in order to ensure unrepeatability of the message, the integrity of the data elements and the first message, and sender's authentication;

• sending from the receiver to the sender a return message, comprising third, forth and fifth data elements with the forth data element being a function of the third data element and of the transaction history with that sender;

• at the sender, analysing the return message including comparing parts that are respectively representative of the forth data element and analysing the fifth data element in order to obtain confirmation of correct receipt of the first message, unrepeatability of the received return message, and receiver authentication;

• at the sender, all successful analyses and comparisons related to the return message create new transaction history value and send a affirmation message to the receiver comprising encrypted and digitally signed sixth data element being a function of the third data element, of the affirmation statement and of the value of the new transaction history;

• at the sender, any unsuccessful analyses and comparisons related to the return message, keep the transaction history unchanged and send an error message to the receiver comprising encrypted and digitally signed a seventh data element being a function of the third data element, of an error statement and of the value of the previous transaction history.

2. The method of claim 1, wherein the transaction history is selected from the empty set and a complex function using or a portion of the content of each previous message.

3. The method of either one of claims 1 or 2, wherein the first and second data elements are analysed by the receiver after applying to the received first data element a function corresponding to the function applied by the sender using the transaction history stored at the receiver and comparing the result of that function with the received second data element.

4. The method of any one of claims 1 to 3, wherein the third and forth data elements are analysed by the sender applying to the received third data element a function corresponding to the function applied by the receiver using the transaction history stored at the sender and comparing the result of that function with the received forth data element.

5. The method of any one of claims 1 to 4, wherein the third data element comprises a first portion of the first data element in order to confirm receipt of the first message.

6. The method of any one of claims 1 to 5, wherein the third data element is a confirmation-reply to the first message in no error situation.

7. The method of any one of claims 1 to 5, wherein the third data element is an error-reply to the first message in an error situation.

8. The method of any one of claims 1 to 7, wherein the fifth data element comprises a value of a function of the predefined portion of the first data element in order to confirm receipt of the first message and the integrity between the sent and return message.

9. The method of claim 8 insofar as it is dependent of claim 5, wherein if the fifth data element is based on a predefined portion of the first data element, this portion differs from the first portion included in the third data element.

10. The method of claim 9, wherein if the fifth data element is based on a predefined portion of the first data element, that predefined portion of the first data element excludes the portion included in the third data element.

11. The method of any one of claims 1 to 10, including digitally signing at least one of:

• at least some of the messages; and

• at least some part of each of the messages.

12. The method of any one of claims 1 to 11, wherein each of the messages is encrypted.

13. The method of any one of claims 1 to 12, wherein each one of the first and third data elements is encrypted.

14. The method of any one of claims 1 to 13, wherein each data element is separated from other data elements with which is transmitted and each one is at least one of separately digitally signed and separately encrypted.

15. The method of any one of claims 1 to 14, wherein the sender and receiver of the messages authenticate each other by including the steps of:

• using the digital signature of the sender in the generation of the second data element from the first data element and encrypted by the sender's dedicated receiver's public key in order to authenticate the sender to the particular receiver;

• using the digital signature of the receiver in the generation of the forth data element from the third data element and encrypted by the sender's public key in order to authenticate the receiver to the particular sender;

• using the part of the first data element which comprises information signed by the sender and includes personal data of the sender and context expected from the sender, which information is understandable only by the receiver's currently selected sender, to generate the fifth data element in order to mutually authenticate the sender as person and smart device from one side and the receiver from the other side as reliable session partner.

16. The method of any one of claims 1 to 15, wherein the transaction history is presented by a transaction state value.

17. The method of claim 16, wherein the transaction state value is based upon the content of a previous message between the sender and receiver.

18. A method of any one of claims 1 to 17, wherein the transaction state value (TSV) is applied including the steps of:

• initially same first stored value is created at the sender and receiver • creating a temporary second TSV at the sender as a function of at least a portion of the first data element and the first stored TSV at the sender;

• at the sender, using the temporary stored TSV in calculation of the second data element with usage of the temporary second TSV, before encrypting it with the public key of the receiver and before sending it as a part of a digitally signed first message;

• at the receiver, receiving and analysing the first message deriving the first and second data elements, creating a second TSV as a function of at least a portion of the received first data element and the first stored TSV at the receiver;

• at the receiver, using the second TSV in analysing the derived first and second data elements of the first message in order to ensure the integrity of the received message; t

• at the receiver, using the second TSV for creation of the forth data element as a part of the return message to the sender, being a digitally signed function of the third data element and of the function of the second TSV at the receiver;

• at the receiver, storing the second TSV as stored TSV, keeping the previous stored TSV for error recovering; • receiving and analysing the second message at the sender deriving third, forth and fifth data elements, calculating equivalent of the forth data element with using the received third data element and the temporary second TSV at the sender, comparing the calculated equivalent of the forth data element with the received forth data element, making sure that the value of temporary second TSV at the sender corresponds to the value of second TSV used at the receiver;

• before storing the temporary second TSV as the stored TSV at the sender, compare the fifth data element with the value of the function of the predefined portion of the first data element in order to confirm that the first message was correctly received by the receiver, and check that all analyses and comparisons related to the return message are successful, than store the temporary second TSV as stored TSV;

• at the receiver, store the second TSV as stored TSV if there the receiver receives from the sender an affirmation message and not an error message.

19. The method of claims 1 to 18, wherein the sending of the first message from the sender to the receiver is improved with sending an additional message providing an atomic security transaction consisted of two one-way messages for rising the messaging security, additional phase in the generation of the new transaction state value (TSV) is introduced for increasing the security of the stateful protocol and the return message from the receiver to the sender is used to confirm the non-repudiation of the sender, in order to provide a "two-message commit, transaction stateful protocol with confimied non-repudiation", including the steps:

• at the sending party, o sending a digital signed first message to the receiving party; o calculating a temporary first TSV at the sender as a function of the first message and the stored TSV, and calculating a hash value of the temporary first TSV; o encrypting the hash value of the temporary first TSV, using the receiving party's public key, digitally sign it and sending this as a second message to the receiving party; o calculating a temporary second TSV at the sender based on the temporary first TSV and a function of the second message;

• at the receiving party, o checking the validity of the first digitally signed message; o calculating afresh temporary first TSV at the receiver as a function of the received first message and the stored TSV at the receiver; o comparing the hash value of the temporary first TSV at the receiver with the received value in the second message in unencrypted and verified form; o calculating a second TSV at the receiver based on the temporary first TSV at the receiver and function of the second message and store it as stored TSV at the receiver; o sending a return message to the sending party containing an encrypted hash value of the second TSV with a digital signature;

• at the sending party, o receiving the return message and calculating the hash value of the temporary second TSV at the sender; o comparing the hash value of the temporary second TSV at the sender with the decrypted and verified content of the return message; and o storing the temporary second TSV as stored TSV.