JP2023082548A - Web conference system, client device, client program, server device, server program, certificate authority device, and certificate authority program - Google Patents

Abstract

To allow each participant in a web conference to obtain an encryption key for message communication through a small number of times of two-party key sharing.SOLUTION: A client device 200 generates and stores a communication key when the client device participates first, performs key sharing with a parent client when the client device participates second and later, and uses an encrypted communication key from the parent client to decrypt the communication key and store the communication key. If the key sharing with a child client is not performed, the client device 200 performs key sharing with a newly joined client device by making the same the child client, updates the stored communication key by hashing, and transmits the encrypted communication key to the child client, and transmits a participation notification to the parent client. When receiving the participation notification from the child client, the client device 200 updates the stored communication key by the hashing.SELECTED DRAWING: Figure 1

Description

The present disclosure relates to web conferencing systems.

In a web conferencing system, messages are encrypted and sent to each participant. A cryptographic key for messaging is encrypted and sent to each participant.
Non-Patent Document 1 describes that each participant performs bilateral key sharing with all participants.

When n persons participate in the web conference, _n C ₂ times of key sharing are required. Since key sharing is very costly, it is necessary to reduce the number of times of key sharing as much as possible.

Paul Rosler, et. al. , "More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema", 2018 IEEE European Symposium on Security and P rivacy (Euro S&P)

The present disclosure aims to enable each participant in a web conference to obtain cryptographic keys for messaging through a small number of bilateral key agreements.

The web conference system of the present disclosure is
A plurality of client devices participating in a web conference.
each of the plurality of client devices,
generating and storing a communication key to be used for message communication in the web conference when first participating in the web conference;
When participating in the web conference for the second time or later, share a key with a client device that is participating in the web conference and has become a parent client, receive an encrypted communication key from the parent client, and communicate with the parent client. Decrypting the communication key from the encrypted communication key using the shared key of, storing the communication key,
When the key is not shared with a child client while participating in the web conference, the key is shared with a client device newly participating in the web conference as the child client, and the communication key being stored is hashed. encryption, encrypts the updated and stored communication key using a shared key shared with the child client, transmits the encrypted communication key to the child client, and notifies the parent client of participation. and send
When receiving a participation notification from the child client, the stored communication key is updated by the hashing.

According to the present disclosure, each participant (client device) of the web conference shares an encryption key for message communication (communication key ) can be obtained.

1 is a configuration diagram of a web conference system 100 according to Embodiment 1; FIG. FIG. 2 is a configuration diagram of a client device 200 according to Embodiment 1; FIG. 3 is a functional configuration diagram of the client device 200 according to Embodiment 1. FIG. 3 is a configuration diagram of a server device 300 according to Embodiment 1. FIG. 2 is a configuration diagram of a certificate authority device 400 according to Embodiment 1. FIG. 4 is a flowchart of preparation processing and registration processing according to the first embodiment; 4 is a flowchart of preparation processing according to the first embodiment; 4 is a flowchart (1/2) of registration processing according to Embodiment 1; 4 is a flowchart (2/2) of registration processing according to Embodiment 1; 4 is a flowchart of setting processing (outline) according to the first embodiment; 10 is a flowchart (1/2) of setting processing (specific example) according to the first embodiment; 2 is a flowchart (2/2) of setting processing (specific example) according to Embodiment 1; FIG. 2 shows a signed member list 111 according to the first embodiment; FIG. FIG. 4 shows the corrected member list 112 according to the first embodiment; FIG. 4 is a schematic diagram of joining processing and leaving processing according to the first embodiment; FIG. 4 is a data flow diagram of joining processing and leaving processing according to Embodiment 1. FIG. 4 is a flowchart (1/4) of participation processing according to Embodiment 1; 4 is a flowchart (2/4) of participation processing according to Embodiment 1; 4 is a flowchart (3/4) of participation processing according to Embodiment 1; 4 is a flowchart (4/4) of participation processing according to Embodiment 1; 4 is a flowchart (1/2) of the leaving process according to the first embodiment; 2 is a flowchart (2/2) of a leaving process according to Embodiment 1; 4 is a flowchart of communication processing according to Embodiment 1; FIG. 2 is a configuration diagram of a client device 200 according to Embodiment 2; 4 is a configuration diagram of a detection unit 270 according to Embodiment 2. FIG. FIG. 4 is a configuration diagram of a server device 300 according to Embodiment 2; FIG. 10 is a data flow diagram of detection processing according to the second embodiment; 9 is a flowchart of detection processing according to the second embodiment;

The same or corresponding elements are denoted by the same reference numerals in the embodiments and drawings. Descriptions of elements having the same reference numerals as those described will be omitted or simplified as appropriate. Arrows in the figure mainly indicate the flow of data or the flow of processing.

Embodiment 1.
The web conference system 100 will be described based on FIGS. 1 to 23. FIG.

*** Configuration description ***
The configuration of the web conference system 100 will be described based on FIG.
A web conference system 100 comprises a plurality of client devices 200 participating in a web conference.
The web conferencing system 100 further includes a server device 300 and a certificate authority device 400 .
A plurality of client devices 200 , server devices 300 and certificate authority devices 400 communicate with each other via network 101 . A specific example of network 101 is the Internet.

The configuration of the client device 200 will be described based on FIG.
The client device 200 is a computer including hardware such as a processor 201 , a memory 202 , an auxiliary storage device 203 , a communication device 204 and an input/output interface 205 . These pieces of hardware are connected to each other via signal lines.

A processor 201 is an IC that performs arithmetic processing and controls other hardware. For example, processor 201 is a CPU.
IC is an abbreviation for Integrated Circuit.
CPU is an abbreviation for Central Processing Unit.

Memory 202 is a volatile or non-volatile storage device. Memory 202 is also referred to as main storage or main memory. For example, memory 202 is RAM. The data stored in memory 202 is saved in auxiliary storage device 203 as needed.
RAM is an abbreviation for Random Access Memory.

Auxiliary storage device 203 is a non-volatile storage device. For example, auxiliary storage device 203 is ROM, HDD, flash memory, or a combination thereof. Data stored in the auxiliary storage device 203 is loaded into the memory 202 as needed.
ROM is an abbreviation for Read Only Memory.
HDD is an abbreviation for Hard Disk Drive.

Communication device 204 is a receiver and transmitter. For example, communication device 204 is a communication chip or NIC. Communication of the client device 200 is performed using the communication device 204 .
NIC is an abbreviation for Network Interface Card.

The input/output interface 205 is a port to which an input device and an output device are connected. For example, the input/output interface 205 is a USB terminal, input devices are a keyboard, mouse and microphone, and output devices are a display and speakers. Input/output of the client device 200 is performed using the input/output interface 205 .
USB is an abbreviation for Universal Serial Bus.

The client device 200 includes elements such as a preparation unit 210 , a registration unit 220 , a setting unit 230 , a joining unit 240 , a leaving unit 250 and a communication unit 260 . These elements are implemented in software.

The auxiliary storage device 203 stores client programs for causing the computer to function as a preparation section 210 , a registration section 220 , a setting section 230 , a joining section 240 , a leaving section 250 and a communication section 260 . The client program is loaded into memory 202 and executed by processor 201 .
The auxiliary storage device 203 further stores an OS. At least part of the OS is loaded into memory 202 and executed by processor 201 .
The processor 201 executes the client program while executing the OS.
OS is an abbreviation for Operating System.

Input/output data of the client program is stored in the storage unit 290 .
Memory 202 functions as storage unit 290 . However, a storage device such as the auxiliary storage device 203 , a register within the processor 201 and a cache memory within the processor 201 may function as the storage unit 290 instead of or together with the memory 202 .

The client device 200 may include multiple processors that substitute for the processor 201 .

The client program can be recorded (stored) in a computer-readable manner in a non-volatile recording medium such as an optical disc or flash memory.

