JP2006217446A - Remote conference system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a remote conference system provided with a relay server, which is capable of preventing leakage of the conference contents in the relay server. <P>SOLUTION: In a remote conference system, public keys corresponding to closed keys generated in respective user terminals 120 and 130 are preliminarily registered in a member information file 115 of a relay server 110 as member information. A conference holding means 122 of the sponsor-side user terminal 120 generates an encryption key for conference, acquires the public key of the participant-side user terminal 130 from the relay server 110, and encrypts the encryption key for conference by the public key and transmits the encrypted public key to the participant-side user terminal 130 via the relay server 110. A conference data transmission/reception means 123 of the sponsor-side user terminal 120 and a conference data transmission/reception means 133 of the participant-side user terminal 130 transmit and receive conference data encrypted by the encryption key for conference, via a conference data relay means 114 of the relay server 110. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a remote conference system via a network, and more particularly to a configuration for encrypting and transmitting conference data between client terminals via a relay server.

Conventionally, as a remote conference system, a system that transmits and receives conference data such as voice data between user terminals connected via a communication network has been used.
In this case, a method in which a plurality of user terminals access the conference server on the organizer side is also conceivable, but it has not been easy to realize between different companies due to firewall settings. In other words, in a corporate network, a firewall is generally installed between the internal network and the external network to restrict communication. Therefore, when accessing the conference server from a user terminal on the external network, the firewall setting must be made. Changes were necessary. In this case, in order to maintain high security, it is necessary to minimize the range in which communication is permitted. Therefore, the network address of the transmission source, the network address of the reception destination, and the port that allows data to pass through Numbers etc. were set finely. Therefore, there is a problem that a great burden is imposed on the conference manager or the network manager, and it is not possible to easily cope with addition of a new conference participant, change of the network address of the conference participation terminal, and the like. there were. Furthermore, there is a problem that a company that adopts a security policy that does not accept any firewall setting change cannot perform a remote conference.
Therefore, as a remote conference system including a relay server that relays conference data transmitted and received between the terminals, the relay server includes means for transmitting conference data using a predetermined communication protocol permitted by each terminal. The provided structure is publicly known (for example, refer to Patent Document 1).
JP 2001-258001 A

  In the remote conference system described in Patent Document 1, a relay server uses a communication network (for example, HTTP) permitted by a corporate network in which a firewall is installed to transmit and receive conference data, thereby providing a firewall. It is possible to realize a remote conference among a plurality of corporate networks that have installed. Here, in the transmission / reception of the conference data when using HTTP, the relay server receives an HTTP request including the conference data from each terminal and transmits the HTTP response to the HTTP request including the conference data.

  However, in the remote conference system described in Patent Document 1, since the conference data transmitted and received between the user terminals is transmitted as it is to the relay server, the conference server can acquire the conference data, and the relay server There was a risk of the contents of the meeting leaking to other service providers.

  The present invention has been made to solve the above-mentioned problems, and an object thereof is to provide a remote conference system capable of preventing leakage of conference contents at the relay server in a remote conference system having a relay server. .

In order to solve the above problems, the present invention is connected to a conference organizer side terminal and a conference participant side terminal via a network, and transmits and receives between the conference organizer side terminal and the conference participant side terminal. A teleconferencing system comprising a relay server having means for relaying conference data to be transmitted, wherein the relay server receives a public key corresponding to a private key generated and registered in advance at each terminal. Means for registering in association with the identification ID; and a public key corresponding to the terminal identification ID of the conference participant side terminal on the conference organizer side terminal in response to the participation request received from the conference participant side terminal. The conference organizer side terminal encrypts the conference encryption key generated in advance with the public key included in the participation request confirmation message received from the relay server, Means for transmitting to the conference participant side terminal via a relay server; and encrypting the conference data with the conference encryption key and transmitting the conference data to the relay server; and the encrypted conference data received from the relay server The conference participant side terminal decrypts and registers the encrypted conference encryption key received via the relay server with a pre-registered private key. Means for encrypting the conference data with the conference encryption key and transmitting the encrypted conference data to the relay server, and decrypting the encrypted conference data received from the relay server with the conference encryption key. It is characterized by.
Each terminal includes a session key received from the relay server, and includes means for encrypting a sequence number indicating the number of transmissions of a message including conference data with the session key and including the sequence number in a conference data transmission / reception message, A relay server for registering a session key for each terminal in association with the terminal identification ID; a means for registering a sequence number indicating the number of messages received for each terminal in association with the terminal identification ID; The encrypted sequence number included in the conference data transmission / reception message is decrypted with a session key associated with a terminal identification ID indicating a destination terminal of the conference data transmission / reception message, and is registered in association with the terminal identification ID. Whether or not the decoded sequence number matches or does not match, and the conference data transmission is determined according to the determination result. Registers the encrypted conference data contained in the signal message, characterized in that it comprises means for returning the encrypted conference data to the terminal identification ID included in the conference data communication message destined ID.

