JP2007036389A - Hand-over method of tls session information, and computer system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method of efficiently handing over session information of the TLS protocol used for a computer system connected to clients via a network. <P>SOLUTION: The method is characterized in that the session information in compliance with the TLS protocol processed by a relay server 110 is written in a TLS session information database 170, whose access is limited by a secure OS so that a roll 1 server 130 reuses the information for second and succeeding accesses by a user, thereby omitting hand-shake processing of a concerned part and carrying out processes, in compliance with the TLS protocol. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a technology for safely taking over information between servers via a network, and more particularly to a technology for safely taking over TLS protocol session information from one server running a secure OS to another server.

  With the rapid spread of the Internet at homes and businesses and the progress of broadbandization, electronic commerce and the like are increasing rapidly. Along with this, the importance of security technology in computer systems such as encryption technology has increased dramatically, and in the e-commerce site using an actual Web server, communication path encryption technology called TLS (Transfer Layer Security) protocol has been introduced. It is often used.

  The TLS protocol is a protocol corresponding to the fifth layer (session layer) of the OSI (Open System Interconnection) reference model, and protects communication of application data between two computers connected via a network. By following the TLS protocol, communication data encryption and communication partner authentication can be performed mainly. For example, as described in detail in Non-Patent Document 1, record data is transmitted and received on a communication path set by lower layer TCP, and used for authentication of a communication partner and generation of a key necessary for encryption of application data Exchange of random number data to be performed, compression of application data, encryption, tampering detection, and the like. The outline of the processing procedure will be described below.

(1) A TCP connection is established between the client and the server.
(2) The client and server perform a handshake process for performing authentication and exchanging key information according to the TLS protocol. As the first stage of handshake processing, the client sends a ClientHello message to the server. The ClientHello message includes random number data used for key generation, and identifiers of encryption algorithms and compression algorithms supported by the client. The following handshake process including the ClientHello message is exchanged as part of the record data.
(3) As the second stage of the handshake process, after receiving the ClinetHello message, the server generates messages such as ServerHello and ServerHelloDone, and transmits them to the client. The ServerHello message includes a session ID (hereinafter referred to as “SID”). The SID will be described later.

(4) As the third stage of the handshake process, after the client receives a message such as ServerHello, it generates a message such as ClientKeyExchange, ChangeCipherSpec, and Finished and sends it to the server. The ClientKeyExchange message contains the encrypted random number data used to generate the encryption key. This data is combined with the random number data included in the ClientHello and ServerHello messages to encrypt the application data and detect the alteration. Generate a key. These data are associated with the SID, and are reused when communication is performed again after disconnecting the TCP connection. Details will be described later. ChangeCipherSpec indicates that subsequent communication is compressed and encrypted. The Finished message notifies the server that the client-side handshake process has been completed.

(5) As the fourth stage of the handshake process, the server receives a message such as ClientKeyExchange, decrypts the encrypted random number data included in ClientKeyExchange, and generates an encryption key. Further, a ChangeCipherSpec and a Finished message are generated and transmitted to the client.
(6) Thereafter, the client and the server use the encryption key generated from the random number data to encrypt the communication data or add the data for tampering detection and transmit it to the other party. The receiving side confirms that there is no decryption or falsification, acquires application data, and performs the original application processing. Note that application data is compressed before encryption. These processes are performed in units of records.

  The procedures (1) to (6) are complete handshake processing procedures when the client and the server communicate for the first time, and are processing that places a relatively heavy load on the client and the server. In particular, the load due to encryption and decryption of random number data included in the ClientKeyExchange message is large. This is because public key cryptography is used.

  For this reason, in the handshake process in the second and subsequent communications, the exchange of the ClientKeyExchange message is omitted, and the random hand data that was exchanged during the first complete handshake process is reused to define a simplified handshake process that reduces the load. ing. Hereinafter, a communication procedure using the simplified handshake will be described.

