Method and apparatus for video call encryption, initiator terminal, receiver terminal

Abstract

The application relates to the technical field of video call encryption, and discloses a method for video call encryption, which is applied to an initiator terminal and comprises the following steps: sending call request information to a receiver terminal through a signaling server to trigger the receiver terminal to return a response message; obtaining a first session key from a first key material pool to generate first confirmation information; the first key material pool stores a shared key pre-injected by a quantum key distribution network; sending the first confirmation information to the receiver terminal to trigger the receiver terminal to obtain a second session key according to the first confirmation information, generate second confirmation information and feed back the second confirmation information; verifying the second confirmation information, encrypting audio and video data by using the first session key; and sending the encrypted data packet to the receiver terminal. The method can improve the security of video call data and reduce the deployment cost of the terminal. The application also discloses an apparatus for video call encryption, an initiator terminal and a receiver terminal.

Description

Technical Field

[0001] This application relates to the field of video call encryption technology, such as a method and apparatus for video call encryption, an initiating terminal, and a receiving terminal. Background Technology

[0002] With the increasing popularity of applications such as telemedicine, online education, and family video calls, users are demanding more and more privacy and security from video calls.

[0003] Currently, there are two main technical approaches to end-to-end encryption in video calls: one is that video call applications (such as WeChat Video, FaceTime, etc.) use the TLS 1.3 protocol handshake, and its key negotiation phase relies on the ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) protocol for forward secure key exchange. ECDHE's security is based on the Elliptic Curve Discrete Logarithm Problem (ECDLP), which can be solved in polynomial time using Shor's algorithm. If an attacker implements a Harvest Now, DecryptLater strategy—intercepting and storing all encrypted communication traffic now, and then using quantum computers to crack it in bulk later—all historical video call content will face systemic leakage, resulting in low security for video call encryption. The other approach is a physical layer security scheme based on Quantum Key Distribution (QKD). The QKD solution requires both communicating terminals to deploy quantum transceiver equipment, such as single-photon detectors and quantum state modulators, and connect to the QKD network node via dedicated quantum optical fibers. Deploying quantum transceiver equipment is costly and requires professional maintenance personnel, which significantly increases the cost of the transceiver terminals.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.

[0006] This disclosure provides a method and apparatus for encrypting video calls, as well as an initiating terminal and a receiving terminal, which can improve the security of video call data and reduce the deployment cost of the terminal.

[0007] In some embodiments, the method is applied to an initiating terminal, and includes: sending call request information to a signaling server, triggering the signaling server to authenticate the initiating terminal, and if the authentication is successful, forwarding the call request information to a receiving terminal to trigger the receiving terminal to authenticate the initiating terminal and return a response message; upon receiving the response message returned by the receiving terminal, obtaining a first session key from a preset first key material pool, and generating first confirmation information based on the first session key; the first key material pool stores a shared key pre-injected by a quantum key distribution network; sending the first confirmation information to the receiving terminal, triggering the receiving terminal to obtain a second session key based on the first confirmation information, generating second confirmation information based on the second session key, and feeding back the second confirmation information; verifying the second confirmation information fed back by the receiving terminal, and if the verification is successful, encrypting the audio and video data to be sent using the first session key to obtain an encrypted audio and video data packet; and sending the encrypted audio and video data packet to the receiving terminal.

[0008] In some embodiments, the method is applied to a receiving terminal, and the method includes: upon receiving call request information sent by a signaling server, authenticating the initiating terminal based on the call request information; if the authentication is successful, sending a response message to the sending terminal through the signaling server, triggering the sending terminal to return first confirmation information; the first confirmation information includes a key sequence number and a call random number encrypted using a first session key; the key sequence number corresponds to the first session key; receiving the first confirmation information sent by the sending terminal, obtaining a second session key from a preset second key material pool based on the key sequence number; the second key material pool stores a shared key pre-injected by a quantum key distribution network; generating second confirmation information based on the second session key and the encrypted call random number, and sending the second confirmation information to the sending terminal, triggering the initiating terminal to verify the second confirmation information; receiving encrypted audio and video data packets sent by the sending terminal, and decrypting the received encrypted audio and video data packets using the second session key.

[0009] In some embodiments, the apparatus includes a first processor and a first memory storing program instructions, the first processor being configured to execute the above-described method for encrypting video calls when the program instructions are executed.

[0010] In some embodiments, the apparatus includes a second processor and a second memory storing program instructions, the second processor being configured to execute the above-described method for encrypting video calls when the program instructions are executed.

[0011] In some embodiments, the initiating terminal includes: an initiating terminal body; and the aforementioned device for encrypting video calls is installed on the initiating terminal body.

[0012] In some embodiments, the receiving terminal includes: a receiving terminal body; and the aforementioned device for encrypting video calls is installed on the receiving terminal body.

[0013] The method and apparatus for video call encryption, along with the initiating terminal and receiving terminal provided in this disclosure, achieve the following technical effects: A shared key is periodically injected into a first key resource pool on the initiating terminal's local machine via a quantum key distribution (QKD) network. The initiating terminal only needs to retrieve the pre-stored shared key from the first key resource pool and use it as the session key to confirm the session with the receiving terminal and encrypt audio and video data. Thus, the session key originates from the information-theoretic secure key of the QKD process, and its security is based on the no-cloning theorem and the measurement collapse principle of quantum mechanics, independent of the attacker's computational power. Even if future quantum computers break through the classical public-key cryptography system, they will not be able to crack the encrypted historical call content, effectively improving the security of video call data. Furthermore, it eliminates the need to deploy quantum transceiver equipment locally on the transceiver terminals, effectively reducing terminal deployment costs.

[0014] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description

[0015] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 This is a schematic diagram of a method for encrypting video calls provided in an embodiment of this disclosure; Figure 2 This is a schematic diagram of another method for encrypting video calls provided in an embodiment of this disclosure; Figure 3 This is a schematic diagram of another method for encrypting video calls provided in an embodiment of this disclosure; Figure 4 This is a schematic diagram of an apparatus for encrypting video calls provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of another device for encrypting video calls provided in an embodiment of this disclosure; Figure 6 This is a schematic diagram of an initiating terminal provided in an embodiment of this disclosure; Figure 7 This is a schematic diagram of a receiving terminal provided in an embodiment of this disclosure. Detailed Implementation

[0016] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0017] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0018] Unless otherwise stated, the term "multiple" means two or more.

[0019] In this embodiment of the disclosure, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.

[0020] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.

[0021] The term "correspondence" can refer to an association or binding relationship. The correspondence between A and B means that there is an association or binding relationship between A and B.

[0022] The method for encrypting video calls provided in this disclosure is applied to the initiating terminal. The initiating terminal includes smart TVs, smartphones, tablets, or video conferencing terminals, etc.

[0023] Quantum key distribution (QKD) is based on the no-cloning theorem and the measurement collapse principle of quantum mechanics to generate information-theoretic secure symmetric keys between two communicating parties.

[0024] Both the sending and receiving terminals integrate an HSM (Hardware Security Module). The HSM is a dedicated security chip that provides cryptographic services including secure key storage, hardware-based key derivation, symmetric encryption / decryption (AES-256-GCM), and true random number generation. The HSM features an active anti-tampering mechanism. Upon detecting physical intrusion, such as drilling, voltage spikes, or abnormal temperatures, it automatically triggers an internal high-voltage erasure circuit to remove all key materials in less than 1 μs.

