JP2006279938A - Decryption apparatus for use in encrypted communication - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To maintain a security level of existent encrypted communication by monitoring encrypted communication data using an existent monitoring device. <P>SOLUTION: A decryption apparatus 3 for use in encrypted communication stores first key information for decrypting a packet transmitted from a terminal 1 and encrypting a packet destined to the terminal 1, second key information for decrypting a packet transmitted from a terminal 2 and encrypting a packet destined to the terminal 2, and an encryption algorithm. When a packet is received from the terminal 1, it is decrypted using the first key information according to the encryption algorithm, and the decrypted packet is encrypted using the second key information and transmitted to the terminal 2. When a packet is received from the terminal 2, the packet is decrypted using the second key information according to the encryption algorithm, and the decrypted packet is encrypted using the first key information and transmitted to the terminal 1. When relaying a packet, a decrypted packet is shaped to be processible by a monitoring device 4 and outputted to the monitoring device 4. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to an encryption communication decryption apparatus that encrypts a packet and performs authentication processing between transmission and reception using authentication data in order to prevent tapping and tampering of communication data in a communication system using, for example, IP (Internet Protocol). The present invention relates to an encryption communication decryption apparatus that monitors communication contents in order to detect or prevent unauthorized programs such as viruses and worms, unauthorized intrusion, information leakage, and the like in communications with enhanced security of communication data.

  Conventionally, an intrusion detection system (IDS) has been used as a communication monitoring system for monitoring and controlling communication data in order to detect or prevent unauthorized programs such as viruses and worms, unauthorized intrusion, and information leakage. Those employing an intrusion protection system (IPS), a virus wall, a content filter, and the like are known.

Among these security technologies, as a product corresponding to SSL (Secure Sockets Layer) which is one of encryption communication protocols, for example, Webwasher SSL Scanner and the technology described in Patent Document 1 below are known. The technology used in this product is a device that connects on the SSL communication path, internally terminates the SSL communication, decrypts the application data, and relays it after verifying it.
JP-A-10-93557

  However, in the conventional technique, even encrypted communication data can be decrypted and monitored to determine whether the communication data is abnormal. However, the communication data monitoring device and the decryption device are integrated. Therefore, there is a problem that the existing intrusion monitoring system cannot be reused. Therefore, in the above-described technique, when there is an existing IPS or IDS and it is intended to add and monitor encrypted communication data, a new decryption device and a monitoring device are used instead of the existing IPS and IDS. And had to be introduced.

  The communication inspection device described in Patent Document 1 decrypts and monitors the content of the packet, but does not re-encrypt and relay the decrypted packet for monitoring. It could not be said that the level was maintained.

  Therefore, the present invention has been proposed in view of the above-described circumstances, and enables encrypted communication data to be monitored by using an existing communication data monitoring device, thereby protecting the existing encrypted communication security. An object of the present invention is to provide an encryption / decryption device that can maintain a level.

  An encryption communication decryption device according to the present invention is provided between a first communication device and a second communication device, and transmits and receives encrypted packets between the first communication device and the second communication device. The monitoring device monitors the communication contents of the transmitted and received packets.

  The encryption communication decryption device decrypts a packet transmitted from the first communication device and encrypts a packet addressed to the first communication device, and a packet transmitted from the second communication device. And the second key information for encrypting the packet addressed to the second communication device and the first key information or the encryption algorithm using the second key information are stored in the storage means. . When the packet is received from the first communication device, the relay unit decrypts the packet using the first key information according to the encryption algorithm, and the decrypted packet is converted into the second key information. And encrypted and transmitted to the second communication device. In addition, when a packet is received from the second communication device, the relay unit decrypts the packet using the second key information according to the encryption algorithm, and the decrypted packet is converted into the first key information. And encrypted and transmitted to the first communication device.

  Such a cryptographic communication decryption device, when relaying a packet by the relay means, causes the output means to shape the packet decrypted by the relay means into a form that can be processed by the monitoring device, and output the packet to the monitoring device. By causing the monitoring device to monitor the communication contents, the above-described problems are solved.

  In addition, another encryption communication decryption device according to the present invention transmits a packet transmitted and received encrypted between the first communication device and the second communication device to the first communication device and the second communication. Interception is performed via a relay device provided on the communication path with the device, and the communication content of the packet is monitored by the monitoring device.

  The encrypted communication decryption device includes first key information for decrypting a packet transmitted from the first communication device to the second communication device, and a packet transmitted from the second communication device to the first communication device. The second key information to be decrypted and the encryption algorithm using the first key information or the second key information are stored in the storage means. When a packet is received from the first communication device, the packet is decrypted by the decrypting means using the first key information according to the encryption algorithm. Further, when a packet is received from the second communication device, the packet is decrypted by the decrypting means using the second key information according to the encryption algorithm.

  In such an encryption communication decryption device, the output unit shapes the packet decrypted by the decryption unit into a form that can be processed by the monitoring device, outputs the packet to the monitoring device, and causes the monitoring device to monitor the communication content. Solve the problem.

  According to the encryption communication decryption apparatus of the present invention, key information and an encryption algorithm are stored as information necessary for decrypting encryption communication, and the decrypted packet is processed into a form that can be processed by the monitoring apparatus. The communication content can be monitored by the monitoring device after shaping. Therefore, according to this encrypted communication decryption device, even if the communication content is encrypted, the communication content can be monitored, and a monitoring device that can analyze only the existing plaintext can be used. . Also, according to this encryption communication decryption apparatus, the communication contents are monitored without transmitting the decrypted packet to the first communication apparatus or the second communication apparatus, so that the security level of the existing encryption communication is maintained. can do.

  Hereinafter, first to third embodiments to which the present invention is applied will be described with reference to the drawings.

[First Embodiment]
The communication system according to the first embodiment to which the present invention is applied connects a cryptographic communication decryption apparatus on a cryptographic communication path, and acquires and relays communication data flowing on the cryptographic communication path. This communication system decrypts encrypted communication data when relaying the communication data by the encryption communication decryption device, shapes the decrypted communication data into a data form that can be processed on the monitoring side, and then performs legitimate communication. Monitor data. If the communication data is determined to be valid communication data, the encrypted communication decryption device re-encrypts the decrypted communication data and transmits it to the data transmission destination. Thus, it is monitored whether an illegal program such as a virus or a worm, an illegal intrusion, or an information leak has occurred on an encrypted communication path between communication apparatuses performing encrypted communication.

  Further, in this communication system, since the communication data is shaped by the encryption communication decryption device that decrypts the encrypted communication data, the encryption communication decryption device and the decrypted communication data monitoring device are configured separately. Any monitoring device can be used, and an existing monitoring device can be used.

  Furthermore, this communication system encrypts the communication data decrypted to monitor the encrypted communication data again by the encryption communication decryption device and relays it, thereby encrypting the encryption between the communication devices that are the subjects of the encrypted communication. Provide communication transparently. As a result, it is not necessary for the communication apparatus that performs communication on the encrypted communication path to change the setting from the existing communication process, and the security level of the existing encrypted communication is maintained.

[Configuration of communication system]
In this communication system, for example, as shown in FIG. 1, an encryption communication decryption device 3 is provided between a VPN (Virtual Private Network) terminal 1 (first communication device) and a VPN terminal 2 (second communication device). The present invention is applied to a communication system in which a VPN session is established. In this communication system, when communicating from the VPN terminal 1 to the VPN terminal 2 via the network N, the VPN terminal 1 and the VPN terminal 2 are used to prevent wiretapping of data on the network N and spoofing of the transmission source. The security of communication data is ensured by establishing a VPN session by IPsec (IP (Internet Protocol) security protocol). In this communication system, the encrypted communication decryption device 3 decrypts the communication content and outputs it to the network monitoring device 4. The network monitoring device 4 monitors the communication content and controls the relay by the encrypted communication decryption device 3. It is.

  In this communication system, the VPN terminal 2, the encryption / decryption device 3 and the network monitoring device 4 are connected by an IP (Internet Protocol) based LAN (Local Area Network). In this communication system, the network N is, for example, an IP network that can be used by the public.

  The VPN terminal 1 and the VPN terminal 2 perform processing (IKE processing) according to IKE (Internet Key Exchange) in order to construct a VPN session between the VPN terminal 1 and the VPN terminal 2 when it is necessary to transmit packets after performing encryption processing. A common key (hereinafter referred to as a session key), which is information for encrypting and decrypting communication data, is held. In addition, the VPN terminal 1 and the VPN terminal 2 generate a packet by performing processing conforming to IPsec, which is a security protocol in the network layer. Specifically, the VPN terminal 1 and the VPN terminal 2 perform a process (ESP process) according to an ESP protocol that creates a security protocol, for example, an encryption payload (ESP: IP Encapsulating security Payload), among protocols included in IPsec. Do.

  The encryption communication decryption device 3 receives data transmitted from the VPN terminal 1 or the VPN terminal 2 when the VPN terminal 1 and the VPN terminal 2 are performing the IKE process and the ESP process. And the encryption communication decoding apparatus 3 relays the packet transmitted / received by the VPN terminal 1 and the VPN terminal 2 by performing the predetermined process mentioned later. Furthermore, the encryption communication decryption device 3 decrypts the communication data (the payload portion of the ESP packet) encrypted by ESP, and shapes the decrypted communication data into an IP packet having a data structure that can be received by the network monitoring device 4. Output to the network monitoring device 4.

  When receiving the IP packet in which the ESP packet is decrypted and shaped by the encryption communication decryption device 3, the network monitoring device 4 analyzes the content of the IP packet. Here, the network monitoring device 4 performs legitimate communication data transmitted between the VPN terminal 1 and the VPN terminal 2 by performing, for example, an analysis process on whether or not a virus or worm is included. Or whether it is illegal. If the network monitoring device 4 determines that the communication data is inappropriate, the network monitoring device 4 notifies the network administrator or the like.

  In such a communication system, for the packet communication between the VPN terminal 1 and the VPN terminal 2, the encryption communication decryption device 3 performs processing such as decryption, reading, storage, modification, encryption, and transfer of the ESP packet. I do. As a result, the communication system intercepts communication between the VPN terminal 1 and the VPN terminal 2 and performs only the existing processing for the VPN terminal 1 and the VPN terminal 2, and the contents of the encrypted communication are transmitted to the network monitoring device 4. Can be monitored.

  In the following description, for simplicity of explanation, among the various procedures defined in RFC (Request For Comments) 2409, mutual authentication using a pre-shared key is performed in the main mode, and a part thereof is omitted. State the case. The secret key and the public key refer to the secret key and the public key in the Diffie-Hellman key sharing method defined in RFC2631, and further, description about error processing such as when unexpected data is input is omitted. To do.

[Configuration of Encryption Communication Decryption Device 3]
Next, a functional configuration of the encryption / decryption device 3 in the communication system described above will be described with reference to FIG. In the following description, the initiating side VPN terminal 1 or VPN terminal 2 that establishes the VPN session is called an initiator (initiating side communication device), and the responding side VPN terminal 1 or VPN terminal that reacts to the initiation of the initiator. 2 is called a responder (response side communication device). Each unit of the encryption communication decryption apparatus 3 described below stores a communication control program compliant with, for example, IKE or ESP in a ROM or the like, and each function obtained by executing the communication control program by the CPU. This corresponds to each unit realized by a unit, an interface circuit, and a hard disk device.

  As described above, the encryption communication decryption device 3 is connected to the network N and the network monitoring device 4, and transmits / receives IP packets to / from the network N and receives the network monitoring device 4 by the network monitoring device 4. Possible IP packets and LAN frames are transmitted. The encryption communication decryption device 3 intercepts an IP packet transmitted between the VPN terminal 1 and the VPN terminal 2 via the network N, and shapes it into a data form that can be analyzed by the network monitoring device 4.

  The encryption communication decryption device 3 includes a communication interface 11 for reception with respect to the VPN terminal 1 and the VPN terminal 2, a communication interface 12 for transmission, and a communication interface 13 that is an interface with respect to the network monitoring device 4.

  The communication interface 11 and the communication interface 12 are for reception and transmission for simplicity, but actually one of the two interfaces is fixedly connected to the VPN terminal 2 and the other is fixedly connected to the network N. That is, when a packet is received from the VPN terminal 2, one communication interface 11 is used as an interface on the VPN terminal 2 side, and the other communication interface 12 is used as an interface on the network N side. When a packet is received from the network N, one communication interface 11 is used as an interface on the network N side, and the other communication interface 12 is used as an interface on the VPN terminal 2 side.

  In addition, the encryption / decryption device 3 includes a pre-shared key holding unit 14 that stores a pre-shared key agreed in advance between the VPN terminal 1 and the VPN terminal 2 constituting the VPN session. The pre-shared key stored in the pre-shared key holding unit 14 is input by, for example, a network administrator's keyboard operation. The encryption communication decryption apparatus 3 sets not only pre-shared key protection but also information necessary for establishing a VPN session.

  Further, the encrypted communication decryption device 3 generates the communication contents between the VPN terminal 1 and the VPN terminal 2 decrypted by the packet decryption unit 15 by shaping them into the data format of the IP packet by the packet shaping unit 28, Output by the communication interface 13. Thereby, the encryption communication decoding device 3 can make the network monitoring device 4 evaluate the communication content.

  When the encrypted communication decryption apparatus 3 receives a packet containing data encrypted by the communication interface 11, the encrypted communication decryption apparatus 3 decrypts the packet by the packet decryption unit 15 and sends the decrypted data to the packet reading unit 16. If the packet received by the communication interface 11 does not include encrypted data, the packet data is sent to the packet reading unit 16 as it is. Then, the packet reading unit 16 determines the content of the plaintext data and sends necessary data to the packet generation unit 17, the session information holding unit 18, the public key holding unit 19, or the key shared data holding unit 20. send.

  The session information holding unit 18 stores, as session information, various information transmitted and received when performing IKE processing between the VPN terminal 1 and the VPN terminal 2. The session information of the initiator and the session information of the responder stored in the session information holding unit 18 are read when the session key generating unit 21 generates a session key.

  The public key holding unit 19 sends the initiator public key sent from the packet reading unit 16 (the public key of the communication device received from the initiating communication device) and the responder public key (the received key received from the responding communication device). The communication device public key), the initiator-side public key generated by the public key generation unit 22, and the responder-side public key are stored. The public key of the initiator stored in the public key holding unit 19 and the public key of the responder are read when the common secret key generation unit 24 generates the common secret key, and the public key on the initiator side is read by the initiator and the responder side The public key is read into the packet generation unit 17 when the public key is transmitted to the responder.

  The public key on the initiator side is generated by the encryption / decryption device in place of the responder, and corresponds to the public key of the responder. The public key on the responder side is generated by the encryption / decryption device in place of the initiator, and corresponds to the public key of the initiator.

  The key sharing data holding unit 20 proposes a plurality of IKESAs by the initiator, and the group description (Group Description) attribute of the transform payload in the proposal payload included in any of the IKESAs (valid IKESAs) selected by the responder. Store the value. The information stored in the key sharing data holding unit 20 is read when the secret key generation unit 23 generates a secret key, and is read when the common secret key generation unit 24 generates the common secret key.

  The secret key generation unit 23 generates a secret key on the initiator side and a secret key on the responder side, and stores them in the secret key holding unit 25. At this time, the secret key generation unit 23 refers to the value of the group description attribute held in the key sharing data holding unit 20 and determines the type of the secret key. The secret key on the initiator side is generated by the encryption / decryption device in place of the responder, and corresponds to the secret key of the responder. The secret key on the responder side is generated by the encryption / decryption device in place of the initiator, and corresponds to the secret key of the initiator.

  The public key generation unit 22 uses the responder-side secret key stored in the secret key holding unit 25 and the value of the oakley group associated with the value of the group description attribute stored in the key sharing data holding unit 20. To generate a public key on the responder side and to associate the secret key on the initiator side stored in the secret key holding unit 25 and the value of the group description attribute stored in the key sharing data holding unit 20 The public key on the initiator side is generated using the value of the Oakley group, and each public key is stored in the public key holding unit 19. Thereby, the packet generation unit 17 can read out each public key stored in the public key holding unit 19 when transmitting the public key to the initiator and the responder.

  The common secret key generation unit 24 stores the initiator public key stored in the public key holding unit 19, the initiator-side secret key stored in the secret key holding unit 25, and the key shared data holding unit 20. A common secret key (initiator side common secret key) of the initiator is generated from the value of the oakley group associated with the value of the group description attribute. Similarly, on the responder side, the common secret key generation unit 24 generates the responder's common secret key (responder's common secret key) from the responder's public key, the responder's secret key, and the value of the Oakley group. . Then, the common secret key generation unit 24 outputs the common secret key of the initiator and the common secret key of the responder to the session key generation unit 21.

  When the session key generation unit 21 inputs the common secret key of each of the initiator and the responder from the common secret key generation unit 24, the session key generation unit 21 uses the pre-shared key stored in the pre-shared key storage unit 14 to the session information storage unit 18. A SKEYID is generated with reference to the stored session information. Then, the session key generation unit 21 uses the generated secret key, the common secret key of the initiator and responder stored in the common secret key generation unit 24, and the session information stored in the session information holding unit 18 Referring to each, session keys are generated and stored in session key holding unit 26.

  In such an encryption communication decryption apparatus 3, when transmitting a packet to the responder or initiator, the packet generation unit 17 recognizes information stored in the packet and generates a packet according to the information from the packet reading unit 16. . When the packet generated by the packet generator 17 needs to be encrypted, the encryption / decryption device 3 reads the session key stored in the session key holding unit 26 by the packet encryption unit 27 and encrypts it. And transmitted from the communication interface 12.

  In addition, when the encryption communication decryption apparatus 3 completes an IKE process, which will be described later, by negotiating and determining a session key and an encryption algorithm, the VPN terminal 1 and the VPN terminal 2 use the session key determined by the IKE process. The network monitoring device 4 monitors the contents of the encrypted communication transmitted between the two. At this time, the packet shaping unit 28 shapes the packet that has been decrypted with the session key by the packet decrypting unit 15 into a data form that can be received and analyzed by the network monitoring device 4 and outputs the packet from the communication interface 13. Thereby, the encryption communication decryption device 3 causes the network monitoring device 4 to monitor the communication content of the encryption communication transmitted between the VPN terminal 1 and the VPN terminal 2.

  The detailed processing contents of the encryption / decryption device 3 will be described later.

