End-to-End Post-Quantum Cryptography Encryption Protocol for Video Conferencing System Based on Government Public Key Infrastructure

Abstract

Owing to the expansion of non-face-to-face activities, security issues in video conferencing systems are becoming more critical. In this paper, we focus on the end-to-end encryption (E2EE) function among the security services of video conferencing systems. First, the E2EE-related protocols of Zoom and Secure Frame (SFrame), which are representative video conferencing systems, are thoroughly investigated, and the two systems are compared and analyzed from the overall viewpoint. Next, the E2EE protocol in a Government Public Key Infrastructure (GPKI)-based video conferencing system, in which the user authentication mechanism is fundamentally different from those used in commercial sector systems such as Zoom and SFrame, is considered. In particular, among E2EE-related protocols, we propose a detailed mechanism in which the post-quantum cryptography (PQC) key encapsulation mechanism (KEM) is applied to the user key exchange process. Since the session key is not disclosed to the central server, even in futuristic quantum computers, the proposed mechanism, which includes the PQC KEM, still satisfies the E2EE security requirements in the quantum environment. Moreover, our GPKI-based mechanism induces the effect of enhancing the security level of the next-generation video conferencing systems up to a quantum-safe level.

1. Introduction

The use and importance of video conferencing systems are rapidly increasing in industry and academia due to the common preference for a remote environment. Security vulnerabilities in video conferencing systems have been exposed as their usage has increased. Hence, end-to-end encryption (E2EE) stands out as one of the most pressing needs for enhancing security in video conferencing systems. E2EE ensures that when two entities communicate, the contents of the message remain concealed from anyone except the intended recipient, preserving their confidentiality [1].

In order to address security vulnerabilities, video conferencing systems are currently implementing E2EE security measures. Zoom, a video conferencing system popular in recent times, currently offers two phases of E2EE security and has plans to gradually implement it across four phases. Additionally, they consistently share E2EE security updates through whitepapers on their website [2].

Discussions of security services for video conferencing systems are actively progressing through the international standardization process for various technologies.

A representative example is Secure Frame (SFrame), which is currently undergoing standardization [3]. SFrame is a group communication protocol that applies E2EE security to a web real-time-communication (WebRTC) protocol that enables real-time communication. It provides E2EE security by applying a double encryption method to a selective forwarding unit (SFU), an intermediate communication, in order to prevent the exposure of message information. Furthermore, SFrame uses a key management system for the E2EE function for symmetric key sharing. Messaging layer security (MLS) is recommended for key management systems in standardization documents [3]. This is an E2EE key management system, which is also undergoing Internet Engineering Task Force (IETF) standardization [4].

The SFrame group communication protocol has gained attention for significantly reducing communication overhead, a problem with E2EE. SFrame is currently applied and used in video conferencing systems such as Google Duo and Cisco Webex [5].

In this study, the E2EE-related protocols of Zoom and SFrame were investigated. Also, a detailed comparison between the two systems was conducted. The discussion focuses on the E2EE protocols in a video conferencing system based on the Government Public Key Infrastructure (GPKI), which is known for robust reliability compared to authentication mechanisms used in the commercial sector.

In particular, we propose a specific protocol that uses the key encapsulation mechanism (KEM) of post-quantum cryptography (PQC) for exchanging user keys in a GPKI-based video conferencing system. The proposed protocol does not expose the key to a central server because it securely shares the key through PQC KEM when a user enters a video conference. This protocol effectively fulfills authenticity, confidentiality, and integrity, which are the E2EE security requirements [6].

To analyze the GPKI-based video conferencing system, we focused on the On-nara system in Korea [7]. In short, we compared the speeds of the proposed PQC KEM protocol, NTRU KEM, with the existing GPKI protocol, RSA 2048. Furthermore, we analyzed the security of PQC KEM for GPKI and made comparisons with Zoom and SFrame, which are used in the commercial sector.

In Section 2, the research trends and security requirements regarding E2EE security are explored, including an investigation into the security vulnerabilities of Zoom. In Section 3, an analysis is conducted on the key management system presented in Zoom’s E2EE whitepaper. Section 4 describes the structure related to the E2EE function of SFrame and the E2EE security key management system, MLS. Section 5 discusses the E2EE protocol in the government user authentication mechanism and the GPKI-based authentication system. We propose a protocol that applies PQC KEM to the user key exchange process, and based on this, we construct a next-generation video conferencing system with an E2EE security function. Finally, Section 6 concludes this paper.

2. Research Trends

2.1. E2EE-Related Research

