JP2014116641A - Communication device and communication system - Google Patents

Abstract

There are servers that prioritize cipher suites on the server side without following the SSL / TLS encryption communication specifications.
A communication device according to the present invention includes an encryption method acquisition unit that acquires first information of an encryption method that can be used by the other communication device, and the plurality of encryption methods based on the first information. An encryption method selection unit that selects an encryption method to be used in communication with the other communication device, and a transmission unit that transmits the encryption method selected by the encryption method selection unit to the other communication device. .
[Selection] Figure 1

Description

  The present invention relates to SSL (Secure Socket Layer) / TLS (Transport Layer Security) encryption communication, and more particularly to a handshake of SSL / TLS communication, for example, a method for determining an encryption suite used in SSL / TLS communication. Applied.

  Conventionally, there is SSL / TLS encryption communication as one method for performing communication safely. SSL / TLS encryption communication has a feature that it can be set very easily even though it is strong encryption communication. Because of this convenience, SSL / TLS encryption communication has been rapidly spreading in recent years, and it is becoming common for inexpensive embedded devices.

  However, an inexpensive embedded device has a weaker CPU than a general personal computer and is not suitable for executing heavy-duty cryptographic processing. Therefore, many inexpensive embedded devices select a cipher suite with good performance when executing SSL / TLS cipher communication. If you run a heavy cipher suite on a vulnerable embedded device, you might seriously lose convenience.

  In communications that require a security level such as authentication, it is necessary to select a cipher suite that emphasizes safety rather than performance, but even in such a case, cipher suites with heavy loads are limitedly used. Is desirable.

  Further, from the viewpoint of performance, many inexpensive embedded devices often have only a client function for SSL / TLS encryption communication.

  One of the reasons is the public key cryptosystem of SSL / TLS cipher communication. A public key encryption method used in SSL / TLS encryption communication is generally RSA (Rivest Shamir Adleman) encryption. With RSA encryption, the processing on the client side is very light compared to the server.

  Another reason is the specification of SSL / TLS encryption communication (see Non-Patent Documents 1, 2, and 3). The cipher suites used between the client and the server are selected by the server from the cipher suites presented by the client. It is possible to present its own priority, and the server selects a cipher suite that has the highest priority. In other words, prioritization of cipher suites to be used is performed at the client.

  According to this specification, a client, that is, an inexpensive embedded device can use a cipher suite that is light in processing.

T. T. et al. Dierks, C.I. Allen, “The TLS Protocol Version 1.0”, RFC 2246, [online], January 1999, [March 29, 2011 search], Internet <http://www.ietf.org/rfc/rfc2246 .txt> T. T. et al. Dierks, E.I. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1”, RFC 4346, [online], April 2006, [March 29, 2011 Search], Internet <http: //www.ietf. org / rfc / rfc4346.txt> T. T. et al. Dierks, E.I. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, [online], August 2008, [March 29, 2011 Search], Internet <http: //www.ietf. org / rfc / rfc5246.txt>

  However, some of the servers support the cipher suites with high priority presented by the client, but ignore the priorities, and the cipher suites desired by the server from the presented cipher suites. There is something to choose. In other words, there are servers that prioritize cipher suites on the server side without following the SSL / TLS encryption communication specifications.

  The present invention has been devised to solve such problems of the prior art. The main purpose of the present invention is to provide an inexpensive embedded device operating as a client for SSL / TLS encryption communication. The purpose is to give the right to prioritize cipher suites according to the specifications of SSL / TLS encryption communication (see Non-Patent Documents 1, 2, and 3). This makes it possible to use SSL encryption communication with good performance even with an inexpensive embedded device.

  In order to solve the above-described problem, a communication device of the present invention is a communication device that performs encryption communication with another communication device using an encryption method selected from a plurality of encryption methods. Used in communication between the plurality of encryption schemes and the other communication devices based on the first information, and an encryption scheme acquisition unit that acquires first information of encryption schemes that can be used by the communication apparatus. It is configured to include an encryption method selection unit that selects an encryption method, and a transmission unit that transmits the encryption method selected by the encryption method selection unit to the other communication device.

  Further, in the communication device according to the present invention, the encryption method acquisition unit transmits the encryption method selected from the plurality of encryption methods to the other communication device, and based on a response result of the other communication device, the first method It was configured to acquire the information.

  The communication device of the present invention further includes priority information of the plurality of encryption methods in communication with the other communication device, and the encryption method acquisition unit is configured to use the plurality of encryption methods based on the priority information. The encryption method selected from the methods is configured to be transmitted to the other communication device.

  Also, the communication device of the present invention is configured such that the priority information is different depending on other communication devices.

  Further, the communication device of the present invention is configured such that the encryption method acquisition unit acquires second information of an encryption method that cannot be used by the other communication device based on the response result.

  In the communication device of the present invention, the encryption method acquisition unit transmits a plurality of encryption methods selected from the plurality of encryption methods to the other communication device, and based on a response result of the other communication device, It comprised so that 1st information might be acquired.

  The communication system of the present invention is a communication system including a first communication device and a second communication device, and the first communication device can use a plurality of encryption methods. An encryption method is transmitted to the second communication device, and the second communication device transmits information on the availability of the encryption method transmitted from the first communication device to the first communication device. Configured.

  Further, in the communication system of the present invention, the first communication device communicates with the second communication device from the plurality of encryption schemes based on the usability information transmitted from the second communication device. It was configured to select the encryption method used for communication between the two.

  Further, in the communication system of the present invention, the first communication device has priority information of the plurality of encryption methods in the second communication device, and the plurality of encryption methods are based on the priority information. The selected encryption method is configured to be transmitted to the second communication device.

  In addition, the communication system of the present invention further includes a third communication device capable of communicating with the first communication device, and the first communication device includes the plurality of encryption schemes in the third communication device. It was configured to have priority information.

  In the communication system of the present invention, the first communication device transmits a plurality of encryption methods selected from the plurality of encryption methods to the second communication device, and the second communication device includes the first communication device. The information indicating whether or not each encryption method is transmitted, which is transmitted from one communication device, is transmitted to the first communication device.

  The communication device of the present invention is a client that selects a cipher suite to be used in accordance with cipher suite priority information in the client, and the client includes cipher suite examining means for investigating the installation status of the server's cipher suite. The client uses the cipher suite checking means to acquire the cipher suite mounting information in the server at least once in advance, and the acquired cipher suite is selected in the cipher suite used in SSL / TLS cipher communication. It was configured to specify the optimal cipher suite using the on-board information of the suite.

  Here, the cipher suite investigation means may, for example, acquire the installation information investigated by another computer from the computer, or investigate the target server by itself to acquire the installation information. It may be a thing.

  According to this, even if it is a server that prioritizes the cipher suites used by the other party, it becomes possible to prioritize the cipher suites that are used by the client, and the client of an inexpensive embedded device However, SSL encryption communication can be used with good performance.

  The communication device of the present invention is a client that selects a cipher suite to be used in accordance with cipher suite priority information in the client, and the client includes cipher suite examining means for investigating the installation status of the server's cipher suite. The client uses the cipher suite checking means to acquire the cipher suite mounting information in the server at least once in advance, and in selecting a cipher suite to be used in SSL / TLS cipher communication, the client From the cipher suite installation information in the server and the cipher suite priority information in the client, the cipher suite having the highest priority for the client that can be used in the server is selected, and SSL / TLS negotiation (SSL / TLS) is selected. C In specifying a cipher suite to be used by the client for the server, the cipher suite having at least the cipher suite selected by the client and having a higher priority in the server than the selected cipher suite. It was configured to specify a cipher suite that does not contain.

  According to this, even if it is a server that prioritizes the cipher suites used by the other party, it becomes possible to prioritize the cipher suites that are used by the client, and the client of an inexpensive embedded device However, SSL encryption communication can be used with good performance.

  In the communication device of the present invention, the cipher suite investigating unit designates the cipher suite to be investigated, performs SSL / TLS negotiation (SSL / TLS handshake), and obtains the response result of the server, thereby specifying the cipher suite. It is configured to determine whether or not the encrypted cipher suite is installed in the server.

  According to this, the client can easily and quickly obtain the cipher suite installation information in the server.

  Further, the communication device of the present invention is configured such that the cipher suite examining means investigates a cipher suite not mounted on the client.

  According to this, for clients that can add cipher suites, check the installation status on the server, including the cipher suites added in advance, and save the installation information. And quick processing becomes possible.

  Further, the communication apparatus of the present invention is configured such that the cipher suite examining means investigates only the cipher suite installed in the client.

  According to this, it is possible to quickly investigate the installation status of the cipher suite in the server. For clients that do not add or rarely add cipher suites, it is preferable to reduce the initial installation status investigation time rather than considering re-investigation when adding cipher suites.

  Further, in the communication device of the present invention, the cipher suite investigating means investigates the installation status of the cipher suites in the server in the order of priority of cipher suites in the client, and the server returns an alert or investigates Until there is no cipher suite to be used, the configuration of the cipher suite installed in the server is examined.

  According to this, since it is investigated whether or not the server is installed with respect to the cipher suites installed on the client, if this installation information is saved, when the cipher suite prioritization changes on the client side , Eliminating the need for re-investigation. The effect is large when the cipher suite prioritization in the client is set as a user setting and the cipher suite prioritization is frequently changed.

  In the communication apparatus of the present invention, the client performs SSL / TLS negotiation (SSL / TLS handshake) by simultaneously specifying a plurality of cipher suites to be investigated, and obtains a response result of the server. It is determined whether or not at least one specified cipher suite is installed in the server, and if the response result is a cipher suite designation from the server, the cipher suite is designated first. One or more cipher suites obtained by removing the cipher suite designated by the server from a plurality of cipher suites are designated, SSL / TLS negotiation (SSL / TLS handshake) is performed again, and the response result of the server is determined. Whether at least one of the newly specified cipher suites is installed on the server It was configured to perform the Kano judgment.

  According to this, when investigating whether or not a server is installed with respect to a cipher suite installed on a client, the investigation time can be shortened.

  When investigating whether or not each server installs cipher suites installed on the client, it is necessary to investigate the number of cipher suites, which takes time. On the other hand, in this method, while the client is presenting at least one cipher suite that is installed in the server, there is no change in the time and effort when investigating one by one. If multiple cipher suites that are not to be presented are presented, only one survey is required, saving time.

  In this method, if the server is a server that prioritizes cipher suites, the cipher suites are prioritized by looking at the cipher suite order selected by the server as well as the cipher suites installed on the server. It is possible to know.

  Further, the communication device of the present invention is configured such that the cipher suite examining means also investigates the priority order of cipher suites in the server.

  According to this, if the cipher suite prioritization in the server and the cipher suite prioritization in the client are the same, the client can execute the SSL / TLS negotiation in a normal manner. In the case of a device that cannot store installation information on the client, it is not necessary to investigate the installation status of the cipher suite in the server each time. That is, the SSL / TLS negotiation process may be speeded up.

  In the communication apparatus of the present invention, the cipher suite checking means prepares a plurality of TCP ports, specifies the cipher suite to be checked in each port, and performs SSL / TLS negotiation (SSL / TLS handshake). ).

  According to this, the client can quickly investigate the installation status of the cipher suite in the server. When investigating using the same TCP port, it is necessary to wait for the server's response once, but if this method is used, it is not necessary.

  Further, the communication device of the present invention is configured such that the cipher suite examining means investigates using a TCP port different from the TCP port used in SSL / TLS encrypted communication.

  According to this, when SSL / TLS encryption communication is performed, an application that is the main body that performs SSL / TLS encryption communication and an SSL / TLS encryption module that realizes SSL / TLS encryption communication are separated and implemented. The SSL / TLS cryptographic module does not use the TCP port specified for the SSL / TLS cryptographic module as an application to use for SSL / TLS cryptographic communication, but uses another TCP port to check the installation status of the cipher suite in the server. Can investigate.

  Although the TCP port used for the survey may be closed, if this method is used, the TCP port specified in the SSL / TLS cryptographic module by the application to be used for SSL / TLS cryptographic communication is not used for the survey. I can't close it. This makes it very easy to create an application.

  Further, in the communication apparatus of the present invention, the client includes mounting status storage means for storing and reading cipher suite mounting information in the server, and the client uses the mounting status storage means to The cipher suite mounting information in the server is stored, and in SSL / TLS cipher communication, the stored cipher suite mounting information in the server is read using the mounting status storage means.

  According to this, since it is not necessary to re-execute the cipher suite installation status check in the server, SSL / TLS negotiation can be performed quickly.

  Also, the communication device of the present invention is configured to store the encryption sweet mounting information in the server and the encryption sweet priority information in the client separately.

  This makes it possible to reduce the storage capacity and simplify the storage method when the cipher suite prioritization in the client differs depending on the server to be connected and the communication purpose.

  In addition, the communication device of the present invention is configured to store together the cipher suite mounting information in the server and the cipher suite priority information in the client.

  According to this, the storage capacity can be reduced when the server to be connected is determined.

  Further, the communication device of the present invention is the client in which priorities of cipher suites to be used differ depending on the convenience of the client, such as communication contents and client load status, and the client is performing SSL / TLS encryption communication. When the communication content is changed, the SSL / TLS renegotiation is performed.

  According to this, even if it is a server that prioritizes the cipher suites used by the other party, the client can lead the cipher suite selection in accordance with the communication purpose and the client load status.

  For example, the client can select a ciphersuite with high security for authentication, and can select a ciphersuite with good performance when passing a large amount of data with a high load.

  The communication apparatus of the present invention is the client that communicates with a plurality of servers, and is configured to change the priority information of the cipher suites to be used in accordance with the server that communicates.

  According to this, it is possible to communicate with various types of servers by selecting a cipher suite led by a client.

  The communication device of the present invention further comprises priority changing means that allows a user to change the priority information of the cipher suite in the client, and the priority information of the cipher suite in the client is obtained using the priority change means. Configured to change.

  According to this, a user's security policy and view can be reflected in SSL / TLS encryption communication.

  In addition, the communication apparatus of the present invention includes a survey determination unit that determines whether the client investigates the cipher suite installation information in the server, and the client uses the survey determination unit to It is configured to determine whether or not to check the information on the cipher suites installed.

  According to this, it is necessary for the client to investigate the installation status of the cipher suite on the server, even for servers that do not prioritize cipher suites or servers that have prioritized cipher suites but have little impact on the client. You can save time and effort.

  In the communication apparatus according to the present invention, the investigation determination unit performs SSL / TLS negotiation (SSL / TLS handshake) in which at least two or more cipher suites installed in the server are simultaneously specified, and the server performs Client Hello. The server determines whether the cipher suite is prioritized based on whether the cipher suite described at the top is selected or not, and the server does not select the cipher suite described at the top in Client Hello. In such a case, the server is configured not to prioritize cipher suites.

  According to this, it becomes possible to automatically investigate whether or not the server is prioritizing cipher suites.

  In the communication apparatus according to the present invention, the investigation / determination means selects one cipher suite from at least two cipher suites supported by the server, and uses this as a description cipher suite at the top in Client Hello to perform SSL / TLS negotiation. (SSL / TLS handshake), then another cipher suite is selected, this is the description cipher suite at the top in Client Hello, and SSL / TLS negotiation (SSL / TLS handshake) is performed to Is configured to determine whether or not the cipher suite is prioritized.

  According to this, the client can automatically investigate whether or not the cipher suites are prioritized reliably and quickly.

  According to the present invention, the load of a communication device can be distributed to other communication devices. That is, the load on the communication device can be reduced.

The sequence diagram which shows the 1st example of SSL / TLS encryption communication in embodiment of this invention The sequence figure which shows the 1st example of the method "investigating the installation situation of the encryption sweet which a server supports" in embodiment of this invention The figure which shows the 1st example of the functional block in embodiment of this invention The figure which shows the 1st example of the flowchart by the side of the client in embodiment of this invention The figure which shows the 1st example of the flowchart by the side of the server in embodiment of this invention The figure which shows the 1st example of the hardware constitutions in embodiment of this invention The sequence diagram which shows the 2nd example of the method "investigating the installation situation of the encryption sweet which a server supports" in embodiment of this invention The sequence diagram which shows the 3rd example of the method "investigating the installation situation of the encryption sweet which a server supports" in embodiment of this invention The figure which shows the 2nd example of the functional block in embodiment of this invention The figure which shows the 2nd example of the flowchart by the side of the client in embodiment of this invention The figure which shows the 2nd example of the flowchart by the side of the server in embodiment of this invention The figure which shows the 2nd example of the hardware constitutions in embodiment of this invention The sequence diagram which shows the 2nd example of SSL / TLS encryption communication in embodiment of this invention The sequence diagram which shows the 4th example of the method "investigating the installation situation of the encryption sweet which a server supports" in embodiment of this invention The figure which shows the 3rd example of the functional block in embodiment of this invention The figure which shows the 3rd example of the flowchart by the side of the client in embodiment of this invention The sequence diagram which shows the 3rd example of SSL / TLS encryption communication in embodiment of this invention The sequence diagram which shows the 5th example of the method "investigating the installation situation of the encryption sweet which a server supports" in embodiment of this invention The figure which shows the 4th example of the functional block in embodiment of this invention The figure which shows the 4th example of the flowchart by the side of the client in embodiment of this invention The sequence diagram which shows the 4th example of SSL / TLS encryption communication in embodiment of this invention The sequence diagram which shows the 6th example of the method "investigating the installation situation of the encryption sweet which a server supports" in embodiment of this invention The figure which shows the 5th example of the functional block in embodiment of this invention The figure which shows the 5th example of the flowchart by the side of the client in embodiment of this invention. The figure which shows the 3rd example of the hardware constitutions in embodiment of this invention The sequence diagram which shows the 7th example of the method "investigating the installation situation of the encryption sweet which a server supports" in embodiment of this invention The sequence diagram which shows the 8th example of the method "investigating the installation situation of the encryption sweet which a server supports" in embodiment of this invention The sequence diagram which shows the 9th example of the method "investigating the installation situation of the encryption sweet which a server supports" in embodiment of this invention The sequence diagram which shows the 5th example of SSL / TLS encryption communication in embodiment of this invention The figure which shows the 6th example of the functional block in embodiment of this invention. The figure which shows one side of the 6th example of the flowchart by the side of the client in embodiment of this invention The figure which shows the other of the 6th example of the flowchart by the side of the client in embodiment of this invention The figure which shows the 3rd example of the flowchart by the side of the server in embodiment of this invention The figure which shows the 4th example of the hardware constitutions in embodiment of this invention The figure which shows the 1st example of the mounting method of mounting information in case there exist multiple servers to connect in embodiment of this invention The figure which shows the 2nd example of the mounting method of mounting information in case there exist multiple servers to connect in embodiment of this invention The figure which shows the 1st example of the mounting method of the "priority information of the cipher suite which a client supports" when there are a plurality of servers to connect in the embodiment of the present invention, and the priority differs for each server and for each purpose The figure which shows the 2nd example of the mounting method of the "priority information of the cipher suite which a client supports" in the case where there are a plurality of servers to be connected in the embodiment of the present invention and the priorities are different for each server and each purpose The figure which shows the 1st example of the method by which a user changes "priority information of the encryption sweet which a client supports" in embodiment of this invention The figure which shows the 1st example of the method in which the client in embodiment of this invention judges whether the mounting information of the encryption sweet in the said server is investigated. The figure which shows the 2nd example of the method in which the client in embodiment of this invention judges whether the mounting information of the encryption sweet in the said server is investigated. Sequence diagram showing a sixth example of SSL / TLS encryption communication in the embodiment of the present invention

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

In order to simplify the description, it is assumed that the client and the server each hold the following cipher suite. The cipher suite is, for example, an encryption algorithm and a compression algorithm, and includes a key exchange method, an encryption method, and the like. In an actual implementation, any cipher suite may be installed (that is, usable).
Client: TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
Server: TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
If there is no special explanation, it is assumed that the cipher suite prioritization in the client has the following settings. Again, any prioritization may be performed in actual implementation. The priority information may be stored in the server or the client, or may be stored in an external storage device or the like. When stored in an external storage device, the server or client may acquire priority order information via a network or the like. Alternatively, the priority order may be calculated each time by a control unit such as a CPU.
1: TLS_RSA_WITH_RC4_128_MD5
2: TLS_RSA_WITH_RC4_128_SHA
3: TLS_RSA_WITH_AES_128_CBC_SHA
4: TLS_RSA_WITH_AES_256_CBC_SHA
It is assumed that the priority is the highest and the priority is lower in the order of 2, 3, and 4. In order to simplify the description, there is no cipher suite having the same priority, but there may be a plurality of cipher suites having the same priority in an actual implementation.

  FIG. 1 is a sequence diagram showing an example of SSL / TLS encryption communication according to the present invention.

(FIG. 1- (S1)) The client investigates the installation status of cipher suites supported by the server (information on cipher suites that can be used), so that the following cipher suites supported by the client are stored in the server. Know that does not support.
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
(FIG. 1- (S2)) In selecting a cipher suite, the client tries to select a cipher suite having a higher priority among cipher suites held by the client. Next, the cipher suite with the highest priority is selected.

