Streaming security encryption method for prototype verification of power video surveillance chips

Abstract

This invention relates to the field of integrated circuit design verification technology, and discloses a streaming security encryption method for prototype verification of power video surveillance chips. This method obtains the risk level by parsing the video stream and generates an encryption configuration vector indicating the algorithm and header format. Based on the vector, it prefetches keys for high-risk streams and generates a pipelined verification header containing a key index. Subsequently, authentication encryption is performed in the encryption core, and the data is encapsulated into a secure data packet. This invention parameterizes the security policy and pre-generates the verification header, making the security overhead a quantifiable and deterministic item. This allows for precise removal of security overhead during prototype verification, obtaining pure evaluation data that reflects the intrinsic performance of the chip's core computing power.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit design verification technology, and in particular to a streaming security encryption method for prototype verification of power video surveillance chips. Background Technology

[0002] Prototype verification of power video surveillance chips utilizes a Field-Programmable Gate Array (FPGA)-based platform. This platform accurately and quantifiably verifies core performance indicators such as computing power, throughput, and power consumption under near-real-world video stream loads. This provides a reliable basis for final tape-out design decisions and significantly reduces R&D risks. Power surveillance video streams carry sensitive information such as the operational status and geographical location of critical infrastructure, and their transmission and storage must meet stringent security and integrity requirements. Power video surveillance chips not only need powerful computing capabilities but also must incorporate reliable data security encryption mechanisms to achieve design-as-security. This means that during the prototype verification phase, in addition to verifying computing power and energy efficiency, the functional correctness of the security mechanism and its performance under real data stream conditions must be verified simultaneously.

[0003] In existing solutions, standardized encryption algorithm hardware modules are usually directly connected to the data path of the FPGA platform. Although this method can encrypt data, it will introduce additional processing delays, logic resource consumption and dynamic power consumption into the encryption and decryption operations. These overheads are coupled with the chip's own computing performance, making it impossible for the measured system-level performance indicators to accurately reflect the true capabilities of core computing components such as neural network acceleration units in the future chip, thereby weakening the guiding value of prototype verification for chip design. Summary of the Invention

[0004] Therefore, the purpose of this invention is to overcome the shortcomings of existing technologies where direct connection of standardized encryption modules to the data path of FPGA verification platforms introduces unquantifiable performance overhead coupled with the core computing power of the chip, thereby interfering with the accurate evaluation of the chip's intrinsic performance. This invention provides a streaming security encryption method for prototype verification of power video surveillance chips. The method parameterizes the security strategy into an encryption configuration vector and pre-generates a pipelined verification header containing a key index based on the encryption configuration vector. This solidifies security auxiliary operations such as key management into predictable, fixed processing steps. This decouples the critical path of security overhead from the core data processing timing, making the processing latency and resource consumption introduced by the security mechanism in prototype verification deterministic and independently quantifiable measurement items. Thus, the performance loss of the security subsystem is accurately extracted and quantified from the total system overhead obtained in prototype verification, ultimately obtaining evaluation data that accurately reflects the intrinsic performance of the chip's core computing unit.

[0005] To address the aforementioned technical problems, this invention provides a streaming security encryption method for prototype verification of power video surveillance chips, applied to an FPGA prototype verification platform containing a configurable encryption core. The method includes: Parse the received concurrent video streams to obtain the regional risk level identifier; Based on the regional risk level identifier, a corresponding encryption configuration vector is generated; wherein, the encryption configuration vector at least indicates the risk level, encryption algorithm, and verification header format; For video streams whose encryption configuration vector indicates a high-risk level, an encryption key is obtained based on the encryption configuration vector, and the cache address of the encryption key is recorded; a pipelined verification header is generated by combining the cache address and the verification header format; the pipelined verification header includes a verification parameter segment and a key index segment that maps to the cache address; The data payloads of each video stream and the encryption configuration vector are input into the encryption core; if the encryption configuration vector indicates a high risk level, the data payload is authenticated and encrypted using the encryption key to obtain ciphertext and integrity check code; the integrity check code is filled into the verification parameter segment, and the pipelined verification header and the ciphertext are encapsulated into a secure data packet.

[0006] Preferably, parsing the received concurrent video streams to obtain the regional risk level identifier includes: parsing the protocol encapsulation of the concurrent video streams through the video stream parsing module in the FPGA prototype verification platform; if the regional risk level identifier is extracted from a specified field of the protocol encapsulation, the extracted identifier is output; if a valid regional risk level identifier cannot be extracted from the specified field of the protocol encapsulation, a preset default risk level identifier is output, and an identifier abnormality status information corresponding to the video stream is generated.

[0007] Preferably, generating a corresponding encryption configuration vector based on the regional risk level identifier includes: querying a configuration mapping table to obtain a set of baseline configuration parameters associated with the regional risk level identifier; monitoring the real-time operating status of the FPGA prototype verification platform to obtain status parameters characterizing the processing load; and selecting a target encryption algorithm from the set of baseline configuration parameters based on the status parameters to generate the encryption configuration vector.

[0008] Preferably, the state parameter includes the instantaneous power consumption of the encryption core; selecting a target encryption algorithm from the set of benchmark configuration parameters based on the state parameter includes: when the instantaneous power consumption exceeds a threshold, selecting an encryption algorithm with lower computational complexity from the set of benchmark configuration parameters as the target encryption algorithm.

