Simplified secure shared key establishment and data delivery protocols for electronic commerce

• US 6,681,017 B1
• Filed: 09/03/1997
• Issued: 01/20/2004
• Est. Priority Date: 09/03/1997
• Status: Expired due to Term

• Current Assignee: Nokia of America Corporation (Nokia Corporation)
• Original Assignee: Lucent Technologies, Inc. (Nokia Corporation)
• Inventors: Mayer, Alain Jules, Matias, Yossi, Silberschatz, Abraham
• Primary Examiner(s): Sheikh, Ayaz
• Assistant Examiner(s): Song, Hosuk
• Application Number:
  US08/922,492
• Time in Patent Office: 2,330 Days
• Field of Search: 380/21, 380/49, 380/277-285, 713/201, 713/150-152, 713/170-171, 713/176, 713/172, 705/80
• US Class Current: 380/277
• CPC Class Codes: H04L 2209/56 Financial cryptography, e.g. electronic payment or e-cash
• CPC Class Codes: H04L 63/045 wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption cryptographic mechanisms or cryptographic arrangements using a plurality of keys or algorithms H04L9/14
• CPC Class Codes: H04L 63/061 for key exchange, e.g. in peer-to-peer networks cryptographic mechanisms or cryptographic arrangements for key agreement H04L9/0838
• CPC Class Codes: H04L 9/0825 using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
• CPC Class Codes: H04L 9/0844 with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys

Abstract

A number of protocols are disclosed for providing simplified security for a series of low-cost transactions carried out between a client and a server within an on-going client-server relationship. A key establishment protocol is used to generate a shared key which will be used by the client and server for the series of transactions. The client generates the shared key as a function of a client identifier, a server identifier and secret client information, encrypts the shared key using a public key of the server, and sends the encrypted shared key to the server. The server responds by incorporating server information into a response which is encrypted using the shared key and sent to the client. The client decrypts the response, verifies that the server has accepted the shared key, and then sends additional client information, such as a credit card number, to the server, using the shared key for encryption. The client may then use the shared key in a series of subsequent transactions with the server. The subsequent transactions may be in accordance with a data delivery protocol in which the client requests information, and the server supplies the information encrypted using the shared key. The server may require that the client demonstrate possession of the shared key before responding to a data delivery request. The generation and use of the shared key may be made substantially transparent to the client through the use of a client-side web proxy.

Claims

1. A method of secure communication between a client and a server, comprising:

encrypting a shared key, generated in association with the client, using a public key associated with the server;

sending the encrypted shared key to the server;

receiving a response from the server incorporating information encrypted using the shared key; and

verifying acceptance of the shared key by the server, using the information in the response;

wherein said accepted shared key is recomputed in association with the client for use in an on-going client-server relationship which comprises one or more subsequent transactions between the client and the server, such that a separate key exchange for each transaction need not be performed and the accepted shared key need not be stored in association with the client between said transactions, and such that the use of said accepted shared key persists during the course of the on-going client-server relationship;

further wherein the accepted shared key persists for a time period substantially larger than a related transaction time period associated with a secure socket layer (SSL) protocol thereby allowing the accepted shared key to persist for at least two transactions separated by a time period substantially larger than the SSL related transaction time period, and wherein the client, during subsequent transactions, is able to use a communication device that is different than a communication device used during the key exchange.

2. The method of claim 1 wherein the server stores the accepted shared key and an identifier of the client on an initial interaction with the client, and then retrieves the shared key upon being presented with the stored client identifier in a subsequent transaction.

3. The method of claim 1 further including the step of sending additional client information from the client to the server if the information received in the response is verified as associated with the server.

4. The method of claim 1 wherein an additional message is sent from the server to the client in order to provide a non-repudiation property for a transaction based on the accepted shared key, wherein the additional message includes a vendor signature on client information.

5. The method of claim 1 further including the steps of:

sending a request to the server along with a client identifier;

receiving a response to the request from the server, wherein the response is encrypted using the accepted shared key; and

decrypting the response using the accepted shared key, to thereby authenticate the response and obtain the requested information.

6. The method of claim 5 further including the step of requiring the client to demonstrate possession of the accepted shared key before providing the requested information.

7. The method of claim 1 further including the step of generating the shared key at the client as a function of an identifier of the client, an identifier of the server, and secret information associated with the client.

8. The method of claim 7 wherein the function is a Janus function.

9. The method of claim 1 further including the step of generating the shared key in a web proxy associated with the client.

10. The method of claim 9 wherein all long-term memory utilized by the web proxy is unsecure.

11. The method of claim 9 wherein the client utilizes a plurality of web proxies during the course of the on-going client-server relationship.

12. The method of claim 9 wherein the accepted shared key is regenerated by the web proxy when required for a subsequent transaction between the client and the server, in a manner which is substantially transparent to the client.

