Video data encryption storage method and device, encrypted video playback method and device, and camera device

Abstract

The invention provides a video data encryption storage method and device, an encrypted video playback method and device and a camera device. The encryption storage method comprises the following steps: generating a device key according to at least one unique hardware identifier of a camera and a user-defined password set by a user; for each to-be-stored video file, generating a file key according to the equipment key and time sequence information of the video file; and performing encryption processing on the corresponding original video file by using the file key, and storing the encrypted video file obtained through encryption processing in a storage medium. According to the scheme disclosed by the invention, the key is generated by binding the equipment hardware, the user-defined password and the file time, so that the privacy and the data security of the user are greatly protected.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method and apparatus for encrypting and storing video data, a method and apparatus for encrypting and playing back video, and a camera device. Background Technology

[0002] In recent years, with the rapid development and popularization of Internet of Things (IoT) technology, video capture devices, represented by network cameras, have been widely used in various scenarios such as home security, commercial surveillance, and traffic recording. While providing convenience and security, these devices also generate massive amounts of video data. This video data often contains highly sensitive privacy information such as users' personal lives, home environments, and workplaces. Therefore, how to ensure the security of this data storage has become a core issue of widespread concern to the industry and users.

[0003] Currently, the mainstream local storage medium for camera video data is removable memory cards, such as MicroSD cards. However, existing technologies still have some shortcomings in data security protection schemes for this type of local storage. Most commonly, to simplify design and reduce costs, many camera devices do not encrypt the video files stored on the card; the video data is stored in plaintext. This method poses a significant security risk. Once the camera or memory card is stolen or lost, the perpetrator can directly read all the video content without any technical decryption, seriously threatening the user's privacy and security. Summary of the Invention

[0004] This disclosure provides a method and apparatus for encrypted storage of video data, a method and apparatus for encrypted video playback, and a camera device to solve or alleviate one or more technical problems in the prior art.

[0005] Firstly, this disclosure provides a method for encrypted storage of video data, including: Generate a device key based on at least one unique hardware identifier of the camera and a user-defined password; For each video file to be stored, a file key is generated based on the device key and the timing information of the video file; The original video file is encrypted using the file key, and the encrypted video file is stored in the storage medium.

[0006] Secondly, this disclosure provides an encrypted video playback method, including: Receive video playback requests containing the target timestamp; Based on the target timestamp, the corresponding target video file is retrieved from the storage medium, and the target video file is verified by signature. If the signature verification is successful, a file key for decrypting the target video file is generated based on the creation timestamp of the target video file and the preset device key; The target video file is decrypted using the file key, and the decrypted video data is sent to the user terminal.

[0007] Thirdly, an encrypted storage device for video data is provided, comprising: The first key module is used to generate a device key based on at least one unique hardware identifier of the camera and a user-set custom password; The second key module is used to generate a file key for each video file to be stored, based on the device key and the timing information of the video file. An encrypted storage module is used to encrypt the corresponding original video file using the file key and store the encrypted video file in a storage medium.

[0008] Fourthly, an encrypted video playback device is provided, comprising: The receiving module is used to receive video playback requests containing the target timestamp; The signature verification module is used to retrieve the corresponding target video file from the storage medium based on the target timestamp, and to verify the signature of the target video file. The key generation module is used to generate a file key for decrypting the target video file based on the creation timestamp of the target video file and a preset device key, provided that the signature verification is successful. The decryption module is used to decrypt the target video file using the file key and send the decrypted video data to the user terminal.

[0009] Fifthly, a camera device is provided, comprising: The image acquisition module is used to acquire video data; Main control processing module; The storage medium communicating with the main control processing module is used to store encrypted video files, which are obtained by the main control processing module executing the method described in any one of the embodiments of this disclosure.

[0010] The beneficial effects of the technical solution provided in this disclosure include at least the following: By binding device hardware, user-defined password, and file time to generate a key, user privacy and data security are greatly protected.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0012] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments provided according to this disclosure and should not be construed as limiting the scope of this disclosure.

