WO1999025093A2 - Secure handshake protocol - Google Patents

Secure handshake protocol Download PDF

Info

Publication number
WO1999025093A2
WO1999025093A2 PCT/FI1998/000869 FI9800869W WO9925093A2 WO 1999025093 A2 WO1999025093 A2 WO 1999025093A2 FI 9800869 W FI9800869 W FI 9800869W WO 9925093 A2 WO9925093 A2 WO 9925093A2
Authority
WO
WIPO (PCT)
Prior art keywords
party
message
certificate
inter
indicating
Prior art date
Application number
PCT/FI1998/000869
Other languages
French (fr)
Other versions
WO1999025093A3 (en
Inventor
Olli Immonen
Original Assignee
Nokia Networks Oy
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 Nokia Networks Oy filed Critical Nokia Networks Oy
Priority to AU10359/99A priority Critical patent/AU1035999A/en
Priority to US09/554,112 priority patent/US6931528B1/en
Publication of WO1999025093A2 publication Critical patent/WO1999025093A2/en
Publication of WO1999025093A3 publication Critical patent/WO1999025093A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/069Authentication using certificates or pre-shared keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80Wireless
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication

Definitions

  • the present invention relates in general to a secure handshake protocol for telecommunications networks. More particularly, the invention re- lates to a method and an apparatus for providing secure handshake between call parties with minimal overhead before actual data transmission.
  • TLS Transport Layer Security
  • a TLS-type protocol comprises several layers, such as: Upper layer protocols Handshake protocol/Alert protocol/Application protocol
  • Figure 1 is based on section 7.3 of said TLS draft protocol, and it illustrates a prior art handshake method.
  • parties A and B are also referred to as “client” and “server”, respectively.
  • client hello message comprises a list of cipher suites and compres- sion methods supported by the client. Additionally, the message may also comprise a time stamp.
  • server B selects a cipher suite and a compression method. (Optionally, B may also check the timestamp to make sure that the message is not an old message being retransmitted.)
  • step 13 the server B responds with a server hello message.
  • the client hello and server hello messages 11 and 13 establish security between the parties, typically by establishing the following attributes: protocol version, session ID, cipher suite and compression method.
  • the server B sends its own certificate C B to the client A and it requests the client A to send its client certificate C A to the server B.
  • the client A verifies B's certificate and obtains B's public key E B .
  • the client A sends B a finished message, indicating that A has been able to verify B's identity. Additionally, A sends its own certificate C A to B.
  • B uses C A to obtain A's public key E A .
  • step 17 B sends its own finished message to the client A.
  • each party In connection with verifying its peer's identity, each party independently calculates a shared secret key for this session. Now both parties have exchanged keys, agreed on a cipher suite/compression method and verified the identity of the other party.
  • the client A can start transmitting application data.
  • An essential component in the above protocol are the certificates C A and C B .
  • each party can verify its peer's identity.
  • a certificate comprises at least its owner's identity (A/B) and public key(s) (E A /E B ), period of validity, the issuer of the certificate and the issuer's digital signature. It may also comprise the rights granted to its owner.
  • a suitable mechanism for digital signatures is a reversal of public-key encryption: the issuer signs the certificate with its private key and whoever wants to verify the certificate, does so by using the issuer's public key.
  • a suitable structure for a certificate is specified in ISO standard X.509.
  • Fig. 1 A problem with this prior art handshake protocol is the high overhead required. As seen in Fig. 1 , the actual data transmission does not begin until step 15, or after four messages have been transmitted between the parties. In a wireless multiple access system, where the parties A and B are separated by an air interface Urn and a public land based mobile network PLMN, the actual messaging is much more complicated than the one shown in Fig. 1. This is because Fig. 1 only shows the actual messages and omits (for clarity) the resource reservation and release steps which are routine for a person skilled in the art, but which are nevertheless indispensable.
  • the invention is applicable to telecommunication systems with a slow and/or unreliable transmission channel acting as a bottleneck between the parties.
  • Figure 1 shows a signalling diagram illustrating a prior art handshake protocol
  • Figure 2 is a combination wherein the bottom portion is an inter- leaved signalling diagram/flowchart illustrating an embodiment of the invention and the top portion is a block diagram showing how the inventive functionality can be mapped to various network elements.
  • FIG. 2 An embodiment of the invention will be de- scribed.
  • the lower portion of Fig. 2 is an interleaved signalling diagram/flowchart illustrating an embodiment of the invention.
  • the upper portion of Fig. 2 is an associated block diagram, illustrating a possible mapping between call parties and physical network elements.
  • step 21 the client A sends a first inter-party message comprising all the elements of the message of step 11.
  • An inter-party message is a message from A to B or vice versa.
  • the message of step 21 comprises an identifier ID A of the client A, and encryption parameters (such as random numbers and/or initialisation vectors) if required by any of the indicated cipher suites.
  • the identifier ID A will be studied later in more detail.
  • the server B selects a cipher suite. Preferably, it also checks the timestamp of the message sent by A.
  • step 23 instead of requesting A's certificate C A from A itself, the server B uses the ID A sent by A to retrieve A's certificate C A from a certificate store CS.
  • the connection between B and CS should be significantly faster than the air inter- face Um.
  • the trustee CS returns A's certificate C A .
  • B can also maintain a local memory MEM of certificates and omit the inquiry to CS if A's certificate is found in the local memory.
  • step 25 verifies C A , obtains A's public key E A and calculates the shared secret key.
  • B sends a second inter-party message to A.
  • the second inter-party message comprises B's certificate C B . It also indicates that B has been able to verify A's certificate.
  • step 27 A verifies B's certificate C B , obtains B's public key E B and calculates the shared secret key.
  • step 28 A sends B a third inter-party message comprising a fin- ished message which indicates that it has been able to verify B's certificate.
  • Fig. 2 only shows what happens when the handshake is successful, i.e. both parties act according to the protocol. If a departure from the protocol is detected, this is usually a fatal error and the handshake terminates.
  • the last inter-party message (comprising the finished message in step 28) points from A to B. This is in marked contrast to the prior art handshake shown in Fig. 1.
  • An advantage of this property of the invention is that application data can be concatenated with the third inter-party message in step 28.
  • the effective overhead of the handshake protocol according to the invention is only two inter-party messages, compared to an overhead of four messages in the prior art handshake. In order to achieve this, an appropriate key exchange mechanism must be used.
  • Suitable key exchange algorithms include Diffie-Hellman (DH) with fixed parameters certified with Digital Signature Algorithm (DSA).
  • the DH algorithm can be found in most textbooks on cryptography. Additionally, the original Diffie-Hellman algorithm (DH) is described in US Patent 4 200 770 and the Digital Signature Algorithm (DSA) is a U.S. standard and a de facto international standard.
  • Another good combination is Elliptic Curve Diffie-Hellman (ECDH) with fixed parameters certified with Elliptic Curve Digital Signature Algorithm (ECDSA).
  • ECDH Elliptic Curve Diffie-Hellman
  • ECDSA Elliptic Curve Digital Signature Algorithm
  • the difference between standard DH and ECDH is only different mathematics in obtaining and using encryption and decryption keys. Such differences are not essential to the invention.
  • RSA Raster-Shamir-Adlemann
  • ECES Elliptic Curve Encryption Scheme
  • a server key exchange takes place as follows. B generates a random number, which is a pre-master secret, encrypts it with A's public key, and sends the result to A. Thus the message in step 26 would comprise ServerHello, C B , ServerKeyExchange, Finished. Now A decrypts this pre-master secret.
  • This server key exchange procedure resembles a mirror image of the one used in TLS, whereby the handshake can still be accom- pushed with two messages over the air interface.
  • the handshake method described above uses public keys. As is well known, public-key cryptography is much slower than symmetric cryptography. Therefore, it is preferable to use the public-key handshake only for exchanging parameters which are used for computing a shared key for symmet- ric cryptography, such as DES.
  • the parameters (random numbers) sent in message 21 can be used for this purpose.
  • the inventive handshake somewhat limits the available key-exchange mechanisms during the handshake phase, the invention does not limit the available mechanisms used for the actual data transmission. In other words, the invention does not limit the choices available for symmetric cryptography, although it requires that the parameters for the symmetric cryptography first used are exchanged by using a key-exchange mechanism with fixed parameters.
  • the encryption parameters sent in message 21 (and 26) can be combined with private keys to create pre-master secrets which in turn are used to create master secrets, etc.
  • a separate message can be concatenated. This separate message can be used for changing the selected cryptography mechanism.
  • the identifier ID A of client A should be unique to each A. Suitable identifiers are e.g. a network number, such as MSISDN or an X.509 number.
  • the 1D A is not protected by the handshake protocol proper, although it may be protected by a lower level protocol. Therefore, it is preferable to create the 1D A using a one-way function, such as a hash function.
  • One-way functions are functions that are much easier (at least by several orders of magnitude) to perform in one direction than in the reverse direction. Examples of one-way functions are multiplying large prime numbers, discrete exponentiation, elliptical functions and hash functions.
  • the advantage of one-way functions is that they hide the identity of A from possible eavesdroppers. As is well known, hash functions reduce information. Hashed numbers are thus not necessarily unique. However, a good combination is achieved by using a hash of the cli- ent's public key E A and assigning public keys such that they do not produce identical hash values.
  • the upper portion of Fig. 2 shows how the functionality of the invention can be mapped to various network elements.
  • the invention can be used in a wireless communication system, such as a mobile communications system.
  • the client A can be a mobile station MS, possibly having a portable computer PC connected or integrated thereto.
  • the server B can be a computer B' providing financial services, or granting access to confidential information, etc.
  • a and B can communicate over an air interface Um and via a pub- lie land based mobile network PLMN, possibly also via a public switched mobile network PSTN.
  • the trustee CS could be implemented in one of the registers of the PLMN, such as a home location register (HLR), or a GPRS register GR.
  • the trustee services can be implemented as disclosed in said ISO standard X.509.
  • B can maintain a local memory MEM of certificates and omit the inquiry to CS if A's certificate is found in the local memory.
  • B can e.g. be connected to a local area network and the certificates of all the clients A are maintained over the local area network.
  • a local memory MEM can also be used as a cache memory for storing recently used certificates. In real-time applications, if a certificate is revoked, the computer B' must be informed and it must also delete the revoked certificate from its cache.
  • An important advantage of the invention is that the overhead over the slow communications channel, such as the air interface, can be halved compared to prior art protocols.
  • Another advantage is that the client's certificate C A does not have to stored in the client itself. Since the client A is typically a mobile station, its memory capacity is limited. This also reduces the information gained by dishonest third parties in case the client hardware gets lost or stolen, or is used by unauthorised persons. Also, because the client's certificate C A is not transmitted over the air interface, less information is leaked to possible eavesdroppers.

Abstract

Method for a secure handshake protocol between A and B, connected by a slow channel (Um). A sends a first message (21) indicating a set of cipher suites with parameters, and its identifier (IDA). B selects a cipher suite, obtains A's certificate (CA) over a fast connection, verifies A's certificate (CA) and obtains A's public key (EA). Next B sends a second message (26) comprising B's certificate (CB), and indication that B has verified A's certificate (CA), and an indication about the selected cipher suite. A begins to use the selected cipher suite, verifies B's certificate (CB) and obtains B's public key (EB). Next A sends a third message (28) indicating that A has verified B's certificate (CB). Application data can be sent from A to B in the third message (28), whereby a two-way key-exchange and mutual verification is achieved with an effective overhead of two messages (21, 26) between A and B.

Description

Secure handshake protocol
Background of the Invention
The present invention relates in general to a secure handshake protocol for telecommunications networks. More particularly, the invention re- lates to a method and an apparatus for providing secure handshake between call parties with minimal overhead before actual data transmission.
Within this application, "TLS" refers to Transport Layer Security. One such protocol is described in "The TLS Protocol", May 21 , 1997, by Tim Dierks and Christopher Allen, Consensus Development. This document has been published as "draft-ietf-tls-protocol-03.txt", incorporated herein by reference. More particularly, the present invention proposes an improved handshake protocol which is applicable i.a. in protocols like TLS.
A TLS-type protocol comprises several layers, such as: Upper layer protocols Handshake protocol/Alert protocol/Application protocol
Record protocol Transport protocol Lower level protocols
Figure 1 is based on section 7.3 of said TLS draft protocol, and it illustrates a prior art handshake method. In order to keep the specification consistent with said draft, parties A and B are also referred to as "client" and "server", respectively. (Terms like "hello" and "finished" are also used consistently with said TLS draft.) In step 11 , the client A sends a client hello message. This client hello message comprises a list of cipher suites and compres- sion methods supported by the client. Additionally, the message may also comprise a time stamp. In step 12, the server B selects a cipher suite and a compression method. (Optionally, B may also check the timestamp to make sure that the message is not an old message being retransmitted.)
In step 13 the server B responds with a server hello message. The client hello and server hello messages 11 and 13 establish security between the parties, typically by establishing the following attributes: protocol version, session ID, cipher suite and compression method. In connection with the server hello message, the server B sends its own certificate CB to the client A and it requests the client A to send its client certificate CA to the server B. In response to this, in step 14 the client A verifies B's certificate and obtains B's public key EB. In step 15 the client A sends B a finished message, indicating that A has been able to verify B's identity. Additionally, A sends its own certificate CA to B. In step 16, B uses CA to obtain A's public key EA. In step 17, B sends its own finished message to the client A. In connection with verifying its peer's identity, each party independently calculates a shared secret key for this session. Now both parties have exchanged keys, agreed on a cipher suite/compression method and verified the identity of the other party. In step 18, the client A can start transmitting application data.
An essential component in the above protocol are the certificates CA and CB. By means of certificates signed by a mutually trusted authority, each party can verify its peer's identity. A certificate comprises at least its owner's identity (A/B) and public key(s) (EA/EB), period of validity, the issuer of the certificate and the issuer's digital signature. It may also comprise the rights granted to its owner. A suitable mechanism for digital signatures is a reversal of public-key encryption: the issuer signs the certificate with its private key and whoever wants to verify the certificate, does so by using the issuer's public key. A suitable structure for a certificate is specified in ISO standard X.509.
A problem with this prior art handshake protocol is the high overhead required. As seen in Fig. 1 , the actual data transmission does not begin until step 15, or after four messages have been transmitted between the parties. In a wireless multiple access system, where the parties A and B are separated by an air interface Urn and a public land based mobile network PLMN, the actual messaging is much more complicated than the one shown in Fig. 1. This is because Fig. 1 only shows the actual messages and omits (for clarity) the resource reservation and release steps which are routine for a person skilled in the art, but which are nevertheless indispensable.
Disclosure of the Invention
Based on the foregoing description, it is an object of the present invention to create a method and suitable network elements (nodes and termi- nals) for providing a secure handshake protocol with a low overhead, i.e. a small number of messages over the air interface. This object will be achieved with a method and network elements which are characterized by what is disclosed in the appended independent claims. Advantageous embodiments of the present invention will be presented in the dependent claims. The invention is based on a novel distribution of operations between the parties A and B. In addition, some messages over the air interface can be eliminated by using a land-based certificate store or service, and performing an inquiry to this store. Further, the invention is based on the vision that the last message of the handshake proper should be sent from A to B, whereby actual data transmission can be concatenated with the last hand- shake message, whereby the net overhead is minimised.
The invention is applicable to telecommunication systems with a slow and/or unreliable transmission channel acting as a bottleneck between the parties.
Brief Description of the drawings In the following, the invention will be described by means of preferred embodiments with reference to the accompanying drawing, in which:
Figure 1 shows a signalling diagram illustrating a prior art handshake protocol; and
Figure 2 is a combination wherein the bottom portion is an inter- leaved signalling diagram/flowchart illustrating an embodiment of the invention and the top portion is a block diagram showing how the inventive functionality can be mapped to various network elements.
Detailed description of the invention
Referring now to Fig. 2, an embodiment of the invention will be de- scribed. The lower portion of Fig. 2 is an interleaved signalling diagram/flowchart illustrating an embodiment of the invention. The upper portion of Fig. 2 is an associated block diagram, illustrating a possible mapping between call parties and physical network elements.
In step 21 the client A sends a first inter-party message comprising all the elements of the message of step 11. (An inter-party message is a message from A to B or vice versa.) Additionally, the message of step 21 comprises an identifier IDA of the client A, and encryption parameters (such as random numbers and/or initialisation vectors) if required by any of the indicated cipher suites. The identifier IDA will be studied later in more detail. In re- sponse to the client hello message, in step 22 the server B selects a cipher suite. Preferably, it also checks the timestamp of the message sent by A. In step 23, instead of requesting A's certificate CA from A itself, the server B uses the IDA sent by A to retrieve A's certificate CA from a certificate store CS. The connection between B and CS should be significantly faster than the air inter- face Um. In step 24, the trustee CS returns A's certificate CA. Alternatively or additionally, B can also maintain a local memory MEM of certificates and omit the inquiry to CS if A's certificate is found in the local memory. In step 25, B verifies CA, obtains A's public key EA and calculates the shared secret key. In step 26, B sends a second inter-party message to A. The second inter-party message comprises B's certificate CB. It also indicates that B has been able to verify A's certificate. (However, this indication can be an implicit one, meaning that B only sends its certificate if it has verified A's certificate.) In step 27, A verifies B's certificate CB, obtains B's public key EB and calculates the shared secret key. In step 28, A sends B a third inter-party message comprising a fin- ished message which indicates that it has been able to verify B's certificate.
For clarity, Fig. 2 only shows what happens when the handshake is successful, i.e. both parties act according to the protocol. If a departure from the protocol is detected, this is usually a fatal error and the handshake terminates. It should be noted that the last inter-party message (comprising the finished message in step 28) points from A to B. This is in marked contrast to the prior art handshake shown in Fig. 1. An advantage of this property of the invention is that application data can be concatenated with the third inter-party message in step 28. Thus the effective overhead of the handshake protocol according to the invention is only two inter-party messages, compared to an overhead of four messages in the prior art handshake. In order to achieve this, an appropriate key exchange mechanism must be used. Suitable key exchange algorithms include Diffie-Hellman (DH) with fixed parameters certified with Digital Signature Algorithm (DSA). The DH algorithm can be found in most textbooks on cryptography. Additionally, the original Diffie-Hellman algorithm (DH) is described in US Patent 4 200 770 and the Digital Signature Algorithm (DSA) is a U.S. standard and a de facto international standard. Another good combination is Elliptic Curve Diffie-Hellman (ECDH) with fixed parameters certified with Elliptic Curve Digital Signature Algorithm (ECDSA). The difference between standard DH and ECDH is only different mathematics in obtaining and using encryption and decryption keys. Such differences are not essential to the invention.
Additionally, RSA (Rivest-Shamir-Adlemann) and ECES (Elliptic Curve Encryption Scheme) algorithms can be used with appropriate modifica- tions. With these algorithms, a server key exchange takes place as follows. B generates a random number, which is a pre-master secret, encrypts it with A's public key, and sends the result to A. Thus the message in step 26 would comprise ServerHello, CB, ServerKeyExchange, Finished. Now A decrypts this pre-master secret. This server key exchange procedure resembles a mirror image of the one used in TLS, whereby the handshake can still be accom- pushed with two messages over the air interface.
The handshake method described above uses public keys. As is well known, public-key cryptography is much slower than symmetric cryptography. Therefore, it is preferable to use the public-key handshake only for exchanging parameters which are used for computing a shared key for symmet- ric cryptography, such as DES. The parameters (random numbers) sent in message 21 can be used for this purpose.
Although the inventive handshake somewhat limits the available key-exchange mechanisms during the handshake phase, the invention does not limit the available mechanisms used for the actual data transmission. In other words, the invention does not limit the choices available for symmetric cryptography, although it requires that the parameters for the symmetric cryptography first used are exchanged by using a key-exchange mechanism with fixed parameters. The encryption parameters sent in message 21 (and 26) can be combined with private keys to create pre-master secrets which in turn are used to create master secrets, etc. Thus, to each application data message following message 28, a separate message can be concatenated. This separate message can be used for changing the selected cryptography mechanism.
The identifier IDA of client A should be unique to each A. Suitable identifiers are e.g. a network number, such as MSISDN or an X.509 number. The 1DA is not protected by the handshake protocol proper, although it may be protected by a lower level protocol. Therefore, it is preferable to create the 1DA using a one-way function, such as a hash function. One-way functions are functions that are much easier (at least by several orders of magnitude) to perform in one direction than in the reverse direction. Examples of one-way functions are multiplying large prime numbers, discrete exponentiation, elliptical functions and hash functions. The advantage of one-way functions is that they hide the identity of A from possible eavesdroppers. As is well known, hash functions reduce information. Hashed numbers are thus not necessarily unique. However, a good combination is achieved by using a hash of the cli- ent's public key EA and assigning public keys such that they do not produce identical hash values.
The upper portion of Fig. 2 shows how the functionality of the invention can be mapped to various network elements. The invention can be used in a wireless communication system, such as a mobile communications system. The client A can be a mobile station MS, possibly having a portable computer PC connected or integrated thereto. The server B can be a computer B' providing financial services, or granting access to confidential information, etc. A and B can communicate over an air interface Um and via a pub- lie land based mobile network PLMN, possibly also via a public switched mobile network PSTN.
The trustee CS could be implemented in one of the registers of the PLMN, such as a home location register (HLR), or a GPRS register GR. Alternatively, the trustee services can be implemented as disclosed in said ISO standard X.509.
Instead of retrieving A's certificate from CS, or in addition to it, B can maintain a local memory MEM of certificates and omit the inquiry to CS if A's certificate is found in the local memory. B can e.g. be connected to a local area network and the certificates of all the clients A are maintained over the local area network. A local memory MEM can also be used as a cache memory for storing recently used certificates. In real-time applications, if a certificate is revoked, the computer B' must be informed and it must also delete the revoked certificate from its cache.
An important advantage of the invention is that the overhead over the slow communications channel, such as the air interface, can be halved compared to prior art protocols. Another advantage is that the client's certificate CA does not have to stored in the client itself. Since the client A is typically a mobile station, its memory capacity is limited. This also reduces the information gained by dishonest third parties in case the client hardware gets lost or stolen, or is used by unauthorised persons. Also, because the client's certificate CA is not transmitted over the air interface, less information is leaked to possible eavesdroppers.
The invention has been described in its preferred embodiments. However, the specifications for telecommunications technology are developing rapidly. Such developments may require additional modifications to the invention. Therefore, all words and expressions should be interpreted broadly, and they are intended for illustrating rather than limiting the invention as specified in the appended claims.