Since non-face-to-face environments are becoming more prevalent, there is an increase in the usage of online video conferencing systems. As a result, the importance of security technology for protecting the privacy of entities is receiving attention. However, a problem may occur in which the private information of an entity is exposed to a central server when video conferencing information is transmitted. A concept that has emerged to resolve this problem is E2EE, that is, an encryption technology for protecting the privacy of entities. If E2EE technology is applied to encrypt using a key that is shared only by the entities who are communication parties, the entities’ privacy is protected because messages cannot be verified except by those entities.

On the other hand, there are several practical barriers to the actual application and deployment of E2EE technology. The most significant obstacle is when the communicating party does not utilize a reliable certification authority (CA)’s Public Key Infrastructure (PKI) during the secret key generation process and instead relies on an unreliable third party as a server. This compromises the privacy of the entities, as the third party gains access to the secret key information, rendering the E2EE security function ineffective. Apart from the security issues arising from the perspective of E2EE, the following obstacles should also be taken into consideration [1].

• The government’s national policy does not actively encourage the application of E2EE technology.
• Problems arise when an entity wants services provided by a third party with low security reliability.

Despite these obstacles, E2EE security needs to be applied for the security of the entity’s video conferencing system. Furthermore, entities need to check if the system has applied E2EE security.

As a representative protocol with E2EE security, the Signal Protocol, applied to various message applications, is a cryptographic protocol that provides E2EE security for word, voice, and video encryption. This protocol has five features, Immediate Decryption, Long-lived Sessions, Usability, Forward Secrecy, and Post-Compromise Security [1].

The communication parties of the Signal Protocol receive messages immediately and decryption without loss or delay is possible. To this end, the Signal Protocol has a feature that maintains the session between communication parties until they reinstall an application or change the device. In addition, the protocol has usability because it does not use its own password or CA’s PKI. Forward Secrecy refers to the feature that even if a user in the group is attacked and the group secret key is exposed, the attacker cannot decrypt the message before the attack. Contrary to Forward Secrecy, Post-Compromise Security refers to the feature that an attacker cannot decrypt messages after a user has been attacked. Therefore, Post-Compromise Security is also referred to as Future Secrecy.

E2EE security requirements, including Forward Secrecy and Post-Compromise Security features, are defined according to the IETF standardization document [6]. In this document, the requirements for E2EE security are divided into necessary and optional features, as summarized in

Table 1. Features of end-to-end encryption.

Necessary Features	Optional Features
Authenticity Confidentiality Integrity	Availability
	Loss Resilience
	Deniability
	Forward Secrecy
	Post-Compromise Security
	Metadata Obfuscation
	Disappearing Messages

.

E2EE must satisfy the following three requirements: authenticity, confidentiality, and integrity. There are additional features that enhance E2EE security and contribute to its effectiveness. There are seven conditions, including Forward Secrecy and Post-Compromise Security, provided by the Signal Protocol.

The Cisco Webex video conference application provides E2EE security. It securely exchanges the shared meeting key based on MLS and encrypts meeting content using SFrame. It claims the security model of Webex. Also, it is able to exchange video conference data securely that are encrypted via the use of specific ciphersuites. They have described their strategy in the whitepaper [8].

On the other hand, Cisco Webex has presented a roadmap to implement zero-trust-based E2EE. The roadmap consists of two phases: Phase 1 and Phase 2. In Phase 1, they plan to deploy an E2EE using standards-based cryptography with SFrame and MLS. Phase 2 involves adding a method to verify end-to-end verified identification based on the automatic certificate management environment (ACME) protocol, which is a certification authority structure [9]. ACME supports extensions for various identifiers in different PKI contexts. Additionally, ACME can automate certain aspects of certificate management, even if some non-automated processes are still required [10].

2.2. Vulnerable Case of Video Conferencing System Security

Various video conferencing systems are being launched worldwide. Notable video conferencing systems include Zoom, Cisco Webex, Facebook, Microsoft Teams, and Google Meet. Among them, the average number of Zoom users in 2020 increased by over 40 times compared to 2019 [11].

However, as the number of Zoom users rapidly increased and began to attract attention, the number of attackers threatening security also increased. Zoom has been subject to several attacks by attackers; particularly, Zoom members’ private information has been leaked to the dark web, and Zoom Bombing/Zoom Trolling, which disrupts meetings, such as by hacking the screen, has become common.

In addition to intentional attacks, Zoom has experienced various security vulnerability issues. Zoom was also aware of these, and took measures such as upgrading the encryption algorithm to AES-256-GCM or adding a 2-Factor Authentication method to solve it [11]. Although Zoom has addressed most of the vulnerabilities, its E2EE function has only been partially addressed. Currently, the E2EE security features provided by Zoom have only been implemented up to Phase 2 out of a total of four phases.

3. Analyzing Zoom’s E2EE Capabilities

3.1. Zoom’s E2EE Capabilities

