JP2007329751A - Encrypted communication system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a protocol stack capable of further improving a function of preventing leakage of data, falsification and spoofing of data, invasion, and attack without modifying high-order application programs. <P>SOLUTION: The communication system includes at least a protocol encrypting means for encrypting a payload of a protocol corresponding to at least TCP or UDP out of information units, such as packets to be input/output or transmitted/received in accordance with a predetermined encryption logic, and outputting or transmitting the encrypted payload; and a protocol decrypting means for decrypting the encrypted protocol inputted or received, in accordance with a predetermined decryption logic. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to an encrypted communication system for communication, and more particularly to an encrypted communication system for preventing data “leakage” and “falsification”, “spoofing”, “entrance”, and “attack” on the Internet.

  In recent years, communication using the Internet has rapidly spread in society because anyone can access a computer on a network by connecting it to a network as long as it has a Windows personal computer. On the other hand, with the spread of Internet communication, there are social problems such as hackers and crackers intruding into other people's computer systems to steal software, data, tamper and destroy. It is getting bigger.

  As a specific case of illegal interference, first of all, there is a system interference in which a large number of messages are sent from the network and the operation of the computer system is interrupted so that the central system cannot be used. If the host is overloaded due to this interference, the system may go down.

  In addition, there is an illegal interception of “illegal access and impersonation” that obtains a host password, steals confidential information, or alters or destroys information. Some of these obstructions mean that the information held by the computer can be rewritten and the person can fall. In addition, fraudulent acts called spyware that sneak into specific computers and exploit personal sensitive data such as email addresses and passwords have also occurred. In this way, it is impossible to deny the possibility that so-called eavesdropping is frequently performed in which the contents of a database held by a computer connected to a network are illegally stolen.

In addition, there is no risk of cyber terrorism caused by intentional stealing of personal information or cyber terrorism lurking inside the company at the site or server operator.
In addition, fraudulent disturbances such as sending "viruses" that are programs that cause computer problems to other people's computers have recently been increasing. This sent virus infects a computer that used e-mail at home, and when it is connected to the company, the entire company computer is infected, or the virus destroys files in the computer. There are also problems such as bringing down the entire network.

  For this reason, IPsec (IP) is a function to prevent data leakage or tampering in communication over the Internet using conventional Transmission Control Protocol / Internet Protocol (TCP / IP) or User Datagram Protocol (UDP). SEC: Encrypted communication called Security Architecture for Internet Protocol (SSL) or Secure Socket Layer (SSL) is used. In general, encrypted communication includes a common key (also referred to as a secret key) encryption method and a public key encryption method, and IPsec often uses a common key encryption method. The common key cryptosystem has a feature that the encryption / decryption speed is faster than the public key cryptosystem. The common key encryption method used for IPsec is a method in which encryption and decryption are performed with the same key, and the key may be generated on either the transmission side or the reception side. In order to use a common key, it is necessary to pay close attention not to leak the contents to the outside when exchanging keys.

  A typical algorithm used in the common key cryptosystem is DES (Data Encryption Standard: a common key (secret key) encryption algorithm developed by IBM Corporation, USA). IPsec also uses this DES as one of the encryption algorithms. A feature of IPsec is that not only a specific application is encrypted but all communications transmitted from the host are encrypted at the IP level. As a result, the user can perform secure communication without being aware of the application. In addition, IPsec can change the encryption algorithm to be used without changing its own mechanism so that it can be used in the future.

  A 32-bit code called SPI (Security Pointer Index) is used as a common encryption key used in IPsec, and IKE (Internet Key Exchange) is used as a key exchange protocol. Furthermore, in IPsec, a protocol AH (Authentication Header) for integrity authentication is prepared.

  SSL is an HTTP protocol with security function developed by Netscape Corporation (currently merged with AOL). By using this protocol, the client and server can authenticate each other on the network, and credit card information It is possible to exchange highly confidential information such as. This prevents data eavesdropping, replay attacks (attack of eavesdropping on data flowing over the network and repeatedly sending data), spoofing (communication by pretending to be the person), data tampering, etc. be able to.

The above-described IPsec encrypts and transmits IP packets. Therefore, application software that uses a higher-level protocol such as TCP or UDP does not need to be aware that IPsec is used.
On the other hand, in SSL, digital certificates using RSA (Rivest Shamir Adleman: an acronym for three developers of public key cryptography) public key cryptography are used at the mutual authentication level, and DES is used for data encryption. Common key encryption technology is used. Since this SSL is in the session layer of the fifth layer, it depends on a specific application.
R. Atkinson, August 1995, `` Security Architecture for the Internet Protocol '', RFC 1825

  However, there is a problem in that SSL is not compatible with applications. An application uses a socket (5th layer) as a program interface when performing Internet communication. For this reason, when an application uses SSL (5th layer), this socket interface must be changed to an SSL interface. Therefore, SSL does not have application compatibility. On the other hand, since IPsec is located below the socket (5th layer), the application can use the socket (5th layer) as a program interface as it is, so that the application is compatible.

  On the other hand, IPsec has a problem that the maximum segment size becomes small. In other words, since the ESP header and ESP trailer are used in IPsec, the payload becomes small, so that fragments (packet division) occur and throughput decreases. In addition, since fragmentation is prohibited in a TCP packet, it is necessary to grasp the environment through which IPsec passes at the end end and set the maximum segment size at which no fragment occurs. On the other hand, since SSL does not need to grasp the environment through which it passes, it is not necessary to set the maximum segment size.

  The present invention has been made in view of the above-described problems, and it is not necessary to implement an “encryption function” for preventing unauthorized entry into a computer terminal in each application program. There is no need to recreate the program itself, and it is possible to communicate with a communication partner that does not support the above encryption function in the conventional plaintext, and furthermore, encryption and authentication even in an environment where IPsec is not available (or in a situation where you do not want to use it) It is an object of the present invention to provide a communication system, particularly a protocol stack, a related communication device, a communication method, and a communication program for realizing the communication stack.

  In order to solve the above problems and achieve the object of the present invention, the encrypted communication system of the present invention performs communication between a plurality of hosts by adding an encryption function to the TCP or UDP protocol located in the transport layer. An encrypted communication system, a connection sequence means for connecting to a communication partner after determining whether the communication partner is a communication partner having a legitimate authority, and encryption corresponding to both ends of the communication path, and An agreement means for negotiating a decryption logic, a protocol encryption means for encrypting and transmitting packets of information transmitted and received between a plurality of hosts according to the encryption logic decided by the agreement means, and a decryption logic decided by the agreement means Protocol decoding means for decoding packets of information transmitted / received between a plurality of hosts according to The sequence means transmits a connection request from the first host to the second host and a connection response from the second host to the first host so as to cope with the network environment that excludes the unknown option. At this time, a flag is added to the TCP connection header, TCP2 specific information or emergency data is added to the payload, and encryption is performed to confirm that the key necessary for encrypted communication and the partner host have authority to perform the encrypted communication. Negotiation data is exchanged, and the agreement means determines that the connection sequence means has the proper authority, and uses only the communication partner connected to the encryption and decryption logic using the TCP or UDP protocol of the transport layer. The protocol encryption unit performs communication based on the TCP or UDP protocol in the transmitted / received information packet. Encrypt and send the payload of the Col protocol decoding means is an encryption communication system, characterized by decoding the payload of the encrypted protocol of the packet of information to be transmitted and received.

Examples of embodiments of the present invention will be described below with reference to FIGS.
FIG. 1 shows a protocol stack used in an embodiment of an encrypted communication system of the present invention.

  As shown in FIG. 1, the protocol stack used in the present invention has a NIC (Network Interface Card) Driver 11 in a layer corresponding to the physical layer (first layer) and the data link layer (second layer) of the OSI 7 layer. Arranged. As described above, this driver is a driver for an interface card for connecting hardware such as a computer to a network, and its contents are data transmission / reception control software. For example, a LAN board or a LAN card for connecting to Ethernet corresponds to this.

  In the third network layer, there is an IP emulator 3 partially extending to the transport layer (fourth layer). A function as a transport is not mounted on the extended portion. It only provides network layer functionality to the session layer. The IP emulator 3 functions to switch between “IPsec on CP” 13b and “IP on CP” 13a, which are protocols for performing encrypted communication, depending on the application. Here, “on CP” indicates that it is subject to monitoring, destruction, disconnection or passage restriction of “entry” and “attack” by a cracking protector (CP), or that can be set. ing.

  In addition, ARP on CP (Address Resolution Protocol on Cracking Protector) is arranged in the network layer. This ARP on CP is a protocol used to obtain a MAC (Media Access Control) address, which is a physical address of Ethernet, from an IP address provided with a protection measure against a cracker. The MAC is a transmission control technique used in a LAN or the like called medium access control, and is used as a technique for specifying a frame transmission / reception method, a frame format, error correction, and the like as a data transmission / reception unit.

  Here, the IP emulator 13 is software or firmware for matching various security functions according to the present invention with a conventional IP peripheral stack. That is, ICMP (Internet Control Message Protocol) 14a, which is a protocol for transferring IP error messages and control messages, and a group of hosts configured to efficiently deliver or receive the same data to a plurality of hosts Software (IGMP) that is a protocol for controlling the network, TCP15, UDP16, and software for matching with the socket interface 17, or firmware or hardware (electronic circuit, electronic component) is there. This IP emulator 13 can perform adaptation processing before and after IPsec encryption / decryption and addition / authentication of necessary authentication information.

  In the upper transport layer (fourth layer) of the IP emulator 13, a TCP emulator 15 and a UDP emulator 16 are arranged. The TCP emulator 15 functions to switch between “TCPsec on CP” 15b, which is a protocol for performing encrypted communication, and “TCP on CP” 15a, which is a normal communication protocol. Similarly, the UDP emulator 16 functions to switch between “UDPsec on CP” 16b, which is a protocol for performing encrypted communication, and “UDP on CP” 16a, which is a normal communication protocol.