Based on FIG. 3, the functional configuration of the client device 200 will be described.
The preparation unit 210 has a CA certificate acquisition unit 211 .
The registration unit 220 includes an identification code acquisition unit 221 , a signature key generation unit 222 and a CL certificate acquisition unit 223 .
The setting unit 230 includes a member list generation unit 231 , a meeting information acquisition unit 232 and a member list correction unit 233 .
The participation unit 240 includes a conference participation unit 241 , a communication key generation unit 242 , a key sharing unit 243 , a communication key update unit 244 , a communication key acquisition unit 245 and a participation notification unit 246 .
The leaving unit 250 includes a leaving notification unit 251 , a re-sharing unit 252 , a new key generation unit 253 and a new key transmission unit 254 .
The communication section 260 includes a message transmission section 261 and a message reception section 262 .
"CA" means Certificate Authority.
"CL" means client.

The configuration of the server device 300 will be described based on FIG.
The server device 300 is a computer having hardware such as a processor 301 , a memory 302 , an auxiliary storage device 303 , a communication device 304 and an input/output interface 305 . These pieces of hardware are connected to each other via signal lines.

A processor 301 is an IC that performs arithmetic processing and controls other hardware. For example, processor 301 is a CPU.
Memory 302 is a volatile or non-volatile storage device. Memory 302 is also referred to as main storage or main memory. For example, memory 302 is RAM. The data stored in the memory 302 is saved in the auxiliary storage device 303 as required.
Auxiliary storage device 303 is a non-volatile storage device. For example, auxiliary storage device 303 is ROM, HDD, flash memory, or a combination thereof. Data stored in the auxiliary storage device 303 is loaded into the memory 302 as required.
Communication device 304 is a receiver and transmitter. For example, communication device 304 is a communication chip or NIC. Communication of the server device 300 is performed using the communication device 304 .
The input/output interface 305 is a port to which an input device and an output device are connected. For example, the input/output interface 305 is a USB terminal, the input device is a keyboard and mouse, and the output device is a display. Input/output of the server device 300 is performed using the input/output interface 305 .

The server device 300 includes elements such as an identification code management section 321 , a conference information management section 331 , a participation management section 341 , a withdrawal management section 351 and a communication management section 361 . These elements are implemented in software.

The auxiliary storage device 303 stores server programs for causing the computer to function as an identification code management section 321 , a meeting information management section 331 , a participation management section 341 , a withdrawal management section 351 and a communication management section 361 . The server program is loaded into memory 302 and executed by processor 301 .
The auxiliary storage device 303 further stores an OS. At least part of the OS is loaded into memory 302 and executed by processor 301 .
The processor 301 executes the server program while executing the OS.

Input/output data of the server program is stored in the storage unit 390 .
Memory 302 functions as storage unit 390 . However, a storage device such as the auxiliary storage device 303 , a register within the processor 301 and a cache memory within the processor 301 may function as the storage unit 390 instead of or together with the memory 302 .

The server device 300 may include multiple processors that substitute for the processor 301 .

The server program can be recorded (stored) in a computer-readable manner in a non-volatile recording medium such as an optical disc or flash memory.

The configuration of the certificate authority device 400 will be described based on FIG.
The certificate authority device 400 is a computer having hardware such as a processor 401 , a memory 402 , an auxiliary storage device 403 , a communication device 404 and an input/output interface 405 . These pieces of hardware are connected to each other via signal lines.

A processor 401 is an IC that performs arithmetic processing and controls other hardware. For example, processor 401 is a CPU.
Memory 402 is a volatile or non-volatile storage device. Memory 402 is also referred to as main storage or main memory. For example, memory 402 is RAM. The data stored in memory 402 is saved in auxiliary storage device 403 as needed.
Auxiliary storage device 403 is a non-volatile storage device. For example, auxiliary storage device 403 is ROM, HDD, flash memory, or a combination thereof. Data stored in the auxiliary storage device 403 is loaded into the memory 402 as needed.
Communication device 404 is a receiver and transmitter. For example, communication device 404 is a communication chip or NIC. Communication of the certificate authority device 400 is performed using the communication device 404 .
The input/output interface 405 is a port to which an input device and an output device are connected. For example, the input/output interface 405 is a USB terminal, the input device is a keyboard and mouse, and the output device is a display. Input/output of the certificate authority device 400 is performed using the input/output interface 405 .

The certificate authority device 400 includes elements such as a CA certificate issuing unit 411 and a CL certificate issuing unit 421 . These elements are implemented in software.

Auxiliary storage device 403 stores a certificate authority program for causing the computer to function as CA certificate issuing unit 411 and CL certificate issuing unit 421 . The certificate authority program is loaded into memory 402 and executed by processor 401 .
The auxiliary storage device 403 further stores an OS. At least part of the OS is loaded into memory 402 and executed by processor 401 .
The processor 401 executes the certification authority program while executing the OS.

Input/output data of the certificate authority program is stored in the storage unit 490 .
Memory 402 functions as storage unit 490 . However, a storage device such as the auxiliary storage device 403 , a register within the processor 401 and a cache memory within the processor 401 may function as the storage unit 490 instead of or together with the memory 402 .

Certificate authority device 400 may include a plurality of processors in place of processor 401 .

The certification authority program can be recorded (stored) in a computer-readable manner in a non-volatile recording medium such as an optical disc or flash memory.

***Description of operation***
The operation procedure of the web conference system 100 corresponds to the web conference method.
The procedure of operation of the web conference system 100 corresponds to the procedure of processing by the web conference program. A web conferencing program includes a client program, a server program and a certificate authority program.

The web conference method includes preparation processing, registration processing, setting processing, joining processing, leaving processing, and communication processing.

Based on FIG. 6, the overview of the preparation process and the registration process will be described.
The preparation process is a process for each client device 200 to obtain a CA certificate.
Registration processing is processing for each member of the web conference to obtain an identification code and a CL certificate.
A CA certificate is an electronic certificate of certificate authority device 400 .
The identification code identifies the member or client device 200 for the member.
A CL certificate is an electronic certificate of the client device 200 .

“Client” represents the client device 200 .
“Server” represents the server device 300 .
“Certificate authority” represents the certification authority device 400 .

First, client device 200 acquires a CA certificate from certificate authority device 400 .

The client device 200 then transmits the user information to the server device 300 .
User information is data indicating information about the user of the client device 200 . For example, the user information indicates the name, email address, and the like.
Server device 300 transmits an identity verification request to client device 200 .
The personal identification request is data for requesting confirmation from the user himself/herself.
The client device 200 transmits a personal identification response to the server device 300 .
The personal identification response is a response to the personal identification request.
Server device 300 transmits the identification code to client device 200 .
The client device 200 then receives the identification code.

The client device 200 then generates a Certificate Signing Request (CSR).
A CSR is data for requesting a CL certificate. The CSR contains an identification code.
Client device 200 transmits the CSR to certification authority device 400 .
Certificate authority device 400 transmits a query request to server device 300 .
The inquiry request is data for requesting an identification code inquiry. The inquiry request contains the same identification code as contained in the CSR.
Server device 300 transmits an inquiry response to certification authority device 400 .
A query response is a response to a query request. The inquiry response indicates whether the identification code included in the inquiry request is the identification code sent to the client device 200 (correct identification code). We continue assuming that the identification code included in the inquiry request is the correct identification code.

Next, certificate authority device 400 generates a CL certificate and transmits the CL certificate to server device 300 .
Then, server device 300 receives and stores the CL certificate.

A specific example of the preparation process will be described with reference to FIG.
The “acquisition unit” of the client represents the CA certificate acquisition unit 211 .
The “issuer” of the certificate authority represents the CA certificate issuer 411 .
The “storage unit” of the certificate authority represents the storage unit 490 .

In step S101, the CA certificate issuing unit 411 generates a CA key pair.
A CA key pair is a key pair of certificate authority device 400 .
A key pair is a pair of a private key and a public key.

Next, CA certificate issuing unit 411 generates a CA certificate using the CA key pair.
A CA certificate contains the CA public key and signature. This signature is generated using the CA private key.

CA certificate issuing unit 411 then stores the CA private key and CA certificate in storage unit 490 . As a result, the CA private key and CA certificate are stored in the certificate authority device 400 .

