WebRTC-based end-to-end encryption P2P direct connection monitoring method, system, device and storage medium

Abstract

This invention discloses an end-to-end encrypted P2P direct connection monitoring method, system, device, and storage medium based on WebRTC. The method obtains an independent master key derived from the encrypted connection between the image acquisition device and the client. A frame-level encryptor is inserted into a pre-set WebRTC native media pipeline. The independent master key, a pre-set synchronization source identifier, and a pre-set frame sequence number are combined to generate a unique key for each frame. Based on the synchronization source identifier, the client decrypts the unique key for each frame using the independent master key. The network switching status of the image acquisition device is detected, triggering a connection reset mechanism. The independent master key is not re-derived within a preset time, and the independent master key is reused. This achieves frame-level, two-layer end-to-end encryption, ensuring the video stream is uncrackable from acquisition to the client. Furthermore, it enables seamless reconnection during network switching, while also considering the performance of devices with low computing power.

Description

[0001] Technology Neighborhood This invention relates to the fields of network communication and video surveillance technology, and in particular to an end-to-end encrypted P2P direct connection monitoring method, system, device and storage medium based on WebRTC. Background Technology

[0002] Current WebRTC-based video surveillance systems primarily use cameras to push audio and video streams to cloud media servers, with clients pulling the streams from the servers. While this architecture is mature and stable, the media stream must be relayed through the server, meaning server operators can obtain the plaintext video stream or have decryption capabilities, posing a privacy risk. It also introduces additional forwarding latency. Another approach uses cameras and clients to establish peer-to-peer connections via STUN / TURN, where the media stream doesn't pass through the server. However, this solution suffers from a serious flaw: the ICE (Intercept for Continuous Transmission) degradation mechanism lacks user control—when P2P penetration fails, the system automatically falls back to the TURN relay, resulting in the video stream passing through a third-party relay server in plaintext. Summary of the Invention

[0003] The purpose of this invention is to address the technical problems existing in the background art by proposing an end-to-end encrypted P2P direct connection monitoring method, system, device, and storage medium based on WebRTC.

[0004] To achieve the above-mentioned technical objectives, the technical solution adopted by the present invention is as follows: A first implementation of the first aspect of this invention provides an end-to-end encrypted P2P direct connection monitoring method based on WebRTC, applied to an image acquisition device and a client. This end-to-end encrypted P2P direct connection monitoring method based on WebRTC includes: S101. Obtain the independent master key derived between the image acquisition device and the client during the encrypted connection; S102. Insert a frame-level encryptor into the pre-configured WebRTC native media pipeline, and use the independent master key, the pre-configured synchronization source identifier, and the pre-configured frame sequence number as the key derivation for the frame-level encryptor to generate a unique key for each frame. S103. Based on the synchronization source identifier, the client uses an independent master key to decrypt the unique key of each frame. S104. Detect the network switching status of the image acquisition device, trigger the connection reset mechanism, and do not re-execute S101 within a preset time, and reuse the independent master key.

[0005] Optionally, in a second implementation of the first aspect of the present invention, S101 includes: S1011. Obtain the client's connection request to the image acquisition device, transmit the public key and certificate of the image acquisition device to the client, and have the client verify the certificate; S1012. The temporary random number generated by the client is encrypted using the public key and transmitted to the image acquisition device, which then decrypts it using the built-in private key. S1013. Based on the preset key exchange algorithm, derive independent master keys for the client and the image acquisition device.

[0006] Optionally, in a third implementation of the first aspect of the present invention, S101 further includes: S1014. Force the image acquisition device to collect several candidate ICE addresses; S1015. Periodically check the connectivity of each candidate ICE address and determine whether a P2P candidate pair is established within a preset time. S1016. If the connection is not established within the timeout period, a signaling message indicating that the client connection failed will be sent, pending authorization from the client to allow the pre-configured TURN server to forward the connection.