The most characteristic feature of the present invention is that this transport layer (fourth layer) is equipped with encrypted communication protocols of TCPsec 15b and UDPsec 16b. TCPsec15b and UDPsec16b will be described later.
In the upper session layer (fifth layer) of the transport layer (fourth layer), a socket interface 17 for exchanging data with protocols such as TCP and UDP is provided. The meaning of this socket is a network address that combines an IP address corresponding to an address in the network of a computer and a port number that is a sub-address of the IP address as described above. It consists of a single software program module (execution program, etc.) or a single hardware module (electronic circuit, electronic component, etc.) that is added or deleted collectively.

The socket interface 17 provides a uniform access method from higher-level applications (such as the EC application shown in FIG. 2 and the broadcast application shown in FIG. 3). I try to keep the interface.
The TCP emulator 15 has a function of preventing data leakage / falsification in the transport layer, that is, a TCPsec 15b having functions such as encryption, integrity authentication and partner authentication, and such encryption, integrity authentication, and partner It has a function of distributing packets to any one of the normal protocols TCP15a having no function such as authentication. Further, since both the TCPsec 15b and the TCP 15a are provided with a cracking protector (CP), it is possible to realize a function of protecting against “entry” and “attack” by a cracker, regardless of which one is selected. The TCP emulator 15 also serves as an interface with a socket, which is an upper layer.

  Further, as described above, TCP has an error compensation function, whereas UDP does not have an error compensation function, but has a feature that the transfer speed is correspondingly faster and a broadcast function is provided. As with the TCP emulator 15, the UDP emulator 16 has a function of preventing data leakage / falsification, that is, a UDPsec 16b having functions such as encryption, integrity authentication and counterpart authentication, and such encryption, integrity authentication, And has a function of distributing the packet to any one of the normal protocols UDP 16a having no function such as counterpart authentication.

  As shown in FIG. 1, socket 17, TCP emulator 15, UDP emulator 16, "TCPsec on CP" 15b, "UDPsec on CP" 16b, "TCP on CP" 15a, "UDP on CP" 16a, "ICMP on CP" ”14 a,“ IGMP on CP ”14 b, IP emulator 13,“ IP on CP ”13 a, and“ ARPonCP ”12 are protocol stacks for performing the encryption processing of the present invention. The stack is collectively referred to as TCP2 (registered trademark pending). Note that “IPsec on CP” 13b is not included as essential in TCP2, but TCP2 including “IPsec on CP” 13b may be used.

  TCP2 of the present invention implements CP (cracking protection) in standard protocols of TCP, UDP, IP, IPsec, ICMP, IGMP, and ARP, and attacks from communication and application programs to each protocol stack. (Trojan horses, program tampering, unauthorized use by authorized users) can be prevented. Also, in TCP2, a TCP emulator 15 is mounted, and this TCP emulator 15 is outward-facing to maintain compatibility when viewed from the socket 17 in the session layer and the IP emulator 13 in the network layer. It can look the same as standard TCP. Actually, the TCP2 function is executed by switching between TCP and TCPsec. TCPsec is an encryption and authentication function in the transport layer according to the present invention.

  Similarly, in TCP2, the UDP emulator 16 is mounted, and the UDP emulator 16 is compatible with the socket 17 that is a session layer and the IP emulator 13 that is a network layer in order to maintain compatibility. From the outside, it can be shown as standard UDP. Actually, as a function of TCP2, UDP and UDPsec are switched and executed. UDPsec is an encryption and authentication function in the transport layer according to the present invention.

Next, TCPsec15b and UDPsec16b, which are functions that prevent “data leakage”, which is a particularly important function in TCP2, will be described.
As an encryption / decryption method (algorithm, logic (logic)) for TCPsec15b and UDPsec16b, a known secret key (common key) encryption algorithm is used. For example, DES (Data Encryption Standard), which is a secret key encryption algorithm developed by IBM in the 1960s, and 3DES as an improved version thereof are used. As another encryption algorithm, IDEA (International Data Encryption Algorithm) announced by Mr. James L. Massey and Mr. Xuejia Lai of Swiss Institute of Technology in 1992 is also used. In this encryption algorithm, data is divided into 64-bit blocks and encrypted, and the length of the encryption key is 128 bits. It is designed to have sufficient strength for linear cryptanalysis and differential cryptanalysis that efficiently decrypt private key cryptography.

  In addition, as encryption methods of TCPsec15b and UDPsec16b used in the present invention, encryption methods such as FEAL (Fast Data Encipherment Algorithm), MISTY, and AES (Advanced Encryption Standard) are used, and a secret encryption created independently is also used. -Decryption algorithms can also be used. Here, FEAL is an encryption method developed by Nippon Telegraph and Telephone Corporation (at that time), and is a secret key type encryption method that uses the same key for encryption and decryption. This FEAL has an advantage that encryption and decryption can be performed at a higher speed than DES.

  Next, MISTY, which is also an encryption method used in the present invention, is a secret key type encryption method developed by Mitsubishi Electric Corporation, and encrypts data divided into 64-bit blocks in the same manner as IDEA. The key length is 128 bits. The same program is used for encryption and decryption as in DES. This method is also designed to have sufficient strength against linear cryptanalysis and differential cryptanalysis that efficiently decrypt private key cryptography.

  AES is the next-generation standard encryption method of the US government, which is being selected by the US Department of Commerce's Standard Technology Bureau, as the next-generation encryption standard to replace DES, which is the current standard encryption method. Development has been advanced. Among a number of ciphers that were collected by public recruitment around the world, the Rijndael method developed by Belgian crypto developers Joan Daemen and Vincent Rijmen was adopted in October 2000.

  As described above, as the encryption methods of TCPsec15b and UDPsec16b of the present invention, various known secret key encryption algorithms can be adopted, and a secret key (common key) encryption method uniquely developed by the user is used. Can also be used.

  Furthermore, as a method of “party authentication” and “integrity authentication” to prevent so-called “spoofing” and “data falsification”, an algorithm using a public key or pre-shared, for example, MD5 Authentication algorithms such as (Message Digest 5) and SHA1 (Secure Hash Algorithm 1) are used. An algorithm using a unique one-way function may be employed instead of such a known authentication algorithm.

  This MD5 is one of hash functions (one-way summarization functions) used for authentication and digital signatures, generates a fixed-length hash value based on the original text, and compares it at both ends of the communication path. It is possible to detect whether the original text has been tampered with during communication. This hash value takes a value like a pseudo random number, and based on this value, the original text cannot be reproduced. It is also difficult to create another message that generates the same hash value.

  SHA1 is also one of hash functions used for authentication, digital signatures, etc., and generates a 160-bit hash value from the original text of 2 <64> bits or less and compares it at both ends of the communication path. It detects the alteration of the original text. This authentication algorithm is also employed in IPsec, which is a typical example of conventional encrypted communication on the Internet.

  These authentication algorithms are designed to enable secure key exchange using the DH (Diffie-Hellman) public key distribution method or the IKE (Internet Key Exchange) protocol (UDP 500) similar to IPsec. Moreover, it is scheduled by a protocol driver program (TCPsec15b, UDPsec16b, etc.) so that the encryption / integrity authentication algorithm (logic) itself and the key set / domain for that purpose are changed periodically.

  Next, based on FIG. 2, the encrypted communication using the encryption system TCP2 (particularly, TCPsec) according to the first embodiment of the present invention will be described. FIG. 2 is an example applied to communication applied particularly to an EC (Electronic Commerce) application.

  FIG. 2 shows a host computer (so-called server) in which client terminals 3a, 3b and 3c for EC applications connected to the network 20 are connected to another network 30 via a network control device 2 such as a so-called router or gateway. It is a figure which shows the whole structure at the time of being connected to the communication apparatus which functions as.

  Of the client terminal 3a, client terminal 3b, and client terminal 3c connected to the network 20, the client terminals 3b and 3c do not implement the TCP2 of the present invention. That is, neither TCPsec nor UDPsec, which are protocols for the encryption method of the present invention, is implemented in the client terminals 3b and 3c. Only the client terminal 3a supports TCP2. For the client terminal 3b, connection by normal protocol processing by a network policy setting (not shown), that is, for the TCP level, an encryption function for preventing “data leakage”, an integrity authentication function for preventing “data tampering”, In addition, the other party authentication function for preventing “spoofing” is performed without connection.

  In any of the client terminals 3a to 3c, application software for EC is mounted on the upper layer of the socket. The host computer 1 connected to the network 30 is equipped with TCP 2, and EC application software 18 is mounted on the upper layer of the socket 17. In FIG. 2, an unused protocol such as UDPsec is omitted, but the software stack constituting the protocol stack of FIG. 1 is all installed in the protocol stack structure of the host computer 1.

  That is, first, a NIC driver (NIC Driver) 11 is arranged across the first layer (physical layer) and the second layer (data link layer), and the ARP (Address Resolution Protocol) is provided on the upper layer (third layer). ) 12 and the IP emulator 13 are arranged. The TCP emulator 15 and the UDP 16 are arranged in the fourth transport layer. The reason why there is no description of the UDP emulator (including UDPsec and UDP) in FIG. 2 is that TCPsec, which emphasizes error compensation rather than speed, is used as encrypted communication for the EC application of the first embodiment. . This does not mean that the host computer is not equipped with UDPsec. The installation of TCP2 means that both UDPsec and TCPsec are installed as already described.

