2009 International Symposium on Information Engineering and Electronic Commerce
Improved TLS Handshake ProtocolsUsing Identity-
based Cryptography
Changyan Peng, Quan Zhang and Chaojing Tang
School of Electronic Science and Engineering
National University of Defense Technology
Changsha, Hunan, China
pengchangyan@gmail.com
Abstract — Transport layer security (TLS) protocol is widely
used in e-business and information systems for providing security
attributes such as authentication, confidentiality and integrity.
However, the certificate-based mechanism which is adopted by
most TLS handshake protocols results in complex certificate
management overheads and long handshake latency. To
overcome these disadvantages, a series of handshake protocols
were presented that applies identity-based encryption, signature,
signcryption, and authenticated key agreement schemes
respectively. Security analysis indicates that the identity-based
protocols have equivalent security level but more security
attributes than the standard certificate-based schemes and the
ones proposed in the literature so far. Experiment results show
that our schemes have commensurate cryptographic computation
overheads comparing with other schemes, but achieve shorter
handshake latency especially in bandwidth-limited environments
because of less communication traffic.
Keywords - transport layer security; handshake protocol;
identity-based cryptography; bilinear pairing
I. INTRODUCTION
With the rapid development of e-business and information
systems, transport layer security (TLS) [1] protocol is broadly
deployed in order to protect plenty of network application
protocols. As an evolvement and standardization of secure
socket layer (SSL) [2], TLS supports security services with
authentication, confidentiality and integrity between two
networking applications. Handshake protocol is the core of
TLS and the pre-requisite of secure communications, which
accomplishes crypto algorithm negotiation, authentication,
session key agreement, and so on.
Security and performance are the two most critical factors
in TLS applications. However, most TLS implementations
utilize public-key certificate mechanisms, which introduce the
transport and process of certificates in the client-server
authentication procedure, thus make the handshake protocol
suffer from heavy overheads and long duration. In recent years,
identity-based cryptography (IBC) [3] is developing at a rapid
pace both in academic research and practical application, and
has also been employed in many fields of information security.
IBC-based TLS handshake protocols mainly extend from
standard protocols in the aspects including crypto algorithms,
key exchange, key management mechanism, et al. Because of
978-0-7695-3686-6/09 $25.00 © 2009 IEEE
DOI 10.1109/IEEC.2009.33
certificates are needless any more, IBC-based schemes achieve
less communication overheads and shorter handshake latency.
Unfortunately, the IBC-based protocols proposed in the
literature so far [4] [5] are merely simple extensions of TLS in
the GRID environment, and still suffer from too many
overheads both in computation and communication.
In this paper, four identity-based cryptography primitives
are adaptively applied to TLS handshake protocol, then
security analysis and simulation experiments are conducted to
validate the better effects and efficiencies. The remainder of the
paper is organized as follows. Section II provides an overview
of TLS handshake protocol and identity-based cryptography.
Our IBC-based protocols are detailedly presented in section III.
In Section IV and V, results of security analysis and simulation
experiments are described. Finally, section VI summarizes our
conclusions and discusses future work.
II. AN OVERVIEW OF TLS AND IBC
A. TLS and handshake protocol
TLS comprises two main components, namely handshake
protocol and record protocol. The former is responsible for
negotiating and establishing secure connections, while the latter
is responsible for securing data transmission. During the
establishment of a TLS session, handshake protocol negotiates
a common cipher suit, authenticates the server and the client
(optional), and agrees on necessary session keys to protect the
communication traffic. After a success handshake, the session
turns into the data transfer phase. The record protocol uses
symmetric-key algorithms for bulk encryption, thus application
data can be transported in a secure style.
Fig. 1 shows the total protocol operations of a standard TLS
handshake [1]. The procedure is described in four steps:
Step 1: The client C and the server S exchange random
nonces (used for replay protection) and negotiate a common
cipher suite with the ClientHello and the ServerHello messages.
Step 2: S sends its public-key certificate in the Certificate
message and sends the ServerKeyExchange message for key
agreement. If S requests client authentication, it sends a
CertficateRequest message listing acceptable certificate types
and certificate authorities. S finishes the Hello procedure with
the ServerHelloDone message.
135
 Step 3: C verifies the validity of S’s certificate. If public-
