Piggy-backed key exchange protocol for providing secure,...

Electrical computers and digital processing systems: support – Multiple computer communication using cryptography – Particular communication authentication technique

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C713S160000, C713S168000, C713S152000, C709S203000

Reexamination Certificate

active

06751731

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer program product for providing a piggy-backed key exchange protocol. This protocol is used between a client and server to establish security parameters that are used to exchange data in a secure manner. By piggy-backing the key exchange onto other messages, the overhead associated with setting up a secure browser connection is reduced.
2. Description of the Related Art
Traditionally, complex distributed applications have been designed around the client/server paradigm, where the application logic is split into two integral parts. One of the parts provides the client functionality, and the other provides the server functions. Each of the parts is then installed on the respective hardware. Such an architecture has the fundamental drawback that the application usually must be tailored around a particular user device and vice versa: the application must function on the particular hardware and software profile of the intended user device, and the user device must meet the application requirements in terms of form-factor, processor requirements, storage capabilities, etc. This coupling leads to the implementation of the client functionality being fundamentally tied to a single type or class of end-user device. The client implementation typically must be modified in order to operate on different devices or operating system platforms, and separate versions must be provided to address the inherent differences in the devices and platforms. This leads to increased complexity and expense for application development and testing, distribution and support, etc. Because of the proliferation in client device types, it is becoming increasingly demanding to provide applications that reliably meet the constraints imposed by the different device types. This proliferation also creates a greater burden on end users who must similarly obtain and manage different versions of their application software, one for each type of device.
In the face of these challenges, there is a clear trend toward delivering applications to users in a form that is accessible via a more standard infrastructure that is available on most hardware and operating system platforms. One type of standard infrastructure is the browser. (Note that the browser implementation itself is generally non-portable, but the intent is to have the browser represent the only platform-specific code that developers write and that end users must deploy.) Within this standard infrastructure, application-specific content may be retrieved and presented to the user. Moreover, application-specific logic may be executed within an appropriate scripting environment provided on the client side by most browsers, including Netscape Navigator® and Internet Explorer. (“Netscape Navigator” is a registered trademark of Netscape Communications Corporation.) On some devices, the scripting environment may be separate from the browser, and may support richer (though still portable) application logic such as those applications written in the Java programming language. (“Java” is a trademark of Sun Microsystems, Inc.)
The tradeoff that comes from making the client infrastructure standard, however, is that it is also generic. That is, while the infrastructure is not written for the needs of a particular client application, it is able to act as the client for a wide range of applications. In this generic client environment, the problem of implementing each application shifts primarily toward the server side. (Hereinafter, the term “browser” will be used to refer to the generic client software, including the associated scripting and application environment(s).) This, in turn, somewhat complicates the tasks that must be implemented in the server software, as the server software must adapt the content to match the capabilities of the particular browser executing on the client. Alternatively, the burden may be shifted to one or more computers in the delivery chain between the client and server. In particular, a variety of transcoders and gateways can be envisaged in this delivery chain. Each of these transcoders and gateways may potentially have knowledge of a target client device's particularities, which the transcoder or gateway can then use to adjust data generated by a server application that is being delivered to this client. The Wireless Application Protocol, or “WAP,” is an example of an application architecture which may employ this type of multiple transcoder and multiple gateway environment.
In such an environment where data is being transmitted between a client and server while passing through intermediate transcoders or gateways, data security is often a key concern. A client may need to send data to the server that is considered security-sensitive by the client or the server, such as when a person's credit card information is transmitted through a network for use by an electronic shopping application executing on the server. In addition, the content dispatched from the server to the client is often considered security-sensitive. A simple example of this situation is the same electronic shopping application just discussed, where the server may transmit an order confirmation to the client that includes the client's credit card information Many other security-sensitive transmissions exist, such as those that occur when using electronic banking, online stock trading, online bill presentment and payment, etc. The problems that may ensue when sensitive data is exposed to an unintended recipient, such as a computer hacker, can be quite serious. While gateways, and transcoders in particular, may be designed to modify the application content in legitimate ways when forwarding it through the delivery chain, sensitive content at the same time must not be disclosed to such intermediaries. (U.S. patent application Ser. No. 09/352,534, which is titled “Method for Transmitting Information Data from a Sender to a Receiver via a Transcoder, Method of Transcoding Information Data, Method for Receiving Transcoded Information Data, Sender, Transcoder, and Receiver” and is assigned to the same assignee, defines a novel technique for use in such an environment where the security-sensitive portions of a Hypertext Markup Language, or HTML, document are encrypted while leaving the remaining portions in plain text.)
A number of security protocols have been developed for use in client/server and other networking environments. Examples include the SSL (Secure Sockets Layer), TLS (Transport Layer Security), and WTLS (Wireless Transport Layer Security) protocols. (TLS is being defined by the Internet Engineering Task Force as a follow-on replacement for SSL, and WTLS is being developed by the WAP Forum as a security protocol optimized for the mobile computing environment.) These protocols all share the characteristic of encrypting all data transmitted through a network connection or communication session, thereby preventing an intermediary, such as a transcoder, from inspecting and/or modifying any of the data being exchanged. Consequently, these transport-based security protocols are ineffective in environments having transcoders and gateways that must legitimately modify and therefore inspect some non-security-sensitive sections of the data stream.
To enable intermediaries to perform legitimate content modifications, end-to-end security in a complex delivery chain such as that described above must be provided at the application layer (referred to equivalently as the “application level”) of the client and server. This means that security-related functions such as encryption, decryption, and authentication are performed under control of the application software, as only the application is able to distinguish between content that can be transmitted in plaintext (i.e. can be exposed to and acted upon by intermediaries) and content that is security sensitive and must be protected end-to-end (i.e. cannot be expose

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Piggy-backed key exchange protocol for providing secure,... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Piggy-backed key exchange protocol for providing secure,..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Piggy-backed key exchange protocol for providing secure,... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-3343207

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.