Since the cipher suites of the client priorities 1 and 2 correspond to the cipher suites, the client selects the cipher suite of the priority 3 described below.
TLS_RSA_WITH_AES_128_CBC_SHA
In all figures including this figure, the explanation is given in the case where there is only one cipher suite with the same priority. However, there are several cipher suites with the same priority in all figures including this figure. It doesn't matter. If there are a plurality of cipher suites of the same priority supported by the server, the cipher suite may be narrowed down to one as desired, or a plurality or all cipher suites may be selected. That is, in this embodiment, the selection here includes the case where all cipher suites are selected. When selecting a plurality of cipher suites, Client Hello specifying a plurality of cipher suites is transmitted. For the sake of simplicity, it is assumed here that there is only one cipher suite with the same priority.

  (FIG. 1- (S3)) The client designates the selected cipher suite and transmits Client Hello to the server. (4) Since the server holds the designated cipher suite, the server transmits Server Hello to the client using the designated cipher suite. Although not shown, SSL / TLS negotiation is correctly executed after this, and common key encryption communication in SSL / TLS encryption communication is started.

  Even if it is a server that prioritizes the cipher suites used by the other party, according to the present invention, there is an advantage that the client can lead the cipher suite selection in this way. Since a cipher suite with good performance can be selected on the client's initiative, this effect is significant especially in the case of an embedded device having a vulnerable CPU.

  In this example, the case where the client is one server is described. However, in the case where a plurality of servers are the partner, the “priority information of cipher suites supported by the client” differs for each server. It may be. For example, for financial servers such as banks and securities, higher priority is given to cipher suites that emphasize security, and for content servers such as Internet TV that receive large amounts of data, cipher suites that emphasize performance. It is recommended to make a setting such as increasing the priority of.

  FIG. 2 is a sequence diagram showing a first example of a method of “investigating the installation status of a cipher suite supported by a server” in the embodiment of the present invention, and the “installation status of a cipher suite supported by a server” in FIG. It is also a sequence diagram showing an example of a method of “investigating”.

  Here, the client transmits Client Hello specifying one cipher suite in order to investigate the installation status of the cipher suite of the server. If an alert (handshake_failure) is returned, the server determines that the cipher suite is not held.

  (FIG. 2-(S1)) The client sees the priority order information of the cipher suite held by itself and designates “TLS_RSA_WITH_RC4_128_MD5”, which is the cipher suite of priority 1, and transmits Client Hello. (FIG. 2-(S2)) Since the server does not support "TLS_RSA_WITH_RC4_128_MD5", an alert (handshake_failure) is returned. As a result, the client knows that the server does not support TLS_RSA_WITH_RC4_128_MD5. (FIG. 2-(S3)) And communication is cut | disconnected. In general, the communication is disconnected from the server side, but if the server does not disconnect, the communication is disconnected from the client side. In the description of all the subsequent drawings, the disconnection of communication after an alert (handshake_failure) is the same, and the description is omitted. The communication disconnection is performed by the network control unit 100, for example.

  (FIG. 2-(S4)) Since the server does not support "TLS_RSA_WITH_RC4_128_MD5" which is a cipher suite of priority 1, the client next designates Client Hello by specifying "TLS_RSA_WITH_RC4_128_SHA" which is a cipher suite of priority 2. Send. (FIG. 2-(S5)) Since the server does not support "TLS_RSA_WITH_RC4_128_SHA", an alert (handshake_failure) is returned. As a result, the client knows that the server does not support “TLS_RSA_WITH_RC4_128_SHA”. (FIG. 2-(S6) Then, the communication is disconnected. Note that the processing up to this point results in the client examining the installation information of the cipher suite of the server. , And “cipher suite information not supported by the server” that does not support “TLS_RSA_WITH_RC4_128_SHA”.

  In addition, although it has shown in figure that the process after this is processed continuously, a process after this may be performed when the process is stopped here and actually performing encryption communication. Here, in order to simplify the explanation, it is assumed that the subsequent processing is continuously performed.

  Note that if the client stores “cipher suite information that the server does not support”, it will use “cipher suite information that the server does not support” from the next time without investigating the server's cipher suite information. As a result, it is possible to immediately proceed to the next process (7).

  (FIG. 2-(S7)) Since the server does not support "TLS_RSA_WITH_RC4_128_SHA" which is the cipher suite of priority 2, the client next selects the cipher suite of priority 3. As a result, the cipher suite used by this is selected. (FIG. 2-(S8)) And "TLS_RSA_WITH_AES_128_CBC_SHA" is designated and Client Hello is transmitted. As a result, the cipher suite used by this is transmitted. (FIG. 2-(S5)) Since the server supports "TLS_RSA_WITH_AES_128_CBC_SHA", it specifies "TLS_RSA_WITH_AES_128_CBC_SHA" and returns Server Hello. As a result, the client performs SSL / TLS negotiation with the server using “TLS_RSA_WITH_AES_128_CBC_SHA”. Thereafter, SSL / TLS negotiation is correctly executed, and communication of common key encryption in SSL / TLS encryption communication is started.

  This method sequentially checks whether or not the server supports the cipher suite in order from the cipher suite having the highest priority. If the cipher suite designated by the server is supported, SSL / TLS cipher communication is performed without disconnecting the communication.

  In the above description, in order to simplify the description, it has been described that the investigation is sequentially performed in the order of priority of the cipher suites. However, the investigation is not necessarily performed in the order of priority of the cipher suites. When a plurality of port numbers are available, it is possible to connect with a plurality of channels and transmit a plurality of Client Hellos at the same time. In FIG. 2, Client Hello that checks the installation status of the cipher suite of the server and Client Hello that transmits the cipher suite to be used, that is, 1, 4, and 8 (which may be transmitted first) are transmitted simultaneously. Then, 2, 5, and 9 are obtained, and “TLS_RSA_WITH_AES_128_CBC_SHA” can be selected from the result. And SSL / TLS encryption communication is performed as it is by communication of this cipher suite.

  There is a method of using such a plurality of port numbers also in the description of the subsequent drawings, but this description is omitted for the sake of simplification unless otherwise necessary.

  FIG. 3 is a diagram showing a first example of functional blocks in the embodiment of the present invention, and is also an example of the functional block diagram of FIG. FIG. 4 is a diagram showing a first example of a flowchart on the client side in the embodiment of the present invention, and is also a flowchart of the client 1 in FIG. FIG. 5 is a diagram showing a first example of a flowchart on the server side in the embodiment of the present invention, and is also a diagram showing a first example of a flowchart on the server side in the embodiment of the present invention. Next, description will be made with reference to FIGS. 3, 4, and 5.

  The client 1 starts SSL / TLS encrypted communication with the server 2 via the network. The client 1 prioritizes the cipher suites that the client 1 wants to use with the “priority information of cipher suites supported by the client”. The client 1 indicates which cipher suite is currently selected as “current priority”. The counter is stored as a number in the "counter shown" 700. The initial value of the “counter indicating the current priority” 700 is 1.

  (FIG. 4-(S1)) First, the Client Hello generating unit 400 (part of the cipher suite investigation means) holds "priority information on cipher suites supported by the client" and "a counter indicating the current priority" "Read cipher suite information from 700. Initially, since the value of the “counter indicating the current priority” 700 is 1, information “TLS_RSA_WITH_RC4 — 128_MD5” is read.

  (FIG. 4-(S2)) Client Hello production | generation part 400 (a part of encryption sweet investigation means) produces | generates the Client Hello message which designated "TLS_RSA_WITH_RC4_128_MD5" as an encryption sweet, and sends this to the data transmission part 110. FIG.

  (FIG. 4-(S3)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 4-(S4)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 5-(S1)) The server 2 starts in a message reception waiting state from the client 1. The data receiving unit 220 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 5-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 5-(S3)) "TLS_RSA_WITH_RC4_128_MD5" is specified as the cipher suite in the Client Hello message, but since the server 2 does not support this, the Client Hello receiving unit 410 generates a handshake_failure message, This is sent to the data transmission unit 210.

  (FIG. 5-(S <b> 4)) The data transmission unit 210 transmits a handshake_failure message to the client 1 via the network control device 200.

(FIG. 5- (S5)) Thereafter, the client hello receiving unit 410 disconnects the communication with the client 1, and the server 2 again waits to receive a message from the client 1 (FIG. 4- (S4)). The data receiving unit 120 receives the handshake_failure message transmitted from the server 2 via the network control device 100. The data receiving unit 120 sends the handshake_failure message to the Server Hello receiving unit 500 (part of the cipher suite checking means) that processes (interprets) the handshake_failure message.

  (FIG. 4-(S5)) Server Hello receiving part 500 (a part of encryption sweet investigation means) checks whether the received message is a handshake_failure message.

  (FIG. 4-(S6)) Server Hello receiving part 500 (a part of encryption sweet investigation means) receives a handshake_failure message, Therefore It cuts communication. Even if the server does not disconnect the communication, the communication is disconnected. Then, the Server Hello receiving unit 500 (part of the cipher suite examining unit) adds 1 to the “counter indicating the current priority” 700 and calls the Client Hello generating unit 400 (part of the cipher suite examining unit). (That is, go to (A)). By adding 1 to the “counter indicating the current priority” 700, the investigation result that the server 2 does not have “TLS_RSA_WITH_RC4_128_MD5” is obtained.

  (FIG. 4- (S1)) Next, the client hello generation unit 400 (part of the cipher suite investigation means) indicates “priority information on cipher suites supported by the client” and “current priority” The cipher suite information is read from the counter 700. Since the value of the “counter indicating the current priority” 700 is 2, information “TLS_RSA_WITH_RC4_128_SHA” is read.

  Thereafter, the flow is the same as that in the case of “TLS_RSA_WITH_RC4_128_MD5” for both the client 1 and the server 2. Since the server 2 does not support “TLS_RSA_WITH_RC4_128_SHA” ((S6) in FIG. 4), the Server Hello receiving unit 500 (part of the cipher suite checking means) disconnects communication, and the “counter indicating the current priority order” “1 is added to 700, and the client hello generating unit 400 is called again. By adding “1” to the “counter indicating the current priority” 700, it is possible to obtain an investigation result that the server 2 does not include “TLS_RSA_WITH_RC4_128_SHA”.

  (FIG. 4-(S1)) Next, the client hello generating unit 400 obtains cipher suite information from the "priority information of cipher suites supported by the client" and the "counter indicating the current priority" 700 held by itself. read out. Since the value of the “counter indicating the current priority” 700 is 3, information “TLS_RSA_WITH_AES_128_CBC_SHA” is read. Since the server 2 supports “TLS_RSA_WITH_AES_128_CBC_SHA”, the client 1 eventually selects the cipher suite to be used.

  (FIG. 4-(S2)) The Client Hello production | generation part 400 produces | generates the Client Hello message which designated "TLS_RSA_WITH_AES_128_CBC_SHA" as a cipher suite, and sends this to the data transmission part 110. FIG. In other words, the client 1 has transmitted the cipher suite to be used as a result.

  (FIG. 4-(S3)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 4-(S4)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 5-(S1)) The data receiving part 220 of the server 2 receives the Client Hello message which the client 1 transmitted via the network control apparatus 200. FIG. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 5-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 5-(S6)) Since the server 2 supports "TLS_RSA_WITH_AES_128_CBC_SHA", the Client Hello reception part 410 processes this Client Hello message, and calls the Server Hello production | generation part 510. FIG.

  (FIG. 5-(S7)) Server Hello production | generation part 510 produces | generates a Server Hello / Server Certificate / Server Hello Done message, and sends this to the data transmission part 210. FIG.

  (FIG. 5-(S <b> 8)) The data transmission unit 210 transmits a Server Hello / Server Certificate / Server Hello Done message to the client 1 via the network control device 200.

  (FIG. 5-(S9)) Thereafter, the server 2 enters a state of waiting for receiving a message from the client 1.

  (FIG. 4-(S <b> 4)) The data receiving unit 120 of the client 1 receives the Server Hello / Server Certificate / Server Hello Done message transmitted by the server 2 via the network control device 100. The data receiving unit 120 sends the Server Hello / Server Certificate / Server Hello Done message to the Server Hello receiving unit 500 (part of the cipher suite investigation means) that processes (interprets) the handshake_failure message.

  (FIG. 4-(S5)) Server Hello receiving part 500 (a part of encryption sweet investigation means) checks whether the received message is a handshake_failure message.

  (FIG. 4-(S6)) Since the received message is not a handshake_failure message, the Server Hello receiving unit 500 (part of the cipher suite checking means) sends this to the SSL negotiation processing unit 600 (that is, proceeds to (B)). . Note that the SSL negotiation processing unit 600 performs negotiation processing in SSL / TLS encryption communication after the Server Hello / Server Certificate / Server Hello Done message processing.

  (FIG. 4-(S7)) The SSL negotiation process part 600 processes a Server Hello / Server Certificate / Server Hello Done message, and produces | generates a common key. Next, a Client Key Exchange / Change Cipher Spec / Finished message is generated and sent to the data transmission unit 110.

  (FIG. 4-(S8)) The data transmission part 110 transmits a Client Key Exchange / Change Cipher Spec / Finished message with respect to the server 2 via the network control apparatus 100. FIG.

(FIG. 4- (S9)) After that, the client 1 enters a state of waiting for receiving a message from the server 2. (FIG. 5- (S9)) The data receiving unit 220 of the server 2 transmits the client key exchange / change transmitted by the client 1. A Cipher Spec / Finished message is received via the network control device 200. The data receiving unit 220 processes (interprets) this Client Key Exchange / Change Cipher Spec / Finished message to the Client Key Exchange / Change Cipher Spec / Finished message. Note that the SSL negotiation processing unit 610 performs negotiation processing in SSL / TLS encryption communication after the client key exchange / change cipher spec / finished message processing.

  (FIG. 5-(S10)) The SSL negotiation process part 610 processes a Client Key Exchange / Change Cipher Spec / Finished message, and produces | generates a common key. Next, a Change Cipher Spec / Finished message is generated and sent to the data transmission unit 210.

  (FIG. 5-(S <b> 11)) The data transmission unit 210 transmits a Change Cipher Spec / Finished message to the client 1 via the network control device 200.

  Although not shown in the functional block diagram, the server 2 thereafter performs cryptographic communication with the client 1 using the created common key. The encryption communication is a common key encryption process defined by SSL / TLS encryption communication, and a hash process is performed simultaneously with the encryption process. Therefore, the common key here means a key used in each of the cryptographic processing and the hash processing.

  (FIG. 4-(S9)) The data receiver 120 of the client 1 receives the Change Cipher Spec / Finished message transmitted by the server 2 via the network control device 100. The data receiving unit 220 sends this Change Cipher Spec / Finished message to the SSL negotiation processing unit 600 that processes (interprets) the Change Cipher Spec / Finished message.

  (FIG. 4-(S10)) SSL negotiation process part 600 processes a Change Cipher Spec / Finished message.

  As described above, the encryption method (cipher suite) acquisition unit corresponds to the client hello generation unit 400 (part of the cipher suite investigation unit) and the server hello reception unit 500 (part of the cipher suite investigation unit). Further, the client hello generating unit 400 that selects the cipher suite to be transmitted to the server 2 based on the information acquired by the encryption method acquisition unit is also an encryption method selection unit. Note that the priority order may be calculated by the encryption method acquisition unit or the encryption method selection unit.

  Although not shown in the functional block diagram, after this, the client 1 performs cryptographic communication with the server 2 using the created common key.

  FIG. 6 is a diagram showing a first example of the hardware configuration in the embodiment of the present invention, and is also an example of the hardware configuration diagram of FIG. The client 1 executes data transmission / reception of the network with the CPU 10 that executes program processing, the RAM 20 that is a temporary storage memory, the HDD (hard disk) 30 that is a rewritable nonvolatile memory, and the ROM 40 that is a non-rewritable nonvolatile memory. MAC / PHY50. On the other hand, the server 2 includes a CPU 11 that executes program processing, a RAM 21 that is a temporary storage memory, a ROM 41 that is a non-rewritable nonvolatile memory, and a MAC / PHY 51 that executes network data transmission / reception. The client 1 and the server 2 are connected to each other via a network via a MAC / PHY 50 and a MAC / PHY 51.

  First, the hardware configuration of the client 1 will be described. Each processing unit of the client 1 illustrated in FIG. 3 is executed by the CPU 10 and the RAM 20.

  The “counter indicating the current priority” 700 is disposed in the RAM 20 which is a temporary storage memory, but may be any rewritable memory, and may be disposed in the HDD (hard disk) 30 or the flash ROM. Good.

  Next, “priority information of cipher suites supported by the client” is preferably arranged in a rewritable nonvolatile memory. In this figure, an HDD (hard disk) 30 is used as a rewritable nonvolatile memory, but any type of rewritable nonvolatile memory such as a flash ROM may be used. Although operation is possible even if “priority information on cipher suites supported by the client” is arranged in the RAM 20 which is a temporary storage memory, it is not preferable because it takes time to register the priority every time.

  Note that “priority information on cipher suites supported by the client” is determined at the time of mounting, and if the priority is not changed after mounting, the cipher suites may be arranged in the ROM 40, which is a non-rewritable nonvolatile memory.

  The “cipher suite supported by the client” is a program of an actual cipher suite, and is usually placed in a non-volatile memory. In order to avoid confusing the description, the functional block diagram of the client 1 does not show “cipher suites supported by the client”, but as shown in the functional block diagram of the server 2, This is necessary for cryptographic communication. Here, “encryption suite supported by the client” is arranged in the ROM 40, but the present invention is not limited to this. When the cipher suite program is downloaded from the server and used every time, it can be arranged in a volatile memory such as the RAM 20.

  The MAC / PHY 50 is hardware that controls network communication, and implements the network control device 100.

  Next, the hardware configuration of the server 2 will be described. Each processing unit of the server 2 illustrated in FIG. 3 is executed by the CPU 11 and the RAM 21.

  The “cipher suite supported by the server” is a program of an actual cipher suite, and is usually placed in a non-volatile memory. Here, “encryption suite supported by the server” is arranged in the ROM 41, but the present invention is not limited to this. When the cipher suite program is downloaded from another server and used every time, it can be arranged in a volatile memory such as the RAM 21.

  The MAC / PHY 51 is hardware that controls network communication, and implements the network control device 200.

  FIG. 7 is a sequence diagram showing a second example of the method “investigating the installation status of the cipher suites supported by the server” in the embodiment of the present invention, and FIG. 7 shows the installation status of the cipher suites supported by the server. It is also a sequence diagram showing another example of the “investigating” method. The sequence is almost the same as in FIG. The difference from FIG. 2 is that, as shown in FIG. 7- (S7), FIG. 7- (S8)), and FIG. When Client Hello specifying “TLS_RSA_WITH_AES_128_CBC_SHA”, which is a suite, is transmitted and the server returns Server Hello, SSL / TLS negotiation is not continuously executed and communication is temporarily cut off. This makes it possible to clearly separate the “investigation of server cipher suite installation information” phase and the “select cipher suite to use” phase.

  By separating the “Investigate server cipher suite installation information” phase and the “Select cipher suite to use” phase, it is possible to “inspect server cipher suite installation information” in advance. When performing SSL / TLS negotiation, there is no need to investigate again, and quick SSL / TLS negotiation can be realized.

  For example, when the server device to which the user connects can be specified by the client device, it is possible to check and store the cipher suite installation information of the server device at the time of setting.

  Note that the functional block diagram and flowchart of FIG. 7 are substantially the same as those of FIGS. 3, 4, 5, and 6, and thus the description thereof is omitted. The major difference is that when Server Hello is received in (FIG. 4- (S5)), the communication is cut without proceeding to (FIG. 4- (S7)). Details will be described in FIG.

  FIG. 8 is a sequence diagram showing a third example of the method “investigating the installation status of the cipher suites supported by the server” in the embodiment of the present invention, and FIG. 8 shows the installation status of the cipher suites supported by the server. It is also a sequence diagram showing another example of the “investigating” method. The sequence is almost the same as in FIG. This also clearly separates the phase of “investigating on-board information of cipher suites on the server” and the phase of “selecting cipher suites to use”.

  In FIG. 7, it is investigated whether or not the server supports cipher suites with high priority supported by the client. In FIG. 8, it is determined whether or not the server supports all cipher suites supported by the client. is investigating. When all cipher suites are examined, although there is a time-consuming drawback, if the "priority information of cipher suites supported by the client" is changed, there is no need to investigate again. For example, it is convenient when the user changes “priority information on cipher suites supported by the client” on the client device.

  In the description of the drawings so far, the description has been given on the case where there is only one “cipher suite priority information supported by the client”, but the method of FIG. ing. For example, even when connecting to the same server, there is a case where priority is given to a cipher suite having a stronger process for authentication and priority is given to a light cipher suite having good performance for normal communication. Even in such a case, once the server determines whether or not the server supports all the cipher suites supported by the client, the cipher suite to be selected can be found in each case, so that labor can be saved.

  Note that although it is assumed here that the server supports all cipher suites supported by the client, some cipher suites may be investigated. When prioritizing cipher suites on a client device, if there are cipher suites that are not used in any case, it is reasonable to exclude them. In any case, if there is a cipher suite having a high priority and the server to be connected always supports this cipher suite, only the cipher suite having a higher priority than the cipher suite need be examined.

  Next, detailed description of FIG. 8 will be given. Here, the client transmits Client Hello specifying one cipher suite in order to investigate the installation status of the cipher suite of the server. If an alert (handshake_failure) is returned, the server determines that the cipher suite is not held.

  (FIG. 8-(S1)) The client sees the priority order information of the cipher suite held by itself and designates “TLS_RSA_WITH_RC4_128_MD5”, which is the cipher suite of priority 1, and transmits Client Hello. (FIG. 8-(S2)) Since the server does not support "TLS_RSA_WITH_RC4_128_MD5", an alert (handshake_failure) is returned. As a result, the client knows that the server does not support TLS_RSA_WITH_RC4_128_MD5. Note that this cipher suite is stored as not supported. (FIG. 8-(S3)) And communication is cut | disconnected.

  (FIG. 8-(S4)) Next, a client transmits Client Hello by designating "TLS_RSA_WITH_RC4_128_SHA" which is a cipher suite of the priority order 2. (FIG. 8-(S5)) Since the server does not support "TLS_RSA_WITH_RC4_128_SHA", an alert (handshake_failure) is returned. As a result, the client knows that the server does not support “TLS_RSA_WITH_RC4_128_SHA”. Note that this cipher suite is stored as not supported. (FIG. 8-(S6)) And communication is cut | disconnected.

  (FIG. 8- (S7)) Next, the client designates “TLS_RSA_WITH_AES_128_CBC_SHA”, which is a cipher suite of priority 3, and transmits Client Hello.

  (FIG. 8-(S8)) Since the server supports "TLS_RSA_WITH_AES_128_CBC_SHA", it returns Server Hello. As a result, the client knows that the server supports “TLS_RSA_WITH_AES_128_CBC_SHA”. This cipher suite may be stored as supported, but is not stored in the description here. (FIG. 8-(S9)) And communication is cut | disconnected.

  Here, the communication is disconnected in (FIG. 8-(S <b> 9)). However, when Server Hello is returned, the communication may be disconnected after the SSL / TLS negotiation is completed. Further, when the SSL / TLS negotiation is completed, the negotiation may be re-negotiated at the next Client Hello ((S10) in FIG. 8) without disconnecting the communication. In the description of the subsequent figures, the same processing can be performed when Server Hello is returned. This description is omitted in the following figures.

  However, when SSL / TLS negotiation is completed, time is required for public key encryption processing, which is not preferable.

  (FIG. 8-(S10)) Next, the client designates “TLS_RSA_WITH_AES_256_CBC_SHA”, which is a cipher suite of priority 4, and transmits Client Hello. (FIG. 8-(S11)) Since the server supports "TLS_RSA_WITH_AES_256_CBC_SHA", it returns Server Hello. As a result, the client knows that the server supports “TLS_RSA_WITH_AES_256_CBC_SHA”. This cipher suite may be stored as supported, but is not stored in the description here. (FIG. 8-(S12)) And communication is cut | disconnected.

  Through the above procedure, the client stores at least “cipher suite information not supported by the server” that the server does not support “TLS_RSA_WITH_RC4_128_MD5” and “TLS_RSA_WITH_RC4_128_SHA” among the cipher suites that the client supports.

  Here, in order to simplify the description, the explanation is made such that the cipher suites are investigated in the order of priority, but in actuality, any order may be used.

  2 and 7, the subsequent processing is illustrated as being continuously processed. However, when the processing is stopped once and actual encrypted communication is performed, the subsequent processing is performed. May be performed. Here, in order to simplify the explanation, it is assumed that the subsequent processing is continuously performed.

  In addition, if the client stores “information on cipher suites not supported by the server”, it will use “information on cipher suites not supported by the server” from the next time without investigating the installed information on the server's cipher suites. As a result, it is possible to immediately proceed to the next process (FIG. 8- (S13)).

  (FIG. 8-((S13)) Next, the client selects the cipher suite to be used in order to actually perform SSL / TLS cipher communication with the server.The server supports the cipher suites of priority levels 1 and 2. Therefore, the client selects the cipher suite using “TLS_RSA_WITH_AES_128_CBC_SHA”, which is the cipher suite of priority 3.

  (FIG. 8-(S14)) Then, the client transmits Client Hello specifying "TLS_RSA_WITH_AES_128_CBC_SHA" to transmit the cipher suite to be used to the server. (FIG. 8-(S15)) Since the server supports "TLS_RSA_WITH_AES_128_CBC_SHA", it specifies "TLS_RSA_WITH_AES_128_CBC_SHA" and returns Server Hello. As a result, the client performs SSL / TLS negotiation with the server using “TLS_RSA_WITH_AES_128_CBC_SHA”. Thereafter, SSL / TLS negotiation is correctly executed, and communication of common key encryption in SSL / TLS encryption communication is started.

  It should be noted that the installation status of the cipher suite of the server is thoroughly investigated, and the server obtains information that “TLS_RSA_WITH_AES_128_CBC_SHA” is prioritized over “TLS_RSA_WITH_AES_256_CBC_SHA”, or the server follows the priority of the client, that is, is listed higher When information indicating that a cipher suite is selected is obtained, the client may transmit Client Hello specifying “TLS_RSA_WITH_AES_128_CBC_SHA” and “TLS_RSA_WITH_AES_256_CBC_SHA”. However, this method is not preferable because it takes time. Since this is the same in subsequent figures, this explanation is omitted in the subsequent figures.

  FIG. 9 is a diagram showing a second example of functional blocks in the embodiment of the present invention, and is also an example of the functional block diagram of FIG. FIG. 10 is a diagram showing a second example of the flowchart on the client side in the embodiment of the present invention, and is also the flowchart of the client 1 in FIG. FIG. 11 is a diagram showing a second example of the flowchart on the server side in the embodiment of the present invention, and is also the flowchart of the server 2 in FIG. Next, description will be made with reference to FIGS. 9, 10, and 11. 9, 10, and 11 are also partly described in detail in FIG. 7.

  The client 1 starts SSL / TLS encrypted communication with the server 2 via the network. The client 1 assigns priorities to the cipher suites that it wants to use with “priority information on cipher suites supported by the client”, and the cipher suite information 800 (installation status storage means or encryption method storage unit) It is a mechanism for checking a cipher suite not supported by the server 2 for the suite. Note that the supported cipher suites may be checked as supported, but here, in order to simplify the description, only the unsupported cipher suites are checked. Here, the mounting information 800 (loading status storage means) is stored for each cipher suite, but the storage means is not limited to this, and the number of unsupported cipher suites is remembered. There are various storage means.

  Here, the installation information 800 (installation status storage means) stores the installation information of the encryption suite of the server. However, without providing such a storage area, the “encryption suite supported by the client” is used. It is also possible to store the installation information of the cipher suite of the server in the “priority information”. However, in order to simplify the explanation, it is assumed that the mounting information of the server's cipher suite is stored in the mounting information 800 (mounting status storage means) in the subsequent figures. However, in FIGS. 37 and 38, a method for storing the cipher suite installation information of the server in “priority information of cipher suites supported by the client” will be described.

  Further, the client 1 is provided with a “current counter” 710 indicating which cipher suite is to be investigated when investigating the installation status of the cipher suite of the server. The “current counter” 710 is inputted with the priority number of the cipher suite, and the client 1 investigates the cipher suite having the priority set with the number set in the “current counter” 710. It has become.

  When 0 is assigned to the “current counter” 710, the client 1 does not check the installation status of the cipher suite of the server, performs normal SSL / TLS negotiation, and performs SSL / TLS cipher communication. ing. Here, the initial value of the “current counter” 710 is 1.

  (FIG. 10-(S <b> 1)) First, the Client Hello generation unit 400 (part of the cipher suite investigation unit) encrypts the “priority information on cipher suites supported by the client” and the “current counter” 710 held by itself. Read suite information. Initially, since the value of “current counter” 710 is 1, information “TLS_RSA_WITH_RC4_128_MD5” is read.

  (FIG. 10-(S <b> 2)) The client hello generating unit 400 (a part of the cipher suite examining means) generates a client hello message specifying “TLS_RSA_WITH_RC4_128_MD5” as the cipher suite, and sends this to the data transmitting unit 110.

  (FIG. 10-(S3)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 10-(S4)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 11-(S1)) The server 2 starts in a state waiting for receiving a message from the client 1. The data receiving unit 220 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 11-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 11-(S3)) “TLS_RSA_WITH_RC4_128_MD5” is specified as a cipher suite in the Client Hello message, but since the server 2 does not support this, the Client Hello receiving unit 410 generates a handshake_failure message, This is sent to the data transmission unit 210.

  (FIG. 11-(S4)) The data transmission part 210 transmits a handshake_failure message with respect to the client 1 via the network control apparatus 200. FIG.

  (FIG. 11-(S5)) Thereafter, the client hello receiving unit 410 disconnects communication with the client 1, and the server 2 again enters a state of waiting for receiving a client hello message from the client 1.

  (FIG. 10-(S <b> 4)) The data receiving unit 120 of the client 1 receives the handshake_failure message transmitted by the server 2 via the network control device 100. The data receiving unit 120 sends the handshake_failure message to the Server Hello receiving unit 500 (part of the cipher suite checking means) that processes (interprets) the handshake_failure message.

  (FIG. 10- (S5)) Server Hello receiving section 500 (part of the cipher suite checking means) checks whether or not the received message is a handshake_failure message.

  (FIG. 10- (S6)) Server Hello receiving unit 500 (part of the cipher suite checking means) received the handshake_failure message, so server 2 supports “TLS_RSA_WITH_RC4_128_MD5” in mounting information 800 (mounting status storage means). Remember not to.

  (FIG. 10-(S <b> 7)) Next, the Server Hello receiving unit 500 (part of the cipher suite checking means) disconnects the communication and adds 1 to the “current counter” 710.

