Camera shooting equipment, video data processing method and device and medium

Abstract

The invention relates to camera equipment, a video data processing method and device and a medium, and the method comprises the steps: responding to a privacy mode activation request, and determining a public key which is pre-bound with initial terminal equipment and is associated with the request from an equipment public key list locally stored in the current camera equipment; encrypting the collected video stream by using a pre-generated session key to obtain encrypted video data; encrypting the session key by using a public key to obtain a key data packet; and uploading encrypted video data and the key data packet to a remote storage space through a server communication path, so that an initial terminal device decrypts the key data packet by using a private key matched with the public key to obtain a session key, and decrypts the encrypted video data according to the session key to restore an original video stream. According to the method, the risks of cloud data leakage and internal peeping can be fundamentally eradicated, and the data control right is returned to the user.

Description

Technical Field

[0001] This application relates to the field of data security, and in particular to a camera device, video data processing method and apparatus, and medium. Background Technology

[0002] With the popularization of IoT technology, smart security cameras have been widely used in homes and commercial spaces, providing users with remote monitoring services. In existing technologies, typical network video surveillance systems usually adopt a client-server architecture. Under this architecture, the audio and video data collected by the camera equipment is encoded and then transmitted via the internet to a cloud service platform for storage and forwarding. Authorized users can request and view the video stream from the cloud through their terminal devices. To ensure data security, the industry generally adopts transmission channel encryption technology, such as encrypting the transmission link, to prevent data from being eavesdropped on during transmission.

[0003] To further enhance security, some traditional technologies employ more advanced hybrid encryption methods. However, without exception, these methods submit the encryption key along with the encrypted video data to the cloud server. This means that from the perspective of the cloud server's core role and permissions, it possesses not only the encrypted data but also the corresponding key. The cloud service platform is not merely a data channel but also deeply involved in key management and access control. For example, the distribution of public keys requires relaying through the cloud server, which technically allows the cloud to always have access to and even hold the decryption key. Although the data transmission process is encrypted, the video data may exist in plaintext on the cloud server, or the cloud service provider may hold the necessary decryption key for transcoding, intelligent analysis, and other purposes. Technically, this centralized data processing model means that all user video data converges at a single control point in the cloud.

[0004] Based on this technical principle, traditional solutions will at least lead to the following corresponding technical problems: Once the security protection of the cloud service platform is breached, such as by a hacker attack or by internal personnel abusing administrative privileges, the massive amount of user video data stored in the cloud will face the risk of large-scale leakage. Since the cloud has the technical ability to access data, user privacy and security depend entirely on the security measures and management systems of the cloud service provider, rather than on the technology itself. This technical model, which completely relinquishes data control to a third party, cannot fundamentally solve the problems of data leakage and internal spying in the cloud, leaving users' sensitive video information with potential security risks. This technical problem is directly related to user data sovereignty and privacy security, and is a critical pain point that urgently needs to be addressed in the current technical architecture. Summary of the Invention

[0005] The primary objective of this application is to solve at least one of the above-mentioned problems by providing a camera device, video data processing method and apparatus, and medium.

[0006] To achieve the various objectives of this application, the following technical solution is adopted: A video data processing method provided for one of the purposes of this application includes the following steps: In response to the privacy mode activation request, determine the public key pre-bound to the initial terminal device associated with the request from the list of device public keys stored locally on the current camera device; The captured video stream is encrypted using a pre-generated session key to obtain encrypted video data; The session key is encrypted using the public key to obtain a key data packet; The encrypted video data and the key data packet are uploaded to a remote storage space via a server communication path, so that the initial terminal device can use a private key paired with the public key to decrypt the key data packet to obtain the session key, and decrypt the encrypted video data according to the session key to restore the original video stream.

[0007] A video data processing apparatus, proposed for one of the purposes of this application, comprises: The request-response module is configured to respond to privacy mode activation requests by determining the public key pre-bound to the initial terminal device associated with the request from the list of device public keys stored locally on the current camera device. The video encryption module is configured to encrypt the captured video stream using a pre-generated session key to obtain encrypted video data; The key encryption module is configured to encrypt the session key using the public key to obtain a key data packet; The data output module is configured to upload the encrypted video data and the key data packet to a remote storage space via a server communication path, so that the initial terminal device can use a private key paired with the public key to decrypt the key data packet to obtain the session key, and decrypt the encrypted video data according to the session key to restore the original video stream.

[0008] In another aspect, a camera device provided for one of the purposes of this application includes a processor and a memory, wherein the processor invokes and runs a computer program in the memory to perform the steps of the video data processing method.

[0009] In another aspect, a computer-readable storage medium is provided to suit another purpose of this application, which stores, in the form of computer-readable instructions, a computer program implemented according to the video data processing method, which, when invoked by a computer, performs the steps included in the corresponding method.

[0010] Compared with traditional technologies, the technical solution provided in this application brings significant beneficial effects through fundamental changes at the architectural level, including but not limited to: First, this application achieves technical cloud-based security, fundamentally eliminating the risks of cloud data leakage and internal surveillance. Specifically, because video data is encrypted at the camera device using a session key that can only be decrypted by authorized terminal devices, and the public key used to encrypt this session key is securely stored locally on the camera device beforehand, the cloud service platform can only serve as a storage and transmission channel for the encrypted video data and its key data packet after they are uploaded to the remote storage space. Technically, it is completely unable to decrypt or view the video content. This shifts the guarantee of user privacy and security from relying on the cloud service provider's systems and management to being ensured by cryptographic technology itself, thereby establishing an irrefutable foundation of technical trust.

[0011] Secondly, this application effectively returns data control and sovereignty to the user. By placing the core encryption and decryption operations between the user-controlled terminal device and the camera equipment, the user becomes the sole master of their own video data, completely changing the situation in the traditional centralized model where user data control falls into the hands of a third party. This allows users to truly control the fate of their sensitive information, making it particularly suitable for sensitive scenarios such as homes and offices with extremely high privacy protection requirements, greatly enhancing users' sense of security and trust in using the product.

[0012] Furthermore, this application achieves the aforementioned extremely high level of security while maintaining practicality and compatibility. It does not require disruptive modifications to existing cloud storage infrastructure; instead, it cleverly redefines the role of the cloud in the data flow, transforming it from an active data processor into a passive data carrier. This means that the security level of the monitoring system can be seamlessly improved without sacrificing the convenience, scalability, and high availability offered by cloud storage, achieving a highly efficient balance between security and practicality. Attached Figure Description

[0013] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating a typical embodiment of the video data processing method of this application; Figure 2 This is a schematic block diagram of the video data processing apparatus of this application; Figure 3 This is a schematic diagram of the structure of a computer device used in this application. Detailed Implementation

[0014] The video data processing method provided in this application is based on a collaborative network system, primarily implemented through camera equipment within it. This network system includes camera equipment, at least one terminal device, and a cloud server located in the cloud. The camera equipment, acting as the acquisition and initial processing end for video data, is deployed in the monitored physical space, such as a home or office, and possesses image sensors, computing units, network communication modules, and secure storage areas. The terminal device is typically a user-owned smart device, such as a smartphone, tablet, or personal computer, running a dedicated client application. The cloud server provides connection intermediaries, data storage, and basic management services to the camera equipment and terminal devices via the internet, primarily undertaking the routing and storage functions of encrypted data in this architecture.

[0015] It is important to understand that this application redefines the security roles and data flow relationships of the aforementioned entities within the network architecture. Unlike traditional architectures, the cloud server in this application is strictly limited to a trusted conduit rather than a data controller. Specifically, an end-to-end secure association is established between the camera device and the terminal device. Core security operations, such as key negotiation, data encryption, and decryption, are all completed directly or indirectly between the camera device and the terminal device. The cloud server does not hold the complete key materials required to decrypt the user's video content, thereby achieving enhanced data privacy protection at the architectural level.

[0016] Based on this architecture, the video data processing method of this application is mainly embodied in a computer program (or firmware) executed on the camera device. This method can also be partially implemented by a client application on the terminal device, depending on the actual situation. When the computer program is loaded into the processor of the camera device and runs, it controls the camera device to perform a series of operations, including but not limited to key management, video capture, data encryption, and network uploading. The network uploading operation is performed through a server communication path, specifically referring to the data channel established between the camera device and the aforementioned cloud server for transmitting encrypted video data and related control information. Therefore, the scope of protection of this application also covers non-volatile computer-readable storage media storing a computer program implementing the above method, and camera devices configured by the program to perform specific functions.

[0017] To facilitate understanding of the following embodiments, some core concepts involved in this application are explained in a preliminary manner. The so-called end-to-end secure channel in this application refers to a communication path independent of the server communication path, used to securely transmit sensitive information, such as public keys for encryption, between the camera device and the terminal device. Its establishment method may include near-field communication or secure relay via a cloud server, but the core is to ensure that the transmitted content is not visible to the cloud server.

