GB2366974A

GB2366974A - Pre-processing data for secure protocol transfer

Info

Publication number: GB2366974A
Application number: GB0113692A
Authority: GB
Inventors: Edward J Dobner; David G Kuehr-Mclaren; Patrick Michael Livecchi; Timothy G Shoriak
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2000-06-08
Filing date: 2001-06-06
Publication date: 2002-03-20
Anticipated expiration: 2021-06-06
Also published as: GB0113692D0; KR20010110991A; CN1309207C; KR100423191B1; GB2366974B; CN1329417A

Abstract

The invention concerns file transmission using a secure protocol such as Secure Sockets Layer (SSL) or Transaction Layer Security (TLS). Files to be served are pre- processed to insert empty spaces therein, in the location(s) where hash values are required according to the protocol definition. When the file is requested by a client, actual hash values are computed and substituted for the reserved empty spaces. This technique enables sending large blocks of data to an encryption engine and takes advantage of resulting processing efficiencies, without regard to smaller size limitations for message segments that are imposed by a security protocol definition.

Description

<Desc/Clms Page number 1> IMPROVING SECURE SERVER PERFORMANCE WITH PRE-PROCESSED DATA READY FOR SECURE PROTOCOL TRANSFER The present invention relates to a computer system, and deals more particularly with a method, system, and computer program product for improving the performance of a secure server in a networking environment (such as the Internet) by pre-processing the data that will be transmitted using a secure protocol (such as Secure Sockets Layer, or "SSL", or an analogous security protocol such as Transaction Layer Security, or "TLS"). Secure Sockets Layer, or "SSL", is a networking protocol developed by Netscape Communications Corp. and RSA Data Security, Inc. to enable secure network communications in a non-secure environment. More particularly, SSL is designed to be used in the Internet environment, where it operates as a protocol layer above the TCP/IP (Transmission Control Protocol/Internet Protocol) layers. The application code then resides above SSL in the networking protocol stack. After an application (such as a browser) creates data to be sent to a peer in the network, the data is passed to the SSL layer where various security procedures are performed on it, and the SSL layer then passes the transformed data on to the TCP layer. On the receiver's side of the connection, after the TCP layer receives incoming data it passes that data upward to the SSL layer where procedures are performed to restore the data to its original form, and that restored data is then passed to the receiving application. The most recent version of SSL is described in detail in "The SSL Protocol, Version 3.0", dated November 18, 1996 and available on the World Wide Web ("Web") at http://home.netscape.com/eng/ss13/draft302.txt (hereinafter, "SSL specification"). The protocols underlying the Internet (TCP/IP, for example) were not designed to provide secure data transmission. The Internet was originally designed with the academic and scientific communities in mind, and it was assumed that users of the network would be working in non- adversarial, cooperative manners. As the Internet began to expand into a public network, usage outside these communities was relatively limited, with most of the new users located in large corporations. These corporations had the computing facilities to protect their user's data with various security procedures, such as firewalls, that did not require security to be built into the Internet itself. In the past few years, however, Internet usage has skyrocketed. Millions of people now use the Internet and the Web on a regular basis. (Hereinafter, the terms "Internet" and "Web" are used synonymously unless otherwise indicated.) These users perform a wide variety of tasks, from exchanging electronic mail messages to searching for information to performing business transactions. These users may be

accessing the Internet from home, from their cellular phone, or from a number of other environments where security procedures are not commonly available. To support the growth of the Internet as a viable place to do business, often referred to as "electronic commerce" or simply "e-commerce", easily- accessible and inexpensive security procedures had to be developed. SSL is one popular solution, and is commonly used with applications that send and receive data using the HyperText Transfer Protocol ("HTTP"). HTTP is the protocol most commonly used for accessing that portion of the Internet referred to as the Web. When HTTP is used with SSL to provide secure communications, the combination is referred to as "HTTPS". Non-commercial Internet traffic can also benefit from the security SSL provides. SSL has been proposed for use with data transfer protocols other than HTTP, such as Simple Mail Transfer Protocol ("SMTP") and Network News Transfer Protocol ("NNTP"). SSL is designed to provide several different but complementary types of security. First is message privacy. Privacy refers to protecting message content from being readable by persons other than the sender and the intended receiver(s). Privacy is provided by using cryptography to encrypt and decrypt messages. SSL uses asymmetric cryptography, also known as public-key cryptography. A message receiver can only decrypt an encrypted message if he has the proper private key and decryption algorithm that are associated with the message creator's public key. Second, SSL provides data integrity for messages being transmitted. Data integrity refers to the ability for a message recipient to detect whether the message content was altered after its creation (thus rendering the message untrustworthy). A message creator passes the message through an algorithm which creates what is called a "message digest", or "message authentication code". Alternatively, the algorithm output is often referred to as a "hash" of the message, because algorithms of this type are known as "hashing algorithms". This digest or hash is sent along with the message. When the message is received, the receiver also processes the message through an algorithm, creating another digest. If the digest computed by the receiver does not match the digest sent with the message, then it can be assumed that the message contents were altered in some way after the message was created. The third security feature SSL provides is known as authentication. Communications over the Internet take place as a sequence of electronic signals, without the communicating parties being able to see each other and visually determine with whom they are communicating. Authentication is a technique that helps to ensure that the parties are who they represent themselves to be - whether the party is a human user or an application