[0009] Preferably, obtaining the encryption key based on the encryption configuration vector includes: determining a corresponding key derivation strategy according to the risk level indicated by the encryption configuration vector; obtaining a key identifier according to the key derivation strategy; extracting corresponding derivation parameters from the video stream according to the key derivation strategy; the derivation parameters including at least a stream sequence number; and inputting the key identifier and the derivation parameters into a key derivation function corresponding to the key derivation strategy to generate the encryption key.

[0010] Preferably, extracting corresponding derived parameters from the video stream according to the key derivation strategy includes: when the key derivation strategy indicates a first type of strategy, extracting the stream sequence number from the protocol encapsulation of the video stream as the derived parameter; when the key derivation strategy indicates a second type of strategy, simultaneously extracting the stream sequence number and the timestamp fragment from the protocol encapsulation of the video stream, and combining the stream sequence number and the timestamp fragment to generate the derived parameter.

[0011] Preferably, the method further includes: periodically collecting the physical non-cloning function response value related to the encryption core inside the FPGA prototype verification platform; and when generating the encryption key, using the physical non-cloning function response value as an additional input salt value, and inputting it into the key derivation function together with the key identifier and the derivation parameter.

[0012] Preferably, generating a pipelined verification header by combining the cache address and the verification header format includes: determining the encoding method of the key index segment according to the verification header format; and combining and encoding the cache address with the data packet sequence number of the video stream according to the encoding method to generate the key index segment.

[0013] Preferably, according to the encoding method, combining the cache address and the data packet sequence number of the video stream to generate the key index segment includes: performing a first hash operation on the cache address to obtain a first digest value; performing a second hash operation on the data packet sequence number to obtain a second digest value; interleaving specified bits of the first digest value and specified bits of the second digest value to generate a combined encoded value; and extracting corresponding bits from the combined encoded value according to the length of the key index segment to generate the key index segment.

[0014] Preferably, the method further includes: after encapsulating the security data packet, calculating the transmission hash value of the security data packet; performing iterative hash accumulation calculation on the transmission hash values ​​of all the security data packets in the current video frame to obtain a frame-level integrity credential; and embedding the frame-level integrity credential into the verification parameter segment of the first security data packet in the next video frame.

[0015] Compared with the prior art, the above-described technical solution of the present invention has the following advantages: The streaming security encryption method for prototype verification of power video surveillance chips described in this invention integrates encryption configuration vector parameters to configure the risk level of video streams, encryption algorithms, and verification header formats. Based on the encryption configuration vector, encryption keys are pre-fetched for high-risk video streams, and a pipelined verification header containing key indexes is generated, thereby enabling the encryption core to perform differentiated encryption processing according to a unified configuration.

[0016] Furthermore, this scheme pre-defines and solidifies key management operations into a rapidly parsable verification header structure, separating the critical path of security processing from the variable data processing loop. This makes the processing latency introduced by the security mechanism a deterministic and independently measurable pipeline stage, and the logic resources and dynamic power consumption consumed become clearly attributable configuration items. Thus, in the total system overhead obtained from prototype verification, the performance loss of the security subsystem can be accurately extracted and quantified, ultimately obtaining evaluation data that accurately reflects the intrinsic performance of the chip's core computing unit. This provides a direct basis for resource allocation and performance balance between security modules and computing modules in the chip architecture. Attached Figure Description

[0017] To make the content of this invention easier to understand, the invention will be further described in detail below with reference to specific embodiments and accompanying drawings, wherein: Figure 1 This is a flowchart of a streaming security encryption method for prototype verification of a power video surveillance chip in a preferred embodiment of the present invention; Figure 2 This is a flowchart of obtaining regional risk level identifiers in a preferred embodiment of the present invention; Figure 3 This is a flowchart of obtaining the encryption key in a preferred embodiment of the present invention. Detailed Implementation

[0018] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, so that those skilled in the art can better understand and implement the present invention. However, the embodiments described are not intended to limit the present invention.

[0019] The core problem to be solved in the implementation of this invention is: how to separate and accurately quantify the security processing overhead from the performance loss of the entire prototype verification system while ensuring the correct functioning of the security mechanism, so as to avoid the distortion of the performance evaluation of the core computing unit (such as the neural network accelerator) of the chip due to the introduction of the security module.

[0020] Specifically, when standard encryption IP cores are directly integrated into the data path of an FPGA prototyping platform, their encryption / decryption operations are completely coupled with video stream data processing in terms of time, resources, and power consumption. The total latency and total power consumption measured by engineers are mixed values, making it impossible to distinguish how much is core computational overhead and how much is security processing overhead. This renders performance prediction and optimization of power video surveillance chips based on prototype data inaccurate, potentially leading to the final chip failing to meet performance standards during actual deployment due to insufficient security load estimation or exceeding power consumption limits due to over-design.