[0025] Combination Figure 1 As shown, this disclosure provides a method for encrypting video calls, including: In step S101, the initiating terminal sends a call request message to the signaling server, triggering the signaling server to authenticate the initiating terminal. If the authentication is successful, the call request message is forwarded to the receiving terminal, triggering the receiving terminal to authenticate the initiating terminal and return a response message.

[0026] In some embodiments, the call request information is an INVITE request, which also includes the initiating terminal's digital certificate and a list of PQC (Post-Quantum Cryptography) algorithms supported by the initiating terminal. For example, the initiating terminal's digital certificate is an X.509 certificate with an EC P-256 signature. The initiating terminal sends the call request information to the signaling server, so that the signaling server can authenticate the initiating terminal based on its digital certificate. For example, the signaling server verifies the legality, integrity, and source trustworthiness of the certificate based on the initiating terminal's X.509 certificate chain and digital signature carried in the INVITE request. If authentication is successful, the call request information is forwarded to the receiving terminal, so that the receiving terminal can authenticate the initiating terminal based on its digital certificate. If authentication is successful, the receiving terminal returns a response message to the signaling server, so that the signaling server can return the response message to the initiating terminal. The response message is "200 OK". The response message also includes the receiving terminal's digital certificate and a list of supported PQC algorithms. In this way, the initiating terminal and the receiving terminal complete two-way authentication and password capability negotiation through the signaling server.

[0027] In step S102, when the initiating terminal receives the response message returned by the receiving terminal, it obtains the first session key from the preset first key material pool and generates the first confirmation information based on the first session key. The first key material pool stores the shared key pre-injected by the quantum key distribution network.

[0028] In some embodiments, the first key pool is managed as a FIFO (First In First Out) circular queue. The initiating terminal's HSM (Hardware Security Module) reads the first key from the first key pool and uses it as the first session key.

[0029] In step S103, the initiating terminal sends a first confirmation message to the receiving terminal, triggering the receiving terminal to obtain a second session key based on the first confirmation message, generate a second confirmation message based on the second session key, and then send back the second confirmation message.

[0030] In step S104, the initiating terminal verifies the second confirmation information fed back by the receiving terminal. If the verification is successful, the initiating terminal uses the first session key to encrypt the audio and video data to be sent, thereby obtaining the encrypted audio and video data packet.

[0031] In step S105, the initiating terminal sends the encrypted audio and video data packets to the receiving terminal.

[0032] The method for encrypting video calls provided in this disclosure involves periodically injecting a shared key into a first key resource pool on the initiating terminal's local machine via a quantum key distribution (QKD) network. The initiating terminal only needs to retrieve the pre-stored shared key from the first key resource pool and use it as the session key to confirm the session with the receiving terminal and encrypt audio and video data. Thus, the session key originates from the information-theoretic secure key of the QKD process, and its security is based on the no-cloning theorem and the measurement collapse principle of quantum mechanics, independent of the attacker's computational power. Even if future quantum computers break through the classical public-key cryptography system, they will not be able to crack the encrypted historical call content, effectively improving the security of video call data. Furthermore, it eliminates the need to deploy quantum transceiver equipment locally on the transceiver terminals, effectively reducing terminal deployment costs.

[0033] Optionally, the shared key stored in the first key resource pool is injected as follows: According to a preset injection period, the ciphertext payload sent by the quantum key distribution network node is received through the first encrypted transmission channel. The ciphertext payload includes the encrypted shared key, a second authentication tag, a timestamp, and a key sequence number. The first encrypted transmission channel is the transmission channel between the sending terminal and the quantum key distribution network node. The integrity of the ciphertext payload is verified based on the second authentication tag, and its validity is verified based on the timestamp and key sequence number. If both integrity and validity verifications pass, the shared key and its corresponding key sequence number are written into the first key resource pool. In this way, a secure shared key injection channel is established between the initiating terminal (HSM) and the QKD network node via a standard internet link, eliminating the need for the initiating terminal to deploy quantum transceiver equipment and effectively reducing terminal deployment costs.

[0034] In some embodiments, before the initiating terminal receives the ciphertext payload sent by the quantum key distribution network node through the first encrypted transmission channel, the method further includes: performing two-way certificate authentication between the initiating terminal and the quantum key distribution network node, and establishing the first encrypted transmission channel.

[0035] The initiating terminal and the quantum key distribution network node perform two-way certificate authentication and establish a first encrypted transmission channel. This includes: the initiating terminal using a pre-configured digital certificate to perform two-way certificate authentication with the quantum key distribution network node. If the two-way certificate authentication is successful, the initiating terminal and the quantum key distribution network node negotiate and determine a key suite, which includes an authentication encryption algorithm and a hash algorithm. The negotiated key suite is then used to establish an encrypted transmission channel, i.e., the first encrypted transmission channel.

[0036] The pre-installed digital certificate is an X.509 digital certificate with an EC P-256 elliptic curve signature. This pre-installed digital certificate is issued by the QKD service provider's CA (Certificate Authority).

[0037] Specifically, the initiating terminal's HSM and QKD network nodes perform an mTLS (Mutual Transport Layer Security) 1.3 handshake using an X.509 digital certificate with an EC P-256 elliptic curve signature. During the mTLS 1.3 handshake, both parties negotiate and determine a cipher suite: TLS_AES_256_GCM_SHA384. Here, AES_256 indicates the use of the AES (Advanced Encryption Standard) algorithm with a 256-bit key length, GCM (Galois / Counter Mode) indicates the authentication encryption mode, and SHA384 indicates the use of the SHA (Secure Hash Algorithm) with a 384-bit output length as the hash function. This cipher suite ensures that the computational security of the encrypted transmission channel is at least at the AES-256 level. After a successful handshake, an encrypted transmission session is established between the two parties. The session key for this session is independently managed by the TLS (Transport Layer Security) protocol layer and is cryptographically independent of the QKD shared key to be transmitted subsequently. This independence ensures that even if the TLS session key is compromised during transmission, the security of the QKD shared key will not be affected.

[0038] The QKD network node retrieves a shared key, denoted as K_QKD, generated by the QKD process, from its internal key pool. K_QKD is 256 bits long (32 bytes). The QKD network node uses the TLS session key established during the mutual certificate authentication process as the transmission encryption key and performs AES-256-GCM (Advanced Encryption Standard - 256bit - Galois / Counter Mode) encryption on K_QKD to generate a ciphertext payload. The ciphertext payload has the following data format: [16-byte Initialization Vector (IV)] + [32-byte encrypted K_QKD] + [16-byte GCM authentication tag] + [8-byte timestamp (UNIX second-level timestamp)] + [4-byte key sequence number]. The QKD network node sends this ciphertext payload to the initiating terminal's HSM through the established TLS encrypted channel, i.e., the first encrypted transmission channel. The 16-byte GCM authentication tag is the second authentication tag.