[0013] Figure 1 This is a flowchart illustrating a method for encrypting and storing video data according to an embodiment of this disclosure; Figure 2 This is a schematic diagram of a camera binding process according to an embodiment of the present disclosure; Figure 3 This is a flowchart illustrating a method for encrypting and storing camera video data according to an embodiment of the present disclosure; Figure 4 This is a flowchart illustrating an encrypted video playback method according to an embodiment of the present disclosure; Figure 5 This is a flowchart illustrating an encrypted video playback method according to another embodiment of the present disclosure; Figure 6 This is a schematic diagram of the structure of a camera device according to an embodiment of the present disclosure; Figure 7 This is a schematic diagram of the structure of an encrypted storage device for camera video data according to an embodiment of the present disclosure; Figure 8 This is a schematic diagram of the structure of an encrypted video playback method apparatus according to an embodiment of the present disclosure; Figure 9 This is a block diagram of an electronic device used to implement embodiments of the present disclosure. Detailed Implementation

[0014] The present disclosure will now be described in further detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0015] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0016] In related technologies, to address the security issues arising from plaintext storage, some existing solutions have introduced encryption mechanisms. A common approach is to employ a user password-based encryption scheme, where the user sets a password, and the device uses a key derived from that password to encrypt the video file. This scheme improves security to some extent, but its security strength depends entirely on the complexity of the user password, and the encryption granularity is usually quite large, such as using the same key for the entire storage area or all files.

[0017] In the broader field of information security, hardware security technologies have begun to be applied to enhance key security. For example, in devices such as smartphones and financial terminals, using hardware such as security chips or trusted execution environments to protect the secure storage and use of keys has become a mature technological approach. Security chips can provide a secure environment isolated from the main processor, effectively preventing keys from being stolen by malicious software. However, how to deeply integrate this hardware-level security capability with application-layer requirements such as user authentication and file management, especially in consumer-grade camera scenarios that require both offline use and independent encryption of multiple files, to build a secure and convenient key management and data encryption system remains a technological direction that requires continuous exploration and improvement in this field.

[0018] In order to at least partially solve one or more of the above-mentioned problems and other potential problems, embodiments of this disclosure provide a method for encrypted storage of video data and an encrypted video playback method.

[0019] Figure 1 This is a flowchart illustrating a method for encrypting and storing video data according to an embodiment of this disclosure. Figure 1 As shown, the method includes at least the following steps: S110: Generate a device key based on at least one unique hardware identifier of the camera and a user-defined password.

[0020] In this embodiment, a camera is an electronic device capable of capturing video and storing it digitally. Each camera device has a globally unique hardware identifier, such as the serial number of a central processing unit (CPU), which is fixed at the factory. When configuring the camera for the first time, the user sets a custom password through a mobile application (user terminal), which is used to enhance the security of the camera.

[0021] When the encryption process begins, the camera first executes step S110, reading its unique hardware identifier and combining it with the user-set custom password. Then, it uses a specific encryption algorithm to generate a master key, called the device key. This device key is the root key for all subsequent encryption operations; it is simultaneously bound to both the physical device and the user's identity.

[0022] S120: For each video file to be stored, generate a file key based on the device key and the timing information of the video file.

[0023] Next, when the camera starts recording video, it splits the video stream into multiple independent raw video files, for example, generating one file per minute. For each newly generated raw video file, the camera executes step S120. It obtains the timing information of the file (e.g., the file creation time), and then performs an encryption operation on this timing information again with the device key generated in step S110 to generate a separate file key for this video file.

[0024] S130: Encrypt the corresponding original video file using the file key, and store the encrypted video file to the storage medium.

[0025] Finally, the camera performs step S130, encrypting the original video file using the newly generated file key to generate an encrypted video file. This encrypted video file is then written to a storage medium, such as a Secure Digital (SD) card inserted into the camera.

[0026] According to the scheme of this disclosure embodiment, a key is generated by binding the device hardware, user password, and file time. Each device has an independent device key, achieving "one device, one key," and each video file has an independent file key, achieving a "one file, one key" security policy. Even if the storage medium (such as an SD card) is stolen, because the original camera hardware and user-defined password are missing, attackers cannot regenerate the correct device key and file key, and therefore cannot decrypt the video content, greatly protecting user privacy and data security.

[0027] In one possible implementation, step S110 generates a device key based on at least one unique hardware identifier of the camera and a user-set custom password, and further includes the following steps: S111: Generate a first key based on at least one unique hardware identifier of the camera.

[0028] S112: Generate a device key based on the user-set preset key and the first key.

[0029] In this embodiment, the generation of the device key is designed as a hierarchical derivation process to enhance security. First, in step S111, the camera uses only its own unique hardware identifier as input to generate an intermediate key, called the first key, through an encryption algorithm. This first key is entirely determined by the hardware characteristics and is the inherent fingerprint of the device.