Zoom plans to provide E2EE security by subdividing it into four phases. According to Zoom’s E2EE whitepaper [2], E2EE security features have been specified in up to two phases. Zoom’s E2EE security plan is as follows:

• Phase 1: Client Key Management
• Phase 2: Identity Check
• Phase 3: Transparency Tree
• Phase 4: Real-Time Security

Phase 1 of Zoom’s E2EE involves Client Key Management. Client Key Management is a system designed to securely distribute the meeting key ($MK$) among the entities (clients) participating in a meeting, enabling them to encrypt and decrypt meeting data. E2EE Phase 2 is an Identity Check. In Phase 1, the identity status of each client is based on the displayed screen name during the meeting, whereas in Phase 2, the client’s identity status is traced using Sigchain. By reviewing the record of the client’s identity status during the meeting, it becomes possible to prevent attacks from suspicious devices.

Zoom’s E2EE phases 3 and 4 have not been applied and are planned for application in the future. Phase 3 introduces the Transparency Tree, which expands the authentication assurance to enable all clients in the conference to verify devices and keys. Phase 4 involves Real-Time Security, which strengthens meeting security through additional signatures and enables client Sigchain verification without passing through the Zoom server.

In Section 3, we analyze Client Key Management, which is the first step in E2EE security. The details and plans for the remaining phases of Zoom’s E2EE security are included in Zoom’s E2EE whitepaper [2].

3.2. Analysis of Zoom’s E2EE Phase 1

A Zoom meeting typically comprises a host, who initiates and manages the meeting, and participants who join the meeting. First, assume that Alice (host) and Bob (participant) understand the Client Key Management system of Zoom. Additionally, it is assumed that both entities possess a long-time signing key (${ISK}_I$) and a long-time verification key (${IVK}_I$). Based on the above conditions, the process of Zoom’s Client Key Management system is illustrated in Figure 1 [2].

We describe the progress of Figure 1 in terms of Algorithm 1:

• When each client logs in to Zoom, the Zoom server generates a signature (${Sig}_{Server}^I({IVK}_I)$) for each client’s verification key (${IVK}_I$) (Algorithm 1, Line 1).
• Each client generates a temporary encryption key pair, public key, and secret key (${pk}_I,s{k}_I$). Each client generates a signature (${Sig}_I$) with the Edwards-curve Digital Signature Algorithm (EdDSA), and after that uploads the public key (${pk}_I$), signature (${Sig}_I$), and signature for the verification key (${Sig}_{Server}^I({IVK}_I)$) to the bulletin board (Algorithm 1, Lines 2–6).
• To generate a symmetric key ($K_{AB}$) for the encryption/decryption of the meeting key ($MK$), the host (Alice) performs the Diffie–Hellman method between the public key (${pk}_B$) of the verified participant (Bob) and its own private key (${sk}_A$). Subsequently, these keys are used as inputs to the HMAC-based Key Derivation Function (HKDF). The participant (Bob) uses his own private key (${sk}_B$) and the host’s public key (${pk}_A$) to generate a symmetric key ($K_{AB}$) in a similar manner (Algorithm 1, Lines 8, 12).
• The host generates a 32-byte shared meeting key ($MK$) that is used to encrypt and decrypt the meeting data using AES-GCM. The meeting key is generated using a cryptographically secure random number generator (RNG). The host then encrypts it with the symmetric key ($K_{AB}$), uploads it to the bulletin board, decrypts the ciphertext with the symmetric key ($K_{AB}$), and obtains the meeting key ($MK$) (Algorithm 1, Lines 9, 10, 13).

Otherwise, if a new participant, Charlie, joins the key management system as mentioned above, which includes Alice and Bob, the following steps are additionally performed. It is assumed that Charlie possesses a long-time signing key (${ISK}_C$) and a long-time verification key (${IVK}_C$).

Algorithm 1: E2EE Key Exchange Process of Zoom

$\mathit{A}$: Alice (host),$\mathit{B}$: Bob (client),${\mathit{p}\mathit{k}}_{\mathit{I}}$: public key,${\mathit{s}\mathit{k}}_{\mathit{I}}$: secret key,${\mathit{I}\mathit{V}\mathit{K}}_{\mathit{I}}$: verification key, ${\mathit{I}\mathit{S}\mathit{K}}_{\mathit{I}}$: signing key,$\mathit{M}\mathit{K}$: shared meeting key,${\mathit{S}\mathit{i}\mathit{g}}_{\mathit{I}}$: signature for public key, ${\mathit{K}}_{\mathit{A}\mathit{B}}$: symmetric key for enc/dec, ${\mathit{S}\mathit{i}\mathit{g}}_{\mathit{S}\mathit{e}\mathit{r}\mathit{v}\mathit{e}\mathit{r}}^{\mathit{I}}\left(\mathit{I}\mathit{V}{\mathit{K}}_{\mathit{I}}\right)$: signature of the server for verification key