[0018] When preset activation conditions are met, the camera device can enter privacy mode. Privacy mode refers to a special operating state of the camera device in which end-to-end encryption is enabled for the video stream. The device public key list in the camera device is an authorized list stored in the local secure area of ​​the camera device. It records the identity of the terminal devices authorized to access the end-to-end encrypted video and their corresponding asymmetric encryption public keys, serving as the local basis for access control decisions.

[0019] Furthermore, in certain embodiments, this application will introduce the concept of a security server, which is essentially the functional role played by the cloud server in undertaking specific security verification services such as issuing and verifying security tokens. The two are usually in the same server cluster in terms of physical entities, but have different logical functions.

[0020] In summary, subsequent embodiments will be described in detail within the context of this network architecture and conceptual foundation. Readers should understand that by executing the methods and procedures of this application, the camera device transforms from a simple data collector into an intelligent terminal with local security decision-making and data processing capabilities, which is key to achieving the aforementioned beneficial effects. Based on an understanding of the above application scenarios and network architecture, subsequent embodiments will revolve around the aforementioned hardware and software environment and concepts. The following will continue to elaborate on various embodiments of this application.

[0021] Please see Figure 1 In some embodiments, the video data processing method of this application can be implemented as an application running in a camera device, and the method includes: Step S3100: In response to the privacy mode activation request, determine the public key pre-bound to the initial terminal device associated with the request from the list of device public keys stored locally on the current camera device; The camera device stores a list of device public keys in its local secure storage area. This list is generated after the camera device and the terminal device have successfully completed an end-to-end secure binding, and is updated every time a terminal device binds to or unbinds from the camera device. It records the association between the identity of the authorized terminal device, such as the initial terminal device, and its corresponding asymmetric encryption public key.

[0022] When a privacy mode activation request is triggered, the processor of the current camera device executes pre-set computer program instructions to access and parse the request. The parsing process includes identifying the source of the request or specific identification information carried within it—that is, the identity of the initial terminal device—to determine which bound terminal device initiated the request or which bound terminal device needs to have privacy mode activated. Subsequently, the processor performs a query operation in the device public key list, searching for an entry that matches the parsing result. The matching criteria include the unique identity of the terminal device, such as the device serial number or a globally unique identifier assigned by the system. Upon successful matching, the processor extracts the public key associated with that entry.

[0023] Because the device's public key list resides in the camera device's local secure storage area, access control decisions rely entirely on this locally stored data, eliminating the need for any queries to the cloud server during the decision-making process. This localized decision-making mechanism forms the basis for a cloud-based, crime-free design, ensuring that even if the network connection between the camera device and the cloud server is interrupted, or if there are security risks on the cloud server, the encryption behavior in privacy mode can still be correctly executed according to the pre-established security policy. The device's public key list, as the sole basis for access control, can be stored in the camera device's trusted execution environment or in a hardware-protected storage area such as a secure chip to prevent malicious tampering.

[0024] In one embodiment, the privacy mode activation request can originate directly from an explicit instruction sent by the initial terminal device. For example, the user can manually click the button to enable privacy mode through the application interface on the initial terminal device. In this case, the request will contain the identity identifier of the terminal device, and the camera device can obtain the public key of the terminal device accordingly.

[0025] In another embodiment, the request can be automatically generated directly or indirectly by the monitoring service module of the camera device when preset conditions are met. For example, if the initial terminal device has left the home area based on geofencing technology, the monitoring service module generates an internal request and specifies the identity of the terminal device that needs to enable privacy mode according to the policy, and determines the public key from the device public key list accordingly.

[0026] Step S3200: Encrypt the acquired video stream using the pre-generated session key to obtain encrypted video data; After successfully identifying the public key corresponding to the initial terminal device from the device public key list, the camera device's processor begins encrypting the video data. This is done by using a pre-generated session key to encrypt the captured raw video stream, thus obtaining encrypted video data. The session key can be a symmetric encryption key, randomly generated by the camera device as needed, and its lifespan is associated with a single communication session or a specific encryption period; for example, it can be dynamically generated once for each privacy mode activation session.

[0027] Session keys can be generated within a secure environment of the camera device, such as by a built-in cryptographically secure random number generator. A typical implementation of this session key includes an AES (Advanced Encryption Standard) key, with a key length selectable based on the desired security level, such as AES-128 or AES-256. Session keys can be generated after responding to a privacy mode activation request but before starting the encrypted video stream to ensure key freshness.

[0028] In one embodiment, the encryption of the video stream can employ full-frame encryption. The camera device's processor invokes an encryption algorithm library and uses a generated session key to encrypt the raw video frame data output by the video acquisition module in real time. The raw video stream acquired by the camera device is typically already compressed and encoded, such as in H.264 or H.265 format. The encryption operation is applied to the compressed bitstream data, encrypting consecutive frame sequences to generate ciphertext data blocks. These ciphertext data blocks are then combined sequentially to form the encrypted video data.

[0029] In another embodiment, a selective encryption strategy can be employed to balance security and processing efficiency. In this embodiment, the processor determines the portion of data requiring encryption from the acquired video stream according to a preset encryption strategy, and encrypts only this target data to obtain encrypted video data. The target data can be keyframes in the video stream, a set of sequence parameters from the video stream, or both.

[0030] In another embodiment, the target data can be encrypted using the session key of this application, while other video stream data other than the target data can be encrypted using other preset lightweight encryption methods to finally obtain encrypted video data.

[0031] Once the encryption process is complete, the resulting encrypted video data is cryptographically processed ciphertext that cannot be directly viewed. This encrypted video data, along with the key data packets generated in subsequent steps, is prepared for secure transmission to remote storage. The entire encryption process is completed locally on the camera device; the cloud server does not participate in encryption / decryption operations and has no way of obtaining the plaintext session key or video data, thus ensuring privacy and security at the source of data generation.

[0032] Step S3300: Encrypt the session key using the public key to obtain a key data packet; After encrypting the video stream using the session key to obtain encrypted video data, the camera device needs to ensure that the session key can be securely transmitted to the authorized initial terminal device, while preventing any third party, including cloud servers, from obtaining it. To this end, the camera device will perform an operation to encrypt the session key using the initial terminal device's public key, thereby obtaining a key data packet.

[0033] Specifically, the camera device's processor invokes an asymmetric encryption algorithm pre-protocoled with the initial terminal device, using a public key determined from the device's public key list and bound to the initial terminal device, to encrypt the aforementioned generated session key. This public key is provided by the initial terminal device during the binding phase via an end-to-end secure channel, while the paired private key is securely stored locally on the initial terminal device and never leaves. After the encryption operation is complete, the plaintext session key is converted into ciphertext, which, like the encrypted video data, is unreadable to the cloud server.

[0034] The encrypted result, i.e., the ciphertext of the session key, together with other necessary metadata information, constitutes the key data packet. Metadata information may include an identifier for this encrypted session, the terminal device identity corresponding to the public key used, the encryption algorithm identifier, and the initialization vector, etc. The format of the key data packet can be defined according to the actual protocol; for example, a specific data encapsulation structure can be used to serialize and package the ciphertext and metadata. In one embodiment, the key data packet can be constructed as a lightweight binary structure, containing a fixed header and a variable-length data body. The header stores metadata, and the data body stores the encrypted session key ciphertext. In another embodiment, standard text formats such as JSON or XML can also be used for encapsulation, facilitating cross-platform processing.

[0035] The asymmetric encryption algorithm used can be a variety of mature standard algorithms. In one embodiment, the RSA algorithm can be used, encrypting the session key with the public key; its security is based on the difficulty of factoring large integers. In another embodiment, an elliptic curve-based ECC algorithm, such as ECIES, can also be used, offering advantages such as shorter key length and higher computational efficiency while providing equivalent security strength. Parameters that may be used during encryption, such as the padding scheme, can be determined specifically based on the selected algorithm; for example, when using the RSA algorithm, the OAEP padding scheme can be applied to enhance security.

[0036] The security of the final generated key data packet relies entirely on the private key corresponding to the public key used. Since only the authorized initial terminal device possesses this private key, theoretically only that device can successfully decrypt the key data packet and recover the plaintext session key. At this point, the session key is securely encapsulated within the key data packet, preparing it for the next step of uploading it along with the encrypted video data to remote storage, ensuring end-to-end confidentiality.

[0037] Step S3400: Upload the encrypted video data and the key data packet to a remote storage space through a server communication path, so that the initial terminal device can use the private key paired with the public key to decrypt the key data packet to obtain the session key, and decrypt the encrypted video data according to the session key to restore the original video stream.

[0038] After locally generating the encrypted video data and key data packet, the camera device initiates the data upload process. This process transmits the encrypted video data and key data packet to remote storage space via the server communication path. The server communication path refers to the network channel established between the camera device and the cloud server for data transmission. Its underlying layer can be based on the TCP / IP protocol suite, and secure transport layer protocols such as TLS / SSL can be used to encrypt the communication link to ensure the security of data transmission and prevent data from being eavesdropped on or tampered with.