[0030] Subsequently, in step S112, the camera combines the user-set custom password (referred to here as the preset key) with the first key generated in the previous step, and then performs another encryption algorithm to finally generate the device key.

[0031] According to the scheme of this disclosure embodiment, this two-step key generation method separates hardware identity and user identity during the key generation process, constructing a more secure key derivation hierarchy. The first key, as the root of hardware binding, ensures the physical uniqueness of the key. The device key adds user authentication on top of hardware binding, achieving dual security protection.

[0032] In one possible implementation, in step S111, the unique hardware identifier acquired by the camera can be a combination of one or more hardware identity information. A preferred embodiment is to simultaneously read the unique identifier (Secure Element ID) of the security chip inside the camera and the unique identifier (CPUID) of the central processing unit. The security chip is a hardware module specifically designed to handle encryption tasks and protect keys; its unique identifier typically has tamper-proof and copy-proof characteristics. These two identifiers are combined (e.g., string concatenation) and used as input to generate the first key. The security chip can also be an IoT chip in an Internet of Things (IoT) device.

[0033] According to the scheme of this disclosure, by employing a combination of security chip ID and CPUID, the uniqueness and anti-counterfeiting properties of the hardware identifier are significantly enhanced. In particular, the use of a security chip provides a high-level hardware guarantee for the root of trust in the key system, greatly improving the security of the entire encryption scheme.

[0034] In one possible implementation, step S111 generates a first key based on at least one unique hardware identifier of the camera, and further includes the following steps: A hash-based message authentication code algorithm is used to generate a first key based on at least one unique hardware identifier of the camera.

[0035] In this embodiment of the disclosure, the HMAC (Hash-based Message Authentication Code) algorithm, such as HMAC-SHA256, is specifically used when generating the first key. The unique identifier of the security chip and the unique identifier of the central processing unit read from the hardware are concatenated and used as the "message" input to the HMAC algorithm. Simultaneously, a fixed salt value can be preset as the "key" input to the HMAC algorithm. After the algorithm is executed, a fixed-length 256-bit hash value is output, which is the first key.

[0036] According to the scheme of this disclosure embodiment, the HMAC algorithm can ensure that even if the length of the input (hardware identifier) ​​is not fixed, the output first key has a fixed length and high randomness. At the same time, HMAC can resist various attacks against ordinary hash functions, ensuring that the conversion process from hardware identifier to first key is unidirectional and secure.

[0037] In one possible implementation, step S112 generates a device key based on a user-set preset key and a first key, and further includes the following steps: The device key is generated using a key derivation function based on the user-defined password and the first key.

[0038] In this embodiment of the disclosure, the device key is generated using an industry-standard HMAC-Based Key Derivation Function (HKDF). HMAC is an abbreviation for Hash-based Message Authentication Code. The first key generated in step S111 is used as the "salt" input to the HKDF, and the user-set custom password is used as the "Input Keying Material (IKM)" input. Through the two stages of extraction and expansion of the HKDF, a high-entropy, fixed-length device key is finally generated.

[0039] According to the scheme of this disclosure, using a standard key derivation function such as HKDF is the best practice for securely combining two secrets from different sources (a hardware-generated first key and a user-inputted password) into a unified strong key. It effectively addresses the potential entropy deficiency (i.e., insufficient randomness) in user passwords and generates a cryptographically strong device key, far more secure than simple concatenation or hash operations.

[0040] In one possible implementation, in step S120, the timing information used to generate the file key is specifically the creation timestamp of the original video file.

[0041] For example, when a camera creates a video file named vid_20250820_215000.mp4 at 9:50 PM on August 20, 2025, its file system metadata will contain a creation timestamp accurate to the second or millisecond. The camera will read this timestamp and use it as one of the inputs to generate the file key corresponding to that file.

[0042] According to the scheme of this disclosure, the file creation timestamp is used as timing information to ensure that each file has a unique input parameter, thereby deriving a unique file key. This method is simple, efficient, and reliable, and can automatically achieve the goal of "one file, one key".

[0043] In one possible implementation, the specific encryption method of step S130 is described, which specifically includes: S131: In response to the recorded video stream reaching a preset duration threshold, generate the original video file to be encrypted.

[0044] S132: The original video file is encrypted using an authentication encryption algorithm to obtain an encrypted video file and an authentication tag for integrity verification.