The protocol stack of the network control device 2 with the client terminals 3a, 3b, 3c connected to the network 20 and the host computer 1 connected to the network 30 is firmware (NIC driver, ARP, IP stacked as a stack ( Electronic circuit with nonvolatile memory).
The client terminal 3a is a terminal that supports the TCP2 of the present invention. Here, a protocol stack is shown as a terminal provided with a communication device that supports only TCPsec. Client terminals 3b and 3c do not support TCP2 of the present invention.

  The client terminal 3a is mounted with protocol driver software distributed in advance through a network or a recording medium such as a CD-ROM. Similarly, protocol driver software is distributed and implemented in advance for the client terminals 3b and 3c.

  In particular, for the client terminal 3c, IPsec, which is a conventional encryption method, is implemented. However, since the network control device (router) 2 performs IP masquerading with reference to a TCP port number, IPsec cannot be used effectively. It is like that. Further, for the client terminal 3c, the connection request is discarded by a network policy setting (not shown). Note that the confirmation of whether or not the network policy is set or the protocol is implemented (received packet analysis or the like) itself is a well-known matter to those skilled in the art, and thus description thereof is omitted in this specification.

  When the host computer 1 communicates with the client terminal 3a, the host computer 1 communicates with the client terminal 3b or 3c. However, the host computer 1 communicates with the client terminal 3b or 3c. When doing so, communication according to the TCP protocol (particularly TCPsec) of the present invention is not negotiated, that is, communication using the normal TCP protocol is performed. Of course, when the host computer 1 communicates with the client terminal 3c supporting IPsec, it is natural that encrypted communication by IPsec can be performed. Even if the host computer 1 tries to communicate with the client terminal 3b or 3c not equipped with TCP2, it is possible to stop the communication by the function of TCP2 that the host computer 1 has.

  In this embodiment, the host computer 1 and the client terminal 3a exchange encryption and decryption logic via a network. However, using a removable medium such as an FD, CD, or UDB memory. It goes without saying that the negotiation logic for encryption and decryption can be exchanged between the communicating parties in advance.

  Next, the encrypted communication using the UDPsec encryption method in TCP2, which is the second embodiment of the present invention, will be described with reference to FIG. FIG. 3 shows a host computer (so-called server) in which client terminals 4a, 4b, 4c for broadcasting applications connected to the network 20 are connected to another network 30 via a network control device 2 such as a so-called router or gateway. 1 is a diagram illustrating an overall configuration of a communication system that communicates with a communication device 1 that functions as:

  FIG. 3 shows the protocol stacks of the client terminals 4a, 4b, and 4c and the host computer 1, but the client terminals that support TCP2 are 4a and 4b. That is, only the terminals 4a and 4b are provided with UDPsec. Broadcast application software is installed in the upper layer of the socket of each client terminal. Further, the host computer 1 connected to the network 30 is also equipped with TCP 2, and the broadcast application software 19 is mounted on the upper layer of the socket 17. Similarly to the host computer 1 in FIG. 2, the host computer 1 in FIG. 3 has all the software constituting the TCP 2 that is the structure of the protocol stack in FIG.

  The protocol stack possessed by the host computer 1 is substantially the same as the protocol stack of the host computer 1 of FIG. 2, but differs from the protocol stack of the host computer 1 of FIG. 2 in that there is a UDP emulator 16 instead of the TCP emulator. Is a point. This is because the broadcast application software handles a large amount of data such as images, and therefore, high speed is more important than error compensation such as data transmission.

  The protocol stack of the network control device 2 that includes the client terminals 4a, 4b, and 4c connected to the network 20 and the host computer 1 connected to the network 30 has firmware (NIC driver, ARP, and IP stacked as a stack ( Electronic circuit with nonvolatile memory).

  The client terminal 4a is a terminal that supports the TCP2 of the present invention. Here, the client terminal 4a is a terminal provided with a communication device that supports only UDPsec, and the client terminal 4b corresponds to the UDPsec of the present invention and a known IPsec. The client terminal 4c is a communication device that supports only known IPsec. This client terminal 4c does not support TCP2 of the present invention. Similar to the client terminals 3a to 3c in FIG. 2, protocol driver software distributed in advance through a network or via a recording medium such as a CD-ROM is mounted on these client terminals 4a to 4c. .

  In particular, encryption / decryption logic for preventing "data leakage" and authentication information addition / authentication logic for preventing "data falsification" are supported between the host computer 1 and the client terminals 4a, 4b, 4c. Need to be. Although it is possible to make an arrangement with a policy similar to the known so-called IPsec, in the second embodiment of the present invention, since protocol driver software itself is distributed in advance, a secret is obtained by a simpler original protocol. It is also possible to negotiate keys and use packets with a simpler structure. Further, instead of a known encryption / decryption and authentication algorithm, an encryption / decryption and authentication algorithm (logic) itself created independently can be incorporated as a software module of the protocol driver.

  Note that the client terminal 4c does not implement TCP2, but implements well-known IPsec that is used on the Internet, and thus can perform secure communication to some extent. However, the clients 4a and 4b implement and use UDPsec, which is a constituent element of TCP2 according to the present invention, instead of IPsec, for the performance of the target broadcast application or the security policy. The reason for using UDPsec instead of IPsec is that IPsec itself is vulnerable, for example, performance degradation caused by encrypting the UDP port number portion (belonging to the IP payload) with IPsec.

  In addition, by embedding the partner authentication protocol for determining whether the communication partner is correct in the TCP or UDP protocol stack of TCP2 of the present invention, that is, TCPsec or UDPsec, without being aware of the upper application between the communication partners, A communication partner authentication function can be implemented. In this case, it is possible to substantially increase the number of communication packets, the packet length, and the like as long as the cost does not increase.

  In particular, when implementing a broadcast function for transmitting data to an unspecified number of other parties in a network, when using UDPsec, which is an encryption method according to the present invention, client terminals 3a and 3b that receive the broadcast. Starts negotiation (arrangement) and obtains communication partner authentication and a secret key for communication. The client terminals 3a and 3b cannot decrypt the UDPsec distribution data from the host computer 1 until the communication partner is authenticated and the communication secret key is acquired.

Next, based on FIG. 4, the packet structure transmitted / received in the communication of the first and second embodiments of the present invention, its encryption range, and the application range of integrity authentication will be described.
FIG. 4A shows the TCPsec / IPsec packet structure, each encryption range, and the applicable range of integrity authentication. FIGS. 4B and 4C show the TCPsec / IP and UDPsec / IP packet structures and the respective ciphers. It shows the scope of application and the scope of integrity certification.

  As shown in FIG. 4A, in the TCPsec / IPsec packet structure, an IPsec ESP header 42 follows immediately after the IP header 41. Subsequently, a TCP header 43 and additional information 44 of TCPsec are provided, followed by application data 45. After the application data 45, a TCPsec additional trailer 46, which is information for supporting encrypted data such as a blank of data generated by block cipher, the length of the blank, and the number of the next header, is arranged. The additional authentication data 47 is arranged. After that, the packet structure is such that an ESP trailer 48 for IP and ESP authentication data 49 are arranged.

  Of these, the portions indicated by numbers 41, 42, 48, and 49 are information for IPsec, and the numbers 43, 44, 46, and 47 are information related to TCPsec that plays a central role in TCP2 according to the present invention. Here, TCPsec is also arranged according to IPsec. However, depending on the encryption and authentication algorithms employed, the TCPsec additional information 44 and the additional trailer 46 may be omitted, or the TCPsec additional authentication data 47 may be reduced. Even it can be used.

  In the TCP2 packet structure shown in FIG. 4A, encryption is performed by two methods, TCPsec and IPsec. In this case, the transmission side first encrypts the TCPsec side and adds TCPsec authentication data. Next, IPsec is encrypted and IPsec authentication data is added. On the receiving side, first, the IPsec is decrypted, the data of the received packet is verified by the IPsec authentication data, and then the TCPsec side is decrypted, and the data of the received packet is verified by the TCPsec authentication data.

  In this way, data having a packet structure as shown in FIG. 4A is encrypted using two types of encryption algorithms, IPsec and TCPsec, and further integrity authentication is performed. It is possible to establish an encryption communication system that is extremely robust against intrusion and the like. The range encrypted by TCPsec is the application data 45 and the TCPsec additional trailer 46, and the TCPsec additional information 44 is further added to the encryption range as the authentication range by TCPsec. Note that the encryption range encrypted by the conventional IPsec is a portion from the TCP header 43 to the ESP trailer 48, and the authentication range is a range from the ESP header 42 to the ESP trailer 48.

  FIG. 4B shows the TCPsec / IP packet structure. Unlike FIG. 4A, the TCP header 43 and TCPsec additional information 44 follow immediately after the IP header 41, and application data 45 continues. It has a structure. The application data 45 is followed by a TCPsec additional trailer 46 and TCPsec additional authentication data, which are information supporting encrypted data such as a blank of data generated by block cipher, the length of the blank, and the number of the next header. 47 is arranged.

  Here, the numbers 43, 44, 46, and 47 are information characteristic of TCPsec. However, as described above, depending on the encryption / authentication algorithm employed, these pieces of information may be distributed in header fields that are not used by TCPsec / IP, etc., or may not be calculated or estimated from individual packets. It can be omitted by negotiation. Further, by constructing a TCPsec / IP packet as shown in FIG. 4 (b) using TCP corresponding to the upper layer of the IP layer and a protocol field not using IP, an IPsec packet focusing only on the lower layer IP Thus, the packet length can be easily reduced. Here, as shown in the figure, the encryption range is application data 45 and a TCPsec additional trailer 46, and the TCPsec additional information 44 is added to the authentication range in addition to the encryption range.

  FIG. 4C shows a UDPsec / IP packet structure according to the present invention. The UDPsec additional information 44a, the UDPsec additional trailer 46a, and the UDPsec additional authentication data 47a are information necessary for supporting UDPsec. As shown in the figure, the encryption range includes application data 45a and a UDPsec additional trailer 46a. The authentication range includes UDPsec additional information 44a in addition to the encryption range.

  Next, the operation of the encryption processing system using TCPsec according to the first embodiment of the present invention is based on the flowcharts shown in FIGS. 5 to 6 and FIGS. 8 to 14 and the sequence diagram shown in FIG. explain.

  FIG. 5 is a flowchart of processing in TCP and TCPsec passive open (open for waiting for connection corresponding to host B in FIG. 7, for example, the Web server opens in this state). The TCP / TCPsec passive open process starts when the program waits for connection open (step S1). This portion corresponds to the processing on the host B side in FIG.

  First, the port number to be opened is analyzed (step S2). In this analysis, for example, in the case of a Web server, the TCP port number 80 is used to check the definition state. Next, it is determined whether or not this port number 80 is permitted for TCPsec passive open (step S3). If TCPsec passive open is not permitted in step S3, it is determined whether or not TCP passive open is permitted (step S4). If TCP passive open is not permitted in determination step S4, neither TCPsec nor TCP is permitted, and TCP / TCPsec passive open fails, and the process is interrupted (step S7).

When TCP passive open is permitted in the determination step S4, that is, when TCPsec passive open is not permitted but TCP passive open is permitted, a TCP passive open process shown in FIG. Step S5).
If the TCPsec passive open permission state is confirmed in the determination step S3, the TCPsec passive open process shown in FIG. 9 described later is executed (step S6).

  When the TCP passive open process or the TCPsec passive open process in step S5 or S6 ends, the TCP / TCPsec passive open process ends (step S7). As described above, in this example, the upper-level application performs passive open with TCP. However, if TCPsec is supported according to the determination of TCP2, communication is performed with TCPsec, and if TCPsec is not supported. Communication is performed using TCP.

  Next, TCP and TCPsec active open processing according to the present invention will be described with reference to FIG. The TCP / TCPsec active open is a connection request open. For example, a client terminal mounted with a Web browser opens in this state. In FIG. 7, the processing on the host A side corresponds to this. FIG. 6 is a flowchart of processing in this active open. When a connection request is opened in the upper application program, this TCP / TCPsec active open processing is started (step S8).

  First, the port number to be opened is analyzed (step S9). In this analysis, for example, when a client terminal application that implements a Web browser tries to use the TCP port number 3000, the definition state of the TCP port number 3000 is confirmed.

  Next, it is determined whether TCPsec active open is permitted for this port number 3000 (step S10). If it is determined in step S10 that TCPsec active open is not permitted, it is subsequently determined whether TCP active open is permitted (step S11). If TCP active open is not permitted in the determination step S11, neither TCPsec nor TCP active open is permitted, TCP / TCPsec active fails, and the connection process is interrupted (step S14). .

  When the TCP active open is permitted in the judgment step S11, that is, when the TCPsec active open is not permitted but the TCP active open is permitted, the TCP active open process shown in FIG. Step S12).

  If the TCPsec active open permission state is confirmed in the determination step S10, the TCPsec active open process shown in FIG. 11 described later is executed (step S13). When the TCPsec active open process or the TCPsec active open process in step S12 or S13 ends, the TCP / TCPsec active open process ends (step S14). In the case of TCP / TCPsec active open, as in the case of TCP / TCPsec passive open (FIG. 5), active open is performed by TCP from the upper application, but TCPsec is supported by judgment of TCP2. If so, communication is performed using TCPsec. If TCPsec is not supported, communication is performed using TCP.

  Next, communication processing using TCPsec of the present invention will be described with respect to sequence processing between the active open side host A and the passive open side host B based on FIG.