program. For example, if a human user is buying goods over the Internet using a credit card, it is important for him to know that the application waiting on the other end of the connection for his credit card information is really the vendor he believes he is doing business with, and not an impostor waiting to steal his credit card information. These security features are very powerful, and provide a high degree of protection for Internet users. However, operation of the SSL protocol generates a significant amount of processing overhead. Secure Internet servers, such as secure HTTP servers, must be capable of responding in a timely manner to a very large number of requests for secure message content. The overhead of the SSL protocol causes these servers to become bottlenecks in the processing of client requests. The SSL protocol overhead can be attributed to three factors: (1) extra network traffic (e.g. in the handshaking protocol, where a number of various security-related parameters are negotiated in a sequence of message exchanges) ; (2) the use of relatively expensive asymmetric key cryptography operations for encryption and decryption of keys that are to be transmitted between the client and server as a secure session begins; and (3) the symmetric encryption of the bulk data to be transferred between the client and server. The first factor has been addressed by making efficiencies in SSL protocol implementations with regard to sockets. The second factor is being addressed by various vendors of cryptographic hardware adapter cards and accelerators. While encryption of the bulk data, the third factor, does not generate as much overhead as the other factors, it still consumes a significant amount of processing time. Many cryptographic hardware accelerators contain circuitry for symmetric encryption (referred to equivalently as "symmetric ciphers"), such as the well-known DES, 3DES, and RC4 ciphers. However, the nature of the SSL protocol makes it difficult to leverage any advantage from these accelerators. This is because the SSL protocol places a maximum size restriction of 16 Kilobytes on the data to be transmitted in the payload of any individual message transmission. Messages or files that exceed this size must therefore be segmented and exchanged using multiple message transmissions. (Some higher-level applications may even force the size restriction to be lower: applications are known for which the optimum segment size has been determined to be 4K.) The problem with this is that most cryptographic hardware cards and accelerators work most efficiently with large blocks of data. The SSL protocol, however, prohibits encrypting data in blocks larger than the maximum record size, because each encrypted block must include a hash value that was calculated (prior to the encryption process) over the data in the block. This restriction forces large messages to be sent to the encryption

engine using multiple segments that are each smaller than the maximum record size (i.e. having room for the inserted hash value within each segment), which in turn results in less- than-optimal use of the encryption engine. (An "encryption engine", as the term is used herein, refers to an encryption process which may be a hardware-implemented process such as a card or accelerator, but may alternatively be implemented in software in a particular environment, or in a combination of hardware and software.) The Transaction Layer Security (TLS) protocol is designed as a follow-on security technique that will eventually replace SSL. (SSL will end with Version 3.0, and TLS will begin with a version 1.0 that is based on the SSL Version 3.0 specification.) TLS is being standardized by a working group of the IETF (Internet Engineering Task Force), and is documented in "The TLS Protocol, Version 1.0 , dated January, 1999 (RFC 2246). The message exchanges in the TLS protocol are analogous to those of the SSL protocol, and thus implementations of TLS will also suffer from the inefficiencies which have been described above. One approach to increasing SSL throughput has been to push the entire protocol into a hardware device. In this case, the entire SSL protocol is done at the network layer, and the application only sees clear (unencrypted) data going into and out of the card interface. However, this can be difficult to efficiently manage in a single card, as a typical server may have hundreds of SSL sessions going on simultaneously. Also, different applications (and sometimes different ports inside the same application) may require variations in SSL processing, such as different key values, client authentication, etc. An SSL hardware device that performs the entire protocol will either not be flexible, or the cost of the card (both in throughput and in dollars) will raise as the functionality increases. In addition, SSL hardware will be difficult to update as new ciphers are added to SSL and/or TLS. Accordingly, the invention provides a computer program product for improving efficiency of symmetric encryption of bulk data for transmission using a secure protocol, said computer program product comprising: computer-readable program code means for determining a file to be securely transmitted; and computer-readable program code means for pre-processing said file to optimize a symmetric encryption process to be applied before said secure transmission, said pre-processing means comprising: computer-readable program code means for computing a record size of data to be used for said file during said secure transmission, wherein said record size is a transmit segment size minus a hash length; computer-readable program code means for segmenting said file into a sequence of records of said record size; computer-readable program code means for appending an

empty space to each of said sequence of records; and computer-readable program code means for writing each of said sequence of records and said appended empty spaces to an output file.

A technique for improving the manner in which the symmetric encryption of bulk data is performed for transmission using a secure protocol such as SSL or TLS is preferably provided According to a preferred embodiment this technique is provided such that the advantages of encrypting large blocks of data for transmission can be realized, even though the data is transmitted in multiple smaller blocks.

Preferably data files that will be sent using a secure protocol are pre-processed, where the pre-processing creates a revised file that is in an optimal form for encryption using a large block size yet adheres to protocol requirements for transmitting smaller block sizes.

According to a preferred embodiment a padding block is appended to the final one of the records prior to when the appending step operates on the final block.