[0021] To solve the above problems, the specific embodiments of the present invention are as follows: Reference Figure 1 As shown, this invention discloses a streaming security encryption method for prototype verification of power video surveillance chips, applied to an FPGA prototype verification platform containing a configurable encryption core. The method includes: S100. Parse the received concurrent video streams and obtain the regional risk level identifier; S200. Generate a corresponding encryption configuration vector based on the regional risk level identifier; wherein the encryption configuration vector indicates at least the risk level, encryption algorithm and verification header format; S300: For video streams whose encryption configuration vector indicates a high-risk level, obtain the encryption key based on the encryption configuration vector and record the cache address of the encryption key; combine the cache address and the verification header format to generate a pipelined verification header; the pipelined verification header includes a verification parameter segment and a key index segment that maps to the cache address; S400: Input the data payload and encryption configuration vector of each video stream into the encryption core; if the encryption configuration vector indicates a high risk level, use the encryption key to perform authentication encryption on the data payload to obtain ciphertext and integrity check code; fill the integrity check code into the verification parameter segment, and encapsulate the pipelined verification header and ciphertext into a secure data packet.

[0022] The following combination Figure 1 Each step is explained in detail: In specific implementation step S100, the video stream access and preprocessing module on the FPGA platform is responsible for implementation. This module receives concurrent video streams from different surveillance cameras corresponding to different geographical areas. These video streams are typically encapsulated based on the standard RTP over UDP protocol. During implementation, the module parses specific fields in the video stream protocol header, such as RTP extension headers or application-layer custom fields, to obtain preset regional risk level identifiers. For example, video streams from the core high-voltage area of ​​a substation are identified as high-risk, while video streams from ordinary office areas are identified as low-risk. The regional risk level identifier is the starting point for all subsequent differentiated processing decisions.

[0023] In specific implementation step S200, the system maintains a configuration mapping table. This table, indexed by the regional risk level identifier, stores the corresponding set of baseline configuration parameters. Upon obtaining the regional risk level identifier, the system queries this table to generate a structured encrypted configuration vector. This encrypted configuration vector is a crucial control data structure, containing at least three defined fields: the first field indicates the risk level; the second field indicates the encryption algorithm selected for that level. For example, high risk corresponds to AES-256-GCM, and low risk corresponds to AES-128-GCM or a lighter-weight verification mode; the third field indicates the verification header format, which defines the length of the key index segment, the encoding method, and the size of the verification parameter segment in the subsequently generated verification header. The encrypted configuration vector transforms the abstract security policy into concrete, hardware-executable instructions.

[0024] In specific implementation step S300, a series of meticulous preparatory work is performed only for high-risk video streams: First, the system obtains the corresponding encryption key from the key management unit according to the algorithm indication in the encryption configuration vector. After obtaining the key, it is loaded into a dedicated, adjacent high-speed cache area for the configurable encryption core, and the cache address of the encryption key in the cache is precisely recorded. The cache address is either a physical address or a logical address. Next, the system dynamically constructs a pipelined verification header by combining this cache address with the verification header format determined in step S200. This pipelined verification header is designed as a fixed-length data structure containing two key parts: one is a key index segment, which generates a fixed-length short index that can be uniquely mapped back to the original cache address through a specific encoding method; the other is a reserved verification parameter segment, the size of which is defined by the verification header format and is used to carry the integrity check code in subsequent steps.

[0025] In specific implementation step S400, the encryption core, which processes the incoming video stream's valid data payload (i.e., image data) and its corresponding encryption configuration vector, is sent together to the configurable encryption core. The encryption core parses the encryption configuration vector: if it indicates a low-risk level, a fast data integrity verification pipeline with extremely low overhead is activated; if it indicates a high-risk level, a complete authentication encryption pipeline is activated. For high-risk streams, the encryption core uses the encryption key prefetched into the adjacent buffer in step S300 to perform authentication encryption on the data payload. This authentication encryption operation outputs both the encrypted ciphertext and a cryptographically strong integrity check code in a single processing step. Subsequently, the system fills the integrity check code into the verification parameter segment of the pipelined verification header in step S300. Finally, the complete pipelined verification header and ciphertext are encapsulated to form the final secure data packet for transmission or storage.

[0026] The streaming security encryption method for prototype verification of power video surveillance chips in this invention first parameterizes the security policy into an encryption configuration vector, ensuring that each security strength selection corresponds to a set of explicit hardware configuration parameters. This means that when engineers change the security level, they are changing measurable configuration words, not unpredictable module behavior. Secondly, in step S300, the prefetching of the encryption key and the generation of the pipelined verification header advance and solidify the key lookup and scheduling that must occur at the beginning of encryption in traditional encryption processes. The encryption key is pre-placed in the adjacent buffer of the encryption core, and the key index segment in the pipelined verification header allows the receiver to quickly locate the encryption key by decoding this fixed-length field without the need for a complex lookup table. This method transforms the most uncertain and delayed part of the security process into a deterministic, parallel, fixed step.

[0027] Therefore, during the actual processing of the encryption core in step S400, the main time consumption is in the algorithm calculation itself, and this calculation delay can be accurately predicted and measured by the algorithm type and hardware frequency. Ultimately, the total delay added to the entire security subsystem (from parsing the configuration to generating the data packet) is equal to the fixed header generation delay in step S300, plus the standard calculation delay of the selected encryption algorithm in step S400; both of these parts can be accurately measured on the FPGA platform through timing analysis and actual measurement. Similarly, the number of logic units consumed and the dynamic power consumption of this security subsystem depend on the selected encryption algorithm configuration.