FIG. 7 shows a connection sequence, a data communication sequence, and a disconnection sequence in comparison with standard TCP when TCPsec, which is the cryptographic processing protocol of the present invention, is used. 7A is a diagram showing a communication sequence when standard TCP is used, and FIG. 7B is a diagram showing a communication sequence when TCPsec of the present invention is used.
As shown in FIG. 7A, in the standard TCP, the host B application is TCP passive open and the host A application is TCP active open.

  When the host B application performs TCP passive open, TCP passive open processing (see step 5 and FIG. 8 in FIG. 5) is started, and reception waits as shown in step S15 in FIG. When the application of host A performs TCP active open, TCP active open processing (see step S12 in FIG. 6 and FIG. 10) is started, and connection from host A to host B is performed as shown in step S52 of FIG. A request (SYN) is transmitted. As a result, the standard TCP connection sequence is started.

  Upon receiving this connection request (SYN), the host B side ends the analysis of the received packet of this connection request and transmits a connection response (SYN / ACK) to the host A side. Here, ACK is an abbreviation for Acknowledgment, and is transmitted when data transfer is normally completed. Upon receiving this connection response (SYN / ACK), the host A side transmits an ACK (acknowledgment) indicating that the connection is completed, and ends the standard TCP connection sequence.

  When this standard TCP connection sequence ends, the standard TCP data communication sequence becomes valid, and either the host A side or the host B side transmits data, and then receives an ACK (acknowledgment) from the data receiving side. Data is transmitted and received by repeating the basic pattern of returning.

In this standard TCP data communication sequence, either the host A or the host B can make a disconnection request to the other party.
FIG. 7A shows a case where a disconnection request is transmitted from the active open side host A to the passive open side host B. When there is a disconnection request from the application of the host A, the host A transmits a disconnection request (FIN). When receiving the disconnection request (FIN), the host B transmits a disconnection response (FIN / ACK) as shown in step S23 of FIG. Upon receiving this disconnection response (FIN / ACK), the host A transmits an ACK (acknowledgment) and ends the standard TCP disconnection sequence.