(FIG. 10- (S8)) The Server Hello receiving unit 500 (part of the cipher suite checking means) determines whether the value of the “current counter” 710 exceeds the number of cipher suite priorities = MAX value. ,
Value of “current counter” 710 = MAX (4 in this figure) +1
Check whether or not. Here, since the value of the “current counter” 710 is 2, the Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the “current counter” 710 and does not process the Client Hello generating unit 400. (Part of the cipher suite investigation means) is called (that is, the process proceeds to (A)).

  (FIG. 10- (S1)) Next, the client hello generating unit 400 (part of the cipher suite investigation means) holds “priority information on cipher suites supported by the client” and “current counter” 710 held by itself. Read cipher suite information. Since the value of the “current counter” 710 is 2, information “TLS_RSA_WITH_RC4_128_SHA” is read.

  Thereafter, the flow is the same as that in the case of “TLS_RSA_WITH_RC4_128_MD5” for both the client 1 and the server 2. Since the server 2 does not support “TLS_RSA_WITH_RC4_128_SHA” (FIG. 10- (S6)), the Server Hello receiving unit 500 (part of the cipher suite investigation means) stores the server information in the installation information 800 (installation status storage means). 2 stores “TLS_RSA_WITH_RC4_128_SHA” is not supported.

  (FIG. 10-(S <b> 7)) Next, the Server Hello receiving unit 500 (part of the cipher suite checking means) disconnects the communication and adds 1 to the “current counter” 710.

(FIG. 10- (S8)) The Server Hello receiving unit 500 (part of the cipher suite checking means) determines whether the value of the “current counter” 710 exceeds the number of cipher suite priorities = MAX value. ,
Value of "current counter" 710 = MAX (4 in this figure) + 1
Check whether or not. Here, since the value of the “current counter” 710 is 3, the Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the “current counter” 710 and does not process the Client Hello generating unit 400. (Part of the cipher suite investigation means) is called (that is, the process proceeds to (A)).
(FIG. 10- (S1)) Next, the client hello generating unit 400 (part of the cipher suite investigation means) holds “priority information on cipher suites supported by the client” and “current counter” 710 held by itself. Read cipher suite information. Since the value of “current counter” 710 is 3, information “TLS_RSA_WITH_AES_128_CBC_SHA” is read.

  (FIG. 10- (S2)) The client hello generating unit 400 (part of the cipher suite examining means) generates a client hello message specifying “TLS_RSA_WITH_AES_128_CBC_SHA” as the cipher suite, and sends this to the data transmitting unit 110.

  (FIG. 10-(S3)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 10-(S4)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 11-(S1)) The data receiver 220 of the server 2 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 11-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 11-(S6)) Since the server 2 supports "TLS_RSA_WITH_AES_128_CBC_SHA", the Client Hello reception part 410 processes this Client Hello message, and calls the Server Hello production | generation part 510. FIG.

  (FIG. 11-(S7)) The Server Hello production | generation part 510 produces | generates a Server Hello / Server Certificate / Server Hello Done message, and sends this to the data transmission part 210. FIG.

  (FIG. 11-(S8)) The data transmission part 210 transmits a Server Hello / Server Certificate / Server Hello Done message to the client 1 via the network control device 200.

  (FIG. 11-(S9)) Thereafter, the server 2 enters a state of waiting for a message from the client 1.

  (FIG. 10-(S <b> 4)) The data reception unit 120 of the client 1 receives the Server Hello / Server Certificate / Server Hello Done message transmitted from the server 2 via the network control device 100. The data receiving unit 120 sends the Server Hello / Server Certificate / Server Hello Done message to the Server Hello receiving unit 500 (part of the cipher suite investigation means) that processes (interprets) the handshake_failure message.

  (FIG. 10- (S5)) Server Hello receiving section 500 (part of the cipher suite checking means) checks whether or not the received message is a handshake_failure message. The Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the mounting information 800 (mounting status storage means) because the received message is not a handshake_failure message.

  (FIG. 10-(S <b> 7)) Next, the Server Hello receiving unit 500 (part of the cipher suite checking means) disconnects the communication and adds 1 to the “current counter” 710.

(FIG. 10- (S8)) The Server Hello receiving unit 500 (part of the cipher suite checking means) determines whether the value of the “current counter” 710 exceeds the number of cipher suite priorities = MAX value. ,
Value of "current counter" 710 = MAX (4 in this figure) + 1
Check whether or not. Here, since the value of the “current counter” 710 is 4, the Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the “current counter” 710 and does not process the Client Hello generating unit 400. (Part of the cipher suite investigation means) is called (that is, the process proceeds to (A)).
(FIG. 11-(S <b> 9)) Although the server 2 is in a state waiting for receiving a message from the client 1, communication has been cut off from the client 1. become. In addition, in the flowchart of FIG. 11, (S9) and (S10) are illustrated separately for easy understanding, but actually, the communication disconnection process of (S10) is performed in the message reception process of (S9). Executed.

  (FIG. 10- (S1)) Next, the client hello generating unit 400 (part of the cipher suite investigation means) holds “priority information on cipher suites supported by the client” and “current counter” 710 held by itself. Read cipher suite information. Since the value of the “current counter” 710 is 4, the information “TLS_RSA_WITH_AES_256_CBC_SHA” is read.

  Thereafter, the flow is the same as that in the case of “TLS_RSA_WITH_AES_128_CBC_SHA” for both the client 1 and the server 2. Since the server 2 supports “TLS_RSA_WITH_AES_256_CBC_SHA”, nothing is processed in the mounting information 800 (mounting status storage unit).

  (FIG. 10-(S <b> 7)) Next, the Server Hello receiving unit 500 (part of the cipher suite checking means) disconnects the communication and adds 1 to the “current counter” 710.

(FIG. 10- (S8)) The Server Hello receiving unit 500 (part of the cipher suite checking means) determines whether the value of the “current counter” 710 exceeds the number of cipher suite priorities = MAX value. ,
Value of "current counter" 710 = MAX (4 in this figure) + 1
Check whether or not.

(FIG. 10-(S9)) Here, since the value of the "current counter" 710 is 5, (that is, the above equation holds), the Server Hello receiving unit 500 (part of the cipher suite checking means) No. "710 is set to 0, and the Client Hello generating unit 400 is called (that is, the process proceeds to (A)).
(FIG. 10-(S10)) Next, when the "current counter" 710 is 0, the Client Hello generating unit 400 selects a cipher suite to be used from the mounting information 800 (mounting status storage unit). Specifically, the selection is as follows. (1) The client hello generating unit 400 knows from the mounting information 800 (mounting status storage means) that “TLS_RSA_WITH_RC4_128_MD5” of priority 1 is not supported. (2) Next, the client hello generating unit 400 knows from the mounting information 800 (mounting status storage means) that “TLS_RSA_WITH_RC4_128_SHA” of priority 2 is not supported. (3) Next, the client hello generating unit 400 knows that “TLS_RSA_WITH_AES_128_CBC_SHA” with priority 3 is supported from the mounting information 800 (mounting status storage means). Therefore, the client hello generating unit 400 selects “TLS_RSA_WITH_AES_128_CBC_SHA” as the cipher suite.

  Here, the client hello generating unit 400 has been described as selecting the information of the mounting information 800 (mounting status storage unit) from the one with the highest priority, but the method of selecting the cipher suite is not limited to this. Conversely, it may be possible to select the previous cipher suite that is checked in order from the lowest priority. As described above, there are various methods for selecting a cipher suite from the mounting information 800 (mounting status storage unit).

  (FIG. 10- (S11)) The client hello generating unit 400 generates a client hello message specifying “TLS_RSA_WITH_AES_128_CBC_SHA” as a cipher suite, and sends this to the data transmitting unit 110.

  (FIG. 10-(S12)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 10-(S13)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 11-(S1)) The data receiver 220 of the server 2 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 11-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 11-(S6)) Since the server 2 supports "TLS_RSA_WITH_AES_128_CBC_SHA", the Client Hello reception part 410 processes this Client Hello message, and calls the Server Hello production | generation part 510. FIG.

  (FIG. 11-(S7)) The Server Hello production | generation part 510 produces | generates a Server Hello / Server Certificate / Server Hello Done message, and sends this to the data transmission part 210. FIG.

  (FIG. 11-(S8)) The data transmission part 210 transmits a Server Hello / Server Certificate / Server Hello Done message to the client 1 via the network control device 200.

  (FIG. 11-(S9)) Thereafter, the server 2 enters a state of waiting for a message from the client 1.

  (FIG. 10- (S13)) The data receiving unit 120 of the client 1 receives the Server Hello / Server Certificate / Server Hello Done message transmitted by the server 2 via the network control device 100. The data receiving unit 120 sends the Server Hello / Server Certificate / Server Hello Done message to the Server Hello receiving unit 500 (part of the cipher suite investigation means) that processes (interprets) the handshake_failure message.

  (FIG. 10- (S14)) The Server Hello receiving unit 500 (part of the cipher suite checking means) sends the received message to the SSL negotiation processing unit 600 when the “current counter” 710 is 0 (that is, (B Go to)). Note that the SSL negotiation processing unit 600 performs negotiation processing in SSL / TLS encryption communication after the Server Hello / Server Certificate / Server Hello Done message processing.

  (FIG. 10-(S15)) The SSL negotiation process part 600 processes a Server Hello / Server Certificate / Server Hello Done message, and produces | generates a common key. Next, a Client Key Exchange / Change Cipher Spec / Finished message is generated and sent to the data transmission unit 110.

  (FIG. 10-(S16)) The data transmission part 110 transmits a Client Key Exchange / Change Cipher Spec / Finished message to the server 2 via the network control apparatus 100.

(FIG. 10- (S17)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2. (FIG. 11- (S9)) The data receiving unit 220 of the server 2 transmits the Client Key Exchange / Change transmitted by the client 1. A Cipher Spec / Finished message is received via the network control device 200. The data receiving unit 220 processes (interprets) this Client Key Exchange / Change Cipher Spec / Finished message to the Client Key Exchange / Change Cipher Spec / Finished message. Note that the SSL negotiation processing unit 610 performs negotiation processing in SSL / TLS encryption communication after the client key exchange / change cipher spec / finished message processing.

  (FIG. 11-(S11)) SSL negotiation process part 610 processes a Client Key Exchange / Change Cipher Spec / Finished message, and produces | generates a common key. Next, a Change Cipher Spec / Finished message is generated and sent to the data transmission unit 210.

  (FIG. 11-(S12)) The data transmission part 210 transmits a Change Cipher Spec / Finished message to the client 1 via the network control apparatus 200.

  Although not shown in the functional block diagram, the server 2 thereafter performs cryptographic communication with the client 1 using the created common key. The encryption communication is a common key encryption process defined by SSL / TLS encryption communication, and a hash process is performed simultaneously with the encryption process. Therefore, the common key here means a key used in each of the cryptographic processing and the hash processing.

  (FIG. 10-(S17)) The data receiver 120 of the client 1 receives the Change Cipher Spec / Finished message transmitted by the server 2 via the network control device 100. The data receiving unit 220 sends this Change Cipher Spec / Finished message to the SSL negotiation processing unit 600 that processes (interprets) the Change Cipher Spec / Finished message.

  (FIG. 10-(S18)) The SSL negotiation process part 600 processes a Change Cipher Spec / Finished message.

  Although not shown in the functional block diagram, after this, the client 1 performs cryptographic communication with the server 2 using the created common key.

  FIG. 12 is a diagram illustrating a second example of the hardware configuration according to the embodiment of the present invention, and is also an example of the hardware configuration diagram of FIG. 9. The client 1 executes data transmission / reception of the network with the CPU 10 that executes program processing, the RAM 20 that is a temporary storage memory, the HDD (hard disk) 30 that is a rewritable nonvolatile memory, and the ROM 40 that is a non-rewritable nonvolatile memory. MAC / PHY50. On the other hand, the server 2 includes a CPU 11 that executes program processing, a RAM 21 that is a temporary storage memory, a ROM 41 that is a non-rewritable nonvolatile memory, and a MAC / PHY 51 that executes network data transmission / reception. The client 1 and the server 2 are connected to each other via a network via a MAC / PHY 50 and a MAC / PHY 51.

  First, the hardware configuration of the client 1 will be described. Each processing unit of the client 1 illustrated in FIG. 3 is executed by the CPU 10 and the RAM 20.

  The “current counter” 710 and the mounting information 800 (mounting status storage means) are arranged in the RAM 20, which is a temporary storage memory, but may be any rewritable memory, such as the HDD (hard disk) 30 or the flash. You may arrange | position to ROM etc.

  Next, “priority information of cipher suites supported by the client” is preferably arranged in a rewritable nonvolatile memory. In this figure, an HDD (hard disk) 30 is used as a rewritable nonvolatile memory, but any type of rewritable nonvolatile memory such as a flash ROM may be used. Although operation is possible even if “priority information on cipher suites supported by the client” is arranged in the RAM 20 which is a temporary storage memory, it is not preferable because it takes time to register the priority every time.

  Note that “priority information on cipher suites supported by the client” is determined at the time of mounting, and if the priority is not changed after mounting, the cipher suites may be arranged in the ROM 40, which is a non-rewritable nonvolatile memory.

  The “cipher suite supported by the client” is a program of an actual cipher suite, and is usually placed in a non-volatile memory. In order to avoid confusing the description, the functional block diagram of the client 1 does not show “cipher suites supported by the client”, but as shown in the functional block diagram of the server 2, This is necessary for cryptographic communication. Here, “encryption suite supported by the client” is arranged in the ROM 40, but the present invention is not limited to this. When the cipher suite program is downloaded from the server and used every time, it can be arranged in a volatile memory such as the RAM 20.

  The MAC / PHY 50 is hardware that controls network communication, and implements the network control device 100.

  Next, the hardware configuration of the server 2 will be described. Each processing unit of the server 2 illustrated in FIG. 3 is executed by the CPU 11 and the RAM 21.

  The “cipher suite supported by the server” is a program of an actual cipher suite, and is usually placed in a non-volatile memory. Here, “encryption suite supported by the server” is arranged in the ROM 41, but the present invention is not limited to this. When the cipher suite program is downloaded from another server and used every time, it can be arranged in a volatile memory such as the RAM 21.

  The MAC / PHY 51 is hardware that controls network communication, and implements the network control device 200.

  FIG. 13 is a sequence diagram showing a second example of SSL / TLS encryption communication in the embodiment of the present invention.

(S13- (S1)) The client knows that the server supports the following cipher suites among the cipher suites supported by the client by examining the installation status of the cipher suites supported by the server.
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
(S13- (S2)) In selecting a cipher suite, the client tries to select a cipher suite having a higher priority among cipher suites held by the client, but at this time, a client that does not correspond to the cipher suite is selected. Instead, lower the priority until the appropriate item appears.

The cipher suites with the client priorities 1 and 2 are not selected because they do not correspond to the cipher suites. The client selects a cipher suite with priority 3 as described below.
TLS_RSA_WITH_AES_128_CBC_SHA
As described with reference to FIG. 1, the explanation is given in the case where there is only one cipher suite having the same priority. However, in all the figures including this figure, any number of cipher suites having the same priority may be used. I do not care. If there are a plurality of cipher suites of the same priority supported by the server, the cipher suite may be narrowed down to one as desired, or a plurality or all cipher suites may be selected. When selecting a plurality of cipher suites, Client Hello specifying a plurality of cipher suites is transmitted. For the sake of simplicity, it is assumed here that there is only one cipher suite with the same priority.

  (S13- (S3)) The client designates the selected cipher suite and transmits Client Hello to the server. (4) Since the server holds the designated cipher suite, the server transmits Server Hello to the client using the designated cipher suite. Although not shown, SSL / TLS negotiation is correctly executed after this, and common key encryption communication in SSL / TLS encryption communication is started.

  FIG. 14 is a sequence diagram showing a fourth example of the method “investigating the installation status of the cipher suites supported by the server” in the embodiment of the present invention, and FIG. 14 shows the installation status of the cipher suites supported by the server. It is also a sequence diagram showing an example of a method of “investigating”. The sequence is almost the same as in FIG. This also clearly separates the phase of “investigating on-board information of cipher suites on the server” and the phase of “selecting cipher suites to use”.

  In FIG. 8, the cipher suites supported by the client and the cipher suites not supported by the server are investigated. In FIG. 14, the cipher suites supported by the client and the cipher suites supported by the server are investigated. When all cipher suites are examined, although there is a time-consuming drawback, if the "priority information of cipher suites supported by the client" is changed, there is no need to investigate again. For example, it is convenient when the user changes “priority information on cipher suites supported by the client” on the client device.

  The method shown in FIG. 14 is also suitable when there are a plurality of “priority information on cipher suites supported by the client”. For example, even when connecting to the same server, there is a case where priority is given to a cipher suite having a stronger process for authentication and priority is given to a light cipher suite having good performance for normal communication. Even in such a case, once the server determines whether or not the server supports all the cipher suites supported by the client, the cipher suite to be selected can be found in each case, so that labor can be saved.

  Note that although it is assumed here that the server supports all cipher suites supported by the client, some cipher suites may be investigated. When prioritizing cipher suites on a client device, if there are cipher suites that are not used in any case, it is reasonable to exclude them. In any case, if there is a cipher suite having a high priority and the server to be connected always supports this cipher suite, only the cipher suite having a higher priority than the cipher suite need be examined.

  Next, a detailed description of FIG. 14 will be given. Here, the client transmits Client Hello specifying one cipher suite in order to investigate the installation status of the cipher suite of the server. If an alert (handshake_failure) is returned, the server determines that the cipher suite is not held.

  (FIG. 14-(S1)) The client looks at the priority order information of the cipher suite held by itself and designates “TLS_RSA_WITH_RC4_128_MD5”, which is the cipher suite of priority 1, and transmits Client Hello. (FIG. 14-(S2)) Since the server does not support "TLS_RSA_WITH_RC4_128_MD5", an alert (handshake_failure) is returned. As a result, the client knows that the server does not support TLS_RSA_WITH_RC4_128_MD5. Although this cipher suite may be stored as not supported, it is not stored in the description here. (S13- (S3)) And the communication is disconnected.

  (FIG. 14-(S4)) Next, a client transmits Client Hello by designating "TLS_RSA_WITH_RC4_128_SHA" which is a cipher suite of priority 2. (FIG. 14-(S5)) Since the server does not support "TLS_RSA_WITH_RC4_128_SHA", an alert (handshake_failure) is returned. As a result, the client knows that the server does not support “TLS_RSA_WITH_RC4_128_SHA”. Although this cipher suite may be stored as not supported, it is not stored in the description here. (S13- (S6)) and the communication is disconnected.

  (S13- (S7)) Next, the client designates “TLS_RSA_WITH_AES_128_CBC_SHA”, which is a cipher suite of priority 3, and transmits Client Hello.

  (S13- (S8)) Since the server supports “TLS_RSA_WITH_AES_128_CBC_SHA”, it returns Server Hello. As a result, the client knows that the server supports “TLS_RSA_WITH_AES_128_CBC_SHA”. Note that this cipher suite is stored as being supported.

  (S13- (S9)) And the communication is disconnected.

  (S13- (S10)) Next, the client designates “TLS_RSA_WITH_AES_256_CBC_SHA”, which is a cipher suite of priority 4, and transmits Client Hello.

  (S13- (S11)) Since the server supports “TLS_RSA_WITH_AES_256_CBC_SHA”, it returns Server Hello. As a result, the client knows that the server supports “TLS_RSA_WITH_AES_256_CBC_SHA”. Note that this cipher suite is stored as being supported.

  (S13- (S12)) and the communication is disconnected.

  Through the above procedure, the client stores at least “TLS_RSA_WITH_AES_128_CBC_SHA” and “TLS_RSA_WITH_AES_256_CBC_SHA”, “cipher suite information supported by both server and client” among cipher suites supported by the client.

  Here, in order to simplify the description, the explanation is made such that the cipher suites are investigated in the order of priority, but in actuality, any order may be used.

  2, 7, and 8, the subsequent processing is illustrated as being continuously processed. However, when the processing is stopped at this point and actual encrypted communication is performed, this processing is performed. Subsequent processing may be performed. Here, in order to simplify the explanation, it is assumed that the subsequent processing is continuously performed.

  In addition, if the client stores “cipher suite information supported by both the server and the client”, the next time the client does not investigate the installation information of the server's cipher suite, the “cipher suite supported by both the server and the client” It is possible to immediately proceed to the next processing of (S13- (S13)) using the “information”.

  (S13- (S13)) Next, since the client actually performs SSL / TLS encryption communication with the server, the client selects a cipher suite to be used. Among the cipher suites supported by the server, “TLS_RSA_WITH_AES_128_CBC_SHA”, which is the cipher suite with the highest priority in the client, is selected as the cipher suite.

  (S13- (S14)) Then, the client transmits Client Hello specifying "TLS_RSA_WITH_AES_128_CBC_SHA" in order to transmit the cipher suite to be used to the server. (S13- (S15)) Since the server supports "TLS_RSA_WITH_AES_128_CBC_SHA", it designates "TLS_RSA_WITH_AES_128_CBC_SHA" and returns Server Hello. As a result, the client performs SSL / TLS negotiation with the server using “TLS_RSA_WITH_AES_128_CBC_SHA”. Thereafter, SSL / TLS negotiation is correctly executed, and communication of common key encryption in SSL / TLS encryption communication is started.

  FIG. 15 is a diagram showing a third example of functional blocks in the embodiment of the present invention, and is also an example of the functional block diagram of FIG. FIG. 16 is a diagram showing a third example of the flowchart on the client side in the embodiment of the present invention, and is also the flowchart of the client 1 in FIG. The flowchart of the server 2 in FIG. 15 is the same as that in FIG. Next, description will be made with reference to FIGS. 15, 16, and 11.

  The client 1 starts SSL / TLS encrypted communication with the server 2 via the network. The client 1 assigns the priorities of the cipher suites that the client 1 wants to use with the “priority information of cipher suites supported by the client”, and the installation information 800 (installation status storage means) The cipher suite supported by the server 2 is checked. Note that unsupported cipher suites may be checked as being unsupported, but here, in order to simplify the description, only supported cipher suites are checked. Here, the mounting information 800 (loading status storage means) is stored for each cipher suite, but the storage means is not limited to this, and the number of unsupported cipher suites is remembered. There are various storage means.

  Further, the client 1 is provided with a “current counter” 710 indicating which cipher suite is to be investigated when investigating the installation status of the cipher suite of the server. The “current counter” 710 is inputted with the priority number of the cipher suite, and the client 1 investigates the cipher suite having the priority set with the number set in the “current counter” 710. It has become.

  When 0 is assigned to the “current counter” 710, the client 1 does not check the installation status of the cipher suite of the server, performs normal SSL / TLS negotiation, and performs SSL / TLS cipher communication. ing. Here, the initial value of the “current counter” 710 is 1.

  (FIG. 16-(S <b> 1)) First, the client hello generating unit 400 (part of the cipher suite investigation means) encrypts the “cipher suite priority information supported by the client” and the “current counter” 710 held by itself. Read suite information. Initially, since the value of “current counter” 710 is 1, information “TLS_RSA_WITH_RC4_128_MD5” is read.

  (FIG. 16-(S <b> 2)) The client hello generating unit 400 (part of the cipher suite examining unit) generates a client hello message specifying “TLS_RSA_WITH_RC4_128_MD5” as the cipher suite, and sends this to the data transmitting unit 110.

  (FIG. 16-(S3)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 16-(S4)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 11-(S1)) The server 2 starts in a state waiting for receiving a message from the client 1. The data receiving unit 220 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 11-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 11-(S3)) “TLS_RSA_WITH_RC4_128_MD5” is specified as a cipher suite in the Client Hello message, but since the server 2 does not support this, the Client Hello receiving unit 410 generates a handshake_failure message, This is sent to the data transmission unit 210.

  (FIG. 11-(S4)) The data transmission part 210 transmits a handshake_failure message with respect to the client 1 via the network control apparatus 200. FIG.

  (FIG. 11-(S5)) Thereafter, the client hello receiving unit 410 disconnects communication with the client 1, and the server 2 again enters a state of waiting for receiving a client hello message from the client 1.

  (FIG. 16-(S <b> 4)) The data receiving unit 120 of the client 1 receives the handshake_failure message transmitted by the server 2 via the network control device 100. The data receiving unit 120 sends the handshake_failure message to the Server Hello receiving unit 500 (part of the cipher suite checking means) that processes (interprets) the handshake_failure message.

  (FIG. 16-(S5)) Server Hello receiving part 500 (a part of encryption sweet investigation means) checks whether the received message is a handshake_failure message. The Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the mounting information 800 (mounting status storage means) because the received message is a handshake_failure message.

  (FIG. 16-(S7)) Next, the Server Hello receiving unit 500 (part of the cipher suite checking means) disconnects the communication and adds 1 to the "current counter" 710.