[0007] Optionally, in a fourth implementation of the first aspect of the invention, the frame-level encryptor is positioned after the encoder output and before the RTP packet encapsulation in the WebRTC native media pipeline.

[0008] Optionally, in the fifth implementation of the first aspect of the present invention, the frame-level encryptor uses the AES-256-GCM encryption algorithm.

[0009] Optionally, in the sixth implementation of the first aspect of the present invention, the unique key for each frame is generated by combining the independent master key, the synchronization source identifier, and the frame sequence number using the HMAC-SHA256 algorithm.

[0010] Optionally, in a seventh implementation of the first aspect of the present invention, S104 further includes: S1041. Construct a key rollover mechanism and set the image acquisition device to update the independent master key when the preset time or the cumulative amount of encrypted data reaches a threshold.

[0011] A second aspect of the present invention provides an end-to-end encrypted P2P direct connection monitoring system based on WebRTC, comprising: The key derivation module is used to obtain the independent master key derived between the image acquisition device and the client during the encrypted connection. An independent encryption module is used to insert a frame-level encryptor into the pre-built WebRTC native media pipeline. It combines an independent master key, a pre-built synchronization source identifier, and a pre-built frame sequence number as the key derivation for the frame-level encryptor to generate a unique key for each frame. The decryption module is used to decrypt the unique key of each frame using the client's independent master key based on the synchronization source identifier. The reuse module is used to detect the network switching status of the image acquisition device, trigger the connection reset mechanism, and not re-execute the key derivation module within a preset time, as well as reuse the independent master key.

[0012] A first implementation of the third aspect of the present invention provides an end-to-end encrypted P2P direct connection image acquisition device based on WebRTC, the end-to-end encrypted P2P direct connection image acquisition device based on WebRTC includes: a memory and at least one processor, the memory stores instructions, and the memory and the at least one processor are interconnected via a line; The at least one processor invokes the instructions in the memory to cause the WebRTC-based end-to-end encrypted P2P direct connection image acquisition device to execute the WebRTC-based end-to-end encrypted P2P direct connection monitoring method as described in any one of the first aspects of the present invention.

[0013] A first implementation of the fourth aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the WebRTC-based end-to-end encrypted P2P direct connection monitoring method as described in any one of the first aspects of the present invention.

[0014] Compared with existing technologies, this invention has the following beneficial technical effects: By obtaining the independent master key derived from the encrypted connection between the image acquisition device and the client, a frame-level encryptor is inserted into the pre-set WebRTC native media pipeline. The independent master key, the pre-set synchronization source identifier, and the pre-set frame sequence number are combined as the key derivation for the frame-level encryptor to generate a unique key for each frame. Based on the synchronization source identifier, the client uses the independent master key to decrypt the unique key for each frame. The network switching status of the image acquisition device is detected, triggering a connection reset mechanism. The independent master key is not re-derived within a preset time, and the independent master key is reused. This achieves frame-level, two-layer end-to-end encryption, ensuring that the video stream is uncrackable from acquisition to the client. Furthermore, it enables seamless reconnection during network switching, taking into account the performance of low-computing-power devices. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the first embodiment of the WebRTC-based end-to-end encrypted P2P direct connection monitoring method in this invention. Figure 2 This is a schematic diagram of the second embodiment of the WebRTC-based end-to-end encrypted P2P direct connection monitoring method in this invention. Figure 3 This is a schematic diagram of the third embodiment of the WebRTC-based end-to-end encrypted P2P direct connection monitoring method in this invention. Figure 4 This is a schematic diagram of the seventh embodiment of the WebRTC-based end-to-end encrypted P2P direct connection monitoring method in this invention. Figure 5 A schematic diagram of an embodiment of the WebRTC-based end-to-end encrypted P2P direct connection monitoring system in this invention; Figure 6 This is a schematic diagram of an embodiment of an end-to-end encrypted P2P direct-connection image acquisition device based on WebRTC in this invention. Detailed Implementation