Next, a communication sequence using TCPsec according to the present invention will be described with reference to FIG. In FIG. 7B, the host B application is TCPsec passive open, and the host A application is TCPsec active open.
When the host B application performs TCPsec passive open, TCPsec passive open processing (see step S6 and FIG. 9 in FIG. 5) is started, and reception waits as shown in step S31 in FIG. When the application of host A performs TCPsec active open, TCPsec active open processing (see step S13 in FIG. 6 and FIG. 11) is started, and a connection request is sent from host A to host B as shown in step S69 of FIG. (SYN) is transmitted. As a result, the TCPsec connection sequence is started. Note that the TCPsec flag and the TCP2-specific information or emergency data are added to the connection request (SYN) in the data part to notify the other party that it is the correct partner. That is, before exchanging the next TCPsec negotiation data between the host A and the host B, it is possible to confirm whether or not the counterpart terminal is a terminal that supports TCP2, in other words, whether or not it is a correct counterpart for communication. it can.

  On the host B side, when the connection request (SYN) transmitted from the host A is received, if it is a correct partner, a connection response (SYN / ACK) is transmitted to the host A. Note that the TCPsec flag and the TCP2 specific information or emergency data are added to the data part in the connection response (SYN / ACK) to notify the other party of being a correct partner. When the host A side receives the connection response (SYN / ACK) from the host B, it transmits an ACK (acknowledgment). Subsequently, the TCPsec negotiation data is exchanged between the host A and the host B, and if it is a correct partner, the TCPsec connection sequence is terminated.

  When this connection sequence is completed, the TCPsec data communication sequence becomes valid, and after repeating the basic pattern in which either the host A side or the host B side transmits data and then returns an ACK (acknowledgment) from the data receiving side. Data is sent and received. Needless to say, this data is all encrypted data.

  In the TCPsec data communication sequence, either host A or host B can make a disconnection request to the other party. In FIG. 7B, disconnection is started from the host A on the active open side. When there is a disconnection request from the application of the host A, the host A transmits a disconnection request (FIN). In this disconnection request (FIN), a TCPsec flag and TCP2-specific information or emergency data are added to the data part, so that the other party can be notified of the correct party. When receiving the disconnection request (FIN), the host B transmits a disconnection response (FIN / ACK) as shown in step S42 in FIG. Note that the TCPsec flag and TCP2-specific information or emergency data are added to the data part in the disconnection response (FIN / ACK) to notify the other party that the party is the correct partner. Upon receiving this disconnection response (FIN / ACK), the host A transmits an ACK (acknowledgment) and ends the TCPsec disconnection sequence.

  The sequence from connection to disconnection of communication for TCPsec, which is one of the standard TCP and TCP2 of the present invention, has been described above based on FIG. 7, but a flow chart for passive open processing and active open processing for TCP and TCPsec below. Will be described in order.

First, the details when the TCP passive open process is started in step S5 of the flowchart of FIG. 5 will be described based on the flowchart of FIG.
When the protocol to be processed in step S5 in FIG. 5 is determined to be TCP, the TCP passive open process in FIG. 8 is started. First, it waits for reception and analyzes the received packet (step S15). Subsequently, it is determined whether or not the received packet is a correct packet, that is, whether or not it is a TCP protocol attack pattern in a DoS attack (step S16). If it is determined in step S16 that the packet is an illegal packet, the received packet is discarded (step S17), and the next packet is awaited.

  If it is determined in the determination step S16 that the received packet is a correct TCP packet, it is subsequently determined whether or not the connection is in progress, that is, whether or not the connection sequence between the host A and the host B in FIG. (Step S18). If it is determined in the determination step S18 that the connection is being established, it is next determined whether or not the packet is a disconnection request (FIN in FIG. 7A) (step S19). If it is not a disconnection request, it is subsequently determined whether it is a disconnection response (FIN / ACK in FIG. 7A) (step S20). If it is neither a disconnection request nor a disconnection response, TCP data transmission / reception processing is performed (step S21). If the received packet is a disconnection response, an ACK is transmitted from the host A in FIG. Disconnected (step S25). If it is determined in the determination step S19 that the request is a disconnection request from the host A, a disconnection response is transmitted from the host B (step S23).

When a disconnection response is transmitted in step S23, the final ACK is waited (step S24). Then, after receiving the final ACK, the TCP is disconnected (step S25), and the TCP passive open is terminated (step S26).
If it is determined in the determination step S18 that the reception port is not connected, it is determined whether or not the received packet is a passive open permission port (step S27). If the received packet is not permitted, the received packet is discarded (step S28) and the next packet is awaited. If it is determined in the determination step S27 that the received packet is permitted to be passively opened, it is then determined whether or not the packet is a connection request (step S29). Discard (step S28) and wait for the next packet. If it is determined in the determination step S29 that the request is a connection request, a connection response is transmitted to set the TCP in a connection state (step S30).

  Next, details of the processing step S6 in the TCPsec passive open of FIG. 5 will be described based on the flowchart of FIG. This process is a process when it is determined that the process of the received packet is a TCPsec process, as shown in step S6 of FIG. First, waiting for reception, the received received packet is analyzed (step S31). Subsequently, it is determined whether or not the received packet is a correct packet, that is, whether or not it is a TCP protocol attack pattern in a DoS attack (step S32). If it is determined in step S32 that the packet is an illegal packet, the received packet is discarded (step S33), and the process returns to step S31 to wait for reception of the next packet.

  If it is determined in the determination step S32 that the received packet is a correct packet, it is subsequently determined whether or not the connection between the host A and the host B has been completed (whether connection is in progress) (step S34). If it is determined in the determination step S34 that the host A and the host B are connected, it is determined whether or not the next received packet is a disconnection request (FIN) (step S35). If it is not a disconnection request, it is next determined whether or not the received packet is a disconnection response (FIN / ACK) (step S36). If the received packet is neither a disconnection request nor a disconnection response, TCPsec data transmission / reception processing shown in FIG. 12 described later is performed (step S37), and the process proceeds to step S49. Next, when there is a disconnection response in the determination step S36, it is determined whether or not the disconnection keys match (step S38). Here, the disconnect key is a common key (secret key) exchanged between the host A and the host B in the negotiation in the connection sequence of FIG. 7, and the communication between the two can be disconnected only when the keys match. It can be done. If the disconnection keys match in determination step S38, ACK is transmitted (step S39), and TCPsec between host A and host B is disconnected (step S44). If the disconnection key does not match in determination step S38, the packet is discarded as an illegal packet (step S41), and the next received packet is awaited. Further, when it is determined in the determination step S35 that the received packet is a disconnection request (FIN), it is determined whether or not the disconnection keys match (step S40). If the disconnection key does not match, the received packet is discarded as an illegal packet (step S41), and if the disconnection key matches, a disconnection response (FIN / ACK) is transmitted (step S42). If a disconnection response is transmitted in step S42, the process waits for the final ACK from the other party (step S43). When this final ACK is received, TCPsec is disconnected (step S44), and TCPsec passive open is terminated (step S44). Step S45).

  If it is determined in the determination step S34 that the host A and the host B are not connected, it is determined whether or not the received packet is a passive open permission port (step S46). If the received packet is not a passive open permission port, the received packet is discarded (step S47), and the process returns to step S31 to wait for the next packet. If it is determined in the determination step S46 that the received packet is a passive open permission port, a TPCsec passive connection process shown in FIG. 13 described later is executed (step S48).

  Subsequently, based on the common key and the authentication data, it is determined whether or not the communication partner is normal, that is, a partner having a valid authority (step S49). If it is determined that it is a normal partner, the process returns to step S31 to wait for the next received packet. If it is determined that the communication partner is not a normal partner, the TPCsec connection is forcibly disconnected (step S50). The TCPsec passive open process is terminated (step S51).

Next, the TCP active open process shown in step S12 of FIG. 6 will be described based on the flowchart of FIG.
FIG. 10 is a diagram illustrating processing when it is determined that the protocol to be processed in FIG. 6 is TCP. First, a connection request (SYN) is transmitted from the transmission side host A to the reception side host B. (Step S52). When a connection response (SYN / ACK) is transmitted from the receiving host B in response to this connection request, it waits for reception next and analyzes the received packet (step S53). Next, it is determined whether or not the received packet is a correct packet, that is, whether or not it is a TCP protocol attack pattern in a DoS attack (step S54). If it is determined in step S54 that the packet is an illegal packet, the received packet is discarded (step S55), the process returns to step S53, and the next packet is awaited.

  If it is determined in the determination step S54 that the received packet is a correct packet, it is subsequently determined whether or not the transmission side (active side) host A and the reception side (passive side) host B are connected (step S54). S56). If it is determined in this determination step S56 that the connection is established, it is next determined whether or not the received packet is a disconnection request from the transmission side host A to the reception side host B (step S57). . If this is not a disconnection request, it is next determined whether or not it is a disconnection response (FIN / ACK) from the receiving host B to the transmitting host A (step S58). If it is neither a disconnection request nor a disconnection response, TCP data transmission / reception processing is performed (step S59), and the next received packet is awaited. If it is determined in step S58 that the response is a disconnection response from host B to host A, host A transmits an ACK affirming disconnection (step S60), and disconnects TCP (step S63).

If the received packet is a disconnection request in the determination step S57, a disconnection response is transmitted from the host B to the host A (step S61), and the host B waits for reception of the final ACK from the host A (step S61). S62). Then, after the host B receives the final ACK from the host A, the TCP is disconnected (step S63), and the TCP active open is ended (step S64).
If it is determined in the determination step S56 that the transmission side host A and the reception side host B are not connected, it is determined whether or not the received packet is an active open permission port (step S65). If the received packet is not permitted, the received packet is discarded (step S66) and the next packet is awaited. If it is determined in the determination step S65 that the received packet is permitted to be active open, it is then determined whether or not there is a connection response from the receiving host B (step S67). Then, the packet is discarded (step S66), the next packet is waited, and if the connection response is made from the receiving host B, the TCP connection state is set (step S68), the process returns to step S53, and the next received packet is wait.