A header is preferably prepended to a first of the records in the output file, wherein the header stores information comprising one or more of: (1) an identification of an encryption algorithm to be used by the symmetric encryption process; (2) an identification of a hashing algorithm to be applied to the records prior to operation of the symmetric encryption process; and (3) the record size.

According to a preferred embodiment, the technique further comprises: receiving a request for the file; locating the output file, responsive to the receiving; obtaining a hash key and an encryption key associated with the received request; applying a hashing algorithm to each of the records in the sequence, using the obtained hash key; substituting, for each of the records, a result of the hashing algorithm for the appended empty space, thereby creating a hashed file; encrypting the hashed file using the obtained encryption key and a symmetric encryption algorithm to perform the symmetric encryption process, thereby creating an encrypted file; and transmitting the encrypted file in response to the request. In this case, the technique preferably also further comprises: prepending a header to the output file, wherein the header stores information comprising an identification of the symmetric encryption algorithm; and adding the obtained encryption key to the header for use by the encrypting. Or, the prepended header may store information comprising an identification of the

hashing algorithm, in which case the technique further comprises adding the obtained hash key to the header for use by the applying. The header preferably further comprises an initialization vector to be used by the encrypting. The secure protocol may be Secure Sockets Layer (SSL), Transaction Layer Security (TLS), or another secure protocol. The invention further provides a system for improving efficiency of symmetric encryption of bulk data for transmission using a secure protocol, comprising: means for determining a file to be securely transmitted; and means for pre-processing said file to optimize a symmetric encryption process to be applied before said secure transmission, said pre-processing comprising: means for computing a record size of data to be used for said file during said secure transmission, wherein said record size is a transmit segment size minus a hash length; means for segmenting said file into a sequence of records of said record size; means for appending an empty space to each of said sequence of records; and means for writing each of said sequence of records and said appended empty spaces to an output file. The invention yet further provides a method for improving efficiency of symmetric encryption of bulk data for transmission using a secure protocol, comprising the steps of: determining a file to be securely transmitted; and pre-processing said file to optimize a symmetric encryption process to be applied before said secure transmission, said pre-processing comprising the steps of: computing a record size of data to be used for said file during said secure transmission, wherein said record size is a transmit segment size minus a hash length; segmenting said file into a sequence of records of said record size; appending an empty space to each of said sequence of records; and writing each of said sequence of records and said appended empty spaces to an output file. The invention yet further provides a system for symetrically encrypting bulk data for transmission using a secure protocol, said system comprising: means for receiving a request for a file which has been segmented into a sequence of records of a record size, wherein said record size is a size of data to be used for said file during transmission, and wherein said record size is a transmit segment size minus a hash length, and wherein said file has empty space appended to each of said sequence of records, said system further comprising: means for locating said file, responsive to receipt of said request; means for obtaining a hash key and an encryption key associated with said received request; means for applying a hashing algorithm to each of said records in said sequence, using said

obtained hash key; means for substituting, for each of said records, a result of said hashing algorithm for said appended empty space, thereby creating a hashed file; means for encrypting said hashed file using said obtained encryption key and a symmetric encryption algorithm to perform said symmetric encryption process, thereby creating an encrypted file; and means for transmitting said encrypted file in response to said request. According to a yet further aspect, the invention provides a method for symetrically encrypting bulk data for transmission using a secure protocol, said method comprising the step of: receiving a request for a file which has been segmented into a sequence of records of a record size, wherein said record size is a size of data to be used for said file during transmission, and wherein said record size is a transmit segment size minus a hash length, and wherein said file has empty space appended to each of said sequence of records, said method further comprising the steps of: locating said file, responsive to receipt of said request; obtaining a hash key and an encryption key associated with said received request; applying a hashing algorithm to each of said records in said sequence, using said obtained hash key; substituting, for each of said records, a result of said hashing algorithm for said appended empty space, thereby creating a hashed file; encrypting said hashed file using said obtained encryption key and a symmetric encryption algorithm to perform said symmetric encryption process, thereby creating an encrypted file; and transmitting said encrypted file in response to said request. The invention yet further provides a computer program comprising program code adapted to perform the above method. A preferred embodiment of the present invention will now be described by way of example only and with reference to the following drawings: Figure 1 is a block diagram of a computer workstation environment in which a preferred embodiment of the present invention is practiced; Figure 2 is a diagram of a networked computing environment in which a preferred embodiment of the present invention is practiced; Figures 3 and 4 depict flowcharts illustrating the logic which is used to implement a preferred embodiment of the present invention; and Figure 5 illustrates a data file to be transmitted to a requester, before and after processing the file according to a preferred embodiment of a present invention.

Figure 1 illustrates a representative workstation hardware environment in which a preferred embodiment of the present invention is practiced. The environment of Fig. 1 comprises a representative single user computer workstation 10, such as a personal computer, including related peripheral devices. The workstation 10 includes a microprocessor 12 and a bus 14 employed to connect and enable communication between the microprocessor 12 and the components of the workstation 10 in accordance with known techniques. The workstation 10 typically includes a user interface adapter 16, which connects the microprocessor 12 via the bus 14 to one or more interface devices, such as a keyboard 18, mouse 20, and/or other interface devices 22, which can be any user interface device, such as a touch sensitive screen, digitized entry pad, etc. The bus 14 also connects a display device 24, such as an LCD screen or monitor, to the microprocessor 12 via a display adapter 26. The bus 14 also connects the microprocessor 12 to memory 28 and long-term storage 30 which can include a hard drive, diskette drive, tape drive, etc.