In step S102, the CA certificate acquisition unit 211 acquires a CA certificate.
For example, the CA certificate acquisition unit 211 requests the CA certificate from the certification authority device 400, the CA certificate issuing unit 411 transmits the CA certificate to the client device 200, and the CA certificate acquisition unit 211 issues the CA certificate. receive. Means such as via the web or e-mail are used for communication of the CA certificate. Note that the CA certificate must reach the client device 200 without being tampered with.

CA certificate acquisition unit 211 then stores the CA certificate in storage unit 290 . As a result, the CA certificate is stored in the client device 200 .

A specific example of the registration process will be described with reference to FIGS. 8 and 9. FIG.
The “acquisition unit” of the client represents the identification code acquisition unit 221 or the CL certificate acquisition unit 223 .
The “generator” of the client represents the signature key generator 222 .
The “storage” of the client represents storage 290 .
The “management section” of the server represents the identification code management section 321 .
The “storage” of the server represents the storage 390 .
The “issuer” of the certificate authority represents the CL certificate issuer 421 .
The “storage unit” of the certificate authority represents the storage unit 490 .

In step S<b>201 , the user of the client device 200 inputs user information to the client device 200 .
The identification code acquisition unit 221 accepts input user information.

In step S<b>202 , the identification code acquisition unit 221 transmits user information to the server device 300 .
The identification code management unit 321 receives user information.

Next, the identification code management unit 321 transmits an identity verification request to the client device 200 .
The identification code acquisition unit 221 receives the personal identification request.
The personal identification request indicates the address of the confirmation website (registration site). A website address can be indicated by a URL. URL is an abbreviation for Uniform Resource Locator.

Next, the identification code acquisition unit 221 displays the registered site address on the display.
The user of the client device 200 designates the address of the registration site by operating the mouse or the like.

Then, the identification code acquisition unit 221 transmits a personal identification response to the server device 300 by accessing the registration site.
The identification code management unit 321 receives the personal identification response.

In step S<b>203 , the identification code management section 321 generates an identification code for the user of the client device 200 .

The identification code management unit 321 associates the user information and the identification code with each other and stores them in the storage unit 390 . As a result, the user information and the identification code are stored in the server device 300 .

The identification code management section 321 transmits the identification code to the client device 200 .
The identification code acquisition unit 221 receives the identification code.

The identification code acquisition section 221 stores the identification code in the storage section 290 . As a result, the identification code is stored in the server device 300 .

In step S211, the signature key generation unit 222 generates a signature key pair.
The signature key pair is the key pair of client device 200 . A signature key pair is used for various signatures.

Signature key generation unit 222 stores the signature key pair in storage unit 290 . As a result, the signature key pair is stored in the client device 200 .

In step S212, the CL certificate acquisition unit 223 generates a CSR.
A CSR contains an identification code and a signing public key.

CL certificate acquisition unit 223 transmits the CSR to certificate authority device 400 .
The CL certificate issuing unit 421 receives the CSR.

In step S<b>213 , CL certificate issuing unit 421 transmits a query request to server device 300 .
The identification code management section 321 receives the inquiry request.
The inquiry request contains the same identification code as contained in the CSR.

The identification code management unit 321 checks the identification code included in the inquiry request with the stored identification code. The identification code included in the inquiry request is called the "subject code".
If the Subject Code matches any of the stored Identity Codes, then the Subject Code is the correct Identity Code.

The identification code management unit 321 transmits the inquiry response to the certification authority device 400 .
The CL certificate issuing unit 421 receives the inquiry response.
The query response contains query results. The inquiry result indicates whether or not the target code is a correct identification code.

In step S214, the CL certificate issuing unit 421 refers to the inquiry result included in the inquiry response and determines whether the identification code included in the CSR is a correct identification code.
If the identification code included in the CSR is a correct identification code, the CL certificate issuing unit 421 uses the CA private key to generate the CL certificate.
A CL certificate contains a signing public key and a signature. This signature is generated using the CA private key.

If the identification code contained in the CSR is not the correct identification code, the CL certificate will not be generated. In this case, the CL certificate acquisition unit 223 cannot acquire the CL certificate.

The description is continued for the case where the identification code included in the CSR is the correct identification code.
CL certificate issuing unit 421 transmits the CL certificate to client device 200 .
The CL certificate acquisition unit 223 receives the CL certificate.

The CL certificate acquisition unit 223 stores the CL certificate in the storage unit 290. FIG. Thereby, the CL certificate is stored in the client device 200 .

Features of registration processing will be described.
The server device 300 generates an identification code for each of the multiple client devices 200 and transmits the identification code to each of the multiple client devices 200 .
Each of the plurality of client devices 200 receives the identification code. Each client device 200 also generates a signature key pair. Each client device 200 then transmits a certificate request indicating the signature public key and the identification code to the certification authority device 400 .
Certificate authority device 400 receives the certificate request and transmits to server device 300 a query request indicating the identification code indicated in the certificate request.
The server device 300 receives the inquiry request and checks the identification code indicated in the inquiry request with the respective identification codes of the plurality of client devices 200 . Server device 300 then transmits an inquiry response indicating the collation result to certification authority device 400 .
Certificate authority device 400 receives the inquiry response. Then, if the identification code indicated in the inquiry request is the identification code of one of the plurality of client devices 200, the certificate authority device 400 converts the electronic certificate containing the signature public key indicated in the certificate request into a certificate It is issued for the client device 200 that is the source of the request.

Based on FIG. 10, the outline of the setting process will be described.
The setting process is a process of setting a member list for the web conference.
The member list is data indicating the identification code of each member participating in the web conference.

First, client (A) generates a member list.
Client (A) generates a signature for the member list.
Client (A) transmits the signed member list to server device 300 .
Server device 300 verifies the signature of the member list. If the signature is correct, server device 300 saves the member list.

Then, server device 300 transmits the meeting information to each member indicated in the member list. When client (A) and client (B) are shown in the member list, server device 300 transmits conference information to each of client (A) and client (B).
The conference information is data indicating information about the web conference.

We continue with the case where the client (B) modifies the member list.
Client (B) requests a member list from server device 300 .
Server device 300 transmits the member list to client (B).
Client (B) modifies the member list.
Client (B) transmits the signed member list to server device 300 .
Server device 300 verifies the signature of the member list. If the signature is correct, server device 300 updates the member list.

A specific example of the setting process will be described with reference to FIGS. 11 and 12. FIG.
The “generator” of the client represents the member list generator 231 .
The “acquisition unit” of the client represents the conference information acquisition unit 232 .
The “modifier” of the client represents the member list modifier 233 .
The “storage” of the client represents storage 290 .
The “management section” of the server represents the conference information management section 331 .
The “storage” of the server represents the storage 390 .

In step S301, the user (A) inputs the identification code of each member participating in the web conference to the client (A). The user shall be informed of the identification code by each member.
Member list generator 231 accepts each input identification code.

Member list generation unit 231 generates a member list.
The member list shows each identification code accepted.

In step S302, member list generator 231 generates a signature for the member list using the signature private key.

The member list generator 231 then generates a signed member list.
A signed member list is data that includes a member list, a signature, and a CL certificate.

FIG. 13 shows the signed member list 111 . Signed member list 111 is an example of a signed member list generated by client (A).
The signed member list 111 contains identification codes and attributes for each member. "Joining" means that the user identified by the identification code joins the members of the web conference.
The signed member list 111 includes a member list, signature (A) and CL certificate (A).
Signature (A) is a signature generated using the signature private key of client (A).
CL certificate (A) is the CL certificate of client (A).

Returning to FIG. 11, the description continues from step S303.
In step S<b>303 , member list generating section 231 transmits a meeting setting request to server device 300 .
The conference information management unit 331 receives the conference setting request.
A conference setup request is data for requesting the setup of a web conference. The meeting setup request contains a signed member list.