[0016] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0017] For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 -Appendix Figure 4 The WebRTC-based end-to-end encrypted P2P direct connection monitoring method in this embodiment of the invention is applied to an image acquisition device and a client. This WebRTC-based end-to-end encrypted P2P direct connection monitoring includes: S101. Obtain the independent master key derived between the image acquisition device and the client during the encrypted connection; In this embodiment, when the image acquisition device leaves the factory, the manufacturer writes an ECC / P-256 asymmetric key pair into the device's security area. The device certificate is issued by the manufacturer's CA and includes the device ID, public key, and manufacturing date. The user uses a client to obtain the public key and certificate of the image acquisition device through scanning a code / local area network discovery, verifies the certificate chain, exchanges session protocols, and derives an independent master key. It should be noted that the independent master key can be used in both the image acquisition device and the client.

[0018] Furthermore, step S101 includes: S1011. Obtain the client's connection request to the image acquisition device, transmit the public key and certificate of the image acquisition device to the client, and have the client verify the certificate; S1012. The temporary random number generated by the client is encrypted using the public key and transmitted to the image acquisition device, which then decrypts it using the built-in private key. S1013. Based on the preset key exchange algorithm, derive independent master keys for the client and the image acquisition device.

[0019] In this embodiment, the client generates a 32-byte random number, encrypts it with the public key of the image acquisition device, and sends it to prevent the random number from being stolen during transmission. The image acquisition device decrypts it with its own private key. The two parties exchange temporary key materials through ECDH (Elliptic Curve Key Exchange Algorithm). Finally, the HKDF (HMAC-based Key Derivation Function) algorithm is used to concatenate the ECDH calculation result and the random number decrypted by the image acquisition device to derive a unique independent master key.

[0020] It is important to note that the independent master key exists only in the hardware security zone of the image acquisition device and on the client's local machine. The signaling server only forwards the encrypted random number throughout the process and cannot obtain the independent master key or any original material from which the independent master key is derived. Furthermore, the independent master key is completely separate from the DTLS-SRTP transport layer key that comes with WebRTC. Even if the DTLS key is leaked, it is impossible to deduce the independent master key from it, thus achieving double-layer encryption to improve security.

[0021] Furthermore, step S101 also includes: S1014. Force the image acquisition device to collect several candidate ICE addresses; S1015. Periodically check the connectivity of each candidate ICE address and determine whether a P2P candidate pair is established within a preset time. S1016. If the connection is not established within the timeout period, a signaling message indicating that the client connection failed will be sent, pending authorization from the client to allow the pre-configured TURN server to forward the connection.

[0022] In this embodiment, an ICE policy with mandatory priority and authorization downgrade is constructed. The RTCPeerConnection of the image acquisition device is configured in mandatory mode to collect multiple candidate ICE addresses. These candidate ICE addresses come from three core sources: First, host candidates, i.e., the local network of the image acquisition device. These are pure local addresses that do not require any server forwarding and are the core candidates for direct P2P connection, and are also the first priority for ICE checks. Second, server reflection candidates. When the image acquisition device is under NAT (Network Address Translation), the internal IP cannot be directly accessed by the external network and needs to obtain a public network mapping address through a STUN server. This still falls under the category of P2P connection, and only obtains the public network mapping through a STUN server without data relay. Third, relay candidates. This is an alternative after P2P direct connection fails. It is only enabled after user authorization and uses a TURN server as a relay node, providing a dedicated relay address and port. The image acquisition device sends media data to this address, and then the TURN server forwards it to the client.

[0023] If no P2P candidate pair is established within the timeout period, and the TURN server is not automatically activated, the image acquisition device sends a fallback-request signal to the client, carrying the number of candidate pairs currently tried and the network type. The client's UI pop-up window prompts "The current network cannot connect directly. Do you allow forwarding through the encrypted relay server (TURN server)?" The user can choose "Allow only this time" or "Cancel". Only when the user chooses "Allow" will the image acquisition device activate the pre-configured TURN server, and the TURN forwarding media will be the ciphertext encrypted in step C. This changes the default logic of the existing WebRTC implementation of automatic TURN after P2P failure, returning the network policy decision-making power to the user.