1: For user $A$,$B$ do ${Sig}_{Server}^I\left(IV{K}_I\right)\leftarrow$Zoom server         ▷$A$,$B$ signs in, $I\in \{A,B\}$

2: procedure (Zoom’s E2EE Key Exchange) 3:   For user $A$,$B$ do                         ▷$I\in \{A,B\}$ 4:      (${pk}_I$,${sk}_I$)$\leftarrow$KeyGen 5:      ${Sig}_I\leftarrow$EdDSA(${pk}_I$) 6:      bulletin board$\leftarrow${${pk}_I$,${Sig}_I$,${Sig}_{Server}^I$} 7:   For user $A$ do 8:      $K_{AB}\leftarrow$HKDF(Diffie–Hellman(${pk}_B$, ${sk}_A$)) 9:      $MK\stackrel{\$}{\leftarrow }$Secure RNG 10:     bulletin board$\leftarrow$Enc($K_{AB}$,$MK$) 11:  For user $B$ do 12:     $K_{AB}\leftarrow$HKDF(Diffie–Hellman(${pk}_A$, ${sk}_B$)) 13:     $MK\leftarrow$Dec($K_{AB}$, Enc($K_{AB}$,$MK$)) 14: end procedure

• The Zoom server generates a signature (${Sig}_{Server}^C({IVK}_C)$) for Charlie’s verification key (${IVK}_C$). After that, Charlie generates a temporary encryption key pair (${pk}_C,s{k}_C$) and a signature (${Sig}_C$) with EdDSA. Then, Charlie uploads the public key (${pk}_C$), signature (${Sig}_C$), and signature for the verification key (${Sig}_{Server}^C\left({IVK}_C\right)$) to the bulletin board.
• To generate a symmetric key ($K_{AC}$), Alice performs the Diffie–Hellman method between the public key (${pk}_C$) and its own private key (${sk}_A$). Charlie uses his own private key (${sk}_C$) and the Alice’s public key (${pk}_A$) to generate the symmetric key ($K_{AC}$), similarly.
• Alice generates a new 32-byte shared meeting key ($M{K}^{*}$). Then, Alice encrypts it with each symmetric key ($K_{AB}$,$K_{AC}$) and uploads it to the bulletin board. After that, Bob and Charlie can decrypt the ciphertext with each symmetric key ($K_{AB}$,$K_{AC}$), and obtain the meeting key ($M{K}^{*}$).

4. Structure of SFrame Video Conferencing System

Here in Section 4, the group communication protocol SFrame and the key management system MLS, which are in the process of standardization as video conferencing systems, are analyzed. Subsequently, we describe how the E2EE-related Zoom and SFrame protocols were investigated to compare and analyze the two systems. SFrame applies the E2EE mechanism to the WebRTC protocol, enabling real-time communication [3].

The SFrame protocol employs double encryption to media, such as video or audio, ensuring secure transmission with E2EE. As a result, the SFU central server, which relays end-to-end media traffic, cannot access the plaintext message information, but only the necessary metadata for communication routing. Moreover, SFrame encrypts the entire media frame during transmission rather than encrypting individual media packets separately. In other words, SFrame uses an initialization vector ($IV$) and an authentication tag for each frame for encryption. This method has gained significant attention, as it reduces communication overhead, which is a well-known challenge in E2EE [3].

4.1. Analysis of SFrame

The double encryption method applied by SFrame is as follows [3]:

• Hop-by-Hop Encryption (DTLS-SRTP)
• End-to-End Encryption (Symmetric)

Figure 2 illustrates the process by which the communication parties, Alice and Bob, securely transmit media using the SFrame protocol with double encryption. First, the two entities share a group symmetric key schedule through a key management system with E2EE security in advance.

Alice retrieves the SFrame symmetric key from the pre-shared key schedule and utilizes it to encrypt the media. Next, the encrypted media are packetized before being transmitted to the SFU. Alice encrypts the packetized media with the Datagram Transport Layer Security for Secure Real-time Transport Protocol (DTLS-SRTP) symmetric key and transmits it to the SFU. The SFU decrypts the media packet using the pre-shared DTLS-SRTP symmetric key with Alice, and then re-encrypts the decrypted media with Bob’s DTLS-SRTP symmetric key before delivering it. Finally, Bob can decrypt the ciphertext sequentially with a DTLS-SRTP key and an SFrame symmetric key. Consequently, the plaintext of the media is not exposed to the SFU. The SFU checks only the media metadata and routes the media packets received from Alice to Bob.