key certificate is requested by S, C sends it in the Certificate
message. Then C sends the ClientKeyExchange message to
finish the agreement on the session key and sends the
CertificateVerify message to be verified by S. Now S and C can
compute a session key for bulk encryption in record protocol.
Step 4: In the end, both the client and the server send the
ChangeCipherSpec message while switching to the new cipher
algorithm, and send the Finished message to complete the
handshake protocol.
Both symmetric and asymmetric cryptography have been
used for authentication between the server and the client.
Though symmetric cryptographical methods using the pre-
shared key mechanism [6] feature little computation and
communication overheads, it suffers poor scalability and isn’t
fit for large-scale applications.
Asymmetric cryptography mechanisms including RSA and
Elliptic Curve Cryptosystem (ECC) have been used in TLS,
and related protocols have been standardized. Comparing with
RSA, ECC achieves equivalent security strength with smaller
keys. For instance, 163-bit ECC is as secure as 1024-bit RSA.
ECC is especially attractive in bandwidth-constrained wireless
environments because smaller keys result in power, bandwidth
and computational savings [7]. In these schemes, public key
infrastructure (PKI) should be deployed to relate a user’s
certificate to his identity. However, certificate-based schemes
introduce much computation, traffic and delay because of
certificate query, path construction and exchange.
Figure 1. TLS handshake protocol.
B. IBC and its application to TLS
The basic idea of IBC is that public keys can be derived
from arbitrary strings such as e-mail, IP or MAC addresses.
Meantime, private keys are generated and distributed by a
trusted authority – Private Key Generator (PKG) which is
PKI’s counterpart. Since IBC is certificate-free, it is more
lightweight than PKI.
IBC was first introduced by Shamir in 1984. After the
seminal discovery of a practical and secure identity-based
encryption (IBE) scheme [3] which uses pairings over elliptic
curves by Boneh and Franklin in 2001, a lot of identity-based
schemes come forth, which mainly focus on identity-based
encryption, identity-based signature (IBS) [8], identity-based
signcryption (IBSC) [8], and identity-based authenticated key
agreement (IBAKA) [9]. We first introduce pairings briefly.
136
Let G1 denote a cyclic additive group of some large prime
order q and G2 a cyclic multiplicative group of the same order.
A pairing is a map: e : G1 u G1 o G2 such that for all P, Q Î G1
and all a, b Î Z q* , e(aP, bQ) = e( P, Q) ab . Note that e is also
symmetric, i.e., e( P, Q ) = e(Q, P) . Typically, the map is
derived from the Weil, or the Tate, or other pairings on an
elliptic curve over a finite field.
IBC enjoys the features that public key cryptography
possesses without the need of certificate and the flaws it brings,
and has already been applied to many areas of network and
information security. Lim first proposed a handshake protocol
[4] that simultaneously used IBE and IBS, which was applied
to GRID for users’ authentication and authorization by the
servers. Li extended the protocol in a hierarchical structure and
argued that the protocol is more efficient than the traditional
schemes according to the results of simulation tests [5].
However, the two schemes have several deficiencies. First,
they are just extensions of TLS in GRID, and lack for
systematization and generalization. Second, they still suffer
from too many overheads in computation and communication.
At last, they are only designed for mutual authentication, and
the situation without client authentication isn’t considered. Our
protocols are preferable to solve these problems.
III. IBC-BASED TLS HANDSHAKE PROTOCOLS
According to different application scenarios and security
requirements, four kinds of handshake protocols are designed
using IBE, IBS, IBSC and IBAKA respectively. It is supposed
that PKG has already finished the generation and distribution
of system parameters and users’ private keys before the
protocol begins. We also assume that the client has the key pair
( QC , SC ) while the server has ( QS , S S ).
The proposed protocol is depicted in Fig. 2. As seen in the
figure, both the server S and the client C didn’t have to send the
Certificate message comparing with the certificate-based
schemes because public key can be derived from the identity. If
client authentication is requested, the server sends the
IdentityRequest message, and then the client sends the
IdentityVerify message for verification. From the description
above, it can be inferred that both the rounds and traffic of the
protocol decrease. Although the content and meaning of the
messages is different, main procedure is similar in different
protocols based on four cryptography primitives. So only the
different parts (step 2 and 3) in the protocol will be concerned
for simplifying the following description, while other steps that
are similar to section IIA will be omitted.
Figure 2. IBC-based TLS handshake protocol.
A. IBE-based handshake protocol
The Diffie-Hellman key exchange protocol is used in our
new protocols to agree on a session key, and most of the
messages have to be extended for supporting new protocols.
Step 2: The server S selects a random number a, and then
computes g a . If client authentication is needless, S sends g a in
the ServerKeyExchange message for key agreement. On the
contrary, S encrypts g a using the public key QC of the client C,
and sends the result EQc [ g a ] in the message. In addition, S sends
the IdentityRequest message that declares client authentication
is requested, and sends the ServerHelloDone message.
Step 3: C gets g a directly or gets it by decryption. C selects
a random number b, and then computes g b . C encrypts it
using QS , and sends EQs [ g b ] in the ClientKeyExchange message.
Also C sends the IdentityVerify message for verification. At the
moment, C and S can compute the session key respectively. C
computes K CS ( g a )b , while S computes K SC ( g b ) a after S
gets g b by decryption. Since K CS K SC , a common session key
is deduced.
It can be seen that authentication is arrived at by the IBE
scheme. At last, a secure connection is established.
B. IBS-based handshake protocol
Mutual authentication between the client and the server can
also be achieved by IBS schemes. The IBS-based handshake
protocol is described below.
Step 2: The server S selects a random number a, and
computes g a . S signs it by its private key S S , and sends g a and
the signature result Sig Ss [ g a ] in the ServerKeyExchange
message. The rest operation is similar to the IBE-based
protocol.
Step 3: The client C verifies the signature by public key QS .
If it is invalid, C quits the protocol. Otherwise C selects a
random number b, computes g b , and then sends it in the
ClientKeyExchange message. If client authentication is
requested, C signs g b by its private key SC , and appends it in
the forementioned message.
Finally, the session key can be verified by the Finished
message.
C. IBSC-based handshake protocol
Li proposed an IBC-based handshake protocol in which
mutual authentication and key agreement is attained by
combining IBE and IBS schemes together. Actually the
combination can be replaced by identity-based signcryption
with more efficiency. It must be pointed out that the protocol
only fits the situation with mutual authentication.
Step 2: The server S selects a random number a, and
computes g a . S signcrypts g a by taking as input necessary
system parameters, S’s private key S S and the client C’s public
key QC . Then S sends the ciphertext result in the
ServerKeyExchange message. The IdentityRequest message is
not required any more.
Step 3: The client C unsigncrypts the message by taking as
input system parameters, C’s private key SC and S’s public
137
key QS . If the verification result is false, C quits the protocol.
Otherwise C selects a random number b, computes g b , and
then sends it to S in the ClientKeyExchange message. From
then on, a session key can be computed simultaneously.
The computation load of IBSC schemes is less than that of
the combination of the IBE and the IBS schemes, which will be
evaluated later.
D. IBAKA-based handshake protocol
Identity-based authenticated key agreement protocol
provides mutual key authentication using pairings. The
intrinsic feature of IBAKA makes it align well with the mode
of mutual authentication. The IBAKA scheme proposed by
Chen [9] is adopted in the protocol below.
Step 2: The server S selects a random number a, and
computes TS aQS . Then S sends TS to the client C in the
ServerKeyExchange message. The IdentityRequest message is
also omitted.
Step 3: The client C randomly selects a number b, and then
computes TC bQC . C sends it to S in the ClientKeyExchange
message. After that C computes K CS e(TS  bQS , SC ) , while S
gets K SC e( S S , TC  aQC ) . According to [9], K CS is equal to K SC ,
and a common session key can be arrived at.
The remarkable feature of the protocol is that it uses an
IBAKA protocol instead of a DH one. The protocol can also
adopt other IBAKA protocols after adequate modifications.
IV. SECURITY ANALYSIS
The security of IBC is based on the hardness of several
problems such as the bilinear Diffie-Hellman problem, the
computational Diffie-Hellman problem and so on. No
algorithm is known to be able to efficiently solve any of them
so far. More comprehensive description of security analysis of
IBC can be referred to [3] [8] [9].
On the basis of security mechanisms of TLS, the proposed
protocols attain several basic security properties including
authentication, confidentiality and integrity. In addition, the
protocols achieve the following security merits and are more
secure than the quondam ones.
Forward security: Owing to the freshness of session keys
which are derived from randomly chosen numbers by the client
and the server, even if long term secret keys are disclosed to
any adversary, session keys established before the compromise
would not be exposed.
Key authentication: The features of mutual authentication
between the client and the server assure that only the
participants know the session key.
Mutual key agreement: Key agreement is finished by the
close cooperation between the client and the server.
Resistance to the man-in-the-middle attack: The virtue of
the IBC schemes that public keys are derived from the
identities naturally guarantees that the IBC-based protocols are
resistant to the man-in-the-middle attack if long term keys are
not compromised.
 V. PERFORMANCE EVALUATION