[Operation of Encryption Communication Decryption Device 3]
Next, the operation of the encryption / decryption device 3 configured as described above will be described with reference to FIGS.

"Overall operation"
First, as an overall operation of the encryption communication decryption apparatus 3, as shown in FIG. 3, when a packet is received from the VPN terminal 1 or the VPN terminal 2 (step ST1), whether or not the packet is a packet in the IKE process (IKE packet). Is determined (step ST2). At this time, the encryption communication decryption apparatus 3 refers to the header of the lower protocol such as IP included in the packet by the packet reading unit 16, determines the type of the packet, and if it is determined that the packet is an IKE packet, The process proceeds to ST3, and if it is determined that the packet is not an IKE packet, the process proceeds to step ST4.

  In step ST3, before the data is communicated between the VPN terminal 1 and the VPN terminal 2, the encryption communication decryption apparatus 3 performs IKE processing for exchanging keys and establishing a VPN session. This IKE process generates the IKE session key and ESP session key of the VPN terminal 1, and the IKE session key and ESP session key of the VPN terminal 2 by performing the process defined in RFC2409. Here, in the IKE process, key exchange is performed according to ISAKMP (Internet security association key management) defined in RFC2408.

  In step ST3, every time the encrypted communication decryption apparatus 3 receives a packet in step ST1, it performs the IKE process once as shown in FIG. Then, after performing the IKE process of step ST3, the cryptographic communication decryption apparatus 3 advances the process to step ST6, transmits the packet generated by the IKE process to the VPN terminal 1 or the VPN terminal 2, and ends the process. The processing content shown in FIG. 4 will be described later.

  On the other hand, in step ST4, the encryption communication decryption apparatus 3 determines whether or not the packet received in step ST1 is an ESP packet. At this time, the encryption / decryption device 3 determines the type of the packet by referring to the header information included in the packet by the packet reading unit 16, and proceeds to step ST5 when determining that the packet is an ESP packet. If it is determined that the packet is not an ESP packet, the process proceeds to step ST6.

  In step ST5, the encryption communication decryption apparatus 3 performs ESP processing as shown in FIG. 5, and in step ST6, the packet generated by the ESP processing is transmitted to the VPN terminal 1 or the VPN terminal 2. The processing contents shown in FIG. 5 will be described later. In step ST6, if the packet to be transmitted has a checksum field, it is updated to a recalculated value.

"IKE processing"
Next, detailed contents of the IKE process in step ST3 described above will be described with reference to FIGS. This IKE process is performed from the first process indicated by the number “1” to the ninth process indicated by the number “9” as shown in FIG.

  This IKE process has two phases, a first phase and a second phase. In the first phase, partner authentication between the VPN terminal 1 and the VPN terminal 2, that is, authentication of the communication partner, and exchange of a session key used in the IKE process (hereinafter referred to as IKE session key) are performed.

  In the first phase, there are two modes: a main mode that encrypts the ID of each initiator and responder, and an aggressive mode that has a simplified procedure compared to the main mode because the ID is not encrypted. Either one is executed. In this example described below, a case will be described in which the main mode is performed as the first phase with the VPN terminal 1 as an initiator and the VPN terminal 2 as a responder.

"First process"
In this first phase, as shown in FIG. 6, the initiator first transmits a packet including an SA (security association) payload whose destination is set as a responder as an IKE packet S1. The SA payload includes an encryption algorithm for encrypting data in the IKE process, a hash algorithm for generating a message authentication code, a mutual authentication method, a prime number necessary for key generation (an Oakley group), a session key One or more pieces of data such as expiration dates (hereinafter referred to as IKESA) are included.

  Next, the encryption communication decryption apparatus 3 receives the IKE packet S1 including the SA payload transmitted from the initiator by the communication interface 11 (step ST1), determines that it is an IKE packet (step ST2), and performs the IKE shown in FIG. The process proceeds to step ST3.

  In this IKE process, first, in step ST11, the IKE packet S1 received by the communication interface 11 is input to the packet decoding unit 15, and the value stored in the flag field of the ISAKMP header of the IKE packet S1 by the packet decoding unit 15 is input. With reference to whether or not the encryption bit (E) is stored in the flag field, it is determined whether or not the data included in the IKE packet S1 is encrypted. In this case, since the data included in the IKE packet S1 including the SA payload is not encrypted, the data included in the IKE packet S1 is output from the packet decoding unit 15 to the packet reading unit 16 without being decrypted. The process proceeds to step ST13.

  In step ST13, the packet reading unit 16 extracts the ISAKMP header initiator cookie (Initiator Cookie) and SA payload values from the IKE packet S1, and stores them in the session information holding unit 18.

  Next, the packet reading unit 16 determines whether a key exchange (KE) payload is included after the ISAKMP header of the IKE packet S1 (step ST14), and whether a random number payload Nr is included (step ST14). Step ST18), it is determined whether or not a hash payload is included (step ST20). Since the IKE packet S1 does not include any of the key exchange payload, the random number payload, and the hash payload, the packet reading unit 16 does not perform the processes of Step ST15 to Step ST17, Step ST19, and Step ST21, and does not perform Step ST22 Proceed with the process.

  Next, in step ST22, the packet reading unit 16 determines whether or not the IKE packet S1 has been subjected to the processing in step ST12 and has been decoded. Then, the encryption communication decryption apparatus 3 outputs the IKE packet S1 received in step ST1 from the packet reading unit 16 to the packet generation unit 17 and transmits it from the communication interface 12 to the responder without being encrypted by the packet encryption unit 27. Let

  As a result, the responder receives the IKE packet S1. When the responder receives the IKE packet S1, the responder selects one IKESA (hereinafter referred to as a valid IKESA) from the IKESA included in the SA payload of the IKE packet S1, and the SA payload including the valid IKESA. IKE packet S2 is generated, and the destination is transmitted as the initiator.

"Second process"
Next, the encryption communication decryption apparatus 3 receives the IKE packet S2 transmitted from the responder by the communication interface 11 of the encryption communication decryption apparatus 3 (step ST1), determines that it is an IKE packet (step ST2), and FIG. The process proceeds to the IKE process shown (step ST3).

  In this IKE process, first, in step ST11, the IKE packet S2 received by the communication interface 11 is input to the packet decoding unit 15, and the value stored in the flag field of the ISAKMP header of the IKE packet S2 by the packet decoding unit 15 is input. With reference to whether or not the encryption bit (E) is stored in the flag field, it is determined whether or not the data included in the IKE packet S2 is encrypted. In this case, since the IKE packet S2 including the valid IKESA is not encrypted, the IKE packet S2 is output from the packet decrypting unit 15 to the packet reading unit 16 without being decrypted, and the process proceeds to step ST13.

  In step ST13, the packet reading unit 16 extracts the responder cookie (Responder Cookie) of the ISAKMP header and the valid IKESA included in the SA payload from the IKE packet S2, and stores them in the session information holding unit 18. Further, the packet reading unit 16 stores the value of the group description attribute of the transform payload in the proposal payload included in the valid IKESA in the key sharing data holding unit 20.

  Next, the packet reading unit 16 determines whether the key exchange payload is included after the ISAKMP header of the IKE packet S2 (step ST14), whether the random number payload Nr is included (step ST18), the hash payload Is included (step ST20). Since the IKE packet S2 does not include any of the key exchange payload, the random number payload, and the hash payload, the packet reading unit 16 does not perform steps ST15 to ST17, step ST19, and step ST21, but performs step ST22. Proceed with the process.

  Next, the packet reading unit 16 determines whether or not the IKE packet S2 has been subjected to the process of step ST12 and has been decoded, and ends the process because it has not been decoded. Then, the encryption communication decryption apparatus 3 outputs the IKE packet S2 received in step ST1 from the packet reading unit 16 to the packet generation unit 17, and transmits it from the communication interface 12 to the initiator without being encrypted by the packet encryption unit 27. Let

  As a result, the initiator receives the IKE packet S2. When the initiator receives the IKE packet S2, the initiator recognizes the IKESA included in the SA payload of the IKE packet S2 as a valid IKESA.

  As a result, the initiator, the responder, and the encryption communication decryption apparatus 3 are in a state where the valid IKESA is stored, and the negotiation of the contents of the IKESA indicating the encryption algorithm, the hash algorithm, and the like in the IKE process is completed. Then, the communication system shifts to key exchange.

That is, the initiator generates a secret key x by generating a random number, and the prime number p and the primitive element g indicated by the value of the group description attribute of the transform payload in the proposal payload included in the secret key x and the valid IKESA by using the door, to generate a public key g ^x mod p, to generate a key exchange payload KE containing the public key g ^x mod p. Further, the initiator generates a random number payload Ni including a separately generated random number Ni_b. Then, the initiator creates an IKE packet S3 including the generated key exchange payload KE and random number payload Ni, and transmits the destination as a responder. Note that the primitive element g is a constant 2 in IKE. Further, in the following description, for simplicity, mod p of the initiator public key g ^x mod p is omitted and expressed as an initiator public key g ^x . In the following description, mod p is omitted for the responder's public key and common secret key.

"Third process"
Next, the encryption communication decryption apparatus 3 receives the IKE packet S3 transmitted from the initiator by the communication interface 11 (step ST1), determines that it is an IKE packet (step ST2), and shifts to the IKE process shown in FIG. (Step ST3).

  In this IKE process, first, in step ST11, the packet decrypting unit 15 determines whether the data included in the IKE packet S3 received by the communication interface 11 is encrypted. In this case, since the IKE packet S3 is not encrypted, the IKE packet S3 is output from the packet decrypting unit 15 to the packet reading unit 16 without being decrypted, and the process proceeds to step ST13.

In step ST13, the packet analysis unit 16, together with the stores the public key storage unit 19 from the key exchange payload KE takes out the public key ^{g x} of the initiator of the IKE packet S3, the random number payload Ni of the IKE packet S3, the random number Ni_b And is stored in the session information holding unit 18.

  Next, the packet reading unit 16 determines whether or not the key exchange payload KE is included after the ISAKMP header of the IKE packet S3 (step ST14). Since the key exchange payload KE is included, step ST15 ~ The process proceeds to step ST17.

In step ST15, a secret key x ′ on the responder side is generated by the secret key generation unit 23 and stored in the secret key holding unit 25, and in the next step ST16, stored in the secret key holding unit 25 by the public key generation unit 22. The responder side public key g ^{x ′} is generated from the responder side secret key x ′ and stored in the public key holding unit 19, and in the next step ST17, the packet generation unit 17 receives the IKE received in step ST1. An IKE packet S3 ′ is generated by rewriting the public key g ^{x of the} initiator included in the packet S3 with the public key g ^{x ′} on the responder side stored in the public key holding unit 19.

  Next, the packet reading unit 16 determines whether or not the random number payload Nr is included in the IKE packet S3 (step ST18) and whether or not the hash payload is included (step ST20). Since the packet reading unit 16 does not include either the random number payload Nr or the hash payload, the process proceeds to step ST22 without performing steps ST19 and ST21.

  Next, the packet reading unit 16 determines whether or not the IKE packet S3 has been subjected to the process of step ST12 and has been decoded, and ends the process because it has not been decoded.

  Then, the encryption / decryption device 3 transmits the IKE packet S3 'created in step ST17 from the communication interface 12 to the responder without being encrypted by the packet encryption unit 27 (step ST6).

Accordingly, when the responder receives the IKE packet S3 ′, it generates a secret key y by generating a random number in the same manner as the initiator, generates a public key ^gy mod p using the secret key y, and generates the public key and it generates an IKE packet S4, containing a random number payload Nr including the key exchange payload and separately generated random number Nr_b including g ^y, and transmits the destination as an initiator.