[0024] S102. Insert a frame-level encryptor into the pre-configured WebRTC native media pipeline, and use the independent master key, the pre-configured synchronization source identifier, and the pre-configured frame sequence number as the key derivation for the frame-level encryptor to generate a unique key for each frame. S103. Based on the synchronization source identifier, the client uses an independent master key to decrypt the unique key of each frame. In this embodiment, the frame-level encryptor is set after the encoder output and before the RTP packet encapsulation in the WebRTC native media pipeline. The frame-level encryptor uses the AES-256-GCM encryption algorithm. The unique key for each frame is generated by combining the HMAC-SHA256 algorithm with the independent master key, the synchronization source identifier (SSRC), and the frame sequence number. The specific encryption process is as follows: input the original NAL unit (length L), generate a 12-byte random IV (initialization vector), perform AES-256-GCM encryption, output ciphertext C, and attach a 16-byte authentication tag T and RTP payload = IV(12) || C || T(4) to achieve double encryption. The media stream is protected by both DTLS-SRTP (transport layer) and E2EE (application layer). Even if the TURN server intercepts the SRTP key, it still cannot decrypt the ciphertext. The encryption granularity is fine to the frame level, and it supports independent decryption in packet loss scenarios.

[0025] S104. Detect the network switching status of the image acquisition device, trigger the connection reset mechanism, and do not re-execute S101 within a preset time, and reuse the independent master key.

[0026] S1041. Construct a key rollover mechanism and set the image acquisition device to update the independent master key when the preset time or the cumulative amount of encrypted data reaches a threshold.

[0027] In this embodiment, the image acquisition device detects network switching (e.g., Wi-Fi → 4G), triggers ICE restart, and does not re-execute step S101. The client reuses the independent master key, only re-exchanging SDP and ICE candidates. The reuse period here is up to 72 hours. After the timeout, key negotiation needs to be re-established. The key rollover mechanism is that the image acquisition device automatically generates a new random number every 10 minutes or after accumulating 1GB of encrypted data, and sends it to the client through the existing encryption channel. The image acquisition device and the client synchronously update the independent master key.

[0028] In the specific implementation process, the user downloads the App client, the image acquisition device is powered on, and the device information is broadcast via BLE. The App reads the QR code of the image acquisition device, decodes it to obtain the device ID and certificate download URL, and downloads the device certificate from the manufacturer's CA via HTTPS to verify the signature validity.

[0029] The App generates a 32-byte random number R_c and performs ECDH encryption using the public key (P-256) of the image acquisition device: using the ECIES scheme, the ciphertext C1 is output.

[0030] The app sends the following via WebSocket signaling (wss: / / signal.example.com): json {"type": "key_exchange","device_id": "CAM-2025-A7F3","ciphertext": "0x7b2c3d...(256 bytes)","timestamp": 1740000000} After receiving the image, the image acquisition device decrypts the private key to obtain R_c, generates a temporary elliptic curve key pair, calculates the ECDH shared key, concatenates it with R_c, performs HKDF-SHA256, outputs a 32-byte independent master key, and the image acquisition device replies with key_exchange_ack.

[0031] The App calls getUserMedia (for testing purposes only; the App does not collect local streams during actual monitoring) to create an RTCPeerConnection.

[0032] The image acquisition device RTCPeerConnection is configured as follows: javascript const iceServers = [{ urls: 'stun:stun1.l.google.com:19302'},{ urls:'stun:stun2.l.google.com:19302'} / / No TURN configuration—key: TURN is not pre-configured, but dynamically injected by the authorization directive]; const pc = new RTCPeerConnection({ iceServers}); / / Inject custom ICE policy pc.x_iceFallbackPolicy = 'user-authorized-only'; Image acquisition devices and clients exchange SDP Offer / Answer signals to collect ICE candidates.