(1) The client sends a ClientHello message to the server. This message includes an SID that identifies the TLS session generated during the first complete handshake process.
(2) After receiving the ClientHello message, the server obtains random number data exchanged at the first communication corresponding to the SID from the cache memory, and uses it for encryption and falsification detection in the second and subsequent communications. A ServerHello, ChangeCipherSpec, and Finished message including this SID are generated and transmitted to the client.
(3) The client receives the ChangeCipherSpec and Finished message. Further, a ChangeCipherSpec and a Finished message are generated and transmitted to the server. In subsequent communications, a key is generated from random number data corresponding to the SID and is used for encryption.

  The above is the outline of the TLS protocol. The encryption algorithm, compression algorithm, and random number data used for encryption key generation agreed between the client and the server are referred to as “TLS session information”. The client and the server can identify the TLS session information using the SID, and can efficiently use the TLS protocol by performing the simple handshake process.

On the other hand, a security-enhanced operating system (hereinafter referred to as a “secure OS”) that has traditionally belonged to military technology has become generally available. By using the forced access control of the secure OS, there is a vulnerability in a server such as a Web server, and even if this vulnerability is attacked, the damage of the attack can be limited only to that server. For example, damages such as “server shuts down” and “files accessible to the server are altered or leaked outside” occur, but other servers in the same computer system shut down or were damaged It is possible to prevent destruction and leakage of files that are not accessed by the server. That is, the scope of damage is limited to the access range of resources and processes permitted by the OS to the domain and role to which the server process belongs. Here, the domain and the role are security attributes assigned to the process. The secure OS compares the security attribute of this process with the security attribute assigned to the resource to be accessed, and permits access. Decide whether to do or forbid.
With such a domain and role, a security technology using a feature of a secure OS that can limit the damage range even if the application is vulnerable has been developed.

For example, in Non-Patent Document 2, using a secure OS, the authority (domain) given to a user such as a Web server and the types (types) of resources that can be used with that authority are limited. A technique for subdividing and minimizing authority is disclosed so that a person cannot freely access resources on various OSs. Note that transmission / reception of information related to the safety of the communication path such as TLS session information is not described.
In Patent Document 1, as a method for taking over, sharing, and transferring information such as communication path security and role between different computer systems, a delegation token including information such as a key, a role, and a period is encrypted. Techniques for safely exchanging using techniques are disclosed.

JP 2004-166238 A T. Dierk, C. Allen, "The TLS Protocol ver. 1", InternetRFC 2246, Jan. 1999 Independent Administrative Institution Information Processing Promotion Organization Security Center, “Functional Specification for Investigation and Design of Web Server Based on Forced Access Control”, April 26, 2005

However, the technique described in Non-Patent Document 2 has a problem that the load on the Web server is too large because the Web server is activated every time there is an access. In fact, a virtual terminal server such as telnet and a file transfer server such as ftp are relatively simple and lightweight servers, so the server may be started each time access is made, but the web server is complicated. Since it is large-scale, there is only one server to start, and this single server handles a large amount of access by a plurality of clients. In addition, because of the nature of the application, the frequency of access to the Web server is very high, and it is impractical to start the server for cryptographic processing each time it is accessed.
Further, in the technique described in Patent Document 1, information necessary for delegation of roles and the like is protected by using a cryptographic technique in order to securely transfer between servers using tokens. Since each requires encryption processing, there is a problem that the load on the server increases.

  In view of the above problems, an object of the present invention is to provide an efficient and secure TLS session information takeover method used in a computer system connected to a client via a network. It is another object of the present invention to provide a computer system whose operating efficiency is greatly improved by using a TLS session information takeover method.