(FIG. 16-(S8)) The Server Hello receiving unit 500 (part of the cipher suite investigation means) determines whether the value of the “current counter” 710 exceeds the number of cipher suite priorities = MAX value. ,
Value of "current counter" 710 = MAX (4 in this figure) + 1
Check whether or not. Here, since the value of the “current counter” 710 is 2, the Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the “current counter” 710 and does not process the Client Hello generating unit 400. (Part of the cipher suite investigation means) is called (that is, the process proceeds to (A)).
(FIG. 16- (S1)) Next, the client hello generating unit 400 (part of the cipher suite checking means) holds the “priority information of cipher suites supported by the client” and the “current counter” 710 held by itself. Read cipher suite information. Since the value of the “current counter” 710 is 2, information “TLS_RSA_WITH_RC4_128_SHA” is read.

  Thereafter, the flow is the same as that in the case of “TLS_RSA_WITH_RC4_128_MD5” for both the client 1 and the server 2. Since the server 2 does not support “TLS_RSA_WITH_RC4_128_SHA”, no processing is performed on the mounting information 800 (mounting status storage unit).

  (FIG. 16-(S7)) Next, the Server Hello receiving unit 500 (part of the cipher suite checking means) disconnects the communication and adds 1 to the "current counter" 710.

(FIG. 16-(S8)) The Server Hello receiving unit 500 (part of the cipher suite investigation means) determines whether the value of the “current counter” 710 exceeds the number of cipher suite priorities = MAX value. ,
Value of "current counter" 710 = MAX (4 in this figure) + 1
Check whether or not. Here, since the value of the “current counter” 710 is 3, the Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the “current counter” 710 and does not process the Client Hello generating unit 400. (Part of the cipher suite investigation means) is called (that is, the process proceeds to (A)).
(FIG. 16- (S1)) Next, the client hello generating unit 400 (part of the cipher suite checking means) holds the “priority information of cipher suites supported by the client” and the “current counter” 710 held by itself. Read cipher suite information. Since the value of “current counter” 710 is 3, information “TLS_RSA_WITH_AES_128_CBC_SHA” is read.

  (FIG. 16-(S2)) The client hello generating unit 400 (part of the cipher suite examining means) generates a client hello message specifying “TLS_RSA_WITH_AES_128_CBC_SHA” as a cipher suite, and sends this to the data transmitting unit 110.

  (FIG. 16-(S3)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 16-(S4)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 11-(S1)) The data receiver 220 of the server 2 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 11-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 11-(S6)) Since the server 2 supports "TLS_RSA_WITH_AES_128_CBC_SHA", the Client Hello reception part 410 processes this Client Hello message, and calls the Server Hello production | generation part 510. FIG.

  (FIG. 11-(S7)) The Server Hello production | generation part 510 produces | generates a Server Hello / Server Certificate / Server Hello Done message, and sends this to the data transmission part 210. FIG.

  (FIG. 11-(S8)) The data transmission part 210 transmits a Server Hello / Server Certificate / Server Hello Done message to the client 1 via the network control device 200.

  (FIG. 11-(S9)) Thereafter, the server 2 enters a state of waiting for a message from the client 1.

  (FIG. 16-(S <b> 4)) The data receiving unit 120 of the client 1 receives the Server Hello / Server Certificate / Server Hello Done message transmitted by the server 2 via the network control device 100. The data receiving unit 120 sends the Server Hello / Server Certificate / Server Hello Done message to the Server Hello receiving unit 500 (part of the cipher suite investigation means) that processes (interprets) the handshake_failure message.

  (FIG. 16-(S5)) Server Hello receiving part 500 (a part of encryption sweet investigation means) checks whether the received message is a handshake_failure message.

  (FIG. 16-(S6)) Since the received message is not a handshake_failure message, the server hello receiving unit 500 (part of the cipher suite checking means) stores the server 2 in the TLS_RSA_WITH_AES_128_CBC_SHA in the mounting information 800 (mounting status storage means). Remember to support.

  (FIG. 16-(S7)) Next, the Server Hello receiving unit 500 (part of the cipher suite checking means) disconnects the communication and adds 1 to the "current counter" 710.

(FIG. 16-(S8)) The Server Hello receiving unit 500 (part of the cipher suite investigation means) determines whether the value of the “current counter” 710 exceeds the number of cipher suite priorities = MAX value. ,
Value of "current counter" 710 = MAX (4 in this figure) + 1
Check whether or not. Here, since the value of the “current counter” 710 is 4, the Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the “current counter” 710 and does not process the Client Hello generating unit 400. (Part of the cipher suite investigation means) is called (that is, the process proceeds to (A)).
(FIG. 11-(S <b> 9)) Although the server 2 is in a state waiting for receiving a message from the client 1, communication has been cut off from the client 1. become. In addition, in the flowchart of FIG. 11, (S9) and (S10) are illustrated separately for easy understanding, but actually, the communication disconnection process of (S10) is performed in the message reception process of (S9). Executed.

  (FIG. 16- (S1)) Next, the client hello generating unit 400 (part of the cipher suite checking means) holds the “priority information of cipher suites supported by the client” and the “current counter” 710 held by itself. Read cipher suite information. Since the value of the “current counter” 710 is 4, the information “TLS_RSA_WITH_AES_256_CBC_SHA” is read.

  Thereafter, the flow is the same as that in the case of “TLS_RSA_WITH_AES_128_CBC_SHA” for both the client 1 and the server 2. Since the server 2 supports “TLS_RSA_WITH_AES_256_CBC_SHA” (FIG. 10- (S6)), the Server Hello receiving unit 500 (part of the cipher suite investigation unit) is included in the installation information 800 (installation status storage unit). Stores support for “TLS_RSA_WITH_AES_256_CBC_SHA”.

  (FIG. 16-(S7)) Next, the Server Hello receiving unit 500 (part of the cipher suite checking means) disconnects the communication and adds 1 to the "current counter" 710.

(FIG. 16-(S8)) The Server Hello receiving unit 500 (part of the cipher suite investigation means) determines whether the value of the “current counter” 710 exceeds the number of cipher suite priorities = MAX value. ,
Value of "current counter" 710 = MAX (4 in this figure) + 1
Check whether or not.

(FIG. 16-(S9)) Here, since the value of the "current counter" 710 is 5, (that is, the above equation holds), the Server Hello receiving unit 500 (part of the cipher suite checking means) No. "710 is set to 0, and the Client Hello generating unit 400 is called (that is, the process proceeds to (A)).
(FIG. 16-(S10)) Next, the Client Hello production | generation part 400 selects the encryption sweet to utilize from the mounting information 800 (mounting condition memory | storage means), when the "current counter" 710 is 0. Specifically, the selection is as follows. (1) The client hello generating unit 400 knows from the mounting information 800 (mounting status storage means) that “TLS_RSA_WITH_RC4_128_MD5” of priority 1 is not supported. (2) Next, the client hello generating unit 400 knows from the mounting information 800 (mounting status storage means) that “TLS_RSA_WITH_RC4_128_SHA” of priority 2 is not supported. (3) Next, the client hello generating unit 400 knows that “TLS_RSA_WITH_AES_128_CBC_SHA” with priority 3 is supported from the mounting information 800 (mounting status storage means). Therefore, the client hello generating unit 400 selects “TLS_RSA_WITH_AES_128_CBC_SHA” as the cipher suite.

  Here, the client hello generating unit 400 has been described as selecting the information of the mounting information 800 (mounting status storage unit) from the one with the highest priority, but the method of selecting the cipher suite is not limited to this. Conversely, the cipher suite that is checked last may be selected in order from the lowest priority. As described above, there are various methods for selecting a cipher suite from the mounting information 800 (mounting status storage unit).

  (FIG. 16-(S <b> 11)) The client hello generating unit 400 generates a client hello message specifying “TLS_RSA_WITH_AES_128_CBC_SHA” as a cipher suite, and sends this to the data transmitting unit 110.

  (FIG. 16-(S12)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 16-(S13)) Thereafter, the client 1 enters a state of waiting to receive a message from the server 2.

  (FIG. 11-(S1)) The data receiver 220 of the server 2 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 11-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 11-(S6)) Since the server 2 supports "TLS_RSA_WITH_AES_128_CBC_SHA", the Client Hello reception part 410 processes this Client Hello message, and calls the Server Hello production | generation part 510. FIG.

  (FIG. 11-(S7)) The Server Hello production | generation part 510 produces | generates a Server Hello / Server Certificate / Server Hello Done message, and sends this to the data transmission part 210. FIG.

  (FIG. 11-(S8)) The data transmission part 210 transmits a Server Hello / Server Certificate / Server Hello Done message to the client 1 via the network control device 200.

  (FIG. 11-(S9)) Thereafter, the server 2 enters a state of waiting for a message from the client 1.

  (FIG. 16-(S13)) The data receiver 120 of the client 1 receives the Server Hello / Server Certificate / Server Hello Done message transmitted from the server 2 via the network control device 100. The data receiving unit 120 sends the Server Hello / Server Certificate / Server Hello Done message to the Server Hello receiving unit 500 (part of the cipher suite investigation means) that processes (interprets) the handshake_failure message.

  (FIG. 16-(S14)) Server Hello receiving part 500 (a part of encryption sweet investigation means), when "current counter" 710 is 0, sends the received message to SSL negotiation processing part 600 (that is, (B Go to)). Note that the SSL negotiation processing unit 600 performs negotiation processing in SSL / TLS encryption communication after the Server Hello / Server Certificate / Server Hello Done message processing.

  (FIG. 16-(S15)) The SSL negotiation process part 600 processes a Server Hello / Server Certificate / Server Hello Done message, and produces | generates a common key. Next, a Client Key Exchange / Change Cipher Spec / Finished message is generated and sent to the data transmission unit 110.

  (FIG. 16-(S16)) The data transmission part 110 transmits a Client Key Exchange / Change Cipher Spec / Finished message to the server 2 via the network control apparatus 100.

(FIG. 16- (S17)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2. (FIG. 11- (S9)) The data receiving unit 220 of the server 2 transmits the Client Key Exchange / Change transmitted by the client 1. A Cipher Spec / Finished message is received via the network control device 200. The data receiving unit 220 processes (interprets) this Client Key Exchange / Change Cipher Spec / Finished message to the Client Key Exchange / Change Cipher Spec / Finished message. Note that the SSL negotiation processing unit 610 performs negotiation processing in SSL / TLS encryption communication after the client key exchange / change cipher spec / finished message processing.

  (FIG. 11-(S11)) SSL negotiation process part 610 processes a Client Key Exchange / Change Cipher Spec / Finished message, and produces | generates a common key. Next, a Change Cipher Spec / Finished message is generated and sent to the data transmission unit 210.

  (FIG. 11-(S12)) The data transmission part 210 transmits a Change Cipher Spec / Finished message to the client 1 via the network control apparatus 200.

  Although not shown in the functional block diagram, the server 2 thereafter performs cryptographic communication with the client 1 using the created common key. The encryption communication is a common key encryption process defined by SSL / TLS encryption communication, and a hash process is performed simultaneously with the encryption process. Therefore, the common key here means a key used in each of the cryptographic processing and the hash processing.

  (FIG. 16-(S <b> 17)) The data receiving unit 120 of the client 1 receives the Change Cipher Spec / Finished message transmitted by the server 2 via the network control device 100. The data receiving unit 220 sends this Change Cipher Spec / Finished message to the SSL negotiation processing unit 600 that processes (interprets) the Change Cipher Spec / Finished message.

  (FIG. 16-(S18)) The SSL negotiation process part 600 processes a Change Cipher Spec / Finished message.

  Although not shown in the functional block diagram, after this, the client 1 performs cryptographic communication with the server 2 using the created common key.

  12 shows an example of the hardware configuration diagram of FIG. 15 as in FIG. Since the explanation is the same, I will omit it.

  FIG. 17 is a sequence diagram showing a third example of SSL / TLS encryption communication in the embodiment of the present invention.

(FIG. 17- (S1)) The client investigates the installation status of the cipher suites supported by the server, and the cipher suites with the highest priority among the cipher suites supported by the server are as follows. know.
TLS_RSA_WITH_AES_128_CBC_SHA
(FIG. 17-(S2)) A client selects the said encryption sweet in selection of an encryption sweet.
TLS_RSA_WITH_AES_128_CBC_SHA
As described with reference to FIG. 1, the explanation is given in the case where there is only one cipher suite having the same priority. However, in all the figures including this figure, any number of cipher suites having the same priority may be used. I do not care. If there are a plurality of cipher suites of the same priority supported by the server, the cipher suite may be narrowed down to one as desired, or a plurality or all cipher suites may be selected. When selecting a plurality of cipher suites, Client Hello specifying a plurality of cipher suites is transmitted. For the sake of simplicity, it is assumed here that there is only one cipher suite with the same priority.

  (FIG. 17-(S3)) A client designates this selected encryption sweet and transmits Client Hello to a server. (FIG. 17-(S4)) Since a server hold | maintains this designated encryption sweet, Server Hello is transmitted to a client by this designated encryption sweet. Although not shown, SSL / TLS negotiation is correctly executed after this, and common key encryption communication in SSL / TLS encryption communication is started.

  FIG. 18 is a sequence diagram showing a fifth example of the method “investigating the installation status of the cipher suites supported by the server” in the embodiment of the present invention, and FIG. 17 shows the installation status of the cipher suites supported by the server. FIG. 11 is a sequence diagram illustrating an example of a “investigation” method. The sequence is almost the same as that shown in FIGS. This also clearly separates the phase of “investigating on-board information of cipher suites on the server” and the phase of “selecting cipher suites to use”.

  In FIG. 14, the cipher suites supported by the client and the cipher suites supported by the server are investigated. In FIG. 18, the cipher suite having the highest priority among the cipher suites supported by the server is investigated. Yes. Since all cipher suites are not examined, the investigation time can be shortened.

  Next, detailed description of FIG. 18 will be given. Here, the client transmits Client Hello specifying one cipher suite in order to investigate the installation status of the cipher suite of the server. If an alert (handshake_failure) is returned, the server determines that the cipher suite is not held.

  (FIG. 18-(S1)) The client looks at the priority order information of the cipher suite held by itself, and designates “TLS_RSA_WITH_RC4_128_MD5”, which is the cipher suite of priority 1, and transmits Client Hello. (FIG. 18-(S2)) Since the server does not support "TLS_RSA_WITH_RC4_128_MD5", an alert (handshake_failure) is returned. As a result, the client knows that the server does not support TLS_RSA_WITH_RC4_128_MD5. (FIG. 18-(S3)) And communication is cut | disconnected.

  (FIG. 18-(S4)) Next, a client transmits Client Hello by designating "TLS_RSA_WITH_RC4_128_SHA" which is a cipher suite of priority 2. (FIG. 18-(S5)) Since the server does not support "TLS_RSA_WITH_RC4_128_SHA", an alert (handshake_failure) is returned. As a result, the client knows that the server does not support “TLS_RSA_WITH_RC4_128_SHA”. (FIG. 18-(S6)) And communication is cut | disconnected.

  (FIG. 18-(S7)) Next, the client designates “TLS_RSA_WITH_AES_128_CBC_SHA”, which is a cipher suite of priority 3, and transmits Client Hello.

  (FIG. 18-(S8)) Since the server supports "TLS_RSA_WITH_AES_128_CBC_SHA", it returns Server Hello. As a result, the client knows that the server supports “TLS_RSA_WITH_AES_128_CBC_SHA”. Then, this cipher suite is stored as “information of cipher suite having the highest client priority among cipher suites supported by the server”.

  (FIG. 18-(S9)) And communication is cut | disconnected.

  Here, in order to simplify the description, the explanation is made such that the cipher suites are investigated in the order of priority, but in actuality, any order may be used. For example, in the case of investigating from the lower priority, it is sufficient to check until the server returns an alert (handshake_failure) and store the cipher suite that returned the previous Server Hello.

  In addition, like FIG.2, FIG.7, FIG.8, FIG.14, although it has shown in figure so that the process after this may be processed continuously, a case where processing is stopped here and actually performs encrypted communication In addition, the subsequent processing may be performed. Here, in order to simplify the explanation, it is assumed that the subsequent processing is continuously performed.

  In addition, if the client stores “information on the cipher suite with the highest client priority among the cipher suites supported by the server”, the client can check the installed information of the cipher suite on the server from the next time. By using the information of the cipher suite having the highest client priority among the cipher suites supported by the server, it is possible to immediately proceed to the next process (FIG. 18- (S13)).

  (FIG. 18-(S10)) Next, the client selects the cipher suite to be used in order to actually perform SSL / TLS cipher communication with the server. Among the cipher suites supported by the server, “TLS_RSA_WITH_AES_128_CBC_SHA”, which is the cipher suite with the highest priority in the client, is selected as the cipher suite.

  (FIG. 18-(S11)) Then, the client transmits Client Hello specifying "TLS_RSA_WITH_AES_128_CBC_SHA" in order to transmit the cipher suite to be used to the server. (FIG. 18-(S12)) Since the server supports "TLS_RSA_WITH_AES_128_CBC_SHA", it specifies "TLS_RSA_WITH_AES_128_CBC_SHA" and returns Server Hello. As a result, the client performs SSL / TLS negotiation with the server using “TLS_RSA_WITH_AES_128_CBC_SHA”. Thereafter, SSL / TLS negotiation is correctly executed, and communication of common key encryption in SSL / TLS encryption communication is started.

  FIG. 19 is an example of a diagram illustrating a fourth example of functional blocks in the embodiment of the present invention, and is also an example of the functional block diagram of FIG. 20 is a diagram showing a fourth example of the flowchart on the client side in the embodiment of the present invention, and is also the flowchart of the client 1 in FIG. The flowchart of the server 2 in FIG. 19 is the same as that in FIG. Next, description will be made with reference to FIGS.

  The client 1 starts SSL / TLS encrypted communication with the server 2 via the network. Client 1 uses “priority information on cipher suites supported by the client” to prioritize the cipher suites that it wants to use, and the cipher suite with the highest client priority among the cipher suites supported by the server. The information is stored in the mounting information 800 (mounting status storage means). Here, the mounting information 800 (mounting status storage means) is a storage area corresponding to each cipher suite supported by the client, and the cipher suite having the highest client priority among the cipher suites supported by the server is checked. However, the storage means is not limited to this. The mounting information 800 (mounting status storage means) may simply store the number of the cipher suite having the highest client priority among the cipher suites supported by the server, and there are various storage means. is there.

  Further, the client 1 is provided with a “current counter” 710 indicating which cipher suite is to be investigated when investigating the installation status of the cipher suite of the server. The “current counter” 710 is inputted with the priority number of the cipher suite, and the client 1 investigates the cipher suite having the priority set with the number set in the “current counter” 710. It has become.

  When 0 is assigned to the “current counter” 710, the client 1 does not check the installation status of the cipher suite of the server, performs normal SSL / TLS negotiation, and performs SSL / TLS cipher communication. ing. Here, the initial value of the “current counter” 710 is 1.

  (FIG. 20-(S <b> 1)) First, the client hello generation unit 400 (part of the cipher suite investigation means) encrypts the “priority information of cipher suites supported by the client” and the “current counter” 710 held by itself. Read suite information. Initially, since the value of “current counter” 710 is 1, information “TLS_RSA_WITH_RC4_128_MD5” is read.

  (FIG. 20-(S <b> 2)) The client hello generating unit 400 (part of the cipher suite investigation unit) generates a client hello message specifying “TLS_RSA_WITH_RC4_128_MD5” as the cipher suite, and sends this to the data transmitting unit 110.

  (FIG. 20-(S3)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 20-(S4)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 11-(S1)) The server 2 starts in a state waiting for receiving a message from the client 1. The data receiving unit 220 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 11-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 11-(S3)) “TLS_RSA_WITH_RC4_128_MD5” is specified as a cipher suite in the Client Hello message, but since the server 2 does not support this, the Client Hello receiving unit 410 generates a handshake_failure message, This is sent to the data transmission unit 210.

  (FIG. 11-(S4)) The data transmission part 210 transmits a handshake_failure message with respect to the client 1 via the network control apparatus 200. FIG.

  (FIG. 11-(S5)) Thereafter, the client hello receiving unit 410 disconnects communication with the client 1, and the server 2 again enters a state of waiting for receiving a client hello message from the client 1.

  (FIG. 20-(S4)) The data receiver 120 of the client 1 receives the handshake_failure message transmitted by the server 2 via the network control device 100. The data receiving unit 120 sends the handshake_failure message to the Server Hello receiving unit 500 (part of the cipher suite checking means) that processes (interprets) the handshake_failure message.

  (FIG. 20-(S5)) Server Hello receiving part 500 (a part of encryption sweet investigation means) checks whether the received message is a handshake_failure message. The Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the mounting information 800 (mounting status storage means) because the received message is a handshake_failure message.

  (FIG. 20-(S7)) Next, the Server Hello receiving unit 500 (part of the cipher suite checking means) disconnects the communication and adds 1 to the "current counter" 710.