Further, the responder generates SKEYID from the pre-shared key, the random number Ni_b of the initiator included in the random number payload Ni of the received IKE packet S3 ′, and its own random number Nr_b, and from the secret key y and the public key g ^{x ′} on the responder side The common secret key g ^x′y = (g ^{x ′} ) ^{y is} calculated. Then, the responder generates SKEYID_d, SKEYID_a, and SKEYID_e from the SKEYID, the common secret key g ^x′y , the initiator cookie, and the responder cookie.

"4th process"
Next, the encryption communication decryption apparatus 3 receives the IKE packet S4 transmitted from the responder by the communication interface 11 (step ST1), determines that it is an IKE packet (step ST2), and shifts to the IKE shown in FIG. 4 ( Step ST3).

  In this IKE process, first, in step ST11, the packet decrypting unit 15 determines whether the data included in the IKE packet S4 received by the communication interface 11 is encrypted. In this case, since the IKE packet S4 is not encrypted, the IKE packet S4 is output from the packet decrypting unit 15 to the packet reading unit 16 without being decrypted, and the process proceeds to step ST13.

In step ST13, the packet analysis unit 16, together with the stores the public key storage unit 19 from the key exchange payload removed public key ^{g y} of the responder of the IKE packet S4, from the random number payload of the IKE packet S4, taken out random Nr_b And stored in the session information holding unit 18.

  Next, the packet reading unit 16 determines whether or not the key exchange payload KE is included after the ISAKMP header of the IKE packet S4 (step ST14). Since the key exchange payload KE is included, step ST15 ~ The process proceeds to step ST17.

In step ST15, the secret key generation unit 23 generates the initiator-side secret key y ′ and stores it in the secret key holding unit 25. In the next step ST16, the public key generation unit 22 stores it in the secret key holding unit 25. and save it 'from the public key g ^y of the ^initiator' private key y of the initiator side has the public key holder 19 generates a next step ST17, holding the packet analysis unit 16 by the packet generating unit 17 the public key g ^y of the responder included in the IKE packet S4, creating a ^'IKE packet S4, rewritten to' public keys g ^y of the initiator, which is stored in the public key storage unit 19.

  Next, the packet reading unit 16 determines whether or not the random number payload Nr is included in the IKE packet S4 (step ST18), and since it is included, the process proceeds to step ST19.

In step ST19, the session key generation unit 21 generates an IKE session key in accordance with RFC2409. At this time, the encryption / decryption device 3 first uses the common secret key generation unit 24 to execute the initiator public key g ^x stored in the public key holding unit 19 and the initiator side stored in the secret key holding unit 25. The initiator's common secret key g ^{xy ′} is calculated from the secret key y ′ and the Oakley group p associated with the value of the group description attribute of the key sharing data holding unit 20.

Similarly, the common secret key generation unit 24, and a public key g ^y of the responder that stores the public key storage unit 19, a secret key x 'of the responder side that stores the secret key storage unit 25, a key sharing The responder's common secret key g ^x′y is calculated from the oakley group p associated with the group description attribute value of the data holding unit 20.

  Next, the session key generator 21 uses the effective common key hash algorithm from the pre-shared key held in the pre-shared key holding unit 14, the random number Ni_b stored in the session information holding unit 18, and the random number Nr_b. To generate SKEYID.

Then, the session key generation unit 21 uses the effective IKESA hash algorithm from the generated SKEYID, the initiator's common secret key g ^{xy ′} , the initiator cookie stored in the session information holding unit 18, and the responder cookie. KEYID_d, SKEYID_a, and SKEYID_e, which are IKE session keys, are generated and stored in the session key holding unit 26, respectively.

Similarly, the session key generation unit 21 the generated SKEYID, a common secret key ^{g x'y} of the responder, the initiator cookie is stored in the session information storage unit 18, from the responder cookie, using a hash algorithm of the valid IKESA Thus, SKEYID_d, SKEYID_a, and SKEYID_e, which are responder's IKE session keys, are generated and stored in the session information holding unit 18, respectively. The responder's IKE session key generated by the session key generation unit 21 has the same value as the session key generated by the responder when the IKE packet S4 is transmitted.

In this way, the encryption / decryption device 3 generates IKE session keys for the initiator and the responder from different common secret keys such as the common secret key g ^{xy ′} of the initiator and the common secret key g ^x′y of the responder. To do.

  Next, the packet reading unit 16 determines whether or not the hash payload is included in the IKE packet S4 (step ST20). Since the hash payload is not included, the process proceeds to step ST22 without performing the process of step ST21. Proceed with the process.

  Next, the packet reading unit 16 determines whether or not the IKE packet S4 has been subjected to the process of step ST12 and has been decoded, and ends the process because it has not been decoded.

  The encryption communication decryption apparatus 3 transmits the IKE packet S4 'created in step ST17 from the communication interface 12 to the initiator without being encrypted by the packet encryption unit 27 (step ST6).

Thus, when the initiator receives the IKE packet S4 ′, the initiator generates a SKEYID from the pre-shared key, the random number Nr_b included in the received random number payload, and the random number Ni_b generated by itself, and the secret key x and the IKE packet generated by the initiator. S4 from the 'public key g ^y of the initiator side that is included ^in', to compute a common secret key g ^{xy '.} Then, the initiator generates SKEYID_b, SKEYID_a, and SKEYID_e, which are session keys for IKE, from the generated SKIYID and common secret key g ^{xy ′} and the initiator cookie and responder cookie. Thus, the IKE session key created by the initiator has the same value as the IKE session key of the initiator generated when the encryption / decryption device 3 transmits the IKE packet S4 ′.

  As a result, the process of holding the IKE session key by the initiator and the responder is completed, and the IKE session key of the initiator and the IKE session key of the responder are held in the encryption communication decryption apparatus 3. More specifically, the initiator, responder, and encryption / decryption device 3 encrypt the data after the ISAKMP header of the IKE packet with the encryption algorithm set by the effective IKESA using SKEYID_e as the encryption key in the subsequent processing. Turn into.

Next, the initiator creates an ID payload including IDii that is its own ID and a hash payload including a hash value. At this time, the initiator calculates the hash from the SKEYID according to RFC 2409, the initiator public key g ^x , the initiator cookie, the responder cookie, the SA payload, and the ID payload of the initiator using the hash algorithm set by the valid IKESA. Create a hash payload containing the value HASH_I. Then, the initiator transmits an IKE packet S5 obtained by encrypting the hash payload and the ID payload with the IKE session key.

"Fifth process"
Next, the encryption communication decryption apparatus 3 receives the IKE packet S5 transmitted from the initiator by the communication interface 11 (step ST1), determines that it is an IKE packet (step ST2), and shifts to the IKE process shown in FIG. (Step ST3).

  In this IKE process, first, in step ST11, the packet decrypting unit 15 determines whether the data included in the IKE packet S5 received by the communication interface 11 is encrypted. In this case, since the IKE packet S5 is encrypted, the process proceeds to step ST12, and the packet decrypting unit 15 uses the valid IKESA encryption algorithm to store the initiator stored in the session key holding unit 26. Decryption is performed using the IKE session key, and it is output to the packet reading unit 16, and the process proceeds to step ST13.

  In step ST13, the packet reading unit 16 extracts the IDii of the initiator from the ID payload of the IKE packet S5 and stores it in the session information holding unit 18.

  Next, the packet reading unit 16 determines whether a key exchange payload is included after the ISAKMP header of the IKE packet S5 (step ST14), whether a random number payload Nr is included (step ST18), a hash payload Is included (step ST20). The packet reading unit 16 does not include either the key exchange payload or the random number payload Nr, but includes the hash payload. Therefore, the packet reading unit 16 does not perform the processing of Step ST15 to Step ST17 and Step ST19. The process proceeds to ST21.

In step ST21, the IKE packet S5 ′ obtained by changing the hash value HASH_I included in the hash payload of the IKE packet S5 held in the packet reading unit 16 to the hash value recalculated by the session information on the responder by the packet generation unit 17 is obtained. create. At this time, the hash value is stored by the packet generation unit 17 in the SKEYID, the responder-side public key g ^{x ′} transmitted to the responder held in the public key holding unit 19, the responder public key g ^y , and the session information holding unit 18. Using the stored initiator cookie, responder cookie, SA payload value of the IKE packet S1, and the IDii of the initiator, it is generated using a valid IKESA hash algorithm.

  In the next step ST22, since the packet decoding unit 15 performs decoding in the previous step ST12, the process proceeds to step ST23. In this step ST23, the packet encryption unit 27 reads the responder's IKE session key from the session key holding unit 26 using the effective IKESA encryption algorithm, and creates it in step ST21 using the IKE session key. The IKE packet S5 ′ is encrypted.

  Then, the encrypted communication decryption apparatus 3 transmits the encrypted IKE packet S5 'from the communication interface 12 to the responder (step ST6).

  When the responder receives the IKE packet S5 ′, the responder decrypts the IKE packet S5 ′ with the IKE session key, performs the same processing as when the initiator creates the IKE packet S5, calculates the hash value, and The hash value HASH_I included in the hash payload is compared. Since these values are the same, the responder determines that there has been no impersonation or tampering in the IKE process with the initiator.

Next, the responder creates an ID payload including IDir, which is its own ID, and a hash payload including a hash value. In this case, responder, SKEYID according to RFC2409, public key ^{g y} of the responder, the initiator cookie, responder cookie, SA payload, using the ID payload of the initiator, by performing the calculation with the set hash algorithms enable IKESA , A hash payload including the hash value HASH_R is created. Then, the responder transmits an IKE packet S6 in which the hash payload and the ID payload are encrypted with the IKE session key.

"Sixth process"
Next, the encryption communication decryption apparatus 3 receives the IKE packet S6 transmitted from the responder via the communication interface 11 (step ST1), determines that it is an IKE packet (step ST2), and shifts to the IKE process shown in FIG. (Step ST3).

  In this IKE process, first, in step ST11, the packet decrypting unit 15 determines whether the data included in the IKE packet S6 received by the communication interface 11 is encrypted. In this case, since the IKE packet S6 is encrypted, the IKE packet S6 is converted into the packet decryption unit 15 using the valid IKESA encryption algorithm using the responder session key stored in the session key holding unit 26. (Step ST12), and the process proceeds to step ST13.

  In step ST13, the packet reading unit 16 extracts the responder IDir from the ID payload of the IKE packet S6 and stores it in the session information holding unit 18.

  Next, the packet reading unit 16 determines whether the key exchange payload is included after the ISAKMP header of the IKE packet S6 (step ST14), whether the random number payload Nr is included (step ST18), the hash payload Is included (step ST20). In this case, the IKE packet S6 does not include either the key exchange payload or the random number payload Nr, and includes the hash payload. Therefore, without performing the processing of step ST15 to step ST17 and step ST19, The process proceeds to step ST21.

In step ST21, the packet generation unit 17 changes the hash value HASH_R included in the hash payload of the IKE packet S6 held in the packet reading unit 16 to the hash value recalculated by the session information on the initiator side. create. At this time, the hash value is saved by the packet generation unit 17 in the SKEYID, the initiator-side public key g ^{y ′} stored in the public key holding unit 19, the initiator public key g ^x , and the session information holding unit 18. From the initiator cookie, the responder cookie, the SA payload value of the IKE packet S1, and the IDir of the responder stored in the previous step ST13, the valid IKESA hash algorithm is used.

  In the next step ST22, since the packet decoding unit 15 performs decoding in the previous step ST12, the process proceeds to step ST23. In this step ST23, the packet encryption unit 27 reads the initiator IKE session key from the session key holding unit 26 using the effective IKESA encryption algorithm, and creates it in step ST21 using the IKE session key. The encrypted IKE packet S6 ′ is encrypted.

  Then, the encrypted communication decryption apparatus 3 transmits the encrypted IKE packet S6 'from the communication interface 12 to the initiator (step ST6).

  When the initiator receives the IKE packet S6 ′, the initiator decrypts the IKE packet S6 ′ with the IKE session key, calculates the hash value by performing the same process as when the responder creates the IKE packet S6, and the IKE packet S6 ′ Compare with HASH_R included in the hash payload. Since these values are the same, the initiator determines that there has been no impersonation or tampering in the IKE process with the responder.

  As a result, the communication partner has been authenticated between the initiator and the responder, and the first phase ends.

  Next, following the first phase, the process proceeds to the second phase in which the negotiation of the SA for the ESP process and the exchange of the ESP session key used in the ESP process are performed. In the second phase described below, a case where a process called a quick mode is performed according to the SA of the IKE process established in the first phase will be described.

  In the second phase of the quick mode, first, the initiator transmits an IKE packet S7 including a hash payload, an SA payload, and a random number payload Ni.

  The hash payload includes a hash value HASH (1) calculated by the first-phase valid IKESA hash algorithm from SKEYID_a obtained in the first phase, the message ID of the ISAKMP header, the SA payload, and the random number payload Ni. The SA payload is one set of negotiated data (hereinafter referred to as IPsec SA) in IPsec, such as an encryption algorithm for encrypting the ESP payload, a hash algorithm for generating authentication data, and an expiration date of the ESP session key. The above includes an index value (security parameter index: SPI) for selecting an ESP session key when an ESP packet described later is received. The random number payload Ni includes a newly generated random number Ni_b of the initiator. Then, the initiator encrypts the portion after the ISAKMP header using the IKE session key SKEYID_e by the effective IKESA encryption algorithm, and creates the IKE packet S7.

"Seventh process"
Next, when the IKE packet S7 is received by the communication interface 11, the encryption communication decryption apparatus 3 sends the IKE packet S7 to the packet decryption unit 15 and determines whether or not the IKE packet S7 is encrypted (step ST11). ). In this case, since the IKE packet S7 is encrypted, the packet decrypting unit 15 performs decryption (step ST12). At this time, the packet decryption unit 15 decrypts the IKE packet S7 using the IKE session key SKEYID_e of the initiator stored in the session key holding unit 26 in accordance with the encryption algorithm set in the valid IKESA of the first phase. To the packet reading unit 16.

  In the next step ST13, the packet reading unit 16 extracts the SA payload included in the IKE packet S7 and the random number payload including the random number Ni_b, and stores them in the session information holding unit 18.

  Next, the packet reading unit 16 determines whether a key exchange payload is included after the ISAKMP header of the IKE packet S7 (step ST14), whether a random number payload is included (step ST18), and whether the hash payload is It is determined whether it is included (step ST20). In this case, the IKE packet S7 does not include the key exchange payload and the random number payload Nr, but includes the hash payload. Therefore, the processing in step ST15 to step ST17 and step ST19 is not performed, and the process returns to step ST21. Transition.

  In step ST21, the packet generation unit 17 changes the hash value HASH (1) of the hash payload of the IKE packet S7 held in the packet reading unit 16 to the hash value recalculated by the information on the responder side. Is output to the packet encryption unit 27. At this time, the packet generation unit 17 receives the IKE session key SKEYID_a of the responder stored in the session key holding unit 26, the message ID of the ISAKMP header, the SA payload of the IKE packet S7 stored in the previous step ST13, and the random number Ni_b. And recalculate using a valid IKESA hash algorithm to generate a new hash value HASH (1).

  In the next step ST22, since the packet reading unit 16 has decoded the IKE packet S7 in the previous step ST12, the process proceeds to step ST23. In step ST 23, the IKE packet S 7 ′ is encrypted using the responder's IKE session key stored in the session key holding unit 26, and is output to the communication interface 12.

  Then, the encryption / decryption device 3 transmits the encrypted IKE packet S7 'from the communication interface 12 to the responder (step ST6).

  When the responder receives the IKE packet S7 ′, the responder calculates the hash value by performing the same process as when the initiator creates the IKE packet S7, and compares it with the hash value HASH (1) included in the hash payload of the IKE packet S7 ′. To do. Since these values are the same, the responder determines that there has been no impersonation or tampering in the IKE process with the initiator.

  Next, the responder selects one IPsec SA from the set of IPsec SAs included in the SA payload of the IKE packet S7 ′, and creates an SA payload including the selected IPsec SA (valid IPsec SA) and SPI value. In addition, a random number payload including a newly generated random number Nr_b is created. Then, the responder obtains the hash value HASH (2) from the IKE session key SKEYID_a, the message ID included in the ISAKMP header of the IKE packet S7 ′, the random number Ni_b included in the random number payload, and the created SA payload and random number payload. Calculate to create a hash payload containing the HASH (2).

  Then, the responder encrypts the part after the ISAKMP header with the IKE session key using the effective IKESA encryption algorithm, and transmits the IKE packet S8 including the hash payload, the SA payload, and the random number payload Nr.

  The responder uses the EKEY session key with the effective IKESA hash algorithm using the SKEYID_d, the valid IPsecSA protocol field included in the IKE packet S7 ', the initiator and responder SPI field values, and the random numbers Ni_b and Nr_b. A certain KEYMAT is generated.

"Eighth process"
Next, when the communication interface 11 receives the IKE packet S8, the encryption communication decryption apparatus 3 sends the IKE packet S8 to the packet decryption unit 15 and determines whether or not the IKE packet S8 is encrypted (step ST11). ). In this case, since the IKE packet S8 is encrypted, the packet decrypting unit 15 performs decryption (step ST12). At this time, the packet decryption unit 15 decrypts the IKE packet S8 using the responder IKE session key SKEYID_e stored in the session key holding unit 26 in accordance with the encryption algorithm set in the first phase valid IKESA. To the packet reading unit 16.

  In the next step ST13, the packet reading unit 16 extracts the valid IPsec SA included in the SA payload of the IKE packet S8 and the random number Nr_b included in the random number payload, and stores them in the session information holding unit 18.

  Next, the packet reading unit 16 determines whether or not the key exchange payload is included after the ISAKMP header of the IKE packet S8 (step ST14), whether or not the random number payload Nr is included (step ST18), and the hash payload. Is included (step ST20). In this case, the IKE packet S8 does not include the key exchange payload, but includes the random number payload Nr and the hash payload. Therefore, the processing in steps ST15 to ST17 is not performed, and steps ST19 and ST21 are performed. Transition.

  In step ST19, the session key generation unit 21 generates an ESP session key in accordance with RFC2409. At this time, the session key generation unit 21 firstly stores the IKE session key SKEYID_d of the initiator stored in the session key storage unit 26, the valid IPsec SA protocol field stored in the session information storage unit 18, the value of the SPI field, The random number Ni_b and the random number Nr_b are read out, and an ESP session key KEYMAT for the initiator is generated using a valid IKESA hash algorithm and stored in the session key holding unit 26.

  Similarly, the session key generation unit 21 includes a responder IKE session key SKEYID_d held in the session key holding unit 26, a valid IPsec SA protocol field stored in the session information holding unit 18, a value of the SPI field, and a random number. The Ni_b and the random number Nr_b are read, and the responder's ESP session key KEYMAT is generated using a valid IKESA hash algorithm and stored in the session key holding unit 26.

  In subsequent step ST21, the packet generation unit 17 changes the hash value HASH (2) included in the hash payload of the IKE packet S8 held in the packet reading unit 16 to the hash value recalculated by the information on the initiator side. S8 ′ is generated and output to the packet encryption unit 27. At this time, the packet generation unit 17 stores the IKE session key SKEYID_a of the initiator stored in the session key holding unit 26, the message ID of the ISAKMP header, the random number Ni_b of the initiator stored in the session information holding unit 18, the SA payload, The responder random number Nr_b is read, and the hash value is recalculated using the hash algorithm of the effective IKESA.

  In the next step ST22, since the packet reading unit 16 has decoded the IKE packet S8 in the previous step ST12, the process proceeds to step ST23. In this step ST 23, the IKE packet S 8 ′ is encrypted using the IKE session key of the initiator stored in the session key holding unit 26 and output to the communication interface 12.

  Then, the encrypted communication decryption apparatus 3 transmits the encrypted IKE packet S8 'from the communication interface 12 to the initiator (step ST6).

  When the initiator receives the IKE packet S8 ′, the initiator performs the same process as when the responder creates the IKE packet S8, calculates the hash value, and compares it with the hash value HASH (2) included in the hash payload of the IKE packet S8 ′. To do. Since these values are the same, the initiator determines that there has been no impersonation or tampering in the IKE process with the responder.

  Next, the initiator uses the effective IKESA hash from SKEYID_a, the message ID of the ISAKMP header of the received IKE packet S8 ′, the random number Ni_b generated by itself, and the random number Nr_b included in the random number payload of the received IKE packet S8 ′. A hash value HASH (3) is calculated by an algorithm, and a hash payload including the HASH (3) is created. Then, the initiator creates an IKE packet including the created hash payload, and transmits an IKE packet S9 obtained by encrypting the hash payload portion with the IKE session key.

  In addition, the initiator uses the effective IKESA hash algorithm using SKEYID_d, the valid IPsecSA protocol field included in the IKE packet S8 ′, the initiator and responder SPI field values, the random number Ni_b, and the random number Nr_b, KEYMAT, which is a session key for use, is generated.