The meeting information management unit 331 verifies the signed member list included in the meeting setting request.
Specifically, the meeting information management unit 331 verifies the signature in the signed member list using the signature public key included in the CL certificate in the signed member list. If the signature is correct, the signed member list is correct.

If the signed member list is correct, the meeting information manager 331 generates meeting information.
Then, the meeting information management unit 331 associates the signed member list and the meeting information with each other and stores them in the storage unit 390 . As a result, the signed member list and meeting information are stored in server device 300 .
The meeting information includes meeting URL and member list URL.
The meeting URL is the address of the website accessed when joining the web conference.
The member list URL is the website address for accessing the member list.

If the signed member list is incorrect, the web conference will not be set up and the member list will not be registered.

Continuing with the case where the signed member list is correct.
In step S304, the conference information management unit 331 transmits the conference information to the users identified by each identification code shown in the member list based on the stored user information. For example, the conference information management unit 331 transmits conference information using each user's email address.

In the client device 200 of each user, the conference information acquisition unit 232 receives conference information.
Then, the meeting information acquiring section 232 stores the meeting information in the storage section 290 . Accordingly, the conference information is stored in the client device 200 .

Each user may send meeting information to other members as needed.

In step S311, the member list correction unit 233 accesses the member list using the member list URL according to the instruction of the user (B).
Member list correction unit 233 then downloads the member list. At this time, the meeting information management section 331 transmits the member list to the client (B), and the member list correction section 233 receives the member list.

In step S312, member list correction unit 233 corrects the member list according to the instruction of user (B).
Specifically, member list correction unit 233 adds correction data to the signed member list. The correction data indicates the content of corrections to the member list.

In step S313, member list correction unit 233 uses the signature private key to generate a signature for the correction data.

Member list correction unit 233 then generates a corrected member list.
The modified member list contains the signed member list, modification data, signature and CL certificate.

The modified member list 112 is shown in FIG. Modified member list 112 is an example of signed member list 111 (see FIG. 11) that has been modified by client (B).
The modified member list 112 contains the signed member list 111, modification data, signature (B) and CL certificate (B). "Exclusion" means that the user identified by the identification code is excluded from the members of the web conference.
The modified data indicates that member (D) is joining the web conference membership and member (C) is being removed from the web conference membership.
Signature (B) is a signature generated using the signature private key of client (B).
CL certificate (B) is the CL certificate of client (B).

Returning to FIG. 12, the description continues from step S314.
In step S<b>314 , member list correction unit 233 transmits the corrected member list to server device 300 .
The meeting information manager 331 receives the corrected member list.

The meeting information manager 331 verifies the corrected member list.
Specifically, the meeting information management unit 331 verifies the signature in the corrected member list using the signature public key included in the CL certificate in the corrected member list.

The meeting information manager 331 verifies the corrected data in the corrected member list.
For example, the meeting information management unit 331 determines whether or not exclusion of non-members is included in the correction content.

If the signature and correction data are correct, the meeting information management section 331 updates the stored signed member list with the corrected member list.

If at least one of the signature and modification data is incorrect, the modified member list is discarded and the stored signed member list is not updated.

Features of the setting process will be described.
Any one of the client devices 200 generates a member list and transmits the signed member list to the server device 300 .
Server device 300 receives the signed member list and verifies the signature of the signed member list. Then, if the signature of the signed member list is correct, server device 300 stores the member list.
Each of the multiple client devices 200 receives the member list from the server device 300 . Each client device 200 then modifies the member list and transmits the signed modified list to the server device 300 . A modified list is a modified member list.
Server device 300 receives the signed modified list and verifies the signature of the signed modified list. Then, if the signature of the signed modified list is correct, the server device 300 updates the stored member list with the modified list.

An overview of the joining process and the leaving process will be described with reference to FIGS. 15 and 16. FIG.
Participation processing is processing for each member to participate in the web conference.
The withdrawal process is for a member who has already participated in the web conference to withdraw from the web conference.

In FIG. 15, solid white circles indicate members participating in the web conference. Dashed white circles indicate members who have not participated in the web conference. Black circles indicate members who left the web conference.
When member (A) participates in the web conference first, server device 300 determines whether member (A) can participate using the member list.
When each member participates in the web conference for the second time or later, each member's participation is determined by one of the participating members. For example, whether or not member (B) can participate is determined by member (A). Member (B) determines whether member (C) can participate.
A member who has decided whether or not to participate is called a "parent member". Also, a member whose participation is determined to be possible is referred to as a "child member".
Parent and child members share a key. For example, member (A) shares a key with member (B). Also, member (B) shares a key with each of member (A) and member (B).
When a participating member leaves the web conference, the parent member for the leaving member and the child member for the leaving member share a key. For example, when member (C) leaves, member (B) and member (D) share a key.

In FIG. 16, "Join" means participation in the web conference. “Auth” means determination (authentication) of whether or not to participate in the web conference. "Ratchet" means hashed. "Leave" means leaving the web conference. "Gen" means generation of a communication key.
A communication key is a common key used for message communication in a web conference. The communication key is also called a group key.
Also, “k _X,Y ” represents a shared key of member (X) and member (Y). “k _X,G ” represents the updated communication key.

When a new member participates in the web conference, the parent member (corresponding member) for the new member hashes the communication key being stored, updates it, and distributes the updated communication key to the new member.
Further, if there is a parent member for the member, the member notifies the parent member of the new member's participation.
The parent member then hashes and updates the stored communication key. If there is a parent member (superordinate member) for the parent member, the parent member notifies the superordinate member of the new member's participation. Upper members operate in the same manner as parent members. For example, when member (C) participates in a web conference, member (B) hashes and updates communication keys k′A _{and G} , and updates the updated communication key k″. Distribute _{A and G} to members (B). Further, member (B) notifies member (A) of member (C)'s participation. Member (A) then hashes the communication keys k′A _,G and updates them to communication keys k″ _A,G .

When a participating member leaves the web conference, the parent member (corresponding member) of the leaving member generates a new communication key and distributes the new communication key to each child member of the parent member and the leaving member. If there is a parent member (superior member) for the parent member, the superior member distributes a new communication key to the parent member. And the parent member to the superior member behaves like the superior member. If there is a child member (lower member) for the child member, the child member distributes a new communication key to the lower member. Subordinate members then behave like child members.
For example, when member (C) withdraws from the web conference, member (B) generates new communication keys k _{B and G} , and new communication keys k for each of member (A) and member (D). Distribute _{B and G.}

A specific example of the participation process will be described with reference to FIGS. 17 to 20. FIG.
“Client (A)” represents the client device 200 that first participates in the web conference.
“Client (B)” represents the client device 200 that participates in the web conference second.
"Client (C)" represents the client device 200 that participates in the web conference third.
“Client (D)” represents the client device 200 that participates in the web conference fourth.
The client's “participant” represents the conference participant 241 .
The “generation unit” of the client represents the communication key generation unit 242 .
The “shared part” of the client represents the key sharer 243 .
The “updater” of the client represents the communication key updater 244 .
The “acquisition unit” of the client represents the communication key acquisition unit 245 .
The client's “notifier” represents the participation notifier 246 .
The “storage” of the client represents storage 290 .
The “management section” of the server represents the participation management section 341 .
The “storage” of the server represents the storage 390 .

In step S<b>401 , the conference participation unit 241 of client (A) transmits a participation request to the server device 300 .
The participation management unit 341 receives the participation request.
A participation request is data for participating in a web conference. The join request contains an identification code.

The participation management unit 341 determines whether there is a client device 200 participating in the web conference. At this time, there is no client device 200 participating in the web conference.
In this case, the participation management unit 341 determines whether the same identification code as the identification code included in the participation request is included in the stored member list. An identification code that is the same as the identification code included in the participation request is called a “target code”.
If the target code is included in the stored member list, the participation management unit 341 permits the client (A) to participate in the web conference. Then, the participation management unit 341 transmits a participation response indicating permission to participate in the web conference to the client (A). The participation management unit 341 manages the identification code of each member participating in the web conference.
If the target code is not included in the stored member list, the participation management unit 341 transmits a participation response indicating disapproval of participation in the web conference to the client (A).
The conference participation unit 241 receives the participation response. A join response is a response corresponding to the join request.