(FIG. 20-(S8)) The Server Hello receiving unit 500 (part of the cipher suite investigation means) determines whether the value of the “current counter” 710 exceeds the number of cipher suite priorities = MAX value. ,
Value of "current counter" 710 = MAX (4 in this figure) + 1
Check whether or not. Here, since the value of the “current counter” 710 is 2, the Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the “current counter” 710 and does not process the Client Hello generating unit 400. (Part of the cipher suite investigation means) is called (that is, the process proceeds to (A)).
(FIG. 20-(S <b> 1)) Next, the client hello generation unit 400 (part of the cipher suite investigation unit) holds the “priority information on cipher suites supported by the client” and the “current counter” 710. Read cipher suite information. Since the value of the “current counter” 710 is 2, information “TLS_RSA_WITH_RC4_128_SHA” is read.

  Thereafter, the flow is the same as that in the case of “TLS_RSA_WITH_RC4_128_MD5” for both the client 1 and the server 2. Since the server 2 does not support “TLS_RSA_WITH_RC4_128_SHA”, no processing is performed on the mounting information 800 (mounting status storage unit).

  (FIG. 20-(S7)) Next, the Server Hello receiving unit 500 (part of the cipher suite checking means) disconnects the communication and adds 1 to the "current counter" 710.

(FIG. 20-(S8)) The Server Hello receiving unit 500 (part of the cipher suite investigation means) determines whether the value of the “current counter” 710 exceeds the number of cipher suite priorities = MAX value. ,
Value of "current counter" 710 = MAX (4 in this figure) + 1
Check whether or not. Here, since the value of the “current counter” 710 is 3, the Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the “current counter” 710 and does not process the Client Hello generating unit 400. (Part of the cipher suite investigation means) is called (that is, the process proceeds to (A)).
(FIG. 20-(S <b> 1)) Next, the client hello generation unit 400 (part of the cipher suite investigation unit) holds the “priority information on cipher suites supported by the client” and the “current counter” 710. Read cipher suite information. Since the value of “current counter” 710 is 3, information “TLS_RSA_WITH_AES_128_CBC_SHA” is read.

  (FIG. 20-(S <b> 2)) The client hello generating unit 400 (part of the cipher suite investigation unit) generates a client hello message specifying “TLS_RSA_WITH_AES_128_CBC_SHA” as the cipher suite, and sends this to the data transmitting unit 110.

  (FIG. 20-(S3)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 20-(S4)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 11-(S1)) The data receiver 220 of the server 2 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 11-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 11-(S6)) Since the server 2 supports "TLS_RSA_WITH_AES_128_CBC_SHA", the Client Hello reception part 410 processes this Client Hello message, and calls the Server Hello production | generation part 510. FIG.

  (FIG. 11-(S7)) The Server Hello production | generation part 510 produces | generates a Server Hello / Server Certificate / Server Hello Done message, and sends this to the data transmission part 210. FIG.

  (FIG. 11-(S8)) The data transmission part 210 transmits a Server Hello / Server Certificate / Server Hello Done message to the client 1 via the network control device 200.

  (FIG. 11-(S9)) Thereafter, the server 2 enters a state of waiting for a message from the client 1.

  (FIG. 20-(S4)) The data receiver 120 of the client 1 receives the Server Hello / Server Certificate / Server Hello Done message transmitted from the server 2 via the network control device 100. The data receiving unit 120 sends the Server Hello / Server Certificate / Server Hello Done message to the Server Hello receiving unit 500 (part of the cipher suite investigation means) that processes (interprets) the handshake_failure message.

  (FIG. 20-(S5)) Server Hello receiving part 500 (a part of encryption sweet investigation means) checks whether the received message is a handshake_failure message.

  (FIG. 20-(S6)) Since the received message is not a handshake_failure message, the server hello receiving unit 500 (part of the cipher suite checking means) indicates that the server 2 has “TLS_RSA_WITH_AES_128_CBC_SHA” in the mounting information 800 (mounting status storage means). Remember to support. This is the cipher suite with the highest priority among the cipher suites supported by the server. And Server Hello receiving part 500 (a part of encryption sweet investigation means) cuts off communication.

  (FIG. 11-(S <b> 9)) Although the server 2 is in a state waiting for receiving a message from the client 1, communication has been cut off from the client 1. become. In addition, in the flowchart of FIG. 11, (S9) and (S10) are illustrated separately for easy understanding, but actually, the communication disconnection process of (S10) is performed in the message reception process of (S9). Executed.

(FIG. 20-(S <b> 9)) The Server Hello receiving unit 500 (part of the cipher suite examining means) sets “current counter” 710 to 0 and calls the Client Hello generating unit 400 (that is, proceeds to (A)). ).
(FIG. 20-(S10)) Next, the Client Hello production | generation part 400 selects the encryption sweet to be used from the mounting information 800 (mounting condition memory | storage means), when the "current counter" 710 is 0. Since the cipher suite checked in the mounting information 800 (mounting status storage means) is “TLS_RSA_WITH_AES_128_CBC_SHA”, the Client Hello generating unit 400 selects “TLS_RSA_WITH_AES_128_CBC_SHA” as the cipher suite.

  (FIG. 20-(S <b> 11)) The client hello generating unit 400 generates a client hello message specifying “TLS_RSA_WITH_AES_128_CBC_SHA” as a cipher suite, and sends this to the data transmitting unit 110.

  (FIG. 20-(S12)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 20-(S13)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 11-(S11)) The data receiving part 220 of the server 2 receives the Client Hello message which the client 1 transmitted via the network control apparatus 200. FIG. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 11-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 11-(S6)) Since the server 2 supports "TLS_RSA_WITH_AES_128_CBC_SHA", the Client Hello reception part 410 processes this Client Hello message, and calls the Server Hello production | generation part 510. FIG.

  (FIG. 11-(S7)) The Server Hello production | generation part 510 produces | generates a Server Hello / Server Certificate / Server Hello Done message, and sends this to the data transmission part 210. FIG.

  (FIG. 11-(S8)) The data transmission part 210 transmits a Server Hello / Server Certificate / Server Hello Done message to the client 1 via the network control device 200.

  (FIG. 11-(S9)) Thereafter, the server 2 enters a state of waiting for a message from the client 1.

  (FIG. 20-(S13)) The data receiver 120 of the client 1 receives the Server Hello / Server Certificate / Server Hello Done message transmitted by the server 2 via the network control device 100. The data receiving unit 120 sends the Server Hello / Server Certificate / Server Hello Done message to the Server Hello receiving unit 500 (part of the cipher suite investigation means) that processes (interprets) the handshake_failure message.

  (FIG. 20-(S14)) Server Hello receiving part 500 (a part of encryption sweet investigation means) sends the received message to SSL negotiation processing part 600 when "current counter" 710 is 0 (that is, (B Go to)). Note that the SSL negotiation processing unit 600 performs negotiation processing in SSL / TLS encryption communication after the Server Hello / Server Certificate / Server Hello Done message processing.

  (FIG. 20-(S15)) The SSL negotiation process part 600 processes a Server Hello / Server Certificate / Server Hello Done message, and produces | generates a common key. Next, a Client Key Exchange / Change Cipher Spec / Finished message is generated and sent to the data transmission unit 110.

  (FIG. 20-(S16)) The data transmission part 110 transmits a Client Key Exchange / Change Cipher Spec / Finished message to the server 2 via the network control apparatus 100.

(FIG. 20- (S17)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2. (FIG. 11- (S9)) The data receiving unit 220 of the server 2 transmits the Client Key Exchange / Change transmitted by the client 1. A Cipher Spec / Finished message is received via the network control device 200. The data receiving unit 220 processes (interprets) this Client Key Exchange / Change Cipher Spec / Finished message to the Client Key Exchange / Change Cipher Spec / Finished message. Note that the SSL negotiation processing unit 610 performs negotiation processing in SSL / TLS encryption communication after the client key exchange / change cipher spec / finished message processing.

  (FIG. 11-(S11)) SSL negotiation process part 610 processes a Client Key Exchange / Change Cipher Spec / Finished message, and produces | generates a common key. Next, a Change Cipher Spec / Finished message is generated and sent to the data transmission unit 210.

  (FIG. 11-(S12)) The data transmission part 210 transmits a Change Cipher Spec / Finished message to the client 1 via the network control apparatus 200.

  Although not shown in the functional block diagram, the server 2 thereafter performs cryptographic communication with the client 1 using the created common key. The encryption communication is a common key encryption process defined by SSL / TLS encryption communication, and a hash process is performed simultaneously with the encryption process. Therefore, the common key here means a key used in each of the cryptographic processing and the hash processing.

  (FIG. 20-(S17)) The data receiver 120 of the client 1 receives the Change Cipher Spec / Finished message transmitted by the server 2 via the network control device 100. The data receiving unit 220 sends this Change Cipher Spec / Finished message to the SSL negotiation processing unit 600 that processes (interprets) the Change Cipher Spec / Finished message.

  (FIG. 20-(S18)) The SSL negotiation process part 600 processes a Change Cipher Spec / Finished message.

  Although not shown in the functional block diagram, after this, the client 1 performs cryptographic communication with the server 2 using the created common key.

  Note that FIG. 12 shows an example of the hardware configuration diagram of FIG. 19, similarly to FIGS. 9 and 15. Since the explanation is the same, I will omit it.

  FIG. 21 is a sequence diagram showing a fourth example of SSL / TLS encryption communication according to the embodiment of the present invention.

(FIG. 21-(S1)) The client knows that the server supports the following cipher suites by examining the installation status of the cipher suites supported by the server.
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
(FIG. 21-(S <b> 2)) In selecting a cipher suite, the client tries to select a cipher suite having a higher priority among cipher suites held by the client. Don't select, lower priority until appropriate item appears.

The cipher suites with the client priorities 1 and 2 are not selected because they do not correspond to the cipher suites. The client selects a cipher suite with priority 3 as described below.
TLS_RSA_WITH_AES_128_CBC_SHA
As described with reference to FIG. 1, the explanation is given in the case where there is only one cipher suite having the same priority. However, in all the figures including this figure, any number of cipher suites having the same priority may be used. I do not care. If there are a plurality of cipher suites of the same priority supported by the server, the cipher suite may be narrowed down to one as desired, or a plurality or all cipher suites may be selected. When selecting a plurality of cipher suites, Client Hello specifying a plurality of cipher suites is transmitted. For the sake of simplicity, it is assumed here that there is only one cipher suite with the same priority.

  (FIG. 21-(S3)) A client designates this selected encryption sweet and transmits Client Hello to a server. (FIG. 21-(S4)) Since a server hold | maintains this designated encryption sweet, Server Hello is transmitted to a client by this designated encryption sweet. Although not shown, SSL / TLS negotiation is correctly executed after this, and common key encryption communication in SSL / TLS encryption communication is started.

  FIG. 22 is a sequence diagram showing a sixth example of the method “investigating the installation status of the cipher suites supported by the server” in the embodiment of the present invention, and the “installation status of the cipher suites supported by the server” in FIG. It is also a sequence diagram showing an example of a method of “investigating”. The sequence is almost the same as that shown in FIGS. This also clearly separates the phase of “investigating on-board information of cipher suites on the server” and the phase of “selecting cipher suites to use”.

  In FIG. 14, the cipher suites supported by the server in the cipher suites supported by the client are investigated. In FIG. 22, the cipher suites supported by the server are investigated regardless of the cipher suites supported by the client. . Examining all cipher suites has the disadvantage of time-consuming, but eliminates the need to re-investigate when cipher suites supported by the client are added. For example, it is convenient when there is a mechanism in which a client device can add a cipher suite by software download or the like.

  Although all cipher suites supported by the server are investigated here, some cipher suites may be investigated. It is reasonable to exclude such cipher suites when it is clear that the client device will never use them in the future. For example, it is preferable to exclude cipher suites that are currently weak in security and cannot be used.

  As can be seen from the above description, the investigation of the cipher suites supported by the server may be replaced with the investigation of the cipher suites not supported by the server. Since this is the same, detailed description is omitted.

  Next, detailed description of FIG. 22 will be given. Here, the client transmits Client Hello specifying one cipher suite in order to investigate the installation status of the cipher suite of the server. If an alert (handshake_failure) is returned, the server determines that the cipher suite is not held.

  In addition, the client holds “cipher suite information defined in the SSL / TLS specification”. This information is basically all cipher suite information defined in the SSL / TLS specification, but as explained above, cipher suites that the client knows not to use in the future are removed. May be.

  (FIG. 22-(S1)) The client sees "cipher suite information defined in the SSL / TLS specification", designates "TLS_RSA_WITH_RC4_128_MD5" which is the cipher suite posted therein, and transmits Client Hello. . (FIG. 22-(S2)) Since the server does not support "TLS_RSA_WITH_RC4_128_MD5", an alert (handshake_failure) is returned. As a result, the client knows that the server does not support TLS_RSA_WITH_RC4_128_MD5. Although this cipher suite may be stored as not supported, it is not stored in the description here. (FIG. 22-(S3)) And communication is cut | disconnected.

  (FIG. 22-(S4)) Next, the client looks at “cipher suite information defined in the SSL / TLS specification”, designates “TLS_RSA_WITH_RC4_128_SHA”, which is the cipher suite listed therein, and client Hello. Send. (FIG. 22-(S5)) Since the server does not support "TLS_RSA_WITH_RC4_128_SHA", an alert (handshake_failure) is returned. As a result, the client knows that the server does not support “TLS_RSA_WITH_RC4_128_SHA”. Although this cipher suite may be stored as not supported, it is not stored in the description here. (FIG. 22-(S6)) And communication is cut | disconnected.

  (FIG. 22-(S7)) Next, the client looks at “cipher suite information defined in the SSL / TLS specification”, designates “TLS_RSA_WITH_AES_128_CBC_SHA”, which is the cipher suite listed therein, and client Hello. Send. (FIG. 22-(S8)) Since the server supports "TLS_RSA_WITH_AES_128_CBC_SHA", it returns Server Hello. As a result, the client knows that the server supports “TLS_RSA_WITH_AES_128_CBC_SHA”. Note that this cipher suite is stored as being supported. (FIG. 22-(S9)) And communication is cut | disconnected.

  In this way, the client looks at “cipher suite information defined in the SSL / TLS specification” and checks whether the server is equipped with the cipher suites listed therein. .

  Through the above-described procedure, the client supports at least the cipher that the server supports “TLS” which is the information that the server supports “TLS_RSA_WITH_3DES_EDE_CBC_SHA”, “TLS_RSA_WITH_AES_128_CBC_SHA”, and “TLS_RSA_WIES_256_CBC_SHA”.

  In this example, the survey is performed in the order of “TLS_RSA_WITH_RC4_128_MD5”, “TLS_RSA_WITH_RC4_128_SHA”, “TLS_RSA_WITH_AES_128_CBC_SHA”,...

  In addition, like FIG.2, FIG.7, FIG.8, FIG.14, FIG.18, although it has shown in figure so that the process after this may be processed continuously, here, a process is stopped once and actually encryption communication is carried out. When performing the above, the subsequent processing may be performed. Here, in order to simplify the explanation, it is assumed that the subsequent processing is continuously performed.

  In addition, if the client stores “information on the cipher suites supported by the server”, it will use the “information on cipher suites supported by the server” from the next time, without investigating the server's cipher suite information. As a result, it is possible to immediately proceed to the next process (FIG. 22- (S10)).

  (FIG. 22-(S10)) Next, the client selects the cipher suite to be used in order to actually perform SSL / TLS cipher communication with the server. Among the cipher suites supported by the server, “TLS_RSA_WITH_AES_128_CBC_SHA”, which is the cipher suite with the highest priority in the client, is selected as the cipher suite.

  (FIG. 22-(S11)) Then, the client transmits Client Hello specifying "TLS_RSA_WITH_AES_128_CBC_SHA" to transmit the cipher suite to be used to the server. (FIG. 22-(S12)) Since the server supports "TLS_RSA_WITH_AES_128_CBC_SHA", it designates "TLS_RSA_WITH_AES_128_CBC_SHA" and returns Server Hello. As a result, the client performs SSL / TLS negotiation with the server using “TLS_RSA_WITH_AES_128_CBC_SHA”. Thereafter, SSL / TLS negotiation is correctly executed, and communication of common key encryption in SSL / TLS encryption communication is started.

  FIG. 23 is a diagram showing a fifth example of functional blocks in the embodiment of the present invention, and is also an example of the functional block diagram of FIG. FIG. 24 is a diagram showing a fifth example of the flowchart on the client side in the embodiment of the present invention, and is a flowchart of the client 1 in FIG. The flowchart of the server 2 in FIG. 23 is the same as that in FIG. Next, description will be made with reference to FIGS. 23, 24, and 11. FIG.

  The client 1 starts SSL / TLS encrypted communication with the server 2 via the network. The client 1 assigns the priorities of the cipher suites that the client 1 wants to use with the “priority information of cipher suites supported by the client”, and the installation information 800 (installation status storage means) The cipher suite supported by the server 2 is checked. Note that unsupported cipher suites may be checked as being unsupported, but here, in order to simplify the description, only supported cipher suites are checked.

  Further, in order to investigate the cipher suites supported by the server, the client holds the “cipher suite information defined in the SSL / TLS specifications” described above. This information is basically all cipher suite information defined in the SSL / TLS specification, but as explained above, cipher suites that the client knows not to use in the future are removed. May be. Here, the mounting information 800 (mounting status storage means) stores whether each cipher suite listed in “Information on cipher suites defined in the SSL / TLS specifications” is supported. It is said. Note that the storage means is not limited to this, and there are various methods for the storage means, such as memorizing the numbers of unsupported cipher suites.

  Further, the client 1 is provided with a “current counter” 710 indicating which cipher suite is to be investigated when investigating the installation status of the cipher suite of the server. The “cipher suite information defined in the SSL / TLS specification” defines not only the cipher suite information but also the order in which each cipher suite is examined. If the order is input, the client 1 is configured to investigate the cipher suites in that order.

  When 0 is assigned to the “current counter” 710, the client 1 does not check the installation status of the cipher suite of the server, performs normal SSL / TLS negotiation, and performs SSL / TLS cipher communication. ing. Here, the initial value of the “current counter” 710 is 1.

  (FIG. 24-(S <b> 1)) First, the Client Hello generation unit 400 (part of the cipher suite investigation unit) obtains the cipher suite from “cipher suite information defined in the SSL / TLS specification” and “current counter” 710. Read the information. Initially, the value of the “current counter” 710 is “1”, but this is described as “TLS_RSA_WITH_RC4_128_MD5” in “cipher suite information defined in the SSL / TLS specifications”.

  (FIG. 24-(S2)) Client Hello production | generation part 400 (a part of encryption sweet investigation means) produces | generates the Client Hello message which designated "TLS_RSA_WITH_RC4_128_MD5" as an encryption sweet, and sends this to the data transmission part 110. FIG.

  (FIG. 24-(S3)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 24-(S4)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 11-(S1)) The server 2 starts in a state waiting for receiving a message from the client 1. The data receiving unit 220 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 11-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 11-(S3)) “TLS_RSA_WITH_RC4_128_MD5” is specified as a cipher suite in the Client Hello message, but since the server 2 does not support this, the Client Hello receiving unit 410 generates a handshake_failure message, This is sent to the data transmission unit 210.

  (FIG. 11-(S4)) The data transmission part 210 transmits a handshake_failure message with respect to the client 1 via the network control apparatus 200. FIG.

  (FIG. 11-(S5)) Thereafter, the client hello receiving unit 410 disconnects communication with the client 1, and the server 2 again enters a state of waiting for receiving a client hello message from the client 1.

  (FIG. 24-(S <b> 4)) The data receiving unit 120 of the client 1 receives the handshake_failure message transmitted by the server 2 via the network control device 100. The data receiving unit 120 sends the handshake_failure message to the Server Hello receiving unit 500 (part of the cipher suite checking means) that processes (interprets) the handshake_failure message.

  (FIG. 24-(S5)) Server Hello receiving part 500 (a part of encryption sweet investigation means) checks whether the received message is a handshake_failure message. The Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the mounting information 800 (mounting status storage means) because the received message is a handshake_failure message.

  (FIG. 24-(S7)) Next, Server Hello receiving part 500 (a part of encryption sweet investigation means) cut | disconnects communication, and adds 1 to the "current counter" 710. FIG.