With the above configuration, in the present invention, the conference encryption key for encrypting / decrypting the conference data is encrypted with the public key corresponding to the private key generated and registered in the participant side terminal, and relayed Since the encrypted conference encryption key cannot be decrypted by the relay server because it is sent to the participant's terminal via the server, plaintext conference data is not acquired at the relay server. It becomes possible to prevent leakage of conference contents.
In addition, since the relay server determines whether the sequence numbers indicating the number of messages transmitted / received between the relay server and each terminal match / mismatch, it is possible to prevent spoofing by a malicious third party. It becomes possible. In particular, since the sequence number is encrypted / decrypted using a session key registered in advance for each terminal in the relay server, even if an HTTP request or an HTTP response is intercepted, a third party Since the sequence number is never known, it is possible to more reliably prevent spoofing by a third party.

Hereinafter, a conference system according to an embodiment of the present invention will be described with reference to the drawings.
FIG. 1 is a block diagram showing a schematic configuration of a remote conference system according to the present embodiment.
The remote conference system 100 according to the present embodiment includes a relay server 110 that relays conference data. The relay server 110 is configured to be accessible from the organizer-side user terminal 120 and the plurality of participant-side user terminals 130 via a communication network such as the Internet, and includes a member information registration receiving unit 111 and a conference holding receiving unit 112. , The conference participation receiving unit 113 and the conference data relay unit 114, and the information storage units of the member information file 115, the conference information file 116, and the conference data file 117 are provided.
The organizer-side user terminal 120 includes member information registration unit 121, conference holding unit 122, conference data transmission / reception unit 123, and information storage units of a private key file 124 and a conference encryption key file 125. Yes.
The participant-side user terminal 130 includes processing units such as a member information registration unit 131, a conference participation unit 132, and a conference data transmission / reception unit 133, and information storage units such as a private key file 134 and a conference encryption key file 135. Yes.
In the remote conference system 100 according to the present embodiment, a public key / private key pair is generated in advance at each user terminal 120, 130, and the public key is transmitted to the relay server 110 at the time of member information registration. It is registered in the member information file 115 of the server 110.
The organizer-side user terminal 120 generates a conference encryption key, obtains the public key of the participant-side user terminal 130 from the relay server 110, encrypts the conference encryption key with the public key, and sets the relay server 110. To the participant-side user terminal 130.
The organizer-side user terminal 120 and the participant-side user terminal 130 transmit and receive the conference data encrypted with the conference encryption key via the relay server 110. In this case, a communication protocol such as HTTP is used for communication between the user terminals 120 and 130 and the relay server 110.

FIG. 2 is a diagram showing main encrypted data exchanged between the organizer side or participant side user terminals 120 and 130 and the relay server in the member information registration process.
First, the member information registration means 121 and 131 of the user terminals 120 and 130 transmit the public key arbitrarily generated to the relay server 110.
The member information registration accepting unit 111 of the relay server 110 encrypts a public key confirmation random number using the received public key and transmits it to the user terminals 120 and 130.
The member information registration means 121 and 131 of the user terminals 120 and 130 decrypt the public key confirmation random number encrypted using the private key corresponding to the public key, and return the random number to the relay server 110. .
As a result, the member information registration accepting unit 111 of the relay server 110 confirms the validity of the public key transmitted from each of the user terminals 120 and 130 and registers it in the member information file 115.