The symmetric key used for double encryption in the encryption/decryption process of the SFrame protocol is the same, and a key management system for the E2EE function is essential for symmetric key sharing. The$index$and$base\text{\_}key$information related to the$KID$are assigned to the entities of the group belonging to the key management system. Therefore, each entity obtains the$base\text{\_}key$information used for decryption by checking the$KID$of the transmitted media header. For SFrame encryption,$base\text{\_}key$is used as an input to the HKDF function to derive the SFrame symmetric key and$salt$value. Subsequently, a$nonce$is generated by XOR$salt$with$ctr$, and the$nonce$value is used for encryption/decryption.

4.2. SFrame’s Key Management System

The SFrame protocol was proposed to separate the use of the key from the encryption algorithm. Using this design, any key management system with E2EE security can be applied to SFrame, for example, E2EE security protocols such as Signal Protocol, Olm Protocol, MLS, etc. Currently, the IETF draft document on SFrame recommends the use of MLS as the key management system [3].

Analysis of MLS Protocol

The MLS protocol is a key management system in the process of standardization by the IETF. MLS has been standardized since 2018, and recently, an RFC standard was proposed [4].

Figure 3 shows the initial group creation process for the MLS key management system. To describe this process, the Ratchet Tree, the key schedule of the MLS, and Secret Tree structures have to be explained; however, this paper describes the process of adding members without explaining the tree structure.

We describe progress of Figure 3 in terms of Algorithm 2:

Algorithm 2: E2EE Key Exchange Process of MLS Protocol

$\mathit{A}$: host,$\mathit{B}$: client,${\mathit{p}\mathit{k}}_{\mathit{I}}$: public key,${\mathit{s}\mathit{k}}_{\mathit{I}}$: secret key,$\mathit{c}\mathit{r}\mathit{e}\mathit{d}\mathit{e}\mathit{n}\mathit{t}\mathit{i}\mathit{a}{\mathit{l}}_{\mathit{I}}$: credential, ${\mathit{I}\mathit{V}\mathit{K}}_{\mathit{I}}$: verification key,${\mathit{I}\mathit{S}\mathit{K}}_{\mathit{I}}$: signing key,$\mathit{I}{\mathit{D}}_{\mathit{I}}$: identity,$\mathit{p}\mathit{a}\mathit{t}\mathit{h}\text{\_}\mathit{s}\mathit{e}\mathit{c}\mathit{r}\mathit{e}\mathit{t}$, $\mathit{j}\mathit{o}\mathit{i}\mathit{n}\mathit{e}\mathit{r}\text{\_}\mathit{s}\mathit{e}\mathit{c}\mathit{r}\mathit{e}\mathit{t}$: parameters to generate key schedule,$\mathit{p}\mathit{s}\mathit{k}$: pre-shared key $\mathit{A}\mathit{S}$: Authentication Service

1: procedure (MLS’s E2EE key exchange process)

2:   For user $A$,$B$ do                                                    ▷$I\in \{A,B\}$ 3:      $credentia{l}_I\stackrel{Verify}{\leftarrow }AS$                                            ▷$credentia{l}_I=\{IV{K}_I,I{D}_I\}$ 4:      Directory$\leftarrow$KeyPackage($I$)                                ▷KeyPackage($I$)$=\{p{k}_I,ciphersuit{e}_I,si{g}_I\}$ 5:   For user $A$ do 6:      $path\text{\_}secret[0],init\text{\_}secret[0]\stackrel{\$}{\leftarrow }$Secure RNG 7:      $joiner\text{\_}secret\leftarrow$HKDF($path\text{\_}secret\left[0\right],init\text{\_}secret\left[0\right]$) 8:      Directory$\leftarrow$Enc($p{k}_B$,$path\text{\_}secret\left[0\right]\parallel joiner\text{\_}secret\parallel psk\left(option\right)$) 9:   For user $B$ do 10:     $path\text{\_}secret\left[0\right]$,$joiner\text{\_}secret$,$psk\left(option\right)\leftarrow$          Dec($s{k}_B$, Enc($p{k}_B$,$path\text{\_}secret\left[0\right]\parallel joiner\text{\_}secret\parallel psk\left(option\right)$)) 11: end procedure

• Assume that a host creates a group, and a client joins a group. They join the group and present their credentials for authentication and undergo verification by the Authentication Service (AS) of the MLS server. 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$path\text{\_}secret\left[0\right]$and$init\text{\_}secret\left[0\right]$by a cryptographically secure RNG, uses them as inputs to HKDF, and creates a $joiner\text{\_}secret$ that is necessary to make MLS key schedule. The host encrypts$path\text{\_}secret\left[0\right]$,$joiner\text{\_}secret$, and$psk\left(option\right)$with the client’s public key ($p{k}_B$) and transmits them (Algorithm 2, Lines 5–8).
• The client decrypts the received ciphertext with their own private key ($s{k}_B$) to obtain the$joiner\text{\_}secret$value. The client creates the same key schedule as the host, using the acquired$joiner\text{\_}secret$and$psk\left(option\right)$ (Algorithm 2, Lines 9–10).

