![](bg2.png)
2 MOTIVATION
Today, e-commerce applications have more specific
needs such as secure data storage and evidence
management. Implementing a non-repudiation
service in a security protocol will lead to more
interoperability between applications and can
provide standard evidence that critical transactions
have taken place. The proof is an S/MIME (Dusse,
1998), PKCS7 (Kalishi, 1998) or XML-DSIG
(W3C, 2000) signed data based on the proposed
IETF Internet standards. The main reasons for
integrating a signature module in the SSL/TLS
security protocol are as follows:
1. Modularity of TLS protocol
The first motivation of our proposal is the
modular nature of SSL/TLS protocol. Since
SSL/TLS is developed in four independent
protocols, our approach can be added without
any change to the SSL/TLS protocol and with
a total reuse of pre-existing SSL/TLS
infrastructure and implementation. To
demonstrate, we implemented SSL-SIGN as a
single package that can be optionally used to
deliver the non-repudiation service and
without any change in other SSL/TLS
protocols. Our work was also improved by the
standardization of (Blake-Wilson, 2003) that
we propose to use to keep interoperability with
existing SSL/TLS versions.
2. Generic non-repudiation service
The first objective of SSL-SIGN is to provide
a generic non-repudiation service that can be
easily used with protocols. SSL-SIGN will
minimize both design and implementation of
the signature service and that of the designers
and implementators who wish to use this
module. Thus, we choose to implement the
signature module with an SSL-like function
(ssl_sign_write & ssl_sign_read) with a
number of input parameters to simplify its
integration with applications.
3. Digital signature of E-business transactions
E-business applications are being more exigent
in security needs and there is an insistent demand
for an electronic equivalent to the handwritten
signature. The technologies needed for this
purpose (S/MIME, PKCS7v1.5, CMS (Housley,
2002)) have been available for several years but
are totally independent of the security protocols
in use like SSL and IPSEC. Integrating a data
signature module in a security protocol especially
SSL/TLS will lead to more secure transaction
between entities and can provide evidence that
can be later presented to a third party to resolve
any disputes between them.
3 THE SSL/TLS PROTOCOL
This section gives a short introduction into the
SSL/TLS protocol. It also explains the specification
of the SSL/TLS handshake protocol and the
proposed SSL/TLS Extensions. However, a detailed
specification of SSL/TLS and SSL/TLS Extensions
is outside the scope of this paper. We only introduce
the two concepts with enough detail to put the
description of our design and architecture in context.
3.1 Background
The standard SSL/TLS Protocol consists of two
layers: the TLS Record Protocol and the TLS
Handshake Protocol. The TLS Record takes
messages to be transmitted from various high level
protocols and encapsulates them in a secure
connection with data integrity and confidentiality.
The TLS Handshake Protocol allows the peer
entities located at both ends of the secure channel to
authenticate one another, to negotiate encryption
algorithms and to exchange secret session keys for
encryption. Once this phase in finished, a protected
connection is established.
3.2 The SSL/TLS Handshake
Protocol
TLS handshake is the most complex part of the
SSL/TLS protocol. In the TLS handshake, the two
entities will create a shared secret and authenticate
each other. However, in most cases, only the server
is authenticated.
In a typical full handshake (figure 1), the client
will begin the TLS exchange by sending a
ClientHello message which contains a random
number (R1), a session identifier (S_ID), a
compression list (compression_list) and a list of
supported cipher suites (cipher_list). The server
sends the ServerHello message that contains a
generated random number (R2), a session identifier
and the selected cipher suite. The server also sends,
his X509 certificate message containing the server’s
public key. The client verifies the server’s public
key and generates a 48-byte random number, called
the pre-master-secret, encrypts it using the server
public key and sends it to the server in the
ClientKeyExchange message. Upon receiving the
ClientKeyExchange message, the server decrypts the
ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS
306