FIG. 3 is a flowchart showing details of member information registration processing performed by the member information registration means 121 and 131 of the user terminals 120 and 130 on the organizer side or the participant side and the member information registration reception means 111 of the relay server 110. .
The member information registration means 121, 131 of each user terminal 120, 130 accepts an input of a user ID arbitrarily determined by the user (step 301), and generates a public key / private key (step 302). Here, a public key / private key pair is generated based on publicly known public key encryption technology, and a ciphertext encrypted with the public key cannot be decrypted unless the private key is used. .
Each member information registration means 121, 131 stores the private key in the private key files 124, 134 (step 303), generates a member information registration message including the public key, and stores it in the data part of the HTTP request. Then, it is transmitted to the relay server 110 (step 304). In this case, the member information registration message includes at least a message type, a desired user ID for user identification, and a public key.
The member information registration receiving means 111 identifies the message type included in the data part of the received HTTP request, determines that it is a member information registration message (step 305), and the user ID included in the member information registration message Based on the information, the member information file 115 is referred to, and it is confirmed whether the user ID does not match that already registered (step 306).
If it does not match the user ID registered in the member information file 115, a random number for key confirmation is generated, and the user ID and the random number for key confirmation are recorded in the key confirmation data storage area (step 307).
The generated key confirmation random number is encrypted with the public key included in the member information registration message (step 308), a key confirmation inquiry message including the encrypted data is generated, and stored in the data part of the HTTP response to the HTTP request. Then, it is returned to the user terminals 120 and 130 (step 309).
Each member information registration means 121, 131 identifies the message type of the key confirmation inquiry message included in the data part of the received HTTP response, determines that it is a member information registration message, and uses the encrypted key confirmation message The random number is decrypted with the private key stored in the private key files 124 and 134 (step 310).
A key confirmation response message including the decrypted random number for key confirmation is generated, stored in the data part of the HTTP request, and transmitted to the relay server 110 (step 311).
The member information registration receiving unit 111 identifies the message type and determines that the message is a key confirmation response message (step 312), and based on the user ID and the key confirmation random number included in the key confirmation response message, the key confirmation data After confirming that it matches the key confirmation random number recorded in the storage area (step 313), the member information is registered in the member information file 115 (step 314). In this case, the registered information is deleted from the key confirmation data storage area.
After registering the member information, the member information registration accepting unit 111 generates a member registration completion message, stores it in the data part of the HTTP response, and returns it to the user terminals 120 and 130 (step 315).
Each member information registration unit 121, 131 displays the received member registration end message and ends the process (step 316).
In step 306, if the user ID included in the member information registration message is already registered, a response message including a message indicating that the user ID desired by the user has already been used is sent to the user terminal 120, Reply to 130. The member information registration means 121 and 131 of the user terminals 120 and 130 that have received the response message display a message to prompt the user ID to be re-input, and when the input of a new user ID is accepted, the relay server again. A member information registration message is transmitted to 110.
In step 313, if the key confirmation random number included in the key confirmation response message and the key confirmation random number recorded in the key confirmation data storage area do not match, the member information registration accepting unit 111 The information for the member is deleted from the confirmation data storage area, and a member information registration failure message is returned to the user terminals 120 and 130. The member information registration units 121 and 131 of the user terminals 120 and 130 that have received the member information registration failure message display an error message and end the processing.

FIG. 4 is a diagram illustrating an example of a member information registration message that the member information registration units 121 and 131 of the user terminals 120 and 130 transmit to the relay server 110 in the member information registration process.
The member information registration message 400 is generated and transmitted by the member information registration means 121 and 131 in the member information registration process, and includes a message type, a desired user ID, a mail address, and a public key.
The message type is for identifying that the message is a member information registration message. In this example, the message type is composed of a character string of “member information registration”. The desired user ID is composed of a character string arbitrarily selected by the user, and the relay server 110 determines the presence or absence of duplicate registration. The public key is arbitrarily generated by the user terminals 120 and 130, and is used for encryption of a public key confirmation random number in the member information registration process and also for encryption of a meeting encryption key described later.

FIG. 5 is a diagram illustrating an example of the data structure of the member information file 115 provided in the relay server 110.
The member information file 500 shown in FIG. 5 stores information included in the member information registration message received from the user terminals 120 and 130 in the member information registration process, and includes a user ID 501 for identifying each user and a mail address 502. And the public key 503.
The member information registration receiving unit 111 of the relay server 110 searches the member information file 115 based on the user ID included in the member information registration message received from the user terminals 120 and 130, and checks the presence / absence of registration.

FIG. 6 is a diagram illustrating an example of the data structure of the key confirmation data used for the member information registration process.
The key confirmation data 600 includes a user ID included in the member information registration message and a key confirmation random number generated randomly for the user ID.
The member information registration receiving unit 111 of the relay server 110 encrypts the random number included in the key confirmation data with the public key included in the member information registration message.

FIG. 7 is a diagram illustrating an example of a key confirmation inquiry message transmitted from the member information registration receiving unit 111 of the relay server 110 to the user terminals 120 and 130.
The key confirmation inquiry message 700 includes a message type indicating a “key confirmation inquiry” and an encrypted random number.
The member information registration accepting unit 111 of the relay server 110 includes the random number encrypted with the public key in the key confirmation inquiry message and transmits it to the user terminals 120 and 130.

FIG. 8 is a diagram showing an example of a key confirmation response message returned by each member information registration unit 121, 131 in response to the key confirmation inquiry message.
The key confirmation response message 800 is decrypted with a message type indicating “key confirmation response”, its own user ID, and the private keys stored in the private key files 124 and 134 of the user terminals 120 and 130. And random numbers.
The member information registering means of the user terminals 120 and 130 acquires the encrypted random number included in the key confirmation inquiry message, decrypts it with the private key, and includes the decrypted random number in the key confirmation response message 800. Send back.

FIG. 9 is a diagram illustrating an example of a member information registration completion message transmitted to the user terminals 120 and 130 by the member information registration receiving unit 111 of the relay server 110.
The member information registration completion message 900 includes a message type indicating “member information registration completion” and a user ID registered in the member information file 115.
The member information registration accepting unit 111 of the relay server 110 compares the random number included in the key confirmation response message 800 acquired from the user terminals 120 and 130 with the random number stored in the key confirmation data storage area, and matches. If it is, the member information is registered in the member information file 115 and a member information registration completion message 900 is transmitted to the user terminals 120 and 130.

  Through the above processing, the user ID and public key for each user terminal 120 and 130 are registered in the member information file 115 of the relay server 110.