4.3. Comparison between Zoom and SFrame

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

Table 2. Comparison between Zoom and SFrame.

Property		Zoom	SFrame (with MLS)
Key Agreement		ECDH, HKDF	HPKE (ECDH-based KEM) (RFC 9180)
Signature		EdDSA	EdDSA ECDSA
Shared-Key Exchange		$Enc$($MK$)$\leftarrow$Symmetric($K_{IJ}$)	$Enc$($joiner\text{\_}secret$, $path\text{\_}secret$[$i$]) $\leftarrow$Asymmetric($p{k}_I$, $s{k}_I$)
E2EE	Authenticity	○	○
	Confidentiality	○	○
	Integrity	○	○
Transparency Tree		×	○

.

To compare the E2EE-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\text{\_}secret\left[0\right]$,$joiner\text{\_}secret$, and$psk\left(option\right)$using the asymmetric key encrypt/decrypt method.

As mentioned in Section 2, Table 1 lists the necessary features for E2EE security, such as authentication, confidentiality, and integrity. Both Zoom and SFrame fulfill all these features for E2EE security.

Finally, Zoom currently implements E2EE 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 E2EE security plan.

5. Next-Generation Video Conferencing System

5.1. 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 can manage the list of public keys. The GPKI is an example of such an infrastructure that provides the necessary mechanisms for managing and distributing public keys securely. The GPKI, also known as an administrative electronic signature, utilizes GPKI certificates issued by certification authorities. These certificates serve as electronic information that verifies and provides evidence of the authenticity of signatures. Electronic information is issued to administrative, auxiliary, and assistant agencies, public infrastructure, banks, and users [13].

Figure 4 depicts GPKI-based and National Public Key Infrastructure (NPKI)-based certification schemes. First, the GPKI system uses a top-level certification authority (CA1) to manage a list of public keys for public service workers (A, B). The CA1 issues a certificate ($cer{t}_I$) containing a signature for the public key ($p{k}_I$) that signs with its private key ($s{k}_{CA}$). Second, the NPKI system uses another top-level certification authority (CA2) that manages multiple CAs. These multiple CAs maintain public keys for civilians (C, D). Also, these CAs issue a certificate ($cer{t}_I$) to civilians. These two authentication systems mutually recognize each other and collaborate to manage a certificate trust list. As CA1, CA2, and the CAs managed by them are trusted authorities, users can trust the public keys contained in the certificates they issue.

5.2. End-to-End PQC Encryption Protocol Applicable to GPKI-Based Video Conferencing Systems

GPKI-based video conferencing systems employ user authentication mechanisms that differ from those used in the commercial sector. Unlike Zoom’s login and signature method, and authentication through SFrame’s credentials, GPKI-based video conferencing systems require a login with a certificate issued by a government agency. Consequently, if all meeting participants are affiliated with a government agency and possess GPKI-based certificates, there are no obstacles to their participation. Meanwhile, ordinary people who participate in meetings do not have GPKI certificates; therefore, another authentication method is required. Access through a provided link or a one-time password authentication method may be a possible method for authenticating those in the commercial sector.

We propose the application of PQC KEM to the user key exchange process of the E2EE protocol in a GPKI-based video conferencing system. Previously, in Zoom’s E2EE security Phase 1, Client Key Management and meeting data could be encrypted or decrypted if a 32-byte$MK$was shared securely. In the proposed next-generation video conferencing system, the session key ($ss$) shared through KEM plays the same role as the 32-byte$MK$in Zoom.

Figure 5, below, shows the application of the PQC KEM to the GPKI-based video conferencing system. We describe the progress of the Figure 5 in terms of Algorithm 3:

Algorithm 3: E2EE Key Exchange Process with KEM Applied to Next-Generation Video Conferencing System

$\mathit{A}$: host,$\mathit{B}$: client,${\mathit{p}\mathit{k}}_{\mathit{I}}$: public key,${\mathit{s}\mathit{k}}_{\mathit{I}}$: secret key,${\mathit{I}\mathit{V}\mathit{K}}_{\mathit{I}}$: verification key,${\mathit{I}\mathit{S}\mathit{K}}_{\mathit{I}}$: signing key,${\mathit{S}\mathit{i}\mathit{g}}_{\mathit{S}\mathit{e}\mathit{r}\mathit{v}\mathit{e}\mathit{r}}^{\mathit{I}}\left(\mathit{I}\mathit{V}{\mathit{K}}_{\mathit{I}}\right)$: signature of the server for verification key,${\mathit{S}\mathit{i}\mathit{g}}_{\mathit{I}}$: signature for public key,$\mathit{R}$: random source,$\mathit{s}\mathit{s}$: shared session key,$\mathit{c}\mathit{t}$: ciphertext

