Initiate non-blocking RSA
signing operation if
identical signing request
not already initiated
Sheet 4 of5 US 8,091,125 B1 3&2 N0 328 Retrieve RSA signing result 320 F F
Controller Application Cryptographic Toolkit
Retrieve crypto op results
Receive crypto op results
I I I I I Request crypto operation if } I R I ll Receive crypto op request I I I I I I I Initiate crypto operation I I I I I I I Return notification I I I r : parameters Save notification I parameters : I I I P’ I Perform application I specifio processing | V I § Determine that crypto op 1 has completed I I I I I I I I I I I I I I I I I I I I I
1 METHOD AND SYSTEM FOR PERFORMING ASYNCHRONOUS CRYPTOGRAPHIC OPERATIONS
CROSS-REFERENCE TO RELATED APPLICATIONS
This application is a continuation patent application of U.S. patent application Ser. No. 10/308,844, filed Dec. 2, 2002, U.S. Pat. No. 7,376,967, the benefit ofwhich is claimed under 35 U.S.C. §120, and further claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Application Ser. No. 60/348,970 filed on Jan. 14, 2002, each of which are incorporated herein by reference in their entirety.
This application relates generally to cryptographic techniques, and, more specifically, to techniques for accelerating performance of cryptographic operations.
Many web sites today use the Secure Sockets Layer and Transport Layer Security (SSL) protocols to achieve end-toend secure communications, particularly in the areas of electronic commerce and financial services. The SSL protocol is described in Netscape Communications Corp., Secure Sockets Layer (SSL) version 3, (November 1996). The TLS protocol is derived from SSL, and is described in Dierks, T., and Allen, C., “The TLS Protocol Version 1.0,” RCE 2246 (January 1999), available at the Internet Engineering Task Force (IETF). As used throughout this application, including the claims, SSL refers to SSL, TLS, and all secure communications protocols derived therefrom. A widely used SSL-enable protocol today is the Hypertext Transport Protocol (HTTP) encapsulated in an SSL connection, commonly known as HTTPS. The HTTP protocol is described in “Hypertext Transport Protocol (HTTP) version 1.0, RFC 1945 (May 1996)” and “Hypertext Transport Protocol (HTTP) version 1.1, RFC 2616 (June 1999)”. The SSL protocol’s authentication mechanism typically requires web servers to perform computationally expensive mathematical operations, the effects of which are fewer requests serviced per unit time and higher latency in processing individual requests.
The SSL protocol provides several methods to authenticate bothparties to an SSL connection, the most common of which is the user of Riverst-Shamir-Adleman (RSA) authentication pas part of a public key infrastructure (PKI). This is described in RSA Cryptography Standard, PKCS #1 Version 2.0, (Nov. 1, 1993), available from RSA’s website. In common usage, web servers will authenticate themselves to clients, but not vice-versa. As part of this procedure, the authenticating party performs a computationally expensive RSA “signing” operation in a full SSL handshake. This calculation is very time consuming and comprises the single largest bottleneck in short-lived SSL connections.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a system diagram of a computer network in which the invention may be practiced;
FIG. 2 is a block diagram of an exemplary network device that may be employed to perform the invention;
FIGS. 3A-B are flowcharts illustrating a process for performing asynchronous cryptographic operations; and
FIG. 4 is a flowchart illustrating interactions between a controller application and a cryptographic toolkit, in accordance with the present invention.
In the following detailed description of exemplary embodiments of the invention, reference is made to the accompanied drawings, which form a part hereof, and which are shown by way of illustration, specific exemplary embodiments of which the invention may be practiced. These embodiments are described in suflicient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized, and other changes may be made, without departing from the spirit or scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims. The phrase “in one embodiment” as used herein does not necessarily refer to the same embodiment, though it may. As used herein, the term “or” is an inclusive “or” operator, and is equivalent to the term “and/or”, unless the context clearly dictates otherwise.
The present invention is a system and method for improving performance of cryptographic operations. In one embodiment, a single process or thread of execution cooperates with a modified cryptographic toolkit, which off-loads portions of a cryptographic protocol in an asynchronous manner. In one embodiment, a number of threads of execution each perform the method of the invention. The threads may be in a single process or in a number of processes. The invention is described herein with reference to an SSL toolkit and the performance of cryptographic operations such as an RSA signing operation. It is to be understood that these references are exemplary in order to simplify the discussion, and that the invention can be practiced with other cryptographic operations and toolkits other than SSL toolkits.
One approach to improving performance of RSA signing operations is to use an accelerator card. The Rainbow CryptoSwift PCI card, made by Rainbow Technologies, of Irvine, Calif., is one such accelerator card. The accelerator card improves performance as compared with performing all operations in software, because the Rainbow accelerator reduces the modular exponentiation latency. In this approach, software in an SSL-enabled application, such as an SSL proxy or web server, makes calls to the accelerator card using the accelerator application program interface (API). These calls are blocking calls. That is, when a call is made to the accelerator card, the program making the call blocks and waits until the card completes the requested operation. Upon completion of the operation, the controlling program continues. While waiting for the accelerator operation to complete, the SSL-enabled application is unable to process additional client requests.
F5 Networks, Inc. provides an SSL proxy (available in some BIG-IP products), which alleviates load on web server pools by stripping or “terminating” SSL from HTTPS (or any protocol fully encapsulated by SSL), and centralizes PKI key/certificate management. The BIG-IP product also can optionally re-encrypt data after performing operations on decrypted data.
One technique for improving performance is to use multithreaded or multi-processed applications that establish multiple connections with an accelerator card. The simplifications of multi-threaded and multi-processed architectures often allow complex problems to be solved in an easier manner than with single-threaded, single-processed applications.
However, the use of multiple threads and context switching adds overhead that limits the performance of such techniques.
FIG. 1 shows components of an exemplary environment 100 in which the invention may be practiced. Not all of the components are required to practice the invention, and variations in the arrangement and type of the components may be made without departing from the spirit or scope of the invention.
FIG. 1 shows a wide area network, such as the Internet 102 that communicates with a server load balancer 104. The server load balancer routes each incoming packet of network traflic to one of a set of one or more SSL proxies 106. Each SSL proxy performs decryption and encryption operations, and forwards plaintext network traflic to a second server load balancer 108. Plaintext is ordinary unencrypted text and/or binary data. The second server load balancer 108 routes incoming packets to servers 112 within a server array 110, which includes one or more servers 112. Alternate configurations of network devices can also be used with the present invention.
FIG. 2 is a block diagram illustrating components within an SSL proxy 106, in accordance with one embodiment of the present invention. The SSL proxy 106 includes a controlling application 202, an SSL cryptographic toolkit 204, and a hardware accelerator 206. In one embodiment, the SSL cryptographic toolkit 204 is the OpenSSL toolkit that has been modified to incorporate the inventive features described herein. It should be noted that, while the invention is described herein as employing an SSL proxy and an SSL cryptographic toolkit, the invention may also be practiced in other cryptographic applications, and is not limited to those involving SSL.
The SSL cryptographic toolkit includes an SSL API 208, which is an interface used for communication between the controlling application 202 and the SSL cryptographic toolkit 204. The SSL cryptographic toolkit 204 further includes an SSL state machine 210, cryptographic components 212, and a hardware abstraction layer. The cryptographic components 212 includes an RSA module 214. The RSA module performs RSA cryptographic computations that may be oflioaded to a hardware accelerator 206 via the hardware abstraction layer 216. In one embodiment, the SSL cryptographic toolkit is implemented as software executing on a CPU (not shown) within the SSL proxy 106. In another embodiment, at least some of the components of the SSL cryptographic toolkit 204 are implemented in hardware or by a combination of software and hardware. The functions of the SSL proxy can be distributed between hardware and software in a number of different ways.
As illustrated in FIG. 2, the hardware accelerator 206 includes an accelerator API 218, a kernel driver 220, and a PCI card 222. The Rainbow CryptoSwift PCI card, made by Rainbow Technologies, of Irvine, Calif., is one such PCI card.
One actual embodiment of the present invention uses a modified version of the Open SSL cryptographic toolkit (available at Open SSL’s website) as the SSL cryptographic Toolkit 204. In this embodiment, the SSL API 208, the SSL state machine 210, the cryptographic components, and the RSA module 214 are modified versions of the standard OpenSSL distribution. The OpenSSL cryptographic toolkit and the Open SSL API have been modified in order to allow a single-process single-threaded application to continue servicing other connections during the time in which one or more connections are awaiting the result of a hardware-accelerated RSA signing operation. These modifications include extensions to the OpenSSL API and changes in existing API functions’ semantics. The changes to the OpenSSLAPI take effect
scriptor corresponding to the nonblocking hardware-accelerated RSA signing operation. When the RSA signing operation result is ready, the accelerator driver marks this descriptor ready for reading. If no non-blocking hardware operation was initiated, -1 is returned This new function is used by the application to indicate to the SSL cryptographic toolkit that is supports and desires to use the performance enhancements provided by the present Invention. If this function is not called by the application, the SSL cryptographic toolkit will not use the non-blocking acceleration enhancements and will remain backwardcompatible with legacy applications. This new function is used by the application to query the SSL cryptographic toolkit for the current enabled/disabled status of the performance enhancements provided by the present invention.
SSLisetiuseinonblockinghw
SSLigetiuseinonblockingihw
In one embodiment of the present invention, the SSL cryptographic toolkit 204 constructs data structures (as defined by the hardware accelerator vendor) and calls the corresponding non-blocking cryptographic acceleratorAPI functions. It also retains additional relevant state information regarding the progress of each SSL connection with respect to hardwareaccelerated operations. API functions in the SSL API 208 reflect and communicate the status of non-blocking hardware-accelerated operations and their corresponding event notification parameters. Additionally, a generic hardware abstraction layer 216 eases the integration of a variety of hardware accelerators with the present invention. This layer directly communicates with the accelerator API 218.
In one embodiment of the present invention, the SSL cryptographic toolkit 204 stores the global enabled/ disabled status of the non-blocking enhancements, as well as augmenting each SSL connection data structure with additional storage reserved for state information regarding non-blocking hardware-accelerated operations in progress. This abstraction layer internally maintains the data structures specific to each hardware acceleration device, and exposes a common interface to initiate, retrieve the result of, and cancel non-blocking hardware-accelerated operations.
In one embodiment of the present invention, the controlling application 202 recognizes when the cryptographic toolkit has initiated a non-blocking hardware-accelerated cryptographic operation by use of function return values and error
|