In this section, two metrics including crypto processing
time and handshake duration are used for performance
evaluation of different protocols in the handshake phase.
The simulation platform was made up of five computers in
a local area network. The computers were all equipped with
Pentium D 3.0G CPU, 2 GB memory, and the Windows XP
professional SP3 operating system. The public key algorithms
IBSC-based scheme. The IBE-based scheme and Li’s scheme
take longer processing time, while the IBS-based and IBAKA-
based scheme achieve less time. It can also be seen that the
load of the server is far less than that of the client in the IBSC-
based scheme, which would greatly improve the capability of
the server because it can accept more client connections in the
same conditions.
8
RSA
7 ECC

with equivalent security level were chosen, including 1024-bit

IBE
IBS

AverageProcessingTime˄ ms˅
6

RSA, 163-bit ECC, and 512-bit IBC. The implementations of 5

the RSA-based and ECC-based protocols come from OpenSSL 4

0.9.8g [10], while the IBC-based protocols adopt the 3

algorithms in PBC 0.4.10 [11]. 1

0
Client Server

A. Crypto processing time

a˅ Without Client Authentication

The computation loads of all protocols are compared by 14
RSA

public-key operations that most of the crypto processing time is

ECC
12
IBE
IBS

AverageProcessingTime˄ ms˅
spent on. Encryption/decryption and signature/verification are 10 IBE+IBS
IBSC
IBAKA