The workstation 10 may communicate with other computers or networks of computers, for example via a communications channel or modem 32. Alternatively, the workstation 10 may communicate using a wireless interface at 32, such as a CDPD (cellular digital packet data) card. The workstation 10 may be associated with such other computers in a local area network (LAN) or a wide area network (WAN), or the workstation 10 can be a client in a client/server arrangement with another computer, etc. All of these configurations, as well as the appropriate communications hardware and software, are known in the art.

Figure 2 illustrates a data processing network 40 in which a preferred embodiment of the present invention is practiced. The data processing network 40 includes a plurality of individual networks, such as wireless network 42 and network 44, each of which includes a plurality of individual workstations 10. Additionally, as those skilled in the art will appreciate, one or more LANs may be included (not shown), where a LAN may comprise a plurality of intelligent workstations coupled to a host processor.

Still referring to Figure 2, the networks 42 and 44 also includes mainframe computers or servers, such as a gateway computer 46 or application server 47 (which accesses a data repository 48). A gateway computer 46 serves as a point of entry into each network 44. The gateway 46 is preferably coupled to another network 42 by means of a communications link 50a. The gateway 46 also directly coupled to one or more workstations 10 using a communications link 50b, 50c. The gateway computer 46 is

implemented utilizing, by way of example, an Enterprise Systems Architecture/370, or an Enterprise Systems Architecture/390 computer (both available from IBM), etc. Depending on the application, a midrange computer, such as an Application System/400 (also known as an AS/400) may be employed (also available from IBM). ("Enterprise Systems Architecture/370" is a trademark of IBM; "Enterprise Systems Architecture /390 ", "Application System/400", and "AS/400" are registered trademarks of IBM.) In this embodiment, the gateway computer 46 is also coupled 49 to a storage device (such as data repository 48). Further, the gateway 46 is directly or indirectly coupled to one or more workstations 10.

Those skilled in the art will appreciate that the gateway computer 46 may be located a great geographic distance from the network 42, and similarly, the workstations 10 may be located a substantial distance from the networks 42 and 44. For example, the network 42 may be located in California, while the gateway 46 may be located in Texas, and one or more of the workstations 10 may be located in New York. The workstations 10 connect to the wireless network 42 using a networking protocol such as the Transmission Control Protocol/ Internet Protocol ("TCP/IP") over a number of alternative connection media, such as cellular phone, radio frequency networks, satellite networks, etc. The wireless network 42 preferably connects to the gateway 46 using a network connection 50a such as TCP or UDP (User Datagram Protocol) over IP, X.25, Frame Relay, ISDN (Integrated Services Digital Network), PSTN (Public Switched Telephone Network), etc. The workstations 10 may alternatively connect directly to the gateway 46 using dial connections 50b or 50c. Further, the wireless network 42 and network 44 may connect to one or more other networks (not shown), in an analogous manner to that depicted in Fig. 2.

Software programming code which embodies a preferred embodiment of the present invention is typically accessed by the microprocessor 12 of a server (such as server 47) from long-term storage media 30 of some type, such as a CD-ROM drive or hard drive. The software programming code may be embodied on any of a variety of known media for use with a data processing system, such as a diskette, hard drive, or CD-ROM. The code may be distributed on such media, or may be distributed to users from the memory or storage of one computer system over a network of some type to other computer systems for use by users of such other systems. Alternatively, the programming code may be embodied in the memory 28, and accessed by the microprocessor 12 using the bus 14. The techniques and methods for embodying software programming code in memory, on physical media, and/or

distributing software code via networks are well known and will not be further discussed herein.

A user who requests a file which is processed according to a preferred embodiment of the present invention may connect his computer to a server using a wireline connection, or a wireless connection. Wireline connections are those that use physical media such as cables and telephone lines, whereas wireless connections use media such as satellite links, radio frequency waves, and infrared waves. Many connection techniques can be used with these various media, such as: using the computer's modem to establish a connection over a telephone line; using a LAN card such as Token Ring or Ethernet; using a cellular modem to establish a wireless connection; etc. The user's computer may be any type of computer processor, including laptop, handheld or mobile computers; vehicle-mounted devices; desktop computers; mainframe computers; etc., having processing (and optionally communication) capabilities. The remote server, similarly, can be one of any number of different types of computer which have processing and communication capabilities. These techniques are well known in the art, and the hardware devices and software which enable their use are readily available. Hereinafter, the user's computer will be referred to equivalently as a "workstation", "device", or "computer", and use of any of these terms or the term "server" refers to any of the types of computing devices described above.