[0039] In one embodiment, the upload operation can manifest as the camera device actively initiating a network request to the cloud server, such as via an HTTP POST request or an HTTPS PUT request, sending encrypted video data and a key data packet as the request payload to a resource endpoint specified by the cloud server. Upon receiving the request, the cloud server stores it in a persistent storage system, such as an object storage service or a distributed file system, thus completing the saving in remote storage space. In another embodiment, the upload process can also be based on a specific streaming protocol, such as RTMP or a proprietary UDP-based protocol, to achieve low-latency, real-time uploading of video data. Regardless of the specific communication protocol used, the cloud server's role in this process is strictly limited to a data receiver, storer, and forwarder; it cannot parse the content of the encrypted video data, nor can it decrypt the key data packet to obtain the session key.

[0040] Once the encrypted video data and key data packet are uploaded to the remote storage space, they become accessible to authorized terminal devices, including the initial terminal device itself. When the initial terminal device needs to view the video, its client application can send a request to the cloud server to retrieve the data. The cloud server responds to this request by sending the stored encrypted video data and the corresponding key data packet to the initial terminal device over the network.

[0041] After receiving the data, the initial terminal device first processes the key data packet. Its client application uses a private key that matches the public key used to encrypt the session key in step S3300 to decrypt the ciphertext portion of the key data packet that has undergone asymmetric encryption. This private key is always securely stored within the secure area of ​​the initial terminal device, such as the secure element or trusted execution environment of a smart device, and never leaves the device. Successful decryption restores the plaintext session key, thus ensuring that only authorized devices holding the corresponding private key can obtain the session key; no third party, including cloud servers, can perform this operation.

[0042] After successfully obtaining the plaintext session key, the initial terminal device uses this session key to decrypt the encrypted video data. The decryption process is the inverse operation of the encryption process and requires the same symmetric decryption algorithm as encryption, such as AES. The client application performs decryption calculations on the received encrypted video data ciphertext to reconstruct the compressed and encoded original video stream, such as an H.264 or H.265 format stream. Finally, this video stream is sent to the decoder for decoding and ultimately presented as the original video image for the user to view through the display device.

[0043] As can be seen from the above embodiments, this application constructs a complete end-to-end video data security processing system, which achieves multi-dimensional and in-depth technical advantages compared to traditional architectures, specifically manifested as follows: First, this application fundamentally achieves the neutralization and unreadable nature of cloud data. By completely pre-emptively implementing encryption at the data source—the camera device—and utilizing a key encapsulation mechanism where decryption is only possible with the private key held by the initial terminal device, it ensures that video data is under strong cryptographic protection from the very beginning of its generation. This completely eliminates the cloud server's ability to directly access and decrypt video content, redefining its role as a reliable but unsuspecting data pipeline and storage repository. This fundamental architectural change shrinks the risk of data breaches from the vast cloud network boundaries to the user's own controllable terminal devices, effectively curbing catastrophic privacy breaches caused by large-scale attacks on the cloud platform or abuse of privileges by internal personnel.

[0044] Secondly, this application demonstrates exceptional precision in privacy control and dynamic responsiveness. Activation of privacy mode no longer relies on simple, easily forgotten manual operations by the user, but rather is intelligently linked to specific usage scenarios and contexts. Whether based on explicit user commands or automatically triggered by preset conditions such as geofencing and time policies, it accurately determines when the highest level of privacy protection needs to be activated. This ensures that privacy protection seamlessly integrates into the user's daily life, automatically activating a robust protective barrier when needed, and maintaining system availability and functionality when not required, thus achieving a high level of balance between ultimate security and user convenience.

[0045] Furthermore, this application demonstrates significant security autonomy and system robustness. Critical access control decisions rely entirely on a list of device public keys stored locally on the camera, eliminating the need for cloud lookups in the decision chain. This localized decision-making mechanism endows the system with a high degree of autonomy; even in the event of a temporary network connection interruption to the cloud server, a failure of the cloud service itself, or even a security threat, the camera can still independently and correctly perform encryption operations according to the established security policy. This decentralized security model greatly enhances the stability and reliability of the camera in the face of uncertainties such as network fluctuations or partial infrastructure failures.

[0046] Furthermore, this application also possesses excellent performance optimization potential and architectural compatibility. By introducing selective encryption strategies, the allocation of computing resources can be flexibly adjusted according to actual security needs. For example, high-strength encryption can be applied only to key frames that determine the quality of video decoding, ensuring the protection of core visual information while significantly reducing the computational burden on the device, lowering power consumption and transmission latency, enabling this technical solution to run efficiently on resource-constrained embedded devices. Simultaneously, it does not require disruptive modifications to existing cloud storage infrastructure; instead, through logical redefinition, it cleverly leverages the reliability and scalability of existing cloud services, achieving a smooth integration of security enhancements with the existing technological ecosystem.

[0047] It is evident that this application not only precisely addresses the inherent flaws of cloud data leakage and internal spying under traditional architectures, but also achieves comprehensive technological breakthroughs in areas such as intelligent privacy control, autonomous system operation, and efficient resource utilization, providing a solid technical foundation for realizing truly user-centric data sovereignty and security.

[0048] Based on any embodiment of the method in this application, before determining the public key pre-bound to the initial terminal device associated with the request from the list of device public keys locally stored in the current camera device in response to the privacy mode activation request, the method includes: Step S2100: In response to the device binding command triggered by the initial terminal device, generate a paired public key and private key in the initial terminal device, and associate the public key with the identity identifier of the initial terminal device; When a user needs to bind their initial terminal device to the camera device, a device binding command is triggered through the initial terminal device. This command can be initiated by the user running a dedicated client application on the initial terminal device and performing a specific operation through the application interface, such as clicking "Add New Device" or scanning a QR code provided by the camera device. After receiving the user's binding intention, the client application generates and processes the device binding command.

[0049] In response to this device binding command, the initial terminal device will perform an asymmetric key pair generation operation locally. The generation process typically takes place within a secure execution environment of the terminal device, such as utilizing a trusted execution environment built into the smart terminal or cryptographic services provided by a security chip. In one embodiment, an industry-standard key generation algorithm may be used, such as the RSA algorithm or an elliptic curve-based ECC algorithm. For the RSA algorithm, the key length can be selected to be 2048 bits or longer to ensure security strength; for the ECC algorithm, a standard curve such as secp256r1 can be selected. The generated key pair includes a public key and a paired private key, the private key being securely stored in a protected storage area of ​​the terminal device, ensuring it never leaves the device and cannot be directly accessed externally.

[0050] After successfully generating the key pair, the initial terminal device needs to establish an association between the public key and its own identity identifier. The identity identifier is information used to uniquely identify the initial terminal device in the system. Its specific forms include, but are not limited to, the device serial number assigned by the device manufacturer, a globally unique identifier assigned by the operating system, or a unique user account identifier assigned by an application or cloud service platform. The purpose of the association operation is to strongly bind the generated public key to the identity of the terminal device, so that the public key can clearly represent this specific device. In one embodiment, this association can be represented by creating a data structure locally on the terminal device to store the public key data and the identity identifier together. In another embodiment, a higher level of binding can also be achieved by generating a digital certificate. That is, the terminal device itself or a trusted certificate authority uses its private key to sign the information containing the public key and identity identifier, generating a certificate file. This certificate file itself proves the association between the public key and the identity identifier.

[0051] After key generation and identity association are completed, the initial terminal device is ready to transmit its public key and identity identifier to the camera device through an end-to-end secure channel. This ensures that the trust upon which all subsequent encrypted communications rely stems from a cryptographic identity generated and strictly controlled by the terminal device itself. The entire key pair generation and association process is completed locally on the terminal device; the cloud server does not participate in this process, thus avoiding the risk of key materials being intercepted or controlled by a third party during the generation stage from the very beginning.

[0052] Step S2200: Using an independent transmission path separate from the server communication path as an end-to-end secure channel, the public key and associated identity identifier of the initial terminal device are obtained through this channel and stored in the device public key list of the current camera device to achieve binding; This step aims to achieve a fundamental paradigm shift, transforming the way secure trust is established between devices from a traditional, centralized cloud-dependent vertical authorization model to a decentralized, direct peer-to-peer authentication model. To this end, a separate transmission path, independent of the server communication path, is defined as the sole legitimate end-to-end secure channel for establishing trust. While the technical implementation of this end-to-end secure channel can vary, its architectural constraints are rigid, ensuring that the transmission path of the credentials used to establish trust—namely, the public key and identity identifier—physically or logically bypasses the cloud server. This design fundamentally deprives the cloud of its participation in the initial trust chain establishment process.