[0033] An example of encrypted transmission is: 1. Get the current SSRC: 0x3e4f5a6b 2. Frame sequence number counter: frame_id = 1024 3. Derived key: K_frame = HMAC-SHA256(MK, SSRC(4) || frame_id(4)), take the first 32 bytes. 4. Generate a random IV: 0x7a8b9c0d1e2f3a4b5c6d7e8f 5. AES-256-GCM encryption: Plaintext: 1460 bytes; Ciphertext: 1460 bytes (ciphertext length equals plaintext length in GCM mode); Authentication tag: 16 bytes (truncated to 4 bytes during actual transmission); RTP payload encapsulation: 12-byte IV, 1460-byte ciphertext, and 4-byte authentication tag.

[0034] Total length: 1476 bytes, fragmentation is within MTU 1500, no secondary fragmentation is required.

[0035] Client-side decryption: The client's RTP module parses the IV, ciphertext, and tag. Based on the SSRC, it looks up the MK from the local KeyRing (the KeyRing capacity is 16 by default, and circular overlay is supported), performs the same derivation, and the GCM decrypts and verifies the integrity. If the verification is successful, it sends the data to the hardware decoder.

[0036] In scenarios where symmetric NAT traversal fails: The user places the image acquisition device on a mobile 4G network (carrier-grade symmetric NAT), and the client is behind the company firewall (UDP restricted). After 5 seconds, ICE only obtains host and srflx candidates; relay candidates are not configured.

[0037] The image acquisition device's ICE state machine triggers the fallback process: 1. The image acquisition device sends a fallback request to the signaling server, with the reason: p2p_timeout.

[0038] 2. The signaling server forwards the message to the client, and a pop-up window appears in the client's UI: "A direct connection cannot be established on the current network. Do you allow forwarding via encrypted relay? The relay server cannot view your video content." 3. The user clicks "Allow only this time".

[0039] 4. The client dynamically sends the TURN configuration to the signaling channel of the image acquisition device (pre-embedded in the enterprise version TURN cluster): json {"type": "turn_auth","urls": "turn:turn.example.com:3478?transport=udp","username": "user_abc","credential": "expire=1740003600|hmac=..."} 5. The image acquisition device dynamically adds ICE candidates, re-performs ICE connectivity checks, and successfully establishes relay candidate pairs.

[0040] The above describes the end-to-end encrypted P2P direct connection monitoring method based on WebRTC in the embodiments of the present invention. The following describes the end-to-end encrypted P2P direct connection monitoring method based on WebRTC in the embodiments of the present invention. Please refer to [link to relevant documentation]. Figure 5 The WebRTC-based end-to-end encrypted P2P direct connection monitoring system includes: The key derivation module 201 is used to obtain the independent master key derived between the image acquisition device and the client during the encrypted connection. Independent encryption module 202 is used to insert a frame-level encryptor into the pre-built WebRTC native media pipeline. It combines an independent master key, a pre-built synchronization source identifier, and a pre-built frame sequence number as the key derivation for the frame-level encryptor to generate a unique key for each frame. The decryption module 203 is used to decrypt the unique key of each frame using the client's independent master key based on the synchronization source identifier; The reuse module 204 is used to detect the network switching status of the image acquisition device, trigger the connection reset mechanism, and not re-execute the key derivation module within a preset time, as well as reuse the independent master key.

[0041] Specifically, the key derivation module 201 can execute: Obtain the client's connection request to the image acquisition device, transmit the public key and certificate of the image acquisition device to the client, and have the client verify the certificate; The temporary random number generated by the client is encrypted using a public key and transmitted to the image acquisition device, which then decrypts it using its built-in private key. Based on a pre-set key exchange algorithm, independent master keys are derived for the client and the image acquisition device.