A case where there is a client device 200 participating in the web conference will be described later.

In step S402, the conference participation unit 241 generates a communication key. A communication key is, for example, a random number.
Then, conference participation unit 241 stores the communication key in storage unit 290 . Thereby, the communication key is stored in the client (A).

In step S<b>411 , the conference participation unit 241 of the client (B) transmits a participation request to the server device 300 .
The participation management unit 341 receives the participation request.

The participation management unit 341 determines whether there is a client device 200 participating in the web conference. At this time, client (A) is participating in the web conference.
In this case, the participation management unit 341 transmits a participation response indicating that there is a participating client device 200 to the client (B).
The participation management unit 341 of the client (B) receives the participation response.

In step S412, the key sharing unit 243 of the client (B) generates an exchange key pair.
The exchange key pair is a key pair for sharing keys with other client devices 200 . Examples of exchange keys are ECDH keys or DH keys. ECDH is an abbreviation for Elliptic curve Diffie-Hellman. DH is an abbreviation for Diffie-Hellman.

The key sharing unit 243 of client (B) uses the signature private key to generate a signature for the exchange public key.

The key sharing unit 243 of the client (B) generates exchange data and transmits the exchange data to the server device 300 .
Exchange data is data for exchanging keys with other client devices 200 . The exchange data includes the exchange public key, signature and CL certificate.

The exchange data of the client (B) is called exchange data (B).
The exchange public key included in the exchange data (B) is called an exchange public key (B).
A signature included in the exchange data (B) is called a signature (B).
The CL certificate included in exchange data (B) is called CL certificate (B).

Participation management unit 341 receives exchange data (B) and stores exchange data (B) in storage unit 390 .

In step S413, the participation management unit 341 transmits an authentication request to all client devices participating in the web conference.
The key sharing unit 243 of client (A) receives the authentication request.
The authentication request is data for notifying new participation in the web conference.

The key sharing unit 243 of client (A) determines whether the key is shared with the child client. At this time, the client (A) does not share the key with the child client.
In this case, the key sharing unit 243 of client (A) generates an exchange key pair.
The key sharing unit 243 also uses the signature private key to generate a signature for the exchange public key.
Then, key sharing section 243 generates exchange data and transmits the exchange data to server device 300 .

The exchange data of client (A) is called exchange data (A).
The exchange public key included in the exchange data (A) is called an exchange public key (A).
A signature included in the exchange data (A) is called a signature (A).
The CL certificate included in exchange data (A) is called CL certificate (A).

Participation management unit 341 receives exchange data (A) and stores exchange data (A) in storage unit 390 .

In step S414, the participation management unit 341 transmits the exchange data (A) to the client (B), and transmits the exchange data (B) to the client (A).
The key sharing unit 243 of the client (B) receives exchange data (A).
The key sharing unit 243 of the client (A) receives exchange data (B).

In step S415, the key sharing unit 243 of the client (B) verifies the exchange data (A).
Specifically, the key sharing unit 243 verifies the signature in the CL certificate (A) using the CA public key in the CA certificate.
If the signature in CL certificate (A) is correct, key sharing unit 243 verifies signature (A) using the signature public key in CL certificate (A).
If the signature (A) is correct, then the exchange data (A) is correct. The client (A) is then authenticated.

If the exchange data (A) is correct, the key sharing unit 243 executes processing for key sharing using the exchange public key (A). A shared key (AB) is thereby generated.
Then, key sharing section 243 stores the shared key (AB) in storage section 290 . As a result, the shared key (AB) is stored in the client (A).
Shared key (AB) is a common key shared between client (A) and client (B).

If the exchange data (A) is incorrect, the shared key (AB) will not be generated at the client (B). That is, no key sharing is performed.

In step S416, the key sharing unit 243 of the client (A) verifies the exchange data (B).
Specifically, the key sharing unit 243 verifies the signature in the CL certificate (B) using the CA public key in the CA certificate.
If the signature in CL certificate (B) is correct, key sharing unit 243 verifies signature (B) using the signature public key in CL certificate (B).
If signature (B) is correct, exchange data (B) is correct. The client (B) is then authenticated. This permits the client (B) to participate in the web conference.

If the exchange data (B) is correct, the key sharing unit 243 executes processing for key sharing using the exchange public key (B). A shared key (AB) is thereby generated.
Then, key sharing section 243 stores the shared key (AB) in storage section 290 . As a result, the shared key (AB) is stored in the client (B).

If the exchange data (B) is incorrect, the shared key (AB) will not be generated at the client (A). That is, no key sharing is performed.

In step S421, the communication key updating unit 244 of the client (A) hashes and updates the communication key being stored.
In other words, the communication key updating unit 244 performs hashing on the stored communication key, and updates the stored communication key with the obtained hash value.

In step S422, the communication key updating unit 244 of the client (A) encrypts the updated and stored communication key using the shared key (AB). As a result, an encrypted communication key is obtained.

Communication key update unit 244 of client (A) transmits the encrypted communication key to server device 300 .
Participation management unit 341 receives the encrypted communication key and stores the encrypted communication key in storage unit 390 .

In step S<b>423 , communication key acquisition unit 245 of client (B) transmits a communication key request to server device 300 .
The participation manager 341 receives the communication key request.
A communication key request is data for requesting a communication key.

The participation management unit 341 transmits the encrypted communication key to the client (B).
The communication key acquisition unit 245 of client (B) receives the encrypted communication key.

In step S424, the communication key acquisition unit 245 of the client (B) decrypts the communication key from the encrypted communication key using the shared key (AB).

Communication key acquisition unit 245 of client (B) stores the communication key in storage unit 290 . As a result, the client (B) stores the same communication key as the communication key being stored in the client (A).

In step S425, the participation notification unit 246 of client (A) determines whether there is a parent client for client (A). At this time, there is no parent client for client (A).
In this case, the process ends.

In step S431, client (C) becomes the child client and client (B) becomes the parent client.
Key sharing is then performed between the client (B) and the client (C). The key sharing procedure is the same as the key sharing procedure (S411 to S416) performed between client (A) and client (B).
Thereby, the shared key (BC) is stored in each of the client (B) and the client (C).
Shared key (BC) is a common key shared between client (B) and client (C).

Further, key update is performed between the client (B) and the client (C). The key update procedure is the same as the key update procedure (S421 to S424) performed between the client (A) and the client (B).
Thereby, the communication key is stored in each of the client (B) and the client (C).
This communication key is hashed by the client (B), so it differs from the communication key stored in the client (A).

Then, the participation notification unit 246 of client (B) determines whether or not there is a parent client for client (B) (same as step S425). Client (A) is the parent client to client (B).
In this case, the process proceeds to step S432.

In step S432, the participation notification unit 246 of the client (B) generates a participation notification.
A participation notification is data for notifying the parent client of new participation in the web conference.
Furthermore, the participation notification unit 246 generates a message authentication code (MAC) using the shared key (AB).
The participation notification unit 246 then transmits a participation notification including the MAC to the server device 300 .
The participation management unit 341 receives the participation notification.

Information to identify the join notification (such as a timestamp or sequence number) may be included in the join notification. This information can be used to prevent retransmission of join notifications.

The participation management unit 341 transmits a participation notification to the client (A).
The communication key update unit 244 of client (A) receives the participation notification.

In step S434, the communication key updating unit 244 of the client (A) verifies the MAC included in the participation notification using the shared key (AB).

If the MAC is correct, the communication key updating unit 244 hashes the stored communication key and updates it.
As a result, the client (A) stores the same communication key as the communication key being stored in the client (B).

The hashing method is common to the plurality of client devices 200, and the hashing results are the same for the plurality of client devices 200. FIG. For example, multiple client devices 200 use the same hash function for hashing.

In step S435, the participation notification unit 246 of client (A) determines whether there is a parent client for client (A).
Since there is no parent client for client (A), the process ends.