(FIG. 24-(S8)) The Server Hello receiving unit 500 (part of the cipher suite checking means) determines whether the value of the “current counter” 710 exceeds the number of cipher suites to check = MAX value.
Value of “current counter” 710 = MAX + 1
Check whether or not. Here, since the value of the “current counter” 710 is 2, the Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the “current counter” 710 and does not process the Client Hello generating unit 400. (Part of the cipher suite investigation means) is called (that is, the process proceeds to (A)).
(FIG. 24-(S1)) Next, the Client Hello generation part 400 (a part of encryption sweet investigation means) encrypts from "the encryption sweet information defined by the SSL / TLS specification" and the "current counter" 710. Read suite information. The value of the “current counter” 710 is 2, but it is assumed that this corresponds to “TLS_RSA_WITH_RC4_128_SHA” in “cipher suite information defined in the SSL / TLS specification”.

  Thereafter, the flow is the same as that in the case of “TLS_RSA_WITH_RC4_128_MD5” for both the client 1 and the server 2. Since the server 2 does not support “TLS_RSA_WITH_RC4_128_SHA”, no processing is performed on the mounting information 800 (mounting status storage unit).

  (FIG. 24-(S7)) Next, Server Hello receiving part 500 (a part of encryption sweet investigation means) cut | disconnects communication, and adds 1 to the "current counter" 710. FIG.

(FIG. 24-(S8)) The Server Hello receiving unit 500 (part of the cipher suite checking means) determines whether the value of the “current counter” 710 exceeds the number of cipher suites to check = MAX value.
Value of “current counter” 710 = MAX + 1
Check whether or not. Here, since the value of the “current counter” 710 is 3, the Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the “current counter” 710 and does not process the Client Hello generating unit 400. (Part of the cipher suite investigation means) is called (that is, the process proceeds to (A)).
(FIG. 24-(S1)) Next, the Client Hello generation part 400 (a part of encryption sweet investigation means) encrypts from "the encryption sweet information defined by the SSL / TLS specification" and the "current counter" 710. Read suite information. Although the value of the “current counter” 710 is 3, it is assumed that this corresponds to “TLS_RSA_WITH_AES_128_CBC_SHA” in “cipher suite information defined in the SSL / TLS specifications”.

  (FIG. 24-(S2)) Client Hello production | generation part 400 (a part of encryption sweet investigation means) produces | generates the Client Hello message which designated "TLS_RSA_WITH_AES_128_CBC_SHA" as an encryption sweet, and sends this to the data transmission part 110. FIG.

  (FIG. 24-(S3)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 24-(S4)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 11-(S1)) The data receiver 220 of the server 2 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 11-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 11-(S6)) Since the server 2 supports "TLS_RSA_WITH_AES_128_CBC_SHA", the Client Hello reception part 410 processes this Client Hello message, and calls the Server Hello production | generation part 510. FIG.

  (FIG. 11-(S7)) The Server Hello production | generation part 510 produces | generates a Server Hello / Server Certificate / Server Hello Done message, and sends this to the data transmission part 210. FIG.

  (FIG. 11-(S8)) The data transmission part 210 transmits a Server Hello / Server Certificate / Server Hello Done message to the client 1 via the network control device 200.

  (FIG. 11-(S9)) Thereafter, the server 2 enters a state of waiting for a message from the client 1.

  (FIG. 24-(S <b> 4)) The data reception unit 120 of the client 1 receives the Server Hello / Server Certificate / Server Hello Done message transmitted by the server 2 via the network control device 100. The data receiving unit 120 sends the Server Hello / Server Certificate / Server Hello Done message to the Server Hello receiving unit 500 (part of the cipher suite investigation means) that processes (interprets) the handshake_failure message.

  (FIG. 16-(S5)) Server Hello receiving part 500 (a part of encryption sweet investigation means) checks whether the received message is a handshake_failure message.

  (FIG. 24-(S6)) Since the received message is not a handshake_failure message, the server hello receiving unit 500 (part of the cipher suite checking means) stores “TLS_RSA_WITH_AES_128_CBC_SHA” in the mounting information 800 (mounting status storage means). Remember to support.

  (FIG. 24-(S7)) Next, Server Hello receiving part 500 (a part of encryption sweet investigation means) cut | disconnects communication, and adds 1 to the "current counter" 710. FIG.

(FIG. 24-(S8)) The Server Hello receiving unit 500 (part of the cipher suite checking means) determines whether the value of the “current counter” 710 exceeds the number of cipher suites to check = MAX value.
Value of “current counter” 710 = MAX + 1
Check whether or not. Here, since the value of the “current counter” 710 is 4, the Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the “current counter” 710 and does not process the Client Hello generating unit 400. (Part of the cipher suite investigation means) is called (that is, the process proceeds to (A)).
(FIG. 11-(S <b> 9)) Although the server 2 is in a state waiting for receiving a message from the client 1, communication has been cut off from the client 1. become. In addition, in the flowchart of FIG. 11, (S9) and (S10) are illustrated separately for easy understanding, but actually, the communication disconnection process of (S10) is performed in the message reception process of (S9). Executed.

(FIG. 24-(S1)) Next, the Client Hello generation part 400 (a part of encryption sweet investigation means) encrypts from "the encryption sweet information defined by the SSL / TLS specification" and the "current counter" 710. Read suite information.
With such a procedure, the client 1 sequentially examines the cipher suites listed in “cipher suite information defined in the SSL / TLS specifications”. When all the surveys are completed ((S9) in FIG. 24), the Server Hello receiving unit 500 (part of the cipher suite surveying unit) sets 0 to the “current counter” 710 to generate the Client Hello. Call the part 400 (that is, go to (A)).
When the survey is completed, the client 1 checks the mounting information 800 (mounting status storage means) that the server 2 supports the following cipher suites.
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
(FIG. 24-(S10)) Next, when the "current counter" 710 is 0, the Client Hello production | generation part 400 selects the encryption sweet to use from the mounting information 800 (mounting condition memory | storage means). Specifically, the selection is as follows. (1) The client hello generating unit 400 knows from the mounting information 800 (mounting status storage means) that “TLS_RSA_WITH_RC4_128_MD5” of priority 1 is not supported. (2) Next, the client hello generating unit 400 knows from the mounting information 800 (mounting status storage means) that “TLS_RSA_WITH_RC4_128_SHA” of priority 2 is not supported. (3) Next, the client hello generating unit 400 knows that “TLS_RSA_WITH_AES_128_CBC_SHA” with priority 3 is supported from the mounting information 800 (mounting status storage means). Therefore, the client hello generating unit 400 selects “TLS_RSA_WITH_AES_128_CBC_SHA” as the cipher suite.

  Here, the client hello generating unit 400 has been described as selecting the information of the mounting information 800 (mounting status storage unit) from the one with the highest priority, but the method of selecting the cipher suite is not limited to this. Conversely, the cipher suite that is checked last may be selected in order from the lowest priority. As described above, there are various methods for selecting a cipher suite from the mounting information 800 (mounting status storage unit).

  (FIG. 24-(S11)) The Client Hello production | generation part 400 produces | generates the Client Hello message which designated "TLS_RSA_WITH_AES_128_CBC_SHA" as a cipher suite, and sends this to the data transmission part 110. FIG.

  (FIG. 24-(S12)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 24-(S13)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 11-(S1)) The data receiver 220 of the server 2 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 11-(S2)) The Client Hello reception part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 11-(S6)) Since the server 2 supports "TLS_RSA_WITH_AES_128_CBC_SHA", the Client Hello reception part 410 processes this Client Hello message, and calls the Server Hello production | generation part 510. FIG.

  (FIG. 11-(S7)) The Server Hello production | generation part 510 produces | generates a Server Hello / Server Certificate / Server Hello Done message, and sends this to the data transmission part 210. FIG.

  (FIG. 11-(S8)) The data transmission part 210 transmits a Server Hello / Server Certificate / Server Hello Done message to the client 1 via the network control device 200.

  (FIG. 11-(S9)) Thereafter, the server 2 enters a state of waiting for a message from the client 1.

  (FIG. 24-(S13)) The data reception part 120 of the client 1 receives the Server Hello / Server Certificate / Server Hello Done message which the server 2 transmitted via the network control apparatus 100. FIG. The data receiving unit 120 sends the Server Hello / Server Certificate / Server Hello Done message to the Server Hello receiving unit 500 (part of the cipher suite investigation means) that processes (interprets) the handshake_failure message.

  (FIG. 24-(S14)) When the "current counter" 710 is 0, the Server Hello receiving part 500 (a part of encryption sweet investigation means) sends the received message to the SSL negotiation process part 600 (that is, (B Go to)). Note that the SSL negotiation processing unit 600 performs negotiation processing in SSL / TLS encryption communication after the Server Hello / Server Certificate / Server Hello Done message processing.

  (FIG. 24-(S15)) The SSL negotiation process part 600 processes a Server Hello / Server Certificate / Server Hello Done message, and produces | generates a common key. Next, a Client Key Exchange / Change Cipher Spec / Finished message is generated and sent to the data transmission unit 110.

  (FIG. 24-(S16)) The data transmission part 110 transmits a Client Key Exchange / Change Cipher Spec / Finished message with respect to the server 2 via the network control apparatus 100. FIG.

(FIG. 24-(S17)) Thereafter, the client 1 enters a state of waiting to receive a message from the server 2. (FIG. 11-(S9)) The data receiving unit 220 of the server 2 transmits the Client Key Exchange / Change transmitted by the client 1. A Cipher Spec / Finished message is received via the network control device 200. The data receiving unit 220 processes (interprets) this Client Key Exchange / Change Cipher Spec / Finished message to the Client Key Exchange / Change Cipher Spec / Finished message. Note that the SSL negotiation processing unit 610 performs negotiation processing in SSL / TLS encryption communication after the client key exchange / change cipher spec / finished message processing.

  (FIG. 11-(S11)) SSL negotiation process part 610 processes a Client Key Exchange / Change Cipher Spec / Finished message, and produces | generates a common key. Next, a Change Cipher Spec / Finished message is generated and sent to the data transmission unit 210.

  (FIG. 11-(S12)) The data transmission part 210 transmits a Change Cipher Spec / Finished message to the client 1 via the network control apparatus 200.

  Although not shown in the functional block diagram, the server 2 thereafter performs cryptographic communication with the client 1 using the created common key. The encryption communication is a common key encryption process defined by SSL / TLS encryption communication, and a hash process is performed simultaneously with the encryption process. Therefore, the common key here means a key used in each of the cryptographic processing and the hash processing.

  (FIG. 24-(S17)) The data receiver 120 of the client 1 receives the Change Cipher Spec / Finished message transmitted from the server 2 via the network control device 100. The data receiving unit 220 sends this Change Cipher Spec / Finished message to the SSL negotiation processing unit 600 that processes (interprets) the Change Cipher Spec / Finished message.

  (FIG. 24-(S18)) The SSL negotiation process part 600 processes a Change Cipher Spec / Finished message.

  Although not shown in the functional block diagram, after this, the client 1 performs cryptographic communication with the server 2 using the created common key.

  25 is a diagram showing a third example of the hardware configuration in the embodiment of the present invention, and is also an example of the hardware configuration diagram of FIG. The client 1 executes data transmission / reception of the network with the CPU 10 that executes program processing, the RAM 20 that is a temporary storage memory, the HDD (hard disk) 30 that is a rewritable nonvolatile memory, and the ROM 40 that is a non-rewritable nonvolatile memory. MAC / PHY50. On the other hand, the server 2 includes a CPU 11 that executes program processing, a RAM 21 that is a temporary storage memory, a ROM 41 that is a non-rewritable nonvolatile memory, and a MAC / PHY 51 that executes network data transmission / reception. The client 1 and the server 2 are connected to each other via a network via a MAC / PHY 50 and a MAC / PHY 51.

  First, the hardware configuration of the client 1 will be described. Each processing unit of the client 1 illustrated in FIG. 23 is executed by the CPU 10 and the RAM 20.

  The “current counter” 710 and the mounting information 800 (mounting status storage means) are arranged in the RAM 20, which is a temporary storage memory, but may be any rewritable memory, such as the HDD (hard disk) 30 or the flash. You may arrange | position to ROM etc.

  Next, “priority information of cipher suites supported by the client” is preferably arranged in a rewritable nonvolatile memory. In this figure, an HDD (hard disk) 30 is used as a rewritable nonvolatile memory, but any type of rewritable nonvolatile memory such as a flash ROM may be used. Although operation is possible even if “priority information on cipher suites supported by the client” is arranged in the RAM 20 which is a temporary storage memory, it is not preferable because it takes time to register the priority every time.

  Note that “priority information on cipher suites supported by the client” is determined at the time of mounting, and if the priority is not changed after mounting, the cipher suites may be arranged in the ROM 40, which is a non-rewritable nonvolatile memory.

  The “cipher suite supported by the client” is a program of an actual cipher suite, and is usually placed in a non-volatile memory. In order to avoid confusing the description, the functional block diagram of the client 1 does not show “cipher suites supported by the client”, but as shown in the functional block diagram of the server 2, This is necessary for cryptographic communication. Here, “encryption suite supported by the client” is arranged in the ROM 40, but the present invention is not limited to this. When the cipher suite program is downloaded from the server and used every time, it can be arranged in a volatile memory such as the RAM 20.

  Next, “cipher suite information defined in the SSL / TLS specification” is basically information that is not rewritten, so it is preferable to place it in a non-volatile memory such as the ROM 40. However, in devices that are used for a long period of time, there may be cases where it is desired to exclude a cipher suite whose security level has been lowered in the meantime. is there.

  The MAC / PHY 50 is hardware that controls network communication, and implements the network control device 100.

  Next, the hardware configuration of the server 2 will be described. Each processing unit of the server 2 illustrated in FIG. 23 is executed by the CPU 11 and the RAM 21.

  The “cipher suite supported by the server” is a program of an actual cipher suite, and is usually placed in a non-volatile memory. Here, “encryption suite supported by the server” is arranged in the ROM 41, but the present invention is not limited to this. When the cipher suite program is downloaded from another server and used every time, it can be arranged in a volatile memory such as the RAM 21.

  The MAC / PHY 51 is hardware that controls network communication, and implements the network control device 200.

  FIG. 26 is a sequence diagram showing a seventh example of the method “investigating the installation status of the cipher suites supported by the server” in the embodiment of the present invention, and the “cipher suites supported by the server” shown in FIG. It is also a sequence diagram showing another example of the “investigation of mounting status” method. In FIG. 26, as in FIG. 8, among cipher suites supported by the client, cipher suites not supported by the server are investigated.

  However, unlike FIG. 8, in FIG. 26, the cipher suites supported by the server are not investigated one by one, but a means for presenting a plurality of cipher suites in Client Hello is used. .

  Next, a detailed description of FIG. 26 will be given. Here, the client transmits Client Hello designated by a plurality of cipher suites supported by the client in order to investigate the installation status of the cipher suite of the server. If an alert (handshake_failure) is returned, the server determines that the plurality of cipher suites are not held.

(FIG. 26-(S1)) A client designates all the cipher suites which oneself supports, and transmits Client Hello. Although all cipher suites are specified here, some cipher suites may be used. Here, description will be made assuming that the following cipher suite is specified.
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
(FIG. 26- (S2)) In the case of a server that does not determine the priority order of cipher suites, the cipher suite described at the top of the cipher suites specified by Client Hello is selected from the cipher suites supported by itself. And return Server Hello. In the case of a server that determines the priority order of cipher suites, the cipher suite having the highest priority order for the server is selected from the cipher suites specified by Client Hello, and Server Hello is returned. Here, a description will be given on the assumption that the server has selected “TLS_RSA_WITH_AES_128_CBC_SHA”. The server returns a Server Hello specifying “TLS_RSA_WITH_AES_128_CBC_SHA”.

  The client knows that the server supports “TLS_RSA_WITH_AES_128_CBC_SHA” by this Server Hello. Although this is not illustrated here as storing it, it may be stored. (FIG. 26-(S3)) And communication is cut | disconnected.

(FIG. 26-(S4)) Next, a client transmits Client Hello which designated the following encryption sweets which excluded this "TLS_RSA_WITH_AES_128_CBC_SHA" from the encryption sweet first designated to the server.
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
(FIG. 26-(S5)) Since the server supports "TLS_RSA_WITH_AES_256_CBC_SHA", it returns Server Hello specifying "TLS_RSA_WITH_AES_256_CBC_SHA".

  The client knows from this Server Hello that the server supports “TLS_RSA_WITH_AES_256_CBC_SHA”. Although this is not illustrated here as storing it, it may be stored. (FIG. 26-(S6)) And communication is cut | disconnected.

(FIG. 26-(S7)) Next, the client transmits Client Hello specifying the following cipher suites, excluding this "TLS_RSA_WITH_AES_256_CBC_SHA" from the cipher suites specified for the server second.
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
(FIG. 26-(S8)) Since the server does not support the cipher suite, an alert (handshake_failure) is returned. As a result, the client knows that the server does not support “TLS_RSA_WITH_RC4_128_MD5” and “TLS_RSA_WITH_RC4_128_SHA”. The client remembers that this cipher suite is not supported. (FIG. 26-(S9)) And communication is cut | disconnected.

  The subsequent procedure is the same as in FIG. As can be seen by comparing FIG. 26 and FIG. 8, the number of man-hours is smaller in FIG. 26 for investigating the installation status of the encryption suite of the server. This enables a quick investigation.

  According to this method, it is possible to know the priority order determined by the server for the server that determines the priority order of the cipher suites.

  FIG. 27 is a sequence diagram illustrating an eighth example of the method “investigating the installation status of the cipher suites supported by the server” according to the embodiment of the present invention, and the “cipher suites supported by the server” illustrated in FIG. It is also a sequence diagram showing another example of the “investigation of mounting status” method. In FIG. 27, as in FIG. 18, the cipher suite having the highest client priority among the cipher suites supported by the server is investigated.

  However, unlike FIG. 18, in FIG. 27, the cipher suites supported by the server are not investigated one by one, but a means for presenting a plurality of cipher suites in Client Hello is used. .

  Next, detailed description of FIG. 27 will be given. Here, the client transmits Client Hello designated by a plurality of cipher suites supported by the client in order to investigate the installation status of the cipher suite of the server. If an alert (handshake_failure) is returned, the server determines that the plurality of cipher suites are not held.

(FIG. 27-(S1)) A client designates all the encryption sweets which oneself supports, and transmits Client Hello. Although all cipher suites are specified here, some cipher suites may be used. Here, description will be made assuming that the following cipher suite is specified.
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
(FIG. 27-(S2)) In the case of the server which does not determine the priority of a cipher suite, it selects the cipher suite described in the highest rank from the cipher suites specified by Client Hello among cipher suites supported by itself. And return Server Hello. In the case of a server that determines the priority order of cipher suites, the cipher suite having the highest priority order for the server is selected from the cipher suites specified by Client Hello, and Server Hello is returned. Here, a description will be given on the assumption that the server has selected “TLS_RSA_WITH_AES_128_CBC_SHA”. The server returns a Server Hello specifying “TLS_RSA_WITH_AES_128_CBC_SHA”.

  The client knows that the server supports “TLS_RSA_WITH_AES_128_CBC_SHA” by this Server Hello. The client remembers this. (FIG. 27-(S3)) And communication is cut | disconnected.

  (FIG. 27- (S4)) Next, the client transmits this “TLS_RSA_WITH_AES_128_CBC_SHA” and Client Hello excluding all cipher suites with lower priorities from the cipher suite specified for the server.