[0039] After receiving the encrypted payload, the HSM on the initiating terminal uses the TLS session key to perform AES-256-GCM decryption on the encrypted payload, and simultaneously verifies the 16-byte GCM authentication tag for integrity verification. If the integrity verification passes, the HSM further verifies the timestamp and key sequence number in the encrypted payload. Specifically, the HSM checks whether the key sequence number is greater than the key sequence number of the most recently successfully received encrypted payload in the history, and also checks whether the deviation between the timestamp and the HSM's local time is less than 300 seconds. If all verifications pass, the HSM writes the shared key K_QKD and the key sequence number into its tamper-proof secure storage area, i.e., the first key resource pool.

[0040] Optionally, if all verifications pass, the initiating terminal HSM writes the shared key K_QKD as the new seed key (SeedKey_new) into its tamper-proof secure storage area, overwriting the old seed key (SeedKey_old). To prevent key data corruption due to abnormal situations such as power outages during the writing process, the initiating terminal HSM adopts a dual-slot atomic write strategy, specifically: the initiating terminal HSM maintains two storage slots internally, namely a primary slot and a backup slot, each with independent storage space and a checksum register; when writing the new key, K_QKD is first written to the backup slot, and after the write is completed, the checksum of the backup slot is calculated; the calculated checksum is compared with the expected value, and if the verification passes, the primary slot pointer is atomically switched to the backup slot, making the backup slot the new currently valid primary slot. The old seed key (SeedKey_old) is retained until the next successful injection before being overwritten, ensuring that the normal consumption of the derived key is not affected. With the above dual-slot atomic writing strategy, even if a power failure occurs during the writing process, the initiating terminal HSM can still read the old valid seed key from the undamaged main slot after power-on, thus avoiding the entire system being unable to decrypt call data due to key corruption.

[0041] In some embodiments, 300 seconds before the current injection period expires (i.e., 5 minutes in advance), the initiating terminal HSM sends a pre-injection request to the QKD network node. This pre-injection request carries the remaining time information for the current injection period. Upon receiving the pre-injection request, the QKD network node performs a complete seed key injection operation. This pre-injection mechanism ensures that the new seed key has been successfully written to the HSM before the old seed key expires, achieving seamless handover between the old and new seed keys. If three consecutive injection attempts fail (including network timeout, authentication failure, integrity verification failure, or replay attack detection failure), the initiating terminal HSM triggers an interruption event and records the interruption log information. At this time, the initiating terminal HSM checks the current level of the first key resource pool, i.e., the percentage of remaining available session keys relative to the total capacity of the first key resource pool. If the first key resource pool level is below 25%, it enters the preparation state for PQC (Post-Quantum Cryptography) encryption mode, replacing QKD with the PQC algorithm as the security anchor to ensure that the encryption capability of subsequent video calls is not affected. In this way, the sending terminal HSM can reliably obtain fresh QKD seed keys at a preset injection period, and at the same time, trigger downgrade preparation in a timely manner when the QKD network fails, that is, prepare to switch to PQC encryption mode to ensure the continuous and secure operation of the system.

[0042] In some embodiments, the first key resource pool is managed as a FIFO (First In First Out) circular queue. The first key resource pool operates within the secure storage area of ​​the sender terminal's HSM, decoupling the periodicity of QKD shared key injection from the real-time nature of session key consumption. Thus, even if the QKD network is temporarily interrupted, the shared keys pre-stored in the first key resource pool can still support continuous call encryption, while providing a key buffer for PQC encryption mode downgrade switching.

[0043] The first key material pool uses a fixed-capacity FIFO circular queue as its underlying data structure. This circular queue occupies a contiguous physical address space in the HSM secure storage area, and its capacity N is configurable, ranging from 100 to 10000, for example, N=1000.

[0044] Each queue slot stores a shared key and its associated metadata. Specifically, each slot contains the following fields: shared key ciphertext (32 bytes, 256 bits of the shared key's ciphertext state, protected by the HSM's internal master key), timestamp (8 bytes, 64-bit UNIX millisecond-level timestamp, recording the key injection time), sequence number (8 bytes, 64-bit monotonically increasing sequence number, used for key lifecycle tracking and sorting), and status flag (1 byte, 8-bit status code: 0x00 indicates valid and ready to be consumed, 0xFF indicates consumed, and 0x01 indicates reserved).

[0045] HSM internally maintains two pointer variables to manage the read and write positions of the circular queue: The Head pointer points to the next available valid key slot for consumption. A consumption operation (i.e., retrieving a session key) reads the key from the position pointed to by the Head pointer, and after reading, the Head pointer moves one position forward. The Tail pointer points to the next available free slot for writing. A fill operation (i.e., generating and storing a new key) writes the key to the position pointed to by the Tail pointer, and after writing, the Tail pointer moves one position forward. The movement of the two pointers follows modulo N arithmetic: when a pointer points to the last slot in the queue (index N-1), the next movement will wrap around the pointer to the first slot in the queue (index 0), thus achieving cyclical use of the circular queue. The mathematical expression for pointer movement is: (current pointer value + 1) mod N.

[0046] The sending terminal HSM internally runs a background filling thread responsible for writing the received shared key to the Tail position of the circular queue. Before writing a new key, the filling thread first checks if the queue is full, i.e., it checks if the condition (Tail + 1) mod N != Head is true. If the queue is full, the filling thread enters a blocked waiting state until a consumption operation releases at least one slot; if the queue is not full, it performs the write operation. Before writing the new shared key to the slot, it is first encrypted using the HSM's internal master key to obtain a 32-byte key ciphertext. Subsequently, the key ciphertext, along with the current UNIX millisecond timestamp, the current monotonically increasing sequence number, and the valid status flag (0x00), is written to the slot pointed to by the Tail pointer. After writing is complete, the Tail pointer moves forward one position (wraps around modulo N), and the new key officially enters the consumable state. Optionally, whenever a consumption operation consumes a key, the filling thread immediately replenishes it with a new key to maintain a dynamic balance of the number of keys in the queue. Optionally, when the water level of the first key material pool drops below the warning level, the filling thread switches to full-speed filling mode and continues to fill at the maximum rate of HSM until the water level recovers to above the safe level.

[0047] When the sending terminal's application layer (i.e., the video call application) requests a session key through the HSM's API (Application Programming Interface), a consumption operation is triggered. The sending terminal's HSM first checks if the queue is empty, i.e., it checks if the condition Head != Tail is true. If the queue is empty (i.e., Head == Tail), the HSM blocks and waits for a filling thread to replenish the new key, with a maximum timeout of 100 milliseconds. If the timeout occurs, the HSM returns the error code ERR_KEYPOOL_EMPTY to the application layer, notifying the application layer to suspend new call requests. If the queue is not empty, the retrieval operation is performed. The HSM reads the key handle from the Head position and returns it. The slot's status flag is updated to "consumed," and the Head pointer moves forward one position.