"9th process"
Next, when the IKE packet S9 is received by the communication interface 11, the encryption communication decryption apparatus 3 sends the IKE packet S9 to the packet decryption unit 15 and determines whether or not the IKE packet S9 is encrypted (step ST11). ). In this case, since the IKE packet S9 is encrypted, in step ST12, the packet decrypting unit 15 uses the effective IKESA encryption algorithm to store the IKE session key of the initiator stored in the session key holding unit 26. Decrypt with. In the next step ST13, the packet reading unit 16 determines that the IKE packet S9 does not contain data to be stored in the session information holding unit 18, and proceeds to the next step ST14.

  Next, the packet reading unit 16 determines whether the key exchange payload is included after the ISAKMP header of the IKE packet S9 (step ST14), and whether the random number payload Nr transmitted by the responder is included (step ST18). ), It is determined whether or not a hash payload is included (step ST20). In this case, the IKE packet S9 does not include the key exchange payload and the random number payload Nr transmitted by the responder, and does not include the hash payload. Therefore, the processing in steps ST15 to ST17 and ST19 is not performed. The process proceeds to step ST21.

  In step ST21, the packet generation unit 17 generates an IKE packet S9 ′ in which the hash value included in the hash payload of the IKE packet S9 is changed to a hash value recalculated by the responder session information, and the packet encryption unit 27. At this time, the packet generation unit 17 uses the IKE session key SKEYID_a of the responder stored in the session key holding unit 26, the message ID of the ISAKMP header, the random number Ni_b and the random number Nr_b held in the session information holding unit 18. Then, recalculation is performed using the effective IKESA hash algorithm to generate a new hash value HASH (3).

  In the next step ST22, since the packet encryption unit 27 performs the decryption in the previous step ST12, the process proceeds to step ST23, the IKE session key of the responder is read from the session key holding unit 26, and the IKE packet is read. S9 ′ is encrypted and transmitted to the responder.

  When the responder receives the IKE packet S9 ′, the responder calculates the hash value by performing the same processing as when the initiator creates the IKE packet S9, and compares it with the hash value HASH (3) included in the hash payload of the IKE packet S9 ′. To do. Since these values are the same, the responder determines that there has been no impersonation or tampering in the IKE process with the initiator.

  As a result, the exchange of the ESP session key between the initiator and the responder is completed, and the encryption communication decryption apparatus 3 stores the initiator ESP session key and the responder ESP session key in the second phase. Exit.

  The session key for ESP has an expiration date for the session key set by IPsec SA, and a new ESP session key is generated by executing the second phase again before the expiration date. . In addition, the IKE session key has an expiration date for the session key set by IKESA, and a new IKE session key is generated by executing the first phase again before the expiration date. .

"ESP processing"
The communication system can perform ESP processing in which data is encrypted using the ESP session key and communication is performed between the VPN terminal 1 and the VPN terminal 2 after the IKE processing described above. In this ESP process, the process indicated by the number “11” is performed from the process indicated by the number “10” as shown in FIG.

  Specifically, when the VPN terminal 1 transmits data to the VPN terminal 2, the VPN terminal 1 encapsulates the data to be transmitted to the VPN terminal 2 using any protocol such as TCP (Transmission Control Protocol). create.

  Subsequently, the VPN terminal 1 adds an ESP trailer to the end of the IP packet in accordance with the procedure defined in RFC 2406, and sets the integral multiple of the block length of the IPsec SA encryption algorithm selected in the second phase. To encrypt with the session key for ESP. Then, an ESP header is added to the head of the encrypted data, and an IP header having the destination as the IP address of the VPN terminal 2 and the source as the IP address of the VPN terminal 1 is added to the head of the ESP header. An ESP packet S10 is created and transmitted. In the SPI field of the ESP header, the value of the SPI field of the SA payload transmitted by the VPN terminal 2 in the second phase of IKE is copied and stored.

  Next, when receiving the ESP packet S10 from the VPN terminal 1 (step ST1), the encryption communication decryption apparatus 3 refers to the IP header of the ESP packet S10 and determines that it is not an IKE packet (step ST2). The packet is determined to be a packet (step ST4), and the ESP process in step ST5 is started.

  In this ESP process, as shown in FIG. 5, the encryption communication decryption apparatus 3 first uses the ESP session key of the initiator stored in the session key holding unit 26 by the packet decryption unit 15 in step ST31. The encrypted part of the ESP packet S10 is decrypted according to the encryption algorithm set by IPsec SA. Then, the packet decryption unit 15 outputs the decrypted ESP packet S10 to the packet encryption unit 27 and simultaneously outputs it to the packet shaping unit 28.

  In the next step ST32, the packet shaping unit 28 takes out the ESP trailer from the decrypted encrypted part of the ESP packet S10 output from the packet decrypting unit 15 and converts it into a data format that can be processed by the network monitoring device 4. The packet is shaped and transmitted from the communication interface 13 to the network monitoring device 4 as a plain text packet. Specifically, when the packet shaping unit 28 receives the ESP packet S10 in the transport mode in the ESP protocol, as shown in FIG. 7A, first, the protocol field (next) is included in the ESP trailer of the ESP packet S10. The value of (header number) is copied to the protocol field of the IP header which is a lower layer of the ESP, and the ESP header and ESP trailer are deleted. The length of the ESP trailer is a value obtained by adding 2 bytes to the padding length field of the ESP trailer. Further, the packet shaping unit 28 reflects the change in the data length due to the deletion of the ESP header and ESP trailer in the lower layer header such as IP. Specifically, the IP header length field and checksum field are recalculated. Then, when the communication interface 13 and the network monitoring device 4 are connected via a LAN, the encryption / decryption device 3 has an Ethernet header with the destination address as the MAC address of the network monitoring device 4 at the head of the IP header. Append. Thereby, the network monitoring device 4 can reliably receive the packet, and can monitor the validity and the like by referring to the data of the decrypted plaintext packet.

  The network monitoring device 4 normally monitors all packets that have reached the communication interface even if the packet is not destined for its own address, but the packet shaping unit 28 sets the MAC address of the network monitoring device 4 as the destination. By doing so, when there is a switching hub between the encryption / decryption device 3 and the network monitoring device 4, it is possible to prevent the switching hub from transferring a packet to the port to which the network monitoring device 4 is connected. .

  Further, when receiving the tunnel mode ESP packet S10 in the ESP protocol, the packet shaping unit 28 copies and decodes the next header number (IP: 4) of the ESP trailer as shown in FIG. 7B. The next header number of the IP header (1) added to the head of the IP header (2) appearing at the head of the data is changed.

  In the next step ST33, the packet encryption unit 27 uses the responder's ESP session key to encrypt the decrypted portion of the ESP packet S10 in accordance with the encryption algorithm set in IPsec SA, and the ESP packet S10 ′. Is generated and transmitted from the communication interface 12.

  Next, when the VPN terminal 2 receives the ESP packet S10 ′, the VPN terminal 2 selects the data part after the ESP header according to the value of the SPI field of the ESP header by the encryption algorithm set by IPsec SA. Decrypt with key. Then, the VPN terminal 2 excludes the ESP trailer from the data obtained as a result of decoding, thereby restoring the IP packet encapsulated by the VPN terminal 1 and processing the data.

  Conversely, when the VPN terminal 2 transmits data to the VPN terminal 1, the same processing as described above is performed. However, in step ST31, the ESP packet S11 is decrypted using the responder's ESP session key. In step ST33, the ESP packet S11 'is encrypted using the initiator's ESP session key to generate the communication. It is transmitted from the interface 12.

  In step ST33 described above, the encrypted communication decryption apparatus 3 further includes a communication interface as input means for inputting communication contents output from an arbitrary monitoring apparatus, and before the encrypted communication contents are encrypted and transferred. The communication content may be shaped based on the processing information input from an arbitrary device and transferred after encryption. Specifically, when converting a plaintext IP packet into an ESP packet, the packet shaping unit 28 differs between the content of the ESP packet received from the VPN terminal 1 or the VPN terminal 2 and the content of the ESP packet to be transferred. To. For example, when information indicating a filtering condition of a packet from an arbitrary device is input, the packet shaping unit 28 may determine whether the ESP packet is relayed or not relayed according to the filtering condition.

[Effect of the first embodiment]
As described above in detail, according to the communication system to which the present invention is applied, the ESP session key and the encryption algorithm of the VPN terminal 1 and the VPN terminal 2 are stored as information necessary for decrypting the encrypted communication. In addition, the decrypted plaintext packet can be shaped into a form that can be processed by the network monitoring device 4 and monitored by the network monitoring device 4. Therefore, according to this encrypted communication decryption apparatus 3, even if the communication contents are encrypted, the network monitoring apparatus 4 that can monitor the communication contents and can analyze only the existing plaintext can be used. . Further, according to this communication monitoring system, even when the encrypted text is transparently decrypted on the encrypted communication path and monitored by the network monitoring device 4, it is encrypted again and transmitted to the VPN terminal 1 or VPN terminal 2. And the security level of encryption communication can be maintained.

  Further, according to this communication system, an arbitrary device is connected to the encryption / decryption device 3, and information indicating processing contents additionally performed by the encryption / decryption device 3 is input from the arbitrary device, and re-encryption is performed. It is possible to perform the added processing before relaying to the VPN terminal 1 or the VPN terminal 2 by performing the conversion.

