 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates generally to computer networks, and more
particularly, to securing private communications between networked
computers.
2. Description of the Related Art
There is an increasing need for security in communications over public and
private networks. The expanding popularity of the Internet, and especially
the World Wide Web, have lured many more people and businesses into the
realm of network communications. There has been a concomitant rapid growth
in the transmission of confidential information over these networks. As a
consequence, there is a critical need for improved approaches to ensuring
the confidentiality of private information.
Network security is a burgeoning field. There are well known encryption
alorithms, authentication techniques and integrity checking mechanisms
which serve as the foundation for today's secure communications. For
example, public key encryption techniques using RSA and Diffie-Hellman are
widely used. Well known public key encryption techniques generally
described in the following U.S. Patents: U.S. Pat. No. 4,200,770 entitled,
Cryptographic Apparatus and Method, invented by Hellman, Diffie and
Merkle; U.S. Pat. No. 4,218,582 entitled, Public Key Cryptographic
Apparatus and Method, invented by Hellman and Merkle; U.S. Pat. No.
4,405,829 entitled Cryptographic Communications System and Method,
invented by Rivest, Shamir and Adleman; and U.S. Pat. No. 4,424,414
entitled, Exponentiation Cryptographic Apparatus and Method, invented by
Hellman and Pohlig. For a general discussion of network security, refer to
Network and Internetwork Security, by William Stallings, Prentice Hall,
Inc., 1995.
In spite of the great strides that have been made in network security,
there still is a need for further improvement. For example, with the
proliferation of heterogeneous network environments in which different
host computers use different operating system platforms, there is an
increasing need for a security mechanism that is platform independent.
Moreover, with the increasing sophistication and variety of application
programs that seek access to a wide range of information over networks,
there is an increasing need for a security mechanism that can work with
many different types of applications that request a wide variety of
different types of information from a wide variety of different types of
server applications. Furthermore, as security becomes more important and
the volume of confidential network transactions expands, it becomes
increasingly important to ensure that security can be achieved
efficiently, with minimal lime and effort. The present invention meets
these needs.
SUMMARY OF THE INVENTION
In one aspect, the invention provides a sockets application program
interface bound to a security protocol which is layered between an
application layer and transport layer. The socket interface is widely used
in network environments. This facilitates integration of the invention
into a wide range of host machines connected to a network. Placing the
security protocol between the application layer and the transport layer
enables many different types of application programs to employ the new
security with only slight modification. Moreover, the security protocol
can communicate with many different operating system platforms without
requiring operating system changes.
In another aspect, the invention provides a more efficient handshake
protocol and session key generation scheme. When a client and server
application first establish a secure sockets connection, in accordance
with the invention, they engage in a novel handshake protocol in which
they negotiate security procedures, produce a master key and generate
session keys to be used to encrypt and decrypt information transferred
through the sockets connection. If there are multiple connections between
the client and server applications during a prescribed time interval, then
the handshake protcol may elect to re-use a previously negotiated master
key, thereby obviating the need to generate a new master key, and saving
time in establishing a secure connection.
These and other features and advantages of the invention will become more
apparent from the following description of exemplary embodiments thereof,
as illustrated in the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a pictorial diagram of a computer network;
FIG. 2 is an illustrative drawing of a computer of the network of FIG. 2;
FIG. 3 is an illustrative diagram of an electronic document with
hyperlinks;
FIG. 4 illustrates client/server message flow, in accordance with a present
embodiment of the invention, using the RSA protocol where no
session-identifier is found;
FIG. 5 shows client/server message flow, in accordance with a present
embodiment of invention, using the RSA protocol where there is a shared
session-identifier;
FIG. 6 shows client/server message flow, in accordance with a present
embodiment of the invention, using the RSA protocol and there is a common
session-identification and client authentication is requested;
FIG. 7 shows client/server message flow, in accordance with a present
embodiment of the invention, using a Diffie-Hellman key exchange where
there is shared session-identification;
FIG. 8 shows a generalized representation of a typical Internet protocol
stack which resides in each host machine (client and server) and a typical
subnet protocol stack;
FIG. 9 is an illustrative view of client side and server side application
layer and transport layer programs and protocol structures in accordance
with a present embodiment of the invention;
FIG. 10 is an illustrative view of client and server side application layer
and transport layer programs and protocol structures which employ the
Winsock DLL in conjunction with the SSL library in accordance with an
alternative embodiment of the invention;
FIG. 11 is an illustrative view of client and server side application layer
and transport layer programs and protocol structures which employ a
variation of the Winsock DLL in conjunction with the SSL library in
accordance with another alternative embodiment of the invention; and which
employ a variation of the Winsock DLL in conjunction with the SSL library
in accordance with another alternative embodiment of the present
invention; and
FIG. 12a, 12b and 12c are an illustrative flow diagram showing an example
of the process involved in secure client-server communication in
accordance with a present embodiment of the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
The present invention comprises a novel process and related computer
program embodied in a computer useable medium for ensuring private
communications between application programs running on different
computers. The following description is presented to enable any person
skilled in the art to make and use the invention. Descriptions of specific
applications are provided only as examples. Various modifications to the
preferred embodiment will be readily apparent to those skilled in the art,
and the general principles defined herein may be applied to other
embodiments and applications without departing from the spirit and scope
of the invention. Thus, the present invention is not intended to be
limited to the embodiment shown, but is to be accorded the widest scope
consistent with the principles and features disclosed herein.
A. The Client--Server Model
This section provides a general description of exemplary host computers
(client and server) and the network environment in which they operate.
FIG. 1 is an illustrative pictorial diagram of a typical well known
computer network 100 such as the Internet, for example. The computer
network 100 includes small computers, such as computers 102, 104, 106,
108, 110 and 112 and large computers, such as computers A and B, commonly
used as servers. In general, small computers may be "personal computers"
or workstations and are sites where a human user operates the computer to
make requests for data or services from other computers on the network.
Often, the requested data resides in the large computers referred to as
servers. In this scenario, the small computers are client systems and the
large computers are servers. In this specification, the term "client"
refers to a computer's general role as a requester of data or services,
and the term "server" refers to a computer's role as a provider of data or
services. In general, the size of a computer, in terms of its storage
capacity and processing capability, does not necessarily affect its
ability to act as a client or server. Further, it is possible that a
computer may request data or services in one transaction and provide data
or services in another transaction, thus changing its role from client to
server or vice versa.
The illustrative drawing of FIG. 2 shows an exemplary well known client
computer system 140. It includes a display device 142 (such as a monitor),
a display screen 144, a cabinet 146 (which encloses typical computer
components such as a CPU, RAM, ROM, video card, hard drive, network
adapter card, serial ports, etc.), a keyboard 148, a mouse 150, and
perhaps a modem 152. The modem, for example, allows the client computer
system to be connected to an Interact network via phone lines, for
example.
B. HTML Documents and HTTP
This section describes the use of identification tags to designate
hyperlinks using HTML documents and HTTP as an example. As explained in
the specification, however, the present invention applies to other types
of documents as well, such as Adobe PDF, voice documents and motion
picture and still picture documents.
In order to make the transfer of data from one arbitrary computer to
another possible, uniform protocols have been developed. An early attempt
at creating a uniform protocol for data transfers over the Internet is
File Transfer Protocol (FTP). More recent protocols include Gopher
developed at the University of Minnesota and the World Wide Web project
which defined the HyperText Transfer Protocol (HTTP). HTTP has been
defined by an Internet Draft dated Nov. 5, 1993 and subsequent drains.
By providing uniform protocols so that clients may request objects and
servers may deliver objects to clients, computers on the Internet are able
to easily transfer different types of information such as text and images.
By using the HyperText concept an efficient user interface is provided to
a human user that allows the user to discover what information is
available and to request the information.
An illustration of the HyperText concept is shown in FIG. 3. In FIG. 3, a
portion of document 10 is shown. This is symbolic of text which would
appear, for example, on a computer display screen as viewed by a user.
Text portion 10 includes simple text and HyperText, the latter being text
associated with a link. In text portion 10 there are two HyperText phrases
associated with links. The first one is "client-server model" while the
second is "Internet". The fact that these text phrases are associated with
links is indicated by the underlining of the text phrases.
The first phrase "client-server model" is linked to text document 12 by
means of link 16. Text document 12 is a separate document from text
document 10. Text document 12 may reside in the same computer system as
text document 10 or text document 12 may be in a remote location such as
in a storage device connected to a server that is geographically removed
from the computer system that a user is operating to view document 10.
In practice, links such as 16 can be implemented in a document, such as
document 10, by using a special text format that allows embedded tags or
other symbols within the text to specify a link. These embedded tags are
not displayed to a user reading the text. One popular tag syntax is part
of the HyperText Markup Language (HTML) and uses a Uniform Resource
Locator (URL) form of addressing. The URL is unique for each object on the
network. Objects may be text documents, images, sounds, programs or other
forms of digital data. In FIG. 3, documents 12 and 14 are text objects
pointed to by HyperText links. A HyperText link can be specified in a
number of ways with HTML's. The use of URLs is merely a currently popular
standard way to specify links.
Once specified, link 16 allows a user who is viewing document 10 to easily
retrieve document 12. The user is provided with a simple and obvious
indication that the phrase "client-server model" is a HyperText link to
another document by the underlining. Since the phrase is one that is being
used in context within the document the user is reading, the user may make
a timely decision to learn more about the subject of the HyperText phrase.
For example, in FIG. 3, the HyperText phrase "client-server model" links
to document 12 which provides a further description of a client-server
model.
A common way for the user to access document 12 while viewing document 10
on a display screen of a computer system is to move a pointer on the
display screen by means of an input device, such as a mouse, so that the
pointer is over the phrase "client-server model". The user then depresses
the mouse button to "click on" the phrase. This causes the user's computer
system to retrieve document 12 either from local storage or from a remote
location connected to the user's computer via a network such as the
Internet. Once document 12 is retrieved, the user's computer system
displays the document, or a portion of the document, on the user's display
screen.
Similarly, the second phrase in document 10, "Internet . . . allows the
user to access document 14 by link 20. In other words, if the user clicks
on the HyperText phrase "Internet" document 14, or a portion of document
14, is displayed on the user's screen. HyperText documents can have nested
linking. Document 12 is the target of a HyperText link and may, itself,
have HyperText links within it as shown in FIG. 3 where link 18 is
associated with HyperText "Internet" in document 12. Note that the same
word or phrase may function as a link in different documents and different
documents may link to a common document. Many variations on HyperText
linking from that shown in FIG. 3 are possible.
C. Overview of Sockets API and Secure Sockets Layer (SSL) Interface
A current embodiment of the invention provides a security protocol layered
beneath an application protocol used by an application program to
communicate over a network. The security protocol is implemented through a
"Secure Sockets Layer" library (the SSL library) which is bound to the
application program. The SSL library modules emulate the widely known
"sockets" application program interface (API). The sockets API is
supported by most major operating systems including UNIX and Microsoft
Windows. For a general discussion of the sockets interface, refer to,
Internetworking with TCP/IP, volume 1, by Douglas E. Comer, Prentice-Hall,
Inc. 1995, pages 335-364.
The SSL library establishes a sockets connection with an application
running on a remote computer and then performs a security handshake. Once
the security handshake is complete, the SSL library then encrypts and
decrypts all data sent to and received from a remote host computer through
the socket connection. The SSL library is used with a reliable transport
protocol. For the UNIX Windows environments, this is commonly provided by
TCP/IP. The sockets API also can be used to provide access to Xerox XNS,
Novell SPX/IPX and the OSI protocols as well.
The sockets API typically serves as an interface used by applications to
communicate with the TCP/IP protocol stack. Generally, the client and
server programs each invoke operating system functions that set up an
association between them referred to as a sockets connection. The client
and server applications then invoke operating system functions to send and
receive information between them over a network, such as the Internet, in
a similar manner to calling functions to perform ordinary input/output.
The information, for example, may include graphics, data, instructions and
even computer programs. The sockets connection between the two programs
uses data structures which allow access to TCP/IP services. The sockets
API ordinarily provides a series of system calls that application programs
can invoke to request sockets connection communication services.
More specifically, the typical approach to using sockets is that a server
application creates an open socket ready to accept connections at a given
IP address and (well known) port. Once such a socket has been created,
buffer space can be allocated to store incoming connection requests. The
server socket ordinarily behaves as a passive endpoint waiting for a
connection request to arrive from a client. In order for a client to send
a connection request to a passive socket, the socket must have a name.
Therefore, names are bound to sockets and are published so that a remote
client can address the named socket. To initiate a connection to a remote
socket a client application ordinarily requests a connection and specifies
a local (client) socket and a remote name as parameters. Multiple clients
can use a single server socket. Client requests can be queued in a buffer
associated with the server socket. Typically when a request is accepted
from the queue, a new socket is created and the new socket is used as the
server side connection endpoint with a client. In this manner, a single
well known port number can be used to establish many simultaneous socket
connections. A shutdown (or dose) request usually is employed to terminate
a socket connection.
Thus, in a present embodiment of the invention, an application layer
program makes sockets calls to its SSL library which sets up a sockets
connection and also ensures security during data transmission over the
network. There are important advantages in binding a connection interface
(sockets API) plus a security protocol (described below) in a layer
between an application program layer and a transport layer in accordance
with the invention. For example, since the sockets API is so widely used
by application programs and operating systems, the SSL's sockets API can
be adopted for use in a broad range of network environments. Moreover,
since the SSL library of the presently preferred embodiment of the
invention, is disposed between the application program layer and the
transport layer, security can be provided to multiple different types of
applications without significant modification to the applications
themselves. Furthermore, changes in security requirements or procedures
often can be more readily implemented by changing security protocols
disposed above the transport layer, which is typically implemented as part
of the operating system, than by changing the operating system itself. As
explained above, the SSL library is layered between the application layer
programs and the operating system transport control protocol stack. As a
result, SSL security can be modified and upgraded without changing the
operating system.
D. SSL Library's Security: Key Exchange, Authentication and Integrity
Checks
This section explains the apparatus and methods whereby a client
application and a server application ensure adequate security during an
information exchange between them. Subsequent sections explain the details
of a novel "Record Protocol Specification" used during SSL communications
between client and server and the details of a novel "Handshake Protocol"
used to establish a secure "sockets" layer (SSL) communication channel
between client and server. The disclosure in this section references
public key algorithms, bulk ciphers, authentication processes and
integrity checks in general. It will be appreciated that the principles
discussed in this section can be applied to numerous different specific
instances of each of these security and integrity check mechanisms. The
section below describing the handshake protocol provides many examples of
different combinations of public key algorithms, bulk ciphers,
authentication processes and integrity checks that can be employed
consistent with the invention.
RSA Key Exchange Assuming No "Session-Identifier"
Referring to FIG. 4, there is shown the message flow during handshake
protocol negotiation where RSA key exchange is employed and no
"session-identifier" is stored in server cache. Note that at the stage at
which the message exchange in FIG. 4 begins, the client and server already
have established a "sockets" connection between them, and the server has
determined that the connection is to be a secure connection that employs
the novel SSL processes and program control mechanisms described herein.
As explained above, the sockets API is well known. Moreover, in accordance
with the invention, the sockets connection is initiated by a client
application SSL.sub.-- open call to its SSL library which is bound to the
client application. The data transferred between client and server can be
encrypted/decrypted as it is channeled through the socket. But first,
before any data is transferred, the client and the server must negotiate
an encryption technique for the data transfer, authenticate the connected
parties (server and possibly client too), and check the integrity of the
agreed upon secure connection. This negotiation is carried out in response
to the SSL.sub.-- open call through message flow of FIG. 4, which takes
place using the sockets connection previously set up as part of that same
SSL.sub.-- open call.
The client sends to the server, through the sockets connection, a
client-hello message which includes the following information: challenge
data and cipher.sub.-- specs. In the current implementation of the
invention, the challenge data is a random number used to ensure channel
integrity as explained below. The cipher-specs indicate which bulk ciphers
are supported by the client.
The server responds to the client-hello message with a server-hello message
which includes the following information: connection.sub.--
identification, server.sub.-- certificate and cipher.sub.-- specs. The
connection.sub.-- identification is a randomly generated set of bits. The
server.sub.-- certificate is issued to the server through well known
techniques and is used to certify the authenticity of the server. The
cipher.sub.-- specs sent by the server to the client indicate the bulk
cipher to be used during the data transfer. The bulk cipher is selected by
the server from the choices provide by the client in the ciper.sub.--
specs portion of the client-hello message. Since it is possible that there
may be multiple different ciphers supported by the client and by the
server, it is necessary for the client and server to "negotiate" which
cipher to use based upon the available client and server ciphers. Upon
receiving the client-hello message, the server determines which server
ciphers match the available client ciphers identified in the client
cipher.sub.-- specs portion of the client-hello message. The server
selects a cipher to be used to encrypt/decrypt the data to be transmitted
and indicates its choice in the cipher.sub.-- specs portion of the
server-hello message.
The client delivers a master key to the server in a client-master-key
message. The master key, for example, can be a randomly generated number.
The master key is used by the client and the server to produce session
keys which will be employed to actually encrypt/decrypt the data to be
transferred through the sockets connection. The master key is a shared
secret between the client and the server. The master key is delivered by
the client to the server in encrypted form using a key exchange encryption
algorithm. In FIG. 4, an RSA public key algorithm is employed for key
exchange.
Once the master key has been delivered to the server, the server and the
client both can independently generate the session keys used to actually
encrypt/decrypt data transferred following successful completion of the
handshake protocol. The session keys are produced using well known
techniques such as through hash functions referenced in the sections below
or some other function of the master key and another data value. A more
detailed explanation of the session key production techniques used in the
presently preferred embodiment of the invention is provided below in the
handshake protocol section. It should be understood that, while public key
encryption techniques are used for master key exchange, the actual
encryption/decryption of data transferred between client and server
through the socket is achieved using a well known bulk cipher, such as
RC2, RC4 or IDEA, negotiated through the respective cipher.sub.-- specs
components of the information exchanged in the client-hello and
server-hello messages. The selected bulk cipher uses the session keys to
encipher/decipher data and messages transferred through the socket
connection.
The client sends a client-finished message which indicates that the client
is satisfied with the server. In a present embodiment of the invention,
the client-finish message includes a hash of all of the handshake protocol
messages previously sent by the client. The hash is encrypted using the
agreed upon bulk cipher plus a session key generated by the client,
referred to in FIG. 4 as the client-write-key. Note that the hash function
also is negotiated as part of the cipher.sub.-- specs. In addition, the
connection-identification previously sent to the client by the server is
transmitted to the server with the client-finish message to authenticate
the channel. The server uses the client messages handshake hash to verify
the integrity of the communication between client and server. This final
integrity check will expose third party intervention even if it occurred
at the beginning of the handshake protocol.
The server sends a server-finished message which indicates that the server
is satisfied with the client and is ready to begin the actual data
transfer through the socket connection. In a present embodiment of the
invention, the server-finish message includes a hash of all of the
handshake protocol messages previously sent by the server. The hash is
encrypted using the agreed upon bulk cipher plus a session key generated
by the server, referred to in FIG. 4 as the server.sub.-- write.sub.--
key. The hash function also is negotiated as part of the cipher.sub.--
specs. The server uses the server messages handshake hash to verify the
integrity of the communication between client and server as explained
above.
In addition, a new session.sub.-- identification is sent together with the
hashandshake hash encrypted using the bulk cipher and the server.sub.--
write.sub.-- key. This new.sub.-- session.sub.-- identification is stored
by both the client application and the server application in their
respective cache memories together with the master key and the encryption
algorithm selection (cipher plus hash) so that, as explained below, the
master key can be used again in a future socket connection between the
client and the server. Note that if a client machine, for example, is
running multiple instantiations of the application program then each
instantiation will have its own session-identification.
In a present embodiment, the session.sub.-- identifications are stored by
client application and server application in a table like the following:
______________________________________
session.sub.-- identification table
______________________________________
session.sub.-- ID
machine IP address
master key
encryption
timer
algorithm
______________________________________
The server-finish message also includes the challenge data sent by the
client to the server in the client-hello message. The challenge data is
encrypted by the selected bulk cipher using the server.sub.-- write.sub.--
key. The client decrypts the challenge data in order to verify that the
key exchange has been successful by testing the ability to encrypt and
decrypt the mutually known challenge data using the newly generated
session keys.
RSA Key Exchange Assuming a Session-Identificr Found By Client and Server
Referring to FIG. 5, there is shown a sequence of messages transferred
through the socket connection when the client and server negotiate the
handshake protocol at a time when each stores a common session.sub.--
identification in its respective cache memory. The session.sub.--
identification for a given handshake protocol is stored for a period of
time together with the information generated during the handshake. That
stored information includes the previously agreed upon block cipher and
hash function as well as the earlier master key. A given session.sub.--
identification together with its related information is retained in cache
memory in the client and in the server for a prescribed period of time,
100 seconds in a current implementation. During that time interval, if the
client application again attempts to access the server through a new SSL
library connection, then the new connection can use the same block cipher,
hash function and master key that were negotiated during the prior
handshake protocol.
The stored session.sub.-- identification information advantageously saves
time in establishing secure sockets connections without unreasonably
compromising security. The generation of session keys is a relatively time
consuming task since it involves the exchange of a master key using a
relatively slow public key algorithm. By using the previously derived
session.sub.-- identification information, the master key and encryption
algorithm (a block cipher plus a hash function in the preferred
embodiment), the most time consuming handshake steps can be avoided. This
approach is particularly beneficial, for example, in applications such as
client-server data transfers involving a client application establishing a
secure sockets connection with a secure server over the Internet. A client
application, such as a web browser constructed in accordance with the
present invention for example, may set up a connection to a remote server
in order to retrieve information requested by a client user.
For instance, an electronic document containing hyperlinks may be displayed
by the client browser application. Whenever a user "clicks" on (or
selects) portion of the document associated with a hyperlink, another
electronic document or file or a graphic or some other remotely stored
information that corresponds to the link is retrieved over the Internet
from the server. Before the transfer can occur, however, the handshake
protocol is negotiated, and encryption/decryption information is developed
as described above. That information is stored with the session.sub.--
identification for that connection. When that new document (or other
information) has been transferred to the client, the SSL library causes
the secure sockets connection used to accomplish the transfer of that next
document to be closed. The session.sub.-- identification information
(master key, block cipher, hash function) is stored in cache by the client
and server applications for a prescribed time intervals. If within that
time a user of that same client browser application "clicks" on another
hyperlink, then the client browser application will set up another sockets
connection with the server to satisfy this latest request. Rather than go
through the entire time consuming handshake protocol, however, the client
and server will use the previously generated and stored session.sub.--
identification information (master key, block cipher, hash function) to
secure data transfer through the new socket set up by the SSL library to
satisfy this latest request.
It will be appreciated that as each subsequent client request is made to
the secure server, a new session.sub.-- identification with a new interval
timer is stored in the client cache memory and in the server cache memory.
Thus, the same block cipher, master key and hash functions can be used for
multiple secure sockets connections, even when the connections occur over
a time interval which is extends beyond the prescribed interval of the
original connection for which the session.sub.-- identification
information was negotiated, provided that there is no time gap between any
two requests that exceeds the prescribed time interval.
Referring to FIG. 5 in step.sub.-- the client-hello message sends a
session.sub.-- identification which identifies previously stored security
information (master key, block cipher, hash function) together with
challenge data and cipher.sub.-- specs. The server-hello message sends a
connection.sub.-- identification together with a session.sub.--
identification.sub.-- hit indication. Since the has been a hit, there is a
match between a session.sub.-- identification stored in the client cache
and a session.sub.-- identification stored in the server cache. This means
that there was a previous secure sockets connection between the client
application and the server application, and that the session.sub.--
identification information negotiated and stored in conjunction with that
prior connection still is available for use with this later connection.
Therefore there is no need to negotiate a cipher.sub.-- specs or to
generate and a new master key or to generate new session keys. The
remaining steps in FIG. 5 are identical to the corresponding steps in FIG.
4. Note that a new session.sub.-- identification is delivered in the
server-finish message. This new session.sub.-- identification supplants
the prior session.sub.-- identifications which matched.
RSA Key Exchange Assuming Session-Identification Match and Client
Authentication
In FIG. 6 the first four messages, client-hello, server.sub.-- hello,
client-finish and server-verify are identical to the first four messages
in FIG. 5. However, the server sends a request-certificate message which
includes authentication.sub.-- type and challenge data encrypted with the
server.sub.-- write key (one of the earlier agreed upon master keys). The
authentication-type specifies an encryption technique to be used to
authenticate the client; several authentication techniques can be
supported by a current embodiment of the invention as explained in a
following section. The challenge data is used in the authentication
process. A client-certificate message is sent by the client to the server.
The client-certificate message includes certificate.sub.-- type,
client.sub.-- certificate and response.sub.-- data, all of which are
encrypted using the client.sub.-- write.sub.-- key (one of the earlier
agreed upon master key). Several certificate types, described below, are
supported by the current embodiment. The certificate.sub.-- type indicates
which one has been employed. The client.sub.-- certificate contains the
data defined by the certificate.sub.-- type value. The response data
contains authentication response data which is a function of the
authentication.sub.-- type sent by the server in the request-certificate
message. The final step is the same as the final steps in FIGS. 4 and 5.
Diffie-Hellman Key Exchange Assuming No Session-Identification
FIG. 7, illustrates a Diffie-Hellman (DH) key exchange in accordance with a
current implementation of the present invention. The client-hello and the
server-hello messages, are the same as the corresponding messages in FIG.
4. Also, the client-finish message and the server-finish message are the
same as corresponding messages in FIG. 4. In a present implementation of a
DH key exchange, a "Y" value and a random number are delivered by the
client to the server in a client-dh-key message. The Y value is a public
number which corresponds to a secret number which is the result of an
exponentiation process. The Y value and the random number are used by both
client and server to generate a new randomized key. In a DH key exchange,
both sides in the exchange independently generate the same master key. The
client-session-key message delivers the session.sub.-- key.sub.-- 1
encrypted by a master.sub.-- key. The client session-key message .sub.--
also delivers the random number encrypted by the session.sub.-- key.sub.--
1. This encrypted random number is important in hardware implementations
of the DH exchange.
E. SSL Library's Sockets API
Overview of Internet Architecture
Referring to FIG. 8, there is a generalized illustrative representation of
a typical protocol stack which resides in each host machine (client and
server) connected to the Internet. Also shown is the encapsulation and
decapsulation of a typical program data unit (PDU) (or message) as it
travels from one host to another through the Internet. The application
layer security mechanisms and processes of the present invention
ordinarily operate in an Internet environment, although the invention can
be practiced in different network environments as well.
The typical Internet protocol stack includes five network "layers". Note
that the Internet model lacks the presentation and session layers that are
proposed in the International Standards Organization (ISO) Open Systems
Interconnection (OSI) Reference Model. During client-server
communications, information to be transferred from the server to the
client, for example, is first transferred from server application layer
computer programs down to the server transport layer. Next, the
information is transferred down through network, data link and physical
layers that may be associated with the server, and then up through
physical, data link and network layers that may be associated with the
client. Information transfer down and back up through these lower three
layers may involve transfers through a communication subnet which may
include routing devices as illustrated. The information then continues its
trip up through the client transport layer to the client application
layer. The transfer of information in the opposite direction, from client
to server, involves a similar layer by layer transfer but in the opposite
direction, starting with the client application layer and ending with the
server application layer. Those skilled in the art will appreciate that
there are various different protocols that can be used to implement the
different protocol layers, and that many variations of the basic network
model are possible. For a discussion of well known network architectures
and the typical functions associated with the various layers within the
architecture refer to, Network Management Standards: SNMP, CMIP, TMN,
MIBs, and Object Libraries, Second Edition, by Uyless Black, McGraw-Hill,
Inc., 1994. Also see, Computer Networks, Second Edition, by Andrew S.
Tanenbaum, Prentice-Hall, Inc., 1989.
Focus on Application and Transport Layer Security
In FIG. 9, there is an illustrative drawing providing a more detailed view
of client side and server side application layer and transport layer
programs and protocol structures used during client-server network
communications in accordance with a current embodiment of the invention.
The client and server application layers each include SSL libraries which
cooperate to provide an application program interface which encrypts and
decrypts information passed between different client and server
application programs through a transport layer socket connection. The
client application layer, for example, may include any of numerous types
of computer programs which rely upon client-server network connections.
For example, the client application might be a network browser application
used to provide user access to the World Wide Web. Alternatively, for
instance, the client application might be employed for financial
transactions involving credit card or home banking. It should be
appreciated that these are but a few sample types of application programs
that require security when involved in information transfer using a
client-server network connection. The server application layer, for
example, may include an HTTP server which provides information to a client
browser application in response to a client request. In a present
embodiment, the client application layer may includes multiple application
layer protocols used during transfers of information in connection with
different categories of applications. For example, in a present embodiment
of the invention, a client application may employ HTTP, network news
transfer protocol (NNTP), file transfer protocol (FTP), and Telnet. Each
different application protocol is used in communications involving
different server applications. For example, NNTP is used to access certain
news sources over the Internet; FTP can be used for file transfers over
the Internet; and a Telnet can be used for remote login over the Internet.
An SSL library provides a sockets API that other applications can call to
encrypt and decrypt information passed through a socket connection.
Moreover, in a current embodiment of the invention, both the client and
the server include operating system services which implement respective
client and server transport layer protocols that use socket type
connections. These built in transport layer operating system services may
be an integral part of the client and server operating systems. That is
generally the case, for example, with the UNIX operating system.
Alternatively, for example, the present invention may be practiced in a
host (client or server) environment in which transport layer socket
connection services are implemented as part of an application layer
dynamic link library (DLL), such as Winsock for instance, which runs on
top of a Windows operating system. Winsock is a DLL which provides a
socket application program interface, but it does not provide the socket
layer security.
The illustrative drawing of FIG. 10 shows client and server side
application layers and transport layers which employ the Winsock DLL in
conjunction with the SSL library in accordance with an alternative
embodiment of the present invention. In operation, for example, a client
application calls Winsock to request a socket connection to a server
application. Winsock, in turn, calls the SSL library and requests a
connection to the server application. The SSL library then calls the
operating system protocol stack and establishes the socket connection with
the server side. The client side and server side SSL libraries negotiate
security. Once a security scheme has been agreed upon, the client side SSL
library returns a message to Winsock indicating that a socket connection
is available. Winsock, in turn, returns a message to the calling client
application indicating that a socket is ready. The client then can proceed
to communicate with the server application through Winsock and the SSL
library using the secure socket connection set up by the SSL library.
The illustrative drawings of FIG. 11 shows client and server side
application layers and transport layers which employ a variation of the
Winsock DLL in conjunction with the SSL librar | | |