[0048] The water level of the first key resource pool is obtained by calculating W_pool = ((Tail + N - Head) mod N) / N × 100%, which represents the percentage of the total capacity of the first key resource pool to the remaining available session keys. Here, W_pool is the water level of the first key resource pool, (Tail + N - Head) mod N represents the number of valid keys in the current queue, and N represents the total queue capacity. When W_pool ≥ the safety water level, the safety water level is the first set value, for example, 75%, indicating sufficient available keys in the key resource pool. HSM maintains an on-demand filling rate, i.e., one key is consumed and then replenished. When the warning water level ≤ W_pool < the safety water level, the warning water level is the second set value, for example, 25%, increasing the filling rate to 50% of the maximum rate. When W_pool < the warning water level, the filling rate is increased to the maximum rate, triggering entry into PQC encryption mode. The water level monitoring period is 100 milliseconds, with HSM sampling the current water level value every 100 milliseconds. Furthermore, a state change is only triggered when the water level is below the same threshold for three consecutive samples (i.e., for a duration of 300 milliseconds). Instantaneous fluctuations within a single sampling period do not cause state switching, thus ensuring system stability. Write permissions to the Head pointer are granted only to the consuming thread (i.e., the thread requesting the session key from the application layer). After each consumption operation, the consuming thread updates the Head pointer. Write permissions to the Tail pointer are granted only to the filling thread. After each filling operation, the filling thread updates the Tail pointer. This ensures that only one thread can modify the value of a pointer at any given time, fundamentally avoiding data races caused by multiple threads simultaneously writing to the same memory address.

[0049] Optionally, generating first confirmation information based on the first session key includes: the initiating terminal generating a call random number, encrypting the call random number using the first session key, and obtaining the encrypted call random number. The first confirmation information is generated using the key sequence number and the encrypted call random number, wherein the key sequence number corresponds to the first session key and is obtained from a preset first key resource pool.

[0050] The initiating terminal sends a first confirmation message to the receiving terminal. The receiving terminal extracts the key sequence number from the first confirmation message and uses it to locate and retrieve the corresponding shared key from its local second key resource pool, using it as the second session key. The receiving terminal uses this second session key to decrypt the encrypted call random number in the first confirmation message. It then increments the decrypted call random number by 1 to obtain the confirmation number. Finally, it uses the second session key to encrypt this confirmation number, generating a second confirmation message, which is then sent back to the sending terminal.

[0051] Optionally, the second confirmation information fed back by the receiving terminal is verified, including: the sending terminal decrypting the second confirmation information using the first session key; and if the decryption result is a confirmation number, then the verification of the second confirmation information is confirmed to be successful. That is, it is confirmed that the sending terminal and the receiving terminal have the same session key. Wherein, the confirmation number = call random number + 1.

[0052] Optionally, the audio and video data to be sent is encrypted using the first session key, including: upon successful verification of the second confirmation information, using the first session key and the packet sequence number of the audio and video data, performing an expansion operation using an agreed-upon key derivation function to generate an initialization vector for the audio and video data. Using the first session key and the initialization vector, the audio and video data is encrypted according to a preset encryption algorithm to generate an encrypted audio and video data packet. The encrypted audio and video data packet contains: the initialization vector, the ciphertext of the audio and video data, and the corresponding first authentication tag.

[0053] The packet sequence number of audio and video data is the packet sequence number in the RTP (Real-time Transport Protocol) audio and video data packet header, for example: packet_seq, a 32-bit unsigned integer with a value range of 0 to 4.29 billion. The agreed key derivation function is the HKDF-Expand function.

[0054] Optionally, based on the first session key and the packet sequence number of the audio / video data, an expansion operation is performed using an agreed-upon key derivation function to generate an initialization vector for the audio / video data. This includes: the initiating terminal using the first session key, SessionKey, as the PRK (Pseudo-Random Key), concatenating a preset string, such as "iv", with the packet sequence number as the context identifier info, and calling the HKDF-Expand function (HMAC-based Key Derivation Function Expand) to derive a 12-byte IV (Initialization Vector). Here, IV = HKDF-Expand(PRK = SessionKey, info = 'iv' || packet_seq, L = 12). Here, "||" represents a byte concatenation operation, and L represents the expected output byte length. Since the packet_seq of each RTP packet monotonically increases and is unique within the same session, the initialization vector IV obtained for each packet is also unique, fundamentally guaranteeing the uniqueness of the initialization vector IV.

[0055] When packet_seq reaches the maximum value of a 32-bit unsigned integer (i.e., 4.29 billion), the initiating terminal HSM automatically triggers the first session key rotation: it takes a new first session key SessionKey and resets the packet_seq counter to ensure that the IV never repeats.

[0056] Optionally, using the first session key and initialization vector, the audio and video data are encrypted according to a preset encryption algorithm to generate an encrypted audio and video data packet. This includes: the initiating terminal using the first session key and initialization vector IV to perform AES-256-GTM encryption on the audio and video data to be sent, obtaining ciphertext of the audio and video data and the corresponding first authentication tag. The initiating terminal combines the ciphertext of the audio and video data, the corresponding first authentication tag, and the initialization vector IV into the encrypted audio and video data packet. The length of the ciphertext of the audio and video data is the same as the plaintext. The first authentication tag is a GCM authentication tag, 128 bits (16 bytes), used by the receiving terminal to verify the integrity and authenticity of the data. The format of the encrypted audio and video data packet is: [12-byte plaintext initialization vector IV] + [ciphertext of audio and video data] + [16-byte GCM authentication tag]. That is, the initialization vector is appended in plaintext form before the ciphertext of the audio and video data and the first authentication tag.

[0057] The encrypted audio and video data packets include a 12-byte IV and a 16-byte authentication tag, resulting in a total overhead of 28 bytes. Taking a 4K video call scenario as an example: with a video bitrate of 25 Mbps and an RTP packet length of 1200 bytes, the encryption overhead accounts for approximately 2.3%. This overhead has a negligible impact on the bandwidth of home broadband (typically at the 100 Mbps or gigabit level).

[0058] In some embodiments, to achieve line-speed encryption and meet the real-time requirements of 4K video calls (end-to-end latency <200ms), the encryption engine runs entirely within the HSM hardware of the initiating terminal, employing DMA (Direct Memory Access) zero-copy technology. The application layer software (AP) running on the main CPU of the initiating terminal calls the HSM's encryption service via the PKCS#11 standard interface (Public-Key Cryptography Standards #11) when encryption of audio and video data is required. During the call, the application layer passes the Key Handle (a reference identifier pointing to the internal SessionKey storage location of the HSM), but not the plaintext key. The plaintext key is always stored within the security boundary of the HSM, and the main CPU cannot access it at any time. After receiving the encryption command, the DMA engine within the HSM directly reads the plaintext RTP payload to be encrypted from the output buffer of the audio / video encoder; this process does not require the main CPU to participate in data transfer. The plaintext data read by the DMA is then sent to the hardware encryption engine within the HSM. This hardware encryption engine supports the AES-NI instruction set (Advanced Encryption Standard New Instructions, for x86 architecture processors) or ARM Crypto Extensions (ARM architecture processors). The hardware encryption engine performs parallel encryption on 128-bit blocks (16 bytes per block) in CTR mode, while the GHASH engine computes GCM authentication tags in parallel on the GF(2^128) domain. The encryption and authentication processes are performed synchronously in the hardware pipeline. After encryption, the DMA engine directly writes the generated ciphertext and GCM authentication tags to the network transmit buffer for the network card driver to send to the peer. Throughout the encryption process, data transfer from the encoder buffer to the network transmit buffer achieves zero CPU copying; that is, the main CPU does not need to copy or move any data, only initiate encryption commands and receive completion interrupts. Through the above hardware acceleration mechanism, the measured single-stream encryption throughput of the HSM encryption engine in this embodiment can reach over 500Mbps, reserving sufficient computing power for the main CPU for other tasks such as video encoding and AI image enhancement. Furthermore, the hardware encryption engine internally implements a constant-time encryption path, ensuring that all branch operations are completed within a fixed period, eliminating timing-side channel leakage. Key materials are transmitted via a dedicated masked bus, and the signal levels on the bus are compensated by random masking to prevent electromagnetic radiation analysis attacks.