[0042] Specifically, the key derivation module 201 can also execute: Force the image acquisition device to collect several candidate ICE addresses; The connectivity of each candidate ICE address is periodically checked, and it is determined whether a P2P candidate pair is established within a preset time. If the connection is not established within the timeout period, a signaling message indicating a connection failure will be sent to the client, pending authorization from the client to allow the pre-configured TURN server to forward the connection.

[0043] The frame-level encryptor is set after the encoder output and before the RTP packet encapsulation in the WebRTC native media pipeline.

[0044] The frame-level encryptor uses the AES-256-GCM encryption algorithm.

[0045] The unique key for each frame is generated by combining the independent master key, the synchronization source identifier, and the frame sequence number using the HMAC-SHA256 algorithm.

[0046] Specifically, the reuse module 204 can also execute: A key rollover mechanism is established, which sets the image acquisition device to update the independent master key when the preset time or the cumulative amount of encrypted data reaches a threshold.

[0047] In this embodiment, by obtaining the independent master key derived from the encrypted connection between the image acquisition device and the client, a frame-level encryptor is inserted into the preset WebRTC native media pipeline. The independent master key, the preset synchronization source identifier, and the preset frame sequence number are combined as the key derivation for the frame-level encryptor to generate a unique key for each frame. Based on the synchronization source identifier, the client uses the independent master key to decrypt the unique key for each frame. The network switching status of the image acquisition device is detected, triggering a connection reset mechanism. The independent master key is not re-derived within a preset time, and the independent master key is reused. This achieves frame-level, two-layer end-to-end encryption, ensuring that the video stream is uncrackable from acquisition to the client. Furthermore, it enables seamless reconnection during network switching, taking into account the performance of low-computing-power devices.

[0048] The end-to-end encrypted P2P direct connection monitoring method based on WebRTC in this embodiment of the invention is described in detail from the perspective of unitized functional entities. The end-to-end encrypted P2P direct connection image acquisition device based on WebRTC in this embodiment of the invention is described in detail from the perspective of hardware processing.

[0049] Figure 6 This is a schematic diagram of the structure of an end-to-end encrypted P2P direct-connect image acquisition device based on WebRTC, according to an embodiment of the present invention. This WebRTC-based end-to-end encrypted P2P direct-connect image acquisition device can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 310 (e.g., one or more processors) and a memory 320, and one or more storage media 330 (e.g., one or more mass storage devices) for storing application programs 333 or data 332. The memory 320 and storage media 330 can be temporary or persistent storage. The program stored in the storage media 330 may include one or more units (not shown in the diagram), each unit may include a series of instruction operations on the WebRTC-based end-to-end encrypted P2P direct-connect image acquisition device. Furthermore, the processor 310 may be configured to communicate with the storage media 330 to execute the series of instruction operations in the storage media 330 on the WebRTC-based end-to-end encrypted P2P direct-connect image acquisition device.

[0050] The WebRTC-based end-to-end encrypted P2P direct connection image acquisition device may also include one or more power supplies 340, one or more wired or wireless network interfaces 350, one or more input / output interfaces 360, and / or one or more operating systems 331, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 6 The illustrated end-to-end encrypted P2P direct connection image acquisition device structure based on WebRTC does not constitute a limitation on communication protocol devices based on LAN projection. It may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0051] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when the instructions are executed on a computer, cause the computer to perform the steps of the WebRTC-based end-to-end encrypted P2P direct connection monitoring method.

[0052] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several 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 methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0053] The above describes a WebRTC-based end-to-end encrypted P2P direct connection monitoring method or various implementation methods, but it is not intended that the specific implementation of this invention is limited to these descriptions. Any methods or structures that are similar to or identical to those of this invention, or any technical deductions or substitutions made under the premise of this invention, should be considered within the scope of protection of this invention.

Claims