In order to solve the above problems, the present invention has the following features.
The TLS session information takeover method according to the present invention includes a relay server in which a secure OS operates and receives a request from a client, a role server to which a domain and a role are assigned and performs application processing, and a relationship between the client user and its role , A second database that holds the association between the TLS protocol session ID and the domain and role, and a third database that holds the TLS protocol session information prepared for each role server TLS session information executed by a computer system in which the relay server has only the right to read the first database and has only the right to write to the third database. A takeover method, wherein the relay server As for the processing of the TLS protocol, only the handshake processing is performed, the user who is authenticated at the time of the handshake processing, the role obtained from the first database and the session ID of the TLS protocol are written in the second database, TLS The session information is written into the third database after handshake processing and then discarded, and the encrypted application data is relayed to the role server. Further, when the session using the TLS protocol is resumed, the session starts. Determining a corresponding role server from the second database using a session ID included in a message received from a client as a key, and relaying the message including the message to the role server; Third data By using the TLS session information written over scan document, characterized in that a step of performing a handshake process by TLS protocol.

  In the TLS session information takeover method according to the present invention, the relay server and the role server are individually arranged on different computers on which a secure OS operates, and the computer on which the role server is arranged has a third type. A database adding server that has only the right to write to the database, and the relay server writes the TLS session information to the third database after handshake processing via the database adding server and then discards the information. It is characterized by that.

  The computer system according to the present invention has a first relay server in which a secure OS operates, a relay server that accepts a request from a client, a role server that is assigned a domain and a role and performs application processing, and a user of the client and a relationship between the roles. A second database that holds a database, a session ID of a TLS protocol, a domain and a role, and a third database that holds session information of a TLS protocol prepared for each role server. , A computer system having only the right to read for the first database and only the right to write to the third database, wherein the relay server is related to the processing of the TLS protocol. Only handshake processing is performed. After the user authenticated at the time of the shake process, the role obtained from the first database and the session ID of the TLS protocol are written to the second database, and after the TLS session information is written to the third database after the handshake process Discarding and relaying the encrypted application data to the role server, and when resuming a session based on the TLS protocol, the session ID included in the message received from the client at the start of the session is used as a key. A corresponding role server is determined from the database, and the message including the message is relayed to the role server. The role server uses the TLS session information written in the third database to perform a hand using the TLS protocol. Shake processing And wherein the Ukoto.

  In the computer system of the present invention, the relay server and the role server are individually arranged on different computers on which a secure OS operates, and the computer on which the role server is arranged writes to a third database. A database addition server having only the authority to load is arranged, and the relay server discards the TLS session information after writing it into the third database after handshake processing via the database addition server.

According to the present invention, the role server obtains the TLS session information obtained by the complete handshake process of the relay server from the third database with restricted access, and performs the simplified handshake process, thereby making it efficient and safe. A method for taking over TLS session information can be provided.
In addition, according to the present invention, it is possible to provide a computer system whose operating efficiency is greatly improved by using the above method.

  The best mode for carrying out the present invention will be described below with reference to the drawings.

(Embodiment 1)
FIG. 1 is a diagram illustrating a configuration of a computer system according to the first embodiment. As shown in FIG. 1, the computer 100 includes a relay server 110, a user and role related registration tool 120, a role 1 server 130, a role 2 server 140, an SID and role related database 150, a user and role related database 160, and TLS session information. The database is composed of databases 170 and 180, and a secure OS is running. Furthermore, a client computer (hereinafter referred to as “client”) 200 is connected to the computer 100 from the outside via a network. The individual functions are described below.

  The relay server 110 is the first server that the client 200 accesses the computer 100. When the client 200 connects for the first time, the relay server 110 performs handshake processing according to the TLS protocol, and registers the TLS session information acquired from the client 200 in the TLS session information databases 170 and 180 in the role servers 130 and 140. . Here, by using the secure OS function, the relay server 110 can write (w; write) to the TLS session information databases 170 and 180, but cannot read (r; read). Is limited to. The relay server 110 discards the TLS session information after writing in the TLS session information databases 170 and 180. By doing so, even if the relay server 110 is vulnerable and unauthorized access from outside is permitted, an unauthorized intruder cannot read past TLS session information. After the handshake process, the encrypted communication data is relayed to the role servers 130 and 140 as they are. Details will be described later.

  The user and role related registration tool 120 is a tool for registering the relationship between the user of the client 200 and its role in the user and role related database 160. The user and role related registration tool 120 has the authority to write and read the user and role related database 160, but by using the function of the secure OS, other resources such as the SID and role related database 150 and the TLS session are used. Access to the information databases 170, 180, etc. is prohibited.

  The role servers 130 and 140 are application servers each having a certain role, and perform original application processing. By assigning domains and roles to the role servers 130 and 140, the range of accessible resources can be limited even if the role servers 130 and 140 are illegally accessed. The role servers 130 and 140 perform the simplified handshake process using the TLS session information acquired by the complete handshake process performed by the relay server 110.