13. The method of claim 9 wherein in an initial interaction with the web proxy the client provides a client identifier and additional secret information used by the web proxy to generate the shared key.

14. The method of claim 13 wherein the web proxy uses the client identifier and secret information provided in the initial interaction to compute a shared key for each of a plurality of servers with which the client interacts during a browsing session.

15. An apparatus for use in providing a secure communication between a client and a server, comprising:

at least one processor associated with the client and operative;

(i) to encrypt a shared key, generated in association with the client, using a public key associated with the server, (ii) to send the encrypted shared key to the server, (iii) to receive a response from the server incorporating information encrypted using the shared key, and (iv) to verify acceptance of the shared key by the server using the information in the response, wherein said accepted shared key is recomputed for use in an on-going client-server relationship which comprises one or more subsequent transactions between the client and the server, such that a separate key exchange for each transaction need not be performed and the accepted shared key need not be stored in association with the client between said transactions, and such that the use of said accepted shared key persists during the course of the on-going client-server relationship, further wherein the accepted shared key persists for a time period substantially larger than a related transaction time period associated with a secure socket layer (SSL) protocol thereby allowing the accepted shared key to persist for at least two transactions separated by a time period substantially larger than the SSL related transaction time period, and wherein the client, during subsequent transactions, is able to use a communication device that is different than a communication device used during the key exchange; and

a memory coupled to the processor for at least temporarily storing at least a portion of the information in the response.

16. The apparatus of claim 15 wherein the server stores the accepted shared key and an identifier of the client on an initial interaction with the client, and then retrieves the shared key upon being presented with the stored client identifier in a subsequent transaction.

17. The apparatus of claim 15 wherein the processor generates the shared key as a function of an identifier of the client, an identifier of the server, and secret information associated with the client.

18. The apparatus of claim 17 wherein the function is a Janus function.

19. The apparatus of claim 15 wherein the processor is further operative to generate the shared key using a web proxy associated with the client.

20. The apparatus of claim 19 wherein all long-term memory utilized by the web proxy is unsecure.

21. The apparatus of claim 19 wherein the client utilizes a plurality of web proxies during the course of an on-going client-server relationship.

22. The apparatus of claim 19 wherein the accepted shared key is regenerated by the web proxy when required for a subsequent transaction between the client and the server, in a manner which is substantially transparent to the client.

23. The apparatus of claim 19 wherein in an initial interaction with the web proxy the client provides a client identifier and additional secret information used by the web proxy to generate the shared key.

24. The apparatus of claim 23 wherein the web proxy uses the client identifier and secret information provided in the initial interaction to compute a shared key for each of a plurality of servers with which the client interacts during a browsing session.

25. A method of secure communication between a client and a server, comprising:

receiving in the server an encrypted shared key, wherein the shared key is generated in association with the client and encrypted using a public key associated with the server;

generating a response incorporating information encrypted using the shared key; and

transmitting the response to the client, wherein the client uses the information in the response to verify acceptance of the shared key by the server; and

wherein the accepted shared key is recomputed for use in an on-going client-server relationship which comprises one or more subsequent transactions between the client and the server, such that a separate key exchange for each transaction need not be performed and the accepted shared key need not be stored in association with the client between said transactions, and such that the use of said accepted shared key persists during the course of the on-going client-server relationship;

further wherein the accepted shared key persists for a time period substantially larger than a related transaction time period associated with a secure socket layer (SSL) protocol thereby allowing the accepted shared key to persist for at least two transactions separated by a time period substantially larger than the SSL related transaction time period, and wherein the client, during subsequent transactions, is able to use a communication device that is different than a communication device used during the key exchange.

26. An apparatus for use in providing secure communication between a client and a server, comprising:

a processor associated with the server and operative;

(i) to receive an encrypted shared key, wherein the shared key is generated in association with the client and encrypted using a public key associated with the server, and (ii) to generate and transmit to the client a response incorporating information encrypted using the shared key, wherein the client can verify acceptance of the shared key by the server using the information in the response, and the accepted shared key is recomputed for use in an on-going client-server relationship which comprises one or more subsequent transactions between the client and the server, such that a separate key exchange for each transaction need not be performed and the accepted shared key need not be stored in association with the client between said transactions, and such that the use of said accepted shared key persists during the course of the on-going client-server relationship, further wherein the accepted shared key persists for a time period substantially larger than a related transaction time period associated with a secure socket layer (SSL) protocol thereby allowing the accepted shared key to persist for at least two transactions separated by a time period substantially larger than the SSL related transaction time period, and wherein the client, during subsequent transactions, is able to use a communication device that is different than a communication device used during the key exchange; and

a memory coupled to the processor for storing the shared key.