In this example, there is only one cipher suite having a lower priority than “TLS_RSA_WITH_AES_128_CBC_SHA”, which is “TLS_RSA_WITH_AES_256_CBC_SHA”. Therefore, in this example, Client Hello specifying the following cipher suite is transmitted.
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
(FIG. 27-(S5)) Since the server does not support the cipher suite, an alert (handshake_failure) is returned. As a result, the client knows that the server does not support “TLS_RSA_WITH_RC4_128_MD5” and “TLS_RSA_WITH_RC4_128_SHA”. Accordingly, the client knows that “TLS_RSA_WITH_AES_128_CBC_SHA” is the cipher suite having the highest client priority among cipher suites supported by the server. (FIG. 27-(S9)) And communication is cut | disconnected.

  In this example, after “TLS_RSA_WITH_AES_128_CBC_SHA”, the server returns an alert (handshake_failure). For example, the server returns a server Hello in “TLS_RSA_WITH_RC4_128_SHA”. This “TLS_RSA_WITH_RC4_128_SHA” is stored instead of “TLS_RSA_WITH_AES_128_CBC_SHA”.

  The subsequent procedure is the same as in FIG. As can be seen by comparing FIG. 27 and FIG. 18, the number of man-hours is smaller in FIG. 26 for investigating the installation status of the cipher suite of the server. This enables a quick investigation.

  The procedures in FIGS. 26 and 27 exemplify another investigation method in FIGS. 8 and 18, but this procedure can be applied to other diagrams.

  FIG. 28 is a sequence diagram showing a ninth example of the method “investigating the installation status of the cipher suites supported by the server” according to the embodiment of the present invention, and shows the “cipher suites supported by the server” shown in FIG. It is also a sequence diagram showing another example of the “investigation of mounting status” method. In FIG. 28, as in FIG. 8, among cipher suites supported by the client, cipher suites not supported by the server are investigated.

  However, in FIG. 28, unlike FIG. 8, the TCP port number used to investigate the cipher suite supported by the server is different from the TCP port number actually performing SSL / TLS encryption communication.

  In FIG. 28, the client side includes an application (application) and an SSL (SSL / TLS) module / SSL (SSL / TLS) task. As shown in FIG. 28, if the TCP port number to be used is separated from the TCP port number that actually performs SSL / TLS encrypted communication, the cipher suite that the server supports the TCP port number designated by the application side for SSL / TLS encrypted communication. It becomes unnecessary to use it for the investigation.

  If the TCP port number specified for SSL / TLS encryption communication on the application side is used for investigation of the cipher suite supported by the server, the application side must acquire the TCP port number again every time communication is disconnected. It makes programming difficult. As shown in FIG. 28, if the TCP (SSL / TLS) module / SSL (SSL / TLS) task separately prepares the TCP port number used for the investigation of the cipher suite supported by the server, the application side can set the SSL / The TCP port number designated for TLS encryption communication is not disconnected, and programming is very simple when viewed from the application side.

  Note that the procedure is the same as in FIG. 8 except that the TCP port number used for investigating the cipher suite supported by the server is different from the TCP port number that actually performs SSL / TLS encrypted communication. .

  This procedure can also be applied to other figures.

  FIG. 29 is a sequence diagram showing a fifth example of SSL / TLS encryption communication in the embodiment of the present invention. FIG. 29 investigates the cipher suites supported by both the server and the client, as in FIG. However, the investigation method uses the same method as in FIGS. Although the same method as that of FIG. 14 may be used, the explanation of FIG. 26 and FIG. 27 omits the explanation of the functional block diagram and the flowchart. This method is used here.

  In FIG. 29, cipher suites are switched in actual SSL / TLS cipher communication. This is the essence of this figure. First, in order to perform authentication, the client selects and uses “TLS_RSA_WITH_AES_128_CBC_SHA”, which is the cipher suite with the highest security level among cipher suites supported by the client.

  For communication (delivery of ordinary communication data), the client selects and uses “TLS_RSA_WITH_RC4_128_MD5”, which is the cipher suite that can be processed at the highest speed among cipher suites that the client supports.

  Even if it is a server that prioritizes the cipher suites used by the other party, according to the present invention, there is an advantage that the client can lead the cipher suite selection according to the purpose. In particular, this effect is significant when an embedded device having a vulnerable CPU is a client. Even in such an embedded device, it is possible to achieve both security and performance.

  Next, a detailed description of FIG. 29 will be given. Here, the client transmits Client Hello designated by a plurality of cipher suites supported by the client in order to investigate the installation status of the cipher suite of the server. If an alert (handshake_failure) is returned, the server determines that the plurality of cipher suites are not held.

(FIG. 29-(S1)) A client transmits all of the cipher suites which it supports, and transmits Client Hello. Although all cipher suites are specified here, some cipher suites may be used. Here, description will be made assuming that the following cipher suite is specified.
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
(FIG. 29-(S2)) In the case of the server which does not determine the priority of a cipher suite, it selects the cipher suite described in the highest rank from the cipher suites specified by Client Hello among cipher suites supported by itself. And return Server Hello. In the case of a server that determines the priority order of cipher suites, the cipher suite having the highest priority order for the server is selected from the cipher suites specified by Client Hello, and Server Hello is returned. Here, a description will be given on the assumption that the server has selected “TLS_RSA_WITH_AES_128_CBC_SHA”. The server returns a Server Hello specifying “TLS_RSA_WITH_AES_128_CBC_SHA”.

  The client knows that the server supports “TLS_RSA_WITH_AES_128_CBC_SHA” by this Server Hello. The client remembers this. (FIG. 29-(S3)) And communication is cut | disconnected.

(FIG. 29-(S4)) Next, a client transmits Client Hello which designated the following encryption sweets which excluded this "TLS_RSA_WITH_AES_128_CBC_SHA" from the encryption sweet first designated to the server.
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
(FIG. 29-(S5)) Since the server supports "TLS_RSA_WITH_AES_256_CBC_SHA", it returns Server Hello specifying "TLS_RSA_WITH_AES_256_CBC_SHA".

  The client knows from this Server Hello that the server supports “TLS_RSA_WITH_AES_256_CBC_SHA”. The client remembers this. (FIG. 29 (S6)) Then, the communication is disconnected.

(FIG. 29-(S7)) Next, a client transmits Client Hello which designated the following encryption sweets which excluded this "TLS_RSA_WITH_AES_256_CBC_SHA" from the encryption sweet designated to the server 2nd.
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
(FIG. 29-(S8)) Since the server does not support the cipher suite, an alert (handshake_failure) is returned. As a result, the client knows that the server does not support “TLS_RSA_WITH_RC4_128_MD5” and “TLS_RSA_WITH_RC4_128_SHA”. The client may store this cipher suite as not supported. By the procedure so far, the client knows that both the server and the client support “TLS_RSA_WITH_AES_128_CBC_SHA” and “TLS_RSA_WITH_AES_256_CBC_SHA”. (FIG. 29-(S9)) And communication is cut | disconnected.

  In addition, although it has shown in figure that the process after this is processed continuously, a process after this may be performed when the process is stopped here and actually performing encryption communication. Here, in order to simplify the explanation, it is assumed that the subsequent processing is continuously performed.

  (FIG. 29-(S13)) Next, the client selects the cipher suite to be used in order to actually perform SSL / TLS cipher communication with the server.

  Although not shown in FIG. 29, as shown in FIG. 30, the “cipher suite priority order” is given to the client for authentication (passing authentication data) and for communication (passing communication data), respectively. Information "exists. Here, a description will be given first assuming that the client authenticates to the server.

  The client selects a cipher suite using “TLS_RSA_WITH_AES_256_CBC_SHA” from “cipher suite priority order information (for authentication)” and “cipher suite information supported by both the server and the client”.

  (FIG. 29- (S14)) Then, the client transmits Client Hello specifying "TLS_RSA_WITH_AES_256_CBC_SHA" in order to transmit the cipher suite to be used to the server. (FIG. 29-(S15)) Since the server supports "TLS_RSA_WITH_AES_256_CBC_SHA", it specifies "TLS_RSA_WITH_AES_256_CBC_SHA" and returns Server Hello. As a result, the client performs SSL / TLS negotiation with the server using “TLS_RSA_WITH_AES_256_CBC_SHA”. Thereafter, SSL / TLS negotiation is correctly executed, and communication of common key encryption in SSL / TLS encryption communication is started. Then, authentication data is exchanged between the client and the server.

  (FIG. 29-(S16)) Next, a client shall communicate with a server. The client selects a cipher suite using “TLS_RSA_WITH_AES_128_CBC_SHA” from “cipher suite priority information (for communication)” and “cipher suite information supported by both the server and the client”.

  (FIG. 29- (S17)) Then, the client transmits Client Hello specifying "TLS_RSA_WITH_AES_128_CBC_SHA" to transmit the cipher suite to be used to the server. (FIG. 29-(S18)) Since the server supports "TLS_RSA_WITH_AES_128_CBC_SHA", it designates "TLS_RSA_WITH_AES_128_CBC_SHA" and returns Server Hello. As a result, the client performs SSL / TLS negotiation with the server using “TLS_RSA_WITH_AES_128_CBC_SHA”. Thereafter, SSL / TLS negotiation is correctly executed, and communication of common key encryption in SSL / TLS encryption communication is started. Communication data is exchanged between the client and the server.

  Since this SSL / TLS negotiation is a renegotiation, this SSL / TLS negotiation is normally executed in the previous encrypted communication. In this case, the SSL / TLS negotiation is performed by encrypting with “TLS_RSA_WITH_AES_256_CBC_SHA”. Encryption is started with “TLS_RSA_WITH_AES_128_CBC_SHA” from the time when the SSL / TLS negotiation is completed.

  FIG. 30 is a diagram showing a sixth example of functional blocks in the embodiment of the present invention, and is also an example of the functional block diagram of FIG. 31 and 32 are diagrams showing a sixth example of the flowchart on the client side in the embodiment of the present invention, and are also the flowchart of the client 1 in FIG. FIG. 33 is a diagram showing a third example of the flowchart on the server side in the embodiment of the present invention, and is also the flowchart of the server in FIG. 30. Next, description will be made with reference to FIGS. 30, 31, 32, and 33. FIG.

  The client 1 starts SSL / TLS encrypted communication with the server 2 via the network. The client 1 can grasp the cipher suites to be supported by “cipher suite information supported by the client”. In addition, the installation information 800 (installation status storage means) checks the cipher suites supported by the server 2 for each cipher suite. Note that unsupported cipher suites may be checked as being unsupported, but here, in order to simplify the description, only supported cipher suites are checked. Here, the mounting information 800 (loading status storage means) is stored for each cipher suite, but the storage means is not limited to this, and the number of unsupported cipher suites is remembered. There are various storage means.

  The client 1 has “cipher suite priority information” for authentication (passing authentication data) and for communication (passing communication data). In this way, prioritization of cipher suites to be used is performed according to the purpose.

  Further, the client 1 is provided with a flag 720 that indicates whether or not the installation status of the cipher suite of the server 2 is to be investigated. Only when this flag is TRUE, the client 1 is configured to investigate the installation status of the cipher suite of the server 2. It is assumed that TRUE is initially set in this flag 720.

(FIG. 31- (S1)) First, the client hello generating unit 400 (part of the cipher suite investigation unit) encrypts the “cipher suite information supported by the client” and the mounting information 800 (mounting state storage unit) held by itself. Read suite information. Initially, since there is no cipher suite checked in the mounting information 800 (mounting status storage means), all cipher suites listed in “cipher suite information supported by the client” are read. In this case, the following cipher suites are read.
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
(FIG. 31-(S2)) Client Hello production | generation part 400 (a part of encryption sweet investigation means) produces | generates the Client Hello message which designated the said encryption sweet, and sends this to the data transmission part 110. FIG.

  (FIG. 31-(S3)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 31-(S4)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 33-(S1)) The server 2 starts in a state waiting for receiving a message from the client 1. The data receiving unit 220 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 33-(S2)) Client Hello receiving part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  In the case of a server that does not determine the priority order of cipher suites, the cipher suite described at the highest level is selected from among cipher suites supported by the client, and the server hello is returned. In the case of a server that determines the priority order of cipher suites, the cipher suite having the highest priority order for the server is selected from the cipher suites specified by Client Hello, and Server Hello is returned. Here, a description will be given on the assumption that the server has selected “TLS_RSA_WITH_AES_128_CBC_SHA”.

  (FIG. 33-(S6)) Since the server 2 supports "TLS_RSA_WITH_AES_128_CBC_SHA", the Client Hello reception part 410 processes this Client Hello message, and calls the Server Hello production | generation part 510. FIG.

  (FIG. 33-(S7)) The Server Hello production | generation part 510 produces | generates a Server Hello / Server Certificate / Server Hello Done message, and sends this to the data transmission part 210. FIG.

  (FIG. 33-(S8)) The data transmission part 210 transmits a Server Hello / Server Certificate / Server Hello Done message with respect to the client 1 via the network control apparatus 200. FIG.

  (FIG. 33-(S9)) Thereafter, the server 2 enters a state of waiting for a message from the client 1.

  (FIG. 31-(S4)) The data reception part 120 of the client 1 receives the Server Hello / Server Certificate / Server Hello Done message which the server 2 transmitted via the network control apparatus 100. FIG. The data receiving unit 120 sends the Server Hello / Server Certificate / Server Hello Done message to the Server Hello receiving unit 500 (part of the cipher suite investigation means) that processes (interprets) the handshake_failure message.

  (FIG. 31-(S5)) Server Hello receiving part 500 (a part of encryption sweet investigation means) checks whether the received message is a handshake_failure message.

  (FIG. 31-(S6)) Since the received message is not a handshake_failure message, the server hello receiving unit 500 (part of the cipher suite checking means) indicates that the server 2 has “TLS_RSA_WITH_AES_128_CBC_SHA” in the mounting information 800 (mounting status storage means). Remember to support.

(FIG. 31- (S7)) Next, the Server Hello receiving unit 500 (part of the cipher suite investigation unit) disconnects communication and calls the Client Hello generation unit 400 (part of the cipher suite investigation unit) (that is, ( Go to A)).
(FIG. 33-(S <b> 9)) Although the server 2 is in a message reception waiting state from the client 1, the communication is disconnected from the client 1, so the server 2 exits this message reception waiting state and waits to receive the client hello. become. In addition, in the flowchart of FIG. 11, (S9) and (S10) are illustrated separately for easy understanding, but actually, the communication disconnection process of (S10) is performed in the message reception process of (S9). Executed.

(FIG. 31- (S1)) Next, the client hello generating unit 400 (part of the cipher suite investigation means) uses the “cipher suite information supported by the client” and the mounting information 800 (mounting status storage means) held by itself. Read cipher suite information. At this time, since “TLS_RSA_WITH_AES_128_CBC_SHA” is checked in the mounting information 800 (mounting status storage means), “TLS_RSA_WITH_AES_128_CBC_SHA” is selected from all cipher suites listed in “cipher suite information supported by the client”. ”Is read out. In this case, the following cipher suites are read.
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
(FIG. 31-(S2)) Client Hello production | generation part 400 (a part of encryption sweet investigation means) produces | generates the Client Hello message which designated the said encryption sweet, and sends this to the data transmission part 110. FIG.

  (FIG. 31-(S3)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 31-(S4)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 33-(S5)) The server 2 starts in a state waiting for receiving a message from the client 1. The data receiving unit 220 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 33-(S2)) Client Hello receiving part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 33-(S6)) Since the server 2 supports "TLS_RSA_WITH_AES_256_CBC_SHA", the Client Hello reception part 410 processes this Client Hello message, and calls the Server Hello production | generation part 510. FIG.

  (FIG. 33-(S7)) The Server Hello production | generation part 510 produces | generates a Server Hello / Server Certificate / Server Hello Done message, and sends this to the data transmission part 210. FIG.

  (FIG. 33-(S8)) The data transmission part 210 transmits a Server Hello / Server Certificate / Server Hello Done message with respect to the client 1 via the network control apparatus 200. FIG.

  (FIG. 33-(S9)) Thereafter, the server 2 enters a state of waiting for a message from the client 1.

  (FIG. 31-(S4)) The data reception part 120 of the client 1 receives the Server Hello / Server Certificate / Server Hello Done message which the server 2 transmitted via the network control apparatus 100. FIG. The data receiving unit 120 sends the Server Hello / Server Certificate / Server Hello Done message to the Server Hello receiving unit 500 (part of the cipher suite investigation means) that processes (interprets) the handshake_failure message.

  (FIG. 31-(S5)) Server Hello receiving part 500 (a part of encryption sweet investigation means) checks whether the received message is a handshake_failure message.

  (FIG. 31-(S6)) Since the received message is not a handshake_failure message, the server hello receiving unit 500 (part of the cipher suite checking means) indicates that the server 2 has "TLS_RSA_WITH_AES_256_CBC_SHA" in the mounting information 800 (mounting status storage means). Remember to support.

(FIG. 31- (S7)) Next, the Server Hello receiving unit 500 (part of the cipher suite investigation unit) disconnects communication and calls the Client Hello generation unit 400 (part of the cipher suite investigation unit) (that is, ( Go to A)).
(FIG. 33-(S <b> 9)) Although the server 2 is in a message reception waiting state from the client 1, the communication is disconnected from the client 1, so the server 2 exits this message reception waiting state and waits to receive the client hello. become. In addition, in the flowchart of FIG. 11, (S9) and (S10) are illustrated separately for easy understanding, but actually, the communication disconnection process of (S10) is performed in the message reception process of (S9). Executed.

(FIG. 31- (S1)) Next, the client hello generating unit 400 (part of the cipher suite investigation means) uses the “cipher suite information supported by the client” and the mounting information 800 (mounting status storage means) held by itself. Read cipher suite information. At this time, since “TLS_RSA_WITH_AES_128_CBC_SHA” and “TLS_RSA_WITH_AES_256_CBC_SHA” are checked in the mounting information 800 (mounting status storage means), among the cipher suites listed in “cipher suite information supported by the client” Then, a cipher suite excluding “TLS_RSA_WITH_AES_128_CBC_SHA” and “TLS_RSA_WITH_AES_128_CBC_SHA” is read out. In this case, the following cipher suites are read.
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
(FIG. 31-(S2)) Client Hello production | generation part 400 (a part of encryption sweet investigation means) produces | generates the Client Hello message which designated the said encryption sweet, and sends this to the data transmission part 110. FIG.

  (FIG. 31-(S3)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 31-(S4)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 33-(S1)) The server 2 starts in a state waiting for receiving a message from the client 1. The data receiving unit 220 receives the Client Hello message transmitted from the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 33-(S2)) Client Hello receiving part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 33- (S3)) In the Client Hello message, “TLS_RSA_WITH_RC4_128_MD5” and “TLS_RSA_WITH_RC4_128_SHA” are specified as cipher suites, but since the server 2 does not support this, the Client Hello receiving unit 410 has a handshaking_handshaking_ A message is generated and sent to the data transmission unit 210.

  (FIG. 33-(S4)) The data transmission part 210 transmits a handshake_failure message with respect to the client 1 via the network control apparatus 200. FIG.

  (FIG. 33-(S <b> 5)) Thereafter, the client hello receiving unit 410 disconnects communication with the client 1, and the server 2 again waits to receive a client hello message from the client 1.

  (FIG. 31-(S4)) The data receiver 120 of the client 1 receives the handshake_failure message transmitted by the server 2 via the network control device 100. The data receiving unit 120 sends the handshake_failure message to the Server Hello receiving unit 500 (part of the cipher suite checking means) that processes (interprets) the handshake_failure message.

  (FIG. 31-(S5)) Server Hello receiving part 500 (a part of encryption sweet investigation means) checks whether the received message is a handshake_failure message. The Server Hello receiving unit 500 (part of the cipher suite checking means) does not process the mounting information 800 (mounting status storage means) because the received message is a handshake_failure message.