The SID and role-related database 150 corresponds to the second database of the present invention, and is protected by the function of the secure OS so that only the relay server 110 can read and write.
The user and role related database 160 corresponds to the first database of the present invention, the user and role related registration tool 120 can read and write, and the relay server 110 can only read. Therefore, even if there is unauthorized access to the relay server 110, the user and role-related database 160 cannot be falsified.

  The TLS session information databases 170 and 180 correspond to the third database of the present invention, are arranged corresponding to the role servers 130 and 140, respectively, and only the corresponding role server can access the corresponding TLS session information database. Thus, it is restricted using the function of the secure OS. That is, the functions of the secure OS are set so that the access to the TLS session information database 1 (170) is permitted only from the role 1 server 130, and the access to the TLS session information database 2 (180) is permitted only from the role 2 server 140. Limited to use. Further, as described above, from the relay server 110, only writing such as registration / additional writing is possible, and reading is not possible.

  The client 200 is a computer that accesses the servers 110, 130, and 140 on the computer system of the present invention and requests application processing. The client 200 accesses the role servers 130 and 140 via the relay server 110.

FIG. 2 is a diagram showing the internal structure of the relay server of the present invention.
The TCP connection processing unit 111 accepts a TCP connection from the client 200 and transmits / receives data. On the other hand, in addition to relaying communication data between the client 200 and the role servers 130 and 140 after the handshake processing, communication of handshake messages between the handshake processing unit 113 and the role servers 130 and 140 is also performed.
The record processing unit 112 processes data received from the client 200 received via the TCP connection processing unit 111. As the processing contents, the received data is divided into record data units, or the contents are transferred to the handshake processing unit 113 depending on the contents of the records. Conversely, a message is received from the handshake processing unit 113 and transmitted to the client 200 and the role servers 130 and 140 via the TCP connection processing unit 111.
The handshake processing unit 113 performs a part of the simplified handshake process with the client 200 and the role servers 130 and 140 in addition to the complete handshake with the client 200 as described above.

FIG. 3 is a diagram showing the internal structure of the role server of the present invention. Although the internal structure of the role 1 server 130 is shown here, the internal structure of the role 2 server 140 is the same.
The TCP connection processing unit 131 accepts a connection from the relay server 110, passes received data to the record processing unit 132, and conversely transmits data received from the record processing unit 132 to the relay server 110.

The record processing unit 132 processes data received from the relay server 110 received via the TCP connection processing unit 131. For processing contents, the received data is divided into record units, the contents are transferred to the handshake processing unit 133 and the server data processing unit 134 according to the record contents, and in the case of compressed data, in the case of decompression and encrypted data For example, decryption is performed. Conversely, the message is received from the handshake processing unit 133 and the application data is received from the server data processing unit 134, compressed or encrypted, and transmitted to the relay server 110 via the TCP connection processing unit 131.
The handshake processing unit 133 performs a simple handshake with the client 200 via the relay server 110.

  The server data processing unit 134 performs original application processing. The processing performed by the server data processing unit 134 is limited by the function of the secure OS within the range of resource access given to the role server 130. Therefore, even if the role server 130 encounters unauthorized access, the scope of damage is limited.

  FIG. 4 is a diagram showing the structure of the SID and role-related database of the present invention. Each row indicates one record in the database, and includes a SID field 151 and a role field 152. The value of the SID field 151 is composed of 16 bytes, and is represented by a hexadecimal number. The record of this database is created when the relay server 110 performs a complete handshake process. The client is referred to during the simplified handshake process performed when the client accesses the server again, and is used to determine which role server 130 or 140 to relay communication according to the value of the SID field.

  FIG. 5 is a diagram showing the structure of the user and role-related database 160 according to the present invention. Each row represents one record in the database, and includes a user field 161 and a role field 162. Referenced when the client 200 performs a complete handshake process when accessing the server 110 for the first time. That is, the role is determined from the client user who has been authenticated through the handshake process, and is used to determine which role server 130, 140 to which the communication is relayed.