[0045] S133: Attach an authentication tag to an encrypted video file.

[0046] In this embodiment, the camera's video recording is a continuous data stream. For ease of management and encryption, the system sets a preset duration threshold, such as 60 seconds.

[0047] In step S131, when the duration of the continuously recorded video stream from the camera reaches the 60-second threshold, the system automatically encapsulates this video stream into an independent, unencrypted original video file. For example, it generates a file named VID_20250821_160500.mp4. This process repeats continuously while the camera is on, dividing the continuous monitoring footage into a series of time-sequential, independent file segments.

[0048] Next, in step S132, the camera employs a preferred authentication encryption algorithm, such as AES-256-GCM. This authentication encryption algorithm is an advanced encryption mode that, while performing encryption, calculates a short and unique verification data based on the encryption key and the original data content. This verification data is called an authentication tag. In cryptography, the authentication tag is a message authentication code that effectively proves the integrity and authenticity of the data's origin. Therefore, the output of this step consists of two parts: the encrypted video file (i.e., the ciphertext of the video content) and the corresponding authentication tag.

[0049] Finally, in step S133, the authentication tag generated in the previous step is appended to the end or beginning of the encrypted video file to form a final, complete secure file. The product of this process is a secure file that contains both encrypted content and verification information.

[0050] The technical effects of the solution according to the embodiments of this disclosure are reflected in two aspects: Standardization of file management: By segmenting video streams according to preset durations, continuous monitoring data is transformed into file units of uniform size that are easy to index and retrieve, greatly optimizing storage management efficiency.

[0051] The integrated implementation of dual security guarantees: Employing an authentication encryption algorithm, this method achieves both data confidentiality (video content is encrypted and cannot be viewed by unauthorized parties) and integrity (an additional authentication tag ensures that the video content is not tampered with in any way during storage or transmission) through a single efficient operation. Compared to the two independent steps of "encryption first, then signing," this integrated processing method is more efficient and provides the same level of security guarantee, ensuring the originality and reliability of the video as evidence.

[0052] In one possible implementation, the method further includes the following steps: S140: After the binding between the camera and the user account is completed on the cloud server, obtain the user-set custom password sent by the user terminal.

[0053] In this embodiment of the disclosure, when a user uses the camera for the first time, they can scan the QR code on the camera using an application on their mobile phone (user terminal) to trigger the binding process. For example... Figure 2 As shown, the user terminal and camera communicate with the cloud server respectively. After verifying the device's legitimacy, the cloud server associates the camera's hardware identifier with the user's account, completing the binding. After successful binding, the user terminal prompts the user to set a custom password (or super password) for video encryption. After the user enters the password, the user terminal sends it directly to the camera via a local secure channel. Upon receiving the password, the camera securely stores it for later use in generating a device key.

[0054] According to the embodiments of this disclosure, a secure and convenient user initialization process is described. Binding the device and account is completed via the cloud, ensuring the correctness of device ownership. The custom password used for encryption is transmitted via the local network, avoiding the transmission of sensitive passwords over the public internet and improving the security of the password setting process.

[0055] In one possible implementation, such as Figure 3 The diagram illustrates a method for encrypting and storing camera video data. The specific steps are as follows: Step 1: System Initialization Sensor initialization: After the camera device is started, its image sensor is initialized first to make it ready to work.

[0056] Encryption module initialization: Simultaneously, the device's encryption module is initialized and the master key is generated. This process includes: Obtain root key information: Obtain the ID of the security chip inside the device as the root key (key0), and obtain the CPU ID.

[0057] Generate the first device key (key1): Generate a temporary first device key (key_tmp) by using the HMAC-SHA3 algorithm, combined with the CPU ID and the root key (key0).

[0058] Generate a second device key (key2): Using the key derivation function HKDF, a second device key (key2) is generated in combination with the first device key and the super password set by the user for subsequent encryption.

[0059] Step Two: Segmented Video Recording After the system initialization is complete, the camera begins to acquire real-time video streams from the sensors and records them into an MP4 file named with an index (e.g., 0.mp4).

[0060] The system will continuously monitor the duration of the currently recorded MP4 files.

[0061] Step 3: Trigger Encryption When the system determines that the duration of the current MP4 file has reached or exceeded a preset threshold (e.g., 60 seconds), the recording of the current file will end.

[0062] At this point, the video recording module will notify the encryption module and hand over the currently recorded MP4 file for processing.