Next, a conference data transmission / reception processing method using the remote conference system 100 according to the present embodiment will be described.
In the present embodiment, the meeting holding reception unit 112 of the relay server 110 receives the meeting holding request from the meeting holding unit 122 of the organizer-side user terminal 120 and performs the meeting holding process, and from the participant-side user terminal 130. After receiving the participation request and registering the conference participant, the relay processing of the conference data transmitted and received between the user terminals 120 and 130 is performed.

FIG. 10 is a diagram showing encrypted data transmitted and received in the conference holding process.
In the conference holding process, a session key randomly generated by the conference holding reception unit 112 of the relay server 110 for the organizer-side user terminal 120 in response to the conference holding request from the conference holding unit 122 is stored in the member information file 115. Encrypt with the registered public key and send.
The conference holding unit 122 acquires the session key by decrypting the received encrypted session key with its own private key, encrypts the registered sequence number with the session key, and transmits the encrypted sequence key to the relay server 110.
The conference holding reception unit 112 decrypts the sequence number encrypted in this way with the session key, and confirms the match / mismatch with the sequence number stored in the conference information file 116. Check validity.

FIG. 11 is a flowchart showing a conference holding process procedure performed between the conference holding unit 122 of the organizer-side user terminal 120 and the conference holding reception unit 112 of the relay server 110.
The meeting holding means 122 of the organizer-side user terminal 120 transmits a meeting holding request message including the message type and the registered user ID to the relay server 110 in response to the meeting holding operation by the organizer-side user (step) 1101).
The meeting holding reception unit 112 of the relay server 110 identifies the message type, determines that the message is a meeting holding request message (step 1102), and sets the sequence number indicating the number of messages received from the user ID to “0”. While setting (step 1103), a random session key is generated and stored in the conference information file 116 (step 1104).
The generated session key is encrypted with the public key registered in association with the user ID (step 1105) and included in the user authentication request message and transmitted to the user terminal 120 (step 1106).
The conference holding means 122 decrypts the encrypted session key included in the received user authentication request message, and stores the plaintext session key in the conference encryption key file 125 (step 1107). In the conference encryption key file 125, “0” is stored in the sequence number in association with the plaintext session key (step 1108), and the randomly generated conference encryption key is stored (step 1109).
The conference holding unit 122 stores each data in the conference encryption key file 125, and then generates a conference data transmission / reception permission request message including a message type, a user ID, and a sequence number (step 1110). A conference data transmission / reception permission request message including encrypted data encrypted with the session key is transmitted to the relay server 110 (step 1111). Here, as an encryption process using a session key, a common common key encryption technique is used, and a session key is used for both encryption / decryption processes.
The meeting holding reception unit 112 identifies the message type (step 1112), acquires the session key from the meeting information file 116 based on the user ID included in the meeting data transmission / reception permission request message, and encrypts the meeting data transmission / reception permission request message. The encrypted data is decrypted (step 1113). The sequence number included in the decrypted data is acquired, and it is confirmed that the sequence number matches the sequence number stored in the conference information file 116 (step 1114). 1 is added to the existing sequence number (step 1115).
After performing the above processing, the relay server 110 waits for a connection from the participant-side user terminal 130 (step 1116). That is, when the sequence number is 1 or more, it means that the conference participation reception unit 113 is waiting for a connection from the participant-side user terminal 130.
If the sequence numbers do not match at step 1114, the user information is deleted from the conference information file 116, and a user authentication failure message including an error message is returned to the conference organizer 122.

FIG. 12 is a diagram illustrating an example of a meeting holding request message transmitted from the meeting holding unit 122 of the organizer-side user terminal 120 to the relay server 110 in the meeting holding process.
The meeting holding request message 1200 includes a message type indicating “conference holding request” and a user ID for identifying a user who is a host.
The meeting holding unit 122 transmits a meeting holding request message 1200 including the user ID registered in the member information file 115 of the relay server 110 to the relay server 110.

FIG. 13 is a diagram illustrating an example of the data structure of the conference information file 116 managed by the relay server 110.
The conference information file 1300 shown in FIG. 13 includes a user ID 1301 indicating a user terminal of a user who is an organizer or a participant, a session key 1302 randomly generated for each user, a sequence number 1303, an organizer / It has a participant type 1304 and an organizer ID 1305 indicating the user terminal of the user who is the organizer of the conference. In this example, the organizer's user ID is added, and the session key and sequence number are registered. The organizer / participant type 1304 is “host”, and the host ID 1305 is “−”.
The meeting holding reception unit 112 searches the member information file 115 based on the user ID included in the meeting holding request message 1200, acquires the public key, and encrypts the randomly generated session key with the public key.