[Second Embodiment]
Next, a communication system according to a second embodiment to which the present invention is applied will be described. In addition, about the same part as embodiment mentioned above, the detailed description is abbreviate | omitted by attaching | subjecting the same code | symbol and the same step number.

  As shown in FIG. 8, the communication system according to the second embodiment is configured such that the encryption / decryption device 3 'and the network monitoring device 4' perform two-way communication. In the communication system according to the second embodiment, the plaintext packet output from the encryption / decryption device 3 ′ to the network monitoring device 4 ′ is monitored by the network monitoring device 4 ′, and as a result, relayed by the network monitoring device 4 ′. This is characterized in that a function for discarding inappropriate packets is added by encrypting and relaying only the packets returned to the encrypted communication decryption apparatus 3 ′.

  As shown in FIG. 9, the encryption communication decryption device 3 ′ in the second embodiment additionally includes a communication interface 31 that receives a packet returned from the network monitoring device 4 ′. The received packet is returned to the state before shaping by the packet shaping unit 28, encrypted by the packet encryption unit 27, and output from the communication interface 12. Thereby, the encryption communication decryption device 3 ′ relays the ESP packet when the monitoring result of the network monitoring device 4 ′ is appropriate when relaying the ESP packet. On the other hand, if the monitoring result of the network monitoring device 4 ′ is inappropriate, the encryption communication decryption device 3 ′ does not return the packet and consequently does not relay the ESP packet.

  Further, the network monitoring device 4 ′ communicates with the encrypted communication decryption device 3 ′ through a communication interface that transmits and receives plaintext packets corresponding to the network N side, and a communication interface that transmits and receives plaintext packets corresponding to the VPN terminal 2 side. It becomes a gateway type communication device using two communication interfaces. When the encrypted communication decrypting device 3 ′ receives the plain text IP packet obtained by decrypting the ESP packet, the network monitoring device 4 ′ analyzes the content as in the first embodiment. If it is determined that the content of the packet is inappropriate, the relay of the inappropriate ESP packet is blocked by discarding the packet. On the other hand, when it is determined that the content of the packet is appropriate, the packet is transferred from a communication interface different from the received communication interface to the encryption / decryption device 3 ', and the packet is relayed as an ESP packet.

  Here, like the communication interface 11 and the communication interface 12 in the first embodiment, the communication interface 13 and the communication interface 31 are used for reception and transmission for the sake of simplicity, but actually, the two communication interfaces 13 and 31 are used. Are fixedly connected to the two communication interfaces of the network monitoring device 4 ′.

  When a packet is received from the VPN terminal 2, the communication interface on the VPN terminal 2 side becomes the communication interface 11 for reception, the communication interface on the network N side becomes the communication interface 12 for transmission, and the VPN of the network monitoring device 4 ′. The interface on the terminal 2 side is an interface connected to the communication interface 13, and the interface on the network N side of the network monitoring device 4 ′ is an interface connected to the communication interface 31. On the other hand, when a packet is received from the network N, the communication interface on the network N side becomes the communication interface 11 for reception, the communication interface on the VPN terminal 2 side becomes the communication interface 12 for transmission, and the network of the network monitoring device 4 ′ The interface on the N side is an interface connected to the communication interface 13, and the interface on the VPN terminal 2 side of the network monitoring device 4 ′ is an interface connected to the communication interface 31.

  Upon receiving an IP packet from the network monitoring device 4 ′, the communication interface 31 outputs the packet to the packet shaping unit 28, adds an ESP header and ESP trailer by the packet shaping unit 28, and outputs the packet to the packet encryption unit 27. The data is encrypted and transmitted from the communication interface 12.

  As shown in FIG. 10, the overall operation of the encryption / decryption device 3 ′ is as follows. In step ST41 after receiving the packet in step ST1, the received communication interface receives the plaintext packet, that is, the packet is transmitted. It is determined whether the communication interface 13 or the communication interface 31 has been received. If it is a communication interface that transmits and receives plaintext packets, the process proceeds to step ST42. If it is not a communication interface that transmits and receives plaintext packets, the process proceeds to step ST2 and subsequent steps.

  Further, when receiving the ESP packet from the VPN terminal 1 or the VPN terminal 2 (step ST1), the encryption communication decryption apparatus 3 ′ in the second embodiment determines that it is not a plaintext packet because it is received by the communication interface 11 ( In step ST41), it is determined that the packet is not an IKE packet (step ST2). In step ST4, the packet is determined to be an ESP packet, and ESP processing is started.

  As shown in FIG. 11, the ESP process is performed by using the corresponding ESP session key among the initiator and responder stored in the session key holding unit 26 by the packet decrypting unit 15 in step ST31, and using the IPsec SA. The encrypted part of the ESP packet is decrypted in accordance with the encryption algorithm set in step, and is output to the packet shaping unit 28.

  In the next step ST51, the packet shaping unit 28 shapes the ESP packet and converts it into an IP packet that can be received and analyzed by the network monitoring device 4 '. At this time, the packet shaping unit 28 extracts the ESP trailer from the packet obtained by decrypting the encrypted portion of the ESP packet input from the packet decryption unit 15 as described in FIG. 7A or 7B. Then, the packet is shaped so that the network monitoring device 4 ′ can process it, and in step ST6, it is transmitted to the network monitoring device 4 ′, and the processing is terminated.

  Here, in the packet shaping process of the packet shaping unit 28 in step ST51, for example, first, the value of the protocol field included in the ESP trailer of the ESP packet is copied to the protocol field of the IP header which is the lower layer of the ESP. , ESP header and ESP trailer are deleted. The length of the ESP trailer is a value obtained by adding 2 bytes to the value of the padding length field of the ESP trailer. Further, the packet shaping unit 28 reflects the change in the data length due to the deletion of the ESP header and ESP trailer in the lower layer header such as IP. Specifically, the IP header length field and checksum field are recalculated.

  When the communication interface 13 and the network monitoring device 4 ′ are connected via a LAN, the encrypted communication decrypting device 3 ′ uses the destination address as the MAC address of the network monitoring device 4 ′ at the beginning of the IP header. Add an ether header. As a result, the network monitoring device 4 ′ can reliably receive the packet, and can monitor the validity and the like by referring to the data of the decrypted plaintext packet.

  On the other hand, the network monitoring device 4 'analyzes the contents of the IP packet received from the encrypted communication decryption device 3', and discards the IP packet if determined to be inappropriate. On the other hand, when the content of the IP packet is determined to be appropriate by the network monitoring device 4 ', the IP packet is transmitted to the encrypted communication decryption device 3' from a communication interface different from the communication interface that has received the IP packet.

  On the other hand, when the encryption communication decryption apparatus 3 ′ receives the IP packet transmitted from the network monitoring apparatus 4 ′ by the communication interface 31 (step ST1), the IP packet is a plaintext packet. The process proceeds to ST42.

  In this plaintext processing, as shown in FIG. 12, first, in step ST 61, the IP packet received by the communication interface 31 is shaped into an ESP packet by the packet shaping unit 28 and output to the packet encryption unit 27. At this time, the packet shaping unit 28 performs a conversion opposite to that in step ST51. That is, referring to the length field and header length field of the IP header, the length of the IP header is subtracted from the header length to obtain the length of the data portion, and 2 bytes are added to the length of the data. Next, in order to obtain padding to be added to the added data, n bytes that are an integral multiple of the block length of the encryption algorithm set in IPsec SA are calculated. Then, an ESP header is added after the IP header of the IP packet, and an ESP trailer including n-byte padding is added to the end of the IP packet. At this time, n bytes of padding are copied to the padding length field of the ESP trailer, and the protocol field of the IP header is copied to the next header field of the ESP trailer. A value (50) indicating ESP is copied into the protocol field of the IP header. Further, the change in the data length due to the addition of the ESP header and ESP trailer is reflected in the lower layer header such as IP. Specifically, the IP header length field and checksum field are recalculated.

  In the next step ST62, the packet encryption unit 27 encrypts the decrypted ESP packet according to the encryption algorithm set in IPsec SA using the ESP session key, and transmits it from the communication interface 12.

  On the other hand, the VPN terminal 1 or the VPN terminal 2 that has received the ESP packet selects the data portion after the ESP header according to the value of the SPI field of the ESP header using the encryption algorithm set by IPsec SA. Decrypt with. Then, the VPN terminal 1 or the VPN terminal 2 can restore the encapsulated IP packet and process the IP packet by excluding the ESP trailer from the data obtained as a result of decoding.

[Effects of Second Embodiment]
As described above in detail, according to the communication system according to the second embodiment to which the present invention is applied, the plaintext packet is transmitted from the encrypted communication decryption device 3 ′ to the network monitoring device 4 ′, and the network monitoring device 4 ′. The packet relay can be stopped according to the monitoring result. Further, according to this communication system, it is possible to use the network monitoring device 4 ′ that detects and discards existing illegal packets.

[Third Embodiment]
Next, a communication system according to a third embodiment to which the present invention is applied will be described. In addition, about the same part as embodiment mentioned above, the detailed description is abbreviate | omitted by attaching | subjecting the same code | symbol and the same step number.

  In the communication system according to the third embodiment, when performing encrypted communication in conformity with SSL (Secure Socket Layer) between a server and a client, an encrypted communication decryption device is used to transmit an encrypted packet as in the above-described embodiment. And intercepting the received packet with a network monitoring device. Unlike the above-described IPsec, the encryption communication by SSL does not use the Diffie-Hellman key sharing method, so it is not necessary to directly connect the encryption / decryption device on the communication path between the server and the client, as shown in FIG. Configured as follows.

  In this communication system, a hub 43 is provided in a communication path connecting the SSL client 41 and the SSL server 42, and the encryption communication decryption device 44 and the network monitoring device 4 '' are connected to branch from the hub 43. .

  The SSL client 41 performs processing according to the SSL Handshake Protocol (SSLHP) with the SSL server 42 via the network N and the hub 43 when performing cryptographic communication with the SSL server 42. To establish a SSL protocol connection. At this time, the SSL client 41 first confirms the validity of the SSL server 42 by evaluating the certificate received from the SSL server 42. Thereby, the SSL client 41 performs partner authentication. Thereafter, a key block (common key) and an encryption algorithm are determined between the SSL client 41 and the SSL server 42 by negotiation using a handshake protocol, and an SSL packet obtained by encrypting the data portion (record unit) with the key block is determined. Perform the encrypted communication used.

  Note that the connection in the SSL protocol refers to a TCP connection between the SSL client 41 and the SSL server 42, that is, information identified by a pair of a transmission source and a destination port. A session in the SSL protocol is information identified by a session ID between the SSL client 41 and the SSL server 42. The connection is associated with the session by a session ID transmitted / received by the handshake protocol.

  In the SSL protocol, data is transmitted and received in units of records by performing processing according to an SSL record layer (SSLRL) corresponding to a lower layer of the SSL handshake protocol. The records are transmitted and received after being adjusted by being divided or combined into packets by the TCP / IP layer.

  The hub 43 functions as a relay device that relays an SSL packet communicated between the SSL client 41 and the SSL server 42, and also transmits the SSL packet to the encryption communication decryption device 44. As a result, the hub 43 causes the encryption communication decryption device 44 to intercept the SSL packet to be relayed.

  The encryption communication decryption device 44 can decrypt the SSL packet received from the hub 43 using the server private key stored in the SSL server 42 and process the decrypted packet with the network monitoring device 4 ″. The data is formatted and output to the network monitoring device 4 ″. Specifically, the encryption communication decryption device 44 sets the destination of the Ethernet header of the packet obtained by decrypting the SSL packet as the network monitoring device 4 ″, and sets the destination port or transmission source port of the TCP header as HTTP (HyperText Transfer Protocol). It is shaped into a TCP / IP packet set to the number “80” shown.

  When the network monitoring device 4 ″ receives the TCP / IP packet transmitted from the encryption / decryption device 44, the network monitoring device 4 ″ analyzes the content of the TCP / IP packet and determines whether the content of the TCP / IP packet is appropriate. Determine if it is appropriate. For example, when the network monitoring device 4 ″ detects that the TCP / IP packet includes an Internet worm, the network monitoring device 4 ″ determines that the content of the TCP / IP packet is inappropriate and notifies the administrator or the like. Notice.