[0059] In some embodiments, the sending terminal sends encrypted audio and video data packets to the receiving terminal. The receiving terminal verifies the received encrypted audio and video data packets based on a first authentication tag; if the verification is successful, it uses a second session key and an initialization vector to decrypt the ciphertext of the audio and video data according to a preset decryption algorithm to obtain the decrypted audio and video data, and then displays the decrypted audio and video data.

[0060] Optionally, after sending the encrypted audio and video data packets to the receiving terminal, the process further includes: detecting the level of the first key resource pool and the success rate of shared key injection. If the level of the first key resource pool and the success rate of shared key injection meet a first preset condition, the sending terminal sends a PQC capability declaration message to the receiving terminal. Upon receiving the PQC capability declaration message, the receiving terminal returns a PQC capability confirmation message to the sending terminal. The PQC capability confirmation message includes the target PQC algorithm identifier, enabling both parties to complete algorithm negotiation. If the level of the first key resource pool meets a second preset condition, the PQC encryption mode is executed.

[0061] The first preset condition is that the water level in the first key resource pool is <25%, and the success rate of shared key injection is <50%. The second preset condition is that the water level in the first key resource pool is <5%.

[0062] The format of a PQC capability declaration message is [Message Type=0x01 || List of supported algorithms (sorted by priority) || Algorithm parameters (e.g., Kyber-768 / 1024 security level) || Local random number Nonce_A]. The format of a PQC capability confirmation message is [Message Type=0x02 || Selected target PQC algorithm identifier (2-byte algorithm ID) || Peer random number Nonce_B || DILITHIUM_SIGN (Peer private key, message digest)]. The target PQC algorithm is the algorithm agreed upon by both parties.

[0063] Optionally, the PQC encryption mode includes: the initiating terminal calls `Kyber.CCAKEM.Encaps(pk_peer)` to generate a shared key `ss` and ciphertext `ct`, and sends the ciphertext `ct` to the receiving terminal. The receiving terminal calls `Kyber.CCAKEM.Decaps(sk_self, ct)` to recover the same shared key `ss`. Both parties use the shared key `ss` as a temporary session key to generate a session key chain in PQC mode. The first key resource pool includes a main buffer pool and a backup buffer pool. The main buffer pool continues to provide the QKD mode session key for the currently ongoing video call. The sending terminal writes the temporary session key in PQC encryption mode into the backup buffer pool of the first key resource pool and fills it at the maximum rate. Filling is complete when the water level in the backup buffer pool is ≥75%. When the backup buffer pool is filled, the HSM swaps the pointers of the main buffer pool and the backup buffer pool, and the original backup buffer pool becomes the new main buffer pool for subsequent video call consumption.

[0064] The ongoing audio and video call continues to be encrypted using the QKD mode session key retrieved from the primary buffer pool before the handover, until the call terminates naturally. Only new calls initiated after the handover will use the PQC mode session key from the new primary buffer pool (i.e., the original backup buffer pool). Therefore, during the handover process, the audio and video RTP (Real-time Transport Protocol) streams continue to be encrypted using the session key from before the handover, ensuring uninterrupted video calls and a seamless user experience. This guarantees a superior video call experience for the user.

[0065] In some embodiments, when the video call involves a group call with three or more parties, the initiating terminal HSM uses its internal TRNG to generate a 128-bit (16-byte) random group identifier, denoted as groupID, which is in UUID format version 4. The initiating terminal HSM constructs an info context identifier using the currently valid rotation key RotationKey as the PRK (Pseudo-Random Key): info = 'group' || groupID || timestamp. Here, 'group' is a fixed string (5-byte ASCII code) used to identify that the key is for group calls; groupID is the 128-bit random group identifier generated by the initiating terminal; and timestamp is the UNIX millisecond-level timestamp when the group call was established. The initiating HSM calls the HKDF-Expand function, using RotationKey as the PRK and the aforementioned info as the context identifier, to derive the group session key: GroupSessionKey = HKDF-Expand(PRK = RotationKey, info = 'group' || groupID || timestamp, L = 256). Obtain a 256-bit (32-byte) group session key.

[0066] The initiating terminal and each group member first perform a point-to-point, one-to-one key confirmation handshake. This establishes an end-to-end encrypted secure channel between the initiating terminal and each group member, with each holding a paired session key (PairSessionKey_i) corresponding to the i-th group member. This PairSessionKey_i is used only for point-to-point communication between the initiating terminal and the i-th group member. The initiating terminal's HSM uses PairSessionKey_i to encrypt the GroupSessionKey, obtaining the encrypted payload. The initiating terminal then sends this encrypted payload to the i-th group member via the signaling channel. Upon receiving the encrypted payload, the i-th group member's HSM decrypts it using its locally held PairSessionKey_i, obtaining the plaintext GroupSessionKey. The i-th group member then uses the decrypted GroupSessionKey to encrypt and decrypt the RTP (Real-time Transport Protocol) audio and video streams of the group call. At this point, the i-th group member officially joins the group call.

[0067] When a new member requests to join a group call, or when an existing member leaves the group call, the initiating terminal HSM derives a new group session key, GroupSessionKey_new. The initiating terminal HSM distributes the new GroupSessionKey_new to all existing group members. Upon receiving the new key, all existing group members switch to using the new GroupSessionKey_new for encrypting and decrypting subsequent media streams. The old GroupSessionKey_old is immediately marked as "pending destruction" and is securely erased after all existing group members confirm that they have received and enabled the new key. Thus, newly joined group members only receive GroupSessionKey_new and cannot decrypt historical call content encrypted using GroupSessionKey_old before joining. Leaving group members only possess the old GroupSessionKey_old and cannot decrypt call content encrypted using GroupSessionKey_new after leaving.

[0068] In a group call with M group members, where M≥3, the distribution operations of each group member in the initiating terminal's HSM can be executed in parallel, and the total latency is determined by the slowest single-member distribution latency. With sufficient HSM key derivation capability, such as greater than 1000 times / second, the total latency for key distribution in a group call with M=20 is <50ms.

[0069] In some embodiments, the sending terminal HSM reads the first-ranked shared key from the first key resource pool and uses it as the seed key. A root key is derived from the seed key. A rotation key is derived from the root key. A session key is derived from the rotation key.