[0063] Step 4: Encrypting and Signing Video Files Generate file key (key3): After receiving the notification, the encryption module first obtains the creation timestamp of the file to be encrypted. Then, using the key derivation function HKDF, it combines the second device key (key2) generated in step one with the file's timestamp to generate a unique file key (key3) for this MP4 file.

[0064] File encryption: The original MP4 file is encrypted using the AES-256-GCM encryption algorithm and the file key (key3) just generated, generating an encrypted video file (index_encrypt.mp4).

[0065] File signing: Next, the RSA algorithm is used to sign the already encrypted video file (index_encrypt.mp4) to generate the final encrypted file (index_encrypt_sign.mp4) with the signature, and then it is stored in the storage medium.

[0066] Step 5: Loop Recording and Encryption While the encryption module processes the previous file, the video recording module updates the file index (index++) and returns to step two to start acquiring the video stream and recording the next new MP4 file (e.g., 1.mp4).

[0067] Steps two through five above will be executed continuously in a loop, thereby achieving continuous segmentation, encryption, and signature storage of the camera video stream.

[0068] Figure 4 This is a schematic flowchart of a video playback method applied to a camera according to an embodiment of the present disclosure. Figure 4 As shown, the method includes at least the following steps: S410: Receives a video playback request containing the target timestamp.

[0069] S420: Based on the target timestamp, retrieve the corresponding target video file from the storage medium and verify the signature of the target video file.

[0070] S430: If the signature verification is successful, generate a file key for decrypting the target video file based on the creation timestamp of the target video file and the preset device key.

[0071] S440: Uses a file key to decrypt the target video file and sends the decrypted video data to the user terminal.

[0072] In this embodiment of the disclosure, when a user selects to review a video recording at a certain time point on a mobile application (user terminal), the target timestamp is first obtained based on that time point, and the user terminal sends a video review request containing the target timestamp to the camera in step S410.

[0073] After receiving the request, the camera locates the corresponding encrypted video file (i.e., the target video file) in the storage medium (such as an SD card) based on the target timestamp. Before performing any decryption operation, the camera first performs signature verification, that is, uses the authentication encryption algorithm mentioned in the previous embodiment to verify whether the authentication tag attached to the file is valid.

[0074] If the signature verification passes, indicating that the file has not been tampered with, the camera will proceed to step S430. It will read the creation timestamp of the target video file and, using the preset device key (i.e., the device key generated in Example 1), regenerate the file key for the file using the exact same algorithm as during encryption.

[0075] Finally, in step S440, the camera uses the newly generated file key to decrypt the target video file, obtain playable video data, and streams this data to the user terminal for playback via the local network.

[0076] According to the embodiments of this disclosure, a secure playback process of verification before decryption is provided. The signature verification step ensures the authenticity and integrity of the played video, eliminating the possibility of playing tampered videos. By dynamically regenerating the file key instead of the storage key, the key itself is not stored on disk, further enhancing the system's security.

[0077] In one possible implementation, the preset device key is generated based on an intermediate key and a user-defined custom password; The intermediate key is generated based on at least one unique hardware identifier of the camera.

[0078] In this embodiment, the preset device key used by the camera to generate the file key is the same device key generated during initial encryption. The key generation process is completely consistent with the aforementioned encrypted storage method embodiment to ensure that the same key is used for encryption and decryption.

[0079] Specifically, the preset device key can be stored in the system after its initial generation. Alternatively, it can be regenerated each time it is needed. To reproduce the key when required, the camera performs the following steps again: First, based on at least one unique hardware identifier of the camera, an intermediate key (the same as the first key generated in S111) is generated.

[0080] Then, based on this intermediate key and the user-set custom password, a deterministic preset device key is generated again using the same algorithm (such as HKDF described in the embodiment corresponding to S112).

[0081] In one possible implementation, the unique hardware identifier includes at least one of a security chip unique identifier and a central processing unit unique identifier.

[0082] According to the embodiments of this disclosure, this embodiment emphasizes the determinism and repeatability of the key generation process. By relying on immutable hardware identifiers and user passwords, the camera can accurately recalculate the same device key and file key whenever needed (whether for encryption or decryption), without having to store these sensitive keys on the device for extended periods. This is a stateless, highly secure key management scheme.