concerned in RSA while ECDSA verification and ECDH key 8

exchange are considered in ECC. In IBC schemes, pairing 6

operation, multiplication in G1, and exponentiation in G2 are 4

focused on. Other loads related to hashing, symmetric key 2

encryption and so on are omitted. The main crypto operations 0

Client Server
b˅ Mutual Authentication

are listed in Table I and Table II.

Figure 3. Crypto processing time.
TABLE I. MAIN CRYPTO OPERATIONS WITHOUT CLIENT
AUTHENTICATION As a result of the high cost of pairing operation, IBC-based
schemes incur more overheads as comparing with the RSA-
Client Server based and the ECC-based schemes. However, performance of
RSA RSAverify  RSAencrypt RSAdecrypt usual computers enhances quickly, and the processing time will
ECC ECDSAverify  ECDH op ECDH op certainly decrease. Also, as an emerging technique, IBC is
under rapid development, and many optimization algorithms
IBE 1P  1G1  1G2  1P  have been reported with more efficient implementations. Hence,
IBS 1P  1G1  2G1  the cost of ID-based schemes can be expected to fall.

TABLE II. MAIN CRYPTO OPERATIONS WITH MUTUAL AUTHENTICATION B. Handshake duration
Besides the crypto processing time, the overall handshake
Client Server
duration also involves other delays due to message parsing and
RSA RSAverify  RSAencrypt  RSAsign 2* RSAverify  RSAdecrypt
network latency for message transmission. Certificate parsing
ECC ECDSAverify  ECDH op ECDSAverify  ECDH op spends most of the parsing time among all messages, especially
IBE 2 P  1G1  1G2  2 P  1G1  1G2  in the condition with a long certificate chain. Generally, a
standard X.509 certificate is about 1.5KB in size. The IBC-
IBS 1P  3G1  1P  3G1  based schemes avoid the parsing and verification of certificates,
IBE+IBS 2 P  1G1  1P  1G1  3G2  and efficiently reduce the time of message parsing. Handshake
2 P  1G2  2G1  1G2 
duration is also closely related to network throughput. When
IBSC
the throughput is as low as constrained channel conditions such
IBAKA 1P  2G1  1P  2G1  as wireless communications, the transport of certificate chain
The results shown in Fig. 3 are the average crypto will result in more latency. Comparing with the certificate-
processing time of ten operations of different protocols. based schemes, the IBC-based ones cut down the cost of
certificate transport and achieve less latency.
1) Without client authentication. As seen in Fig. 3 a), the
processing time of the client is always longer than that of the Fig. 4 depicts the average handshake duration of different
server. In all schemes, the IBE-based one spends the most time protocols as the network throughput changes.
both in the client and the server. It is remarkable that the As expected, handshake duration increases when the
processing time of the server is rather short in the IBS-based network throughput decreases. Because the transmitted data
schemes. amount of the IBC-based schemes is much less than that of the
2) Mutual authentication. Fig. 3 b) indicates that the RSA-based and the ECC-based one, the proposed schemes
processing time of both sides is almost the same except the achieve less duration at low network throughput. In the

138
condition of mutual authentication, the decrease ratios are even 2) Mutual authentication. From Fig. 5 b), it can be seen
higher because the amounts of certificate messages are doubled. that the IBE-based scheme and Li’s scheme perform worse for
they need more crypto processing time and larger amounts of
250
RSA transmitted data. The IBS-based and IBSC-based scheme
200
ECC
IBE accomplish better than the former two schemes. Among all the
IBC-based schemes, the IBAKA-based one achieves the best
IBS
Handshake Duration˄ ms˅