[0053] The constraint of transmitting public keys and identity credentials through an end-to-end secure channel fundamentally alters the inherent properties of the trust model. Because trust credentials do not pass through the cloud, their transmission is private, unseen and unaudited by the cloud. Trust is established through direct communication between devices, its security relying on cryptographic protocols and close physical interaction between devices (such as QR code scanning) or the relay of existing trust chains (such as relaying through legacy devices), rather than institutional trust in the cloud server. This makes the established trust relationship pure, existing only between the two devices; the cloud cannot claim any connection to this trust relationship, thus logically absolving itself of responsibility.

[0054] Therefore, this step shifts a crucial security control point forward, moving the most sensitive and critical key distribution operation from a stage where the system continuously relies on the cloud during runtime to the one-time initialization phase of device pairing, and placing this phase within a security boundary inaccessible to the cloud. The camera device stores the public key and identity identifier belonging to the initial terminal device, delivered via an end-to-end secure channel, as a mapping data in its device public key list, thus completing the binding with the initial terminal device. Once binding is complete, all subsequent encrypted communication is built upon a pre-established, robust foundation of trust that cannot be interfered with by the cloud.

[0055] Step S2300: Start listening for privacy mode activation requests that match the privacy mode activation conditions set by the initial terminal device.

[0056] After successfully completing the secure binding between the camera device and the initial terminal device, and storing the initial terminal device's public key and identity identifier in the device's public key list, the camera device needs to possess the capability to automatically or prepare to enter a privacy-oriented working mode according to a preset policy. This capability can be achieved by activating a dedicated monitoring service. This monitoring service continuously monitors specific events or state changes both inside and outside the entire system, and determines whether these events or states meet the privacy mode activation conditions preset by the initial terminal device.

[0057] Once started, the monitoring service runs as a persistent process or background task in the background of the camera device, and its lifecycle is usually consistent with the normal operation of the camera device. The monitoring service can be started automatically immediately after the device binding process is successfully completed, or it can be manually or automatically enabled according to the configuration policy after the camera device initialization is completed.

[0058] The privacy mode activation conditions monitored by the monitoring service can be implemented as policy rules set by the initial terminal device or its associated user and sent to the camera device. These rules define the scenarios or states in which end-to-end encrypted privacy mode needs to be automatically enabled. In one embodiment, the activation condition can be a time-based policy, such as setting the privacy mode to automatically turn on during specific time periods each day. In another embodiment, the activation condition can be based on the device's geographic location, such as being triggered when the initial terminal device leaves the home geofence. Furthermore, the activation condition can also be based on explicit, immediate user commands.

[0059] During operation, the monitoring service continuously compares the monitored real-time data with preset activation conditions. This comparison logic can be built into the firmware of the camera device, or partially or wholly embedded in the cloud server. Its implementation includes, but is not limited to, simple conditional state machines, or more complex rule-based inference engines. When the monitoring service detects that the current system state meets any one or more of the preset privacy mode activation conditions, it triggers an internal privacy mode activation request. This request is a clear internal system signal indicating that the system needs to switch from normal operating mode to a high-security privacy mode.

[0060] In the above embodiments, the complete technical chain from device security binding to intelligent monitoring startup has achieved richer and more positive technical effects in terms of deepening the creativity of technical solutions, including but not limited to: First, by placing the generation, association, and secure distribution of asymmetric key pairs entirely under the control of the user's terminal device, and employing an end-to-end secure channel independent of the cloud from the initial stage, the model for establishing trust relationships between devices is fundamentally reshaped, achieving decentralization and user autonomy in the security foundation. This not only completely eliminates the risk that the cloud may become a single point of failure or a target for theft in the key distribution stage in traditional architectures, but also substantially returns control of data sovereignty to the user at the technical level.

[0061] Secondly, the introduced intelligent monitoring service mechanism upgrades privacy protection from passive, static, manual operation to proactive, dynamic, and context-aware automated behavior. It continuously monitors various contextual signals such as time, geographical location, and user commands, and automatically triggers high-security privacy modes based on preset policies. This significantly reduces the possibility of privacy leaks due to user negligence, improving the reliability of security protection and the seamless user experience. This intelligent response capability allows security protection to seamlessly integrate into real-life scenarios, achieving a high-level balance between security and convenience.

[0062] Furthermore, the organic integration of the above-mentioned elements constitutes a resilient, adaptive, and locally-rooted proactive defense system. This system does not rely on the continuous online presence or absolute trust of cloud servers; even in the event of network outages or cloud unavailability, locally pre-configured security policies and binding relationships can still ensure the normal operation of core privacy functions. This architectural robustness and independence signifies a paradigm shift in video surveillance systems from vulnerable pipelines relying on external safeguards to intelligent terminals with inherent security capabilities.

[0063] Based on any embodiment of the method in this application, an independent transmission path, independent of the server communication path, is used as an end-to-end secure channel. The public key and associated identity identifier of the initial terminal device are obtained through this channel and stored in the device public key list of the current camera device to achieve binding, including: Step S2210: Create an independent transmission path between the current camera device and the initial terminal device, independent of the server communication path, as an end-to-end secure channel; After generating the asymmetric key pair and associating the identity locally on the initial terminal device, a secure trust relationship is further established between the camera device and the initial terminal device. The public key and identity identifier are securely transmitted through an end-to-end secure channel independent of the regular server communication path. The characteristic of this end-to-end secure channel is that its data transmission path does not pass through a cloud server for relay or processing, thus ensuring that the exchanged sensitive information remains invisible to the cloud server, fundamentally avoiding the potential leakage risk during the key distribution process.

[0064] In some embodiments, this end-to-end secure channel can be established using near-field communication (NFC) technology. Specifically, the initial terminal device can encode its public key and associated identity into a QR code and display it on its screen. The user points the camera of the camera device at the QR code, and the camera device scans and parses the QR code content using image recognition technology, thereby directly obtaining the public key and identity. Another NFC method utilizes Bluetooth or Wi-Fi Direct technology to establish a point-to-point wireless communication link directly when the camera device and the initial terminal device are in close physical proximity, transmitting the public key and identity through this link. Yet another NFC method can directly utilize NFC communication between the camera device and the terminal device for end-to-end transmission of the public key and identity. NFC methods rely on physical contact or close proximity constraints, offering extremely high security.

[0065] In another embodiment, when near-field operation is not possible, an end-to-end secure channel can be simulated through an established, trusted remote path. For example, a user can first log in to the system through an old terminal device already bound to the camera device (acting as a trusted intermediary). After the new terminal device (i.e., the initial terminal device) generates a key pair, it sends the public key and identity identifier to the old terminal device. The old terminal device forwards this information to the camera device through its existing secure channel with the camera device (which may itself also be established via near-field operation). During this process, the cloud server can participate in network routing, but it cannot decrypt or tamper with the data content encrypted and forwarded by the old terminal device; the security of the public key material is guaranteed by the trust chain between the terminal devices.

[0066] Step S2220: Receive the public key and associated identity identifier from the initial terminal device through the end-to-end secure channel, and write the public key and associated identity identifier into the device public key list of the current camera device; After successfully receiving the public key and associated identity identifier from the initial terminal device through any of the aforementioned end-to-end secure channels, the camera device immediately performs a binding operation locally. The camera device's processor adds the received public key and identity identifier as a new entry to the device public key list maintained in its local secure storage area. Each entry in the device public key list records the mapping relationship between the identity identifier of an authorized terminal device, such as the initial terminal device, and its corresponding public key. The writing process must ensure data integrity and consistency; in one embodiment, a transactional write mechanism can be used to prevent data corruption. After the binding operation is completed, the initial terminal device is officially authorized, and its public key will be used for encryption of the session key in subsequent privacy mode.

[0067] Step S2230: Send a confirmation message back to the initial terminal device so that the initial terminal device adds the current camera device to its camera device list.

[0068] To ensure the integrity and trustworthiness of the binding process, in one embodiment, after successfully storing the public key information in the device's public key list, the camera device can send a binding confirmation message back to the initial terminal device. This message can be signed by the camera device using the initial terminal device's public key, and verified by the initial terminal device using the private key paired with the public key just sent to the camera device. Once verified, the binding is confirmed, thus mutually confirming its successful establishment. At this point, a cryptographically based trust relationship is established between the camera device and the initial terminal device, laying the foundation for secure video data transmission subsequently.

