## 4 Structure of SFrame Video Conferencing System
### SFrame's Key Management System
The host and client each upload a key package containing their ID, signature, and public key to the directory (Algorithm 2, Lines 2-4). * Next, the host generates \(\textit{path}\_{secret}[0]\) and \(init\_{secret}[0]\) by a cryptographically secure RNG, uses them as inputs to HKDF, and creates a \(\textit{joiner}\_{secret}\) that is necessary to make MLS key schedule. The host encrypts \(\textit{path}\_{secret}[0]\), \(\textit{joiner}\_{secret}\), and \(\textit{psk}(option)\) with the client's public key (\(pk_{B}\)) and transmits them (Algorithm 2, Lines 5-8). Figure 3: Initial group creation process of MLS protocol. * The client decrypts the received ciphertext with their own private key (\(sk_{B}\)) to obtain the _joiner_secret_ value. The client creates the same key schedule as the host, using the acquired _joiner_secret_ and \(psk(option)\) (Algorithm 2, Lines 9-10). ### Comparison between Zoom and SFrame

In this section, we compare the E2 EE-related protocols of Zoom analyzed in Section 3 and SFrame in Section 4. The analyses of these two systems are presented in Table 2.

To compare the E2 EE-related protocols of the two systems, it was assumed that SFrame utilized the MLS protocol as its key management system, although SFrame is a video conferencing system that has the flexibility to support various ciphersuites. Zoom provides detailed information about ciphersuites in their whitepaper. The Diffie-Hellman method, which is commonly used in the key agreement process of Zoom and SFrame, is a one-to-one method for both protocols. Zoom uses Curve25519 Diffie-Hellman to generate a symmetric key (\(K_{IJ}\)) for encryption/decryption and uses the Ed25519 EdDSA. In the case of SFrame, the Elliptic Curve Diffie-Hellman (ECDH) KEM function of Hybrid Public Key Encryption (HPKE) (RFC 9180) was used to share Ratchet Tree information among group members [12]. The SFrame signature algorithm can be applied to both the EdDSA and the Elliptic Curve Digital Signature Algorithm (ECDSA). Both systems encrypt and decrypt information regarding the shared key. Zoom exchanges the meeting key (\(MK\)) by encrypting/decrypting with a symmetric key (\(K_{IJ}\)), whereas SFrame shares \(path\_secret[0]\), \(joiner\_secret\), and \(psk(option)\) using the asymmetric key encrypt/decrypt method. As mentioned in Section 2, Table 1 lists the necessary features for E2 EE security, such as authentication, confidentiality, and integrity. Both Zoom and SFrame fulfill all these features for E2 EE security. Finally, Zoom currently implements E2 EE security up to Phase 2, and specification for a Phase 3 Transparency Tree has not been implemented. In contrast, SFrame uses an asynchronous Ratchet Tree method, which enables users within a group to verify each other's authentication in real time. Therefore, SFrame can be considered to incorporate Phase 3, which corresponds to the structure of Zoom's E2 EE security plan. ## 5 Next-Generation Video Conferencing System

### GPKI-Based System

There are two main issues regarding the operation methods of public key cryptography: lack of user authentication and an expiration date for the public key. In order to use a public key passed on to someone else, it is necessary to have a trusted institution that