FIG. 14 is a diagram illustrating an example of a user authentication request message returned from the meeting holding reception unit 112 of the relay server 110 to the organizer-side user terminal 120.
The user authentication request message 1400 includes a message type indicating “user authentication request” and an encrypted session key. The session key is randomly generated by the relay server 110 and is encrypted with the public key stored in the member information file 115 of the relay server 110.
The meeting holding reception unit 112 returns a user authentication request message 1400 including an encrypted session key to the organizer side user terminal 120 as a response to the meeting holding request message 1200.

FIG. 15 is a diagram showing an example of the data structure of the conference encryption key file 125 that stores the session key and the like received from the relay server 110 by the conference organizer 122 of the organizer-side user terminal 120.
The conference encryption key file 1500 shown in FIG. 15 includes a decrypted session key 1501, a sequence number 1502, and a conference encryption key 1503.
The organizer-side user terminal 120 decrypts the encrypted session key included in the received user authentication request message 1400, randomly generates a conference encryption key, and stores it in the conference encryption key file 125.

FIG. 16 is a diagram illustrating an example of a conference data transmission / reception permission request message transmitted from the conference host 122 of the organizer-side user terminal 120 to the relay server 110.
The conference data transmission / reception permission request message 1600 includes a message type indicating a “data transmission / reception permission request”, a user ID, and a sequence number.
FIG. 17 is a diagram illustrating a state in which a part (sequence number) of the conference data transmission / reception permission request message 1600 illustrated in FIG. 16 is encrypted.
After generating the conference data transmission / reception permission request message 1600 shown in FIG. 16, the conference holding unit 122 transmits the conference data transmission / reception permission request message 1700 in which the sequence number is encrypted with the session key to the relay server 110 as shown in FIG. 17. Send.

FIG. 18 is a diagram showing encrypted data transmitted and received in the conference participation process.
In the conference participation process, a session key randomly generated by the conference participation reception unit 113 of the relay server 110 is sent to the participant side user terminal 130 in response to the participant side conference holding request from the conference participation unit 132. It is encrypted with the public key registered in the file 115 and transmitted.
The conference participation means 132 decrypts the received encrypted session key with its own private key to acquire the session key, encrypts the registered sequence number with the session key, and transmits it to the relay server 110.
The conference participation reception means 113 decrypts the sequence number encrypted in this way with the session key, confirms the match / mismatch with the sequence number stored in the conference information file 116, and then the sponsor side user terminal The public key of the participant side user terminal 130 is transmitted to 120.
The conference organizing unit 122 of the organizer-side user terminal 120 encrypts an arbitrarily generated conference encryption key using the received public key, and transmits the encrypted conference encryption key to the relay server 110.
The conference participation reception unit 111 receives the encrypted conference encryption key and transfers it to the participant-side user terminal 130.
Thereby, the conference participation means 132 receives the encrypted conference encryption key and decrypts it with its own private key, thereby acquiring the conference encryption key. In this case, since the relay server 110 cannot know the private key of the participant-side user terminal 130, the relay server 110 cannot decrypt the encrypted conference encryption key. Here, as the encryption process using the conference encryption key, a common common key encryption technique is used, and the conference encryption key is used for both encryption / decryption processes.

FIG. 19 is a flowchart showing a conference participation processing procedure performed by the conference participation unit 132 of the participant-side user terminal 130, the conference participation reception unit 113 of the relay server 110, and the conference holding unit 122 of the organizer-side user terminal 120.
As a premise of this process, it is necessary that the conference holding process shown in FIG. 11 is completed and the relay server 110 is in a state of waiting for connection from the participant-side user terminal 130.
The conference participation means 132 of the participant-side user terminal 130 generates a conference participation request message including a message type, a user ID, and an organizer ID, and transmits it to the relay server 110 (step 1901).
The conference participation reception unit 113 of the relay server 110 identifies the message type of the received message (step 1902), sets the sequence number of the conference information file 116 to “0” (step 1903), and sets a random session key. It is generated and stored in the conference information file 116 (step 1904).
Thereafter, the conference participation reception unit 113 encrypts the generated session key with the public key registered in association with the user ID (step 1905), and includes the encrypted session key in the user authentication request message, and the participant user It transmits to the terminal 130 (step 1906).
The conference participation means 132 decrypts the encrypted session key included in the received user authentication request message with the private key stored in the private key file 134, acquires the plaintext session key, and obtains the conference encryption key file 135. (Step 1907). The conference encryption key file 135 stores “0” in the sequence number in association with the plaintext session key (step 1908).
The conference participation unit 132 stores each data in the conference encryption key file 135, and then generates a conference data transmission / reception permission request message including a message type, a user ID, and a sequence number (step 1909). A conference data transmission / reception permission request message including encrypted data encrypted with the session key is transmitted to the relay server 110 (step 1910).
The conference participation reception unit 113 identifies the message type (step 1911), acquires the session key from the conference information file 116 based on the user ID included in the conference data transmission / reception permission request message, and encrypts the conference data transmission / reception permission request message. The encrypted data is decrypted (step 1912). The sequence number included in the decrypted data is acquired, and it is confirmed that the sequence number matches the sequence number stored in the conference information file 116 (step 1913). 1 is added to the existing sequence number (step 1914). Here, in the conference information file 116, since the sequence number is 1 and the organizer / participant type is “participant”, it is determined that the user authentication of the participant is successful.
Thereafter, the conference participation reception unit 113 acquires a public key corresponding to the user ID of the participant from the member information file 115, and organizes a conference participation confirmation message including the message type, the participant user ID, and the participant public key. It transmits to the side user terminal 120 (step 1915).
The meeting holding means 122 of the organizer-side user terminal 120 identifies the message type and displays a message on the display screen or the like indicating that the meeting participation request has been received together with the participant user ID included in the meeting confirmation message (step 1916), the permission of participation by the user on the organizer side is accepted (step 1917).
When the participation permission operation is performed by the organizer side user, the conference organizer 122 encrypts the conference encryption key with the participant public key (step 1918), and generates a participation permission message including the encrypted conference encryption key. Then, it transmits to the relay server 110 (step 1919).
The conference participation reception unit 113 identifies the message type of the received message (step 1920), and transfers the received participation permission message to the participant-side user terminal 130 (step 1921).
The conference participation means 132 identifies the message type of the received message, and decrypts and registers the encrypted conference encryption key included in the participation permission message with the private key registered in the private key file (step 1922). .
Through the above processing, both the organizer-side user terminal 120 and the participant-side user terminal 130 have a common conference encryption key, and the conference data is encrypted with the common conference encryption key and transmitted / received. In the relay server 110, it is possible to prevent the leakage of the conference content.
In step 1913, if the sequence numbers do not match, or if a participation disapproval message is received from the organizer-side user terminal 120, the conference participation reception means 113 reads the user information from the conference information file 116. The information is deleted, and a user authentication failure message including an error message is returned to the participant side user terminal 130.