[Configuration of encryption / decryption device]
In the communication system described above, the encryption / decryption device 44 is configured as shown in FIG.

  The communication interface 51 for reception is connected to the hub 43 and receives an SSL packet between the SSL client 41 and the SSL server 42 via the hub 43. Then, the communication interface 51 outputs the SSL packet to the filter unit 52.

  The filter unit 52 receives the SSL packet input from the communication interface 51, and the filtering condition of the SSL packet is supplied by the filter setting unit 53. The filter setting unit 53 is a user interface that sets filtering conditions for the encryption communication decryption device 44 to process as an SSL packet. Specifically, the IP address of the SSL server 42 and the SSL port number of the SSL server 42 are set as filtering conditions. When receiving the SSL packet, the filter unit 52 performs filtering in accordance with the filtering condition set by the filter setting unit 53, and outputs a packet that matches the filtering condition to the record reconstruction unit 54 as an SSL packet. Specifically, the IP address of the packet input from the communication interface 51 is compared with the IP address of the SSL server 42 set as the filtering condition, and further set as the port number of the packet input from the communication interface 51 and the filtering condition. The port number of the SSL server 42 is compared. If the filter unit 52 determines that either is different, the filter unit 52 discards the packet. If the filter unit 52 determines that both are the same, the filter unit 52 determines that the packet is an SSL packet and outputs the SSL packet to the record reconstruction unit 54. .

  The record reconstruction unit 54 reconstructs the data part of the SSL packet into record data in units of records and outputs the record data to the record decoding unit 56. The record information holding unit 55 is a buffer used when the record reconstruction unit 54 reconstructs a record.

  Here, when the data is transmitted according to the SSL protocol, the SSL client 41 and the SSL server 42 divide the data into a structure (record data) called a record in the SSL record layer and pass it to the TCP / IP layer processing. In the TCP / IP layer processing, the input record is further divided into packets in accordance with the MTU value representing the maximum size of the IP datagram, and the data length is adjusted and transmitted.

  When the encryption state held in the connection information holding unit 60 is valid, the record decryption unit 56 stores the record data input from the record reconstruction unit 54 in the cipher suite held in the connection information holding unit 60. The decryption process using the encryption key of the key block is performed according to the encryption algorithm, the decrypted record data is output to the record analysis unit 57, and the encryption state held in the connection information holding unit 60 is invalid In this case, the record data input from the record reconstruction unit 54 is output to the record analysis unit 57 as it is.

  The record analysis unit 57 analyzes the record data output from the record decoding unit 56, and indicates that the message type of the record includes a handshake message generated by a handshake protocol, or It is analyzed whether the message type indicates that the encryption parameter switching (change_cipher_spec) message generated by the encryption parameter switching (change_cipher_spec) protocol is included. When the record data is a message type generated by the handshake protocol or the encryption parameter switching protocol, the record data is output to the handshake analysis unit 58. On the other hand, if the record type is application data (application_data) instead of a message based on the handshake protocol or the encryption parameter switching protocol, the record data is output to the packet shaping unit 63.

  The handshake analysis unit 58 analyzes the record data output from the record analysis unit 57 and outputs the analysis result to the session information holding unit 59 and the connection information holding unit 60. At this time, if the message type of the record data is handshake and the message type of the handshake is client_key_exchange, the handshake analysis unit 58 causes the public key encryption processing unit 61 to decrypt the record data.

  The public key encryption processing unit 61 decrypts the data input from the handshake analysis unit 58 using the secret key set by the secret key setting unit 62 and outputs the decrypted data to the handshake analysis unit 58. The secret key setting unit 62 is a user interface for setting the secret key of the SSL server 42.

  The session information holding unit 59 holds information for identifying an SSL session and an encryption key (master secret key). The session information holding unit 59 specifically holds the IP addresses of the SSL client 41 and the SSL server 42 and the SSL session ID as information for identifying a session.

  The connection information holding unit 60 holds information for identifying a connection of the SSL protocol, a cipher suite, an encryption state, and a key block. The connection information holding unit 60 specifically holds the IP addresses and port numbers of the SSL client 41 and the SSL server 42 as information for identifying an SSL connection. Further, the connection information holding unit 60 holds the encryption state in each direction from the SSL client 41 to the SSL server 42 and from the SSL server 42 to the SSL client 41 as the encryption state. Further, the connection information holding unit 60 holds a message authentication key, an encryption key, and an initial vector for each direction from the SSL client 41 to the SSL server 42 and from the SSL server 42 to the SSL client 41 as key blocks.

  The packet shaping unit 63 shapes the application data decoded by the record decoding unit 56 and output from the record analysis unit 57 into a data format that can be analyzed by the network monitoring device 4 ″, and outputs the data to the communication interface 64. . Specifically, as shown in FIG. 15, when the application data as a result of decrypting the SSL data is obtained, the packet shaping unit 63 adjusts the data length by dividing the application data of the record unit into the packet unit. . Then, a header in which the TCP destination or transmission source port is set to “80”, an IP header, an Ethernet header, etc. is added to the packet unit data, and the destination of the Ethernet (registered trademark) header is set. It is shaped into a TCP / IP packet with the network monitoring device 4 ″.

  The communication interface 64 outputs the TCP / IP packet input from the packet shaping unit 63 to the network monitoring device 4 ''.

[Operation of encryption / decryption device]
Next, the operation of the encryption / decryption device 44 configured as described above will be described with reference to FIGS.

  This network monitoring device 4 ″ performs processing as shown in FIG. 16 to reconstruct a record mainly from IP packets transmitted and received between the SSL client 41 and the SSL server 42. The process of reconstructing this record is started by receiving a TCP / IP packet transmitted / received between the SSL client 41 and the SSL server 42 by the network monitoring device 4 ″.

  First, when the encryption / decryption device 44 receives a TCP / IP packet transmitted / received between the SSL client 41 and the SSL server 42 via the communication interface 51 (step ST71), the filter unit 52 causes the TCP / IP packet to be transmitted. Then, it is determined whether or not the SSL packet is encrypted according to the SSL protocol (step ST72).

  If the filter unit 52 determines that the received TCP / IP packet is an SSL packet, the process proceeds to step ST73. If it is determined that the received packet is not an SSL packet, the process ends. At this time, the filter unit 52 adds a TCP header as an upper layer header of the IP header, and the destination or source IP address and port number are the same as those set by the filter setting unit 53 Are determined to be SSL packets, and if they are not identical, it is determined that they are not SSL packets.

  In step ST73, the record reconstruction unit 54 refers to the header length field of the IP header, the packet length field, and the data offset field of the TCP header to obtain the packet length, the IP header length, and the TCP header length, and from the packet length From the value obtained by subtracting the IP header length and the TCP header length, it is determined whether or not the TCP / IP packet includes data. If the record reconstruction unit 54 determines that the data is included, the process proceeds to step ST74. If the record reconstruction unit 54 determines that the data is not included, the process proceeds to step ST78.

  In step ST74, the record reconstruction unit 54 determines whether the data determined to be included in step ST73 is data in the reverse direction to the data in the connection accumulated in the record information holding unit 55 in the previous process. Determine whether. That is, when the data accumulated in the process of FIG. 16 performed last time is data transmitted from the SSL client 41 to the SSL server 42, the data determined to be included in step ST73 is SSL. It is determined whether the data is transmitted from the server 42 to the SSL client 41. On the other hand, if the data accumulated in the previous processing of FIG. 16 is data transmitted from the SSL server 42 to the SSL client 41, the data determined to be included in step ST73 It is determined whether the data is transmitted from the SSL client 41 to the SSL server 42. If the record reconstruction unit 54 determines that the transmission / reception direction of the previously accumulated data is opposite to the transmission / reception direction of the data received this time, the process proceeds to step ST75 and the reverse direction is not established. If it is determined, the process proceeds to step ST77. If connection data is not stored in the record information holding unit 55, the record reconstructing unit 54 determines that the direction is not the reverse direction, and proceeds to step ST77.

  In step ST77, the record reconstruction unit 54 stores the data in the record information holding unit 55 so that the data can be used in the subsequent processing. At this time, the record reconstruction unit 54 associates the data itself with the sequence number field of the TCP header indicating the position of the transmitted / received data, copies the data to an appropriate location, and stores it in the record information holding unit 55.

  In the next step ST78, the record reconstruction unit 54 refers to the FIN flag in the TCP header and determines whether or not the connection is terminated by the current data transmission. If the record reconstruction unit 54 determines that the process is to be terminated, the process proceeds to step ST79. If it is determined that the record reconstruction unit 54 has not terminated, the process is terminated.

  In step ST79, the record reconstruction unit 54 determines whether or not the data of the connection is stored in the record information holding unit 55. If it is determined that it has been accumulated, the process proceeds to step ST80, and if it is determined that it has not been accumulated, the process ends.

  In step ST80, the record reconstruction unit 54 divides the connection data stored in the record information holding unit 55 into record data by referring to the record header. Then, the record reconstruction unit 54 outputs each record data to the record decoding unit 56, performs the record process, and ends the process. Details of this record processing will be described later with reference to FIG.

  On the other hand, in step ST74, the same process as step ST80 is performed in step ST75 after it is determined that the data included in the SSL packet received in step ST71 is data in the opposite direction to the previous time. In step ST76, data is stored in the record information holding unit 55 as in step ST77.

  The record is reconstructed from the TCP / IP packet transmitted / received between the SSL client 41 and the SSL server 42 by the above procedure. For the sake of simplicity, the description of the procedure for reconstructing the records is omitted.

  Next, the record processing performed in the above-described step ST80 or step ST75 will be described with reference to FIG.

  This record processing is started after the record reconstruction unit 54 reconstructs the record. This record processing is executed when an SSL packet is transmitted and received between the SSL client 41 and the SSL server 42 as shown in FIG. In the processing shown in FIG. 18, the SSL client 41 and the SSL server 42 first negotiate the encryption algorithm and generate a key block by the handshake protocol, and generate the key block according to the determined encryption algorithm. Thus, encryption communication is performed by encrypting upper layer data. Note that the handshake process shown in FIG. 18 performs the following first process, second process, third process, and fourth process, and thereafter enables application data processing.

"First process"
First, in the first process of the handshake process, the SSL client 41 transmits a Client Hello message S21 that is a message first transmitted to the SSL server 42 to the SSL server 42 in accordance with the handshake protocol. The Client Hello message S21 includes a client random number, a session ID, a cipher suite list, and the like. The cipher suite is a public key encryption algorithm used for key exchange between the SSL client 41 and the SSL server 42, an encryption algorithm used for encryption communication of application data, a key length used for the encryption algorithm, a message A value representing a combination of hash algorithms for generating an authentication code.

  On the other hand, when the Client Hello message S21 is intercepted by the encryption communication decryption device 44 via the hub 43, the record including the Client Hello message S21 is input to the record decryption unit 56 of the encryption communication decryption device 44, Start record processing.

  In step ST91 shown in FIG. 17, this record processing refers to the encryption state from the SSL client 41 to the SSL server 42 held in the connection information holding unit 60 by the record decrypting unit 56, and is not yet effective. The process proceeds to ST93.

  In step ST93, the record analysis unit 57 determines whether or not the message type of the received record data indicates a handshake protocol, and is the Client Hello message S21 generated by the handshake protocol. It outputs to the handshake analysis part 58, and advances a process to step ST94.

  In step ST94, the handshake analysis unit 58 determines whether or not the message type of the record data input in step ST93 indicates a Client Key Exchange message, and the received message is not a Client Key Exchange message. Therefore, the process proceeds to step ST95.

  In step ST95, the handshake analysis unit 58 determines whether or not the message type of the received record data indicates a Server Hello message. Since the received message is not a Server Hello message, the process proceeds to step ST96. To proceed.

  In step ST96, the handshake analysis unit 58 determines whether or not the message type of the received record data indicates a Client Hello message. Since the Client Hello message S21 is received, the process proceeds to step ST97. To proceed.

  In step ST97, the client random number generated by the SSL client 41 is acquired from the record received together with the received Client Hello message S21 by the handshake analysis unit 58 and stored in the connection information holding unit 60. Thereafter, in step ST107, the encryption / decryption device 44 deletes the accumulated data stored in the record information holding unit 55 used in the determination in step ST74, and ends the process.

"Second process"
In the next second process, when the SSL server 42 receives the Client Hello message S21 from the SSL client 41, the SSL server 42 transmits a Certificate message S23 to the SSL client 41 following the Server Hello message S22 of the handshake protocol. This Server Hello message S22 is a response message to the Client Hello message S21, and includes a server random number generated by the SSL server 42, a session ID, and a cipher suite used in subsequent processing. The Certificate message S23 is a message for handing over a certificate owned by itself to the SSL client 41, and includes the certificate of the SSL server 42.

  On the other hand, when a record including the Server Hello message S22 is input to the record decrypting unit 56, the encryption / decryption device 44 starts record processing.

  First, in step ST91, this record processing refers to the encryption state from the SSL server 42 to the SSL client 41 held in the connection information holding unit 60 by the record decrypting unit 56, and is not yet effective. To proceed.

  In step ST93, the record analysis unit 57 determines whether or not the record is a handshake protocol. Since the record is a handshake protocol, the record is output to the handshake analysis unit 58, and the process proceeds to step ST94.

  In step ST94, the handshake analysis unit 58 determines whether or not the message type of the received record data indicates a Client Key Exchange message. Since the received message is not a Client Key Exchange message, step ST95 Proceed with the process.

  In step ST95, the handshake analysis unit 58 determines whether or not the message type of the received record data is a Server Hello message. Since the received message is the Server Hello message S22, the process proceeds to step ST98. .

  In step ST98, the handshake analysis unit 58 acquires the server random number, session ID, and cipher suite from the record data received together with the Server Hello message S22, and stores the server random number and cipher suite in the connection information holding unit 60. The session ID is stored in the session information holding unit 59. At this time, the handshake analysis unit 58 assumes that the server random number and cipher suite stored in the connection information holding unit 60 and the session ID stored in the session information holding unit 59 are assumed to have been added to the same Server Hello message S22. In order to associate them with each other, the stored connection information and session information are linked and stored.

  In step ST99, it is determined whether or not a master secret that is a common secret key exists in session information holding unit 59. Since there is no master secret, the process proceeds to step ST107. Thereafter, in step ST107, the encryption / decryption device 44 deletes the accumulated data stored in the record information holding unit 55 used in the determination in step ST74, and ends the process.

  Further, when the record data including the Certificate message S23 is input to the record decryption unit 56 following the Server Hello message S22, the encryption communication decryption apparatus 44 starts the record processing again.

  First, in step ST91, this record processing refers to the encryption state from the SSL server 42 to the SSL client 41 held in the connection information holding unit 60 by the record decrypting unit 56, and is not yet valid. To proceed.

  In step ST93, the record analysis unit 57 determines whether or not the received record data is a handshake protocol. Since the record data is a handshake protocol, the record data is output to the handshake analysis unit 58, and the process proceeds to step ST94.

  In step ST94, the handshake analysis unit 58 determines whether or not the message type of the received record data indicates a Client Key Exchange message. Since the received message is not a Client Key Exchange message, the process proceeds to step ST95. To proceed.

  In step ST95, the handshake analysis unit 58 determines whether or not the message type of the received record data indicates a Server Hello message. Since the received message is not a Server Hello message, the process proceeds to step ST96. To proceed.

  In step ST96, the handshake analyzer 58 determines whether the message type of the received record data is a Client Hello message. Since the received message is not a Client Hello message, the process proceeds to step ST107. Thereafter, in step ST107, the encryption / decryption device 44 deletes the accumulated data stored in the record information holding unit 55 used in the determination in step ST74, and ends the process.

  On the other hand, when the SSL client 41 receives the Server Hello message S22 and the Certificate message S23 from the SSL server 42, the SSL client 41 evaluates the certificate included in the Certificate message, and if it is valid, the random number pre-master secret And a master secret that is a common secret key is generated from the random number pre-master secret, the client random number, and the server random number acquired from the Server Hello message S22. Next, the SSL client 41 generates a key block from the master secret, the client random number, and the server random number.

