Electrical computers and digital processing systems: multicomput – Computer-to-computer session/connection establishing
Reexamination Certificate
1999-11-17
2003-11-04
Barot, Bharat (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer session/connection establishing
C709S203000, C709S217000, C709S219000, C709S228000, C713S150000, C713S155000, C713S152000, C705S064000, C705S065000
Reexamination Certificate
active
06643701
ABSTRACT:
BACKGROUND OF THE INVENTION
A. Field of the Invention
The present invention relates generally to data processing systems and, more particularly, to providing secure communication between a client and a server.
B. Description of the Related Art
The Internet is a collection of computers sending messages to one another over a network that delivers the messages. There are, however, fraudulent computers on the Internet that attempt to trick the network into delivering messages intended for another to them or instruct the network to send bogus messages. In addition, information on the network could be viewed as it is being delivered. Therefore, there is a need to authenticate that the sender or recipient of the message is a proper sender or recipient and to encrypt the message to prevent unauthorized viewing.
When starting a secure communication session, the sender asks a recipient to begin a communication session, and the recipient replies with information that the sender can use to verify that the recipient is not fraudulent. In some cases, the sender could also provide information that the recipient can use to verify that the sender is not fraudulent.
After confirmation of the identity of the recipient and possibly the sender, the sender and the recipient negotiate a set of “keys” with which to use to encrypt and decrypt messages sent between them.
When encrypting a message, the sender uses an encryption key and an encryption algorithm to encrypt messages so that those without the appropriate key cannot read the messages. Upon receiving an encrypted message, the recipient decrypts messages using the appropriate key to render the messages readable (which is also known as “cleartext”).
Various publicly available systems permit the authentication, encryption, and decryption of messages from one end to another end on the Internet. Most web-based applications, such as on-line banking, electronic shopping, and secure remote access to protected networks (like Intranets), use an end-to-end security protocol, such as the Secure Session Layer (SSL) protocol or Transport Layer Security (TLS) protocol for their security needs. Some end-to-end security protocols, such as SSL and TLS, use public-key cryptography to generate symmetric keys (which are also known as session keys) that are used by the encryption and authentication algorithms. The sender and receiver negotiate the symmetric keys during a “handshake” protocol, which typically includes the following steps: (1) authentication, and (2) key exchange using a Rivest, Shamir, and Adelman (RSA) or a Diffie-Hellman (DH) algorithm.
FIG. 1
illustrates a high level diagram of how clients
100
would communicate with a server
120
over a network, such as the Internet, in a manner consistent with the prior systems. The term “client” is typically associated with a program that sends a request for information from the “server.” Nevertheless, these terms are used as examples to differentiate the end points in a network, and “client” could mean “server” and vice versa.
Clients
100
attempt to negotiate how information should be securely transmitted. This negotiation is referred to as a handshaking session. For example, a client
100
desiring to initiate a link
110
using SSL (because of the relatedness between SSL and TLS, in the following discussions “SSL” should be regarded as “SSL or TLS”) and RSA key exchanges would extend its “hand” by informing server
120
it wishes to communicate using SSL and provide information about the client. Server
120
would extend its “hand” with a reply containing information about server
120
and a certificate used in authenticating the server. In some applications, the server may wish to authenticate client
100
, for example if a user of client
100
is accessing a bank account. If so, server
120
would ask for the certificate of client
100
. Another method of authenticating the client would be to provide an application-specific authentication at a level above the SSL layer. For example, the user could supply an authentication token, such as a password, known to the server. Client
100
then authenticates server
120
using the certificate and other information, suchan Internet address. If server
120
cannot be authenticated, the user of client
100
is warned of the problem and informed that an encrypted and authenticated connection cannot be established. Otherwise, client
100
generates a premaster secret, encrypts it with a public key of server
120
, which is a part of the certificate of server
120
, and sends the encrypted result to server
120
. The premaster secret is a secret message that is used to derive a master secret by including additional information such as random numbers selected by the client and server. When an RSA key exchange mechanism is used, client
100
selects the premaster secret without any input from server
120
. By including an additional hashing step in the derivation of the master secret from the premaster secret, server
120
can supply input in the master secret derivation. When client authentication is requested, client
100
uses a private key of client
100
to sign any piece of data that is unique to this handshake and known by both the client and server, and sends the signed data, the certificate of client
100
, and the encrypted premaster secret to server
120
. Server
120
then attempts to authenticate client
100
.
If all authentications are successful, server
120
generates the premaster secret from the encrypted result sent from client
100
. For example, using RSA, the server decrypts the encrypted result from client
100
to generate the premaster secret. In a DH key exchange, server
120
computes the premaster secret using a public key exponentiation. Then, client
100
and server
120
use the premaster secret to generate a master secret, which is used to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to detect any changes in the data between the time it was sent and the time it is received over the SSL connection.
Client
100
sends a message to server
120
informing it that future messages from the client will be encrypted with the session key and an encrypted message indicating that the client portion of the handshake is finished. Server
120
responds with a message to client
100
informing it that future messages from the server will be encrypted with the session key and an encrypted message indicating that the server portion of the handshake is finished.
Thereby, the SSL handshake session is completed and an SSL link
110
, over which client
100
and server
120
transfer data, is established. For subsequent communications between client
100
and server
120
, a session resumption procedure is initiated. In this case, client
100
simply identifies itself to server
120
and indicates that it will continue to use the agreed upon keys from the previous handshaking session stored in memory in client
100
. Server
120
would acknowledge that the end-to-end security session should be resumed over link
110
and use the keys stored in memory in the server
120
.
These publicly available systems, however, could be improved.
The number of new secure connections a hyper text transfer protocol secure (HTTPS) server can handle is typically a small fraction of the number of new regular connections (HTTP) it can handle because the computation steps in the handshaking session are computationally intense and burdensome. If another client
100
requests a new secure connection, it must be refused until the server is able to process the request.
Also, the encrypted connection can make troubleshooting problematic. It may be difficult for application users to test their programs and thereby diagnose and understand performance problems, especially when the user cannot monitor performance at end-points (typically browsers or HTTPS servers) either because of lack of access to source code and/or the difficulty of putting in the appropriate instrumentation mechanisms there.
Additi
Aziz Ashar
Baehr Geoffrey
Caronni Germano
Gupta Amit
Gupta Vipul
Barot Bharat
Finnegan Henderson Farabow Garrett & Dunner LLP
Sun Microsystems Inc.
LandOfFree
Method and apparatus for providing secure communication with... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for providing secure communication with..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for providing secure communication with... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3142273