In the preferred embodiment, the present invention is implemented as one or more computer software programs. The software may be implemented as one or more modules (also referred to as code subroutines, or "objects" in object-oriented programming). In one embodiment, the logic implementing the present invention is integrated with the code of a program which implements the SSL protocol. In an alternative embodiment it is implemented as one or more separate utility modules which provide services that are invoked by such a program, without deviating from the inventive concepts disclosed herein. The server for which the preferred embodiment operates is functioning as a Web server, where that Web server provides services in response to requests from a client connected through the Internet. Alternatively, the server is in a corporate intranet or extranet of which the client's workstation. is a component, or in any other network environment.

The preferred embodiment of the present invention will now be discussed in more detail with reference to Figs. 3 through 5.

Fig. 3 illustrates the logic with which a file is pre-processed, according to the preferred embodiment. This pre-processing prepares a file

such that it requires minimal processing for use with the SSL protocol, and such that it can be fed to an encryption engine in one or more large blocks in order to take advantage of the optimized processing that can be achieved thereby in the encryption engine. Fig. 4 then depicts the logic which is preferably used when a request is received for a file at the server, where the file was preferably pre-processed according to the logic of Fig. 3.

The pre-processing of Fig. 3 is preferably performed in advance, prior to receiving a client request for the file. Alternatively, the pre-processing is done upon receiving such a request, without deviating from the scope of the present invention. (In this latter case, the pre-processed file resulting from operation of Fig. 3 is then preferably stored in persistent storage, where it may be used to increase the efficiency of fulfilling subsequent client requests.) Simply stated, the pre- processing operation inserts holes, or empty space, into the file at the places where the SSL protocol will require a hash value.

The pre-processing operation begins at Block 300 of Fig. 3, where the file to be pre-processed is obtained. An optional file header may be created, as indicated in Block 310. This file header contains information about the file, which can be used to distinguish similar files from one another and to increase the efficiency of the subsequent encryption of the file. The SSL protocol provides for use of many different bulk encryption algorithms and hashing algorithms. A number of differences typically exist between different algorithms. For example, there are two SSL cipher suites for the bulk RC4 cipher, one of which uses the MD5 hashing algorithm and the other which uses the SHA-1 hashing algorithm. The MD5 hash uses 128 bits, whereas the SHA-1 hash uses 140 bits. Thus, a file which is pre-processed for use with the MD5 hash requires inserting smaller holes than a file which is pre-processed for use with an SHA-1 hash. Other differences may exist among cipher suites and algorithms as well, such as whether padding is required at the end of a file which does not end on a particular boundary that is a multiple of the record size used for transmission. Because of these types of differences, it is preferable to pre-process individual files in more than one format. The header of each stored version can then be used to identify which algorithms the pre-processed file is to be used with, and the appropriate stored version can be selected based upon which cipher suite is negotiated between a client and server. (This is discussed below with reference to Block 430 of Fig. 4.) The header also preferably indicates the record size which has been used when inserting the holes (although this information may be omitted if a default record size of 16K is always to be used).

Fig. 5A depicts an example of a data file to be transmitted to a requester, before processing the file according to a preferred embodiment of the present invention. The file content is stored as in the prior art, as a sequence of bytes. Fig. 5B illustrates this data file after processing the file according to the logic of Fig. 3. The optional header is shown at 510, and is stored once at the beginning of the pre-processed file. (Note that this header is preferably not transmitted to the client, but is used internally within the server for purposes of the present invention.) Returning to Fig. 3, the record size to be used in the transmitted message segments for this file is calculated at Block 320. This comprises subtracting the length of the hash from the length of the data to be used in the message payload. For example, if 16K bytes of data are to be transmitted in each message segment, and a 128-bit (16 bytes) hash is used for an MD5 hash as described above, then the record size computed at Block 320 is (16K - 16) bytes. The optional header, when used, is then written to the output file being created (Block 330). As stated above, the information which is written in the header preferably comprises an identification of the encryption algorithm and hashing algorithm for which this file is being prepared, and the record size which is being used. (Other information may be inserted subsequently into the header when preparing the file for encryption and transmission to a particular client according to Fig. 4, as will be described below.) Block 340 asks whether the file being processed is at the end. If so, then the processing of Fig. 3 is complete. Otherwise, processing iterates through the logic of Blocks 350 and 360 until the end of the input file is reached. Block 350 obtains the next bytes of the input file, for the length specified by the record size which was computed in Block 320, and appends an empty space to the end of this data. The empty space has the same length as required by the hashing algorithm for which the file is being prepared. If the number of bytes remaining to be processed in the input file is less than the computed record size, and if the cipher suite in use requires padding short blocks of this type, then Block 350 appends the required amount of padding prior to appending to empty space. Block 360 then writes the block of data which has been created by Block 350 to the output file, after which control returns to Block 340.

The output file of Fig. 5B illustrates how the input file of Fig. 5A is modified by the pre- processing operation of Fig. 3. Empty space (such as elements 525, 535) is shown following each data block (such as elements 520, 530). The empty space is inserted where the SSL protocol requires the hash of each data block. The final data block 590 in this example is

followed by padding space 592, which is then followed by the final empty space 595.