[0083] In one possible implementation, such as Figure 5 As shown in the attached diagram, a specific process for an encrypted video playback method is provided. This process involves the interaction between the user terminal (such as a mobile phone) and the camera, and the steps are as follows: Step 1: User terminal authentication and request Users access the video playback interface on their mobile phones or other user terminals.

[0084] The user enters a preset playback password, and the mobile terminal verifies the password locally.

[0085] After the password verification is successful, the user terminal sends a video playback request to the camera. This request includes the target timestamp used to locate the video segment.

[0086] Step 2: The camera receives the request and performs signature verification. The camera received a request command from the user terminal.

[0087] The camera locates the corresponding encrypted MP4 video file from its storage medium (such as an SD card) based on the target timestamp carried in the request.

[0088] The camera performs a signature verification operation on the found encrypted video files to verify the integrity and authenticity of the files.

[0089] If the signature verification fails, the camera returns a signature verification failure instruction to the user terminal, and the process terminates.

[0090] Step 3: Derive the camera's file key and decrypt it. After the signature verification is successful, the camera will obtain the creation timestamp of the video file.

[0091] The camera uses its internally preset second device key (key2), which combines hardware information and the user's super password, to generate a unique file key (key3) for decryption by performing a key derivation function (HKDF) operation with the file's creation timestamp.

[0092] The camera uses the generated file key (key3) to decrypt the video file.

[0093] If decryption fails, the camera returns a decryption failure command to the user terminal, and the process terminates.

[0094] Step 4: Data Transfer and Video Playback After the video file is successfully decrypted, the camera begins sending the decrypted video data to the user's terminal.

[0095] After receiving the video data, the user terminal decodes it and plays the video back on the interface.

[0096] Figure 6 This is a schematic diagram of the modular structure of a camera device according to an embodiment of the present disclosure. This embodiment provides a specific structure and application form of a camera device capable of executing the aforementioned encrypted storage method and video playback method. This camera device, through the collaborative work of its built-in hardware modules, realizes a complete workflow from video acquisition to secure storage.

[0097] The camera device 600 in this embodiment may have a hardware structure including, but not limited to, the following modules: Image acquisition module: Composed of an optical lens and an image sensor, it is responsible for capturing optical signals from the real world and converting them into raw digital image data.

[0098] Image Signal Processing (ISP): Receives raw data from the image sensor and performs a series of image optimization processes, such as automatic exposure, white balance, noise reduction, and wide dynamic range, ultimately outputting a high-quality video stream.

[0099] The main control processing module (SoC): As the brain of the camera, it is usually a highly integrated chip that integrates multiple functions such as a central processing unit (CPU) and a memory controller. It is responsible for running the operating system and core applications, performing video encoding, data encryption, network communication, and the key generation and encrypted storage methods for video data, as well as the encrypted video playback methods provided in any of the foregoing embodiments of this disclosure.

[0100] Security and Encryption Module: The core of this module is a Secure Element (SE) chip, used to securely generate and store keys, perform cryptographic operations, and provide a hardware root of trust resistant to physical attacks. The unique ID of this secure chip is a key component of the "unique hardware identifier" described in this disclosure. In this embodiment, the secure chip can be a security chip (IoT chip) specifically designed for Internet of Things (IoT) scenarios, providing an efficient and low-power security solution for lightweight devices connected to the network.

[0101] The storage module includes RAM for temporary data storage, flash memory for storing firmware, and an external storage medium interface, such as a MicroSD (TF) card slot, for storing recorded video. The storage medium of the storage module is used to store encrypted video files, which are obtained by the central processing unit executing the encrypted storage method for video data provided in any of the foregoing embodiments.

[0102] Network communication module: This typically includes a Wi-Fi module, and some devices may also include an Ethernet interface or Bluetooth module, used for device networking and communication with user terminals and cloud servers.

[0103] Audio module: Includes a microphone and a speaker, used to collect ambient sound and enable two-way voice communication.

[0104] Peripheral and auxiliary modules include infrared LEDs for night vision, LEDs for indicating device status, power supply interfaces, and power management units (PMUs).

[0105] The camera devices described in this disclosure can take on various product forms depending on their shape, function, and installation method, including but not limited to: Home indoor cameras: usually in the form of point-and-shoot or PTZ cameras, placed on an indoor desktop or ceiling, used for home security, monitoring the elderly, children or pets.

[0106] Outdoor security cameras: typically bullet or dome cameras, waterproof and dustproof, installed on the exterior walls of residences, courtyards or shop entrances for perimeter protection and outdoor monitoring.

