Code stream signature and authentication method
By independently calculating the summary data for each data unit and using authentication identifiers, the problem of authentication failure and high complexity in the tree signature process of audio and video content in the prior art is solved, and the independent authentication and simplified authentication process for each data unit is realized.
Patent Information
- Application Number
- CN202311614838.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-11-28
- Publication Date
- 2025-05-30
AI Technical Summary
In the prior art, in the tree signature process of audio and video content, if a single network abstraction layer (NAL) unit errors or changes in transmission sequence, it leads to authentication failure and cannot be individually authenticated for each NAL unit or NAL unit sequence, resulting in high authentication complexity.
A code stream signature and authentication method is proposed. By independently calculating summary data for each data unit and identifying data units with authentication identifiers, we ensure the one-to-one correspondence between the data unit and the authentication data, and support independent authentication of each data unit.
It realizes that other data units can still be authenticated when some data units are lost, avoiding the problem of mismatch between data units and authentication data caused by long signature time, and simplifying the authentication process.
Smart Images

Figure CN120074826A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present application relate to the field of media, and in particular, to a method for signing and authenticating a bitstream. Background Art
[0002] In many audio and video encoding and decoding scenarios (such as monitoring, live broadcast, video-on-demand, etc.), there are certain requirements for the authenticity and integrity of audio and video content; therefore, in order to ensure the security of audio and video content during transmission and prevent the audio and video content from being tampered with during transmission, it is necessary to sign the audio and video content.
[0003] However, the current technology for tree-shaped signing of audio and video content has some defects: for example, if a single Network Abstract Layer (NAL) unit is incorrect, or the order of NAL units changes during transmission, it will cause multiple NAL units participating in the authentication to fail. Another example is that each NAL unit or NAL unit sequence cannot be authenticated independently. Another example is that if there are multiple NAL unit sequences that need to be decoded independently, or support frame extraction scenarios, or the base layer and enhancement layer NAL unit sequences in GB / T 25724-2017, multiple independent authentication sequences are required, which will make the authentication very complex and difficult to implement using existing technologies. Another example is that the encoding rate is relatively fast while the signing time is relatively long, which will cause the position of the authentication data in the bitstream to be uncertain; or in the case where the authentication data of the previous frame NAL unit sequence is lost, the authentication data cannot be matched with the corresponding NAL unit sequence to be authenticated; and so on. Summary of the Invention
[0004] In view of this, the present application provides a method for signing and authenticating a bitstream.
[0005] In a first aspect, the embodiments of the present application provide a method for signing a bitstream, where the bitstream includes: a group of data units and an authentication identifier for each data unit in the group of data units, and the method includes: first, obtaining authentication data; where the authentication data includes: signature data, an authentication identifier for each data unit in the group of data units, and digest data for each data unit in the group of data units, and the signature data is obtained by signing the digest data for each data unit in the group of data units; then, adding the authentication data to the bitstream.
[0006] Among them, the authentication identifier of each data unit can be used to uniquely identify a data unit; the authentication identifiers of multiple data units in a group of data units can be used to determine the authentication data used for authenticating the group of data units.
[0007] That is to say, for each data unit, the present application independently generates a digest and transmits the digest data of each data unit to the authentication end; in this way, the authentication end can independently authenticate each data unit; therefore, even if some data units are lost (frames are dropped), other data units can still be authenticated. In addition, since the data units are identified using an authentication identifier, the one-to-one correspondence between the data units and the authentication data is ensured, avoiding the problem of mismatch between the data units and the authentication data caused by a long signature time.
[0008] For the temporal scalable video coding (SVC) of the Surveillance Video and Audio Coding (SVAC) standard for public security video surveillance, each data unit uses a temporal_id to identify its temporal layer. During decoding, some temporal layers or data units may not participate in the decoding; in the present application, since each data unit independently generates digest data, during authentication, for the data units participating in authentication, the corresponding digest data can be found in the authentication data, and the data units not participating in authentication do not affect the authentication of other data units.
[0009] For the spatial SVC coding of the SVAC standard, each data unit uses a layer_id to identify its spatial layer. During decoding, some spatial layers or data units may not participate in the decoding; in the present application, since each data unit independently generates digest data, during authentication, for the data units participating in authentication, the corresponding digest data can be found in the authentication data, and the data units not participating in authentication do not affect the authentication of other data units.
[0010] For the video quality SVC coding of the SVAC standard, during decoding, some quality layers or data units may not participate in the decoding. In the present application, since each data unit independently generates digest data, during authentication, for the data units participating in authentication, the corresponding digest data can be found in the authentication data, and the data units not participating in authentication do not affect the authentication of other data units.
[0011] In addition, for SVC coding, only a set of authentication data for the data units needs to be transmitted to support the authentication of the sub-bitstreams extracted from the bitstream.
[0012] That is to say, the present application can also effectively solve the problem that the current temporal SVC coding, spatial SVC coding, and video quality SVC coding of the SVAC standard require independent authentication.
[0013] data unit
[0014] The basic syntax structure of the coded bitstream can be either a NAL unit or an access unit.
[0015] NAL unit
[0016] A syntax structure that contains the type indication of the subsequent data and the number of bytes included (located in the NAL header), and the data appears in the form of a Raw Byte Sequence Payload (RBSP), which may also include scattered anti-counterfeiting bytes when necessary.
[0017] Access unit
[0018] A group of NAL units that are correlated with each other according to specified rules and are consecutive in decoding order.
[0019] It should be noted that, from another dimension, the data unit can also include a coded picture.
[0020] Coded picture
[0021] The coded representation of a frame of image.
[0022] It should be noted that the present application does not group the data units, but for the convenience of description, the term "a group of data units" is used to describe.
[0023] Exemplarily, a group of data units can include n data units, and these n data units are all data units that need to be authenticated, where n is a positive integer. Correspondingly, the authentication data can include n authentication identifiers and n digest data, and the n authentication identifiers correspond to the n data units one by one, and the n digest data correspond to the n data units one by one. Exemplarily, "a group of data units" can also be described as "n data units".
[0024] Exemplarily, the authentication identifier can also be referred to as an authentication serial number (such as it can be represented by authentication_id).
[0025] Exemplarily, the multiple digest data of a group of data units can form a digest data list; that is to say, the authentication data can include a digest data list.
[0026] Exemplarily, the authentication data can be Auth.
[0027] Exemplarily, the signature data can be signature.
[0028] Exemplarily, the digest data can also be referred to as authentication digest data.
[0029] Exemplarily, the bitstream may be an audio compression bitstream (or referred to as an audio compression bitstream) or a video compression bitstream (or referred to as a video compression bitstream), and the present application does not limit this. The present application takes the signing and authentication of a video compression bitstream as an example for illustration.
[0030] bitstream
[0031] The binary data stream formed by encoding image / audio frames.
[0032] According to the first aspect, the method further includes: calculating, according to a digest algorithm, each data unit in a set of data units to obtain the digest data of each data unit in the set of data units. In this way, the digest data of each data unit can be quickly determined.
[0033] For example, calculating, according to the digest algorithm, data unit 1 in a set of data units to obtain the digest data of data unit 1; calculating, according to the digest algorithm, data unit 2 in a set of data units to obtain the digest data of data unit 2;... and so on.
[0034] Exemplarily, the digest data of each data unit in a set of data units may be calculated by hashing (Hash) according to a digest algorithm to obtain the digest data of each data unit in the set of data units.
[0035] It should be understood that the present application does not limit the type of digest algorithm.
[0036] Exemplarily, the digest data may also be referred to as authentication digest data (such as authentication_hash).
[0037] According to the first aspect, or any one of the above implementation manners of the first aspect, the method further includes: concatenating the digest data of each data unit in a set of data units to determine the digest data of the concatenated digest data; signing the digest data of the concatenated digest data with a private key to obtain signature data. In this way, the signature data can be quickly determined.
[0038] Exemplarily, the concatenation may be splicing. For example, the digest data of n data units are respectively: H1, H2, H3, H4, H5,..., Hn; then the concatenated digest data is H1 + H2 + H3 + H4 + H5 +... + Hn. Hashing the concatenated digest data H1 + H2 + H3 + H4 + H5 +... + Hn to obtain the digest data Hg of the concatenated digest data.
[0039] It should be understood that the tree-top digest data may also be generated and signed with a private key to obtain the signature data. The present application does not limit the manner of signing according to the digest data of data units.
[0040] Exemplarily, the private key may be PrivateKey.
[0041] According to the first aspect, or any implementation manner of the above first aspect, the method further includes: generating authentication data according to the signature data, the authentication identifier of each data unit in a set of data units, and the digest data of each data unit in the set of data units.
[0042] According to the first aspect, or any implementation manner of the above first aspect, adding the authentication data to the bitstream includes: encoding the authentication data and adding the encoded authentication data to the bitstream. In this way, the bitrate overhead can be reduced.
[0043] Exemplarily, the authentication data can be encoded using Base64; then, the encoded authentication data is packed into the NAL unit of the authentication data in the bitstream.
[0044] According to the first aspect, or any implementation manner of the above first aspect, each data unit in a set of data units includes one or more Network Abstraction Layer (NAL) units.
[0045] Exemplarily, when a data unit is one NAL unit, a set of data units may include multiple NAL units, and the authentication identifiers of each NAL unit are different. When a data unit is multiple NAL units, a set of data units includes multiple access units, the authentication identifiers of each access unit are different, and the authentication identifiers of the multiple NAL units included in each access unit are the same.
[0046] According to the first aspect, or any implementation manner of the above first aspect, multiple NAL units in a set of data units are associated with each other according to a specified rule, and the decoding order of multiple NAL units in the set of data units is consecutive. That is to say, one data unit is one access unit
[0047] According to the first aspect, or any implementation manner of the above first aspect, each data unit in a set of data units includes an encoded image.
[0048] According to the first aspect, or any implementation manner of the above first aspect, each NAL unit includes the authentication identifier of the data unit to which it belongs. In this way, it is convenient for the authentication side to know the one-to-one correspondence between the NAL unit and the authentication identifier.
[0049] Specifically, it may be that the NAL header of each NAL unit includes the authentication identifier of the data unit to which it belongs.
[0050] Exemplarily, compared with the prior art, the NAL unit of the present application newly adds an authentication identifier authentication_id.
[0051] According to the first aspect, or any implementation manner of the above first aspect, the authentication identifier of each data unit in a group of data units in the bitstream is located before the group of data units. In this way, the authentication end can receive the authentication identifier of each data unit in a group of data units before receiving the group of data units, so as to ensure that the authentication end marks each data unit in the received group of data units according to the authentication identifier of each data unit in the group of data units, determines the authentication identifier of each data unit, and ensures the corresponding relationship between the data unit and the authentication data.
[0052] According to the first aspect, or any implementation manner of the above first aspect, the bitstream further includes a safety parameter set, and the safety parameter set includes the authentication identifier of each data unit in a group of data units.
[0053] Exemplarily, the safety parameter set is located before the group of data units.
[0054] Exemplarily, compared with the prior art, the safety parameter set of the present application newly adds: authentication_id (which can also be called the authentication identifier).
[0055] In a possible manner, the safety parameter set in the bitstream is represented in the form of RBSP. Therefore, the bitstream further includes a safety parameter set, and the safety parameter set includes the authentication identifier of each data unit in a group of data units, which can be written as the bitstream further includes a safety parameter set RBSP, and the safety parameter set RBSP includes the authentication identifier of each data unit in a group of data units.
[0056] According to the first aspect, or any implementation manner of the above first aspect, the bitstream further includes extension information, and the extension information includes the authentication identifier of each data unit in a group of data units.
[0057] Exemplarily, the extension information is located before the group of data units.
[0058] Exemplarily, the CEI extension information of the present application newly adds: authentication_id (which can also be called the authentication identifier).
[0059] Optionally, hash_type (hash type, indicating the algorithm used for authentication), signature_type (digital signature type, indicating the algorithm for digitally signing the digest data of the image (or data unit)), and authentication_flag (indicating whether the video data (or data unit) after the extended data is authenticated) can also be newly added to the CEI extension information of the present application.
[0060] According to the first aspect, or any implementation manner of the above first aspect, the bitstream further includes a first identifier, and the first identifier indicates an authentication mode adopted by a group of data units.
[0061] For example, the first identifier may be authenticate_mode.
[0062] If authenticate_mode is 0, it indicates an authentication method of independently generating digest data for each data unit;
[0063] If authenticate_mode is 1, it indicates a tree - type digest data authentication method.
[0064] According to the first aspect, or any implementation manner of the above first aspect, the bitstream further includes a set of security parameters, and the set of security parameters includes the first identifier.
[0065] Exemplarily, compared with the prior art, the set of security parameters of the present application further adds: authenticate_mode (which can be referred to as the first identifier).
[0066] According to the first aspect, or any implementation manner of the above first aspect, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein, the second identifier indicates a temporal level, and the value of the second identifier is 0.
[0067] Since in the temporal SVC coding scenario of the SVAC standard, the temporal base layer (i.e., the data unit with the second identifier being 0) needs to be parsed, in order to ensure that during the authentication process, whether or not the temporal enhancement layer is parsed, the authentication data can be obtained; the value of the second identifier in the NAL unit of the authentication data can be set to 0.
[0068] In a possible manner, the authentication data in the bitstream is represented in the form of RBSP. Therefore, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier, which can be written as the bitstream further includes an authentication unit of authentication data RBSP, and the NAL unit of authentication data RBSP includes a second identifier.
[0069] Exemplarily, the second identifier may be temporal_id.
[0070] Exemplarily, compared with the prior art, the authentication data adds authentication_id (authentication identifier) and authentication_hash (digest data).
[0071] According to the first aspect, or any implementation of the above first aspect, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a third identifier; wherein, the third identifier indicates the spatial layer or the quality coding layer, and the value of the third identifier is 0.
[0072] Since in the spatial SVC coding or quality SVC coding scenarios of the SVAC standard, the spatial base layer / quality coding base layer (i.e., the data unit with the third identifier being 0) needs to be parsed, therefore, in order to ensure that during the authentication process, whether or not the spatial enhancement layer / quality coding enhancement layer is parsed, the authentication data can be obtained; the value of the third identifier in the NAL unit of the authentication data can be set to 0.
[0073] Exemplarily, the third identifier can be layer_id.
[0074] It should be noted that the authentication data in the first aspect and any implementation of the first aspect may further include the public key corresponding to the private key. Exemplarily, the public key is Public Key, and the public key can be used to verify the signature data. It should be understood that the public key corresponding to the above private key can also be transmitted in other ways, such as being built into the authentication end, or transmitted to the authentication end in the authentication certificate, etc., and this application does not make any restrictions on this.
[0075] It should be noted that the first aspect and any implementation of the first aspect can be executed by the encoder in the signature end, or by the signature module in the signature end, or can also be executed by the cooperation of the encoder and the authentication module in the signature end, and this application does not make any restrictions on this.
[0076] In the second aspect, an embodiment of the present application provides a bitstream, which includes: a set of data units, authentication data, and the authentication identifier of each data unit in the set of data units; wherein, the authentication data includes: signature data, the authentication identifier of each data unit in the set of data units, and the digest data of each data unit in the set of data units, and the signature data is obtained by signing the digest data of each data unit in the set of data units.
[0077] According to the second aspect, the authentication identifier of each data unit in the set of data units is located before the set of data units.
[0078] According to the second aspect, or any implementation of the above second aspect, the bitstream further includes a security parameter set, and the security parameter set includes the authentication identifier of each data unit in the set of data units.
[0079] According to the second aspect, or any implementation of the above second aspect, the bitstream further includes extended information, and the extended information includes the authentication identifier of each data unit in the set of data units.
[0080] According to a second aspect, or any implementation manner of the above second aspect, each data unit in a set of data units includes one or more Network Abstraction Layer (NAL) units.
[0081] According to a second aspect, or any implementation manner of the above second aspect, multiple NAL units in a set of data units are associated with each other according to a specified rule, and the decoding order of multiple NAL units in a set of data units is consecutive. That is to say, one data unit is one access unit.
[0082] According to a second aspect, or any implementation manner of the above second aspect, each data unit in a set of data units includes an encoded image.
[0083] According to a second aspect, or any implementation manner of the above second aspect, each NAL unit includes an authentication identifier of the data unit to which it belongs.
[0084] According to a second aspect, or any implementation manner of the above second aspect, the bitstream further includes a first identifier, and the first identifier indicates an authentication mode adopted by a set of data units.
[0085] According to a second aspect, or any implementation manner of the above second aspect, the bitstream further includes a security parameter set, and the security parameter set includes the first identifier.
[0086] According to a second aspect, or any implementation manner of the above second aspect, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein, the second identifier indicates a temporal level, and the value of the second identifier is 0.
[0087] According to a second aspect, or any implementation manner of the above second aspect, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a third identifier; wherein, the third identifier indicates a spatial level or a quality coding level, and the value of the third identifier is 0.
[0088] According to a second aspect, or any implementation manner of the above second aspect, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data further includes a fourth identifier, and the fourth identifier is used to determine the quantity of digest data included in the authentication data.
[0089] Exemplarily, the fourth identifier may be authentication_hash_number_minus1; it is also a newly added syntax element of the NAL unit of the authentication data in this application.
[0090] The second aspect and any implementation manner of the second aspect respectively correspond to the first aspect and any implementation manner of the first aspect. For the technical effects corresponding to the second aspect and any implementation manner of the second aspect, reference may be made to the technical effects corresponding to the first aspect and any implementation manner of the first aspect above, which will not be elaborated herein.
[0091] In a third aspect, an embodiment of the present application provides a method for authenticating a bitstream. The method includes: First, obtain a first authentication identifier of each data unit in a set of data units from the bitstream; Next, determine first digest data of each data unit in the set of data units; Then, obtain authentication data from the bitstream, where the authentication data includes: signature data, a second authentication identifier of each data unit in the set of data units, and second digest data of each data unit in the set of data units, and the signature data is obtained by signing the second digest data of each data unit in the set of data units; Subsequently, when the signature data is successfully verified, store the authentication data in an authentication data list; Then, from the authentication data list, search for authentication data that matches multiple first authentication identifiers of the set of data units; Wherein, the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of the set of data units; Verify the multiple first digest data in the set of data units according to the multiple second digest data in the matching authentication data.
[0092] It should be noted that the second authentication identifier and the first authentication identifier are used to distinguish the authentication identifier in the authentication data from the authentication identifiers at other positions in the bitstream. The first digest data and the second digest data are used to distinguish the digest data calculated by the authentication end from the digest data in the authentication data.
[0093] According to the third aspect, determining first digest data of each data unit in a set of data units includes: calculating each data unit in the set of data units according to a digest algorithm to obtain first digest data of each data unit in the set of data units.
[0094] In a possible manner, when hash_type is parsed from the security parameter set RBSP of the bitstream, each data unit in the set of data units may be calculated according to the authentication algorithm (i.e., the digest algorithm) indicated by hash_type to obtain first digest data of each data unit in the set of data units.
[0095] For example, each data unit in the set of data units may be hashed according to the digest algorithm indicated by hash_type in the security parameter set RBSP to obtain digest data of each data unit in the set of data units.
[0096] In a possible way, when the hash_type cannot be parsed from the security parameter set RBSP of the bitstream, the digest data of each data unit in a group of data units can be calculated according to a pre-agreed digest algorithm.
[0097] According to the third aspect, or any implementation manner of the above third aspect, the method further includes: obtaining a public key; concatenating the second digest data of each data unit in a group of data units, and determining the digest data of the concatenated second digest data; verifying the signature data according to the public key, the digest data of the concatenated second digest data, and the signature algorithm.
[0098] Exemplarily, when the authentication data generated at the signature end further includes the public key corresponding to the private key used for signature, the public key can also be parsed from the authentication data RBSP.
[0099] In a possible way, when the signature_type is parsed from the bitstream security parameter set RBSP, the signature algorithm can be determined according to the signature algorithm indicated by the signature_type.
[0100] In a possible way, when the camera_idc obtained from the bitstream security parameter set RBSP is available, the signature algorithm can be found from the authentication certificate indicated by the camera_idc.
[0101] In a possible way, the public key can be parsed from the authentication data RBSP of the bitstream.
[0102] In a possible way, the public key pre-built in the authentication end 220 can be obtained.
[0103] In a possible way, the signature algorithm can be determined according to a pre-agreed signature algorithm.
[0104] According to the third aspect, or any implementation manner of the above third aspect, the method further includes: obtaining a first identifier from the bitstream, where the first identifier indicates the authentication mode adopted by a group of data units; when the value of the first identifier is a first preset value, performing the step of determining the first digest data of each data unit in the group of data units.
[0105] According to the third aspect, or any implementation manner of the above third aspect, the method further includes: obtaining a fourth identifier from the bitstream, and determining a value n according to the fourth identifier; where a group of data units includes n data units, and n is a positive integer; obtaining the second digest data of each of the n data units from the bitstream.
[0106] According to a third aspect, or any implementation manner of the above third aspect, each data unit in a group of data units includes one or more Network Abstraction Layer (NAL) units.
[0107] According to a third aspect, or any implementation manner of the above third aspect, multiple NAL units in a group of data units are associated with each other according to a specified rule, and the decoding order of multiple NAL units in a group of data units is consecutive.
[0108] According to a third aspect, or any implementation manner of the above third aspect, each data unit in a group of data units includes an encoded image.
[0109] According to a third aspect, or any implementation manner of the above third aspect, verifying multiple first digest data in a group of data units according to multiple second digest data in the matched authentication data includes: for a first data unit in the group of data units: if a second digest data identical to the first digest data of the first data unit is found in the multiple second digest data in the matched authentication data, it is determined that the authentication of the first data unit is successful; otherwise, it is determined that the authentication of the first data unit fails.
[0110] It should be noted that the third aspect and any implementation manner of the third aspect may be executed by a decoder in the authentication end, or by an authentication module in the authentication end, or by the decoder and the authentication module in the authentication end in cooperation. This application does not limit this.
[0111] The third aspect and any implementation manner of the third aspect respectively correspond to the first aspect and any implementation manner of the first aspect. For the technical effects corresponding to the third aspect and any implementation manner of the third aspect, reference may be made to the technical effects corresponding to the first aspect and any implementation manner of the first aspect above, which will not be elaborated here.
[0112] Fourth aspect, an embodiment of the present application provides a signature device for a bitstream. Among them, the bitstream includes: a group of data units and an authentication identifier for each data unit in the group of data units. The signature device for the bitstream includes:
[0113] A first authentication data acquisition module, configured to acquire authentication data; wherein, the authentication data includes: signature data, an authentication identifier for each data unit in the group of data units, and digest data for each data unit in the group of data units, and the signature data is obtained by signing the digest data for each data unit in the group of data units;
[0114] An addition module, configured to add the authentication data to the bitstream.
[0115] Exemplarily, the above-mentioned signature device for the bitstream can be used to execute the signature method in the first aspect or any possible implementation manner of the first aspect.
[0116] The fourth aspect and any implementation manner of the fourth aspect respectively correspond to the first aspect and any implementation manner of the first aspect. For the technical effects corresponding to the fourth aspect and any implementation manner of the fourth aspect, reference can be made to the technical effects corresponding to the first aspect and any implementation manner of the first aspect above, which will not be elaborated here.
[0117] Fifth aspect, an embodiment of the present application provides an authentication device for a bitstream, and the authentication device for the bitstream includes:
[0118] An authentication identifier acquisition module, configured to acquire a first authentication identifier of each data unit in a group of data units from the bitstream;
[0119] A digest data determination module, configured to determine first digest data of each data unit in a group of data units;
[0120] A second authentication data acquisition module, configured to acquire authentication data from the bitstream, where the authentication data includes: signature data, a second authentication identifier of each data unit in a group of data units, and second digest data of each data unit in a group of data units, and the signature data is obtained by signing the second digest data of each data unit in a group of data units;
[0121] An authentication data storage module, configured to store the authentication data in an authentication data list when the verification of the signature data is successful;
[0122] An authentication data search module, configured to search for authentication data matching multiple first authentication identifiers of a group of data units from the authentication data list; wherein, the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of the group of data units;
[0123] A verification module, configured to verify multiple first digest data in a group of data units according to multiple second digest data in the matching authentication data.
[0124] Exemplarily, the above-mentioned authentication device for the bitstream can be used to execute the authentication method in the third aspect or any possible implementation manner of the third aspect.
[0125] The fifth aspect and any implementation manner of the fifth aspect respectively correspond to the third aspect and any implementation manner of the third aspect. For the technical effects corresponding to the fifth aspect and any implementation manner of the fifth aspect, reference can be made to the technical effects corresponding to the third aspect and any implementation manner of the third aspect above, which will not be elaborated here.
[0126] Sixth aspect, an embodiment of the present application provides an electronic device, including: a memory and a processor, the memory is coupled to the processor; the memory stores program instructions, when the program instructions are executed by the processor, the electronic device is caused to execute the signature method of the bitstream in the first aspect or any possible implementation manner of the first aspect.
[0127] The sixth aspect and any implementation manner of the sixth aspect respectively correspond to the first aspect and any implementation manner of the first aspect. For the technical effects corresponding to the sixth aspect and any implementation manner of the sixth aspect, reference may be made to the technical effects corresponding to the first aspect and any implementation manner of the first aspect above, and details are not described herein again.
[0128] Seventh aspect, an embodiment of the present application provides an electronic device, including: a memory and a processor, the memory is coupled to the processor; the memory stores program instructions, when the program instructions are executed by the processor, the electronic device is caused to execute the authentication method of the bitstream in the third aspect or any possible implementation manner of the third aspect.
[0129] The seventh aspect and any implementation manner of the seventh aspect respectively correspond to the third aspect and any implementation manner of the third aspect. For the technical effects corresponding to the seventh aspect and any implementation manner of the seventh aspect, reference may be made to the technical effects corresponding to the third aspect and any implementation manner of the third aspect above, and details are not described herein again.
[0130] Eighth aspect, an embodiment of the present application provides a chip, including one or more interface circuits and one or more processors; the one or more processors receive or send data through the one or more interface circuits, when the one or more processors execute computer instructions, the steps of the signature method of the bitstream in the first aspect or any possible implementation manner of the first aspect are caused to be executed.
[0131] The eighth aspect and any implementation manner of the eighth aspect respectively correspond to the first aspect and any implementation manner of the first aspect. For the technical effects corresponding to the eighth aspect and any implementation manner of the eighth aspect, reference may be made to the technical effects corresponding to the first aspect and any implementation manner of the first aspect above, and details are not described herein again.
[0132] Ninth aspect, an embodiment of the present application provides a chip, including one or more interface circuits and one or more processors; the one or more processors receive or send data through the one or more interface circuits, when the one or more processors execute computer instructions, the steps of the authentication method of the bitstream in the third aspect or any possible implementation manner of the third aspect are caused to be executed.
[0133] The ninth aspect and any implementation manner of the ninth aspect respectively correspond to the third aspect and any implementation manner of the third aspect. For the technical effects corresponding to the ninth aspect and any implementation manner of the ninth aspect, reference may be made to the technical effects corresponding to the third aspect and any implementation manner of the third aspect above, which will not be elaborated herein.
[0134] In a tenth aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program, which, when running on a computer or a processor, causes the computer or the processor to execute the signature method of the bitstream in the first aspect or any possible implementation manner of the first aspect.
[0135] The tenth aspect and any implementation manner of the tenth aspect respectively correspond to the first aspect and any implementation manner of the first aspect. For the technical effects corresponding to the tenth aspect and any implementation manner of the tenth aspect, reference may be made to the technical effects corresponding to the first aspect and any implementation manner of the first aspect above, which will not be elaborated herein.
[0136] In an eleventh aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program, which, when running on a computer or a processor, causes the computer or the processor to execute the authentication method of the bitstream in the third aspect or any possible implementation manner of the third aspect.
[0137] The eleventh aspect and any implementation manner of the eleventh aspect respectively correspond to the third aspect and any implementation manner of the third aspect. For the technical effects corresponding to the eleventh aspect and any implementation manner of the eleventh aspect, reference may be made to the technical effects corresponding to the third aspect and any implementation manner of the third aspect above, which will not be elaborated herein.
[0138] In a twelfth aspect, an embodiment of the present application provides a computer program product including computer instructions, which, when executed by a computer or a processor, cause the computer or the processor to execute the signature method of the bitstream in the first aspect or any possible implementation manner of the first aspect.
[0139] The twelfth aspect and any implementation manner of the twelfth aspect respectively correspond to the first aspect and any implementation manner of the first aspect. For the technical effects corresponding to the twelfth aspect and any implementation manner of the twelfth aspect, reference may be made to the technical effects corresponding to the first aspect and any implementation manner of the first aspect above, which will not be elaborated herein.
[0140] In a thirteenth aspect, an embodiment of the present application provides a computer program product, where the computer program product includes computer instructions, and when the computer instructions are executed by a computer or a processor, the computer or the processor is caused to execute the authentication method of the bitstream in the third aspect or any possible implementation manner of the third aspect.
[0141] The thirteenth aspect and any implementation manner of the thirteenth aspect respectively correspond to the third aspect and any implementation manner of the third aspect. For the technical effects corresponding to the thirteenth aspect and any implementation manner of the thirteenth aspect, reference may be made to the technical effects corresponding to the third aspect and any implementation manner of the third aspect described above, and details are not described herein again.
[0142] In a fourteenth aspect, an embodiment of the present application provides a computer-readable storage medium, and the computer-readable storage medium stores the bitstream in the second aspect or any possible implementation manner of the second aspect.
[0143] The fourteenth aspect and any implementation manner of the fourteenth aspect respectively correspond to the second aspect and any implementation manner of the second aspect. For the technical effects corresponding to the fourteenth aspect and any implementation manner of the fourteenth aspect, reference may be made to the technical effects corresponding to the second aspect and any implementation manner of the second aspect described above, and details are not described herein again.
[0144] In a fifteenth aspect, an embodiment of the present application provides a device for storing a bitstream, and the device includes: a receiver and at least one storage medium, where the receiver is configured to receive the bitstream in the second aspect or any possible implementation manner of the second aspect; and the at least one storage medium is configured to store the bitstream.
[0145] The fifteenth aspect and any implementation manner of the fifteenth aspect respectively correspond to the second aspect and any implementation manner of the second aspect. For the technical effects corresponding to the fifteenth aspect and any implementation manner of the fifteenth aspect, reference may be made to the technical effects corresponding to the second aspect and any implementation manner of the second aspect described above, and details are not described herein again.
[0146] In a sixteenth aspect, an embodiment of the present application provides a device for transmitting a bitstream, and the device includes: a transmitter and at least one storage medium, where the at least one storage medium is configured to store the bitstream in the second aspect or any possible implementation manner of the second aspect; and the transmitter is configured to obtain the bitstream from the storage medium and send the bitstream to the terminal device through a transmission medium.
[0147] The sixteenth aspect and any implementation of the sixteenth aspect respectively correspond to the second aspect and any implementation of the second aspect. For the technical effects corresponding to the sixteenth aspect and any implementation of the sixteenth aspect, reference can be made to the technical effects corresponding to the second aspect and any implementation of the second aspect above, which will not be elaborated here.
[0148] In a seventeenth aspect, an embodiment of the present application provides a system for distributing a bitstream. The system includes: at least one storage medium for storing the bitstream in at least one of the second aspect or any possible implementation of the second aspect, and a streaming media device for obtaining a target bitstream from at least one storage medium and sending the target bitstream to an end-side device, where the streaming media device includes a content server or a content distribution server.
[0149] The seventeenth aspect and any implementation of the seventeenth aspect respectively correspond to the second aspect and any implementation of the second aspect. For the technical effects corresponding to the seventeenth aspect and any implementation of the seventeenth aspect, reference can be made to the technical effects corresponding to the second aspect and any implementation of the second aspect above, which will not be elaborated here. Description of the Drawings
[0150] Figure 1 Schematic diagram of an exemplary application scenario;
[0151] Figure 2 Schematic diagram of an exemplary authentication and signature system 200;
[0152] Figure 3 Schematic diagram of an exemplary signature process 300;
[0153] Figure 4 Schematic diagram of an exemplary authentication process 400;
[0154] Figure 5A Schematic diagram of an exemplary signature process 500;
[0155] Figure 5B Schematic diagram of an exemplary signature process;
[0156] Figure 6A Schematic diagram of an exemplary authentication process;
[0157] Figure 6B Schematic diagram of an exemplary authentication process 600;
[0158] Figure 7 Schematic diagram of an exemplary signature process 700;
[0159] Figure 8ASchematic diagram of an exemplary authentication process;
[0160] Figure 8B Schematic diagram of an exemplary authentication process 600;
[0161] Figure 9 Schematic diagram of an exemplary signature process 900;
[0162] Figure 10A Schematic diagram of an exemplary authentication process;
[0163] Figure 10B Schematic diagram of an exemplary authentication process 1000;
[0164] Figure 11 Schematic diagram of an exemplary signature device for a bitstream;
[0165] Figure 12 Schematic diagram of an exemplary authentication device for a bitstream;
[0166] Figure 13 Schematic diagram of the structure of an exemplary device. Detailed implementation manners
[0167] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts belong to the scope of protection of the present application.
[0168] The term "and / or" in this article is only used to describe the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. These three situations.
[0169] The terms "first" and "second" in the description and claims of the embodiments of the present application are used to distinguish different objects, rather than to describe the specific order of the objects. For example, the first target object and the second target object are used to distinguish different target objects, rather than to describe the specific order of the target objects.
[0170] In the embodiments of the present application, words such as "exemplarily" or "for example" are used to give examples, illustrations or explanations. Any embodiment or design solution described as "exemplarily" or "for example" in the embodiments of the present application should not be construed as being more preferred or more advantageous than other embodiments or design solutions. Rather, the use of words such as "exemplarily" or "for example" is intended to present relevant concepts in a specific manner.
[0171] In the description of the embodiments of the present application, unless otherwise specified, "a plurality of" means two or more. For example, a plurality of processing units means two or more processing units; a plurality of systems means two or more systems.
[0172] Exemplarily, the signature and authentication method for the bitstream involved in the present application can be applied to sign and authenticate any one of the audio compression bitstream (or referred to as the audio compression bitstream) or the video compression bitstream (or referred to as the video compression bitstream). The present application does not limit this. The present application takes the signature and authentication of the video compression bitstream as an example for illustration.
[0173] bitstream
[0174] The binary data stream formed by encoding image / audio frames.
[0175] Figure 1 It is a schematic diagram of an exemplary application scenario shown. Figure 1 The monitoring scenario, the live broadcast scenario, and the on-demand scenario are shown.
[0176] Refer to Figure 1 , exemplarily, in the monitoring scenario, the camera 11 can sign the monitoring video bitstream to obtain the signed monitoring video bitstream 101. Then, the signed monitoring video bitstream 101 is sent to the laptop 13 through the network 12. After that, the laptop 13 can authenticate the signed monitoring video bitstream 101 to obtain the authentication result 105 and display it, and play the monitoring video 104.
[0177] Refer to Figure 1 , exemplarily, in the live broadcast scenario, the mobile phone 14 can sign the live broadcast video bitstream to obtain the signed live broadcast video bitstream 102. Then, the signed live broadcast video bitstream 102 is sent to the mobile phone 15 through the network 12. After that, the mobile phone 15 can authenticate the signed live broadcast video bitstream 102 to obtain the authentication result 107 and display it, and play the live broadcast video 106.
[0178] Refer to Figure 1 , exemplarily, in the on-demand scenario, the personal computer 16 can sign the on-demand video bitstream to obtain the signed on-demand video bitstream 103. Then, the signed on-demand video bitstream 103 is sent to the mobile phone 17 through the network 12. After that, the mobile phone 17 can authenticate the signed on-demand video bitstream 103 to obtain the authentication result 109 and display it, and play the on-demand video 108.
[0179] It should be understood that the present application can also be used in other scenarios of audio - video encoding and decoding, such as digital content trust scenarios, etc. The present application does not limit this.
[0180] Figure 2 FIG. is a schematic diagram of an exemplary authentication and signature system 200. In Figure 2 the above - mentioned Figure 1 the authentication and signature process is described.
[0181] Referring to Figure 2 , exemplarily, the authentication and signature system 200 may include a signature end 210 and an authentication end 220.
[0182] For example, the signature end 210 may be the camera 11, the mobile phone 14, and the personal computer 16 in the above - mentioned Figure 1 , and the authentication end 220 may be the laptop 13, the mobile phone 15, and the mobile phone 17 in the above - mentioned Figure 1 .
[0183] It should be understood that the same terminal device can serve as both the signature end 210 and the authentication end 220. The present application does not limit this.
[0184] Continuing to refer to Figure 2 , exemplarily, after the signature end 210 obtains the video data 201, it can perform video encoding 21 on the video data 201 to obtain a bitstream 202; and perform video signature 22 on the bitstream 202 to obtain a signed bitstream 203.
[0185] For example, the video data 201 may be the surveillance video collected by the camera 11, the live video recorded by the mobile phone 14, or the on - demand video produced by the personal computer 16 in the above - mentioned Figure 1 .
[0186] For example, the signed bitstream 203 may be the signed surveillance video bitstream 101, the signed live video bitstream 102, or the signed on - demand video bitstream 103 in the above - mentioned Figure 1 .
[0187] It should be noted that the two operations of video encoding 21 and video signature 22 can be executed in parallel.
[0188] It should be noted that in one possible way, the signature end 210 may include an encoder, and the encoder performs video encoding 21 and video signature 22. In one possible way, the signature end 210 may include an encoder and a signature module, where the encoder performs video encoding 21 and the signature module performs video signature 22. In one possible way, the signature end 210 may include a signature module, and the signature module performs video encoding 21 and video signature 22.
[0189] After that, the signing end 210 can send the signed bitstream 203 to the authentication end 220.
[0190] Continuing to refer to Figure 2 , exemplarily, after the authentication end 220 receives the signed bitstream 203, it can perform video authentication 23 on the signed bitstream 203 to obtain an authentication result 205; and it can perform video decoding 24 on the bitstream 202 in the signed bitstream 203 to obtain decoded video data 204.
[0191] For example, the decoded video data 204 can be the surveillance video 104, the live video 106, or the on-demand video 108 in the above Figure 1 .
[0192] For example, the authentication result 205 can be the authentication result 105, the authentication result 107, or the authentication result 109 in the above Figure 1 .
[0193] It should be noted that the video authentication 23 and the video decoding 24 can be executed in parallel.
[0194] It should be noted that in one possible way, the authentication end 220 can include a decoder, and the decoder executes the video decoding 24 and the video authentication 23. In one possible way, the authentication end 220 can include a decoder and an authentication module, the decoder executes the video decoding 24 and the authentication module executes the video authentication 23. In one possible way, the authentication end 220 can include an authentication module, and the authentication module executes the video decoding 24 and the video authentication 23.
[0195] It should be noted that when the signing end 210 performs lossless encoding, the video data is the same as the decoded video data; when the signing end 210 performs lossy encoding, there are differences between the video data and the decoded video data.
[0196] It should be noted that the encoder, the decoder, and the authentication module can be implemented by software or by hardware, and this application does not make any restrictions on this.
[0197] Figure 3 It is a schematic diagram of the exemplary signing process 300. Among them, the process 300 can be implemented by the signing end 210.
[0198] S301, obtain authentication data; where the authentication data includes: signature data, the authentication identifier of each data unit in a group of data units, and the digest data of each data unit in a group of data units, and the signature data is obtained by signing the digest data of each data unit in a group of data units.
[0199] Exemplarily, when authentication support is required, the number n of data units that need to be authenticated can be determined, and an authentication identifier for each of the n data units can be generated; then, the authentication identifiers of each data unit in a group of data units are added to the bitstream. Here, n is a positive integer.
[0200] data unit
[0201] The basic syntax structure of the coded bitstream can be a NAL unit or an access unit.
[0202] NAL unit
[0203] A syntax structure that contains a type indication of the subsequent data and the number of bytes included (located in the NAL header), and the data appears in the form of a Raw Byte Sequence Payload (RBSP), which may also include scattered anti-counterfeiting bytes when necessary.
[0204] access unit
[0205] A group of NAL units that are associated with each other according to specified rules and are consecutive in the decoding order.
[0206] It should be noted that, from another dimension, the data unit can also include a coded picture.
[0207] coded picture
[0208] The coded representation of a frame of image.
[0209] Refer to Figure 3 , exemplarily, the n data units that need to be authenticated in the bitstream are respectively: data unit 1, data unit 2,..., data unit n. These n data units that need to be authenticated can be referred to as a group of data units. A group of data units involved subsequently all refer to the data units that need to be authenticated.
[0210] It should be noted that the present application does not group the data units, but for the convenience of description, the term "a group of data units" is used.
[0211] Refer to Figure 3 , exemplarily, the authentication identifiers in the bitstream are respectively: authentication identifier 1, authentication identifier 2,..., authentication identifier n.
[0212] It should be noted that the n authentication identifiers correspond one-to-one with the n data units. For example, authentication identifier 1 corresponds to data unit 1, authentication identifier 2 corresponds to data unit 2, ..., authentication identifier n corresponds to data unit n. One authentication identifier can be used to identify one data unit, and the n authentication identifiers can indicate the authentication data used by this group of data units.
[0213] Referring to Figure 3 , exemplarily, a digest data can be independently calculated for each data unit in a group of data units, and the digest data (which can also be called authentication digest data) of each data unit in this group of data units can be obtained. The n digest data can include: digest data 1, digest data 2, ..., digest data n; among them, the n digest data correspond one-to-one with the n data units; for example, digest data 1 corresponds to data unit 1, digest data 2 corresponds to data unit 2, ..., digest data n corresponds to data unit n.
[0214] Exemplarily, a signature data (signature) can be obtained by signing according to the digest data of each data unit in a group of data units.
[0215] Exemplarily, authentication data (Auth) can be generated according to the signature data, the authentication identifier of each data unit in a group of data units, and the digest data of each data unit in a group of data units. In this way, the authentication data can be {authentication serial number 1, authentication serial number 2, ..., authentication serial number n, digest data 1, digest data 2, ..., digest data n, signature}.
[0216] Optionally, the digest data of each data unit in a group of data units in the authentication data can form a digest data list {digest data 1, digest data 2, ..., digest data n}.
[0217] S302, Add the authentication data to the bitstream.
[0218] Exemplarily, after the authentication data is obtained, the authentication data can be added to the bitstream to obtain the signed bitstream, that is, the signed bitstream 203 in the above Figure 2 .
[0219] It should be noted that S301~S302 can be executed by the encoder in the signature end 210, or can be executed by the signature module in the signature end 210, or can also be executed jointly by the encoder and the authentication module in the signature end 210 (the encoder executes S302, and the authentication module executes S301), and this application does not make any restrictions on this.
[0220] Figure 4Schematic diagram of the exemplary authentication process 400. Among them, the process 400 can be implemented by the authentication end 220, and the process 400 corresponds to the process 300.
[0221] S401, obtain the first authentication identifier of each data unit in a group of data units from the bitstream.
[0222] Refer to Figure 4 , exemplarily, the bitstream may include data units, authentication identifiers, and authentication data. Among them, in order to distinguish the authentication identifier located in the authentication data and the authentication identifier located at other positions in the bitstream, the authentication identifier located at other positions in the bitstream may be referred to as the first authentication identifier, and the authentication identifier located in the authentication data may be referred to as the second authentication identifier.
[0223] Exemplarily, the bitstream can be parsed to read the first authentication identifier of the data unit to be authenticated from the bitstream. Among them, the first authentication identifier may include: authentication identifier 11, authentication identifier 12,..., authentication identifier 1n. In this way, n data units can be determined as the data units to be authenticated, and these n data units are respectively: data unit 1, data unit 2,..., data unit n.
[0224] Exemplarily, the n first authentication identifiers correspond one-to-one with the n data units, that is: data unit 1 corresponds to authentication identifier 11, data unit 2 corresponds to authentication identifier 12,..., data unit n corresponds to authentication identifier 1n.
[0225] S402, determine the first digest data of each data unit in a group of data units.
[0226] Exemplarily, n data units to be authenticated (that is, a group of data units to be authenticated) can be read from the bitstream. Then, a digest data is independently calculated for each data unit in this group of data units, and the digest data of each data unit in this group of data units can be obtained. In order to distinguish the digest data calculated in S402 and the digest data included in the authentication data, the digest data calculated in S402 can be referred to as the first digest data, and the digest data included in the authentication data can be referred to as the second digest data.
[0227] Refer to Figure 4 , exemplarily, the n first digest data are respectively: digest data 11, digest data 12,..., digest data 1n.
[0228] Exemplarily, the n first digest data correspond one-to-one with the n data units. For example, digest data 11 corresponds to data unit 1, digest data 12 corresponds to data unit 2,..., digest data 1n corresponds to data unit n.
[0229] S403. Obtain authentication data from the bitstream. The authentication data includes: signature data, the second authentication identifier of each data unit in a set of data units, and the second digest data of each data unit in a set of data units. The signature data is obtained by signing the second digest data of each data unit in a set of data units.
[0230] Exemplarily, the bitstream can be parsed to read the authentication data from the bitstream. Among them, the authentication data includes: signature data, n second digest data (including digest data 21, digest data 22,..., digest data 2n) and n second authentication identifiers (including authentication identifier 21, authentication identifier 22,..., authentication identifier 2n).
[0231] Exemplarily, the n second digest data can form a digest data list {digest data 21, digest data 22,..., digest data 2n}.
[0232] Exemplarily, the n second digest data and the n data units correspond one by one. For example, digest data 21 corresponds to data unit 1, digest data 22 corresponds to data unit 2,..., and digest data 2n corresponds to data unit n.
[0233] Exemplarily, the n second authentication identifiers and the n data units correspond one by one. For example, authentication identifier 21 corresponds to data unit 1, authentication identifier 22 corresponds to data unit 2,..., and authentication identifier 2n corresponds to data unit n.
[0234] S404. When the signature data is successfully verified, store the authentication data in the authentication data list.
[0235] Exemplarily, the signature data can be verified. When the signature data is successfully verified, store the authentication data in the authentication data list.
[0236] Among them, the authentication data list can include multiple authentication data (including one or more previously obtained authentication data and the currently obtained authentication data). Each authentication data can include: signature data, the second authentication identifier of each data unit in a set of data units, and the second digest data of each data unit in a set of data units. The signature data is obtained by signing the second digest data of each data unit in a set of data units.
[0237] S405. From the authentication data list, find the authentication data that matches the multiple first authentication identifiers of a set of data units; among them, the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of a set of data units.
[0238] Next, multiple first authentication identifiers obtained from the bitstream can be compared with multiple second authentication identifiers included in each authentication data in the authentication data list; when authentication data containing multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers obtained from the bitstream is found, the authentication data containing these multiple second authentication identifiers can be determined as the authentication data that matches the multiple first authentication identifiers of a set of data units obtained from the bitstream.
[0239] S406. Verify multiple first digest data of a set of data units according to multiple second digest data in the matched authentication data.
[0240] Exemplarily, after the matched authentication data is found from the authentication data list, multiple second digest data (or a digest data list) can be read from the matched authentication data; then, multiple first digest data of a set of data units can be verified according to the multiple second digest data in the matched authentication data.
[0241] Specifically, for the first data unit in a set of data units obtained from the bitstream (the first data unit can be any data unit in the set of data units obtained from the bitstream), it can be checked whether there is second digest data in the multiple second digest data of the matched authentication data that is the same as the first digest data of the first data unit; when second digest data that is the same as the first digest data of the first data unit is found in the multiple second digest data of the matched authentication data, it is determined that the authentication of the first data unit is successful, that is, the authentication result can be authentication successful. Otherwise, it is determined that the authentication of the first data unit fails, that is, the authentication result can be authentication failure.
[0242] For example, in the implementation process, a digest data list {digest data 21, digest data 22,..., digest data 2n} can be made into a Map data structure, such as Map[digest data 21]=1, Map[digest data 22]=1,..., Map[digest data 2n]=1, to achieve fast search.
[0243] It should be noted that S401 to S406 can be executed by the decoder in the authentication end 220, or by the authentication module in the authentication end 220, or by the decoder and the authentication module in the authentication end 220 in cooperation (the decoder executes S401 and S403, and the authentication module executes S402, S404 to S406), and this application does not limit this.
[0244] For the temporal SVC coding of the Surveillance Video and Audio Coding (SVAC) standard, each data unit uses a temporal_id to identify its temporal level. During decoding, some temporal levels or data units may not participate in decoding; in this application, since each data unit independently generates digest data, during authentication, for the data units participating in authentication, the corresponding digest data can be found in the authentication data, and the data units not participating in authentication do not affect the authentication of other data units.
[0245] For the spatial SVC coding of the SVAC standard, each data unit uses a layer_id to identify its spatial level. During decoding, some spatial levels or data units may not participate in decoding; in this application, since each data unit independently generates digest data, during authentication, for the data units participating in authentication, the corresponding digest data can be found in the authentication data, and the data units not participating in authentication do not affect the authentication of other data units.
[0246] For the video quality SVC coding of the SVAC standard, during decoding, some quality levels or data units may not participate in decoding. In this application, since each data unit independently generates digest data, during authentication, for the data units participating in authentication, the corresponding digest data can be found in the authentication data, and the data units not participating in authentication do not affect the authentication of other data units.
[0247] In addition, for SVC coding, only a set of authentication data for data units needs to be transmitted to support the authentication of sub-bitstreams extracted from the bitstream.
[0248] In summary, this application can effectively solve the problem that the current temporal SVC coding, spatial SVC coding, and video quality SVC coding of SVAC coding require independent authentication.
[0249] Secondly, since each data unit is independently authenticated, even in the case of loss (dropped frames) of some data units, other data units can still be authenticated. In addition, by using an authentication identifier to identify data units, the one-to-one correspondence between data units and authentication data is ensured, avoiding the problem of mismatch between data units and authentication data caused by a long signature time.
[0250] Exemplarily, the authentication identifier of each data unit in a set of data units in the bitstream may be located before the set of data units. In this way, the authentication end 220 can receive the authentication identifier of each data unit in a set of data units before receiving the set of data units, so as to ensure that the authentication end 220 marks each data unit in the received set of data units according to the authentication identifier of each data unit in the set of data units, determines the authentication identifier of each data unit, and ensures the correspondence between the data unit and the authentication data.
[0251] Figure 5A It is a schematic diagram of the exemplary signature process 500 shown. Among them, the process 500 can be implemented by the signature end 210. The process 500 is a process in which the SVAC signature end realizes the signature of data units by carrying the authentication identifier through the security parameter set RBSP.
[0252] S501, generate the security parameter set RBSP.
[0253] Exemplarily, when video image authentication needs to be supported, the security parameter set RBSP (such as Figure 5A the SEC_RBSP in) can be generated. Among them, the definition of the security parameter set RBSP in the NAL unit of the security parameter set can be as shown in Table 1:
[0254] Table 1 Definition of the security parameter set RBSP
[0255]
[0256] Authentication mode authentication_mode
[0257] A 2-bit unsigned integer. It indicates the authentication mode adopted for authentication, and can be as shown in Table 2:
[0258] Table 2 Description of the authentication mode
[0259] Value of authentication_mode Description 0 Each data unit independently performs digest data authentication 1 Tree-shaped digest data authentication 2~3 Reserved
[0260] If the authenticate_mode is 0, first concatenate the digest data of the image data (which can also be a data unit), perform digest data on the concatenated digest data, and then perform a digital signature on the digest data.
[0261] Authentication serial number authentication_id
[0262] A binary variable. The authentication serial number is used to identify the authentication data set it uses. The new authentication_id indicates the start of a new authentication sequence (i.e., a new set of data units).
[0263] Hash type hash_type
[0264] A 2-bit unsigned integer. It indicates the algorithm used for authentication (i.e., the algorithm for determining the digest data of the data unit), and the specific correspondence is shown in Table 3 as follows:
[0265] Table 3 Correspondence between Hash Types and Specific Algorithms
[0266] Value of hash_type Authentication algorithm Digest data length (bytes) 0 SM3 32 1~3 Reserved Reserved
[0267] Digital signature type signature_type
[0268] A 2-bit unsigned integer. It indicates the algorithm for digitally signing the digest data of the data unit, as shown in Table 4 below:
[0269] Table 4 Correspondence between Digital Signature Types and Specific Encryption Algorithms
[0270] Value of signature_type Signature algorithm 0 SM2 1~3 Reserved
[0271] Authentication enable flag authentication_flag
[0272] A 1-bit unsigned integer. It indicates whether a set of data units supports authentication, as shown in Table 5:
[0273] Table 5 Explanation of Authentication Enable Flag
[0274] Value of authentication_flag Description 0 Authentication not supported 1 Authentication supported
[0275] camera_idc is a 19-byte string, which is used to represent the certificate identifier of the camera from which the video stream's corresponding image is sourced.
[0276] It should be noted that compared with the prior art, the security parameter set of this application newly adds: authenticate_mode (which can be called the first identifier) and authentication_id (which can also be called the authentication identifier).
[0277] Refer to Figure 5A , for example, SEC_RBSP may include n authentication identifiers: P1, P2, P3, P4,..., Pn. Among them, P1 is the authentication identifier of data unit 1, P2 is the authentication identifier of data unit 2, P3 is the authentication identifier of data unit 3, P4 is the authentication identifier of data unit 4,..., Pn is the authentication identifier of data unit n.
[0278] Exemplarily, when authenticate_mode is 0, it can be determined that the signature method of the bitstream involved in the present application is used for signature, and reference can be made to S502 - S504 below; when authenticate_mode is 1, it can be determined that the signature method in the prior art is used for signature, that is, calculating the tree - type digest data and signing the top - tree digest data. Furthermore, when using the signature method of the present application, during the process of generating the safety parameter set RBSP, the authenticate_mode in the safety parameter set RBSP can be set to 0.
[0279] Exemplarily, during the process of generating the safety parameter set RBSP, the authentication_flag in the safety parameter set RBSP can be set to 1, so that it can indicate that a group of data units located after the safety parameter set RBSP support authentication.
[0280] Exemplarily, when the data unit is a NAL unit, a group of data units can include multiple NAL units, and the authentication identifiers of each NAL unit are different. When the data unit is multiple NAL units, a group of data units includes multiple access units, the authentication identifiers of each access unit are different, and the authentication identifiers of multiple NAL units included in each access unit are the same.
[0281] It should be noted that hash_type, signature_type, and camera_idc in the safety parameter set RBSP are optional.
[0282] S502, calculate each data unit in a group of data units according to the digest algorithm to obtain the digest data of each data unit in the group of data units.
[0283] Exemplarily, the number of data units to be authenticated can be determined according to the number of authentication_id in the safety parameter set RBSP; that is, the number of data units included in a group of data units.
[0284] In a possible way, when the safety parameter set RBSP includes hash_type, the digest algorithm can be the authentication algorithm indicated by hash_type in the safety parameter set RBSP. In this case, each data unit in a group of data units can be calculated according to the authentication algorithm indicated by hash_type in the safety parameter set RBSP to obtain the digest data of each data unit in the group of data units. For example, each data unit in a group of data units can be hashed according to the digest algorithm indicated by hash_type in the safety parameter set RBSP to obtain the digest data of each data unit in the group of data units.
[0285] In one possible way, the signature end 210 and the authentication end 220 can pre-agree on a digest algorithm; in this way, each data unit in a set of data units can be calculated according to the pre-agreed digest algorithm to obtain the digest data of each data unit in the set of data units. In this case, the security parameter set RBSP may not include hash_type.
[0286] It should be understood that the present application does not limit the way for the signature end 210 and the authentication end 220 to synchronize the digest algorithm.
[0287] Referring again to Figure 5A , by way of example, perform a hash calculation on data unit 1 to obtain digest data H1; perform a hash calculation on data unit 2 to obtain digest data H2; perform a hash calculation on data unit 3 to obtain digest data H3; perform a hash calculation on data unit 4 to obtain digest data H4;...; perform a hash calculation on data unit n to obtain digest data Hn.
[0288] S503, concatenate the digest data of each data unit in a set of data units, and determine the digest data of the concatenated digest data of each data unit in the set of data units.
[0289] By way of example, the digest data of each data unit in a set of data units can be spliced to obtain the concatenated digest data as H1 + H2 + H3 + H4 + H5 +... + Hn.
[0290] Then, the concatenated digest data can be calculated to obtain the digest data of the concatenated digest data. For example, perform a hash calculation on H1 + H2 + H3 + H4 + H5 +... + Hn to obtain the digest data Hg of the concatenated digest data (as Figure 5A shown).
[0291] S504, sign the digest data of the concatenated digest data with a private key to obtain signature data.
[0292] In one possible way, when the security parameter set RBSP includes signature_type, the digest data of the concatenated digest data can be signed according to the signature algorithm and private key indicated by signature_type in the security parameter set RBSP to obtain signature data.
[0293] In one possible way, the signature end 210 and the authentication end 220 can pre-agree on a signature algorithm; in this way, the digest data of the concatenated digest data can be signed according to the pre-agreed signature algorithm and private key to obtain signature data. In this case, the security parameter set RBSP may not include signature_type.
[0294] It should be understood that the present application does not limit the manner in which the signature side 210 and the authentication side 220 synchronize the signature algorithm.
[0295] It should be understood that tree top digest data can also be generated, and the private key is used to sign the tree top digest data to obtain signature data. The present application does not limit the manner of signing according to the digest data of the data unit.
[0296] Exemplarily, authentication data is generated according to the digest data of each data unit in a set of data units, the authentication identifier of each data unit in the set of data units, and the signature data.
[0297] For example, the authentication data may include {P1, P2, P3, P4, P5,..., Pn, H1, H2, H3, H4, H5,..., Hn, signature}.
[0298] S505, encode the authentication data and add the encoded authentication data to the bitstream.
[0299] Exemplarily, the authentication data can be encoded using Base64; then, the encoded authentication data is packed into the NAL unit of the authentication data. Among them, the definition of the authentication data RBSP in the NAL unit of the authentication data can be as shown in Table 6 below:
[0300] Table 6 Definition of authentication data RBSP
[0301]
[0302]
[0303] Authentication sequence number authentication_id
[0304] Binary variable. The authentication sequence number of the authentication data set.
[0305] Number of authentication digest data authentication_hash_number_minus1
[0306] 8-bit unsigned integer. Adding 1 represents the length of the signature data in bytes, and the value should be 0 to 255.
[0307] Authentication digest data authentication_hash
[0308] Binary data, the length of which is the length of the digest data corresponding to the hash type in the correspondence table between the hash type and the specific algorithm in the security parameter set, in bytes.
[0309] Length of signature data authentication_data_length_minus1
[0310] 8-bit unsigned integer. Plus 1 represents the length of the signature data in bytes, and the value should be in the range of 0 to 255.
[0311] Bytes of signature data authentication_data[i]
[0312] 8-bit unsigned integer. The i-th byte of a signature data, and the signature data should be Base64 encoded. See rfc3548 for the Base64 encoding method.
[0313] Exemplarily, the authentication identifier included in the authentication data, that is, authentication_id (authentication serial number) in Table 6.
[0314] Exemplarily, the digest data included in the authentication data, that is, authentication_hash (authentication digest data) in Table 6.
[0315] Exemplarily, authentication_hash_number_minus1 in the authentication data RBSP can be referred to as the fourth identifier.
[0316] It should be noted that, compared with the authentication data RBSP in the prior art, the NAL unit of the authentication data in this application includes authentication_id, authentication_hash, and authentication_hash_number_minus1.
[0317] In addition, in the scenario of temporal SVC coding of the SVAC standard, each data unit includes a second identifier (temporal_id) for identifying the temporal level where the data unit is located; correspondingly, the authentication data RBSP can also include the second identifier (temporal_id). Since in the scenario of temporal SVC coding of the SVAC standard, the temporal base layer (i.e., the data unit with the second identifier being 0) needs to be parsed, in order to ensure that during the authentication process, the authentication data can be obtained regardless of whether the temporal enhancement layer is parsed or not; the value of the second identifier in the NAL unit of the authentication data can be set to 0.
[0318] In the scenario of spatial SVC coding or quality SVC coding according to the SVAC standard, each data unit includes a third identifier (layer_id) for identifying the spatial layer or quality coding layer to which the data unit belongs; correspondingly, the authentication data RBSP may also include the third identifier (layer_id). Since in the scenario of spatial SVC coding or quality SVC coding according to the SVAC standard, the spatial base layer / quality coding base layer (i.e., the data unit with the third identifier being 0) needs to be parsed, in order to ensure that during the authentication process, whether or not the spatial enhancement layer / quality coding enhancement layer is parsed, the authentication data can be obtained; the value of the third identifier in the NAL unit of the authentication data can be set to 0.
[0319] Figure 5B Schematic diagram of the signature process shown for illustration. Figure 5B Two sets of data units in the bitstream and the authentication data corresponding to the two sets of data units are shown.
[0320] Refer to Figure 5B , for example, Sec represents the NAL unit of the security parameter set RESP, P1 to Pn respectively correspond to a data unit, and Auth represents the authentication data. Private Key is the private key, sign is the signature, and Public Key is the public key.
[0321] Refer to Figure 5B , in one possible way, the public key can be added to the authentication data.
[0322] It should be understood that the public key corresponding to the above private key can also be transmitted in other ways, such as being built into the authentication end, being transmitted to the authentication end in the authentication certificate, etc., and the present application does not limit this.
[0323] It should be noted that the authentication data corresponding to the current set of data units may be connected after the current set of data units, as shown in the first set of data units and the authentication data of the first set of data units in Figure 5B . The authentication data corresponding to the current set of data units is not necessarily connected after the current set of data units, and may also be connected after the first few data units in the next set of data units (as shown in the second set of data units and the authentication data of the second set of data units in Figure 5B ), which is caused by the difference between the rate of the encoded data units and the rate of generating the authentication data. However, since the present application uses the authentication identifier to identify the data units, the one-to-one correspondence between the data units and the authentication data is ensured, and thus the problem of mismatch between the data units and the authentication data caused by a long signature time can be avoided.
[0324] Figure 6A Schematic diagram of the authentication process shown for illustration.
[0325] Figure 6B Schematic diagram of the exemplary authentication process 600. The process 600 is a process for the SVAC authentication end to implement data unit authentication when the authentication identifier is carried in the security parameter set RBSP. The process 600 corresponds to the process 500.
[0326] S601, Obtain the first authentication identifier of each data unit in a group of data units from the security parameter set RBSP of the bitstream.
[0327] Exemplarily, after the authentication end 220 receives the security parameter set RBSP of the bitstream, when it parses the authentication_flag as 1 from the security parameter set RBSP of the bitstream, it determines that the subsequent group of data units supports authentication. At this time, the syntax elements in the security parameter set RBSP can be continuously parsed in the order of each syntax element in Table 1.
[0328] Exemplarily, parse the hash_mode in the security parameter set RBSP; when the parsed hash_mode is 0, S602 can be executed.
[0329] Exemplarily, parse the authentication_id in the security parameter set RBSP, and the first authentication identifier of each data unit in a group of data units can be obtained.
[0330] Exemplarily, parse the hash_type in the security parameter set RBSP; according to the value of the parsed hash_type, determine the digest algorithm.
[0331] Exemplarily, parse the signature_type in the security parameter set RBSP; according to the value of the parsed signature_type, determine the signature algorithm.
[0332] Exemplarily, parse the camera_idc in the security parameter set RBSP; according to the value of the parsed camera_idc, determine the certificate identifier of the camera from which the bitstream corresponding image is sourced.
[0333] Refer to Figure 6A , Exemplarily, the n first authentication identifiers are respectively: P1, P2, P3, P4,..., Pn.
[0334] S602, Calculate each data unit in a group of data units according to the digest algorithm to obtain the first digest data of each data unit in a group of data units.
[0335] Exemplarily, when the authentication end 220 receives each data unit of a subsequent set of data units, for each NAL unit of each data unit, it may record the corresponding authentication identifier; and calculate for each data unit in the set of data units to obtain the first digest data of each data unit in the set of data units.
[0336] In a possible way, when hash_type is parsed from the security parameter set RBSP of the bitstream, according to the authentication algorithm (i.e., the digest algorithm) indicated by hash_type, calculate for each data unit in the set of data units to obtain the first digest data of each data unit in the set of data units.
[0337] For example, according to the digest algorithm indicated by hash_type in the security parameter set RBSP, perform a hash calculation on each data unit in the set of data units to obtain the digest data of each data unit in the set of data units.
[0338] In a possible way, when hash_type is not parsed from the security parameter set RBSP of the bitstream, calculate for each data unit in the set of data units according to a pre-agreed digest algorithm to obtain the digest data of each data unit in the set of data units.
[0339] Refer to Figure 6A , exemplarily, the n first digest data are respectively: H1’, H2’, H3’, H4’, H5’,..., Hn’.
[0340] S603, obtain authentication data from the bitstream, where the authentication data includes: signature data, the second authentication identifier of each data unit in the set of data units, and the second digest data of each data unit in the set of data units, and the signature data is obtained by signing according to the second digest data of each data unit in the set of data units.
[0341] Exemplarily, the authentication data RBSP in the bitstream can be parsed to obtain the authentication data.
[0342] Exemplarily, parse the authentication_id in the authentication data RBSP to obtain the second authentication identifier of each data unit in the set of data units.
[0343] Exemplarily, parse the authentication_hash_number_minus1 (which can also be called the fourth identifier) in the authentication data RBSP to obtain the number of the second digest data included in the authentication data.
[0344] Exemplarily, the authentication_hash in the authentication data RBSP is parsed according to authentication_hash_number_minus1 to obtain the second digest data of each data unit in a set of data units; wherein, the number of the second digest data is the same as the value calculated according to authentication_hash_number_minus1.
[0345] Exemplarily, when the authentication data generated in the signature end 210 further includes the public key corresponding to the private key for signature, the public key can also be parsed from the authentication data RBSP.
[0346] Exemplarily, the authentication data may include {P1, P2, P3, P4, P5,..., Pn, H1, H2, H3, H4, H5,..., Hn, signature}
[0347] S604, verify the signature data according to the public key, the first digest data of each data unit in a set of data units, and the signature algorithm.
[0348] Exemplarily, the first digest data of each data unit in a set of data units can be concatenated; then, the digest data Hg' of the concatenated first digest data is determined. After that, the verification result of the signature data can be obtained by processing the public key, Hg', and the signature data using the signature verification algorithm corresponding to the signature algorithm.
[0349] In a possible way, when signature_type is parsed from the code stream security parameter set RBSP, the signature algorithm can be determined according to the signature algorithm indicated by signature_type.
[0350] In a possible way, the signature algorithm can be determined according to a pre-agreed signature algorithm.
[0351] In a possible way, when camera_idc is obtained from the security parameter set RBSP of the code stream, the public key can be found from the authentication certificate indicated by camera_idc.
[0352] In a possible way, the public key can be parsed from the authentication data RBSP of the code stream.
[0353] In a possible way, the public key pre-built in the authentication end 220 can be obtained.
[0354] S605, when the verification of the signature data is successful, store the authentication data in the authentication data list.
[0355] S606. Search for authentication data in the authentication data list that matches multiple first authentication identifiers of a set of data units. Among them, the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of the set of data units.
[0356] S607. Verify multiple first digest data of a set of data units based on multiple second digest data in the matching authentication data.
[0357] Exemplarily, S605 - S607 can refer to the descriptions of S404 - S406 above and will not be elaborated here.
[0358] Exemplarily, in S607, multiple second digest data in the matching authentication data can be {H1, H2, H3, H4, H5,..., Hn}, and multiple first digest data of a set of data units can be {H1', H2', H3', H4', H5',..., Hn'}. Search for each first digest data in {H1', H2', H3', H4', H5',..., Hn'} from {H1, H2, H3, H4, H5,..., Hn}. For example, when a second digest data equal to H1' is found from {H1, H2, H3, H4, H5,..., Hn}, it can be determined that the authentication of data unit 1 is successful; when a second digest data equal to H2' is found from {H1, H2, H3, H4, H5,..., Hn}, it can be determined that the authentication of data unit 2 is successful, and so on, which will not be elaborated here. If a second digest data equal to H1' is not found from {H1, H2, H3, H4, H5,..., Hn}, it can be determined that the authentication of data unit 1 fails; if a second digest data equal to H2' is not found from {H1, H2, H3, H4, H5,..., Hn}, it can be determined that the authentication of data unit 2 fails; and so on.
[0359] Figure 7 It is a schematic diagram of the exemplary signature process 700. Among them, process 700 can be implemented by the signature end 210. Process 700 is a process in which the signature end realizes the signature of data units by carrying authentication identifiers through extended information.
[0360] Exemplarily, in H264 video coding, CEI extended information is included in the SEI information with NAL unit type 6, in H265 video coding, CEI extended information is included in the SEI information with NAL unit type 39, and the CEI data of the AVS series standards is carried in the extension_data after the sequence_header. This application extends the CEI syntax to support the authentication of NAL units. Among them, when the new CEI syntax that supports authentication appears, it indicates the start of a new authentication.
[0361] S701, generate extended information.
[0362] Exemplarily, when video image authentication is required, CEI extended information (or CEI data) can be generated, as shown in Table 7:
[0363] Table 7 CEI Data Syntax Format
[0364]
[0365]
[0366] authentication_flag: indicates whether the video data (or data unit) after this extended data is authenticated;
[0367] authentication_id: authentication serial number, used to identify the authentication data set it uses. A new authentication_id indicates the start of a new authentication sequence.
[0368] hash_type: hash type, indicating the algorithm used for authentication. The specific correspondence is shown in Table 8 below:
[0369] Table 8 Correspondence between Hash Types and Specific Algorithms
[0370] Value of hash_type Authentication algorithm Digest data length (bytes) 0 SM3 32 1~3 Reserved Reserved
[0371] signature_type: digital signature type, indicating the algorithm for digitally signing the digest data of the image (or data unit), as shown in Table 9 below:
[0372] Table 9 Correspondence between Digital Signature Types and Specific Encryption Algorithms
[0373] Value of signature_type Signature algorithm 0 SM2 1~3 Reserved
[0374] It should be noted that compared with the prior art, the CEI extended information of this application newly adds: authentication_id (which can also be called authentication identifier), hash_type, signature_type, and authentication_flag.
[0375] Exemplarily, during the process of generating CEI diffusion information, the authentication_flag in the CEI extended information can be set to 1, so that it can indicate that a group of data units located after the CEI extended information support authentication.
[0376] Exemplarily, when the data unit is a single NAL unit, a set of data units may include multiple NAL units, and each NAL unit has a different authentication identifier. When the data unit is multiple NAL units, a set of data units includes multiple access units, and each access unit has a different authentication identifier, while the multiple NAL units included in each access unit have the same authentication identifier.
[0377] It should be noted that hash_type and signature_type in the extended information are optional.
[0378] S702. Calculate each data unit in a set of data units according to the digest algorithm to obtain the digest data of each data unit in the set of data units.
[0379] Exemplarily, the number of data units to be authenticated can be determined according to the number of authentication_id in the CEI extended information; that is, the number of data units included in a set of data units.
[0380] Exemplarily, S702 can refer to the description of S502 above and will not be elaborated here.
[0381] Among them, the difference between S702 and S502 is that in one possible way of S702, the digest algorithm can be the authentication algorithm indicated by hash_type in the CEI extended information.
[0382] S703. Concatenate the digest data of each data unit in a set of data units to determine the digest data of the concatenated digest data of each data unit in the set of data units.
[0383] S704. Sign the digest data of the concatenated digest data of each data unit in a set of data units with a private key to obtain signature data.
[0384] Exemplarily, S703 - S704 can refer to the description of S503 - S504 above and will not be elaborated here.
[0385] Among them, the difference between S704 and S504 is that in one possible way of S704, the signature algorithm can be the signature algorithm indicated by signature_type in the CEI extended information.
[0386] S705. Encode the authentication data and add the encoded authentication data to the bitstream.
[0387] Exemplarily, S702 - S705 can refer to the description of S502 - S505 above and will not be elaborated here.
[0388] Exemplarily, the definition of the authentication data RBSP in process 700 can be shown in Table 10 below:
[0389] Table 10 Definition of Authentication Data RBSP
[0390]
[0391] Authentication serial number authentication_id
[0392] Binary variable. The authentication serial number of the authentication data set.
[0393] Number of authentication digest data authentication_hash_number_minus1
[0394] 8-bit unsigned integer. Plus 1 represents the length of the signature data, in bytes, and the value should be 0 to 255.
[0395] Authentication digest data authentication_hash
[0396] Binary data, with a length of the digest data length corresponding to the hash type in the correspondence table between the hash type and the specific algorithm in the security parameter set, in bytes.
[0397] Length of signature data authentication_data_length_minus1
[0398] 8-bit unsigned integer. Plus 1 represents the length of the signature data, in bytes, and the value should be 0 to 255.
[0399] Number of bytes of signature data authentication_data[i]
[0400] The i-th byte of the signature data.
[0401] It should be noted that the authentication data RBSP generated in process 700 is new.
[0402] Length of signature certificate chain certificate_chain_length_minus1
[0403] The length of the certificate chain used to verify the signature, plus 1 represents the length of the signature data, in bytes, and the value should be 0 to 65535. When it is 1, it means there is no certificate chain.
[0404] Signature certificate chain certificate_chain_data[i]
[0405] The i-th byte of the signature certificate chain.
[0406] It should be noted that certificate_chain_data and certificate_chain_length_minus1 are optional.
[0407] In addition, in the scenario of temporal SVC coding of the SVAC standard, each data unit includes a second identifier (temporal_id) for identifying the temporal level where the data unit is located; correspondingly, the authentication data RBSP can also include the second identifier (temporal_id). Since in the scenario of temporal SVC coding of the SVAC standard, the temporal base layer (i.e., the data unit with the second identifier being 0) needs to be parsed, in order to ensure that the authentication data can be obtained regardless of whether the temporal enhancement layer is parsed during the authentication process, the value of the second identifier in the NAL unit of the authentication data can be set to 0.
[0408] In the scenario of spatial SVC coding or quality SVC coding of the SVAC standard, each data unit includes a third identifier (layer_id) for identifying the spatial level or quality coding level where the data unit is located; correspondingly, the authentication data RBSP can also include the third identifier (layer_id). Since in the scenario of spatial SVC coding or quality SVC coding of the SVAC standard, the spatial base layer / quality coding base layer (i.e., the data unit with the third identifier being 0) needs to be parsed, in order to ensure that the authentication data can be obtained regardless of whether the spatial enhancement layer / quality coding enhancement layer is parsed during the authentication process, the value of the third identifier in the NAL unit of the authentication data can be set to 0.
[0409] In process 700, the public key can also be added to the authentication data (the public key can be in the signature certificate chain certificate_chain_data). It should be understood that the public key corresponding to the above private key can also be transmitted in other ways, such as being built into the authentication end, transmitted to the authentication end in a certificate, etc., and this application does not limit this.
[0410] Figure 8A A schematic diagram of the authentication process shown by way of example.
[0411] Figure 8B A schematic diagram of the authentication process 600 shown by way of example. Process 800 is a process in which the authentication end realizes data unit authentication when the extended information carries an authentication identifier. Process 800 corresponds to process 700.
[0412] S801, obtain the first authentication identifier of each data unit in a set of data units from the extended information of the bitstream.
[0413] Exemplarily, after the authentication end receives the CEI extension information of the bitstream, when the authentication_flag in the CEI extension information of the bitstream is 1, it is determined that the subsequent set of data units supports authentication. At this time, the syntax elements in the CEI extension information can be continuously parsed in the order of each syntax element in Table 7.
[0414] Exemplarily, by parsing the authentication_id in the CEI extension information, the first authentication identifier of each data unit in a set of data units can be obtained.
[0415] Exemplarily, parse the hash_type in the CEI extension information; according to the value of the parsed hash_type, determine the digest algorithm.
[0416] Exemplarily, parse the signature_type in the CEI extension information; according to the value of the parsed signature_type, determine the signature algorithm.
[0417] Refer to Figure 8A , exemplarily, the n first authentication identifiers are respectively: P1, P2, P3, P4,..., Pn.
[0418] S802, calculate each data unit in a set of data units according to the digest algorithm to obtain the first digest data of each data unit in a set of data units.
[0419] Exemplarily, S802 can refer to the description of the above S602 and will not be elaborated here.
[0420] Among them, the difference between S802 and S602 is that in one possible way of S802, the digest algorithm can be determined according to the hash_type parsed from the CEI extension information of the bitstream.
[0421] S803, obtain the authentication data from the bitstream, and the authentication data includes: signature data, the second authentication identifier of each data unit in a set of data units, and the second digest data of each data unit in a set of data units. The signature data is obtained by signing according to the second digest data of each data unit in a set of data units.
[0422] Exemplarily, S803 can refer to the description of the above S603 and will not be elaborated here.
[0423] S804, verify the signature data according to the public key, the first digest data of each data unit in a set of data units, and the signature algorithm.
[0424] Exemplarily, S804 can refer to the description of the above S604 and will not be elaborated here.
[0425] Among them, the difference between S804 and S604 is that in one possible way of S804, the signature algorithm can be determined according to the signature_type parsed from the CEI extension information of the bitstream. Also, since the camera_idc is not included in the CEI extension information of the bitstream; furthermore, S804 does not include the method of determining the public key according to the camera_idc.
[0426] S805, when the signature data is successfully verified, store the authentication data into the authentication data list.
[0427] S806, search for the authentication data in the authentication data list that matches multiple first authentication identifiers of a group of data units; among them, the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of the group of data units.
[0428] S807, verify multiple first digest data of a group of data units according to multiple second digest data in the matching authentication data.
[0429] Exemplarily, S805 to S807 can refer to the descriptions of S605 to S607 above and will not be elaborated here.
[0430] Figure 9 It is a schematic diagram of the exemplary signature process 900. Among them, the process 900 can be implemented by the signature end 210. The process 900 is a process in which the SVAC signature end realizes the signature of data units by carrying the authentication identifier through the NAL header.
[0431] Exemplarily, when video image authentication needs to be supported, a security parameter set RBSP is generated; the definition of the security parameter set RBSP can be as shown in Table 11 below:
[0432] Table 11 Definition of the security parameter set RBSP
[0433]
[0434]
[0435] Among them, the descriptions of the syntax elements in Table 11 can refer to the descriptions of the syntax elements in Table 6 above and will not be elaborated here.
[0436] It should be noted that compared with the prior art, the security parameter set of this application newly adds: authentication_mode (which can be called the first identifier).
[0437] Exemplarily, the authentication_flag in the safety parameter set RBSP can also be set to 1, so that it can indicate that a set of data units located after the safety parameter set RBSP supports authentication.
[0438] It should be noted that hash_type, signature_type, and camera_idc in the safety parameter set RBSP are optional.
[0439] S901, generate a NAL unit.
[0440] Exemplarily, the NAL unit syntax table can be as shown in Table 12:
[0441] Table 12 NAL unit syntax table
[0442]
[0443] Authentication sequence number authentication_id
[0444] Binary variable. The authentication_idc value of '1' indicates the authentication sequence number and is used to identify the authentication data set it uses.
[0445] Authentication enable flag authentication_idc
[0446] Binary variable. Indicates whether the NAL unit is authenticated. The value of '0' indicates that the NAL unit is not authenticated, and the value of '1' indicates that the NAL unit is authenticated by the authentication method specified in the safety parameter set.
[0447] Temporal layer identifier temporal_id
[0448] 3-bit unsigned integer. Indicates the temporal layer where the NAL unit is located.
[0449] It should be noted that compared with the prior art, in the NAL unit included in the data unit of the present application, a new authentication_id (which can also be called an authentication identifier) is added.
[0450] Exemplarily, during the process of generating the NAL unit, the value of authentication_idc can be set to 1; in this way, it can indicate that the NAL unit needs to be authenticated.
[0451] S902, calculate each data unit in a set of data units according to the digest algorithm to obtain the digest data of each data unit in the set of data units.
[0452] Exemplarily, the number of data units to be authenticated can be determined according to the authentication_id obtained from the NAL unit; that is, the number of data units included in a group of data units.
[0453] For example, if the authentication_id is obtained from 100 NAL units and these 100 authentication_ids are all different, it can be determined that each data unit includes one NAL unit, and a group of data units includes 100 data units.
[0454] For another example, if the authentication_id is obtained from 100 NAL units and every 10 of these 100 authentication_ids are the same, it can be determined that each data unit includes 10 NAL units, and a group of data units includes 10 data units.
[0455] S903, connect the digest data of each data unit in a group of data units, and determine the digest data of the digest data of each data unit in the connected group of data units.
[0456] S904, use the private key to sign the digest data of the digest data of each data unit in the connected group of data units to obtain the signature data.
[0457] S905, encode the authentication data and add the encoded authentication data to the bitstream.
[0458] Exemplarily, S902 to S905 can refer to the descriptions of the above S502 to S505 and will not be elaborated here.
[0459] Among them, the definition of the authentication data RBSP can refer to Table 6 above and will not be elaborated here.
[0460] In addition, in the scenario of temporal SVC coding of the SVAC standard, each data unit includes a second identifier (temporal_id) for identifying the temporal layer where the data unit is located; correspondingly, the authentication data RBSP can also include the second identifier (temporal_id). Since in the scenario of temporal SVC coding of the SVAC standard, the temporal base layer (i.e., the data unit with the second identifier being 0) needs to be parsed, in order to ensure that in the authentication process, whether the temporal enhancement layer is parsed or not, the authentication data can be obtained; the value of the second identifier in the NAL unit of the authentication data can be set to 0.
[0461] In the scenario of spatial SVC coding or quality SVC coding according to the SVAC standard, each data unit includes a third identifier (layer_id) for identifying the spatial layer or quality coding layer where the data unit is located. Correspondingly, the authentication data RBSP may also include the third identifier (layer_id). Since in the scenario of spatial SVC coding or quality SVC coding according to the SVAC standard, the spatial base layer / quality coding base layer (i.e., the data unit with the third identifier being 0) needs to be parsed, in order to ensure that in the authentication process, whether or not the spatial enhancement layer / quality coding enhancement layer is parsed, the authentication data can be obtained. The value of the third identifier in the NAL unit of the authentication data can be set to 0.
[0462] In process 900, the public key can also be added to the authentication data. It should be understood that the public key corresponding to the above private key can also be transmitted in other ways, such as being built into the authentication end and transmitted to the authentication end in a certificate, etc. The present application does not limit this.
[0463] Figure 10A Schematic diagram of the authentication process shown for illustration.
[0464] Figure 10B Schematic diagram of the exemplary authentication process 1000. Among them, process 1000 can be implemented by the authentication end 220. Process 1000 is a process for the SVAC authentication end to authenticate data units when carrying an authentication identifier in the NAL header.
[0465] Exemplarily, after the authentication end 220 receives the security parameter set RBSP of the bitstream, when the authentication_flag in the security parameter set RBSP of the bitstream is 1, it is determined that the subsequent group of data units supports authentication. At this time, the syntax elements in the security parameter set RBSP can be continuously parsed in the order of each syntax element in Table 1.
[0466] Exemplarily, parse the hash_mode in the security parameter set RBSP; when the parsed hash_mode is 0, S602 can be executed.
[0467] Exemplarily, parse the hash_type in the security parameter set RBSP; according to the value of the parsed hash_type, determine the digest algorithm.
[0468] Exemplarily, parse the signature_type in the security parameter set RBSP; according to the value of the parsed signature_type, determine the signature algorithm.
[0469] Exemplarily, parse camera_idc in the parsed security parameter set RBSP; determine the authentication certificate identifier of the camera from which the bitstream's corresponding image is sourced according to the value of camera_idc obtained by parsing.
[0470] S1001, obtain the first authentication identifier of the NAL unit from the NAL units of the bitstream.
[0471] Exemplarily, when the authentication end 220 receives the NAL unit, parse authentication_idc parsed from the NAL unit; when authentication_idc is 1, continue to parse the NAL unit to obtain the first authentication identifier in the NAL unit.
[0472] S1002, calculate for each data unit in a set of data units according to the digest algorithm to obtain the first digest data of each data unit in the set of data units.
[0473] Exemplarily, S1002 may refer to the description of S602 above and will not be elaborated here.
[0474] Exemplarily, the present application does not limit the execution order of S1001 and S1002.
[0475] S1003, obtain authentication data from the bitstream, where the authentication data includes: signature data, the second authentication identifier of each data unit in a set of data units, and the second digest data of each data unit in a set of data units, and the signature data is obtained by signing according to the second digest data of each data unit in a set of data units.
[0476] S1004, verify the signature data according to the public key, the first digest data of each data unit in a set of data units, and the signature algorithm.
[0477] S1005, when the verification of the signature data is successful, store the authentication data in the authentication data list.
[0478] S1006, search in the authentication data list for the authentication data that matches the multiple first authentication identifiers of a set of data units; where the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of a set of data units.
[0479] S1007, verify the multiple first digest data of a set of data units according to the multiple second digest data in the matching authentication data.
[0480] Exemplarily, S1003 to S807 may refer to the descriptions of S603 to S607 above and will not be elaborated here.
[0481] It should be understood that in one possible way, both the security parameter set and the NAL units included in the data unit include an authentication identifier. In one possible way, both the diffusion information and the NAL units included in the data unit include an authentication identifier. In one possible way, both the security parameter set and the extension information include an authentication identifier.
[0482] Figure 11 Schematic diagram of a signature device for a bitstream shown for illustration. The schematic diagram of the signature device for the bitstream can be used to execute the method of the foregoing embodiments. Therefore, the beneficial effects it can achieve can refer to the beneficial effects in the corresponding method provided above and will not be elaborated here.
[0483] Among them, the bitstream includes: a set of data units and the authentication identifier of each data unit in the set of data units.
[0484] Refer to Figure 11 , the signature device 1100 of the bitstream may include:
[0485] The first authentication data acquisition module 1101 is used to acquire authentication data; among them, the authentication data includes: signature data, the authentication identifier of each data unit in a set of data units, and the digest data of each data unit in a set of data units, and the signature data is obtained by signing the digest data of each data unit in a set of data units.
[0486] The addition module 1102 is used to add the authentication data to the bitstream.
[0487] Exemplarily, the signature device 1100 of the bitstream further includes:
[0488] The digest data calculation module is used to calculate each data unit in a set of data units according to the digest algorithm to obtain the digest data of each data unit in a set of data units.
[0489] Exemplarily, the digest data calculation module is further used to connect the digest data of each data unit in a set of data units and determine the digest data of the connected digest data.
[0490] The signature device 1100 of the bitstream further includes:
[0491] The signature module is used to sign the digest data of the connected digest data with a private key to obtain the signature data.
[0492] Exemplarily, the signature device 1100 of the bitstream further includes:
[0493] The authentication data generation module is used to generate authentication data according to the signature data, the authentication identifier of each data unit in a set of data units, and the digest data of each data unit in a set of data units.
[0494] Exemplarily, an adding module 1102 is specifically configured to encode authentication data and add the encoded authentication data to the bitstream.
[0495] Exemplarily, each data unit in a set of data units includes one or more Network Abstraction Layer (NAL) units.
[0496] Exemplarily, multiple NAL units in a set of data units are correlated with each other according to a specified rule, and the decoding order of multiple NAL units in a set of data units is consecutive. That is to say, one data unit is one access unit.
[0497] Exemplarily, each data unit in a set of data units includes an encoded image.
[0498] Exemplarily, each NAL unit includes an authentication identifier of the data unit to which it belongs.
[0499] Exemplarily, the authentication identifier of each data unit in a set of data units in the bitstream is located before the set of data units.
[0500] Exemplarily, the bitstream further includes a security parameter set, and the security parameter set includes the authentication identifier of each data unit in a set of data units.
[0501] Exemplarily, the bitstream further includes extension information, and the extension information includes the authentication identifier of each data unit in a set of data units.
[0502] Exemplarily, the bitstream further includes a first identifier, and the first identifier indicates the authentication mode adopted by a set of data units.
[0503] Exemplarily, the bitstream further includes a security parameter set, and the security parameter set includes the first identifier.
[0504] Exemplarily, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein, the second identifier indicates the temporal level, and the value of the second identifier is 0.
[0505] Exemplarily, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a third identifier; wherein, the third identifier indicates the spatial level or the quality coding level, and the value of the third identifier is 0.
[0506] Figure 12 It is a schematic diagram of an authentication device for the bitstream shown exemplarily. The schematic diagram of the authentication device for the bitstream can be used to execute the method of the foregoing embodiments. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be elaborated here.
[0507] Referring to Figure 12 , the authentication device 1200 for the bitstream includes:
[0508] The authentication identifier acquisition module 1201 is configured to acquire a first authentication identifier of each data unit in a set of data units from a bitstream;
[0509] The summary data determination module 1202 is configured to determine first summary data of each data unit in a set of data units;
[0510] The second authentication data acquisition module 1203 is configured to acquire authentication data from a bitstream, where the authentication data includes: signature data, a second authentication identifier of each data unit in a set of data units, and second summary data of each data unit in a set of data units, and the signature data is obtained by signing according to the second summary data of each data unit in a set of data units;
[0511] The authentication data storage module 1204 is configured to store the authentication data in an authentication data list when the verification of the signature data is successful;
[0512] The authentication data search module 1205 is configured to search for authentication data that matches multiple first authentication identifiers of a set of data units from the authentication data list; where the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of a set of data units;
[0513] The verification module 1206 is configured to verify multiple first summary data of a set of data units according to multiple second summary data in the matching authentication data.
[0514] Exemplarily, the summary data determination module 1202 is specifically configured to calculate each data unit in a set of data units according to a summary algorithm to obtain first summary data of each data unit in a set of data units.
[0515] Exemplarily, the bitstream authentication device 1200 further includes:
[0516] The public key acquisition module is configured to acquire a public key;
[0517] The summary data determination module 1202 is further configured to concatenate second summary data of each data unit in a set of data units and determine summary data of the concatenated second summary data;
[0518] The verification module 1206 is further configured to verify the signature data according to the public key, the summary data of the concatenated second summary data, and a signature algorithm.
[0519] Exemplarily, the bitstream authentication device 1200 further includes:
[0520] The identifier acquisition module is configured to acquire a first identifier from a bitstream, where the first identifier indicates an authentication mode adopted by a set of data units;
[0521] When the value of the first identifier is the first preset value, the summary data determination module is used to determine the first summary data of each data unit in a set of data units.
[0522] Exemplarily, the identifier acquisition module is further configured to acquire a fourth identifier from the bitstream and determine a value n according to the fourth identifier; wherein, a set of data units includes n data units, and n is a positive integer.
[0523] Exemplarily, the authentication device 1200 of the bitstream further includes:
[0524] The summary data acquisition module is configured to acquire the second summary data of each data unit among the n data units from the bitstream.
[0525] Exemplarily, each data unit in a set of data units includes one or more network abstraction layer (NAL) units.
[0526] Exemplarily, multiple NAL units in a set of data units are correlated with each other according to a specified rule, and the decoding order of multiple NAL units in a set of data units is continuous. That is to say, one data unit is one access unit.
[0527] Exemplarily, each data unit in a set of data units includes an encoded image.
[0528] Exemplarily, the verification module 1206 is specifically configured to, for the first data unit in a set of data units: if a second summary data identical to the first summary data of the first data unit is found among multiple second summary data in the matching authentication data, determine that the authentication of the first data unit is successful; otherwise, determine that the authentication of the first data unit fails.
[0529] In one example, Figure 13 A schematic block diagram of a device 1300 according to an embodiment of the present application is shown. The device 1300 may include: a processor 1301 and a transceiver / transceiver pin 1302. Optionally, it further includes a memory 1303.
[0530] Each component of the device 1300 is coupled together through a bus 1304. Among them, the bus 1304 includes not only a data bus, but also a power bus, a control bus, and a status signal bus. However, for the sake of clear illustration, all kinds of buses are referred to as the bus 1304 in the figure.
[0531] Optionally, the memory 1303 may be used to store the instructions in the foregoing method embodiments. The processor 1301 may be configured to execute the instructions in the memory 1303, control the receiving pin to receive signals, and control the sending pin to send signals.
[0532] The device 1300 may be an electronic device or a chip of an electronic device in the above method embodiments.
[0533] Among them, all relevant contents of each step involved in the above method embodiments can be cited in the function descriptions of the corresponding functional modules, and will not be elaborated here.
[0534] An embodiment of the present application further provides a chip, including one or more interface circuits and one or more processors; the one or more processors receive or send data through the one or more interface circuits, and when the one or more processors execute computer instructions, the steps of the above related method are executed to implement the steps of the method in the above embodiments. Among them, the interface circuit is a transceiver / transceiver pin 1302.
[0535] This embodiment further provides a computer-readable storage medium, in which computer instructions are stored. When the computer instructions run on an electronic device, the electronic device is enabled to execute the above related method steps to implement the method in the above embodiments.
[0536] This embodiment further provides a computer program product, which includes computer instructions. When the computer instructions are executed by a computer or a processor, the computer is enabled to execute the above related steps to implement the method in the above embodiments.
[0537] In addition, an embodiment of the present application further provides a device, which may specifically be a chip, a component or a module. The device may include a processor and a memory connected to each other; among them, the memory is used to store computer execution instructions. When the device runs, the processor may execute the computer execution instructions stored in the memory, so that the chip executes the methods in the above method embodiments.
[0538] Among them, the electronic device, computer-readable storage medium, computer program product or chip provided in this embodiment are all used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be elaborated here.
[0539] Through the description of the above embodiments, those skilled in the art can understand that for the convenience and conciseness of description, only the above division of each functional module is used as an example. In actual applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.
[0540] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of devices or units can be in electrical, mechanical or other forms.
[0541] The units described as separate components may or may not be physically separated. The components displayed as units may be one physical unit or multiple physical units, that is, they can be located in one place, or they can be distributed to multiple different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0542] In addition, in each embodiment of the present application, each functional unit can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.
[0543] Any content in each embodiment of the present application, as well as any content in the same embodiment, can be freely combined. Any combination of the above content is within the scope of the present application.
[0544] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on such an understanding, the technical solution of the embodiments of the present application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The software product is stored in a storage medium and includes several instructions to enable a device (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the methods in each embodiment of the present application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM), random access memories (RAM), magnetic disks or optical discs that can store program codes.
[0545] The steps of the method or algorithm described in connection with the disclosure of the embodiments of the present application may be implemented in a hardware manner or by a processor executing software instructions. The software instructions may consist of corresponding software modules, and the software modules may be stored in a random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), registers, hard disk, removable hard disk, CD-ROM, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium may also be a component of the processor. The processor and the storage medium may be located in an ASIC.
[0546] Those skilled in the art should be able to realize that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented by hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. The computer-readable medium includes a computer-readable storage medium and a communication medium, where the communication medium includes any medium that facilitates the transmission of a computer program from one place to another. The storage medium may be any available medium accessible by a general-purpose or special-purpose computer.
[0547] The embodiments of the present application have been described above in conjunction with the accompanying drawings, but the present application is not limited to the above specific embodiments. The above specific embodiments are merely illustrative and not restrictive. Under the inspiration of the present application, those of ordinary skill in the art can also make many forms without departing from the purpose of the present application and the scope protected by the claims, and all of them belong to the protection scope of the present application.
Claims
1. A method for signing a bitstream, characterized in that, the bitstream includes: a set of data units and an authentication identifier for each data unit in the set of data units, and the method includes: obtaining authentication data; wherein, the authentication data includes: signature data, an authentication identifier for each data unit in the set of data units, and digest data for each data unit in the set of data units, and the signature data is obtained by signing the digest data for each data unit in the set of data units; adding the authentication data to the bitstream.
2. The method according to claim 1, characterized in that, the method further includes: calculating, according to a digest algorithm, each data unit in the set of data units to obtain the digest data for each data unit in the set of data units.
3. The method according to claim 1 or 2, characterized in that, the method further includes: concatenating the digest data for each data unit in the set of data units, and determining the digest data of the concatenated digest data; signing the digest data of the concatenated digest data with a private key to obtain the signature data.
4. The method according to any one of claims 1 to 3, characterized in that, the method further includes: generating the authentication data according to the signature data, the authentication identifier for each data unit in the set of data units, and the digest data for each data unit in the set of data units.
5. The method according to any one of claims 1 to 4, characterized in that, the adding the authentication data to the bitstream includes: encoding the authentication data, and adding the encoded authentication data to the bitstream.
6. The method according to any one of claims 1 to 5, characterized in that, each data unit in the set of data units includes one or more network abstraction layer (NAL) units.
7. The method according to claim 6, characterized in that, multiple NAL units in the set of data units are associated with each other according to a specified rule, and the decoding order of multiple NAL units in the set of data units is consecutive.
8. The method according to any one of claims 1 to 5, characterized in that, each data unit in the set of data units includes an encoded image.
9. The method according to any one of claims 1 to 6, characterized in that, the authentication identifier for each data unit in the set of data units is located before the set of data units.
10. The method according to claim 6 or 7, characterized in that, each NAL unit includes the authentication identifier of the data unit to which it belongs.
11. The method according to any one of claims 1 to 10, characterized in that, the bitstream further includes a security parameter set, and the security parameter set includes the authentication identifier for each data unit in the set of data units.
12. The method according to any one of claims 1 to 11, characterized in that, the bitstream further includes extension information, and the extension information includes the authentication identifier for each data unit in the set of data units.
13. The method according to any one of claims 1 to 12, characterized in that, The bitstream further includes a first identifier that indicates the authentication mode adopted by the set of data units.
14. The method according to claim 13, wherein, the bitstream further includes a security parameter set, and the security parameter set includes the first identifier.
15. The method according to any one of claims 1 to 14, wherein, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein, the second identifier indicates a temporal level, and the value of the second identifier is 0.
16. The method according to any one of claims 1 to 14, wherein, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a third identifier; wherein, the third identifier indicates a spatial level or a quality coding level, and the value of the third identifier is 0.
17. A bitstream, wherein, the bitstream includes: a set of data units, authentication data, and an authentication identifier for each data unit in the set of data units; wherein, the authentication data includes: signature data, an authentication identifier for each data unit in the set of data units, and digest data for each data unit in the set of data units, and the signature data is obtained by signing the digest data for each data unit in the set of data units.
18. The bitstream according to claim 17, wherein, each data unit in the set of data units includes one or more Network Abstraction Layer (NAL) units.
19. The bitstream according to claim 18, wherein, the multiple NAL units in the set of data units are associated with each other according to a specified rule, and the decoding order of the multiple NAL units in the set of data units is consecutive.
20. The bitstream according to claim 17, wherein, each data unit in the set of data units includes an encoded image.
21. The bitstream according to any one of claims 17 to 20, wherein, the authentication identifier for each data unit in the set of data units is located before the set of data units.
22. The bitstream according to claim 18 or 19, wherein, each NAL unit includes the authentication identifier of the data unit to which it belongs.
23. The bitstream according to any one of claims 17 to 22, wherein, the bitstream further includes a security parameter set, and the security parameter set includes the authentication identifier for each data unit in the set of data units.
24. The bitstream according to any one of claims 17 to 23, wherein, the bitstream further includes extension information, and the extension information includes the authentication identifier for each data unit in the set of data units.
25. The bitstream according to any one of claims 17 to 24, wherein, the bitstream further includes a first identifier that indicates the authentication mode adopted by the set of data units.
26. The bitstream according to claim 25, wherein, the bitstream further includes a security parameter set, and the security parameter set includes the first identifier.
27. The bitstream according to any one of claims 17 to 26, wherein, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a second identifier; wherein, the second identifier indicates a temporal level, and the value of the second identifier is 0.
28. The bitstream according to any one of claims 17 to 26, wherein, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data includes a third identifier; wherein, the third identifier indicates a spatial level or a quality coding level, and the value of the third identifier is 0.
29. The bitstream according to any one of claims 17 to 28, wherein, the bitstream further includes a NAL unit of authentication data, and the NAL unit of authentication data further includes a fourth identifier, and the fourth identifier is used to determine the quantity of digest data included in the authentication data.
30. A method for authenticating a bitstream, wherein, the method includes: obtaining a first authentication identifier of each data unit in a group of data units from the bitstream; determining first digest data of each data unit in the group of data units; obtaining authentication data from the bitstream, where the authentication data includes: signature data, a second authentication identifier of each data unit in the group of data units, and second digest data of each data unit in the group of data units, and the signature data is obtained by signing according to the second digest data of each data unit in the group of data units; when the verification of the signature data is successful, storing the authentication data into an authentication data list; searching, from the authentication data list, for authentication data that matches multiple first authentication identifiers of the group of data units; wherein, the matching authentication data includes multiple second authentication identifiers that are respectively the same as the multiple first authentication identifiers of the group of data units; verifying the multiple first digest data of the group of data units according to the multiple second digest data in the matching authentication data.
31. The method according to claim 30, wherein, the determining first digest data of each data unit in the group of data units includes: calculating each data unit in the group of data units according to a digest algorithm to obtain first digest data of each data unit in the group of data units.
32. The method according to claim 30 or 31, wherein, the method further includes: obtaining a public key; connecting the second digest data of each data unit in the group of data units to determine digest data of the connected second digest data; verifying the signature data according to the public key, the digest data of the connected second digest data, and a signature algorithm.
33. The method according to any one of claims 30 to 32, wherein, the method further includes: obtaining a first identifier from the bitstream, where the first identifier indicates an authentication mode adopted by the group of data units; when the value of the first identifier is a first preset value, performing the step of determining first digest data of each data unit in the group of data units.
34. The method according to any one of claims 30 to 33, characterized in that, the method further comprises: obtaining a fourth identifier from the bitstream, and determining a value n according to the fourth identifier; wherein, the set of data units includes n data units, and n is a positive integer; obtaining second digest data of each of the n data units from the bitstream.
35. The method according to any one of claims 30 to 34, characterized in that, each data unit in the set of data units includes one or more Network Abstraction Layer (NAL) units.
36. The method according to claim 35, characterized in that, multiple NAL units in the set of data units are correlated with each other according to a specified rule, and the decoding order of the multiple NAL units in the set of data units is consecutive.
37. The method according to any one of claims 30 to 34, characterized in that, each data unit in the set of data units includes an encoded image.
38. The method according to any one of claims 30 to 37, characterized in that, verifying the multiple first digest data of the set of data units according to the multiple second digest data in the matched authentication data includes: For the first data unit in the set of data units: If a second digest data identical to the first digest data of the first data unit is found among the multiple second digest data in the matched authentication data, it is determined that the authentication of the first data unit is successful; otherwise, it is determined that the authentication of the first data unit fails.
39. An electronic device, characterized in that, comprising: a memory and a processor, the memory being coupled to the processor; the memory stores program instructions, and when the program instructions are executed by the processor, the electronic device executes the signature method of the bitstream according to any one of claims 1 to 16, or executes the authentication method of the bitstream according to any one of claims 30 to 38.
40. A computer-readable storage medium, characterized in that, the computer-readable storage medium stores a computer program, and when the computer program runs on a computer or a processor, the computer or the processor executes the method according to any one of claims 1 to 16, or executes the method according to any one of claims 30 to 38.
41. A computer program product, characterized in that, the computer program product contains computer instructions, and when the computer instructions are executed by a computer or a processor, the steps of the method according to any one of claims 1 to 16 are executed, or the steps of the method according to any one of claims 30 to 38 are executed.
42. A computer-readable storage medium, characterized in that, the computer-readable storage medium stores the bitstream according to any one of claims 16 to 29.