The logic of Fig. 4 is invoked when a request is received for transmission of a file to a client. When the request is received (Block 400 of Fig. 4A), a test is made to determine whether a pre-processed version of this file is available (Block 410). If not, then the file is processed and transmitted according to the prior art, as shown at Block 420, after which the processing of Fig. 4 is complete for this request. (Alternatively, the logic of Fig. 3 is invoked to create a pre-processed version of the file, as has been described above. In that case, the processing of Fig. 4 preferably continues at Block 430 after the pre-processing operation completes.) When the test in Block 410 has a positive result, Block 430 checks to see if a version is available which was prepared for the encryption algorithm and hashing algorithm which has been negotiated for use between the server and the requesting client. If not, then the file is processed and transmitted according to the prior art, as shown at Block 420; or, in an alternative embodiment the logic of Fig. 3 is invoked to create an appropriate version, after which the processing of Fig. 4 preferably continues at Block 440.

Control reaches Block 440 when a pre-processed version of the requested file is available. This file has empty spaces where the hash values required by SSL are to be inserted before transmitting the file to the requesting client. Block 450 obtains the encryption key and hash key to be used for further preparing the file for transmission. According to the SSL protocol, both the encryption key and the hash key are determined anew for each SSL connection. This necessitates delaying the computation of the hash values until the intended recipient is known (which is the motivation for storing the pre-processed files with empty spaces where the hash value belongs, rather than an actual computed hash value).

Block 460 (Fig. 4B) then checks to see if the end of the file being processed has been reached. If not, then Blocks 480 and 495 are invoked repeatedly to process the output file, further preparing it for transmission to the intended recipient. Block 480 computes a hash over the next block of data in the file, using the hashing algorithm which was negotiated (according to the prior art SSL handshaking protocol) for this client. Block 495 then inserts the computed hash in place of the reserved empty space for this block, after which control returns to Block 460. (Preferably, a data buffer or temporary file is used, rather than rewriting directly into the pre- processed file.)

When the hash values for entire file to be transmitted have been computed, control reaches Block 470. Block 470 passes the processed data buffer, along with the encryption key to be used for transmitting to this client, to the encryption engine. If an initialization vector is to be used for priming the encryption engine, then this vector is preferably passed at this time as well. After the encryption engine has encrypted the data buffer (using blocks of data in sizes which are appropriate to the particular encryption engine in use), the data is then segmented according to the record size to be used (e.g. the maximum 16K record size of the SSL protocol). The multiple segments of the file are then inserted into the payload of multiple outgoing SSL messages (one segment per message payload) and transmitted to the client as shown at Block 490, using prior art SSL messages and techniques. (The actual sending of the data is preferably performed directly from the encryption engine: this operation is shown in Fig. 4 for completeness, and is not meant to imply that the encrypted data must be returned to the same logic that performs the operations in Fig. 4 before it is transmitted to the client.) The processing of the client's request, using the processing improvements of a preferred embodiment of the present invention, is then complete.

In an optional aspect of the preferred embodiment, the header of the processed file is updated to include additional information prior to operation of Block 470. This additional information comprises: the encryption key to be used by the encryption engine; and an initialization vector to be used, if any, for priming the encryption algorithm. In this manner, a11 the information needed by the encryption engine is present in the file header. This approach is particularly advantageous when used with a hardware device or software interface which is designed to take a data file and return valid SSL records in bulk.

In one embodiment, the hash key is included in the file header. When this approach is used, the hashing process shown in Blocks 460, 480, and 495 is not performed prior to sending the file to the encryption engine, but rather is performed by the encryption engine itself upon receiving the file.

In one embodiment, when the hashing process is to be performed by the encryption engine, the hash key is passed to the encryption engine during the processing of Block 470 (described above).

Further processing efficiencies are realized by pipelining the encryption process through the encryption engine (or an array of encryption engines) in parallel, such that the encryption process overlaps the network latency of the client/server requests and responses.

As has been demonstrated, the present invention preferably provides an improved technique for symmetric encryption of bulk data that is to be transmitted to a requester using a secure protocol such as SSL or TLS, resulting in increased throughput and decreased delays when sending a file to a requester. Files are prepared and stored in a manner that enables sending chunks larger than 16K to the encryption engine. only slight modifications to existing SSL processing are required, along with simple modifications to a file to be served. No modifications to the SSL or TLS protocols are required. This technique offers a flexible solution that is easily adaptable for use with changing message payload sizes, as well as changing encryption algorithms and hashing algorithms (including changeable hash value lengths). This technique enables increasing the throughput of SSL traffic, with only very minor additional processing. The techniques disclosed herein are based upon certain predefined characteristics of the security protocols (SSL and TLS) being processed. It will be obvious to one of ordinary skill in the art that the inventive concepts disclosed herein may be adapted to changes in the security protocols, should they occur, including complete replacement with a new protocol having the same semantics as those discussed herein.

Claims