FIG. 20 is a diagram illustrating an example of a conference participation request message transmitted from the conference participation unit 132 of the participant-side user terminal 130 to the relay server 110.
The conference participation request message includes a message type indicating “conference participation request”, a user ID indicating a participant, and a user ID indicating an organizer.
The conference participation unit 132 transmits a conference participation request message 2000 including the user ID registered in the member information file 115 of the relay server 110 to the relay server 110.

FIG. 21 is a diagram illustrating a state in which the conference participation request message 2000 from the participant-side user terminal 130 is received and the participant is registered in the conference information file 116 managed by the relay server 110.
In this example, a user ID indicating a participant is added to the user ID 2101 of the conference information file 2100, and a session key and a sequence number are registered. The organizer / participant type 2104 is “participant”, and “Nobu” indicating the organizer is registered in the organizer ID 2105.

FIG. 22 is a diagram illustrating an example of a participation confirmation message transmitted from the conference participation reception unit 113 of the relay server 110 to the organizer-side user terminal 120.
The participation confirmation message 2200 includes a message type indicating “participation confirmation”, a user ID indicating the participant, and the public key of the participant.
After accepting the conference participation request from the participant-side user terminal 130, the conference participation reception unit 113 transmits a participation confirmation message 2200 including the participant's user ID and public key to the organizer-side user terminal 120.

FIG. 23 is a diagram illustrating an example of a participation permission message returned from the conference host 122 of the sponsor user terminal 120 to the participant user terminal 130 via the relay server 110.
The participation permission message 2300 includes a message type indicating “participation permission” and a conference encryption key encrypted with the public key of the participant.
The meeting holding unit 122 accepts the participation permission including the meeting encryption key encrypted with the participant's public key in response to the participation permission operation by the user on the organizer side with respect to the participation confirmation message 2200 received from the relay server 110. The electronic message 2300 is transmitted to the participant-side user terminal 130 via the relay server 110.

  The user authentication request message transmitted / received between the participant-side user terminal 130 and the relay server 110, the conference data transmission / reception permission request message, and the conference encryption key file 135 in the participant-side user terminal 130 are shown in FIGS. The configuration is substantially the same as that shown in FIG.

Through the above processing, the organizer-side user terminal 120 or the participant-side user terminal 130
Enables transmission / reception of conference data via the relay server 110.
FIG. 24 is a diagram illustrating encrypted data transmitted and received by the user terminals 120 and 130 via the relay server 110.
Each conference data transmission / reception means 123, 133 of the organizer-side or participant-side user terminals 120, 130 sends, to the relay server 110, the sequence number encrypted with the session key, the conference data encrypted with the conference encryption key, Send.
The conference data relay means 114 of the relay server 110 decrypts the sequence number encrypted with the session key, confirms the match of the sequence numbers, stores the encrypted conference data, and also stores the user terminals 120 and 130. Is sent back to the user terminals 120 and 130 as encrypted destination data.