FIG. 6 is a diagram showing the structure of the TLS session information database 1 of the present invention.
The indexes 171 and 173 use the SID as it is. The index 171 corresponds to the SID 151 in the fourth row corresponding to the role 1 shown in FIG. 4, and the index 173 similarly corresponds to the SID 151 in the third row corresponding to the role 1. The data 172 and 174 are data corresponding to the indexes 171 and 173 themselves, and include cryptographic algorithms and key lengths used for sessions corresponding to SIDs, and random number data used for key generation.

FIG. 7 is a flowchart showing the processing contents by the relay server of the present invention. Hereinafter, it demonstrates according to a flowchart.
First, the TCP connection cushion processing unit 111 in the relay server 110 accepts a connection request from a client and passes received data to the record processing unit 112 (step 701). Subsequent transmission / reception with the client is performed via the TCP connection processing unit 111.
Next, the record processing unit 112 analyzes the received data, extracts the upper data, confirms that it is a handshake message, and passes it to the handshake processing unit 113 (step 702). Here, the received data is in the format of TLS Record Protocol (see Non-Patent Document 1), and this processing unit 112 performs processing of the TLS protocol, and takes out the upper alert, handshake, and application data. Since this process is outside the scope of the present invention, details are not described here.

Next, the handshake processing unit 113 performs handshake processing (step 703). Details of the processing will be described later with reference to FIG.
Next, after the handshake process, the TCP connection processing unit 111 relays communication between the client 200 and the role servers 130 and 140 (step 704). After the handshake process, the relay server 110 performs only the relay process.

FIG. 8 is a flowchart showing details of processing performed by the handshake processing unit of the present invention. It is the detail of the handshake process of step 703 shown in FIG.
First, the handshake processing unit 113 in the relay server 110 confirms that the handshake message received from the record processing unit 112 is a ClientHello message, and further, the first TLS session from the client 200 or a past session is confirmed. It is determined whether or not to resume (step 801). The determination is determined by the SID field in the message. That is, if the SID field is blank, it is the first session, and if the SID is entered, it indicates resumption.
Next, a complete handshake process is performed for the first session, and a simplified handshake process is performed if the past session is resumed (step 802).

FIG. 9 is a flowchart showing details of the complete handshake process described in Step 802 of FIG.
The handshake processing unit 113 generates a handshake message such as ServerHello and transmits it to the client 200 via the record processing unit 112 and the TCP connection processing unit 111 (step 901).
Next, the handshake processing unit 113 receives and processes a message such as Certificate transmitted by the client 200 and received via the TCP connection processing unit 111 and the record processing unit 112 (step 902). Through this process, the client 200 of the communication partner is authenticated and the client user is identified.
Next, a handshake message such as Finished is generated and transmitted to the client 200 (step 903).
Note that the above message generation / processing method conforms to the TLS protocol (see Non-Patent Document 1), which is a standard, and will not be described in detail.

Next, the handshake processing unit 113 searches the user and role-related database 160 for the role for the client user authenticated in step 902 to determine which role server 130 or 140 is the relay destination. As shown in FIG. 5, the role search is performed by searching for a record having a user field 161 corresponding to the authenticated user and recognizing the value of the role field 162 of the record (step 904).
Next, the handshake processing unit 113 registers the SID and the role of the client user acquired in Step 904 in the SID and role related database 150 (Step 905). As the SID, the SID included in the ServerHello message generated in step 901 is used. For registration, an SID is generated in the SID field 151 and one record having a role is generated in the role field 152 and added to the SID and role-related database 150.