[0028] During the prototype verification phase, a clear comparison table can be established by running tests with different configurations. For example, enabling AES-256-GCM for high-risk stream encryption will increase the total system latency by X nanoseconds and power consumption by Y milliwatts. This increment represents the individual performance loss of the encryption security module. Subtracting this specific loss from the total system overhead yields data reflecting the intrinsic performance of the chip's core computing units. This fundamentally solves the problem of coupling security and performance evaluation, providing chip architects with the precise data needed to make three-dimensional trade-offs between security, performance, and power consumption.

[0029] In real-world, complex power monitoring network environments, video stream data may experience issues during transmission, such as device incompatibility, configuration errors, network interference, or protocol version differences. These issues can lead to the loss, corruption, or formatting of the area risk level identifier that should be carried in the protocol encapsulation. If the system cannot robustly handle such anomalies, the entire process relying on this identifier for security classification decisions will be interrupted or erroneous. This can potentially lead to two types of risks: first, mistakenly processing high-risk video streams as low-security streams, creating security vulnerabilities; and second, discarding the entire video stream due to its inability to be parsed, affecting monitoring continuity.

[0030] This invention discloses a parsing mechanism with fault tolerance and degradation processing capabilities, which has been used to obtain regional risk level identification; specifically, refer to... Figure 2 As shown, parsing the received concurrent video streams to obtain the regional risk level identifier includes: parsing the protocol encapsulation of the concurrent video streams through the video stream parsing module in the FPGA prototype verification platform; if the regional risk level identifier is extracted from the specified field of the protocol encapsulation, the extracted identifier is output; if a valid regional risk level identifier cannot be extracted from the specified field of the protocol encapsulation, a preset default risk level identifier is output, and an identifier abnormality status information corresponding to the video stream is generated.

[0031] The specific implementation method of this solution is as follows: First, this step is performed by the video stream parsing module in the FPGA prototyping platform. Implemented at the hardware level, the video stream parsing module includes a protocol parsing state machine, a data buffer, and field extraction logic. Its implementation begins with decapsulating the input concurrent video stream at the link layer and network layer protocols until it reaches the protocol unit carrying the video data at the application layer or transport layer. During parsing, the video stream parsing module locates a specified field in the protocol encapsulation according to predefined rules. The specific location of this specified field is pre-configured; for example, it could be a field identified by a specific ID in the RTP header extension, or a fixed offset within a custom structure in the application layer packet header. The video stream parsing module attempts to extract binary data conforming to the expected data format and length requirements from this predetermined location and interprets it as a regional risk level identifier.

[0032] If the regional risk level identifier is successfully extracted from the specified field encapsulated in the protocol, the video stream parsing module outputs the extracted identifier.

[0033] If a valid regional risk level identifier cannot be extracted from the specified fields encapsulated in the protocol, the system initiates a fault-tolerant processing procedure. Failure to extract a valid identifier encompasses various situations: the specified field is completely missing, the field exists but the data value exceeds the legal range, the field format is unrecognizable, or CRC verification fails, etc. In this case, the video stream parsing module executes a preset degradation strategy: outputting a pre-defined default risk level identifier. This default risk level identifier is a static parameter configured during system initialization and is typically set to a conservative, safety-oriented value. Simultaneously, to avoid losing abnormal information, the video stream parsing module generates an identifier abnormal status information corresponding to the video stream. This abnormal status information can be a multi-bit status code, recording the specific type of abnormality, and can be associated with metadata such as the source address and timestamp of the video stream. It is written to a dedicated status register or log buffer for upper-layer monitoring software or debugging interfaces to read and trigger alarms.

[0034] The solution of this invention introduces a conditional branching and default value fault tolerance mechanism to ensure that the system can continuously output a definite risk level when the video stream risk identifier extraction is abnormal. This serves two purposes: first, it guarantees the continuity of the security processing pipeline, enabling prototype verification to run stably under non-ideal data streams, thereby obtaining reliable performance statistics; second, it avoids unexpected security degradation caused by missing identifiers, plugging potential vulnerabilities at the hardware level. This solution embeds robust design principles from the software layer into the front end of the data path using hardware logic, significantly improving the adaptability of the prototype verification system to real-world complex environments and the reliability of its results.

[0035] The aforementioned scheme generates corresponding encryption configuration vectors based on regional risk level identifiers. However, in practice, the prototype verification platform inevitably faces real-time changing loads. Specifically, the platform needs to simulate the future chip's performance under various operating conditions, as factors such as video stream input rate, system temperature, and power supply stability are not constant. While statically configuring a fixed high-strength encryption algorithm based on risk level (e.g., always using AES-256-GCM for high-risk streams) is feasible under low system load, it can lead to a sharp increase in processing latency, buffer overflows, and even data loss when video streams suddenly increase or the platform approaches its processing capacity limit. This not only disrupts the continuity of verification but also causes the measured performance data to deviate significantly from normal performance.

[0036] To ensure that the selected security encryption strength meets basic security policy requirements while adaptively avoiding system performance bottlenecks or real-time performance failures due to excessive security computation overhead, the embodiment of this invention generates a corresponding encryption configuration vector based on the regional risk level identifier. This includes: querying a configuration mapping table to obtain a set of baseline configuration parameters associated with the regional risk level identifier; monitoring the real-time operating status of the FPGA prototype verification platform to obtain status parameters characterizing the processing load; and selecting a target encryption algorithm from the set of baseline configuration parameters based on the status parameters to generate the encryption configuration vector.