FIG. 25 is a flowchart showing a processing procedure for transmitting / receiving conference data between the conference data transmission / reception units 123 and 133 of the user terminals 120 and 130 via the conference data relay unit 114 of the relay server 110.
Since the process of the conference data transmission / reception units 123 and 133 on the organizer side and the participant side in the conference data transmission / reception process is common, in this flowchart, the data transmission / reception units 123 and 133 and the conference data relay unit 114 are connected. Only the processing in between is shown.
First, the conference data relay unit 114 of the relay server 110 generates a conference data file 117 according to the conference holding process (FIG. 11) and the conference participation process (FIG. 19) (step 2501). The conference data file 117 is encrypted with a destination user ID for identifying a conference data transmission destination user terminal, a transmission source user ID for identifying a conference data transmission source user terminal, and a conference encryption key. Conference data is stored.
Each conference data transmission / reception means 123, 133 adds “1” to the registered sequence number (step 2502), generates a conference data transmission / reception request message, and transmits it to the relay server (step 2503). The conference data transmission / reception request message includes a message type, a transmission source user ID, a sequence number, a destination user ID, and conference data. Here, the sequence number and the destination user ID are encrypted with the session key to be the first encrypted data, and the conference data is encrypted with the conference encryption key and the second encrypted data is included in the conference data transmission / reception request message. Transmit to the relay server 110.
The conference data relay unit 114 identifies the message type (step 2504), acquires the session key based on the user ID included in the data transmission / reception request, decrypts the first encrypted data, and acquires the sequence number and the destination ID. (Step 2505). The acquired sequence number is confirmed to match the sequence number registered in the member information file 115 (step 2506), and “1” is added to the sequence number to be updated (step 2507). The second encrypted data is stored in the conference data file 117 together with the transmission source ID based on the destination ID (step 2508).
Thereafter, the conference data relay unit 114 acquires second encrypted data (conference data) having the user ID indicated by the transmission source ID as the destination ID from the conference data file 117, and the second encrypted data (conference data). A data transmission / reception response message including is generated and sent back to the user terminals 120 and 130 of the transmission source (step 2509).
The conference data transmission / reception means 123, 133 identifies the message type of the received message, decrypts the second encrypted data contained in the conference data transmission / reception response message with the conference encryption key (step 2511), and displays the conference data. (Step 2512).
With the above processing, the conference data transmitted and received between the user terminals is encrypted with the conference encryption key, so that leakage of the conference data in the relay server 110 is prevented.

FIG. 26 is a diagram illustrating an example of the data structure of the conference data file 117 provided in the relay server 110.
The conference data file 2600 shown in this example includes data items of a destination user ID 2601 indicating a destination of conference data, a source user ID 2602 indicating a source, and conference data 2603 to be transmitted.
The conference data relay unit 114 of the relay server 110 stores the second encrypted data transmitted from each user terminal 120, 130 in the conference data file 117, and sends it to each user terminal 120, 130 based on the destination user ID. The second encrypted data (conference data) is stored in the HTTP response and sent back.

FIG. 27 is a diagram showing an example of a conference data transmission / reception request message transmitted from each conference data transmission / reception means 123, 133 to the relay server 110.
The conference data transmission / reception request message 2700 includes a message type indicating “data transmission / reception request”, a user ID indicating a transmission source, a sequence number, a destination user ID indicating a transmission destination, and conference data.
FIG. 28 is a diagram showing a state in which a part (sequence number, conference data) of the conference data transmission / reception request message 2700 shown in FIG. 27 is encrypted.
Each conference data transmission / reception means 123, 133 generates the conference data transmission / reception request message 2700 shown in FIG. 27, and then encrypts the sequence number with the session key as shown in FIG. The conference data transmission / reception request message 2800 encrypted in the above is transmitted to the relay server 110.

FIG. 29 is a diagram illustrating an example of a conference data transmission / reception response message that the conference data relay unit 114 of the relay server 110 returns in response to the conference data transmission / reception request message 2800.
The conference data transmission / reception response message 2900 includes a message type indicating “data transmission / reception response”, a transmission source user ID indicating the transmission source of the conference data, and encrypted conference data.
The relay server 110 includes the second encrypted data (conference data) stored in the conference data file 2600 in the conference data transmission / reception response message 2900 and sends it back to the user terminals 120 and 130.
Upon receiving the conference data transmission / reception response message 2900, the conference data transmission / reception means 123, 133 of each user terminal 120, 130 decrypts the second encrypted data (conference data) included in the conference data transmission / reception response message 2900 with the conference encryption key. Turn into.

As described above, in the remote conference system according to the present embodiment, the conference data is encrypted and decrypted with the conference encryption key stored in the organizer-side user terminal and the participant-side user terminal. It is possible to prevent leakage of conference contents on the server. In particular, the conference encryption key is generated at the organizer user terminal, and the conference encryption key is encrypted at the organizer user terminal using the public key generated at the participant user terminal via the relay server. Since it is transmitted to the participant-side user terminal, the conference encryption key can be decrypted only by the participant-side user terminal having the private key.
In addition, since the sequence number indicating the number of messages transmitted / received between the relay server and each user terminal is managed, the validity of the message received by the relay server due to the match / mismatch of the sequence numbers is determined. It is possible to appropriately exclude inappropriate conference data transmitted by a third party. In this case, since the sequence number is encrypted / decrypted with the session key generated by the relay server,

  In addition, in the said embodiment, although the organizer side user terminal and the participant side user terminal are distinguished and comprised, not only this but the function of the organizer side user terminal and the participant side user are included in each user terminal. It is good also as providing both the function of a terminal.