Next, the handshake processing unit 113 adds the session information 172 and 174 acquired by the processing in steps 901 and 902 to the TLS session information database 170 or 180 of the relay destination role server 130 or 140 determined in step 904. (Step 906). The method for generating the session information 172 and 174 follows the TLS protocol, and as shown in FIG. 6, there are a communication partner type, a bulk data encryption algorithm, an encryption type, random number data used for key generation, and the like.
Thereafter, the simplified handshake process is performed between the role server 130 or 140 determined in step 904 and the relay server 110.

  The handshake processing unit 113 generates a ClientHello message including the SID and transmits it to the role server 130 or 140. In order to transmit this message, it is transmitted via the record processing unit 112 and the TCP connection processing unit as in the case of transmitting to the client 200 (step 907). Here, since it is necessary to establish a TCP connection by TCP between the relay server 110 and the role server 130 or 140, the connection process is performed by the TCP connection processing unit 111.

Next, the handshake processing unit 113 receives a ServerHello message or the like from the role server 130 or 140 (step 908). The TLS session information databases 170 and 180 of the role servers 130 and 140 include the TLS session information of the SID, and the role servers 130 and 140 perform a simple handshake.
Next, the handshake processing unit 113 generates a ChangeCipherSpec and a Finished message and transmits it to the role server 130 or 140 (step 909).
Through the above processing, the client 200 and the role servers 130 and 140 can share TLS session information and perform TLS communication.

  Next, the handshake processing unit 113 discards the session information (Step 910). This includes not only erasing the memory unit storing the TLS session information but also erasing it by overwriting with a null character or random number. By performing such processing, even if the relay server 110 is illegally accessed, the session information is not stolen.

Next, a simplified handshake process that is performed when a past session is resumed will be described. FIG. 10 is a flowchart showing details of the simplified handshake process described in Step 802 of FIG.
The handshake processing unit 113 searches the SID and role-related database 150 using the SID included in the ClientHello message as a key, and determines the corresponding role server 130 or 140. A role server is determined by the value of the role field 152 corresponding to the SID of the SID field 151 shown in FIG. 4 (step 1001).

  Next, the previous ClientHello message is transmitted to either the role server 130 or 140. This message is transmitted through the record processing unit 112 and the TCP connection processing unit 111 as in the case of transmitting to the client 200 (step 1002). Here, in order to complete the simplified handshake process, it is necessary to exchange messages such as ServerHello, ChangeCipherSpec, and Finished in addition to ClientHello. These messages are exchanged by either the client 200 or the role server 130 or 140. The relay server 110 only relays the message. Step 1002 of this simplified handshake process corresponds to the relay process performed by the TCP connection processing unit 111 shown in step 704 of FIG.