CLAIMS 1. A computer program product for improving efficiency of symmetric encryption of bulk data for transmission using a secure protocol, said computer program product comprising: computer-readable program code means for determining a file to be securely transmitted; and computer-readable program code means for pre-processing said file to optimize a symmetric encryption process to be applied before said secure transmission, said pre-processing means comprising: computer-readable program code means for computing a record size of data to be used for said file during said secure transmission, wherein said record size is a transmit segment size minus a hash length; computer-readable program code means for segmenting said file into a sequence of records of said record size; computer-readable program code means for appending an empty space to each of said sequence of records; and computer-readable program code means for writing each of said sequence of records and said appended empty spaces to an output file.
2. The computer program product according to Claim 1, further comprising computer-readable program code means, responsive to determining that a final one of said records is shorter than said record size, for appending a padding block to said final one of said records in order to fill the final record prior to when said computer-readable program code means for appending operates on said final block.
3. The computer program product according to Claim 1 or Claim 2, further comprising computer- readable program code means for prepending a header to a first of said records in said output file, wherein said header stores information comprising one or more of: (1) an identification of an encryption algorithm to be used. by said symmetric encryption process; (2) an identification of a hashing algorithm to be applied to said records prior to operation of said symmetric encryption process; and (3) said record size.
4. The computer program product according to any preceding claim, further comprising:

<Desc/Clms Page number 17>

computer-readable program code means for receiving a request for said file; computer-readable program code means for locating said output file, responsive to receipt of said request; computer-readable program code means for obtaining a hash key and an encryption key associated with said received request; computer-readable program code means for applying a hashing algorithm to each of said records in said sequence, using said obtained hash key; computer-readable program code means for substituting, for each of said records, a result of said hashing algorithm for said associated appended empty space, thereby creating a hashed file; computer-readable program code means for encrypting said hashed file using said obtained encryption key and a symmetric encryption algorithm to perform said symmetric encryption process, thereby creating an encrypted file; and computer-readable program code means for transmitting said encrypted file in response to said request.
5. The computer program product according to Claim 4 as dependent upon Claim 3, further comprising: computer-readable program code means for adding said obtained encryption key to said header for use by said computer-readable program code means for encrypting.
6. The computer program product according to Claim 4 as dependent upon Claim 3, or Claim 5, further comprising: computer-readable program code means for adding said obtained hash key to said header for use by said computer-readable program code means for applying.
7. The computer program Froduct according to Claim 5 or Claim 6, wherein said header further comprises an initialization vector to be used by said computer-readable program code means for encrypting.
8. The computer program product according to any preceding Claim, wherein said secure protocol is Secure Sockets Layer (SSL).

<Desc/Clms Page number 18>
9. The computer program product according to any of Claims 1 to 7, wherein said secure protocol is Transaction Layer Security (TLS).
10. A system for improving efficiency of symmetric encryption of bulk data for transmission using a secure protocol, comprising: means for determining a file to be securely transmitted; and means for pre-processing said file to optimize a symmetric encryption process to be applied before said secure transmission, said pre-processing comprising: means for computing a record size of data to be used for said file during said secure transmission, wherein said record size is a transmit segment size minus a hash length; means for segmenting said file into a sequence of records of said record size; means for appending an empty space to each of said sequence of records; and means for writing each of said sequence of records and said appended empty spaces to an output file.
11. The system according to Claim 10, further comprising means, responsive to determining that a final one of said records is shorter than said record size, for appending a padding block to said final one of said records in order to fill said final record prior to when said means for appending operates on said final block.
12. The system according to Claim 10 or Claim 11, further comprising means for prepending a header to a first of said records in said output file, wherein said header stores information comprising one or more of: (1) an identification of an encryption algorithm to be used by said symmetric encryption process; (2) an identification of a hashing algorithm to be applied to said records prior to operation of said symmetric encryption process; and (3) said record size.
13. The system according to Claim 10, 11 or 12, further comprising: means for receiving a request for said file;

<Desc/Clms Page number 19>

means for locating said output file, responsive to receipt of said request; means for obtaining a hash key and an encryption key associated with said received request; means for applying a hashing algorithm to each of said records in said sequence, using said obtained hash key; means for substituting, for each of said records, a result of said hashing algorithm for said associated appended empty space, thereby creating a hashed file; means for encrypting said hashed file using said obtained encryption key and a symmetric encryption algorithm to perform said symmetric encryption process, thereby creating an encrypted file; and means for transmitting said encrypted file in response to said request.
14. The system according to Claim 13 as dependent on Claim 12, further comprising: means for adding said obtained encryption key to said header for use by said means for encrypting.
15. The system according to Claim 13 as dependent on Claim 12, or Claim 14, further comprising: means for adding said obtained hash key to said header for use by said means for applying.
16. The system according to Claim 14 or Claim 15, wherein said header further comprises an initialization vector to be used by said means for encrypting.
17. The system according to any of Claims 10 to 16, wherein said secure protocol is Secure Sockets Layer (SSL).
18. The computer program product according to any of Claims 10 to 16, wherein said secure protocol is Transaction Layer Security (TLS).
19. A method for improving efficiency of symmetric encryption of bulk data for transmission using a secure protocol, comprising the steps of:

<Desc/Clms Page number 20>