[0037] In practice, the system maintains a configuration mapping table, which is initialized in non-volatile memory (such as the FPGA's Block RAM or external Flash) and its contents are loaded during system startup. Each record in the configuration mapping table uses a region risk level identifier as the key and is associated with a set of baseline configuration parameters. This set is not a single parameter, but contains multiple optional encryption algorithms and their associated configurations pre-defined for that risk level. For example, for a high-risk level, the baseline configuration parameter set includes: Algorithm A: AES-256-GCM, high strength, high latency; Algorithm B: AES-128-GCM, medium strength, medium latency, etc.

[0038] The process begins with the system querying this configuration mapping table. Based on the regional risk level identifier obtained in step S100, it uses it as an index to look up the corresponding record in the table, thereby obtaining the set of baseline configuration parameters associated with the regional risk level identifier.

[0039] Meanwhile, the system continuously monitors the real-time operating status of the FPGA prototyping platform. This monitoring is accomplished by dedicated hardware performance counters and sensor modules. The specific methods for acquiring status parameters characterizing the processing load can be varied: a key implementation is monitoring the input buffer occupancy rate of the configurable encryption core, which directly reflects the backlog of data to be processed; another method is monitoring the instantaneous power consumption of the encryption core itself or the chip's junction temperature, these parameters indirectly reflect the current computational load and heat dissipation pressure; changes in system bus bandwidth utilization or video stream input frame rate can also be monitored. These status parameters are acquired in real time and quantified into digital values.

[0040] In a preferred embodiment of the present invention, the state parameters include the instantaneous power consumption of the encryption core; selecting the target encryption algorithm from the set of benchmark configuration parameters based on the state parameters includes: when the instantaneous power consumption exceeds a threshold, selecting an encryption algorithm with lower computational complexity from the set of benchmark configuration parameters as the target encryption algorithm.

[0041] In the specific implementation process, the first step is to accurately obtain the instantaneous power consumption of the encryption core. A hard-core power management module is integrated into the FPGA. This module samples the voltage and calibrated current information of the encryption core's power supply network. Through firmware or hardware logic, the sampled values ​​are periodically read, and an approximate instantaneous power consumption value is obtained by calculating: Power = Voltage × Current. Alternatively, an activity factor-based estimation method can be used: monitoring the switching frequency of key logic units within the encryption core (such as S-boxes and multipliers), and combining this with a pre-calibrated unit activity power consumption coefficient during the simulation phase, the dynamic power consumption can be estimated in real time. Regardless of the specific technology used, the acquired power consumption data is quantified into a numerical value for use in subsequent decision-making logic.

[0042] Lower computational complexity here is a comparative concept; for example, if the baseline configuration parameter set originally prepared the AES-256-GCM algorithm for high-risk streams, the dynamic selection logic might switch to the AES-128-GCM algorithm within the same set when power consumption exceeds limits. Since AES-128 has fewer rounds, the logic flipping activities required for its execution are correspondingly reduced, directly leading to a decrease in instantaneous power consumption. After selecting the new algorithm, the system generates an updated encryption configuration vector containing the new encryption algorithm indication; subsequent incoming video streams belonging to the same risk level will have their data payloads encrypted using this new, lower-complexity encryption algorithm.

[0043] Furthermore, the present invention discloses a method for dynamically deriving differentiated encryption keys for different video streams under the same risk level, or even for different time periods of the same video stream, with reference to... Figure 3 As shown, specifically: obtaining the encryption key based on the encryption configuration vector includes: determining the corresponding key derivation strategy according to the risk level indicated by the encryption configuration vector; obtaining the key identifier according to the key derivation strategy; extracting the corresponding derivation parameters from the video stream according to the key derivation strategy; the derivation parameters include at least the stream sequence number; and inputting the key identifier and the derivation parameters into the key derivation function corresponding to the key derivation strategy to generate the encryption key.

[0044] Specifically, based on the key derivation strategy, the corresponding derived parameters are extracted from the video stream, including: when the key derivation strategy indicates the first type of strategy, the stream sequence number is extracted from the protocol encapsulation of the video stream as a derived parameter; when the key derivation strategy indicates the second type of strategy, the stream sequence number and timestamp fragment are extracted from the protocol encapsulation of the video stream simultaneously, and the stream sequence number and timestamp fragment are combined to generate the derived parameters.

[0045] In practice, the risk level indicated in the encryption configuration vector is the primary basis for selecting the key derivation strategy. The system maintains a risk level-derivation strategy mapping table. For example, a high-risk level is mapped to a strong-security, single-stream single-key first-class strategy; a low-risk level is mapped to an efficient, moderately reusable second-class strategy. Determining the corresponding key derivation strategy means not only selecting a strategy identifier but also activating a whole set of rules bound to that strategy, including the key identifier generation / acquisition rules, derivation parameter extraction rules, and the selection of the key derivation function.

[0046] Next, the key identifier is obtained according to the key derivation strategy. For the first strategy, the key identifier is a composite structure: it consists of a long-term valid regional root key identifier and a session seed periodically generated by the security hardware module. The system queries the key management unit, uses the regional root key identifier to obtain the corresponding key material, and then combines it with the session seed to generate the final key identifier used for derivation. For the second strategy, the key identifier is directly a daily key index that remains unchanged for a relatively long period (e.g., one day). This step ensures that the source and update cycle of the key are different under different strategies.

[0047] Simultaneously, based on the key derivation strategy, corresponding derived parameters are extracted from the video stream. Under all strategies, the stream sequence number is the basic derived parameter, ensuring key differences between different data packets within the same video stream. For the first type of strategy, richer derived parameters are extracted according to its rules, such as the high-order bits of the timestamp or the frame type identifier of the data packet. These additional parameters are extracted from the RTP header or application layer extension header of the video stream through the protocol parsing module. For the second type of strategy, only the stream sequence number is extracted.

[0048] Finally, the key derivation function is invoked. The system selects one of several pre-defined key derivation functions based on the chosen key derivation strategy. The first type of strategy corresponds to a slower but cryptographically stronger function, such as HKDF based on HMAC-SHA256; the second type corresponds to a lighter function, such as fast key derivation based on CMAC-AES. The key identifier and derivation parameters are input into this function, which then performs internal calculations to generate the final encryption key.

[0049] By combining the regional root key identifier, dynamic session seed, and multi-dimensional derivation parameters (sequence number + timestamp), the derived encryption key simultaneously possesses identity binding, timestamp binding, and sequence uniqueness, greatly increasing the difficulty of attacks: even if an attacker intercepts the communication key at a certain moment, they cannot decrypt data before or after it (forward / backward security), nor can they impersonate data sources from other regions or time points. For low-risk flows, a simpler derivation pattern is adopted, significantly reducing key management overhead and computational latency while meeting basic security requirements.

[0050] In key derivation schemes, even with complex strategies and parameters, the derivation process is logically completely deterministic. This means that if an attacker obtains all the logical inputs (key identifier, derivation parameters) and encryption algorithms through reverse engineering, firmware extraction, or management vulnerabilities, they can perfectly reproduce the same encryption key on another identical hardware platform (or even a software simulator), thereby achieving decryption or forgery of encrypted communications.

[0051] To fundamentally defend against firmware / configuration cloning attacks, supply chain attacks, and cross-device reuse attacks targeting key materials, the method also includes: periodically collecting the physical non-cloning function response values ​​related to the encryption core within the FPGA prototyping platform; and when generating encryption keys, using the physical non-cloning function response values ​​as additional input salt values, which are input into the key derivation function along with the key identifier and derivation parameters.

[0052] In the specific implementation process, the Physically Unclonable Function (PUF) response values ​​related to the encryption core within the FPGA prototype verification platform are periodically collected. During implementation, a PUF module is instantiated in the FPGA design. Each time the PUF module is activated, it generates a response based on the chip's internal physical characteristics. This response is highly repeatable on the same chip, but statistically random and unpredictable across different chips. The collection operation is performed periodically, for example, once at system startup and buffered, or before each key derivation; the period is configurable. The collected raw analog responses are processed by a stability enhancement circuit, outputting a stable and clean binary sequence, i.e., the Physically Unclonable Function response value.

[0053] Subsequently, in each execution flow of generating encryption keys, when the key derivation function is called, the implementation process not only passes in the two logical inputs—the key identifier and the derived parameters—but also, crucially, involves using the Physically Unclonable Function (PUF) response value as an additional input salt, which is then input into the key derivation function along with the key identifier and the derived parameters. Specifically, on the hardware data path, the PUF response value is used as an additional input port, concatenated with the other two inputs or fed into the core computation unit of the key derivation function through specific hybrid logic. For example, internally, the function first performs an XOR operation between the PUF response value and the key identifier to obtain the HMAC key, and then uses the derived parameters as the message for computation. This operation ensures that the PUF response value is deeply involved in the key generation computation process.

[0054] Based on the above embodiments, a pipelined verification header is generated by combining the cache address and the verification header format, including: determining the encoding method of the key index segment according to the verification header format; and combining and encoding the cache address and the data packet sequence number of the video stream according to the encoding method to generate the key index segment.

[0055] In practice, the verification header is part of the encryption configuration vector. It explicitly defines the overall structure of the pipelined verification header, particularly the length of the key index segment and the encoding algorithm identifier. The encoding algorithm identifier points to a predefined encoding rule. For example, encoding method A is truncated hash encoding, and method B is bit interleaving and cyclic shift encoding. Based on the obtained verification header format, the corresponding encoding logic hardware module is activated.

[0056] Taking truncated hash encoding as an example, its specific implementation is as follows: The hardware encoding module receives two inputs: one is the cache address, and the other is the data packet sequence number parsed from the header of the current video stream data packet. The encoding logic first concatenates these two input data into an intermediate data block in a predetermined order. Then, this intermediate data block is input into a lightweight cryptographic hash function; the output of the hash function is a relatively long digest. Finally, according to the length defined for the key index segment, a corresponding number of bits are truncated from a fixed position in the digest as the final generated key index segment. Another bit-interleaved encoding method involves interleaving the bits of the cache address and sequence number according to a specific rule, followed by another obfuscation operation. Regardless of the method, the generated key index segment is a short string of fixed length that depends on both the cache address and the sequence number.

[0057] In this embodiment of the invention, because the key index segment is a hash value shared by the cache address and the data packet sequence number, the receiving end cannot extract either the address or the sequence number from it alone. To locate the encryption key, the receiving end must simultaneously know the correct data packet sequence number; conversely, to verify the freshness of the data packet, it must also find the encryption key through the correct address to decrypt and verify the entire data packet. This bidirectional dependency creates a secure closed loop. More importantly, this combined encoding introduces pseudo-randomness to the key index segment itself in terms of cryptographic strength. Even if the cache address remains unchanged for a long time, as long as the data packet sequence number changes continuously, the generated key index segment will also change continuously without a clear pattern. This increases the difficulty for attackers to infer the key cache location or predict future index values ​​through side-channel listening and statistical analysis of the header.

[0058] Furthermore, according to the encoding method, the cache address and the data packet sequence number of the video stream are combined and encoded to generate a key index segment, including: performing a first hash operation on the cache address to obtain a first digest value; performing a second hash operation on the data packet sequence number to obtain a second digest value; interleaving specified bits of the first digest value and specified bits of the second digest value to generate a combined encoded value; and extracting corresponding bits from the combined encoded value according to the key index segment length to generate a key index segment.

[0059] In the specific implementation, a first hash operation is performed on the cache address: the complete cache address value is taken as input and fed into a first hash function, such as SHA-256; after calculation, the first hash function outputs a first digest value that is much longer than the input. Similarly, a second hash operation is performed on the packet sequence number: the packet sequence number is taken as input and fed into a second hash function (which may be the same as or different from the first function); the second hash function outputs a second digest value that is also quite long. These two hash operations are performed independently and do not interfere with each other. Their purpose is to first expand and diffuse the original inputs into long bit strings with good random statistical properties.

[0060] The interleaving rule defines the specific positions and order in which bits are selected from the first digest value and the second digest value. For example, the rule can be defined as: starting from bit 0 of the first digest value, take every other bit; simultaneously, starting from bit 1 of the second digest value, take every other bit. Then, these two sets of bits are alternately arranged into a new bit sequence according to their relative order in their respective sources. For example, the arrangement order could be: [first digest bit 0, second digest bit 1, first digest bit 2, second digest bit 3, ...]. This operation can be efficiently implemented in hardware using a carefully designed interleaving selector (MUX array) and shift register. Through this interleaving, bits from the two sources are deeply and uniformly mixed together to form a combined coded value. This value is typically on the order of the sum of the lengths of the first two digest values, providing abundant bit resources.

[0061] The final step is to extract the corresponding bits from the combined encoded value according to the key index segment length to generate the key index segment; the key index segment length is a fixed value defined by the verification header format. Following predetermined extraction rules, such as truncating 32 consecutive bits from the middle of the combined encoded value or selecting 32 specific positions, a corresponding number of bits are selected from the large combined encoded value. This is equivalent to downsampling the intermediate result after deep mixing, ultimately outputting a fixed-length key index segment.

[0062] In this embodiment, the solution first performs hash operations on the cache address and the data packet sequence number to obtain the diffused digest value, then deeply interleaves the bits of the two digest values ​​to completely merge them, and finally extracts a fixed-length field from the fusion result. This disrupts the traceable association between the original input and the final key index segment at the bit level, making it impossible for attackers to reverse-engineer any valid information about the original cache address or sequence number by intercepting a large number of index segments and performing statistical analysis.

[0063] Furthermore, the method also includes: after encapsulating the obtained security data packet, calculating the transmission hash value of the security data packet; performing iterative hash accumulation calculation on the transmission hash values ​​of all security data packets in the current video frame to obtain a frame-level integrity credential; and embedding the frame-level integrity credential into the verification parameter segment of the first security data packet in the next video frame.

[0064] In the specific implementation process, after the system encapsulates and obtains the secure data packet, it calculates the transmission hash value of the secure data packet before sending it. The object of the transmission hash value calculation here is the secure data packet that is about to enter the transmission channel, including its pipelined verification header and the encrypted ciphertext payload. The calculation uses a cryptographic hash function (such as SHA-256 or BLAKE2s) to generate a fixed-length hash value, which uniquely represents the entire content of the specific data packet.

[0065] Next, the system needs to maintain a frame-level state, which iteratively accumulates hashes on the transmission hashes of all security packets within the current video frame. In practice, the system identifies video frame boundaries. For each security packet belonging to the same video frame, after calculating its transmission hash, it immediately combines it with the current value of a frame cumulative hash register and calculates a new hash value to update the register. A typical iterative hash accumulation calculation method is to concatenate the current frame cumulative hash register value with the just-calculated transmission hash value, then calculate a hash on the concatenated combination, and store the result back in the frame cumulative hash register. That is: New cumulative value = Hash(Old cumulative value || New packet hash value). When the last packet of the current frame has been processed, the final value stored in the frame cumulative hash register is the frame-level integrity credential for that frame.

[0066] Finally, a cross-frame linking operation is performed: the frame-level integrity credential is embedded into the verification parameter segment of the first secure packet in the next video frame. When constructing the first secure packet of the next frame, the system fills the frame-level integrity credential into a reserved location in the verification parameter segment of its pipelined verification header. The frame-level integrity credential will be protected as part of the encrypted authentication input for the first packet of the next frame. This means that the integrity verification of the first packet of the next frame will simultaneously verify both its own content and the integrity credential of the previous frame.

[0067] The present invention generates a frame-level integrity credential by calculating and accumulating the transmission hash value of the secure data packet, and embeds this credential into the first packet of the next frame, thereby constructing a cryptographic hash chain spanning data packets and video frames. This chain mechanism enables the receiver not only to verify the integrity of a single data packet, but also to effectively detect advanced attacks such as deletion, reordering, replacement of data packets within a frame, and loss or tampering of the entire frame data by comparing the expected credential with the received credential.

[0068] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A streaming security encryption method for prototype verification of power video surveillance chips, applied to an FPGA prototype verification platform containing a configurable encryption core, characterized in that, The method includes: Parse the received concurrent video streams to obtain the regional risk level identifier; Based on the regional risk level identifier, a corresponding encryption configuration vector is generated; wherein, the encryption configuration vector at least indicates the risk level, encryption algorithm, and verification header format; For video streams whose encryption configuration vector indicates a high-risk level, an encryption key is obtained based on the encryption configuration vector, and the cache address of the encryption key is recorded; a pipelined verification header is generated by combining the cache address and the verification header format; the pipelined verification header includes a verification parameter segment and a key index segment that maps to the cache address; The data payloads of each video stream and the encryption configuration vector are input into the encryption core; if the encryption configuration vector indicates a high risk level, the data payload is authenticated and encrypted using the encryption key to obtain ciphertext and integrity check code; the integrity check code is filled into the verification parameter segment, and the pipelined verification header and the ciphertext are encapsulated into a secure data packet.

2. The streaming security encryption method for power video surveillance chip prototype verification according to claim 1, characterized in that, Parse the received concurrent video streams to obtain the regional risk level identifier, including: The protocol encapsulation of the concurrent video stream is parsed using the video stream parsing module in the FPGA prototype verification platform. If the regional risk level identifier is extracted from the specified field encapsulated in the protocol, the extracted identifier is output. If a valid regional risk level identifier cannot be extracted from the specified field encapsulated by the protocol, a preset default risk level identifier is output, and an identifier abnormal status information corresponding to the video stream is generated.

3. The streaming security encryption method for power video surveillance chip prototype verification according to claim 1, characterized in that, Based on the regional risk level identifier, a corresponding encryption configuration vector is generated, including: Query the configuration mapping table to obtain the set of baseline configuration parameters associated with the risk level identifier of the region; Monitor the real-time operating status of the FPGA prototype verification platform to obtain status parameters characterizing the processing load; based on the status parameters, select a target encryption algorithm from the set of baseline configuration parameters to generate the encryption configuration vector.

4. The streaming security encryption method for power video surveillance chip prototype verification according to claim 3, characterized in that, The status parameters include the instantaneous power consumption of the encryption core; Selecting a target encryption algorithm from the set of baseline configuration parameters based on the state parameters includes: when the instantaneous power consumption exceeds a threshold, selecting an encryption algorithm with lower computational complexity from the set of baseline configuration parameters as the target encryption algorithm.

5. The streaming security encryption method for power video surveillance chip prototype verification according to claim 1, characterized in that, Obtaining the encryption key based on the encryption configuration vector includes: Determine the corresponding key derivation strategy based on the risk level indicated by the encryption configuration vector; Obtain the key identifier according to the key derivation strategy; According to the key derivation strategy, the corresponding derivation parameters are extracted from the video stream; the derivation parameters include at least the stream sequence number; The key identifier and the derived parameters are input into the key derivation function corresponding to the key derivation strategy to generate the encryption key.

6. The streaming security encryption method for power video surveillance chip prototype verification according to claim 5, characterized in that, According to the key derivation strategy, the corresponding derivation parameters are extracted from the video stream, including: When the key derivation strategy is indicated as the first type of strategy, the stream sequence number is extracted from the protocol encapsulation of the video stream as the derivation parameter; When the key derivation strategy is indicated as the second type of strategy, the stream sequence number and timestamp fragment are extracted simultaneously from the protocol encapsulation of the video stream, and the stream sequence number and the timestamp fragment are combined to generate the derivation parameter.

7. The streaming security encryption method for power video surveillance chip prototype verification according to claim 5, characterized in that, The method also includes: Periodically collect the physical non-cloning function response values ​​related to the encryption core within the FPGA prototype verification platform; When generating the encryption key, the physical non-clonable function response value is used as an additional input salt value, which is input into the key derivation function along with the key identifier and the derivation parameters.

8. The streaming security encryption method for power video surveillance chip prototype verification according to claim 1, characterized in that, Combining the cache address and the verification header format, a pipelined verification header is generated, including: The encoding method of the key index segment is determined according to the verification header format; According to the encoding method, the cache address and the data packet sequence number of the video stream are combined and encoded to generate the key index segment.

9. The streaming security encryption method for power video surveillance chip prototype verification according to claim 8, characterized in that, According to the encoding method, the cache address and the data packet sequence number of the video stream are combined and encoded to generate the key index segment, including: Perform a first hash operation on the cache address to obtain a first digest value; perform a second hash operation on the data packet sequence number to obtain a second digest value; The specified bits of the first digest value and the specified bits of the second digest value are interleaved to generate a combined encoded value; Based on the length of the key index segment, the corresponding bits are extracted from the combined encoded value to generate the key index segment.

10. The streaming security encryption method for power video surveillance chip prototype verification according to claim 1, characterized in that, The method also includes: After encapsulating the secure data packet, calculate the transmission hash value of the secure data packet; The frame-level integrity credential is obtained by iteratively hashing and accumulating the transmission hash values ​​of all the security data packets in the current video frame. The frame-level integrity credential is embedded into the verification parameter segment of the first security data packet of the next video frame.

Images