[0070] The root key is derived from the seed key, as follows: RootKey = HKDF-Extract(salt = HSM_UID, IKM = SeedKey). Here, Salt is the salt value, using the hardware unique identifier HSM_UID fixed at the HSM chip's factory, with a length of 128 bits (16 bytes). IKM is the input key material, using the shared key written to the HSM via a secure injection channel through a QKD network as the seed key, with a length of 256 bits (32 bytes). The output of the HKDF-Extract function is a 256-bit (32-byte) PRK (Pseudo-Random Key), which is the root key RootKey. RootKey is a long-term key, only regenerated during HSM factory initialization, secure reset, or seed key update, and does not participate in daily key rotation.

[0071] The rotation key is derived from the root key, as follows: RotationKey = HKDF-Expand(PRK = RootKey, info = 'rotation' || date_str, L = 256). Here, PRK is the root key (256 bits). The info context identifier is formed by concatenating the fixed string "rotation" (6 bytes of ASCII code) with the date string date_str (8 bytes of ASCII code) in sequence. The date_str format is "YYYYMMDD", for example, "20260719" represents July 19, 2026. This date is calculated in UTC+8 Beijing time and is automatically updated at midnight every day. L represents the expected output key length; L=256, meaning a 256-bit (32-byte) rotation key is output. The underlying pseudo-random function of the HKDF-Expand function is also HMAC-SHA256, outputting a fixed 256-bit rotation key with each call. The old rotation key is retained for 24 hours after rotation (to support decryption of incomplete calls across midnight) and then securely erased. The forward security window for rotating keys is 1 day.

[0072] The session key is derived from the rotation key, including: SessionKey = HKDF-Expand(PRK = RotationKey, info ='session' || sessionID || timestamp, L = 256). Here, PRK is the currently valid rotation key RotationKey (256 bits). The info context identifier is a concatenation of the fixed string "session" (7-byte ASCII code), the session identifier sessionID (16 bytes), and the timestamp (8 bytes) in sequence. The sessionID is a 128-bit random UUID (Universally Unique Identifier) ​​generated by the call initiator's HSM, version 4 (based on random number generation), ensuring global uniqueness. The timestamp is the UNIX millisecond-level timestamp (8-byte big-endian) at the time the call was established, for example, "1721376000000" represents a certain time on July 19, 2026. L is the expected output key length, L=256, meaning a 256-bit (32-byte) session key is output. The underlying pseudo-random function of the HKDF-Expand function is also HMAC-SHA256, which outputs a fixed 256-bit session key each time it is called.

[0073] Each time a new call is established, HSM executes an independent HKDF-Expand call to generate a SessionKey specific to that call. Because the combination of sessionID and timestamp is unique for different calls (sessionID is globally unique, and the same device will not initiate two calls within the same millisecond), the SessionKeys derived from different calls are cryptographically completely independent.

[0074] When the call ends, the HSM performs a secure erase procedure: first, it overwrites the SessionKey storage area with all zeros, and then calls a hardware reset instruction to ensure that no key remains in the register.

[0075] Even if an attacker obtains the current rotation key (RotationKey_current), they cannot deduce the previous rotation key (RotationKey_previous). This ensures that historical call content cannot be decrypted due to the leakage of the current key. Similarly, even if an attacker obtains the current session key (SessionKey_current), they cannot deduce the future session key (SessionKey_future). This ensures that the leakage of the current key will not affect the security of future calls. The SessionKey for call A and the SessionKey for call B are cryptographically independent; even if an attacker obtains the SessionKey for call A, they cannot deduce the SessionKey for call B.

[0076] Using the seed key injected through the QKD network as the root of trust, various keys are generated through a three-level progressive derivation process for different levels, periods, and calls. Each level of derivation uses a different info context identifier to ensure that the keys at different levels are cryptographically independent. Even if the key at one level is compromised, the attacker cannot deduce the parent key from the subkey, nor can they deduce other keys of the same level from the same key.

[0077] The method for encrypting video calls provided in this disclosure is applied to a receiving terminal. The receiving terminal includes smart TVs, smartphones, tablets, or video conferencing terminals, etc.

[0078] Combination Figure 2 As shown, this disclosure provides a method for encrypting video calls, including: In step S201, upon receiving call request information from the signaling server, the receiving terminal authenticates the initiating terminal based on the call request information. The call request information includes the initiating terminal's digital certificate and a list of PQC algorithms supported by the initiating terminal. The initiating terminal's digital certificate is an X.509 certificate with an EC P-256 signature. The receiving terminal verifies the legitimacy of the initiating terminal's identity based on this X.509 certificate. That is, if the X.509 certificate is issued by a trusted CA (Certificate Authority) and has not been tampered with, the authentication of the initiating terminal is deemed successful.

[0079] In step S202, if the authentication is successful, the receiving terminal sends a response message to the sending terminal via the signaling server, triggering the sending terminal to return first confirmation information. The first confirmation information includes a key sequence number and a random number encrypted using the first session key. The key sequence number corresponds to the first session key.

[0080] The receiving terminal authenticates the initiating terminal using its digital certificate. If authentication is successful, the receiving terminal returns a response message to the signaling server. This response message includes the receiving terminal's digital certificate and a list of PQC algorithms supported by the receiving terminal.

[0081] In step S203, the receiving terminal receives the first confirmation information sent by the sending terminal and retrieves the second session key from the preset second key material pool according to the key sequence number. The second key material pool stores shared keys pre-injected by the quantum key distribution network.

[0082] The receiving terminal locates the shared key in its local second key resource pool based on the key serial number, retrieves the shared key, and designates it as the second session key. This second session key corresponds to the key serial number, and the first session key is the same as the second session key.

[0083] In step S204, the receiving terminal generates a second confirmation message based on the second session key and the encrypted call random number, and sends the second confirmation message to the sending terminal, triggering the initiating terminal to verify the second confirmation message.

[0084] In step S205, the receiving terminal receives the encrypted audio and video data packets sent by the sending terminal and decrypts the received encrypted audio and video data packets using the second session key.

[0085] The method for encrypting video calls provided in this disclosure involves periodically injecting a shared key into a second key resource pool on the receiving terminal's local machine via a quantum key distribution (QKD) network. The receiving terminal only needs to retrieve the shared key from the second key resource pool according to the key sequence number and use it as the session key to confirm the session with the sending terminal and encrypt audio and video data. Thus, the session key originates from the information-theoretic secure key of the QKD process, and its security is based on the no-cloning theorem and the measurement collapse principle of quantum mechanics, independent of the attacker's computational power. Even if future quantum computers break through the classical public-key cryptography system, they will not be able to crack the encrypted historical call content, effectively improving the security of video call data. Furthermore, it eliminates the need to deploy quantum transceiver equipment locally on the transceiver terminals, effectively reducing terminal deployment costs.

[0086] Optionally, the shared key stored in the second key resource pool is injected as follows: According to a preset injection period, the receiver receives a ciphertext payload sent by a quantum key distribution network node through a second encrypted transmission channel. The ciphertext payload includes the encrypted shared key, a second authentication tag, a timestamp, and a key sequence number. The second encrypted transmission channel is the transmission channel between the receiving terminal and the quantum key distribution network node. The integrity of the ciphertext payload is verified based on the second authentication tag, and its validity is verified based on the timestamp and key sequence number. If both integrity and validity verifications pass, the shared key and its corresponding key sequence number are written into the second key resource pool.