(FIG. 31-(S8)) Next, the Server Hello receiving part 500 (a part of encryption sweet investigation means) cut | disconnects communication, and sets the flag 720 to FALSE. Then, the client hello generating unit 400 is called (that is, the process proceeds to (A)).
(FIG. 31- (S9)) Next, when the flag 720 is FALSE, the client hello generating unit 400 determines the cipher suite to be used from the “cipher suite priority” and the information mounting information 800 (mounting status storage means). select. First, the client 1 authenticates to the server 2, and therefore, “cipher suite priority” uses authentication. Specifically, the selection is as follows. (1) The client hello generating unit 400 knows that “TLS_RSA_WITH_AES_256_CBC_SHA” with priority 1 is supported from the mounting information 800 (mounting status storage means). Therefore, the client hello generating unit 400 selects “TLS_RSA_WITH_AES_256_CBC_SHA” as the cipher suite.

  (FIG. 31-(S10)) The Client Hello production | generation part 400 produces | generates the Client Hello message which designated "TLS_RSA_WITH_AES_256_CBC_SHA" as a cipher suite, and sends this to the data transmission part 110.

  (FIG. 31-(S11)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 31-(S12)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 33-(S1)) The data receiver 220 of the server 2 receives the Client Hello message transmitted by the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 33-(S2)) Client Hello receiving part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 33-(S6)) Since the server 2 supports "TLS_RSA_WITH_AES_256_CBC_SHA", the Client Hello reception part 410 processes this Client Hello message, and calls the Server Hello production | generation part 510. FIG.

  (FIG. 33-(S7)) The Server Hello production | generation part 510 produces | generates a Server Hello / Server Certificate / Server Hello Done message, and sends this to the data transmission part 210. FIG.

  (FIG. 33-(S8)) The data transmission part 210 transmits a Server Hello / Server Certificate / Server Hello Done message with respect to the client 1 via the network control apparatus 200. FIG.

  (FIG. 33-(S9)) Thereafter, the server 2 enters a state of waiting for a message from the client 1.

  (FIG. 31-(S12)) The data receiver 120 of the client 1 receives the Server Hello / Server Certificate / Server Hello Done message transmitted from the server 2 via the network control device 100. The data receiving unit 120 sends the Server Hello / Server Certificate / Server Hello Done message to the Server Hello receiving unit 500 (part of the cipher suite investigation means) that processes (interprets) the handshake_failure message.

  (FIG. 31-(S13)) When the flag 720 is FALSE, the Server Hello receiving unit 500 (part of the cipher suite examining unit) sends the received message to the SSL negotiation processing unit 600 (that is, proceeds to (B)). . Note that the SSL negotiation processing unit 600 performs negotiation processing in SSL / TLS encryption communication after the Server Hello / Server Certificate / Server Hello Done message processing.

  (FIG. 31-(S14)) The SSL negotiation process part 600 processes a Server Hello / Server Certificate / Server Hello Done message, and produces | generates a common key. Next, a Client Key Exchange / Change Cipher Spec / Finished message is generated and sent to the data transmission unit 110.

  (FIG. 31-(S15)) The data transmission part 110 transmits a Client Key Exchange / Change Cipher Spec / Finished message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 31-(S16)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 33-(S <b> 9)) The data receiving unit 220 of the server 2 receives the Client Key Exchange / Change Cipher Spec / Finished message transmitted from the client 1 via the network control device 200. The data receiving unit 220 processes (interprets) this Client Key Exchange / Change Cipher Spec / Finished message to the Client Key Exchange / Change Cipher Spec / Finished message. Note that the SSL negotiation processing unit 610 performs negotiation processing in SSL / TLS encryption communication after the client key exchange / change cipher spec / finished message processing.

  (FIG. 33-(S11)) SSL negotiation process part 610 processes a Client Key Exchange / Change Cipher Spec / Finished message, and produces | generates a common key. Next, a Change Cipher Spec / Finished message is generated and sent to the data transmission unit 210.

  (FIG. 33-(S12)) The data transmission part 210 transmits a Change Cipher Spec / Finished message with respect to the client 1 via the network control apparatus 200. FIG.

  (FIG. 33-(S13)) Thereafter, the server 2 enters a state of waiting for data (authentication data) from the client 1.

  (FIG. 31-(S16)) The data receiver 120 of the client 1 receives the Change Cipher Spec / Finished message transmitted from the server 2 via the network control device 100. The data receiving unit 220 sends this Change Cipher Spec / Finished message to the SSL negotiation processing unit 600 that processes (interprets) the Change Cipher Spec / Finished message.

  (FIG. 31-(S17)) The SSL negotiation process part 600 processes a Change Cipher Spec / Finished message.

  (FIG. 31-(S18)) Thereafter, the communication unit 900 encrypts the authentication data using the created common key, and sends the encrypted authentication data to the data transmission unit 110. The data transmission unit 110 transmits the encrypted authentication data to the server 2 via the network control device 100.

  Note that the encryption is a common key encryption process defined by SSL / TLS encryption communication, and a hash process is performed simultaneously with the encryption process. Therefore, the common key here means a key used in each of the cryptographic processing and the hash processing.

  (FIG. 33-(S13)) The data reception part 220 of the server 2 receives the encrypted authentication data which the client 1 transmitted via the network control apparatus 200. FIG. The data receiving unit 220 sends the encrypted authentication data to the communication unit 910.

  (FIG. 33-(S14)) The communication part 910 decrypts the encrypted authentication data. Since the data is authentication data, the communication unit 910 sends this authentication data to the authentication unit 920. Note that while the authentication unit 920 does not notify the communication unit 910 that the authentication result is OK, the communication unit 910 discards and does not process the data if the data is communication data.

  (FIG. 33-(S15)) The authentication part 920 test | inspects authentication data. Here, the description will be given in the case where the authentication data is correct. The authentication unit 920 notifies the communication unit 910 that the authentication result is OK.

  In the flowchart of FIG. 33, the process returns to the start after (FIG. 33- (S15)), but this is actually a data reception waiting state. Thereafter, Client Hello from the client 1 is received, but actually, the process returns to the start.

  (FIG. 31-(S13)) Next, when the flag 720 is FALSE and the authentication data is transmitted, the client hello generating unit 400 and the “cipher suite priority” and the information mounting information 800 (mounting status storage unit) Select the cipher suite to be used. Since the client 1 transmits communication data to the server 2, “cipher suite priority” is used for communication. Specifically, the selection is as follows. (1) The client hello generating unit 400 knows from the mounting information 800 (mounting status storage means) that “TLS_RSA_WITH_RC4_128_MD5” of priority 1 is not supported. (2) Next, the client hello generating unit 400 knows from the mounting information 800 (mounting status storage means) that “TLS_RSA_WITH_RC4_128_SHA” of priority 2 is not supported. (3) Next, the client hello generating unit 400 knows that “TLS_RSA_WITH_AES_128_CBC_SHA” with priority 3 is supported from the mounting information 800 (mounting status storage means). Therefore, the client hello generating unit 400 selects “TLS_RSA_WITH_AES_128_CBC_SHA” as the cipher suite.

  (FIG. 31-(S20)) The Client Hello production | generation part 400 produces | generates the Client Hello message which designated "TLS_RSA_WITH_AES_128_CBC_SHA" as a cipher suite, and sends this to the data transmission part 110.

  Since the SSL / TLS negotiation starting with this Client Hello message is a renegotiation, this SSL / TLS negotiation is normally executed in the previous encrypted communication. In this case, the SSL / TLS negotiation is performed by encrypting with “TLS_RSA_WITH_AES_256_CBC_SHA”. Therefore, actually, encryption and decryption processing of the communication unit 900 and the communication unit 910 are involved. Since the description is complicated, this process is omitted and will be described below.

  (FIG. 31-(S21)) The data transmission part 110 transmits this Client Hello message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 31-(S22)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 33-(S1)) The data receiver 220 of the server 2 receives the Client Hello message transmitted by the client 1 via the network control device 200. The data receiving unit 220 sends this Client Hello message to the Client Hello receiving unit 410 that processes (interprets) the Client Hello message.

  (FIG. 33-(S2)) Client Hello receiving part 410 checks whether the encryption sweet designated by the Client Hello message exists in the encryption sweet which self supports.

  (FIG. 33-(S6)) Since the server 2 supports "TLS_RSA_WITH_AES_128_CBC_SHA", the Client Hello reception part 410 processes this Client Hello message, and calls the Server Hello production | generation part 510. FIG.

  (FIG. 33-(S7)) The Server Hello production | generation part 510 produces | generates a Server Hello / Server Certificate / Server Hello Done message, and sends this to the data transmission part 210. FIG.

  (FIG. 33-(S8)) The data transmission part 210 transmits a Server Hello / Server Certificate / Server Hello Done message with respect to the client 1 via the network control apparatus 200. FIG.

  (FIG. 33-(S9)) Thereafter, the server 2 enters a state of waiting for a message from the client 1.

  (FIG. 31-(S22)) The data receiver 120 of the client 1 receives the Server Hello / Server Certificate / Server Hello Done message transmitted by the server 2 via the network control device 100. The data receiving unit 120 sends the Server Hello / Server Certificate / Server Hello Done message to the Server Hello receiving unit 500 (part of the cipher suite investigation means) that processes (interprets) the handshake_failure message.

  (FIG. 31-(S23)) Server Hello receiving part 500 (a part of encryption sweet investigation means) sends the received message to SSL negotiation process part 600 (that is, it progresses to (B)), when flag 720 is FALSE. . Note that the SSL negotiation processing unit 600 performs negotiation processing in SSL / TLS encryption communication after the Server Hello / Server Certificate / Server Hello Done message processing.

  (FIG. 31-(S24)) The SSL negotiation process part 600 processes a Server Hello / Server Certificate / Server Hello Done message, and produces | generates a common key. Next, a Client Key Exchange / Change Cipher Spec / Finished message is generated and sent to the data transmission unit 110.

  (FIG. 31-(S25)) The data transmission part 110 transmits a Client Key Exchange / Change Cipher Spec / Finished message with respect to the server 2 via the network control apparatus 100. FIG.

  (FIG. 31-(S26)) Thereafter, the client 1 enters a state of waiting for receiving a message from the server 2.

  (FIG. 33-(S <b> 9)) The data receiving unit 220 of the server 2 receives the Client Key Exchange / Change Cipher Spec / Finished message transmitted from the client 1 via the network control device 200. The data receiving unit 220 processes (interprets) this Client Key Exchange / Change Cipher Spec / Finished message to the Client Key Exchange / Change Cipher Spec / Finished message. Note that the SSL negotiation processing unit 610 performs negotiation processing in SSL / TLS encryption communication after the client key exchange / change cipher spec / finished message processing.

  (FIG. 33-(S11)) SSL negotiation process part 610 processes a Client Key Exchange / Change Cipher Spec / Finished message, and produces | generates a common key. Next, a Change Cipher Spec / Finished message is generated and sent to the data transmission unit 210.

  (FIG. 33-(S12)) The data transmission part 210 transmits a Change Cipher Spec / Finished message with respect to the client 1 via the network control apparatus 200. FIG.

  (FIG. 33-(S13)) Thereafter, the server 2 enters a state of waiting for data (authentication data) from the client 1.

  (FIG. 31-(S26)) The data receiver 120 of the client 1 receives the Change Cipher Spec / Finished message transmitted by the server 2 via the network control device 100. The data receiving unit 220 sends this Change Cipher Spec / Finished message to the SSL negotiation processing unit 600 that processes (interprets) the Change Cipher Spec / Finished message.

  (FIG. 31-(S27)) The SSL negotiation process part 600 processes a Change Cipher Spec / Finished message.

  (FIG. 31-(S18)) Thereafter, the communication unit 900 encrypts the communication data using the created common key, and sends the encrypted communication data to the data transmission unit 110. The data transmission unit 110 transmits the encrypted authentication data to the server 2 via the network control device 100.

  Note that the encryption is a common key encryption process defined by SSL / TLS encryption communication, and a hash process is performed simultaneously with the encryption process. Therefore, the common key here means a key used in each of the cryptographic processing and the hash processing.

  (FIG. 33-(S13)) The data reception part 220 of the server 2 receives the encrypted communication data which the client 1 transmitted via the network control apparatus 200. FIG. The data receiving unit 220 sends the encrypted communication data to the communication unit 910.

  (FIG. 33-(S16)) The communication part 910 decodes the encrypted communication data. Since the communication unit 910 has previously received a notification that the authentication result is OK from the authentication unit 920, the communication unit 910 processes this communication data.

  Note that SSL / TLS encryption communication continues between the client 1 and the server 2 after (FIG. 31- (S28)) in the flowchart in FIG. 31 and (FIG. 33- (S16)) in the flowchart in FIG.

  34 is a diagram showing a fourth example of the hardware configuration in the embodiment of the present invention, and is also an example of the hardware configuration diagram of FIG. The client 1 executes data transmission / reception of the network with the CPU 10 that executes program processing, the RAM 20 that is a temporary storage memory, the HDD (hard disk) 30 that is a rewritable nonvolatile memory, and the ROM 40 that is a non-rewritable nonvolatile memory. MAC / PHY50. On the other hand, the server 2 includes a CPU 11 that executes program processing, a RAM 21 that is a temporary storage memory, a ROM 41 that is a non-rewritable nonvolatile memory, and a MAC / PHY 51 that executes network data transmission / reception. The client 1 and the server 2 are connected to each other via a network via a MAC / PHY 50 and a MAC / PHY 51.

  First, the hardware configuration of the client 1 will be described. Each processing unit of the client 1 illustrated in FIG. 34 is executed by the CPU 10 and the RAM 20.

  The flag 720 and the mounting information 800 (mounting status storage means) are disposed in the RAM 20 which is a temporary storage memory. However, any rewritable memory may be used, such as the HDD (hard disk) 30 or a flash ROM. May be.

  Next, “Cryptographic Suite Priority Information Supported by Client (for Authentication)” and “Cryptographic Suite Priority Cited Suite Information (for Communication)” are placed in rewritable non-volatile memory. It is preferable to do this. In this figure, an HDD (hard disk) 30 is used as a rewritable nonvolatile memory, but any type of rewritable nonvolatile memory such as a flash ROM may be used. The operation is performed even if "priority information on cipher suites supported by the client (for authentication)" and "priority information on cipher suites supported by the client (for communication)" are arranged in the RAM 20, which is a temporary storage memory. However, it is not preferable because it takes time to register the priority order every time.

  Note that “priority information on cipher suites supported by the client (for authentication)” and “priority information on cipher suites supported by the client (for communication)” are determined at the time of implementation, and the priorities are not changed after implementation. In this case, it may be arranged in the ROM 40, which is a non-rewritable nonvolatile memory.

  The “cipher suite supported by the client” is a program of an actual cipher suite, and is usually placed in a non-volatile memory. In order to avoid confusing the description, the functional block diagram of the client 1 does not show “cipher suites supported by the client”, but as shown in the functional block diagram of the server 2, This is necessary for cryptographic communication. Here, “encryption suite supported by the client” is arranged in the ROM 40, but the present invention is not limited to this. When the cipher suite program is downloaded from the server and used every time, it can be arranged in a volatile memory such as the RAM 20.

  The MAC / PHY 50 is hardware that controls network communication, and implements the network control device 100.

  Next, the hardware configuration of the server 2 will be described. Each processing unit of the server 2 illustrated in FIG. 3 is executed by the CPU 11 and the RAM 21.

  The “cipher suite supported by the server” is a program of an actual cipher suite, and is usually placed in a non-volatile memory. Here, “encryption suite supported by the server” is arranged in the ROM 41, but the present invention is not limited to this. When the cipher suite program is downloaded from another server and used every time, it can be arranged in a volatile memory such as the RAM 21.

  The MAC / PHY 51 is hardware that controls network communication, and implements the network control device 200.

  FIG. 35 is a diagram showing a first example of a mounting information mounting method when there are a plurality of servers to be connected in the embodiment of the present invention. Here, description will be made assuming that there are three types of servers, server A, server B, and server C.

  The client mounting information is information that stores, for each cipher suite, whether the server supports the cipher suite. When there are a plurality of servers, such as server A, server B, and server C, the on-board information has a mechanism for storing for each cipher suite whether each server supports the cipher suite.

  FIG. 36 is a diagram showing a second example of the mounting information mounting method when there are a plurality of servers to be connected according to the embodiment of the present invention.

  The client mounting information is information that stores, for each server, which cipher suites the server supports.

  FIG. 37 shows a first example of a method of implementing “priority information on cipher suites supported by the client” when there are a plurality of servers to be connected and the priorities are different for each server and for each purpose in the embodiment of the present invention. FIG.

  Here, there are two types of servers, server A and server B, and the server A and server B will be described as having different cipher suite priorities in the client. Further, when communicating with the server A, it is assumed that the prioritization of cipher suites in the client differs between authentication and communication.

  The “priority information on cipher suites supported by the client” has a mechanism in which prioritization is performed for each cipher suite.

  In this case, for each cipher suite, the server A authentication, the communication of the server A, and the priority order when the server B is the other party are stored.

  In the figure, (1) has the highest priority, and the following (2) and (3) lower the priority.

  In the figure, there is a blank where no priority order is described. This indicates that the server does not support the cipher suite. The installation status of the cipher suite is stored as installation information, but the installation information may be combined and stored in the “priority information of the cipher suites supported by the client” as described above.

  FIG. 38 shows a second example of a method for implementing “priority information on cipher suites supported by the client” in the case where there are a plurality of servers to be connected and the priorities are different for each server and for each purpose in the embodiment of the present invention. FIG.

  Here, too, there are two types of servers, server A and server B, and the server A and server B will be described as having different cipher suite priorities in the client. Further, when communicating with the server A, it is assumed that the prioritization of cipher suites in the client differs between authentication and communication.

  The “priority information on cipher suites supported by the client” has a mechanism in which priorities are assigned for each server and purpose.

  In this case, the priority order of cipher suites is stored for each authentication of server A, communication of server A, and server B.

  In the figure, (1) has the highest priority, and the following (2) and (3) lower the priority.

  In the figure, there is a blank where no priority order is described. This indicates that the server does not support the cipher suite. The installation status of the cipher suite is stored as installation information, but the installation information may be combined and stored in the “priority information of the cipher suites supported by the client” as described above.

  FIG. 39 is a diagram illustrating a first example of a method in which a user changes “cipher suite priority information supported by a client” according to an embodiment of the present invention. Here, the user uses the priority input unit 950 (priority changing means) of the client 1 to change the cipher suite priority. The priority order input unit 950 (priority order changing means) can be a device including a monitor and a keyboard, for example. The input screen (example) shown in FIG. 39 is displayed on the monitor, and the server address (IP address, etc.) and the priority number of each cipher suite (here, 1 is the highest priority, and is as low as 2, 3). It is possible to change the priority order of the cipher suites by allowing the user to input with the keyboard.

  FIG. 40 is a diagram illustrating a first example of a method in which the client according to the embodiment of the present invention determines whether or not to check the cipher suite installation information in the server.

  This figure is almost the same as FIG. The difference is that a survey flag 730 (part of the survey judgment means) exists in FIG. Here, before the client hello generation unit 400 (part of the investigation determination unit) examines the information on the installation of the cipher suite in the server, the client hello generation unit 400 looks at the investigation flag 730. It is a mechanism for investigating information. If the value of the investigation flag 730 is set to FALSE, the Client Hello generation unit 400 (part of the investigation determination unit) performs normal SSL / TLS encryption communication.

  As a result, the client 1 investigates the cipher suite installation information in the server 2 only when necessary, so that useless labor can be reduced. This function is important because many servers 2 do not prioritize cipher suites.

  This survey flag 730 (part of the survey determination means) may be set by the user. In that case, it is desirable that it can be set for each server to which the user connects. If the performance is poor by using SSL / TLS encryption communication with a certain server, it is possible to try to improve the performance by setting this investigation flag 730 (part of the investigation judgment means) to TRUE.

  Although not shown here, the survey flag 730 (part of the survey determination unit) may be stored for each server when there are a plurality of servers to be connected. Further, the survey flag 730 (part of the survey determination unit) may be stored together with the mounting information 800 and the priority information of the cipher suite.

  FIG. 41 is a diagram illustrating a second example of a method in which the client according to the embodiment of the present invention determines whether or not to check the cipher suite installation information in the server.

  First, as described in the procedure (FIG. 41- (S1)) to (FIG. 41- (S12)), the client searches for at least two or more cipher suites installed in the server.

  Then (FIG. 41- (S13)) Next, Client Hello that specifies at least two or more cipher suites that are found to be installed in the server is transmitted to the server.

  In this example, Client Hello in which “TLS_RSA_WITH_AES_128_CBC_SHA” and “TLS_RSA_WITH_AES_256_CBC_SHA” are simultaneously specified is transmitted to the server. Here, “TLS_RSA_WITH_AES_128_CBC_SHA” is described before “TLS_RSA_WITH_AES_256_CBC_SHA”, but the order may be reversed.

  (FIG. 41-(S14)) Here, it is assumed that the server returns a Server Hello specifying "TLS_RSA_WITH_AES_128_CBC_SHA". If the server returns a Server Hello specifying “TLS_RSA_WITH_AES_256_CBC_SHA”, it can be understood that the server is prioritizing the cipher suites at this point. When the server returns a Server Hello specifying “TLS_RSA_WITH_AES_128_CBC_SHA”, it cannot be determined at this point whether the server respects the priority of the client or prioritizes the cipher suites.

  (FIG. 41-(S15)) Communication is cut | disconnected. Although it is described here that the investigation is performed once each time (FIG. 41- (S16)), the following investigation is performed simultaneously with using a different TCP port (FIG. 41- (S13)). It doesn't matter.

  (FIG. 41-(S16)) Next, Client Hello which designated simultaneously the at least 2 or more encryption sweet which it turned out that the server is mounted is transmitted to a server.

  However, Client Hello of the cipher suite described in the order of “TLS_RSA_WITH_AES_256_CBC_SHA” and “TLS_RSA_WITH_AES_128_CBC_SHA” opposite to the above is transmitted to the server.

  It should be noted that if “TLS_RSA_WITH_AES_256_CBC_SHA” and “TLS_RSA_WITH_AES_128_CBC_SHA” are specified in this order first, the reverse “TLS_RSA_WITH_AES_128_CBC_SH_A_S_SH_A_A_S_SH_A_A_S_SH_A_S_SH_A_S_SH_A_

  (FIG. 41-(S14)) Here, it is assumed that the server returns a Server Hello specifying "TLS_RSA_WITH_AES_128_CBC_SHA". Here, if the server returns a Server Hello specifying “TLS_RSA_WITH_AES_256_CBC_SHA”, it can be seen that the server respects the priority of the client.

  If the server returns a Server Hello specifying “TLS_RSA_WITH_AES_128_CBC_SHA” as shown in this figure, it can be seen that the server is prioritizing cipher suites.

  This block diagram is almost the same as FIG. It is possible to determine whether or not the server is prioritizing between the Client Hello generation unit (part of the investigation determination unit) and the Server Hello reception unit 500 (part of the investigation determination unit). Note that the determination result may or may not be reflected in the survey flag 730 (part of the survey determination means). If it is reflected in the survey flag 730 (part of the survey judgment means), it is not necessary to conduct a survey again, so that labor is saved.

  FIG. 42 is a sequence diagram showing a sixth example of SSL / TLS encryption communication in the embodiment of the present invention. Although the sequence is almost the same as that in FIG. 2, the major difference is that a plurality of cipher suites are selected when a cipher suite to be used is selected.

  This is a processing method in the case where the handshake failure is continuously returned from the server and the client is unable to find the cipher suite supported by both of the client and the server, and the time has passed in the investigation of the installation status of the server's cipher suite. Show.

  In such a case, as shown in FIG. 42, when the allowable time has elapsed, the client finishes the installation of the encryption suite of the server, and selects the encryption sweet according to the information so far.

  Since the communication apparatus according to the present invention can lead the cipher suite selection, it is useful even for vulnerable embedded device clients, which can perform communication with good performance in consideration of security balance.

1 client 2 server 10 CPU (client side)
11 CPU (server side)
20 RAM (client side)
21 RAM (server side)
30 HDD (hard disk)
40 ROM (client side)
41 ROM (server side)
50 MAC / PHY (client side)
51 MAC / PHY (server side)
100 Network controller (client side)
110 Data transmission unit (client side)
120 Data receiver (client side)
200 Network controller (server side)
210 Data transmitter (server side)
220 Data receiver (server side)
400 Client Hello generating unit 410 Client Hello receiving unit 500 Server Hello receiving unit 510 Server Hello generating unit 600 SSL negotiation processing unit (client side)
610 SSL negotiation processing unit (server side)
700 Counter indicating current priority 710 Current counter 720 Flag 730 Investigation flag 800 Mounting information 900 Communication unit (client side)
910 Communication unit (server side)
920 Authentication part 950 Priority input part

Claims (11)

A communication device that performs encryption communication with another communication device using an encryption method selected from a plurality of encryption methods,
An encryption method acquisition unit for acquiring first information of an encryption method usable by the other communication device;
An encryption method selection unit that selects an encryption method to be used for communication with the other communication device from the plurality of encryption methods based on the first information;
A communication device comprising: a transmission unit that transmits the encryption method selected by the encryption method selection unit to the other communication device. The communication device according to claim 1,
The communication device that transmits the encryption method selected from the plurality of encryption methods to the other communication device, and acquires the first information based on a response result of the other communication device. The communication device according to claim 2,
Further comprising priority information of the plurality of encryption schemes in communication with the other communication device;
The encryption method acquisition unit is a communication device that transmits an encryption method selected from the plurality of encryption methods based on the priority information to the other communication device. The communication device according to claim 3,
The priority information is a different communication device depending on another communication device. The communication device according to claim 2,
The encryption method acquisition unit is a communication device that acquires second information of an encryption method that cannot be used by the other communication device based on the response result. The communication device according to claim 1,
The encryption method acquisition unit transmits a plurality of encryption methods selected from the plurality of encryption methods to the other communication device, and acquires the first information based on a response result of the other communication device. . A communication system comprising a first communication device and a second communication device,
The first communication device can use a plurality of encryption methods, and transmits usable encryption methods to the second communication device.
The second communication device is a communication system that transmits to the first communication device information on whether or not to use the encryption method transmitted from the first communication device. The communication system according to claim 6, wherein
The first communication device uses an encryption method to be used in communication with the second communication device from the plurality of encryption methods based on the availability information transmitted from the second communication device. The communication system to select. The communication system according to claim 6, wherein
The first communication device has priority information of the plurality of encryption methods in the second communication device,
A communication device that transmits an encryption method selected from the plurality of encryption methods based on the priority information to the second communication device. The communication system according to claim 8, wherein
A third communication device capable of communicating with the first communication device;
The first communication device is a communication system having priority information of the plurality of encryption schemes in the third communication device. The communication system according to claim 6, wherein
The first communication device transmits a plurality of encryption methods selected from the plurality of encryption methods to the second communication device,
The second communication device is a communication system that transmits, to the first communication device, information on availability of each encryption method transmitted from the first communication device.