1. A WebRTC-based end-to-end encrypted P2P direct connection monitoring method, applied to image acquisition equipment and client, characterized in that, The WebRTC-based end-to-end encrypted P2P direct connection monitoring method includes: S101. Obtain the independent master key derived between the image acquisition device and the client during the encrypted connection; S102. Insert a frame-level encryptor into the preset WebRTC native media pipeline, and combine the independent master key, the preset synchronization source identifier and the preset frame sequence number as the key derivation of the frame-level encryptor to generate a unique key for each frame. S103. Based on the synchronization source identifier, the client decrypts the unique key for each frame using the independent master key; S104. Detect the network switching status of the image acquisition device, trigger the connection reset mechanism, and do not re-execute S101 within a preset time, and reuse the independent master key.

2. The end-to-end encrypted P2P direct connection monitoring method based on WebRTC according to claim 1, characterized in that, S101 includes: S1011. Obtain the client's connection request to the image acquisition device, transmit the public key and certificate of the image acquisition device to the client, and have the client verify the certificate; S1012. The temporary random number generated by the client is encrypted using the public key and transmitted to the image acquisition device, which then decrypts it using its built-in private key. S1013. Based on a preset key exchange algorithm, derive independent master keys for the client and the image acquisition device.

3. The end-to-end encrypted P2P direct connection monitoring method based on WebRTC according to claim 2, characterized in that, S101 further includes: S1014. Force the image acquisition device to collect several candidate ICE addresses; S1015. The connectivity of each candidate ICE address is periodically detected, and it is determined whether a P2P candidate pair is established within a preset time. S1016. If the connection is not established within the timeout period, a signaling message indicating that the client connection failed is sent back, pending authorization from the client to allow the pre-configured TURN server to forward the connection.

4. The end-to-end encrypted P2P direct connection monitoring method based on WebRTC according to claim 3, characterized in that, The frame-level encryptor is set after the encoder output and before the RTP packet encapsulation in the WebRTC native media pipeline.

5. The end-to-end encrypted P2P direct connection monitoring method based on WebRTC according to claim 4, characterized in that, The frame-level encryptor uses the AES-256-GCM encryption algorithm.

6. The end-to-end encrypted P2P direct connection monitoring method based on WebRTC according to claim 5, characterized in that, The unique key for each frame is generated by combining the independent master key, the synchronization source identifier, and the frame sequence number using the HMAC-SHA256 algorithm.

7. The end-to-end encrypted P2P direct connection monitoring method based on WebRTC according to claim 6, characterized in that, S104 further includes: S1041. Construct a key rollover mechanism, setting the image acquisition device to update the independent master key again when the preset time or the cumulative amount of encrypted data reaches a threshold.

8. An end-to-end encrypted P2P direct connection monitoring system based on WebRTC, characterized in that, include: The key derivation module is used to obtain the independent master key derived by the image acquisition device and the client during the encrypted connection. An independent encryption module is used to insert a frame-level encryptor into a pre-configured WebRTC native media pipeline. It combines the independent master key, a pre-configured synchronization source identifier, and a pre-configured frame sequence number as the key derivation for the frame-level encryptor to generate a unique key for each frame. The decryption module is used to decrypt the unique key of each frame using the independent master key based on the synchronization source identifier; The reuse module is used to detect the network switching status of the image acquisition device, trigger the connection reset mechanism, and not re-execute the key derivation module within a preset time, and reuse the independent master key.

9. An end-to-end encrypted P2P direct-connection image acquisition device based on WebRTC, characterized in that, The WebRTC-based end-to-end encrypted P2P direct connection image acquisition device includes: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a line; The at least one processor invokes the instructions in the memory to cause the WebRTC-based end-to-end encrypted P2P direct connection image acquisition device to execute the WebRTC-based end-to-end encrypted P2P direct connection monitoring method as described in any one of claims 1-7.

10. A computer-readable storage medium storing a computer program thereon, characterized in that, When the computer program is executed by the processor, it implements the WebRTC-based end-to-end encrypted P2P direct connection monitoring method as described in any one of claims 1-7.

Images