"Third process"
Next, the SSL client 41 transmits to the SSL server 42 a client key exchange message S24 of a handshake protocol, a change cipher spec message S25 of a cipher parameter change (Change Cipher Spec) protocol, and a finished message S26 of a handshake protocol. .

  The Client Key Exchange message S24 is a message indicating that the random number generated by the SSL client 41 is encrypted with the public key of the SSL server 42 and transmitted to the SSL server 42. The random number pre-master secret is received from the SSL server 42. It includes data encrypted with the public key of the SSL server 42 included in the certificate of the SSL server 42 included in the Certificate message. With this data, the SSL server 42 can generate a master secret. The Change Cipher Spec message S25 is a message notifying that the use of the encryption specification determined by the handshake protocol is started and does not include data. The Finished message S26 of the handshake protocol is a message that notifies the end of the handshake protocol, and includes a value obtained by calculating a handshake message, a master secret, or the like with a hash function.

  The SSL client 41 encrypts a connection record to be transmitted after the Change Cipher Spec message S25 including the Finished message S26 with an encryption key from the SSL client 41 to the SSL server 42 in the key block using an encryption algorithm of the cipher suite. To send a message.

  When the record including the Client Key Exchange message S24 is input to the record decryption unit 56, the encryption communication decryption device 44 starts record processing.

  In step ST91, the encryption state from the SSL client 41 to the SSL server 42 held in the connection information holding unit 60 is referred to by the record decrypting unit 56, and since it is not yet valid, the process proceeds to step ST93.

  In step ST93, the record analysis unit 57 determines whether or not the received record data is a handshake protocol, and since the message generated by the handshake protocol is received, the record data is sent to the handshake analysis unit 58. Is output, and the process proceeds to step ST94.

  In step ST94, the handshake analysis unit 58 determines whether or not the message type of the received record data is the Client Key Exchange message S24. Since the message type is the Client Key Exchange message S24, the process proceeds to step ST100.

  In step ST100, the handshake analysis unit 58 calculates the master secret of the session and stores it in the session information holding unit 59. Specifically, the public key encryption processing unit 61 decrypts the data of the Client Key Exchange message S24 with the server secret key set in advance by the secret key setting unit 62, acquires the random number pre-master secret, The shake analysis unit 58 generates a master secret from the random number pre-master secret, the client random number held in the connection information holding unit 60, and the server random number.

  In step ST101, the handshake analysis unit 58 generates a connection key block. Specifically, a key block is generated from the master secret held in the session information holding unit 59 and the client random number and server random number held in the connection information holding unit 60. Thereafter, in step ST107, the encryption / decryption device 44 deletes the accumulated data stored in the record information holding unit 55 used in the determination in step ST74, and ends the process.

  Further, when a record including the Change Cipher Spec message S25 generated by the encryption parameter switching protocol is input to the record decryption unit 56, the encryption communication decryption apparatus 44 starts record processing again.

  First, in step ST91, the encryption state from the SSL client 41 to the SSL server 42 held in the connection information holding unit 60 is referred to by the record decrypting unit 56, and since it is not yet valid, the process proceeds to step ST93.

  In step ST93, the record analysis unit 57 determines whether or not the received record data is a handshake protocol. Since a message generated by the handshake protocol has not been received, the process proceeds to step ST102.

  In step ST102, the record analysis unit 57 determines whether or not the message type of the received record data is the Change Cipher Spec protocol. Since the Change Cipher Spec message S25 is received, the process proceeds to step ST103.

  In step ST103, the handshake analysis unit 58 effectively changes the encryption state from the SSL client 41 to the SSL server 42 of the connection information holding unit 60. Thereafter, in step ST107, the encryption / decryption device 44 deletes the accumulated data stored in the record information holding unit 55 used in the determination in step ST74, and ends the process.

  Next, when the record data including the Finished message S26 is input to the record decryption unit 56, the encryption communication decryption device 44 starts record processing again.

  First, in step ST91, the record decryption unit 56 refers to the encryption state from the SSL client 41 held in the connection information holding unit 60 to the SSL server 42, and the record processing performed when the previous Change Cipher Spec message S25 is received. In step ST92, the process proceeds to step ST92.

  In step ST92, the record decryption unit 56 decrypts the record data with the encryption algorithm of the cipher suite held in the connection information holding unit 60 and the encryption key from the SSL client 41 to the SSL server 42 of the key block, The data is output to the analysis unit 57.

  In step ST93, the record analysis unit 57 determines whether or not the received record data is a message generated by the handshake protocol, and receives the Finished message S26 generated by the handshake protocol. The record data is output to the analysis unit 58, and the process proceeds to step ST94.

  In step ST94, the handshake analysis unit 58 determines whether or not the message type of the received record data is a Client Key Exchange message. Since the received message is not a Client Key Exchange message, the process proceeds to step ST95. Proceed.

  In step ST95, the handshake analyzer 58 determines whether the message type of the received record data is a Server Hello message. Since the received message is not a Server Hello message, the process proceeds to step ST96.

  In step ST96, the handshake analysis unit 58 determines whether the message type of the received record data is a Client Hello message. Since the received message is not a Client Hello message, the process ends. Thereafter, in step ST107, the encryption / decryption device 44 deletes the accumulated data stored in the record information holding unit 55 used in the determination in step ST74, and ends the process.

  On the other hand, when receiving the Client Key Exchange message S24 transmitted from the SSL client 41, the SSL server 42 decrypts the data including the Client Key Exchange message S24 with the server secret key to obtain a random number pre-master secret, The master secret is calculated from the random number pre-master secret, the client random number, and the transmitted server random number. Next, the SSL server 42 generates a key block from the calculated master secret, the client random number, and the server random number.

  Next, when the SSL server 42 receives the Change Cipher Spec message S25, the encryption key of the key block from the SSL client 41 to the SSL server 42 is converted into the record data of the connection received after that by the encryption algorithm of the cipher suite. It recognizes that it decrypts with.

  Next, when the SSL server 42 receives the Finished message S26, the SSL server 42 decrypts the record including the Finished message S26, compares the data with a value generated in the same manner as the SSL client 41, and has no falsification or impersonation. Confirm.

"4th process"
Next, the SSL server 42 transmits a Change Cipher Spec message S27 of the Change Cipher Spec protocol and a Finished message S28 of the handshake protocol to the SSL client 41. The Change Cipher Spec message S27 transmitted from the SSL server 42 to the SSL client 41 is a response to the Change Cipher Spec message S25 transmitted from the SSL client 41 and does not include data. The Finished message S28 of the handshake protocol includes a value obtained by calculating a handshake message, a master secret, or the like with a hash function. The message after the Change Cipher Spec message S27 is encrypted with the encryption key from the SSL server 42 to the SSL client 41 of the key block by the encryption algorithm of the cipher suite.

  On the other hand, when receiving the Change Cipher Spec message S27, the cryptographic communication decryption apparatus 44 causes the record decryption unit 56 to input record data including the Change Cipher Spec message S27 and starts record processing.

  First, in step ST91, the record decrypting unit 56 refers to the encryption state from the SSL server 42 to the SSL client 41 held in the connection information holding unit 60, and is not yet valid. Proceed.

  In step ST93, the record analysis unit 57 determines whether or not the received record data is a handshake protocol. Since the message is not a message generated by the handshake protocol, the process proceeds to step ST102.

  In step ST102, the record analysis unit 57 determines whether or not the message type of the received record data is the Change Cipher Spec protocol, and since the Change Cipher Spec S27 is received, the process proceeds to step ST103.

  In step ST103, the handshake analysis unit 58 enables the encryption state from the SSL server 42 to the SSL client 41 of the connection information holding unit 60. Thereafter, in step ST107, the cryptographic communication decryption apparatus 44 deletes the accumulated data stored in the record information holding unit 55 used in the determination in step ST74, and ends the process.

  Further, when a record including the Finished message S28 is input to the record decryption unit 56, the encryption communication decryption device 44 starts record processing again.

  First, in step ST91, the record decrypting unit 56 refers to the encryption state from the SSL server 42 to the SSL client 41 held in the connection information holding unit 60, and is set to be valid in the previous record processing. The process proceeds to ST92.

  In step ST92, the record decryption unit 56 decrypts the record data with the encryption algorithm of the cipher suite held in the connection information holding unit 60 and the encryption key from the SSL server 42 to the SSL client 41 of the key block, The data is output to the analysis unit 57.

  In step ST93, the record analysis unit 57 determines whether or not the received record data is a handshake protocol. Since the Finished message S28 is a message generated by the handshake protocol, the record data is sent to the handshake analysis unit 58. Is output, and the process proceeds to step ST94.

  In step ST94, the handshake analysis unit 58 determines whether or not the message type of the received record data is a Client Key Exchange message. Since the received message is not a Client Key Exchange message, the process proceeds to step ST95. Proceed.

  In step ST95, the handshake analyzer 58 determines whether the message type of the received record data is a Server Hello message. Since the received message is not a Server Hello message, the process proceeds to step ST96.

  In step ST96, the handshake analysis unit 58 determines whether or not the message type of the received record data is a Client Hello message. Since the received message is not a Client Hello message, the process ends. Thereafter, in step ST107, the encryption / decryption device 44 deletes the accumulated data stored in the record information holding unit 55 used in the determination in step ST74, and ends the process.

  On the other hand, when the SSL client 41 receives the Change Cipher Spec message S27, the SSL client 41 uses the encryption key from the SSL server 42 to the SSL client 41 of the key block to transmit the record of the connection received after that to the encryption block encryption algorithm. Decrypt.

  Next, when receiving the Finished message S28, the SSL client 41 decrypts the record and compares the data with a value generated in the same manner as the SSL server 42 to confirm that there is no falsification or impersonation.

  Thereby, the handshake protocol between the SSL client 41 and the SSL server 42 is completed. At this time, the SSL client 41, the SSL server 42, and the encryption communication decryption device 44 are in the same encryption key state, that is, the same encryption key is generated and the encryption process is performed with the same data length. .

Application data processing
When the handshake process is completed as described above, application data can be transmitted and received between the SSL client 41 and the SSL server 42. That is, when the application data is transmitted to the SSL server 42, the SSL client 41 divides the application data into records, and encrypts the application data by using the encryption key from the SSL client 41 to the SSL server 42 in the key block. (Application Data) Send with protocol.

  On the other hand, when the record generated by the application data protocol in SSL is input, the encryption communication decryption device 44 starts the record processing.

  In step ST91 of this record processing, the record decrypting unit 56 refers to the encryption state from the SSL client 41 to the SSL server 42 held in the connection information holding unit 60, and is set to be valid in the above-described handshake processing. Therefore, the process proceeds to step ST92.

  In step ST92, the record decryption unit 56 decrypts the record with the encryption algorithm of the cipher suite held in the connection information holding unit 60 and the encryption key from the SSL client 41 to the SSL server 42 of the key block, and the record analysis To the unit 57.

  In step ST93, the record analysis unit 57 determines whether or not the received record data is a handshake protocol. Since the record data is not a record generated by the handshake protocol, the process proceeds to step ST102.

  In step ST102, the record analysis unit 57 determines whether the message type of the received record data is a Change Cipher Spec message. Since the received record is not a Change Cipher Spec message, the process proceeds to step ST104. .

  In step ST104, the record analysis unit 57 determines whether the message type of the received record data is the Application Data protocol, and since the record generated by the Application Data protocol is received, the received record Data is output to the packet shaping unit 63, and the process proceeds to step ST105.

  In step ST105, the packet shaping unit 63 shapes the decrypted portion of the received record data into an HTTP packet, which is output from the communication interface 64 to the network monitoring device 4 ''. At this time, as shown in FIG. 15, the packet shaping unit 63 adds the IP header and TCP header of the IP packet received in step ST71 to the beginning of the decoded part of the received record data, and the destination port of the TCP header Is set to the port number indicating HTTP, and the sequence number field, ACK number field, checksum field, IP header length field, and checksum field of the TCP header are recalculated. Thereby, the record is shaped into an HTTP packet. In addition, when the network monitoring device 4 ″ is compatible with the LAN, the packet shaping unit 63 sets the destination of the Ethernet header to the address of the network monitoring device 4 ″.

  In the next step ST106, the HTTP packet shaped by the packet shaping unit 63 is transmitted to the network monitoring apparatus 4 '' by the communication interface 64. Thereafter, in step ST107, the encryption / decryption device 44 deletes the accumulated data stored in the record information holding unit 55 used in the determination in step ST74, and ends the process.

  As a result, the network monitoring device 4 ″ analyzes the HTTP packet, and can notify the administrator if the content of the HTTP packet is inappropriate.

  When the SSL server 42 transmits application data to the SSL client 41, the encryption communication decryption device 44 starts record processing when a record generated by the application data protocol is input to the record decryption unit 56. .

  First, in step ST91, the record decrypting unit 56 refers to the encryption state from the SSL server 42 to the SSL client 41 held in the connection information holding unit 60, and since it is set to be valid, the process proceeds to step ST92. .

  In step ST92, the record decryption unit 56 decrypts the record with the encryption algorithm of the cipher suite held in the connection information holding unit 60 and the encryption key from the SSL server 42 to the SSL client 41 of the key block, and the record analysis To the unit 57.

  In step ST93, the record analysis unit 57 determines whether or not the received record data is a handshake protocol. Since the message is not a message generated by the handshake protocol, the process proceeds to step ST102.

  In step ST102, the record analysis unit 57 determines whether or not the message type of the received record data is the Change Cipher Spec protocol. Since the received message is not a message generated by the Change Cipher Spec protocol, the step ST104 Proceed with the process.

  In step ST104, the record analysis unit 57 determines whether the message type of the received record data is application data, and has received application data created by the application data protocol. Data is output to the packet shaping unit 63, and the process proceeds to step ST105.

  In step ST105, the packet shaping unit 63 performs the same process as the process in step ST105 described above, thereby shaping the received record data as an HTTP packet. In step ST106, the HTTP packet is transmitted from the communication interface 64 to the network monitoring device 4 ''. Thereafter, in step ST107, the encryption / decryption device 44 deletes the accumulated data stored in the record information holding unit 55 used in the determination in step ST74, and ends the process.

  As a result, the network monitoring device 4 ″ analyzes the HTTP packet, and can notify the administrator if the content of the HTTP packet is inappropriate.

  As described above, the encryption communication decryption device 44 decrypts the encrypted SSL packet transmitted / received between the SSL client 41 and the SSL server 42 and shapes the SSL packet as an HTTP packet. 4 ″, enabling monitoring by the network monitoring device 4 ″.

"Restarting a Session"
In the SSL protocol, an existing session can be used at the time of establishing a connection, and the session can be restarted by reusing a master secret generated at the time of establishing a previous connection. Next, the restart of the session in the SSL will be described with reference to FIG. 19, and the operation of the encryption / decryption device 44 when the session is restarted will be described.

  First, in the session restart process, the Client Hello message S21 is transmitted from the SSL client 41 to the SSL server 42 as in the first process in the SSL protocol described above, and the encryption communication decryption apparatus 44 performs the same process as the first process. Is executed. Thereafter, in the session restart process, the Server Hello message S22, the Change Cipher Spec message S31, and the Finished message S32 are transmitted from the SSL server 42 to the SSL client 41, and the second process by the encryption communication decryption apparatus 44 is started.