FIG. 11 is a flowchart showing details of processing of the role server of the present invention. Here, the processing of the role server 130 will be described, but the processing of the role server 140 is the same.
The TCP connection processing unit 131 in the role server 130 receives the connection request from the relay server 110 and passes the received data to the record processing unit 132 (step 1101). This connection request corresponds to a connection request generated when the relay server 110 transmits a ClientHello message in Step 907 of FIG. 9 and Step 1002 of FIG. Transmission / reception between the relay server 110 and the role server 130 is performed via the TCP connection processing unit 131.

  Next, the record processing unit 132 analyzes the received data, extracts the upper data, confirms that the message is a handshake message, and passes it to the handshake processing unit 133 (step 1102). The received data conforms to the TLS Record Protocol format (see Non-Patent Document 1). The record processing unit 132 performs processing of this protocol, and fetches upper alert, handshake, and application data.

  Next, the handshake processing unit 133 performs handshake processing. In the case of the first session received from the client 200, reception of the ClientHello message of the role server 130 for the simplified handshake processing shown in steps 907 to 909 shown in FIG. 9, generation and transmission of a message such as ServerHello, ChangeCipherSpec, Finished message Processing such as sending. In the case of session resumption, the ClientHello message generated by the role server 130, the generation of a message such as ServerHello and the transmission to the client 200 via the relay server 110, the ChangeCipherSpec generated by the client 200 and relayed by the relay server 110 Then, processing such as reception of a Finished message is performed (step 1103).

  Here, the description is made by distinguishing whether the connection from the client 200 is the first time or the resumption, but the simplified handshake process is the same, and the handshake processing unit 133 performs the process without distinction. The complete handshake process is performed by the relay server 110, and the TLS session information obtained as a result is included in the TLS session information database 170, and the simplified handshake process is performed using the session information in this database. I do. Therefore, it is not necessary to generate TLS session information again for the second and subsequent access from the client, and this generation process can be omitted, and the role server can reuse this session information. It becomes possible to reduce the load of the entire computer system.

Next, the record processing unit 132 analyzes the received data, extracts the upper data, confirms that it is application data, and passes it to the server data processing unit 134. The record processing unit 132 uses the session information in the TLS session information database 170 to detect decryption or falsification of received data, and encrypts transmission data or adds falsification detection data (1104).
As described above, in the first embodiment, the TLS session information is shared between the relay server and the role server, so that the load can be reduced and the operation efficiency can be greatly improved.

(Embodiment 2)
In the first embodiment, a relay server and a role server are arranged on one computer, and access from the relay server 110 to the TLS session information databases 170 and 180 attached to the role servers 130 and 140 is the same as in the first embodiment. If it can be similarly limited, even if each server is arranged on a separate computer, equivalent security can be ensured. The embodiment will be described below.
FIG. 12 is a diagram illustrating a configuration of a computer system according to the second embodiment.
As shown in FIG. 12, the computer system includes a plurality of computers 100, 300, and 400, each running a secure OS.

  Differences from the first embodiment shown in FIG. 1 will be described. In the first embodiment, the relay server 110 and the role servers 130 and 140 are operating on one computer 100 on which the secure OS is operating, whereas in the second embodiment, each server is respectively The relay server 110 is running on another computer, the role 1 server 130 is running on the computer 300, and the role 2 server 140 is running on the computer 400. Further, it is restricted so that only the computer 100 on which the relay server 110 is operated can be accessed from the external network that is the starting point of unauthorized access, and the computers 300 and 400 on which the role servers 130 and 140 are operated cannot be accessed. This can be realized by a known technique such as a firewall.

  In the first embodiment, the relay server 110 performs the TLS handshake process with the client 200 and writes the obtained TLS session information in the TLS session information databases 170 and 180 of the role servers 130 and 140. Thus, in the second embodiment, writing is performed via the database servers 310 and 410 on the computers 300 and 400.

In the first embodiment, the function of the secure OS running on the computer 100 is used to limit the relay server 110 so that it can write to the TLS session information databases 170 and 180 but cannot read it. On the other hand, in the second embodiment, the database servers 310 and 410 write (w; write) to the TLS session information databases 170 and 180 using the function of the secure OS running on the computers 300 and 400. Even if it is possible, it is restricted so that it cannot be read (r; read). As described above, by providing the database servers 310 and 410 and restricting access to the TLS session information databases 170 and 180, the relay server 110 receives unauthorized access as in the first embodiment, and the database servers 310 and 410 are further accessed. Even if an unauthorized access is received, the TLS session information is not read, and security equivalent to that of the first embodiment can be maintained. In order to further increase the security level, communication from the relay server 110 to the database servers 310 and 410 is restricted by using the secure OS function so that application data is sent only in one direction from the relay server to the database servers 310 and 410. You may make it do.
Further, as in the first embodiment, by sharing information, a part of the processing is omitted and the load on the server is reduced, so that high-speed TLS protocol processing can also be realized.

