Forward and backward secure audio and video communication system and communication method based on dynamic key updating

Abstract

The invention discloses a forward and backward secure audio and video communication system and method based on dynamic key updating. The system comprises a client and a server. The client is responsible for interacting with a user, completing end-to-end encryption and key dynamic updating functions of data communication, and providing protection for audio and video communication data; the server side is responsible for user identity authentication, certificate issuing management, friend group chat relationship maintenance and audio and video streaming media data forwarding; the method comprises the following steps: a user registers an account, establishes a video room and invites the user to initiate an audio and video call, and the room user quits at any time and initiates key update actively in the whole call process; according to the method, the data security of audio and video communication of a user is ensured through end-to-end encryption, and meanwhile, a key version management mechanism is adopted, so that when the user joins in or leaves a conference, a video initiator (Host) can issue a new key version and automatically switch to a new key after a certain time, and the synchronization and security of key updating are ensured; the method supports forward security and backward security, even if a certain key version is leaked, an attacker still cannot decrypt historical or future communication content, and the method has a wide market application prospect.

Description

Technical Field

[0001] The present invention belongs to the technical field of audio and video communications, and in particular relates to a forward and backward secure audio and video communication system and a communication method based on dynamic key updating. Background Art

[0002] Traditional audio and video communication systems typically use DTLS-SRTP encrypted channels to secure data transmission. However, DTLS-SRTP only protects data during transmission and cannot prevent attacks on data stored on the server or client. Users are increasingly demanding privacy protection for their communications. However, existing audio and video encryption schemes are often complex to deploy, computationally expensive, or lack security, hindering widespread adoption in high-concurrency, multi-user communication environments. This makes audio and video communication systems a weak link in security protection. Furthermore, password-based authentication methods present significant security risks. Passwords are typically complex and easily cracked through brute force. Furthermore, passwords can be stolen during transmission, further reducing system security. In end-to-end encryption (E2EE) systems, communication data is encrypted at the sender and can only be decrypted by the receiver. This approach effectively prevents server-side attacks. However, existing end-to-end encryption schemes (such as the Signal protocol) are mostly based on the double ratchet algorithm. While this algorithm provides strong forward and backward security, it requires maintaining a large amount of KDF chains and certificate information for group chats, limiting the scalability of group chats.