[0069] The above embodiments achieve fundamental architectural innovation by completely separating the physical path of trust establishment from logical control. First, a trust injection path independent of the cloud is defined at the physical level as an end-to-end secure channel. This completely bypasses the cloud server, a traditional data hub, in the distribution of core key materials, fundamentally eliminating the possibility of the cloud playing any role in the initial trust chain and achieving decentralized laying of the security foundation. Second, by writing public keys and identity identifiers into the device's public key list, it is ensured that the establishment of trust relationships is entirely autonomously completed by the terminal device, with the cloud unable to interfere with or perceive its decision-making logic. Finally, a strong cryptographic authentication two-way handshake mechanism is introduced, using public key signatures to confirm messages, upgrading the traditional one-way registration to peer-to-peer identity recognition between devices. This not only completes the binding loop at the operational level but also establishes an unbreakable point-to-point trust relationship between devices at the cryptographic level, one that the cloud cannot claim as an affiliate. Therefore, it provides the most critical and initial trust anchor for achieving the goal of cloud deregulation, marking a substantial transfer of data control from the service provider to the user device.

[0070] Based on any embodiment of the method in this application, initiating the listening for privacy mode activation requests that match the privacy mode activation conditions set by the initial terminal device may include any one or more of the following embodiments: In one embodiment, the current camera device initiates a listening service to continuously monitor time condition data that matches the privacy mode activation conditions set by the initial terminal device. When the time condition data meets the time condition in the privacy mode activation conditions, the privacy mode activation request is triggered. The monitoring service deployed on the camera device can be a persistent time-monitoring service. This service monitors the system time and compares it with a preset time policy to determine whether a privacy mode activation request has been triggered. The time policy can be set and issued to the camera device by the initial terminal device or its authorized user during the binding phase or through subsequent management instructions. It is usually stored in the camera device's local non-volatile memory in the form of a data structure. A typical policy data structure may contain the following fields: a unique identifier for the policy, the enabled weekday cycle (e.g., Monday to Friday), the daily start and end times (e.g., set to 22:00 to 06:00 the next day), and the policy's enabled status flag. The time monitoring service loads these valid policies from storage upon startup.

[0071] The time monitoring service wakes up periodically (e.g., every minute) or listens for interruptions in the system's real-time clock to obtain the current accurate system time. The service then performs a one-to-one matching calculation against all enabled time policies. The matching logic includes determining whether the current date falls within the weekday cycle specified by the policy, and whether the current time falls within the start and end time intervals defined by the policy. To improve energy efficiency, the monitoring service can enter a low-power sleep state during periods when activation is clearly unnecessary (e.g., several hours after the policy's effective time ends), and resume high-frequency monitoring in advance as the next policy effective time approaches.

[0072] When the matching calculation results indicate that the current system time meets the time condition of any policy—for example, when the system time reaches 22:00—the listening service will immediately generate and trigger a privacy mode activation request. This request is an internal system event that carries necessary contextual information, such as the matched policy ID, the trigger timestamp, and the associated terminal device identity.

[0073] Upon receiving the activation request, the processor verifies its validity and then switches from normal operating mode to privacy mode. The switching process includes: retrieving the corresponding public key from the local device public key list based on the terminal device's identity identifier in the request; starting the session key generator; and beginning to use the session key to encrypt the captured video stream in real time.

[0074] Throughout the entire implementation process of the above embodiments, from condition monitoring and event triggering to mode switching, everything is automatically completed locally on the camera device without the need for cloud server intervention or manual user operation, thus achieving a high degree of automation and intelligence in privacy protection.

[0075] In another embodiment, the current camera device initiates a listening service, which drives the server in the server communication path to continuously monitor whether the real-time geographical location of the initial terminal device meets the privacy mode activation conditions set by the initial terminal device. When the real-time geographical location meets the location conditions in the privacy mode activation conditions, the privacy mode activation request is triggered. The implementation of this embodiment relies on the collaborative work of the camera device, the cloud server, and the initial terminal device. First, the monitoring service initiated by the camera device does not perform geofencing calculations locally, but instead sends a continuous geolocation monitoring request to the cloud server. This request includes privacy mode activation conditions pre-set and issued by the initial terminal device, the most crucial of which is the geofencing policy. This policy includes a preset security zone (e.g., a 100-meter radius centered on the home address) and a trigger action (e.g., activating privacy mode when the device "leaves" the zone). After receiving this monitoring task, the cloud server continuously and frequently obtains the real-time geolocation of the initial terminal device through interfaces provided by the client application running on the terminal device (such as GPS, Wi-Fi, or cell tower location data from a smartphone).

[0076] The cloud server compares the acquired real-time latitude and longitude coordinates with the preset geofence boundaries in real time. A typical triggering logic is as follows: when the system detects that the initial terminal device has moved from inside the geofence to the outside (i.e., a "away from home" event), it determines that the location conditions for activating privacy mode have been met. At this time, the cloud server generates an event notification and sends a trigger signal to the requesting camera device through the server communication path. This signal is a lightweight instruction without specific location details; its core message is to inform the camera device that the preset conditions have been met.

[0077] Upon receiving a trigger signal from the cloud server, the camera's monitoring service treats it as a reliable external event. Based on this, the monitoring service generates a formal privacy mode activation request and submits it to the camera's processor. After verifying the request's legitimacy, the processor executes a series of switching operations: retrieving the public key of the corresponding initial terminal device from the device public key list, generating a session key, and initiating end-to-end encryption of the video stream. The entire process achieves a fully automated closed loop from the occurrence of the geographical event to the activation of the security mode.

[0078] Correspondingly, when the cloud server detects that the initial terminal device has re-entered the geofence from the outside (i.e., a "return home" event), it triggers a deactivation signal. Upon receiving this signal, the camera device generates a privacy mode deactivation request and discontinues end-to-end encryption. The video stream can then be reverted to plaintext transmission or use a cloud-decryptable encryption method, allowing users to conveniently view live footage via their home network upon returning home. This geolocation-based two-way triggering mechanism accurately simulates real-life scenarios: when away from home, the home space becomes a private sanctuary requiring the highest level of privacy protection; upon returning home, users need a seamless and smooth monitoring experience.

[0079] The above embodiments drive cloud servers to perform high-precision geolocation monitoring and judgment, offloading complex computing tasks to the cloud. This enables resource-constrained camera devices to implement intelligent, context-based privacy protection strategies, creating a seamless user experience. Users do not need to perform any manual operations; the system's security status can automatically and dynamically adjust according to changes in the user's physical location. This provides ultimate convenience while ensuring a perfect balance between privacy protection and practicality.

[0080] In another embodiment, the current camera device initiates a monitoring service to continuously monitor the latest user commands of the initial terminal device. When the latest user command matches the command type in the privacy mode activation conditions, the privacy mode activation request is triggered.

[0081] In this embodiment, the monitoring service initiated by the camera device is responsible for continuously monitoring the command input stream from the initial terminal device. These commands are actively issued by the user through the application interface on the terminal device, such as clicking the "Enable Privacy Mode" button or issuing specific voice commands. The monitoring service matches the latest received commands with a preset command type library (such as the command type "Activate Privacy"). Once a match is successful, an internal privacy mode activation request is immediately triggered, thereby driving the system to switch to encrypted state. The entire process forms a short-link, low-latency response from explicit user operation to change in system security state.

[0082] The direct command-based triggering mechanism described in the above embodiments ensures that users have ultimate, immediate, and absolute control over the privacy switch in any scenario. When automated strategies based on time or location cannot cover certain sudden or personalized needs, users can seamlessly intervene through proactive commands, thus establishing a perfect complement between intelligent automation and user autonomy, greatly enhancing system reliability and user trust.

[0083] Based on any embodiment of the method in this application, after uploading the encrypted video data and the key data packet to a remote storage space via a server communication path, the method includes: Step S4100: Receive the device rebinding request sent by the substitute terminal device of the initial terminal device, and obtain the security token issued by the security server, the public key generated by the substitute terminal device, and the digital signature generated by the substitute terminal device using its corresponding private key to operate on the security token. After uploading the encrypted video data and key data packet, this embodiment further provides a secure device replacement and key update mechanism. This mechanism allows users to securely authorize the new device (i.e., the replacement terminal device) as a legitimate video visitor after changing their initial terminal device (e.g., from an old mobile phone to a new one), while ensuring that the entire process complies with end-to-end security principles and that the cloud cannot obtain decryption capabilities.

[0084] When a user needs to activate a new alternative terminal device, they can initiate a device re-binding request to the camera device through that device. This request contains a structured data packet with three key elements: first, a security token issued by a security server, which serves as the cloud-based credential for verifying the legitimacy of the re-binding operation; second, a public key generated by the alternative terminal device itself, which will be used to establish a new encrypted channel; and finally, a digital signature generated by the alternative terminal device using its strictly confidential private key to digitally sign the aforementioned security token. This signature is used to prove to the camera device that it possesses a private key that matches the claimed public key.

[0085] Step S4200: Use the public key of the substitute terminal device and the security token to authenticate the digital signature, so as to verify whether the digital signature belongs to the valid signature of the security token; Upon receiving the request, the camera device initiates a two-factor authentication process to ensure continued security and trust. First, local authentication is performed. The camera device uses the public key of the substitute terminal device provided in the device re-binding request to verify the accompanying digital signature. This verifies whether the digital signature is a valid signature for the received security token. Specifically, using the same verification algorithm (such as RSA or ECDSA) used when generating the digital signature on the substitute terminal device, the camera device decrypts the digital signature using the public key and compares the decryption result with the hash value of the security token. If the comparison matches, it proves that the signature was indeed generated by the entity holding the corresponding private key, thus verifying the authenticity of the substitute terminal device's identity and its acceptance of the re-binding request.