determining a file to be securely transmitted; and pre-processing said file to optimize a symmetric encryption process to be applied before said secure transmission, said pre-processing comprising the steps of: computing a record size of data to be used for said file during said secure transmission, wherein said record size is a transmit segment size minus a hash length; segmenting said file into a sequence of records of said record size; appending an empty space to each of said sequence of records; and writing each of said sequence of records and said appended empty spaces to ::n output file.
20. The method according to Claim 19, further comprising the step of responsive to determining that a final one of said records is shorter than said record size, appending a padding block to said final one of said records in order to fill said final record prior to when said appending step operates on said final block.
21. The method according to Claim 19 or Claim 20, further comprising the step of prepending a header to a first of said records in said output file, wherein said header stores information comprising one or more of: (1) an identification of an encryption algorithm to be used by said symmetric encryption process; (2) an identification of a hashing algorithm to be applied to said records prior to operation of said symmetric encryption process; and (3) said record size.
22. The method according to Claim 19, 20 or 21, further comprising the steps of: receiving a request for said file; locating said output file, responsive to receipt of said request; obtaining a hash key and an encryption key associated with said received request; applying a hashing algorithm to each of said records in said sequence, using said obtained hash key;

<Desc/Clms Page number 21>

substituting, for each of said records, a result of said hashing algorithm for said associated appended empty space, thereby creating a hashed file; encrypting said hashed file using said obtained encryption key and a symmetric encryption algorithm to perform said symmetric encryption process, thereby creating an encrypted file; and transmitting said encrypted file in response to said request.
23. The method according to Claim 22 as dependent on Claim 21, further comprising the step of: adding said obtained encryption key to said header for use by said encrypting step.
24. The method according to Claim 22 as dependent on Claim 21, or Claim 23, further comprising the step of: adding said obtained hash key to said header for use by said applying step.
25. The method according to Claim 23 or Claim 24, wherein said header further comprises an initialization vector to be used by said encrypting step.
26. The method according to any of Claims 19 to 25, wherein said secure protocol is Secure Sockets Layer (SSL).
27. The method according to any of Claims 19 to 25, wherein said secure protocol is Transaction Layer Security (TLS).
28. A system for symetrically encrypting bulk data for transmission using a secure protocol, said system comprising: means for receiving a request for a file which has been segmented into a sequence of records of a record size, wherein said record size is a size of data to be used for said file during transmission, and wherein said record size is a transmit segment size minus a hash length, and wherein said file has empty space appended to each of said sequence of records, said system further comprising:

<Desc/Clms Page number 22>

means for locating said file, responsive to receipt of said request; means for obtaining a hash key and an encryption key associated with said received request; means for applying a hashing algorithm to each of said records in said sequence, using said obtained hash key; means for substituting, for each of said records, a result of said hashing algorithm for said appended empty space, thereby creating a hashed file; means for encrypting said hashed file using said obtained encryption key and a symmetric encryption algorithm to perform said symmetric encryption process, thereby creating an encrypted file; and means for transmitting said encrypted file in response to said request.
29. The system according to Claim 28, further comprising: means for prepending a header to said file, wherein said header stores information comprising an identification of said symmetric encryption algorithm; and means for adding said obtained encryption key to said header for use by said means for encrypting.
30. The system according to Claim 28, further comprising: means for prepending a header to said file, wherein said header stores information comprising an identification of said hashing algorithm; and means for adding said obtained hash key to said header for use by said means for applying.
31. The system according to Claim 29 or Claim 30, wherein said header further comprises an initialization vector to be used by said means for enc-ypting.
32. The system according to any of Claims 28 to 31, wherein said secure protocol is Secure Sockets Layer (SSL).

<Desc/Clms Page number 23>
33. The system according to any of Claims 28 to 31, wherein said secure protocol is Transaction Layer Security (TLS).
34. A method for symetrically encrypting bulk data for transmission using a secure protocol, said method comprising the step of: receiving a request for a file which has been segmented into a sequence of records of a record size, wherein said record size is a size of data to be used for said file during transmission, and wherein said record size is a transmit segment size minus a hash length, and wherein said file has empty space appended to each of said sequence of records, said method further comprising the steps of: locating said file, responsive to receipt of said request; obtaining a hash key and an encryption key associated with said received request; applying a hashing algorithm to each of said records in said sequence, using said obtained hash key; substituting, for each of said records, a result of said hashing algorithm for said appended empty space, thereby creating a hashed file; encrypting said hashed file using said obtained encryption key and a symmetric encryption algorithm to perform said symmetric encryption process, thereby creating an encrypted file; and transmitting said encrypted file in response to said request.
35. The method according to Claim 34, further comprising the steps of: prepending a header to said file, wherein said header stores information comprising an identification of said symmetric encryption algorithm; and adding said obtained encryption kzy to said header for use by said encrypting step.
36. The method according to Claim 34, further comprising the steps of:

<Desc/Clms Page number 24>

prepending a header to said file, wherein said header stores information comprising an identification of said hashing algorithm; and adding said obtained hash key to said header for use by said applying step.
37. The method according to Claim 35 or Claim 36, wherein said header further comprises an initialization vector to be used by said encrypting step.
38. The method according to any of Claims 34 to 37, wherein said secure protocol is Secure Sockets Layer (SSL).
39. The system according to any of Claims 34 to 37, wherein said secure protocol is Transaction Layer Security (TLS).
40. A computer program product comprising program code adapted to perform the method of any of claims 34 to 39 when said program is run on a computer.