"Second process"
When the SSL server 42 receives the Client Hello message S21 from the SSL client 41, the SSL client 41 sends a handshake protocol Server Hello message S22, a Change Cipher Spec protocol Change Cipher Spec message S31, and a handshake protocol Finished message S32 to the SSL client 41. Send.

  Further, the SSL server 42 generates a key block from the master secret generated at the time of establishing the previous connection, the client random number received from the SSL client 41, and the server random number transmitted to the SSL client 41.

  On the other hand, when a record including the Server Hello message S22 is input to the record decrypting unit 56, the encryption / decryption device 44 starts record processing.

  First, in step ST91, this record processing refers to the encryption state from the SSL server 42 to the SSL client 41 held in the connection information holding unit 60 by the record decrypting unit 56, and is not yet effective. To proceed.

  In step ST93, the record analysis unit 57 determines whether or not the received record is a handshake protocol. Since the record is a handshake protocol, the record is output to the handshake analysis unit 58, and the process proceeds to step ST94.

  In step ST94, the handshake analysis unit 58 determines whether or not the message type of the received record data indicates a Client Key Exchange message. Since the received message is not a Client Key Exchange message, step ST95 Proceed with the process.

  In step ST95, the handshake analysis unit 58 determines whether or not the message type of the received record data is a Server Hello message. Since the received message is the Server Hello message S22, the process proceeds to step ST98. .

  In step ST98, the handshake analysis unit 58 acquires the server random number, session ID, and cipher suite from the received record data, stores the server random number and cipher suite in the connection information holding unit 60, and holds the session ID as session information. This is stored in the unit 59. At this time, the handshake analysis unit 58 links and stores the stored connection information and session information in order to associate them with those added to the same message.

  In step ST99, it is determined whether or not a master secret that is a common secret key exists in session information holding unit 59, and since it exists, the process proceeds to step ST101.

  In step ST101, the handshake analysis unit 58 generates a key block in the connection. Specifically, a key block is generated from the master secret held in the session information holding unit 59 and the client random number and server random number held in the connection information holding unit 60.

  Then, when receiving the Change Cipher Spec message S31 and the Finished message S32, the cryptographic communication decryption apparatus 44 performs the same process as when the Change Cipher Spec message S27 and the Server Hello message S28 are received in the fourth process described above.

  On the other hand, when the SSL client 41 receives the Server Hello message S22 from the SSL server 42, the SSL client 41 generates a key block from the master secret generated during the previous connection establishment, the client random number, and the server random number.

  Further, when the SSL client 41 receives the Change Cipher Spec message S31, the connection processing record received after that is sent with the encryption key from the SSL server 42 to the SSL client 41 of the key block by the encryption algorithm of the cipher suite. Decrypt.

  Furthermore, when the SSL client 41 receives the Finished message S32, the SSL client 41 decrypts the record and compares the data with a value generated in the same manner as the SSL server 42 to confirm that there is no falsification or impersonation.

"Third process"
Next, the SSL client 41 transmits, to the SSL server 42, a Change Cipher Spec message S33 of the Change Cipher Spec protocol and a Finished message S34 of the handshake protocol.

  On the other hand, when a record including the Change Cipher Spec message S33 is input to the record decrypting unit 56, the encryption / decryption device 44 starts record processing again.

  First, in step ST91, this record processing refers to the encryption state from the SSL client 41 to the SSL server 42 held in the connection information holding unit 60 by the record decrypting unit 56, and is not yet valid. To proceed.

  In step ST93, the record analysis unit 57 determines whether or not the received record data is a handshake protocol. Since the record data is not a handshake protocol, the process proceeds to step ST102.

  In step ST102, the record analysis unit 57 determines whether or not the message type of the received record data is the Change Cipher Spec protocol, and since the Change Cipher Spec message S33 is received, the process proceeds to step ST103.

  In step ST103, the handshake analysis unit 58 validates the encryption state from the SSL client 41 to the SSL server 42 of the connection information holding unit 60.

  In addition, when a record including the Finished message S34 is input to the record decryption unit 56, the encrypted communication decryption device 44 starts record processing again.

  In step ST91, the record decrypting unit 56 refers to the encryption state from the SSL client 41 to the SSL server 42 held in the connection information holding unit 60, and since it is valid, the process proceeds to step ST92.

  In step ST92, the record decryption unit 56 decrypts the record with the encryption algorithm of the cipher suite held in the connection information holding unit 60 and the encryption key from the SSL client 41 to the SSL server 42 of the key block, and the record analysis To the unit 57.

  In step ST93, the record analysis unit 57 determines whether or not the received record data is a handshake protocol, and since this is a message generated by the handshake protocol, the record is output to the handshake analysis unit 58. The process proceeds to ST94.

  In step ST94, the handshake analysis unit 58 determines whether the message type of the received record data is a Client Key Exchange message. Since the received message is not a Client Key Exchange message, the process proceeds to step ST95. To proceed.

  In step ST95, the handshake analyzer 58 determines whether the message type of the received record data is a Server Hello message. Since the received message is not a Server Hello message, the process proceeds to step ST96.

  In step ST96, the handshake analysis unit 58 determines whether the message type of the received record data is a Client Hello message. Since the received message is not a Client Hello message, the process ends.

  On the other hand, when the SSL server 42 receives the Change Cipher Spec message S33, the SSL server 42 encrypts a record of connection processing received after that by the encryption algorithm of the cipher suite from the SSL client 41 to the SSL server 42. Decrypt with the encryption key.

  Next, when receiving the Finished message S34, the SSL server 42 decrypts the record, compares the data with a value generated in the same manner as the SSL client 41, and confirms that there is no falsification or impersonation. As a result, the session restart process ends, and the application process can be performed. Monitoring of the communication content by the SSL packet is also started by the encryption communication decryption device 44 and the network monitoring device 4 ″. Become.

[Effect of the third embodiment]
As described above in detail, according to the communication system to which the present invention is applied, the message transmitted and received by the handshake process between the SSL client 41 and the SSL server 42 is transmitted via the hub 43 to the encryption communication decryption device 44. The encryption communication decryption device 44 stores the encryption key of the SSL packet transmitted from the SSL client 41 to the SSL server 42 and the encryption key of the SSL packet transmitted from the SSL server 42 to the SSL client 41. be able to. Then, the encryption communication decryption device 44 can decrypt and format the SSL packet transmitted / received by the application process performed between the SSL client 41 and the SSL server 42 using both of the encryption keys. Therefore, according to this communication system, it is possible to monitor and control the communication content by the SSL packet by the existing network monitoring device 4 ″.

  The above-described embodiment is an example of the present invention. For this reason, the present invention is not limited to the above-described embodiment, and various modifications can be made depending on the design and the like as long as the technical idea according to the present invention is not deviated from this embodiment. Of course, it is possible to change.

It is a block diagram which shows the structure of the communication system in 1st Embodiment to which this invention is applied. It is a block diagram which shows the structure of the encryption communication decoding apparatus in 1st Embodiment to which this invention is applied. It is a flowchart which shows the whole process in 1st Embodiment to which this invention is applied. It is a flowchart which shows the process sequence of the IKE process performed with the encryption communication decoding apparatus of the communication system which concerns on 1st Embodiment to which this invention is applied. It is a flowchart which shows the process sequence of the ESP process performed with the encryption communication decoding apparatus of the communication system which concerns on 1st Embodiment to which this invention is applied. It is a flowchart of the message transmitted / received between an initiator, an encryption communication decoding apparatus, and a responder by the IKE process in the communication system which concerns on 1st Embodiment to which this invention is applied. In the first embodiment to which the present invention is applied, it is a schematic diagram for explaining the process of shaping a packet by the encryption communication decryption device, (a) when the received packet is created in the transport mode in ESP (B) is a diagram for explaining the processing when a received packet is created in the tunnel mode in ESP. It is a block diagram which shows the structure of the communication system in 2nd Embodiment to which this invention is applied. It is a block diagram which shows the structure of the encryption communication decoding apparatus in 2nd Embodiment to which this invention is applied. It is a flowchart which shows the whole process in 2nd Embodiment to which this invention is applied. It is a flowchart which shows the process sequence of the ESP process performed with the encryption communication decoding apparatus of the communication system which concerns on 2nd Embodiment to which this invention is applied. It is a flowchart which shows the process sequence of the plaintext process performed with the encryption communication decoding apparatus of the communication system which concerns on 2nd Embodiment to which this invention is applied. It is a block diagram which shows the structure of the communication system in 3rd Embodiment to which this invention is applied. It is a block diagram which shows the structure of the encryption communication decoding apparatus in 3rd Embodiment to which this invention is applied. In 3rd Embodiment to which this invention is applied, it is a schematic diagram for demonstrating the process which shapes a packet with an encryption communication decoding apparatus. It is a flowchart which shows the whole process in 3rd Embodiment to which this invention is applied. It is a flowchart which shows the process sequence of the record process performed with the encryption communication decoding apparatus in the communication system which concerns on 3rd Embodiment to which this invention is applied. It is a flowchart of the message transmitted / received between a SSL client and a SSL server by the handshake process in the communication system which concerns on 3rd Embodiment to which this invention is applied. It is a flowchart of the message transmitted / received between a SSL client and a SSL server by the restart process of the session in the communication system which concerns on 3rd Embodiment to which this invention is applied.

Explanation of symbols

1, 2 VPN terminal 3, 3 ′, 44 Encryption communication decryption device 4, 4 ′, 4 ″ Network monitoring device 11, 12, 13, 31, 51, 64 Communication interface 13 Session key output unit 14 Pre-shared key holding unit DESCRIPTION OF SYMBOLS 15 Packet decoding part 16 Packet reading part 17 Packet generation part 18 Session information holding part 19 Public key holding part 20 Key shared data holding part 21 Session key generation part 22 Public key generation part 23 Secret key generation part 24 Common secret key generation part 25 Secret key holding unit 26 Session key holding unit (storage means)
27 Packet encryption unit 41 SSL client 42 SSL server 43 Hub 52 Filter unit 53 Filter setting unit 54 Record reconstruction unit 55 Record information holding unit 56 Record decryption unit (decryption means)
57 record analysis unit 58 handshake analysis unit 59 session information holding unit 60 connection information holding unit 61 public key encryption processing unit 62 secret key setting unit 63 packet shaping unit

Claims (9)

Provided between the first communication device and the second communication device, send and receive encrypted packets between the first communication device and the second communication device, and communicate the packets transmitted and received An encryption communication decryption device for a communication system that causes a monitoring device to monitor the contents,
While decrypting the packet transmitted from the first communication device, the first key information for encrypting the packet addressed to the first communication device, and decrypting the packet transmitted from the second communication device Storage means for storing second key information for encrypting a packet addressed to the second communication device, and an encryption algorithm using the first key information or the second key information;
When a packet is received from the first communication device, the packet is decrypted using the first key information according to the encryption algorithm, and the decrypted packet is encrypted using the second key information. When the packet is transmitted to the second communication device and the packet is received from the second communication device, the packet is decrypted using the second key information according to the encryption algorithm, and the decrypted packet is Relay means for encrypting using the key information of 1 and transmitting to the first communication device;
An encryption unit comprising: an output unit configured to shape the packet decrypted by the relay unit into a form that can be processed by the monitoring device, output the packet to the monitoring device, and cause the monitoring device to monitor communication contents; Communication decoding device.   The output means sets the destination of the packet decrypted by the relay means to the address of the monitoring device, and is necessary for encryption and decryption of the header and trailer added to the packet decrypted by the relay means By removing the header and trailer and changing the next header protocol information contained in the removed header or trailer to the next header protocol information of the header added to the head of the packet decoded by the relay means, The encrypted communication decryption apparatus according to claim 1, wherein the packet decrypted by the relay unit is shaped into a form that can be processed by the monitoring apparatus. An input means for inputting processing information of processing performed before encrypting the packet decrypted by the relay means;
The relay unit performs processing based on the processing information input by the input unit before encrypting the packet decrypted by the relay unit using the first key information or the second key information, The encrypted communication decryption apparatus according to claim 1, wherein the packet subjected to the processing is encrypted and transmitted to the first communication apparatus or the second communication apparatus. Of the first communication device and the second communication device, one communication device is a communication device on the start side, and the other communication device is a communication device on the response side, and is stored in the storage means. A key generation means for generating key information and second key information;
The key generation means includes
Key sharing data holding means for storing arbitrary values agreed in advance by the initiating communication apparatus and the responding communication apparatus, a secret key generating means for generating a secret key by generating a random number, and the secret key From the secret key generated by the generating means and the value stored in the key sharing data holding means, the public key generating means for generating a public key, and the communication apparatus on the start side or the communication apparatus on the response side Using the received public key, the secret key generated by the secret key generating means, and the value stored in the key shared data holding means, a common secret key generating means for generating a common secret key,
When a key is exchanged between the start side communication device and the response side communication device,
The secret key generation means generates a starter secret key instead of the responding communication device, and generates a responder secret key instead of the starter communication device,
The public key generation means generates a starter public key from the starter private key instead of the responder communication device, and generates a response side public key from the responder private key instead of the starter communication device. Produces
The initiator public key equal to the public key of the responding communication device is transmitted to the initiator communication device, and the response public key equal to the public key of the initiator communication device is transmitted to the responder communication. To the device,
The response side common secret key is generated using the start side secret key generated by the secret key generation means and the public key of the communication apparatus received from the response side communication apparatus, and generated by the secret key generation means. Generating a common secret key on the initiating side using the response side secret key and the public key of the communication device received from the initiating side communication device,
The response side common secret key is stored in the storage means as one of the first key information and the second key information, and the start side common secret key is stored in the first key information and the second key information. The encryption communication decryption apparatus according to claim 1, wherein the encryption means is stored in the storage unit as the other of the key information.   The relay means encrypts the decrypted packet for output from the output means to the monitoring apparatus when the monitoring means receives a monitoring result that is output from the output means and is an appropriate packet by the monitoring apparatus. When relaying and receiving a monitoring result output from the output means and indicating that the packet is inappropriate, the relay of the decoded packet is stopped for output from the output means to the monitoring apparatus. The encryption communication decryption apparatus according to claim 1.   2. The encryption according to claim 1, wherein when the relay unit receives a packet output from the output unit and subjected to arbitrary processing by the monitoring device, the packet is encrypted and relayed. Communication decoding device. A packet that is encrypted and transmitted between the first communication device and the second communication device, and that is provided on a communication path between the first communication device and the second communication device An encryption communication decryption device of a communication system that intercepts through the device and causes the monitoring device to monitor the communication content of the packet,
First key information for decrypting a packet transmitted from the first communication device to the second communication device, and a first key information for decrypting a packet transmitted from the second communication device to the first communication device. Storage means for storing the key information of 2 and the encryption algorithm using the first key information or the second key information;
When a packet is received from the first communication device, the packet is decrypted using the first key information according to the encryption algorithm, and when the packet is received from the second communication device, the encryption is performed. Decrypting means for decrypting the packet using the second key information in accordance with the encryption algorithm;
An encryption unit comprising: an output unit configured to shape the packet decrypted by the decryption unit into a form that can be processed by the monitoring device, output the packet to the monitoring device, and cause the monitoring device to monitor communication contents; Communication decoding device.   The output means adjusts the data of the packet decoded by the decoding means to a data length that can be processed by the monitoring device, and adds the protocol information of the data and the monitoring destination of the packet to the adjusted data. 8. The encryption according to claim 7, wherein a packet added with a header including an address of a device is created to shape the packet decrypted by the decrypting means into a form that can be processed by the monitoring device. Communication decoding device. A secret key setting means for setting a secret key of the first communication device or the second communication device for generating the first key information or the second key information;
A packet for negotiating and determining the first key information, the second key information, and the encryption algorithm being performed between the first communication device and the second communication device; Further comprising key generation means for intercepting and generating first key information and second key information stored in the storage means and an encryption algorithm based on the intercepted packet and the secret key. The encryption communication decryption apparatus according to claim 7, wherein:

Images