[0086] Step S4300: Forward the security token to the security server and request it to verify the security token to verify whether the security token is a valid token applicable to the authorization process between the initial terminal device and the alternative terminal device within a preset validity period. Upon or after completing local authentication, the camera device forwards the received security token to the security server that issued it, requesting valid verification. Similarly, when transmitting the security token to the security server, the camera device's private key is used to encrypt it, generating a digital signature. The security server then decrypts this digital signature using the camera device's public key and compares their consistency. This allows the security server, acting as an authoritative third party, to determine the token's validity. Upon receiving the verification request, the security server checks whether the token's digital signature is valid, within its preset validity period, and applicable to the authorization process between the initial terminal device and the substitute terminal device. For example, if the digital signature contains a timestamp, the security server verifies whether the timestamp has expired, thereby checking if the security token has already been used and preventing replay attacks.

[0087] Step S4400: Only when both the authentication and the legitimate authentication are passed, update the public key and identity identifier of the initial terminal device in the device public key list to the public key and identity identifier of the replacement terminal device.

[0088] The final security decision is based on the results of the aforementioned dual verification. Only when both identity verification (proving the requester's identity is genuine) and legitimacy verification (proving the operation is authorized by the cloud) pass will the camera device perform the crucial key update operation. Specifically, the camera device locates the entry corresponding to the original terminal device in its locally securely stored list of device public keys, and replaces the public key and its identity information therein with the new public key and its identity information for the replacement terminal device. This means the old device immediately loses access, while the new device is officially authorized. Thereafter, all session keys generated for the new device will be encrypted using the new public key. The entire binding process is completed smoothly while ensuring security, achieving a smooth and secure transfer of permissions.

[0089] The above embodiments, by introducing a dual-authentication device rebinding mechanism based on security tokens and digital signatures, have achieved a breakthrough in the dynamism and security of key lifecycle management. Firstly, this mechanism significantly enhances security and convenience in user device replacement scenarios. Users do not need to perform complex rebinding operations; they can seamlessly connect new devices to the system through a single secure authorization process, while ensuring that the access permissions of the old device are revoked immediately and completely, effectively preventing the risk of residual permissions. Secondly, it cleverly balances end-to-end security principles with necessary centralized authorization management. By separating the verification of identity authenticity from the adjudication of operational legitimacy, it ensures that the right to update keys always remains in the hands of the true user, while introducing a secure server as a trusted third party to prevent replay attacks and control the timeliness and scope of authorization, achieving efficient synergy between decentralized security and centralized control. Therefore, this embodiment significantly improves the practicality and user experience of the entire system, enabling the highly secure end-to-end encryption system to adapt to the normal replacement of user devices in the real world, ensuring the continuity of security protection, avoiding the interruption of security policies or complex reset processes caused by device replacement, thereby maintaining an extremely high level of security while ensuring the availability of the technology and user stickiness.

[0090] Based on any embodiment of the method in this application, the acquired video stream is encrypted using a pre-generated session key to obtain encrypted video data, including: Step S3210: Perform real-time analysis on the acquired video stream to identify key frames and non-key frames; The camera equipment performs real-time analysis on the captured raw video stream to identify keyframes and non-keyframes. The video stream typically consists of a continuous sequence of image frames, using inter-frame predictive coding to compress the data volume. In this coding system, keyframes, such as I-frames in H.264 / AVC or H.265 / HEVC standards, are independently coded frames that can be decoded without relying on other frames, containing complete image information. Non-keyframes (such as P-frames or B-frames) are encoded by recording differences from adjacent frames, requiring reference to preceding keyframes or other reference frames during decoding. The identification process is performed by the camera equipment's built-in video encoder or a dedicated analysis module, which parses the video stream and marks keyframes and non-keyframes according to their encoding type.

[0091] Step S3220: Based on a preset encryption strategy, determine the target data to be encrypted. The target data corresponds to the encryption strategy of including only the key frame, or including both the sequence parameter set of the video stream and the key frame. After successfully identifying keyframes and non-keyframes in the video stream, the camera device can determine which data to encrypt based on a preset encryption strategy. This selected data is the target data. The encryption strategy is a predefined set of rules aimed at optimizing computational resource consumption and data transmission efficiency while ensuring basic security requirements. The determination of the target data directly determines the scope of the encryption operation and the final security effect.

[0092] In one embodiment, the encryption strategy can be set to encrypt only keyframes. Under this strategy, the target data only contains all keyframes identified in the video stream. Since keyframes contain complete image information and are reference frames on which decoding non-keyframes depends, encrypting only keyframes can achieve effective security control: any unauthorized party, even if it obtains the video stream, will be unable to decrypt the keyframes, causing all subsequent non-keyframes that depend on them to fail to decode correctly, thus rendering the entire video content unwatchable. Simultaneously, since the amount of non-keyframe data is typically much larger than that of keyframes, this strategy significantly reduces the total amount of data that needs to be encrypted, lowering the processing power requirements of the camera equipment.

[0093] In another embodiment, to further enhance security, the encryption strategy can be configured to simultaneously encrypt both the sequence parameter set and keyframes of the video stream. The sequence parameter set contains global decoding parameters of the video bitstream, such as image size, encoding level, and other information, which is essential for decoder initialization. Encrypting the sequence parameter set and keyframes together as target data means that an unauthorized party, unable to decrypt, will not only be unable to obtain complete image frames but may also be unable to correctly initialize the decoder, thus providing stronger protection for the video data. Although this method increases the amount of encrypted data slightly compared to encrypting only keyframes, it achieves a better balance between security and performance.

[0094] The process of identifying target data is an application of strategy decision-making. Encryption strategies can be embedded in the camera device's firmware, issued by the terminal device during the device binding phase, or remotely configured by the user via a cloud platform. Based on the currently active strategy rules, the strategy decision-making module filters out data units that meet the conditions from the parsed video frame sequence and marks them as target data to be encrypted, preparing for the next encryption operation.

[0095] Step S3230: Use the session key to encrypt the target data to obtain the encrypted video data.

[0096] After the target data is determined, the camera device encrypts the target data using a pre-generated session key to obtain the final encrypted video data. The encryption operation targets the compressed bitstream data. In one embodiment, a symmetric encryption algorithm such as AES-128 or AES-256 can be used to encrypt the target data packet in counter mode or Galois / counter mode. The encryption process generates ciphertext data blocks, which are encapsulated with unencrypted non-keyframe data according to their original timing and structure to form the encrypted video data.

[0097] The above embodiments use selective encryption to encrypt the video stream captured by the camera device, so that the encryption computation is mainly concentrated on key frames. Compared with full frame encryption, the amount of data to be processed is greatly reduced, the computational load and power consumption of the camera device are reduced, and the overall data volume of the encrypted video stream is also reduced, which is conducive to improving network transmission efficiency. Ultimately, a high-efficiency balance between security strength and system performance is achieved.

[0098] Based on any embodiment of the method in this application, after uploading the encrypted video data and the key data packet to a remote storage space via a server communication path, the method includes: Step S5100: Respond to the temporary authorization instruction sent by the initial terminal device, determine the identity identifier of the invited terminal device and the valid authorization policy in the instruction, wherein the valid policy includes the authorization validity period; After the encrypted video data and key data packet are successfully uploaded to the remote storage space, a more refined temporary access authorization mechanism can be provided to meet the needs of temporarily granting video access permissions to specific devices in scenarios such as home cleaning, pet care, or short-term visitors.

[0099] When an authorized user (i.e., the holder of the initial terminal device) needs to temporarily grant access to another device (i.e., the invited terminal device), they send a temporary authorization instruction to the camera device through the client application on the initial terminal device. This instruction explicitly specifies two key elements: the identity of the invited terminal device and the valid authorization policy. The identity is used to uniquely identify the invited terminal device in the system, and its form includes, but is not limited to, the device's MAC address, a unique device identifier assigned by the system, or a user account bound to the device. The valid policy defines the boundary conditions of this authorization, the most basic and necessary element of which is the authorization validity period, i.e., a clearly defined time interval, such as specifying from a certain start time to a certain end time, or specifying a duration calculated from the start of the authorization.

[0100] In one embodiment, the generation and sending of the temporary authorization instruction can be actively triggered by the user. For example, when a user is away from home, they may need to allow cleaning staff to check on their home during their working hours. The user can manually enter the cleaning staff's device identification information (such as scanning a QR code provided by the device) on the application interface of the initial terminal device, set a valid time period (such as 2:00 PM to 4:00 PM that day), and then click to send the instruction. In another embodiment, the instruction can also be automatically generated and sent by the initial terminal device based on preset rules. For example, the system can be set to automatically send a temporary access authorization instruction with a validity period of 2 hours to the mobile device associated with the key card when the smart door lock is opened by a specific key card.

[0101] Upon receiving a temporary authorization instruction, the camera device's processor first needs to parse and verify the instruction. The parsing process includes extracting the invited terminal device's identity and valid policy from the instruction data packet. The verification process includes checking whether the instruction's format is correct, whether the digital signature is valid (if the instruction is signed), and whether the initial terminal device initiating the instruction has the authority to perform this type of authorization. Only instructions that pass verification will be processed by subsequent steps, thereby ensuring the legality and security of the authorization operation and preventing the injection of malicious instructions.

[0102] Step S5200: Obtain the public key of the invited terminal device through an end-to-end secure channel independent of the server communication path, associate the public key and its identity identifier with the valid policy, and add it as a temporary authorization record to the device public key list; The establishment and use of the end-to-end secure channel between the invited terminal device and the camera device can be implemented according to the embodiments disclosed above in this application. After successfully obtaining the public key of the invited terminal device through the end-to-end secure channel, the camera device needs to associate and store the public key with its identity identifier and valid policy. Specifically, the camera device's processor binds the received public key data, identity identifier information, and valid policy (including parameters such as the authorization validity period) parsed from the authorization command to form a complete temporary authorization record. This record is then added to the device public key list maintained in the camera device's local secure storage area.

[0103] The storage structure of temporary authorization records in the device public key list needs to include necessary metadata fields. In one embodiment, the record may include the unique identifier of the invited terminal device, the corresponding public key data, the authorization's effective timestamp, the authorization's expiration timestamp, and the record status identifier (such as "valid" or "expired"). This information is organized into a structured data entry and stored together with other permanent binding records in the device public key list, but can be distinguished by the status identifier during querying and processing.

[0104] Step S5300: During the effective period of the temporary authorization record, its validity policy is continuously monitored. When it is detected that the current system time exceeds the validity period of the authorization or the recycling conditions in the validity policy are met, the temporary authorization record is automatically removed from the device public key list.

[0105] Monitoring effective policies can be handled by a background daemon or periodic task running locally on the camera device. This process or task is activated during the validity period of the temporary authorization record and wakes up at set time intervals, such as once per minute, or works by listening to system clock events. Its primary monitoring target is the authorization validity period. By obtaining the current precise system time and comparing it with the authorization expiration timestamp stored in each temporary authorization record in the list, when the current system time exceeds the authorization validity period of a certain record, it is determined that the record has expired, meeting the primary retrieval condition.

[0106] In addition to validity period monitoring based on absolute time, effective policies can also include more complex eviction conditions, which the monitoring process also needs to analyze and judge. In one embodiment, eviction conditions can be event-based. For example, the policy can be set to automatically trigger the eviction of all temporary authorization records issued by the initial terminal device (i.e., the authorizing party) when it is detected that the initial terminal device has re-entered the local network. This means that all temporary permissions automatically expire when the owner returns home. In another embodiment, eviction conditions can be based on the behavior of the invited terminal device. For example, if the device is detected to have made no access attempts for a continuous period (e.g., 30 minutes), it can be considered that it no longer needs permissions, and the system automatically evictions them to reduce security risks. In yet another embodiment, eviction conditions can also be explicit instructions. When the initial terminal device sends a specific permission revocation instruction, the monitoring process immediately marks the corresponding temporary record as pending eviction upon receiving this instruction.

[0107] When the monitoring process finds that the current system status meets any of the revoke conditions (including but not limited to time expiration, event triggering, or command arrival), it immediately triggers the removal operation of the temporary authorization record. The removal operation is an atomic data management process, ensuring data consistency. The camera device locates the record in its local device public key list and deletes it from the list. This operation means that the public key of the corresponding invited terminal device is immediately revoked, and any subsequent video access requests initiated by that device will be rejected due to the invalid public key. The entire monitoring and revoke process is completed automatically on the camera device itself, without the need for cloud server involvement in decision-making, ensuring the real-time and reliable nature of permission revocation and effectively preventing excessive permission retention.

[0108] The above embodiments demonstrate that, in terms of dynamic authorization granularity, they achieve a leap from static binding to intelligent temporary authorization. Through preset effective strategies, they realize the automatic granting and revoke of permissions, adapting to short-term, high-frequency access needs and significantly improving the granularity and automation level of permission management. Regarding security model robustness, through localized, periodic state monitoring and atomic permission revocation operations, a dynamic security boundary with self-healing capabilities is constructed, ensuring that temporary permissions are not retained due to system forgetting or network interruption, fundamentally eliminating the risk of permission diffusion and enhancing the system's inherent security. In balancing user experience and privacy protection, this mechanism provides ultimate convenience such as automatic authorization for visitors while ensuring the timeliness and controllability of permissions through strict policy enforcement. It meets the needs of temporary sharing scenarios while avoiding the privacy risks caused by long-term open permissions, achieving a high-level unity of security and convenience. Finally, at the system architecture level, the intelligent decision-making and execution capabilities of permission management are pushed down to terminal devices, further consolidating the decentralized security paradigm, reducing continuous dependence on external cloud services, and promoting the evolution of security monitoring systems towards a more autonomous and intelligent privacy protection ecosystem.

[0109] Please see Figure 2 This application provides a video data processing apparatus to meet one of its objectives. It is a functional embodiment of the video data processing method of this application. The apparatus includes a request response module 3100, a video encryption module 3200, a key encryption module 3300, and a data output module 3400. The request response module 3100 is configured to respond to a privacy mode activation request by determining the pre-bound public key of the initial terminal device associated with the request from a list of device public keys stored locally on the current camera device. The video encryption module 3200 is configured to encrypt the acquired video stream using a pre-generated session key to obtain encrypted video data. The key encryption module 3300 is configured to encrypt the session key using the public key to obtain a key data packet. The data output module 3400 is configured to upload the encrypted video data and the key data packet to a remote storage space via a server communication path, so that the initial terminal device can decrypt the key data packet using a private key paired with the public key to obtain the session key, and then decrypt the encrypted video data using the session key to restore the original video stream.

[0110] Based on any embodiment of the method in this application, prior to the request response module 3100, this device further includes: a binding response module, configured to respond to a device binding instruction triggered by the initial terminal device, generate a paired public key and private key in the initial terminal device, and associate the public key with the identity identifier of the initial terminal device; a binding execution module, configured to use an independent transmission path independent of the server communication path as an end-to-end secure channel, obtain the public key and associated identity identifier of the initial terminal device through the channel, and store them in the device public key list of the current camera device to achieve binding; and a listening start module, configured to start listening for privacy mode activation requests that match the privacy mode activation conditions set by the initial terminal device.

[0111] Based on any embodiment of the method in this application, the binding execution module includes: a channel establishment module, configured to create an independent transmission path between the current camera device and the initial terminal device, independent of the server communication path, as an end-to-end secure channel; a binding writing module, configured to receive the public key and associated identity identifier from the initial terminal device through the end-to-end secure channel, and write the public key and associated identity identifier into the device public key list of the current camera device; and a confirmation feedback module, configured to send a confirmation message back to the initial terminal device, so that the initial terminal device adds the current camera device to its camera device list.

[0112] Based on any embodiment of the method in this application, the monitoring initiation module may include any one or more of the following embodiments: In one embodiment, the monitoring initiation module is configured to initiate a monitoring service by the current camera device, continuously monitor time condition data that matches the privacy mode activation conditions set by the initial terminal device, and trigger the privacy mode activation request when the time condition data meets the time condition in the privacy mode activation conditions; In another embodiment, the monitoring initiation module is configured to initiate a monitoring service by the current camera device, driving the server in the server communication path to continuously monitor whether the real-time geographical location of the initial terminal device meets the privacy mode activation conditions set by the initial terminal device, and trigger the privacy mode activation request when the real-time geographical location meets the location condition in the privacy mode activation conditions; In yet another embodiment, the monitoring initiation module is configured to initiate a monitoring service by the current camera device, continuously monitor the latest user instructions of the initial terminal device, and trigger the privacy mode activation request when the latest user instructions match the instruction type in the privacy mode activation conditions.

[0113] Based on any embodiment of the method in this application, following the data output module 3400, the device further includes: a device rebinding response module, configured to receive a device rebinding request sent by a substitute terminal device of the initial terminal device, and obtain a security token issued by a security server, a public key generated by the substitute terminal device, and a digital signature generated by the substitute terminal device using its corresponding private key to operate on the security token; a signature verification module, configured to use the public key of the substitute terminal device and the security token to verify the identity of the digital signature, so as to verify whether the digital signature belongs to the valid signature of the security token; a legality verification module, configured to forward the security token to the security server, requesting it to perform legality verification on the security token, so as to verify whether the security token belongs to the valid token applicable to the authorization process between the initial terminal device and the substitute terminal device within a preset validity period; and a device rebinding execution module, configured to update the public key and its identity identifier of the initial terminal device in the device public key list to the public key and its identity identifier of the substitute terminal device only when both the identity verification and the legality verification are passed.

[0114] Based on any embodiment of the method in this application, the video encryption module 3200 includes: an image recognition module, configured to perform real-time analysis on the acquired video stream to identify key frames and non-key frames; a target determination module, configured to determine target data to be encrypted based on a preset encryption strategy, wherein the target data corresponds to the encryption strategy of including only the key frames, or including both the sequence parameter set of the video stream and the key frames; and an encryption implementation module, configured to use the session key to encrypt the target data to obtain the encrypted video data.

[0115] Based on any embodiment of the method in this application, the data output module 3400 further includes: an authorization response module, configured to respond to a temporary authorization instruction sent by the initial terminal device, determine the identity identifier of the invited terminal device and the valid authorization policy in the instruction, the valid policy including the authorization validity period; a temporary binding module, configured to obtain the public key of the invited terminal device through an end-to-end secure channel independent of the server communication path, associate the public key and its identity identifier with the valid policy, and add it as a temporary authorization record to the device public key list; and an authorization check module, configured to continuously monitor the valid policy during the effective period of the temporary authorization record, wherein when it is detected that the current system time exceeds the authorization validity period or meets the recycling conditions in the valid policy, the temporary authorization record is automatically removed from the device public key list.

[0116] To address the aforementioned technical problems, embodiments of this application also provide a computer device for implementing the camera device of this application. For example... Figure 3The diagram shows the internal structure of a computer device. This computer device includes a processor, a computer-readable storage medium, a memory, a network interface, and various communication components connected via a system bus. The computer-readable storage medium stores an operating system, a database, and computer-readable instructions. The database may store a sequence of control information. When the computer-readable instructions are executed by the processor, they enable the processor to implement a video data processing method. The processor of this computer device provides computing and control capabilities, supporting the operation of the entire computer device. The memory of this computer device may store computer-readable instructions. When these computer-readable instructions are executed by the processor, they enable the processor to execute the video data processing method of this application. The network interface of this computer device is used for communication with a terminal. Those skilled in the art will understand that… Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0117] In this embodiment, the processor is used to execute... Figure 2 The specific functions of each module and its submodules are defined within the device. The memory stores the program code and various types of data required to execute these modules or submodules. The network interface is used for data transmission between the user terminal and the server. In this embodiment, the memory stores the program code and data required to execute all modules / submodules in the video data processing apparatus of this application. The server can call the server's program code and data to execute the functions of all submodules.

