JP4346962B2 - Encrypted communication control device - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to SSL (Secure Socket Layer) processing, which is a security protocol used as an access method that secures security to a Web server.
[0002]
[Prior art]
In SSL, application layer data is encrypted, and is divided into TCP (Transmission Control Protocol) packets that are transport layers and transferred. On the receiving side, encrypted data is assembled from a plurality of TCP packets, decrypted, and a MAC (Message Authentication Code) is calculated to confirm that the data has not been tampered with.
[0003]
There are the following documents as SSL or encrypted communication technologies, but these are general background technologies for the present invention.
[Patent Document 1]
JP 2002-077150 [Patent Document 2]
JP 2003-022321 A [Patent Document 3]
Japanese Patent Laying-Open No. 2003-092604 [Patent Document 4]
Japanese Patent Laid-Open No. 2003-504714 [0004]
[Problems to be solved by the invention]
In the conventional SSL, the encrypted data is divided into TCP and transferred. Therefore, the receiving side cannot perform the SSL processing until all the divided packets are received. For this reason, a delay occurs. In particular, in a server where access is concentrated, such as a Web site, performance is degraded due to delays associated with assembly and consumption of buffer memory. Further, when processing SSL at the relay point, it is necessary to divide and transfer again after the processing.
[0005]
An object of the present invention is to provide an encrypted communication control system that can solve such problems and reduce delay.
[0006]
[Means for Solving the Problems]
According to the first aspect of the present invention, encrypted transmission means for block-encrypting application layer data, and dividing the data into transmission control protocol packets as a transport layer, and transmission control protocol In the encrypted communication control system comprising the receiving and decrypting means for assembling the encrypted data, decrypting the encrypted data, decrypting the data into the application layer data, calculating the message authentication code and verifying that it has not been tampered with, The reception decryption means starts decryption as soon as a packet is received, and assembles the encrypted data, decrypts the data, and authenticates the message so that possible processing other than falsification verification is completed when all the packets are received. A way to schedule code calculations Encrypted communication control method is provided, wherein the was e.
[0007]
According to a second aspect of the present invention, encrypted transmission means for block-encrypting application layer data and dividing it into transmission control protocol packets as a transport layer, and transmission control protocol In the encrypted communication control system comprising the receiving and decrypting means for assembling the encrypted data, decrypting the encrypted data, decrypting the data into the application layer data, calculating the message authentication code and verifying that it has not been tampered with, The encrypted transmission means is provided with means for dividing the application layer data so that it can be transferred in a single packet of the transmission control protocol after block encryption is provided. The
[0008]
The dividing means sets the size of data transferred between the transmission source and the other party to a size that can be transferred by the one packet when the connection between the transmission source and the other party of the application layer data is established. Means for setting may be included.
[0009]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 is a block diagram showing an embodiment of the present invention. The present invention is implemented in an SSL communication apparatus 1 that decrypts SSL traffic from the Internet 4 to the server 5 and encrypts traffic going from the server 5 to the Internet 4 as shown in FIG. The SSL communication apparatus 1 includes a decryption circuit 2 that is in charge of a reception process from the Internet 4 to the server 5 and an encryption circuit 3 that is in charge of a transmission process from the server 5 to the Internet 4.
[0010]
FIG. 2 is a diagram for explaining encryption and decryption used in this embodiment. Communication between the SSL communication apparatus 1 and the Internet 4 is performed by SSL, and a block cipher that performs encryption for each group called a cipher block is used. At this time, the next block is encrypted using the encryption result of the previous block. At the time of decoding, if packets are received in the order of transmission, they can be sequentially decoded.
[0011]
FIG. 3 shows the SSL format. The SSL block includes an SSL header, a payload, a MAC (message authentication code), padding, and a padding length. The data portion (payload) is allowed up to a maximum of 18 KB, and a hash value is calculated over the entire data, and the presence or absence of tampering is checked by comparing with a MAC in the SSL. Since the data length of the TCP packet is shorter than the SSL data length, one SSL data is divided into a plurality of packets and transferred. For this reason, unless all of these packets are received on the receiving side, the reliability of the data cannot be confirmed.
[0012]
FIG. 4 is a diagram for explaining the conventional assembly, decryption, and hash calculation processing procedure, and FIG. 5 is a diagram for explaining the processing procedure of the present invention. Since SSL is divided and transferred to TCP, it is necessary to process it after assembling it on the receiving side. That is, first, ciphertext segmented into TCP is assembled and decrypted, and hash calculation is performed to check whether or not there is any falsification. On the other hand, in the present invention, focusing on the fact that the encryption algorithm can be decrypted as soon as it is received, the possible processing of decryption and hash calculation is performed in advance while assembling the packet. This reduces the delay.
[0013]
FIG. 6 is a diagram for explaining a TCP format at the time of transmission in the present invention. Since the sender's data length cannot be controlled when he / she is the receiving side, the speed is increased by the processing described above. On the other hand, at the time of transmission, the data length can be controlled. Therefore, instead of encrypting the application layer data and sending it by TCP, the data is divided and then encrypted by SSL, and the IP header and TCP header are added to form one TCP packet. As a result, the receiving side can perform decoding and verification for each packet.
[0014]
FIG. 7 is a block diagram showing details of the decoding circuit 2. The decryption circuit 2 includes an identification unit 201, an SSL reception buffer 202, a decryption scheduler 203, a decryption processing unit 204, a plaintext memory 205, a hash scheduler 206, a hash calculation processing unit 207, a hash memory 208, a plaintext transmission processing unit 209, and A session table 210 is provided.
[0015]
The identification unit 201 determines where the received traffic is from. This identified traffic is called a flow. A buffer is allocated for each flow recognized by the identification unit 201. The identified traffic enters the SSL reception buffer 202, is scheduled by the decoding scheduler 203 so as to be processed with the processing performance assigned for each flow, and is decoded by the decoding processing unit 204. Up to this point, the packet is executed as soon as it arrives. However, when the line state is bad and the packet order is changed, the decoding is not executed until the next packet comes. The data that has been decrypted by the decryption processing unit 204 is stored in the plaintext memory 205. When the length determined by the hash algorithm is decrypted, data of that length is scheduled from the plaintext memory 205 by the hash scheduler 206 and hash-processed by the hash calculation processing unit 207. The result of the hash calculation is stored in the hash memory 208 for use in the next hash process. The value remaining in the hash memory 208 when all processing is completed is the hash calculation result. All the SSL blocks (see FIG. 3) are decrypted, and if the hash calculation and the MAC value match, it is not falsified, and the plaintext transmission processing unit 209 performs transmission processing to the server 5. At this time, the MAC and padding added for SSL are removed.
[0016]
The session table 210 holds session / connection information used in SSL communication, and passes information to each unit during calculation. Any change in this information is reflected in the session table 210.
[0017]
FIG. 8 is a block diagram showing the details of the encryption circuit 3. The encryption circuit 3 includes an identification unit 301, a plaintext reception buffer 302, an encryption / hash scheduler 303, a hash calculation processing unit 304, an encryption processing unit 305, a hash memory 306, a ciphertext memory 307, a ciphertext transmission processing unit 308, and A session table 309 is provided.
[0018]
The identification unit 301 determines the flow from the server. The identified flow is stored in the plaintext reception buffer 302. In this embodiment, the encryption side adjusts so that the addition and encryption of the MAC is completed with a single packet. Unlike the decryption circuit 2, each flow can be encrypted without scheduling in units of bytes. When a new packet is input, the packet is encrypted to the end. If the packet order is changed, it will wait until the correct packet arrives. Encryption is performed when a correct packet arrives. One packet is encrypted in sequence for each flow. Since the encryption / hash scheduler 303 needs to add the MAC to the last part of the plaintext, the preceding process advances simultaneously with the hash calculation performed by the hash calculation processing unit 304 and the encryption performed by the encryption processing unit 305. Adjust to wait in part and complete encryption. The processing of the hash calculation processing unit 304 and the hash memory 306 is equivalent to the processing of the hash calculation processing unit 207 and the hash memory 208. The encryption processing unit 305 performs encryption processing while being adjusted by the encryption / hash scheduler 303. When the encryption processing unit 305 is completed, the encryption processing unit 305 passes the data to the ciphertext transmission processing unit 308 and is transferred to the Internet 4.
[0019]
The session table 309 holds session / connection information used in SSL communication, and passes information to each unit during calculation. Any change in this information is reflected in the session table 309.
[0020]
The operation of the decoding circuit 2 shown in FIG. 7 will be described in more detail.
[0021]
FIG. 9 shows a flowchart of the process of the SSL reception buffer 202, and FIG. 10 shows a flowchart of the process of the decoding scheduler 203. These processes are linked to the processes of the decryption processing unit 204.
[0022]
The SSL reception buffer 202 stores an SSL block as shown in FIG. 3 carried by TCP. At this time, the length of the SSL block read from the SSL header is SSL_Length, the number of bytes that can be continuously received without being replaced from the beginning is Dc, the number of decrypted bytes that have already been requested to the decryption scheduler 203 is Dp, Let Ddec be the number of bytes that is the unit of decoding determined by the algorithm.
[0023]
The SSL reception buffer 202 receives SSL cipher data from the network after the start of reception (step A1), and if it is the head of the SSL block (step A2), secures an area for the block, SSL_Length, Dc, Dp The initial value of Ddec is set (step A3). If the value obtained by subtracting the number of bytes for which the processing request has already been completed from the number of bytes that have been continuously received is larger than the number of bytes in the processing unit (step A4), a decoding processing request is sent to the decoding scheduler 203 (step S4). A5). When data is received after a certain interval such as packet switching, the number of consecutive received bytes increases suddenly, and several times the processing unit is requested to be decoded at once. Since the SSL block is not always an integral multiple of the processing unit, the last area makes a decoding process request when the number of consecutive received bytes matches the SSL block length (step A6) (step A7). Thereafter, this process is repeated.
[0024]
Flows are numbered to distinguish them. This is the flow identifier Flow_No. The decoding scheduler 203 receives the decoding processing request Q (Flow_No), the number of decoding bytes allocated to the flow is Unit (Flow_No), the number of bytes to be decoded this time is Dec_size, SSL The maximum number of flows supported by the communication device 1 is assumed to be Flow_max.
[0025]
As shown in FIG. 10, when the decoding scheduler 203 starts accepting a processing request, it first checks sequentially from Flow_No 1 to (Step B1) Flow_max. If there is a decryption request (step B2), the number of bytes to be processed is determined (step B3), and the number of bytes in the SSL ciphertext is decrypted (step B4). When the entire SSL block has been decoded (step B5), the buffer of the corresponding SSL block is released (step B6). When the decoding process is finished or there is no processing request, it is checked whether there is a processing request for the next flow (step B7). This is performed for all the flows, and is repeated thereafter.
[0026]
The decryption processing unit 204 operates in response to a trigger from the decryption scheduler 203 and sends the decrypted plaintext to the plaintext memory 205.
[0027]
FIG. 11 shows a flowchart of processing of the plaintext memory 205, and FIG. 12 shows a flowchart of processing of the hash scheduler 206. This processing is linked to the processing of the hash calculation processing unit 207 and the hash memory 208.
[0028]
The plaintext memory 205 stores the plaintext decrypted by the decryption processing unit 204. The plaintext block length is Plain_Length, the number of bytes received from the decryption processing unit 204 is D_plain, the number of bytes that have already been requested to the hash scheduler 206 is D_hash, and the unit of hash calculation processing determined by the hash algorithm Let Dcal be the number of bytes.
[0029]
In the plaintext memory 205, when plaintext is received from the decryption processing unit 204 (step C1), when it is the head of the plaintext block (step C2), initial values of Plain_Length, D_plain, D_hash, and Dcal are set ( Step C3). In the current specification, since the compression algorithm is not defined in SSL, Plain_Length = SSL_Length. If the number of bytes for calculating the hash is accumulated (step C4), a calculation processing request is issued to the hash scheduler 206 (step C5). Since the end of the plaintext block is not always the number of bytes as a calculation unit, a processing request is issued when the block length is received (step C6) (step C7). Since plaintext confirms delivery with the server after the MAC check, the buffer is not released at this stage. Thereafter, reception and hash processing requests are repeated.
[0030]
The hash scheduler 206 operates in the same manner as the decryption scheduler 203. When the acceptance of scheduling is started, hash processing requests for each flow are confirmed in order (step D1). The number of hash calculation request bytes is Qh (Flow_No), the number of hash calculation bytes assigned to a flow is Unith (Flow_No), and the number of bytes to be hash-calculated this time is Cal_size. It is checked whether there is a hash calculation request (step D2), and if there is, a processing byte number is determined (step D3). Information corresponding to the flow is obtained from the session table 210 and the hash memory 208, and the hash calculation processing unit 207 is controlled so as to calculate the hash with the plain text of Cal_size (step D4), and is recorded in the hash memory 208. It is checked whether or not the calculation of the hash has been completed (step D5). If it has been completed, a comparison with the MAC is performed, and control is performed to verify whether or not tampering has occurred (step D6). When this is completed, the next flow is checked, and when all the flows have been viewed, the first flow is checked again.
[0031]
The hash calculation processing unit 207 writes the calculation result in the hash memory 208, and this becomes an input for the next hash calculation. Finally, what remains in the hash memory 208 is the result of the hash calculation. If it is confirmed that the file has not been tampered with, the plaintext transmission processing unit 209 transfers the plaintext toward the server 5.
[0032]
Next, the operation of the encryption circuit 3 shown in FIG. 8 will be described in detail.
[0033]
The encryption circuit 3 encrypts communication from the server 5 to the Internet 4. Even after encryption, the SSL block as shown in FIG. 3 has an IP (Internet Protocol) header and TCP as shown in FIG. Adjustments are made in advance so that they fit in one packet after adding a header. Since the SSL header and padding are added at the time of encryption, the packet sent out by the server 5 may be shortened in advance by this length. For this purpose, the sequence shown in FIG. 13 is used in the process of establishing a TCP connection.
[0034]
FIG. 13 shows a sequence for establishing a connection with a user who accesses the server 5 via the Internet 4. When a TCP SYN packet is sent from the user, the SSL communication apparatus 1 operates as follows in order to establish a TCP connection between the user and the server 5. First, a DF (fragment prohibition) bit of the IP header is set and transmitted to each of the user and the server to obtain a path MTU (maximum transfer unit). The SSL communication apparatus 1 sets the MSS (maximum segment size) to an appropriate value by the TCP handshake so that the path MTU is not exceeded even if encryption is performed by SSL on the user side and the server 5 side. The TCP connection is established while notifying this value.
[0035]
FIG. 14 shows a flowchart of processing of the plaintext reception buffer 302. When reception of plain text from the server 5 is started, it is stored in the buffer of the corresponding flow (step E1). Next, if the packet to be encrypted can be received (step E2), a hash calculation and an encryption process are requested to the encryption / hash scheduler 303 (step E4). If the packet order is not correct, the buffer is put in the buffer and the next packet is waited (step E3). The encryption / hash scheduler 303 is notified of the buffer start position, data size, flow number, and the like. It then waits for the next packet.
[0036]
FIG. 15 shows a flowchart of processing of the encryption / hash scheduler 303. The encryption / hash scheduler 303 obtains an encryption range that is possible without the MAC from the data size, and controls to execute the hash calculation and the encryption before adding the MAC in parallel (step F1). Upon completion of both, the hash value is added as the MAC to the rest of the plaintext, and the remaining encryption is controlled (step F2). Then, it is checked whether there is a next request. The encryption / hash scheduler 303 finishes processing the received packet at once. The processing is not interrupted after processing for a certain number of bytes as in the case of decoding. Also, the flow is not examined in order. Speed up by processing in the order of arrival. The amount of transmission data is controlled by TCP flow control. These are possible because the processing can be completed in packet units.
[0037]
Data is stored in the hash memory 306 in the hash calculation, and in the ciphertext memory 307 in the encryption. When the encryption is completed, the corresponding packet is transferred from the ciphertext memory 307 to the Internet 4.
[0038]
In the embodiment described above, the decryption circuit 2 must hold the received packet in the plaintext memory 205 until the MAC verification is completed to check for falsification, and wait for the verification to end. With respect to this point, there is a possibility that it can be operated at higher speed by adding a little contrivance.
[0039]
That is, the plaintext for which hash calculation has been completed is immediately transmitted to the server 5 without being buffered in the plaintext memory 205. Since the calculation of the hash can be performed sequentially, it can be transferred in order from the first one. With this method, the plaintext block is not buffered, so the processing speed can be increased as much as when processing is performed for each packet. At this time, when falsification is found during hash verification of the last packet, the plaintext transmission processing unit 209 discards this packet and waits for a timeout without performing retransmission to the server 5. Timeout takes a relatively long time, but is useful in situations where the frequency of tampering is not high. However, even if the last packet is discarded, there may be a problem in the case of a server implementation in which the packets that have arrived first are sequentially read, and there is model dependency.
[0040]
By not buffering plaintext blocks, in most cases where tampering does not occur, a significantly higher throughput and lower delay can be obtained than in the past, and only when tampering occurs, performance degradation associated with waiting for timeout occurs. In the configuration shown in FIG. 7, it can be said that the tampered packet does not reach the server 5 and the security strength is high. On the other hand, when the plaintext block is not buffered, a part of the altered packet reaches the server 5, which is somewhat dangerous, but enables high-speed communication.
[0041]
【The invention's effect】
According to the present invention, the processing can be started without waiting for the arrival of all the packets constituting the SSL block at the time of reception decoding. Thereby, the non-operation time of a processor etc. can be reduced and the performance can be fully utilized. In addition, because another flow can use the processing resources that are available for the flow that could not be decoded due to a change in packet order, etc., the operating rate of the processing unit can be improved and the performance can be used without waste. I can do it.
[0042]
Also, during encrypted transmission, it is possible to exchange packets that do not exceed the path MTU consistently from the user to the server, and that can fit in one packet even if SSL is used. By handling packets that do not exceed the path MTU, it is possible to prevent fragmentation associated with SSL conversion and to prevent sacrifice of performance degradation due to this to other performance. Thereby, it becomes possible to make use of the performance of the encryption processing unit.
[0043]
Further, when encryption / decryption is completed with a single packet, the processing load and delay of assembly and disassembly do not occur. When HTTP (Hyper Text Transfer Protocol) is passed to SSL and encrypted, and it is split by TCP, an assembly process is required at the decryption stage. When transferred, SSL decryption can be performed without assembling, and the original data can be obtained by detecting the end position of data by HTTP, or by considering the end of data by disconnecting the TCP connection.
[0044]
Further, when the SSL communication apparatus receives a TCP packet obtained by dividing HTTP from the server and performs SSL processing by regarding it as transmission data without performing HTTP assembly, the segment size is optimized and received from the server in advance. There is also an advantage that the data accommodation efficiency is better than dividing by the communication device.
[0045]
Furthermore, according to the present invention, the operation rate of the encryption processing unit is improved, and the delay and the processing load are reduced in both directions, so that the amount of memory necessary for the buffer can be reduced. As a result, it is possible to hold more session information in a memory with a sufficient margin.
[Brief description of the drawings]
FIG. 1 is a block diagram showing an embodiment of the present invention.
FIG. 2 is a view for explaining encryption and decryption used in this embodiment.
FIG. 3 is a diagram showing an SSL format.
FIG. 4 is a diagram illustrating processing procedures for conventional assembly, decryption, and hash calculation.
FIG. 5 is a diagram illustrating a processing procedure according to the present invention.
FIG. 6 is a diagram for explaining a TCP format at the time of transmission.
FIG. 7 is a block diagram showing details of a decoding circuit.
FIG. 8 is a block configuration diagram showing details of an encryption circuit.
FIG. 9 is a flowchart of SSL reception buffer processing.
FIG. 10 is a flowchart of processing of a decoding scheduler.
FIG. 11 is a flowchart of plaintext memory processing.
FIG. 12 is a flowchart of processing of a hash scheduler.
FIG. 13 is a diagram showing a connection establishment sequence.
FIG. 14 is a flowchart of processing of a plaintext reception buffer.
FIG. 15 is a flowchart of encryption / hash scheduler processing;
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 1 SSL communication apparatus 2 Decryption circuit 3 Encryption circuit 4 Internet 5 Server 201, 301 Identification part 202 SSL reception buffer 203 Decryption scheduler 204 Decryption process part 205 Plain text memory 206 Hash scheduler 207, 304 Hash calculation process part 208, 306 Hash memory 209 plaintext transmission processing unit 210, 309 session table 302 plaintext reception buffer 303 encryption / hash scheduler 305 encryption processing unit 307 ciphertext memory 308 ciphertext transmission processing unit

Claims (1)

Decryption processing means for decrypting the encrypted data transferred to the application layer data after being block-encrypted and divided into transmission control protocol packets that are transport layers;
A verification means for calculating the message authentication code of the decrypted data and verifying that it has not been tampered with;
Plaintext transmission processing means for transferring data of the application layer verified not to be falsified to the server;
Decryption as soon as a packet is received, and an encryption comprising: the decryption processing means and means for scheduling the operation of the verification means so that possible processing other than tampering verification is completed when all packets are received In the communication control device,
The plaintext transmission processing device transfers the data decrypted by the decryption processing means to the server even if the verification by the verification means has not yet been performed, and the data verification means uses the last packet as the last packet. If tampering is detected, and discards the packet, the encrypted communication control apparatus characterized by waiting for a timed window bets server.

Images