Claims

Claims:
1. A method for a secure handshake protocol between a first party (A) and a second party (B), connected via a communications channel (Um, PLMN) wherein each party supports a respective set of cipher suites and for each party, a respective certificate (CA, CB) is defined, each of the certificates (CA, CB) comprising a public key (EA, EB) of its respective owner (A, B); the method being c h a r a c t e r i z e d in that the first party (A) sends a first inter-party message (21) indicating the set of cipher suites supported by it, parameters required by the cipher suites, and an identifier (IDA) of the first party (A); in response to the first inter-party message (21), the second party (B):
- selects one of said indicated cipher suites which is also supported by the second party (B); - uses said identifier (IDA) to obtain the certificate (CA) of the first party (A) over a connection which is significantly faster than the communications channel (Um, PLMN) connecting said parties;
- verifies said obtained certificate (CA) the of the first party (A) and obtains the public key (EA) of the first party (A); - sends a second inter-party message (26) comprising the certificate
(CB) of the second party (B), an indication that the second party (B) has verified the certificate (CA) of the first party (A), and an indication about said selected cipher suite; in response to the second inter-party message (26), the first party (A):
- begins to use the selected cipher suite;
- verifies the certificate (CB) of the second party (B) and obtains the public key (EB) of the second party (B);
- sends a third inter-party message (28) indicating that the first party (A) has verified the certificate (CB) of the second party (B); whereby information not needed for the above steps can be sent from the first party (A) to the second party (B) in the third inter-party message (28), thus providing a two-way key-exchange and mutual verification with an effective overhead of two inter-party messages (21 , 26).
2. A method according to claim ^ characterized in that said step of obtaining the certificate (CA) of the first party (A) comprises retrieving it from a source (CS) external to the second party.
3. A method according to claim 2, characterized in that said external source (CS) is a register (HLR, GR) of a telecommunications network or a directory service substantially conforming to ISO standard X.509.
4. A method according to claim ^ characterized in that said step of obtaining the certificate (CA) of the first party (A) comprises retrieving it from a local memory (MEM).
5. A method according to any one of the preceding claims, characterized in that said identifier (1DA) of the first party (A) is formed by means of a one-way function, preferably a hash function.
6. A method according to any one of the preceding claims, characterized in that said second inter-party message (26) comprises a pre- master secret which the second party (B) obtains by generating a random number and encrypting it with the public key (EA) of the first party (A).
7. A telecommunications apparatus (A) being adapted to act as a first party in a secure handshake protocol between said apparatus (A) and a second party (B), said apparatus being characterized in that it is adapted to:
- send a first message (21) to the second party (B), said first message indicating a set of cipher suites, parameters required by said cipher suites, and an identifier (IDA) of the apparatus (A);
- receive a second message (26) from the second party (B), said second message comprising an indication about a cipher suite selected by said second party, a certificate (CB) of the second party, an indication that the second party (B) has used said identifier (IDA) of the apparatus to obtain and verify a certificate (CA) of the apparatus (A), and;
- use the cipher suite indicated by said second message (26); - verify the certificate (CB) of the second party (B) and obtain a public key (EB) of the second party (B); - send a third message (28) to the second party (B), said third message indicating that the apparatus (A) has verified the certificate (CB) of the second party.
8. A telecommunications apparatus (A) according to claim 7, c h a r a c t e r i z e d by being adapted to insert information not needed for the above operations in said third message (28).
9. A telecommunications apparatus (B) being adapted to respond to a secure handshake protocol initiated by a first party (A), said apparatus (B) being connectable to said first party (A) by a communications channel (Um, PLMN), said apparatus (B) being c h a r a c t e r i z e d in that it is adapted to:
- receive a first message (21) from the first party (A), said first message indicating a set of cipher suites, parameters required by the cipher suites, and an identifier (IDA) of the first party (A);
- select one of said indicated cipher suites; - use the identifier (IDA) to obtain a certificate (CA) of the first party
(A) over a connection which is significantly faster than said communications channel (Um, PLMN);
- verify said obtained certificate (CA) of the first party (A) and obtain a public key (EA) of the first party (A); - send a second message (26) to the first party (A), said second message comprising a certificate (CB) of the apparatus (B), indicating that the apparatus (B) has verified the certificate (CA) of the first party (A), and indicating said selected cipher suite;
- receive a third message (28) from the first party (A), said third message indicating that the first party (A) has verified the certificate (CB) of the apparatus (B).
10. A telecommunications apparatus (B) according to claim 9, c h a r a c t e r i z e d by being adapted to extract information not needed for the above operations from said third message (28).
PCT/FI1998/000869 1997-11-10 1998-11-10 Secure handshake protocol WO1999025093A2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU10359/99A AU1035999A (en) 1997-11-10 1998-11-10 Secure handshake protocol
US09/554,112 US6931528B1 (en) 1997-11-10 1998-11-10 Secure handshake protocol

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI974186 1997-11-10
FI974186A FI104666B (en) 1997-11-10 1997-11-10 Secure handshake protocol