1 is a diagram illustrating a configuration of a computer system according to a first embodiment. It is a figure which shows the internal structure of the relay server of this invention. It is a figure which shows the internal structure of the role server of this invention. It is a figure which shows the structure of SID of this invention, and a role relevant database. It is a figure which shows the structure of the user and role related database of this invention. It is a figure which shows the structure of the TLS session information database 1 of this invention. It is a flowchart which shows the processing content by the relay server of this invention. It is a flowchart which shows the detail of the process which the handshake process part of this invention performs. It is a flowchart which shows the detail of the complete handshake process described in step 802 of FIG. It is a flowchart which shows the detail of the simple handshake process described in step 802 of FIG. It is a flowchart which shows the detail of a process of the role server of this invention. FIG. 3 is a diagram illustrating a configuration of a computer system according to a second embodiment.

Explanation of symbols

100 Computer 110 Relay Server 111 TCP Connection Processing Unit 112 Record Processing Unit 113 Handshake Processing Unit 120 User and Role Related Registration Tool 130 Role 1 Server 131 TCP Connection Processing Unit 132 Record Processing Unit 133 Handshake Processing Unit 140 Role 2 Server 150 SID And role-related database 151 SID field 152 role field 160 user and role-related database 161 user field 162 role field 170 TLS session information database 1
180 TLS session information database 2
300, 400 Computer 310 Database server 1
410 Database server 2

Claims (4)

Secure OS is running,
A relay server that accepts a request from a client; a role server that is assigned a domain and a role to perform application processing; a first database that holds a relation between the user of the client and its role; a session ID of a TLS protocol, and the domain and role A second database that holds the association, and a third database that holds session information of the TLS protocol prepared for each of the role servers,
In the TLS session information takeover method executed by a computer system in which the relay server has only the authority to read the first database and only the authority to write to the third database. There,
The relay server is
For TLS protocol processing, only handshake processing is performed, the user authenticated at the time of handshake processing, the role obtained from the first database and the session ID of the TLS protocol are written to the second database, and the TLS session Discarding information after writing it into the third database after handshake processing and relaying encrypted application data to the role server;
Further, when resuming a session based on the TLS protocol, a corresponding role server is determined from the second database using a session ID included in a message received from a client at the start of the session as a key, and the message is sent to the role server. And relaying including
The role server is
Performing a handshake process by a TLS protocol using the TLS session information written in the third database. A method for taking over TLS session information. The relay server and the role server are arranged in different computers that individually run secure OSs,
In the computer on which the role server is arranged, a database additional server having only the right to write to the third database is arranged,
The handover of the TLS session information according to claim 1, wherein the relay server has a step of discarding the TLS session information after writing it in the third database after the handshake process via the database addition server. Method. Secure OS is running,
A relay server that accepts a request from a client; a role server that is assigned a domain and a role to perform application processing; a first database that holds a relation between the user of the client and its role; a session ID of a TLS protocol, and the domain and role A second database that holds the association, and a third database that holds session information of the TLS protocol prepared for each of the role servers,
The relay server has only the authority to read the first database and only the authority to write to the third database;
The relay server is
For the TLS protocol processing, only the handshake processing is performed, the user authenticated at the time of the handshake processing, the role acquired from the first database and the session ID of the TLS protocol are written in the second database, and the TLS session Discarding the information after writing it into the third database after handshake processing, relaying the encrypted application data to the role server,
Further, when resuming a session based on the TLS protocol, a corresponding role server is determined from the second database using a session ID included in a message received from a client at the start of the session as a key, and the message is sent to the role server. Relay, including
The role server is
A computer system that performs handshake processing by a TLS protocol using the TLS session information written in the third database. The relay server and the role server are arranged in different computers that individually run secure OSs,
In the computer on which the role server is arranged, a database additional server having only the right to write to the third database is arranged,
The computer system according to claim 3, wherein the relay server discards the TLS session information after writing it in the third database after handshake processing via the database addition server.

Images