If there is a parent client for client (A), client (A), like client (B), sends a participation notification to the parent client.
Then, the parent client, like client (A), updates the stored communication key (step S434), and if necessary, transmits a participation notification (step S435).
This process continues until the client device 200 that does not have a parent client updates the stored communication key.

Features of participation processing will be described.
When participating in the web conference for the first time, the client device 200 generates and stores a communication key.
When participating in the web conference for the second time or later, the client device 200 shares a key with the client device that is participating in the web conference and has become a parent client. Then, the client device 200 receives the encrypted communication key from the parent client, decrypts the communication key from the encrypted communication key using the shared key with the parent client, and stores the communication key.
When participating in a web conference and not sharing a key with a child client, the client device 200 performs key sharing with a client device newly participating in the web conference as a child client. Also, the client device 200 updates the stored communication key by hashing. Then, the client device 200 encrypts the updated and stored communication key using the shared key with the child client, and transmits the encrypted communication key to the child client. Furthermore, the client device 200 transmits a participation notification to the parent client.
Upon receiving a participation notification from a child client, the client device 200 updates the stored communication key by hashing.

Each of the plurality of client devices 200 becomes a participation requesting client when participating in the web conference. Each client device 200 then transmits a participation request indicating an identification code to the server device 300 .
When receiving a participation request from a participation request client who participates in the web conference first, server device 300 checks the identification code indicated in the received participation request with the member list of the web conference. The server device 300 determines whether or not the participation requesting client can participate based on the collation result. Then, the server device 300 transmits a participation response indicating the determination result to the participation request client.
When receiving the participation request of the second and subsequent participation requesting clients in the web conference, the server device 300 transmits an authentication request for the participation requesting client to all the client devices 200 participating in the web conference.
Each client device 200 participating in the web conference operates as follows. If the key is not shared with the child client when the authentication request is received, the client device 200 receives the signed exchange key transmitted from the participation request client and verifies the signature of the signed exchange key. Then, when the exchange key of the signed exchange key is correct, the client device 200 makes the participation requesting client a child client and performs key sharing using the exchange key.

A specific example of the leaving process will be described with reference to FIGS. 21 and 22. FIG.
“Client (A)” represents the client device 200 that first participates in the web conference.
“Client (B)” represents the client device 200 that joined the web conference second.
“Client (C)” represents the client device 200 that joined the web conference third.
“Client (D)” represents the client device 200 that joined the web conference fourth.
The “notifier” of the client represents the withdrawal notifier 251 .
The client's “shared portion” represents the re-shared portion 252 .
The “generator” of the client represents the new key generator 253 .
The “Transmitter” of the client represents the new key transporter 254 .
The “storage” of the client represents storage 290 .
The “management section” of the server represents the withdrawal management section 351 .
The “storage” of the server represents the storage 390 .

In step S<b>501 , the client (B)'s withdrawal notification unit 251 transmits a withdrawal notification to the server device 300 .
The leaving manager 351 receives the leaving notification.
The withdrawal notice is data for withdrawing from the web conference. The leave notification includes the identity code of the leave client.
A leaving client is a client device 200 that has left the web conference.

The withdrawal management unit 351 transmits a withdrawal notice to all client devices 200 participating in the web conference.
In each participating client device 200, the re-sharing unit 252 receives the withdrawal notification.

In each participating client device 200, the re-sharing unit 252 refers to the identification code included in the withdrawal notification.
Then, the re-sharing unit 252 determines whether the client device 200 is a parent client of the departed client or a child client of the departed client.

Client (A) is a parent client to client (B). In this case, the process proceeds to step S502 in the client (A).
Client (C) is a child client to client (B). In this case, the process proceeds to step S502 in the client (C).
Client (D) is not a parent client to client (B). Also, client (D) is not a child client to client (B). In this case, the client (D) does not process the withdrawal notification.

In step S<b>502 , the re-sharing unit 252 of the client (A) generates exchange data (A′) and transmits the exchange data (A′) to the server device 300 .
Also, the re-sharing unit 252 of the client (C) generates exchange data (C′) and transmits the exchange data (C′) to the server device 300 .
The method of generating the exchange data is the same as in the participation process (see FIG. 18).

The leaving management unit 351 receives the exchange data (A') and the exchange data (C'), transmits the exchange data (C') to the client (A), and transmits the exchange data (A') to the client (C). Send.