150 performance. It fully utilizes the virtue of the identity-based

cryptography, and ideally fulfills the peculiar requirement of
100
mutual authentication, which makes it arrive at less processing
50
time and communication traffic.
From the analysis above it can be inferred that the proposed
0
0 200 400 600 800 1000 1200 1400
Network Throughput (Kbps)
1600 1800 2000 IBC-based protocols efficiently improve the performance of
a˅ Without Client Authentication
TLS handshake procedure and particularly suit for wireless
400
environments with low network throughput.
RSA
350 ECC
IBE

VI. CONCLUSIONS
IBS
300
IBE+IBS
Handshake Duration˄ ms˅

IBSC
250 IBAKA

200
Four improved TLS handshake protocols applying different
150
IBC primitives from pairings were designed in order to
100 overcome the shortages of complex certificate management and
50 long handshake latency which exists in current widely-used
0
0 200 400 600 800 1000 1200 1400 1600 1800 2000
TLS protocol. Security analysis asserts that the IBC-based
Network Throughput (Kbps)
b˅ Mutual Authentication protocols have equivalent security level but more security
attributes than the schemes in the literature until now.
Figure 4. Handshake duration. Experiment results show that our schemes have commensurate
crypto computation overheads comparing with other schemes,
Since the handshake duration of different schemes is nearly but achieve shorter handshake latency especially in bandwidth-
undistinguishably, Fig. 5 is used to more clearly compare the limited environments.
duration under three typical network throughput values, 400K,
1000K and 2000K bps. We are now in the process of designing more secure
handshake protocols with perfectly forward security and
60
RSA anonymity, and will conduct further study for performance
50
ECC
IBE optimization and application practicability of our schemes.
IBS
Handshake Duration˄ ms˅

40

REFERENCES
30
[1] T. Dierks and C. Allen, “The TLS protocol version 1.0,”
20 http://www.ietf.org/rfc/rfc2246.txt.
[2] A. Frier, P. Karlton and P. Kocher, “The SSL protocol version 3.0,”
10
http://wp.netscape.com/eng/ssl3/draft302.txt.
0
400 1000 2000
[3] D. Boneh and M. Franklin, “Identity-based encryption from the Weil
Network Throughput (Kbps)
a˅ Without Client Authentication
pairing,” CRYPTO 2001, LNCS 2139, pp. 213-229, 2001.
[4] H.W. Lim and K. Paterson, “Identity-based cryptography for grid
100
RSA
security,” Proc. e-Science'05, Melbourne, Australia, 2005.
90 ECC
IBE [5] H.W. Li, S.X. Sun and H.M. Yang, "Identity-based authentication
80 IBS
IBE+IBS protocol for grid," Journal of Systems Engineering and Electronics, vol.
Handshake Duration˄ms˅

70

60
IBSC
IBAKA 19, pp. 860-865, 2008.
50 [6] F.C. Kuo, H. Tschofenig and F. Meyer, “Comparison studies between
40 pre-shared and public key exchange mechanisms for transport layer
30
security,” Proc. IEEE Global Internet Symposium 2006, in conjunction
20
with INFOCOM 2006, Barcelona, Spain, 2006.
10

0
[7] V. Gupta, S. Gupta, and S. Chang, “Performance analysis of elliptic
400 1000
Network Throughput (Kbps)
2000
curve cryptography for SSL,” Proc. of WiSe'02, Atlanta, USA, 2002.
b˅ Mutual Authentication

[8] P.S.L.M. Barreto, B. Libert, N. McCullagh and J.J. Quisquater,

Figure 5. Handshake duration at typical throughout. “Efficient and provably-secure identity-based signatures and
signcryption from bilinear maps,” ASIACRYPT 2005, LNCS 3788, pp.
515–532, 2005.
1) Without client authentication. As depicted in Fig. 5 a),
[9] L.Q. Chen and C. Kudla, “Identity based authenticated key agreement
the IBS-based scheme always achieves shorter duration than protocols from pairings,” HP Technical Report, 2003.
the IBE-based one because of its less computation loads. The [10] E.A. Young, “OpenSSL 0.9.8g,” http://www.OpenSSL.org/.
difference among the four schemes is not apparent at high
[11] D. Boneh, M. Franklin and B. Lynn, “The pairing-based cryptography
network throughput. library,” http://crypto.stanford.edu/pbc/.

139