[0087] In some embodiments, before the receiving terminal receives the ciphertext payload sent by the quantum key distribution network node through the second encrypted transmission channel, the method further includes: performing two-way certificate authentication between the receiving terminal and the quantum key distribution network node, and establishing the second encrypted transmission channel.

[0088] The injection method for the shared key in the second key material pool is the same as that for the first key material pool, and will not be repeated here.

[0089] Optionally, generating the second confirmation information based on the second session key and the encrypted call random number includes: decrypting the encrypted call random number using the second session key; generating a confirmation number based on the decrypted call random number; and encrypting the confirmation number using the second session key to generate the second confirmation information.

[0090] In some embodiments, the confirmation number = the decrypted call random number + 1.

[0091] Optionally, the encrypted audio and video data packet includes an initialization vector, ciphertext of the audio and video data, and a corresponding first authentication tag. Decrypting the received encrypted audio and video data packet using the second session key includes: verifying the received encrypted audio and video data packet based on the first authentication tag. If the verification is successful, the ciphertext of the audio and video data is decrypted using the second session key and the initialization vector according to a preset decryption algorithm to obtain and output the decrypted audio and video data.

[0092] In some embodiments, the receiving terminal's HSM sequentially extracts a 12-byte initialization vector (IV), the ciphertext of the audio / video data to be decrypted, and a 16-byte GCM authentication tag from the received encrypted audio / video data packet. The receiving terminal's HSM uses the second session key (SessionKey) and the packet sequence number (packet_seq) in the header of the encrypted audio / video data packet to derive the decryption IV according to the same HKDF-Expand formula as the sending terminal. Since both parties share the same session key (SessionKey) and packet sequence number (packet_seq), the derived IV is identical to the IV used by the sending terminal during encryption. The receiving terminal's HSM recalculates a GCM tag for the ciphertext of the audio / video data using the second session key (SessionKey) and the initialization vector (IV), and compares the calculated result with the GCM authentication tag carried in the data packet, i.e., the first authentication tag. If the comparison result is the same, the verification is successful. If the verification is successful, the ciphertext of the audio / video data is decrypted using AES-CTR using the second session key (SessionKey) and the initialization vector (IV), and the restored plaintext audio / video data is output. By employing a security mechanism of verification before decryption, it ensures that every frame of audio and video data received by the decoder is legitimate data that has undergone integrity verification, thus eliminating security risks such as screen distortion and decoder crashes caused by data tampering at the source.

[0093] In some embodiments, when the initiating terminal or the receiving terminal decides to end the call, the terminal sends a BYE request to the other end through a signaling server. Upon receiving the BYE request, the other terminal returns a 200 OK response to confirm the termination of the call.

[0094] In the event of a call termination, both terminals' HSMs perform a session key destruction operation. The session key destruction operation includes: zero-overwrite and hardware register reset. All derived keys of the SessionKey are destroyed synchronously.

[0095] Before performing the key destruction operation, HSM decrypts the uncracked audio and video data packets to ensure that residual packets in the network can be processed normally.

[0096] Combination Figure 3As shown in the embodiments of this disclosure, another method for encrypting video calls is provided, including: Step S301: The initiating terminal sends a call request message to the signaling server.

[0097] In step S302, the signaling server receives the call request information and authenticates the initiating terminal based on the call request information.

[0098] In step S303, if the authentication is successful, the signaling server sends the call request information to the receiving terminal.

[0099] Step S304: The receiving terminal receives the call request information and authenticates the initiating terminal based on the call request information.

[0100] In step S305, if the authentication is successful, the receiving terminal returns a response message to the signaling server.

[0101] In step S306, the signaling server receives the response message and sends the response message to the initiating terminal.

[0102] In step S307, the initiating terminal receives the response message, obtains the first session key from the preset first key material pool, generates a call random number, encrypts the call random number using the first session key, obtains the encrypted call random number, and generates a first confirmation message using the key sequence number and the encrypted call random number. The first key material pool stores shared keys pre-injected by the quantum key distribution network. The key sequence number corresponds to the first session key and is obtained from the preset first key material pool.

[0103] In step S308, the initiating terminal sends a first confirmation message to the receiving terminal.

[0104] In step S309, the receiving terminal obtains the second session key from the preset second key material pool according to the key sequence number in the first confirmation information, decrypts the encrypted call random number using the second session key, generates a confirmation number based on the decrypted call random number, encrypts the confirmation number using the second session key, and generates the second confirmation information.

[0105] In step S310, the receiving terminal sends a second confirmation message to the initiating terminal.

[0106] In step S311, the initiating terminal verifies the second confirmation information fed back by the receiving terminal. If the verification is successful, the initiating terminal uses the first session key to encrypt the audio and video data to be sent, thereby obtaining the encrypted audio and video data packet.

[0107] In step S312, the initiating terminal sends the encrypted audio and video data packets to the receiving terminal.

[0108] In step S313, the receiving terminal receives the encrypted audio and video data packet sent by the sending terminal, and uses the second session key to decrypt the received encrypted audio and video data packet to obtain the plaintext audio and video data.

[0109] Combination Figure 4 As shown, this disclosure provides an apparatus 400 for video call encryption, including a first processor 404 and a first memory 401 storing program instructions. Optionally, the apparatus may further include a first communication interface 402 and a first bus 403. The first processor 404, the first communication interface 402, and the first memory 401 can communicate with each other via the first bus 403. The first communication interface 402 can be used for information transmission. The first processor 404 can call the program instructions in the first memory 401 to execute the video call encryption method described in the above embodiment.

[0110] Furthermore, the logic instructions in the first memory 401 described above can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0111] The first memory 401, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The first processor 404 executes functional applications and data processing by running the program instructions / modules stored in the first memory 401, that is, it implements the method for video call encryption in the above embodiments.

[0112] The first memory 401 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the first memory 401 may include high-speed random access memory and may also include non-volatile memory.

[0113] Combination Figure 5As shown, this disclosure provides an apparatus 500 for video call encryption, including a second processor 504 and a second memory 501 storing program instructions. Optionally, the apparatus may further include a second communication interface 502 and a second bus 503. The second processor 504, the second communication interface 502, and the second memory 501 can communicate with each other via the second bus 503. The second communication interface 502 can be used for information transmission. The second processor 504 can call the program instructions in the second memory 501 to execute the video call encryption method described in the above embodiment.

[0114] Furthermore, the logic instructions in the aforementioned second memory 501 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0115] The second memory 501, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The second processor 504 executes functional applications and data processing by running the program instructions / modules stored in the second memory 501, that is, it implements the method for video call encryption in the above embodiments.

[0116] The second memory 501 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the second memory 501 may include high-speed random access memory and may also include non-volatile memory.

[0117] Combination Figure 6 As shown, this disclosure provides an initiating terminal, such as a smart TV 600. The initiating terminal includes an initiating terminal body and the aforementioned video call encryption device 400. The video call encryption device 400 is installed in the initiating terminal body. The installation relationship described herein is not limited to placement within the initiating terminal, but also includes installation connections with other components of the initiating terminal, including but not limited to physical connections, electrical connections, or signal transmission connections. Those skilled in the art will understand that the video call encryption device 400 can be adapted to any feasible initiating terminal body to achieve other feasible embodiments.