1: procedure (Next-generation video conferencing system’s E2EE key exchange process)

2:   For user $A$,$C$ do                                                                       ▷$I\in \{A,C\}$ 3:      $GPKICertificate\stackrel{Verify}{\leftarrow }CA$ 4:   For user $A$ do 5:      Server$\leftarrow${$ciphersuit{e}_A$,$Si{g}_{Server}^A\left(IV{K}_A\right)$,$Si{g}_A$} 6:   For user $C$ do 7:      ($p{k}_C$,$s{k}_C$)$\leftarrow$KeyGen 8:      Server$\leftarrow${$p{k}_C$,$Si{g}_{Server}^C\left(IV{K}_C\right)$,$Si{g}_C$} 9:   For user $A$ do 10:     $ss\leftarrow R\stackrel{\$}{\leftarrow }$Secure RNG 11:     Server$\leftarrow ct=\mathit{E}\mathit{n}\mathit{c}\mathit{a}\mathit{p}$($p{k}_C$,$R$) 12:  For user $C$ do 13:     $ss\leftarrow R=\mathit{D}\mathit{e}\mathit{c}\mathit{a}\mathit{p}$($s{k}_C$,$ct$) 14: end procedure

First, it is assumed that both the host (A), who owns the GPKI, and the general client (C) are normally authenticated by the NPKI. The host uploads a ciphersuite ($ciphersuit{e}_A$), the server’s signature for the verification key ($Si{g}_{Server}^A\left(IV{K}_A\right)$), and their own signature ($Si{g}_A$). Subsequently, the client generates a public key ($p{k}_C$) and a private key ($s{k}_C$) using the host’s ciphersuite. The client then uploads their public key ($p{k}_C$), the server’s signature for the verification key ($Si{g}_{Server}^B\left(IV{K}_B\right)$), and their own signature ($Si{g}_B$). Next, the host creates a session key ($ss$) using a random source extracted from a cryptographically secure RNG. The host encrypts the session key ($ss$) with the client’s public key ($p{k}_C$), and uploads it. The client decrypts the ciphertext with the secret key ($s{k}_C$) to obtain the session key ($ss$). Finally, the host and client can securely encrypt/decrypt with the session key ($ss$) and share conference data.

The next-generation video conferencing system depicted in Figure 5, which utilized the PQC KEM, addresses the integrity requirement by leveraging authentication and signing provided by the GPKI. Moreover, this system satisfies the confidentiality requirements through public key encryption. Hence, the PQC encryption protocol employed in the GPKI-based video conferencing system fulfills the E2EE security feature requirements outlined in Table 1.

Figure 6 illustrates an example of applying NTRU KEM, one of the third-round candidates for the National Institute of Standards and Technology (NIST) PQC standardization contest, to a GPKI-based video conferencing system. When using a ciphersuite of NTRU KEM with a security level 1, such as ‘ntruhps2048509′, the size of the shared session key ($ss$) is 32 bytes, which is the same size as the$MK$in Zoom [14].

First, the host (A) uploads the server’s signature for the verification key and ciphersuite. The client (C) generates a private key ($f$,$f_p$,$h_q$,$s$) and a public key ($h$) using the NTRU algorithm, and uploads the public key ($h$) and signature. Second, the host extracts a random value ($r$,$m$) using a cryptographically secure RNG, and encrypts it with public key ($h$). During this procedure, the host creates a 32-byte session key ($ss$) with a random value ($r$,$m$). Third, the client decrypts the ciphertext with their own private key ($f$,$f_p$,$h_q$,$s$), and gets ($r$,$m$). Finally, they generate a 32-byte session key ($ss$) with ($r$,$m$) in the same way as the host. Consequently, the host and client both have the 32-byte shared symmetric session key ($ss$), without having exposed the key to the central server.

The NTRU KEM was used as the PQC scheme shown in Figure 6, but other PQC schemes could also be applied to the proposed PQC encryption protocol. As a possible option, since CRYSTALS-KYBER has been selected as the PQC KEM standard after the third round of the NIST PQC standardization competition [15], applying this KEM to the proposed GPKI-based video conferencing system’s E2EE PQC protocol could contribute to improving the security of the next-generation video conferencing system.

5.3. Security of GPKI-Based Video Conferencing Systems