Publications (2)

Publication Number Publication Date
WO1999025093A2 true WO1999025093A2 (en) 1999-05-20
WO1999025093A3 WO1999025093A3 (en) 1999-07-29

Family

ID=8549905

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI1998/000869 WO1999025093A2 (en) 1997-11-10 1998-11-10 Secure handshake protocol

Country Status (5)

Country Link
US (1) US6931528B1 (en)
AU (1) AU1035999A (en)
FI (1) FI104666B (en)
TW (1) TW380346B (en)
WO (1) WO1999025093A2 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1158826A2 (en) * 2000-05-24 2001-11-28 Nokia Mobile Phones Ltd. Method for processing location information relating to a terminal connected to a packet network via a cellular network
DE10025271A1 (en) * 2000-05-22 2001-11-29 Siemens Ag Method for establishing a connection between a terminal and a serving cellular network, cellular network and terminal therefor
WO2002011362A1 (en) * 2000-08-01 2002-02-07 Nokia Corporation Data transmission method, user equipment and gprs/edge radio access network
US6915124B1 (en) * 1999-10-01 2005-07-05 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for executing secure data transfer in a wireless network
US7311246B2 (en) 2004-11-26 2007-12-25 Sony Corporation Method and system for transmitting electronic value information
WO2008048836A1 (en) * 2006-10-13 2008-04-24 Microsoft Corporation Upnp authentication and authorization
US7382882B1 (en) 1998-07-03 2008-06-03 Nokia Corporation Secure session set up based on the wireless application protocol
WO2010022650A1 (en) * 2008-08-29 2010-03-04 华为技术有限公司 Clock synchronization method, device and system

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7131006B1 (en) * 1999-11-15 2006-10-31 Verizon Laboratories Inc. Cryptographic techniques for a communications network
US7519737B2 (en) * 2000-07-07 2009-04-14 Schneider Automation Inc. Input/output (I/O) scanner for a control system with peer determination
US7327846B1 (en) * 2000-09-05 2008-02-05 Chung Nan Chang Secure cryptographic key exchange and verifiable digital signature
GB0309182D0 (en) 2003-04-23 2003-05-28 Hewlett Packard Development Co Security method and apparatus using biometric data
US20050005136A1 (en) * 2003-04-23 2005-01-06 Liqun Chen Security method and apparatus using biometric data
US20040117626A1 (en) * 2003-09-12 2004-06-17 Pioneer Research Center Usa, Inc. Key exchange based on dsa type certificates
US20050141706A1 (en) * 2003-12-31 2005-06-30 Regli William C. System and method for secure ad hoc mobile communications and applications
KR101346734B1 (en) 2006-05-12 2014-01-03 삼성전자주식회사 Multi certificate revocation list support method and apparatus for digital rights management
US8099459B2 (en) * 2006-06-23 2012-01-17 Microsoft Corporation Content feedback for authors of web syndications
US8145532B2 (en) 2006-06-27 2012-03-27 Microsoft Corporation Connecting devices to a media sharing service
US9055107B2 (en) * 2006-12-01 2015-06-09 Microsoft Technology Licensing, Llc Authentication delegation based on re-verification of cryptographic evidence
TW200922256A (en) * 2007-11-06 2009-05-16 Nat Univ Tsing Hua Method for reconfiguring security mechanism of a wireless network and the mobile node and network node thereof
CN101459506B (en) * 2007-12-14 2011-09-14 华为技术有限公司 Cipher key negotiation method, system, customer terminal and server for cipher key negotiation
US8321662B2 (en) 2008-05-08 2012-11-27 International Business Machines Corporation Certificate renewal using secure handshake
US8862874B2 (en) * 2008-05-09 2014-10-14 International Business Machines Corporation Certificate distribution using secure handshake
US8239670B1 (en) * 2008-05-13 2012-08-07 Adobe Systems Incorporated Multi-aspect identifier in network protocol handshake
US8645695B2 (en) * 2009-10-07 2014-02-04 Blackberry Limited System and method for managing security key architecture in multiple security contexts of a network environment
US10657519B2 (en) * 2013-10-22 2020-05-19 Accenture Global Services Limited Facilitating secure transactions using a contactless interface
US10412098B2 (en) 2015-12-11 2019-09-10 Amazon Technologies, Inc. Signed envelope encryption
US9705859B2 (en) * 2015-12-11 2017-07-11 Amazon Technologies, Inc. Key exchange through partially trusted third party
US9699655B1 (en) * 2016-02-23 2017-07-04 T-Mobile Usa, Inc. Cellular device authentication
US10545940B2 (en) * 2017-02-22 2020-01-28 Red Hat, Inc. Supporting secure layer extensions for communication protocols
JP7431382B2 (en) * 2020-10-01 2024-02-14 オボーレン システムズ, インコーポレイテッド Exclusive self-escrow methods and equipment
US11669887B1 (en) * 2022-05-27 2023-06-06 InstaProtek Inc. Learning engine-based navigation system

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0532231A2 (en) * 1991-09-13 1993-03-17 AT&T Corp. Service provision authentication protocol
US5371794A (en) * 1993-11-02 1994-12-06 Sun Microsystems, Inc. Method and apparatus for privacy and authentication in wireless networks
US5638446A (en) * 1995-08-28 1997-06-10 Bell Communications Research, Inc. Method for the secure distribution of electronic files in a distributed environment

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5196840A (en) * 1990-11-05 1993-03-23 International Business Machines Corporation Secure communications system for remotely located computers
US5588060A (en) * 1994-06-10 1996-12-24 Sun Microsystems, Inc. Method and apparatus for a key-management scheme for internet protocols
US5657390A (en) * 1995-08-25 1997-08-12 Netscape Communications Corporation Secure socket layer application program apparatus and method
US5949882A (en) * 1996-12-13 1999-09-07 Compaq Computer Corporation Method and apparatus for allowing access to secured computer resources by utilzing a password and an external encryption algorithm
US6081900A (en) * 1999-03-16 2000-06-27 Novell, Inc. Secure intranet access
US6826690B1 (en) * 1999-11-08 2004-11-30 International Business Machines Corporation Using device certificates for automated authentication of communicating devices
US8015600B2 (en) * 2000-12-22 2011-09-06 Oracle International Corporation Employing electronic certificate workflows
US7415607B2 (en) * 2000-12-22 2008-08-19 Oracle International Corporation Obtaining and maintaining real time certificate status
GB0311621D0 (en) * 2003-05-20 2003-06-25 Nokia Corp A system for crytographical authentication

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0532231A2 (en) * 1991-09-13 1993-03-17 AT&T Corp. Service provision authentication protocol
US5371794A (en) * 1993-11-02 1994-12-06 Sun Microsystems, Inc. Method and apparatus for privacy and authentication in wireless networks
US5638446A (en) * 1995-08-28 1997-06-10 Bell Communications Research, Inc. Method for the secure distribution of electronic files in a distributed environment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
IEEE NETWORK, Sept. 1997, CHANG-SEOP PARK, "On Certificate-Based Security Protocols for Wireless Mobile Communication Systems", pages 50-55. *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7382882B1 (en) 1998-07-03 2008-06-03 Nokia Corporation Secure session set up based on the wireless application protocol
US6915124B1 (en) * 1999-10-01 2005-07-05 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for executing secure data transfer in a wireless network
DE10025271A1 (en) * 2000-05-22 2001-11-29 Siemens Ag Method for establishing a connection between a terminal and a serving cellular network, cellular network and terminal therefor
US7620183B2 (en) * 2000-05-22 2009-11-17 Siemens Aktiengesellschaft Method for establishing a connection between a terminal and an operating mobile radio network, mobile radio network and terminal used in such a method
EP1158826A3 (en) * 2000-05-24 2003-05-07 Nokia Corporation Method for processing location information relating to a terminal connected to a packet network via a cellular network
EP1158826A2 (en) * 2000-05-24 2001-11-28 Nokia Mobile Phones Ltd. Method for processing location information relating to a terminal connected to a packet network via a cellular network
US8781123B2 (en) 2000-05-24 2014-07-15 Nokia Corporation Method for processing location information relating to a terminal connected to a packet network via a cellular network
JP4750346B2 (en) * 2000-08-01 2011-08-17 ノキア コーポレイション Data transmission method, user equipment, and GPRS / EDGE radio access network
WO2002011362A1 (en) * 2000-08-01 2002-02-07 Nokia Corporation Data transmission method, user equipment and gprs/edge radio access network
US7734049B2 (en) 2000-08-01 2010-06-08 Nokia Corporation Data transmission method, user equipment and GPRS/EDGE radio access network
US7311246B2 (en) 2004-11-26 2007-12-25 Sony Corporation Method and system for transmitting electronic value information
WO2008048836A1 (en) * 2006-10-13 2008-04-24 Microsoft Corporation Upnp authentication and authorization
US7882356B2 (en) 2006-10-13 2011-02-01 Microsoft Corporation UPnP authentication and authorization
WO2010022650A1 (en) * 2008-08-29 2010-03-04 华为技术有限公司 Clock synchronization method, device and system