Next, detailed processing when TCPsec active open in step S13 of FIG. 6 is started will be described based on the flowchart of FIG.
The process shown in the flowchart of FIG. 11 is started when it is determined that the protocol to be processed in step S13 of FIG. 6 is TCPsec. First, a connection request (SYN) is transmitted from the transmission side host A to the reception side host B (step S69). On the other hand, the reception side host B receives a connection response (SYN / ACK), and the reception of the packet is started, and the received packet is analyzed (step S70).

  Next, as a result of analyzing the received packet, it is determined whether or not the received packet is a correct TCP packet, that is, whether or not it is a TCP protocol attack pattern in a DoS attack (step S71). As a result, when it is determined that the packet is an illegal packet, the packet is discarded (step S72), and the process returns to step S70 to wait for the next packet.

  If it is determined in the determination step S71 that the received packet is a correct TCP packet, it is next determined whether or not the connection between the transmission side host A and the reception side host B is completed (whether connection is in progress). (Step S73). If the host A and the host B are connected, it is determined whether or not the received packet is a disconnection request (FIN) (step S74). If the received packet is not a disconnection request, it is next determined whether there is a disconnection response from the receiving host B (step S75). If there is no disconnection request and no disconnection response, the TCPsec data transmission / reception process shown in FIG.

  If there is a disconnection response in determination step S75, it is determined whether the disconnection keys match (step S77). The disconnection key is as described in FIG. If the disconnection key matches in the determination step S77, an ACK is transmitted from the transmission side host A to the reception side host B (step S78), and TCPsec between the host A and the host B is disconnected (step S83). . If the disconnection key does not match in decision step S77, the packet is discarded as an illegal packet (step S80), and the next received packet is awaited. If it is determined in the determination step S74 that the received packet is a disconnection request (FIN), it is also determined whether or not the disconnection keys match (step S79). If the disconnection key does not match, the received packet is discarded as an illegal packet (step S80). If the disconnection key matches, a disconnection response (FIN / ACK) is transmitted (step S81). When a disconnection response is transmitted in step S81, the process waits for the final ACK from the other party (step S82). When this final ACK is received, TCPsec is disconnected (step S83), and TCPsec active open ends ( Step S84).

  In the determination step S73, if the connection between the transmission side host A and the reception side host B is not completed, that is, it is determined that the connection is not being performed, it is determined whether or not the received packet is an active open permission port. (Step S85). If the received packet is not permitted, the received packet is discarded (step S87), and the process returns to step S70 to wait for the next packet. If it is determined in the determination step S85 that the received packet is active-open permitted, it is determined whether or not the received packet is a connection response (SYN / ACK) packet from the receiving host B. If the packet is not a connection response packet (step S86), the packet is discarded (step S87) and the next packet is waited. If it is determined in step S86 that the packet is a connection response packet, FIG. A TCPsec active connection process showing the details is performed (step S88).

  When TCPsec active connection processing is performed in step S88, it is next determined whether or not the receiving host B is a normal partner, that is, whether or not the connection is permitted (step S89). If it is determined that the connection is permitted, the process returns to step S70 to wait for reception of the next packet. If it is determined in step S89 that the connection is not permitted, TCPsec is used. Transmission / reception is forcibly disconnected (step S90), and TCPsec active open is terminated (step S91).

  Next, details of the TCPsec data transmission / reception processing when step S37 in FIG. 9 and step S76 in FIG. 11 are selected will be described based on the flowchart of FIG.

  First, when the TCPsec data transmission / reception process is started in step S37 of FIG. 9 and step S76 of FIG. 11, it is first determined whether or not there is a transmission request from a host application of the host A (step S92). If there is a transmission request from the host A host application, the transmission data is encrypted at the transmission side host A (step S93), authentication data is added to it (step S94), and the reception side host B is encrypted. The packet to which the authentication data is added is transmitted (step S95).

  Next, the receiving host B determines whether or not there is received data (step S96). If there is received data, the received data is decrypted (step S97). Next, it is determined whether or not the received and decoded data is correct data (step S98). This determination is made by confirming the decrypted data and the received authentication data. If it is determined that the decrypted data is not correct, the TCP / TCPsec is forcibly disconnected. (Step S99). This forced disconnection is performed by discarding the received data and making a disconnection request to the transmission side. If it is determined in the determination step S98 that the decrypted data is correct data, the received data is fetched, that is, the data is delivered to the upper protocol stack (step S100), and the TCPsec data transmission / reception process is performed. Completion (step S101).

Next, detailed processing when the TCPsec passive connection processing is started in step S48 of FIG. 9 will be described based on the flowchart of FIG.
First, it is determined whether or not the partner is a correct partner, that is, a computer having authority to connect to the own computer (step S102). If the partner is not the correct partner, a process for forcible disconnection of TCPsec is performed (step S102). S103). If it is determined in the determination step S102 that the connection partner is the correct partner, a connection response is transmitted from the receiving host B (step S104).

  And it is confirmed whether the information of the other party who transmitted the connection response exists in the own computer (step S105). If the partner information is not in the computer, the partner information is acquired from the installation server used when installing this system, that is, TCP2 (step S106). Alternatively, the partner information is acquired from the third-party authentication server and the process proceeds to step S107. As the information to be acquired, one or a plurality of TCP2 IDs, user IDs, passwords, biometrics information, device specific information, LAN connection device information, etc., can be used. Even if the own computer already holds the acquisition information from the server, it is necessary to perform the acquisition operation again when the expiration date or the effective use count is exceeded.

  Next, it is determined whether or not the partner information is a correct partner, that is, whether or not the partner information is permitted to access his / her computer (step S107). If the partner to be connected is the correct partner, the TCPsec passive connection is completed (step S108). If the partner is not the correct partner, the TCPsec is forcibly disconnected and the connection is stopped (step S103).

Next, detailed processing when the TCPsec active connection processing is started in step S88 of FIG. 11 will be described based on the flowchart of FIG.
As in the case of the passive connection process in FIG. 13, first, it is determined whether or not the other party who has requested the connection is the right party, that is, whether or not the communication is from the other party having access authority to the own computer ( Step S109). If the communication is from a partner who does not have a valid access authority, the TCPsec active connection is forcibly disconnected and the process ends (step S110).

If it is determined in the determination step S109 that it is the correct partner, a positive connection response (ACK) is transmitted from the transmission side host to the reception side host B (step S111).
Next, it is determined whether or not the own computer has information on the other party (step S112). If the partner information is not in the computer, the partner information is acquired from the installation server used when installing this system, that is, TCP2 (step S113). Alternatively, the partner information is acquired from the third-party authentication server, and the process proceeds to step S114. Here, the information to be acquired is one of TCP2 ID, user ID, password, biometrics information, device specific information, LAN connection device information, etc. on the other side, as in step S106 in FIG. There can be multiple. Even if the own computer already holds the acquisition information from the server, it is necessary to perform the acquisition operation again if the expiration date or the number of effective uses has been exceeded.

  Next, it is determined whether or not the partner information is a correct partner, that is, whether or not the partner information is permitted to access the computer (step S114). If the partner to be connected is the correct partner, the TCPsec active connection is completed (step S115). If the partner is not the correct partner, the TCPsec is forcibly disconnected and the connection is stopped (step S110).

In the foregoing, the passive open and active open communication processing using TCP / TCPsec of TCP2 of the present invention has been described.
Next, a communication system and a communication method using UDP / UDPsec which is the second embodiment of the present invention as shown in FIG. 3 will be described.

FIG. 15 is a flowchart for explaining the UDP / UDPsec passive open processing used in the second embodiment of the present invention.
This process is started by the upper application program (step 120). First, analysis of the port number to be opened, that is, the definition state of the port number is confirmed (step 121). Next, it is determined whether or not this port number is UDPsec open (step S122). If UDPsec is not open, it is determined whether UDP is open (step 123). If neither UDPsec nor UDP is permitted to be opened, UDP / UDPsec ends (step S126). If it is determined in step S123 that UDP is open-permitted, that is, UDPsec is not open-permitted but UDP is open-permitted, the UDP open process shown in FIG. 18 is performed (step S124). In addition, when UDPsec is open in the determination step S122, regardless of whether UDP is open or not, UDPsec open processing is performed (step S125), and the UDP / UDPsec open processing ends (step S125). S126). Even if the upper application is open by UDP, it is possible to communicate by UDPsec or UDP according to the determination of TCP2.

Next, sequence processing in unicast communication using UDP / UDPsec, which is one of the second embodiments of the present invention, will be described with reference to FIG.
FIG. 16 is a diagram illustrating a unicast communication start sequence, a data communication sequence packet (consisting of a header and a payload), and a flow thereof in standard UDP and UDPsec in TCP2 of the present invention. .