[0118] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the video data processing method of any embodiment of this application.

[0119] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0120] Those skilled in the art will understand that the steps, measures, and solutions in the various operations, methods, and processes discussed in this application can be alternated, modified, combined, or deleted. Furthermore, other steps, measures, and solutions in the various operations, methods, and processes discussed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and solutions in the prior art that are similar to those in the open-source operations, methods, and processes of this application can also be alternated, modified, rearranged, decomposed, combined, or deleted.

[0121] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A video data processing method, characterized in that, include: In response to the privacy mode activation request, determine the public key pre-bound to the initial terminal device associated with the request from the list of device public keys stored locally on the current camera device; The captured video stream is encrypted using a pre-generated session key to obtain encrypted video data; The session key is encrypted using the public key to obtain a key data packet; The encrypted video data and the key data packet are uploaded to a remote storage space via a server communication path, so that the initial terminal device can use a private key paired with the public key to decrypt the key data packet to obtain the session key, and decrypt the encrypted video data according to the session key to restore the original video stream.

2. The video data processing method according to claim 1, characterized in that, Before responding to a privacy mode activation request and determining the pre-bound public key of the initial terminal device associated with the request from the list of device public keys stored locally on the current camera device, the process includes: In response to a device binding command triggered by the initial terminal device, a paired public key and private key are generated in the initial terminal device, and the public key is associated with the identity identifier of the initial terminal device; An independent transmission path, separate from the server communication path, is used as an end-to-end secure channel. The public key and associated identity identifier of the initial terminal device are obtained through this channel and stored in the device public key list of the current camera device to achieve binding. Initiate listening for privacy mode activation requests that match the privacy mode activation conditions set on the initial terminal device.