Also Published As

Publication number Publication date
FI974186A (en) 1999-05-11
WO1999025093A3 (en) 1999-07-29
US6931528B1 (en) 2005-08-16
AU1035999A (en) 1999-05-31
FI104666B (en) 2000-04-14
TW380346B (en) 2000-01-21
FI974186A0 (en) 1997-11-10

Similar Documents

Publication Publication Date Title
US6931528B1 (en) Secure handshake protocol
US7542569B1 (en) Security of data connections
US7020778B1 (en) Method for issuing an electronic identity
CN101459506B (en) Cipher key negotiation method, system, customer terminal and server for cipher key negotiation
EP1128597B1 (en) Method and arrangement in a communication network
JP4709815B2 (en) Authentication method and apparatus
US8515078B2 (en) Mass subscriber management
US7707412B2 (en) Linked authentication protocols
KR100832893B1 (en) A method for the access of the mobile terminal to the WLAN and for the data communication via the wireless link securely
US8122250B2 (en) Authentication in data communication
EP1394982B1 (en) Methods and apparatus for secure data communication links
US7979707B2 (en) Secure seed generation protocol
US20030210789A1 (en) Data transmission links
JP2012110009A (en) Methods and arrangements for secure linking of entity authentication and ciphering key generation
GB2404126A (en) Secure communications using a secret key valid for a certain period and verified using a time stamp
JP2005515701A6 (en) Data transmission link
WO2003032575A2 (en) Method and system for providing client privacy when requesting content from a public server
KR20010108150A (en) Authentication enforcement using decryption and authentication in a single transaction in a secure microprocessor
US20120226909A1 (en) Method of Configuring a Node, Related Node and Configuration Server
KR100401063B1 (en) the method and the system for passward based key change
Godfrey A Comparison of Security Protocols in a Wireless Network Environment
CN114531235B (en) Communication method and system for end-to-end encryption
JP2003338812A (en) Encryption system
Wang Security issues to tele-medicine system design
EP1480374B1 (en) Access authentication

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AL AM AT AT AU AZ BA BB BG BR BY CA CH CN CU CZ CZ DE DE DK DK EE EE ES FI FI GB GD GE GH GM HR HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SK SL TJ TM TR TT UA UG US UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SZ 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
AK Designated states

Kind code of ref document: A3

Designated state(s): AL AM AT AT AU AZ BA BB BG BR BY CA CH CN CU CZ CZ DE DE DK DK EE EE ES FI FI GB GD GE GH GM HR HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SK SL TJ TM TR TT UA UG US UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SZ 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

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: KR

WWE Wipo information: entry into national phase

Ref document number: 09554112

Country of ref document: US

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

Ref country code: CA