FIG. 16A shows a communication sequence using standard UDP, and FIG. 16B shows a sequence of encrypted communication using UDPsec.
The standard UDP in FIG. 16A shows an example in which the application is UDP open for both the host A and the host B. When the host B application opens UDP, a UDP open process (see step S124 in FIG. 15 and FIG. 18) is started. Similarly, when the host A application opens UDP, the above UDP open processing is started. This makes it possible to perform UDP data communication. Here, in the unicast communication shown in FIG. 16A, data can be transmitted from either the host A or the host B.

Next, a communication processing sequence by UDPsec, which is one of the TCP2 encryption methods of the present invention, will be described.
FIG. 16B shows an example in which encrypted communication is performed using UDPsec of TCP2 of the present invention. In this example, it is determined that both the host A and the host B are open for UDP and TCP2 is open for UDPsec. It is a case.
When the host B opens UDPsec, a UDPsec open process (see step S125 in FIG. 15 and FIG. 19) is started. Similarly, when the host A opens UDPsec, the UDPsec open processing is started. Then, UDPsec data communication can be realized.

  In the unicast communication using UDPsec shown in FIG. 16B, data can be transmitted from either the host A side or the host B side as in the case of UDP. In the case of FIG. 16B, the description will be given first assuming that there is a UDP data transmission request from the host A application. When receiving a UDP data transmission request from the application, the host B starts a UDPsec unicast reception start process and starts negotiation. If negotiation is performed and the other party is the correct party, the negotiation is completed, and a UDP data transmission request is transmitted from the application as UDPsec data (encrypted data). In this UDPsec unicast communication, ACK (acknowledgment) is not returned from the data receiving side. For this reason, although there is no function for confirming delivery and guaranteeing data, the communication of the data is increased accordingly, which is suitable for communication of large-capacity image data.

FIG. 17 is a diagram for explaining a broadcast communication start sequence, a data communication sequence packet (consisting of a header and a payload), and a flow thereof using standard UDP and UDPsec, which is the TCP2 encryption method of the present invention. is there.
17A is a sequence diagram of communication by standard UDP, and FIG. 17B is a sequence diagram of communication by UDP2 of TCP2 of the present invention.

  In the standard UDP of FIG. 17A, both the host A and the host B have UDP open applications. When the host B application opens UDP, a UDP open process (see step S124 in FIG. 15 and FIG. 18) is started. Also, when the host A application opens UDP, the UDP open process is similarly started. As a result, the UDP data communication can be performed.

  In addition, although data can be generated by either host A or host B, in FIG. 17 (a), data flows in one direction from the host A side to the host B side due to broadcast communication. It is said. Since ACK (acknowledgment) is not returned from the host B side that received the data, it does not have a function of confirming delivery and guaranteeing the data. When broadcasting data, it is possible to broadcast data by setting the subnet address of the IP address to all 1.

Next, encrypted communication by UDPsec in FIG. 17B will be described. Also in this case, both the host A and the host B are open for UDP, and TCP2 is open for UDPsec.
When the host B opens UDPsec, the UDPsec open process (step S125 in FIG. 15 and FIG. 19) is started. Similarly, even if the host A opens UDPsec, the UDPsec open process is started. As a result, the UDPsec data communication can be performed.

  As shown in FIG. 17B, a case will be described where there is a transmission request for UDP broadcast data (data whose IP address indicates broadcast) from the application of the host A. When a UDP broadcast data transmission request is received from an application, it is delivered to an unspecified host as encrypted data by UDPsec without being negotiated. When the host B receives the broadcast data, the host B starts a UDPsec broadcast reception start process in step S141 in FIG. Negotiation is started between the host A and the host B. If the other party is the correct party, the negotiation is completed, and the broadcast data is decoded and sent to the application. At this time, since an ACK (acknowledgment) is not returned from the data receiving side, there is no function for confirming delivery and guaranteeing data.

Next, the standard UDP open process in step S124 of FIG. 15 will be described with reference to FIG.
FIG. 18 is a flowchart of the UDP open process. This process is started when it is determined in step S124 in FIG. 15 that the protocol to be processed is UDP.

  First, it waits for a transmission request or a received packet from the application, and when a transmission request or packet is received, the packet is analyzed (step S127). Here, the reason why the transmission request as well as the received packet is analyzed is to prevent the host A from being transmitted to an unspecified number of persons as the perpetrator by using the host A platform transmitted by a malicious third party. . After analyzing the transmitted / received packet, it is determined whether the packet is a correct packet, that is, whether the packet is not a UDP protocol attack pattern in a DoS attack (step S128). If it is determined in this determination step S128 that the packet is an illegal packet, the packet is discarded (step S129), and the next packet is awaited.

  If it is determined in step S128 that the packet is correct, UDP data transmission / reception processing is performed (step S130), and it is then determined whether a UDP close request has been received from the higher-level application (step S131). If there is a UDP close request from the host application, the UDP open process is terminated (step S132).

  Next, the UDPsec open process in step S125 of FIG. 15 will be described with reference to FIG. FIG. 19 is a flowchart of processing in opening UDPsec, and this processing is started when the protocol to be processed is determined to be UDPsec as shown in step S125 of FIG.

  First, the transmission request or received packet from the application is waited for, and the transmission request or received packet is analyzed (step S133). Next, it is determined whether or not the transmission request or transmission / reception packet from the upper application is a correct UDP packet, that is, whether or not it is a TCP protocol attack pattern in the DoS attack (step S134). If it is determined in step S134 that the packet is not a correct UDP packet, the packet is discarded (step S135), and the next packet is awaited.

  If it is determined in the determination step S134 that the packet is a correct UDP packet, it is then determined whether or not the received packet has undergone a UDPsec negotiation (step S136).

As a result, if it is determined that the packet is a UDPsec negotiation packet, a UDPsec unicast reception start process shown in FIG. 23 described later is performed (step S137), and the process proceeds to step S147.
If it is determined in the determination step S136 that the packet is not a UDPsec negotiation packet, it is subsequently determined whether the communication is broadcast communication (step S138). If it is determined that the communication is broadcast communication, it is determined whether it is a communication start packet, that is, the first communication packet after opening (step S139). The UDPsec data transmission / reception process to be described is performed (step S144). If it is determined in the determination step S139 that it is a communication start packet, it is next determined whether or not it is a transmission packet (step S140). As a result, if it is a transmission packet, the above-described UDPsec data transmission / reception process is performed (step S144). If it is determined that the packet is not a transmission packet, a UDPsec broadcast reception start process of FIG. 20 described later is performed. (Step S141). After this reception start process, it is determined whether or not the transmitted packet is from the correct partner (step S142). If it is determined in decision step S142 that the transmitted packet is not from the correct partner, the packet is discarded (step S143) and the next packet is awaited. If it is determined in the determination step S142 that the partner is the correct partner, the UDPsec data transmission / reception process shown in FIG. 22 is performed (step S144).

  If it is determined in the determination step S138 that the communication is not broadcast communication, that is, unicast communication, it is determined whether or not it is a communication start packet, that is, the first communication packet after opening (step S145). . As a result, when it is determined that the packet is not a start packet, the UDPsec data transmission / reception process detailed in FIG. 22 is performed (step S144).

  If it is determined in the determination step S145 that the communication packet is the first communication packet after opening, a UDPsec unicast transmission start process described later with reference to FIG. 21 is performed (step S146). Thereafter, it is determined whether the communication partner is the correct partner (step S147). If the communication partner is the correct partner, the UDPsec data transmission / reception process is continued (step S144). Discards the received packet (step S148), returns to step S133, and waits for the next packet.

Next, processing at the start of UDPsec broadcast reception in step S141 in FIG. 19 will be described based on the flowchart shown in FIG.
First, it is determined whether or not the own computer holds information on the partner to whom the broadcast has been distributed (step S149). If the information is not held, the partner information is acquired from the installation server used when installing the system (step S150). Alternatively, information is acquired from a third-party authentication server. As the information to be acquired, one or more of the other party's TCP2 ID, user ID, password, biometrics information, device specific information, LAN connection device information, and the like are used. Next, it is determined whether or not the partner to whom the broadcast has been distributed is the correct partner (step S151). If it is determined that the communication partner is correct, UDPsec reception is possible, the UDPsec broadcast communication start processing is terminated (step S153), and reception is possible (step S142 in FIG. 19). Instruct. If it is determined in the determination step S151 that the partner is not a correct partner, the communication is rejected (step S152), and an instruction is given to the step S142 in FIG. Even if there is acquisition information about the other party in step S149, if the expiration date or the number of effective uses is exceeded, it is better to perform the other party information acquisition operation in step S150.

Next, the UDPsec unicast transmission start process in step S146 of FIG. 19 will be described based on the flowchart shown in FIG.
First, it is confirmed whether or not the own computer holds the information of the other party to be transmitted (step S154). If the information is not held, the partner information is acquired by the same method as step S150 in FIG. 20 (step S155). This acquired information is also the same as in the case of FIG.

  Next, it is determined whether or not the transmission partner is a correct partner (step S156). If it is determined that the communication partner is correct, UDPsec transmission is possible, and the UDPsec unicast communication start process is terminated (step S158), indicating that transmission is possible, step S147 in FIG. To instruct. If it is determined in the determination step S156 that the partner is not correct, the communication is rejected (step S157), and an instruction is given to the step S147 in FIG. 19 that data is not acquired.