[0107] Dashcam: Installed inside a vehicle, it records video during driving to provide evidence in case of traffic accidents.

[0108] Video doorbell: It integrates a camera, doorbell and intercom functions, and is installed at the door of the home, allowing homeowners to check the situation at the door and talk to visitors anytime, anywhere.

[0109] Wearable cameras / law enforcement recorders: worn by specific personnel (such as police officers and security guards) to record law enforcement or work processes, ensuring transparency and traceability.

[0110] Based on the diverse device forms described above, the cameras in this disclosure can be widely used in various scenarios requiring video recording and secure storage: Smart home security: Users can remotely view their home through a mobile app, receive alarms for abnormal activity, and protect their family privacy from being leaked through encrypted storage technology.

[0111] Commercial and store monitoring: Used in shopping malls, supermarkets, offices, and other locations for theft prevention, employee management, and operational analysis. Encryption technology protects the security of commercial operational data.

[0112] Traffic records: Private car owners or commercial vehicles (such as ride-hailing vehicles and buses) record driving images. Encryption and signature technologies ensure the integrity and immutability of accident videos when used as evidence.

[0113] Public safety and law enforcement: Law enforcement officers use body cameras to record their duties, and authentication and encryption technologies provide strong technical guarantees for the judicial validity of video evidence.

[0114] It should be understood that the device forms and application scenarios listed above are merely illustrative, and the camera devices protected by this invention are not limited thereto. Any camera device capable of integrating the above hardware modules and executing the methods described in this invention should fall within the protection scope of this application.

[0115] Figure 7 This is a schematic diagram of the structure of an encrypted storage device for video data according to an embodiment of this disclosure. Figure 7 As shown, the encrypted storage device 700 for the video data includes: The first key module 701 is used to generate a device key based on at least one unique hardware identifier of the camera and a user-set custom password; The second key module 702 is used to generate a file key for each video file to be stored, based on the device key and the timing information of the video file. The encrypted storage module 703 is used to encrypt the corresponding original video file using the file key and store the encrypted video file in the storage medium.

[0116] In one possible implementation, the first key module 701 is used for: A first key is generated based on at least one unique hardware identifier of the camera; A device key is generated based on the user-set preset key and the first key.

[0117] In one possible implementation, the unique hardware identifier includes at least one of a security chip unique identifier and a central processing unit unique identifier.

[0118] In one possible implementation, the first key module 701 is used for: A hash-based message authentication code algorithm is used to generate a first key based on at least one unique hardware identifier of the camera.

[0119] In one possible implementation, the first key module 701 is used for: A key derivation function is used to generate a device key based on the user-defined password and the first key.

[0120] In one possible implementation, the timing information is the creation timestamp of the original video file.

[0121] In one possible implementation, the encrypted storage module 703 is used for: In response to the recorded video stream reaching a preset duration threshold, an original video file to be encrypted is generated; The original video file is encrypted using an authentication encryption algorithm to obtain an encrypted video file and an authentication tag for integrity verification; The authentication tag is attached to the encrypted video file.

[0122] In one possible implementation, the device further includes: The binding module is used to obtain the user-set custom password sent by the user terminal when the binding between the camera and the user account is completed on the cloud server.

[0123] Figure 8 This is a schematic diagram of the structure of an encrypted video playback device according to an embodiment of the present disclosure. Figure 8 As shown, the encrypted video playback device 800 includes: The receiving module 801 is used to receive a video playback request containing a target timestamp; The signature verification module 802 is used to obtain the corresponding target video file from the storage medium according to the target timestamp, and to verify the signature of the target video file; The key generation module 803 is used to generate a file key for decrypting the target video file based on the creation timestamp of the target video file and a preset device key, provided that the signature verification is successful. The decryption module 804 is used to decrypt the target video file using the file key and send the decrypted video data to the user terminal.

[0124] In one possible implementation, the preset device key is generated based on an intermediate key and a user-defined password; wherein the intermediate key is generated based on at least one unique hardware identifier of the camera.

[0125] In one possible implementation, the unique hardware identifier includes at least one of a security chip unique identifier and a central processing unit unique identifier.

[0126] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0127] Figure 9 This is a structural block diagram of an electronic device according to an embodiment of the present disclosure. Figure 9 As shown, the electronic device includes a memory 910 and a processor 920. The memory 910 stores a computer program that can run on the processor 920. The number of memories 910 and processors 920 can be one or more. The memory 910 can store one or more computer programs, which, when executed by the electronic device, cause the electronic device to perform the methods provided in the above-described method embodiments. The electronic device may also include a communication interface 930 for communicating with external devices and performing data exchange and transmission.