3. The video data processing method according to claim 2, characterized in that, An independent transmission path, separate from the server communication path, serves as the end-to-end secure channel. Through this channel, the public key and associated identity identifier of the initial terminal device are obtained and stored in the current camera device's device public key list to achieve binding, including: An independent transmission path, separate from the server communication path, is created between the current camera device and the initial terminal device as an end-to-end secure channel; Through the end-to-end secure channel, the public key and associated identity identifier of the initial terminal device are received, and the public key and associated identity identifier are written into the device public key list of the current camera device; A confirmation message is sent back to the initial terminal device so that the initial terminal device adds the current camera device to its camera device list.

4. The video data processing method according to claim 2, characterized in that, Initiate listening for privacy mode activation requests that match the privacy mode activation conditions set by the initial terminal device, including any one or more of the following: The monitoring service is initiated by the current camera device to continuously monitor time condition data that matches the privacy mode activation conditions set by the initial terminal device. When the time condition data meets the time condition in the privacy mode activation conditions, the privacy mode activation request is triggered. The current camera device initiates a listening service, which drives the server in the server communication path to continuously monitor whether the real-time geographical location of the initial terminal device meets the privacy mode activation conditions set by the initial terminal device. When the real-time geographical location meets the location conditions in the privacy mode activation conditions, the privacy mode activation request is triggered. The monitoring service is initiated by the current camera device to continuously monitor the latest user commands of the initial terminal device. When the latest user command matches the command type in the privacy mode activation conditions, the privacy mode activation request is triggered.

5. The video data processing method according to any one of claims 1 to 4, characterized in that, After uploading the encrypted video data and the key data packet to the remote storage space via the server communication path, the process includes: Receive a device rebinding request sent by the substitute terminal device of the initial terminal device, and obtain the security token issued by the security server, the public key generated by the substitute terminal device, and the digital signature generated by the substitute terminal device using its corresponding private key to operate on the security token; The digital signature is authenticated using the public key of the substitute terminal device and the security token to verify whether the digital signature is a valid signature of the security token. The security token is forwarded to the security server, requesting it to verify the security token's validity, in order to verify whether the security token is a valid token applicable to the authorization process between the initial terminal device and the alternative terminal device within a preset validity period; Only when both the authentication and the legitimate verification are successful, the public key and its identity identifier of the initial terminal device in the device public key list are updated to the public key and its identity identifier of the replacement terminal device.

6. The video data processing method according to any one of claims 1 to 4, characterized in that, The captured video stream is encrypted using a pre-generated session key to obtain encrypted video data, including: Real-time analysis of the acquired video stream is performed to identify key frames and non-key frames. Based on a preset encryption strategy, the target data to be encrypted is determined. The target data corresponds to the encryption strategy of including only the key frame, or including both the sequence parameter set of the video stream and the key frame. The target data is encrypted using the session key to obtain the encrypted video data.

7. The video data processing method according to any one of claims 1 to 4, characterized in that, After uploading the encrypted video data and the key data packet to the remote storage space via the server communication path, the process includes: In response to the temporary authorization instruction sent by the initial terminal device, determine the identity identifier of the invited terminal device in the instruction and the valid authorization policy, wherein the valid policy includes the authorization validity period; The public key of the invited terminal device is obtained through an end-to-end secure channel independent of the server communication path. The public key and its identity identifier are associated with the valid policy and added to the device public key list as a temporary authorization record. During the validity period of the temporary authorization record, its validity policy is continuously monitored. When it is detected that the current system time exceeds the validity period of the authorization or the recycling conditions in the validity policy are met, the temporary authorization record is automatically removed from the device public key list.

8. A video data processing apparatus, characterized in that, include: The request-response module is configured to respond to privacy mode activation requests by determining the public key pre-bound to the initial terminal device associated with the request from the list of device public keys stored locally on the current camera device. The video encryption module is configured to encrypt the captured video stream using a pre-generated session key to obtain encrypted video data; The key encryption module is configured to encrypt the session key using the public key to obtain a key data packet; The data output module is configured to upload the encrypted video data and the key data packet to a remote storage space via a server communication path, so that the initial terminal device can use a private key paired with the public key to decrypt the key data packet to obtain the session key, and decrypt the encrypted video data according to the session key to restore the original video stream.

9. A camera device, comprising a processor and a memory, characterized in that, The processor invokes and runs a computer program in the memory to perform the steps of the video data processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 7, which, when invoked by a computer, performs the steps included in the corresponding method.

Images