[0003] Current audio and video encryption technologies primarily utilize the following schemes. Fixed session key schemes (such as WebRTC's SRTP) negotiate a key at the start of a session and maintain it throughout the session. However, this approach presents significant security issues. Once the key is compromised, all communications can be decrypted by an attacker. Furthermore, some end-to-end encryption schemes (such as the Signal protocol) employ a double ratchet algorithm, updating the key each time a message is sent to provide forward and backward security. While this algorithm provides forward and backward security, it requires maintaining a large amount of KDF chains and certificate information for group chats, limiting their scalability. Another common approach is centralized key management, such as Zoom's GCM encryption method, which distributes keys from the server. However, this scheme relies on the server for security. If the server is compromised, all user keys could be compromised, and forward and backward security are not guaranteed.

[0004] In summary, the shortcomings of the prior art are as follows:

[0005] ① The traditional fixed key scheme has low security. Once the key is leaked, the communication content of the entire session may be decrypted.

[0006] ② Although some end-to-end encryption schemes provide strong forward and backward security, they require maintaining a large amount of KDF chains and certificate information for group chats, which limits the scale of group chats. At the same time, the high computational complexity consumes a lot of computing resources.

[0007] ③ Some end-to-end encryption uses centralized key management and relies on the security of the server. Once the server is attacked, all users' keys may be leaked, and there is no guarantee of forward and backward security. Summary of the Invention

[0008] In order to overcome the problems existing in the above-mentioned prior art, the purpose of the present invention is to disclose a forward and backward secure audio and video communication system and communication method based on dynamic key update, which ensures the data security of user audio and video communications through end-to-end encryption, and adopts a key version management mechanism to ensure that when a user joins or leaves a meeting, the video initiator (Host) can issue a new key version and automatically switch to the new key after a certain period of time to ensure the synchronization and security of key updates; the method supports forward security and backward security, even if a key version is leaked, the attacker still cannot decrypt historical or future communication content; the key update process is completely transparent to the user, does not affect the smoothness of audio and video communications, ensures a balance between security and real-time performance, supports efficient key updates in multi-user environments, and improves the key management efficiency in multi-person communication environments; it is suitable for multiple high-security demand scenarios such as remote office, online education, medical consultation, etc., and can provide safe, convenient and reliable audio and video communication protection services for various organizations, and has broad market application prospects.

[0009] In order to achieve the above object, the present invention adopts the following technical solutions:

[0010] A forward and backward secure audio and video communication system based on dynamic key update, comprising a client and a server;

[0011] The client is responsible for interacting with users, completing end-to-end encryption of data communications and dynamic key updates, and providing protection for audio and video communication data. It includes a functional UI for user login, group chat management, and video calls, and is responsible for interacting with users and displaying functions. The key management module (KMM) is responsible for key version management and dynamic updates. The data protection module encrypts and decrypts data including text, audio, and video data.

[0012] The server side is responsible for user identity authentication, certificate issuance and management, friend group chat relationship maintenance, and forwarding of audio and video streaming media data, including business servers, CA servers, and SFU streaming media servers; the SFU streaming media server is responsible for forwarding audio and video streaming media data; the business server is responsible for specific services including user registration, key update request forwarding processing, and providing a unified interface to the outside world to realize user access to the SFU streaming media server; the CA server is independent of the business server and SFU streaming media server, and has a built-in email verification service. It can be directly accessed by users and business servers, and is responsible for issuing and managing user certificates and maintaining the Certificate Revocation List (CRL).

[0013] The encryption certificate and signature certificate of the CA server are built into the client, and can be obtained by requesting the CA server when they are missing.

[0014] A forward and backward secure audio and video communication method based on dynamic key update, the specific steps are as follows:

[0015] Step 1. The user completes account registration;

[0016] Step 2: After completing account registration, users can create video rooms, initiate audio and video calls, and invite other users to participate in audio and video communications;

[0017] Step 3: The room user exits the audio and video communication.

[0018] The specific method of step 1 is:

[0019] 1.1 User registration requests the CA server to send a verification code email through the client. After receiving the verification code, the client generates a temporary session key, namely the SM4 symmetric key, as well as the SM2 public-private key pair of the signing certificate and the SM2 public-private key pair of the encryption certificate locally. Then, the email address, verification code, SM2 public key of the encryption certificate to be applied for, and SM2 public key of the signing certificate are organized into a dictionary object according to the JSON specification and then converted into a JSON string. It is encrypted with the SM2 public key of the encryption certificate of the CA server and submitted to the CA server; the CA server uses the private key of the encryption certificate to decrypt the information contained in the registration request and verify whether the verification code in the request is consistent with the verification code sent. If the verification is successful, the SM2 public key of the encryption certificate and the SM2 public key of the signing certificate are issued, generating encryptionCrt and signingCrt, which are encrypted with the temporary session key and returned to the client;

[0020] 1.2 The client submits a registration request to the business server. The information includes the email address, encryption certificate, signature certificate, hash value of the verification code, hash value of the password and account name. It is encrypted with the public key of the business server and signed with the signature certificate. After verifying the integrity of the registration request, the business server decrypts and verifies the signature and requests certificate binding from the CA server. The certificate binding information includes the email address, encryption certificate, signature certificate and hash value of the verification code. The certificate binding information is also encrypted with the SM2 public key of the encryption certificate of the CA server and signed with the SM2 public key of the signature certificate to ensure security. The CA server decrypts and verifies the integrity of the certificate binding request, verifies the binding relationship of the verification code, email address, encryption certificate and signature certificate. If the verification is successful, the email address, encryption certificate and signature certificate are stored in the local certificate database and a certificate binding success message is returned to the business server. Otherwise, a certificate binding failure message is returned to the business server.

[0021] 1.3 After the business server receives the return information from the CA server, if the return information shows that the certificate binding is successful, it will store the email address, encryption certificate, signature certificate, verification code hash value, password hash value and account name in the local database, and return a confirmation message of successful registration to the client; if the CA server returns information that the certificate binding fails, the business server discards the data and returns a registration failure message; after the client receives the confirmation message of successful registration from the business server, the registration process is completed and the user can log in afterwards.

[0022] The specific method of step 2 is:

[0023] 2.1 After logging in, users can add friends, create group chats, and initiate audio and video calls:

[0024] First, the initiator clicks the video button to select the invited call member to initiate the call. After the request is initiated, the business server applies to the SFU streaming server to create a video room and returns the room ID to the initiator. The initiator first checks the local certificate database to confirm whether the encryption certificate and signature certificate of the selected invited call member are valid. If a valid encryption certificate or signature certificate does not exist locally, the initiator queries the CA server to obtain it.

[0025] Subsequently, the initiator locally generates a new version of the SM4 symmetric key and IV vector, and signs the generated new version of the SM4 symmetric key and IV vector and room ID and other information using the SM2 private key of its own signature certificate. The initiator then uses the SM2 public key of the encryption certificate of each invited call member to perform SM2 encryption separately, ultimately forming an invitation message containing the encrypted data of all invited call members and submitting it to the business server. The business server verifies whether the invited call member belongs to the chat, forwards the invitation request after confirmation, and informs the SFU streaming server of the list of legal participants in the corresponding room.

[0026] After receiving the invitation request, the invited call members use the SM2 private key of their own encryption certificate to decrypt the invitation information and verify the signature. After the verification is passed, they can use the room ID to enter the video room of the SFU streaming server. The audio and video data in the room will be encrypted with the SM4 symmetric key and forwarded by the SFU streaming server. After receiving the data, each invited call member uses the SM4 symmetric key to decrypt and play it; at the same time, the initiator also joins the room, and the audio and video data is also encrypted with the SM4 symmetric key and forwarded to other members in the room by the SFU streaming server; to ensure security, the SFU streaming server authenticates users who attempt to enter the room and verifies whether the user ID is in the list of legitimate participants; in addition, the initiator will update the SM4 symmetric key one minute after entering the room and publish the new version of the SM4 symmetric key to all members in the room to prevent invited members who failed to join in time from still being able to decrypt the media data in the room;

[0027] 2.2 During a video call, the initiator invites other group members who have not yet joined the room to join:

[0028] After the initiator selects the target member, it first generates the next version of key information, including session ID, key version, SM4 symmetric key, SM4 vector, session type, key generation timestamp, and key switch timestamp. It then signs and encrypts the key information and sends it to all members in the room through the service server. Next, the initiator checks whether the encryption certificate and signature certificate of the invited member are stored locally, and verifies whether the encryption certificate and signature certificate are within the validity period. If the local encryption certificate and signature certificate do not exist, the initiator queries the CA server to obtain them.

[0029] The initiator then signs this information and the room ID using the SM2 private key of their own signature certificate. The initiator then uses the SM2 public key of each invited member's encryption certificate to perform SM2 encryption, ultimately forming a key update message containing the encrypted data of all invited members. This message is then submitted to the business server, which then forwards it to the invited members. The business server verifies whether the invited call member belongs to the chat, forwards the invitation request after confirmation, and informs the SFU streaming server of the list of legal participants in the corresponding room.

[0030] After receiving the invitation message, the invited member uses the SM2 private key of his or her own encryption certificate to decrypt the invitation message, verify the signature, record the key version and room ID, then join the room and use the SM4 symmetric key to encrypt and decrypt audio and video data for communication; to ensure the security of the room, one minute after the invitation is initiated, the initiator will update the SM4 symmetric key again, prohibiting new members from entering the room, and at the same time publish the new version of the SM4 symmetric key to all existing members to prevent users who are invited but have not entered the room from still being able to decrypt the media data in the room.

[0031] The specific method of step 3 is:

[0032] When a member in the room needs to exit the call at any time, the member will automatically exit the video room after clicking the hang-up button; the SFU streaming server and business server will notify all members in the room; the video initiator receives the notification message of the member's exit, generates a new version of the SM4 symmetric key to perform the key update process, and introduces a key update cooling-off mechanism to avoid frequent key updates caused by a large number of members exiting in a short period of time; specifically, the initiator first checks whether it is currently in the cooling-off period countdown. If so, only the key update flag is set to true. If it is not in the cooling-off period, the key update is immediately performed and the cooling-off period countdown is started; when the cooling-off period ends, the system checks the key update flag. If the flag is still true, a new round of key update process is automatically triggered.

[0033] After the audio and video call described in step 2 is initiated, room members or the room owner can initiate an active key update at any time. The specific method is as follows:

[0034] When a room member initiates a key update request, the room host distributes the new version of the SM4 key information to all members in the room after receiving the request. In addition, when the room host initiates a key update, the new SM4 key version information is directly released to all members. When the room host needs to release a new version of the key information to the room, the room host first generates the next version of the key information, including the session ID, key version, SM4 symmetric key, SM4 vector, session type, key generation timestamp, and key switch timestamp, and then signs and encrypts the key information and sends it to all members in the room through the service server.

[0035] The initiator then signs this information and the room ID using the SM2 private key of their signature certificate. The initiator then performs SM2 encryption using the SM2 public key of each room member's encryption certificate. This ultimately creates a key update message containing the encrypted data of all room members, submits it to the service server, and forwards it to the room members via the service server.

[0036] After receiving the key update information, the invited member uses the SM2 private key of his or her own encryption certificate to decrypt the invitation information, verify the signature, record the key version and room ID, verify whether the room ID is the current room ID, verify whether the key version is the expected version, and complete the key version switch at the time specified by the key switch timestamp.

[0037] Compared with the prior art, the present invention has the following beneficial effects:

[0038] ① Multi-level verification registration mechanism: Through email verification code, certificate issuance, business server verification and double confirmation of CA server, the legitimacy of user registration is ensured, effectively preventing malicious registration and identity forgery.

[0039] ②Dual authentication of the business server and the SFU streaming server: When forwarding a voice or video call invitation, the business server verifies whether the invited user belongs to the group chat and authenticates the user joining the room. At the same time, the SFU streaming server checks whether the user holds a valid key when forwarding data, achieving dual security protection and ensuring the security of room communications.

[0040] ③ Dynamic key update and cool-off period mechanism: Keys are regularly updated during calls to prevent historical key leaks, and the latest keys are synchronized when members join or leave to ensure forward and backward data security. Furthermore, when a user leaves or actively triggers a key update, the system determines whether they are in the cool-off period, reducing the impact of frequent key changes on performance. Keys are updated promptly when necessary to prevent sensitive data leaks.

[0041] ④ Unnoticed secure communication experience: All security operations such as encryption, certificate management, and key updates are automatically performed in the background. Users can enjoy a smooth experience that is no different from ordinary audio and video communication without additional operations, while ensuring the security of communication data.

[0042] In summary, the present invention adopts a dynamic key update mechanism to ensure that even if a certain key version is leaked, the attacker will not be able to decrypt historical or future communication content. At the same time, the key version update mechanism of the present invention does not need to maintain a large number of certificate chains, which reduces computing costs and improves the scalability of group chats. Through a mechanism that combines active key updates with user join / exit triggering key updates, it is ensured that all members always use the latest keys, thereby preventing the risk of historical key leakage. At the same time, a cooling-off period mechanism is introduced to avoid the impact of frequent key updates on system performance, and key updates are performed in a timely manner when necessary to balance security and system stability. Combined with email verification codes, certificate binding, and dual verification of business servers and CA servers, malicious registration and identity forgery are prevented, thereby improving system security. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1It is the overall structural diagram of the present invention.

[0044] Figure 2 This is a user registration flow chart of the present invention.

[0045] Figure 3 This is a flow chart of the user initiating an audio or video call in the present invention.

[0046] Figure 4 This is a flow chart of inviting other users during a user call in the present invention.

[0047] Figure 5 This is a flowchart of a user exiting a call in the present invention.

[0048] Figure 6 This is a flow chart of active key update during a user call in the present invention.

[0049] Figure 7 This is the effect diagram of group chat audio and video call.

[0050] Figure 8 Provides forward security protection for group chat audio and video. DETAILED DESCRIPTION

[0051] The present invention will be described in further detail below with reference to the accompanying drawings.

[0052] See also Figure 1 ,A forward and backward secure audio and video communication system based on dynamic key updating, includes a client and a server;

[0053] The client is responsible for interacting with users, completing end-to-end encryption of data communications and dynamic key updates, and providing protection for audio and video communication data. It includes a functional UI for user login, group chat management, and video calls, and is responsible for interacting with users and displaying functions. The key management module (KMM) is responsible for key version management and dynamic updates. The data protection module encrypts and decrypts data including text, audio, and video data.

[0054] The server side is responsible for user identity authentication, certificate issuance and management, friend group chat relationship maintenance, and forwarding of audio and video streaming media data, including business servers, CA servers, and SFU streaming media servers; the SFU streaming media server is responsible for forwarding audio and video streaming media data; the business server is responsible for specific services including user registration, key update request forwarding processing, and providing a unified interface to the outside world to realize user access to the SFU streaming media server; the CA server is independent of the business server and SFU streaming media server, and has a built-in email verification service. It can be directly accessed by users and business servers, and is responsible for issuing and managing user certificates and maintaining the Certificate Revocation List (CRL).

[0055] A forward and backward secure audio and video communication method based on dynamic key update specifically comprises the following steps:

[0056] Step 1: Before users can use the secure audio and video communication system to communicate, they must first complete account registration;

[0057] 1.1 The user first enters their email address, and the client requests a verification code email from the CA server. After receiving the verification code, the client locally generates a temporary session key (SM4 symmetric key) and two pairs of SM2 public and private keys. It then organizes the email address, verification code, and the public key of the encryption and signing certificates to be applied for into JSON format, encrypts it with the CA server's public key, and submits it to the CA server. The CA server uses its private key to decrypt the request data and verify the validity of the email verification code. If the verification is successful, it issues a certificate for the encryption and signing public keys, generates encryptionCrt and signingCrt, and encrypts them with the temporary session key before returning them to the client.

[0058] 1.2 The client then submits registration information to the business server, including the email address, encryption certificate, signature certificate, hash value of the verification code, hash value of the password, and account name. It is encrypted using the business server's public key and signed using the signature certificate. After verifying the integrity of the request, the business server decrypts and verifies the signature, and forwards the email address, encryption certificate, signature certificate, and hash value of the verification code to the CA server. The data is also encrypted using the CA server's public key and signed by the signature certificate's public key to ensure security. The CA server decrypts and verifies the integrity of the request, and checks the binding relationship between the verification code, email address, and certificate. If the verification is successful, the email address, encryption certificate, and signature certificate are stored in the database and a success result is returned. Otherwise, a failure message is returned.

[0059] 1.3 After receiving confirmation from the CA server, if the registration is successful, the business server stores the email address, encryption certificate, signature certificate, verification code hash value, password hash value, and account name in the local database and returns a confirmation message of successful registration to the client. If the CA server returns a failure result, the business server discards the data and returns a registration failure message. After the client receives the registration result from the business server, the registration process is completed and the user can log in.

[0060] The flow chart of user registration is as follows Figure 2 shown.

[0061] Step 2: Initiate an audio or video call and invite other users;

[0062] 2.1 After logging in, users can add friends, create group chats, and initiate audio and video calls within the group chat. For example, a group member can click the video button to select a group member to initiate a call. After initiating the request, the service server requests the SFU streaming server to create a video room and returns the room ID to the initiator. The initiator first checks the local certificate database to confirm the validity of the selected group member's certificate and public key. If a valid certificate or public key does not exist locally, the initiator queries the CA server for it. The initiator then locally generates an SM4 encryption key and IV vector and signs this information and the room ID using their own private signature key. They then perform SM2 encryption using the encryption public key of each invited group member. This creates an invitation message containing the encrypted data of all invited group members and submits it to the service server. The service server verifies that the invited user belongs to the group chat, forwards the invitation request upon confirmation, and informs the SFU streaming server of the list of valid participants in the corresponding room.

[0063] After receiving the invitation request, the invited member uses the private key to decrypt the encrypted information and verify the signature. After the verification is passed, the room ID can be used to enter the video room of the SFU streaming server. The audio and video data in the room will be encrypted by SM4 and forwarded by the SFU server. After receiving the data, each member uses the SM4 key to decrypt and play. At the same time, the initiator also joins the room, and the audio and video data is also encrypted by SM4 and forwarded by the SFU server to other members in the room. To ensure security, the SFU streaming server will authenticate the user. In addition, the initiator will update the key one minute after entering the room and publish the new version of the key to all members in the room to prevent invited users who fail to join in time from still being able to decrypt the media data in the room.

[0064] The flow chart of a user initiating an audio or video call is as follows Figure 3 .

[0065] 2.2 While a video call is in progress, the initiator can invite other group members who have not yet joined the room to join. After the initiator selects the target member, he first generates the next version of the key information, signs and encrypts the key information, and sends it to all members in the room through the business server. Next, the initiator checks whether the certificate and public key of the invited group member are stored locally, and verifies their validity. If there is no legal certificate or public key locally, the initiator queries the CA server to obtain it. Subsequently, the initiator uses the encrypted public key of the invited group member to encrypt the key information and forwards it to the invited member through the business server. After receiving the key information, the invited member decrypts and verifies the signature, verifies the key version, and switches to the new key after the specified time. The SFU streaming media server will check whether the user who requests to join is legitimate. If the verification fails, the user will be denied access to the room.

[0066] After receiving the invitation, the invited member decrypts and verifies the key information, records the key version and room ID, then joins the room and uses SM4 to encrypt and decrypt audio and video data for communication. To ensure room security, one minute after the invitation is sent, the initiator will update the key again, prohibit new members from joining the room, and distribute the new version of the key to all existing members to prevent users who have been invited but have not entered the room from decrypting the room's media data.

[0067] The flowchart of inviting other users during a user call is as follows Figure 4 .

[0068] Step 3: The room user exits;

[0069] Participants in the room can exit the call at any time. When the user clicks the hang-up button, they will automatically exit the video room. The SFU streaming server and business server will notify all members in the room. The video initiator will process the exit information. To avoid frequent key updates caused by a large number of members exiting in a short period of time, the system has a key update cooling-off mechanism. The initiator first checks whether it is currently in the cooling-off period. If so, it only sets the key update flag to true. If not, it immediately performs the key update and starts the cooling-off period countdown. When the cooling-off period ends, the system checks the key update flag. If the flag is still true, it automatically triggers a new round of key update process.

[0070] The flowchart of user exiting during a call is as follows Figure 5 .

[0071] During a call, the initiator can manually trigger a rekey at any time. When the initiator clicks the rekey button, the system first checks whether the current cool-off period has occurred. If so, the system sets the rekey flag to true. Otherwise, the rekey is immediately executed and the cool-off period countdown begins. After the cool-off period, if the rekey flag is still true, a new rekey is automatically executed to ensure call security.

[0072] The flowchart of active key update during user call is as follows Figure 6 .

[0073] A simulation system was developed to implement the aforementioned method. Audio and video frame encryption utilizes pluggable stream technology, providing end-to-end encryption of frame-level data on the client side. The client was developed using Tauri and React and deployed on the Windows 11 operating system, using an Intel i7-10700 2.90GHz CPU and 16GB of memory. The server was developed using Java and Node.js and deployed on Ubuntu, using an AMD Ryzen 74800H 2.90GHz CPU and 16GB of memory. The overall architecture includes a business server, a SFU server, and a CA server. The system was deployed and tested in this environment.

[0074] The simulation system was tested with the following test methods. The audio and video call effect test was mainly conducted by simulating a multi-person scenario, gradually increasing the number of call members (from 2 to 10 people), and recording the time required to update the system key for each additional member. At the same time, for 800×600 resolution video frames, the additional delay introduced by the audio and video encryption and decryption processing was tested to ensure that the impact on real-time calls was within an acceptable range. The forward security test simulates the behavior of attackers to verify whether malicious users who have exited the group can continue to obtain and decrypt audio and video streams. The specific method is to temporarily turn off the server's check on user access, and write attack code to allow the exited members to continue to monitor the streaming media data, and observe whether the encryption effect after the key update can effectively prevent the attacker from decrypting it.

[0075] System client audio and video call effect see Figure 7 Key update tests in multi-person scenarios showed that the average key update time increased by 23 milliseconds for each additional member. Testing of 800×600 resolution video frames showed that the additional latency introduced by audio and video encryption and decryption was kept below 70 milliseconds.

[0076] Simulate an attacker to conduct a forward security test of the video, temporarily lift the server's check on user access, and write corresponding test code on the client to simulate the behavior of a malicious attacker obtaining the room's media data. Group member A first invites friends B and C to a video call, and then group member C exits. However, group member C exits the user room as an attacker and continues to monitor streaming media data. However, since member C's exit triggers a key update, group members A and B begin to use the new version of the key to encrypt audio and video calls, and member C cannot correctly decrypt the audio and video data in the room because it does not have the new version of the key. For the sake of user usability, the system displays video frames that cannot be correctly decrypted as white blank frames, such as Figure 8 shown.

[0077] Comprehensive test results demonstrate that the system's forward and backward security mechanisms are effective, while maintaining reasonable performance overhead. In multi-person interaction scenarios, key update time increases by an average of approximately 23ms as the number of participants increases. Furthermore, the impact of insertable stream operations on video frames increases latency by approximately 70ms.

Claims

1. A forward and backward secure audio and video communication system based on dynamic key update, characterized in that: Including client and server; The client is responsible for interacting with users, completing end-to-end encryption of data communications and dynamic key updates, and providing protection for audio and video communication data. It includes a functional UI for user login, group chat management, and video calls, and is responsible for interacting with users and displaying functions. The Key Management Module (KMM) is responsible for key version management and dynamic updates. Data protection module, encrypts and decrypts data including text, audio and video data; The server side is responsible for user identity authentication, certificate issuance management, friend group chat relationship maintenance, and forwarding of audio and video streaming data, including business servers, CA servers, and SFU streaming servers; The SFU streaming media server is responsible for forwarding audio and video streaming media data; The business server is responsible for specific services including user registration, key update request forwarding, and providing a unified interface to the outside world to realize user access to the SFU streaming media server; the CA server is independent of the business server and the SFU streaming media server, and has a built-in email verification service. It can be directly accessed by users and business servers, and is responsible for issuing and managing user certificates and maintaining the Certificate Revocation List (CRL).

2. A forward and backward secure audio and video communication system based on dynamic key update according to claim 1, characterized in that: The encryption certificate and signature certificate of the CA server are built into the client. When the encryption certificate and signature certificate of the CA server are missing, the client requests the CA server to obtain them.

3. The audio and video communication method of the forward and backward secure audio and video communication system based on dynamic key update according to claim 1 or 2, characterized in that: The specific steps are as follows: Step 1. The user completes account registration; Step 2: After completing account registration, users can create video rooms, initiate audio and video calls, and invite other users to participate in audio and video communications; Step 3: The room user exits the audio and video communication.

4. A forward and backward secure audio and video communication method based on dynamic key update according to claim 3, characterized in that: The specific method of step 1 is: 1.1 The user registers by requesting the CA server to send a verification code email through the client. After receiving the verification code, the client locally generates a temporary session key, namely the SM4 symmetric key, as well as the SM2 public-private key pair of the signing certificate and the SM2 public-private key pair of the encryption certificate. Then, the client organizes the email address, verification code, SM2 public key of the encryption certificate to be applied for, and SM2 public key of the signing certificate into a dictionary object according to the JSON specification, converts it into a JSON string, encrypts it with the SM2 public key of the encryption certificate of the CA server, and submits it to the CA server; The CA server uses the private key of the encryption certificate to decrypt the information contained in the registration request and verify whether the verification code in the request is consistent with the verification code sent. If the verification is successful, the CA server issues certificates based on the SM2 public key of the encryption certificate and the SM2 public key of the signing certificate, generates encryptionCrt and signingCrt, and encrypts them with the temporary session key before returning them to the client. 1.2 The client submits a registration request to the business server. The information includes the email address, encryption certificate, signature certificate, hash value of the verification code, hash value of the password, and account name. The request is encrypted using the business server's public key and signed using the signature certificate. After verifying the integrity of the registration request, the business server decrypts and verifies the signature, and requests certificate binding from the CA server. The certificate binding information includes the email address, encryption certificate, signature certificate, and verification code hash value. The certificate binding information is also encrypted by the SM2 public key of the CA server's encryption certificate and signed by the SM2 public key of the signature certificate to ensure security; the CA server decrypts and verifies the integrity of the certificate binding request, verifies the binding relationship between the verification code, email address, encryption certificate, and signature certificate. If the verification is successful, the email address, encryption certificate, and signature certificate are stored in the local certificate database, and a certificate binding success message is returned to the business server. Otherwise, a certificate binding failure message is returned to the business server. 1.3 After the business server receives the return information from the CA server, if the return information shows that the certificate binding is successful, it will store the email address, encryption certificate, signature certificate, verification code hash value, password hash value and account name in the local database and return a confirmation message of successful registration to the client; If the CA server returns information indicating that the certificate binding failed, the business server discards the data and returns a registration failure message; After the client receives confirmation that the business server has successfully registered, the registration process is completed and the user can then log in.

5. The forward and backward secure audio and video communication method based on dynamic key update according to claim 3, characterized in that: The specific method of step 2 is: 2.1 After logging in, users can add friends, create group chats, and initiate audio and video calls: First, the initiator clicks the video button to select the invited call member to initiate the call. After the request is initiated, the business server applies to the SFU streaming server to create a video room and returns the room ID to the initiator. The initiator first checks the local certificate database to confirm whether the encryption certificate and signature certificate of the selected invited call member are valid. If a valid encryption certificate or signature certificate does not exist locally, the initiator queries the CA server to obtain it. Subsequently, the initiator locally generates a new version of the SM4 symmetric key and IV vector, and signs the generated new version of the SM4 symmetric key and IV vector and room ID and other information using the SM2 private key of its own signature certificate. The initiator then uses the SM2 public key of the encryption certificate of each invited call member to perform SM2 encryption separately, ultimately forming an invitation message containing the encrypted data of all invited call members and submitting it to the business server. The business server verifies whether the invited call member belongs to the chat, forwards the invitation request after confirmation, and informs the SFU streaming server of the list of legal participants in the corresponding room. After receiving the invitation request, the invited call member uses the SM2 private key of his or her encryption certificate to decrypt the invitation information and verify the signature. After the verification is passed, he or she can use the room ID to enter the video room of the SFU streaming server. The audio and video data in the room will be encrypted with the SM4 symmetric key and forwarded by the SFU streaming server. After receiving the data, each invited call member uses the SM4 symmetric key to decrypt and play it; At the same time, the initiator also joins the room, and the audio and video data are also encrypted with the SM4 symmetric key and forwarded to other members in the room by the SFU streaming server; To ensure security, the SFU streaming server authenticates users attempting to enter the room and verifies whether the user ID is on the list of legitimate participants. In addition, one minute after entering the room, the initiator will update the SM4 symmetric key and publish the new version of the SM4 symmetric key to all members in the room to prevent invited members who fail to join in time from still being able to decrypt the media data in the room. 2.2 During a video call, the initiator invites other group members who have not yet joined the room to join: After the initiator selects the target member, it first generates the next version of key information, including session ID, key version, SM4 symmetric key, SM4 vector, session type, key generation timestamp, and key switch timestamp. It then signs and encrypts the key information and sends it to all members in the room through the service server. Next, the initiator checks whether the encryption certificate and signature certificate of the invited member are stored locally, and verifies whether the encryption certificate and signature certificate are within the validity period. If the local encryption certificate and signature certificate do not exist, the initiator queries the CA server to obtain them. The initiator then signs this information and the room ID using the SM2 private key of his or her own signing certificate; The initiator then uses the SM2 public key of each invited member's encryption certificate to perform SM2 encryption, ultimately forming a key update message containing the encrypted data of all invited members, and submits it to the business server, which forwards it to the invited members. The business server verifies whether the invited call member belongs to the chat, forwards the invitation request after confirmation, and informs the SFU streaming server of the list of legal participants in the corresponding room. After receiving the invitation message, the invited member uses the SM2 private key of his or her own encryption certificate to decrypt the invitation message, verify the signature, record the key version and room ID, then join the room and use the SM4 symmetric key to encrypt and decrypt audio and video data for communication; to ensure the security of the room, one minute after the invitation is initiated, the initiator will update the SM4 symmetric key again, prohibiting new members from entering the room, and at the same time publish the new version of the SM4 symmetric key to all existing members to prevent users who are invited but have not entered the room from still being able to decrypt the media data in the room.

6. The forward and backward secure audio and video communication method based on dynamic key update according to claim 3, characterized in that: The specific method of step 3 is: When a member in the room needs to exit the call at any time, the member will automatically exit the video room after clicking the hang-up button; the SFU streaming server and business server will notify all members in the room; the video initiator receives the notification message of the member's exit, generates a new version of the SM4 symmetric key to perform the key update process, and introduces a key update cooling-off mechanism to avoid frequent key updates caused by a large number of members exiting in a short period of time; specifically, the initiator first checks whether it is currently in the cooling-off period countdown. If so, only the key update flag is set to true. If it is not in the cooling-off period, the key update is immediately performed and the cooling-off period countdown is started; when the cooling-off period ends, the system checks the key update flag. If the flag is still true, a new round of key update process is automatically triggered.

7. The forward and backward secure audio and video communication method based on dynamic key update according to claim 3, characterized in that: After the audio and video call described in step 2 is initiated, room members or the room owner can initiate an active key update at any time. The specific method is as follows: When a room member initiates a key update request, the room host distributes the new version of the SM4 key information to all members in the room after receiving the request. In addition, when the room host initiates a key update, the new SM4 key version information is directly released to all members. When the room host needs to release a new version of the key information to the room, the room host first generates the next version of the key information, including the session ID, key version, SM4 symmetric key, SM4 vector, session type, key generation timestamp, and key switch timestamp, and then signs and encrypts the key information and sends it to all members in the room through the service server. The initiator then signs this information and the room ID using the SM2 private key of their signature certificate. The initiator then performs SM2 encryption using the SM2 public key of each room member's encryption certificate. This ultimately creates a key update message containing the encrypted data of all room members, submits it to the service server, and forwards it to the room members via the service server. After receiving the key update information, the invited member uses the SM2 private key of his or her own encryption certificate to decrypt the invitation information, verify the signature, record the key version and room ID, verify whether the room ID is the current room ID, verify whether the key version is the expected version, and complete the key version switch at the time specified by the key switch timestamp.

Images