[0118] Combination Figure 7As shown, this disclosure provides a receiving terminal, such as a smart TV 700. The receiving terminal includes a receiving terminal body and the aforementioned video call encryption device 500. The video call encryption device 500 is installed in the receiving terminal body. The installation relationship described herein is not limited to placement inside the receiving terminal, but also includes installation connections with other components of the receiving terminal, including but not limited to physical connections, electrical connections, or signal transmission connections. Those skilled in the art will understand that the video call encryption device 500 can be adapted to any suitable receiving terminal body to achieve other feasible embodiments.

[0119] The technical solutions of this disclosure can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes one or more instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in this disclosure. The aforementioned storage medium can be a non-transitory storage medium, including: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and other media capable of storing program code; it can also be a transient storage medium.

[0120] The foregoing description and accompanying drawings fully illustrate embodiments of this disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, procedural, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. Moreover, the terminology used in this application is for describing embodiments only and is not intended to limit the claims. As used in the description of embodiments and claims, the singular forms “a,” “an,” and “the” are intended to equally include the plural forms unless the context clearly indicates otherwise. Similarly, the term “and / or” as used in this application means including one or more of the associated listed items and all possible combinations thereof. Additionally, when used in this application, the term "comprise" and its variations "comprises" and / or "comprising" refer to the presence of stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Without further limitations, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, or apparatus that includes said element. In this document, each embodiment may focus on the differences from other embodiments, and similar or identical parts between embodiments can be referred to mutually. For methods, products, etc., disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, the relevant parts can be referred to the description of the method section.

[0121] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this disclosure. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0122] The methods and products disclosed in the embodiments herein (including but not limited to devices and equipment) can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units may be merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to implement this embodiment according to actual needs. In addition, the functional units in the embodiments of this disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0123] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different blocks may also occur in a different order than disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. Each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

Claims

1. A method for encrypting video calls, characterized in that, Applied to the initiating terminal, the method includes: Sending a call request message to the signaling server triggers the signaling server to authenticate the initiating terminal. If the authentication is successful, the call request message is forwarded to the receiving terminal, which then triggers the receiving terminal to authenticate the initiating terminal and return a response message. Upon receiving a response message from the receiving terminal, a first session key is obtained from a preset first key material pool, and a first confirmation message is generated based on the first session key; the first key material pool stores a shared key pre-injected by the quantum key distribution network; Send the first confirmation information to the receiving terminal, triggering the receiving terminal to obtain the second session key based on the first confirmation information, generate the second confirmation information based on the second session key, and feed back the second confirmation information; The second confirmation information fed back by the receiving terminal is verified. If the verification is successful, the audio and video data to be sent is encrypted using the first session key to obtain the encrypted audio and video data packet. The encrypted audio and video data packets are sent to the receiving terminal.

2. The method according to claim 1, characterized in that, The shared key stored in the first key resource pool is injected in the following way: According to a preset injection period, the encrypted payload sent by the quantum key distribution network node is received through the first encrypted transmission channel. The encrypted payload includes an encrypted shared key, a second authentication tag, a timestamp, and a key sequence number. The first encrypted transmission channel is the transmission channel between the sending terminal and the quantum key distribution network node. The integrity of the encrypted payload is verified based on the second authentication tag, and the validity of the encrypted payload is verified based on the timestamp and the key sequence number. If both the integrity verification and the validity verification pass, the shared key and the corresponding key sequence number are written into the first key material pool.

3. The method according to claim 1, characterized in that, Generate first confirmation information based on the first session key, including: Generate a random number for the call, and encrypt the random number for the call using the first session key to obtain the encrypted random number for the call; The first confirmation message is generated by combining the key serial number and the encrypted call random number. The key serial number corresponds to the first session key and is obtained from a preset first key material pool.

4. The method according to claim 1, characterized in that, Encrypting the audio and video data to be sent using the first session key includes: If the second confirmation information is verified, an initialization vector for the audio and video data is generated by performing an expansion operation using a key derivation function based on the first session key and the packet sequence number of the audio and video data. Using the first session key and the initialization vector, the audio and video data are encrypted according to a preset encryption algorithm to generate an encrypted audio and video data packet; the encrypted audio and video data packet includes: the initialization vector, the ciphertext of the audio and video data, and the corresponding first authentication tag.

5. A method for encrypting video calls, characterized in that, Applied to a receiving terminal, the method includes: Upon receiving a call request information from the signaling server, the initiating terminal is authenticated based on the call request information. Upon successful authentication, the signaling server sends a response message to the sending terminal, triggering the sending terminal to return first confirmation information. The first confirmation information includes a key sequence number and a random number for the call encrypted using a first session key. The key sequence number corresponds to the first session key. The system receives a first confirmation message from the sending terminal and retrieves a second session key from a preset second key material pool based on the key sequence number; the second key material pool stores a shared key pre-injected by the quantum key distribution network. A second confirmation message is generated based on the second session key and the encrypted call random number, and the second confirmation message is sent to the sending terminal, triggering the initiating terminal to verify the second confirmation message; The system receives encrypted audio and video data packets sent by the sending terminal and decrypts the received encrypted audio and video data packets using the second session key.

6. The method according to claim 5, characterized in that, The shared key stored in the second key resource pool is injected in the following way: According to a preset injection period, the receiver receives the ciphertext payload sent by the quantum key distribution network node through the second encrypted transmission channel. The ciphertext payload includes an encrypted shared key, a second authentication tag, a timestamp, and a key sequence number. The second encrypted transmission channel is the transmission channel between the receiver terminal and the quantum key distribution network node. The integrity of the encrypted payload is verified based on the second authentication tag, and the validity of the encrypted payload is verified based on the timestamp and the key sequence number. If both the integrity verification and the validity verification pass, the shared key and the corresponding key sequence number are written into the second key material pool.

7. The method according to claim 5, characterized in that, A second confirmation message is generated based on the second session key and the encrypted call random number, including: The encrypted call random number is decrypted using the second session key; A confirmation number is generated based on the decrypted call random number; The confirmation number is encrypted using the second session key to generate a second confirmation message.

8. The method according to claim 5, characterized in that, The encrypted audio and video data packets contain an initialization vector, ciphertext of the audio and video data, and a corresponding first authentication tag; The received encrypted audio and video data packets are decrypted using the second session key, including: The received encrypted audio and video data packets are verified based on the first authentication tag; If the verification is successful, the second session key and the initialization vector are used to decrypt the ciphertext of the audio and video data according to the preset decryption algorithm, and the decrypted audio and video data is obtained and output.

9. An apparatus for encrypting video calls, comprising a first processor and a first memory storing program instructions, characterized in that, The first processor is configured to execute, when running the program instructions, the method for video call encryption as described in any one of claims 1 to 4.

10. An apparatus for encrypting video calls, comprising a second processor and a second memory storing program instructions, characterized in that, The second processor is configured to execute, when running the program instructions, the method for video call encryption as described in any one of claims 5 to 8.

11. An initiating terminal, characterized in that, include: The initiating terminal itself; The device for encrypting video calls as described in claim 9 is installed on the initiating terminal body.

12. A receiving terminal, characterized in that, include: The receiving terminal itself; The device for encrypting video calls as described in claim 10 is installed on the receiving party's body.

Images