In Section 3 and Section 4, we reviewed Zoom, a commercially available video conferencing system, and an open library, SFrame. Both systems rely on environments without any PKI or CA that is admitted by external participants. However, in Korea, there exists a video conferencing system, On-Nara, based on the Korean GPKI [7]. Therefore, we aim to obtain security for next-generation video conferencing systems by applying PQC KEM to the On-Nara GPKI system. As a result, the security of our GPKI-based video conferencing system could be enhanced to a quantum-safe level.

We performed a comparative analysis of the GPKI-based video conferencing system. For analysis, we compared the NTRU KEM proposed in Section 5.2 with the On-Nara system. Since the On-Nara video conferencing system is not publicly accessible, our implementation was restricted. Thus, our comparison was limited to the protocol level.

Currently, the GPKI system uses RSA 2048 public key cryptography for key exchange and authentication. Therefore, we compared the cycles of the NTRU KEM with RSA 2048, which is used in GPKI. According to NIST’s documentation, RSA 2048 has a 112-bit security level [16]. For a fair comparison, we chose ‘ntruhps2048509′, which has a similar 128-bit security level [14]. Since the GPKI is not open to the public, we referred to the RSA 2048 and ‘ntruhps2048509′ that are benchmarked in eBACS for our experiment. A comparison of these two protocols is presented in

Table 3. Comparison between RSA 2048 and NTRU KEM [17].

	RSA 2048	NTRU KEM (ntruhps2048509)
Encapsulation	20226 cycles	23696 cycles
Decapsulation	2120310 cycles	38141 cycles
Environment	amd64; Comet Lake; 2019 Intel Core i3-10110U; 2 × 2100MHz
Security level	112-bit	128-bit
Quantum Safe	×	○

[17]. Eventually, we found that NTRU KEM is slightly slower than RSA 2048 for encapsulation. In contrast, it was significantly faster than RSA 2048 for decapsulation. Since CRYSTALS-KYBER is faster than NTRU, we expect more accelerated performance when applying CRYSTALS-KYBER to GPKI.

For NTRU KEM, we implemented this protocol using an open source from NIST’s PQC standardization contest’s third round. We used an Intel Core i7-10700K 3.80GHz with Windows 10 in 64-bit mode and compiled the code through __rdtsc() to measure the CPU’s cycles. As a result, we derived a value of 0.66 megacycles/operation for encapsulation, and 1.41 megacycles/operation for decapsulation. It should be noted that the experimental environment differed from eBACS.

The comparison between the proposed PQC KEM and other systems is presented in

Table 4. Comparison between other systems and PQC KEM for GPKI.

Property	Zoom and SFrame	PQC KEM for GPKI
User Authentication	By commercial sector CA	By government Top-level CA
Key Agreement	Elliptic curve cryptography	Post-quantum cryptography
Quantum Safe	×	○
E2EE	○	○

. PQC KEM for GPKI provides user authentication through a government top-level CA. Meanwhile, Zoom and SFrame provide it by a commercial sector CA, which is less reliable than that of a government. Furthermore, the PQC KEM for GPKI uses PQC for key agreement, offering a quantum-safe level. In contrast, commercial sector systems apply elliptic curve cryptography, which doesn’t provide quantum safety. Both systems, however, provide E2EE security.

In the end, there are no international standards for security requirements of video conferencing systems. In Korea, standardization work is underway by the Telecommunications Technology Association (TTA). This standard is now being organized into four major categories: conference environment setup, user authentication, conference content protection, and conference progression. The E2EE PQC KEM protocol proposed in Section 5.2 meets the security requirements of the TTA standard.

6. Conclusions

We examined and compared two representative video conferencing systems, Zoom and SFrame, focusing on their E2EE capabilities. Both systems were found to meet the necessary feature requirements of E2EE; however, there was a difference between Zoom, which uses a symmetric key method, and SFrame, which uses an asymmetric key method for encrypting and decrypting shared keys.

To improve the security of E2EE protocols in GPKI-based video conferencing systems that are not in the commercial sector, we propose the application of PQC KEM during the key exchange process. This mechanism satisfies the integrity requirement through signing with GPKI-based authentication and the confidentiality requirement through encryption, resulting in E2EE security. Moreover, we expect this mechanism to securely share session keys even in the face of the escalating threat posed by quantum computers. Therefore, the security of video conferencing systems can be improved.

The proposed PQC protocol for E2EE in a GPKI-based video conferencing system appears to serve as valuable reference material for enhancing the On-Nara video conferencing system based on the Korea GPKI. However, as there is currently no established Korean standard for PQC, the application of a specific PQC KEM algorithm may necessitate future modifications for its usage in video conferencing systems. Therefore, the application of a specific PQC algorithm to the proposed protocol is left for future studies. In conclusion, we hope this document will be referenced when users are considering the application of PQC KEM to future video conferencing systems.