Next, UDPsec data transmission / reception processing shown in step S144 of FIG. 19 will be described with reference to FIG.
First, it is determined whether or not there is a transmission request from the application of the host A (step S159). If there is a transmission request, the data is encrypted at the sending host A (step S160), the authentication data is added to the encrypted data (step S161), and the encrypted data is added to the receiving host B. A packet is transmitted (step S162).

  Next, the receiving host B determines whether or not there is received data (step S163). If there is received data, the received data is decoded (step S164). Next, it is determined whether the received and decoded data is correct data (step S165). This determination is made by confirming the decrypted data and the received authentication data. If it is determined that the decrypted data is not correct, the UDP / UDPsec is forcibly disconnected. (Step S166). If it is determined in the determination step S165 that the decrypted data is correct data, the received data is fetched, that is, the data is delivered to the upper protocol stack (step S167), and the UDPsec data transmission / reception process is performed. Completion (step S168).

Next, the UDPsec unicast reception start process shown in step S137 of FIG. 19 will be described based on the flowchart of FIG.
First, it is determined whether or not the own computer holds the partner information of the packet received by unicast (step S169). If it does not have the partner information, the partner information is acquired from the installation server or third-party authentication server used when installing this system (step S170). The information to be acquired is the same as step S150 in FIG. 20 or step S155 in FIG. 21, and includes 1 of the other party's TCP2 ID, user ID, password, biometrics information, device specific information, LAN connection device information, etc. One or more correspond to this.

  Next, it is determined whether or not the partner that has transmitted the unicast is the correct partner (step S171). If it is determined that it is a correct partner, it is notified to the step S147 in FIG. 19 that reception by UDPsec is possible, and the UDPsec broadcast communication start process is ended (step S173). If it is determined in the determination step S171 that the partner is not a correct partner, the fact that data is not acquired is notified to the step S147 in FIG. 19 and communication is rejected (step S172).

  The encryption processing using TCPsec according to the first embodiment of the present invention and the encryption processing using UDPsec according to the second embodiment of the present invention have been described in detail above based on the flowcharts and sequence diagrams.

  Next, how the TCP2 of the present invention is superior to the conventional IPsec or SSL will be described based on 24. FIG.

  It was difficult to handle with SSL, client-client communication, DoS attack on TCP / IP protocol, secure communication of all UDP ports or TCP ports, and applications that had to change socket programs TCP2 is fully compatible with restrictions and the like.

Also, it is difficult to cope with IPsec, communication in a poor environment with frequent errors, communication between different LANs, connection via multiple carriers, communication in PPP mobile environment, ADSL environment TCP2 is fully supported.
Furthermore, according to TCP2 of the present invention, it is possible to cope with the Internet using VoIP (Voice over Internet Protocol) in a mobile environment or an ADSL environment.

  Also, Internet telephones using VoIP between different LANs or between LANs spanning multiple carriers could not be handled by IPsec and SSL. However, according to TCP2 of the present invention, it can be completely supported. Can do.

  FIG. 24 is a diagram for explaining the superiority of TCP2, but a case (b) in which conventional SSL is applied to a protocol stack (a) without security, a case (c) in which IPsec is applied, A case (d) in which TCP2 (TCPsec / UDPsec) of the present invention is applied is shown in comparison. As described above, the SSL in FIG. 24B is provided in the socket of the session layer (fifth layer), so that it is not compatible with the upper application. For this reason, SSL itself has the above-mentioned problems. In addition, since IPsec in FIG. 24C is in the network layer (third layer) and is not compatible with the IP layer, it is subject to various restrictions as described above in configuring the network. On the other hand, TCP2 (TCPsec / UDPsec) in FIG. 24 (d) is an encryption technology introduced into the transport layer (fourth layer), and therefore, the socket can be used as it is from the viewpoint of the application. Also, when viewed from the network, the IP can be used as it is, so there are no restrictions on configuring the network.

As described above, the encrypted communication system and the encrypted communication method using the TCP2 according to the present invention are extremely resistant to data leakage, falsification, impersonation, entry, and attack even compared to the existing encryption processing system. It has a high security function.
The present invention is not limited to the embodiments described above, and it goes without saying that the present invention includes more embodiments without departing from the gist of the present invention described in the claims.

It is a figure which shows the protocol stack of TCP2 used for the communication system of this invention. 1 is an overall configuration diagram of a system in a first embodiment (EC application using TCPsec) of a communication system using TCP2 of the present invention. It is a whole block diagram of the system in 2nd Embodiment (broadcast application by UDPsec) of the communication system using TCP2 of this invention. It is a figure which shows the packet structure of the three protocol stacks in TCP2 of this invention, its encryption range, and an authentication range. (A), (b), (c) is a figure which shows the packet structure of TCPsec / IPsec, TCPsec / IP, UDPsec / IP, each encryption range, and the application range of integrity authentication, respectively. It is a flowchart which shows the process of the TCP / TCPsec passive open which is embodiment of TCP2 of this invention. It is a flowchart which shows the process of the TCP / TCPsec active open which is embodiment of TCP2 of this invention. It is a sequence diagram which shows the exchange of communication between host A (active open) and host B (passive open) of standard TCP and TCPsec of the present invention. 6 is a flowchart showing details of TCP passive open processing S5 of FIG. 5. It is a flowchart which shows the detail of the TCPsec passive open process S6 of FIG. It is a flowchart which shows the detail of TCP active open process S12 of FIG. It is a flowchart which shows the detail of the TCPsec active open process S13 of FIG. 12 is a flowchart showing details of TCPsec transmission / reception processing S37 in FIG. 9 and TCPsec transmission / reception processing S76 in FIG. 10 is a flowchart showing details of the TCPsec passive connection processing S48 of FIG. 12 is a flowchart showing details of TCPsec active connection processing S88 of FIG. It is a flowchart which shows the process of UDP / UDPsec open which is embodiment of TCP2 of this invention. It is a sequence diagram of UDP / UDPsec unicast communication using TCP2 of the present invention. It is a sequence diagram of UDP / UDPsec broadcast communication using TCP2 of the present invention. It is a flowchart which shows the detail of UDP open process S124 of FIG. It is a flowchart which shows the detail of UDPsec open process S125 of FIG. It is a flowchart which shows the detail of UDPsec broadcast reception start process S141 of FIG. It is a flowchart which shows the detail of UDPsec unicast transmission start process S146 of FIG. It is a flowchart which shows the detail of UDPsec data transmission / reception process S144 of FIG. It is a flowchart which shows the detail of UDPsec unicast reception start process S137 of FIG. It is a figure for demonstrating the advantage compared with the case where the conventional IPsec or SSL is applied to TCP2 of this invention.

Explanation of symbols

1 ... Host computer
2. Network control device (router)
3a, 3b, 3c ... client terminal 4a, 4b, 4c ... client terminal 11 ... NIC driver 12 ... ARP or ARP on CP
13 ... IP emulator 13b ... IPsec on CP
15 ... TCP emulator 15b ... TCPsec on CP
16: UDP emulator 16b: UDPsec on CP
17 ... Socket
41 ... IP header 42 ... ESP header 43 ... TCP header 44 ... TCPsec additional information 45 ... data (payload)
46 ... TCPsec additional trailer 47 ... TCPsec additional authentication data 48 ... ESP trailer 49 ... ESP authentication data

Claims (1)

An encryption communication system for performing communication between a plurality of hosts by adding an encryption function to a TCP or UDP protocol located in a transport layer,
A connection sequence means for making a connection with the communication partner after determining whether the communication partner is a communication partner having a legitimate authority;
Arranging means for negotiating corresponding encryption and decryption logic at both ends of the communication path;
Protocol encryption means for encrypting and transmitting packets of information to be transmitted and received between the plurality of hosts according to the encryption logic decided by the agreement means;
Protocol decoding means for decoding packets of information transmitted and received between the plurality of hosts according to the decoding logic decided by the agreement means;
The connection sequence means transmits a connection request from the first host to the second host and a connection response from the second host to the first host so that it can cope with a network environment that excludes unknown options. In addition, a flag is added to the TCP connection header, TCP2-specific information or emergency data is added to the payload, and a key necessary for encrypted communication is exchanged between the first host and the second host. , Exchange encrypted negotiation data to confirm that the other host has authority to perform the encrypted communication,
The agreement means only performs communication based on the encryption and decryption logic using the TCP or UDP protocol of the transport layer only with a communication partner that is determined that the connection sequence means has a legitimate authority. Done
The protocol encryption means encrypts and transmits the payload of the TCP or UDP protocol among the packets of information to be transmitted and received,
The encryption communication system, wherein the protocol decryption means decrypts the payload of the encrypted protocol in the packet of information to be transmitted / received.

Images