It is a block diagram which shows schematic structure of the remote conference system which concerns on one embodiment of this invention. It is a figure which shows the outline | summary of the encryption data transmission / reception process in a member information registration process. It is a flowchart which shows a member information registration process sequence. It is a figure which shows an example of a member information registration message. It is a figure which shows an example of the data structure of a member information file. It is a figure which shows an example of the data structure of the data for key confirmation. It is a figure which shows an example of a key confirmation inquiry message. It is a figure which shows an example of a key confirmation response message. It is a figure which shows an example of a member information registration completion message. It is a figure which shows the outline | summary of the encryption data transmission / reception process in a meeting holding process. It is a flowchart which shows a meeting holding process procedure. It is a figure which shows an example of a meeting holding request | requirement message | telegram. It is a figure which shows an example of the data structure of a meeting information file. It is a figure which shows an example of a user authentication request message. It is a figure which shows an example of the data structure of the encryption key file for meetings. It is a figure which shows an example of a meeting data transmission / reception permission request message. It is a figure which shows the example which encrypted a part of meeting data transmission / reception permission request message. It is a figure which shows the outline | summary of the encryption data transmission / reception process in a conference participation process. It is a flowchart which shows a meeting participation process procedure. It is a figure which shows an example of a meeting participation request message. It is a figure which shows an example of the data structure of a meeting information file. It is a figure which shows an example of a meeting participation confirmation message. It is a figure which shows an example of a meeting participation permission message | telegram. It is a figure which shows the outline | summary of the encryption data transmission / reception process in a meeting data transmission / reception process. It is a flowchart which shows a meeting data transmission / reception processing procedure. It is a figure which shows an example of the data structure of a meeting data file. It is a figure which shows an example of a meeting data transmission / reception request message. It is a figure which shows the example which encrypted a part of meeting data transmission / reception request message. It is a figure which shows an example of a meeting data transmission / reception request response message.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 100 Remote conference system, 110 Relay server, 111 Member information registration reception means, 112 Conference holding reception means, 113 Conference participation reception means, 114 Conference data relay means, 115 Member information file, 116 Conference information file, 117 Conference data file, 120 Organizer side user terminal, 121 Member information registration means, 122 Conference holding means, 123 Conference data transmission / reception means, 124 Private key file, 125 Conference encryption key file, 130 Participant side user terminal, 131 Member information registration means, 132 Conference participation means, 133 Conference data transmission / reception means, 134 Private key file, 135 Conference encryption key file.

Claims (2)

A means for relaying conference data transmitted and received between the conference organizer side terminal and the conference participant side terminal is connected to the conference organizer side terminal and the conference participant side terminal via a network. A teleconferencing system comprising relay servers,
The relay server responds to a participation request received from the conference participant side terminal, a means for registering a public key corresponding to a private key generated and registered in advance in each terminal in association with a terminal identification ID And a means for transmitting a participation request confirmation message including a terminal identification ID of the conference participant side terminal and a public key corresponding to the conference organizer side terminal,
The conference organizer side terminal encrypts the conference encryption key generated in advance with the public key included in the participation request confirmation message received from the relay server, and transmits it to the conference participant side terminal via the relay server. Means for encrypting conference data with the conference encryption key and transmitting the encrypted conference data to the relay server, and decrypting the encrypted conference data received from the relay server with the conference encryption key,
The conference participant side terminal decrypts the encrypted conference encryption key received via the relay server with a pre-registered private key and registers conference data using the conference encryption key. A teleconferencing system comprising: means for encrypting and transmitting to the relay server, and decrypting encrypted conference data received from the relay server with the conference encryption key. Each terminal has a session key received from the relay server, and includes means for encrypting a sequence number indicating the number of transmissions of a message including conference data with the session key and including the sequence number in a conference data transmission / reception message,
Means for registering a session key in association with the terminal identification ID for each terminal; means for registering a sequence number indicating the number of messages received for each terminal in association with the terminal identification ID; The encrypted sequence number included in the conference data transmission / reception message is decrypted with a session key associated with a terminal identification ID indicating a destination terminal of the conference data transmission / reception message, and registered in association with the terminal identification ID. A match between the sequence number being decrypted and the decrypted sequence number is determined, the encrypted conference data included in the conference data transmission / reception message is registered according to the determination result, and the conference data transmission / reception message is 2. A means for returning encrypted conference data whose destination ID is the included terminal identification ID. Teleconference system described.

Images