[0128] If the memory 910, processor 920, and communication interface 930 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0129] Optionally, in a specific implementation, if the memory 910, processor 920, and communication interface 930 are integrated on a single chip, then the memory 910, processor 920, and communication interface 930 can communicate with each other through an internal interface.

[0130] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0131] Further, optionally, the aforementioned memory may include read-only memory and random access memory, and may also include non-volatile random access memory. The memory may be volatile or non-volatile, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct RAMBUS RAM (DR RAM).

[0132] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this disclosure are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line, DSL) or wireless (e.g., infrared, Bluetooth, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)). It is worth noting that the computer-readable storage media mentioned in this disclosure can be non-volatile storage media; in other words, it can be non-transient storage media.

[0133] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0134] In the description of the embodiments of this disclosure, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this disclosure. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0135] In the description of the embodiments disclosed herein, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0136] In the description of embodiments of this disclosure, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more.

[0137] The above description is merely an exemplary embodiment of this disclosure and is not intended to limit this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the protection scope of this disclosure.

Claims

1. A method for encrypting and storing video data, characterized in that, include: Generate a device key based on at least one unique hardware identifier of the camera and a user-defined password; For each video file to be stored, a file key is generated based on the device key and the timing information of the video file; wherein, the timing information is the creation timestamp of the original video file; The original video file is encrypted using the file key, and the encrypted video file is stored in the storage medium.

2. The method according to claim 1, characterized in that, Generate a device key based on at least one unique hardware identifier of the camera and a user-set custom password, including: A first key is generated based on at least one unique hardware identifier of the camera; A device key is generated based on the user-set preset key and the first key.

3. The method according to claim 1, characterized in that, The step of generating a first key based on at least one unique hardware identifier of the camera includes: A hash-based message authentication code algorithm is used to generate a first key based on at least one unique hardware identifier of the camera.

4. The method according to claim 2, characterized in that, The step of generating a device key based on the user-set custom password and the first key includes: A key derivation function is used to generate a device key based on the user-defined password and the first key.

5. The method according to claim 1, characterized in that, The step of encrypting the corresponding original video file using the file key includes: In response to the recorded video stream reaching a preset duration threshold, an original video file to be encrypted is generated; The original video file is encrypted using an authentication encryption algorithm to obtain an encrypted video file and an authentication tag for integrity verification; The authentication tag is attached to the encrypted video file.

6. The method according to claim 1, characterized in that, Also includes: Once the camera and user account are bound together on the cloud server, the user-set custom password sent from the user terminal is retrieved.

7. A method for encrypted video playback, characterized in that, include: Receive video playback requests containing the target timestamp; Based on the target timestamp, the corresponding target video file is retrieved from the storage medium, and the target video file is verified by signature. If the signature verification is successful, a file key for decrypting the target video file is generated based on the creation timestamp of the target video file and the preset device key; The target video file is decrypted using the file key, and the decrypted video data is sent to the user terminal.

8. The method according to claim 7, characterized in that, The preset device key is generated based on an intermediate key and a user-defined password. The intermediate key is generated based on at least one unique hardware identifier of the camera.

9. A video data encryption storage device, characterized in that, include: The first key module is used to generate a device key based on at least one unique hardware identifier of the camera and a user-set custom password; The second key module is used to generate a file key for each video file to be stored, based on the device key and the timing information of the video file. An encrypted storage module is used to encrypt the corresponding original video file using the file key and store the encrypted video file in a storage medium.

10. An encrypted video playback device, characterized in that, include: The receiving module is used to receive video playback requests containing the target timestamp; The signature verification module is used to retrieve the corresponding target video file from the storage medium based on the target timestamp, and to verify the signature of the target video file. The key generation module is used to generate a file key for decrypting the target video file based on the creation timestamp of the target video file and a preset device key, provided that the signature verification is successful. The decryption module is used to decrypt the target video file using the file key and send the decrypted video data to the user terminal.

11. A camera device, characterized in that, include: The image acquisition module is used to acquire video data; Main control processing module; The storage medium communicating with the main control processing module is used to store encrypted video files, which are obtained by the main control processing module performing the method of any one of claims 1-8.

Images