In step S503, the re-sharing unit 252 of the client (A) verifies the exchange data (C'), generates a shared key (AC) through key sharing, and stores the shared key (AC).
Also, the re-sharing unit 252 of the client (C) verifies the exchange data (A'), generates a shared key (AC) through key sharing, and stores the shared key (AC).
The method of verification and key agreement is the same as in the joining process (see Figure 18).

In step S511, the new key generator 253 of client (A) generates a new communication key.
The new key generation unit 253 updates the stored communication key with a new communication key. As a result, a new communication key is stored in the client (A).

In step S512, the new key transmission unit 254 of the client (A) encrypts the new communication key using the common key (AC). As a result, an encrypted communication key is obtained.

New key transmission unit 254 transmits the encrypted communication key to server device 300 .
The withdrawal management unit 351 receives the encrypted communication key and stores the encrypted communication key in the storage unit 390 .

The withdrawal management unit 351 transmits the encrypted communication key to the client (C).
The new key transmission unit 254 of client (C) receives the encrypted communication key.

In step S513, the new key transmission unit 254 of the client (C) decrypts the new communication key from the encrypted communication key using the shared key (AC).
The new key transmission unit 254 updates the stored communication key with a new communication key. As a result, a new communication key is stored in the client (C).

In step S514, the new key transmission unit 254 of client (C) determines whether there is a child client for client (C). Client (D) is a child client to client (C).
In this case, new key transmission unit 254 of client (C) encrypts the new communication key using the shared key (CD) and transmits the encrypted communication key to server device 300 .
The withdrawal management unit 351 receives the encrypted communication key and transmits the encrypted communication key to the client (D).
New key transmission unit 254 of client (D) receives the encrypted communication key.

In step S515, the new key transmission unit 254 of the client (D) decrypts the new communication key from the encrypted communication key using the shared key (CD), and updates the stored communication key with the new communication key. . As a result, a new communication key is stored in the client (D).

The new key transmission unit 254 of client (D) determines whether there is a child client for client (D). There are no child clients for client (D).
In this case, the process ends.

If there is a child client for client (D), client (D) sends an encrypted communication key to the child client, like client (C).
Then, the child client updates the stored communication key (step S515), and transmits the encrypted communication key as necessary, in the same manner as the client (D).
This process continues until the client device 200 that does not have a child client updates the stored communication key.

Features of the leaving process will be described.
When leaving the web conference, the client device 200 transmits a leaving notice to each of the parent client and child client.
Upon receiving the parent client's withdrawal notification, the client device 200 shares a key with a new parent client. A parent client for a parent client becomes the new parent client. The client device 200 receives the encrypted communication key from the new parent client, and decrypts the new communication key from the encrypted communication key using the shared key with the new parent client. Then, the client device 200 stores a new communication key instead of the communication key being stored. Furthermore, the client device 200 encrypts the new communication key using the shared key with the child client, and transmits the encrypted communication key to the child client.
When receiving the encrypted communication key from the parent client, the client device 200 decrypts the new communication key from the encrypted communication key using the shared key with the parent client, and replaces the stored communication key with the new communication key. Store communication keys.
Upon receiving the child client's withdrawal notification, the client device 200 shares the key with the new child client. A child client for a child client becomes a new child client. Also, the client device 200 generates a new communication key and stores it instead of the communication key being stored. The client device 200 then encrypts the new communication key using the shared key shared with the new child client, and transmits the encrypted communication key to the new child client.

Each of the plurality of client devices 200 does not share keys with other client devices unless either the parent client or the child client leaves the web conference.

Communication processing will be described based on FIG.
The communication process is a process in which the client devices 200 participating in the web conference communicate messages.

The “sender” of the client represents the message sender 261 .
The “receiver” of the client represents the message receiver 262 .
The “storage” of the client represents storage 290 .
The “storage” of the server represents the storage 390 .

In step S601, the user of client (A) inputs a message to client (A).
Message transmission unit 261 receives messages. The form of the message is, for example, text, audio or video.

The message transmission unit 261 encodes messages. In other words, the message transmission unit 261 converts the message into data in a prescribed format. This gives us an encoded message.

The message sending unit 261 encrypts the encoded message using the communication key. This results in an encrypted message.

Message transmission unit 261 transmits the encrypted message to server device 300 .
Communication management unit 361 receives the encrypted message and stores it in storage unit 390 .

The communication manager 361 transmits the encrypted message to each client device 200 participating in the web conference.
The message receiver 262 of client (B) receives the encrypted message.

In step S603, the message receiving unit 262 of the client (B) decrypts the encoded message from the encrypted message using the stored communication key.

Message receiver 262 decodes the message from the encoded message.

The message receiver 262 outputs messages. For example, the message receiving section 262 displays the message on the display.

*** Effect of Embodiment 1 ***
For bilateral key sharing, it is necessary to safely deliver the initial key (exchange key) of each user to the other party. Conventionally, the initial key was registered with the server along with the telephone number. Therefore, if the server administrator has malicious intent, spoofing by replacing the initial key becomes possible.
In the first embodiment, initial keys are distributed using electronic certificates. This makes it possible to prevent tampering with the initial key on the server.

In Embodiment 1, a list of participating members is generated when a web conference is established. This can prevent an uninvited third party from entering the room (participating in the web conference).

Traditionally, _n C ₂ key agreements were required for n members.
According to Embodiment 1, the number of times of key sharing can be reduced to (n−1+α) times. "α" means the number of withdrawals.

In Embodiment 1, a new participating client is passed an updated communication key by hashing. This prevents newly joining clients from decrypting messages before joining.

In Embodiment 1, a new communication key is generated when a client participating in the web conference leaves the web conference. This prevents the leaving client from decrypting messages after leaving.

Embodiment 2.
A form of coping with withdrawal from a web conference without notification will be described mainly with reference to FIGS. 24 to 28 for differences from the first embodiment.

*** Configuration description ***
The configuration of the client device 200 will be described based on FIG.
The client device 200 further includes an element called a detector 270 . The detection unit 270 is realized by software.
The client program also causes the computer to function as the detector 270 .

The configuration of the detection unit 270 will be described based on FIG. 25 .
The detection unit 270 includes a confirmation request unit 271 , a confirmation response unit 272 and a proxy notification unit 273 .

Based on FIG. 26, the configuration of the server device 300 will be described.
The server device 300 further includes a detection manager 371 . The detection manager 371 is realized by software.
The server program further causes the computer to function as the detection manager 371 .

***Description of operation***
A web conferencing method includes a sensing process.
The detection process is a process of detecting a client device 200 that has left the web conference without issuing a withdrawal notification.

Based on FIG. 27, the outline of the detection process will be described.
"Join" means participation in a web conference.
"Gen nonce" means generation of a nonce. A nonce is a random value.
"Sign" means signature.
"Verify" means signature verification.
"Auth" means authentication of the child client.
“Gen k _B,G ” means generation of a communication key.

While participating in the web conference, client (A) sends a nonce to each client participating in the web conference. Each client participating in the web conference generates a signature for the nonce and sends the signature to client (A). Client (A) verifies each signature.
After that, client (C) left the web conference without issuing a leave notice.
Client (E) then sent a nonce to each client participating in the web conference. However, the signature could not be received from the client (C).
In this case, client (E) notifies each client that client (C) has left the web conference.
After that, the client (B), which was the parent client of the client (C), generates new communication keys _{kB, G} , and the new communication keys _{kB, G} are transmitted to each client.

A specific example of the detection process will be described with reference to FIG.
The “request part” of the client represents the confirmation request part 271 .
The client's “response part” represents the acknowledgment part 272 .
The “storage” of the client represents storage 290 .
The “management section” of the server represents the detection management section 371 .
The “storage” of the server represents the storage 390 .

In step S701, the confirmation request unit 271 of each participating client device 200 determines whether it is the confirmation timing.
The confirmation timing is a default timing for confirmation of leaving. For example, each time that occurs at regular intervals after the transmission of the participation notification is the confirmation timing.

Acknowledgment timing is detected at client (A).
In this case, the confirmation request unit 271 of the client (A) transmits a withdrawal confirmation request to the server device 300 .
The detection management unit 371 receives the withdrawal confirmation request.
The withdrawal confirmation request is data for confirming the client device 200 that has withdrawn from the web conference. The leave confirmation request includes a confirmation message. A confirmation message is an arbitrary message and includes a nonce to prevent retransmission of the confirmation message.

The detection management unit 371 transmits a withdrawal confirmation request to all the client devices 200 managed as participating client devices 200 .
The confirmation response unit 272 of the client (B) receives the withdrawal confirmation request.
The confirmation response unit 272 of the client (C) receives the withdrawal confirmation request.

In step S702, the confirmation response section 272 of client (B) generates a signature for the confirmation message using the signature private key.
The acknowledgment unit 272 generates a leave acknowledgment and transmits the leave acknowledgment to the server device 300 .
The detection management unit 371 receives the withdrawal confirmation response.
The leave confirmation response is a response to the leave confirmation request. The leave acknowledgment contains the signature, CL certificate and identification code for the acknowledgment message.

The acknowledgment unit 272 of the client (C) transmits a withdrawal acknowledgment to the server device 300 in the same way as the client (B).
The detection management unit 371 receives the withdrawal confirmation response.

In step S703, the detection manager 371 generates management data.
The management data includes each leaving acknowledgment and a joining client list.
The participating client list is a list of identification codes of client devices 200 managed as participating client devices 200 .

The detection management unit 371 transmits management data to the client (A).
The proxy notification unit 273 of client (A) receives the management data.

In step S704, the proxy notification unit 273 of client (A) verifies each withdrawal confirmation response included in the management data.
Specifically, proxy notification unit 273 verifies the signature in the CL certificate using the CA public key in the CA certificate.
If the signature in the CL certificate is correct, proxy notification unit 273 verifies the signature on the confirmation message using the signature public key in the CL certificate.
If the signature on the confirmation message is correct, then the leave acknowledgment is correct.

The proxy notification unit 273 extracts from the participating client list an identification code that does not match any identification code in any correct withdrawal confirmation response.
The client device 200 identified by the extracted identification code is called a withdrawn client.
A withdrawn client is a client device 200 that has withdrawn from the web conference without sending a withdrawal notification.

If there is a withdrawn client, the proxy notification unit 273 of client (A) sends a withdrawal notification on behalf of the withdrawn client.
The processing for the withdrawal notification (withdrawal processing) is as described in the first embodiment.

Features of detection processing will be described.
When receiving a confirmation request for confirming that the user has left the web conference, each client device 200 participating in the web conference transmits an acknowledgment to the confirmation request.
Each client device 200 participating in the web conference transmits a confirmation request at an arbitrary timing, and receives a confirmation response from the client devices participating in the web conference. Next, the client device 200 detects the client device 200 that has not left the web conference and is not the sender of the confirmation response as a withdrawn client. Then, the client device 200 transmits a withdrawal notice of the withdrawn client.

*** Effect of Embodiment 2 ***
According to the second embodiment, it is possible to deal with the case where the member silently leaves the web conference.

***Summary of Embodiments***
A member who joins the web conference first generates a communication key. Members who join the web conference for the second time or later perform authentication and key sharing with one of the members who have already joined. When a member leaves the web conference, the member who authenticates the leaving member performs authentication and key sharing with the member authenticated by the leaving member.

If the authentication and key sharing at the time of participation are successful, the authenticating member hashes its own communication key and passes the hash value as the communication key to the member to be authenticated. At the same time, the authenticated member notifies other participating members to that effect. Each member contacted hashes its communication key.

After leaving authentication and key sharing, the member who authenticated the leaving member generates a communication key and distributes the communication key to the members who have shared the key. The member who received the communication key distributes the communication key to the members who have shared the key.

The first member to join the web conference is judged by the member list.

Each member authenticates and exchanges keys with up to two people.

A member who establishes a web conference generates a list of participating members, affixes signatures to the list, transmits the list to the server, and is issued a URL for the conference. Each member on the list behaves as follows, as appropriate. A member receives the list from the server, adds and deletes members to the list, signs the list, and sends the list to the server.

Upon initial registration of a user, the server performs identity verification and issues an identification code that uniquely identifies the verified user. A subscriber sends a certificate issuance request (CSR) containing an identification code to the CA. The CA inquires of the server about the existence of the identification code, and issues a certificate if the identification code is registered.

At any time during the web conference, one member generates a nonce and requests signatures from other members. Other members sign the nonce and send the signature back to the requesting member along with the certificate. A member who requests a signature verifies the signature to detect silently leaving members. After detection, withdrawal processing (authentication, key sharing, communication key update) is executed.

*** Supplement to the embodiment ***
Server device 300 and certificate authority device 400 may be configured as one device.

Each embodiment is an example of a preferred form and is not intended to limit the technical scope of the present disclosure. Each embodiment may be implemented partially or in combination with other embodiments. The procedures described using flowcharts and the like may be changed as appropriate.

Each element of client device 200, server device 300, and certificate authority device 400 may be implemented in software, hardware, firmware, or a combination thereof.
The "units" that are elements of the client device 200, the server device 300 and the certificate authority device 400 may be read as "processing", "process", "circuit" or "circuitry".

100 web conference system, 101 network, 111 signed member list, 112 modified member list, 200 client device, 201 processor, 202 memory, 203 auxiliary storage device, 204 communication device, 205 input/output interface, 210 preparation unit, 211 CA certificate acquisition unit, 220 registration unit, 221 identification code acquisition unit, 222 signature key generation unit, 223 CL certificate acquisition unit, 230 setting unit, 231 member list generation unit, 232 meeting information acquisition unit, 233 member list correction unit, 240 participation unit, 241 conference participation unit, 242 communication key generation unit, 243 key sharing unit, 244 communication key update unit, 245 communication key acquisition unit, 246 participation notification unit, 250 withdrawal unit, 251 withdrawal notification unit, 252 re-sharing unit , 253 new key generation unit, 254 new key transmission unit, 260 communication unit, 261 message transmission unit, 262 message reception unit, 270 detection unit, 271 confirmation request unit, 272 confirmation response unit, 273 proxy notification unit, 290 storage unit, 300 server device, 301 processor, 302 memory, 303 auxiliary storage device, 304 communication device, 305 input/output interface, 321 identification code management unit, 331 conference information management unit, 341 participation management unit, 351 withdrawal management unit, 361 communication management unit , 371 detection management unit, 390 storage unit, 400 certification authority device, 401 processor, 402 memory, 403 auxiliary storage device, 404 communication device, 405 input/output interface, 411 CA certificate issuing unit, 421 CL certificate issuing unit, 490 memory unit.

Claims (13)

comprising a plurality of client devices participating in a web conference;
each of the plurality of client devices,
generating and storing a communication key to be used for message communication in the web conference when first participating in the web conference;
When participating in the web conference for the second time or later, share a key with a client device that is participating in the web conference and has become a parent client, receive an encrypted communication key from the parent client, and receive the encrypted communication key from the parent client. Decrypt the communication key from the encrypted communication key using a shared key with, store the communication key,
When the key is not shared with a child client while participating in the web conference, the key is shared with a client device newly participating in the web conference as the child client, and the communication key being stored is hashed. encryption, encrypts the updated and stored communication key using a shared key shared with the child client, transmits the encrypted communication key to the child client, and joins the parent client send notifications and
A web conferencing system that updates the stored communication key by the hashing when a participation notification from the child client is received. Each client device that has participated in the web conference,
sending a withdrawal notification to each of the parent client and the child client when leaving the web conference;
Each client device participating in the web conference,
When receiving the parent client's withdrawal notification, the parent client for the parent client is set as a new parent client, and the key is shared with the new parent client, and the encrypted communication key is received from the new parent client. decrypting a new communication key from the encrypted communication key using a shared key with the new parent client, storing the new communication key instead of the currently stored communication key, and generating the new communication key is encrypted using the shared key with the child client, and an encrypted communication key is transmitted to the child client;
When an encrypted communication key is received from the parent client, a new communication key is decrypted from the encrypted communication key using the shared key with the parent client, and the new communication key is replaced with the communication key being stored. store a valid communication key,
when receiving a notification of leaving the child client, making the child client of the child client a new child client, sharing the key with the new child client, generating a new communication key, and generating the communication key being stored. 2. The web conference according to claim 1, wherein the new communication key is encrypted using a shared key shared with the new child client, and the encrypted communication key is transmitted to the new child client. system. Each client device participating in the web conference,
when receiving a confirmation request for confirming that the user has left the web conference, sending an acknowledgment to the confirmation request;
A client that transmits the confirmation request at an arbitrary timing, receives the confirmation response from a client device participating in the web conference, and is not the sender of the confirmation response and has not left the web conference. 3. The web conferencing system according to claim 2, wherein the device is detected as a departed client, and the exit notification of said departed client is sent. 4. Each of the plurality of client devices does not share the key with other client devices unless one of the parent client and the child client leaves the web conference. The web conference system described in . The web conference system comprises a server device,
each of the plurality of client devices becomes a participation request client and transmits a participation request indicating an identification code to the server device when participating in the web conference;
The server device
When receiving the participation request of the participation request client that first participates in the web conference, the identification code indicated in the received participation request is collated with the member list of the web conference, and based on the collation result, the participation request client determine whether or not to participate, and transmit a participation response indicating the determination result to the participation request client;
When receiving a participation request of a participation request client that participates second or later in the web conference, sending an authentication request for the participation request client to all client devices participating in the web conference;
Each client device participating in the web conference,
receiving a signed exchange key transmitted from the join request client, verifying a signature of the signed exchange key, and verifying the signature if the key sharing with the child client has not been performed when the authentication request is received; 5. The web conference system according to any one of claims 1 to 4, wherein, if the signature of the exchange key with attachment is correct, the participation requesting client is made the child client and the key is shared using the exchange key. any one of the plurality of client devices generates the member list and transmits the signed member list to the server device;
the server device receives the signed member list, verifies the signature of the signed member list, and stores the member list if the signature of the signed member list is correct;
each of the plurality of client devices receives the member list from the server device, modifies the member list, and transmits a signed modified list to the server device;
The server device receives the signed modified list, verifies the signature of the signed modified list, and if the signature of the signed modified list is correct, updates the stored member list to the modified list. The web conference system according to claim 5, wherein the list is updated. The web conference system includes a certificate authority device,
the server device generates the identification code for each of the plurality of client devices, transmits the identification code to each of the plurality of client devices;
each of the plurality of client devices receives the identification code, generates a signature key pair, and transmits a certificate request indicating the signature public key and the identification code to the certification authority device;
The certificate authority device receives the certificate request, and transmits a query request indicating the identification code indicated in the certificate request to the server device,
The server device receives the inquiry request, compares the identification code indicated in the inquiry request with the identification code of each of the plurality of client devices, and transmits an inquiry response indicating the comparison result to the certification authority device. death,
The certificate authority device receives the inquiry response, and the signature public key indicated in the certificate request when the identification code indicated in the inquiry request is the identification code of one of the plurality of client devices. 7. The web conference system according to claim 5 or 6, wherein an electronic certificate containing is issued for a client device that is the sender of the certificate request. A client device used in the web conference system according to any one of claims 1 to 7. A client program for causing a computer to function as the client device according to claim 8. A server device used in the web conference system according to any one of claims 5 to 7. A server program for causing a computer to function as the server apparatus according to claim 10. A certificate authority device used in the web conference system according to claim 7. A certificate authority program for causing a computer to function as the certificate authority device according to claim 12.

Images